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] i010 - a proposal



I believe there is a way to achieve what you are trying to do without resorting to extending the spec to handle multiple RMS or RMD, which I strongly advise against (so many statements in WS-RM assume that sequences happen over a single RMD and a single  RMS - departing from this would mean a tedious "model" upgrade I believe.)


I know it may look like just a modeling game, but I'd rather :

- make the definitions of RMS and RMD abstract enough so that they tolerate distributed implementations,

Rather than:

- introduce the concept of  a sequence spanning "multiple RMSs / RMDs".

After all, if I understand your point at the f2f, you still expect these distributed RMDs to behave virtually like a single one.


In order to do this - and also to allow for spanning several endpoints, in the sense of Service endpoints - we could relax the association RMD / endpoint. For example, the core definitions could be:


Line 182: - RMS: An addressable SOAP processing entity able to execute all functions associated with sending

reliable messages, as specified in this document (as well as in WS-RM Policy).


Line 183: - RMD: An addressable SOAP processing entity able to execute all functions associated with receiving

reliable messages, as specified in this document (as well as in WS-RM Policy)..


Line 80:  I would suggest simply: "It defines a messaging protocol to identify, track, and manage the

reliable delivery of messages transmitted between a source party and a

destination party." (avoiding to mention any number of parties)


There also several places where "endpoint" is used abusively instead of RMD or RMS.

In Section 2: (L-147, L-150...) use the term "RMD" instead of just "endpoint".

More generally, endpoint should mean either service endpoint or client endpoint (e.g. rename " AD endpoint",  "AS endpoint"), which may have a different address than the RMD or RMS.


In Section 3.2 and elsewhere, expressions like "RM Source endpoint." should be reduced to just "RM Source", given that an RMS or RMD might not be addressable as the same endpoint as the Source or Destination.





From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Thursday, September 22, 2005 6:46 AM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] i010 - a proposal


(oops - I meant to hit send a couple of days ago)

I took an AI to write up a formal proposal for issue 10:

Issue 10, as stated, deals with whether or not a single RM sequence can span multiple ports.  Looking at this issue some more though I believe the broader issue is really whether a single RM sequence can span multiple endpoints as well.  Should the RM spec limit a single RM sequence to just a single RM Source and RM Destination or should it leave it up to the implementation to decide?  I believe it should leave it up to the various implementations.  If an implmentation is smart enough to share RM state across multiple endpoints then there is no reason why a single sequence could not be used to deliver messages to all of them (and to be clear I do see multiple RMSs and RMDs being an option).  So, with that mind I'd like to propose the following changes to the specs:

Using this version of the RM spec: http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14548/wsrm-1.1-spec-wd-03.pdf
Line 80:
        remove the word "exactly" in the
      sentence "...delivery of messages between exactly two parties,..."

To the end of line 439 add:
        This specification makes no restriction of the plurality of the
      RM Source or RM Destination.  If implementations can support
      a single RM Sequence spanning multiple WSDL ports or even
      multiple service endpoints then they are free to do so.  However,
      it is out of scope for this specification to define how this
      ability is communicated or achieved.

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