Hi, Does anyone know the current status of supporting asynchronous calls over a webservice binding in Tuscany? Are there are any working samples or test cases that demonstrate this functionality?
Thanks, Kapil On 9/4/06, Jim Marino <[EMAIL PROTECTED]> wrote:
On Sep 4, 2006, at 3:37 AM, Liu, Jervis wrote: > Hi, I have been following this thread and trying to figure what the > requirements are for the asynchronous support according to SAC > spec, and how this relates to ws bindings. As far as the Celtix > binding is concerned, Celtix supports asynchronous call per JAX-WS > spec, i.e., a non-blocking asynchronous call can be achieved by > either callback or polling using javax.xml.ws.Reponse or > AsyncHander defined by the jax-ws spec. This raised several issues > to be resolved when it is used in a SCA environment. The server > side (service), is relatively straightforward to do, the complexity > of non-blocking calls is already handled by Celtix. The reference > side however, is a little bit more complex, we need somehow map JAX- > WS style callback interfaces to sca callback interface. > Yes we'll need to do that as part of the SCA spec as well. I know Li was interested in this so perhaps we could come up with something and propose it as part of the JAX-WS spec Dan, Oisin and others have been working on. > Also I believe it is not Tuscany's responsibility to worry about an > async transport support, we should not try to implement sth in > Tuscany using Jetty6 NIO or AsyncWeb. I think it depends on the binding. Since Celtix has its own transport, Tuscany would use that, but for bindings that don't (e.g. "async JSON") we would need a transport service. This corresponds to the distinction between "binding extensions" and "transport extensions"; Celtix happens to give us both. > This is handled by the specific ws bindings, take the server side > as an example, my feeling is that the non-blocking return should > occur before the invocation on the target object, and when the > target object returns, the callback should also handled internally > inside the ws binding. > This brings up an interesting point of when handlers and policy get called. I was imagining the binding would receive the callback from the transport (in Celtix this is bundled together), do its thing with respect to deserialization of the message and then have Tuscany perform the correlation to the correct callback invocation chain. The message would be sent down the invocation chain and Tuscany would be responsible for delivering the message to the callback's target invoker to dispatch. The tricky part Ignacio and I have been talking about is how to do the correlation. He's coming up with some ideas so I'll let him jump in here... > Ignacio, if you are about to work on the async callbacks stories, I > would be very interested in working with you, especially on the ws > binding part. Let me know if there is anything I can help out. > Cool, I'd like to see conversational callbacks working with a variety of component implementation types using Celtix. A particularly interesting thing would be to see how we could leverage Celtix RM in this. Jim > Cheers, > Jervis > > >> -----Original Message----- >> From: Jim Marino [mailto:[EMAIL PROTECTED] >> Sent: Saturday, September 02, 2006 12:59 AM >> To: [email protected] >> Subject: Re: Async callbacks over ws binding w/Axis2, was Re: Inner >> composite patch >> >> >> >> On Sep 1, 2006, at 4:00 AM, ant elder wrote: >> >>> I've not thought much about async yet in Tuscany so could you give >>> a more >>> "big picture" view of what is being done (or just point me to OSOA >>> white >>> papers or sections in the spec if they talk about it)? >>> >> Please see the specs (assembly and Java) for details on the >> programming model for callbacks and conversations. >>> For example for services with a WS binding are you talking about >>> something >>> like: >>> >>> soap/http request arrives >>> request queued in Tuscany runtime >>> http 202 response sent >>> ... >>> tuscany processes queued request >>> soap/http response sent >>> >>> And I guess references with a WS binding will support >> remote services >>> working the same way? >>> >>> Whats needed to be done in the SCDL to get that to happen, how do >>> callbackInterfaces relate to this, or whether or not the incoming >>> requests >>> use a non-anonymous WSA replyTo? >>> >>> For references with a WS binding what will control whether or not >>> we send >>> out a non-anonymous WSA replyTo? And can that happen >> independent of >>> whether >>> or not the component invoking the reference uses a >> callbackInterface? >>> >> I'll let Ignacio reply to the specifics on flowing across Axis using >> WS-Addressing since he has thought about this more but two higher >> level things are relevant. One is that the wiring infrastructure >> should delegate to the binding for propagation of correlation >> information (e.g. there are ways to do this with JMS implementations >> or various remoting protocols such as T3). This will mean we need to >> have a correlation service in core for invocation "sequences" that >> cross *remote* boundaries (optimizations may be done for sequences >> that remain in shared memory). Indigo/WCF as an approach for >> propagating correlation through WS-splat so we may want to look at >> that for ideas and as a way to achieve interop. >> >>> Is there going to be a single Tuscany HTTP service that >> listens for >>> service >>> requests and reference responses, or will there be separate >>> listeners for >>> the reference responses? (and how will this fit in with the >>> existing Tuscany >>> ServletHost facility?) >>> >> My initial reaction would be to leave that up to the binding to >> decide. It can have one transport listener that picks things up and >> passes them back through the reference or it may have multiple (e.g. >> maybe in JMS someone decides to send response back over a different >> queue). >> >>> Sorry for all the questions but I'm interested in this from being >>> involved >>> in Synapse which is trying to do similar things. As an fyi, in >>> Synapse we've >>> just added a non-blocking http transport for Axis2 based on >>> asyncweb which >>> we may be able do something with in Tuscany. See: >>> >> Maybe we could have an async transport service similar to what >> Synapse has (care to take that on)? Also, Jetty 6 has support >> for NBIO. >> >> Jim >> >>> http://svn.apache.org/viewvc/incubator/synapse/trunk/java/modules/ >>> nhttp/ >>> >>> ...ant >>> >>> On 8/31/06, Ignacio Silva-Lepe <[EMAIL PROTECTED]> wrote: >>>> >>>> Sure, np. >>>> >>>> The basic idea is to use (1) the wiring and connection >>>> infrastructure that >>>> is there (or shortly to be there once the patch is applied) for >>>> composite >>>> references and services, and (2) the non-blocking execute with >>>> callback >>>> facilities of Axis2's operation client. >>>> >>>> Axis2Reference would need to be modified to use a variation of >>>> Axis2TargetInvoker that calls operationClient.execute(false) and >>>> that sets >>>> up a callback target invoker as the callback registered with >>>> operationClient. This could work as a subclass of >> Axis2TargetInvoker, >>>> probably in a similar way as AsyncJavaTargetInvoker is a >> subclass of >>>> PojoTargetInvoker (minus the new thread creation bit, that becomes >>>> unnecessary). >>>> >>>> Axis2Service is a bit trickier, mainly because the Axis2 api is >>>> not quite >>>> there for our needs. At first glance, it would seem like we could >>>> create >>>> an >>>> Axis2ServiceInOutAsyncMessageReceiver that extends Axis2's >>>> AbstractInOutAsyncMessageReceiver. But this latter class assumes >>>> that the >>>> business logic returns the result synchronously, i.e., when its >>>> call to >>>> invokeBusinessLogic is done it assumes that the result has been >>>> left in >>>> newmsgCtxt, and then it turns around and invokes the >> callback with >>>> the >>>> result or fault. We need to be able to separate this function so >>>> that the >>>> async invocation of the target component does happen in an >>>> independent >>>> Axis2ServiceInOutAsyncMessageReceiver, but the callback >> invocation >>>> happens >>>> in an Axis2ServiceCallbackTargetInvoker that is created by >>>> Axis2Service >>>> and >>>> that is set on the Axis2Service's outbound wire by the connector. >>>> A key >>>> item >>>> is the in-message context provided to >>>> Axis2ServiceInOutAsyncMessageReceiver's receive and that >> is needed in >>>> Axis2ServiceCallbackTargetInvoker to create the out-message >>>> context. We >>>> may >>>> end up using a workContext techinque similar to that used by >>>> AsyncJavaTargetInvoker in the local case. It may be possible to >>>> factor out >>>> the databinding function that is common with >>>> Axis2ServiceInOutSyncMessageReceiver. >>>> >>>> Needless to say, this is a first pass at putting this together, so >>>> comments >>>> are welcome. >>>> >>>> ----- Original Message ----- >>>> From: "ant elder" <[EMAIL PROTECTED]> >>>> To: <[email protected]> >>>> Sent: Thursday, August 31, 2006 9:58 AM >>>> Subject: Re: Inner composite patch, was Re: Optiional Autowire >>>> >>>> >>>>> On 8/31/06, Ignacio Silva-Lepe <[EMAIL PROTECTED]> wrote: >>>>> >>>>> <snip/> >>>>> >>>>> I am getting a good picture of what needs to be done for async >>>> callbacks >>>>>> over ws binding w/axis2 and I can keep looking at this in my >>>> current >>>>>> sandbox >>>>>> until you are done, so it's not like I am stuck. >>>>> >>>>> >>>>> Could you post an email about what and how you're looking at >>>> doing async >>>>> and >>>>> Axis2? There's a few of us who've worked on this binding in the >>>> past >>>> who'd >>>>> be interested, I didn't even know you were looking at >> this until >>>> it was >>>>> mentioned on IRC yesterday (unless I missed some previous email). >>>>> >>>>> ...ant >>>>> >>>> >>>> >>>> >>>> >> --------------------------------------------------------------------- >>>> 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] >> >> > > --------------------------------------------------------------------- > 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
