Preparing to Implement a Service Directory

The primary point of variance in directory implementations is the ServiceInformation class. Determining what information that a service directory should keep and what is irrelevant is somewhat difficult without knowing every type of user and publisher that will use the directory. The following implementation details may help shed more light on service directories before dissecting the service directory implementation:

Determine what information the directory needs to hold in the ServiceInformation class: If a company uses a private service directory, putting details about the company implementing each service in the service directory seems like a bit too much information because it will always be the same company. On the other hand, this information could play a vital role in a directory that services the world. Some applications may want to choose a business process implementation on company information.

Determine if it is appropriate to hold onto a service's proxy in the ServiceInformation class or whether binding information and the interface to the service is sufficient: Jini uses a model that pushes aproxy to a service into the directory. For Jini this is a good decision because programmers write the bulk of Jini applications using the Java platform and can therefore use the proxy downloaded from the service directory. On the other hand, you design Web Services in such a way that any language or platform can access the service directory. There is not a lot of use in putting a Java RMI proxy into the service if clients to your Web Service want to use Python.

Plan for performance concerns: The Application is the most likely component to be using the directory in the context of a larger, performance-critical operation. A directory will likely perform a lot like one of the common Web search engines. There will be frequent bursts of usage, but in general, the performance will be good. Nonetheless, be wary of expecting good performance from a service directory all the time. Applications should cache service information locally whenever possible.

Plan for scalability: Specifically, plan for scalability concerns in terms of both the number of service users and publishers that will use the service directory as well as the number of service information objects that will reside in the service directory. Both numbers will be unpredictable. An interesting aspect of the number of service information objects is that the directory will more likely increase over time than decrease. After all, how many Web pages exist on the Web that are no longer maintained but still clutter up search engines (I would guess millions).

Plan for an explosion of listings in common directories: As volume increases , it will become harder to separate legitimate services from imposters or services that represent businesses that cannot fulfill your needs. Either tight regulation of the service directories or strong self-policing of the directory space will be required. In either case, you will likely want to have an approved list of services that you allow your application to use. You can generate this list through a combination of automation and footwork. Using the directory notification mechanisms, your application can notify you when it finds a new match for a potential business partner. After you check out the potential business partner through traditional means, you should enter the information into an approved list of partners for the application to use.

Consider the service directory a service with a well-known address and binding type: There is no reason that directories should not be first class services in the Service-Oriented Architecture. In fact, the latest versions of UDDI contain Web Service Description Language (WSDL) files that developers can take off the shelf to build interfaces for the directory in their own languages.