axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Fremantle <pzf...@gmail.com>
Subject Re: [axis2] proposal for client API refactoring
Date Mon, 28 Nov 2005 21:34:59 GMT
+1 I think this is good.

BTW Synapse also has a need for a "flexible sync/async MEP client". The use
case is where we have a message and we don't know if it is in-only, robust
in-only or in-out/fault.

Paul

On 11/28/05, Davanum Srinivas <davanum@gmail.com> wrote:
>
> +1 from me.
>
> -- dims
>
> On 11/28/05, Sanjiva Weerawarana <sanjiva@opensource.lk> wrote:
> > Eran and I spent quite a few hours in the last few days going thru the
> > client API and have a proposal for how to refactor it. Without
> > explaining the current state in detail, I'll write up the proposed new
> > state and then list the work items so you can see what we're proposing
> > to change.
> >
> > The main motivation for the changes are to eliminate duplication across
> > different levels of the API and overall to hide complexity and disclose
> > it only as needed.
> >
> > All code is o.a.axis2.client unless otherwise indicated. The basic
> > structure is as follows:
> >
> > - Options
> >     This class is the generic options class containing all the options
> > to configure any MEP client. This JavaBean will have bean properties for
> > the usual addressing stuff (To/From/ReplyTo/FaultTo/etc.) as well as a
> > HashMap backed property bag for putting arbitrary properties. Basically
> > the idea is to make the Options class the one class that users use to
> > configure any MEP client. Each MEPClient subclass will specify
> > additional properties that must be in the Options instance in order to
> > configure those downstream Client classes.
> >
> > - MEPClient
> >     This is the abstract base class for all MEP clients. Remove all the
> > get/set methods for addressing properties etc. and replace it with one
> > method: get/setOptions which takes an Options instance.
> >
> > - InOutMEPClient
> >     As above but inherit stuff from MEPClient instead.
> >
> > - InOnlyMEPClient
> >     As above for cleanup. After that, rename as RobustInOnlyMEPClient as
> > that's the MEP this is really implementing.
> >
> > - Add new InOnlyMEPClient to implement true fire-n-forget behavior on
> > the client using a new thread.
> >
> > - Remove MessageSender and move the convenience method to send just a
> > SOAPEnvelope or an OMElement to the parent RobustInOnlyMEPClient class.
> > Add similar conveniences for the new InOnlyMEPClient class. Change the
> > send() methods to not take an operation name at all but rather defalt to
> > something.
> >
> > - Move Call.invoke with the simple forms of invoke() using a SOAPElement
> > or an OMElement to the parent InOutMEPClient class. That makes Call
> > redundant for the most part .. I'm fine in leaving for user convenience.
> >
> > Once we change this stuff, the code usage will look like this:
> >
> > import o.a.axis2.client.*;
> >
> > ...
> > Options o = new Options();
> > o.setX(..);
> > o.setY(..);
> > ...
> > Call c = new Call ();
> > c.setOptions (o);
> > c.invoke ...
> >
> > So this avoids problems like having message information headers in
> > multiple places etc.. Some other supporting mods are needed too but
> > those are straightforward.
> >
> > We discussed doing the same approach for the Stub class but I haven't
> > written that up yet.
> >
> > Sanjiva.
> >
> >
>
>
> --
> Davanum Srinivas : http://wso2.com/blogs/
>

Mime
View raw message