Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Build a SOAP-based Chat Application with Java Web Services, Part 2 : Page 6

In Part 1, you built a fully-functional chat application using the Eclipse IDE and free Web services software from Systinet. In Part 2, use WASP Developer for Eclipse 4.6 to extend your original application with asynchronous messaging.


advertisement
Step III: Asynchronous Transport
The Async API alone didn't make any requirements on the server side. For it, the call was like any other ordinary synchronous call. Asynchronous transport requires the server to contain a logic that doesn't try to send the response over the connection opened by the client. Instead, this logic closes the request connection immediately, and opens a new one to the client once the response message is ready.

Obviously, the client must tell the server to behave differently in order to make a truly asynchronous transport call. Some metadata must be sent along with the request message, and the server must be able to detect it, read it, and act accordingly. WASP Server for Java uses SOAP Headers to pass metadata between parties. The solution is transport independent (imagine usage of transport protocols that don't support any extra data to be sent with the payload, like ftp, plain file on disk, RDB table etc.); and builds on existing industry standards. The information tells the server that the client's address for routing the response message is encoded via the WS-Routing SOAP Header in WASPJ. WS-Routing is a specification maintained by a couple of large Web services players (Microsoft, IBM and others) and defines the routing of SOAP messages. Here, WS-Routing tells the server to which address it should deliver the response message. Because of the widespread support of this specification, this solution is interoperable with frameworks that support it—like .NET.

The actual last step is to tell the SOAP framework to use asynchronous transports. Do this by adding this line to the client code:



serviceClient.setAsyncTransport("http");

This method tells WASPJ to make all forthcoming calls transport asynchronous. Use http as the response message protocol here because its usage doesn't need any additional configuration. You could make the response come thru POP3, JMS, whatever, but it would require a more complex setup.

When using the http case, WASPJ starts a standalone http server on the client side. The address of this client's server along with the identification of the invocation (the correlation information) is sent to the service in the form of WS-Routing SOAP Header. The server reads it, finds out it needs to use an asynchronous response, and uses this information for sending the response back to the client. Please note that this is a frameworks matter only, you don't have to make the smallest change to the existing implementation of the Web service! The full source of this truly asynchronous client is in Listing 6 (See also ServiceClientTransAsync.java in DEMO_HOME/src ).

/** * @param args the command line arguments */ public static void main (String args[]) throws Exception { ChatService service; String wsdlURI = "http://localohost:6060/ChatServiceAsync/wsdl"; String serviceURI = "http://localhost:6060/ChatServiceAsync/"; // lookup service ServiceClient serviceClient = ServiceClient.create(wsdlURI); serviceClient.setServiceURL(serviceURI); service = (ChatService)serviceClient.createProxy(ChatService.class); // now, call the methods on your Web Service interface // let's start with some synchronous calls, print the existing messages long lastMessageId; ChatMessage msgs[]; service.postMessage("Enter", "Sandman"); msgs = service.getAllMessages(); lastMessageId = msgs[msgs.length - 1].id; printMessages(msgs); //now let's wait for another messages to arrive System.out.println(">>> Client: Making the asynchronous call, " + " waiting for response to arrive..."); //1. turn on the transport asynchrony serviceClient.setAsyncTransport("http"); //initiate the async invocation; //read new messages from the server with timeout 10s AsyncConversation async = service.beginGetOrWaitforNewMessages(lastMessageId, 10000); //setup the callback that will be called when the response arrives MyCallbackClass callback = new MyCallbackClass(service); async.setCallback(callback); //the following dumb code demonstrates that the client keeps running //my callback decides if it's been enough already while (!finishedWork) { //The client now either sleeps (read "does other important work"); System.out.println(" Client: ... zzzzZZZ " + "... doing other work ... zzZZ ..."); Thread.sleep(2000); System.out.println(" Client: " + "Sending another post to the server."); service.postMessage("Wake Up!", "Sandman"); } //2. clean up, release all resources, stop the http server Wasp.destroy(); System.out.println("--- Client: All work done, exiting."); }

  1. Tell the WASPJ framework to use transport asynchrony for all forthcoming calls.
  2. As the server was started in the client transparently, you now have to shut it down (otherwise there are running threads left and the client never shuts down completely).
And that's it! You now have a fully asynchronous client implemented. Start it and see if it works. Please note that the client's internal WASPJ server is running on port 7070. If this port is already in use, the client-side server (haven't I said that the differences between clients and server diminish under asynchronous communication? What a strange-looking term: "client-side server") won't start and the demo will not work.

If you still yearn for more code, the final version of the client—with multiple calls and multiple responses—can be found in Listing 7. See also ChatServiceClientBeastAsync.java in DEMO_HOME/src. Don't blame me if you cannot read this code easily! You've been warned!

Asynchronous Reality
Asynchronous invocation in the world of Web services is a reality. With the appropriate tools, there's nothing to fear. Standards are already available, and allow you to build asynchronous heterogenous solutions that are mutually interoperable—and more standards are coming soon. In the near future, we will see a rise of asynchronous messaging, as it is one of the building blocks of a future where documents (not RPC calls) will be the major transport vehicle for business-to-business integration.



Petr Dvorak is the Director of Product Development at Systinet Corporation. Reach him at petr.dvorak@systinet.com.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date