You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Michele Mazzucco <Mi...@ncl.ac.uk> on 2006/05/26 16:32:16 UTC
[Axis2] setOperationContext() question
Hi all,
is it possible to get the same result with outgoing messages as well by
using the setOperationContext() (it seems to me that the
outMsgCtx = opctx.getMessageContext(WSDLConstants.MESSAGE_LABEL_OUT_VALUE);
into the setOperationContext() doesn't work as espected
)?
If no, is there any way to add some headers to outgoing messages?
Thanks in advance,
Michele
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] setOperationContext() question
Posted by Michele Mazzucco <Mi...@ncl.ac.uk>.
Ok, this is the point. The problem is that it seems they don't work.
Michele
Samisa Abeysinghe wrote:
> Michele Mazzucco wrote:
>
>> Right, but how can I get the same result, say, in a message handler,
>> where you have only the message context?
>>
>>
> If I understand your problem correct, you want to add a header from a
> handler.
> If that is the case, you can access the SOAP envelope and use its API to
> get the job done.
>
> Samisa...
>
>> Michele
>>
>> Samisa Abeysinghe wrote:
>>
>>
>>> Michele Mazzucco wrote:
>>>
>>>
>>>> Hi all,
>>>>
>>>> is it possible to get the same result with outgoing messages as well by
>>>> using the setOperationContext() (it seems to me that the
>>>>
>>>> outMsgCtx =
>>>> opctx.getMessageContext(WSDLConstants.MESSAGE_LABEL_OUT_VALUE);
>>>>
>>>> into the setOperationContext() doesn't work as espected
>>>> )?
>>>>
>>>> If no, is there any way to add some headers to outgoing messages?
>>>>
>>>>
>>>>
>>> You can use:
>>> public void addHeader(OMElement header)
>>> of service client to add headers.
>>>
>>> HTH.
>>> Samisa...
>>>
>>>
>>>> Thanks in advance,
>>>> Michele
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] setOperationContext() question
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Michele Mazzucco wrote:
>Right, but how can I get the same result, say, in a message handler,
>where you have only the message context?
>
>
If I understand your problem correct, you want to add a header from a
handler.
If that is the case, you can access the SOAP envelope and use its API to
get the job done.
Samisa...
>Michele
>
>Samisa Abeysinghe wrote:
>
>
>>Michele Mazzucco wrote:
>>
>>
>>
>>>Hi all,
>>>
>>>is it possible to get the same result with outgoing messages as well by
>>>using the setOperationContext() (it seems to me that the
>>>
>>>outMsgCtx =
>>>opctx.getMessageContext(WSDLConstants.MESSAGE_LABEL_OUT_VALUE);
>>>
>>>into the setOperationContext() doesn't work as espected
>>>)?
>>>
>>>If no, is there any way to add some headers to outgoing messages?
>>>
>>>
>>>
>>>
>>You can use:
>>public void addHeader(OMElement header)
>>of service client to add headers.
>>
>>HTH.
>>Samisa...
>>
>>
>>
>>>Thanks in advance,
>>>Michele
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>>For additional commands, e-mail: axis-user-help@ws.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] setOperationContext() question
Posted by Michele Mazzucco <Mi...@ncl.ac.uk>.
Right, but how can I get the same result, say, in a message handler,
where you have only the message context?
Michele
Samisa Abeysinghe wrote:
> Michele Mazzucco wrote:
>
>> Hi all,
>>
>> is it possible to get the same result with outgoing messages as well by
>> using the setOperationContext() (it seems to me that the
>>
>> outMsgCtx =
>> opctx.getMessageContext(WSDLConstants.MESSAGE_LABEL_OUT_VALUE);
>>
>> into the setOperationContext() doesn't work as espected
>> )?
>>
>> If no, is there any way to add some headers to outgoing messages?
>>
>>
> You can use:
> public void addHeader(OMElement header)
> of service client to add headers.
>
> HTH.
> Samisa...
>
>> Thanks in advance,
>> Michele
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] setOperationContext() question
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Michele Mazzucco wrote:
>Hi all,
>
>is it possible to get the same result with outgoing messages as well by
>using the setOperationContext() (it seems to me that the
>
>outMsgCtx = opctx.getMessageContext(WSDLConstants.MESSAGE_LABEL_OUT_VALUE);
>
>into the setOperationContext() doesn't work as espected
>)?
>
>If no, is there any way to add some headers to outgoing messages?
>
>
You can use:
public void addHeader(OMElement header)
of service client to add headers.
HTH.
Samisa...
>Thanks in advance,
>Michele
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] setOperationContext() question
Posted by robert lazarski <ro...@gmail.com>.
You can use WSDLConstants.MESSAGE_LABEL_IN_VALUE and
WSDLConstants.MESSAGE_LABEL_OUT_VALUE . Or, messageContext.getFLOW(), ie:
if (messageContext.getFLOW() == MessageContext.IN_FLOW) {
...
} else (messageContext.getFLOW() == MessageContext.OUT_FLOW) {
...
}
HTH,
Robert
http://www.braziloutsource.com/
On 5/26/06, Michele Mazzucco <Mi...@ncl.ac.uk> wrote:
>
> Chathura,
>
> I'm sorry, but if I use the same handler, how can I distinguish between
> incoming and outgoing messages?
>
> Thanks,
> Michele
>
> Chathura Herath wrote:
> > The out message context is created at the end of the in chain by the
> > message receiver only if required(e.g. if the mep is In-Only the
> > particular message receiver will not create the out message context).
> > Anyway, what you have described below isnt the anticipated programming
> > model of axis2.
> > Here is wht you should do.
> > Write an inflow handler that saves the headers/state(that u want to
> > lookup in the outflow) in the operationcontext using the setProperty
> > method.
> > Write and outflow handler that extracts this saved state/header from
> > the operation context and set it to the out soapEnvelop.
> > Create amodule out of this handler(s) and deploy.
> > You can use the same handler for both, have a look at the login
> > module in the user guide.
> > http://ws.apache.org/axis2/1_0/userguide4.html#Step2_:_LogHandler
> > HTH
> > Chathura
> >
> > On 5/26/06, Michele Mazzucco <Mi...@ncl.ac.uk> wrote:
> >> Hi all,
> >>
> >> is it possible to get the same result with outgoing messages as well by
> >> using the setOperationContext() (it seems to me that the
> >>
> >> outMsgCtx =
> >> opctx.getMessageContext(WSDLConstants.MESSAGE_LABEL_OUT_VALUE);
> >>
> >> into the setOperationContext() doesn't work as espected
> >> )?
> >>
> >> If no, is there any way to add some headers to outgoing messages?
> >>
> >> Thanks in advance,
> >> Michele
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-user-help@ws.apache.org
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
Re: [Axis2] setOperationContext() question
Posted by Michele Mazzucco <Mi...@ncl.ac.uk>.
Chathura,
I'm sorry, but if I use the same handler, how can I distinguish between
incoming and outgoing messages?
Thanks,
Michele
Chathura Herath wrote:
> The out message context is created at the end of the in chain by the
> message receiver only if required(e.g. if the mep is In-Only the
> particular message receiver will not create the out message context).
> Anyway, what you have described below isnt the anticipated programming
> model of axis2.
> Here is wht you should do.
> Write an inflow handler that saves the headers/state(that u want to
> lookup in the outflow) in the operationcontext using the setProperty
> method.
> Write and outflow handler that extracts this saved state/header from
> the operation context and set it to the out soapEnvelop.
> Create amodule out of this handler(s) and deploy.
> You can use the same handler for both, have a look at the login
> module in the user guide.
> http://ws.apache.org/axis2/1_0/userguide4.html#Step2_:_LogHandler
> HTH
> Chathura
>
> On 5/26/06, Michele Mazzucco <Mi...@ncl.ac.uk> wrote:
>> Hi all,
>>
>> is it possible to get the same result with outgoing messages as well by
>> using the setOperationContext() (it seems to me that the
>>
>> outMsgCtx =
>> opctx.getMessageContext(WSDLConstants.MESSAGE_LABEL_OUT_VALUE);
>>
>> into the setOperationContext() doesn't work as espected
>> )?
>>
>> If no, is there any way to add some headers to outgoing messages?
>>
>> Thanks in advance,
>> Michele
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] setOperationContext() question
Posted by Michele Mazzucco <Mi...@ncl.ac.uk>.
Hi,
it seems that is the point. If you have an IN-OUT operation, the
in-handler can't save any information into the message context because
the out message context is not the same, and thus the informations are lost.
If the "computational node" handles only *one* request at a time, this
is not a problem: assuming the in and out handlers are the same, you
simply save the in-msg context and gets the informations during the out
phase. However, if the computational nodes handles more that one client
request at a time, the only solution I see is to correlate the in msg.
Id and the out msg. Id.
Any suggest is welcome.
Thanks,
Michele
Chathura Herath wrote:
> Hi Michele ,
>
>
> On 5/26/06, Michele Mazzucco <Mi...@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. I could try to clarify things
> for you. I still do not understand you are trying to do. You shouldn't
> have to corelate request and responce because such corelation is done
> inside the ServiceClient using return parameters or callbacks.
>
>
>> 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.
>>
>>
>> Thanks,
>> Michele
>>
> HTH
> Chathura
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] setOperationContext() question
Posted by Ali Sadik Kumlali <as...@yahoo.com>.
Hi,
As I've seen from Michele's postings, we need to do the same thing. So,
I wanted to share my thoughts and my design.
- At the server side, axis2 is only used as a broker to our backend
application which is able to process requests asynchronously. Thus,
some operations can take very long time what we called long running
transactions.
- When the backend system is ready to send back the results, axis2
layer should be handle the result and should add necessary outgoing
information to it before sending to the target end point.
- You may say this can be done by using AsyncMessageReceiver. But, it's
not fault tolerant. It only creates a new thread that waits for the
process result from the backend system. What happens if the machine
that runs axis2 layer crashes? My thread and all the necessary outgoing
information is gone. But client will not aware of this and will wait
forever.
- You may also offer me to design my architecture by only using in MEP.
But in this case, there is nothing that I can bind requests and the
result messages. So, I cannot say the clients which result message
should they wait for which request.
Actually, as all enterprise application developers, I (and may be
Michele) need monitorible and fault tolerant asynchronous messaging.
AFAIK, this can only be achived by persisting the information that is
needed for outgoing messages.
I've chosen following design
- My WSDL has input-output-fault(s) operations which let the clients
think it will use an in-out MEP. So, if they use axis2, they will be
able to invoke my services in either blocking or non-blocking fashion,
but without really knowing I will process their requests asynchronously
on my backend application.
- I'll use (and will force my clients to use) seperate channels for
request and the response.
- At my service side, I'll use in-only receiver. Thus, when the
receiver gets the message, by sending appropriate HTTP header back over
the same channel, it will let the client to close request channel and
to create a listener for the response. Please consider this scenario is
done over HTTP. In JMS case, server will not be able to send a message
back to the client to make it close to the request channel.
- Also, receiver persists the information that will later be used to
prepare outgoing message.
- When the one of the operation found in *custom* skeleton is invoked,
it only converts incoming message to the input of backend system then
invokes the backend system's service in fire-and-forget fashion. But,
please consider my axis2 layer has a listener for the results coming
from the backend system. Please also consider that I have only one
listener (say MDB) and this is always up.
- When the process has been finished at backend system, it will let the
axis2 layer's listener to get the message.
- When the listener gets the message, it will create an outgoing
message by blending persistent outgoing info with the message comming
from the backend system. Later, it will send the outgoing message to
the target end point which is our client's listener.
- When the client get the result, it'll accomplish the process.
As you've seen here, client has no knowledge about how I processed it's
request. It only knows it's messaging as in-out mep.
Have I successfully implemented this? No, of course :) But, when I get
answers and the solutions to my problems which I created JIRA logs(
AXIS2-679, AXIS2-725, AXIS2-741) I'll do it.
Hope this extra long :) message clear some points.
Regards,
Ali Sadik Kumlali
--- Michele Mazzucco <Mi...@ncl.ac.uk> wrote:
> Hi Chathura,
>
> please see my comments inline.
>
> Chathura Herath wrote:
> > Hi Michele ,
> >
> >
> > On 5/26/06, Michele Mazzucco <Mi...@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
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] setOperationContext() question
Posted by Michele Mazzucco <Mi...@ncl.ac.uk>.
Hi Chathura,
please see my comments inline.
Chathura Herath wrote:
> Hi Michele ,
>
>
> On 5/26/06, Michele Mazzucco <Mi...@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
Re: [Axis2] setOperationContext() question
Posted by Chathura Herath <ch...@gmail.com>.
Hi Michele ,
On 5/26/06, Michele Mazzucco <Mi...@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. I could try to clarify things
for you. I still do not understand you are trying to do. You shouldn't
have to corelate request and responce because such corelation is done
inside the ServiceClient using return parameters or callbacks.
> 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.
>
>
> Thanks,
> Michele
>
HTH
Chathura
--
Chathura Herath
http://people.apache.org/~chathura/
http://chathurah.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] setOperationContext() question
Posted by Michele Mazzucco <Mi...@ncl.ac.uk>.
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)?
2 - What happens if the MEP is in-out? Are the request and reply message
context the same?
Thanks,
Michele
Chathura Herath wrote:
> The out message context is created at the end of the in chain by the
> message receiver only if required(e.g. if the mep is In-Only the
> particular message receiver will not create the out message context).
> Anyway, what you have described below isnt the anticipated programming
> model of axis2.
> Here is wht you should do.
> Write an inflow handler that saves the headers/state(that u want to
> lookup in the outflow) in the operationcontext using the setProperty
> method.
> Write and outflow handler that extracts this saved state/header from
> the operation context and set it to the out soapEnvelop.
> Create amodule out of this handler(s) and deploy.
> You can use the same handler for both, have a look at the login
> module in the user guide.
> http://ws.apache.org/axis2/1_0/userguide4.html#Step2_:_LogHandler
> HTH
> Chathura
>
> On 5/26/06, Michele Mazzucco <Mi...@ncl.ac.uk> wrote:
>> Hi all,
>>
>> is it possible to get the same result with outgoing messages as well by
>> using the setOperationContext() (it seems to me that the
>>
>> outMsgCtx =
>> opctx.getMessageContext(WSDLConstants.MESSAGE_LABEL_OUT_VALUE);
>>
>> into the setOperationContext() doesn't work as espected
>> )?
>>
>> If no, is there any way to add some headers to outgoing messages?
>>
>> Thanks in advance,
>> Michele
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] setOperationContext() question
Posted by Chathura Herath <ch...@gmail.com>.
Following was for server side header manipulation btw.
Regards
Chathura
On 5/26/06, Chathura Herath <ch...@gmail.com> wrote:
> The out message context is created at the end of the in chain by the
> message receiver only if required(e.g. if the mep is In-Only the
> particular message receiver will not create the out message context).
> Anyway, what you have described below isnt the anticipated programming
> model of axis2.
> Here is wht you should do.
> Write an inflow handler that saves the headers/state(that u want to
> lookup in the outflow) in the operationcontext using the setProperty
> method.
> Write and outflow handler that extracts this saved state/header from
> the operation context and set it to the out soapEnvelop.
> Create amodule out of this handler(s) and deploy.
> You can use the same handler for both, have a look at the login
> module in the user guide.
> http://ws.apache.org/axis2/1_0/userguide4.html#Step2_:_LogHandler
> HTH
> Chathura
>
> On 5/26/06, Michele Mazzucco <Mi...@ncl.ac.uk> wrote:
> > Hi all,
> >
> > is it possible to get the same result with outgoing messages as well by
> > using the setOperationContext() (it seems to me that the
> >
> > outMsgCtx = opctx.getMessageContext(WSDLConstants.MESSAGE_LABEL_OUT_VALUE);
> >
> > into the setOperationContext() doesn't work as espected
> > )?
> >
> > If no, is there any way to add some headers to outgoing messages?
> >
> > Thanks in advance,
> > Michele
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
>
> --
> Chathura Herath
> http://people.apache.org/~chathura/
> http://chathurah.blogspot.com/
>
--
Chathura Herath
http://people.apache.org/~chathura/
http://chathurah.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] setOperationContext() question
Posted by Chathura Herath <ch...@gmail.com>.
The out message context is created at the end of the in chain by the
message receiver only if required(e.g. if the mep is In-Only the
particular message receiver will not create the out message context).
Anyway, what you have described below isnt the anticipated programming
model of axis2.
Here is wht you should do.
Write an inflow handler that saves the headers/state(that u want to
lookup in the outflow) in the operationcontext using the setProperty
method.
Write and outflow handler that extracts this saved state/header from
the operation context and set it to the out soapEnvelop.
Create amodule out of this handler(s) and deploy.
You can use the same handler for both, have a look at the login
module in the user guide.
http://ws.apache.org/axis2/1_0/userguide4.html#Step2_:_LogHandler
HTH
Chathura
On 5/26/06, Michele Mazzucco <Mi...@ncl.ac.uk> wrote:
> Hi all,
>
> is it possible to get the same result with outgoing messages as well by
> using the setOperationContext() (it seems to me that the
>
> outMsgCtx = opctx.getMessageContext(WSDLConstants.MESSAGE_LABEL_OUT_VALUE);
>
> into the setOperationContext() doesn't work as espected
> )?
>
> If no, is there any way to add some headers to outgoing messages?
>
> Thanks in advance,
> Michele
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Chathura Herath
http://people.apache.org/~chathura/
http://chathurah.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org