Applications Messaging Standard

[Mark Taylor]

On Thu, 8 Feb 2007, Doug Tody wrote:

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

I either don't understand this statement, or I don't agree with it.
The difference between a standard and an implementation is what 
code is used.  Apache and Microsoft IIS for instance are different 
implementations but they implement the same standard, which is HTTP.
The essential point is that a client program doesn't need to know which 
one it is talking to, and that is (I believe) the feature we need 
to have in an inter-application messaging standard.

I am quite happy for messages to spend part of their journey between
components using whatever transport mechanism seems best to implementors,
but it seems to me that the part that the client talks to must
have a fixed behaviour, otherwise there will be situations where
two IVOA-messaging-standard-compliant applications are unable
to communicate with each other.  The discussion of endorsing a variety 
of different message infrastructures makes it sound like this will
not be the case, since the steps that a client performs to 
connect to a D-Bus daemon (for instance) are quite different
from the steps it takes to send XML-RPC messages.

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

So what we need to agree on is the protocol (or possibly a range of
protocols, though I'm not convince that more is better) which clients 
use to talk to the "hub", and not mandate anything which happens
within such a "hub", where the "hub" is some kind of layer which 
shields the application from the underlying messaging infrastucture.
That sounds like perfect sense to me.  Is it what you're saying, 
or are you saying something else?

I'm sorry if some of these comments sound laboured or stating the
obvious, but I can't tell if people are talking at cross-purposes
here or if there is a genuine disagreement.

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/