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: 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]
> >
>
>
> ---------------------------------------------------------------------
> 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]
