[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] Pointer to SCA event processing presentation
Sorry I forgot to add the following general comment.
By the looks of it you agreeing that we need to add to the model to support evening
(adding channels to references, a new binding.eventing etc).
What I think we should do is focus on the concepts we need to add rather than just tweak the current syntax, and come back to the
syntax issue after.
Martin.
> -----Original Message-----
> From: Martin Chapman [mailto:martin.chapman@oracle.com]
> Sent: 28 August 2009 17:13
> To: 'Jim Marino'
> Cc: 'OASIS Assembly'
> Subject: RE: [sca-assembly] Pointer to SCA event processing presentation
>
> Jim, didn't mean to imply not to carry on the email discussion, so here are some responses.
>
> Martin.
>
> > -----Original Message-----
> > From: Jim Marino [mailto:jim.marino@gmail.com]
> > Sent: 27 August 2009 21:28
> > To: Martin Chapman
> > Cc: 'OASIS Assembly'
> > Subject: Re: [sca-assembly] Pointer to SCA event processing presentation
> >
> > Hi Martin,
> >
> > I will try my best to attend in September. I have been tied up with
> > other commitments over the summer that overlap with the SCA calls. In
> > the meantime, it may be beneficial if we can continue some of the
> > discussion through email as a way to make forward progress.
> >
> > Thanks,
> > Jim
> >
> > On Aug 27, 2009, at 5:45 PM, Martin Chapman wrote:
> >
> > > 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.
>
> [<MartinC>] Since I think a reference can only be either a normal (sca 1.1) reference or a reference
> to an eventing channel (but not
> both) does it real make sense to overload the semantics. I agree there is a lot of syntactic
> similarities, but since the semantics
> are very different between the two modes of interactions is it wise to use the same syntax. Also, I
> think references/publisher is
> the easy side of the equation, the service is more complex imho. For bindings we need to be able to
> also indicate the underlying
> technology binding, so that we can configure binding.eventing.jms or binding.eventing.mq, this is a
> change to the current binding
> model.
>
> > >>
> > >> 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.
>
> [<MartinC>] The issue here is whether the recipient barfs if it gets something it didn't quite expect.
> In RMI, if you don't get your parameters matching you get a system failure - this is strong typing.
> In JMS you have to unpack and decipher the onMessage contents, and its up to you if you barf or not.
> Its more loosely typed as you
> can tolerate different data.
>
> > >>
> > >> 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?
>
> [<MartinC>] At one level, send(msg) receive(msg) everything is the same, but as you go up into the
> application level code there are
> two modes of thinking: send this message to whoever verses interact with a service provide to do
> something, the later has a service
> contract at the destination.
>
> >>>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.
> [
> [<MartinC>] The point is that there is no semantic contract between a producer and a consumer, but
> there is between client invoking
> a service. That's what we mean by implied processing here - semantic contract.
>
> > 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.
>
> [<MartinC>] Your proposal does address this but see comment above about syntax vs semantics.
> > >>
> > >> 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.
>
> [<MartinC>] Again this is a syntax vs semantics issue. Filters only apply to eventing (I hope at
> least) so lets separate out
> concerns.
> > >>
> > >> 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.
> [<MartinC>] Ok there are restrictions if you use a reference for eventing. By the time you have
> enumerated all the restrictions and
> additions it gets very confusing.
>
> > >> 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?
> [<MartinC>] Yes, another issue is that application programmers want to send one event, not go through
> sending it to multiple
> places.
>
> > >>
> > >> 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
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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]