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
