Successful web services will rely on open, accessible connectivity. Web services providers and their potential customers need to "talk the same language".

The alphabet soup - XML, Soap, WSML, UDDI and so on - that is currently, it might seem, in danger of swamping web services is the technologist's response to the problems of communicating in the web environment.

"To business people, it must seem like the technologists have gone mad - but web services will need all of these mechanisms if they are to work," says Simon Holloway, northern European business solutions manager for Sun One, Sun Microsystems' dedicated web services division.

"The services have to be defined in a common way so that comparisons can be made. And you need to be able to find ways to make contracts and define the processes that must take place to complete transactions." he adds.

Randy Heffner, vice president of applications architecture at consultants Giga Information Group, says there is nothing new about alphabet soup.

"There are historical parallels in earlier attempts to build universal middleware, such as the Object Management Group's (OMG) common object request broker architecture, (Corba).

"When you write this sort of code, you are building a tight high-level interface between applications," he says.

One of the main technological achievements of the internet has been to create common communications standards. A decade ago - before businesses caught on to the powerful notion of "internetworking" - commercial data communications were dominated by proprietary technologies such as IBM's System Network Architecture (SNA) and Digital's DECnet. If an organisation bought into one of these proprietary technologies, it was automatically excluded from the rest unless it invested in complex and expensive "middleware" to provide the connections.

The internet changed this, of course, and created a universal networking language that enables computers to "talk" to each other. Electronic mail and common "browser" standards for distributing and presenting text, graphics, video and audio have been made possible through the medium of the world wide web. Connection standards such as hypertext transmission protocol (HTTP) and hypertext mark-up language (HTML) spawned the dotcom phenomenon and opened the door to commercial use of the web.

But there is a significant limitation in the original design of the internet and the web. While ideally suited to the distribution of "unstructured" data such as text and pictures, there are no facilities for dealing with the structured data necessary for commercial transactions. The web has no concept of what data "means" nor how it should be processed.

This lack of a semantic dimension to data is not important in the context of the original design aims of the web, which deal with information publication and distribution. It is, however, essential for web-based commercial transactions such as ordering goods and services or making payments.

If a customer wants to order a product from a supplier or request a service, both sides need to be able to understand each other at a much richer level than the mere exchange of data. Both parties need to know exactly what a "customer", an "order quantity" or a "service level" is and understand the processes that lie behind the data.

"A unified middleware platform is imperative to the success of web services," says Rene Bonvanie, vice president of 9i database marketing at Oracle. "You need the same levels of security, integration and robustness that are associated with traditional transaction processing applications."

A plethora of additional "connectivity" methods has emerged to compensate for the limitations of the basic internet standards.

The most important of these additions is extensible mark-up Language (XML). Not only does XML provide a way to describe the "meaning" of data, it forms the basis for many other emerging standards.

Primarily, XML does the job that earlier electronic data interchange (EDI) systems used to do. The difference is that XML is universal and inexpensive compared to proprietary EDI systems.

"HTML is great for unstructured data. But you need XML to add a standard mechanism for exchanging the commercial information in an electronic document," says Mr Holloway of Sun.

"The rest of the alphabet soup is to provide ways of describing the interchange between those who provide and those who use web services."

XML defines data items such as a customer name or an invoice value so they can be understood regardless of the computer platform or application software. This means, for example, that an Oracle Financials user can link to an SAP software user and exchange data freely.

While this is a good starting point, this is all it is. XML cannot describe nor control the business processes which are essential to complete a transaction in the web environment. XML needs both a control framework and further extensions to define transactions and their business processes.

Microsoft's .Net and Sun's Java-based Sun One aim to provide different - and, unfortunately, incompatible - frameworks for XML and the other linking software needed to execute web services. Simple object access protocol (Soap) provides a way to transport XML definitions across the internet.

Other standards based on XML aim to fill the technology gaps in the web. Web services description language (WSDL), for example, describes what a web service offers and how it may be used. Universal description, discovery and integration (UDDI) is the "yellow pages" directory of available web services. It uses WSDL to describe them. E-business XML (ebXML) goes some way to describing the processes associated with an XML document.

"Web services have to be pragmatic, so they need mechanisms to make this possible.

"While the jargon makes it sound complex, the problem is really very simple: can I hear you? Can I understand you? And, can I record the conversation," observes Mr Bonvanie of Oracle.

The truth is that this "simple problem" could have been solved years before the emergence of internet if manufacturers and software developers had agreed on common standards for data description and exchange. It is to be hoped that the alphabet soup surrounding web services continues the good work of the designers of the web and the internet, rather than destroying it.

EMAIL THIS PRINT THIS MOST POPULAR