Apps Messaging - Semantics of a Message
Noel.Winstanley at manchester.ac.uk
Mon Apr 16 03:41:46 PDT 2007
I'd like to stick my head above the parapet and state that I agree
with Mark & Alasdair's position.
It is my understanding that it was the real-world success of plastic
that piqued IVOA's interest in messaging. I talked to several of the
exec whilst at moscow - the impression I got was that their desire
was for a plastic-like cleaned-up international standard. And that it
should be agreed swiftly, so that we can all get on with using it as
a stable standard, so benefitting from plastic's main aim 'let each
application concentrate on what it does well'.
Although designing a generalized messaging system is attractive I
don't think that this is what we've been asked for. There's plenty of
these already in existence - from CORBA, through COM, to SOAP -
designed by more, and better qualified people than us. Actually,
some of these aren't even very good - but I doubt our committee will
Despite, or maybe because of it's simplicity, plastic has shown
itself to be adequate for the real-world usage of data-exchange. It's
been popular with developers and more importantly users. And I
believe that it's this usage that this working group has been
mandated to standardize - not generalized messaging.
I understand that a plastic-like design would not be a good fit for
all the use-cases suggested in this discussion. The poor fits are,
roughly, some form of invocation mechanism - calling tasks on IRAF,
for example - rather than the 'data-exchange' mechanism of a plastic-
I've been listening with interest to the discussion, as a
generalized invocation mechanism would be something that would
benefit Astro Runtime too. However, I'm not convinced that invocation
and data-exchange are similar enough to make it worthwhile to fit
them within the same (family of) standards.
In a data-exchange system, the messages are better known than the
applications - it's the messages that are standardized, and
applications implement the standard to produce or consume these
messages. In an invocation system, the applications are better known
that the messages - each application has it's own 'api listing' of
messages that it, and only it, accepts. Because of this, applications
in a data-exchange system can be substituted for each other, or not
even be present, yet the system will still do something sensible. In
an invocation system, the applications are more tightly-bound, as the
messsages are application-specific - and if an application is
messaging IRAF, well, only IRAF will do.
If I were to expose the AstroRuntime functionality over a messaging
system, I'd need to define a new message for each operation (either
that, or use a more untyped message such as invoke [operation-name]).
I don't see what benefit this gives over accessing the API using
existing XMLRPC, RMI or SWIG interfaces. In fact, it seems worse - as
the client has more hoops to jump through to invoke an operation and
has less type-safety. Maybe it's the asynchronicity that's appealing
- but that too can be available through an API (callbacks, listeners,
To me, a standardized messaging system only seems appropriate when
the applications are substitutable. Where a client is explicitly
coding against the API of a particular application (be it IRAF,
VOClient, Aladin Scripting, AstroRuntime), then it may as well use
that application's own native access method - as the client is
tightly-bound to the functionality provided by that application anyhow.
On 13 Apr 2007, at 15:35, Mark Taylor wrote:
> On Thu, 12 Apr 2007, Doug Tody wrote:
>>>> What is important is to get the underlying messaging model right.
>>> I'm not trying to be funny, but: why? Leaving aside any
>>> 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.
> The benefits that you list sound to me more ideological than
> As you can probably tell, I am somewhat (though not totally) sceptical
> that designing a multi-layered model-based abstract generalised
> messaging architecture followed by separately designing multiple
> alternative prescriptive specifications of how to implement this,
> as opposed to starting with the specifications of what applications
> need to do in order to talk to each other, is the best way to go
> about things. Such additional layers of abstract design *may*
> pay dividends, but only if it turns out that new messaging
> situations arise which both are difficult/impossible in the basic
> profile and must/should share part of their specification
> with it, and it's not clear to me that that will be the case.
> Such multi-layered approaches also face dangers not presented by
> one-size-fits-all designs, such as the possibility of partial
> implementations and of "compliant" implementations or messages
> which are mutually incompatible. Whether I am being admirably
> pragmatic or woefully short-sighted here will only be answered
> by future developments.
> However, we're probably not going to progress further on this by
> continuing to argue about it. Some people in the debate are more
> concerned with how the data model underlying messaging is formulated
> (with a view to permitting various different implementation profiles
> as needs arise in the future), and others are more focussed on
> sorting out the nuts and bolts of what an application has to do
> in order to participate in a messaging or data-sharing conversation,
> in particular on issues like bootstrapping a connection with the hub
> and selection of a wire protocol. To some extent these concerns are
> orthogonal (though of course the former will influence the latter),
> so I think we should be able to come up with something satisfactory
> to both sets of interests without too much disagreement.
> *If* we go down the route of revolution (scrapping PLASTIC as it
> and replacing it with something which can do similar things but which
> may have advantages such as more flexibility and securer theoretical
> underpinnings) rather than evolution (incremental modifications of
> the existing PLASTIC standard to allow it to do new things where new
> capabilities are required), then I am happy that this is done along
> lines similar to those that Mike and Doug are advocating, although
> there are still matters of detail to address. I agree with the
>> 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).
> as far as it applies to the task of specifying a standard from
> what will require some effort however is reworking existing code in
> PLASTICised applications (and, less importantly, in hub
> and organising things such that the changeover between the existing
> and future messaging systems does not leave users with tools on
> the desktop unable to to communicate because they speak different
> messaging protocols.
> The opinions in this message are basically my personal ones; I've
> got some idea, but I'm not sure, how far they are shared by other
> active and passive participants in the debate, and I don't wish to
> push them if they are not widely shared. It might be a good
> point for such participants who have an interest or opinion
> (particularly those who hope in the short or long term to adopt
> whatever it is we end up agreeing on) to provide input about
> where they stand on these issues.
> P.S. I should mention that I will be away all next week; I understand
> that John Taylor and Alasdair Allan will also be busy.
> 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/
More information about the apps