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

[Danny van der Rijn <dannyv@tibco.com>]

> 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

S/MIME Cryptographic Signature