Everything you need to know about Web services
To the outsider, information technology is made up of many strange things whose purpose and nature are as elusive as pixie dust. Within IT, Web services has the same shimmering, numinous feel.
What it is seemingly depends on whom you ask: for a marketing manager, Web services is the key to integrating disparate networks of disparate clients, servers, appliances, data, users and programs. To a programmer, Web services are application programming interfaces, object definitions and protocols. To the casual observer, it is an excuse for an endless stream of claim and counterclaim between acronym-heavy consortia; they are ideas of great importance whose benefits are hard to quantify.
Which is a shame. Web services software is very important and easily described: it is a set of XML-based standards and programming guidelines that allow applications to swap data over the Internet. With it, you can take any aspect of your company's data management and computing processes and link it to another division, another company, end users or whoever you like, pretty much independently of whatever systems they are using. By mediating and automating the process of sharing data across the Net between heterogeneous systems, Web services has successfully combined some of the most powerful ideas in the history of computing, and have done so in an open, non-proprietorial way -- in theory and, to some extent, in practice.
Distributed data processing is nothing new. It first started in earnest when minicomputers and workstations began to become popular in the 60s and 70s, because they were much cheaper and more flexible than mainframes -- which did all processing centrally and used terminals merely as input/output devices. But minis and workstations still needed to share data and cooperate in how they processed it, so a variety of methods were evolved to allow one computer to control a process on another. These were proprietary but surprisingly powerful. At the same time, the idea of objects caught hold, where data and code were encapsulated in one entity -- this proved a good match for remote processing, as you could send an object in a message and expect it to be handled properly.
As PCs evolved, they took up these ideas. Standards such as Corba, and Microsoft's COM and Dcom were attempts to put objects over networks, but variously had issues with interoperability, scalability and proprietorial control. At the same time, though, the Internet, email and the World Wide Web became enormously successful precisely because the protocols were universal, scalable and truly, purely open. Various schemes for putting EDI (Electronic Data Interchange, one of the antediluvian ancestors of Web services) over Internet protocols were cooked up, but the big bang in Web services was kicked off by XML, the eXtensible Markup Language.
XML emerged in late 1996 as a way to create structured Web documents that could contain arbitrary data in standard ways. By agreeing on schema -- sets of rules in XML -- two or more companies wishing to share data in machine-readable ways could do so over the Net, using standard tools. In short order, XML-based ways of running procedures on remote machines and of sharing objects were evolved: one of the most important has been Soap, the Simple Object Access Protocol, but WSDL, UDDI, and others have sprouted. In simple terms, UDDI says where services are, WSDL describes what they do and Soap talks to them, but this description can be inflated to a shelf full of foot-thick books as quickly as you can wave a credit card at Amazon.
The business of implementing systems using these protocols has led to a proliferation of alternative frameworks, toolkits, and ways of building and deploying components built out of objects. The major camps are Microsoft's .Net framework, and Sun and IBM's Enterprise Java Beans (EJB), a division that is prototypical of many current Web services issues.
It is politically incorrect to create proprietary systems these days, as too many people have memories of being locked into one company's architecture and suffering high prices and low performance as a result. The correct attitude is to espouse open systems that anyone can use -- provided they are your open systems and you have a privileged position. Thus, much of the energy in the standards bodies is being expended by ad-hoc consortiums trying to outflank each other. For example: there is a need to send XML documents between systems and be sure they arrive -- the bare bones Web messaging protocols don't do this.
In February, Sun, Oracle, Fujitsu, Hitachi, NEC and Sonic Software submitted a standard called Web Services Reliable Messaging to the Organization for the Advancement of Structured Information Standards (Oasis). But in March, Microsoft, IBM, BEA Systems and Tibco unveiled a specification called WS-ReliableMessaging (WS-RM), which does the same thing in an incompatible manner. It has yet to be presented to a standards body, either Oasis or the World Wide Web Consortium (W3C), both of which have fingers in the Web services pie.
This is far from unusual, and is the major downside to Web services at the moment. It was spotted long ago that one could claim 100 percent compliance to open standards by using XML for everything, but create a de-facto controlled system by defining and controlling schema. This conflict between open systems -- what developers and companies want -- and closed, proprietary areas of influence -- what the vendors want -- is often more important than the stated engineering or business reasons a particular vendor promulgates in support of its stance.
It's not the first time such a dichotomy has existed in IT, but Web services has a very important role to play in the future of every aspect of computing. When it works -- as with Amazon -- they can create entirely new areas of economic activity: it is impossible to imagine a future online without them, hence the intensity of vendor propaganda around the issue. The engineering aspects of future Web service standards are open to debate, but what actually happens will hinge on political and commercial events far more than the raw suitability of various technical approaches.
Find out more about Web services in this IT Priorities Special Report:
Everything you need to know about Web services