Apps messaging - messaging model

[Doug Tody]

Some more detailed comments on the suggested "Messaging Model" topic.


On Fri, 6 Apr 2007, Mike Fitzpatrick wrote:
> MESSAGEs can be described generally as being a NOTIFY, a REPLY,
> or a REQUEST message.

In general at a higher level we have things like RPCs, producer/consumer
(broadcast) messages, property change events, streams, logging messages,
and so forth.

If we analyze these the fundamental message types would appear to be
just as you suggest above.  Producer/consumer messages have a single
producer and zero-N consumers.  Ditto for property change events, streams,
and logging messages.  An RPC is a synchronous request.  REPLY is needed
only for asynchronous REQUESTs.

At the lowest level, asychronous messages are most important, hence one
ends up with the list of primitives you suggest.

> A REQUEST message is one that
> asks another application to perform some action; in this case the
> application SHOULD reply explicitly with a status message indicating
> whether the request was completed, however it is not an error if it does
> not.

There is nothing wrong with an asychronous REQUEST, in fact this is a
fundamental case.  Fully event driven, distributed execution requires
asynchronous execution.  I suggest everything should be asynchronous
by default at the most basic level, with synchronous requests being
an optional feature.  This is not obvious, but is the conclusion
reached by experience with most actual successful distributed systems.

> [Note: Applications may set a property in the Hub to request
> confirmation of delivery of every message and so are free to decide for
> themselves whether a missing reply is to be considered an error.]

In general this is terribly inefficient in a distributed system
(although one might still want to have the option, e.g., for debugging
or low performance protocols).  A better approach is to have the
ability, at the protocol level, to synchronize periodically, at which
time any errors will be detected.

> 	More specifically, a MESSAGE contains an 'mtype' attribute that
> defines the semantic meaning of the message.  The concept behind the

Specification of the message type or class is fundamental.  More on this
below.


> Message Attributes
> ------------------
>
>    sender 	The <appName> of sender application.  The Hub will supply
> 		this attribute to the receiving application.  The

This is important, and can be supplied by the messaging system ("hub")
at connect time.  Discussion has suggested that this is a problem for
desktop-to-desktop scenarios, but I don't think so.  Leave the appName
up to the messaging system and it can deal with this (the "appClass" on 
the other hand, may need to be standardized).

>    recipient	The recipient of the message.  This is a String value
> 	 	supplied by a sending applicaton that may be one of the
> 		reserved words:

Probably all you need here is the appName (which is actually an instance
ID), or nothing.  The Hub is a well-known appName.  A pattern is not needed,
as this is specified by the consumer of a message, when it registers a
pattern (or whatever) for the notify-style messages it wants to receive.

>    msgid	A unique id assigned to each message by the Hub and included
> 		as a message attribute for the RECEIVEd message.  This
> 		value is returned to the sender as a response to the SEND
> 		method, the msgid will remain the same in a REPLY method
> 		message so the sender can identify the originating message.

Having this assigned by the Hub and passed back to the app for
every message is unessary and terribly inefficient, as it requires a
round-trip on every message and prevents streaming.  Since the appName
assigned by the "hub" is unique for a session, all one needs is for the
"app" (process or whatever) to concatenate a message number or some
such to the appName and you have a unique message ID for the session
(I would NOT suggest that these be persisted as someone asked about).

>    mtype 	A UCD-like string indicating the request or message type.
> 		The semantics and syntax of the mtype are described in more
> 		detail below.

This is fundamental, and is the basis for message delivery within
an "app", consumer message subscription, etc.  I much prefer
something like the UCD syntax to the ivorns used in PLASTIC.
The simplest approach is a dot-delimited message class,
e.g,. "<class>.<subclass>.<etc>", where <class> could be the
application name, or some other general message class.  However a
UCD-like syntax could provide additional expressive capability
(whether this is needed is TBD).

In general the message content can vary greatly (different protocols
could be used to do the similar things), so one might need to identify
the type of message content, however this could probably be handled
within the mtype syntax.

Versioning is also very important.  Perhaps the message (content) protocol
and version should be specified with a separate attribute.

>    refID 	An ID assigned by an app to be used as a reference to a
> 		result object in future messages it may receive.  In some

This can probably be handled within the message content, rather than as
a fundamental attribute.  It does not need to be cached within the "hub",
as I saw mentioned at one point.  The messaging system does not need to
know anything about this.

>    arguments 	A whitespace-delimited string specifying the arguments of
> 		the message.  In the case of a REPLY message this will be
> 		either a string containing the response value, or in the
> 		case of a request that does not return a value, one of the
> 		reserved strings:
>
> 		OK          Request was executed w/out error
> 		ERR         Request encountered an error
> 		REJECTED    Recipient refused to process the request
> 		DELIVERED   Recipient received the message but did not reply

This is not a fundamental message attribute.  Rather, this is the message
*content*.  The form it takes could be anything, and depends upon the
message content.  At this level it should be a block of data.  It may or
may not be text data.

The rest of the original posting starts to specify an example of message
content, so I won't comment on that here.

 	- Doug