SOAP won't clean middleware's messy reality

By James Kobielus
Network World, 05/22/00

The Internet won't mature as an e-business environment until the industry converges on middleware infrastructures that bind billions of heterogeneous components into a unified computing web.

Everyone agrees that new standards for e-business middleware must address several key business-to-business requirements that traditional approaches don't support. Business-to-business middleware must use HTTP as the principal transport protocol. It must specify XML as the primary content-encoding syntax. It must work across diverse operating environments, object models and programming interfaces. It must rely on asynchronous message-passing communications. And it must be able to traverse enterprise firewalls without compromising end-to-end network security.

XML-based remote procedure call (RPC) technology is a promising middleware approach that appears to satisfy many of these criteria. XML-based RPC technology enjoys significant backing from Microsoft, which has banded with other companies to develop and proselytize the Simple Object Access Protocol (SOAP).

SOAP is a solid specification that addresses the core requirements for XML-based RPCs. But even SOAP's most fervent advocates admit that it - or any other XML-based RPC - would be inadequate for tightly coupled applications that have relied on traditional synchronous RPCs or object-oriented frameworks, such as the Common Object Request Broker Architecture (CORBA) and Distributed Component Object Model (DCOM). And SOAP lacks features necessary for a full-blown distributed-computing environment, such as mechanisms for creating, instantiating, naming, locating and managing distributed components.

Of course, the notion that there needs to be a single business-to-business middleware protocol or framework is beginning to seem quaint and outmoded. What we're seeing these days is the development of a new type of business-to-business infrastructure, the interchange server, that bridges dissimilar middleware environments, transport protocols and document formats for the purpose of connecting trading partners and enterprise applications. Interchange servers are essentially e-business workflow engines. They validate, map, translate, manipulate and route electronic data interchange (EDI) documents, enterprise resource planning system outputs and other objects between dissimilar applications and systems.

Interchange servers, also called integration brokers, will become the backbone of most business-to-business and enterprise application integration deployments. Interchange server vendors include large firms such as IBM, Oracle and Hewlett-Packard, as well as smaller middleware vendors such as Bluestone Software, Excelon, Mercator Software and NEON Systems.

It's no surprise that Microsoft has pinned its e-business software architecture on an interchange server of its own - the upcoming BizTalk Server 2000 product. Microsoft is clearly hedging its middleware bets with this product. BizTalk Server 2000 will support interfaces to SOAP as well as to the vendor's established middleware technologies (DCOM, Microsoft Message Queue Server and Microsoft Transaction Server) and Internet-standard transport protocols. However, Microsoft overstates its case when it claims that the product interfaces to any format and any protocol. For example, BizTalk Server 2000 is notable for its lack of support for CORBA and Internet Inter-ORB Protocol, which compete with DCOM. It also lacks built-in adapters for some competing message brokers, transaction monitors and XML-based business-to-business message formats.

But that's just Microsoft being Microsoft. What's interesting is that Bill Gates and crew have embraced considerable (although not complete) heterogeneity in their e-business middleware architecture. Another interesting development is that Microsoft is not assuming it can push through a new de facto standard unilaterally. Clearly, it's not banking on SOAP as the future middleware standard that blows the competition away - or even pushes DCOM and other proprietary middleware approaches into early retirement.

For sure, SOAP and other XML-based RPCs will assume important niches in an increasingly tangled, multiplatform middleware fabric. They will probably become an important technique for linking companies' business applications across extranets and trading hubs, supplementing traditional EDI workflows.

Nevertheless, e-business environments must weave new and old middleware approaches into a robust new synthesis. Heterogeneity is the stubborn reality we must all embrace as we integrate diverse business processes. No single integration framework can do justice to all networked applications.