[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New proposed issues 1/12 - 1/18
Below is the list of new proposed
issues I have since the last call. Please let me know if any were missed. –
Marc g Proposed-01 Title: suggest the restricted use of anonymous URI Proposed-02 Title: Use of offered sequences
unclear in current spec Proposed-01 Title: suggest the restricted use of anonymous URI Origin: Doug Davis dug@us.ibm.com http://lists.oasis-open.org/archives/ws-rx/200601/msg00080.html Proposal: Proposed-02 Title: Use of offered sequences
unclear in current spec Description/Justification: When an RMS sends a CreateSequence
that includes an offer, the offer is meant to be an optimisation for creating a
sequence back from the RMD to the RMS. Closer inspection highlights issues
with this approach. The RMS knows the endpoint of the
RMD and sends it the CreateSequence message with the Offer, but the RMD is not
informed of the endpoint it should use to send protocol messages back to the
RMS for the offered sequence, or which AD endpoints the sequence can be used
for. Now, the RMD could assume that a) It should send protocol
messages to the same endpoint that it sends the CreateSequenceResponse message
to for the inbound sequence. b) It should send protocol
messages to the same endpoint that it sends Acks to for the inbound sequence c) It should send protocol
messages to the same endpoint that it would have done if it had created the
outbound sequence itself, which could be a, or b, or another endpoint as yet
unknown to it. but assumptions break
interoperability and the RMD still doesnt know which application messages can
use the sequence. As an optimisation, the offer
should not change the behaviour that would be observed without the
optimisation. Lets take an example. Two applications
A and B use reliable messaging to query addresses from an address book
application at endpoint X. They both use the same RMS and share the same
sequence, and the RMD at endpoint X passes the messages onto the address book
app where addresses are queried and need to be sent back. Application A sets a
wsa:ReplyTo of Endpoint A for its replies. Application B
sets a wsa:ReplyTo of Endpoint B for its replies. Both these endpoints
support WSRM. When the replies are sent back, two sequences are established.
One to endpoint A and one to endpoint B. Now try and do the same with
offer. The RMS creates the outbound sequence and offers a sequence the other
way. Its accepted by the RMD. Now the application messages arrive at the RMD,
are processed by the address book app and the replies need to be sent back to
Endpoint A and Endpoint B. Which endpoint does the offered
sequence service? None, A, B, or both? Further more, since the spec
doesn't limit the offered sequence to just replies (it can be used for any msg
going from the RMD to the RMS) this problem is made even worse. Even before
the first application message from the RMS to the RMD is sent, the RMD could
have a message for the RMS. How does the RMD know whether or not the wsa:To EPR
in this message matches one of the possibly many RMS EPRs that the offered
sequence is for? The result is the creation of an
offered sequence where its not clear which application messages can use it, or
where to send the protocol messages. Target: core Type: design Origin: Daniel Millwood MILLWOOD@uk.ibm.com http://lists.oasis-open.org/archives/ws-rx/200601/msg00086.html Proposal: Whilst there may be a subset of
WSRM usecases where offer could make sense, I believe it is too open to
interpretation to be interoperable. For the benefit of interoperability, it
should be removed from the spec. Delete from
<wsrm:CreateSequence> in line 274, through to 277 Delete lines 309
through to 330 Delete lines 369 through to 384 Delete line 1043 Delete line
1060 Delete lines 1090 through to 1106 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]