What Is the Biztalk Philosophy?

Like this article? We recommend 

Microsoft presents BizTalk as a new philosophy for implementing multivendor e-commerce infrastructures. It is unfamiliar territory for Microsoft, the company that has pressed a "Windows Everywhere" party line for years. The BizTalk philosophy, by contrast, calls for an e-commerce environment that, on the surface, seems to not depend on only one operating system. According to the philosophy, a BizTalk e-commerce infrastructure is multiplatform, relies on open Internet standards, and integrates applications through loosely coupled, message-passing protocols.

The core of Microsoft's BizTalk philosophy is encapsulated in the slogan "no glue," which speaks more to a technical crowd than to a general business audience. As expressed in a Microsoft white paper on the topic, the concept of "glue" permeates traditional attempts to bridge incompatible systems and applications. The paper defines "glue" as a paradigm for application integration that involves all of the following:

• Deployment of best-of-breed applications that are often incompatible in terms of their capability to share data and interface process logic

• Definition of an ad-hoc information model or schema common to the incompatible applications

• Use of a specific transport protocol for interfacing application components to each other across a network or across the bus in a particular machine

• Implementation of an intermediate layer of software adapters (either on the same or different machines as the communicating applications) for exposing the functionality of otherwise-incompatible systems, translating objects and data shared by the systems, managing transfer of objects and data between the systems over appropriate protocols, and enforcing appropriate business rules in interactions between the systems

One advantage of the "glue" approach is that it allows companies to avoid rewriting existing applications in order to get them to work together. As a result, you can eliminate the delay, cost, and trouble of rewriting one or more applications. Instead, you implement an adapter layer—usually a communication-gateway or format-translation program—that adapts the outputs of one application to the inputs of the other, and vice versa. You might also use an object protocol—such as Common Object Request Broker Architecture (CORBA)—to allow dispersed applications to behave as if they were running on the same machine under the same operating system.

Another advantage of the "glue" approach is that it gives companies the flexibility to acquire "best of breed" software packages that run on different platforms or operating environments. As long as you can acquire or develop a software "glue layer" to interface "best-of-breed" applications, you can make incompatible environments play together to some extent. You don't necessarily need to run all applications under a single operating environment, such as Microsoft Windows 2000 or Sun Solaris, to get them to interoperate.

The great disadvantage of the "glue" approach is the maintenance burden on programmers and the corresponding cost burden on companies that employ them. We can define the "glue" approach's maintenance burden through the following statements, which form a sort of "devil's syllogism" for software developers:

• The greater the range of applications to be integrated, the greater is the need for upfront systems analysis and planning at a global level.

• The greater the range of applications to be integrated, the more system analyst hours are needed to plan and oversee this integration.

• The greater the range of applications to be integrated, the broader are the ranges of programming conventions, binary data types, security contexts, and methods that will need to be bridged among them.

• The greater the range of applications and programming conventions to be integrated, the more complex is the range of potential interactions among them.

• The more complex the interactions, the more intricate and convoluted the "glue" code has to be, and the more often this code will have bugs and glitches.

• The more rapidly the various applications change, the more often the "glue" code needs to be modified.

• The more intricate the "glue" code is, the more often it has bugs and glitches; and the more often it needs to be modified, the more often it needs to be tested.

• The more often the "glue" code needs to be modified and tested, the more programmer-hours are needed to do this work.

• The more often the "glue" code has bugs and glitches, the more programmer-hours are needed to diagnose, troubleshoot, and fix it.

• The broader the range of applications that this "glue code" interfaces, the broader are the skill sets of analysts and programmers who work on this "glue code" (hence, the more expensive the technical talent needed to keep it all running).

Microsoft rightly notes that the traditional "glue" approach will not scale up to this new age of universal e-commerce, which will require heretofore unheard-of levels of end-to-end application integration across diverse companies and technical environments. The way out of the devil's syllogism of the "glue" paradigm, according to the BizTalk philosophy, is to implement more "loosely coupled" integration among communicating applications.

Under BizTalk's "no-glue" paradigm, applications don't need to be aware of each other's calling conventions—such as programming parameters to be passed, and data types and formats to be returned. Instead, you establish a universal communication infrastructure and interchange format that manages the flows of information between applications. This universal infrastructure and format will eliminate application dependencies on the locations of various software components, on the protocols that bridge these components, and on the object models and programming constructs that bind them into an integrated application service. The more universally the applications interface to a universal infrastructure, and generate and consume the universal format, the less need there will be for intermediate "glue" code to help them interoperate.

