Truly remarkable Gregg. Your zeal is commendable. Your argument is
very valuable and worth debating.
You say: it's all there today. There are many that would say that it
was all there with CORBA. Many SOA implementations using CORBA are
out there. And that was governed by a very large consortium and not a
single vendor. And wasn't limited to one language either. But many of
us that deployed CORBA wouldn't and don't force CORBA on people
today! It's but one of many useful technologies out there for
implementing services.
Why CORBA didn't remain the standard used in SOA can be put down to
several factors. We've all heard many over there years. I only bring
this up because I think it is important o understand from your Java-
has-all perspective.
1) Microsoft wasn't involved - Microsoft being a large participant in
the enterprise meant their exclusion from the OMG and CORBA left many
doubting whether CORBA could be a complete standard. Having to bridge
from COM to CORBA and CORBA to COM seemed unnatural. (products like
COMet did this). Microsoft being involved in the WS- community helps
in many ways to ease the markets worries that WS- might fail. Mind
you it doesn't stop some of the in-fighting ;-) What's interesting
from the Java perspective is that Microsoft went the C# route. Hence
in this way Java is not unlike CORBA. (Also see notes below about
platform control)
2) Standards process too slow. The OMG were accused of having a
cumbersome and slow standards ratification process. In fact many of
us heard the "what's great about Java and the JCP is that it's
controlled by a single vendor and therefore gets things ratified
fast. No more waiting on the OMG." So quite often a single vendor can
have a positive effect on standards. Which is amusing .. to me
anyway. What's also interesting about this argument is that Web
services standards are in danger of hitting this problem. There are
so many political and commercial battles going on that the standards
bodies are playing right into ... well right into arguments similar
to your own .... like Java is the cure for cancer and world peace :-)
3) CORBA is too complicated. Actually with the introduction of POA
and all it's policies and objects-by-value you can see how this
argument came up. The problem here is that not all SOA
implementations need all the details that we "experts" debate about
in these forums. These standards need to be discussed, defined and
ratified for like the top 5% (if even that) of organizations that
need them all. But there are lots of organizations that need only the
basics to implement SOA. If their needs grow then the standards will
be there for them but they don't need it all immediately. I think
this causes paralysis for those implementing SOA. We all need to tell
the market to START SMALL!!! (even if you're big). What's interesting
about this from your (Java) arguments perspective is that Java has
become VERY complicated too.
I think there are more arguments that are less obvious.
I think System Integrators (SI) play a big role in popularity of
products which then has effect on standards. Where can they make
money? Moving to a new standard might mean that they can rebuild what
they just built in five years in the "new and improved" technology.
I think that analysts need something new and fresh to say to their
clients and the market. No use saying "hey what you used last year is
just great! Keep using it. We have nothing new to say" And so the
analyst feeds into the cycle ... which often becomes recycle. (No
offense to Anne et al .. it's just the nature of the business ...
they also try to keep vendors honest).
And platform players, once upon a time middleware and building
distributed services meant nothing on the radar to big platform
vendors. But there was money to be made and control of the middleware
part of the stack meant more control for your platform. And it's no
use being 3rd or 4th on the leader board. So when you are .. invent
something new ... then get the analysts and SIs on board. And so the
cycle continues.
Quite a cynical view perhaps but that my observation. And it does
generate innovation. No doubt about that. But there is a lot of
recycle and "emperor's new clothes" factors involved too.
But I reiterate what I said to you earlier: there is no J in SOA.
Sure you can wrap everything Java. Bt many of us don't want to, and
won't and feel we have very good reasons for not wanting too. Most
importantly why force Java in an environment that doesn't need it.
Take for instance COBOL application in a CICS environment. Why not
just Web service enable them naturally rather than forcing Java and a
JVM on front??
BTW I like Java and have been using it for about 10 years. I just
don't see it as the gateway to everything.
William
On Jan 22, 2006, at 6:11 PM, Gregg Wonderly wrote:
> 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
>
>
>
>
>
>
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/
