Apps Messaging - Semantics of a Message

[Doug Tody]

Hi Mark -

On Thu, 12 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
>
> 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".

Whenever concerns are separated like this, one tends to end up
with a more modular and flexible system while reducing overall
system complexity.  Basically, instead of trying to come up with
one grand scheme which does everything and handles all use-cases (or
over-simplifying things in which case it has to be done all over again
for the next problem), you leave much of the problem to the message
content model, which is also the part closest to the semantics of
different classes of applications.  Since this part is replaceable,
you can define a simple content model now for the case of inter-tool
messaging, but it remains possible to extend the system to handle
other cases in the future.  HTTP for example takes a similar approach.

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

Linked by the same basic messaging model and associated infrastructure
(including implementations) - which is quite a lot.  Would you
like to replace HTTP with something else for every new class of Web
application?  By basic messaging model I mean the message container and
attributes (mtype, message ID, sender, content model, etc., as Mike
outlined earlier), and the allowable semantics for message delivery.
See http://www.ivoa.net/forum/apps/0704/0319.htm

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

This is extremely important, as it will be the basis for all
the message-related protocols which are layered on top of it,
and the basis for all messaging-related software implementations.
A model like this tends to get built into all software which uses it.
It defines the basic semantics of how you do messaging.

It is fine to say you will do something now and fix it later, but if
you look the history of actual software of this type, once it reaches
a certain stage and gets used in a number of implementations, it will
become very difficult to change.  Eventually the only alternative is
to do something different.

Also: this does not have to be all that hard.  I don't think we are
far from having such a basic messaging model.  What Mike outlined
earlier, with some more work along the lines of these discussions,
would probably work for our applications (not just for high level
inter-tool messaging).

> ... rather than, for instance, one that's a bit scrappy
> but demonstrably works, and could have bits bolted on to it.

Like a different message content model, e.g., for transporting binary
data inline?

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

Yes.  If we can do this, it would provide a major piece of what is
needed for desktop data processing and analysis type applications.
PLASTIC has been very successful at addressing part of the problem,
but is not quite enough (even though it can't avoid getting into many
of the issues involved).

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

It is essential to build upon the community take-up already
demonstrated by PLASTIC, which means keeping to something similar for
this class of application.  The important thing here is to retain the
same basic architecture, semantics, and level of complexity.  I don't
think it is essential at this early stage to freeze the interfaces.
That happens when you get to an IVOA V1.0 standard.

 	- Doug