A birds-eye view of Web services

Chart the best course for your Web services programming initiative

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.

Figure 1. Indonesia: An ensemble of islands. The islands communicate via a (maritime) interconnection network, following protocols established by tradition and law. Copyright: National Geographic Society, 2001.

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.

Figure 2. Veni, Creator Spiritus, the opening of Mahler's "Symphony of a Thousand": An ensemble of many players. Copyright: Dover Publications, New York. Click on thumbnail to view full-size image.

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.

Figure 3. A cruise reservation Web service: An ensemble of software components. The components might reside on remote network nodes and communicate via Web-based protocols, such as HTTP. A Web service client coordinates interaction between service components.

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:

  1. Automate information conversion to a common format
  2. 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.

Type systems

Each line in the updates.txt file contains a record in a specified format. That format denotes the record's data type. The file itself might consist of zero or more such records separated by line break characters. That structure, in turn, defines a data type for the file itself. A set of data types produces a type system (see Luca Cardelli's "Type Systems"). You can define data types in any way you like, but XML is the most popular choice for creating a shared type system. Simple XML documents use DTDs (document type definitions) for their type specification. DTDs can be embedded inside XML files and bundled with the data, or an XML file can refer to external DTDs. However, globally shared type systems often require type definitions of greater complexity than DTDs can accommodate, and also mandate unambiguous type identification. For example, you might prefer to restrict the values a given data element can assume in an XML document. XML Schemas offer great flexibility in defining a common type system, and thus form an important Web services programming technique. (I will examine schema definitions in detail in my next column.) Once you define a type system in XML, you will receive cruise updates via documents that are instances of those types. When you receive such a document, you must bind its information into your Java program. Several tools exist for parsing XML documents and converting them into Java object representations. SAX (Simple API for XML) has been widely used for sequential parsing of XML files. For nonsequential, or random, access to an XML file, the World Wide Web Consortium (W3C) defined the Document Object Model (DOM). XML parsers supporting DOM, such as JDOM or dom4J, produce a hierarchical document representation in the form of a Java object set corresponding to elements in the original XML structure. A more recently available tool, the Java Architecture for XML Binding (JAXB), aims to automate the binding of XML-based documents into Java programs.

In addition to converting to and from XML and Java, you might also need to convert an XML infochunk from one data type to another. For instance, if one cruise line defines the element destination, whereas another refers to the same concept as destination_port, you can convert one XML element to the other by specifying this equivalence relationship. Utilizing another W3C-defined standard, the XSL Transformations Specification (XSLT), you can specify far more complex relationships between types than simple equivalence. The recently defined Java API for XML Parsing (JAXP) allows SAX, DOM, and XSLT processing capability of an XML document from a Java program. Figure 4 demonstrates this process.

Figure 4. Message format conversion between a Web service application's elements. Infochunks in proprietary data formats are presented as XML documents. XML documents are parsed via SAX or DOM, or automatically bound into Java objects via the JAXB API. You can convert between XML document types with XSLT.

Even if two XML documents conform to similar data type rules, those documents' creators may use names not understood outside their own document's context. To ensure that naming does not require global agreement for every XML document type, the W3C defined XML namespaces. When referring to an XML language specification, Web services documents typically define the namespace for that specification. Conceptually, namespaces are similar to the dot notation (.) used when referring to variables or methods inside objects, such as in myObject.thatMethod().

Message interchange

Once we define data types, and can interact with XML type instances and bind them to our Java programs, we will need to tackle data exchange protocol. Instead of Magellan Tours' reservation program checking for periodic updates on each cruise company's Website, we want each cruise operator to send Magellan an XML-formatted message and encode the update's type and data in that message. This mechanism is similar to sending an email or submitting HTML-form data to a server. The key difference: instead of a free-text email message or an ad hoc formatted HTML form, the data exchange messages conform to an XML data type. The Simple Object Access Protocol (SOAP) specification defines one such message format. A SOAP message consists of a header, a body, and an envelope. The latter encapsulates the message and annotates it with metadata, such as a reference to the message-encoding specification used to format the message's header and body.

