What Can It Help?

We've heard how great XML is, how it helps with certain issues, and seen a few examples, but what does this mean? What types of difficulties does it solve, how does it solve them, and why is XML the solution for these issues? These are questions that we need to ask ourselves before choosing XML as our solution-providing method. We need to be sure it is the right means to provide integration points with our applications, or descriptions and structure to our content.

In this section we will talk about specific uses of XML and how they work. Because most of these concepts will be applied in greater detail later in the book, these example cases will not cover every detail of the code involved. What is important to understand after completing this section is that XML can be used in the creation of objects, application messaging, and process modeling.

Working with Objects

Those of you familiar with the principles and practices of object-oriented programming will have added respect, and probably motivation, for creating items in an object-oriented manner. Doing so allows for a degree of flexibility and potential component reuse that is not possible when operating in a non-object environment. XML is no different and has its own object-like implementations and uses. We will cover these in the following sections.

Modeling

Soon after XML 1.0 was released, gaps in the language were filled with complementary standards. One such limitation of XML was the inability to present data in an object-oriented manner. To help fill this void, a Note at the W3C was published titled "Schema for Object-Oriented XML (SOX)". This Note, which became an important part of the foundation that was used to build XSD, extended XML 1.0 by supporting the following six items. (Because we cover XSD in Appendix A, we use SOX in this example.)

SOX makes it possible, for example, to create a home computer object that contains a monitor, housing (CPU, RAM, hard disk, and so forth), speakers, a keyboard, and a mouse. The definition of this schema shown, in Listing 1-8, home_computer.sox, gives you the ability to create documents describing various home computers but does not allow you to describe another type of computer that might have more options.

Because SOX enforces a valid Uniform Resource Identifier (URI), we must include the file:// portion of the URL in the <schema> element. For this example we have placed the schema on the S: drive of a Windows machine, so please adjust this attribute value for your system.

Listing 1-8 home_computer.sox: A schema describing our home computer.

<?xml version = "1.0" encoding = "UTF-8"?>
<!DOCTYPE schema SYSTEM 
  "urn:x-commerceone:document:com:commerceone:xdk:xml:schema.dtd$1.0">
<schema uri = "file:///S:/home_computer.sox" soxlang-version = "V0.2.2">
	<elementtype name = "home_computer">
		<model>
			<sequence>
				<element type = "monitor"/>
				<element type = "housing"/>
				<element type = "speakers"/>
				<element type = "keyboard"/>
				<element type = "mouse"/>
			</sequence>
		</model>
	</elementtype>
	<elementtype name = "monitor">
		<model>
			<string/>
		</model>
	</elementtype>
	<elementtype name = "housing">
		<model>
			<sequence>
				<element type = "cpu"/>
				<element type = "ram"/>
				<element type = "disk_space"/>
				<element type = "modem"/>
			</sequence>
		</model>
	</elementtype>
	<elementtype name = "speakers">
		<model>
			<string/>
		</model>
	</elementtype>
	<elementtype name = "keyboard">
		<model>
			<string/>
		</model>
	</elementtype>
	<elementtype name = "mouse">
		<model>
			<string/>
		</model>
	</elementtype>
	<elementtype name = "cpu">
		<model>
			<string/>
		</model>
	</elementtype>
	<elementtype name = "ram">
		<model>
			<string/>
		</model>
	</elementtype>
	<elementtype name = "disk_space">
		<model>
			<string/>
		</model>
	</elementtype>
	<elementtype name = "modem">
		<model>
			<string/>
		</model>
	</elementtype>
</schema>

Figure 1-6 is a visual representation of this schema.

Figure 1-6 A visual representation of our home computer data model.

This data model is fine if we only define home computers, but what happens if we want to define a work computer? Using SOX we can build such an object by extending our base <home_computer> element as shown in Listing 1-9. If we link in our home_computer.sox schema, define a new element called <work_computer>, and say it extends <home_computer>, we are able to add items like a printer, scanner, and zip drive. This new schema, work_computer.sox, now inherits all the elements in the original schema and requires only that we define the additions.

