Applications Messaging Standard

[Alasdair Allan]

Doug Tody wrote:
> In any case, the real issue here is not what the current PLASTIC  
> implementation does, but what we want for an inter-tool messaging  
> standard developed via the IVOA framework.

Absolutely, however I think the first thing we should do is take a  
hard look at PLASTIC. Its proved that it can fill the inter- 
application messaging niche extremely successfully, and has been  
widely adopted, usually from the ground up, rather than imposed from  
the top down. That says to me that its easy to develop against and  
that it does what it sets out to do well enough that people are  
willing to overlook its flaws (and I'd be the first to say there are  
several, sorry John!)...

> I suggest that this should:
>
>     o	Target simple inter-tool messaging (don't try to be a full
>     	messaging infrastructure; that is a separate problem).

Yup.

>     o	Separate protocol from implementation.  That is, we should be
>     	able to implement a message bus/hub in different languages such
> 	as Java or C, or layer the protocol on top of an existing robust
> 	messaging infrastructure such as D-Bus, MPI, PVM, ActiveMQ,
> 	Ice, CORBA, etc.  It is fine to have a simple hub (or two)
> 	developed as part of the standard, which doesn't queue messages,
> 	guarantee delivery, and so forth.

Yes, but. Surely the entirely point is that one application that  
supports this messaging protocol can talk (possibly via some sort of  
messaging hub, although we shouldn't entirely rule out peer-to-peer  
at this stage), if we're required to support all of these that isn't  
possible. What's the point of having a standard that doesn't let one  
application that supports it talk to another application that  
supports it?

>     o	Separate protocol from message content.  The message content can
>     	be defined/standardized separately.  It should be possible to
> 	easily extend the protocol by adding new message content.

Yup.

>     o	Be multi-language and not tied to any one messaging technology
>     	(such as Java RMI).

Yup, I see this as a main requirement. Whatever we do has to work in  
Java, Perl, Python, Ruby, C++ and preferably C and Fortran. I'd like  
whatever we come up with to be simple enough so that your "astronomer  
in the street" can add some code to their monolithic Fortran 77  
simulation code to talk to our cutting edge VO-aware display tools.  
That'd be nice, but that means things have to be really simple,  
astronomers may be good algorithms people, but historically they  
haven't dealt with messaging all that much or socket programming or  
any of the other things we tend to take for granted when we call  
something "easily implement-able".

>     o	Be multi-protocol, with the same message content expressable
> 	in at least two different wire protocols (XML/RPC, JSON,
> 	OpenWIRE, STOMP, etc.).

Yes, but... err, why?

> A concern is that, if in the future we try to use this inter-tool
> messaging standard in distributed data analysis system which already
> has a robust general messaging infrastructure, it should be possible
> to layer the inter-tool protocol on top of this infrastructure,
> without having to support two similar but different implementations.

Yes, but... what's the point? So people can claim they support the  
IVOA's standard? In itself that's pointless, the existing distributed  
data analysis system you're talking about has to be able to talk to a  
random "off the street" 3rd party application from some other  
developer on the other side of the planet that you've never heard of  
before.... or the entire exercise is totally futile. The reason to  
have this is so that one random 3rd party application can talk to  
some other random 3rd party application without any prior knowledge  
of it. We aren't aiming at replacing existing standards, or existing  
messaging layers here.

Al.