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

[Eric Johnson <eric@tibco.com>]

To echo Danny's point...

I think about this as the difference between warnings and errors.

In my view, a sensible "design-time" experience for a composite editor 
will show warnings whenever consumers and producers have no channels 
connected to them.  Some components, however may wish to indicate that 
some of those possible warnings are more severe than others.  For 
example, a consumer of a logging service may not think it an error if it 
is not currently connected to anything (or, as a continuation of our 
morning discussion, autowire does nothing).

However, a consumer used to implement a non-repudiation purposes may 
care deeply if it isn't getting messages, and that needs to be escalated 
into an error condition.  An analogy that comes to mind - Java 
exceptions - checked or unchecked?  Mostly, I think Java developers have 
collectively come to agree that checked exceptions tend to be way over 
used in APIs.  Does that mean that they're *never* useful?  Some people 
certainly stake out that position, but certainly not everyone.  Bringing 
the analogy full circle - this low-end wiring requirement strikes me as 
a similar pattern of assertion - I *require* that the situation be dealt 
with, versus simply knowing that it ought to be dealt with.

I conclude that doing something here is a useful part of the model.

Question: would using a policy intent be a valid alternate way of 
capturing the same notion?

-Eric.

On 12/14/10 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 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
>