OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[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]