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
The 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.
Ever closer
The 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.
Web Services, a definition
According 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.
SOAP, 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."
Industry recognition and support
Not 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.
Of 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
WSDL 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 technical details.
What are Web Services for?
Since 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:
To implement personalized information exchange between B2B partners.
To offer and publish modular applications in a ready-to-use format.
It 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.
Directory, please!
Within 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?"
What the market needs is a simple service enabling players to:
Find the right partner (the one offering the Web Service(s) you need)
Get the information necessary to be able to embark on electronic exchange with the partner (access a WSDL document for instance).
This 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?
If 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.
What 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.
Offering 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.
Does this mean that Web Services are just another trend that suppliers are trying to get us to swallow?
SOAP: Internet middleware
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.
Thanks 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!
For 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…
SOAP 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!
So what is the true nature of Web Services? Client-server between applications, over the Net.
The 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 (EAI).
It 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).
Four 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.
The True Nature of Web Services
)