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.
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.
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.