| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] [Issue 251] Some early thoughts
- From: Peter Niblett <firstname.lastname@example.org>
- To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Tue, 21 Dec 2010 11:15:41 +0000
The main question seems to be whether the
author of an event producing component needs a way of asserting that "my
events must be processed by someone", or whether it's actually the
application assembler's responsibility to make sure this happens.
Let's suppose that we think the component
author does need this ability... As Anish has pointed out, a cardinality
lower bound of 1 in the CT won't actually achieve this, so long as we require
(allow) producers to be wired to channels. All it would say is that the
events get as far as the channel. So at best it would be a hint.
It would be a bit stronger if assemblers were to wire directly from
Producers to Consumers, but even then the Consumer could choose to filter
out the event.
Eric's intent idea seems to be pointing
to some kind of assertion on the producer that says "my events must
be handled". I guess this could be used by a static analysis tool
that looks at the whole assembly and flags an error/warning if it sees
such producers whose events appear to be going nowhere. There's a number
of things like this that a static analysis tool can do - we give a brief
discussion of them in chapter 10 of the book Event Processing in Action.
The logging / non-repudiation point
is valid, but again putting a cardinality of 1 doesn't guarantee that the
event goes to a logging service - just that it goes somewhere. This is
another question where we have to decide whether it's something that needs
first class support in the model, or whether we can reasonably (at least
for now) leave it to assemblers to make sure that they wire in the right
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)
Anish Karmarkar <Anish.Karmarkar@oracle.com>
Eric Johnson <email@example.com>
Danny van der Rijn
<firstname.lastname@example.org>, OASIS Assembly <email@example.com>
[Issue 251] Some early thoughts
On 12/14/2010 12:54 PM, Eric Johnson wrote:
> 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
> 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
> 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.
I see this slightly differently. Being connected to a channel means
nothing wrt getting messages (or having your messages be acted on).
WRT warnings/errors comparison: The way I see this is that a
tool/validator can look at a composite and let the user know that a
particular producer/consumer is not connected anywhere. The user can
decide if this is fatal or not. Or even set an option that says how
strict he wants to be.
But this isn't really about the tool/validator user (or assembler). The
question is: should component developer be able to set this in the
I tend to think that this would be very misleading to the developer.
Connectedness in eventing, unlike service-reference world, guarantees
nothing. A developer who wants to rely on message being received or
being acted upon, can set the cardinality with the expectation that
appropriate messages are indeed being received or acted up. And this may
> 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
> 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
> a similar pattern of assertion - I *require* that the situation be
> 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?
Don't think it could. Assuming eventing would have intent matching
similar to the one in service-ref world, all the policy intent would say
is *if* you connect, then the intents have to match. This assumes that
the policy intent semantics for eventing would not be drastically
different from the service-ref world. There is an issue for this, which
we haven't resolved yet.
> On 12/14/10 10:09 AM, Danny van der Rijn wrote:
>>> For example, an order processing component may have a dependency
>>> credit-card service. Unless that dependency is satisfied,
>>> processing component just won't work.
>> Again, back to different interpretations of eventing. Just because
>> using eventing doesn't always mean that I'm throwing *any* notion
>> coupling to the wind. Your statement above can have the same validity
>> in eventing use cases. Therefore, I think it's necessary to make
>> 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
>> On 12/14/2010 12:41 AM, Anish Karmarkar wrote:
>>> I took an AI to come up with a proposal for issue 251 .
>>> Here are my initial thoughts:
>>> Issue 251 points out that currently the cardinality (number
>>> channel connections) of producers and consumers is 0..n. It
>>> suggests that we allow 0..1 and 1..1.
>>> It seems obvious that this is coming from the fact that in
>>> service-reference model these possibilities exists. I believe
>>> such a comparison isn't appropriate. In the service-reference
>>> 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
>>> Unless that dependency is satisfied, the order processing
>>> just won't work. Similarly, the same order processing component
>>> 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,
>>> 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
>>> an event may ever be delivered to it. Similarly, a producer
>>> produce events, but there is not guarantee that any consumer
>>> either listening for those events or even if a consumer is
>>> it may decide to just drop it on the floor and not take any
>>> based on that event. Furthermore, these kind of connections
>>> to be many-to-many. As far as cardinality goes, the cardinality
>>> to be wrt how many channels the producer/consumer is connected
>>> regardless of how many consumer/producers are on those channels.
>>> makes cardinality in pub-sub tricky. As far as cardinality
>>> bound goes, what is the difference between a consumer connected
>>> channels each with 5 producers and the same consumer connected
>>> single channel with 10 producers?
>>> Therefore, for the cardinality upper bound, I don't think
>>> sense to have a "1" restriction. IOW, it should
always be "n".
>>> WRT cardinality lower bound, there are two possibilities "0"
>>> I'm leaning towards saying it is always "0", since
there is no
>>> guarantee that even if you connect the producer/consumer to
>>> that anyone else is participating. But I have a feeling that
>>> *might* be good reasons to allow a "1" restriction
on the lower bound
>>>  http://osoa.org/jira/browse/ASSEMBLY-251
>>> To unsubscribe from this mail list, you must leave the OASIS
>>> generates this mail. Follow this link to all your TCs in OASIS
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:
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]