Copyright © Cloud Software Group, Inc. All Rights Reserved

Messages Mediate Interactions Between Programs

Three distinct kinds of interactions occur between programs in the Rendezvous environment:

•	Publish/subscribe interactions, such as distribution of information to multiple recipients.

•	Request/reply interactions, such as queries or transactions to individual services.

•	Multicast request/reply interactions, such as queries to one or more anonymous services.

Publish/Subscribe Interactions

Publish/subscribe interactions are driven by events (usually the arrival or creation of data)—a publisher makes information available for general distribution. Communication is in one direction (publisher to subscribers), and often one-to-many as shown in Figure 4. The complete interaction consists of one multicast message, published once, and received by all subscribers.

Figure 4 Event-Driven Publish/Subscribe Interaction

Example applications:

•	Securities data feed handlers publish the latest stock prices to hundreds of traders on a trading floor simultaneously.

•	Materials movement systems distribute data to various materials handlers, controllers and tracking systems on a factory floor.

•	Inventory levels flow continuously to accounting, purchasing, marketing and other departments in a retail store.

•	A bug-tracking database immediately sends bug reports and updates to all personnel interested in a particular project.

•	A master database publishes updates to a set of internet mirrors.

 

In publish/subscribe interactions, data producers are decoupled from data consumers—they do not coordinate data transmission with each other, except by using the same subject name. Producers publish data to the network at large.

Consumers place a standing request for data by subscribing. Consumers can listen for messages on any subject(s) on the network; a subscription is a request for messages.

Rendezvous software supports publish/subscribe interactions with multicast communication.

Request/Reply Interactions

Demand for data drives request/reply interactions. A client requests data from a server; the server computes an individual response and returns it to the client. Communication flows in both directions, as in Figure 5. The complete interaction consist of two point-to-point messages—a request and a reply.

Figure 5 Demand-Driven Request/Reply Interaction

Demand driven computing is well-suited for distributed applications such as these examples:

•	Transaction processing (as in ATM banking).

•	Database query (with a remote DBMS).

•	Factory equipment control.

 

In request/reply interactions, data producers coordinate closely with data consumers. A producer does not send data until a consumer makes a request. Each program sends its message to a specific inbox name within the other program.

The server sends replies specifically to the client that requested the data. The requesting client listens until it receives the reply, and then stops listening (unless it expects further installments of information).

Rendezvous software supports request/reply interactions with point‑to‑point communication.

Multicast Request/Reply Interactions

Like request/reply interactions, multicast request/reply interactions are driven by demand for data. While traditional request/reply interactions involve one requestor and one server, in multicast request/reply interactions multiple servers can receive the request and respond as appropriate. Communication flows in both directions, and only some servers respond to the client request, as in Figure 6. The complete interaction consists of one multicast request message, and any number of point-to-point reply messages.

Figure 6 Multicast Request/Reply Interaction

Example applications:

•	Database query with multiple servers.

•	Distribution of computing sub-tasks to the first available server.

•	Network management applications that multicast requests for test information.

 

In multicast request/reply interactions, data producers coordinate closely with data consumers. A server does not send data until a client requests it. Servers send point-to-point replies to the specific client program.

If a server has the information the consumer requested, it sends a reply. The requesting client listens until it receives one or more replies. The client stops listening by destroying the reply inbox listener.

Rendezvous software supports multicast request/reply interactions with a combination of multicast and point‑to‑point communication.

Copyright © Cloud Software Group, Inc. All Rights Reserved