Here are my thoughts on it.
Nice write up. I really actually miss the old interop problems pre WS-*. I used to curse DCOM/Java interop (it really was horrible), but it is no worse then what we have today with WS-* IMHO. I understand how we got here … I think it is understandable. It is just really unfortunate. Perhaps if the XML Schema writers had focused on the 80/20 rule, & the WSDL folks toned it down a bit (oh how I miss the simplicity of CORBA IDL), we wouldn’t be in the complexity hell that we are in today, but maybe interop is just this hard regardless. I for one have to say that I’m pretty disappointed where things are today, and don’t see a bright future for the course we are on. I just don’t buy the part you wrote about “…SOAP for building the backbone of it” in terms of interop. Yes in theory it should be, but I think the complexity of it all, the industry politics, and the endless specification churn point a pretty bleak future for SOAP and WS-*. I mean it is April 2006 – shouldn’t things be further along then they are now?
I think that sadly, WS-* is fatally flawed. Perhaps I am just jaded from trying to actually use it for interop or have a mental block when I stare at SOAP messages with oodles of headers. I know that HTTP Headers and SOAP Headers are at the end of the day essentially the same thing, but to me, it is just fundamentally wrong to have the headers in the XML document. To me, the XML document is the application developer’s domain – sticking that stuff there just invites panic.
Also, perhaps I am not informed, but are there any success stories out there on interop and WS-ReliableMessaging, AtomicTransactions, etc.? I’ve found it hard enough to make complex documents interoperate between .NET and Java using vanilla WSDL.
The stuff you guys are doing to make Indigo POX friendly is laudable. At least developers will have an eject button once they give up on building their “backbone”.
3 comments:
It should work like IP sockets: the application just sends the data. Whee! I don't have to pack connection information into every struct that I send; once the connection is established and configured, it just looks like another stream.
Headers residing within a SOAP message may seem weird at first to those not familiar with web services standards, but there is much value in allowing header information to be exposed in such a way.
SOAP over HTTP isn't really an ideal way to be performing large numbers of operations over a network; it's (ab)using HTTP in a manner that wasn't the intended purpose of the protocol. SOAP over HTTP (or REST over HTTP, for that matter) is not an efficient usage of the underlying TCP protocol for scenarios involving significant message volumes..
Allowing headers to reside within the SOAP Message XML pulls away from existing solutions' underlying focus on HTTP, allowing future integration solutions to run overtop more appropriate/varied transports. This has already been illustrated with SOAP-over-SMTP bindings, SOAP-over-XMPP, etc.
This is only one of the benefits of having headers within a SOAP message; there are many others (related to multiple parties in a "filter chain" each operating on a single SOAP message independently, intelligent message routing, security/policy/signing operations, etc.)
That said, the benefits of the SOAP specification don't really shine through unless you're performing relatively complex operations that involve multiple parties, cryptographic signing, routing, etc. Otherwise, SOAP may be seen as somewhat "heavy" for simple operations. SOAP/WS-* seems comparable to a swiss-army-knife; quite capable of almost anything you need, but carrying with it a certain amount of complexity and overhead.
Thanks for the comment Elliot!
I have worked with SOAP since it came out. I do all of the complex things you mentioned and still avoid it like the plague.
SOAP makes none of these things easier. On the contrary, it makes them more difficult in my experience.
Cheers.
Post a Comment