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

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

On 12/14/2010 10:09 AM, Danny van der Rijn wrote:
>
>> For example, an order processing component may have a dependency on a
>> credit-card service. Unless that dependency is satisfied, the order
>> processing component just won't work.
>
> Again, back to different interpretations of eventing. Just because I'm
> using eventing doesn't always mean that I'm throwing *any* notion of
> coupling to the wind. Your statement above can have the same validity in
> eventing use cases. Therefore, I think it's necessary to make a
> distinction between a lower bound of 0 and a lower bound of 1.
>

I didn't intend to imply that an application that uses eventing doesn't 
necessarily have a need to have coupling. But I like the model where 
such coupling is done at a higher-level (application logic as far as 
eventing model is concerned). It keeps the model arguable simple, while 
compromising on a feature.
Did you have any specific usecase/scenario in mind?


> I do agree, though, that upper bounds have less meaning in the pub/sub
> world.
>

Good. So we agree, at least, on 50% of the proposal ;-)

>
> On 12/14/2010 12:41 AM, Anish Karmarkar wrote:
>> I took an AI to come up with a proposal for issue 251 [1].
>> Here are my initial thoughts:
>>
>> Issue 251 points out that currently the cardinality (number of channel
>> connections) of producers and consumers is 0..n. It also suggests that
>> we allow 0..1 and 1..1.
>>
>> It seems obvious that this is coming from the fact that in the
>> service-reference model these possibilities exists. I believe that
>> such a comparison isn't appropriate. In the service-reference model, a
>> component-reference specifies an interface-based dependency. Sometimes
>> such dependencies must to be satisfied to get the component/composite
>> to work correctly. For example, an order processing component may have
>> a dependency on a credit-card service. Unless that dependency is
>> satisfied, the order processing component just won't work. Similarly,
>> the same order processing component may want to allow the dependency
>> to be satisfied by multiple credit-card services (requirement being,
>> there be at least one). These dependencies get injected into the
>> component and the component, based on its internal logic, may decide
>> which services to call.
>>
>> 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?
>>
>> Therefore, for the cardinality upper bound, I don't think it makes
>> sense to have a "1" restriction. IOW, it should always be "n".
>>
>> WRT cardinality lower bound, there are two possibilities "0" or "1".
>> I'm leaning towards saying it is always "0", since there is no
>> guarantee that even if you connect the producer/consumer to a channel
>> that anyone else is participating. But I have a feeling that there
>> *might* be good reasons to allow a "1" restriction on the lower bound
>>
>> Thoughts?
>>
>> -Anish
>> --
>>
>> [1] http://osoa.org/jira/browse/ASSEMBLY-251
>>
>> ---------------------------------------------------------------------
>> 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
>