acm - an acm publication


Software message terminology

Ubiquity, Volume 2002 Issue January, January 1 - January 31, 2002 | BY Kersasp D. Shekhdar 


Full citation in the ACM Digital Library

Even IT managers can sometimes have problems distinguishing between a request, a notification and an event. This article reveals the differences and similarities between software messages.

With the advent and evolution of distributed computing, messages of different kinds between communicating processes were introduced and implemented. The differences between these messages are sometimes obvious but are very often subtle. Furthermore, some terms are used as pseudonyms for each type of message. And finally, many project managers today are increasingly non-technical even as they adopt a more hands-on style.

Miscommunication between management and technical developers is rife, with developers often not taking the time to educate their managers not only on the details but even on the basics. The net result is a common misuse of terminologies that results in crossed-wires or sometimes in total miscommunication. A case in point is the fact that the order-entry systems of one of America's largest telecom companies is falsely thought by managers and even by some developers to be an built on a true event-based messaging architecture. The reality is that it is built on a messaging system based on notifications and callbacks between tightly coupled processes!

Undoubtedly some sectors of the IT industry suffer from confusion about the terminology of messaging and lack of full knowledge of the essential differences between their types. This article seeks to cut through the confusion. By providing real-world analogies and a table of differences based on their properties, we seek to define and differentiate request, notification, and event such that they can be understood by layperson and expert alike. In addition, several messaging terms are also briefly explained with reference to the main topic.


The problem of being unable to distinguish between the different messages is not exclusive to non-technical IT managers! As variations on existing paradigms get developed, new terms get introduced, and distinctions become blurred, inaccurate terms can get used by anyone. Even in the exceptional and rightfully famous work Design Patterns, Gamma, Helm, Johnson & Vlissides make a fairly common mistake in their "Observer" aka "Publish-Subscribe" pattern. They state "Subject ... knows its observers," "ConcreteSubject ... sends a notification to its observers when its state changes," and "ConcreteObserver notifies its observers whenever ... ." The unfortunate notion has crept in, that although the observer, of course, observes the subject, the subject also has full knowledge of its observers! Thus per the description, Gamma's "Observer" is actually a variation on the traditional request-based model (cf. telephone example below) and not a "Publish-Subscribe" model as Gamma et al. claim. (This is not an isolated case; a related misunderstanding is found in Apple's WebObjects manual.)

The important thing to understand in the Publish-Subscribe pattern is that the "subject" need not know, perhaps even should notknow, its observers let alone message them of anything; for all the subject knows there may be a hundred observers observing it -- or none at all. To paraphrase Jacobsen who said it best: "Everybody knows the King of Sweden. But the King of Sweden does not know all his people." (from Object-Oriented Software Design.)

(Note: In computing science, the term event is used to denote software-originated events based on state-change (regardless of their earliest origin), as well as user-originated events such as individual keystrokes and mouse-clicks. This article construes "events" to mean the former.)

Real-World Analogies

Imagine a person calling up on the phone and asking for you by name. That person then tells you that some charity is soliciting money and asks you for a donation. The caller waits for you to say something and now it is your turn to reply. You may pledge some money or refuse to do so. The caller may then say something else causing you to give a second reply. Or if you are offended by the caller, you may just hang up. But you do not simply ignore the caller and just stand there holding the phone doing nothing at all.

Now consider yourself listening on the radio when the newscaster talks about some natural calamity such as a flood or earthquake. The newscaster has no idea that you or anyone else is listening; you are decoupled via the ether and the airwaves. You may directly contact a charity. Or you may take other actions such as tell your friend what you heard or publish this information in a newsletter. Or you may ignore the message entirely and do nothing at all. Similarly other listeners will take one of the several courses of action that were open to you.

Finally, think of receiving a notice from your bank. The notice is addressed to you and any other joint account-holders personally, and regards the specific matter that a cheque you deposited was not honoured for which reason the bank has charged you a returned cheque fee. The bank has simply given a message to you directly and the expectation of a reply is not there. You may take subsequent actions such as contacting the maker of the cheque or reporting the incident to the financial crimes division. Perhaps you may contact the bank to ask a question or try to get a refund of the fee. This third case is a type of message that is "in-between" the other two, combining as it does elements of each of them.

