Win a copy of Practical SVG this week in the HTML/CSS/JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Axis2 asynchronous communication

 
jonathan Greens
Ranch Hand
Posts: 139
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
dear folks,
I want to be able to start a process from java client, then periodically checks the status of this process until it's done. But for some reason, when client checks the status code, it never changes... On the server side the status code does change. see code for detail:
My server side code:

client side code:


console logs:
server:
0.1
0.2
.
.
.
1.0

client:
0.0
0.0
0.0
.
.
result received mytest
0.0

what's wrong?
thanks!
 
jonathan Greens
Ranch Hand
Posts: 139
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok I found out the cause, every time I make a webservice call from the client, say reportGenerate.getProgress(), the server creates a new instance of ReportGenerate to handle the request..
how do I solve this issue?
 
Stella Lok
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

You need to set the scope of your service to Session, so that the same instance will be used throughout your client's calls.

Check out this link: http://www.developer.com/java/web/article.php/3620661
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"Guybrush Threepwood",

Please check your private messages.
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You need to set the scope of your service to Session, so that the same instance will be used throughout your client's calls[/URL]


While this may work it may also limit the usefulness of the Web Service for non-Axis 2 clients. The use of the "session" is Axis 2 specific and doesn't appear anywhere in the WSDL - the service contract.

I see this as a design problem. You need to separate your service application class from the class that handles the web service interface and the data (un)marshalling. The service application class exists while the system is up and running, while the web interface class is only created on a per request basis. Obviously your service application class has to be capable of handling multiple processing requests simultaneously. The web service interface class on the other hand would, based on the nature of the (SOAP) request, initiate, monitor the progress or finally obtain the result of its particular processing request.

To do that the (SOAP) request needs to use a correlation Identifier. The correlation identifier is returned by the service application class when a new "processing request" is initiated. The correlation identifier must be sent with the progress and result (SOAP) requests so that the application knows which processing request you are referring to. That also means that the correlation identifier is now part of the service contract (WSDL) - so now non-Axis 2 clients should be able to use it too.

Typically web services are supposed to be stateless (which is why Axis gets a new web service interface class for each request). However the use of a correlation identifier is the one accepted (interoperable) solution when the lifetime of the "processing request" exceeds that of the (SOAP) communication request.

Pattern 3: Request/reply operations with polling
 
jonathan Greens
Ranch Hand
Posts: 139
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thank you both for the wonderful solutions. I understand the state of session management a bit more now.
Regarding the use of session in axis2, I tried the steps in the article, but it doesn't work. new instances of the application class still gets instantiated for every remote call i invoke from the client.
on client I did _serviceClient.getOptions().setManageSession(true);
on server in services.xml <service name="ReportGenerate" scope="soapsession">

here's the asynchronous method call the client stub:


am I missing something?
thanks
[ September 26, 2007: Message edited by: jonathan Greens ]
 
jonathan Greens
Ranch Hand
Posts: 139
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Right now I am polling the server for status every second. Is it possible to have server send the status message to the client? and then the client can handle this message in its onMessage callback function? In axis2, the result of the function call can be get asynchronously from onMessage callback, but is it possible to explicitly send messages from the server before the final result is sent?
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by jonathan Greens:
Is it possible to have server send the status message to the client?


Simple answer: No.
The HTTP protocol provides no means for a web server to contact a web client.

Workarounds:
  • Keep the request open until you have the result. This is essentially a synchronous call.
  • Require that the web client supply a web server address to send the result to.



  • The second workaround requires that your "web service client" knows a "web service" that can accept the result and get it back to the client.

    BEA specified a SOAP conversation protocol to use this particular workaround.
    More recently the Web Services Addressing Protocol (WSA) is being used to accomplish the same end. Axis 2 supports WS-Addressing.

    However look at the ramifications:
  • The client has to support WS-Addressing in one way or another.
  • The client has to provide a return URI of a web service capable of accepting the result and "knows of a way" to get it back to the client.
  • Just because the client can connect to the service provider doesn't mean the service provider can connect to the provided URI. Typically in cases where the client runs its own embedded web server, firewalls and proxies will often prevent the service provider from reaching the client.


  • So really you are better off with Pattern 3: Request/reply operations with polling. However I would suggest that you include a "don't bother me for N seconds" in your submission/status response so that a co-operative client can back off. To guard against less co-operative clients place a handler in the request handler chain that bounces the status request with a SOAP fault ("you didn't wait your turn!") if they don't wait long enough (and the result isn't ready yet).

    You really are looking at three client actions:
  • Submitting the processing request.
  • Obtaining the processing status.
  • Obtaining the result.


  • You may be tempted to reduce that to:
  • Submitting the processing request.
  • Obtaining the result (with a not-ready-yet response)


  • However the three stage approach is simpler in that you do not have to design the result response message to also accommodate the "result not ready please wait another N seconds" scenario - you can simply issue a SOAP fault ("Did I tell you that the result was ready yet?").

    There should be no problem to expose this as a document/literal web service. The submission request, status request, and result request message should be distinctive enough not to require the web method names of RPC/literal. (And even it they contained the same data the XML element names would differentiate them).
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!