Other Articles by Brian Walsh

Facing the Future, Columnists, January 11, 1999 Heading for Disaster?, Features, January 11, 1999 The Almighty and All-Important Consumer, Columnists, February 8, 1999 It's Not a Digital Market, It's a Digital Payment System, Columnists, March 8, 1999 XML: Revenge of the Nerds, Columnists, April 5, 1999

Other Columnists this issue

Top of the Stack By David Willis On the Edge By Art Wittmann

Company Directory

Browse our directory to get data, starting with a particular company.

Reader Service

Allows you to request additional product information from our advertisers.

Print The Full Article

ClickHere

E-mail this URL

ClickHere

Buy the Book

You may be thinking, "Well, then, who cares? APIs are for programming geeks. We're IT executives (or network architects or new-media experts) and we don't need code around here." But you should care, because providing organized access to data and services by publishing an API is how we turn data into information, and then into knowledge and ultimately into action.

The current requirements for Internet navigation and emerging requirements for services exceed the capabilities of the solutions now available. Keyword searches simply are not geared to navigate the amount of information floating on the Web. While all Web users have access to the entire Internet, they have a window to only a very small part of it. Most Web users add at most one new site a month to their personal scope of interest. The rest of the time they spend answering e-mail, checking stocks and scanning the news. Finding more simply requires too much effort or, worse, necessitates relying on a portal's paid-for links to spoon-feed it to the consumer. Moreover, as new services become available, a nasty conglomeration of ill-fitting CGI posts and plug-ins is not the high ground on which to build networks of cooperating sites. It's the 1990s' equivalent of screen-scraping 3270 applications.

The Next Generation of Web Data Interchange Each generation of computing technology creates its own solutions for data exchange. For example, mainframes use protocols and standards they've spawned. PC applications default to proprietary file formats or lowest-common-denominator delimited files. In its turn, Web-based computing uses formats that have grown out of its environment. The problem is that the ubiquitous mechanisms are primitive, first-generation solutions, such as CGI posts, or are based on a race to "layer in" solutions--plug-ins or server APIs, for example. Letting this generation of data-exchange practices stagnate at this level is like spiking the football on the 50-yard line--there's a long way to go to get the type of functionality we need.

The Web model is successful because it offers choices and smoothes over differences in product selection, implementation levels and operations. The details of your hosting environment, security policy, browser choices and desktop applications don't matter. For the Web model to continue to deliver substantial value for the next generation, we need to continue the paradigm.

Imagine if it really didn't matter which accounting software the finance department used, what molecular modeler the folks in the lab implemented or what network-management software your outsource vendor employed. The reality is that these things matter a lot.

Today, one chooses between uniformity of implementation, or the startup and ongoing expenses involved with integration. (Talk to anyone who's involved in creating Web-based commerce or business-service applications, and they'll tell you about expenses.) According to a 1996 Gartner Group report on message brokers, extract and update programs consume 35 percent to 40 percent of an enterprise's programming budget simply to transfer information. It doesn't always have to be this way, but to reach that happy day when it isn't, application developers and vendors must agree on content standards for sharing information. That's where XML comes in, by providing the high-level mechanism to move that data out to partners and customers.

The advantage of this strategy for application integration is that it lets organizations use their own vendors, develop their own agents and leverage their own data stores as infrastructures as needed by their own capacities and resources. The intricacies of dependencies among different application vendors are reduced, while particular pairs of partners still can leverage each other's capabilities and infrastructure as part of a specific project. For all involved, this integration strategy will reduce significantly the labor costs spent on integration and capital costs for specific applications for specific partners. This means that more time and money can be spent concentrating on the unique requirements of the organization. Because Web-site-to-Web-site integration will be easier, only a minimal number of user-presentation interactions need to take place to accomplish the same task.

For example, instead of surfing to individual Web sites to find the best price for product X, a user could interact with a single server that collects that information on his or her behalf. This process is possible now by parsing HTML, but it will be made simpler, less expensive and more common by using XML.

First-Time Benefits XML provides benefits heretofore missing from any single technology. It is flexible: New tag and attribute names for data can be added at any time without breaking applications. It allows for searching: Currently, searching HTML is about as accurate as screen-scraping. Most important, XML is self-describing: An application can recognize a new XML, parse it and interpret it without a priori knowledge.

Java provides platform-independent objects of arbitrary complexity delivered over standard interfaces and leveraging network security; XML provides platform-independent data of arbitrary complexity over the same infrastructure.

So what's a reasonable way to prepare oneself to adopt XML? It comes down to education and architecture. It's relatively easy to educate oneself about XML. Vendors from Microsoft to IBM have endorsed it and are good sources of information.

As a starting point, several XML editors are available--ArborText's Epic, Microsoft's XMLPad and SoftQuad's XMetaL, to name just a few. The larger question is what support is available for XML at all tiers in the architecture.

And an even trickier question is where does XML fit in the classic three-tier architecture (client/application server/data server). Should all HTML be converted into XML for delivery to the client? Should the database deliver all columns cast into XML for delivery to the application server? Should application servers use XML as the lingua franca for interapplication communication? All are possibilities.

The main drawbacks of the browser interface have more to do with the consistency of controls as compared to native applications than with the format of data. The concept of an XML search server could be useful, but relational databases have been around for a long time, survived challenges from object databases and still reign supreme as the core of most organizations. It would be useful to perform high-fidelity content management that would require both conversion to XML and XML content tools (such as Chrystal Software's Astoria, Data Harmony's Data Harmony and POET Software's POET Content Management Suite). However, from a priority standpoint, and given the concern about trading-partner networks mentioned earlier, it seems that the use of XML by the middle tier is most intriguing.

A New Player: XML Data Servers What role does an XML data server play? Obviously it provides XML data to other objects in the middle tier through a (hopefully) standard interface. But couldn't one simply cast database result sets and object serialization into XML? The operative word in that question is simply. Don't be fooled into thinking this is something that can be homegrown. According to ObjectDesign, authors of the eXcelon XML data server, XML-based data servers will provide the following capabilities:

· storage and manipulation of native XML data;

· high-performance query over large sets of XML components;

· integration with different data sources into a unified XML storage area where it can be manipulated and queried using XML standards;

· execution of applications using the Document Object Model against the XML data model;

· standard interfaces to common Web development languages, such as Jscript, VBScript and Java;

· single point of administration for XML data; and

· distribution of XML data in a manner that will scale as the number of users increases.

Whatever the advantages, IT architects will need to graft XML servers into existing middle-tier designs. That is not a simple task when you consider the heft of the combined weight of transaction servers, Web servers, database-stored procedure suites, background processes and security hurdles. In a paradoxical turn of events, in order to deliver productivity by standardizing and streamlining data exchange for next-generation Web applications, XML servers will need to address the productivity of the architects and administrators responsible for their implementation first.

Brian Walsh is founder of bwalsh.com, a Portland, Ore., consulting firm specializing in Internet and client/server product strategies, development and testing. Send your comments on this column to him at brian@bwalsh.com.