The XML You Need to Know for Web Services, Page 2
XML Liberates Data
XML constrains a Web service in the same ways a development platform or programming language constrains an application. For instance, if I develop an application in C++, the coding of the program is where I manage data within the application with respect to data types and structures. In the world of Web services, you want (and need) to decouple data type and structure from the traditional type-reference-in-memory paradigm that for years has stood in the way of common data, shareable across multiple apps. XML stores type information independently, moving it beyond the applications that want to use it.
There's a minor inefficiency associated with this. Consider that the type information needed to handle XML-populated data elements isn't part of the application that's handling the data, so it isn't initially in memory; it must be accessed separately. This represents some overhead, and in the case of multiple clients accessing the Web server hosting the app repeatedly, it's the same overhead invoked over and over.
Defining the Web Service Itself
A typical Web service is, for all practical purposes, built out of XML components.
The fundamental component in the XML web service paradigm is the data-bearing instance of the XML document that constitutes a message to, or from, the Web serviceit's the reason the Web service exists in the first place. Then there's the schema that defines (and validates) that message's format, the SOAP envelope.
But that's only the beginning. The Web service itself constitutes an interface, and all interfaces must be unambiguously defined for all parties using them to be effective. In the world of Web services, this is accomplished with WSDLWeb Service Description Language.
WSDL effectively standardizes how Web service interfaces can be described, in terms of formats and protocols used. Because WSDL exists, it is not necessary to create any special components to talk to any of the endless servers that are out there on the Web, hosting Web services. As with the schemas defining XML documents, WSDL enables any two parties using it to share and implement an interface definition, enabling conversation between them.
And this in turn necessitates two more XML components that comprise Web services. There's an XML schema bearing the WSDL that validates a Web service's interface definitionand then there's the XML instance document that actually establishes the interface.
The Role of the Namespace
Once you've jumped into the world of XML Web services, you'll rapidly accumulate XML documents of various types, and it will become obvious that their organization is a key to the success of both XML as a medium for data storage and definition, and Web services as a medium for processing and transport.
This organization is achieved through the use of the namespace. A namespace-qualified element names within an XML document, and as you might guess, a Web service often handles multiple related documents at the same time (for example, a SOAP envelope schema, a WSDL schema, and the data-bearing instances of both). It is not only possible for such documents to carry elements with the same names, it's inevitable. Namespaces differentiate those data element names by specific document.
Namespaces have other uses. They can serve as keywords to specify semantic processing; they can also be used as application-specific prefixes in Web services with many application components.
Typically, a namespace is a URI (see Figure 4), although it doesn't have to be. Part of the rationale for using URIs as namespaces is that they are likely to be unique (note that XML parsers generally will not validate this uniqueness; it is assumed).
Finally, namespaces facilitate the enforcement of desired XML processor functions. If you put the SOAP encoding namespace in a SOAP message, the processor must serialize the message according to the encoding mechanism described in the specification.
Figure 4: Typical XML Namespace attribute.
XML as Schema (the *.xsd File)
The XML schema is basically a contract, agreed-upon by a Web service and those clients that interact with it, as to what any XML instance submitted to the site (or emanating from it) must look like. Its power is that it is external to the Web service as such.
Why is this so? Consider that a schema is generally an in-house description of one company's data storage. A database schema, for instance, describes tables used in your particular company, and is internal to your systems. An outside entity will generally not have use of your local schemas, but will have its own; we tend not to share them. Remapping, then, is generally both essential and cumbersome, and specific to a relationship between two companies.
But when an XML schema is external to a Web service, it is available to any and all partners that might use the Web service; remapping is no longer a one-to-one proposition between two parties, but a more economical mapping to a shared central point. It's far better for your company, implementing the Web service, because you have only to produce the single schema for all to use, rather than a unique remapping for each partnership.
In addition, an XML schema is (as opposed to its database-specific cousin) rapidly configured and even more rapidly modified. And these modifications represent little burden in upgrade; companion technologies (see XSLT above) enable rapid transition from an old schema to a new one.
Roll Up Your Sleeves
If you're moving into the world of Web services, you'll want some hands-on, get-acquainted time with XML. You can get additional information on this at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/webservbasics.asp.
About the Author
Scott Robinson is an IT consultant to the U.S. manufacturing, brokerage, healthcare and biotech industries. He has managed design teams sponsored by the Department of Defense and the Department of Energy, and has worked with academic research groups. He is vice president of development at Quantumetrics, Inc.
Page 2 of 2