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: RE: [ws-rx] New Issue: Need to clarify relationship between theWS-RM specification and MakeConnection specification


But why does the issue have to be around MC? From RM’s point of view, MC can be viewed as just another transport – one that supports reachable clients. The pivot is reachable vs non-reachable clients, not MC per-se.

 

--Stefan

 

From: Gilbert Pilz [mailto:gpilz@bea.com]
Sent: Thursday, January 18, 2007 10:53 AM
To: Doug Davis
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] New Issue: Need to clarify relationship between the WS-RM specification and MakeConnection specification

 

Whether or not the problem of re-sending responses to non-addressable clients is solved by other specs is not really the issue here. The issue is "how should a WS-RM implementation behave if an MC implementation isn't available?"

 

- gp

 


From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Thursday, January 18, 2007 8:26 AM
To: Gilbert Pilz
Cc: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] New Issue: Need to clarify relationship between the WS-RM specification and MakeConnection specification


Option #3: Say nothing about transport-level issues and assume it will be solved thru composing with other specs (like MC).

thanks
-Doug

__________________________________________________
STSM | Web Services Architect | IBM Software Group
(919) 254-6905 | IBM T/L 444-6905 | dug@us.ibm.com


"Gilbert Pilz" <gpilz@bea.com>

01/18/2007 03:25 AM

To

<ws-rx@lists.oasis-open.org>

cc

Subject

[ws-rx] New Issue: Need to clarify relationship between the WS-RM specification and MakeConnection specification

 




We need to clarify the relationship between the base WS-RM specification and the MakeConnection specification. It seems that there are two options:

Option #1: The base specification could explicitly depend upon the MakeConnection specification. For example, by using phrases such as the current (line 238) "Implementations MAY use the WS-MakeConnection anonymous URI template . . .". The problem with this is that it requires the base specification to normatively reference the MC specification. This causes the schedules of WS-RM and WS-MC to be tied together, which runs counter to one of the reasons for splitting them in the first place.

Option #2: The base specification could refer to optional polling mechanisms "such as" WS-MC. A logical consequence of this is that the base spec needs to clearly spell out how the RMS and RMD should behave in the *absence* of any such polling mechanisms (otherwise they are not really optional). Foremost is the expected behavior of the RMD when the RMS sends a CreateSequence message that contains an Offer in which the Endpoint value is wsa:anonymous. It seems that, absent any polling mechanism, there is no way for a server-side RMS to resend unacknowledged response messages* and therefore the RMD SHOULD NOT respond with a CreateSequenceResponse that contains an Accept element (i.e. the RMD SHOULD NOT accept the offer).

- gp

* You could argue that the client can prompt the server to re-send the response by re-sending the request. Without getting into the specifics of this idea, it would still need to be clearly defined in the specification if we expect people to produce solutions that can interoperate around this feature.



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