+1 from me.

-- dims

On 11/28/05, Sanjiva Weerawarana <[EMAIL PROTECTED]> 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/

Reply via email to