Apps Messaging - Semantics of a Message

[Noel Winstanley]

Hi chaps,
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  
design better.

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

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,  
polling) too.

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.




cheers
noel

On 13 Apr 2007, at 15:35, Mark Taylor wrote:

> Doug,
>
> 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  
>>> 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.
>
> The benefits that you list sound to me more ideological than  
> practical.
> 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  
> stands
> 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  
> comment:
>
>> 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  
> scratch:
> what will require some effort however is reworking existing code in
> PLASTICised applications (and, less importantly, in hub  
> implementations),
> 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.
>
> Mark
>
> 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/ 
> ~mbt/
>