Hi Chathura,
please see my comments inline.
Chathura Herath wrote:
> Hi Michele ,
>
>
> On 5/26/06, Michele Mazzucco <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
