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

Regards

Peter Niblett

IBM Senior Technical Staff Member

Member of the IBM Academy of Technology

+44 1962 815055

+44 7825 657662 (mobile)

From:      
 Anish Karmarkar <>

To:      
 Eric Johnson <>

Cc:      
 Danny van der Rijn
<>, OASIS Assembly <>

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

>>

---------------------------------------------------------------------

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