On 18/10/2007, Rob Eamon <[EMAIL PROTECTED]> wrote: > > > > > > > --- In [email protected], andresgr > <[EMAIL PROTECTED]> wrote: > > > > Hi everyone! First post on the group :) > > > > I've been researching the "publish-subscribe" options available in > > a SOA today. What i'm searching for is a events "publish-subscribe" > > model both standard (where standar means both java and .net more or > > less) powerful and mature. > > > > My impression is that today that does not exist. The options: > > > > 1) JMS: not interoperable at the wire level and standar only in > > java. > > 2) WS-Eventing - WS-Notification: competing, overlapping and > > inmature standards. > > 3) Atom/Rss: very simple, but not powerful. > > > > Clearly SOA is somehow "mature" on the *services* aspect but no in > > the *events* aspect. > > One point of view is that service-oriented designs don't address > events because being event-driven is completely different from being > service-oriented. An architecture can (and should) include both > notions, but "SOA" does not encompass EDA. The folks at ZapThink feel > that all interactions between services are "events" but that seems to > be a stretch IMO.
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). > > One possibility for the technical delivery aspect of EDA is to simply > pick one of the leading messaging/ESB solutions. Every one of them > has pros and cons and selecting one (or more) is likely to provide > the functions you'll need. MQ. AQ. MSMQ. Sonic. Fiorano. webMethods. > TIBCO. (I'm violating my own peeve by listing companies instead of > products, but you get the idea.) > > Alas, I'm not sure any of the products today will give you the > universal standard you may be seeking and you'll may end up with > messaging bridges regardless of which product suite you go with. 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. > Changing messaging providers later is theoretically possible (if you > avoid proprietary APIs and product-specific features) but in practice > it is similar to changing databases--doable but you won't like doing > it. 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. > > -Rob > >
