Applications Messaging Standard

Mark Taylor m.b.taylor at bristol.ac.uk
Thu Feb 8 08:34:36 PST 2007


On Thu, 8 Feb 2007, 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.
>
> 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).
>
>    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.
>
>    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.
>
>    o	Be multi-language and not tied to any one messaging technology
>    	(such as Java RMI).
>
>    o	Be multi-protocol, with the same message content expressable
> 	in at least two different wire protocols (XML/RPC, JSON,
> 	OpenWIRE, STOMP, etc.).

Doug,

your suggestions of not tying such a standard to any given messaging
technology, messaging infrastructure, protocol etc sound prima
facie reasonable.  However I would like to make the point that there
are disadvantages to this as well as advantages.  If there is only
one way of sending these messages then any two systems which 
implement the standard will be able to talk to each other. 
If however there is a choice of wire protocols, message buses, etc
then there is the chance, perhaps the likelihood, that any two given 
software systems which both implement the IVOA-messaging-standard
will be unable to communicate because one is using D-Bus while the
other is using ActiveMQ, or whatever.
Protocol and message bus bridges which translate between different
choices in this respect are a possibility but could easily result
in serious complication if the number of choices gets large.

Mark

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



More information about the apps mailing list