The Software Equivalents

Software designs are quite analogous. In the first case, one process issues a synchronous request upon another process that does some work while the caller blocks, waiting (assuming it is single-threaded). Whatever the caller "said" i.e. the arguments it may have passed, will influence the reply of the callee. The caller may then send another request to which the callee will return another reply. And finally if the caller's message is unacceptable to the callee, e.g. if its arguments are out of bounds, the callee may raise ("throw" in C++) an exception or it may abort(). The callee cannot message the caller because it is anonymous. (Notwithstanding any message headers.) A request is a synchronous message; this is also known as a round-trip message. The most well known examples of requests are the messages sent by an SQL client to an RDBMS server.

Likewise in the second case, if one process receives a specific kind of event that it has "tuned in" for, it may do some work as a direct result of reception of the event. The event-publisher has no idea of who is subscribed to its events; the two are decoupled via an event-hub. The second process may pass on the event to some object it has a reference to. It may examine the arguments and do some processing. It may well generate an event of its own. Or it may ignore the received event entirely. An event originates as an asynchronous message; this is also known as a one-way message. A proper implementation of CORBAServices' EventService in which event-suppliers would publish events to an event-channel that decouples the suppliers from the event-consumers is an example of this type of message.

For the third case, the caller sends one or a limited number of well-known processes a message. The caller then goes on its way -- it sent the notification to a known process but typically does not care about any response. The target does whatever processing it is supposed to as a result of the notification, which work may involve communicating with other processes -- including the caller itself. If the target has a reference to the caller, it may "turn around" and send the caller a message. Such messages are known as callbacks. If the notification and callback messages recur, the paradigm is known as conversation. Notifications are usually sent as asynchronous messages, but they may be sent as synchronous messages too with the reply merely being used to indicate receipt of the message. This is analogous to the bank sending a bounced cheque notice by regular mail for the most part but possibly sending it by certified return-receipt mail in some instances. As an example of this type of message, consider a bank's Withdrawals Management System. For any withdrawal attempt that generates an error, the system sends a notification (with data) to a subsidiary Error Transaction System, and a Security Log for these to process however they may.

Properties of the Different Types of Messages

The properties of a request, a notification and an event -- all of which are messages -- are tabulated below. Their similarities and differences are evident. For the first three properties, request and notification are similar and event is different. For the next three properties, notification and event are similar while request is different. For the last two properties, each of the three is unique.

(R) = Request ; (N) = Notification; (E) = Event

(R) Targeted message
(N) Targeted message
(E) Scattershot message

(R) Invoker knows target
(N) Invoker knows target
(E) Invoker does not know recipient(s)

(R) Invoker finds or knows target & the target is passive
(N) Invoker finds or knows target & the target is passive
(E) Recipients tune-in and locate invoker, thus target is active

(R) A single message goes to one particular target
(N) A single message goes to one to a limited number of particular (known) targets
(E) A single message goes to zero to many general (unknown) recipients

(R) Caller waits for a rep
(N) Caller does not wait for anything
(E) Caller does not wait for anything

(R) A return is expected
(N) No reply or action is expected
(E) No reply or action is expected

(R) Invoker will know something about the resulting behaviour of target
(N) Invoker will probably not know anything about the resulting behaviour of recipients
(E) Invoker will not know anything about the resulting behaviour of recipients

(R) Invoker & Target are tightly coupled and one of them is dependent on the other
(N) Invoker & target are tightly coupled but they work independently
(E) Invoker & recipients are entirely decoupled and they work independently

Kersasp Shekhdar holds a BS in computer science from SMU, Dallas and has worked for seven years as a software engineer. His work focuses on backends and industry-independent software such as generic engines, bridges/gateways and tools. He has recently segueued into project leadership.


Leave this field empty