SOAP, the Simple Object Access Protocol
November 6, 2000
|
SOAP is an XML-based protocol that lets you activate an application,
or even an individual object or method within an application, across
the Internet. SOAP could revolutionize the whole process of
developing Web applications.
|
As we've observed in
previous articles, Web sites are becoming more like
applications and vice versa. At the same time, the trend toward
hosted applications is gathering steam. But many Web
applications still depend on scripting languages that were
designed to work within the limitations of HTML and slow dial-up
connections. And much existing data interchange depends on
proprietary, Web-unfriendly technology.
A group of vendors that includes Microsoft is hoping to clean up
the situation with the proposed Simple Object Access Protocol
(SOAP) standard. This XML-based protocol lets you activate an
application, or even an individual object or method within an
application, across the Internet. SOAP could revolutionize
the whole process of developing Web applications (as well as
providing plenty of opportunities for cute puns). Will SOAP scrub
away the friction that inhibits cross-enterprise applications, or
will it be a washout? We'll try to explain how SOAP fits in to
the complex world of online computing, and why it represents such
an important milestone.
At first glance, SOAP may seem like nothing to get into a lather
about. After all, it's not even a new technique — it merely
codifies the existing practice of combining XML and HTTP to
invoke methods (in an object-oriented programming language such
as C++ or Java, a method is a bit of computer code that
performs a specific action) across networks and across platforms.
And even that is merely another way to do something which has
been possible for some time using other methods (such as DCOM or
CORBA/IIOP).
However, SOAP is significant because it represents a major step
forward in the process of moving applications (and eventually the
entire Universe!) to the Web and XML. Boosterism aside, the XML-
based Web represents openness, extensibility and true platform
independence, so moving business processes thither has to be a
good thing.
To translate for the less technically-inclined, what we're
talking about here is sending a request from one computer to an
application on another computer (and possibly a completely
different platform), instructing that application to do
something. There are several ways of doing this, but the XML/HTTP
combination is far more Internet-friendly, and that's the
significance of SOAP.
Not Bubble Bath, but Business to Business
One much-touted application of XML is business-to-business
integration. "B2Bi" is the latest teen idol in the business
world, much as "e-commerce" was a couple of years ago. The basic
idea is that a business can integrate its computer systems with
those of its business partners (suppliers, vendors, customers),
eliminating redundant data entry, speeding up order turnaround
times, and generally reducing the "friction" involved in
business-to-business transactions.
For example, under the old-fashioned way of doing things, a clerk
might receive a purchase order by mail or fax, then have to key
the information into the computer network. In a more modern
scenario, the supplier company maintains a Web site (a so-called
"extranet") which lets workers at the buyer's company enter
purchase orders online. But in the absence of true integration,
the workers still have to key the information again to put it
into their own accounting or ERP
program. B2Bi software lets the supplier's and buyer's
applications talk to each other, so that the information goes
automatically to both. It also lets workers at one company run
queries to applications at another, so that (for example) the
availability and price of an item can be checked before placing
an order.
Of course, companies have been doing things like this for years
by means of EDI (
Electronic Data Interchange). EDI is a standardized way of
exchanging various types of data among applications, using the
ANSI X.12 (United States) and EDIFACT (international) standards
(Confusingly, the meaning of "EDI" has expanded, and some writers
now use the term to refer to all forms of data interchange,
including those based on XML). But traditional EDI, developed for
a world in which proprietary applications talked to each other
over private networks (sometimes called Value Added Networks or
VANs), is looking a bit elderly in the more open world of XML and
the Internet. By all accounts, it can be complicated and
expensive to implement.
EDI messages must follow rigid formats, and the companies on
either side of the transaction must have EDI software installed.
EDI code was optimized to conserve bandwidth, so it's cryptic and
hard for humans to read. XML is a far more flexible standard that
requires no proprietary software. Furthermore, EDI has not proven
to be very easy to implement over the Internet, as it doesn't
fully support popular Internet security technologies such as SSL
and HTTP Authentication. For some early ruminations on EDI vs
XML, see
XML: Evolution or Revolution?.
For an in-depth discussion of the differences, see
XML and EDI: Peaceful Co-Existence.
Companies Prepare to Clean Up
|
eBook library