+1 for options May be we need to change the message signature of *MEPClient invoke*(..) methods to pass the SOAPEnvelope instead of MessageContext and do the property transfer via Options.
Exposing the MessageContext results in very loosly defined bundries of what should be set or not. Unless user knows finer detail it is bit tricky to create a MessageContext himself. Thanks Srinath 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. > >
