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

[Simon Nash]

The semantics of the ODE protocols for state identifiers and callback
endpoints are interesting but they seem somewhat different from the SCA
approach of having callable references that contain client-specified
conversation IDs, callback IDs, and callback references.

I'm not sure of the advantage of using a special header instead of
a reference parameter of the wsa:To endpoint.  Please see my recent
post explaining why I think putting all the implicit data in wsa:To
is consistent with the SCA model.  What is the benefit of pulling out
the callback URI and the callback ID into a separate header?  These
are part of the callable reference on both client and service sides,
together with the conversationID, and it doesn't seem natural to
separate them from the conversation ID in the wire protocol.

  Simon

Raymond Feng wrote:

Hi,

I think it is a good idea to pass the callback EPR and callback id in a <tuscany:Callback> header of type wsa:EndpointReference for the request call as we cannot find a built-in wsa element for this purpose.

For the request:

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

       </wsa:ReferenceParameters>
   </wsa:EndpointReference>
</tuscany:Callback>

For the callback:

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

       </wsa:ReferenceParameters>
</wsa:To>

The ODE folks seem to have a similar idea: http://ode.apache.org/stateful-exchange-protocol.html.

Thanks,
Raymond

----- Original Message ----- From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>

To: <tuscany-dev@ws.apache.org>
Sent: Saturday, September 08, 2007 3:45 PM

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

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?

--
Jean-Sebastien

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