Applications Messaging Standard

[Doug Tody]

On Thu, 8 Feb 2007, John Taylor wrote:

> On 8 Feb 2007, at 15:12, 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.
>
> I agree that this is desirable.  There might be a trade off here between the 
> wire protocols we can offer in a Hub, and the languages it is possible to use 
> to write one.  We probably don't need to worry about as many languages as we 
> do for client applications messaging though.

At least for the simpler wire protocols, it should be possible to implement
the infrastructure with almost any language or technology.


>>    o	Be multi-language and not tied to any one messaging technology
>>    	(such as Java RMI).
>
> Again, in my view there's no question that we should be multi-language.  But, 
> the range of languages and platforms we want to support could influence 
> technology choices, so....which ones do you think we must support?
> http://www.ivoa.net/twiki/bin/view/IVOA/ApplicationsMessagingInitialQuestionsSeventeen

For the desktop case, where users get to choose their favorite
tools, languages, or analysis environment, and where we might
want to interface to any client application, I think it has to be
possible to interface to any popular compiled or scripting language.
Of course someone might have to write a language binding, but if the
wire protocols are chosen carefully, probably there will already be
interfaces for all the major languages.


>>    o	Be multi-protocol, with the same message content expressable
>> 	in at least two different wire protocols (XML/RPC, JSON,
>> 	OpenWIRE, STOMP, etc.).
>
> I think this is still an open question - there's arguments for and against.
> http://www.ivoa.net/twiki/bin/view/IVOA/ApplicationsMessagingInitialQuestionsFifteen
>
> My feeling is that we should ease the job of the client programmer where we 
> can by providing several wire protocols even though this complicates life for 
> the "Hub" author.

Not only is it desirable to make things easier for client applications,
it is important to help ensure that the protocol is not tied to any one
implementation technology.  "At least two" would go a long ways to help
ensure that this is the case.

The sort of thing which is likely to happen eventually is that we
implement a protocol adapter to support the inter-tool protocol on
top of some more general messaging infrastructure, e.g., in a full-up
scalable/distributed data analysis environment.  We would like to
have existing code in this system be able to talk directly to apps
that support the tool protocol (Aladin, topcat, etc.).  This will
require that the semantic content of the messages be independent of
the wire protocol used to express the messages.  This is a desirable
feature in any case.

 	- Doug