Introduction

As outlined in the first part of this article, referencing services greatly extends their visibility and promotes their capitalization. When most of the time services are deployed somewhere and accessible from a fairly static location, it happens that, to cater particular business needs that we will be outlined later on this post, some services requires to be discoverable in order to be accessed transparently regardless of their particular location at the time. This document covers such a requirement by exposing how to combine open standards and WCF to publish services in such a way that they can be discovered dynamically at runtime based on custom business criteria.

Service Referencing

Dynamic service referencing and discovery in general are complementary to static referencing and address different business requirements.

Dynamic Service Discovery

Requirements

Prior to take advantage of discovering services at run time, two major points must be addressed and settled. First, because discovery has a cost that is not negligible it must be used only to address particular business needs. Then, it must be handled with the scope of a business contract. This contract defines the way the service can be discovered as well as the options available for interacting with it.

Discovery is costly

By nature, discovery is costly either on the network because discovery requests will have to be sent across the whole network using multicast or either on pure processing because the discovery will add a few extra steps in the way you access a service. By using discovery, you cannot just have the service’s access points in your configuration or in a repository (remember part I of this paper).

A full use case of taking advantage of discovery requires those steps:

· Send a request on the network for services matching a business requirement,

· Receive all the responses from the services,

· Select the most relevant one,

· Act accordingly which means extracting the selected service’s metadata in order to dynamically generate a proxy in order to communicate with this service.

As you can see these are extra steps that increase the client side effort required to communicate with a service. Compared to just using Visual Studio’s “Add web/service reference”, it becomes obvious that it would be foolish to use discovery all over the place just for the sake of calling dynamically services. This highlight once again the fact that discovery must respond to a business requirement and must be evaluated as such before deciding on using it.

Discoverability driven by business need

Taking the decision to expose a service as discoverable must be done in the light of a business requirement. The overhead induced by such discoverability must be balanced with the benefits you get out of it. Some business scenarios require services to be discoverable because they’re occasionally up, they are nomad and are not always accessible at the same location and so on… We will quickly describe few scenarios later on this paper.

Existing service selection solutions: BAS/TPM

Existing products and technologies already address service selection based on a set of business rules; a product such as Microsoft Biztalk offers Trading Partner Management (TPM) as well as Business Activity Services (BAS) that allows selecting business partners. This mechanism rests on well defined static business contracts as well as a predefined set of rules. This is similar to what discovery requires in the sense that business contracts must be settled first before starting discovering services. The rules equivalent used by BAS/TPM is represented as criteria. Where BAS/TPM offers dynamic selection of existing, referenced services endpoints, discovery allows going one step further and adds dynamic communication between client and service.

Business contract settled

The first thing to complete before even thinking about launching Visual Studio to hit the discovery API and start discovering dynamically services is to clearly define the business contracts responsible to formalize the way a client can interact with such a service. This also helps identifying if the service in question should even be discoverable at all. Doing this preliminary step with discovery in mind will help you evaluate which operations should be discoverable and can, and probably will, have an impact on the way you design and decompose your business contracts. This is a crucial step to complete in order to ensure a proper use of discovery and avoid useless discovery overhead on operations that do not require it.

Negotiation phase finalized

The approach taken here in relation to the discovery requires that a “negotiation process” occurred prior to starting discovering services. Those services are already well known, they are driven by a well known business contract, and the only unknown piece of information at the time of discovery is the location of the service responding to a particular business need. The lever allowing switching between existing services are defined by search criteria as explained bellow.

Search criteria defined (Extended search criteria with business context which is not included in business contract)

Discovering services is all about being able to specify custom, business oriented criteria that are relevant to the discovery. Those criteria must be though through and evaluated in such a way that they can conveniently be set in place, computed and interpreted. At the same level that one must define the business contracts that will dictate the way services are exposed as discoverable, one must define the search criteria that will be used to discover such services.

Use cases

Because, as outlined previously, one must be careful to where to take advantage of discovery, it is important to outline a few sample use cases where discovery can help addressing business requirements. The most obvious advantage of using discovery features in your environment is to reduce the effort required to register your services within an information system as well as provide business attributes in order to easily discover relevant services based on business criteria.

Goal: Reduce registration effort

Here are three sample use cases that highlight the benefits of using discovery to either reducing registration service effort, cope with services occasionally connected as well as nomad users that requires to connect to specific, context driven, services.

Nomad services

A salesman visiting clients worldwide often has to connect to the office VPN to either download or upload data in order to do day to day work. By taking advantage of discovery as well as his geographical position, he can transparently find to the most relevant local branch to connect to in order to

Disconnected services

When dealing with occasionally connected services, it is important, in order to offer the best quality of service, to be able to find active services that respond to particular business requirements. Using discovery in such scenario, allows querying the information system for active services addressing a particular business requirement. This query mechanism can be sharpened to include specific business or technical parameters to ease the look up process and provide a transparent experience from a consumer point of view.

N3RD – Command Center

During wild fires in south of France, firemen have to deploy a remote command center close to the incident. Because of time constraints, there is no time to waste to setup and register this new, temporary, command center. This is where discovery comes into place; it allows the remote command center to register onto the network so the calls related to the fire are routed automatically to this new virtual station and not to the existing fire stations. Once the fire is over, this temporary, remote command center is then switched off and disappears from the information system. No calls can be routed anymore to this command center.

Video demonstration

A demo video of WS-discovery in action is available here.

This demo addresses the N3RD Command Center use case described above and contains 3 parts:

