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