Enterprise Integration Patterns
Conversation Patterns
Consult DirectoryConversation Patterns » Discovery

A participant wants to initiate a conversation.

How can a conversation initiator find a partner across a large network without flooding the network with requests?

  • The late binding between participants lowers the location coupling between them. However, it also puts the discovery on the critical path to establishing a conversation.
  • Many networks do not route broadcast packets beyond the local network. This makes it difficult or impossible for an initiator using Dynamic Discovery to discover participants that are not nearby.
  • Broadcast or multicast queries do not scale to large networks as the network may become flooded with discovery requests.
  • Centralized administration may be involved in setting up a new service, e.g. to assure service quality. Therefore, new participants should not be allowed to introduce themselves to the network.

The initiator consults a directory, which refers it to one or more appropriate participants. Available participants register with the directory upfront.

The Consult Directory conversation involves the following participants:

  • The Initiator initiates the conversation by sending a Lookup message to the Directory.
  • The Directory receives Register messages from available Providers. When it receives a Lookup messages from the Initiator it responds with a reference to one or more Provider.
  • The Provider registers itself with the Directory.

In order to select an appropriate conversation partner, the directory has to provide a language for the initiator to express what type of partner it desires. Common strategies include:

  • Unique Identifiers: Each type of service or conversation partner may be assigned a globally unique identifier. An initiator specifies this identifier to locate a partner of the desired type. This approach typically requires manual registration of participant types in some sort of global catalog.
  • Interface Definition: An initiator may look for a service that conforms to a specific type interface. The interace may be specified by the type, which is similar to using a unique identifier.
  • Attributes: Participants may represent their capabilities through sets of attributes selected from a global set.
  • Keyword match>: Directories may not impose a structure at all, but allow the initiator to express its needs in plain text. The directory uses search heuristics to supply the initiator with services candidates.

A service directory is only useful if it keeps up-to-date with which available conversation partners. Most directories use Services Register in Directory or Directory Finds Services strategies [PLoPD5] to maintain a relevant list of participants. Alternatively, new participants can be entered by hand. The more frequently services appear or disappear, the more difficult it is for the directory to stay in sync with the real state of the network, favoring a Dynamic Discovery approach.

In order to use Consult Directory, an initiator must know how to contact the directory. This can be achieved through Dynamic Discovery or Advertise Availability as the number of directories tends to be small and fairly stable.

Because queries to the directory may be expensive, conversation initiators frequently cache results of previous inquiries. This approach reduces traffic on the directory but increases the likelihood that the initiator operates with out-of-date information. This approach is most viable in networks where service discovery is frequent, but services join or depart infrequently. A connection error on initial connect to the conversation partner helps identify outdated cached information.

Related patterns: Dynamic Discovery, Advertise Availability

Table of Contents
Describing Conversations
Hypermedia State
Conversation Vocabulary
Dynamic Discovery
Advertise Availability
Consult Directory
Leader Election
Starting a Conversation
Three-Way Hand Shake
Acquire Token First
Rotate Tokens
Verify Identity
User Grants Access
Basic Conversations
Asynchronous Request-Response
Request-Response with Retry
Quick Acknowledgment
Load Balancer
Managing Distributed Systems
Resource Management
Incremental State Build-up
Renewal Reminder
Ensuring Consistency
Ignore Error
Compensating Action
Tentative Operation
Coordinated Agreement