Stu Charlton makes a strong case for why WS-SOAP will never get beyond its current level of development.
The entire fiasco should go down in computing lore as an epic tragedy.
But the most interesting statement from his post is this...
WS-Eventing isn't really implemented or ratified. So there's still a lot of room for MQ, JMS, TIBCO/RV, etc.Apparently some lessons are hard to learn.
We've now all learned no one in their right mind, vendor or customer, should be investing in WS-SOAP. Furthermore, we should all *immediately* begin extrapolating the lessons learned over the last few years.
Why would anyone, vendor or customer, invest in *any* of the above listed messaging technologies?
OK, if I ran a trading floor with a lot of value moving around constantly I would give RV a look. But under no other circumstances.
If I had any of these already in my data center I would already have a plan in place for isolating and ultimately obsoleting them. Any minor investments would fall under the category of "regret".
HTTP, XMPP, maybe AMQP, and very few others would be on the short list.
4 comments:
"Tragedy" was not the first word to describe that that came to mind. "Farce" was.
I guess that depends on one's perspective. The tragedy of it is that the farce of it had such significant consequences. And still does.
The whole thing put me in mind of the "OSI Wars". Same mindsets, same results...and nobody learned or willl learn their lessons.
Vendor relationships whither slowly. I can't complain, it pays my bills. Risk management is the name of the game, and change = risk.
Regarding AMQ, or any toolkit that handles re-ordering, retries & duplicate detection... Is this generally a good idea? I tend to say "probably not", but realize that this is a minority opinion. Reliability is an application-level consideration -- retries and duplicate detection typically have to be "redone" at the application level anyway. The fact that few seem to see this illustrates rampant ignorance of the "end to end" principle which has been so successful on the Internet.
There is clearly a market for signing a cheque to a vendor and "not thinking things through". It's why large enterprise vendors like SAP, IBM, and Oracle thrive. It means short-term productivity. And in many cases, at a certain scale & risk exposure, it's acceptable to delegate to an piece of proprietary infrastructure. Of course, it's up to the vendor to ensure this decision doesn't end up in "regret".
Developers can be lazy - note the number of HTTP sites that say "don't hit the submit twice!", when this has been a solved problem since, oh, 1996. Hence the desires for rich QoS in one's messaging technologies.
Post a Comment