William Henry wrote:
> And some people are getting confused with their knowledge of Java :-)
>
> "All the pieces of SOA are here". One piece missing - there is no J
> in SOA ;-)
>
> Not to say that Java isn't playing a big part in SOA deployments but
> there are a lot of non-Java applications out there that need
> something more.
>
> If your a green fields shop starting off with a homogenous
> environment then perhaps Java is a good choice.
It's a simple choice William. Do you take a toolset that solves your problem
directly, and apply it, or do you use 5 different toolsets, all of which don't
address issues in their domains, which are imperative to address, and invest
money, time and your ability to expand your needs in the future?
To draw on another thread, the more declarative your solution is, the more
confined you will be do the features available in the declaration. The more
imperative your solution is, the more opportunity you have improve, upgrade and
morph your solution over time, independently of the vendors.
Object oriented programming in java, and specifically the use of interfaces,
provides a declarative form of contract, while implementations of that
interface
provide you the flexibility of an imperative solution. Other aspects of object
oriented programming and the Java language provide a mallable gap between
declarative vs imperative programming.
The important thing about mobile code is it allows for imperative
implementations of declarative contracts to travel the network spontaneously.
Java is a network focused programming language (the Network is the Computer)
from many perspectives.
What many people are missing out on is that the WS standards are adding feature
after feature that are already available in the Java/Jini programming
environment. There are still large gaps in capabilities.
The standards based development of WS standards is extremely vendor centric.
The vendors are deciding which problems to solve and which things to make work
for you. You are not in control at all. In order to do something different,
you have to have doors into every toolset and platform that you need which will
allow you to amend document content, change semantic behavior etc.
If you go down this path, you'll be able to solve exactly the set of problems
that the vendors find fruitful to develop for. This means the big guys with
the
money will get what they need and the small guys with the needs will for ever
invest in something different, hunt and searching for the "something" that will
actually work the way they need it.
Historically, this is what has made the cost of business for small companies so
much larger than one might expect.
Enjoy your ride, the path is bumpy and the road will bend sharply when you
least
expect it.
Gregg Wonderly
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
