Friday, June 09, 2006

Introducing the O/WS Impedance Mismatch

According to French cartoonist Marcel Gotlib it takes at least four arms to correctly fold a road map, which makes it virtually impossible for any human beings. So if you know someone who can fold a road map, he certainly is a visitor from another planet.

Nowadays, there is another way of spotting such hidden visitors: if you know someone who can make sense of these crazy web service standards, then she might well be from another planet.

In fact, you do not need four arms for that, but four heads:
  • one for dealing with your programming language,
  • one for dealing with the programming language of the service you want to call or the client you want to be called from,
  • one for dealing with the subtleties of SOAP style and encoding and other WSDL non-senses,
  • and one for the cursing, because believe me, there will be a lot of profanity involved.
How did we get there? Why on Earth do we have to deal with a new impedance mismatch issue? The origin of the classical O/R one is obvious: databases and object oriented worlds followed two different tracks at different periods of time and then decided to meet (to collide would be a more appropriate term).

But the origin of this new Object-WebService Impedance Mismatch are more confused to me. The lessons from CORBA and DCOM were well known so creating an inter-operable, easy to use and extend standard for web services should have been possible.

The basics were good: HTTP is simple yet powerful and XML is strict yet offers plenty of room for extensibility. But we are now far away from those basics. Two basic examples:
  • SOAP does not mean "Simple Object Access Protocol" anymore, since June 2003 it simply means soap, voila! Some said because the "Object Access" part was misleading, but the truth is that the "Simple" part was misleading. There is nothing simple anymore there. Moreover, soap is a good choice because it can make you slip and crash violently on the floor. It can also burn your eyes and make you cry. You have been warned.

  • standard APIs are just plain lame. If you go for the static stubs, you get so tightly coupled to the service you invoke that it would be wiser to embed its code in your application, at least the performance would gain. If you go for the dynamic proxies, you will swallow your hat when you will call services that disguise their RPC aspirations in document literal draperies. What else can you try? Proprietary APIs that outfox the standard ones? Probably, if it is an option.
I will not even mention the tragic WS-* family, where some members bear the same moniker to be sure that the bravest who were still trying hard to find their way out, will stumble and fall to the ground in a terrible noise of crushed iron.

Is there any hope?

If you control both sides of the equation, do yourself a favor and take some REST: any pragmatic XML over HTTP approach will make your live easier and might even extend it of a few years.

If you control only one side and have to deal with the O/WS mismatch, do not distribute the misery in all of your consumers or producers: federate the knowledge of the WS-Arcanes in a pervasive middleware component, have your guys talk only to it and let it handle the chewing and spitting of standard web service messages to the outside (and cruel) world.

2 comments:

Anonymous said...

I agree with you.

What I have often seen is an enormous over-engineering in SOAP WSDL (like very complex schemas) which strongly compromise the interoperability. XML is eXtensible so people can extend it to much.

But once upon a time I was a CORBA developer and there were also services like those of CORBAMed where the IDL was so complex IONA's and Visigenic's IDL compilers could not make sense of it...

KISS (Keep It Simple...) & Use the technology for its strength should be the best practices here.

David Dossot said...

Thanks for sharing your experience and insight.

KISS is certainly a good principle to follow.

I am not scared to do such heresies like building a SOAP message "by hand" (ie with a StringBuilder) and HTTP posting it to a webservice. The stripping the result with regexp and converting them to typed data with basic parsing features.

All this amount to a few lines of code, does not require any extra jar in the classpath, nor it needs any obscure XML configuration file.

It does not offer the flexibility mainstream webservice APIs do but who cares? Whatever the technique, I am somehow coupled to the distant service I am calling. If this distant service changes, I will have to modify and redeploy my client anyway.

So why bothering with a hammer when I simply need to whack a fly?