The AxisClient Sanjiva proposes below sounds very nice. +1 -- Tom Jordahl Adobe (formerly Macromedia)
-----Original Message----- From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 06, 2005 11:48 PM To: [email protected] Subject: Re: [Axis2]Conserns on method signature on InOutMEPClientinvokeXX() On Mon, 2005-12-05 at 21:44 -0500, Srinath Perera wrote: > What I thought is something like this > > 1. Call keep a instance of a MEPClient inside it and call the methods > providing a nicer interface (e.g. OMElement instead of MessageContext) > > 2. Call have a new Call(MEPClient){ ..} constructer that allow the > user to create a Call (have a nicer interface) that wrap his MEP > Client. Plus Call has old constructors which will create a MEPClient > inside it. I was going to reply with a similar proposal in response to your email thread with subject "Support for the wsdl based dynamic invocation". So I'll cancel that and move it over here. Eran was going to refactor MessageSender to /dev/null I thought by moving the convenience methods up. Background (for others, not for you Srinath!): *MEPClient classes offer two ways to send/receive SOAP messages: by sending a message context or by sending a SOAP envelope. These are fine and dandy, but they expose SOAP to users .. which would be a bad thing unless they want it. Hence the creation of MessageSender (for InOnlyMEPClient) and Call (for InOutMEPClient) to provide a convenience API that allows just the payload XML to be sent/received. So first of all, why do we have APIs for sending/receiving both MessageContexts and SOAPEnvelopes? Sometimes you need to get access to more than the actual SOAP stuff - such as transport info. To do that you have to allow the user to have access to the MessageContext. In addition, MessageContext also provides a level of abstraction over WS-Addressing versions. There are also a bunch of properties of MessageContext which are not available thru Options (e.g., whether the message is a Fault message or not); how does an interested party indicate that? Why do we need a SOAPEnvelope level API? One word: headers. Applications sometimes have to set specific headers - the WSDL may require certain headers to be included. So in a general case, the app may want to stick stuff into headers too. We can eliminate the SOAPEnvelope case if we want (MessageContext supports that too obviously). However, we put it in as a convenience. I'd be fine with removing it and having only the MessageContext API. IMO 90+% of users will end up using the simplest API: the one that deals with only the XML payload inside the SOAP envelope. However, we have to retain the flexibility to do more. Consider a BPEL impl on top of Axis2- that may want to insert a process instance ID as a header into messages going in and out.. if the only API is to deal with the payload it can't do it. Another example is Sandesha- IIRC Sandesha needs to generate new MessageID values when re-sending a message (or was that secure conversation?). In that case, you must have a way to get to the entire message. I'd like to clean this up further if possible: - have *MEPClient classes offer only a MessageContext entry point - remove MessageSender and Call - introduce a new single convenience class that supports a simpler API than both MessageSender and Call (see next) The simpler client API would be one class which has a simple API for sending/receiving just XML instead of having a different convenience subclass of each MEP client. I'm thinking of something like: class AxisClient { // options for this client void setOptions (Options opt); // use for fire-and-forget void send (OMElement payload); // use for robust-in-only void sendRobust (OMElement payload) throws AxisFault; // use for in-out OMElement sendReceive (OMElement payload) throws AxisFault; void sendReceiveNonBlocking (OMElement payload, Callback cb) throws AxisFault; } (We'd have one instance each of InOutMEPClient, InOnlyMEPClient and RobustInOnlyMEPClient inside AxisClient to implement this. If you write another MEP then you can't use this API.) We encourage the use of this API only for users looking for a simple DII. If you want more control, you must use *MEPClient. So if you're Sandesha, Kandula, WSS4J or Synapse then this API is not meant for you. > Problem I try to solve with this is following > > 1) I want to create a configured MEPClient out of a WSDL. Since I have > detail like AxisService..operations ect I like to use MEPClient > interface and create a *configured* MEPClient. > > 2) But with existing thingy .. now I am stuck to MEPClient interface > ..I want to give users an easy to use interface. What I purpose is a > new Call(mepclient); method that allow to have a nicer interface to > the MEPClient. > > If we can not do that .. I can write a wrapper classes to wrap > InOnlyMEPClient and InOutMEPClient to provide a nicer interfaces > ..That would add ugly two classes to Client classes. First of all, what you're doing is crossing MEPs ... that is, a given WSDL may have more than one MEP in use. So you can't write this as a thing that extends MEPClient IMO. What you're doing is more of stub, but with the stub getting its "methods" from the WSDL. As such, I suggest you create a totally new class called WSDLClient whic doesn't extend any *MEPClient classes and is conceptually similar to the AxisClient class above. > In anycase I consider forcing dynamic invocation (WSDL based builder) > users to use the complex MEPClient interfaces as unaccetable. +1, as above. Sanjiva.
