Yours, Mike
Dr Mike Edwards
Mail Point 146, Hursley
Park
STSM
Winchester, Hants SO21
2JN
SCA & Services
Standards
United Kingdom
Co-Chair OASIS SCA
Assembly TC
IBM Software Group
Phone:
+44-1962 818014
Mobile:
+44-7802-467431 (274097)
e-mail:
----- Forwarded by Mike
Edwards/UK/IBM on 14/12/2010 13:56 -----
From:
Mike Edwards/UK/IBM
To:
Anish Karmarkar <>
Date:
14/12/2010 09:08
Subject:
Re: [sca-assembly] [Issue 251] Some
early thoughts
Anish,
Thanks for these thoughts.
I started with the position which I
think you express below - namely that cardinality has no place in the Event
Processing
world and is nominally 0..n in all cases.
The reason that this issue got raised
was some discussion during the F2F, which has indeed re-emerged on the
227
discussion list, that some folk think
that there is a reason to limit the number of places that a producer and/or
a consumer
and/or a "prosumer" can be
connected to.
I actually don't agree with this. I
think that limiting the cardinality which can apply to any of these things
does not serve the
needs of anyone - least of all the Assembler.
I have not seen any usecases for which a limitation actually adds
anything.
As a result, my position is that we
can Close with No Action on this issue, leaving the cardinality as 0..n
as it is today.
Yours, Mike
Dr Mike Edwards
Mail Point 146, Hursley
Park
STSM
Winchester, Hants SO21
2JN
SCA & Services
Standards
United Kingdom
Co-Chair OASIS SCA
Assembly TC
IBM Software Group
Phone:
+44-1962 818014
Mobile:
+44-7802-467431 (274097)
e-mail:
From:
Anish Karmarkar <>
To:
OASIS Assembly <>
Date:
14/12/2010 08:51
Subject:
[sca-assembly] [Issue 251] Some early
thoughts
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
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
