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. Received on 2007-02-08Z11:25:06