Applications Messaging Standard

[Doug Tody]

Hi Mark -

I think we are actually saying the same thing.  If we define a
standard inter-tool messaging protocol and implement it on top of,
e.g., D-Bus, you client does not talk directly to D-Bus, it talks to
an implmentation of the defined messaging standard which just happens
to use D-Bus, MPI, Ice, or whatever internally.  It is not a compliant
implementation unless a standard interface is presented which isolates
the client from the underlying messaging infrastructure used.

 	- Doug


On Fri, 9 Feb 2007, Mark Taylor wrote:

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