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] Proposal for PR001 - MakeConnection sent to AcksTo


+1


On 19 Oct 2006, at 18:46, Marc Goodner wrote:

All,

 

Microsoft was opposed to the MakeConnection functionality when it was added to the specification. We continue to be concerned about the impact of the current form of MakeConnection in terms of the problems it has composing with WS-Addressing and unspecified but allowed polling capabilities independent of WS-RM. We do now see that there are RM cases that MakeConnection addresses that are important.

 

We have been looking at how MakeConnection could be modified to compose properly with WS-Addressing, retain scope to RM, and still solve the RM scenarios it supports today. Retaining a generic polling model was not one of our goals.

 

We arrived at the attached proposal that supports the following scenarios. We do believe that this is the set of RM scenarios MakeConnection currently attempts to address. We are unaware of any others.

1.       Allow an unreachable RMD of an established sequence to use the back channel to receive Sequence Traffic and Lifecycle messages.

2.       Allow a RMS to establish a new sequence to an unreachable RMD.

3.       Composability with mechanisms that facilitate identifying an unreachable RMD.

 

Details on how this proposal can solve each of these scenarios are covered below.

 

What we are proposing is to remove both the RM anon URI and the identifier from MakeConnection.  Instead we propose targeting the MakeConnection message at the AcksTo EPR of the RMS. We think this satisfies all of the RM scenarios that the current form of MakeConnection satisfies as listed above.

 

The principal impact of this change is that the RMS needs to add some unique information, e.g. in the form of ref params to that EPR, to distinguish MakeConnection requests from otherwise anonymous clients. When it cannot identify the requestor of the MakeConnection message it sends a CreateSequence to start a  new sequence and establishes the unique AcksTo EPR. The recipient of a MakeConnection request is also permitted to refuse it if the recipient cannot satisfy the requirement to transmit messages on the underlying transport back channel.

 

Summary of changes:

·         MakeConnection is now a header, modeled similarly to AckRequested.

o   MakeConnection has been tightly scoped to RM uses, there is no generic polling capability.

o   MakeConnection messages are sent to the AcksTo EPR

§  RM anon URI and Identifier are both gone

§  AcksTo EPR should use unique info, e.g. ref params, to distinguish clients for MakeConnection requests.

§  If an RM service cannot distinguish the requestor it should send a CS (with a unique AcksTo EPR if needed) or fault.

·         Secure use of MakeConnection is defined

·         We have added flow diagrams illustrating the model and expanded on the description of the feature.

·         Added a new fault, MakeConnectionRefused.

·         The state table has been updated. Only new rows are needed for the existing RMS/RMD state tables. The separate state tables for MakeConnection are no longer needed.

 

Details on supported scenarios:

1.       Allow an unreachable RMD of an established sequence to use the back channel to receive Sequence Traffic and Lifecycle messages.

This is covered in the attached document in detail. The common scenario here will be an inbound sequence to an anonymous client that was established via Offer (there is no requirement that offer be used however). In this scenario at sequence creation time the server side RMS simply sets up its AcksTo with unique information it can use to identify MakeConnection requests from this client, e.g. by using ref params in the EPR.

 

2.       Allow a RMS to establish a new sequence to an unreachable RMD.

This is also described in the attached document. The primary scenario here is for reliable out only sequences. In this case as the AcksTo EPR has not been established the client sends the MakeConnection message to the RM endpoint. When an RM endpoint receives a MakeConenction message it cannot correlate to an existing sequence it should return either a CreateSequence to establish a new inbound sequence or raise a MakeConnectionRefused fault.

 

3.       Composability with mechanisms that facilitate identifying an unreachable RMD.

This is not explicitly described in the attached document but is enabled by what is present. Other mechanisms could be composed independently to enable or enhance a scenario where an unreachable RMD needs to be identified. This scenario would arise in cases where there is an unreachable client with an established outbound sequence that the server side RM service wishes to initiate an inbound sequence to. In this case it can place a MessagePending header in a response to the client to trigger it to send a MakeConnection request. This MessagePending header should include the optional AcksTo EPR so that the subsequent MakeConnection request to flow a CreateSequence can be correlated to the correct unreachable client. The server side RMS can then use the unique information in the AcksTo EPR it provided to relate the sequence to the Sequence Traffic and Lifecycle messages it needs to send to the specific unreachable RMD.

<PR001 - MC AcksTo.doc>
<PR001 - MC AcksTo.pdf>



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