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