OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] i089 and polling


Paul,
Thank you for proposing a scheme with which I hope we can constructively
frame this debate.  I have been puzzled a bit, probably due to my
feeblemindedness, about what this debate is about and exactly which
problems beg solution and how.

I strongly urge that the working group carefully define, prioritize and
vote on those use cases it is to cover.  Because it MAY make a
difference, we ought to specify either that HTTP is the only underlying
protocol, or it is only one of the underlying protocols.  Some of the
problems are amplified only on certain such protocol bindings.

I have also heard claims and counter claims of complexity and so forth.
I propose that a reasonable metric that may be used for comparison is
how each proposal might impact the state table.  

Thanks
-bob

-----Original Message-----
From: Paul Fremantle [mailto:paul@wso2.com] 
Sent: Thursday, May 11, 2006 7:47 AM
To: wsrx
Subject: [ws-rx] i089 and polling

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]