OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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 logging compnents


Peter Niblett
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)

From:        Anish Karmarkar <Anish.Karmarkar@oracle.com>
To:        Eric Johnson <eric@tibco.com>
Cc:        Danny van der Rijn <dannyv@tibco.com>, OASIS Assembly <sca-assembly@lists.oasis-open.org>
Date:        21/12/2010 08:29
Subject:        Re: [sca-assembly] [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 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.

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
component type?
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
not happen.

> 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?

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.

> -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]
>>> ---------------------------------------------------------------------
>>> 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:

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 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]