In addition to simple data items, SOAP messages may include processing directives. For instance, a SOAP message's intended receiver might advertise a public interface with a method getCurrentPrice()that consumes a cruise vacation's name and produces the trip's price. (We'll discuss shortly how a service advertises its interfaces.) Each time the intended recipient receives such a message, it constructs the necessary objects for the parameters, executes the method, and produces a SOAP message corresponding to the method's return value, if any exists. The listing below shows a SOAP envelope encapsulating a message, including processing directives the receiver performs. SOAP documents are exchanged via different protocols, such as HTTP or SMTP, and are processed in either a synchronous or an asynchronous manner:

<
env:Envelope xmlns:env=http://www.w3c.org/2001/12/soap-envelope">
  <env:Header>
    <a:cruiseInq xmlns="http://magellantravel/cruise" 
      env:actor="http://www.w3c.org/2001/12/soap-envelope/actor/next"
        env:mustUnderstand="true">
           <a:reference>uuid:897ccba1-e342-123b-daab
jfds98as9077</reference>
             <a:dateAndTime>2002-1-10T15:32:12:000
08:00</a:dateAndTime>
    </a:cruiseInq>
  </env:Header>
  <env:Body>
    <b:travelPlan xmlns="http://magellantravel/cruise/plan">
       <b:departure>
            <b:departurePort>San Francisco</b:departurePort>
              <b:departureMonth>July</b:departureMonth>
       </b:departure>
       <b:destination>
          <b:destinationPort>Jakarta</b:destinationPort>
       </b:destination>
    </b:travelPlan>
    <c:cabinPreference xmlns="http://magellantravel/cruise/cabins">
       <c:cabinType>FirstClass</c:cabinType>
       <c:smoking>No</c:smoking>
       </c:cabinPreference>
  </env:Body>
</env:Envelope>

SOAP does not specify the underlying transport protocol to deliver the message. You can use HTTP, SMTP, or any other Internet-based protocol, although HTTP proves the most useful in practice. HTTP servers are already ubiquitous, and they listen on port 80, which is typically available for communication across firewalls. A J2EE application server, for instance, might recognize an HTTP POST command containing a SOAP document. It would then process the directives contained in that message, possibly invoking EJB (Enterprise JavaBean) components for business logic or data access. Finally, that J2EE server would encapsulate the response in a SOAP document and return it to the sender via the HTTP protocol, as Figure 5 demonstrates.

Figure 5. A J2EE server processes a SOAP message, interacting with EJBs. It formats the results into a SOAP message, and returns it to the caller.

Such synchronous interaction between Web service components is referred to as XML-RPC, as it shares similarities with remote procedure calls (RPC). Java programmers do not have to manually format and process such messages, because the Java APIs for XML-based RPC (JAX/RPC) automates much of that routine work. Instead, you can focus on message-exchange semantics. In addition, SOAP messages might be processed in an asynchronous manner, where the sender does not expect an immediate response. You can equip an SMTP (email) server to process SOAP messages. When a new email arrives, if it follows the SOAP document format, the email server could perform the actions specified in that message. For instance, it could forward the message to another person, based on a criteria set, or save some of the message's information in a database. SOAP's ability to interact with asynchronous, messaging-style applications created a need for the Java APIs for XML Messaging (JAXM) to help developers automate most routine message formatting tasks.

Describe and find Web services

Describing the syntax and semantics of document types, defining naming systems for them, and allowing XML-based messages to facilitate communication between remote system components all seem like ideas our friend needs. However, being a seasoned developer, she still isn't convinced that a Web services-oriented design suits her application best. The event that helps her decide that is accidental. As she descends from her office and heads for the subway station, she rests her eyes on the small advertising billboards gracing the escalator tunnel walls. Though she's taken this escalator many times before, today she notices the advertisements rushing by her: BlackSeaTravel.com, BlueAdriatic.com, SaltySeaVacations.com. If cruise companies, airlines, travel agencies, and hotels created electronic billboards on the Web, and advertised on those billboards not only their Website URLs, but also the types and formats of the messages they processed, as well as descriptions of how those messages must pass to them, she could write programs to automatically find the companies she could exchange messages with, and integrate their business with Magellan Travel's system.

The Web Service Description Language (WSDL) offers that descriptive ability. A WSDL file is an XML document, and the Java API for WSDL (JWSDL) lets any Java program create and read Web services description files. Because WSDL documents standardize how we document Web service software components, they can form the basis of software documentation and standardize how we access software repositories, even within one enterprise.

