 | Level: Intermediate Kevin Williams (kevin@blueoxide.com), CEO, Blue Oxide Technologies, LLC
08 Jul 2003 In the final installment of this three-part column, Kevin Williams looks at some of the ways you can take advantage of the reusable XML components that he defined in the previous two installments of this column. Designing XML with reusable components can, in many ways, create direct and indirect benefits; Kevin takes a quick look at some of the most important.
This column builds on the philosophy of XML reuse I described in the first two columns, so if you haven't read those yet you might want to before diving into this one (see Resources).
The first benefit of using reusable components isn't necessarily a direct benefit of the design of XML structures that use components, but it is a natural outcome of the approach. To create components that can be reused, you need to capture solid semantics about those components. These semantics can be extended into the processing code itself to make the programmer's job easier. Take a look at the brief example in Listing 1. Suppose you have the following customer XML document:
Listing 1. Example customer XML document
<customer>
<name>Amalgamated Widgets, Inc.</name>
<contact>Fred Smith</contact>
<phone>304-555-1212</phone>
</customer>
|
If you were to design this document as a single XML schema, you might not capture the semantics for each datapoint in the schema -- which would make it more difficult to write code to accurately process instances. (For example, is contact a name or an e-mail address? Is the order of the name first name, middle name, last name or last name, comma, first name, middle name?)
On the other hand, if you choose to design this document using reusable XML components (datapoints for name, contact, and so on), you have already forced yourself to capture good semantics, because you can't reuse the components without knowing precisely the semantics of those components. This means that the processing software can take these semantic constraints as read and simplify the programmer's job.
Reusable XSLT components
Another natural benefit of the component-based approach to XML design is the ability to reuse XSLT fragments to ensure a standardized presentation of information across many different documents. Again, this is a natural outcome of capturing good semantics and reusing elements and attributes whenever possible. Suppose you have the following two documents:
Listing 2. Example customer and supplier XML documents with no reuse
<customer>
<name>Amalgamated Widgets, Inc.></name>
<contact>Fred Smith</contact>
<phone>304-555-1212</phone>
</customer>
<supplier>
<companyName>Sprockets Unlimited</companyName>
<salesContact>Joe Jones</contact>
<contactPhone>540-555-6789</phone>
</supplier>
|
In these examples no effort has been made to reuse content, so elements with identical semantic constraints (such as name and companyName) have different tag names. When it comes time to write stylesheets to present these documents (as HTML, for example), you now have to write one stylesheet that processes the customer document and another that processes the supplier document -- leading to duplication of effort, which is just what you're trying to avoid. Now suppose that these two documents were designed with reuse in mind:
Listing 3. Customer and supplier XML documents designed for reuse
<my:customer xmlns:my="http://mycompany.com/schemas">
<my:companyName>Amalgamated Widgets, Inc.</my:companyName>
<my:salesContactName>Fred Smith</my:salesContactName>
<my:salesContactPhone>304-555-1212</my:salesContactPhone>
</my:customer>
<my:supplier xmlns:my="http://mycompany.com/schemas">
<my:companyName>Sprockets Unlimited</my:companyName>
<my:salesContactName>Joe Jones</my:salesContactName>
<my:salesContactPhone>540-555-6789</my:salesContactPhone>
</my:supplier>
|
Note that this solution uses a namespace for all elements. Whether you think namespaces are a good idea or not, the proper use of them ensures that every element and attribute in your schema is uniquely and unambiguously defined -- the combination of a namespace URL and an element or attribute name can always be mapped back to a single semantic assertion about the meaning of that element or attribute. Listing 3 also reuses the datapoints in these structures. If you then want companyName to be represented as an <H2> field in your HTML wherever it appears, you can write one fragment of XSLT that styles it this way:
Listing 4. Stylesheet fragment to render a companyName element
<xsl:template xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:my="http://mycompany.com/schemas">
match="my:companyName">
<H2><xsl:value-of select="." /></H2>
</xsl:template>
|
This fragment can then be included in the stylesheets for my:customer and my:supplier:
Listing 5. Including the companyName stylesheet fragment in other stylesheets
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:include href="companyName.xslt" />
...
</xsl:stylesheet>
|
Now, when the word comes down that companyName needs to be H3 instead of H2, you just have to change companyName.xslt and all of the other stylesheets automatically reflect the change. If you hadn't made a conscious effort to ensure that the company name had a consistent identity across the various documents where it appears, this change would be much more difficult.
Class-to-XML mapping (fragment serialization, deserialization)
The third benefit I want to discuss begins to appear when higher-order elements are reused. Suppose you have the following structure that represents a person across all your XML documents:
Listing 6. Sample person XML fragment
<my:person xmlns:my="http://mycompany.com/schemas">
<my:personName>Kevin Williams</my:personName>
<my:address1>123 Anywhere Street</my:address1>
<my:city>Anytown</my:city>
<my:state>WV</my:state>
<my:postalCode>25532</my:postalCode>
<my:country>USA</my:country>
</my:person>
|
If this structure is reused in many different places in your XML schemas, you can simplify your processing code by writing a class that maps directly onto this element structure. The class might have a Parse method that reads an XML fragment representing a person and decomposes it into public members of the class; it might also have a Serialize method that creates an appropriate XML fragment based on the public members. By creating these sorts of XML-aware classes, you can make it possible to reuse parsing and serialization code -- as long as you have properly reused the structures in your XML schemas. Here's an example (written in pseudocode; this approach is equally applicable to any object-oriented programming language):
Listing 7. Pseudocode class representing a Person object
Class: Person
Public String personName
Public String address1
Public String address2
Public String city
Public String state
Public String postalCode
Public String country
Public Method boolean Parse (String personElement)
Public Method string Serialize ()
|
Depending on the type of information being manipulated, you might also want to include other methods that provide additional functionality in this class as well (such as a Persist() method, which stores the person in a database). It should be clear how designing for reuse at the beginning of the development effort leads to these sorts of benefits later.
Bringing XML and Web services together
An unfortunate trend among today's XML Web services developers is the tendency to think of Web services as a distinct platform from XML. This is due, in part at least, to the Web services wizards included in most of the recent integrated development environments. When a wizard can automatically generate WSDL and SOAP messages for whatever methods you have lying around in your objects, why bother thinking about the underlying XML? Well, as you might guess, the answer is simple: reuse. For example, suppose I have a method on a data object that allows me to read and write a person to my relational database:
Listing 8. Person class, revisited
Class: Person
Public String personName
Public String address1
Public String address2
Public String city
Public String state
Public String postalCode
Public String country
Public Method boolean Persist()
Public Method boolean RetrievePerson (int personID)
|
I could just expose the properties and methods on this object as Web services, but it wouldn't really be useful -- I'd have to make eight calls just to store a person (seven calls to the set methods on the various properties and one call to the Persist method. The key is to keep in mind that Web services should be thought of as outward facing, even if they are only being used to connect systems internally. Think of it as writing an API to your system: You wouldn't define an API that required calls to be made this way, would you? While you're at it, you should define your Web services to take advantage of the design work you have already done on your XML instances. The benefit should be clear -- one shared set of semantics means that consumers of your Web services have a clearly-defined, unambiguous definition of each part of the inbound and outbound Web service payload, and can use it more easily than if the parameters had cryptic names like fn. A better definition to expose as a Web service might look like this:
Listing 9. Person class with a better Web service interface
Class: Person
Public Method boolean StorePerson(string personName,
string address1, string address2, string city, string state,
string postalCode, string country)
|
Conclusion
You'll find many benefits to designing XML schemas using reusable components. These benefits lead directly to shorter development cycles and simpler maintenance of code. If you are designing a large system with many different types of XML documents, taking the time to identify reusable components of those documents early in the development effort benefits that effort in the long term.
Resources
- Read the two previous XML for Data column installments on reuse: Part 1 provides an overview of XML reuse in enterprise-level solutions (developerWorks, March 2003), while Part 2 focuses on the types of components that can be reused in XML designs and provides examples of each in XML and XML Schema (April 2003).
- For more practical XSLT techniques, check out
The XSLT Cookbook
by Sal Mangano (O'Reilly and Associates).
- The xml.com Web site provides a good variety of articles with new ideas for XML developers.
- Find more XML resources on the developerWorks XML zone.
- Get IBM WebSphere Studio, a suite of tools that automate XML development, both in Java and in other languages. It is closely integrated with the WebSphere Application Server, but can also be used with other J2EE servers.
- Find out how you can become an IBM Certified Developer in XML and related technologies.
About the author | | | Kevin Williams is the CTO of Blue Oxide Technologies, LLC, a company that designs XML and Web service creation software. Visit their Web site at http://www.blueoxide.com. Kevin can be reached for comment at kevin@blueoxide.com. |
Rate this page
| |
