Re: [xmlblaster] xmlBlaster in the real world

[Marcel Ruff <mr at marcelruff.info>]

Madere, Colin wrote:

> Yes, thanks, I did run through that list when first looking at xmlBlaster
> and ruled almost all of them out since they didn't meet one or another
> criteria for my project or had licensing that conflicted with client
> requirements :)
>
> Only things my group is wary about is lack of JMS compliance (which I
> realize can be sort of tacked on) 
The JMS approach has some aspects to note:

o  JMS is just a client API to code against.

o  Therefor the protocol between client and server is vendor specific

o  Therefor if you have once installed a JMS product in a real distributed
  environment you can't change it easily any more:
Imagine you have installed an air traffic controller software on all 
airports
of your country: If you change the JMS product on one airport suddenly
all other airports can't communicate/share their informations (for
example the 'runway is closed due to accident' message).
Upgrading all airports at the same time is practically impossible
as it is an 24 hours operation for transcontinental flights.

o  This is the reason that xmlBlaster has a generic server API,
you could change the server behind the API or code other clients
in any programming language on desire.

o If you once have chosen a JMS vendor you quickly use
vendor specific extension (e.g. for clustering), in reality changing the
JMS vendor is not possible this easy anymore.

o XmlBlaster has many plugin possibilities to extend it
in any way. We code what we think is best and what we
learn about MoM each day, we don't need to take care
on the JMS prison.

o It shouldn't be too complicated to hide xmlBlaster behind a JMS API,
but note that two things are currently missing: transaction support and 
SQL'ish query
(as we use XPath or plugins like REGEX, XPath, etc to further filter).
But i can't see the point of a JMS API (probably psychological/marketing 
reasons only).
If somebody adds it, why not?

These are just some reasons why xmlBlaster is existing
and why we have choosen not to implement another JMS server,

best regards

Marcel