RE: [sca-assembly] some of our concerns with the eventing proposal

["Martin Chapman" <martin.chapman@oracle.com>]

 

 

From: Jim Marino [mailto:jim.marino@gmail.com]
Sent: 10 September 2009 10:30
To: OASIS Assembly
Subject: Re: [sca-assembly] some of our concerns with the eventing proposal

 

 

On Sep 9, 2009, at 11:40 PM, Danny van der Rijn wrote:

Anish Karmarkar wrote:
[full conversation below]

One of the mismatches:
 From a pub-sub dev POV, as a publisher I don't want to be aware of all
the subscribers and vice versa. In the current model (for Java POJO)
what I get on the reference side is an array of references -- which
breaks the model. I then also have to iterate over the array and do a
"publish" for each member of the array. That makes no sense from a
pub-sub POV. I want to one publish per event/message. One-way is not
pub=sub.

I wouldn't go so far as to say that the current model's x..n wirings is anything more than a poor-man's hack to approximate pub/sub (perhaps *this* is Martin's chocolate teapot). 

[<MartinC>] My chocolate teapot was a hope that we don’t get to a lowest common denominator of saying an event is an “any” and let the developer worry about unmarshalling and figuring out what the contents are. In other words some content definition language is desirable whether that be wsdl, plain xsd or whatever.

However, using a binding such as JMS with a x..1 binding comes a lot closer to pub/sub.  One-way IS pub/sub IF your transport has pub/sub qualities. 

 

I think this this goes to one of the core issues. The JMS binding can be used for pub/sub and there is no need to iterate over an array of references on the client. Topics can perform a broadcast to multiple services configured as listener endpoints. For example, the following can be done:

 

[<MartinC>] In my head, the current model requires a binding to provide the semantics of the wire is it supporting. Wires asscurrently defined are point to point (single reference to single service). So while I agree that JMS can provide these features, we are currently lacking a wiring mechanism that provides a suitable nxm abstraction, that can be used over different transport technologies. I think this was one of the agreed areas to explore.

 

public class SomeProducerImpl implements .... {

 

          @Reference

        protected EventListener listener;

 

       public void doSomething(...) {

                      // some processing....

                      Event event = //....

                      listener.onEvent(event);

          }

 

}

 

public class SomeConsumer1 implements  EventListener {

 

       public void onEvent(Event event) {

                      // some processing....

          }

 

}

 

public class SomeConsumer2 implements  EventListener {

 

       public void onEvent(Event event) {

                      // some processing....

          }

 

}

 

<composite name="ProducerComposite".....>

          <component name="SomeProducer">

                      <implementation.java class="foo.SomeProducerImpl"/>

                      <reference name="listener">

                                  <binding.jms>

                                        <destination name="someTopic" type="topic"/>

                       </binding.jms>

                      </reference>

          </component>

</composite>

 

<composite name="ConsumerComposite1".....>

          <component name="SomeConsumer1">

                      <implementation.java class="foo. SomeConsumer1"/>

                      <service name="EventListener">

                                  <binding.jms>

                                        <destination name="someTopic" type="topic"/>

                       </binding.jms>

                      </service>

          </component>

</composite>

 

<composite name="ConsumerComposite2".....>

          <component name="SomeConsumer1">

                      <implementation.java class="foo. SomeConsumer2"/>

                      <service name="EventListener">

                                  <binding.jms>

                                        <destination name="someTopic" type="topic"/>

                       </binding.jms>

                      </service>

          </component>

</composite>

 

Both the consumer components (and any other listener subscribed to the topic) will receive messages.

 

Jim

 

Squeezing pub/sub out of a fundamentally point-to-point transport like HTTP is going to take a much larger miracle than the current proposal.