+1 to QName instead of AxisOperation.
Tom Jordahl
Adobe Server Development
-----Original Message-----
From: Srinath Perera [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 07, 2005 3:18 AM
To: [email protected]
Subject: Re: [Axis2]Conserns on method signature on InOutMEPClient
invokeXX()
One more thing ..shall we replace the AxisOperation in the
InOutMEPClient methods with the QName?
Thanks
Srinath
On 12/6/05, Srinath Perera <[EMAIL PROTECTED]> wrote:
> 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.
> >
> >
> >
>
