Applications Messaging Standard

[Tony Linde]

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? 

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

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

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

This is where you lose me. Is xml-rpc a 'wire protocol'? And doesn't the
protocol chosen enforce constraints on the messaging interface? And the
discussion about the file-based protocol is only wrt how to find the running
hub, not how to pass messages.

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.

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