Big +1 for AxisClient :)
Since AxisClient is really cross MEP I can use it instead of
WSDLClient (but only support for the MEPs AxisClient support). What do
you think .. should I have a WSDLClient anyway or use the AxisClient?
Thanks
Srinath
On 12/6/05, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
> 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.
>
>
>
