Applications Messaging Standard

[Alasdair Allan]

Noel Winstanley wrote:
> Plastic has a lot less support for security, transactions, and  
> other things that typically concern enterprise software. If a  
> plastic message is dropped, or even spoofed or intercepted, it's  
> assumed that this isn't the end of the world.

I think this is a good assumption, we shouldn't over-engineer our  
solution. Things like quality of service and guaranteed delivery add  
a whole layer of complexity we don't really need for the task at hand.

I also don't think we need support for (much) security, and I don't  
really want to go near logging or transactions, again I don't think  
its needed.

> Similar to a messaging system, a plastic hub doesn't really care  
> about the content of the messages - the definition and format of  
> mesages are left to the message producer and consumer to agree,  
> whilst the hub just takes care of routing them.

However this is vital I think, one thing I really (really) think  
PLASTIC did right was leaving the messages alone. My application can  
get a showObjects message (for instance) and do whatever it likes  
with it. It isn't constrained by the standard to do the expected  
thing. That leads to innovative uses for the messages, you can't  
think of everything when you build a standard...

> Plastic is good for quickly exchanging control info between desktop  
> apps. Message Brokers are good for, eg,  processing banking  
> transactions.

Yup!

Al.