Listing 1-9 work_computer.sox: A new schema extending our home_computer.sox schema.

<?xml version = "1.0" encoding = "UTF-8"?>
<!DOCTYPE schema SYSTEM 
  "urn:x-commerceone:document:com:commerceone:xdk:xml:schema.dtd$1.0">
<schema uri = "file:///S:/home_computer.sox" soxlang-version = "V0.2.2">
	<join system = "file:///S:/home_computer.sox"/>
	<elementtype name = "work_computer">
		<extends type = "home_computer">
			<append>
				<sequence>
					<element type = "scanner"/>
					<element type = "zip_drive"/>
					<element type = "printer"/>
				</sequence>
			</append>
		</extends>
	</elementtype>
	<elementtype name = "scanner">
		<model>
			<string/>
		</model>
	</elementtype>
	<elementtype name = "zip_drive">
		<model>
			<string/>
		</model>
	</elementtype>
	<elementtype name = "printer">
		<model>
			<string/>
		</model>
	</elementtype>
</schema>

Figure 1-7 provides a representation of this new schema so you can compare it to the home_computer.sox schema.

Now that the work computer schema is defined, we can create an instance document of this schema. Because SOX-compliant parsers will pull in the necessary parent schemas, we only need to reference the work_computer.sox schema in our example shown in Listing 1-10.

Listing 1-10 first_work_computer.xml: An instance of our work_computer.sox schema

<?xml version = "1.0" encoding = "UTF-8"?>
<?soxtype file:///S:/work_computer.sox?>
<work_computer>
	<monitor>15 inch</monitor>
	<housing>
		<cpu>1 GHz</cpu>
		<ram>256 MB</ram>
		<disk_space>60 GB</disk_space>
		<modem>56k</modem>
	</housing>
	<speakers>JBL</speakers>
	<keyboard>Microsoft</keyboard>
	<mouse>Microsoft</mouse>
	<scanner>Microtek</scanner>
	<zip_drive>100 MB</zip_drive>
	<printer>HP</printer>
</work_computer>
Figure 1-7 A visual representation of our new schema base on our home computer schema.

Object modeling allows you to reuse components of XML schema dialects, like SOX or XSD, which can lead to increased productivity within your development environment by cutting down on redundant work.

Procedure Invocation

Invoking new derivative classes of XML objects is not the only way you can use XML in an object-oriented manner. The ability to invoke a procedure on a different system using XML is also possible with several standards, such as Simple Object Access Protocol (SOAP), which we cover in Chapter 14, and XML-Remote Procedure Call (XML-RPC). Both standards represent a way you can pass information to an object (an application in many cases), process the information, and return the results.

RPC allows you to tap another machine, application, or device for its functionality, creating a virtual application to perform a given task. RPC is not a new concept, so many of you might have some experience working with it. XML-RPC, however, is relatively new.

XML-RPC is a simple specification that uses a Hypertext Transfer Protocol (HTTP) POST request to pass a set of commands, parameters, and so forth to a remote object. This request, which is broken into a header and payload, is then processed by the remote application. A response is returned once complete, which could contain either the results of the processing or an appropriate error. Let's walk through an example to help describe the requirements of XML-RPC.

While the request is a standard HTTP POST, XML-RPC dictates that the following items must be contained in the head of the request. Note that the traditional first line of an HTTP request, which contains the method (POST), requested URI (such as /scripts/xml-rpc-processor.exe) and protocol version (such as HTTP/1.1), is implied in this list, so we will not list these requirements separately. A sample is included after the list.

User-Agent: SomeApp/1.1 (Windows XP)
Host: database.example.com
Content-Type: text/xml
Content-length: 361

