Service Discovery

The first of the seven categories in our "Services Platform" is Service Discovery. We defined this category as "The automatic identifying of a software-based service which allows processing functions to be offered and then executed after they have been located. Also includes design time notification". In determining what our standard would be we developed a set of requirements and use cases to describe the desired functionality.

The requirements are:

• The ability to publish services in a searchable repository (service directory).
• The ability for a developer to view available service bindings for a service within the IDE and select one.
• The ability for a software developer to see available service bindings for a service and select one.
• The ability for a repository to maintain a list of subscribers.
• The ability for a repository to send email notification to subscribers.
• The ability for a repository to detect a breaking change to a service contract.
• The ability for a developer to register a service as a subscriber to a particular service provider for the purposes of impact analysis.
• The ability for a service directory to have high availability by running on multiple nodes that are network load balanced.

And the use cases are:

• Publish a Service. At design time, the developer publishes the new service to the service repository via a web-based user interface.
• Modify a Service. At design time, the developer modifies an existing service and publishes the modified service via a web-based user interface. If this is a breaking change, then this invokes the notification use case below.
• Search for a Service. At design time, the developer needs the ability to query a service repository to discover whether or not a specific service exists to determine whether to build a new one or employ existing one (not re-inventing the wheel).
• Select a Service Endpoint. At design time, the developer needs to choose among service endpoints (e.g., MSMQ, .NET Remoting, SOAP) based on the relevant system requirements
• Service Directory Notifies Subscribers of Contract Change. At design time, the service directory sends an email notification to a subscribing set of developers when an existing service contract changes. This is done for the sake of impact analysis.
• Developer Subscribes to a Service. At design time, the developer registers their application as a consumer of a particular service that is listed in the service directory. Registration involves providing the mailing list (Exchange Group, but preferably not an individual email address) of the developer responsible for responding to contract changes. The value that this provides is the ability for the notificaiton use case to know who the service consumers of a particular service are and how to notify them when a breaking change occurs
• Developer Un-Subscribes to a Service. At design time, the developer un-registers their application as a consumer of a particular service that is listed in the service directory. This terminates the ability for notification.
• Application Discovers Service at Startup. At runtime during application startup, the application needs to discover initially/dynamically what channel/binding resolves to a specific endpoint and what the service contract is at that endpoint (provided by service directory). Note: It is a best practice to persist (cache) in the application the service data from most recent contact with the service directory. This mitigates any issues should the Service Directory be unavailable. This will likely be implemented in a template class that is used to derive classes that need this functionality.
• Application Discovers Service Change at Runtime. At runtime during application execution, the application needs to be able to discover dynamically if an endpoint changes or whether a contract changes and take appropriate remedy action.

As we looked at this list we found that Universal Description, Discovery and Integration (UDDI) 2.0 as implemented on Windows Server 2003 satisfied some but not all of these requirements. Where UDDI is weak (or rather non-existant) is on the subscription and notification end.

After discussing the situation with Microsoft we decided that we would provisionally adopt UDDI 2.0 on Windows Server 2003 as the standard for Service Discovery and then later (after our first deliverable) add our own extensions to provide the subscription and notification services we'll need in the long term. We felt we could afford to follow this course since most clients in our architecture will interact with the directory through a Service Agent or "proxy" that is client-side. In fact, as I'll describe later, our Service Agent abstracts the calls to the directory at runtime (the last two use cases) using the interface defined below so that we can later switch directories or implement our own.

namespace Compassion.Services.Common.Directory
{
public interface IServiceDirectory
{
IServiceEndpoint RetrieveServiceEndpointUsingUuid
(string type, string serviceKey);

IServiceEndpoint RetrieveServiceEndpointUsingServiceInterface
(string type, string serviceInterface);

void SetConnection(string url, bool secure);
}
}

We've then implemented a UddiServiceDirectory class that inherits this interface and uses the Microsoft UDDI SDK to interact with the directory. You'll notice that the basics of the interface allow for retrieving the service endpoint (an object that encapsulates the communication transport) using either the service key (a GUID like that used in UDDI) or the name of the service interface. The type parameter is used to determine which service endpoint will be returned. In our first go round we've defined "Default" and "Reliable" that map to an HTTP or MSMQ end point respectively.

And even though the UDDI 3.0 specification is published, only UDDI 2.0 is implemented on Windows Server 2003 and so that gives us the core level of functionality (the first three requirements) out of the box that we don't need to implement.