5.1. Choosing a Communication Technology

Web services are only one of several ways for a client to access an application service. For example, Java applications may access application services using RMI/IIOP, JMS, or Web services. There are advantages and disadvantages with each of these communication technologies, and the developer must weigh these considerations when deciding on the client application design.

Interoperability is the primary advantage for using Web services as a means of communication. Web services give clients the ability to interoperate with almost any type of system and application, regardless of the platform on which the system or application runs. In addition, the client can use a variety of technologies for this communication. Furthermore, different client types—such as handheld devices, desktop browsers, or rich GUI clients—running on different platforms and written in different languages may be able to access the same set of services. Some applications may be designed such that their functionality is only accessible via a Web service.

Web services use HTTP as the transport protocol, which enables clients to operate with systems through firewalls. The service's WSDL document enables clients and services that use very different technologies to map and convert their respective data objects. For services and clients that are based on JAX-RPC, the JAX-RPC runtime handles this mapping transparently.

Let's look at the different communication approaches that are available to a J2EE client to access a service, including Web services, RMI/IIOP, and Java Message Service. Clients can easily use the JAX-RPC-generated stub classes to access a Web service. Although not as fast from a performance perspective as other technologies (such as RMI/IIOP), JAX-RPC gives clients greater flexibility and supports more types of clients.

J2EE application clients may also use RMI/IIOP to make remote calls over the network on application business logic. RMI/IIOP is often used for clients operating in intranet environments, where there is a greater degree of control over the client's deployment and the J2EE server. While these controlled environments provide a client container that handles the communication security, passing through firewalls can be problematic. RMI/IIOP provides clients with secure access to the application business logic while at the same time taking care of the details of the client and server communication and marshalling and demarshalling parameters.

Java Message Service (JMS) is another means for J2EE clients to communicate with server applications. JMS provides a means for asynchronous communication. Applications using JMS are better suited to a setting that is behind a firewall, since messaging systems generally do not work well on the Internet. (Often, messaging systems are not even exposed on the Internet.) Not only must developers have some knowledge of how to work with messaging systems, such as how to set up and use topics or queues, but the messaging system mechanisms must already be in place.

Although Web services provide a standard way to exchange XML documents over HTTP, you can use nonstandard approaches as well. Communication using the HTTP protocol requires only a simple infrastructure to send and receive messages. However, the client application must be able to parse the XML documents representing the messages. Parsing involves mapping the XML data to the client application's object model. When using this means of communication, the developer at a minimum needs to write code to send and receive the documents over HTTP as well as to parse the document data. If such communication must also be secure, developers would have to include code that uses Secure Socket Layer (SSL), making the development task more difficult. However, this means of communication may be sufficient, particularly in a closed environment or when clients are applets. Care should be taken if using this approach, since it is not standard.