On 7/20/07, Raymond Feng <[EMAIL PROTECTED]> wrote:

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]

Raymond,

Having trouble parsing this line

"This speical reference will be bound to the caller component in the
context."

Are you saying "$callback$.s1" is wired to "$callback$.r1". What does "in
the context" mean.

Simon

Reply via email to