One technical basis upon which Microsoft grounds the BizTalk philosophy is a fairly recent standard called the Extensible Markup Language (XML), which was ratified by the World Wide Web Consortium (W3C) in February 1998. Another technical linchpin for BizTalk is an older technology known alternately as message-oriented middleware (MOM) or message brokering.

Let's focus on XML because this is the core technology behind the BizTalk framework. Essentially, XML provides a flexible language for defining content that carries its own application context. A "self-describing" XML document, object, or message can contain all the content and context that two dissimilar systems or applications need to ensure interoperability. Communicating applications need not share a common object model, network protocol, operating system, database, or programming language as long as they can exchange and interpret messages formatted in XML. Senders and recipients of XML documents are free to process them as they wish, without being tightly coupled to each other.

That's XML's promise, and it's well on the way to fulfilling that promise, judging by the impressive range of vendors who are implementing it and vertical markets that have based their interoperability standards on it. Microsoft is certainly not the only software vendor singing the praises of XML these days. However, Microsoft's embrace of XML as the basis for its BizTalk Framework has occasioned some industry cynicism about the company's motives. Some observers suspect that Microsoft has defined the BizTalk Framework to build hidden "hooks" that constrain users to implementing these specifications exclusively over Windows environments. There are legitimate grounds for such cynicism, but the real story is not pure black-and-white. Shortly, we will discuss limitations and catches in the current version, 2.0, of the BizTalk Framework.

Microsoft says it has gotten religion on the issue of open standards, and offers the BizTalk Framework as testament to its newfound faith. The company says it based the BizTalk Framework on two guiding principles: Use standards wherever possible, and make the process of defining the interoperability specifications as open as possible. The BizTalk Framework consists of the following components:

• A technical specification that defines mandatory and optional XML tags for a BizTalk "message envelope"

• An online repository (http://www.biztalk.org/) that contains vertical-market XML "schemas" for the e-commerce documents to be transmitted in the standard BizTalk message envelope

Microsoft claims that the BizTalk Framework realizes the "no-glue" philosophy in three ways. However, the company has left the Framework littered with caveats that could easily be interpreted as defining the need for a new generation of "glue" under the guise of XML-oriented middleware.

First, Microsoft states that BizTalk eliminates the need for applications to agree on a particular transport protocol in order to exchange BizTalk message envelopes because the framework is protocol-independent. Nevertheless, Microsoft strongly encourages the use of message-oriented middleware protocols, such as its own Microsoft Message Queue (MSMQ) protocol.

Second, Microsoft claims that BizTalk doesn't require applications to agree on or be aware of each other's calling conventions in order to exchange BizTalk message envelopes and process them successfully. However, the company has left several state variables that require some knowledge of platform-specific application contexts undefined, such as those under its Windows 2000 operating system (OS).

Third, Microsoft claims that BizTalk eliminates the need for special-purpose adapter software layers to support object and data mapping and interchange among multiple applications. However, the BizTalk Framework strongly suggests the need for a general-purpose e-commerce adapter layer, such as that provided by its BizTalk Server product.

We won't argue the metaphysical and ultimately futile issue of what constitutes the complete absence of "glue" in a distributed application environment. However, one important point to remember is that Microsoft is overstating its case when it asserts that "BizTalk applications are essentially blind"—in other words, that they need no foreknowledge of the configuration or state of other applications in order to exchange and process BizTalk-wrapped e-commerce documents effectively. We've shown that the BizTalk envelope specification leaves large loopholes for platform-specific, end-to-end implementations.

About the Author

James Kobielus has more than 15 years experience as an analyst in the distributed computing and telecommunications industry. He is a recognized authority on strategic telecommunications and information systems topics, and is an occasional speaker at network-computing industry conferences. He is a contributing editor for Network World, and writes its popular column "Above the Cloud." He is the author of more than 150 columns, books, feature articles, and buyers' guides, including Measuring Business Value of Information Technologies (International Center for Information, 1987, ISBN 0-9450-9802-2) and Workflow Strategies (IDG, 1997, ISBN 0-7645-3012-7). His latest book is BizTalk: Implementing Business-to-Business E-Commerce (Prentice Hall PTR, 2000, ISBN 0-13-089159-2).