Just want to ask a question. Are we talking just about "technical event" or both technical and "business (economic) event"?
That aside, IMHO, after partners negotiate a contract, a commitment between the partners is created. The commitment may be fulfilled by creating an event between partners, that may invoke a service. We can put this concept into supply chain using trading partners. :> H.Ozawa --- In [email protected], Michael Poulin <[EMAIL PROTECTED]> wrote: > > 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 > <angoro@> 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 >
