--- In [email protected], "Steve Jones" <[EMAIL PROTECTED]> wrote: > > On 19/10/2007, Rob Eamon <[EMAIL PROTECTED]> wrote: > > > > Yeah, by MQ I meant WebSphere MQ (the successor to MQSeries). > > Successor? Naah, just a rebrand (5.2 was called MQSeries then > because WebSphere MQ) like the MQSI - WebSphere Message Broker - > WebSphere Advanced ESB.
We're going to debate the meaning of successor now? :-) > > Interesting. Not an "issue" per se, but was your experience > > without incident in terms of anything provided by the underlying > > provider that didn't work the same with the new provider? > > Pretty much so yes, unless you count the actual product not working > properly (JBossMQ from 2001 IIRC). Clearly there are config > differences in both the product and the JNDI but once we'd split all > of those up the core code was the same. It was of course a bit of a > pig to get all of the config things done. > > > > > SQL, of course, is supposed to provide DB independence if you're > > careful. I view JMS similarly. Has your experience shown > > otherwise? I know it's off-topic for this forum but I'd be > > interested in hearing any issues/non-issues you've encountered. > > I'd say its similar, but with the added advantage that JMS just does > the principles and leaves the practice down to config. SQL mixes > the two and doesn't provide a decent set of separation. So I'd > view JMS more like a Hibernate than a SQL as it gives you a > consistent coding model and then enables you to create platform > specific configs and optimisations. > > Actually that is on-top really for SOA as its about the separation > of the business logic from the platform implementation. Thanks for sharing the info! -Rob
