Re: [Axis2] Synchronous response over JMS

[Roger Nell <ro...@yahoo.com>]

Hi Ali, 

Responses to your number questions:

1) I'm not sure this message interaction is covered by the message exchange patterns (MEP) defined in SOAP.  I do not think you can get the "blocked for a short time" feature.  I suggest you think of building more logic into your client or service and use async all the way if it all possible.

My feeling is that if the message fails for some reason such as security or validation the fault message would likely come back pretty quick.  If the message is accepted the service is called and the response comes back sometime later. For long running tasks, we have our services publish status messages to a temporary JMS topic so that the client can monitor the progress.  Messages like "finished 1 of 100, 2 of 100, etc."  The publishing topic for status messages can be passed to the service in the initial request.  Not quite SOAP, more like what  WS-EVENTING might be if I had any code that implemented this standard.  I do recall, when using the network sniffer Ethereal to watch what axis2 is doing over HTTP, that axis2 sent an immediate response, like an HTTP OK message, and then later the response.  I don't know how you may be able to exploit this feature but it does sound like something you should look in to.

2) No I don't believe that is the case, the WSDL doesn't speak of the single/dual channel issue.  It also doesn't speak of the protocol to use for the reply.  The WSDL tells the client where the server is listening.  The client sets the reply protocol and address via WS-Addressing. The server decodes the reply address and sends the response.  This allows for an HTTP request with a JMS reply.  If the client sets the reply as blank or Anonymous, it means that the reply should return on the same single channel. An in-out MEP over JMS should never use Anonymous because the channels are one way.

3) I don't see that message traffic matters that much as JMS is high performance, at least ours is ;-).  I would focus on the complexity of the solution when choosing one over the other. Get it working first, optimize last.

Hope this helps, best of luck.

Ali Sadik Kumlali <as...@yahoo.com> wrote: Hi Roger,

Thank you very much for the reply. Your explanations are very clear and
understandable.

Actually, what I want to do is, letting the client to *immediately*
know whether its request has passed security and validation check and
accepted by the server. I thought that was only possible with the
immeadiate response over the same channel/connection. Thus, while the
server checks the correctness of the request, the client is blocked for
a short time. 

With this is in mind;

1) Is this expectation and design not well-suited? Should I also send
acknowledment message over a new channel/connection?
  1.1) If no, how can I do this with JMS?

2) If my operation in WSDL says "input-output-fault(s)", doesn't the
client code generated from the WDSL expect the output or the fault over
the same channel/connection?

3) I'm expecting significant message traffic. Is it good the client to
listen both the actual result and the acknowledgement response on the
same endpoint?

Thanks a lot,

Ali Sadik Kumlali

--- Roger Nell  wrote:

> Ali,
> I've been puttering around with axis2 and web services for a couple
> of months. I also have a strong interest in Web Services over JMS. 
> Hope the comments below help.
> 
> Synchronous means that the client blocks while the service call
> executes.
> Asynchronous means the client doesn't block while the service call
> executes, the client receives the reply via a callback.
> 
> Neither sync or async relate to the transport: HTTP or JMS, etc.
> 
> Transports can be a bi-directional over a single channel/connection
> like traditional SOAP over HTTP, or uni-directional but needing two
> channels JMS, or HTTP where the client also listens for a reply.
> 
> For dual channel, the client sends a request with the callback
> endpoint  information embedded in the soap envelope header.  In JMS
> it would likely be a client created temporary queue name.   For two
> channel operations the client must launch a listener to get the
> reply.  The server executes the requested operation and sends the
> reply or fault back to client's listener.
> 
> Axis2 has a a demonstration JMS server that can receive a SOAP calls
> over JMS, execute the operation and return the results over JMS, see
> SimpleJMSListener.java.  It took a bit of spelunking through the
> source code to get it to work as there is no documentation.
> 
> The wsdl would indicate JMS.
> 
> Hope this helps.
> 
> Ali Sadik Kumlali  wrote: Hi all,
> 
> I'm using Axis2's HTTP transport with the type of
> input+output+fault(s)
> messaging. Here is the structure of my WSDL design:
> 
> Synchronous operation:
>   - input: requestMsg
>   - output: resultMsg
>   - fault: faultMsg
> 
> Asynchronous operation:
>   - input: requestMsg
>   - output: ackMsg
>   - fault: faultMsg
> 
> As you can see, whether the client calls synchronous or asynchronous
> operation, I respond them back "synchronously" to let them know the
> server's status regarding the request.
> 
> In the near future, I might be required to support JMS transport,
> too.
> But, AFAIK, JMS is one-way messaging protocol which I don't see a way
> to send faults back synchronously.
> 
> How does Axis2's JMS transport behave to input-output-fault(s) 
> operations? Am i going to be required to change my WSDL or something
> like that?
> 
> Thanks in advance,
> 
> Ali Sadik Kumlali
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> 
>    
> ---------------------------------
> Yahoo! Mail goes everywhere you do.  Get it on your phone.



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


		
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.