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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
