+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" <[EMAIL PROTECTED]> To: <[email protected]> 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. > >
