XML Schema (W3C 2001d, W3C 2001e) is a language used with XML specifications to describe data’s structure, the constraints on content, and data types. It was designed to provide more control over data than was provided by DTDs that use the XML syntax. While XML Schema and DTDs are not mutually exclusive, XML Schema is regarded as an alternative to DTDs for specifying data types. SOAP, which we will discuss later, explicitly prohibits the use of DTDs.
In many ways, XML Schema makes XML interesting. XML provided two ways to aggregate elements: sequence and choice. A sequence of elements requires that each element of the sequence appear once in the order specified. Choice requires that a single element be present from a list of potential elements. With XML Schema, the
language designer can specify whether an element in a sequence must appear at all,
minOccurs, or whether there is a maximum number of appearances, maxOccurs. XML Schema datatypes are primitive or derived. A primitive datatype does not depend on the definition of any other datatype. Many built-in primitive datatypes have been predefined by XML Schema. They include integer, boolean, date, and others. Derived datatypes are other datatypes that have been constrained, explicitly listed, or combined (the actual term used in the specification is “union”). Constrained datatypes take an existing datatype and restrict the possible values of the datatype. The derived datatype belowSixconsists of integers restricted to values between 0 and 5. The restriction on the datatype is called a facet. A datatype may consist of a list of acceptable values. A datatype of U.S. coins contains penny, nickel, dime, and quarter. The union of U.S. coins with U.S. paper denominations results in all United States currency denominations.
XML Schema is useful for several reasons. First, the built-in datatypes of XML Schema support the precise definition of data. With facets, schemas can constrain the values of XML data. Finally, a definition that is more precise can be achieved with derived datatypes. Once a schema has been defined, schema processors are able to val- idate a document to ensure that the document corresponds to the schema’s structure and permissible values. This checking can eliminate a source of many of the vulnera- bilities that plague Web-based systems.
We have modified the purchase order example to show some of the features we’ve just discussed. Up until now, we have conveniently avoided discussing lines 2– 4 of the example. What they do is identify this XML document as an XML Schema document that defines the namespace http://www.widgets.com. Line 4 also declares the default
scope of the names in the schema to be www.widgets.com. We’ve been using XML
Schema all along. In this example, each of the elements is now associated with an appropriate data type. In addition, we have specified that the itemDescriptionelement is optional and does not have to be in the sequence.
<?xml version=”1.0” encoding=”UTF-8”?> <xs:schema targetNamespace=”www.widgets.com” xmlns:xs=”http://www.w3.org/2001/XMLSchema” xmlns=”www.widgets.com” elementFormDefault=”qualified” attributeFormDefault=”unqualified”> <xs:element name=”order”> <xs:complexType> <xs:sequence>
<xs:element name=”orderNum” type=”xs:string”/> <xs:element name=”itemDescription” type=”xs:string” minOccurs=”0”/>
<xs:element name=”quantity” type=”xs:integer”/> <xs:element name=”unitPrice” type=”xs:decimal”/> <xs:element name=”aggregatePrice”
type=”xs:decimal”/>
</xs:sequence>
<xs:attribute name=”currency” type=”xs:string”/> </xs:complexType>
</xs:element> </xs:schema>
There are many other aspects to XML Schema. A good overview is contained in XML Schema Part 0: Primer(W3C 2001c). XML Schema are placed in a separate schema doc- ument so that type definitions can be reused in other XML documents. This can lead to
confusion when the term XML schemais used. This confusion is comparable to what
occurs when XMLis used. When a separate XML schema document is used, references
to the XML schema instance must be namespace qualified so that the XML schema processor can determine that a separate schema instance is being referenced. This is usually done by declaring an XML namespace using an attribute with xmlns:for a suf- fix. The location of the schema instance can be declared eliminating any possibility of ambiguity. We’ve been declaring the namespace in our order examples using the
xmlns:attribute.
The advantage of using this schema is that there are schema processors that check the values of elements to ensure that the values comply with the facets in the schema. This reduces the possibility of using improperly formed input as a means of compro- mising the security of an XML-based system.
SOAP
We are now ready to discuss SOAP. SOAP is a unidirectional, XML-based protocol for passing information. (As of draft version 1.2, SOAP is no longer an acronym.) Despite
being unidirectional, SOAP messages can be combined to implement
request/response processes, or even more sophisticated interactions. In addition to the sending and the receiving nodes of a SOAP message, SOAP message routing includes intermediary nodes. SOAP intermediaries should not be confused with intermediaries in any underlying protocol. For instance, HTTP messages may be routed through inter- mediaries. However, these intermediaries are not involved in the processing of SOAP messages. SOAP intermediaries play a role in the handling or processing of a message at the application level.
SOAP describes an XML-based markup language “for exchanging structured and typed information.” The information passed in a SOAP message can either represent documents or remote procedure calls (RPCs) that invoke specific procedures at the ser- vice provider. A SOAP document could be a purchase order or an airline reservation form. On the other hand, an RPC can invoke software to charge a purchase. There are no clear guidelines to determine when a document or an RPC should be used. The sys- tem designer will make this decision.
Web Services using SOAP have gained popularity very quickly. The concept of an XML RPC was created in 1998 by David Winer of Userland Software. The XML-RPC specification was released in 1999 and was the work of Winer, Don Box of Develop- Mentor, and Mohsen Al-Ghosein and Bob Atkinson of Microsoft. While the specifica- tion was published as XML-RPC, the working group adopted the working name SOAP. Soon after, SOAP .9 and 1.0 were released. In March 2000, IBM joined the group and worked on the SOAP 1.1 specification. The 1.1 version was adopted by the W3C as a recommendation. SOAP version 1.2 currently exists as a series of working drafts (W3C 2002e, W3C 2002f). In addition to the working drafts, there is a SOAP 1.2 Primer (W3C 2002d) that takes the information in the working drafts and describes SOAP fea- tures using actual SOAP messages.
The discussion in this section is based on the SOAP 1.2 working drafts. The discus- sion is not meant to be all encompassing and is a brief overview of the protocol. The reader should consult the W3C drafts or other books on SOAP to get further details.
As with any other protocol, there are two portions to the SOAP Protocol: a descrip- tion of the messages that are to be exchanged, including the format and data encoding rules, and the sequence of messages exchanged. As the reader will see, there isn’t a lot of specificity to SOAP. This is by design. Rather than overspecifying and trying to anticipate every possible outcome, the SOAP designers took a minimalist approach. SOAP specifies the skeleton of a message format—very little else is required. This approach allows messages to be tailored to application-specific uses. In addition to the protocol, there are protocol bindings that describe how SOAP can be transported using different underlying transport protocols. Currently, HTTP is the only underlying pro- tocol with a binding referenced in the SOAP specification, but others are possible and not excluded by the specification.