In the year 2000, many marketplaces did not achieve the
results that had been announced. Suddenly, the enthusiasm
that was buzzing around B2B has cooled. Now that we can
look at the situation with a bit of hindsight, it is easy
to explain why independent marketplaces (the main channel
for B2B exchanges over the Internet) are not taking off.
The equation never did add up
whole equation put forward by marketplaces is based on a
set of false assumptions. The word was that B2B intermediaries
on the Web would enable enterprises to find new trading
partners. And it was said that Web-based exchanges would
also enable costs to be brought down as a result of the
heightened competitiveness between suppliers.
But what enterprises actually want is to be able to plan
their purchases of raw materials or their rate of output
with secure partners, rather than having to track down the
best bargain every day. Cost reduction may be a desirable
goal but it can only be achieved through better integration
of exchanges between partners, not through artificial competition.
essential is therefore to optimize exchanges (make them
faster, cheaper) by interconnecting applications (SCM, ERP,
etc.). This is what enterprises want, and what they are
demanding. It's not necessarily about finding new partners,
but rather, stepping up and enhancing exchanges with existing
partners that enterprises have taken the time to select
and in whom they have often already started to invest. Every
new trend always has an even newer one hot on its heels,
and as the excitement in the marketplaces fizzles out, a
new notion is already gaining ground with the media: Web
Services, a definition
to Mark Colan (IBM), Web Services are "Internet-based modular
applications that perform a specific business task and conform
to a specific technical format." So, if certain processes
from your applications can be invoked over the Internet,
within a method and with a standard format, then you are
already a server of Web Services. Similarly,
if you call on certain processes external to your applications
via Internet, then you are already a client
of Web Services.
the standard at the heart of Web Services
Everyone understands that for this sort of openness to work,
you need standardized formats and methods. The good news
is that this all exists and has been available since April
of last year: SOAP 1.1. SOAP is a Remote Procedure Call
(RPC) protocol that uses standard Internet protocols for
transport - either HTTP for synchronous calls or SMTP for
asynchronous calls. SOAP uses XML for the envelope (i.e.
the format of data transmitted). The abbreviation SOAP stands
for Simple Object Access Protocol, but we could also translate
it as "Service-Oriented Architecture Protocol."
recognition and support
only does SOAP rely exclusively on well-established standards,
but it is also widely recognized by the major market players
such as Microsoft, IBM, Oracle, and even Sun. Even Microsoft's
MS.net initiative has SOAP at its core, though the protocol
has been taken on as a W3C project and and has a multitude
of open source implementations.
course, this is all very well, but SOAP is still just an
RPC, calling low-level functions and leaving pretty much
everything up to developers. In order to make it easier
to use, there is a format for describing services that can
be invoked by SOAP WSDL.
A useful addition
can be seen as a complement to SOAP, as it facilitates interoperability
between Web services. Like IDL (Interface Definition Language),
which acts as a service describer with CORBA, WSDL (Web
Service Description Language) is an XML syntax to describe
Web services. The specifications for WSDL come from a joint
initiative by Microsoft, IBM and Ariba. More and more SOAP
implementations support this description language; with
WSDL, applications that use SOAP can self-configure exchanges
between Web services, while hiding most of the low-level
are Web Services for?
the technical side of things seems to have gotten off to
a good start, we should be able to start believing the promises
made by Web Services. The next step is to ask what their
actual role will be.
The marketing departments of the leading industry players
highlight the following objectives:
implement personalized information exchange between B2B
offer and publish modular applications in a ready-to-use
is the second objective that is emphasized most by the media;
this is easily explained: after the succession of partial
failures suffered by ASPs (Application Service Providers
or outsourcing applications via the Net) and marketplaces,
the entire IT industry is desperate to find a way to sell
Web-based technical intermediation.
this context, SOAP and WSDL can be seen as the main pieces
in the puzzle, but they do not form the entire schema on
their own. As was the case for sites aimed at end-customers,
Web Services dedicated to enterprises are set to experience
a massive boom, if we are to believe the predictions. Industry
professionals, confronted by an extremely rich offering
in which it is hard to identify anything, will then have
to face the eternal question of "Where and how
does one find information?"
the market needs is a simple service enabling players to:
the right partner (the one offering the Web Service(s) you
the information necessary to be able to embark on electronic
exchange with the partner (access a WSDL document for instance).
is where UDDI (Universal Description, Discovery, and Integration)
comes in. UDDI was the brainchild of several of the giants
of the IT industry (IBM, Microsoft and Ariba, the very same
three that were behind WSDL… and it's no coincidence); it
is essentially a vast worldwide database of services offered
on the Web. At least 130 companies have promised to support
UDDI. 36 were members of the original project and a further
94 have joined the movement since. The project has already
managed to gather together companies such as Accenture,
Cargill, Clarus, CommerceOne, Compaq, Dell, I2, ICG, Rational,
Sabre, SAP, Sun, Tibco, WebMethods. All the players involved
see it as a major step forward.
UDDI offers a technical framework that is independent from
platforms and totally open, so that enterprises can find
one another, define how they will interact on Internet,
and define how information should be shared using a worldwide
registration system. The result of this project, according
to its promoters, will be that enterprises will be able
to enter the B2B world a lot quicker.
So the technical schema that we can draw up for Web Services
features the following:
- XML: format for data exchange and description
- SOAP: protocol for calling Web Services
- WSDL: format for describing Web Services
- UDDI: central organization for registering, finding
and using Web Services
Web Services to the rescue of Asps?
the truth be told, the picture is less rosy than it might
first appear. Firstly, UDDI is an application that can be
queried by SOAP, not a Web directory that any user can consult
simply by typing in a few keywords. This automatically limits
its audience, though we will soon see Web sites springing
up that specialize in querying the UDDI directory.
will restrict the success of a directory like UDDI is the
same thing that handicapped marketplaces: the real needs
of enterprises. It's more about working well with partners
you know, rather than finding new ones.
process intermediation via Web Services doesn't change anything.
What's really needed in order to optimize exchanges between
enterprises is greater close-range integration.
this mean that Web Services are just another trend that
suppliers are trying to get us to swallow?
The answer to the above is no, because SOAP-based Web Services
are an effective way to open up applications and successfully
interconnect information systems, and also to accomplish
urbanization of the information system.
to SOAP, we finally have the middleware that will enable
us to achieve client-server between applications and via
Internet - and that is a major innovation!
at least fifteen years, we have been waiting for a simple,
lightweight RPC that lets you outside of the local network.
Previous attempts failed because they weren't simple, and
they weren't standard. It's not because CORBA, DCOM or even
RMI are heavy, slow and painstaking to use that they were
dropped by developers writing Web applications. It's above
all because none could naturally cross the Firewall barrier…
does not suffer this handicap, because it's based on HTTP.
And this gives it one more advantage in terms of compliance
with real standards!
what is the true nature of Web Services? Client-server between
applications, over the Net.
way is clear for a whole new class of applications. These
will be inter-enterprise Web Services that will bring concrete
form to the notion of the hyper-EAI: openness and urbanization
of the information system on the scale of the Internet.
What is more, the logic that holds true when it comes to
opening applications up to the outside also holds true for
projects dealing with the internal integration of applications
could become easier than before to integrate existing resources,
thanks to SOAP, which has proven to be a fairly unintrusive
technique (since it is only a lightweight RPC). We will
see enterprises set up XML Hubs that will use SOAP to carry
information in order to organize inter-application exchanges,
whether inside the information system (EAI) or outwards
(hyper-EAI or interface with partners' information systems).
years ago, we all saw the rush to develop Web sites on the
Internet. Today, we will witness the rush to set up Web
Services over the Internet.