Applications Messaging Standard

[Tony Linde]

I must say the tech language is starting to get beyond my puir little brain,
but

> My feeling is that we should ease the job of the client programmer  
> where we can by providing several wire protocols even though this  
> complicates life for the "Hub" author.

If this means making it just easy for a .Net programmer to adopt plastic in
his client-side app as a Java programmer, then I'm all for it.

T.

> -----Original Message-----
> From: owner-apps at eso.org [mailto:owner-apps at eso.org] On 
> Behalf Of John Taylor
> Sent: 08 February 2007 16:11
> To: Doug Tody
> Cc: apps at ivoa.net
> Subject: Re: Applications Messaging Standard
> 
> 
> On 8 Feb 2007, at 15:12, Doug Tody wrote:
> 
> > On Thu, 8 Feb 2007, Alasdair Allan wrote:
> >>> Is PLASTIC a messaging protocol or a messaging infrastructure?
> >>
> >> Both, PLASTIC applications pass a message either using 
> Java-RMI or  
> >> XML-RPC to the PLASTIC Hub which passes the message out to  
> >> applications that have registered that they deal with that 
> message  
> >> either using Java-RMI or XML-RPC depending on which the  
> >> application supports. [...]
> >>
> >>> That is, if I already have a robust messaging 
> infrastructure, can  
> >>> I layer a PLASTIC adapter on top of this and achieve the same  
> >>> level of interoperability between applications as with 
> the simple  
> >>> PLASTIC hub? PLASTIC apps would still "speak" PLASTIC, but the  
> >>> messaging infrastructure could be anything.
> >>
> >> Sort of...
> >
> > In any case, the real issue here is not what the current PLASTIC  
> > implementation does, but what we want for an inter-tool messaging
> > standard developed via the IVOA framework.
> 
> I think it is relevant to discuss what the current PLASTIC  
> implementation does.  If we can discover the reasons why PLASTIC  
> isn't suitable, then it will help us decide what we _do_ want from a  
> framework.
> 
> http://www.ivoa.net/twiki/bin/view/IVOA/ 
> ApplicationsMessagingInitialQuestionsFifteen
> 
> >
> > I suggest that this should:
> >
> >     o	Target simple inter-tool messaging (don't try 
> to be a full
> >     	messaging infrastructure; that is a separate problem).
> >
> 
> I agree - this should be our first priority.  Discussion of the more  
> complex cases can then take place on a background thread 
> while we get  
> the inter-tool messaging working.
> So what should be our target for May? http://www.ivoa.net/twiki/bin/ 
> view/IVOA/ApplicationsMessagingInitialQuestionsSeventeen
> 
> 
> >     o	Separate protocol from implementation.  That 
> is, we should be
> >     	able to implement a message bus/hub in 
> different languages such
> > 	as Java or C, or layer the protocol on top of an existing robust
> > 	messaging infrastructure such as D-Bus, MPI, PVM, ActiveMQ,
> > 	Ice, CORBA, etc.  It is fine to have a simple hub (or two)
> > 	developed as part of the standard, which doesn't queue messages,
> > 	guarantee delivery, and so forth.
> 
> I agree that this is desirable.  There might be a trade off here  
> between the wire protocols we can offer in a Hub, and the languages  
> it is possible to use to write one.  We probably don't need to worry  
> about as many languages as we do for client applications messaging  
> though.
> 
> 
> >
> >     o	Separate protocol from message content.  The 
> message content can
> >     	be defined/standardized separately.  It should 
> be possible to
> > 	easily extend the protocol by adding new message content.
> >
> 
> I didn't even pose a question on this, since it seems like a no- 
> brainer.  It's what we've been doing along with PLASTIC anyway.
> 
> 
> >     o	Be multi-language and not tied to any one 
> messaging technology
> >     	(such as Java RMI).
> 
> Again, in my view there's no question that we should be multi- 
> language.  But, the range of languages and platforms we want to  
> support could influence  technology choices, so....which ones do you  
> think we must support?
>    http://www.ivoa.net/twiki/bin/view/IVOA/ 
> ApplicationsMessagingInitialQuestionsSeventeen
> 
> 
> >
> >     o	Be multi-protocol, with the same message 
> content expressable
> > 	in at least two different wire protocols (XML/RPC, JSON,
> > 	OpenWIRE, STOMP, etc.).
> 
> I think this is still an open question - there's arguments for and  
> against.
> http://www.ivoa.net/twiki/bin/view/IVOA/ 
> ApplicationsMessagingInitialQuestionsFifteen
> 
> My feeling is that we should ease the job of the client programmer  
> where we can by providing several wire protocols even though this  
> complicates life for the "Hub" author.
> 
> 
> 
> 
> >
> > A concern is that, if in the future we try to use this inter-tool
> > messaging standard in distributed data analysis system which already
> > has a robust general messaging infrastructure, it should be possible
> > to layer the inter-tool protocol on top of this infrastructure,
> > without having to support two similar but different implementations.
> >
> > 	- Doug
> >
> 
>