axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michele Mazzucco <>
Subject Re: [Axis2] setOperationContext() question
Date Sat, 27 May 2006 09:24:41 GMT
Hi Chathura,

please see my comments inline.

Chathura Herath wrote:
> Hi Michele ,
> On 5/26/06, Michele Mazzucco <> wrote:
>> Hi Chathura,
>> so now my questions are:
>> 1 - What happens if the response doesn't follow the in-out MEP but it is
>> created from scratch by a new ServiceClient?, I think my informations
>> are lost, am I right (but I could save the message context and correlate
>> the request and reply message through message id)?
> Service client has few methods such as sendreceive, fireandforget, etc
> and meps are built into those methods. So if you can say which method
> are you using or paste a piece of code. 

say you have a service like the one showed by Ali in the "Unexpected EOF
in prolog" thread (13/05/06):

public class MyService {

  private MessageContext inMsgCtx;

  public void setOperationContext(OperationContext opctx)
           throws AxisFault {
    inMsgCtx =

  public void echo (OMElement incomingPayload)

        throws XMLStreamException {;

    OMElement outgoingPayload = incomingPayload;

    oldOptions = inMsgCtx.getOptions();
    String messageID = inMsgCtx.getMessageID();
    EndpointReference targetEPR = oldOptions.getReplyTo();
    String action = oldOptions.getAction();
    sendResult(messageID, targetEPR, action, outgoingPayload);

  public void sendResult(String messageId, EndpointReference targetEPR,
        String action, OMElement payload) {
    ServiceClient sender = null;
    try {
      Options options = new Options();
      options.setRelationships(new RelatesTo[] {
          new RelatesTo(messageId,

      ConfigurationContext confCtx =
      sender = new ServiceClient(confCtx, null);

      // Blocking Invocation
    } catch (AxisFault axisFault) {
    } catch (Exception ex) {
    } finally {
      try {
      } catch (AxisFault axisFault) {
          // have to ignore this

What happens here? You loose all the informations the handler saved in
the, don't you?

I could try to clarify things
> for you. I still do not understand you are trying to do. 

I have a node acting as broker. It forwards client requests to
computational nodes according to some policies. Computational nodes
execute the request (I don't have any control, and thus I can't make any
assumption, on services executed by computational nodes).
To make this architecture working, I have am handler on the broker side
(which essentially changes the routing informations, since the broker
doesn't provide any "business" service, but it allows me to provide with
a transparent architecture) and an handler on each computational node
(used to take statistics and eventually fetch the service from a
repository, if it's not already deployed at that node).

You shouldn't
> have to corelate request and responce because such corelation is done
> inside the ServiceClient using return parameters or callbacks.

Now, if the business service has the usual signature (i.e. OMElement foo
(OMElement payload)) the node handler can save informations (I need to
save some informations both during the in-flow and the out-flow, they
will be used by the broker) in the properties field of the MessageContext.

>> 2 - What happens if the MEP is in-out? Are the request and reply message
>> context the same?
> Ok here is a bit of background. for one invocateon there is only *one*
> Operation Context. Could have many message contexts. If the MEP in in
> out; then there are two message contexts and one operation context
> that it will be attached to. Boththe message contexts will return the
> same operation context object if you call getoperationcontext on both
> of them. So i believe this answers your second question, which is NO
> there are two messsage contexts.

If the answer is *no*, how can I save informations during the in-flow
and be sure that they will be received by the broker?

client ---->  handlerA | broker ----> handlerB* | node

* the handlerB saves some informations during the in-flow phase as well
during the out-flow phase (these informations are used by the broker)

>> Thanks,
>> Michele
> Chathura


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message