Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference used for?)

[Raymond Feng]

Hi,

I'm making changes in the code as the discussion goes on. What's the final 
agreement here? It starts to become difficult to update my local changes by 
merging all the other check-ins and I would like to push in the code as soon 
as we have a consensus.

Thanks,
Raymond

----- Original Message ----- 
From: "Simon Nash" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Sunday, September 09, 2007 1:44 PM
Subject: Re: WS-Addressing mapping (was Re: What is 
Message.set/getCallableReference used for?)


Yes, I'm proposing what I said in [1] with a <tuscany:CallbackReference>
reference parameter under the wsa:To stateful EPR.  Looking at this again,
it could be slightly improved to eliminate the <wsa:EndpointReference>
and <wsa:Address> within <tuscany:CallbackReference>, giving:

<wsa:To>
   <wsa:EndpointReference xmlns:wsa="..." xmlns:tuscany="...">
      <wsa:Address>...URI of the service being invoked...</wsa:Address>
      <wsa:ReferenceParameters>
          <tuscany:CallbackID>callback-A01</tuscany:CallbackID>

<tuscany:ConversationID>conversation-006</tuscany:ConversationID>
          <tuscany:CallbackReference>
             ...URI of the service for the callback...
          </tuscany:CallbackReference>
      </wsa:ReferenceParameters>
   </wsa:EndpointReference>
</wsa:To>

This requires the <tuscany:CallbackReference> to be "fluffed up" into
a <wsa:To><wsa:EndpointReference> when the callback is sent, with the
<tuscany:CallbackID> and <tuscany:ConversationID> as its reference
parameters:

<wsa:To>
   <wsa:EndpointReference xmlns:wsa="..." xmlns:tuscany="...">
      <wsa:Address>...URI of the service for the callback...</wsa:Address>
      <wsa:ReferenceParameters>
          <tuscany:CallbackID>callback-A01</tuscany:CallbackID>

<tuscany:ConversationID>conversation-006</tuscany:ConversationID>
      </wsa:ReferenceParameters>
   </wsa:EndpointReference>
</wsa:To>

  Simon

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg22923.html

Raymond Feng wrote:

Hi, Simon.

To be sure, are you proposing to send the callalbe reference as a 
reference parameter under the wsa:To EPR?

Thanks,
Raymond

----- Original Message ----- From: "Simon Nash" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Sunday, September 09, 2007 12:35 PM
Subject: Re: WS-Addressing mapping (was Re: What is 
Message.set/getCallableReference used for?)


Comments at the end.

  Simon

Jean-Sebastien Delfino wrote:

More thoughts at the bottom.

Simon Nash wrote:


Raymond Feng wrote:

At this moment, the "From" of the Message is used for the reference 
of the source component. And if the interface is bidirectional, the 
"From" EPR will contain a callback EPR.

The current code only sets "From" in the Message for a bidirectional
interface.  This means that outbound interceptors don't currently get 
any
"From" endpoint information for calls across a unidirectional 
interface.

What's going to happen if the user customize the callback object by 
calling ServiceReference.setCallback() with a ServiceReference? 
Should we replace the callback EPR under the From or carry it as part 
of the reference parameters of the To?

In this case, the current code in JDKInvocationHandler replaces the 
"From"
EPR with the custom ServiceReference.  Again, this means that outbound
interceptors don't have access to the "From" reference endpoint.

So the value of holding the callback endpoint information somewhere 
other
than the Message's "From" endpoint is that outbound interceptors can 
have
access to the actual calling reference endpoint if they need it.

  Simon

Thanks,
Raymond

