You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2007/09/04 04:03:09 UTC
What is Message.set/getCallableReference used for?
Could somebody help me understand what Message.set/getCallableReference
is used for?
If I comment it then some callback test cases start to fail, but I don't
really understand why we need to store a CallableReference in the
message, and its relationship with the from and to EndpointReferences,
which can already host callback endpoints.
Also CallableReference is specific to Java (if I understand correctly it
takes a Java business interface) so if it's really used and needed I'm
not sure about how it's used for callbacks typed by WSDL or other
interface definition languages.
Thanks
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What is Message.set/getCallableReference used for?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> There are a set of states associated with
> CallableReference/ServiceReference such as the callbackID,
> conversationID and callbackObject. We need to flow them in the Message
> so that the target service can have the correct correlations. At this
> moment, we have some of fields on the Message and I thought maybe it's
> better to follow the CallableReference as a whole. Another reason is
> that the RequestContext has a few methods to retrieve the
> ServiceReference, CallbackReference and Callback object.
CallbackID seems to be set to CorrelationID, already another field of
the message.
Here are the only usages I can find for getCallableReference():
in Axis2BindingInvoker
fromEPR.addReferenceParameter(CALLBACK_ID_REFPARM_QN,
(String)msg.getCallableReference().getCallbackID());
in CallbackInterfaceInterceptor, doesn't look like a valid usage
and setCallableReference():
in JDKInvocationHandler
msg.setCallableReference(callableReference);
just after having done
msg.setCorrelationID(callbackID);
Are there any other valid usages? I'm probably missing something as I've
not been able to understand why callbacks start to fail when I remove
this and just flow the callbackID in the correlationID field... Could
somebody else give it a try as well?
>
> I agree with your comments that it's not very nice to have
> CallableReference directly on the Message as accessors. Moving
> forward, we probably need to define headers for the Message interface
> so that we can flow extra context data without poluting the Message
> interface. There are already some use cases such as:
>
> * Pass some information from one interceptor to another one, for
> example, the DataBindingInterceptor can tell the PassByValueInvoker to
> skip the copy.
> * Carry binding-specific context in the Message, for example, SOAP
> headers for binding.ws or JMS properties for binding.jms.
We'll probably need a "headers" property on the message, but I think
we'll have to be careful into a bag of things that are convenient to
pass around this way but not absolutely necessary.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jean-Sebastien Delfino"
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Monday, September 03, 2007 7:03 PM
> Subject: What is Message.set/getCallableReference used for?
>
>
>> Could somebody help me understand what
>> Message.set/getCallableReference is used for?
>>
>> If I comment it then some callback test cases start to fail, but I
>> don't really understand why we need to store a CallableReference in
>> the message, and its relationship with the from and to
>> EndpointReferences, which can already host callback endpoints.
>>
>> Also CallableReference is specific to Java (if I understand correctly
>> it takes a Java business interface) so if it's really used and needed
>> I'm not sure about how it's used for callbacks typed by WSDL or other
>> interface definition languages.
>>
>> Thanks
>>
>> --
>> Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference
used for?)
Posted by Simon Nash <na...@hursley.ibm.com>.
Comments inline.
Simon
Jean-Sebastien Delfino wrote:
> Comments inline.
>
> [snip]
> Simon Nash wrote:
>
>> I agree that we need a conclusion. I believe the detailed proposal below
>> supports all the SCA semantics and I'd like to propose that we go with it
>> for Tuscany 1.0.
>>
>> Any comments, questions, agreement, or disagreement?
>>
>> Simon
>>
>
> I was initially thinking that the Callback EPR should be a separate
> header outside of the To EPR but the code snippet that you put together
> to simulate the SCA built-in callback (at the bottom of that email)
> convinced me that I was wrong about it :)
>
> So I'm +1 with your proposal in [1]:
>
> Request message
> <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>
> <wsa:EndpointReference>
> <wsa:Address>...URI of the service for the
> callback...</wsa:Address>
> <wsa:EndpointReference>
> </tuscany:CallbackReference>
> </wsa:ReferenceParameters>
> </wsa:EndpointReference>
> </wsa:To>
>
> Callback message:
> <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>
>
> In plain text:
> - CallbackID flows as a reference parameter of the "To" EPR
> - ConversationID flows as a reference parameter of the "To" EPR
> - CallbackReference is a well formed EPR and flows as a reference
> parameter of the "To" EPR
>
I can see the benefit of this, as it makes the pseudo-code below a
closer match for what is flowing on the wire, with an SCA callable
reference always being serialized as a WS-Addressing EPR. So I am
+1 with using a well-formed WS-Addressing EPR for the callback EPR.
> I think that we should propose this mapping to the OASIS SCA Bindings
> workgroup. Different implementations of SCA should follow the same
> mapping if we want them to interoperate over Web Services for example.
>
Yes, I agree. I'll ask the chair of the newly formed OASIS TC how we
should raise this as formal issue for the TC.
> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg22923.html
>
>
> [snip]
>
>>
>>>> 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
>
>
> I'm not keen on doing that. I'd prefer to stick to your initial proposal
> which seems cleaner to me, using the same standard form to represent the
> CallbackReference EPR in the request message and the To EPR in the
> callback message.
>
+1 for going with the alternative version above instead of this version.
>>>>>
>>>>>>
>>>>>> @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);
>>>>>> }
>>>>>> }
>
>
> I'd suggest a small variation of this pseudo-code, to be more in line
> with the protocol that you proposed (the callbackID doesn't flow in the
> CallbackReference in the request message):
>
> @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);
> 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.setCallbackID(myReference.getCallbackID());
> clientReference.getService().written(clientReference);
> }
> }
>
+1 for this change. It makes the pseudo-code match exactly with the
protocol on the wire.
Simon
> --
>
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference used for?)
Posted by Raymond Feng <en...@gmail.com>.
I'm fine with your summary.
Thanks,
Raymond
----- Original Message -----
From: "Simon Nash" <na...@hursley.ibm.com>
To: <tu...@ws.apache.org>
Sent: Thursday, September 13, 2007 1:48 AM
Subject: Re: WS-Addressing mapping (was Re: What is
Message.set/getCallableReference used for?)
>I don't know if we reached a conclusion on this discussion.
>
> If we are agreed that the callback object is conceptually part of
> the conversation state and should not be changed during a conversation
> (because of unpredictable results in some async cases), then we could
> go one step further and prevent it from being changed while it is
> associated with an active converation. This removes the concern of
> unpredictability. We can also ask the OASIS TC for a spec clarification
> on how this is supposed to work.
>
> Simon
>
> Simon Nash wrote:
>
>> See inline.
>>
>> Simon
>>
>> Raymond Feng wrote:
>>
>>> Comments inline.
>>>
>>> Thanks,
>>> Raymond
>>>
>>> ----- Original Message ----- From: "Simon Nash" <na...@hursley.ibm.com>
>>> To: <tu...@ws.apache.org>
>>> Sent: Tuesday, September 11, 2007 7:47 AM
>>> Subject: Re: WS-Addressing mapping (was Re: What is
>>> Message.set/getCallableReference used for?)
>>>
>>>
>>>> Thanks for pointing out this issue. I think we're OK with just
>>>> using ConversationID as the correlator as long as we make the
>>>> following assumptions:
>>>>
>>>> 1. The correlation from ConversationID to callback object is done
>>>> on a per-reference basis.
>>>
>>>
>>>
>>> Are you assuming for the lifecylce of a conversation, there is only one
>>> effective callback object for a given service reference?
>>
>> >
>> Yes. This seems consistent with the following spec words: "...callback
>> messages go to the client and are then routed to the specific instance
>> that has been registered as the callback object". See further comments
>> below on this.
>>
>>> Even so, we
>>> still need to do some correlations (using the callback endpoint URI as
>>> the key?) to relate a callback to the given service reference, right?
>>>
>> Logically yes, but I don't think any explicit correlation on endpoint
>> URI is needed. I was expecting each callback endpoint to keep its own
>> correlation table that maps ConversationID to callback object. (This
>> is probably just a particular implementation of what you are saying.)
>>
>>>> 2. The callback goes to the callback object that is set into the
>>>> reference at the time the callback is made, not at the time
>>>> the forward call is made.
>>>>
>>>> Consider the following code:
>>>>
>>>> myRef = componentContext.getServiceReference(convInterface, refName);
>>>> myRef.setCallback(callback1);
>>>> myRef.getService().startConversation();
>>>> myRef.setCallback(callback2);
>>>> myRef.getService().continueConversation();
>>>> myRef.setCallback(callback3);
>>>>
>>>
>>> Are you saying if the myRef.setCallback() is called for multiple times,
>>> the effective callback object will override the previous one? If so and
>>> if startConversation() and contineConversation() are one-way async
>>> operations, the result is unpredictable.
>>>
>> Yes, I am saying that. The situation won't arise unless someone changes
>> the callback object after making an async call. If the callback object
>> were never set, then all callbacks would go to a single instance of the
>> client component. It seems reasonable to think of the callback object
>> as a way of redirecting callbacks from this single instance to a
>> different
>> single instance on the client side, rather than a way of redirecting
>> callbacks to multiple client-side instances on a per-call basis.
>>
>> Another way to look at this is that the callback object instance becomes
>> part of the state of the conversation. This seems consistent with the
>> requirement that a callback object that isn't a service reference can
>> only be used with a stateful callback. If a different unique
>> correlation ID were used to locate the callback object, there would
>> be no need for the stateful callback limitation.
>>
>>>> With the assumptions listed above, the callbacks from
>>>> startConversation()
>>>> and continueConversation() would go to callback3 (the current value)
>>>> instead of callback1 and callback2 respectively (the values at the time
>>>> of the forward calls). I don't see anything in the spec that says that
>>>> this is not correct.
>>>
>>>
>>>
>>> Assuming both the forward call and callback are synchronous, if the
>>> callback happens in the startConversation() method of the target
>>> service, then it will go to callback1, right? In this case, the
>>> setCallback(callback2) hasn't even been called.
>>>
>> Yes, thanks for the clarification. I realised just as I pushed Send that
>> I hadn't been clear that I was thinking of the async case where callbacks
>> arrived after all the code had been executed.
>>
>> Simon
>>
>>>>
>>>> Does this take care of the cases you had in mind?
>>>>
>>>> Simon
>>>>
>>>> Raymond Feng wrote:
>>>>
>>>>> +1 on the proposal. There is one more thing to add.
>>>>>
>>>>> For the case that the callback object is not a ServiceReference, we
>>>>> don't flow it in the Message, but we still need to correlate the
>>>>> callback to this object so that the callback can be routed to the
>>>>> right callback object. ConversationID alone is good enough, because
>>>>> we can use different callback objects in the same conversation. I
>>>>> suggest that we add a "CallbackObjectID" to reference parameter under
>>>>> the CallbackReference. The CallbackObjectID can be the system hash
>>>>> code of the callback object. The ConversationID + CallbackObjectID
>>>>> will be the key for the correlation.
>>>>>
>>>>> Do you agree?
>>>>>
>>>>> Thanks,
>>>>> Raymond
>>>>>
>>>>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>>>>> <js...@apache.org>
>>>>> To: <tu...@ws.apache.org>
>>>>> Sent: Monday, September 10, 2007 3:43 PM
>>>>> Subject: Re: WS-Addressing mapping (was Re: What is
>>>>> Message.set/getCallableReference used for?)
>>>>>
>>>>>
>>>>>> Comments inline.
>>>>>>
>>>>>> [snip]
>>>>>> Simon Nash wrote:
>>>>>>
>>>>>>> I agree that we need a conclusion. I believe the detailed proposal
>>>>>>> below
>>>>>>> supports all the SCA semantics and I'd like to propose that we go
>>>>>>> with it
>>>>>>> for Tuscany 1.0.
>>>>>>>
>>>>>>> Any comments, questions, agreement, or disagreement?
>>>>>>>
>>>>>>> Simon
>>>>>>>
>>>>>>
>>>>>> I was initially thinking that the Callback EPR should be a separate
>>>>>> header outside of the To EPR but the code snippet that you put
>>>>>> together to simulate the SCA built-in callback (at the bottom of that
>>>>>> email) convinced me that I was wrong about it :)
>>>>>>
>>>>>> So I'm +1 with your proposal in [1]:
>>>>>>
>>>>>> Request message
>>>>>> <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>
>>>>>> <wsa:EndpointReference>
>>>>>> <wsa:Address>...URI of the service for the
>>>>>> callback...</wsa:Address>
>>>>>> <wsa:EndpointReference>
>>>>>> </tuscany:CallbackReference>
>>>>>> </wsa:ReferenceParameters>
>>>>>> </wsa:EndpointReference>
>>>>>> </wsa:To>
>>>>>>
>>>>>> Callback message:
>>>>>> <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>
>>>>>>
>>>>>> In plain text:
>>>>>> - CallbackID flows as a reference parameter of the "To" EPR
>>>>>> - ConversationID flows as a reference parameter of the "To" EPR
>>>>>> - CallbackReference is a well formed EPR and flows as a reference
>>>>>> parameter of the "To" EPR
>>>>>>
>>>>>> I think that we should propose this mapping to the OASIS SCA Bindings
>>>>>> workgroup. Different implementations of SCA should follow the same
>>>>>> mapping if we want them to interoperate over Web Services for
>>>>>> example.
>>>>>>
>>>>>> [1]
>>>>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg22923.html
>>>>>>
>>>>>>
>>>>>> [snip]
>>>>>>
>>>>>>>
>>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm not keen on doing that. I'd prefer to stick to your initial
>>>>>> proposal which seems cleaner to me, using the same standard form to
>>>>>> represent the CallbackReference EPR in the request message and the To
>>>>>> EPR in the callback message.
>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> @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);
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'd suggest a small variation of this pseudo-code, to be more in line
>>>>>> with the protocol that you proposed (the callbackID doesn't flow in
>>>>>> the CallbackReference in the request message):
>>>>>>
>>>>>> @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);
>>>>>> 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.setCallbackID(myReference.getCallbackID());
>>>>>> clientReference.getService().written(clientReference);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Jean-Sebastien
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>>
>>>>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference
used for?)
Posted by Simon Nash <na...@hursley.ibm.com>.
I don't know if we reached a conclusion on this discussion.
If we are agreed that the callback object is conceptually part of
the conversation state and should not be changed during a conversation
(because of unpredictable results in some async cases), then we could
go one step further and prevent it from being changed while it is
associated with an active converation. This removes the concern of
unpredictability. We can also ask the OASIS TC for a spec clarification
on how this is supposed to work.
Simon
Simon Nash wrote:
> See inline.
>
> Simon
>
> Raymond Feng wrote:
>
>> Comments inline.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message ----- From: "Simon Nash" <na...@hursley.ibm.com>
>> To: <tu...@ws.apache.org>
>> Sent: Tuesday, September 11, 2007 7:47 AM
>> Subject: Re: WS-Addressing mapping (was Re: What is
>> Message.set/getCallableReference used for?)
>>
>>
>>> Thanks for pointing out this issue. I think we're OK with just
>>> using ConversationID as the correlator as long as we make the
>>> following assumptions:
>>>
>>> 1. The correlation from ConversationID to callback object is done
>>> on a per-reference basis.
>>
>>
>>
>> Are you assuming for the lifecylce of a conversation, there is only
>> one effective callback object for a given service reference?
>
> >
> Yes. This seems consistent with the following spec words: "...callback
> messages go to the client and are then routed to the specific instance
> that has been registered as the callback object". See further comments
> below on this.
>
>> Even so, we
>> still need to do some correlations (using the callback endpoint URI as
>> the key?) to relate a callback to the given service reference, right?
>>
> Logically yes, but I don't think any explicit correlation on endpoint
> URI is needed. I was expecting each callback endpoint to keep its own
> correlation table that maps ConversationID to callback object. (This
> is probably just a particular implementation of what you are saying.)
>
>>> 2. The callback goes to the callback object that is set into the
>>> reference at the time the callback is made, not at the time
>>> the forward call is made.
>>>
>>> Consider the following code:
>>>
>>> myRef = componentContext.getServiceReference(convInterface, refName);
>>> myRef.setCallback(callback1);
>>> myRef.getService().startConversation();
>>> myRef.setCallback(callback2);
>>> myRef.getService().continueConversation();
>>> myRef.setCallback(callback3);
>>>
>>
>> Are you saying if the myRef.setCallback() is called for multiple
>> times, the effective callback object will override the previous one?
>> If so and if startConversation() and contineConversation() are one-way
>> async operations, the result is unpredictable.
>>
> Yes, I am saying that. The situation won't arise unless someone changes
> the callback object after making an async call. If the callback object
> were never set, then all callbacks would go to a single instance of the
> client component. It seems reasonable to think of the callback object
> as a way of redirecting callbacks from this single instance to a different
> single instance on the client side, rather than a way of redirecting
> callbacks to multiple client-side instances on a per-call basis.
>
> Another way to look at this is that the callback object instance becomes
> part of the state of the conversation. This seems consistent with the
> requirement that a callback object that isn't a service reference can
> only be used with a stateful callback. If a different unique
> correlation ID were used to locate the callback object, there would
> be no need for the stateful callback limitation.
>
>>> With the assumptions listed above, the callbacks from
>>> startConversation()
>>> and continueConversation() would go to callback3 (the current value)
>>> instead of callback1 and callback2 respectively (the values at the time
>>> of the forward calls). I don't see anything in the spec that says that
>>> this is not correct.
>>
>>
>>
>> Assuming both the forward call and callback are synchronous, if the
>> callback happens in the startConversation() method of the target
>> service, then it will go to callback1, right? In this case, the
>> setCallback(callback2) hasn't even been called.
>>
> Yes, thanks for the clarification. I realised just as I pushed Send that
> I hadn't been clear that I was thinking of the async case where callbacks
> arrived after all the code had been executed.
>
> Simon
>
>>>
>>> Does this take care of the cases you had in mind?
>>>
>>> Simon
>>>
>>> Raymond Feng wrote:
>>>
>>>> +1 on the proposal. There is one more thing to add.
>>>>
>>>> For the case that the callback object is not a ServiceReference, we
>>>> don't flow it in the Message, but we still need to correlate the
>>>> callback to this object so that the callback can be routed to the
>>>> right callback object. ConversationID alone is good enough, because
>>>> we can use different callback objects in the same conversation. I
>>>> suggest that we add a "CallbackObjectID" to reference parameter
>>>> under the CallbackReference. The CallbackObjectID can be the system
>>>> hash code of the callback object. The ConversationID +
>>>> CallbackObjectID will be the key for the correlation.
>>>>
>>>> Do you agree?
>>>>
>>>> Thanks,
>>>> Raymond
>>>>
>>>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>>>> <js...@apache.org>
>>>> To: <tu...@ws.apache.org>
>>>> Sent: Monday, September 10, 2007 3:43 PM
>>>> Subject: Re: WS-Addressing mapping (was Re: What is
>>>> Message.set/getCallableReference used for?)
>>>>
>>>>
>>>>> Comments inline.
>>>>>
>>>>> [snip]
>>>>> Simon Nash wrote:
>>>>>
>>>>>> I agree that we need a conclusion. I believe the detailed
>>>>>> proposal below
>>>>>> supports all the SCA semantics and I'd like to propose that we go
>>>>>> with it
>>>>>> for Tuscany 1.0.
>>>>>>
>>>>>> Any comments, questions, agreement, or disagreement?
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>
>>>>> I was initially thinking that the Callback EPR should be a separate
>>>>> header outside of the To EPR but the code snippet that you put
>>>>> together to simulate the SCA built-in callback (at the bottom of
>>>>> that email) convinced me that I was wrong about it :)
>>>>>
>>>>> So I'm +1 with your proposal in [1]:
>>>>>
>>>>> Request message
>>>>> <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>
>>>>> <wsa:EndpointReference>
>>>>> <wsa:Address>...URI of the service for the
>>>>> callback...</wsa:Address>
>>>>> <wsa:EndpointReference>
>>>>> </tuscany:CallbackReference>
>>>>> </wsa:ReferenceParameters>
>>>>> </wsa:EndpointReference>
>>>>> </wsa:To>
>>>>>
>>>>> Callback message:
>>>>> <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>
>>>>>
>>>>> In plain text:
>>>>> - CallbackID flows as a reference parameter of the "To" EPR
>>>>> - ConversationID flows as a reference parameter of the "To" EPR
>>>>> - CallbackReference is a well formed EPR and flows as a reference
>>>>> parameter of the "To" EPR
>>>>>
>>>>> I think that we should propose this mapping to the OASIS SCA
>>>>> Bindings workgroup. Different implementations of SCA should follow
>>>>> the same mapping if we want them to interoperate over Web Services
>>>>> for example.
>>>>>
>>>>> [1]
>>>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg22923.html
>>>>>
>>>>>
>>>>> [snip]
>>>>>
>>>>>>
>>>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I'm not keen on doing that. I'd prefer to stick to your initial
>>>>> proposal which seems cleaner to me, using the same standard form to
>>>>> represent the CallbackReference EPR in the request message and the
>>>>> To EPR in the callback message.
>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> @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);
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I'd suggest a small variation of this pseudo-code, to be more in
>>>>> line with the protocol that you proposed (the callbackID doesn't
>>>>> flow in the CallbackReference in the request message):
>>>>>
>>>>> @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);
>>>>> 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.setCallbackID(myReference.getCallbackID());
>>>>> clientReference.getService().written(clientReference);
>>>>> }
>>>>> }
>>>>>
>>>>> --
>>>>>
>>>>> Jean-Sebastien
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>
>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference
used for?)
Posted by Simon Nash <na...@hursley.ibm.com>.
See inline.
Simon
Raymond Feng wrote:
> Comments inline.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Simon Nash" <na...@hursley.ibm.com>
> To: <tu...@ws.apache.org>
> Sent: Tuesday, September 11, 2007 7:47 AM
> Subject: Re: WS-Addressing mapping (was Re: What is
> Message.set/getCallableReference used for?)
>
>
>> Thanks for pointing out this issue. I think we're OK with just
>> using ConversationID as the correlator as long as we make the
>> following assumptions:
>>
>> 1. The correlation from ConversationID to callback object is done
>> on a per-reference basis.
>
>
> Are you assuming for the lifecylce of a conversation, there is only one
> effective callback object for a given service reference?
>
Yes. This seems consistent with the following spec words: "...callback
messages go to the client and are then routed to the specific instance
that has been registered as the callback object". See further comments
below on this.
> Even so, we
> still need to do some correlations (using the callback endpoint URI as
> the key?) to relate a callback to the given service reference, right?
>
Logically yes, but I don't think any explicit correlation on endpoint
URI is needed. I was expecting each callback endpoint to keep its own
correlation table that maps ConversationID to callback object. (This
is probably just a particular implementation of what you are saying.)
>> 2. The callback goes to the callback object that is set into the
>> reference at the time the callback is made, not at the time
>> the forward call is made.
>>
>> Consider the following code:
>>
>> myRef = componentContext.getServiceReference(convInterface, refName);
>> myRef.setCallback(callback1);
>> myRef.getService().startConversation();
>> myRef.setCallback(callback2);
>> myRef.getService().continueConversation();
>> myRef.setCallback(callback3);
>>
>
> Are you saying if the myRef.setCallback() is called for multiple times,
> the effective callback object will override the previous one? If so and
> if startConversation() and contineConversation() are one-way async
> operations, the result is unpredictable.
>
Yes, I am saying that. The situation won't arise unless someone changes
the callback object after making an async call. If the callback object
were never set, then all callbacks would go to a single instance of the
client component. It seems reasonable to think of the callback object
as a way of redirecting callbacks from this single instance to a different
single instance on the client side, rather than a way of redirecting
callbacks to multiple client-side instances on a per-call basis.
Another way to look at this is that the callback object instance becomes
part of the state of the conversation. This seems consistent with the
requirement that a callback object that isn't a service reference can
only be used with a stateful callback. If a different unique
correlation ID were used to locate the callback object, there would
be no need for the stateful callback limitation.
>> With the assumptions listed above, the callbacks from startConversation()
>> and continueConversation() would go to callback3 (the current value)
>> instead of callback1 and callback2 respectively (the values at the time
>> of the forward calls). I don't see anything in the spec that says that
>> this is not correct.
>
>
> Assuming both the forward call and callback are synchronous, if the
> callback happens in the startConversation() method of the target
> service, then it will go to callback1, right? In this case, the
> setCallback(callback2) hasn't even been called.
>
Yes, thanks for the clarification. I realised just as I pushed Send that
I hadn't been clear that I was thinking of the async case where callbacks
arrived after all the code had been executed.
Simon
>>
>> Does this take care of the cases you had in mind?
>>
>> Simon
>>
>> Raymond Feng wrote:
>>
>>> +1 on the proposal. There is one more thing to add.
>>>
>>> For the case that the callback object is not a ServiceReference, we
>>> don't flow it in the Message, but we still need to correlate the
>>> callback to this object so that the callback can be routed to the
>>> right callback object. ConversationID alone is good enough, because
>>> we can use different callback objects in the same conversation. I
>>> suggest that we add a "CallbackObjectID" to reference parameter under
>>> the CallbackReference. The CallbackObjectID can be the system hash
>>> code of the callback object. The ConversationID + CallbackObjectID
>>> will be the key for the correlation.
>>>
>>> Do you agree?
>>>
>>> Thanks,
>>> Raymond
>>>
>>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>>> <js...@apache.org>
>>> To: <tu...@ws.apache.org>
>>> Sent: Monday, September 10, 2007 3:43 PM
>>> Subject: Re: WS-Addressing mapping (was Re: What is
>>> Message.set/getCallableReference used for?)
>>>
>>>
>>>> Comments inline.
>>>>
>>>> [snip]
>>>> Simon Nash wrote:
>>>>
>>>>> I agree that we need a conclusion. I believe the detailed proposal
>>>>> below
>>>>> supports all the SCA semantics and I'd like to propose that we go
>>>>> with it
>>>>> for Tuscany 1.0.
>>>>>
>>>>> Any comments, questions, agreement, or disagreement?
>>>>>
>>>>> Simon
>>>>>
>>>>
>>>> I was initially thinking that the Callback EPR should be a separate
>>>> header outside of the To EPR but the code snippet that you put
>>>> together to simulate the SCA built-in callback (at the bottom of
>>>> that email) convinced me that I was wrong about it :)
>>>>
>>>> So I'm +1 with your proposal in [1]:
>>>>
>>>> Request message
>>>> <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>
>>>> <wsa:EndpointReference>
>>>> <wsa:Address>...URI of the service for the
>>>> callback...</wsa:Address>
>>>> <wsa:EndpointReference>
>>>> </tuscany:CallbackReference>
>>>> </wsa:ReferenceParameters>
>>>> </wsa:EndpointReference>
>>>> </wsa:To>
>>>>
>>>> Callback message:
>>>> <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>
>>>>
>>>> In plain text:
>>>> - CallbackID flows as a reference parameter of the "To" EPR
>>>> - ConversationID flows as a reference parameter of the "To" EPR
>>>> - CallbackReference is a well formed EPR and flows as a reference
>>>> parameter of the "To" EPR
>>>>
>>>> I think that we should propose this mapping to the OASIS SCA
>>>> Bindings workgroup. Different implementations of SCA should follow
>>>> the same mapping if we want them to interoperate over Web Services
>>>> for example.
>>>>
>>>> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg22923.html
>>>>
>>>>
>>>> [snip]
>>>>
>>>>>
>>>>>>> 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
>>>>
>>>>
>>>>
>>>> I'm not keen on doing that. I'd prefer to stick to your initial
>>>> proposal which seems cleaner to me, using the same standard form to
>>>> represent the CallbackReference EPR in the request message and the
>>>> To EPR in the callback message.
>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> @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);
>>>>>>>>> }
>>>>>>>>> }
>>>>
>>>>
>>>>
>>>> I'd suggest a small variation of this pseudo-code, to be more in
>>>> line with the protocol that you proposed (the callbackID doesn't
>>>> flow in the CallbackReference in the request message):
>>>>
>>>> @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);
>>>> 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.setCallbackID(myReference.getCallbackID());
>>>> clientReference.getService().written(clientReference);
>>>> }
>>>> }
>>>>
>>>> --
>>>>
>>>> Jean-Sebastien
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference used for?)
Posted by Raymond Feng <en...@gmail.com>.
Comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Simon Nash" <na...@hursley.ibm.com>
To: <tu...@ws.apache.org>
Sent: Tuesday, September 11, 2007 7:47 AM
Subject: Re: WS-Addressing mapping (was Re: What is
Message.set/getCallableReference used for?)
> Thanks for pointing out this issue. I think we're OK with just
> using ConversationID as the correlator as long as we make the
> following assumptions:
>
> 1. The correlation from ConversationID to callback object is done
> on a per-reference basis.
Are you assuming for the lifecylce of a conversation, there is only one
effective callback object for a given service reference? Even so, we still
need to do some correlations (using the callback endpoint URI as the key?)
to relate a callback to the given service reference, right?
> 2. The callback goes to the callback object that is set into the
> reference at the time the callback is made, not at the time
> the forward call is made.
>
> Consider the following code:
>
> myRef = componentContext.getServiceReference(convInterface, refName);
> myRef.setCallback(callback1);
> myRef.getService().startConversation();
> myRef.setCallback(callback2);
> myRef.getService().continueConversation();
> myRef.setCallback(callback3);
>
Are you saying if the myRef.setCallback() is called for multiple times, the
effective callback object will override the previous one? If so and if
startConversation() and contineConversation() are one-way async operations,
the result is unpredictable.
> With the assumptions listed above, the callbacks from startConversation()
> and continueConversation() would go to callback3 (the current value)
> instead of callback1 and callback2 respectively (the values at the time
> of the forward calls). I don't see anything in the spec that says that
> this is not correct.
Assuming both the forward call and callback are synchronous, if the callback
happens in the startConversation() method of the target service, then it
will go to callback1, right? In this case, the setCallback(callback2) hasn't
even been called.
>
> Does this take care of the cases you had in mind?
>
> Simon
>
> Raymond Feng wrote:
>
>> +1 on the proposal. There is one more thing to add.
>>
>> For the case that the callback object is not a ServiceReference, we don't
>> flow it in the Message, but we still need to correlate the callback to
>> this object so that the callback can be routed to the right callback
>> object. ConversationID alone is good enough, because
>> we can use different callback objects in the same conversation. I suggest
>> that we add a "CallbackObjectID" to reference parameter under the
>> CallbackReference. The CallbackObjectID can be the system hash code of
>> the callback object. The ConversationID + CallbackObjectID will be the
>> key for the correlation.
>>
>> Do you agree?
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>> <js...@apache.org>
>> To: <tu...@ws.apache.org>
>> Sent: Monday, September 10, 2007 3:43 PM
>> Subject: Re: WS-Addressing mapping (was Re: What is
>> Message.set/getCallableReference used for?)
>>
>>
>>> Comments inline.
>>>
>>> [snip]
>>> Simon Nash wrote:
>>>
>>>> I agree that we need a conclusion. I believe the detailed proposal
>>>> below
>>>> supports all the SCA semantics and I'd like to propose that we go with
>>>> it
>>>> for Tuscany 1.0.
>>>>
>>>> Any comments, questions, agreement, or disagreement?
>>>>
>>>> Simon
>>>>
>>>
>>> I was initially thinking that the Callback EPR should be a separate
>>> header outside of the To EPR but the code snippet that you put together
>>> to simulate the SCA built-in callback (at the bottom of that email)
>>> convinced me that I was wrong about it :)
>>>
>>> So I'm +1 with your proposal in [1]:
>>>
>>> Request message
>>> <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>
>>> <wsa:EndpointReference>
>>> <wsa:Address>...URI of the service for the
>>> callback...</wsa:Address>
>>> <wsa:EndpointReference>
>>> </tuscany:CallbackReference>
>>> </wsa:ReferenceParameters>
>>> </wsa:EndpointReference>
>>> </wsa:To>
>>>
>>> Callback message:
>>> <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>
>>>
>>> In plain text:
>>> - CallbackID flows as a reference parameter of the "To" EPR
>>> - ConversationID flows as a reference parameter of the "To" EPR
>>> - CallbackReference is a well formed EPR and flows as a reference
>>> parameter of the "To" EPR
>>>
>>> I think that we should propose this mapping to the OASIS SCA Bindings
>>> workgroup. Different implementations of SCA should follow the same
>>> mapping if we want them to interoperate over Web Services for example.
>>>
>>> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg22923.html
>>>
>>>
>>> [snip]
>>>
>>>>
>>>>>> 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
>>>
>>>
>>> I'm not keen on doing that. I'd prefer to stick to your initial proposal
>>> which seems cleaner to me, using the same standard form to represent the
>>> CallbackReference EPR in the request message and the To EPR in the
>>> callback message.
>>>
>>>>>>>
>>>>>>>>
>>>>>>>> @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);
>>>>>>>> }
>>>>>>>> }
>>>
>>>
>>> I'd suggest a small variation of this pseudo-code, to be more in line
>>> with the protocol that you proposed (the callbackID doesn't flow in the
>>> CallbackReference in the request message):
>>>
>>> @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);
>>> 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.setCallbackID(myReference.getCallbackID());
>>> clientReference.getService().written(clientReference);
>>> }
>>> }
>>>
>>> --
>>>
>>> Jean-Sebastien
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>>
>
> --
> Simon C Nash IBM Distinguished Engineer
> Hursley Park, Winchester, UK nash@hursley.ibm.com
> Tel. +44-1962-815156 Fax +44-1962-818999
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference
used for?)
Posted by Simon Nash <na...@hursley.ibm.com>.
Thanks for pointing out this issue. I think we're OK with just
using ConversationID as the correlator as long as we make the
following assumptions:
1. The correlation from ConversationID to callback object is done
on a per-reference basis.
2. The callback goes to the callback object that is set into the
reference at the time the callback is made, not at the time
the forward call is made.
Consider the following code:
myRef = componentContext.getServiceReference(convInterface, refName);
myRef.setCallback(callback1);
myRef.getService().startConversation();
myRef.setCallback(callback2);
myRef.getService().continueConversation();
myRef.setCallback(callback3);
With the assumptions listed above, the callbacks from startConversation()
and continueConversation() would go to callback3 (the current value)
instead of callback1 and callback2 respectively (the values at the time
of the forward calls). I don't see anything in the spec that says that
this is not correct.
Does this take care of the cases you had in mind?
Simon
Raymond Feng wrote:
> +1 on the proposal. There is one more thing to add.
>
> For the case that the callback object is not a ServiceReference, we
> don't flow it in the Message, but we still need to correlate the
> callback to this object so that the callback can be routed to the right
> callback object. ConversationID alone is good enough, because
> we can use different callback objects in the same conversation. I
> suggest that we add a "CallbackObjectID" to reference parameter under
> the CallbackReference. The CallbackObjectID can be the system hash code
> of the callback object. The ConversationID + CallbackObjectID will be
> the key for the correlation.
>
> Do you agree?
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jean-Sebastien Delfino"
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Monday, September 10, 2007 3:43 PM
> Subject: Re: WS-Addressing mapping (was Re: What is
> Message.set/getCallableReference used for?)
>
>
>> Comments inline.
>>
>> [snip]
>> Simon Nash wrote:
>>
>>> I agree that we need a conclusion. I believe the detailed proposal
>>> below
>>> supports all the SCA semantics and I'd like to propose that we go
>>> with it
>>> for Tuscany 1.0.
>>>
>>> Any comments, questions, agreement, or disagreement?
>>>
>>> Simon
>>>
>>
>> I was initially thinking that the Callback EPR should be a separate
>> header outside of the To EPR but the code snippet that you put
>> together to simulate the SCA built-in callback (at the bottom of that
>> email) convinced me that I was wrong about it :)
>>
>> So I'm +1 with your proposal in [1]:
>>
>> Request message
>> <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>
>> <wsa:EndpointReference>
>> <wsa:Address>...URI of the service for the
>> callback...</wsa:Address>
>> <wsa:EndpointReference>
>> </tuscany:CallbackReference>
>> </wsa:ReferenceParameters>
>> </wsa:EndpointReference>
>> </wsa:To>
>>
>> Callback message:
>> <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>
>>
>> In plain text:
>> - CallbackID flows as a reference parameter of the "To" EPR
>> - ConversationID flows as a reference parameter of the "To" EPR
>> - CallbackReference is a well formed EPR and flows as a reference
>> parameter of the "To" EPR
>>
>> I think that we should propose this mapping to the OASIS SCA Bindings
>> workgroup. Different implementations of SCA should follow the same
>> mapping if we want them to interoperate over Web Services for example.
>>
>> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg22923.html
>>
>>
>> [snip]
>>
>>>
>>>>> 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
>>
>>
>> I'm not keen on doing that. I'd prefer to stick to your initial
>> proposal which seems cleaner to me, using the same standard form to
>> represent the CallbackReference EPR in the request message and the To
>> EPR in the callback message.
>>
>>>>>>
>>>>>>>
>>>>>>> @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);
>>>>>>> }
>>>>>>> }
>>
>>
>> I'd suggest a small variation of this pseudo-code, to be more in line
>> with the protocol that you proposed (the callbackID doesn't flow in
>> the CallbackReference in the request message):
>>
>> @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);
>> 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.setCallbackID(myReference.getCallbackID());
>> clientReference.getService().written(clientReference);
>> }
>> }
>>
>> --
>>
>> Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
--
Simon C Nash IBM Distinguished Engineer
Hursley Park, Winchester, UK nash@hursley.ibm.com
Tel. +44-1962-815156 Fax +44-1962-818999
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference used for?)
Posted by Raymond Feng <en...@gmail.com>.
+1 on the proposal. There is one more thing to add.
For the case that the callback object is not a ServiceReference, we don't
flow it in the Message, but we still need to correlate the callback to this
object so that the callback can be routed to the right callback object.
ConversationID alone is good enough, because
we can use different callback objects in the same conversation. I suggest
that we add a "CallbackObjectID" to reference parameter under the
CallbackReference. The CallbackObjectID can be the system hash code of the
callback object. The ConversationID + CallbackObjectID will be the key for
the correlation.
Do you agree?
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Monday, September 10, 2007 3:43 PM
Subject: Re: WS-Addressing mapping (was Re: What is
Message.set/getCallableReference used for?)
> Comments inline.
>
> [snip]
> Simon Nash wrote:
>> I agree that we need a conclusion. I believe the detailed proposal below
>> supports all the SCA semantics and I'd like to propose that we go with it
>> for Tuscany 1.0.
>>
>> Any comments, questions, agreement, or disagreement?
>>
>> Simon
>>
>
> I was initially thinking that the Callback EPR should be a separate header
> outside of the To EPR but the code snippet that you put together to
> simulate the SCA built-in callback (at the bottom of that email) convinced
> me that I was wrong about it :)
>
> So I'm +1 with your proposal in [1]:
>
> Request message
> <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>
> <wsa:EndpointReference>
> <wsa:Address>...URI of the service for the
> callback...</wsa:Address>
> <wsa:EndpointReference>
> </tuscany:CallbackReference>
> </wsa:ReferenceParameters>
> </wsa:EndpointReference>
> </wsa:To>
>
> Callback message:
> <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>
>
> In plain text:
> - CallbackID flows as a reference parameter of the "To" EPR
> - ConversationID flows as a reference parameter of the "To" EPR
> - CallbackReference is a well formed EPR and flows as a reference
> parameter of the "To" EPR
>
> I think that we should propose this mapping to the OASIS SCA Bindings
> workgroup. Different implementations of SCA should follow the same mapping
> if we want them to interoperate over Web Services for example.
>
> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg22923.html
>
>
> [snip]
>>
>>>> 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
>
> I'm not keen on doing that. I'd prefer to stick to your initial proposal
> which seems cleaner to me, using the same standard form to represent the
> CallbackReference EPR in the request message and the To EPR in the
> callback message.
>
>>>>>
>>>>>>
>>>>>> @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);
>>>>>> }
>>>>>> }
>
> I'd suggest a small variation of this pseudo-code, to be more in line with
> the protocol that you proposed (the callbackID doesn't flow in the
> CallbackReference in the request message):
>
> @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);
> 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.setCallbackID(myReference.getCallbackID());
> clientReference.getService().written(clientReference);
> }
> }
>
> --
>
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference
used for?)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Comments inline.
[snip]
Simon Nash wrote:
> I agree that we need a conclusion. I believe the detailed proposal below
> supports all the SCA semantics and I'd like to propose that we go with it
> for Tuscany 1.0.
>
> Any comments, questions, agreement, or disagreement?
>
> Simon
>
I was initially thinking that the Callback EPR should be a separate
header outside of the To EPR but the code snippet that you put together
to simulate the SCA built-in callback (at the bottom of that email)
convinced me that I was wrong about it :)
So I'm +1 with your proposal in [1]:
Request message
<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>
<wsa:EndpointReference>
<wsa:Address>...URI of the service for the
callback...</wsa:Address>
<wsa:EndpointReference>
</tuscany:CallbackReference>
</wsa:ReferenceParameters>
</wsa:EndpointReference>
</wsa:To>
Callback message:
<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>
In plain text:
- CallbackID flows as a reference parameter of the "To" EPR
- ConversationID flows as a reference parameter of the "To" EPR
- CallbackReference is a well formed EPR and flows as a reference
parameter of the "To" EPR
I think that we should propose this mapping to the OASIS SCA Bindings
workgroup. Different implementations of SCA should follow the same
mapping if we want them to interoperate over Web Services for example.
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg22923.html
[snip]
>
>>> 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
I'm not keen on doing that. I'd prefer to stick to your initial proposal
which seems cleaner to me, using the same standard form to represent the
CallbackReference EPR in the request message and the To EPR in the
callback message.
>>>>
>>>>>
>>>>> @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);
>>>>> }
>>>>> }
I'd suggest a small variation of this pseudo-code, to be more in line
with the protocol that you proposed (the callbackID doesn't flow in the
CallbackReference in the request message):
@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);
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.setCallbackID(myReference.getCallbackID());
clientReference.getService().written(clientReference);
}
}
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference
used for?)
Posted by Simon Nash <na...@hursley.ibm.com>.
I agree that we need a conclusion. I believe the detailed proposal below
supports all the SCA semantics and I'd like to propose that we go with it
for Tuscany 1.0.
Any comments, questions, agreement, or disagreement?
Simon
Raymond Feng wrote:
> 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" <na...@hursley.ibm.com>
> To: <tu...@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" <na...@hursley.ibm.com>
>>> To: <tu...@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"
>>>>>>> <js...@apache.org>
>>>>>>> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference used for?)
Posted by Raymond Feng <en...@gmail.com>.
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" <na...@hursley.ibm.com>
To: <tu...@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" <na...@hursley.ibm.com>
>> To: <tu...@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"
>>>>>> <js...@apache.org>
>>>>>> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference
used for?)
Posted by Simon Nash <na...@hursley.ibm.com>.
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" <na...@hursley.ibm.com>
> To: <tu...@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"
>>>>> <js...@apache.org>
>>>>> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference used for?)
Posted by Raymond Feng <en...@gmail.com>.
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" <na...@hursley.ibm.com>
To: <tu...@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"
>>>> <js...@apache.org>
>>>> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference
used for?)
Posted by Simon Nash <na...@hursley.ibm.com>.
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"
>>> <js...@apache.org>
>>> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference
used for?)
Posted by Simon Nash <na...@hursley.ibm.com>.
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"
> <js...@apache.org>
> To: <tu...@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"
>>>> <js...@apache.org>
>>>> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference used for?)
Posted by Raymond Feng <en...@gmail.com>.
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" <js...@apache.org>
To: <tu...@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"
>>> <js...@apache.org>
>>> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference
used for?)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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"
>> <js...@apache.org>
>> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference
used for?)
Posted by Simon Nash <na...@hursley.ibm.com>.
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"
> <js...@apache.org>
> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference used for?)
Posted by Raymond Feng <en...@gmail.com>.
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.
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?
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference
used for?)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
WS-Addressing mapping (was Re: What is Message.set/getCallableReference
used for?)
Posted by Simon Nash <na...@hursley.ibm.com>.
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"
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What is Message.set/getCallableReference used for?
Posted by Raymond Feng <en...@gmail.com>.
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" <js...@apache.org>
To: <tu...@ws.apache.org>
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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What is Message.set/getCallableReference used for?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What is Message.set/getCallableReference used for?
Posted by Simon Nash <na...@hursley.ibm.com>.
Comments inline. I removed some text to make the current discussion
easier to follow.
Simon
Raymond Feng wrote:
> Please see my comments inline.
>
(cut)
>>>
>>> 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().
>>
>> >
>> The caller's EPR would not be lost when we do a service invocation.
>> Before the invocation, it is available as the "To" EPR in the
>> ThreadMessageContext. The invocation puts a new ThreadMessageContext
>> on the stack with the "To" EPR for the service that's being invoked.
>> When the invocation returns, the previous ThreadMessageContext is
>> restored and we still have the caller's EPR in the "To" field of
>> the ThreadMessageContext for RequestContext.getServiceReference()
>> to use.
>
>
> By the caller's EPR, I meant the EPR for the reference on the caller
> component. There might be intents/policies associated with the reference
> and some interceptors will need to access all these information. The
> previous To cannot provide such data for the outbound reference.
>
Thanks for the explanation. I now understand what you mean by the
caller's EPR and I understand why it might be needed by the outbound
interceptors. However, I'm not sure if it's valid to consider this
as an endpoint as far as WS-Addressing is concerned. From the
WS-Addressing spec:
A Web service endpoint is a (referenceable) entity, processor, or
resource where Web service messages can be targeted.
All SCA services, including callback pseudo-services, definitely qualify
as endpoints in this sense. I'm not so sure about SCA references.
Perhaps they could be considered logical endpoints in the sense that
the reply from the forward call (HTTP POST response) comes back to the
client reference (in some sense).
This case is discussed in the WS-Addressing spec, which says that the
"anonymous" URI
http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
should be used in this case. So if we are going to represent the client
reference as the From endpoint in the WS-Addressing protocol, I think
we should send the anonymous URI as its wsa:Address and not make up some
new Tuscany-specific URI to put in this element.
> Let's assume this chain:
>
> --> Component1.Service1 ---> Component1.Reference1 --> Component2.Service1
>
> The previous To will be "Component1.Service1" and the new From should be
> "Component1.Reference1". In the application code of Component2.Service1,
> I assume the RequestContext.getServiceReference() will return the
> CallableReference representing Component1.Reference1.
>
This raises some big questions. I had expected getServiceReference()
to return a server-side reference (suitably configured with the
conversation ID, callback ID, and callback endpoint from the service
invocation) that could be used to make a local call across the
SCA binding to Component2.Service1. It would be similar to a
self-reference but with additional configuration I think this is how
it currently works. If getServiceReference() returns a CallableReference
representing Component1.Reference1, does this mean that any calls through
this CallableReference would use the client's reference binding?
For Web services, this would need all the reference binding model
information to be serialized and sent to the service side, which doesn't
seem very practical or desirable.
The same issue applies to serialization and deserialization of
ServiceReferences/CallableReferences. Does the entire client-side
reference information including its binding model get serialized and
deserialized? Whatever we do for this, we should do the same for
the above case.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What is Message.set/getCallableReference used for?
Posted by Raymond Feng <en...@gmail.com>.
Please see my comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Simon Nash" <na...@hursley.ibm.com>
To: <tu...@ws.apache.org>
Sent: Thursday, September 06, 2007 12:01 PM
Subject: Re: What is Message.set/getCallableReference used for?
> See inline.
>
> Simon
>
> Raymond Feng wrote:
>
>> More comments inline.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message ----- From: "Simon Nash" <na...@hursley.ibm.com>
>> To: <tu...@ws.apache.org>
>> Sent: Thursday, September 06, 2007 8:37 AM
>> Subject: Re: What is Message.set/getCallableReference used for?
>>
>>
>>> I'm OK with most of this, but I have some comments and concerns.
>>> See inline.
>>>
>>> Simon
>>>
>>> Raymond Feng wrote:
>>>
>>>> +1 on the proposal. I'll give a try to refactor the Message code.
>>>>
>>>> Thanks,
>>>> Raymond
>>>>
>>>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>>>> <js...@apache.org>
>>>> To: <tu...@ws.apache.org>
>>>> Sent: Wednesday, September 05, 2007 5:43 PM
>>>> Subject: Re: What is Message.set/getCallableReference used for?
>>>>
>>>>
>>>>> Simon Nash wrote:
>>>>>
>>>>>> See inline.
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>> Raymond Feng wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> There are a set of states associated with
>>>>>>> CallableReference/ServiceReference such as the callbackID,
>>>>>>> conversationID and callbackObject. We need to flow them in the
>>>>>>> Message so that the target service can have the correct
>>>>>>> correlations. At this moment, we have some of fields on the Message
>>>>>>> and I thought maybe it's better to follow the CallableReference as a
>>>>>>> whole. Another reason is that the RequestContext has a few methods
>>>>>>> to retrieve the ServiceReference, CallbackReference and Callback
>>>>>>> object.
>>>>>>>
>>>>>> This works on the reference binding side for marshalling onto the
>>>>>> wire
>>>>>> but not on the service binding side for unmarshalling from the wire
>>>>>> into the Message. See point 5 of my comments in TUSCANY-1591.
>>>>>>
>>>>>>> I agree with your comments that it's not very nice to have
>>>>>>> CallableReference directly on the Message as accessors. Moving
>>>>>>> forward, we probably need to define headers for the Message
>>>>>>> interface so that we can flow extra context data without poluting
>>>>>>> the Message interface.
>>>>>>
>>>>>>
>>>>>> >
>>>>>> Its makes sense to put everything that is Java-specific (currently
>>>>>> callback ID, conversation ID, conversation sequence and
>>>>>> callbackObject)
>>>>>> into a separate header. It would also be good to separate out the
>>>>>> processing of these things from the core invocation framework into
>>>>>> Java-specific interceptors.
>>>>>>
>>>>>>> There are already some use cases such as:
>>>>>>>
>>>>>>> * Pass some information from one interceptor to another one, for
>>>>>>> example, the DataBindingInterceptor can tell the PassByValueInvoker
>>>>>>> to skip the copy.
>>>>>>> * Carry binding-specific context in the Message, for example, SOAP
>>>>>>> headers for binding.ws or JMS properties for binding.jms.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Raymond
>>>>>>>
>>>>>>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>>>>>>> <js...@apache.org>
>>>>>>> To: <tu...@ws.apache.org>
>>>>>>> Sent: Monday, September 03, 2007 7:03 PM
>>>>>>> Subject: What is Message.set/getCallableReference used for?
>>>>>>>
>>>>>>>
>>>>>>>> Could somebody help me understand what
>>>>>>>> Message.set/getCallableReference is used for?
>>>>>>>>
>>>>>>>> If I comment it then some callback test cases start to fail, but I
>>>>>>>> don't really understand why we need to store a CallableReference in
>>>>>>>> the message, and its relationship with the from and to
>>>>>>>> EndpointReferences, which can already host callback endpoints.
>>>>>>>>
>>>>>>>> Also CallableReference is specific to Java (if I understand
>>>>>>>> correctly it takes a Java business interface) so if it's really
>>>>>>>> used and needed I'm not sure about how it's used for callbacks
>>>>>>>> typed by WSDL or other interface definition languages.
>>>>>>>>
>>>>>> There are a number of implementation classes for Java-specific APIs
>>>>>> that6 are currently in core/context:
>>>>>> CallableReferenceImpl
>>>>>> ComponentContextImpl
>>>>>> ConversationImpl
>>>>>> RequestContextImpl
>>>>>> ServiceReferenceImpl
>>>>>>
>>>>>> Having these classes in core causes problems when trying to fully
>>>>>> implement their spec semantics, because some of these semantics need
>>>>>> Java-specific code. The example that I am struggling with at the
>>>>>> moment is ServiceReferenceImpl.setCallback() which can take either
>>>>>> an instance of a Java implementation class or a service reference.
>>>>>> If the former is passed, ServiceReferenceImpl should check to make
>>>>>> sure it implements the callback interface and is Serializable (see
>>>>>> section 1.6.7.5 of the Java Annotations and APIs spec). This is not
>>>>>> possible without using Java-specific code, but I don't want to make
>>>>>> the core module dependent on the implementation-java-runtime module.
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> We're getting close to our 1.0 release and I think it's time to clean
>>>>> up some of the SPIs, remove what's not really indispensable, and try
>>>>> to avoid inconsistencies in last minute improvements and bug fixes.
>>>>>
>>>>> I've reviewed some of this code and here's what I think needs to
>>>>> happen:
>>>>>
>>>>> - Implementations of the org.osoa.sca Java API should move out of core
>>>>> to the implementation-java-runtime module, as suggested - if I
>>>>> understood correctly - by Simon as well
>>>>>
>>> +1
>>>
>>>>> - Message.callableReference should be removed, as it's carrying
>>>>> duplicate info
>>>>>
>>> +1
>>>
>>>>> - EndpointReference should reference parameters, similar to the "evil"
>>>>> WS-addressing, but simpler and more light weight, with just 3 fields:
>>>>> - callbackID
>>>>> - conversationID
>>>>> - callbackObject
>>>
>>> >>
>>> I'm not convinced about putting callbackObject into EndpointReference.
>>> The callbackObject can be one of the following:
>>> 1) a ServiceReference
>>> 2) a local Java instance that supports the callback interface
>>>
>>> For case 1), the "From" or "replyTo" field (see my comments below)
>>> on the wire would be used to pass the callbackObject's endpoint
>>> instead of passing the client's callback service endpoint. The callback
>>> would not be directed back to this client, so there is no reason to hold
>>> this ServiceReference in this client's EndpointReference.
>>>
>>> For case 2), this is not passed on the wire, but is retained by the
>>> caller (for stateful callbacks only) to be used for callback
>>> invocations.
>>> The caller needs to provide a means to correlate the callback object
>>> instance with the conversation ID for the stateful callback's
>>> conversation.
>>> I don't think the caller's EndpointReference needs to hold the
>>> callbackObject or play any part in this.
>>
>>
>> I agree with Simon's analysis. So there's no need to pass the
>> callbackObject in the EndpointReference for case 2.
>>
>>>
>>>>> 3 fields will be better than a big Map here as I'd hate to see a new
>>>>> Map created for each invocation :)
>>>>>
>>> +1
>>>
>>>>> - Message.correlationID should be removed as its semantics is not
>>>>> clear and it won't be necessary anymore if callbackID gets carried in
>>>>> the endpoint reference
>>>>>
>>> +1
>>>
>>>>> - 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().
> >
> The caller's EPR would not be lost when we do a service invocation.
> Before the invocation, it is available as the "To" EPR in the
> ThreadMessageContext. The invocation puts a new ThreadMessageContext
> on the stack with the "To" EPR for the service that's being invoked.
> When the invocation returns, the previous ThreadMessageContext is
> restored and we still have the caller's EPR in the "To" field of
> the ThreadMessageContext for RequestContext.getServiceReference()
> to use.
By the caller's EPR, I meant the EPR for the reference on the caller
component. There might be intents/policies associated with the reference and
some interceptors will need to access all these information. The previous To
cannot provide such data for the outbound reference.
Let's assume this chain:
--> Component1.Service1 ---> Component1.Reference1 --> Component2.Service1
The previous To will be "Component1.Service1" and the new From should be
"Component1.Reference1". In the application code of Component2.Service1, I
assume the RequestContext.getServiceReference() will return the
CallableReference representing Component1.Reference1.
>
>> I sgguest that we keep the callback
>> endpoint as a reference parameter in the caller's EPR which should be the
>> From.
> >
> By the caller's EPR, do you mean the contexr "To" EPR that represents
> the service on which the client was invoked? I see no use case in which
> it would be useful to pass this EPR as "From" information on a new
> invocation. The only client endpoint that the called service needs
> to know about is the callback endpoint for any callbacks that it
> may invoke.
>
>> 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.
>>
> This works, but it seems to involve putting extra information in the
> caller endpoint as well as passing "From" information on the wire
> that would never be used by the called service.
>
>>>>> Hopefully this won't generate long debates. If there's too many
>>>>> questions or if what I'm proposing here is not clear, I'll post some
>>>>> code implementing this. It'll be more concrete this way.
>>>>>
>>>>> Thoughts?
>>>>>
>>> You didn't mention conversationSequence. I'm not convinced that we
>>> need this in the Message. Every invocation of a method of a
>>> conversational interface is either starting or continuing a conversation
>>> (the service knows which), except for methods marked @EndsConversation
>>> (again, the service knows which). I don't see a use case that requires
>>> a conversationSequence to flow in the Message.
>>>
>>
>> +1 to remove conversationSequence. This information is already available
>> on the Operation which is part of the Message.
>>
>>> You didn't mention messageId. Is there any reason to have this in
>>> the Message? It's not being used currently.
>>>
>>
>> messageID and correlationID are typical patterns for asynchronous
>> messaging. I'm OK to either deprecate them or remove them.
>>
>>> Simon
>>>
>>>
>>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What is Message.set/getCallableReference used for?
Posted by Simon Nash <na...@hursley.ibm.com>.
See inline.
Simon
Raymond Feng wrote:
> More comments inline.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Simon Nash" <na...@hursley.ibm.com>
> To: <tu...@ws.apache.org>
> Sent: Thursday, September 06, 2007 8:37 AM
> Subject: Re: What is Message.set/getCallableReference used for?
>
>
>> I'm OK with most of this, but I have some comments and concerns.
>> See inline.
>>
>> Simon
>>
>> Raymond Feng wrote:
>>
>>> +1 on the proposal. I'll give a try to refactor the Message code.
>>>
>>> Thanks,
>>> Raymond
>>>
>>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>>> <js...@apache.org>
>>> To: <tu...@ws.apache.org>
>>> Sent: Wednesday, September 05, 2007 5:43 PM
>>> Subject: Re: What is Message.set/getCallableReference used for?
>>>
>>>
>>>> Simon Nash wrote:
>>>>
>>>>> See inline.
>>>>>
>>>>> Simon
>>>>>
>>>>> Raymond Feng wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> There are a set of states associated with
>>>>>> CallableReference/ServiceReference such as the callbackID,
>>>>>> conversationID and callbackObject. We need to flow them in the
>>>>>> Message so that the target service can have the correct
>>>>>> correlations. At this moment, we have some of fields on the
>>>>>> Message and I thought maybe it's better to follow the
>>>>>> CallableReference as a whole. Another reason is that the
>>>>>> RequestContext has a few methods to retrieve the ServiceReference,
>>>>>> CallbackReference and Callback object.
>>>>>>
>>>>> This works on the reference binding side for marshalling onto the wire
>>>>> but not on the service binding side for unmarshalling from the wire
>>>>> into the Message. See point 5 of my comments in TUSCANY-1591.
>>>>>
>>>>>> I agree with your comments that it's not very nice to have
>>>>>> CallableReference directly on the Message as accessors. Moving
>>>>>> forward, we probably need to define headers for the Message
>>>>>> interface so that we can flow extra context data without poluting
>>>>>> the Message interface.
>>>>>
>>>>>
>>>>> >
>>>>> Its makes sense to put everything that is Java-specific (currently
>>>>> callback ID, conversation ID, conversation sequence and
>>>>> callbackObject)
>>>>> into a separate header. It would also be good to separate out the
>>>>> processing of these things from the core invocation framework into
>>>>> Java-specific interceptors.
>>>>>
>>>>>> There are already some use cases such as:
>>>>>>
>>>>>> * Pass some information from one interceptor to another one, for
>>>>>> example, the DataBindingInterceptor can tell the
>>>>>> PassByValueInvoker to skip the copy.
>>>>>> * Carry binding-specific context in the Message, for example, SOAP
>>>>>> headers for binding.ws or JMS properties for binding.jms.
>>>>>>
>>>>>> Thanks,
>>>>>> Raymond
>>>>>>
>>>>>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>>>>>> <js...@apache.org>
>>>>>> To: <tu...@ws.apache.org>
>>>>>> Sent: Monday, September 03, 2007 7:03 PM
>>>>>> Subject: What is Message.set/getCallableReference used for?
>>>>>>
>>>>>>
>>>>>>> Could somebody help me understand what
>>>>>>> Message.set/getCallableReference is used for?
>>>>>>>
>>>>>>> If I comment it then some callback test cases start to fail, but
>>>>>>> I don't really understand why we need to store a
>>>>>>> CallableReference in the message, and its relationship with the
>>>>>>> from and to EndpointReferences, which can already host callback
>>>>>>> endpoints.
>>>>>>>
>>>>>>> Also CallableReference is specific to Java (if I understand
>>>>>>> correctly it takes a Java business interface) so if it's really
>>>>>>> used and needed I'm not sure about how it's used for callbacks
>>>>>>> typed by WSDL or other interface definition languages.
>>>>>>>
>>>>> There are a number of implementation classes for Java-specific APIs
>>>>> that6 are currently in core/context:
>>>>> CallableReferenceImpl
>>>>> ComponentContextImpl
>>>>> ConversationImpl
>>>>> RequestContextImpl
>>>>> ServiceReferenceImpl
>>>>>
>>>>> Having these classes in core causes problems when trying to fully
>>>>> implement their spec semantics, because some of these semantics need
>>>>> Java-specific code. The example that I am struggling with at the
>>>>> moment is ServiceReferenceImpl.setCallback() which can take either
>>>>> an instance of a Java implementation class or a service reference.
>>>>> If the former is passed, ServiceReferenceImpl should check to make
>>>>> sure it implements the callback interface and is Serializable (see
>>>>> section 1.6.7.5 of the Java Annotations and APIs spec). This is not
>>>>> possible without using Java-specific code, but I don't want to make
>>>>> the core module dependent on the implementation-java-runtime module.
>>>>>
>>>>> Simon
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>
>>>>>
>>>>
>>>> We're getting close to our 1.0 release and I think it's time to
>>>> clean up some of the SPIs, remove what's not really indispensable,
>>>> and try to avoid inconsistencies in last minute improvements and bug
>>>> fixes.
>>>>
>>>> I've reviewed some of this code and here's what I think needs to
>>>> happen:
>>>>
>>>> - Implementations of the org.osoa.sca Java API should move out of
>>>> core to the implementation-java-runtime module, as suggested - if I
>>>> understood correctly - by Simon as well
>>>>
>> +1
>>
>>>> - Message.callableReference should be removed, as it's carrying
>>>> duplicate info
>>>>
>> +1
>>
>>>> - EndpointReference should reference parameters, similar to the
>>>> "evil" WS-addressing, but simpler and more light weight, with just 3
>>>> fields:
>>>> - callbackID
>>>> - conversationID
>>>> - callbackObject
>>
>> >>
>> I'm not convinced about putting callbackObject into EndpointReference.
>> The callbackObject can be one of the following:
>> 1) a ServiceReference
>> 2) a local Java instance that supports the callback interface
>>
>> For case 1), the "From" or "replyTo" field (see my comments below)
>> on the wire would be used to pass the callbackObject's endpoint
>> instead of passing the client's callback service endpoint. The callback
>> would not be directed back to this client, so there is no reason to hold
>> this ServiceReference in this client's EndpointReference.
>>
>> For case 2), this is not passed on the wire, but is retained by the
>> caller (for stateful callbacks only) to be used for callback invocations.
>> The caller needs to provide a means to correlate the callback object
>> instance with the conversation ID for the stateful callback's
>> conversation.
>> I don't think the caller's EndpointReference needs to hold the
>> callbackObject or play any part in this.
>
>
> I agree with Simon's analysis. So there's no need to pass the
> callbackObject in the EndpointReference for case 2.
>
>>
>>>> 3 fields will be better than a big Map here as I'd hate to see a new
>>>> Map created for each invocation :)
>>>>
>> +1
>>
>>>> - Message.correlationID should be removed as its semantics is not
>>>> clear and it won't be necessary anymore if callbackID gets carried
>>>> in the endpoint reference
>>>>
>> +1
>>
>>>> - 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().
>
The caller's EPR would not be lost when we do a service invocation.
Before the invocation, it is available as the "To" EPR in the
ThreadMessageContext. The invocation puts a new ThreadMessageContext
on the stack with the "To" EPR for the service that's being invoked.
When the invocation returns, the previous ThreadMessageContext is
restored and we still have the caller's EPR in the "To" field of
the ThreadMessageContext for RequestContext.getServiceReference()
to use.
> I sgguest that we keep the
> callback endpoint as a reference parameter in the caller's EPR which
> should be the From.
>
By the caller's EPR, do you mean the contexr "To" EPR that represents
the service on which the client was invoked? I see no use case in which
it would be useful to pass this EPR as "From" information on a new
invocation. The only client endpoint that the called service needs
to know about is the callback endpoint for any callbacks that it
may invoke.
> 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.
>
This works, but it seems to involve putting extra information in the
caller endpoint as well as passing "From" information on the wire
that would never be used by the called service.
>>>> Hopefully this won't generate long debates. If there's too many
>>>> questions or if what I'm proposing here is not clear, I'll post some
>>>> code implementing this. It'll be more concrete this way.
>>>>
>>>> Thoughts?
>>>>
>> You didn't mention conversationSequence. I'm not convinced that we
>> need this in the Message. Every invocation of a method of a
>> conversational interface is either starting or continuing a conversation
>> (the service knows which), except for methods marked @EndsConversation
>> (again, the service knows which). I don't see a use case that requires
>> a conversationSequence to flow in the Message.
>>
>
> +1 to remove conversationSequence. This information is already available
> on the Operation which is part of the Message.
>
>> You didn't mention messageId. Is there any reason to have this in
>> the Message? It's not being used currently.
>>
>
> messageID and correlationID are typical patterns for asynchronous
> messaging. I'm OK to either deprecate them or remove them.
>
>> Simon
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What is Message.set/getCallableReference used for?
Posted by Raymond Feng <en...@gmail.com>.
More comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Simon Nash" <na...@hursley.ibm.com>
To: <tu...@ws.apache.org>
Sent: Thursday, September 06, 2007 8:37 AM
Subject: Re: What is Message.set/getCallableReference used for?
> I'm OK with most of this, but I have some comments and concerns.
> See inline.
>
> Simon
>
> Raymond Feng wrote:
>
>> +1 on the proposal. I'll give a try to refactor the Message code.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>> <js...@apache.org>
>> To: <tu...@ws.apache.org>
>> Sent: Wednesday, September 05, 2007 5:43 PM
>> Subject: Re: What is Message.set/getCallableReference used for?
>>
>>
>>> Simon Nash wrote:
>>>
>>>> See inline.
>>>>
>>>> Simon
>>>>
>>>> Raymond Feng wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> There are a set of states associated with
>>>>> CallableReference/ServiceReference such as the callbackID,
>>>>> conversationID and callbackObject. We need to flow them in the Message
>>>>> so that the target service can have the correct correlations. At this
>>>>> moment, we have some of fields on the Message and I thought maybe it's
>>>>> better to follow the CallableReference as a whole. Another reason is
>>>>> that the RequestContext has a few methods to retrieve the
>>>>> ServiceReference, CallbackReference and Callback object.
>>>>>
>>>> This works on the reference binding side for marshalling onto the wire
>>>> but not on the service binding side for unmarshalling from the wire
>>>> into the Message. See point 5 of my comments in TUSCANY-1591.
>>>>
>>>>> I agree with your comments that it's not very nice to have
>>>>> CallableReference directly on the Message as accessors. Moving
>>>>> forward, we probably need to define headers for the Message interface
>>>>> so that we can flow extra context data without poluting the Message
>>>>> interface.
>>>>
>>>> >
>>>> Its makes sense to put everything that is Java-specific (currently
>>>> callback ID, conversation ID, conversation sequence and callbackObject)
>>>> into a separate header. It would also be good to separate out the
>>>> processing of these things from the core invocation framework into
>>>> Java-specific interceptors.
>>>>
>>>>> There are already some use cases such as:
>>>>>
>>>>> * Pass some information from one interceptor to another one, for
>>>>> example, the DataBindingInterceptor can tell the PassByValueInvoker to
>>>>> skip the copy.
>>>>> * Carry binding-specific context in the Message, for example, SOAP
>>>>> headers for binding.ws or JMS properties for binding.jms.
>>>>>
>>>>> Thanks,
>>>>> Raymond
>>>>>
>>>>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>>>>> <js...@apache.org>
>>>>> To: <tu...@ws.apache.org>
>>>>> Sent: Monday, September 03, 2007 7:03 PM
>>>>> Subject: What is Message.set/getCallableReference used for?
>>>>>
>>>>>
>>>>>> Could somebody help me understand what
>>>>>> Message.set/getCallableReference is used for?
>>>>>>
>>>>>> If I comment it then some callback test cases start to fail, but I
>>>>>> don't really understand why we need to store a CallableReference in
>>>>>> the message, and its relationship with the from and to
>>>>>> EndpointReferences, which can already host callback endpoints.
>>>>>>
>>>>>> Also CallableReference is specific to Java (if I understand correctly
>>>>>> it takes a Java business interface) so if it's really used and needed
>>>>>> I'm not sure about how it's used for callbacks typed by WSDL or other
>>>>>> interface definition languages.
>>>>>>
>>>> There are a number of implementation classes for Java-specific APIs
>>>> that6 are currently in core/context:
>>>> CallableReferenceImpl
>>>> ComponentContextImpl
>>>> ConversationImpl
>>>> RequestContextImpl
>>>> ServiceReferenceImpl
>>>>
>>>> Having these classes in core causes problems when trying to fully
>>>> implement their spec semantics, because some of these semantics need
>>>> Java-specific code. The example that I am struggling with at the
>>>> moment is ServiceReferenceImpl.setCallback() which can take either
>>>> an instance of a Java implementation class or a service reference.
>>>> If the former is passed, ServiceReferenceImpl should check to make
>>>> sure it implements the callback interface and is Serializable (see
>>>> section 1.6.7.5 of the Java Annotations and APIs spec). This is not
>>>> possible without using Java-specific code, but I don't want to make
>>>> the core module dependent on the implementation-java-runtime module.
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>> We're getting close to our 1.0 release and I think it's time to clean up
>>> some of the SPIs, remove what's not really indispensable, and try to
>>> avoid inconsistencies in last minute improvements and bug fixes.
>>>
>>> I've reviewed some of this code and here's what I think needs to happen:
>>>
>>> - Implementations of the org.osoa.sca Java API should move out of core
>>> to the implementation-java-runtime module, as suggested - if I
>>> understood correctly - by Simon as well
>>>
> +1
>
>>> - Message.callableReference should be removed, as it's carrying
>>> duplicate info
>>>
> +1
>
>>> - EndpointReference should reference parameters, similar to the "evil"
>>> WS-addressing, but simpler and more light weight, with just 3 fields:
>>> - callbackID
>>> - conversationID
>>> - callbackObject
> >>
> I'm not convinced about putting callbackObject into EndpointReference.
> The callbackObject can be one of the following:
> 1) a ServiceReference
> 2) a local Java instance that supports the callback interface
>
> For case 1), the "From" or "replyTo" field (see my comments below)
> on the wire would be used to pass the callbackObject's endpoint
> instead of passing the client's callback service endpoint. The callback
> would not be directed back to this client, so there is no reason to hold
> this ServiceReference in this client's EndpointReference.
>
> For case 2), this is not passed on the wire, but is retained by the
> caller (for stateful callbacks only) to be used for callback invocations.
> The caller needs to provide a means to correlate the callback object
> instance with the conversation ID for the stateful callback's
> conversation.
> I don't think the caller's EndpointReference needs to hold the
> callbackObject or play any part in this.
I agree with Simon's analysis. So there's no need to pass the callbackObject
in the EndpointReference for case 2.
>
>>> 3 fields will be better than a big Map here as I'd hate to see a new Map
>>> created for each invocation :)
>>>
> +1
>
>>> - Message.correlationID should be removed as its semantics is not clear
>>> and it won't be necessary anymore if callbackID gets carried in the
>>> endpoint reference
>>>
> +1
>
>>> - 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.
>>> Hopefully this won't generate long debates. If there's too many
>>> questions or if what I'm proposing here is not clear, I'll post some
>>> code implementing this. It'll be more concrete this way.
>>>
>>> Thoughts?
>>>
> You didn't mention conversationSequence. I'm not convinced that we
> need this in the Message. Every invocation of a method of a
> conversational interface is either starting or continuing a conversation
> (the service knows which), except for methods marked @EndsConversation
> (again, the service knows which). I don't see a use case that requires
> a conversationSequence to flow in the Message.
>
+1 to remove conversationSequence. This information is already available on
the Operation which is part of the Message.
> You didn't mention messageId. Is there any reason to have this in
> the Message? It's not being used currently.
>
messageID and correlationID are typical patterns for asynchronous messaging.
I'm OK to either deprecate them or remove them.
> Simon
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What is Message.set/getCallableReference used for?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Simon Nash wrote:
> I'm OK with most of this, but I have some comments and concerns.
> See inline.
>
> Simon
>
>
> I'm not convinced about putting callbackObject into EndpointReference.
> The callbackObject can be one of the following:
> 1) a ServiceReference
> 2) a local Java instance that supports the callback interface
>
> For case 1), the "From" or "replyTo" field (see my comments below)
> on the wire would be used to pass the callbackObject's endpoint
> instead of passing the client's callback service endpoint. The callback
> would not be directed back to this client, so there is no reason to hold
> this ServiceReference in this client's EndpointReference.
>
> For case 2), this is not passed on the wire, but is retained by the
> caller (for stateful callbacks only) to be used for callback invocations.
> The caller needs to provide a means to correlate the callback object
> instance with the conversation ID for the stateful callback's
> conversation.
> I don't think the caller's EndpointReference needs to hold the
> callbackObject or play any part in this.
+1
>
>>> - 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.
>
Your reading of the WS-addressing spec if correct, +1 from me to use
"from" instead of "replyTo" to carry the endpoint reference of the
callback service.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What is Message.set/getCallableReference used for?
Posted by Simon Nash <na...@hursley.ibm.com>.
I'm OK with most of this, but I have some comments and concerns.
See inline.
Simon
Raymond Feng wrote:
> +1 on the proposal. I'll give a try to refactor the Message code.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jean-Sebastien Delfino"
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Wednesday, September 05, 2007 5:43 PM
> Subject: Re: What is Message.set/getCallableReference used for?
>
>
>> Simon Nash wrote:
>>
>>> See inline.
>>>
>>> Simon
>>>
>>> Raymond Feng wrote:
>>>
>>>> Hi,
>>>>
>>>> There are a set of states associated with
>>>> CallableReference/ServiceReference such as the callbackID,
>>>> conversationID and callbackObject. We need to flow them in the
>>>> Message so that the target service can have the correct
>>>> correlations. At this moment, we have some of fields on the Message
>>>> and I thought maybe it's better to follow the CallableReference as a
>>>> whole. Another reason is that the RequestContext has a few methods
>>>> to retrieve the ServiceReference, CallbackReference and Callback
>>>> object.
>>>>
>>> This works on the reference binding side for marshalling onto the wire
>>> but not on the service binding side for unmarshalling from the wire
>>> into the Message. See point 5 of my comments in TUSCANY-1591.
>>>
>>>> I agree with your comments that it's not very nice to have
>>>> CallableReference directly on the Message as accessors. Moving
>>>> forward, we probably need to define headers for the Message
>>>> interface so that we can flow extra context data without poluting
>>>> the Message interface.
>>>
>>> >
>>> Its makes sense to put everything that is Java-specific (currently
>>> callback ID, conversation ID, conversation sequence and callbackObject)
>>> into a separate header. It would also be good to separate out the
>>> processing of these things from the core invocation framework into
>>> Java-specific interceptors.
>>>
>>>> There are already some use cases such as:
>>>>
>>>> * Pass some information from one interceptor to another one, for
>>>> example, the DataBindingInterceptor can tell the PassByValueInvoker
>>>> to skip the copy.
>>>> * Carry binding-specific context in the Message, for example, SOAP
>>>> headers for binding.ws or JMS properties for binding.jms.
>>>>
>>>> Thanks,
>>>> Raymond
>>>>
>>>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>>>> <js...@apache.org>
>>>> To: <tu...@ws.apache.org>
>>>> Sent: Monday, September 03, 2007 7:03 PM
>>>> Subject: What is Message.set/getCallableReference used for?
>>>>
>>>>
>>>>> Could somebody help me understand what
>>>>> Message.set/getCallableReference is used for?
>>>>>
>>>>> If I comment it then some callback test cases start to fail, but I
>>>>> don't really understand why we need to store a CallableReference in
>>>>> the message, and its relationship with the from and to
>>>>> EndpointReferences, which can already host callback endpoints.
>>>>>
>>>>> Also CallableReference is specific to Java (if I understand
>>>>> correctly it takes a Java business interface) so if it's really
>>>>> used and needed I'm not sure about how it's used for callbacks
>>>>> typed by WSDL or other interface definition languages.
>>>>>
>>> There are a number of implementation classes for Java-specific APIs
>>> that6 are currently in core/context:
>>> CallableReferenceImpl
>>> ComponentContextImpl
>>> ConversationImpl
>>> RequestContextImpl
>>> ServiceReferenceImpl
>>>
>>> Having these classes in core causes problems when trying to fully
>>> implement their spec semantics, because some of these semantics need
>>> Java-specific code. The example that I am struggling with at the
>>> moment is ServiceReferenceImpl.setCallback() which can take either
>>> an instance of a Java implementation class or a service reference.
>>> If the former is passed, ServiceReferenceImpl should check to make
>>> sure it implements the callback interface and is Serializable (see
>>> section 1.6.7.5 of the Java Annotations and APIs spec). This is not
>>> possible without using Java-specific code, but I don't want to make
>>> the core module dependent on the implementation-java-runtime module.
>>>
>>> Simon
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>> We're getting close to our 1.0 release and I think it's time to clean
>> up some of the SPIs, remove what's not really indispensable, and try
>> to avoid inconsistencies in last minute improvements and bug fixes.
>>
>> I've reviewed some of this code and here's what I think needs to happen:
>>
>> - Implementations of the org.osoa.sca Java API should move out of core
>> to the implementation-java-runtime module, as suggested - if I
>> understood correctly - by Simon as well
>>
+1
>> - Message.callableReference should be removed, as it's carrying
>> duplicate info
>>
+1
>> - EndpointReference should reference parameters, similar to the "evil"
>> WS-addressing, but simpler and more light weight, with just 3 fields:
>> - callbackID
>> - conversationID
>> - callbackObject
>>
I'm not convinced about putting callbackObject into EndpointReference.
The callbackObject can be one of the following:
1) a ServiceReference
2) a local Java instance that supports the callback interface
For case 1), the "From" or "replyTo" field (see my comments below)
on the wire would be used to pass the callbackObject's endpoint
instead of passing the client's callback service endpoint. The callback
would not be directed back to this client, so there is no reason to hold
this ServiceReference in this client's EndpointReference.
For case 2), this is not passed on the wire, but is retained by the
caller (for stateful callbacks only) to be used for callback invocations.
The caller needs to provide a means to correlate the callback object
instance with the conversation ID for the stateful callback's conversation.
I don't think the caller's EndpointReference needs to hold the
callbackObject or play any part in this.
>> 3 fields will be better than a big Map here as I'd hate to see a new
>> Map created for each invocation :)
>>
+1
>> - Message.correlationID should be removed as its semantics is not
>> clear and it won't be necessary anymore if callbackID gets carried in
>> the endpoint reference
>>
+1
>> - 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.
>> Hopefully this won't generate long debates. If there's too many
>> questions or if what I'm proposing here is not clear, I'll post some
>> code implementing this. It'll be more concrete this way.
>>
>> Thoughts?
>>
You didn't mention conversationSequence. I'm not convinced that we
need this in the Message. Every invocation of a method of a
conversational interface is either starting or continuing a conversation
(the service knows which), except for methods marked @EndsConversation
(again, the service knows which). I don't see a use case that requires
a conversationSequence to flow in the Message.
You didn't mention messageId. Is there any reason to have this in
the Message? It's not being used currently.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What is Message.set/getCallableReference used for?
Posted by Raymond Feng <en...@gmail.com>.
+1 on the proposal. I'll give a try to refactor the Message code.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Wednesday, September 05, 2007 5:43 PM
Subject: Re: What is Message.set/getCallableReference used for?
> Simon Nash wrote:
>> See inline.
>>
>> Simon
>>
>> Raymond Feng wrote:
>>> Hi,
>>>
>>> There are a set of states associated with
>>> CallableReference/ServiceReference such as the callbackID,
>>> conversationID and callbackObject. We need to flow them in the
>>> Message so that the target service can have the correct correlations.
>>> At this moment, we have some of fields on the Message and I thought
>>> maybe it's better to follow the CallableReference as a whole. Another
>>> reason is that the RequestContext has a few methods to retrieve the
>>> ServiceReference, CallbackReference and Callback object.
>>>
>> This works on the reference binding side for marshalling onto the wire
>> but not on the service binding side for unmarshalling from the wire
>> into the Message. See point 5 of my comments in TUSCANY-1591.
>>
>>> I agree with your comments that it's not very nice to have
>>> CallableReference directly on the Message as accessors. Moving
>>> forward, we probably need to define headers for the Message interface
>>> so that we can flow extra context data without poluting the Message
>>> interface.
>> >
>> Its makes sense to put everything that is Java-specific (currently
>> callback ID, conversation ID, conversation sequence and callbackObject)
>> into a separate header. It would also be good to separate out the
>> processing of these things from the core invocation framework into
>> Java-specific interceptors.
>>
>>> There are already some use cases such as:
>>>
>>> * Pass some information from one interceptor to another one, for
>>> example, the DataBindingInterceptor can tell the PassByValueInvoker
>>> to skip the copy.
>>> * Carry binding-specific context in the Message, for example, SOAP
>>> headers for binding.ws or JMS properties for binding.jms.
>>>
>>> Thanks,
>>> Raymond
>>>
>>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>>> <js...@apache.org>
>>> To: <tu...@ws.apache.org>
>>> Sent: Monday, September 03, 2007 7:03 PM
>>> Subject: What is Message.set/getCallableReference used for?
>>>
>>>
>>>> Could somebody help me understand what
>>>> Message.set/getCallableReference is used for?
>>>>
>>>> If I comment it then some callback test cases start to fail, but I
>>>> don't really understand why we need to store a CallableReference in
>>>> the message, and its relationship with the from and to
>>>> EndpointReferences, which can already host callback endpoints.
>>>>
>>>> Also CallableReference is specific to Java (if I understand
>>>> correctly it takes a Java business interface) so if it's really used
>>>> and needed I'm not sure about how it's used for callbacks typed by
>>>> WSDL or other interface definition languages.
>>>>
>> There are a number of implementation classes for Java-specific APIs
>> that6 are currently in core/context:
>> CallableReferenceImpl
>> ComponentContextImpl
>> ConversationImpl
>> RequestContextImpl
>> ServiceReferenceImpl
>>
>> Having these classes in core causes problems when trying to fully
>> implement their spec semantics, because some of these semantics need
>> Java-specific code. The example that I am struggling with at the
>> moment is ServiceReferenceImpl.setCallback() which can take either
>> an instance of a Java implementation class or a service reference.
>> If the former is passed, ServiceReferenceImpl should check to make
>> sure it implements the callback interface and is Serializable (see
>> section 1.6.7.5 of the Java Annotations and APIs spec). This is not
>> possible without using Java-specific code, but I don't want to make
>> the core module dependent on the implementation-java-runtime module.
>>
>> Simon
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> We're getting close to our 1.0 release and I think it's time to clean up
> some of the SPIs, remove what's not really indispensable, and try to
> avoid inconsistencies in last minute improvements and bug fixes.
>
> I've reviewed some of this code and here's what I think needs to happen:
>
> - Implementations of the org.osoa.sca Java API should move out of core
> to the implementation-java-runtime module, as suggested - if I
> understood correctly - by Simon as well
>
> - Message.callableReference should be removed, as it's carrying
> duplicate info
>
> - EndpointReference should reference parameters, similar to the "evil"
> WS-addressing, but simpler and more light weight, with just 3 fields:
> - callbackID
> - conversationID
> - callbackObject
> 3 fields will be better than a big Map here as I'd hate to see a new Map
> created for each invocation :)
>
> - Message.correlationID should be removed as its semantics is not clear
> and it won't be necessary anymore if callbackID gets carried in the
> endpoint reference
>
> - 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.
>
> Hopefully this won't generate long debates. If there's too many
> questions or if what I'm proposing here is not clear, I'll post some
> code implementing this. It'll be more concrete this way.
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What is Message.set/getCallableReference used for?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
> See inline.
>
> Simon
>
> Raymond Feng wrote:
>> Hi,
>>
>> There are a set of states associated with
>> CallableReference/ServiceReference such as the callbackID,
>> conversationID and callbackObject. We need to flow them in the
>> Message so that the target service can have the correct correlations.
>> At this moment, we have some of fields on the Message and I thought
>> maybe it's better to follow the CallableReference as a whole. Another
>> reason is that the RequestContext has a few methods to retrieve the
>> ServiceReference, CallbackReference and Callback object.
>>
> This works on the reference binding side for marshalling onto the wire
> but not on the service binding side for unmarshalling from the wire
> into the Message. See point 5 of my comments in TUSCANY-1591.
>
>> I agree with your comments that it's not very nice to have
>> CallableReference directly on the Message as accessors. Moving
>> forward, we probably need to define headers for the Message interface
>> so that we can flow extra context data without poluting the Message
>> interface.
> >
> Its makes sense to put everything that is Java-specific (currently
> callback ID, conversation ID, conversation sequence and callbackObject)
> into a separate header. It would also be good to separate out the
> processing of these things from the core invocation framework into
> Java-specific interceptors.
>
>> There are already some use cases such as:
>>
>> * Pass some information from one interceptor to another one, for
>> example, the DataBindingInterceptor can tell the PassByValueInvoker
>> to skip the copy.
>> * Carry binding-specific context in the Message, for example, SOAP
>> headers for binding.ws or JMS properties for binding.jms.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>> <js...@apache.org>
>> To: <tu...@ws.apache.org>
>> Sent: Monday, September 03, 2007 7:03 PM
>> Subject: What is Message.set/getCallableReference used for?
>>
>>
>>> Could somebody help me understand what
>>> Message.set/getCallableReference is used for?
>>>
>>> If I comment it then some callback test cases start to fail, but I
>>> don't really understand why we need to store a CallableReference in
>>> the message, and its relationship with the from and to
>>> EndpointReferences, which can already host callback endpoints.
>>>
>>> Also CallableReference is specific to Java (if I understand
>>> correctly it takes a Java business interface) so if it's really used
>>> and needed I'm not sure about how it's used for callbacks typed by
>>> WSDL or other interface definition languages.
>>>
> There are a number of implementation classes for Java-specific APIs
> that6 are currently in core/context:
> CallableReferenceImpl
> ComponentContextImpl
> ConversationImpl
> RequestContextImpl
> ServiceReferenceImpl
>
> Having these classes in core causes problems when trying to fully
> implement their spec semantics, because some of these semantics need
> Java-specific code. The example that I am struggling with at the
> moment is ServiceReferenceImpl.setCallback() which can take either
> an instance of a Java implementation class or a service reference.
> If the former is passed, ServiceReferenceImpl should check to make
> sure it implements the callback interface and is Serializable (see
> section 1.6.7.5 of the Java Annotations and APIs spec). This is not
> possible without using Java-specific code, but I don't want to make
> the core module dependent on the implementation-java-runtime module.
>
> Simon
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
We're getting close to our 1.0 release and I think it's time to clean up
some of the SPIs, remove what's not really indispensable, and try to
avoid inconsistencies in last minute improvements and bug fixes.
I've reviewed some of this code and here's what I think needs to happen:
- Implementations of the org.osoa.sca Java API should move out of core
to the implementation-java-runtime module, as suggested - if I
understood correctly - by Simon as well
- Message.callableReference should be removed, as it's carrying
duplicate info
- EndpointReference should reference parameters, similar to the "evil"
WS-addressing, but simpler and more light weight, with just 3 fields:
- callbackID
- conversationID
- callbackObject
3 fields will be better than a big Map here as I'd hate to see a new Map
created for each invocation :)
- Message.correlationID should be removed as its semantics is not clear
and it won't be necessary anymore if callbackID gets carried in the
endpoint reference
- 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.
Hopefully this won't generate long debates. If there's too many
questions or if what I'm proposing here is not clear, I'll post some
code implementing this. It'll be more concrete this way.
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What is Message.set/getCallableReference used for?
Posted by Simon Nash <na...@hursley.ibm.com>.
See inline.
Simon
Raymond Feng wrote:
> Hi,
>
> There are a set of states associated with
> CallableReference/ServiceReference such as the callbackID,
> conversationID and callbackObject. We need to flow them in the Message
> so that the target service can have the correct correlations. At this
> moment, we have some of fields on the Message and I thought maybe it's
> better to follow the CallableReference as a whole. Another reason is
> that the RequestContext has a few methods to retrieve the
> ServiceReference, CallbackReference and Callback object.
>
This works on the reference binding side for marshalling onto the wire
but not on the service binding side for unmarshalling from the wire
into the Message. See point 5 of my comments in TUSCANY-1591.
> I agree with your comments that it's not very nice to have
> CallableReference directly on the Message as accessors. Moving forward,
> we probably need to define headers for the Message interface so that we
> can flow extra context data without poluting the Message interface.
>
Its makes sense to put everything that is Java-specific (currently
callback ID, conversation ID, conversation sequence and callbackObject)
into a separate header. It would also be good to separate out the
processing of these things from the core invocation framework into
Java-specific interceptors.
> There are already some use cases such as:
>
> * Pass some information from one interceptor to another one, for
> example, the DataBindingInterceptor can tell the PassByValueInvoker to
> skip the copy.
> * Carry binding-specific context in the Message, for example, SOAP
> headers for binding.ws or JMS properties for binding.jms.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jean-Sebastien Delfino"
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Monday, September 03, 2007 7:03 PM
> Subject: What is Message.set/getCallableReference used for?
>
>
>> Could somebody help me understand what
>> Message.set/getCallableReference is used for?
>>
>> If I comment it then some callback test cases start to fail, but I
>> don't really understand why we need to store a CallableReference in
>> the message, and its relationship with the from and to
>> EndpointReferences, which can already host callback endpoints.
>>
>> Also CallableReference is specific to Java (if I understand correctly
>> it takes a Java business interface) so if it's really used and needed
>> I'm not sure about how it's used for callbacks typed by WSDL or other
>> interface definition languages.
>>
There are a number of implementation classes for Java-specific APIs
that6 are currently in core/context:
CallableReferenceImpl
ComponentContextImpl
ConversationImpl
RequestContextImpl
ServiceReferenceImpl
Having these classes in core causes problems when trying to fully
implement their spec semantics, because some of these semantics need
Java-specific code. The example that I am struggling with at the
moment is ServiceReferenceImpl.setCallback() which can take either
an instance of a Java implementation class or a service reference.
If the former is passed, ServiceReferenceImpl should check to make
sure it implements the callback interface and is Serializable (see
section 1.6.7.5 of the Java Annotations and APIs spec). This is not
possible without using Java-specific code, but I don't want to make
the core module dependent on the implementation-java-runtime module.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What is Message.set/getCallableReference used for?
Posted by Raymond Feng <en...@gmail.com>.
Hi,
There are a set of states associated with CallableReference/ServiceReference
such as the callbackID, conversationID and callbackObject. We need to flow
them in the Message so that the target service can have the correct
correlations. At this moment, we have some of fields on the Message and I
thought maybe it's better to follow the CallableReference as a whole.
Another reason is that the RequestContext has a few methods to retrieve the
ServiceReference, CallbackReference and Callback object.
I agree with your comments that it's not very nice to have CallableReference
directly on the Message as accessors. Moving forward, we probably need to
define headers for the Message interface so that we can flow extra context
data without poluting the Message interface. There are already some use
cases such as:
* Pass some information from one interceptor to another one, for example,
the DataBindingInterceptor can tell the PassByValueInvoker to skip the copy.
* Carry binding-specific context in the Message, for example, SOAP headers
for binding.ws or JMS properties for binding.jms.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Monday, September 03, 2007 7:03 PM
Subject: What is Message.set/getCallableReference used for?
> Could somebody help me understand what Message.set/getCallableReference is
> used for?
>
> If I comment it then some callback test cases start to fail, but I don't
> really understand why we need to store a CallableReference in the message,
> and its relationship with the from and to EndpointReferences, which can
> already host callback endpoints.
>
> Also CallableReference is specific to Java (if I understand correctly it
> takes a Java business interface) so if it's really used and needed I'm not
> sure about how it's used for callbacks typed by WSDL or other interface
> definition languages.
>
> Thanks
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org