Data-Oriented Components

Data-Oriented Components

Deploying XML-based systems requires that developers write software that accesses , manipulates, and creates XML as if it were data. In some cases, this software runs on top of the server infrastructure discussed previously. In other cases, the software may operate as a standalone program. In all cases, XML offers improved productivity through the wide availability of components for generating, processing, and distributing machine-readable XML data, which developers require.

While there are numerous types of utilities that can assist them, there are three categories crucial to most serious applications. Any serious XML programming requires moving XML data in and out of internal programming data structures. Development tools reduce the amount of coding and improve the quality of code for this repetitious task. In practice, using XML as data also requires transforming documents from one XML format to another, as well as between XML and other formats. Transformation tools simplify the problem of creating XSLT transforms and integrating external data into XML architectures. Moreover, most data-oriented applications of XML involve distributed communication. While application servers and packaged solutions provide basic functionality, the Web services paradigm often requires either integrating a variety of server-provided services or deploying standalone functionality to nonserver devices. In these cases Web services components reduce time to market.

Development Tools

The most common task in developing XML application is ensuring that a piece of code that manipulates an XML document works as desired. Performing this task requires the developer to work simultaneously with a document and the associated code. It helps the developer to view the XML document in two different ways. First, developers need a text view but with all the additional features they've come to expect from a code editor ”indenting, highlighting, and syntax checking. Second, they need a browsable tree view, much like they have for class hierarchies. Together these two views allow the developer to maintain a good mental model of the document and thereby understand how the code running against it should work. Many commercial IDEs , especially those for Java and from Microsoft, provide this functionality. There are also open source modules for adding the text viewing capabilities to popular code editors like EMACS .

While IDEs supply features that help when working on code that manipulates XML documents, there is the issue of writing this code in the first place. Many XML applications work with a known set of XML formats. For example, an application for the insurance industry would work with documents conforming to insurance- related XML DTDs or Schemas. Writing the code to move data back and forth between documents using these formats and internal data structure is time-consuming and repetitive. Schema compilers can take a DTD or Schema and generate much of this code, saving time and improving quality. Such tools include Breeze Factor's Breeze XML Studio (Java), Bristol Technology's eXactML (C++), Microsoft's Visual Studio .NET (C++ and Visual Basic), The Mind Electric's Electric XML+, OracleXML Class Generator (C++ and Java), and Sun's Java Architecture for XML Binding (JAXB).

Transformation Tools

Many applications concern the exchange of information about coherent business entities. It is likely that different parties to these exchanges will have different definitions of these entities. These different definitions will probably take the form of different DTDs or Schemas. As you saw in Chapter 3, XSLT can address this problem. However, for large applications that work with many different formats, you may find it difficult and time-consuming to create all the necessary XSLT by hand. Creating a supply chain management system may require writing transforms for hundreds of formats. Moreover, these formats can change regularly. Developers need tools to make this process more efficient. A number of vendors offer visual mapping tools that let the developer indicate how to move element and attribute values from the source format to element and attribute values of the target format. The tools then generate the XSLT code, and many provide debugging features for making sure the generated code works properly. Products in this category include ActiveState's Visual XSLT (Visual .NET plug-in), B-Bop Xfinity Designer, eXcelon's Stylus Studio, IBM's Visual XML Transformation Tool, Induslogic's XSL Stylesheet Editor, and TIBCO XMLTransform.

Unfortunately, not all data exists in an XML format. Many applications must map data from non-XML sources to XML formats and vice versa. Developers need components that can perform this mapping both in bulk and upon request. These tools are similar to those for mapping data from relational databases to object-oriented programming structures and migrating data from operational stores to data warehouses. They include features for browsing the structures of data sources and then specifying how to translate from data fields to elements and attributes. These tools are quite sophisticated because processing data from a non-XML source may require more than simply pulling data from a column and putting in an element. There are also datatype conversions and collapsing or exploding relationships between fields. The two leading products for this purpose are Data Junction's Integration Engine and Mercator's Integration Broker.

Distributed Application Components

As previewed in the discussion of Application Servers in the preceding Server Infrastructure section, many applications use XML to facilitate distributed communication in custom applications. Usually, such applications use SOAP and the other Web services protocols. Task frameworks can help improve productivity, but the issues can extend beyond the boundaries of application servers. It often helps to have tight integration of distributed application development across development tools, frameworks, and servers. The development tools can then quickly lead developers in the use of the advanced framework and server features. This breadth of integration usually comes under the umbrella of a large vendor's overarching distributed XML paradigm. Examples include BEA WebLogic Workshop, IBM WebServices, Microsoft .NET, and Sun ONE.

In many cases, you will already have a substantial commitment to a vendor through existing server infrastructure and development tools. Obviously, the least disruptive choice for Web services components will be that vendor. However, if you plan to make a decision on your preferred supplier based on Web services support, you can go either the integrated solution or best-of-breed route. The integrated solution route offers the benefit of making a single vendor responsible for the success of your applications. It has the drawback of restricting you to that vendor. The best-of-breed route has the advantage of enabling you to choose the best vendor for other infrastructure such as platforms and tools. It has the disadvantage of making you responsible for integrating the entire system. Major vendors offer integration along two dimensions: platforms and tools. In this case, the platform is a composite of hardware architecture, operating system, and mission critical components like DBMSs.

Figure 5-6 presents a conceptual graph of where major vendor offerings fall in the space formed by these two dimensions. Microsoft has the highest platform specificity because it requires that you use its operating system and other server infrastructure. IBM and Sun both offer their solutions on multiple platforms but, of course, they try to drive the sales of their specific platforms. BEA is almost completely platform agnostic . All vendors try to take advantage of a Web service's potential productivity gains to some extent, with a certain degree of development tool integration. BEA does this through a high-level framework but leaves core programming tool choices. IBM and Sun offer their own IDEs based on standard programming and scripting languages. Microsoft offers its own IDEs and languages.

Figure 5-6. Degree of Integration by Major XML Component Vendors

The large vendor initiatives have drawbacks. To achieve the desired breadth of integration, they often sacrifice modularity and performance. Obviously, they want developers to buy the complete packages, so they often require all-or-nothing commitments. Maintaining the synchronization between all the components usually introduces a substantial amount of overhead. These drawbacks are severe for applications not deployed in application servers, especially if targeted at small devices. Smaller products such as CapeClear's CapeStudio, The Mind Electric's GLUE, and Polar Lake fill this gap with components that Web services enable application-specific code in a tight, standalone footprint.