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] Proposed updates to Doug's text


Hmm. The novelty is questionable.

The ebXML MS 3.0 spec contains a very similar facility (which they call One-Way Pull MEP), which also includes identification via a conversation segmentation technique they call Message Partitioning.

If I'm not mistaken, this facility was introduced into ebMS 3.0 in November 2005, as a result of a proposal from Fujitsu. There are perhaps roots in the more specialized use of the back-channel for acks in WS-Reliability.

I've seen this technique used in ad-hoc frameworks going back to at least 1990. Digital had a TP product that incorporated a very early RPC. The client could initiate a task on the server, but the message flow thereafter was always modelled as server-sends-RPC-to-client (the client implemented upcalls). Turning it around to get client-driven invocations on the server required this kind of pull behaviour. I've seen variants in other situations.

The ebMS spec is worth a look, incidentally, just to see how they handled this capability, without use of WS-Addressing. An interesting point of comparison.

Perhaps "somewhat unorthodox" would be a good description.

Alastair


Anish Karmarkar wrote:
I like the next text as well.
I suggest: s/unusual/new/

-Anish
--

Doug Davis wrote:
  
I like the new text.  Just wondering if there's a better word than 
"unusual"?

LOL, looking at:  http://thesaurus.reference.com/browse/unusual
The first two synonyms sum it up nicely but from totally different 
perspectives.
"noteworthy" perhaps?  I'm partial to "awe-inspiring"  :-)

thanks,
-Doug



*Paul Fremantle <paul@wso2.com>*

10/05/2006 06:15 PM

	
To
	"ws-rx@lists.oasis-open.org" <ws-rx@lists.oasis-open.org>
cc
	
Subject
	[ws-rx] Proposed updates to Doug's text


	






Here are my suggested edits, incorporating Paul Cotton's second point.

Since the message exchange pattern use by MakeConnection is an unusual
pattern, the following points
need to be reiterated for clarification:
● The MakeConnection message is logically part of a one-way operation;
there is no reply message to the MakeConnection itself, and any response
flowing on the HTTP backchannel is a pending message.
●Since there is no reply message to MakeConnection, the WS-Addressing
specific rules in Section 3.4 “Formulating a Reply Message” are not
used. Therefore the value of any wsa:ReplyTo element in the
MakeConnection message has no effective impact since the WS-Addressing
[reply endpoint] property that is set by the presence of wsa:RepyTo is
not used.
● In the absence of any pending message, there will be no message
transmitted on the transport
back-channel. E.g. In the HTTP case, just an HTTP 202 Accepted will be
returned without any SOAP envelope in the HTTP response message.
● When there is a message pending, it is sent on the transport
back-channel, using the connection that has been initiated by the
MakeConnection request.
* The MakeConnection message and operation is deliberately excluded from
the WSDL in Appendix B, as this behaviour can only be partially captured
using WSDL.



Paul

    

  


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