1. The client runs a probe match on the network and several stations respond to it. (Client doesn't know which fire station must be selected).

2. Fire stations respond to the client request and indicate their respective geographical position. The client then picks the closest one.

3. The client sends a custom probe message indicating its geographical position, only services located within a 3 miles range respond to the request. The client picks the closest one.

In the last part, we used header injection in the address in order to call dynamically the service.

Standardization

There are multiple ways to technically address such a capability. Where anyone could implement its own solution to this problem it is critical to offer the most open solution. This is all about discovery therefore if you want your services to be discoverable the worst path to follow would be to implement a custom proprietary discovery protocol. In the same way, open standards allow exposing services metadata, so regardless of the platform you are working with; you can query, read and interpret those metadata. The same concern is true for discovery, being discoverable requires following standards so third parties or different platforms can still discover your services.

Business service must focus on business it serves

Adding to a service the capability of being discoverable must not interfere with the business purpose of the service. Such a capability must not require any specific code on the service itself and must be able to be plugged side by side with the service it exposes as discoverable. The implementation that we will describe later on takes into account this fact.

Dynamic discovery is a technical service

Discovery is a purely technical process allowing addressing business requirements. Such a capability must not interfere with the business in any way. The discoverability footprint must be reduced to the maximum in order to ensure proper business throughput.

Use a specification with large adoption

Discovery is all about the ability to be discoverable for the services requiring to be exposed as such. It is therefore crucial to follow standards in order to ease interoperability with existing technologies or products. There are numerous standards driven by consortiums that helps standardization and promotes interoperability. Within the WS-* galaxy, there is one specification targeting discovery: WS-Discovery.

WS-Discovery

The implementation presented here is based on Vipul Modi’s work published here that offers a very good baseline for building an effective and extendable business oriented service discovery.

This specification, driven by few major actors of the IT world such as BEA, Microsoft, Intel, Canon etc…, defines a multicast discovery protocol to locate services. As a WS-* specification, it quickly becomes the de facto protocol when dealing with dynamic service discovery. The implementation presented bellow follows this specification and ensure a wide openness with existing platforms as well as the largest scope to provide the widest discoverability. The full WS-Discovery specification is available here.

Maturity

This specification is already widely available for device discovery thanks to UPnp, SSDP and Windows Rally initiative. Windows Vista uses this standard for discovering devices capabilities and offering or exposing relevant functionalities. For example, when displaying your network neighborhood, your residential gateway can expose its configuration page so Windows Vista can add an extra contextual menu allowing opening up the gateway’s configuration regardless of its actual IP address.

Smart implementation

This discovery process as outlined in the WS-Discovery specification follows the famous Publish - Subscribe pattern where a discoverable service joining the network sends a multicast Hello message notifying all the listening parties that it is available. In the same way, before shutting the service down, it notifies the same listening parties that it is leaving and will therefore not be available to serve requests anymore by sending a Bye message. During the time the service is available and discoverable, it is able to responds to discovery messages sent across the network, again following WS-Discovery specifications. This technical capability must not interfere with the business purpose of the service. Such a service cannot afford to take execution time to respond to discovery messages.

Relayed and diffused infrastructure

As mentioned above, a service cannot waste time servicing pure technical operations. Therefore, a dedicated mechanism must be setup to expose the discovery capability of the business service without interfering with the business value the service brings. In order to address that, a separate, purely technical, service is automatically created and started along with the business service. It runs as separate instance with the only purpose of exposing discovery and responding to discovery requests. The diagram bellow outlines the architecture put in place clearly separate business value from technical capability brought by WS-Discovery:

As this diagram suggest, there is a clear separation between the business scope of the service and client and the discovery process and the discovery process never interfere with the business operations.

Few messages exchanged

WS-Discovery is based on very simple, yet powerful, set of messages. By offering Hello and Bye messages, the publish/subscribe pattern can be easily implemented. In conjunction with those two messages, come two types of messages allowing querying for discoverable services: Probe and Resolve.

Identity card to extend

The specification describes a common identity card specifying a set of common attributes that a discoverable service must expose. As described in the class diagram bellow, these are: AnyAttributes, AnyElelments, EndpointAddressAugust2004, MetadataVersion, Scopes, Types and XAddress.

Extensibility driven

Thanks to WS-Discovery specification openness (with AnyAttribute and AnyElements) the messages are endlessly extensible to cater any specific business requirements. One of the goals of the WS-Discovery implementation exposed here was to provide the most convenient extensibility model in order to allow developer to easily define custom, business oriented messages that provides a friendly business centric client side discovery mechanism. The class diagram bellow describes this architecture:

As you can see, by inheriting from ServiceProperties class, it is trivial to declare a custom, business focused, specialization of it that exposes the geographical position of the service declared as discoverable. Using the same technique, messages can be specialized as EmergencySiteHello class suggests. Again, client side, the same technique is used to create business centric MatchCriteria that allows discovering services based on business attributes, see CallerMatchCriteria.

Going further

Microsoft Surface

Such a technology could greatly extend the applicative discoverabilities of Microsoft Surface. Any application can easily take advantage of this discovery mechanism based on business or technical contracts as well as custom criteria thus react appropriately with devices or applications in range of the Surface.

Going further than just a way to connect applications and devices, such a technology can open a broad new range of scenarios where opened applications could be modified or notified by discovered devices or services and provide a deeper interaction between human and machine.

ESB Toolkit (Resolve UUID)

A cornerstone of an enterprise service bus (ESB) is the service repository that it maintains. The notion of static and dynamic referencing address in this two part article can be directly applied to an ESB by taking advantage of both UDDI for the static service referencing and WS-Discovery for dynamic service discovery. The extra step that an ESB should offer is a dedicated proxy allowing taking advantage of WS-Discovery in order to provide a transparent communication initiation.

Getting started with our implementation

This article comes with a fully featured getting started kit walking you through two samples in order to get you started quickly with our implementation of WS-Discovery. The kit is available here

Links

The pdf version of this paper is here.
The demo video is here.

Format: wmv
Duration: --:--