[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [xmlblaster] xmlBlaster in the real world
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
> 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