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

[Jim Marino <jim.marino@gmail.com>]

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). 

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:

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.