hmm, can we handle this scenario in Axis2, in general.
I think the preferred way is to write a Client extending from
MEPClient. But I don't think it should come in to Axis2.
-- EC
Paul Fremantle wrote:
+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 <[EMAIL PROTECTED]> wrote:
+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/
|
- Re: [axis2] proposal for client API refactoring Eran Chinthaka
-
