A participant wants to initiate a conversation.
How can a conversation initiator find a partner when it has no knowledge whatsoever about available partners?
- Point-to-point communication (see Point-to-Point Channel) requires the initiator to know the conversation partner it wants to communicate with. Communication over Publish-Subscribe Channel allow a sender to broadcast messages to multiple subscribers without the sender having to know the subscribers' identity.
- Late binding between a conversation initiator and a conversation partner lowers the location coupling between them. However, it also puts the discovery on the critical path to establishing a conversation.
- Even in the presence of a central lookup service, a new participant has to first establish a connection to the lookup service. This can provide a bootstrap problem.
- Deploying new services should be easy and involve as little manual administration as possible. Maintaining a list of available conversation partners is bound to get out of date as new partners appear and existing ones retire.
The consumer broadcasts a query to the network, indicating what kind of service or services it is looking for. All potential providers listen to the query, with the ones who are able and willing to fulfill the request responding. The initiator selects one partner from the responses it receives.
The Dynamic Discovery conversation involves the following participants:
- The Initiator starts the Dynamic Discovery by broadcasting a Lookup message. Based on the received Responses it selects a conversation partner and begins the conversation.
- Potential Providers listen for lookup message and respond if they are itself with the Directory.
The process of Dynamic Discovery consists of the following steps:
- Request: The Initiator sends a service request via a Publish-Subscribe Channel. The Initiator has no knowledge of any specific service recipient.
- Consider: Potential conversation partners receive the request and can decide whether to respond or not.
- Respond: If a conversation partner is willing to engage in a conversation it replies with an Offer to the Initiator, typically via the Return Address supplied by the Requestor.
- Choose: The Initiator collects the Offer messages from the potential Providers and decides which one to interact with.
- Interact: The Initiator begins a conversation with the chosen partner. The initiator may also announce its decision to the other service candidates to allow them to relinquish potentially allocated resources.
The Publish-Subscribe Channel often takes the form of an IP multicast on a local network segment, which has the advantage that only nearby services see the request. This approach avoids flooding the whole network and increases the chances that an initiator finds a nearby conversation partner.
Both the Initiator and the Providers can apply rules as to whether they want to become conversation partners. These rules can be based on criteria specified by the Initiator (e.g. the type of service that is needed) or the state of the Provider (e.g., number of clients that are currently being served).
When collecting Offer messages from Providers, the initiator acts as an Aggregator. The Initiator has to decide how long to wait for Offer messages and how pick a Provider. Because the initiator does not know how many potential Providers may respond, the completeness condition typically employs a "first best" or "timeout" strategy.
Dynamic Discovery particularly well in environments where conversation partners appear and disappear frequently because maintaining a central list of partners is difficult to keep in sync with the reality. Dynamic Discovery can also be used to discover a registry, in which case Consult Directory follows Dynamic Discovery.
Once the Initiator has identified a conversation partner, it may use other patterns to establish a conversation. For example, it might need to establish trust with the provider before it wants to begin to exchange information. Because Dynamic Discovery establishes a direct connection between initiator without any intermediary, the communicating parties may have to spend more effort establishing a conversation.
Broadcasting across the network can be inefficient if initiators frequently look for conversation partners. Therefore, Dynamic Discovery works best with long running conversations or stateful conversations that do not require an initiator to rediscover a provider every time.
Initiators often cash the result of previous Dynamic Discovery conversations, thus reducing network traffic. This implies, though, that information may be out-of-date. Therefore, the Initiator has to be prepared that the contacted service is not available.
The initial interaction of Dynamic Discovery resembles Scatter-Gather. However, Scatter-Gather is based on a stateless Pipes and Filters model, whereas Dynamic Discovery is a stateful conversation. For example, in Scatter-Gather the initiator and the Aggregator may be completely disconnected entities, whereas in Dynamic Discovery responses have to come back to the initiator to be meaningful.
Example: DHCP
Most IP-based networks assign IP addresses dynamically: when a machine joins a network, it is identifiable at the Data Link Layer of the OSI stack by its unique MAC (Media Access Control) address, but does not yet have an IP address needed to address it at the Transport Layer. To manage the assignment of IP addresses while avoiding address collisions, a Dynamic Host Configuration Protocol (DHCP) server issues and tracks IP addresses "leased" to machines on the network. In order to obtain an IP address, though, a new machine has to first discover a DHCP server.
DHCP uses UDP broadcast packets to locate a DHCP server. One or more servers respond with an offer for a lease to an IP address. The client accepts one offer and broadcasts its decision so that other DHCP servers can take back their offers. Dynamic Discovery is a good choice for the discovery of DHCP servers because IP assignment happens relatively infrequently thanks to leases that often run several days. To manage IP addresses efficiently, DHCP servers Lease addresses for a limited amount of time.
Related patterns: Aggregator, Scatter-Gather, Consult Directory, Lease, Pipes and Filters, Point-to-Point Channel, Publish-Subscribe Channel, Return Address
