Re: Question on callback bindings
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" <[EMAIL PROTECTED]> To: Sent: Friday, July 20, 2007 11:36 AM Subject: Re: Question on callback bindings 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. http://ns1#wsdl.interface(Service1)" callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/> http://ns1#wsdl.interface(Service1Callback)"/> 2) Create an internal reference for the callback of a service on the target component http://ns1#wsdl.interface(Service1)" callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/> http://ns1#wsdl.interface(Service1Callback)"/> 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: 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 > disp
Re: Question on callback bindings
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" <[EMAIL PROTECTED]> To: Sent: Friday, July 20, 2007 11:36 AM Subject: Re: Question on callback bindings 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. http://ns1#wsdl.interface(Service1)" callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/> http://ns1#wsdl.interface(Service1Callback)"/> 2) Create an internal reference for the callback of a service on the target component http://ns1#wsdl.interface(Service1)" callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/> http://ns1#wsdl.interface(Service1Callback)"/> 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: 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question on callback bindings
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. http://ns1#wsdl.interface(Service1)" callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/> http://ns1#wsdl.interface(Service1Callback)"/> 2) Create an internal reference for the callback of a service on the target component http://ns1#wsdl.interface(Service1)" callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/> http://ns1#wsdl.interface(Service1Callback)"/> 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: 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
Re: Question on callback bindings
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. http://ns1#wsdl.interface(Service1)" callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/> interface="http://ns1#wsdl.interface(Service1Callback)"/> 2) Create an internal reference for the callback of a service on the target component http://ns1#wsdl.interface(Service1)" callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/> interface="http://ns1#wsdl.interface(Service1Callback)"/> 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: 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]
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]
Re: Question on callback bindings
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 <[EMAIL PROTECTED]> wrote: Hi, Assuming we have the following declaration: reference r1 is wired to service s1. http://ns1#wsdl.interface(Service1)" callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/> http://ns1#wsdl.interface(Service1)" callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question on callback bindings
On 7/18/07, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, Assuming we have the following declaration: reference r1 is wired to service s1. http://ns1#wsdl.interface(Service1)" callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/> http://ns1#wsdl.interface(Service1)" callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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
Question on callback bindings
Hi, Assuming we have the following declaration: reference r1 is wired to service s1. http://ns1#wsdl.interface(Service1)" callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/> http://ns1#wsdl.interface(Service1)" callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
