Re: Apps Messaging - Semantics of a Message

From: Doug Tody <dtody-at-nrao.edu>
Date: Wed, 11 Apr 2007 07:49:00 -0600 (MDT)


On Wed, 11 Apr 2007, Mark Taylor wrote: 

> I would much prefer to agree on a small number of mtypes which we know we 
> need, and augment the list on an ad hoc basis as indicated by emerging 
> specific requirements of applications which need to do particular jobs.

This is basically what I was suggesting as well; the "small number of mtypes which we know we will need", is your basic object model for interoperable inter-tool messaging. After that, I suspect we begin to transition to a different model closer to stateful interactions with a specific tool/app (which is fine but it is more of a custom extension).

On Wed, 11 Apr 2007, Mark Taylor wrote: 

> On Tue, 10 Apr 2007, Doug Tody wrote:

>> 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. All that is required
>> is to specify the message content model, and version number.
>>
>> While this may sound complicated, in fact it can simplify messaging
>> quite a bit, as it becomes possible to implement the basic messaging
>> system without having to specify the message content (many existing
>> messaging systems work this way). Furthermore, since the message
> 
> What it simplifies is the messaging infrastructure (writing a hub).
> It pushes additional complexity to the client applications, which
> need separate layers for (a) receiving the message and (b) parsing
> its content.  They may need more than one of each if they wish to be
> able to operate in the presence of a variety of the defined message
> protocols, or a variety of the defined content models, that the
> flexibility allows.

Actually, this does not have to be the case, because a simplified interface/protocol (as exposed by the "hub") can be provided for inter-tool messaging. Basically, the underlying messaging model and infrastructure can be more sophisticated and usable for a wider range of things, but a simplified interface/protocol could be provided for the sort of whole-object messaging done with PLASTIC. This simplified interface might for example, support only one message content model. This would appear to be integrated into the interface, from the client applications point of view (basically the message content layer is pushed down into the "hub" to provide this simplified interface).

To do more complex things, a different interface would be required, but clients would not need to use this. What we want to achieve, is to allow those "plasticised" apps to interface to the more powerful sort of messaging infrastructure required for large data processing systems, so that they can be used without modification.

What is important is to get the underlying messaging model right. However, this is only a problem for the system designers.

Received on 2007-04-11Z15:49:56