Re: [Axis2]Conserns on method signature on InOutMEPClient invokeXX()

[Sanjiva Weerawarana <sa...@opensource.lk>]

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.

Re: [Axis2]Conserns on method signature on InOutMEPClient invokeXX()

[Srinath Perera <he...@gmail.com>]

One more thing ..shall we replace the AxisOperation in the
InOutMEPClient methods with the QName?
Thanks
Srinath

On 12/6/05, Srinath Perera <he...@gmail.com> 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 <sa...@opensource.lk> 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.
> >
> >
> >
>

Re: [Axis2]Conserns on method signature on InOutMEPClient invokeXX()

[Srinath Perera <he...@gmail.com>]

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 <sa...@opensource.lk> 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.
>
>
>