Dialogues and Monologues

Dialogues and Monologues

Two kinds of conversations can occur with Web services: dialogues and monologues. Dialogues are the conversations between exactly two parties with messages flowing to and from both parties. Monologues are conversations between one primary message sender and any number of message receivers.

Figure shows a monologue in action. The idea is that a single message sender can send a series of messages all belonging to the same session. This series of messages can be related in any number of ways. It's important to note that there can be any number of receivers of this same message (in Figure labeled as A, B, and C).

The uses for such a monologue are interesting. Backward communication to the sender from any of the receivers is not requisite for an interesting application. In fact, the receivers don't even need to be using the messages in the same manner.

For example, the messages being sent could contain the status of the server, including information such as CPU utilization, available memory, and size of the primary process. The first two receivers, A and B, could be management applications such as Hewlett Packard's OpenView or Microsoft's Operations Manager.

However, the last receiver, C, may be a backup server that is watching to see if it needs to start processing requests in order to replace the message sender. Or, C could be an application that will send out alerts via SMS (Short Message Service) or pure phone dialing of pagers once certain thresholds are seen.

Other applications of a monologue are for streaming information such as news, stock quotes, and media (e.g., music and video). Any of these could have a number of clients. Permitting an architecture in which the message sender doesn't have to worry about messages from a large number of receivers allows for a highly flexible design.

Dialogues are much more common than monologues; when Web services are deployed, they usually are dialogues. The Figure illustrates the basic idea of a dialogue.

A dialogue is a conversation between two parties. Both parties send messages, and both parties receive them. The key characteristic is the presence of a long series of messages, not necessarily request–response message exchanges. These messages may be a part of several sessions, although generally any one conversation would equate to a single session.

Ultimately, the notion of a long running exchange of messages could yield some interesting scenarios, particularly if by long running we are talking about not just seconds or minutes, but hours or days—or perhaps even weeks. (That's not to say that a conversation couldn't last longer than weeks, but my mind can only believe so much.)

Examples of these scenarios include the purchase order example I've used throughout this book. Taking into account the actual time it may take to process a purchase order, and that the process may require human intervention, you can easily see how allowing days and weeks would help. The steps are easy to extrapolate:

This process could continue indefinitely, as status and other information is continually traded. In fact, this same dialogue could later include an invoice. The point is that we have two logical message senders and message receivers that engage in a dialogue of messages. That dialogue is long running, yet flexible and powerful enough to deliver everything required. Notice that e-mail integration is an obvious feature with this kind of system. If you require near real-time notification without history, an IM (instant messaging) system such as MSN Messenger would also be a likely candidate.