Richard Monson-Haefel continues to take the gloves off on J2EE and WS-* (at least the Java WS-* impls). I might not be reading closely enough, but I wish his firm, Burton Group would do the same on WS-* (I'm a customer). He and Burton Group have been consistent on J2EE, but Richard's boss Anne Thomas Manes continues to beat the WS-* drum. I read a couple of her pieces on a plane this week and she has totally drunk the WS-* Kool-Aid. She isn't a total zealot on it or anything, but she is astonishingly pro WS-* in the face of a lot of criticism and lack of success stories in the field. To be fair, it is possible that I just haven't found the right research. Richard - are you (or have you already and I missed it) going to take the gloves off on WS-* in your Burton Group writings? I love your blog, but it only makes a real difference if it is in the official Burton Group position papers.
Also, if J2EE is on the ropes today, who is to say that WS-* won't be in a couple of years? Given its trajectory compared to where J2EE was in the beginning, I think it is quite possible that WS-* will die a much quicker death then J2EE.
Update 08-May-06
To clarify, I thought that Anne's research was very thorough in terms of coverage - it was quite useful. I just was disturbed that given the history on things like J2EE she so easily assumed that WS-* will survive and thrive. Perhaps its her job to be hopeful like that and to try to get momentum going in one direction. My focus is solving integration problems today and in the not so distant future. Perhaps our requirements are different.
Update 13-May-06
I found some interesting links to Anne's response:
James Governor
Mark Nottingham - (he used to chair the WS-Addressing WG at W3C)
Dave Johnson
6 comments:
Perhaps I'm totally wrong, but I still see WS-* as a very suitable application-level API to an open messaging infrastructure. It's development is only in it's childhood, but I keep believing in WS-* just because I don't see any emerging XML-based alternative.
Hi Mike,
Thanks for reference to my blog entry. I've posted this response on my own site, but decided it might be helpful to post it here as well.
One of the reasons you have not seen me comment on WS* (all those web service standards) is that its not my area of coverage. In other words, I have not been keeping up with all the specifications and therefore don’t have enough information to formulate an opinion on the subject.
That said, I will tell you that my gut reaction is that WS* is far too complex. There seems to be no end to these specifications; they are extremely complexity is scary. But that is just a gut reaction, not a studied opinion.
The value of WS* and SOA as an architecture has been a subject of debate on our research team for a while. I can tell you that Anne Thomas Manes believes they are important but not a panacea. I personally have trouble seeing the value in them. I’ll leave the opinion of other analysts out of it … if they want to comment they can. We debate this WS* and SOA a lot, as well as other topics like the value of dynamic programming languages, the new Microsoft technologies and so on. These debates are never resolved to 100% satisfaction of all analysts, but we try to ensure that all reports are as unbiased as possible and present at different perspectives.
Burton Group has put out a number of reports on the WS* initiatives and standards as well as SOA. This is absolutely necessary because our clients, like myself, are simply overwhelmed with information and desire a clear understanding of what these specifications do and what value they provide. If you examine our reports closely, however, you’ll find plenty of evidence of dissenting opinions. Here are a couple of examples from reports we published on SOA and WS*
“Initially, when IBM and Microsoft first introduced the [web services] framework in 2000, WS-* comprised a reasonably small set of specifications, including Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and Universal Description, Discovery and Integration (UDDI), and proponents extolled the framework’s simplicity. But over the last six years, WS-* has grown to more than 50 specifications in various stages of completion and ratification. The characteristic of simplicity no longer applies.
In response to the growing complexity of WS-*, an expanding faction of technical experts recommends reverting to a simpler approach essentially using Plain old XML (POX) over HTTP and conforming to Representational State Transfer (REST), the architecture of the World Wide Web [1]. “
There is a lot more of this throughout the reports, but the point is we work hard to deliver balanced opinions. I’m not a supporter of WS* or SOA, to be perfectly honest, but then again I’m just one opinion in a team of many. Think of my perspective as a dissenting opinion based on less than inadequate research. I know SOAP, WSDL, XML, HTTP, and XML Schema better than most people and I understand the JAX-WS programming model extremely well, so I feel qualified to offer public opinions on those subjects. I have not, however, kept up on things like WS-Security, WS-Transactions, WS-Addressing, WS-ReliableMessaging, ad noisome.
When our customer ask for advice on SOA or WS*, I refer them to Anne Thomas Manes because she is the one who has done all the research in this area, not me. Like it or not; No analyst can know everything and those that offer opinions on all subjects are more of a liability than an asset.
Richard Monson-Haefel
Hey Thanks a lot for the great response Richard. That makes sense. With your permission, I am selectively quoting a document named, "Enterprise Service bus: EAI in Transition". It isn't 100% pro WS-*, but it seems to assume that "proprietary" MOM will be replaced by WS-RM. I don't like using proprietary APIs for MOM either so I try to stick to JMS. I have also learned that proprietary is indeed worth avoiding, but you often have to choose your poison. "Proprietary & works like a champ" is far better then "Standard & makes you want to gauge your eyes out"
My point is analysts were saying similar things about proprietary CORBA frameworks when J2EE came out. Look what some (very wise) analysts are saying today about J2EE ;)
Like I said, I still find the research helpful. I just think that it should be a little bit more skeptical given the state of things and the history of past standardization efforts (that in hindsight were far less ambitious). What I specifically don’t like is the conclusion -- it does point out some risks, but then goes onto conclude that WS-* will prevail. From where I sit I don't see any evidence of that.
Now the excerpts:
Burton Group recommends that enterprises upgrade their current EAI products from traditional MOM to the ESB WSF/MOM hybrids and avoid deploying any additional proprietary protocols in their environments.
The WSF offers a standard, pervasive, simple, low-cost alternative to traditional MOM-based EAI products. The WSF enables easy interoperability among Windows, Linux, UNIX, and mainframe, and among .NET, Java, C++, and other languages without the use of proprietary APIs or protocols. Instead, the WSF relies on two core specifications—Web Services Description Language (WSDL) and Simple Object Access Protocol (SOAP), which enable cross-vendor interoperability. WSDL provides a standard language for describing a service interface, and SOAP provides a standard messaging protocol for communication.
Although the WSF is pervasive, it isn't quite ready to completely replace MOM-based solutions. The WSF doesn't currently support the same level of robustness as traditional MOM protocols, which support reliable messaging, publish-and-subscribe (pub/sub), and two-phase commit (2PC) transaction integrity. But the WSF is maturing rapidly, and it won't be long before it supplants the need for proprietary MOM.
None of these specifications have been finalized, much less ratified as standards, so developers should use them with caution. There's no guarantee that multivendor products can interoperate, and the specifications will certainly change before they are finalized. Even so, the vendors are busy building implementations, and with careful administration, developers can use them to build robust applications.
Conclusion:
Enterprise service bus (ESB) refers to a segment of the enterprise application integration (EAI) software market that addresses the intersection of message-oriented middleware (MOM) and web services. ESB products provide seamless interoperability with established reliable-messaging MOM protocols such as IBM WebSphere MQ, TIBCO Rendezvous, and Sonic Software SonicMQ. Meanwhile, the superplatform vendors and other web services platform (WSP) vendors are adding ESB functionality to their systems based on the interoperable WSReliableMessaging (WSRM) specification. Once WSRM and other key web services framework (WSF) standards are universally implemented, the need for vendor-proprietary ESB protocol stacks will wither away.
Hi Mike,
Thanks for posting and referencing some of my work. I've posted a response to your original message here.
One additional note about the difference between standard/proprietary APIs and standard/proprietary protocols: JMS is a standard API, but not a standard protocol. Like most Java APIs, it's goal is to enable portability of code, not interoperability of middleware. Each JMS implementation uses a proprietary protocol, which means that JMS implementations can't interoperate without using some type of protocol adapter.
WS-RM and the soon to be standardized WS-RX don't define a standard API, but they do define a standard protocol, meaning that any WS-RX-compliant product will be able to interoperate with any other WS-RX-compliant product without requiring a protocol adapter. From my perspective, that's a big win. But I also understand your perspective that it's better to go with something proprietary that works than to struggle with something standard that doesn't. Nonetheless, I'm pretty confident that WS-RX will eventually replace the need for proprietary MOM protocols. Once the need is gone, the products will soon follow.
See this post by Andrew Townley for a comprehensive analysis of standard APIs vs protocols.
Thanks Anne.
Yep, I know what you are talking about on JMS. We discussed that a bit on the SOA Yahoo list:
http://groups.yahoo.com/group/service-orientated-architecture/message/4085
If anything, Andrew's post scared me off even more from WS-*.
I guess time will tell on WS-RM et. al.
I assume, I am missing something, but can this be true on WS-RM?
From Stfan Tilkov
http://innoq.com/blog/st/2006/02/08/wsrm_and_wcf.html
quoting Christian Weyer:
"The only real problem I currently have with the WS-RM implementation in WCF is that they do not have a durable store for the WS-RM messages. It is all in-memory and AppDomain-based."
Doesn't sound very reliable ...
Can it be that the spec doesn't mandate this?
Doesn't sound like it:
http://blogs.msdn.com/shycohen/archive/2006/02/20/535717.aspx
"Reliable sessions are implemented using the WS-ReliableMessaging protocol. This protocol is yet another misnamed WS-* protocol, as it actually only deals with the reliability of the transfer and says nothing about durability, delivery acknowledgments, TTL for a message, long running sessions where a particular message is lost forever, etc. Currently, there is no active work going on to develop an interoperable Queued Messaging specification, but I expect that we will get to it in the near future."
My $$ remains on proprietary messaging for at least 3-5 years while the madness of this gets worked out ;)
---
BTW, I was on another plane today and read some more of your stuff. This time you were talking about WS-Security. Good stuff. You do great work - I think you know that I am just arguing with you on the technical merits of WS-* technology - I really do value your efforts.
You're correct that WS-RX doesn't mandate the use of durable queues. WCF does support durable queues, but only when using MSMQ as the transport (defeating the purpose of using WS-RX in the first place.)
I don't think I've ever said that WS-RX is ready for prime-time. It still has a lot of bugs to work out, and until then, MOM is still the right solution (albeit proprietary) when durable, reliable messaging is required.
Post a Comment