RE: Issue LC50 - MEPs

>-----Original Message-----
>From: www-ws-desc-request@w3.org 
>[mailto:www-ws-desc-request@w3.org] On Behalf Of Amelia A Lewis
>Sent: Thursday, Nov 18, 2004 14:38 PM
>To: David Booth
>Cc: www-ws-desc@w3.org
>Subject: Re: Issue LC50 - MEPs
>
>
>
>(fixed bouncy-bouncy address list)
>
>On Thu, 18 Nov 2004 16:27:48 -0500
>David Booth <dbooth@w3.org> wrote:
>> The assertion isn't that the client doesn't care.  The 
>client may care
>> about many things that are outside the scope of WSDL.  The point is
>
>This one isn't outside the scope of WSDL.  It's a service description
>language, not a code generation language.
>
>> merely that client1 doesn't receive the reply when the reply is sent
>> instead to client2.  
>
>client1 may be required to supply the address to which the reply is
>sent.  *Surely* this is unambiguously within the scope of things that
>are described by WSDL?  I'm seriously boggled that anyone could suggest
>otherwise.
>
>> Therefore, from the point of view of modeling the
>> interaction in WSDL, there is only a single one-way message from the
>> client1 to the service, or a single message from the service to
>> client2. 
>
>I completely reject the idea that if you don't have an open socket, it
>isn't request/response.  It is perfectly feasible to have
>request/response without it, by supplying the replyto address and a
>correlation identifier.  This is how it works in the world outside HTTP
>for the standard in-out MEP!
>
>Either asynchronous communications can *never* bind the in-out MEP, or
>they can bind both the existing in-out MEP and another MEP (p2c?).  It
>is *not* required that they discard the request/response semantic just
>because the message is redirected, and the fact that the messages are
>correlated *is* important to both sides in the exchange!
>

I agree. See below. 

>> More concretely, client1 doesn't generate stubs and skeletons
>> for client2. 
>
>None of my clients generate stubs or skeletons anyway.  Please do not
>use this argument; we're not recreating COM.  At least, we're 
>not solely
>doing so.  My clients need the information about message 
>correlation and
>addressing in these MEPs.  It is *not* adequate to pretend that they're
>independent operations with no relationship.
>

>From my perspective, we used the concept of a node to refer to a nebulous entity which has the  awareness of the "full" MEP pattern, that is the act of sending the message and receiving the response. Hence the relationship between the request and response can not be realized semantically if we think of two unrelated entities which are completely unaware of each other. 

In order to redirect the reply message to another address, the sender (client) is well aware of the redirection as it IS the client that redirects the message at will via addressing mechanisms. Hence, client that is initiating the redirect of the response is well aware of its relationship with the second physical address. Without this awareness, i.e. the relationship, pattern will not work anyway. I can not arbitrarily ask Jonathan to redirect my action items to you without first arranging with you that you will receive and process them on my behalf. ;-). 

If we think along the same lines, the issue that whether there are two separate addresses becomes not important, because two parties with separate physical addresses are acting together as a single logical entity, which is considered as, "one node". 

IMO, I think we introduced a confusion because of the implication to SOAP, as the definition of Node may suggest a SOAP Node and how its identity (URI) may play a role wrt addressing is not clear when reply is redirected to a different address. 

Therefore, I propose that we clarify the reference we call "node" and replace it with a definition of "entity" along the lines of: 

"An entity is a point of contact that can send and receive messages. It may have multiple physical addresses that may also be enabled by separate bindings. However, they are correlated via a single identity that is typically defined by an application."

Ok, send in the bombs now ;-)

--umit

Received on Friday, 19 November 2004 00:47:24 UTC