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