RE: [sca-assembly] Pointer to SCA event processing presentation

["Martin Chapman" <martin.chapman@oracle.com>]

> So far it seems to me that this can be handled by services,
> references, and bindings. I may be wrong in the end, but it seems
> worthwhile to start from that premise given the additional complexity
> the eventing proposal introduces.

What I find frustrating in this discussion is the premise that we don't need to do anything, followed by some hacking of how to make
it work. We either need to do something or we don't. The current model requires references and services to be wired,  requires the
interfaces on each end to match (or at least a subset to match), and then relies on a binding to support the 1-to-1 interaction. If
you take the need for a wire out of the equation and push interaction semantics (1-m,m-1, m-n) down into a binding, you have IMHO
invented a different type of wire, for which the current semantics (such as interface matching) are no longer necessary - and for
which autowiring may become very problematic. I don't think we need code snippets to explore these differences, as we have to be
able to conceptualise at the SCDL level.

One of the use cases we have within Oracle is in the presentation, that of a new employee.
Rather than build an HR business process that hard wires (pun intended) the processes required throughout Oracle,
the HR system send out a new employee event. This is then captured by whoever is listening (payroll, IT, directory updates,
security), of course the HR system doesn't know beforehand who and how many other recipients there are. In addition each listener
may also be listening for other events from other producers in the system, and typically there is an additional listener who
captures all events into a log. This type of scenario is hard to model with SCDL as it stands, even though we tried. 

Martin.

> -----Original Message-----
> From: Jim Marino [mailto:jim.marino@gmail.com]
> Sent: 01 September 2009 11:02
> To: OASIS Assembly
> Subject: Re: [sca-assembly] Pointer to SCA event processing presentation
> 
> 
> On Sep 1, 2009, at 9:15 AM, Anish Karmarkar wrote:
> 
> > Jim Marino wrote:
> >> Hi Anish,
> >> I have a very naive question about the eventing proposal: is there
> >> a capability that cannot be implemented using JMS? My impression is
> >> the JMS API has everything that is needed to be the foundation of
> >> an eventing system.
> >
> > JMS doesn't provide what is needed for an assembly model. JMS, as
> > you know, is a *Java* *API*. It doesn't say how to do things in,
> > say, BPEL. It doesn't say how to create a composite application that
> > contains components that want to subscribe or publish events of
> > certain types. It doesn't allow multiple components that contain
> > publish/subscribe/topic functionality to be connected/wired/
> > configured and deployed/managed as a  single entity.
> >
> 
> I should have been clearer. My question wasn't about using the JMS API
> directly. Rather, it was about using it (and a JMS provider) to build
> eventing functionality as a binding.
> 
> > If I were to stretch the comparison a bit: even though we have JAX-
> > WS, which can be used to implement and invoke services, we still
> > need SCA ;-)
> 
> That was my point :-)
> 
> >
> > What the contribution addresses is an assembly-level model for pub-
> > sub. It provides the additional concepts/constructs needed to
> > declare subscribers (or consumers), publishers (or producers),
> > topics (channels) that can coexist with existing service-reference-
> > wiring model and takes advantage of the intent/policy framework.
> >
> 
> So far it seems to me that this can be handled by services,
> references, and bindings. I may be wrong in the end, but it seems
> worthwhile to start from that premise given the additional complexity
> the eventing proposal introduces.
> 
> Jim
> 
> 
> > Hope that makes sense.
> >
> > -Anish
> > --
> >
> >> As an aside, I'm not asking this as a way of implying that JMS
> >> should be used and/or required.
> >> Jim
> >> On Aug 26, 2009, at 6:57 PM, Anish Karmarkar wrote:
> >>> Hi Sanjay,
> >>>
> >>> Here is the link to the presentation:
> >>> http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/32653/SCA-
> EventingProcessing.pdf
> >>>
> >>> It does talk about the motivation and has use cases.
> >>>
> >>> HTH
> >>>
> >>> -Anish
> >>> --
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >> ---------------------------------------------------------------------
> >> 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
> 
> 
> ---------------------------------------------------------------------
> 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