You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2007/07/18 19:58:39 UTC
Question on callback bindings
Hi,
Assuming we have the following declaration: reference r1 is wired to service
s1.
<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="s1">
<interface.wsdl interface="http://ns1#wsdl.interface(Service1)"
callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/>
<binding.ws .../>
<callback>
<binding.ws .../>
</callback>
</reference>
Then the callback path seems to be following: s1 (binding.ws) ---> r1
(binding.ws). Is this like another web service call? or is it really that
the s1 provides asynchronous response to the web service layer and the web
service client is making a callback?
For the forward call, r1 --> ws client ......(soap/http) .....ws
service -->s1. Which path should be used for the callback?
1) s1--> ws client ......(soap/http) .....ws service -->r1 (another regular
ws call)
or
2) s1--(ws-callback)--> ws server ...(soap/http) ... ws
client --(ws-callback)-->r1 (over ws callback MEP)
Thanks,
Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Question on callback bindings
Posted by Simon Nash <na...@hursley.ibm.com>.
Raymond Feng wrote:
> Hi, Simon.
>
> Multiple references can be wired to the same service. To support the
> callback, we need to know which component reference the call is from.
> The information is probably in the context of the invocation.
>
> We can create a fixed wire from "$callback$.s1" to "$callback$.r1". Then
> we need to know all the references that are wired to this service. I'm
> wondering if we can use the $callback$.s1 more dynamically by binding
> the caller as the callback target on the fly?
>
I think either of these approaches is possible. My current code takes the
first approach for wired local calls using binding.sca, and the second
approach for unwired calls across the Web Service binding, with the dynamic
addressing information being passed using WS-Addressing headers. For a
local call, we could put this information in a thread-local context.
Simon
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Simon Laws" <si...@googlemail.com>
> To: <tu...@ws.apache.org>
> Sent: Friday, July 20, 2007 11:36 AM
> Subject: Re: Question on callback bindings
>
>
>> On 7/20/07, Raymond Feng <en...@gmail.com> 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" <mi...@gmail.com>
>>> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
>>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>> 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
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Question on callback bindings
Posted by Raymond Feng <en...@gmail.com>.
Hi, Simon.
Multiple references can be wired to the same service. To support the
callback, we need to know which component reference the call is from. The
information is probably in the context of the invocation.
We can create a fixed wire from "$callback$.s1" to "$callback$.r1". Then we
need to know all the references that are wired to this service. I'm
wondering if we can use the $callback$.s1 more dynamically by binding the
caller as the callback target on the fly?
Thanks,
Raymond
----- Original Message -----
From: "Simon Laws" <si...@googlemail.com>
To: <tu...@ws.apache.org>
Sent: Friday, July 20, 2007 11:36 AM
Subject: Re: Question on callback bindings
> On 7/20/07, Raymond Feng <en...@gmail.com> 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" <mi...@gmail.com>
>> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Question on callback bindings
Posted by Simon Laws <si...@googlemail.com>.
On 7/20/07, Raymond Feng <en...@gmail.com> 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" <mi...@gmail.com>
> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> 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
Re: Question on callback bindings
Posted by Raymond Feng <en...@gmail.com>.
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" <mi...@gmail.com>
To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Question on callback bindings
Posted by Mike Edwards <mi...@gmail.com>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Question on callback bindings
Posted by Simon Nash <na...@hursley.ibm.com>.
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
Simon Laws wrote:
> On 7/18/07, Raymond Feng <en...@gmail.com> wrote:
>
>>
>> Hi,
>>
>> Assuming we have the following declaration: reference r1 is wired to
>> service
>> s1.
>>
>> <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="s1">
>> <interface.wsdl interface="http://ns1#wsdl.interface(Service1)"
>> callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/>
>> <binding.ws .../>
>> <callback>
>> <binding.ws .../>
>> </callback>
>> </reference>
>>
>> Then the callback path seems to be following: s1 (binding.ws) ---> r1
>> (binding.ws). Is this like another web service call? or is it really that
>> the s1 provides asynchronous response to the web service layer and the
>> web
>> service client is making a callback?
>>
>> For the forward call, r1 --> ws client ......(soap/http) .....ws
>> service -->s1. Which path should be used for the callback?
>>
>> 1) s1--> ws client ......(soap/http) .....ws service -->r1 (another
>> regular
>> ws call)
>> or
>> 2) s1--(ws-callback)--> ws server ...(soap/http) ... ws
>> client --(ws-callback)-->r1 (over ws callback MEP)
>>
>> Thanks,
>> Raymond
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>> Well 1) would be useful if the callback occurs outside of the context of
>
> the original call or if the callback doesn't happen for a really long time,
> i.e. long enough for connection timeouts. Downside, I guess, is to do the
> plumbing to host the callback.
>
> Simon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Question on callback bindings
Posted by Simon Laws <si...@googlemail.com>.
On 7/18/07, Raymond Feng <en...@gmail.com> wrote:
>
> Hi,
>
> Assuming we have the following declaration: reference r1 is wired to
> service
> s1.
>
> <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="s1">
> <interface.wsdl interface="http://ns1#wsdl.interface(Service1)"
> callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/>
> <binding.ws .../>
> <callback>
> <binding.ws .../>
> </callback>
> </reference>
>
> Then the callback path seems to be following: s1 (binding.ws) ---> r1
> (binding.ws). Is this like another web service call? or is it really that
> the s1 provides asynchronous response to the web service layer and the web
> service client is making a callback?
>
> For the forward call, r1 --> ws client ......(soap/http) .....ws
> service -->s1. Which path should be used for the callback?
>
> 1) s1--> ws client ......(soap/http) .....ws service -->r1 (another
> regular
> ws call)
> or
> 2) s1--(ws-callback)--> ws server ...(soap/http) ... ws
> client --(ws-callback)-->r1 (over ws callback MEP)
>
> Thanks,
> Raymond
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Well 1) would be useful if the callback occurs outside of the context of
the original call or if the callback doesn't happen for a really long time,
i.e. long enough for connection timeouts. Downside, I guess, is to do the
plumbing to host the callback.
Simon