Friday, July 16, 2004

WSDL versus JINI

Sean Landis argues that Web Services are not a good way of implementing SOA. In his view, JINI is better - the true successor to CORBA. His argument seems to be based on the assertion that Java has a better semantics than WSDL.

This argument is causing ripples of bluster and indignation in the blogsphere, for example Stevan Tilkov. Tilkov can't say what's wrong with Landis's argument, or can't be bothered. But see comment by Steve Laughran.

Of course, when you are doing anything interesting (non-trivial) in SOA, there are important semantic issues - and these apply regardless whether you are using web services or JINI. Of course, the choice between web services and Jini will have a significant impact at the technology level, with particular regard to technological heterogeneity. But does this choice have any real impact at the business/information/application services level? If I'm a business analyst or enterprise application architect, do I really care whether it's web services or JINI in the transport layer, or is it someone else's problem?

Lawrence Wilkes of the CBDI Forum writes
But JINI only means JAVA

I am sure JINI is wonderful, but will these people EVER learn that the world is not predicated on JAVA? And running JMV on Windows is NOT the answer....

If you control ALL the endpoints that you might be able to choose JAVA/JINI But what does that do to the principle of loose coupling? What happens when an endpoint changes (as it INEVITABLY will). And no, I don't want to have to rebuild the links if an endpoint changes to another technology - I want it to happen seamlessly, dynamically.

Sean asks "Why do people base their SOA on Web Services?" but he never mentions ANY of the basic reasons for using WS once! No mention of loose coupling, platform independence, richer specification (not just an IDL), design and run time applicability, etc, etc.

And as for "For example, if there's a degree of dynamic behaviour, if services may come and go, then JINI would be better. If the environment is static, then web services is great. " Well that seems to completely misunderstand the objective of Web Services. And if the new service is NOT java-based - what then?

Or what about "It's trivial to write a Java interface but even a simple interface is daunting in WSDL" Well NO ONE WRITES WSDL ... Just like no one should write JINI - but programmers (as Sean is) never understand this point - so they compare the complexity of writing the code, totally failing to see the benefits the code contains, and that the code doesn't have to be written or inspected by humans - its MACHINE READABLE so we can benefit from AUTOMATION....

Java is so 90's. This is the 21st century, we don't want solutions from the last millennium.
We know that traditional developers find loose coupling scary - so they find ways to retreat back into a homogeneous world. JINI/JAVA is a great way to do this. Of course WSDL doesn't solve all the problems of an open distributed world - but it doesn't hide from them either.


Stefan Tilkov said...

That I *don't* say what's wrong with his argument may be true. That I *can't* is an assumption on your part :-)

Sean Landis said...

I stumbled across SOAPbox while googling. I can't resist responding to some of the points presented by Mr. Wilkes. I may occasionally borrow some of Mr. Wilkes' words - modified slightly - to help me make my points...

I wonder when will these people EVER learn that the world is not predicated on protocols? Seriously, this is one of the important tradeoffs I try to explain in my artima blog. You can standardize on protocols and be language independent, or you can standardize on language and by protocol independent. Which is better? It depends, but your choice will certainly determine the eventual nature, strengths, and weaknesses of your system.

In my original post I did state that controlling the endpoint platform was helpful. But let's look at this another way: one could easily establish a JVM running a facade between a Jini-based SOA infrastructure and their internal infrastructure. Isn't that what web services do? Isn't it true that typical WS deployments require a facade of some sort on every actual service? How may of these services are native web services? Sure a vendor can provide a WS interface, but there's still a fairly thick layer between your actual service and the web service SOA. Why would it be any more complicated, or any worse, to establish a facade in Java/JINI than in your favorite WS implementation? Tools. Right. Well, they're fine for one or two revisions of any particular component in your system, but they tend to rapidly drift when any one of the dozen WS technologies, or your actual service, gets reved. Yeah, a Java/Jini approach struggles with this issue too, just with a much smaller number of independent revisions and standards to deal with.

I'm confused about Mr. Wilkes concern about loose coupling. Endpoints do change and why would anyone have to rebuild the links when they do? I'm surprised he seems to think web services are somehow more dynamic than Jini. Mr. Wilkes mustn't understand Jini.

I don't think Mr. Wilkes read my post very carefully either. He states: "...but he never mentions ANY of the basic reasons for using WS once! No mention of loose coupling, platform independence, richer specification (not just an IDL), design and run time applicability, etc, etc."

Actually, I did mention in the conclusion that web services is an excellent integration technology, especially within an IT environment. I also said that if a web client environment is your goal, then WS is the way to go. I also go into quite a bit of detail on why I do not think platform independence is all it's cracked up to be. And finally I think I made a great argument as to why Java is a richer specification that WS can acheive. Regarding design and runtime applicability, I can't comment as I don't know what that means.

The main trouble I have with the Web Services religion is that its acolytes teach us that WS is best for everything. My point is that it's not. And so I believe that it is Mr. Wilkes who seems to "completely misunderstand the objective of Web Services." To reiterate what I said in my blog, if platform independence is a fundamental requirement, and you are willing to give up some of the benefits I outline therein, then of course WS is the way to go.

Clearly Mr. Wilkes totally missed the point I was trying to make by comparing the complexity of WSDL with the simplicity of a Java interface. Sure, most people use tools and don't write WSDL. The point is that the marshalling and unmarshalling on the endpoints (or the tools for that matter) must be trusted to do the right thing. The right thing on both ends - even the end that Mr. Wilkes is so worried about because he can't control it. I'm a veteran of many CORBA battles and I know that language independence and standarized protocols lead to loss of hair. Oh, and by the way, the code is only machine [actually software] readable if the machine [software] doesn't bollux it up. Java code can be automated too and you take the same risks along with the benefits.

This loose coupling concept seems to be so fundamental to Mr. Wilkes arguement, but I just haven't drunk enough Web Services coolaid to know what he's talking about. Unless it's language coupling. In that case, geez, I get so tired of these (uh, if your not a programmer, what are you?) retreating to a homogeneous world. A single protocol is a great way to do this, but it's so 80's. Anyone old enough to remember Sun RPC?

Ok, I had a little fun at Lawerence's expense. My appologies. But seriously, the bottom line is that big systems which tie together many heterogeneous technologies must standardize on something and adapt to something else. You can standardize on a protocol and adapt to a language, or you can standardize on a language and adapt to the protocols. I argue that there's more power intrinsic in the second approach for a certain class of applications. I would also agree that the first approach is more suitable for other classes of applications and may even be preferable for some theoretical middle ground area depending on the environment, the tools, etc. Still, I stand by my claim that Jini is a better SOA technology than WS in most cases, and I think I back that up in my blog.