axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michele Mazzucco <Michele.Mazzu...@ncl.ac.uk>
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 <Michele.Mazzucco@ncl.ac.uk> 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 =
      opctx.getMessageContext(WSDLConstants.MESSAGE_LABEL_IN_VALUE);
  }

  public void echo (OMElement incomingPayload)

        throws XMLStreamException {
    incomingPayload.build();
    incomingPayload.detach();		

    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.setTo(targetEPR);
      options.setTransportInProtocol(Constants.TRANSPORT_HTTP);
      options.setUseSeparateListener(false);
      options.setAction(action);
      options.setMessageId(UUIDGenerator.getUUID());
      options.setRelationships(new RelatesTo[] {
          new RelatesTo(messageId,
              AddressingConstants.Submission.
              WSA_RELATES_TO_RELATIONSHIP_TYPE_DEFAULT_VALUE)});

      ConfigurationContext confCtx =
          ListenerManager.defaultConfigurationContext;
      sender = new ServiceClient(confCtx, null);
      sender.setOptions(options);

      // Blocking Invocation
      sender.sendReceive(payload);
    } catch (AxisFault axisFault) {
      axisFault.printStackTrace();
    } catch (Exception ex) {
      ex.printStackTrace();
    } finally {
      try {
          sender.finalizeInvoke();
      } catch (AxisFault axisFault) {
          // have to ignore this
          axisFault.printStackTrace();
      }
    }
  }
}


What happens here? You loose all the informations the handler saved in
the messagecontext.options.properties, 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
>>
> HTH
> Chathura



Thanks,
Michele

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org


Mime
View raw message