Apps Messaging - Semantics of a Message

[Rob Seaman]

Noel Winstanley wrote:

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

The IVOA exec often gets something different than it asked for :–)

With no smiley, I think either path being discussed would be  
responsive to the WG's charge.

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

Here you're arguing both ends against the middle.  CORBA is the  
poster child for design by committee.  I also don't think that the  
discussion has been about a generalized messaging system.  Whatever  
"astronomical applications messaging" is, it isn't this.  A main  
architectural question is whether "VOOOM" (or whatever it will be  
called) will be constrained to applications running on a single  
host.  That doesn't sound like CORBA to me.

I'd also argue that the astronomical software community itself  
contains many of the "better qualified people".  We're a small, but  
feisty, group that attracts interest from many larger players due not  
only to the niftiness of the science of astronomy, but also to the  
interesting bit of computing phase space that astronomical use cases  
transect.

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

This is an interesting take on the discussion.  The fundamental issue  
is whether interoperability is a requirement.  If not, then two (or  
more standards) are a viable option.  On the other hand, if functions  
like "data-exchange" must be interoperable with functions like  
"invocation", then both must be realized by the same design.  That  
design, however, may permit staged or partial implementations.

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

These aren't applications, these are composite systems each hosting  
multiple applications.  I would think a main point of VOOOM would be  
to permit these systems to interoperate one with the other.  What  
you're describing is a situation in which a client would have to use  
different technologies to communicate with each system.  In that  
case, each client becomes its own "hub" and each programmer must  
develop her own task-specific equivalent of VOOOM.

Rob Seaman
NOAO