[Axis 2] async/messaging API?

[Aleksander Slominski <as...@cs.indiana.edu>]

Chathura Herath wrote:

>>>4. 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 ???
>
>  
>
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 MEP
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

Re: [Axis 2] async/messaging API?

[Shawn Dahlen <sm...@gmail.com>]

> >
> 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 MEP
> 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

I looked into the use of Future recently in JDK5, but I didn't know that
it was backported.  I think it would be wise to at least look into for the
async capabilities.

> 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

Has anyone done research into the potential projects that may offer
code annotations
in JDK 1.4?  I think this will have some importance as we attempt to
simplify the
programming model.  I know of Apache Attributes.