Browse DevX
Sign up for e-mail newsletters from DevX


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

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.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

art 1 of this tutorial provided a light introduction to the world of Web services. You created a simple SOAP implementation of a Simple Chat server. You also created a client that consumes the chat server's services. This second tutorial extends the original concept of the SimpleChat server with asynchronous messaging.

Asynchronous Invocation
For those new to distributed computing as well as Web services, asynchronous invocation is among the most valuable tools at a developer's disposal when it comes to fine tuning and removing bottlenecks from the system. In the ChatService tutorial, the client application process sends its request to the service and waits for the response message before continuing. This type of synchronous behavior can result in high performance penalties if you're expecting high messaging latency on your network system, either because of traffic congestion, call failures, or server-side delays in processing the response. A more efficient use of client side resources is to send a request and then move the client process along. Later, you can either poll for the response or handle it as a callback reduces traffic and makes. These and related approaches are called "asynchronous invocation." For a more complete and very useful discussion of asynchronous invocation, see Jack Shirazi's Java Performance Tuning.

In the context of the WASPJ framework, there are two levels of asynchrony, which are mutually orthogonal. The first one focuses on the client's application logic, and is purely client-side efficiency driven. In this scenario, the client consumes a service's business logic that has a long latency. The client doesn't want to wait idle for the response to arrive. Instead, it wants to call the invocation framework in a non-blocking mode, letting the framework efficiently handle the long-running transaction and to then be notified when the result is ready. This dimension is called "API asynchrony", because it is often established with a special non-blocking invocation APIs.

The second level focuses on the physical means of communication between the two parties, or, the "Transport asynchrony." In the transport synchronous scenario, two parties access an open direct communication channel for exchange of messages. When using transport asynchrony, there's no single channel for transmission of both the request and response messages. Instead, the user uses one connection (or some messaging service) to send the request. The service then processes the request, and uses another connection to send the response. A classical example of asynchronous transport communication is the exchange of emails. Transport asynchrony lessens the differences between how "client" and "server" are traditionally understood. The client itself must be able to behave like a server. It must have its own unique address where it listens for the (response) message to arrive.

In the end, these two aspects create four combinations. All of them have their use case. Sync/sync is obvious. Asynchronous API over synchronous transport can be used when it is affordable to keep the direct connection open for some (not exceedingly long) amount of time. Synchronous API over asynchronous transports is used when there's no way to create a direct communication channel between the two parties (firewall, limited availability of one of the parties, missing physical direct link, etc.). Finally, the asynchronous API and asynchronous transport are used in the truly asynchronous loosely coupled environment, where the business transactions can take long time to complete. This demo is modeled in a fully asynchronous environment.

Sync/Async Advantages


API Sync

API Async

Trans. Sync

Simple and straight forward to implement

Saves Client resources but not network ones

Trans. Async

Useful when communication is unreliable or must be indirect (i.e. Firewall)

True loosely coupled solution where processes can be long running and traffic heavy

Comment and Contribute






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



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