Applications Messaging Standard

[Doug Tody]

On Sat, 17 Feb 2007, Tony Linde wrote:

> Hi Doug,
>
> I don't know about others but I'm not sure of the terms you're using. It'd
> be useful if you could add an eg to the terms to help muggles like me follow
> you. Eg, is xml-rpc a wire protocol or interface or what?

XML-RPC, JSON, etc. are wire protocols.  You can transmit the same
information with either.

>> define is merely an "interface" (e.g., in the sense of a modern
>
> I'm pretty sure I understand this bit: you mean the methods and parameters
> used to define how a client gets the hub to do stuff?

Yes, plus the semantics of these methods.  Such an interface can be
defined as an abstract interface, and you need an implementation before
some client can use the interface.

>> operations with well-defined semantics.  An "implementation" like
>
> But the implementation has to present the interface in a way anyone can get
> at. It is not much good having the interface implemented as java methods
> which cannot be called by .net apps.

You get at the implementation via the protocol.  That is what makes
it language independent.  You can go one step futher and bind the
protocol into a specific language, and then you have an RPC, RMI,
CORBA/SOAP, etc. type of facility.

>> least one wire
>> protocol to be used to talk to the implementation of the standard
>> messaging interface.  If for example this protocol is socket-based,
>> we need to specify in socket terms what the protocol is (e.g., as in
>> Pat's example).  If the protocol is partly file-based, then we need
>> to specify that instead.  This protocol is largely a separate matter
>> from the formal messaging interface, which could be implemented over
>> multiple wire protocols.
>
> This is where you lose me. Is xml-rpc a 'wire protocol'? And doesn't the
> protocol chosen enforce constraints on the messaging interface?

As you say, xml-rpc (for example) is a wire protocol, and the choice
of a protocol can limit what you can do with messaging.  That is why,
if you want to make your messaging multi-protocol (similar to trying
to make code "portable"), you have to look at several transports and
design it carefully.

> And the
> discussion about the file-based protocol is only wrt how to find the running
> hub, not how to pass messages.

The protocol is concrete and has to specify how you actually do things
like make a connection.  If multiple implementations need to use a file
to bootstrap a connection, then it is part of the connection protocol.
As you say, this detail would not affect the actual messaging passing,
but it would still be part of the connection protocol.

> I think the problem I have is with conflating three separate activities into
> one. We're talking about: a) finding an installed hub, getting it running
> and keeping it running; b) discovery by new client apps of the running hub
> and how to talk to it; c) the types of messages to be sent to the hub and
> their content. These are three separate problems that we need to solve
> (although one solution may cover two or more problems) and it'd certainly
> help me if people could specify which problem they're addressing in their
> discussions.
>
> T.

Right - I think the discussions have tended to mix all these together
(although lately we have only been talking about connections).  Ultimately,
to define a standard they will need to be differentiated, so we know what
the standard defines and what is up to the implementation.

 	- Doug


>> -----Original Message-----
>> From: owner-apps at eso.org [mailto:owner-apps at eso.org] On
>> Behalf Of Doug Tody
>> Sent: 17 February 2007 00:16
>> To: apps at ivoa.net
>> Subject: Re: Applications Messaging Standard
>>
>> Regarding this issue of the "hub", or "message bus", etc. - these are
>> all just examples of some form of messaging infrastructure.
>> Words like
>> "hub" or "bus" merely imply a certain type of connection topology
>> that the messaging infrastructure implements.  They make it easier to
>> talk about these things in concrete terms, but the terms are imprecise
>> and possibly misleading so we need to be a bit careful using them.
>>
>> If we try to think about this a bit more formally, what we need to
>> define is merely an "interface" (e.g., in the sense of a modern
>> language such as Java etc.) which provides certain well-defined
>> operations with well-defined semantics.  An "implementation" like
>> the PLASTIC hub merely implements this interface.  So long as some
>> software implements the interface in a compliant fashion, it doesn't
>> matter how it is implemented.  A given implementation may well support
>> additional, completely different interfaces simultaneously, or the
>> semantics may be a superset of what the standard defines.
>>
>> In addition to a standard interface we need to define at
>> least one wire
>> protocol to be used to talk to the an implementation of the standard
>> messaging interface.  If for example this protocol is socket-based,
>> we need to specify in socket terms what the protocol is (e.g., as in
>> Pat's example).  If the protocol is partly file-based, then we need
>> to specify that instead.  This protocol is largely a separate matter
>> from the formal messaging interface, which could be implemented over
>> multiple wire protocols.
>>
>> The messaging interface will probably only provide some mechanism
>> for expressing a message, and transmitting or receiving a message.
>> The message _content_ used to talk to specific applications is then
>> another aspect of the standard.  For the most part, the message
>> content is probably independent of the specific messaging interface,
>> although certain concepts such as message classes and so forth will
>> probably need to be common.
>>
>> Finally, when it comes time to use this in a client application,
>> ultimately there is probably going to be some sort of API which
>> client programs actually use.  If all we do is specify things to
>> the level of the wire protocol, the applications programmer is still
>> likely to write their own API on top of, e.g., XML/RPC or whatever.
>> One certainly wants to standardize the protocol so that this sort of
>> thing is possible.  However, real-world users - for example writing
>> Python apps (or IDL, IRAF, etc.) - will generally not very much mind
>> if someone hands them a ready made module which implements
>> the protocol
>> and provides a nice easy to use API.
>>
>> I think these are all important elements of the inter-tool messaging
>> facility we are talking about.  They all need to be carefully defined,
>> and should not be all muddled together.
>>
>>  	- Doug
>>
>
> http://www.Taglocity.com Tags: IVOA, apps
>