Java Reference
In-Depth Information
Considering the Architecture
In practice, the term
web service
has come to apply to just about any machine-to-
machine communications application that makes use of web technologies. More than
just shorthand to describe a certain class of application, this designation is appropriate
as the paradigm has evolved.
In large-scale environments, a web service's division of responsibilities, as shown in
Figure 13-1, is important. However, in many situations, the division of responsibilities
can be (and has been) simplified to reflect differences in requirements and computing
environments.
One of these simplifications is the removal of the broker, or the combination of the
broker and service provider. In this model, clients have a predefined notion of the loca-
tion and nature of the services provided by service providers. This is especially true for
many mobile clients, because the complexity and overhead of dynamic discovery and
capability negotiation can add significantly to the memory costs of an application.
Another way to categorize web services is by looking at the nature of the interaction
between client and server. Broadly speaking, there are three categories of interaction:
remote procedure call (RPC) services, service-oriented architecture (SOA) services, and
services that use representational state transfer (REST). I like to think of these as taking a
functional approach, a messaging approach, and a resource approach, respectively.
RPC-oriented web services are among the most common, and their semantics date
back to pre-Web client/server programming in which a client requests a remote server
to execute a specific operation. The semantics of encapsulating a request and response
typically vary from service to service; small services make great use of simple XML rep-
resentations for objects and requests, while more complex applications almost always
use SOAP to represent objects.
■
Note
The Java RMI you first saw in Chapter 11 is another example of an RPC interface.
SOA web services are among the largest and most complex, and SOA is widely sup-
ported by many industry vendors today. Unlike RPC, in which the primary concept is that
of a method call that is typically tightly coupled with the underlying implementation and
domain, SOA represents requests as messages. In other words, its focus is on messages,
not operations. SOA can provide many advantages when implementing large-scale web
services between many different subsystems or organizations. SOA web services use
SOAP—an XML representation of objects for data interchange—and WSDL to describe
the kinds of services a server or client offers or needs.
Finally, web services based on REST attempt to use the range of methods provided by
HTTP to describe the kinds of operations a client may request a service to perform on
documented objects. A hallmark of RESTful web services is the presentation of well-
known URLs that represent objects, rather than operations, services, or a general
