Comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Simon Nash" <[EMAIL PROTECTED]>
To: <[email protected]>
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"
<[EMAIL PROTECTED]>
To: <[email protected]>
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/[email protected]/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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Simon C Nash IBM Distinguished Engineer
Hursley Park, Winchester, UK [EMAIL PROTECTED]
Tel. +44-1962-815156 Fax +44-1962-818999
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
