Why Web Services?
A Unicorn InterGlobal White Paper
Mike Peat
May 2002
Introduction
Web Services, seemingly made up of a host of difficult acronyms – XML, SOAP, WSDL, UDDI and so on – have been attracting an increasing amount of attention recently. Do they represent an attempt by major industry vendors to whip customers into a buying frenzy in order to shore up their flagging revenues, or are they actually something worth being interested in for their potential usefulness to business?
I take the latter view and I would like to explain why.
What are Web Services really?
Web Services are a mechanism for software applications to interact with other software applications, generally on different computers. This is not intrinsically new: from the time in 1969 the first login was attempted over Arpanet, the precursor of the Internet, (it crashed as the “g” in “login” was being typed!) computer software has been interacting across an enormous range of networks and connections.
Web Services however are not about low level communications; they are designed for “application level” interaction. Instead of your “telnet” software giving you a session on a UNIX host or your web browser allowing you to see and interact with pages from an HTTP server or your Windows Explorer displaying files from your NT server, Web Services are about your Accounting system talking to your Manufacturing system or your Inventory system talking to several of your suppliers’ Ordering systems… or your customers’ systems automatically placing orders with you!
Even this is not a new concept: for decades groups of companies have cooperated in electronic data interchange (EDI), typically to streamline supply-chain processes. More recently other, more flexible, mechanisms (Microsoft’s DCOM and the Object Management Group’s CORBA ORBs are two leading examples) have been used in this role.
So what makes Web Services different?
The thing about Web Services…
The designers of the Web Services approach (and there are many) learned from the experience of those earlier mechanisms and addressed some of their failings.
Web Services are vendor (Microsoft, IBM, Sun or whoever…), platform (Windows, Unix, Linux, etc.) and language (C++, Visual Basic.Net, Java, C#, Perl, Python, etc.) neutral. This means both that no one player in the marketplace can drive them in a direction they don’t want to go and that whatever an organisation’s computing base, they have the potential to utilise them without massive investment or change.
Web services are also relatively protocol neutral. This means that the existing protocols that underpin all sorts of electronic communication we take for granted today (because they just work, so we don’t think about them much – HTTP: the Web; SMTP: e-mail; FTP: file transfer) can be used for them. They don’t require new and untested mechanisms to be brought into play since they can be implemented over the infrastructure already in place both on the Internet and in most organisations’ internal networks.
Where previous interoperability mechanisms used arcane binary formats as the basis for their communications, Web Services are based on XML, a format which is (almost) as easily readable by humans as by machines. XML has enjoyed widespread adoption for virtually every kind of data interchange since its initial development by the World Wide Web Consortium (W3C) in 1996.
Adoption
In addition to being vendor and platform neutral, Web Services are actively being pushed by almost every major player in the computing world (yes, they do think it will make them money!).
Web Services are a core component of Microsoft’s new .Net infrastructure; they are actually one of the major things that makes .Net different. Indeed some of the protocols that make up Web Services (SOAP, and to a degree WSDL) started life at Microsoft, but have emerged from it and are no longer under its control.
IBM are strongly committed to Web Services using Java and produced the first major implementations which they then ” open sourced ” by donating them to the Apache Project (Apache is the open source web server that runs over 65% of the sites on the Web).
The Apache Foundation, which oversees Apache, created “Apache SOAP” from IBM’s offering, which has now evolved into “Axis”, a very fully featured Web Services engine that is designed (among other things) to allow existing applications to easily integrate with Web Services.
Sun Microsystems’ “Sun One” environment supports Web Services as one of its core components and of course Sun, as the developers of Java, have a direct interest in its involvement with Web Services.
Hewlett-Packard and SAP (along with IBM and Microsoft) have been instrumental in setting up UDDI repositories (explained below) and developing software to work with them.
How do Web Services work?
The basis for Web Services is SOAP, a mechanism for exchanging data in XML format between machines as discrete messages. They can be one-way (just send a message), two-way (ask a question and get an answer) or even multicast (send the same message to lots of places).
Alongside SOAP there is WSDL (Web Services Description Language) which provides a machine (and person!) readable definition of how to interact with a service, usually using SOAP, but other mechanisms such as HTML web browsing are also explicitly supported, while the specification allows for extension to whatever other media might be required. This allows a SOAP and WSDL capable program to know how to interact with a service it has never heard of before, essentially at the touch of a button.
Finally UDDI (Universal Description, Discovery and Integration) repositories provide a mechanism for finding out about what services are available, again without any human involvement (although it might take a human to make the decisions about which one of several competing services to use).
Together these provide an environment where software applications of whatever flavour can make use of each other to achieve whatever end result is required, and they can do this without technology specialists from the organisations involved arranging meetings, sitting down and working out a common specification and then developing the software to do it.
So what are they good for?
Web Services can potentially be used in many situations, rarely doing anything that couldn’t be done before, but just making the process of doing it quicker, easier (read: cheaper) and ultimately less error-prone. Here are some very simple examples.
Allowing heterogeneous systems to communicate
Most medium and large organisations which have been around for a while have accumulated disparate systems. They may well run in totally different computing environments: the Marketing Department’s NT server, the Accounting Department’s Novell box and the Production Department’s Unix mini. Traditionally if information stored on one was needed on another the solution was to write out text files on the source, transfer them to the target and then read them in there, generally as an overnight exercise (that is, of course, when the data was not manually re-keyed from paper reports!).
In this kind of environment Web Services can start by simplifying the overnight exchange process and probably making it more reliable – the system that needs the data requests it from the one that holds it and gets it back. Simple.
However, once the Web Services mechanism has been built, one can ask the question “why do they need all that data and what do they do with it?”. Frequently it will turn out that only a tiny (although unpredictable) portion of the data is actually getting used each day before it is all overwritten by the next night’s download.
With a Web Services mechanism already in place, the possibility of, say, the Marketing System being able to make “on demand” requests for customer data from the Accounting Department’s database becomes not just feasible, but sensible. Instead of continuing to replicate data from one system to another against the chance it might be needed, data can be shared as and when it is required.
This latter mechanism also has applicability to environments where physically separated sites need access to the same data. Again a traditional approach is nightly data feeds, but all sorts of synchronisation issues can raise their heads in such situations and there is rarely a totally ideal solution (not to mention the fact that night is a distinctly relative term when you have offices in London, New York and Tokyo).
With Web Services, which were designed to operate over the Internet in the first place and which can be made secure with powerful encryption, the solution becomes not replication but widespread access on demand, and at a relatively low cost. Web Services over any reasonably fast Internet connection (down to say 128 kbps ISDN) can respond not very much slower than a conventional client/server database. The attractions are obvious.
Allowing business partners to automate their interactions
No organisation is an island: every company, however large or small, uses the services of other companies, often many, many other companies. Ordering and paying for these services is the substance of the “supply-chain”, the traditional home of EDI applications.
It may be that an Inventory system already automates the ordering process to a degree. As stocks of something become low it may generate a printed purchase order to the supplier, or even fax or e-mail an order directly to them, or perhaps it just internally reminds or e-mails someone in “Purchasing” who manually processes the order. Whatever the ordering end does, it is a reasonable bet that at the supplier end the process becomes manual very quickly, with the printed, faxed or e-mailed purchase order being re-typed into the supplier’s systems. The overhead of all of this is what has made the supply chain the main focus for EDI.
With Web Services this can potentially be made both much simpler and, later, more complex. The Inventory system can simply use the supplier’s Ordering (Web) Service to place the order directly into their system. It might do this in a simple messaging fashion similar to e-mail (and might even use the SMTP e-mail protocol to do it), or it might use a request/response mechanism (say over HTTP) to get a confirmation from the supplier.
Suddenly, among competing suppliers, the ability to process a customer’s orders in this highly automated fashion would become a significant selling point to customers with Web Services enabled systems because of the reduced costs involved in doing business with them. This will drive more suppliers to offer a Web Services ordering capability. This in turn will create a marketplace of competing Web Services to chose from and open the door to allowing the customer’s systems to start to make purchasing decisions based on price, quality, delivery timescales, past history and the like without requiring any human intervention.
This might seem a touch scary, but it is worth remembering that ordering “stuff” is probably not the substance of the customer’s business; the less time and effort expended on it, the more profitable the business becomes.
Allowing the public offering of both free and charged-for services
Many kinds of service and product today can be delivered electronically rather than physically. Credit checks, company information, stock exchange prices (everybody’s first SOAP application seems to be a stock price service – it is even in the SOAP specification), computer software, digital pictures, music and video, news feeds, exchange rate information, on-line banking (money is fast becoming a digital-only phenomenon – in the not-too-distant future if you are not wired you will be poor by definition)… the list could go on and on.
In these cases it is not just ordering, but delivery and payment that can be handled through Web Services. The potential complexity of interactions, involving customers, suppliers, credit-check agencies, banks and trusted third-parties may seem daunting, but if there is one thing computers are good for it is handling complexity, especially when that complexity is only made up of numerous, individually simple, interactions.
Some services will be free. Why? Because in many cases it will be to the advantage of the supplier to provide such a service. Amazon or Barnes and Noble will doubtless offer book and other product information look-up services – for obvious reasons. Stock exchanges or stock brokers may offer price quote services to encourage people to use their (revenue generating) dealing services. Travel information and hotel room availability and pricing will be free, again because it leads to revenue. Weather and forecast information will tend to be free because you already pay for it in your taxes, while the same logic will apply to all manner of government information services.
One might, for example, imagine a “Travel Agent” application that anyone could buy cheaply. Installed on your machine, it knows nothing of the travel and accommodation services on offer, but it does know where the major public UDDI repositories can be accessed (configurable from the menu, because they may change) and what sort of things a traveller will need to book. When you want to plan a trip, it talks to UDDI servers and finds out what is on offer, communicates with those services, then presents you with the various options and prices. You make your choices and it goes away and makes the reservations, ensuring confirmation and possibly even paying for them using your credit card, or perhaps digital cash or your on-line banking facility (another Web Service). When everything is done and dusted it prints (well, it could download them to your PDA or mobile phone by IR or BlueTooth, but I like paper!) you out your itinerary complete with dates, times, flights, insurance, hotels, car rentals and maps. It would of course start to learn your preferences and categorise the choices it offered based on what you had selected in the past.
When I compare this with an attempt to book a flight over the Web that I once made which failed on “step 13 of 14” leaving me not knowing if the flight was booked or if my credit card had been debited… well you might guess that I’d buy that software!
The Web was not designed for electronic commerce; Web Services were.
Allowing software applications to be made up of distributed elements
Although we might not think of it that way, the examples above are all about distributing, to some degree, aspects of software applications.
When the Marketing system stops trying to replicate the customer information in the Accounting department’s database but instead calls it off on demand, in a very meaningful sense the Accounting database becomes a distributed element of the Marketing system.
When customers and suppliers have systems that interact automatically without human intervention, what they form is really a distributed application that is neither wholly in the customer’s system or the supplier’s, but spans both. Importantly, if there are multiple suppliers to chose from, then the application is flexibly spread across all of those competing suppliers, and indeed across all of the customers who use them.
This flexibility is important in itself: if Supplier X has their systems go down, they won’t be participating in the selection process, but customers can still place an order with Supplier Y or Supplier Z, so the distributed application is still working, in spite of one of its parts being broken. It is resilient in much the same way that the Internet itself is.
That simple message has implications for systems that will perhaps be “born” to be distributed, rather than those, like our examples, that “achieve” distributedness (or perhaps have it “thrust upon them”). The very nature of such systems and their connection mechanisms means that they need to be resilient, but at the same time it provides a natural mechanism for providing that resilience through redundancy.
Conclusion
Web Services are not a universal panacea. They will not cure all of computing’s ills or address every problem. In many situations they will have no applicability at all, so beware of the salesman who tells you they are indispensable to your business (Hey! You were getting by OK without them, right?).
What they do is to make a number of things that were previously difficult, expensive and uncertain, simple, cheap and reliable by providing a well worked-out commonly accepted approach to them. In some cases, because the tasks involved were so onerous and expensive, and the potential gains insufficiently great, they may well make things possible that were previously impossible in practice.
By doing this they promote the development of publicly available services, leading to a network environment within which all sorts of things which were never available before might be offered. They also make the consumption of those services much easier, again by being standardised, and the increased consumption that this ease leads to will make the provision of such services both more rewarding (profitable) and cheaper (because of volumes), spurring on yet greater provision and consumption.
Web Services are not a revolution in themselves, they are simply a standard which facilitates interaction, but they may well pave the way for a quiet revolution in the way we do business.
Remember that HTML was simply a standard for marking up documents to make them easy to share over a network… and look what that led to.