ATTENTION: This blog has moved to a new location. Please update your bookmarks, browsing habits, and aggregators.

	Friday, July 25, 2003

Moving to Roller This post (and this weblog) has a new home. Sometime in the next few weeks, I'll be migrating my blog from Radio to Roller, the open-source Java blog server, and hosting it on one of our servers.  My motivations are two-fold.  First, Radio has been getting in inexplicable deadlocks with Microsoft Outlook 2003, a situation easily resolved by killing the local instance of Radio.  Second, Roller appears to be functionally equivalent but will give me the ability to control the server side.  Thankfully, Radio stores its data in XML, so it shouldn't be too difficult to map it into Roller's database and pick up where I left off. 5:01:45 PM

Web Services Reliable Messaging, Standards and the Community Melting Pot This post (and this weblog) has a new home. Web Services Reliable Messaging In the News Back in March, I blogged about the two versions of reliable messaging for web services, one from a group of vendors (submitted to OASIS) and the other from Microsoft/BEA/IBM/TIBCo.  (Does anyone know the dirt on why BEA and TIBCo people are listed among the authors but not in the acknowledgements?) Recently, CNet published an article that asked whether this schism was placing the collective web services initiative at risk.  I claim (and claimed) that competition in standards is a good thing, so long as it weeds out the weaker, less complete ideas and drives the community toward a consensus.  (For a similar perspective, check out ZapThink in a recent ZapFlash.)  In the worst case, having a couple of widely-used technologies (e.g., Unix and Windows) with different merits isn't all that bad. Similarities, Differences, and Stones Left Unturned: Why There's No Rush Constructive conflict and/or big vendor brinksmanship aside, there is little risk of anyone running off with the prize for web services reliable messaging just yet, and the reasons are instructive as to the state of web services in general.  In what follows, I'll refer to the OASIS version as WS-RM and the other as WS-ReliableMessaging and use different colors. First, both versions are defined largely in terms of SOAP 1.1 (both specs specify SOAP 1.1 as the dependency) header elements, and there are a number of basic differences between the functionality that the two specifications include or import: Configuration.  WS-RM does not provide or suggestion a way to configure the endpoints or for the endpoints to negotiate with each other to find acceptable settings, either through WSDL extensions or through inquiry.  WS-ReliableMessaging imports functionality from the WS-Policy for this purpose, but that's not much good, as, to quote the WS-Policy specification, "WS-Policy stops short of specifying how policies are discovered or attached to a Web service." Request/Acknowledgement/Response Pattern.  WS-RM specifies that each request corresponds to exactly one acknowledgement, while WS-ReliableMessaging allows a more flexible interaction where groups or ranges (in a sequence) of messages can be acknowledged at once.  WS-RM disclaims application-level acknowledgements (section 1.1.1), while WS-ReliableMessaging potentially mixes them up (section 3.2). Basic Reliability Considerations.  WS-RM considers (at a cursory level) the necessary persistence properties of endpoints to handle duplicate elimination, while WS-ReliableMessaging leaves it out.  WS-ReliableMessaging acknowledges security concerns without touching on some important business cases such as non-repudiation; WS-RM ignores security issues entirely.  Neither specification considers the necessary coupling of a reliable messaging protocol with a reliable transport.  Neither specification mentions a way to mark acknowledgements of duplicate messages as such, meaning that there is a possibility that a malicious sender could insert a message into a sequence. And this is just a start.  There are enough similarities, differences, and omissions to provoke an active dialog, but there are also major open items. For example, because WS-RM dictates both the request and response structure, it is incompatible with the basic SOAP 1.1/WSDL 1.1 infrastructure of transport and protocol bindings.  (On the WSDL issue, there has been some good discussion traffic [initial message | ensuing thread] about this on the OASIS WS-RM mailing list.)  WS-ReliableMessaging, with things like the ability for a sender to request acknowledgements from the receiver, is in the same boat.  This statement, that neither candidate "standard" is consistent with current, unextended, unmodified web services infrastructure, is a very strong statement.  Nonetheless, this is not an insurmountable obstacle: it is (merely) work that needs to be done. Both proposed specifications have to be carefully examined as use cases for the now-current generation (SOAP 1.2/WSDL 1.2) of web services infrastructure, but for the moment, the community has zero choices.  Both contenders, if they remain separate, will look substantially different after their next round of evolution. Side Node: Implementation and Experimentation With Tetsu Miyamoto, I recently worked on an article for JavaWorld (the one in Japan, not the one in the US).  Harmonization with SOAP/WSDL is convenient but not required for usability, and we outlined and completed a first pass on a basic implementation of OASIS WS-RM in Java.  It will get open-sourced once it gains a little more maturity, and anyone who is interested in experimenting or helping out should drop me a line. Addendum I ran across an article on IBM developerWorks that discusses some implementation details for WS-ReliableMessaging. 3:41:23 AM