Eric Newcomer wrote:
> I have to point out that Java is under the control of
> a single vendor, which makes it about as vendor
> controlled as a technology can get.
Java is controlled by a community process which everyone can participate in.
Sun Microsystems plays a sheparding roll in the community by having a sizeable
presense in engineering representation. They also have the predominate
implementation under their direct control. There are several implementations
of
the Java virtual machine which you can choose to use, instead of Sun's.
However, due to the breath of features and complexity of implementation, most
of
the implementations you can use, are based on some iteration of the Sun
Microsystems version.
Who is in charge of the evolution of your application server environment,
operating system and language platform? Probably not you or your company.
Everyone is dependent on a vendor, a technology, and its evolution. Right now,
the Java platform leads in terms of technical breadth and capabilities for
supporting SOA using mobile code.
That may change over time as other platforms evolve. But, those which choose
not to support mobile code, will forever burden the users with massive
dependencies on versioning, configuration, and (re)distribution/updates.
Many people's experiences with J2EE and associated APP servers frame their
opinions of Java and what they should use Java to do. J2EE is not Java. J2EE
is but a vertical market platform that has many problems due to the fact that
it
was one of the first platforms to target the associated space. All of the
leasons learned are being used to experiment with new technologies involving
Java and many other language platforms.
It's the dynamic of that arena which will control how "web applications" are
developed in the future. If your SOA is not about "web applications", you are
probably wondering why you have to use all of these "web" technologies.
The Java platform, provides a great platform for doing "everything" that you
need your SOA to do. Where you have completely Java based services with lots
of
traffic flowing, you can use native Java streams for messaging between them.
For non-Java pieces, you can use the Jini platform to put a Java face on your
legacy application, and employ mobile code to optimize access to a batch mode
service by using local execution to iterate through large data sets without
exposing a batch API if not needed. In places where the same data is needed in
batches, you can include a service interface for that as needed. The service
side of your delegate service is the same.
Lots of choices available in using Java. Lots of opportunity to tune your
implementation without an API change. And, Java has application level security
built in. You don't have to tunnel your service over HTTP to take advantage of
some hardware devices add on security implementation. You can use Kerberos or
X.5xx or something competely different, to deploy authentication with your
transport implementation. Authorization is then controlled by the Java
security
model.
This is available today, no need to wait for your vendor to provide it, no need
to wait for the standards to be developed.
The fact is that most other non-Java "SOA" platforms are so far behind on
network computing, that their only recourse is to develop new standards to slow
down the pace so that they can stay alive and participate.
How much do you want to pay, and how long do you want to wait?
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/
