Apps Messaging - Semantics of a Message

[Mark Taylor]

Hi Doug,

On Wed, 11 Apr 2007, Doug Tody wrote:

> 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.

Very well, by doing it like this you can put the extra complication 
into the hub rather than applications, which is greatly preferable. 
(Parenthetically: I don't see how this scheme fits with your 
claim that it "simplifies messaging quite a bit".  It may simplify 
the overarching abstract description of the messaging system, but 
any complexity you lose there has to reappear by the time you get 
down to a prescription that applications need to follow in order 
to implement it - things like parsing of parameters have to happen
*somewhere*, and if there's more than one way it can be done 
you're going to need to specify it more than one way and implement 
it more than one way.  I guess simplicity usually turns out to
be a slippery concept.)

That aside ... it seems you're talking here about something like a
collection of linked protocols (linked by what - the same "messaging
data model"?), or at least of different profiles of one overarching 
abstract protocol.  This would seem to imply that you're going to
end up with various different applications which are all
"IVOA messaging protocol compliant", but which can't all talk to
each other.  Is this a correct analysis of what you're saying?

> What is important is to get the underlying messaging model right.

I'm not trying to be funny, but: why?  Leaving aside any difficulties
about coming to agreement on the details of such a model, can you 
explain what you see as the practical advantages of having a "right"
messaging model rather than, for instance, one that's a bit scrappy
but demonstrably works, and could have bits bolted on to it. 
We haven't been too explicit about this so far, but I presume what 
we're talking about here is adopting within the IVOA a messaging 
protocol which would replace PLASTIC (as well as providing facilities 
for other modes of messaging).  If that protocol differs significantly 
from what PLASTIC currently looks like, the cost to those developers 
who have already invested effort in it, and to some extent for the 
astronomers who are using their applications, would be quite 
considerable, so an explicit list of what you see as the benefits 
of such a course would be a useful contribution.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/