Rob wrote: "service-oriented designs don't address events because being event-driven is completely different from being service-oriented". I think that these two just complement each other.
Otherwise, we would have troubles designing mediation services, for example. Event may be a reason for a service invocation. As well as a service may cause an event. SOA "does not encompass EDA" because SOA is not EA; there is no need to encompass EDA until it is available on its own. - Michael 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. 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. 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. -Rob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
