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

Description/justification:
When an AS uses an RMS to reliably send messages to an RMD, the RMS will need to be able to resend the un-acked messages at will.  If the AS uses a target URL or wsa:To value such that the RMS can not, at its own discretion, initiate the (re)sending of messages then the RMS would be severely limited in its ability to complete its job.  To this end the RM spec should discourage the use of wsa:To values that would put the RMS in this situation, like the anonymous URI.  Of course, there may be times that using the anonymous URI _and_ RM can work and so we shouldn't totally ban the use of anonymous URI but we should make people aware that w/o some other mechanism, a generic WSA+RM soap stack would not be able to support this.  Note, that while this is phrased in the context of wsa:To, for replies the RMD becomes the RMS and the wsa:ReplyTo becomes the wsa:To - so it would mean that we'd, implicitly, be discouraging the use of the anonymous URI in wsa:ReplyTo when people would want responses sent reliably.

Target: core

Type: design

Origin: Doug Davis dug@us.ibm.com

http://lists.oasis-open.org/archives/ws-rx/200601/msg00080.html

 

Proposal:

After line 441 of [1] add:

Messages sent using this protocol MUST NOT use a wsa:To value that would prohibit the RM Source from retransmitting unacknowledged messages.  For example, using the anonymous URI, without any additional transmission mechanism, would restrict an RM Source's ability to re-establishing a new connection to the RM Destination when a re-transmission of a message is needed.

 

 

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]