Applications Messaging Standard

[Alasdair Allan]

Doug Tody wrote:
> Noel Winstanley wrote:
>> Tony Linde wrote:
>>> Quick(ish) question re PLASTIC: is the plastic hub something like  
>>> a message broker?
>>
>> Its a little like a message broker, but specialized and simplified  
>> to the task of inter-application messaging - so not a general  
>> messaging solution.
>>
>> Unlike a messaging system like MSeries or ActiveMQ, Plastic hub  
>> implementations don't queue messages, and makes no guarantees  
>> about delivery of messages (whilst MSeries guarantee once and once  
>> only for every message), or, I believe, ordering of messages.
>
> Depending upon what one is doing, these semantics can be quite  
> important to the correct functioning of an application.

Sure, but I don't believe simple inter-application messaging at the  
desktop level really needs guaranteed delivery, or quality of service  
guarantees or messages queues , or any of that other complicated stuff.

The secret to building an excellent specification is to get just  
complicated enough to implement the features needed to accomplish the  
task, and then stop. Adding extra features at that point doesn't make  
anyone's life easier except the people writing the specification who  
can't agree which features aren't necessary.

> 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. We have discussed adding further (perhaps optionally  
supported) transport protocols to the standard, and in fact have  
discussed removing Java-RMI as a mandatory protocol (just leaving XML- 
RPC since that's cross-platform and cross-language and relatively  
easy for most developers to target).

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

I sort of do this inside eSTAR. I have a software as services  
architecture, and some PLASTIC messages are propagated between "non- 
customer facing" back end daemons until they reach a piece of  
software that actually speaks PLASTIC (via XML-RPC since I'm a Perl  
guy) at which point they're pushed to the outside world via the  
PLASTIC Hub. In some instance this means the message will them be  
bridged again off that machine via the PLASTIC Gateways I was  
discussing in my initial message.

However if you mean "Can I send a PLASTIC message via random protocol  
X" then at least at the moment the answer is "No" because it's not  
PLASTIC if the message doesn't go via the Hub.

> Messaging is fundamental to all distributed applications (no one is
> saying anything here about transactions, that is a separate matter).
> I think the main distinction is that PLASTIC is intentionally limited
> in scope, being intended only for simple inter-tool messaging.

Totally agree...

> As soon as it grows and you get real distributed applications, as  
> opposed to independent tools sending an occasional "load this" type  
> message, then one is back in the realm of the more complex  
> messaging systems.

I'd tend to agree, internally I use XML via SOAP web services in the  
negotiation layer between my pieces of software. However I've found  
PLASTIC to be just the right level of complexity for my code to talk  
to other people's code.

I'd really hate to loose the simplicity that PLASTIC offers by over- 
burdening it with complex message brokering tasks. I don't view  
either PLASTIC, or the IVOA application messaging standard, as  
needing the features of messaging systems like MSeries or ActiveMQ.

Al.