[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. > 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. > 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. I 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. > 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. 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. 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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]