[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposal for PR001 - MakeConnection sent to AcksTo
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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]