Hi,
It seems that we all agree the callback path should be treated as a regular
interaction using the callback interface over the selected binding. Can we
then simplify the callback processing in Tuscany as follows?
1) Normalize the callbacks as a regular reverse call in the
CompositeBuilderImpl:
a) Create an internal service for the callback of a reference on the source
component.
<reference name="r1">
<interface.wsdl interface="http://ns1#wsdl.interface(Service1)"
callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/>
<binding.ws .../>
<callback>
<binding.ws .../>
</callback>
</reference>
<service name="$callback$.r1">
<interface.wsdl
interface="http://ns1#wsdl.interface(Service1Callback)"/>
<binding.ws .../> <!-- copied from the binding.ws under callback -->
</service>
2) Create an internal reference for the callback of a service on the target
component
<service name="s1">
<interface.wsdl interface="http://ns1#wsdl.interface(Service1)"
callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/>
<binding.ws .../>
<callback>
<binding.ws .../>
</callback>
</service>
<reference name="$callback$.s1">
<interface.wsdl
interface="http://ns1#wsdl.interface(Service1Callback)"/>
<binding.ws .../> <!-- copied from the binding.ws under callback -->
</reference>
This speical reference will be bound to the caller component in the context.
2) Remove all the speical handling of callbacks in core, including the
callback invocation chains, callback wires and callback invoker since now
the callback is just a regular invocation.
Does it make sense?
Thanks,
Raymond
----- Original Message -----
From: "Mike Edwards" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Friday, July 20, 2007 4:27 AM
Subject: Re: Question on callback bindings
Simon Nash wrote:
I am implementing approach 1). The code is turning out to be
straightforward and this approach fully supports the SCA callback
spec AIUI.
The Axis2 callback MEP isn't the same as an SCA callback, and it's
confusing that these have the same name. With the Axis2 callback
MEP, the forward call is sent asynchronously, and the callback
message carries the result from the forward call. In SCA, the
callback is a normal call made in the reverse direction, and the
signature of the callback is unrelated to the signature of the
forward call.
Simon
Folks,
This is the correct interpretation.
SCA callback is very general and make no assumption about the nature of
the transport used between the reference and the service.
The call interface has each method able to be a full request/response, if
that is what is required. They can of course have a void return or be a
OneWay invocation.
The callback interface equally allows each method to be a full
request/response or a OneWay.
There is no assumption made about the number or the timing of the
invocations on the callback interface related to a given invocation on the
call interface. Indeed, SCA today has no metadata that captures these
relationships (it has been suggested quite seriously that it might be
possible to capture this metadata as an abstract BPEL process, but this
has not been progressed as a formal addition to the Assembly
specification).
So, the correct behaviour is for the call to be treated as a regular
SOAP/HTTP interaction, completely independent from any callback
interaction.
A given call may result in 0, 1 or many callback invocations. A simple
example might be a service for placing an order. The "place order"
operation may be request/response with the response acting as a "ack" that
the order was received. However, the "place order" may then be followed
by callbacks like the following:
- "order accepted" - once credit checking and item availability checks are
done
- "order dispatched" - once the order items have been packaged and
dispatched to the shipper
Yours, Mike.
---------------------------------------------------------------------
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]