The body of the request contains the elements necessary to identify the procedure as well as pass in any arguments. In rpc-request.xml shown in Listing 1-11, we will use an application called validateUser.exe and we will pass it a first name and age parameter. Although this is a fictitious application, it could represent an application that validated a user's access, by name and age, against certain information. Note that the server processing the XML-RPC request would need to know what validateUser.exe was or where it was located; it would need to be able to launch the application.

Listing 1-11 rpc-request.xml: An XML-RPC request document.

<?xml version="1.0"?>
<methodCall>
  <methodName>validateUser.exe</methodName>
  <params>
    <param>
      <value>
        <struct>
          <member>
            <name>FirstName</name>
            <value>
              <string>John</string>
            </value>
          </member>
          <member>
            <name>Age</name>
            <value>
              <i4>28</i4>
            </value>
          </member>
        </struct>
      </value>
    </param>
  </params>
</methodCall>
More information on these values and what they mean in HTTP terms can be found at .

The document begins with the <methodCall> element followed by the <methodName> and a list of <params>. For more information on the various types of information you can pass, visit .

The response, like the request, will use the HTTP protocol. To be validated, at a minimum it must return the following information in the header:

  • Response Code: see HTTP specification for more information on the various response codes
  • Content-Length: the size of the document being passed
  • Content-Type: should state text/xml to define that the request contains XML information

An example would look like this:

HTTP/1.1 200 OK
Content-Length: 219
Content-Type: text/xml

As before, you can visit for more information on HTTP responses.

The body of the response contains markup outlining the procedure returned from its processing. This information is stored in a <methodResponse> element, which can contain a single <params> or <fault> element depending on the successfulness of the processing. For example, if no error occurred, you might see a result like the one in rpc-response-success.xml in Listing 1-12, which states that the user was accepted.

Listing 1-12 rpc-response-success.xml: A successful response from our procedure call.

<?xml version="1.0"?>
<methodResponse>
  <params>
    <param>
      <value>
        <string>Accepted</string>
      </value>
    </param>
  </params>
</methodResponse>

If an error occurred in the processing you might see something like rpc-response-error.xml shown in Listing 1-13, where the application validateUser.exe was not found.

Listing 1-13 rpc-response-error.xml: An error stating the application was not found on the system.

<?xml version="1.0"?>
<methodResponse>
  <fault>
    <value>
      <struct>
        <member>
          <name>ErrorCode</name>
          <value>
            <int>1</int>
          </value>
        </member>
        <member>
           <name>ErrorMessage</name>
           <value>
             <string>Application not found.</string>
           </value>
        </member>
      </struct>
    </value>
  </fault>
</methodResponse>

Invoking procedures, applications, and processes on remote systems offers a compelling reason to look into and potentially use XML-RPC. Remember that we will discuss SOAP later in this book, so before you make any decisions, be sure to understand the benefits and issues of both of these standards.

Application Messaging

The term "messaging" is often thought of as messaging between friends and family, such as with Microsoft Network Messenger, and not between full blown enterprise-level applications, which could in turn connect your data repositories to those of your partners and affiliates. XML changed all that, and with the help of standards like SOAP, application messaging is now a reality.

XML is used to describe the Application Programming Interface (API) to a Web Service, which allows applications to partially automate the process by which they communicate. The requesting application can understand the capabilities of the responding server and determine if it is compatible with its own data structure and type.

What Is Messaging?

The purpose of application messaging is for software applications, potentially in geographically different locations, to communicate in a near-automated fashion. Communicating usually involves receiving a request, processing that request, and a returning a result to the requesting application. XML emerges as the language of choice for describing not only the request, but also the response. This description might contain the path or route of the request, the type of information requested, and the actual data returned (marked up in XML, of course), but this is only part of the solution.

With the shift to Web Services as the next generation of Application Service Providers, XML is used not only for application-to-application messaging, but also for describing the services themselves. This description could contain anything from the type of data that can be requested to outlining the result options. Following this model, applications can query other applications to understand their capabilities before making a request.

