On 19/10/2007, Rob Eamon <[EMAIL PROTECTED]> wrote: > > > > > > > --- In [email protected], "Steve Jones" > <[EMAIL PROTECTED]> wrote: > > > > > > Again this comes down (IMO) to the definition of SOA. If you take a > > business view of SOA then clearly both technical SOA (WS-*) and > > event based models (EDA) are implementation approaches and from a > > business perspective it doesn't really matter. If however you are > > doing message exchange then yes you have a different approach to > > event based (IME). > > Yup. That's why I lead my comment with "one point of view." > > > Unless of course you choose the standard piece for messaging that is > > going around (forget the name at the moment as its late) or of > > course the grand-daddy of them all MQSeries which runs on > > everything and everyone seems to interop with it. > > 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. I have to put my hands up and say that despite finding that IBM hadn't tested Java, AIX and MQSeries on (IIRC) 5.1 there is no doubt that MQSeries was the best price/performance piece of quality software I've ever used. MQSI was one of the worst. > > > If you are using JMS (and I have no idea why you wouldn't) then > > switching providers isn't an issue (IME) sure a bit of config > > changes but the core code and principles remain the same. > > 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. > > -Rob > >
