Apps Messaging - Semantics of a Message

[Phillip Warner]

On Tue, 10 Apr 2007 11:45:05 -0600 (MDT)
Doug Tody <dtody at nrao.edu> wrote:

> On Tue, 10 Apr 2007, Mark Taylor wrote:
> 
> > To respond to Doug's comment about wanting various alternative
> > argument transport formats, this could be only one (the default?)
> > of several possible argument transport formats.   For instance
> > instead of passing individual arguments in this way you could have
> > a single _argblock attribute which passes a packed data structure
> > containing the information.
> 
> I just want to amplify this point.  It appears that everyone agrees
> that it is a good thing to separate the messaging mechanism from
> the message content; the messaging infrastructure shouldn't know or
> care what is in the message, it just delivers it.  We can go one step
> further and specify that the infrastructure just delivers the message
> payload as an opaque blob of some sort, and it is up to another layer
> of software to compose or interpret the message.

To take this a step further, if you use, e.g., Java interfaces, you can
specify what the underlying messaging infrastructure should be capable
of, and leave it up to the programmer to implement the details.  This
way you can specify that the underlying protocol should have the
ability to, e.g., use transactions, guarantee delivery, yada, etc.  In
essence, the interface is the contract-wrapper around the underlying
protocol.

That way, the next-gen (or whatever it will be--still PLASTIC?) hub can
be coded against the interface, and rely upon "injection" of the
messaging implementation. The hub doesn't have to change with different
protocols.  Only the implementation of the interface has to change in
order to adapt the messaging implementation.  This depends on who is
deploying the hub.


> 
> Hence in this view what we have are the basic messaging model,
> specifying the message attributes and available delivery semantics,
> one or more message content models, specifying the message payload,
> and one or more messaging protocols, specifying how a client
> application interacts with the messaging infrastructure.
> 

So, I think my response was a restatement Doug's last sentence above.

Phil