Imagine someone walked into your office and, without introduction, offered you a large sum of money if you answered this question -- in thirty seconds and while standing on one foot: Just what isa computer program?
That was the question our imaginary friend pondered one late winter morning in her office, located high above the city's bustle. Rays of sun cut through her office window, settling on her desk and illuminating the crimson letters of the title of the book that lay in front of her. She let the book rest there, unopened, while savoring a minute of being able to keep the full context of her concerns in mind, without getting distracted by the details. That book contained those details. Its title read: Magellan.
That was the name of an agency that wanted her to design an electronic cruise ship reservation system. The Internet-based system would act as a hub of sea travel information, concentrating data, reservations, and payments from many other businesses -- cruise ship operators, payment processors, airlines, hotels, travel agencies, and the like. Each business would have its own Website, and many would maintain internal e-commerce systems capable of taking reservations from the Internet. Some would already provide access via cellular phones; others would operate homepages in dozens of languages and allow payments in many currencies.
Let's follow our imaginary friend's path in this endeavor. With each step, we will have a set of programs that form the fancied Magellan Travel system. A common thread between these programs is their use of techniques and technologies that together define the term Web services. As a Java developer, you already know quite a bit about Web services, perhaps without realizing it. Thus, the journey will take us through familiar territory, placing that territory in a new context. In one regard, though, Web services aredifferent from anything most Java developers have encountered before. To appreciate that difference, we'll take the elevator up to our friend's office and catch a birds-eye view of what a Web services program looks like.
A thousand islands, a symphony, and a Web services program
A favorite cruise destination is a collection of about 17,000 islands, quite a few of which are uninhabited. On those inhabited, natives speak several languages, and their cultures, even religions, might differ from island to island. Yet, all those islands -- one of which bears the name of our favorite programming language -- collectively form the country Indonesia. If you represented Indonesia in software, it would probably be a type of
Collection. Most likely, it would also be a parallel program, as each island component operates independent of the others. Figure 1 shows this island ensemble.
However, you might prefer a river cruise down the slow-moving river Isar in the German state of Bavaria, visiting the town of Munich along your way. Ninety-two years ago, that city witnessed an amazing musical performance, where the premiere of a new symphony featured 858 singers and 171 players -- an ensemble of 1,029 musicians. The conductor, Gustav Mahler, coordinated this giant group's music making so that no performer would miss a beat. His symphony came to be known as the "Symphony of a Thousand."
Figure 2 demonstrates this type of ensemble: The performers communicate via protocols established in musical practice. A conductor coordinates interaction, which is synchronized by a steady musical beat.
Just as a map represents a real physical shape, or a musical score indicates a composition's sound, a computer program represents a physical design. Instead of having a body in physical space, the program takes its distinct shape inside the computer once it starts to run: the shape of an information machine, for which your program is the blueprint. The key difference between Web services and other types of applications lies not so much in the particular technologies Web services use, but in the shape of a Web services program compared with most other application types.
One way to grasp that shape is to consider it an ensemble. Computer scientist David Gelernter, the inventor of space-based programming (JavaSpaces is an example of a space-based program), first suggested the idea to view a software program as an ensemble of asynchronous processes. As we explore design alternatives and technologies for Web services programming, Gelernter's notion becomes an increasingly useful frame of reference: it lets us form a mental image of what Web services are. With that image in mind, we can gain a more beneficial, and practical, understanding of technologies that support Web services. The myriad abbreviations for Web services technologies -- the Web services "alphabet soup" -- will start to fall into place.
A programming model of everything
A Web service ensemble comprises software components that reside on network nodes distributed across the Web. Your Web service program acts as the conductor to ensure that this software ensemble performs according to your design blueprints. Almost every Web service technology aims to facilitate interaction and coordination between the software components that make up your Web service.
To see why this model is helpful, let's return to our friend as she commences her assignment. Her reservation program must account for information from possibly hundreds of cruise companies, must send reservation confirmations back to the appropriate companies, and may also interact with businesses as diverse as airlines, credit card companies, and travel insurance agencies. All these businesses likely use different information systems and maintain different data schemata, and their systems assume diverse reliability and availability characteristics. While integrating heterogeneous information systems has long been possible, Web services promise to bring that integration capability within any developer's reach and, indeed, within the scope of one computer program.
In the Web services universe, any one of these hundreds of information systems is a software component accessible via standard Web protocols, such as HTTP, SMTP (Simple Mail Transfer Protocol), or FTP. Each component defines an interface, hiding its implementation from external view. Except for occasional downtimes, each component is available for continuous information processing on the Web. In addition, no component has pre-existing knowledge of what other components might contact it, when such contacts might occur, or what processing load those requests would place on it.
This is a familiar picture. At any given time, Web servers, FTP servers, or SMTP servers listen for incoming calls on the Internet, process those calls, and possibly return some value of that processing's result. When a client contacts an HTTP server, that client does not know how a server implements the HTTP protocol. Behind an HTTP server might be a J2EE (Java 2 Platform, Enterprise Edition) server, a database management system, or a mere 20-line Java program. The client treats each implementation in an identical manner.
This infrastructure is already in place. However, this picture fails to explain how we might turn these services into a Java program's integral parts. The ability to represent those services inside Java programs -- or programs written in any other language, for that matter -- and to interact with those services as you would with any Java object is the key benefit of Web services technologies. As your program interacts with other network components, those components must be represented as Java objects inside your program, regardless of their representation on the network or on other network nodes -- regardless even of the programming language in which they were originally written.
The process of associating a non-Java representation of a resource -- or information chunk (infochunk), message, or document -- with a Java program is referred to as binding that resource to your program. The most common way to bind a non-Java infochunk to a Java program is to create a Java representation of that information object. Infochunk binding is a major element of Web services programming, and techniques supporting it form a key part of a Web services programming model.
Figure 3 depicts what a Web service program that interacts with Java object representations of a software ensemble might look like. The vertical line represents time, and the horizontal line represents the references inside the program. The program reaches out to other network components, each of which might be composed of Web services. The program's shape changes as it accesses various references during its execution.
Gelernter presents a similar model as a geometric program. You can lay out its design starting from one corner on the top, going down with the passing of time, and extending to the right as your program extends to other software chunks, some of which might reside on distant network nodes. You can write each chunk in a different programming language as long as it can coordinate its interaction. This model's components execute simultaneously, making the ensemble a parallel program. The model is recursive: each element might itself be an ensemble, indicating a third dimension to this graph. Gelernter suggests that such a geometric program describes any computation model (see "A Computational Model of Everything"). Inasmuch as the program outlines relationships of Web-based software services, it models a Web services-based program. We will evaluate Web services technologies and frameworks in this model's context, and examine how each technology assists in constructing such a program.
Making a system: Types, names, and descriptions
Checking back with our friend, we find her figuring out how to obtain information about cruise packages from partner companies. Batch-mode processing is as old as computer technology itself, and remains a popular data exchange method. In this scenario, each cruise company provides updates according to an agreed-upon format. A typical format for batch data transfer represents each record as a line of text, with data fields in each marked off by commas or spaces (referred to as a CSV file).
Once you've settled on a format, you must transfer those update files from the partner's system to yours, perhaps using FTP or email, or by downloading it from an HTTP URL. Thereafter, you would convert the records to your system's representation of a given data item. For instance, you might create SQL statements for each record, based on your database schema, and execute those statements against your database management system. The following snippet represents a tour operator adding a new cruise offering:
1, 20020101, Jakarta, 10, 500, 3
This agreed-upon protocol requires the first data item (
1) to signify the action taken -- the addition of a new trip. The second item indicates the date the change takes effect, the third denotes the departure city, the fourth the trip's length in days, and the fifth the price in US dollars. The last element designates the number of cabin types on the ship. A typical data transfer protocol might consist of periodically checking a specially designated file with the above format on a given URL; for example, retrieving
http://commodorecruises/updates.txtevery day at 5:00 p.m..
Arranging these file formats and protocols with many cruise operators quickly becomes impractical. Our friend needs to:
- Automate information conversion to a common format
- Automate the data exchange mechanism with a business partner
In its most basic form, Web services programming centers around these two activities. Most Web services platforms offer tools that support these tasks.