Re: [sca-assembly] [Issue 251] Some early thoughts

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

On 12/20/2010 4:45 PM, Eric Johnson wrote:
> A quick response to this:
>
> On 12/14/10 12:41 AM, Anish Karmarkar wrote:
>> The pub-sub model is different than this. A consumer may express
>> interest in certain events, but there is absolutely no guarantee that
>> an event may ever be delivered to it. Similarly, a producer may
>> produce events, but there is not guarantee that any consumer is either
>> listening for those events or even if a consumer is listening, it may
>> decide to just drop it on the floor and not take any action based on
>> that event. Furthermore, these kind of connections are meant to be
>> many-to-many. As far as cardinality goes, the cardinality has to be
>> wrt how many channels the producer/consumer is connected to regardless
>> of how many consumer/producers are on those channels. This makes
>> cardinality in pub-sub tricky. As far as cardinality upper bound goes,
>> what is the difference between a consumer connected to 2 channels each
>> with 5 producers and the same consumer connected to a single channel
>> with 10 producers?
>
> Seems like the above notion confuses the M-to-N relationship of
> (publishers & subscribers) "attached" to a channel, with the different
> scenario of attaching a producer to multiple channels. With the latter,
> in the generic case, the runtime will likely need to send messages to
> both channels - thus a receiving consumer will see the same message
> *twice* because a producer is wired to two channels, and the consumer is
> wired to the same two channels. Consequently, I see a dramatic
> difference between allowing a consumer to consume from multiple
> channels, and allowing both a producer and a consumer to attach to
> multiple channels.
>
> In the second case, I'm guaranteeing the ability to achieve a relatively
> useless outcome - a consumer who is ("best effort", or whatever quality
> of service is in use) guaranteed to receive two or more copies of the
> same event.
>
> Why?
>

Hmm. Very similar to multiple copies of emails I get sometimes from 
sca-j, sca-bindings, sca-assembly, sca-policy, and sca-bpel mailing 
lists. I would not want to unsub from either of them. I just use a 
Thunderbird add-on to deal with that.

But, I do see your point.

Nevertheless, at the CT level (which is where the cardinality decision 
is made) you do not know whether such a situation indeed exists. An 
assembler may connect a producer P to >1 channel and a consumer C to >1 
channel. Whether this results in the consumer getting two ore more 
copies of the same event depends on the channels that they are connected 
to. For example, P may be connected to channels C1 and C2 and C may be 
connected to channels C1 and C3. This decision is made at assembly and 
cardinality is decided at component development time.

-Anish
--

> -Eric.
>