[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]