RE: [sca-assembly] some of our concerns with the eventing proposal

[Mike Edwards <mike_edwards@uk.ibm.com>]

Jeff,

I think that the business case for adding
Event Processing to SCA is that we have customers building systems that
do combine event processing
and service processing.  Currently
that means a change in paradigm for the programmers and application assemblers:
 - eg. introducing "messy"
middleware APIs into what would otherwise be "clean" SCA service
components. 
-  eg. Having a good model for
the Assembly of service components but no model at all for the assembly
and organization of components linked via event communications.

From my point of view, it is more a
question of why you *wouldn't* want to model event interactions as well
as service interactions.

Now, as to what needs to be done to
the SCA specifications to deal with event processing, that is a different
question....


Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

From:	"Estefan, Jeff A (3100)" <jeffrey.a.estefan@jpl.nasa.gov>
To:	"'OASIS Assembly'" <sca-assembly@lists.oasis-open.org>
Date:	09/09/2009 18:50
Subject:	RE: [sca-assembly] some of our concerns with the eventing proposal

---

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 which 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.

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.

Regards...

 - Jeff E.

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU