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>

----- Original Message ----- From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, September 06, 2007 11:49 AM
Subject: Re: What is Message.set/getCallableReference used for?


I'm OK with everything else said in thread so I cut it out to keep this readable.

[snip]
Raymond Feng wrote:


- A new Message.replyTo endpoint reference field should be added as the "replyTo" endpoint can be different from the "from" endpoint and callback information should be carried in that new replyTo endpoint reference.

I don't agree with this.  The WS-Addressing replyTo field is used for
a reply to the forward message. The semantics of a reply (see section 3.2
of the WS-Addressing spec) are not the same as SCA callback semantics.
An SCA callback is a new message that is additional to the reply for
the original forward message.  A WS-Addressing request/reply exchange
must observe the following requirements:
 1. The request message must contain a MessageID element
 2. The reply message must contain a RelatesTo element containing
    the MessageId of the original request.
Neither of these is needed for callback purposes.  SCA callbacks should
not be tied to the original message in this way.

The wsa:From element is well suited to carrying the SCA callback
endpoint information because it simply provides an endpoint to call and
does not impose any additional protocol requirements.


I don't think we should directly use From to hold the callback endpoint. We'll lost the caller's EPR if we do so and we cannot support RequestContext.getServiceReference(). I sgguest that we keep the callback endpoint as a reference parameter in the caller's EPR which should be the From. By default, the callback endpoint will be the callback service on the source reference and it can be changed by calling ServiceReference.setCallback() on the caller side.



To help me understand what you're proposing (and since all of this has to work with Web Services as well) can you paste here two SOAP envelopes showing a request and a callback? Thanks.

--
Jean-Sebastien





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

Reply via email to