XML makes possible the implementations that were anticipated during the years when SOA was just a subject for academic review:
As you develop a service
you're likely to use XML to describe the service interface
you may use XML to create the logic itself (as you'll see in Chapter 7, when we describe BPEL)
in relation to Web services, you may access the transmitted data using technologies such as XPath, which require knowledge of the XML-based message format
After you develop a service, you may use XML to store the service contract in a registry.
At configuration time, you may use XML to configure the service, even to the extent of assigning different values to variables inside the service implementation. That degree of configurability is shown in Chapter 9, when we describe Service Component Architecture.
At Web-service run time, the transmitted data is simply text in an XML format, and XML engines convert the data at the transmission endpoints, as Figure 4.1 illustrates.
Figure 4.1: XML engines at Web-service run time
At a transmitting endpoint, an XML processor converts a message into the format required for transmission. At the receiving endpoint, another XML processor converts the message from the transmission medium into the local format.
In the absence of a universal format like that provided by XML, an SOA runtime product would need to act in one of two ways to support Web services. The product could handle data conversions as needed to transform data from each endpoint-specific format directly to every other one. With this approach, the addition of a new kind of endpoint would require significant updates to the runtime product. Alternatively, the product would restrict the computer languages used in the participating endpoints.
XML has a cost. Use of text rather than a binary format slows processing and requires more disk space. An SOA runtime product can reduce the cost of transmission by compressing each XML-based message, but time is required for data conversion in any case.