E-business, B2B, enterprise information portals (EIPs) and XML are the leading buzzwords of our industry because information - and its efficient management - is at the heart of any e-business environment. XML is the standard for the markup of information in Web-based Internet/intranet and extranet applications and this article provides future users of XML with a blueprint of how to make the best use of these new and converging technologies.

This article will start by looking at how enterprises can use XML to connect different systems throughout their organizations, then go on to show how they can use portal technology to serve the needs of internal and external users. Finally, I'll show how all of this provides an e-business-enabling layer for commerce-oriented applications.

The XML Backbone
Legacy systems
At the simplest level EIPs provide an efficient means of managing secure and personalized access to corporate information resources. However, one of the problems we had to face very early on was that this alone wasn't enough.

All too often, the resource an EIP is supposed to manage isn't ready to be accessed, especially via the Web. One of the first tasks while building an EIP in a large-scale enterprise is to arrange for the Web-enablement of very diverse data sources.

Clearly, XML is the key candidate for these categories of problems. Instead of using the proprietary data formats of the data sources, XML is a natural fit as it describes the information handled in a standardized way.

Moreover, in XML we also get the ability to work with stylesheets to provide various renditions of our data. And once extracted into XML format, not only can EIPs use the data set but so can other applications, especially if they're already XML-enabled.

Reusable Infrastructure
According to a recent GartnerGroup report, a typical enterprise will devote 35-40% of its programming budget to developing and maintaining "extract and update" programs whose sole purpose is to transfer information between different databases and legacy systems (see Figure 1).

While in the old pre-XML days dozens of programmers had to waste their talents on repeatedly developing extract and update programs, today - using XML - we can slowly start to develop an abstraction layer in which all the information in an organization is being passed around in XML (see Figure 2).

As a matter of fact, the XML backbone per se is an abstract concept, a way of thinking. It makes no assumptions about underlying transport protocols. Enterprises can implement an XML backbone using whatever technology/protocol (or rather mix thereof) they want, whatever fits into their existing and planned IT infrastructure.

Besides the obvious integration of back-end systems, the integration of other XML components more oriented toward documents - such as document management, editors, link managers and so on - is another level of the XML backbone that's also of strategic importance.

It's Not a Shrink-Wrap World
A word of caution at this point: all that's been said so far about the XML backbone might sound too good to be true. Well, you can get there, but it will require a significant commitment to a strategic initiative...and it will certainly take time and money.

It's not a shrink-wrap world, except for well-defined subproblems. Don't expect a single vendor to come to you with the panacea for all your IT problems in five minutes. These are difficult problems that skilled and experienced IT experts have been trying to solve for many years; XML is merely a new way of looking at it. Granted, as with any other technology, you'll be able to achieve partial success in a relatively short period of time. But the truly complex problems typically take a long(er) time to solve.

One of the more promising developments in this area is that more and more vendors have started shipping XML-capable releases of their software. Many others have recognized the need to provide connector technology for integrating various systems into the brave new world of XML.

An XML-Based EIP
What do we really mean when we say an "XML-based EIP"? Typically it will include one or more of the following aspects.

XML for Metadata
Even though we might wish all the data in the world were already in XML, we're still far away from that - very far, as a matter of fact. For the time being, the harsh reality is that EIPs will have to deal with data that doesn't come in XML format, such as word-processed documents, spreadsheets and graphics. XML still comes in very handy in these cases as a wrapper for such blob objects (see Figure 3). In this way, such metadata can be handled very efficiently.

XML for Data
The use of XML in data distribution relates back to the foregoing section about the XML backbone. Through a portal, we pass XML information to end users (rendering it with some sort of stylesheet mechanism) or to some other system for further processing. From a portal's perspective it doesn't really matter whether your content ends up at the user's desktop or some other machine.

If you're so fortunate that your portal vendor provides some fancy connectors in the back end, combined maybe with the ability to insert your own business rules using scripting or other means, you can do even more interesting things, such as write back to data sources or create complex applications driven by these scripts.

One example of what you can do with XML on the server side, especially combined with a persistent DOM on the server, is the XPages environment (see Figure 4). XPages was developed by DataChannel and has been submitted to the Apache XML open-source project.

XML-Based Software Development
I call this "eat your own dog food." Wouldn't it be silly for a vendor to tout XML whenever and wherever possible if he or she doesn't use XML for the software itself? Indeed, as it turns out, XML can be of great use in the software development process. Without getting specific about our own software, I would like to share some of the results of our R&D at DataChannel, since it may be applicable to your own software development.

I've mentioned earlier the XML backbone as an enterprise-wide initiative. During our product development, we also created a product-internal XML backbone - an abstraction layer for all internal data sources to be abstracted into a single DOM-interfaced data structure. All the application developer gets to see is the DOM, although in the background we interact with filesystems, RDBMS and LDAP/ADSI components.

Following this approach, we were also able to separate content from display, and could even separate the programming logic. Using XSL/CSS, therefore, we have full control over the look and feel of the portal, and because we believe this is of great value to the entire XML community, the core component of this module has been submitted to Apache.org.

Business to Anywhere
The browser, whether laptop or desktop, is losing its position as the only way to access information from the Internet. As our society becomes increasingly mobile, our information systems design must follow the trends.

The GartnerGroup estimates that by the end of 2005, more than one billion mobile phones will be in use worldwide. Cellular phones and PDAs are just the beginning of a whole new era of information mobility, and XML is destined to be one of the leading enabling technologies for this new technology wave.

Reuse
Content already marked up in XML can be reused for any output data format needed (see Figure 5). The same XML content can be rendered for output to a browser (HTML), to a cell phone (WML or HDML), to a PDA (maybe a subset of HTML) or any other conceivable data format. Granted, this doesn't yet solve the problem of particular transport protocols to a device but, at least from a data perspective, everything is in place.

Device Markup Languages
XML provides very flexible means for designers of output devices to create data formats that are most appropriate for the requirements, including the constraints of a particular device. XML is particularly suitable for this, as it's a metalanguage for creating markup languages. Wireless markup language (WML) is just one example.

A Not-So-Traditional B2B Landscape
When you hear the term B2B communication, what comes to one's mind all too often is "machine-to-machine" integration. In other words, how do I enable the exchange of data between my own enterprise systems and those of my business partners, such as suppliers and customers? Some of the systems offered in today's market will even allow you to manage the exact steps for the exchange of business data, and to monitor the execution of these business processes, via a graphical user interface.

However, this very narrow view of B2B leaves out two important aspects:

1. Document-content-oriented B2B: Exchange of design drawings, contract negotiations, RFQ, RFP and RFI development, and so on. These types of operations are typically conducted between human participants and involve collaborative work on unstructured content. XML transactions alone are sufficient when only commodities are involved, but aren't sufficient for more complex business processes between companies.

2. Human decision-making: Typical B2B processes involve more than the exchange of transactions between machines. Usually, human beings will be involved and have to make quick and informed decisions that allow a business process to continue smoothly to the next step. What's the point of high volume transactions between machines if the human being(s) involved take hours/days to do their part?

Enterprise information portals, using XML technologies, are well positioned to cover these two areas. Both from a content and a metacontent perspective, XML provides the necessary power.

To conclude, Figure 6 shows you how it all fits together: from the XML backbone through the portal to any device, anywhere.