Using XML for describing Web Services

Jean-Jacques Moreau
Youenn Fablet

Canon Research Centre France S.A.
Rue de la Touche Lambert
35517 Cesson-Sévigné Cedex



Out of the several trends that affect the computing industry, two are noteworthy in the context of Web Services:

  1. The number of business computers connected to the Internet/the Web is large, even in countries other than the United States.
  2. The Web is increasingly being used as a place to conduct business transactions.

The latter point is a radical departure from the Web as conceived originally, i.e. a space for publishing and sharing documents. An ever growing portion of the Web is indeed being used for providing services over the Web.

There is no standard definition yet of what a "Web Service" is. Common sense suggests that these are services provided to users via the Web; and this probably involves technologies such as XML and HTTP. However, a striking difference between the more traditional Web, and its services counterpart, is that the former was built with human beings in mind -i.e. they were the ultimate users-, whereas the latter is being constructed for the sole benefit of computers -i.e. they are the ones which will drive and operate the services remotely. Examples of Web Services are: a stock quote service, an automobile part ordering service, a payroll service.

This change of focus has sparked a number of efforts, the latest being the standardization of the XML Protocol (XMLP) by W3C. XMLP enables pieces of software sitting on one side of the Web -the clients of a service-, to remotely execute functionality offered by pieces of software at the other end of the Web -the providers of the service. XMLP shares a number of characteristics with prior art systems such as DCE RPCs, Microsoft DCOM, OMG's CORBA or Java RMI. It is unique in its ability to make use of, and integrate with other Web technologies.

XMLP, however, falls short of defining how Web Services are advertised or discovered. In particular, there is no way of knowing in advance what functionality is being offered by a particular service, unless one happens to know someone who knows. This is clearly unacceptable in the long run: there is a need for a well defined, standard way of describing remote services.

Microsoft and IBM have proposed the Web Service Description Language (WSDL) as a possible solution. WSDL allows service providers to describe the individual operations that can be carried out remotely. More recently, Dave Winer has proposed ALIDL, a service description language similar in spirit to the DCOM or CORBA's Interface Definition Language (IDL). An ALIDL interface is an XML document listing the operations (name, parameters) provided by a remote service.


We have been performing work (XMLI) similar to ALIDL, although we use a syntax which we believe is more natural. Notice in particular how a "function" name (e.g. rotate) is followed by the functions' parameters (e.g. picture, angle). (Whether such a "function" maps to a function call, or is implemented by a script, a case statement or a database query is unimportant as far as this paper is concerned.)



The Web is gradually transforming itself into a platform for e-services. The forthcoming W3C XML Protocol allow these services to be accessed in a uniform and standardized manner. There is more to services than just access, though. In particular, we believe service description and advertisement is equally important -and hence probably worthy a standardization effort.