 | |||
|
Wednesday May 16 2001 How Web Services Came to Be Tracing the ancestry of Web Services Web Services, while they may feel like a completely new way of doing things, have a certain feeling of inevitability about them - a sense that they are an evolution not a revolution. In this article, we'll take a look at some of the historical imperatives that are driving us towards Web Services, and perhaps explain why the time is right for this technological development. One of the historical trends that have led us towards Web Services has its roots in component architecture. Invented over the course of the 1980s, components were originally developed in the context of graphical user interfaces - they still form the core of most GUI architectures today. Before components, applications had to be more or less atomic: single entities containing all of the required functionality. In order to re-use code from another application, you would need the source-code for the functionality you wished to borrow, and the compiled code for the functionality would be contained in both application files. As GUIs became commonplace, the issue of code re-use became more important. The functionality of, for example, a menu-bar, which was required by many applications, could simply be provided by having every application developer write their own menu-bar code, and compile it into their program; or it could be provided by giving developers a library of source code providing functions for drawing menu-bars, and providing the correct functionality when a menu item is clicked. In the first case, there would be no consistency across user interfaces of different applications. In the second instance, you would have to reveal a lot of source code in order to give developers the tools they needed. In either case, the resulting applications would contain a lot of duplicated code, which would be expensive in both storage, and memory. Components provided a solution to this problem. Instead of compiling all of the code in an application into one entity, a component architecture allows the code to be broken down into several independently compiled units, components, which communicate via an infrastructure provided by the operating system. This opened up the possibility of making use of components that had been built by other people, such as a component that provides menu-bar functionality. Instead of including the menu-bar code in your application, you include code which asks the component infrastructure to get the menu-bar component to do it for you. To do this, you only need to know two things: what the component infrastructure calls the menu-bar component, and what sort of instructions the menu-bar component understands. You don't need the menu-bar source code (it can have been written in any language which supports the component model, since it's compiled code). You don't need to worry about what's going on inside the menu-bar component. You're even isolated from how the component infrastructure communicates with the menu-bar component. In fact, this isolation allows us to do even more, and it didn't take long for components to be put to many more uses than simply building GUIs. With a little work, the component infrastructure can be changed so that it doesn't just manage communication between components on the same computer, but, by communicating with component infrastructures on other computers across a network, it manages communication between components on many different computers. This could be used to handle communications between client programs and databases, or between web servers and business applications. Distributed component architectures enabled the rapid development of complex, distributed applications. The software which manages the communication in these systems is what we call component middleware. Two main architectures have developed: The Object Management Group (OMG) developed the first specification of CORBA (the Common Object Request Broker Architecture) in 1991, and Microsoft developed the distributed version of their COM component architecture, DCOM, in 1995. When Sun launched the Java platform, it included its own simple distributed component system, RMI (Remote Method Invocation), but still relies on CORBA for heavy-duty distributed systems. Distributed components have one limitation: they can generally only be used across a tightly managed network, such as a corporate intranet. They don't play well in an open, fragile environment such as the public Internet. Web Services are, in some ways, a development of distributed components onto the public net. In the same way that component middleware allows one piece of software to make use of functionality which is contained in another piece of software on another computer, Web Services use the Internet's protocols in order to provide a component infrastructure which does the same across the whole net. Distributed components offer a relatively low-level approach to distributed programming. However, in the mid 1990s, IBM developed a new kind of distributed middleware - the MQSeries message-oriented-middleware (MOM), or message queuing, system. DEC Followed suit with DECmessageQ, and Microsoft launched MSMQ in 1996 with the Windows NT 4.0 Option Pack. MOM is a much more disconnected architecture even than distributed component architectures, because it allows the disconnection of software not simply across space, but also over time. Message queuing, as the name implies, provides a mechanism for messages from one program to be queued, and then handled by another program at a later time. Messaging systems have been one of the most interesting developments in business middleware of recent times, and also provide some of the inspiration for Web Services. Web Services do this by leveraging the Internet's existing messaging infrastructure: electronic mail. In a similar way to components, message queuing systems are generally limited to operating in closed, managed networks, and in a similar way, Web Services offer the possibility of extending their benefits across the wider world of the open internet. The third thread leading towards the development of Web Services is the interactive Web. We're all used to web sites asking us to fill in forms nowadays - most of the useful web sites in the world are based around processing of some sort of user input, whether it is search terms for a search engine, inputting an e-mail address to subscribe to a newsletter, or filling in credit card details to order a computer. All of these types of web site provide a useful service for a client, but they are limited by the fact that they have a closed interface. Let me explain what I mean by that. When I perform a search using my favorite search engine, say I type in the words 'Web Service', and click the search button, the results are returned to me as a neatly formatted web page, which my browser presents to me as graphical, human-readable information, with clickable links through to all of the sites listed. This is fine, so long as my intention is simply to browse a few sites about Web Services looking for a little information. However, if my intentions were more complex - say, I wanted to put the URLs for all of the sites which the search located into a spreadsheet, or I wanted to check each of the URLs returned against a content-rating service provided by another web site, then the information is not in a useful format. I can extract all of the information I want and then manually process it, but it is an intensive task, and if I wanted to perform it every day, it would become tedious very quickly. I could write a program which extracts the information (this is a process called screen-scraping), and automatically performs the processing I require, but it would be dependent on the search engine not changing the way they present their information, or the way their search form works. The fact is, that by limiting the interface of a search engine to human beings who fill in the form on the web site, and presenting the results only in the way the search engine provider offers, the search engine's data is limited to only a fraction of its possible uses, and in some ways, its value is therefore also limited. Many other services that are exposed over the web via this sort of human interface would also benefit from having their interfaces opened up. Web Services are also an answer to this need. So, by offering a way to build distributed applications out of components, and message publishers and receivers, across the entire Internet, where the components are the sort of services which are already exposed to people via a large number of existing web sites, Web Services are, in many ways, the logical conclusion of several threads which have been developing in the IT industry for twenty years. However, this doesn't mean we should underestimate their significance. By combining the steam engine and the wheel, George Stephenson was simply combining the logical conclusions of two established fields of engineering into their logical conclusion, but the implications of the invention of railroads can still be felt today. Web Services have something of the feel of that first steam train about them - it's going to be in interesting ride. Keep up to date with all the new articles and features on
Web Services Architect: |