Several software registries with Web-wide reach are already operational. Universal Description, Discovery, and Integration (UDDI) is an effort by a business consortium that lets you advertise your Web services free of charge in publicly available UDDI registries. Currently, IBM, Microsoft, Hewlett-Packard, and Accenture offer such free registries, but the list is expected to grow in the near future. No matter which registry instance you go to, the UDDI specification requires that each registry provider synchronize registration information with others; thus, you will find the same service descriptions across UDDI registries.

UDDI resembles a yellow pages service: you create an entry for your business, specifying your business's name, and then define what Web services your company offers, how to access those Web services, and what specifications those services implement. UDDI does not require you to use WSDL to describe your Web services; you could use a human language for that purpose. However, WSDL offers a structured description format, and thus helps other software automatically find your Web services. Your program interacts with a UDDI registry via SOAP messages, and you can search UDDI registries via a Web browser.

UDDI is not the only Web-wide registry effort. The ebXML initiative aims to build a registry that includes more detailed, business process-specific information about your service. For instance, if your service forms part of a workflow application, ebXML lets you specify how other elements in that workflow should interact with your service, through the use of Collaboration Protocol Profiles (CPP) and Collaboration Protocol Agreements (CPA).

If you ever registered information with naming and directory services, such as JNDI (Java Naming and Directory Interface) or LDAP (Lightweight Directory Access Protocol), you know that directories define APIs to register with them and to search and browse them. The Java API for XML Registries (JAXR) aims to unify registration with XML-based registries. This API provides its own data model and maps that model to UDDI, ebXML, and other registry entry formats. The API's current implementation from Sun lets you interact with UDDI registries from any Java program.

From systems to frameworks

While types, names, and descriptiveness form Web services' key concepts, and while a set of Java APIs allow Web services programs to advertise themselves and discover other Web services, real-life application solutions require more inclusive programming frameworks to account for a Web services program's particular shape. Since Web service messages travel through the Internet, a public network, message integrity and security must be integral parts of any solution from the start. Several distributed computing schemes in the past considered the network transparent and eternally reliable. Their users found that, no matter how hard you try, the network remains eternally unreliable.

Java RMI (remote method invocation) was the first widely used distributed computing framework to recognize the network as an entity with its own characteristics. If we model a Web services program as an ensemble of distributed processes communicating through messages, then the network is very much a part of that software model. Thus, a Web services framework must consider network failures, and offer a programmer tools to handle those failure conditions. Without that ability, a Web services program will not function correctly.

Related to reliability is the ability to securely conduct business via Web services. Security involves being able to identify users and software services, and establish context for a Web services operation based on participant identities. For instance, a cruise trip reservation must account for the cruise line's commission rates -- that information must be discovered and securely incorporated into the context of the reservation service. For complex operations, context must guarantee transactional integrity as well.

A Web services framework must also account for privacy. Many airlines let frequent fliers obtain discounts on cruise ship vacations. Therefore, a reservation service's context should incorporate a customer's frequent flier information. Clearly, there is a point at which the customer decides that his or her privacy is more valuable than the travel discount a cruise line offers in return for personal information. The location of that point might be different for each customer, and a framework must account for that difference.

Software frameworks seldom remain mere specifications: implementations make them practical for developers, and development tools support their construction. Sun Microsystems has announced the Sun ONE Web services framework, and a subsequent article will describe what Magellan Travel's hard-working programmers think of it. IBM's WebSphere has evolved into a Web services framework; I will describe that framework's benefits also in an upcoming article. Finally, Web services frameworks come under different names. For instance, Hewlett-Packard's impressive offerings are called E-Services. And this spring, we shall follow our friend on an imaginary journey up north, where Web services are called .Net in the local dialect. As a Java developer, she will find that many of her business partners require her software to interact with .Net services.

With that thought, she senses a brief chill in the air gathering from the dark subway tunnel. In a ferocious thunder, a train roars in, halting to the tune of 100 tons of screeching metal. Once inside the car, she notices a map on the wall. Its colorful dots are the subway stations, each a small universe, connected to the others only by the narrow rail, and the subway cars ferrying passengers in between. The train starts, with a slight jerk, carrying her off into a stretch of darkness deep beneath New York City.

Frank Sommersis founder and CEO of Autospaces, a company focused on bringing Jini technology to the automotive software market.

Learn more about this topic

Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more