NetworkWorld: SOAP won't clean middleware's messy reality

Date view	Thread view	Subject view	Author view

From: Rohit Khare (Rohit@KnowNow.com)
Date: Mon Aug 07 2000 - 12:40:36 PDT

Next message: Tom Whore: "Needlepoint pirates"
Previous message: John Klassa: "Re: The elder Obi-Wan is dead"

>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.

Read that again. --Rohit
====================================================================
http://www.nwfusion.com/columnists/2000/0522kobielus.html
SOAP won't clean middleware's messy reality
By James Kobielus
Network World, 05/22/2000

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.