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.
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. 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. 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. Cheers, Jervis > -----Original Message----- > From: Jim Marino [mailto:[EMAIL PROTECTED] > Sent: Saturday, September 02, 2006 12:59 AM > To: tuscany-dev@ws.apache.org > 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: <tuscany-dev@ws.apache.org> > >> 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]
