Applications Messaging Standard

[Doug Tody]

There are getting to be a lot of conversations going here, so I will
try to combine them all in this one.  The key issue being discussed
appears to be whether protocol can be separate from implementation
(my view is basically "of course", and if we don't do this, it isn't
a standard).


On Thu, 8 Feb 2007, Mark Taylor wrote:

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

This is the difference between a standard, and an implementation.
If someone implements the standard inter-tool protocol on top of some
messaging infrastructure, and the implementation is compliant, two
apps will be able to talk to each other using the new "hub".  It is
the responsibility of the implementor to ensure that this works.

If this is not taken as a serious goal of the project, then it is
likely that apps will become dependent upon the detailed semantics of
whatever hub has been implemented, and what you have is a proprietary
implementation, not a standard.


On Thu, 8 Feb 2007, John Taylor wrote:

> On 8 Feb 2007, at 17:19, Doug Tody wrote:
>> At least for the simpler wire protocols, it should be possible to implement
>> the infrastructure with almost any language or technology.
>
> Possible, but not necessarily practical.  I'd be happy to live with not being
> able to write a "Hub" in IDL if that was the sacrifice necessary to include
> easy-to-use protocols in the hub.  My point is that the set of languages in
> which we need to write a Hub is different, and probably smaller than, the set
> of languages we need to support for clients.  It might be useful to know what
> these languages are so that we can decide what wire protocols are of
> interest.  It's even possible we could make some or all of the wire protocols
> optional, but as Mark pointed out, that needs some careful thought.

A good baseline would be C and Java, with the major platforms being Unix/Linux
based systems, Java, and Microsoft.  If it works for those then probably
it can be integrated with almost anything.


On Thu, 8 Feb 2007, Alasdair Allan wrote:

> Doug Tody wrote:
>> 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.
>
> Well sure, but that's not a application messaging standard at that point.

I don't get this.  You are saying one can't have multiple implementations
of the same standard messaging protocol?

> The problem I have with this is that (as a user) if I have two applications
> that claim to implement this protocol they might not be able to talk to one
> another because either they (or an intervening hub if there is one) don't
> speak the same protocol. In practice the entire point is for the user to be
> able to fire up two 3rd party applications and they "just work" without any
> prior knowledge of each other, or the user having to understand the one
> speaks IVOA Applications Messaging Standard via XML-RPC and the other via
> Jabber, and finding and then running a Hub implementation that speaks both.

I agree this is what we want; it is addressed easily by having the
standard specify one or two wire protocols which are mandatory.

 	- Doug