----- Original Message ----- From: "Jean-Sebastien Delfino" 
<[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Friday, September 07, 2007 4:09 PM
Subject: Re: WS-Addressing mapping (was Re: What is 
Message.set/getCallableReference used for?)


Simon Nash wrote:

Until now we have always held this information in the wsa:From 
element.
However, in thinking about what is really going on here in 
WS-Addressing
terms, I believe we should be putting it in the wsa:To element 
instead.
The wsa:To element is mandatory for WS-Addressing, but we are not
sending it currently.  Here's how this would look:

 <wsa:To>
    <wsa:EndpointReference xmlns:wsa="..." xmlns:tuscany="...">
    <!-- I'm not sure if we should use sca or tuscany ns here -->
       <wsa:Address>...URI of the service being 
invoked...</wsa:Address>
       <wsa:ReferenceParameters>
           <tuscany:CallbackID>callback-A01</tuscany:CallbackID>

<tuscany:ConversationID>conversation-006</tuscany:ConversationID>
           <tuscany:CallbackReference>
                <wsa:EndpointReference>
                        <wsa:Address>...URI of the service for the 
callback...</wsa:Address>
                <wsa:EndpointReference>
           </tuscany:CallbackReference>
       </wsa:ReferenceParameters>
    </wsa:EndpointReference>
 </wsa:To>

(Note: I have capitalized the first letters of CallbackID, 
ConversationID
and CallbackReference to match the WS-Addressing "house style")

This has a few advantages:

 1. It makes us fully compliant with WS-Addressing.

 2. WS-Addressing has the notion of a stateful endpoint reference, 
where
    the endpoint address is augmented with other information that
    represents a particular "instance" of the endpoint.  This is 
exactly
    what is happening here.  Invocations to the same SCA service 
that
    differ only in their conversation and callback information are 
very
    nicely modelled as different WS-Addressing endpoint references 
for
    the same endpoint address.

 3. It allows the wsa:To infomation to be exactly the same as the
    information that would be serialized to represent the 
CallableReference
    for the invocation.  This is a very neat solution to the 
question
    of how a CallableReference should be serialized.  It might even
    give us a decent chance of being interoperable with some 
non-SCA
    environments.

The callback message would be as follows:

 <wsa:To>
    <wsa:EndpointReference xmlns:wsa="..." xmlns:tuscany="...">
    <!-- I'm not sure if we should use sca or tuscany ns here -->
       <wsa:Address>...URI of the service for the 
callback...</wsa:Address>
       <wsa:ReferenceParameters>
           <tuscany:CallbackID>callback-A01</tuscany:CallbackID>

<tuscany:ConversationID>conversation-006</tuscany:ConversationID>
       </wsa:ReferenceParameters>
    </wsa:EndpointReference>
 </wsa:To>

Regarding the sca or tuscany namespace question, the code currently
uses the sca namespace but it may be better to use tuscany until we
get spec endorsement that this is the correct SCA-approved mapping 
for
SCA conversations and callbacks to Web service protocols.  This
would be defined in the WS Binding specification.

For comparison, this is what the current code does for forward 
calls,
with the From address directly representing the callback endpoint:

 <wsa:From>
    <wsa:EndpointReference xmlns:wsa="..." xmlns:tuscany="...">
    <!-- I'm not sure if we should use sca or tuscany ns here -->
       <wsa:Address>...The URI of the service for the 
callback...</wsa:Address>
       <wsa:ReferenceParameters>
           <tuscany:CallbackID>callback-A01</tuscany:CallbackID>

<tuscany:ConversationID>conversation-006</tuscany:ConversationID>
       </wsa:ReferenceParameters>
    </wsa:EndpointReference>
 </wsa:From>

  Simon

Raymond Feng wrote:

Hi,

I'm thinking of this syntax:

<wsa:From>
   <wsa:EndpointReference xmlns:wsa="..." xmlns:tuscany="..."> 
<!--  I'm not sure if we should use sca or tuscany ns here -->

<wsa:Address>...sourceComponentURI#referenceName...</wsa:Address>
      <wsa:ReferenceParameters>

<tuscany:callbackID>callback-A01</tuscany:conversationID>

<tuscany:conversationID>conversation-006</tuscany:conversationID>
          <tuscany:callbackReference>
               <wsa:EndpointReference>
                       <wsa:Address>...The URI of the service for 
the callback...</wsa:Address>
               <wsa:EndpointReference>
          </tuscany:callbackReference>
      </wsa:ReferenceParameters>
   </wsa:EndpointReference>
</wsa:From>


+1 to flow callback ID and conversation ID in parameters of the "to" 
endpoint reference.

I don't understand the technical reason for flowing the callback 
endpoint reference - nested!! - in a parameter of the "to" endpoint 
reference.

Can you help me understand why we cannot just use the "from" 
endpoint reference to identify the callback endpoint?

--
Jean-Sebastien



I've reviewed this thread and - unless I missed something - I think we 
have consensus on:
- conversationID flows as a reference parameter of the "to" epr
- callbackObject does not flow in the message at all

We don't have consensus on how to flow the callbackID, as I'm not sure 
yet that flowing it as a parameter of the "to" epr is right.

And we're still discussing the following how to flow the callback epr:
- as the replyTo epr?
- the from epr?
- as a callback epr nested in a parameter of the from or to eprs?
- as another epr, a callback epr, peer of the from, to and replyTo? 
(another option that I'd like to consider)

I think that the "WS-addressing mapping" exercise helped us make 
progress. How about another similar exercise now to help close this :)

IMO the SCA callback APIs provide built-in support for one of a more 
general category of message exchange patterns where partners exchange 
messages back and forth and communicate their service references and 
context data relevant to the interaction as part of the exchanged 
business data.

Let's take an example with 2 components, a Client component is wired to 
a Writer component, invokes the Writer to write some data, the writer 
sends another message to the client when the data has been written. I 
hope that the following pseudo-code will be clear enough to illustrate 
the scenario.

@Service(Client.class)
class Client {
   ComponentContext componentContext;
   Writer writer;

   write(inputData) {
      self = componentContext.createSelfReference();
      id = new UUID();
      writer.asyncWrite(self, id, inputData);
   }

   written(id) {
     // data <id> has been written
   }
}


@Service(Writer.class)
class Writer {

 @OneWay
 asyncWrite(clientReference, id, inputData) {
   // actually write the data

   clientReference.getService().written(id);
 }

}

Another variation of this could do self.setCallbackID(id) in the Client 
and id = clientReference.getCallbackID() in the Writer to pass the id 
as part of the reference instead of a business method parameter, but I 
don't think it really changes the pattern.

Assuming that a WS binding is used, what do people think the SOAP 
messages for the request and callback should look like?

I am sure there are many variations on this pattern that could be
used, as well as the two you have mentioned.  In deciding which one
to focus on as we consider the protocol mapping, I think an important
factor is that SCA does not treat conversationID, callbackID, and
callbackEndpoint as independent parameters to be passed around
separately.  They are all combined in the concept of a callable
reference (together with a destination endpoint), and it is this
callable reference that is conceptually passed around implicitly on
each method call or callback.

Staying as close to the SCA model as we can, but passing everything
around explicitly by the application, the above example would become:

 @Service(Client.class)
 class Client {
    ComponentContext componentContext;
    Writer writer;

    write(inputData) {
       target = componentContext.getServiceReference(Writer.class, 
"writer");
       self = componentContext.createSelfReference();
       id = new UUID();
       target.setCallbackID(id);
       self.setCallbackID(id);
       target.setCallback(self);
       target.getService().asyncWrite(target, inputData);
    }

    written(myReference) {
       // data <myReference.getCallbackID()> has been written
    }
 }

 @Service(Writer.class)
 class Writer {

    @OneWay
    asyncWrite(myReference, inputData) {
       // actually write the data

       clientReference = myReference.getCallback();
       clientReference.getService().written(clientReference);
    }
 }

Note that the caller's reference is not passed.  Like the ID, this is
set as a property of the target's reference, and it is the target's
reference that is passed around on every call.

We may debate whether or not this is a good pattern, but it is the
pattern defined by SCA.  And it is quite simple and logical once you
get used to it.  All the implicit data for the call is part of the
service reference that makes the call, and this service reference
is passed implicitly on every call.  The service reference is
serializable so that it can be passed around explicitly if desired.
The semantics of passing it explicitly or implicitly are the same,
with the same data being transmitted.

It is this semantic model that leads me to think of the SCA service
reference with all its implicit data as being closely equivalent to
the wsa:To stateful endpoint reference.  When using WS-Addressing,
the wsa:To endpoint reference including its state data is passed
with every call, which is very similar to the above pseudo-code.

  Simon






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]