RE: [xmlblaster] xmlBlaster in the real world

["Madere, Colin" <colin.madere at ieminc.com>]

After reading about I've pretty much come to a conclusion closely matching
your input below.  I didn't mean to stir up "JMS garbage", hadn't realized
the specifics I now do.

I'm gunning for xmlBlaster and if we have to tack on a client-side JMS
library to make people happy I won't cry about it :)

I commend the quality work you folks have done and from the little
prototypes I've set up with xmlBlaster the design looks excellent.  With
some re-assurance from others on the list about production systems relying
on xmlBlaster, things look even better.  Keep kicking tail!

> -----Original Message-----
> From:	Marcel Ruff [SMTP:mr at marcelruff.info]
> Sent:	Thursday, April 10, 2003 2:16 PM
> To:	xmlblaster at server.xmlblaster.org
> Subject:	Re: [xmlblaster] xmlBlaster in the real world
> 
> 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
>