[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] some of our concerns with the eventing proposal
>From: Estefan, Jeff A (3100) [mailto:jeffrey.a.estefan@jpl.nasa.gov] >Martin, After listening in on today's conversation, it seems one of >the key sticking points is a desire to support the "fire and forget" >pub/sub messaging model in whch an event producer say is (or wishes >to be) completely decoupled from an event consumer(s). While such >models are in ubiquitous use each and every day, I do not believe >that such a communication model implies the event consumer(s) are >completely decoupled from some third party mediator entity, i.e., an >event broker or channel. There has to be some semantic engagement >between the broker/channel and the consumer, at a minimum, an agreed >upon information model for understanding the syntax and semantics of >the event notification messages and the underlying communication >protocol that will be used as part of the interaction. May seem >obvious, but just wanted to get that point across. Unfortunately, we >ran out of time today before I could get on the queue. I agree that the term "contract" spans a lot more ground than IDL does, and even more ground, when mixed in with "semantic". Semantic contracts have even wider modes of specification-- denotational, axiomatic, operational in CS, various models in UML,OWL, Z, FOL, HOL, etc-- than ordinary contracts. So I think the FAQ should not try to make the point that IDLs (including WSDL as a distant relative) are not needed in EP/EDA by using the overly strong premise that there is "no" semantics ever shared. That's too extreme. After all, in your submission, you say that the event (report) can be typed, and typing is at least one way that semantics can be checked on both ends. In fact, there seem to be several places, in the understandable effort to distinguish EP/EDA area from SOA, where extreme statements are made. I think it would be useful to allow, for example, some form of channel passing within the event, even though that could be viewed as (an addressless) callback of sorts. That would make it useful for notifications of auction starts, quote solicitations, and the like so interaction-- even using contact with services! for taking bids-- important as SOA, just as reactive systems are as important as transformational ones. Maybe there still needs to be political activity in SCA to even out the ideological playing field, and SCA taking on events could begin to balance the last 6 years of SOA mania. >A lot of discussion on proposed techniques or "tricks" to add to the >SCA-Assembly spec in order to support the event processing paradigm, >but have yet to hear a solid business case for doing so. IMHO, of >course. Rolling out the heavy "enterprise architecture" argumentative weaponry of "solid business case"! OK, EP is a little different than pub-sub, but take a look at the GS1 GDSN initiative to distribute "master data" (about GTINs and GLNs and the like -- product and company location information) in the grocery, CPG, healthcare, and other supply chains. While it has been slow taking off, it is now a federated community of channels connecting suppliers, distributors, and retailers, including organizations like P&G and Walmart, using subscriptions and publication, with validation/authorization in the middle. (That should suffice for one case, but it probably won't make use of SCA in the near term.)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]