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

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

> -----Original Message-----
> From: Jim Marino [mailto:jim.marino@gmail.com]
> Sent: 01 September 2009 14:12
> To: OASIS Assembly
> Subject: Re: [sca-assembly] Pointer to SCA event processing presentation
> 
> Martin,
> 
> I'm sorry you find this discussion frustrating but please try and
> understand the position some of us are in who were not privy to the
> prior eventing work done outside OASIS. I think it is fair to raise
> questions about the current proposal; it is after all just potentially
> one proposal among many that could be considered.
> 
> Also, I feel it is reasonable to start with the premise that we should
> first see if existing concepts can accommodate eventing use cases.
> Given the complexity surfacing in SCA and the concern that has been
> voiced about this, a good argument can be made that we should be very
> cautious about adding new concepts, particularly when the 1.1
> specifications have not been released and user experience/feedback has
> been limited.
> 
> In raising the questions I have, my goals have been to:
> 
> 1. Understand eventing requirements
> 2. See if SCA can meet those requirements
> 3. Provide a solution that does not increase the complexity of SCA and
> is consistent with its current design
> 4. Provide a solution that is modular.
> 
> I hope the first three goals came across in my previous emails. The
> fourth goal was not explicitly stated. Basically, I would like to have
> eventing decoupled (no pun intended) from the core assembly
> specification so that runtimes can choose to implement it or not. This
> is not only good design practice but also serves a practical purpose
> in gaining at least two conformant SCA implementation sooner rather
> than later.
> 
> The rest of my comments are inline.
> 
> Jim
> 
> 
> On Sep 1, 2009, at 2:22 PM, Martin Chapman wrote:
> 
> >> 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.
> 
> I haven't seen any proposal that says nothing needs to be done. The
> disagreement is over whether new concepts are required or existing
> ones suffice.
[<MartinC>] This is a contradiction. The current concepts are not adequate, and even you have bee proposing tweaks to them.
> 
> > The current model requires references and services to be wired,
> 
> This is not accurate. It requires them to be configured with a
> binding. That is different.
[<MartinC>] Im sorry, the current model requires a wire or a target to be specified, independent of what binding is used.
> 
> > requires the
> > interfaces on each end to match (or at least a subset to match),
> 
> This is also not accurate. My proposal requires the *data* to match
> (i.e. be the same type or a substitutable type), not the interfaces.

[<MartinC>] Im getting confused dipping in and out of the current 1.1. model and your on the fly proposal. Im trying to stay at the
current model and understand its deficiencies.
 
> believe this is required of all approaches. I'll also note at the risk
> of belaboring the point that this is how the JMS binding behaves. For
> example, I can configure a reference with the JMS binding pointing to
> a destination A and configure a service using the JMS binding that is
> associated with the same destination. The reference and service can
> have different interfaces as long as the data matches.

[<MartinC>] Not with the current 1.1 definitions and JMS binding you can't
> 
> > 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.
> 
> My proposal doesn't invent anything new here. This is exactly how a
> reference behaves when bound to a service provider that is hosted
> outside the domain. 
[<MartinC>] Yes but we are within a domain not outside it...

[<MartinC>] >In this context, interface matching is not done as
> with a wire. Also, autowire has nothing to do with this use case as
> autowire is only used for wiring references to services (by the
> definition of wiring, in the same domain), which is not being done here.
> 
> 
> > I don't think we need code snippets to explore these differences, as
> > we have to be
> > able to conceptualise at the SCDL level.
> >
> 
> I'm sorry you disagree and would urge you to reconsider. I find
> walking through concrete examples - code and SCDL - very useful since
> it helps establish a common understanding and vocabulary. In my
> experience it also helps in driving consistency at a conceptual level
> and validates a design.
> 
> 
> > 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.
> >
> 
> I would like to walk through the difficulties using a combination of
> SCDL and code. If you agree, I can post an example of what I was
> thinking.

[<MartinC>] The trouble is you are commenting on our proposal by making your own proposal, which is fine, but unless you write up a
proposal in full it really is hard to follow this discussion, scl and or code snippets aside. That's really my main point here.

> 
> Jim
> 
> > 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
> >
> >
> 
> 
> ---------------------------------------------------------------------
> 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