[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] Pointer to SCA event processing presentation
Comments inline.
Jim
On Sep 1, 2009, at 10:01 AM, Anish Karmarkar wrote:
> Jim,
>
> This is a very good discussion.
>
> For some historical context, in OSOA, we started exactly where you
> have:
> using async one-way methods with no exceptions, typing using
> interfaces, mapping subscribers to services and publishers to
> references.
> (there were some variations on this, where channels were modeled as
> "broker" components, subscribers were modeled as references with
> callbacks, autowire was used to avoid explicit wires, etc)
>
I'm proposing something different. In my model, there are no wires,
just bound references and services (using the eventing binding).
> This use of service-reference-wiring model posed several problems.
> We had to start special-casing lots of things. The end product was a
> model that did not make a lot of sense if you come from the pub-sub
> world (or even if you did not). It results in an impedance mismatch.
> Few non-exhaustive examples:
> 1) Subscribers are modeled by services, but the first message
> (subscribe message in some systems) has to actually flow from the
> service to the reference.
This is where an example would help. Is the subscription explicitly
made by the component implementation? I thought the subscription would
be handled by the infrastructure based on the assembly configuration.
If that is the case, then it would be the binding that handles the
subscribe message. Consequently, nothing would need to flow from the
reference to the service. This is exactly how the JMS binding behaves
both with queues and topics. The binding handles the subscription,
i.e. setting up of MessageListeners.
> 2) Publishers should not know who the subscribers are (or if there
> are any) and vice versa. When you explicitly wire services and
> references, this disconnected model is broken.
I'm not proposing to use wires. Also, the publishers remain completely
decoupled from the subscribers in my model. It's the same as when the
JMS binding is used, which is as decoupled as the eventing proposal
Oracle is making.
> 3) A publisher wants to publish by sending a message once. It should
> not have to send the same message to N subscriber (eg, in Java I
> don't want to see an array of references, on which I have to do a
> 'ref[i].send(msg)' in a loop).
In my model it doesn't need to. In Java, the event publishing would
look like the following:
public class SomePublisher ....{
@Reference
protected SomeChannel channel;
public void doIt(....) {
//... do some stuff
Event event = //...
channel.onEvent(event); // publish the event
}
}
The event can be received by 0..n subscribers.
> 4) A deployment of additional publishers should not require any
> change whatsoever to the existing subscribers and vice versa. But a
> service-reference-wiring model does.
My proposal does not require any change to existing subscribers or
publishers in the case where additional publishers are added. Just to
be clear, I'm using a service-reference-binding model, not service-
reference-wiring one.
> 5) Interfaces and methods in pub/sub model are artificial
> constructs. You would of course process these in your language
> specific constructs (such as methods in Java). But events are
> produced and events are consumed. There is no action implied
> whatsoever in the contract. A consumer may ignore a message.
> Interface contracts do have semantics. To use an interface/method
> launchMissles() you have to read the documentation for that method
> to understand what it means.
>
I commented on this in my previous post to Martin. Interfaces do not
necessarily imply semantics. Consider the following in Java:
public interface Foo {
void onFoo(Event event);
}
What does it do?
Interfaces in this context only provide typing. Again, this is where
an example would be beneficial. How would the Oracle proposal look in
Java and how would that be substantially different than what is above?
> You can squint a little and work around some of the mismatches. But
> the cumulative effect of special-casing everything (kind of, death
> by thousand cuts) that results in a model that looks nothing like a
> pub-sub model, isn't very useful IMHO.
>
> There are more examples, this is just off the top of my head. I'll
> respond to the specific questions/proposal in this thread later today.
>
OK thanks. Counter examples in code would be really helpful :-)
Jim
> Thanks.
>
> -Anish
> --
>
> Jim Marino wrote:
>> 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]