However, I have a question in my mind about asynchronous "service" and "client" for a long time. As I know, the current implementation of async dual client in axis2 is to listen to a specific port, 6060 by default. That makes problem when running several async dual clients on the same machine at the same time. What I expect is to remove the difference between client and server so that all services can be accessed through the same port for a certain transportation, the http or tcp or JMS transportation components are always there listening, and the correlated service will be triggered based on ws-addressing.
Cheers,
Don
On 3/14/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
On Tue, 2006-03-14 at 10:59 -0600, Dong Liu wrote:
> Maybe I should clarify my point here:
>
> 1. A service can support asynchronous communication with a
> message queue stands before it, no matter whether or not this
> service is able to support asynchronous messaging by nature.
> 2. It is hard for an asynchronous service to handle long-run
> service requests without the support of a message queue and
> more important a persistence layer.
> I am not sure if they are correct. Any comments?
It seems to me that you're looking for WS-Reliable Messaging like
features. Have you looked at Sandesha2? That will give behavior you're
looking for.
I think the core Axis2 platform should continue to have a simple,
lightweight async model based purely on threads to cover simple
patterns. If you really need reliable, long running async behavior then
its time to use WS-RM.
Sanjiva.
