RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Build a SOAP-based Chat Application with Java Web Services

This introduction to Web services eschews the canonical "stockQuote" service in favor of a more complex and more informative SOAP-based chat application. Learn how to develop a fully-functional application using the Eclipse IDE and free Web services software from Systinet.

here are many definitions of what Web services are or should be, each more or less understandable. It's interesting how sometimes the simplest things are the hardest to describe. With that in mind, here's yet another take: a Web service is an entity that can exchange documents with the outer world. This entity is self descriptive and possesses a unique identity.

The document content is XML; strictly speaking SOAP. SOAP (Simple Object Access Protocol) defines the internal structure of the XML documents that Web services consume and produce. Web services speak SOAP. SOAP is recognized as an industry standard and is widely adopted across many boundaries—across software vendors, hardware platforms, operating systems or programming languages.

Every Web service has a home. This is its identity. The address is defined by a URI (also known as a URL). A Web service lives at and is identified by its URI. This address is often called an endpoint. The identity has nothing to do with security in this context. The service used in this tutorial lives at http://localhost:6060/ChatService/.

A Web service carries its own description. This tells you what kinds of documents it exchanges (the interface definition). It says where the service lives (the URI address). And it also says which transport protocols it can use for the exchange of the documents (the binding). The language used for the Web services description is WSDL (Web services Definition Language). A Web service is completely described by its WSDL document. You only need the WSDL document in order to communicate with a standalone Web service. Though WSDL describes the Web service in its own context, it says nothing about orchestration of multiple Web services.

A Web service has a home, but you need to find where it lives in order to visit it. In other words, you need a telephone book listing Web services. UDDI (Universal Description, Discovery and Integration) is the industry standard telephone book. UDDI deals with registering and discovering Web services.

Putting it all together, a Web service is an entity that exchanges SOAP documents with the world, is located at some URI, is described with a WSDL document, and can be listed and discovered in the UDDI registry.

A Dose of Reality
Countless types of documents can be sent to and received from Web services. It can be a periodic temperature report in a steel mill, it can be a tax refund request defined by the local government, or it can be a document style representation of an RPC call from one software component to another one. The same applies to the exchange scenarios. You can imagine one-way messages, or request-response messaging where a request document must be followed with the response document, or even completely asynchronous messaging where a single subscription to a service results in the periodic delivery of information. Most of the current usage of Web services follow the RPC over XML pattern. The reason for this is obvious—developers can "turn-into-Web-services" existing applications without significant code modifications, or create clients for Web services with minimal effort. Web services frameworks often hide the complexity of the underlying infrastructure. They usually provide tools for language-to-WSDL and WSDL-to-language generation. Exposing language constructs as Web services is much faster and simpler than manually dealing with XML documents. Today, Web services are frequently used as an integration tool that lets developers and system architects interconnect heterogeneous applications.

Though the Web service and its clients in this article follow the RPC over XML pattern, the application field of Web services is much broader. In the near future, there will most likey be more and more implementations based on pure document exchange patterns that are more loosely coupled.

A Simple Chat Server
In this article, I've attempted to create an application that is more challenging than the famous stock quote service, but is still easy to read and understand. It is a chat server application. The functionality of the chat server is very simple—clients either post new messages and/or read them.

This chat server implementation is completely orthogonal to WASP and Web services. It can be successfully compiled and used in any other Java environment. This chat server also represents pre-existing business logic. Feel free to examine the code to understand. You can download the source code for the chat implementation (but not the Web service, which isn't written yet) here.

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