
They were asking for it the day they called it "SOAP envelope".
Postal Service 101: kids, when you want to send a letter, you prepare the contents, then put it in the envelope, close it, THEN write the address ON THE OUTSIDE. You don't do things like, say, put the address inside then close the envelope, write a different address and enjoy the foregoing mail-bouncing madness.
You listening, WS-Addressing guys? As a matter of fact, if you decide to do that, somebody would have to parse the full message in order to deliver it, which has been pointed out as a major architecture flaw for load-balancing a real application.
When the message is being parsed it has already arrived. If I want a custom delivery policy, surely the same technology that handles the http/jms/smtp (ahem) stuff can do this nicely, there is no point in repeating this "feature" in the standard. Be it known that anyways, most of the ESB providers chose to ignore this and implement their own mechanisms, easier to use and more flexible.
If I have seen further it is by standing on ye shoulders of Giants -- Newton to Hooke.The OSI model demonstrates a different approach. With OSI each layer solves its part of the problem and delegates the rest to the layers beneath it; this way, TCP does not try to solve IP-addressing problems such as reachability or routing.
With web services - fuck the previous work! We have redone everything from scratch: security, encription, addressing, I would rewrite the ISO encoding if given the chance. No way I would reuse that hippie SSL thing or JMS reliable delivery or the other. They do not work, and the solution used to send a credit card over the internet to purchase a book at amazon is obviously insufficient to implement communication between systems because of, ah, things.
Say I have to develop a Single-Sign-On system; I configure security for my web portal, integrate it with the SSO provider, then integrate it again with WS-Security and WS-SecureConversation just because.
Any sufficiently advanced incompetence is indistinguishable from malice -- The Napoleon-Clarke LawThere is only one possible reason for such a blatant wheel-reinvention (other than a terminal syphilis and lobotomy combo): control. The OSI layers where designed by people from an academic background with no corporate interest behind, trying to achieve interoperability for the network. The WS standards have been designed by two major players (IBM and Microsoft), and by ignoring the current state-of-the-art they got complete control over the whole enchilada, a clean ground to make products that compete.
If you make my same mistake and get your copy of the Web Service Platform Architecture book (can I have my money back?), you will learn that not all transport protocols implement the great manna of technologies that wrap the web services parade. Boy, if I wanted to implement encryption or security over IMAP or FTP, I would be doomed to failure because nobody in the world has ever done it before.
That was sarcasm.
This argument happens to be a two-sided sword: the standard goes tiptoeing over the fact that if you want to attach big files to your SOAP message, you must use XOP *cough*that only works with http*cough*. Anyways, this must be the exception because any SOAP implementation will work like a charm with dozens of transports. Last time I saw, integrating JMS (the second most used protocol) with Axis 2 was a real pain spiced with close to zero documentation (including, but not limited to, the Axis test suite that by the way do not include a JMS test case).
I barely can restrain myself of using WS-I18N, and hey, people, how can I work without the much-needed WS-Cache or WS-Clustering - that being kind of an oxymoron, but no more than a WS-Addressing spec.
I wonder when, if, why, where did I give rights to anyone to burden my existence with such overcomplicated specs. CORBA was abandoned for EJB because it was too complicated, and five years later we are looking at SOAP and its absurd ranking of 150+ specs. Do your math.

4 comments:
I always wondered why to use WS-shit when REST is so simple, but again, maybe my requirements were simple. Did you find something that is not possible to do with REST, and thereÅ› no other option than to use WS-*??
You can choose between EJB3 (a standard) or spring (a de facto standard) for your business layer, but REST is neither. Unarguably better than using WS, but it's just an acronym for "doing it my way".
Politically speaking, it's hard to convince the PHB that "roll my own solution" is the way to go, while there are no clear winners in the REST arena. On the other hand, REST do not have an equivalent of WSDL as an interface between teams; in order to call my REST interface you must first read my docs or use a library I provide for, say, Java.
When I am given the freedom to choose (and I am frequently not), I would still choose REST. But still waiting for The Next Big Thing, as it have not arrived yet.
He He, I couldn't help but chuckle when I read your post. Nice one.
Overcomplicated specifications are becoming way too rampant. Nobody seems to care for "keeping it simple" :-)
I am in the process of starting to work with JSF... and sometimes I think it has been made a little more complicated than warranted. But that's just my initial feeler. Maybe I will change my opinion once I get to know it better.
--
Regards
Parag
"Maybe I will change my opinion once I get to know it better."
You won't.
Post a Comment