> 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 do agree, though, that upper bounds have less meaning in the pub/sub
world.
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
