[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] Pointer to SCA event processing presentation
Actually, my initial impression is we *don't* need to add anything to
the model and that we should start with the premise that eventing can
be accommodated through existing concepts, without the need for any
"tweaks". This assumption may turn out to be wrong but I think it is
better to start from that position than introducing new concepts at
the outset.
What I was proposing was to follow the approach we have taken with
bindings, in particular JMS. In this scheme, a channel would be
similar to a JMS destination, i.e. a concept specific to the binding,
not a new assembly concept. This will provide consistency across SCA,
which generally makes things simpler for end-users.
I also believe we should accompany proposals with concrete examples of
what we want to achieve, rather than just concepts. Otherwise, we are
likely to get bogged down in terminology.
I'll provide more specifics in my response to your other message.
Jim
On Aug 28, 2009, at 6:22 PM, Martin Chapman wrote:
> 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
>
>
>
> ---------------------------------------------------------------------
> 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]