Applications Messaging Standard

[Doug Tody]

On Thu, 8 Feb 2007, Alasdair Allan wrote:

> Doug Tody wrote:
>>    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?

The point is not to "support" all the mentioned messaging technologies,
but rather to define a simple messaging protocol which is sufficiently
independent of implementation to be possible to implement on top of
any sufficiently general messaging infrastructure.


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

I addressed this already in my response to John's mail.  Aside from
possibly making things easier for clients, the main point is to separate
the semantic content of a message from the specific wire protocol used
for transport.  Otherwise one risks becoming locked in to a specific
technology, and you have something which is more an implementation than
a standard.


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

The point is to be able to write an adapter so that some existing
TBD messaging infrastructure can be used to talk to useful tools that
already support this simple inter-tool protocol.

 	- Doug