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


OK.... let's try a PDF.

-----Original Message-----
From: Marc Goodner
Sent: Thursday, November 02, 2006 12:46 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Proposal for PR001 - MakeConnection sent to AcksTo

This doesn't seem to be getting through the list server so I'm resending. Apologies if it is a repeat.

-----Original Message-----
From: Marc Goodner
Sent: Thursday, November 02, 2006 12:01 PM
To: 'Anish Karmarkar'
Cc: 'wsrx'
Subject: RE: [ws-rx] Proposal for PR001 - MakeConnection sent to AcksTo

Here is a revised version with using a MakeConnectionTo EPR. Most of the updated text is on the first page describing that EPR rather than the previous proposed changes to the AcksTo EPR. The bulk of the details are the same.

I did correct one other thing Doug noticed. The text was inconsistent on the proper response to a MakeConnection that could not be correlated to a sequence. In one place it clearly stated that the receiver could send a CS or a MCRefused fault. In the exemplar it said the CS had to be returned. I've corrected the inconsistency so that CS or MCRefused is allowed in either place.

Regards,
Marc g

-----Original Message-----
From: Marc Goodner
Sent: Wednesday, November 01, 2006 10:00 AM
To: 'Anish Karmarkar'
Cc: wsrx
Subject: RE: [ws-rx] Proposal for PR001 - MakeConnection sent to AcksTo

Sorry for the slow reply, responses inline.

-----Original Message-----
From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
Sent: Thursday, October 19, 2006 12:29 PM
To: Marc Goodner
Cc: wsrx
Subject: Re: [ws-rx] Proposal for PR001 - MakeConnection sent to AcksTo

Marc,

I'll have to look at this proposal carefully, but looking at it cursorily I have one comment/question:

I'm not comfortable on overloaded AcksTo. AcksTo is the place where acks go and it may not have a capability to send messages back.

MG: Well, since protocol faults already go to the AcksTo EPR I think it is already overloaded as the destination for protocol control messages. I certainly think of the MC in those terms. I do take your point though that this does at the very least overload the current name.

Especially in
the unreachable RMD case, if the RMD knows how to talk to the RMS (which it has to, to send the 1st MakeConnection message), why not let the 1st MakeConnection contain the RMD's EPR (with refps)? This would allow the RMD to continue talking to the same service and poll for message.

MG: That's a good suggestion. Another alternative would be to add a new EPR specific to MC.

I understand that you are trying to create a solution that can never be used outside the context of WSRM, but in doing so you are making the solution convoluted and taking away some of RM's features (like having a central AcksTo service that only services Acks).

MG: If we pursue the idea of having a EPR specific to the MC that problem will go away.

-Anish
--

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

MakeConTo MC.pdf



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