A Simple Example of Messaging

News Feed, Inc. builds a system that returns the daily news to a requesting application. The system has everything from sports, financial news, and local news, to world, weather, and travel news. The application has the ability to be queried and pass a date to see if it has any relevant news for a given day. This query also contains the type of information you're looking for, what you want returned (count, headers, all data), and how many results are returned. The XML schema used to describe this query is located in Listing 1-14. In Chapter 7 you will see that standards exist that provide an entire framework for this type of communication, so treat this as a simple example of how you might implement a messaging system.

Listing 1-14 NFQuery.dtd: An XML schema for querying the News Feed system.

<?xml version='1.0' encoding='UTF-8' ?>
<!ELEMENT query (news)>
<!ELEMENT news EMPTY>
<!ATTLIST news  date  CDATA  #REQUIRED
          type   (global | local | financial | 
                  sports | travel | weather )  #REQUIRED
          what   (count | headers | all )  #REQUIRED
         limit CDATA  #IMPLIED > 

Joe's Sports Tips, a local newspaper that uses News Feed's data, only wants to retrieve sports news. Because of this, Joe's first sends a query to the News Feed system to see how many sports headlines it has for a given date. The query, contained in Listing 1-15, requests the number of sport headlines for October 10, 2001.

Listing 1-15 2001-10-10_sports_query.xml: The Joe's Sports Tips query of the News Feed system.

<?xml version = "1.0" encoding = "UTF-8"?>
<!DOCTYPE query SYSTEM "NFQuery.dtd">
<query>
	<news date = "2001-10-10" type = "sports" what = "count"/>
</query>

The next part of the process is for News Feed to return a response to Joe's. The format of the response is governed by the NFResponse.dtd schema in Listing 1-16. The response, shown in Listing 1-17, shows 53 items in sports news on October 10.

Listing 1-16 NFResponse.dtd: A schema for News Feed's response.

<?xml version='1.0' encoding='UTF-8' ?>
<!ELEMENT results (count | headers | all)>
<!ATTLIST results  date CDATA  #REQUIRED
          type  (global | local | financial | 
                 sports | travel | weather )  #REQUIRED >
<!ELEMENT count (#PCDATA)>
<!ELEMENT headers (#PCDATA)>
<!ELEMENT all (headline+)>
<!ELEMENT headline (#PCDATA)>

Listing 1-17 2001-10-10_sports_query_response.xml: The response from News Feed.

<?xml version = "1.0" encoding = "UTF-8"?>
<!DOCTYPE results SYSTEM "NFResponse.dtd">
<results date = "2001-10-10" type = "sports">
	<count>53</count>
</results>

Now that Joe's knows how many items it can access, the system decides to request the first 10 articles. Again using the NFQuery.dtd data model, it changes the initial query to reflect that it wants 10 items and the entire article for these items.

Listing 1-18 2001-10-10_get_sports.xml: A request for the first 10 sport news stories.

<?xml version = "1.0" encoding = "UTF-8"?>
<!DOCTYPE query SYSTEM "NFQuery.dtd">
<query>
	<news date="2001-10-10" 
         type="sports" what="all" limit="10"/>
</query>

Several sections in this book discuss this type of application-to-application messaging and communication. Chapter 4 and Chapter 15 are dedicated to messaging and Microsoft's BizTalk Server, which provides all the components necessary to get you up and running, including Microsoft BizTalk Messaging Manager.

Process Modeling

A relatively new use of XML is to model processes and workflow. Remember the map.xml document earlier in this chapter? That document was a good example of steps, or a process, that needed to occur in a specific order. Not following this order, or the directions in our example, will result in someone getting lost.

Using XML to model processes is not just a means by which you can describe how something works. Because it was implemented in XML, it inherits all the abilities of the XML language, such as validation. This provides a second level of verification when it comes to ensuring that processes are defined according to the rules and objectives set forth.