Chathura Herath wrote:
i personally would like to use util.concurrent.Future (java.util.concurrent.Future in JDK5 backported to JDK 1.4 http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/) in API to denote delayed result such as async response message in MEP4. Srinath mentioned that the receiver concept was similar to what I
was proposing. Perhaps I do not understand its purpose, but why do we
want to capture a MEP in a handler? Isn't the MEP (irregard of a WSDL
description) driven by message endpoints, especially if everything is
inheritently one-way in messaging?
To my understanding MEP doesn't say anything about whether the service is sync/async and if I'm right that is a user decision which says how the client will behave after sending the out message and till the reception of the in message. Similar argument is valid for the server side. This get fussier due to the usage of the Transport being oneway/twoway(e.g. Http is a two way transport and would require a response in the transport level despite the service call being sync/async). So three things to note are 1) MEP 2) sync/async behavior of the service 3) behavior of the transport.
Axis2 was architected with Asynchronous in mind, but Synchronous ws calls were of great significance. So the receiver concept is expected to differentiate the behavior of the message path inside the engine which will be determined based on the MEP in the WSDL and service being a sync/async. Further the transport layer complexity will be handled inside the TransportReceiver s and TransportSender s.
Wouldn't the Call (or
MessageClient) class drive the exchange pattern?
Not right now in Axis2. If you look at the Call class you ll see that it provides a generic API so that client Stub can use Call and invoke the *right method* to get the expected behavior (Sync/Async and MEP). Basically we will eventually codegen a client side stub based on the MEP and it is required client behavior that will invoke the *right method* of the Call. Point that I want to note is that it requires something before the Call class to make the right Messaging choice.
Personally I believe the concept of p2p messaging goes beyond the capabilities of the current implementation of Call and I don't think it will be elegant for us to squeeze the concept of p2p messaging *as it is* and map the messageprovider and messageconsumer to axis sever and axis client respectively. Instead may be a different approach such as where messagerprovider and consumer are axis servers with running services for both message sending and reception (inplace of the Call) for the p2p messaging; While supporting the current Call impl which has a very high usability.
Comments ???
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Future.html
that is used for example in JBoss (though i think that API is overly complex mix of homegrown async and EJB):
http://docs.jboss.org/ejb3/tutorial/asynch/asynch.html
it is still better than dealing with callbacks IMHO: http://www.onjava.com/pub/a/onjava/2005/02/23/remoting.html
and then there are some other interesting ideas mostly around metadata annotations like this one:
http://jroller.com/page/talipozturk/20050117#asynchronous_methods_in_java
thanks,
alek
Regards Chathura
-- The best way to predict the future is to invent it - Alan Kay
