Talking the BizTalk

IN THE OLD days of document management, quick-fingered clerks would clean up and reformat data as they entered it, sifting out invalid documents and keeping information moving through a complicated workflow.

These days, the exchange of electronic business documents can be automated using middleware and a mix of proprietary and standardized tools — but often imperfectly. BizTalk Server 2002 is Microsoft’s latest effort to bring together all the tools and network services developers need to set up an efficient EAI (enterprise application integration) infrastructure.

BizTalk binds its messaging and business process automation facilities with other Microsoft technologies, including Windows 2000’s COM+ and XML services, SQL Server, Exchange Server, and Visio (none of which is included in BizTalk’s purchase price). The result is a thorough, manageable, scalable, and well-documented EAI solution. Our examination of BizTalk Server 2002 revealed an extremely capable integration platform, but getting the most out of it requires skilled Windows developers willing to become expert in BizTalk’s unique approach.

BizTalk’s structure

We tested BizTalk Server 2002 on a pair of dual-processor Windows 2000 servers with 1GB of RAM, one using dual AMD Athlon MP 2000+ CPUs and the other running dual 2.2GHz Intel Xeon processors. Servers of this caliber are adequate for development, but BizTalk’s runtime hardware requirements are substantial. Unless your application has a low transaction volume and nondemanding response-time requirements, a deployed BizTalk configuration will likely call for a cluster of high-powered servers. And at $25,000 per CPU for BizTalk alone, deployment costs can add up quickly.

The package is an upgrade to the previous BizTalk Server 2000 release. Functionally, the two versions are almost identical. To create a BizTalk solution, the developer first uses the BizTalk Editor to define the format of the documents that will be exchanged. The BizTalk Mapper sets up the automated conversion of documents from foreign formats (such as, for example, the invoices generated by your partner’s back-end system) to your own. Then the developer sketches out a document processing workflow diagram using Visio.

The workflow can make calls to both custom-written processing modules and external applications, including Web services. BizTalk compiles each diagram into XLANG, an XML file that describes the workflow. Finally, the BizTalk scheduler service interprets the XLANG file and automates the receipt, storage (in SQL Server databases), and processing of the document.

The scheduler is BizTalk’s most valuable component. It manages the touchiest, most complicated piece of the EAI puzzle and can trim hundreds of development man-hours from large integration projects.

Surprisingly, however, the new version of BizTalk Server offers little new functionality, possibly because Microsoft is now mostly concerned with breaking existing BizTalk applications. The most significant changes include vastly improved documentation and source code samples, various improvements in the scalability of the XLANG business process scheduling engine, and the Seed intercompany deployment wizard.

The Seed wizard automates much of the process of setting up a document exchange relationship with an external partner also running BizTalk Server. The wizard gathers the necessary document specifications and other BizTalk data into a file, which is then sent to the partner. Using the Seed tools, the partner tests the configuration locally, then checks the intercompany communications link.

Once both sides are satisfied with the test results, the solution is moved into deployment mode and the documents start flowing. In short, the Seed wizard does not shortcut development, but it does allow relatively nontechnical staff to manage some aspects of deployment.

The XLANG scheduler has also been enhanced to make more efficient use of system resources. In particular, multiple instances of the same business process can now share a single message queue, and administrators can set limits on the number of scheduler objects permitted to run at once. Queues and object instances are expensive commodities, so these changes should help companies make better use of available hardware.

Where’s .Net?

We had hoped that BizTalk’s 2002 upgrade would leverage the .Net framework, Web services, and Visual Studio .Net to lighten developers’ skill requirements. But while the freely downloadable .Net Toolkit for BizTalk Server is a worthwhile step in this direction, neither the 2002 upgrade nor the .Net Toolkit substantially change or ease BizTalk development.

BizTalk is not built on the .Net framework, so all interaction with .Net code is managed through .Net’s COM (Component Object Model) interoperability layer and a set of wrapper classes provided by the toolkit. Although it is possible to write BizTalk code using Visual Studio .Net, the biggest advantage we observed over Visual Studio 6 is the ability to use the C# language.

For some, BizTalk’s greatest worth will be its excellent documentation and source code samples, both of which are enhanced by the .Net Toolkit. While learning to code for BizTalk, developers will become versed in EAI best practices and in the powerful messaging, XML processing, and communications technologies built into Windows 2000.

With these building blocks in hand, developers may find that the server components of BizTalk are not needed for smaller EAI projects. But for the big jobs and for creating a unified Windows-based EAI infrastructure that serves many departments and partners, BizTalk Server 2002 is a solid choice.