axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jal...@opensource.lk
Subject Re: [axis2] proposal for client API refactoring
Date Tue, 29 Nov 2005 05:26:49 GMT
+1 for the refactoring.

Just a simple clarification, what is the difference between options.setX and
having them as call.setX()?

Thanks,

Jaliya
----- Original Message -----
From: "Sanjiva Weerawarana" <sanjiva@opensource.lk>
To: <axis-dev@ws.apache.org>
Sent: Monday, November 28, 2005 1:49 PM
Subject: [axis2] proposal for client API refactoring


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


Mime
View raw message