Apps Messaging - Semantics of a Message
m.b.taylor at bristol.ac.uk
Thu Apr 12 03:07:25 PDT 2007
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 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/
More information about the apps