Save This Page
Home » axis2-1.5-src » org.apache » axis2 » client » [javadoc | source]
org.apache.axis2.client
abstract public class: OperationClient [javadoc | source]
java.lang.Object
   org.apache.axis2.client.OperationClient

Direct Known Subclasses:
    OutOnlyAxisOperationClient, RobustOutOnlyOperationClient, OutInAxisOperationClient

An operation client is the way an advanced user interacts with Axis2. Actual operation clients understand a specific MEP and hence their behavior is defined by their MEP. To interact with an operation client, you first get one from a specific AxisOperation. Then you set the messages into it one by one (whatever is available). Then, when you call execute() the client will execute what it can at that point. If executing the operation client results in a new message being created, then if a message receiver is registered with the client then the message will be delivered to that client.
Field Summary
protected  AxisOperation axisOp     
protected  ServiceContext sc     
protected  Options options     
protected  OperationContext oc     
protected  Callback callback     
protected  AxisCallback axisCallback     
protected  boolean completed     
Constructor:
 protected OperationClient(AxisOperation axisOp,
    ServiceContext sc,
    Options options) 
Method from org.apache.axis2.client.OperationClient Summary:
addMessageContext,   addReferenceParameters,   complete,   execute,   executeImpl,   getMessageContext,   getOperationContext,   getOptions,   prepareMessageContext,   reset,   setCallback,   setCallback,   setMessageID,   setOptions
Methods from java.lang.Object:
equals,   getClass,   hashCode,   notify,   notifyAll,   toString,   wait,   wait,   wait
Method from org.apache.axis2.client.OperationClient Detail:
 abstract public  void addMessageContext(MessageContext messageContext) throws AxisFault
    Add a message context to the client for processing. This method must not process the message - it only records it in the operation client. Processing only occurs when execute() is called.
 protected  void addReferenceParameters(MessageContext msgctx) 
 public  void complete(MessageContext msgCtxt) throws AxisFault 
    To close the transport if necessary , can call this method. The main usage of this method is when client uses two tarnsports for sending and receiving , and we need to remove entries for waiting calls in the transport listener queue. Note : DO NOT call this method if you are not using two transports to send and receive
 public final  void execute(boolean block) throws AxisFault 
    Execute the MEP. This method is final and only serves to set (if appropriate) the lastOperationContext on the ServiceContext, and then it calls executeImpl(), which does the actual work.
 abstract public  void executeImpl(boolean block) throws AxisFault
    Execute the MEP. What this does depends on the specific operation client. The basic idea is to have the operation client execute and do something with the messages that have been added to it so far. For example, if its an Out-In MEP, then if the Out message has been set, then executing the client asks it to send the message and get the In message, possibly using a different thread.
 abstract public MessageContext getMessageContext(String messageLabel) throws AxisFault
    Return a message from the client - will return null if the requested message is not available.
 public OperationContext getOperationContext() 
    To get the operation context of the operation client
 public Options getOptions() 
    Return the options used by this client. If you want to set a single option, then the right way is to do getOptions() and set specific options.
 protected  void prepareMessageContext(ConfigurationContext configurationContext,
    MessageContext mc) throws AxisFault 
    prepareMessageContext gets a fresh new MessageContext ready to be sent. It sets up the necessary properties, transport information, etc.
 public  void reset() throws AxisFault 
    Reset the operation client to a clean status after the MEP has completed. This is how you can reuse an operation client. NOTE: this does not reset the options; only the internal state so the client can be used again.
 abstract public  void setCallback(Callback callback)Deprecated! Please -  use the AxisCallback interface rather than Callback, which has been deprecated

    Set the callback to be executed when a message comes into the MEP and the operation client is executed. This is the way the operation client provides notification that a message has been received by it. Exactly when its executed and under what conditions is a function of the specific operation client.
 public final  void setCallback(AxisCallback callback) 
    Set the callback to be executed when a message comes into the MEP and the operation client is executed. This is the way the operation client provides notification that a message has been received by it. Exactly when its executed and under what conditions is a function of the specific operation client.
 protected  void setMessageID(MessageContext mc) 
    Create a message ID for the given message context if needed. If user gives an option with MessageID then just copy that into MessageContext , and with that there can be multiple message with same MessageID unless user call setOption for each invocation.

    If user want to give message ID then the better way is to set the message ID in the option and call setOption for each invocation then the right thing will happen.

    If user does not give a message ID then the new one will be created and set that into Message Context.

 public  void setOptions(Options options) 
    Sets the options that should be used for this particular client. This resets the entire set of options to use the new options - so you'd lose any option cascading that may have been set up.