Understanding the Structure of a Service Directory

Service directories are flat structures with deep associated structures that represent the data they store about a service. Depending on the amount of data a service directory chooses to store, the structure may become complex underneath the service interface. An essential point to remember about a service directory is that it too is a service; therefore, the directory lies underneath a single point interface.

Figure 5-1 illustrates the participants in a service directory. The ServiceInformation is the most volatile part of the design diagram. Requirements and designs of different Service-Oriented Architectures drive different designs for the service information.

Figure 5-1: Service directory class diagram

The structure and operations on a service directory make it similar to a database structure. Interestingly, if you consider the service directory as a participant in a service environment that exhibits both implementation and location transparency, it is not important what architecture you use to implement a service directory.

The ServiceInformation association to the ServiceImplementation contains an interesting twist in the world of Service-Oriented Architectures. This association does not have to be a classic aggregation or composition relationship between the components . Instead, the ServiceInformation must contain enough information for an application to bind to and communicate with the real service implementation.

Understanding the Components of a Service Directory

You need to consider five major components in a service directory and the context for the service directory. Two components, Directory and Service Information , are a part of the formal directory. The ServiceImplementation may or may not reside within the Directory itself. The following are the service directory components:

Directory: The service directory is the primary point of contact for publishing, locating, registering for notifications, and maintaining directory entries. To a component on the outside of the service directory, the directory appears to be persistent and always available. Service publishers determine the contents of the service directory, and applications locate service information through the same interface.

ServiceInformation: Service information is the core asset of the service directory. There are zero to n pieces of service information associated with a service directory. Actual contents of the service information vary based on the particular Service-Oriented Architecture implementation. For example, Jini registries have proxies to the services published within the directory. Web Service directories only contain information about how to bind to and communicate with a service, not a service or proxy to the service. Common types of information are the service interface, information about any standards that the service adheres to, what business owns the service, and additional information about the service itself.

Application: An application uses the location and registration operations on the service directory. Applications leverage the directory to locate suitable implementations of business processes. Applications use the notification methods to wait for specific services to enter the directory or to make sure they get notified if there is a change in an implementation or status of a service.

Publisher: The service publisher is an intermediate component that leverages the publishing operations on the directory to publish information about a service. Occasionally, the service itself acts as the service publisher, but considering the components separately allows a decoupling of the service implementation from the particular service directory implementation.

ServiceImplementation: The service itself never directly interacts with the service directory (unless it is a self-publishing service). A service information component resides in the directory that represents information about the location and interface to the service as well as any additional contextual information about the service. Frequently, the service does not know the contextual information or its own location.

Of the previous components, the ServiceInformation component is the most volatile of the high-level design components. The "Using Universal Description, Discovery, and Integration (UDDI) for Web Services" section discusses a concrete example of the primary service directory used in a Web Service environment, UDDI.

Understanding Service Directory Collaborations

Most collaborations within a service directory are similar to those you would see on a database (create, read, update, and delete). Advanced service directories, such as UDDI version 3, go further than the original versions to support the ability to register for changes within the contents of the directory. The primary collaborations in a service fall into two categories: service users who want to locate particular services and components that publish information about a service. The collaborations are as follows :

Publish: A Publisher pushes information about a particular service through the Directory interface. Often, the service publisher creates an instance of ServiceInformation and passes it directly to the Directory for publishing.

Delete: A Publisher can delete service information out of the service directory by invoking the delete operation and identifying the proper service information to remove.

Update: A Publisher can update service information through the service directory interface. Service publishers use the update operation to change and add company information (such as contacts), change the location of services, or change some status information about the service.

Locate: An application locates one or more service information objects through the locate interface on the service directory. The application passes a filter to the service directory, and the directory uses the filter to select appropriate service information objects for return to the application. The service information objects returned to the application contain all of the information that a user requires for contacting a service directly.

Register: An application registers with a service directory to receive updates based on some filter criteria. The filter can apply to updates to the service directory that do not correspond to a single existing service information object, or the filter can apply to a specific service information object. The former would capture service directory changes such as the publishing of a service information object; the latter would capture an update to a service information object.

Notify: The Directory notifies all registered application components when publishing, creating, or updating service information. The notification occurs based on filter criteria set by the service user. Filters could apply to changes to the service directory or to changes to specific- service information objects.

From all of the previous collaborations, not even one has to interact directly with the service. The ServiceInformation object serves as the information someone needs to bind to and communicate directly with the service. Web Services give you the interface for the service as well as the location and communication protocol to use to contact the service. Different designs and contents of the ServiceInformation class enable different approaches.

Figure 5-2 illustrates the basic sequence of events, ignoring temporal aspects of the sequence. A publisher creates a service information object and publishes it to a directory. Some point after that, an application uses the directory to look up a service. The directory returns the service information object to the application. The application creates a representation of the service to use in their process, such as a proxy or full-blown architecture adapter, and then communicates directly with the service.

Figure 5-2: Collaborations between directory components

It is important to remember that upon publishing, the information about your service leaves your control. Once in a public directory, your service is available for any number of productive or nonproductive uses. It is important to prepare for thousands of users, and it is important to prepare for people who may misuse your service.