The job of cataloguing the world's species is straightforward, methodical, and slow. Taxonomists...add an average of 13,000 species a year to the list of known organisms. At that rate it would take centuries to complete the census. Because no central storehouse coordinates the results, even the number of species named so far—between 1.5 million and 1.8 million—is uncertain.
(Laura Tangley, "How Many Species Are There?"
US News and World Report
, August 1997)
How do you find what you are looking for? At home, you might organize things any way you like, provided you find what you need quickly. If you share your dwellings with others, you must all be able to find the things you mutually need. Of course, you can still organize your own desk in any manner, including—if you're like me—completely unorganized.
At your office, more people rely on the ability to locate commonly needed forms and other supplies with minimum effort. Administrative assistants label file cabinets and drawers with the names of their contents so other people can easily locate what they need. Even if you dislike that organization method, you would not rearrange those cabinets without first asking your colleagues. Since everyone depends on the ability to find needed office items, the desire for a shared organizational structure takes precedence over personal convenience.
The way we organize our computer files mirrors the office file cabinet example. When looking for the minutes from a year-old client meeting, you'd first find the folder with the client's name, look for the Meetings subfolder, and then perhaps sort that folder's contents by date. Of course, another person might organize it differently: he might have a Work folder, then a Meetings folder, inside which he would group items by client. That difference can be problematic when you're on vacation and your coworker urgently needs that meeting note. Thus, for important files, offices typically allocate shared directories, or network drives, and create policies on where and how you should save files.
The moral here is that we tend to name things and then categorize them, assigning each category a name, in turn. That hierarchical approach has served us for many a millennium in grasping what we know of the universe. Assigning names is how things enter our conceptual world, and that naming ability lets us have language. Indeed, "spoken words are the symbols of mental experience, and written words are the symbols of spoken words." (See Aristotle.) As we discover relationships between things, we categorize them according to those relationships. That categorization is a mental experience, and the symbol for that experience is the category name. A categorization system based on names is a taxonomy.
Web service registries
While file systems rely on naming and categorization for organizing files, naming and directory services extend that concept to the network. A directory suggests it contains a complete inventory of computing resources in the realm of things it categorizes. Just as a telephone directory aims to comprehensively include all lawyers, accountants, or art historians living in a city, a naming and directory service's usefulness is greatly affected by whether it contains all the printers, database servers, users, or administrators in an organization or department (domain). When a user wishes to log into a database, for example, that database might contact a directory server to determine the user's access privileges. If a directory contained only a partial list of authorized users, its usefulness to the organization would be questionable.
To ensure comprehensiveness, naming and directory services rely on system administrators to enter all known resources within their administrative domains. Since system administrators are typically employed by the organizations whose resources they must enter, an organization can expect that its administrators do a good job and that the directory remains up-to-date.
That expectation no longer holds when multiple organizations control the things we wish to name and categorize. In that case, we hope that each organization registers the resources it wants others to know about in publicly available registries. Web services are an example of such resources. When an organization wishes to expose a Web service, it registers that service in public Web service registries. As its name suggests, a registry is a special directory that not only points users to a resource, but also lets them register services with it.
Several public Web service registries are currently operational; however, they differ in how they characterize and categorize a Web service. Universal Description, Discovery, and Integration (UDDI) registries employ a popular Web service categorization mechanism; UDDI instances are operated by IBM, Hewlett-Packard (HP), Microsoft, SAP, and a growing list of other companies. ebXML directories provide another Web service category, aimed mainly at e-business transactions. Hong Kong University currently provides a public ebXML directory. Other public Web service registry efforts are based on standards, such as ISO (International Standards Organization) 11179, the eCo Framework, or OASIS (Organization for the Advancement of Structured Information Standards). (Refer to Metadata standards.)
Web service registries not only offer more capabilities than directories, they also offer more than simple naming services. Naming implies using words to describe things, a technique that does not scale to global proportions when words must assume exact and identical meanings in all contexts. As the renaissance Dutch painter Pieter Bruegel amiably depicts, since Biblical times, the multitude of human languages has derailed many efforts to build things that rely on exactitude (see Figure 1).
So that Web services don't remain another unfulfilled vision, Web service registries allow a service provider to associate formal descriptions with a Web service. Such descriptions utilize a syntax that precisely defines a Web service. Precision extends both to a service's categorization, as well as its specification; for example, how other Web services might interact with it programmatically.
In categorization, the formalized semantics and syntax define a Web service registry's information model; while Web service description languages define a service's specification on how to invoke it. An example of the former is the structure and specification of UDDI or ebXML registries; an example of the latter is the Web Services Description Language (WSDL). Following, I will show you how to interact with registry information models from a Java program and how to categorize your Web service so that others can find it. (In an upcoming column, I will discuss service description languages, including WSDL.)
Mass-market system integration
Let's revisit our imaginary friend, whom you met in the previous Web Services column, as she sets out to construct a cruise ship reservation Web service for the Magellan Travel Agency. As you might recall, she must integrate diverse information sources from cruise lines and offer her customers a seamless search and reservation experience. As you'll see, Web services do not offer irreplaceable capabilities for such a system, but they do make large-scale integration tasks manageable and feasible.
In its initial form, Magellan Travel's system needs to do the following:
- Manage an up-to-date cruise inventory and let customers search that inventory database
- Allow a customer to reserve a cruise vacation through a set of Webpages; once a reservation is made, automatically enter that reservation into the appropriate cruise line's system
Figure 2 depicts these requirements and how various entities must interact to support Magellan Travel's application.
Without Web services, our friend could look up cruise line operators in a telephone directory, telephone them, and arrange a suitable protocol for interoperation with them. For each customer, that process would typically involve lengthy meetings and discussions with its technical staff. With limited developer resources, some cruise lines might not be able to make their senior developers—those with the most system knowledge—readily available for the project; thus, jeopardizing our friend's success. Given the cost involved, that offline integration process suggests that only the largest travel agencies and reservation systems can list cruise vacations from the most significant cruise companies. Since customers prefer reservation systems with the biggest selection, the largest companies would grow even larger, while those with less financial resources would effectively become obsolete.
Our friend needs a way to automatically discover cruise companies, including the exact specifications of those companies' network services. In addition, Magellan also needs to advertise its reservation service, letting cruise ship operators update Magellan's database whenever they change their schedules. If discovering and publishing exact technical specifications can reduce integration costs, Magellan Travel, and many smaller companies like it, could obtain and maintain the same information its larger competitors rely on.
This could lead to a benefit similar to what the hardware world has experienced for the past two decades: as PCs have simultaneously reached extraordinary computing power and mass-market prices, any business today can afford vast computing resources; whereas, two decades prior, running gigabyte databases, data mining applications, desktop publishing, or video editing were only the wealthiest corporations' exclusive domain. By bringing the ability to assemble large-scale systems out of network-bound components within the reach of mass-market consumers, Web services have the potential to commoditize software development and integration.
Web service development cycle
Just as a PC won't do your work for you (though we wish it did), Web services do not put large-scale system integration on autopilot. Rather, they suggest a software development cycle specific to Web service development. Our friend's path illustrates that cycle:
- Investigate existing standards. To ensure that her reservation service interoperates with cruise ship companies, hotels, and other business partners, she first must investigate what standards exist in those respective industries. Many Web-centric interoperation standards already exist, such as RosettaNet (manufacturing), StarStandard (automotive retailing), and the Open Travel Alliance (OTA), that aim to standardize information exchange in the travel industry. (I will survey the different standards efforts under way in a future column.)
- Build a standards-compliant implementation. Since our friend at Magellan Travel is starting from scratch, legacy integration won't be an issue. However, if you already have your own internal system, you should consider exposing that system's functionality via standards-based interfaces.
- Register her implementation with Web service registries. She names and categorizes her service according to the classification mechanism that each Web service registry offers. Later, a code example registers Magellan Travel's Web services with both UDDI and ebXML registries.
- Query Web service registries for the types of companies she wants to do business with. In addition, she might narrow her queries to those companies that implement the exact software specifications her system handles. You will shortly see an example of that query capability.
- Download a prospective business's detailed software specifications as well as any software component necessary to access its systems. She obtains that information from the Web service registries. This article's concluding section highlights how that works.
- Make, if necessary, a business arrangement with the newly integrated partner company. A vibrant effort is under way in the research and business communities to figure out how an organization can make money from Web services. Keep checking this column for a future article on electronic contracts as well as economics-based service provisioning mechanisms.
Figure 3 illustrates the Web service development lifecycle. You might note that I extended the business requirements from Figure 2 to include interaction with Web service registries to support service discovery.
Figure 3 also illustrates the participants in Web service registration and discovery:
- Registry operator: An organization that provides public Web service registries. As noted earlier, examples include IBM, Microsoft, HP, SAP, and Ariba for UDDI-based registries, and at least one publicly accessible ebXML registry operated by Hong Kong University.
- Submitting organization: The business that registers its services with public registries. It retains ownership over the information it submits to a registry.
- Content submitter: The person or software performing the registry submission for a submitting organization.
- Registry guest: A user (human or software) that browses or searches a registry's contents.