[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] [Issue 251] Some early thoughts
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]