Applications Messaging Standard

[John Taylor]

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
>