i089 and polling

[Paul Fremantle <paul@wso2.com>]

I started a new note chain, because this isn't a reply to anyone's email 
in particular, but to the whole bunch of emails we've seen.

The charter is important to this discussion, but I would encourage us to 
look at specific use cases and technical details first, and use the 
charter as the consistency check as we move forward. I think the main 
question before us is which use cases do we wish to satisfy.

The use cases we have seen discussed so far are:

1) Reliable in-only or reliable request only - this is already satisfied 
by the spec
2) Reliable request-response
3) Unreliable request/reliable response
4) Reliable out-only
5) A sequence with an anonymous client RM Destination to be shared 
across multiple client endpoints
6) A server RMD to be able to initiate sequences with the client - e.g. 
to support more than one sequence in the case of SOAP1.1 and SOAP1.2 
messages.

Of course there may be others that I have missed, but I think that is a 
fairly comprehensive list.

I believe that Doug's proposal handles all of these scenarios.

My minimalist proposal aimed to support #2 as a primary use case. 
Section 4.2 (Offer on its own) was aimed at making it possible to 
support #3 and #4.

I still have a strong issue around #4 which is that there is currently 
no way of supporting unreliable out-only with an anon client using any 
of the specs or standards that WS-RM references, and so we cannot be 
said to be composing with an existing model to add reliability, which I 
see as the main aim of this TC. I believe strongly that scenario #2 is 
what we are aiming for as the primary objective.

The options for supporting scenarios 5 and 6 with my proposal are 
complicated. I have not been motivated by these scenarios as they seem 
to be corner-of-corner-cases, and not focused on the core problem of 
enabling simple RM interactions from SMBs (such as WSO2) who do not have 
publicly addressable URIs. However that is my opinion as a member of 
this TC on which use cases are important.

I propose that the TC decides which use cases are "must-have" and which 
are "nice-to-have". I propose that we take the simplest, clearest 
technical proposal that supports the must-haves, and treat any 
nice-to-haves that are enabled as a bonus. I agree that having positive 
side-effects can be a good thing, but time and again the XP principal of 
focussing on core requirements and not adding unnecessary functionality 
has been shown to lead to more stable simple and secure systems. I 
actually think that is what Doug and I have done - simply that we have 
started from different core requirements. Perhaps the most useful thing 
the TC could do to make progress is agree on the core requirements.

Finally, I would like to ask the TC to try and address this issue in as 
objective and peaceful manner as possible. I know I am as guilty as 
anyone of getting fired up over this, but I believe that the more we can 
address this in a calm and objective manner the smoother our progress to 
a standard will be.

Regards,

Paul

-- 

Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://feeds.feedburner.com/bloglines/pzf
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com