SOAP Web Services
ormerly considered a buzzword, Service-Oriented Architecture (SOA) today forms part of
day-to-day architectural life. However, sometimes it is confused with web services. SOA is an
architecture principally based upon service-oriented applications that can be implemented
with different technologies such as web services.
Web services are said to be “loosely coupled” because the client of a web service doesn’t
have to know its implementation details (such as the language used to develop it or the
method signature). The consumer is able to invoke a web service using a self-explanatory
interface describing the available business methods (parameters and return value). The
underlying implementation can be done in any language (Visual Basic, C#, C, C++, Java, etc.).
A consumer and a service will still be able to exchange data in a loosely coupled way: using
XML documents. A consumer sends a request to a web service in the form of an XML docu-
ment, and, optionally, receives a reply, also in XML.
Web services are also about distribution. Distributed software has been around for a long
time, but unlike existing distributed systems, web services are adapted to the Web. The default
network protocol is HTTP, a well-known and robust stateless protocol.
Web services are everywhere, and they can run on desktops or be used for business-to-
business (B2B) integration so that operations that previously required manual intervention
are performed automatically. Web services integrate applications run by various organizations
through the Internet or within the same company (which is known as Enterprise Application
Integration, or EAI). In all cases, web services provide a standard way to connect diverse pieces
Understanding Web Services
Simply put, web services constitute a kind of business logic exposed via a service interface to a
client application (i.e., a service consumer). However, unlike objects or EJBs, web services pro-
vide a loosely coupled interface using XML. Web service standards specify that the interface
to which a message is sent should define the format of the message request and response, and
mechanisms to publish and to discover web service interfaces (a registry).
In the Figure 14-1, you can see a high-level picture of a web service interaction. The web
service can optionally register its interface into a registry (UDDI) so a consumer can discover
it. Once the consumer knows the interface of the service and the message format, it can send a
request and receive a response.