Ten best bets for XML applications

Ten best bets for XML applications

－－Wondering where to begin with XML? These projects won't turn into dead ends.

Bob Schloss

Senior Software Engineer, IBM T. J. Watson Research Center

April 2000

Searching for a trial project for XML? While the XML specs and tools are still being developed, some applications are more suitable than others to start with. Find out which types of applications make sense to develop with XML now.

Many IT departments feel ready to try XML in a single project. But where to begin? XML functionality and tool support still evolves: style sheets aren't quite solid yet, query capability is still on the way, and so on. No one wants to be caught in mid-project having to retrofit to a moving specification or to stop unexpectedly and craft tools. That means that not every obvious XML application makes sense to develop now.

To help you figure out whether the XML application you want to build is a good bet for developing now, compare it to this checklist of ten telltale signs that your application needs XML and that commercial middleware and tools are adequate at this time for you to succeed with your project. Some of the signs are obvious; some less so, as you will see.

Applications that use data with repeating text fields

Applications whose persisting data includes a variable number of repeating (nested) textual fields should use XML. This is an obvious XML application, and one that has suitable tools in place. An XML processor, such as XML4J or XML4C or Xerces which provides a DOM API (see Resources), allows your program to create or read this kind of document. Also, the document can be stored in repositories, such as IBM DB2 with XML Extender (see Resources), where queries can retrieve documents regardless of which repeating field contains the data used in the query.

Applications that need Unicode

Applications for multilingual or multinational audience that use textual names of people, enterprises, and geographic places need the flexibility to display the names in the correct local language and character set. Use XML for such applications because XML uses Unicode by default, which allows end users to encode names in their preferred language and character set.

Applications that exchange data between enterprises

Another obvious use for data exchange formatting is an application that exchanges data between enterprises, using software produced and configured by more than one enterprise. The benefit of XML here is debugging, because the data interchange is at least somewhat readable when done with XML tags. I'm convinced that messages structured in readable HTTP, NNTP, FTP, and so on, made it possible for independent programmers to debug their interactions with software from others whose source code they did not have during the formative years for Internet software of the 1980s and 1990s. XML serves the same purpose, but the ability to define your own document types means all programs can use readable data interchange (and with more bandwidth available, they can afford to), and XML抯 ability to nest and mix (using namespaces) is an important advance.

Route-and-flow applications

Route-and-flow applications differ from conventional applications: they do not have one program active for an entire transaction, waiting in real-time for subsystems to complete their portion of the work. Instead they use independent subsystems that examine or augment the data and then pass it on to one or more other subsystems, which can work asynchronously, using some type of queued data pipe. XML is particularly apt right now for those route-and-flow applications that do not have real-time transaction confirmation requirements. The IBM MQSeries Integrator can be especially valuable in building these applications by allowing the routing logic separate from the business processing logic. TIBCO and others also make route-and-flow middleware, and the Java Messaging Framework and the Open Applications Group now specify common APIs. (See Resources) for information about these products.)

Applications that produce microcode data reports

XML's structured repetition and programming language independence mean new generations of server code can evolve to collect data from embedded sensors without changing the embedded-device microcode. Because many embedded sensors are programmed with microcode to send cumulative data reports back to a server, this could be an important XML application for developers working with embedded systems.

Older forms of XML cumulative data reports could be converted to newer forms using XSLT, using programs like LotusXSL or Xalan (see Resources), so that the server business logic that reads the reports does not become littered with case statements. And there will be older forms: for example, each generation of electric meters will capture more information than the previous generation did, but there will be no worldwide replacement of the older meters in the field.

Applications that display results on various devices

As ubiquitous computing takes hold, more and more applications must present data to end users on many varied devices. That's a natural use of XML: the applications present status to end users as an XML document. Transcoding (see Resources) would alter the data for optimal rendering on the end user's current access device, whether handheld computer, Web browser, pager, audio phone, smart cellular phone, or other.

XML and transcoding also address the end users?limitations (for example, limited eyesight) using alternative renderings.

An added benefit of reporting status as an XML document is that filters can determine if the status is highly unusual or urgent, and route filtered messages through additional channels to additional end users.

EDI background

EDI provides application-to-application exchange of information using standard, formatted electronic transactions, such as ANSI X12 or EDIFACT. EDI implementations require each corporation to understand the relationship between each trading partner and to itemize the data required for each business transaction (such as, sending a purchase order). The EDI document formalizes these relationships and standardizes the resulting business transactions. The transmission of this formatted data is usually done in batch mode (as opposed to real time).

