[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] Pointer to SCA event processing presentation
Jim, On yesterdays call we agreed to have bi-weekly sessions, starting 9th Sep, focussing on eventing. We need to collect comments, and address them as appropriate. You contribution below is valuable to this effort and I would encourage you to participate in these calls. Martin > -----Original Message----- > From: Jim Marino [mailto:jim.marino@gmail.com] > Sent: 27 August 2009 15:36 > To: Martin Chapman > Cc: 'OASIS Assembly' > Subject: Re: [sca-assembly] Pointer to SCA event processing presentation > > OK. Not having been privy to the initial drafting of the specification > outside of OASIS (i.e. in OSOA), I may raise some questions that have > already been answered. But for those who are new to this such as > myself, I'll ask them anyway. > > My first reaction - and this is based on incomplete knowledge - is > that eventing seems to be dragging in a boat-load of additional > concepts and technologies. For example, as you mention below, there is > the possibility that an interoperable eventing protocol may be required. > > There are also: consumers, producers, events, event types, EDL, > channels, filters, and channel promotion. Many of those concepts > appear to simply mirror concepts we already have. For example: > > consumers ----> services > producers ----> references > events ----> messages > EDL ----> a type system such as XML Schema or Java > channels ----> binding metadata > filters ----> binding metadata > channel promotion ----> service/reference promotion > > The reason why I asked if JMS could be used to implement eventing is > that I wanted to see if this apparent duplication of concepts could be > eliminated by accommodating eventing capabilities using existing > concepts, in particular bindings. Since JMS appears to capture the > semantics of eventing, this leads me to believe an "eventing" binding > and a set of intents could be defined to achieve this. > > I noticed the deck contained a slide outlining why these additional > concepts are needed. Before responding to that, I'll outline what I > was thinking first. > > To start, I was thinking there would be an eventing binding which > could be configured in the following way: > > <component name="MyProducer"> > <implementation.java ..../> > <reference name="channel1"> > <binding.eventing channel="foo"/> > </reference> > <reference name="channel1"> > <binding.eventing channel="bar"/> > </reference> > </component> > > <component name="MyFooConsumer"> > <implementation.java ..../> > <service> > <binding.eventing channel="foo" filter=".."/> > </service> > </component> > > <component name="MyBarConsumer"> > <implementation.java ..../> > <service> > <binding.eventing channel="bar" filter=".."/> > </service> > </component> > > > public class MyProducerImpl implements SomeService { > > @Reference > protected MyChannel channel1; > > @Reference > protected MyChannel channel2; > > public void doSomething(...) { > Event event1 == //... > Event event2 == //... > channel1.onEvent(event1); > } > > } > > public interface MyChannel { > > @OneWay > void onEvent(Event event) ; > } > > > Based on this example, I've included some comments with respect to the > slide from the deck mentioned above: > > 1. No decoupling > > I think the above example is fairly decoupled. It requires a reference > to be bound (but not wired), which I think is the correct behavior > given that allowing 0..n would require code to check for null pointers > making it complex. If there was no consumer, the binding would swallow/ > ignore the event. > > 2. Requires interfaces for typing > > I'm not sure I follow this. My understanding is that for strongly > typed languages such as Java, some interface is required. If an > interface is not required, how is an event sent in Java? Even other > language, some shared type system or type mapping is required. > > 3. Interface/operations have processing semantics, events don't > > I'm not sure I agree with the assumption that interfaces have > processing semantics. How does MyChannel.onEvent() imply processing > semantics? One thing that would help is if someone could provide a > Java code example that did not imply processing semantics so a > comparison can be mode. Note that the MyChannel example was strongly > typed, but the following could also be defined: > > public interface MyUntypedChannel { > > void event(Object event); > } > > 4. Doesn't allow addition of producers/consumers dynamically > > I think the proposal above addresses this concern. It would be up to > the binding infrastructure to handle this. Note that I think there may > be an incorrect assumption related to references/wires as well. Wires > can be updated dynamically. > > 5. No ability to set filters > > This would be handled in the binding configuration. In the example, I > used an attribute but it could also be modeled as an element for > complex expressions. I'm hoping the filter language will be left open > as opposed to inventing one. > > 6. Various issues crop up because of the model mismatch. For example, > sca:reference(0..n) is mapped to an array in Java > > This would be addressed by using a bound required (1..1) reference. > Also, note that 0..n does not have to map to an array in Java, it can > also map to certain collection types. Are there other issues along > these lines? > > 7. Subscribers do not offer services they offer callbacks > 8. Services do not subscribe they make software functionality > available for others to use. > > I think these two are debatable. For example, the JMS binding works > this way. Why can't we use the same principle and keep things > consistent with JMS? > > 9. A subscribe message will be sent from a service to a reference: a > direction reversal > > I think this is conflating services/references and runtime > infrastructure. The latter is setting up subscriptions, not a service > or reference. This is consistent with how the JMS binding is designed. > > 10. Changes are hard to manage > > Could you provide examples? > > > ------------------------------- > > What would help me is if someone can provide examples of how eventing > works in a concrete programming language. My own preference is Java, > but C++, BPEL, etc,. would be fine. > > Thanks for reading this far :-) > > Jim > > On Aug 27, 2009, at 3:24 PM, Martin Chapman wrote: > > > We have not addressed that question yet. The current Assembly spec > > does state in the conformance section that a web services binding > > is required, and there is a PR comment on that. Depending on how we > > resolve that comment, we may have to add an analogous > > interoperable protocol for eventing (or not as the case may be.) > > > > Martin. > > > > > >> -----Original Message----- > >> From: Jim Marino [mailto:jim.marino@gmail.com] > >> Sent: 27 August 2009 14:14 > >> To: Martin Chapman > >> Cc: 'OASIS Assembly' > >> Subject: Re: [sca-assembly] Pointer to SCA event processing > >> presentation > >> > >> OK I'm currently just interested in the API. From your response, it > >> sounds as if the JMS API can be used to capture the semantics of the > >> eventing proposal. > >> > >> Given that, your response does raise an additional question. Is the > >> proposal mandating an interoperable wire protocol such as WS-Eventing > >> or AMQP be used? In other words, would it be considered compliant to > >> build eventing capabilities using a JMS provider that did not support > >> an interoperable wire protocol? I'm hoping your answer is "yes" :-) > >> > >> Thanks, > >> Jim > >> > >> > >> > >> On Aug 27, 2009, at 2:48 PM, Martin Chapman wrote: > >> > >>> Everything but a standard wire protocol;-) > >>> > >>>> -----Original Message----- > >>>> From: Jim Marino [mailto:jim.marino@gmail.com] > >>>> Sent: 27 August 2009 00:06 > >>>> To: OASIS Assembly > >>>> Subject: Re: [sca-assembly] Pointer to SCA event processing > >>>> presentation > >>>> > >>>> 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. > >>>> > >>>> 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 > > > > > --------------------------------------------------------------------- > 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]