Raymond, others, Please feel free to poke around Axis2's JMS stuff [1] (experimental) that was tested using ActiveMQ
thanks, dims [1] http://marc.theaimsgroup.com/?l=axis-dev&m=113392334526832&w=2 On 3/23/06, Raymond Feng <[EMAIL PROTECTED]> wrote: > I meant JMS transport backed by ActiveMQ at the beginning. > > I also realized that it makes sense to have an async binding framework which > supports pluggable implementation backed by different async providers. The > framework should capture the common things and leave the protocol-specific > work (for example, how to schedule a task) to the concrete providers (if > it's JMS, using the JMS API to send the invocation message to request > queue). > > Another question would be: > > Do we want to differentitate the Threading-based async and Messaging-based > async? > > Thanks, > Raymond > > ----- Original Message ----- > From: "Jeremy Boynes" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Thursday, March 23, 2006 12:49 PM > Subject: Re: A release for JavaOne? > > > > Do you mean an ActiveMQ transport or a JMS transport backed by ActiveMQ > > (realizing that there is more to ActiveMQ than just JMS)? > > > > Some async stuff I think can be handled by a simple work manager (in the > > general sense, not the JSR-237 sense although that could be an > > implementation) - does that fit? > > > > -- > > Jeremy > > > > Jim Marino wrote: > >> I was thinking ActiveMQ may be the transport mechanism. There's a lot > >> more to the programming model that would be part of Tuscany. > >> > >> Jim > >> > >> > >> On Mar 23, 2006, at 12:38 PM, Raymond Feng wrote: > >> > >>> Is ActiveMQ binding also candidate to support async PM? It seems that > >>> Celtix's JMS transport is based on Active MQ. > >>> > >>> Thanks, > >>> Raymond > >>> > >>> ----- Original Message ----- From: "Jean-Sebastien Delfino" > >>> <[EMAIL PROTECTED]> > >>> To: <[email protected]> > >>> Sent: Thursday, March 23, 2006 12:22 PM > >>> Subject: Re: A release for JavaOne? > >>> > >>> > >>> > >>>> [snip] > >>>> > >>>>> > >>>>> > >>>>>> Other than that I think it would be good to find ways to > >>>>>> show how Tuscany plans to be more than just another platform for Java > >>>>>> web > >>>>>> services. > >>>>>> > >>>>>> > >>>>> Yes, I agree with that. We may have different reasons why we agree. My > >>>>> reasoning is based on SCA, which is intended to be more than "another > >>>>> platform for Java web services". Tuscany should be this primarily > >>>>> because of SCA. > >>>>> > >>>>> I think the best way to demonstrate this is through extensibility > >>>>> inline with SCA around impl types and bindings. Practically, I would > >>>>> suggest this be a JMS binding since JMS is something a lot of Java > >>>>> people use, particularly in comparison with others, and is the next > >>>>> binding type targeted by the spec. This shows SOA != web services. > >>>>> > >>>>> Jim > >>>>> > >>>>> > >>>> Jim, I agree. It would be very good to demonstrate a subset of the SCA > >>>> async programming model running on top of a JMS binding. I think it > >>>> would make a lot sense to do this with the Celtix binding that Dan is > >>>> starting to work on. Again there's not a lot of time before May and as > >>>> I think you already said on this thread we'll probably be able to only > >>>> implement a subset of the async PM (maybe just one one-way invocations > >>>> without callbacks for example), but running the async PM on top of the > >>>> Celtix binding would help show the power of SCA, and would be a good > >>>> way to flesh out any issues and get concrete input into the spec as we > >>>> start implementing this. > >>>> --Jean-Sebastien > >>>> > >>> > >>> > >> > > > > > > -- Davanum Srinivas : http://wso2.com/blogs/
