provider could use one of the XML programmatic API s. Elements of this mes-
sage can be processed sequentially, so we could probably get by with the Sim-
ple API for XML ( SAX ). If instead the provider needed to construct the entire
tree to process the elements of the message out of sequence, the provider
would probably need a more robust API , such as the DOM API .
We also have some flexibility in managing changes in the interface. We can
add processing steps at the client or server to translate between different XML
formats, or even convert to a format that is not XML at all by using Extensible
Stylesheet Language Transformations ( XSLT ). We could even use XSLT to
translate this message format to a valid communication block for an older
interface. XML , combined with the incredible flexibility and tools at the client
and server sides, lets us decouple important interfaces.
Solution 2: Delay binding with web services
XML allows us to decouple interfaces by adding an abstraction layer and struc-
tural clues to the message. We also have a technology that addresses the prob-
lem of premature binding: web services let us describe our interface as a
service that clients can register and bind. The interesting part of this process
for us is delayed binding .
Figure 7.8 shows how this works. The provider describes a service in an
XML -based markup language called Web Services Description Language
( WSDL ), and publishes the interface in a distributed registry. The requester
can search the registry for a service and then bind to the service. The standard
for the open registration of resources is called Universal Discovery Description
and Integration ( UDDI ), which specifies a common XML description of an
Figure 7.8 Web services loosen coupling between the provider and the requester by delaying the
binding process. Providers publish their service in a distributed registry. Requesters can then
search the registry for an appropriate service. When one is found, the service is bound between the
requester and provider.