For various reasons, trading partners may resist installing EDI software at their location and integrating the EDI transaction with their proprietary order entry or purchasing applications. Although the communications can be direct, trading partners might use different network protocols or operate on different schedules. Corporations also have to provide staffing to bring trading partners online, to work through network problems, and to resolve data inconsistencies. For a price, a Value Added Network (VAN) provider offers EDI mailboxing services and manages the operational and technical challenges found with managing large trading partner communities.

The EDI model works well for large, high-volume companies but is often too costly a solution for the smaller corporation that cannot afford such a large software, programming, and integration investment.
 
EDI-like or supply-chain applications

Although standards in this area are still evolving, applications that offer functions that work like EDI (electronic data interchange) are pretty good bets for XML development.

Most of the value of EDI can be duplicated using XML, extranets, and Virtual Private Networks, as well as the emerging IETF/W3C standard for Digitally Signed XML documents using Public Key Infrastructure encryption keys. Pairwise supply chain applications that perform the interchange via the Internet rather than a Value Added Network provider are the best candidates to begin developing now.

Some standards are being created by the RosettaNet Consortium (see Resources). Hosted trading networks, from companies like Ariba and Commerce One (see Resources), are developing xml/EDI functionality also, even though standards are not in place.

Applications that need enterprise document management

Documents, unfortunately, don't always contain the full context to allow them to be properly interpreted. For example, you may have a digital copy of a bid your company submitted to a customer six months ago, but it contains no information about whether the bid is still under consideration, was accepted, was rejected, or was superceded by a later revised bid. A digital copy of a customer complaint letter probably contains no clue of what response your company made to it. So enterprise document management must be more than just databases or digital libraries; it must contain metadata -- data about the documents and about classes of users, classes of operations and applications, individual users, and more.

XML works very well for the metadata that allows versioning, combining in numerous configurations, user-interest profiles, and so forth.

Enterprise application integration

Crafting applications for integration of enterprise resource planning (ERP) systems, transaction systems, repositories, and groupware is now possible. Connectors and adapters that allow these systems to accept input and produce output in XML formats are quickly coming on the market.

For example, XML Lightweight Extractor (available from alphaWorks, see Resources) can pull data out of databases in XML format, and many database vendors have announced or released XML adapters, including Oracle and SAP.

Mismatches between the outputs of one system and the inputs of another can sometimes be fixed with a simple transformation rule expressed in XSLT.

Matchmaking marketplaces

If you operate a brokerage of some sort, where attributes of available supply sources and attributes of current and projected demand are specified using multiple dimensions, XML stands out as a natural match. Suppliers describe what they have in XML, buyers describe what they are looking for, and your application logic optimizes the matches. In many matchmaking marketplaces, controlled disclosure is required to lure buyers and sellers. XML easily offers the ability to distribute subsets of supply descriptions, produced with XSLT rules, that include only the information that potential buyers have the right to see, without tipping the seller抯 hand to privileged information.

Get started

Now that you have a choice of ten application categories that you can develop with today's tools as trial projects, pick one that meets a compelling need for your employer today. Choose a project that you suspect will require frequent changes and enhancements (the malleability of applications built with XML will make your life easier down the road).

Start with a project that one developer, or at most two, can design and code by themselves. Consider trying a project in which your team installs both the application that produces XML and the application that consumes the XML. Then figure out what middleware, programming language, and tools you need (developerWorks and alphaWorks are great places to start, as well as the xml-dev archive and some of the books on XML for applications that came out since the summer of 1999). Decide if the XML Document Types you need are already defined (a good place to start is at XML.ORG) or if you'll need to define your own. And enjoy yourself!

About the author

Bob Schloss?work on application development began with optimizing compilers, evolved to address content-intensive electronic publishing applications with open standard metadata , and recently focused on exchangeable XML data during 1997-1999, when Bob co-chaired the W3C Working Group that produced the Resource Description Framework Model and Syntax Recommendation. He now coordinates IBM Research groups in California, New York, Israel, and Japan doing leading-edge work on XML facilities for applications and XML cross-industry e-business standards. Visit his Web page to learn more about his work. Bob can be reached at schloss@watson.ibm.com