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 <[EMAIL PROTECTED]> wrote:
> 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]
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
