WS-ReliableExchange Update

WS-ReliableExchange Update

In June I WS-ReliableExchange: The Beginning of the End!? about the then imminent battle   over the reliable messaging space in web services.  I received several positive comments from people interested in gaining   an ‘insider’s’ perspective on the specification’s development process.  Recently I’ve been asked by several of these   interested readers for an update on the situation, so, without further adieu…

What actually happened in Palo Alto?

The initial TC convening meeting that SAP hosted in Palo Alto in June came and went without   many problems.  In fact, one of the biggest problems at the meeting was the initial lack of internet connectivity for the   attendees (it seems that I am somewhat of a bad luck charm in this respect), but this was fixed relatively quickly by the   event staff.  The mood of the initial meeting was surprisingly amicable, especially given the history (details in my   previous WS-ReliableExchange: The Beginning of the End!?) between the two camps that   comprised the majority of the attendees.  There was some back and forth about how the TC should be conducted, the wording of   the charter, and initial issues were raised for the group to consider for discussion.  All in all, it seems that the   industry has agreed to align and the WS-ReliableMessaging specification that will be produced by the OASIS WS-ReliableExchange TC appears to be the   primed for widespread industry acceptance and adoption. 

The conduct of the TC

One of the biggest advantages (or disadvantage, depending on how you look at it) of the OASIS standardization process is   that each TC governs itself.  That is to say, unlike the other standardization bodies, the W3C for example, which lay out   the ground rules and tools for all the work that should be done in the various working groups under the auspices of that   organization, each TC in OASIS needs to define its own manner of working.  Quite a bit of time was spent working out when   meetings should occur, how long they should last, what the voting process for issues should be, etc..  Several issues that   really should be solved in a generic manner once and for all by the OASIS staff continue to be rehashed in each working   group.  For example, document version management could be handled by a simple CVS server for all TCs, and this was discussed   at great length and to no avail. 

The most important point of this phase of the meeting was that the proposed chairs, Sanjay Patil of SAP, and Paul Fremantle   formerly of IBM and now working for WSO2, were accepted as the chairs of the TC.  After this initial action and an   introduction to the IPR rules and general policies of the OASIS organization we moved on to the more substantive matters.

Charter discussion

The charter for a TC is a very important document.  It outlines the work that the TC intends to complete and also the work   that is explicitly out of scope.  When an issue is raised throughout the specification development process, it can only be   considered by the TC if it meets the criteria in the charter.  As per OASIS rules, changes to the charter require a special   majority vote to pass.  As defined in the OASIS TC process   document  a

‘”Special Majority Vote” is a TC vote in which at least 2/3 (two thirds) of the Voting Members vote “yes” and no more   than 1/4 (one fourth) of the Voting Members vote “no”. These numbers are based on the total number of Voting Members,   regardless of the number of Voting Members present in the meeting. Abstentions are not counted. For example, in a TC in   which there are 30 Voting Members, at least 20 Voting Members must vote “yes” for a motion to pass; but if 8 or more vote   “no” then the motion fails. All Special Majority Votes must be conducted by the OASIS TC Administrator.”‘

The most contentious charter discussion came around adding references to other documents, notably WS-Reliability, i.e. the   spec with which WS-ReliableMessaging would most likely compete for industry adoption.  It should be noted that this proposal   was made by Oracle, one of the original authors of WS-Reliability.  After some heated discussion, this was finally kicked to a web ballot (conducted by the OASIS TC Administrator, as per the   by laws), which subsequently failed and the references weren’t added. 

The second charter issue was around the normative reference to security, specifically WS-SecureConversation.  It was argued that   security and reliable messaging were two orthogonal topics and that this relationship should not be outlined in the charter.    It is important to note that while WS-Security was listed in the charter   as a possible solution for security concerns related to reliable messaging, it was part of a non-exhaustive non-normative   list.  This fact, and agreement by the majority of the TC, resulted in one of the more significant changes in the   specification (see below for details).

The submission document

After the charter issues were clarified, Chris Ferris presented the submission work to the TC.  The point of this was to   clarify any ambiguities or questions that members of the TC would have about the intent of the authors.  During this   presentation some questions were posed that were not easily answered and were recorded as potential issues.  None of these   issues were discussed in detail at the time, they were instead recorded as later discussion points for the TC. The meeting   was adjourned at 12:15pm on Friday and all participants retreated to their various camps to discuss what had just happened.

What’s happened since then?

After the initial structure of the WS-RX TC was agreed upon the TC could actually begin working on the spec.  For those of   you unfamiliar with the process, representatives from the various member companies will closely analyze the specification   and raise issues that they find with the specification to the group.  Generally this is accompanied by a proposal as to how   the issue raiser would like to see this issue resolved.  At that point, the TC begins discussion of the issue.  Robert’s Rules of Order is used as a guideline for discussion.  We have conducted   extensive conference calls and had a face to face meeting in Seattle.  The next scheduled meeting is set to occur in   Sunnyvale, California in mid December.

At the time of this writing, the TC has raised 74 issues, ranging from minor editorial nits to substantial architecture   changes.  Of those, 23 issues have been agreed upon, closed, and incorporated into the document.  Another 23 have been   agreed upon, but have not yet been incorporated in the document.  There are currently 17 active issues that are being   discussed by the TC.  Below I’ve given a list of the issues and their resolutions that I think readers will find the most   interesting.  The full issues list can be found here.

Important issues and their resolutions

Most of the issues the TC has made decisions about have resulted in making the specification tighter.  They aren’t   necessarily big changes, but they aren’t minor editorial nits either.  A good example would be the decision to specifically   disallow using a value for wsrm:acksTo that would effectively prohibit sending acks and therefore break the protocol (the   WS-Addressing ‘none’ IRI was specifically in mind).   What I would rather concentrate on here are what I find to be the 3   most significant changes to the specification.

• Remove dependency on WS-Security: This was alluded to above and is probably the most significant and charged   issue of all.  One side of the table maintained that there was a threat model that required WS-Security, and the other side   felt that security and reliable messaging are two orthogonal issues and that this dependency shouldn’t be baked directly   into the RM spec. The latter group won the vote by a narrow margin.
• CloseSequence: The CloseSequence change is significant because it was illustrated to the group that the protocol   allowed the sequence to be terminated in an inconsistent state.  New control messages were added to the protocol to   gracefully shutdown a sequence so that both the RMS and the RMD had an accurate accounting of the state of the other.
• Removal of retransmission parameters: This is the most recent significant change that removes the retransmission   parameters that were specified in the policy specification.  The thinking behind this is that these things should be handled   in an implementation specific manner and need not be specified.

What’s next?

That should pretty much bring us up to speed.  As you can see, lots of work has gone into this specification, and there is   still plenty to do (Notably the arguments over the inclusion of the DeliveryAssurances and the negotation of policy   parameters between the sender and receiver have yet to come to a conclusion).  Work will continue, more issues will be   raised, more issues will be resolved, new drafts will be published, and I’ll be here to keep a pulse on it for all you   readers.  Hopefully this kind of sneak preview will whet your appetite for the first public draft that will hopefully be   available in the near future.