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