axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <>
Subject Re: [Axis2]Conserns on method signature on InOutMEPClient invokeXX()
Date Tue, 06 Dec 2005 18:18:18 GMT
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

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

> In anycase I consider forcing dynamic invocation (WSDL based builder)
> users to use the complex MEPClient interfaces as unaccetable.

+1, as above.


View raw message