Re: [ASSEMBLY-250] NEW ISSUE: Need an equivalent to "autowire" forthe eventing world

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

What would the criteria be for autowiring? We don't require producers 
and channels to tell the "whole truth" about the event types that they 
produce. Only consumer specify exactly what they want (from the 
runtime), so we would be wiring consumer->channel(s) and 
producer->channel(s) based on incomplete information.

Furthermore, event types are different than interfaces in that the event 
type info do not have the same kind of method semantics associated with 
it that interface/methods do. A WMD-found event is just that, as opposed 
to 'void startWar(WMDFound madeupData)'. There is a "semantic 
loose-coupling" in eventing.

Multiple channels that have the same event type information associated 
with it may in fact do very different things, especially if you are 
reusing EDLs for various purposes.

"The use case: Forcing users to explicitly wire up all of the producers 
and consumers may be over-determined ..." -- I tend to think that this 
is a good thing. Assuming that a consumer/producer needs to be wired to 
a particular channel based on the config that we (currently) have in the 
model seems presumptuous in the eventing world of loose coupling, 
partial declarations by producers/channels, and reusing of event types. 
Especially, if the scope of such an "autowire" is anything beyond the 
composite.

-Anish
--

On 10/28/2010 4:38 PM, Eric Johnson wrote:
> Title: Need an equivalent to "autowire" for the eventing world
>
> Target: Assembly 1.2 WD 01
>
> Description:
> With the references and services of SCA Assembly, the spec currently
> supports the notion of "autowire". Whatever the merits in the service
> space, this concept fits even more naturally into the eventing world.
>
> The use case: Forcing users to explicitly wire up all of the producers
> and consumers may be over-determined. That, is, given the exact
> specification of which events a consumer is interested in, and the
> events that a producer sends out, that should be sufficient to wire
> them. Making this situation worse, users might have to go through the
> error prone effort of specifying which channels are required to connect
> to which producers, and possibly missing out, or incorrectly wiring in a
> few cases.
>
> One distinction to draw in the "autowire" of producers and consumers in
> the eventing world is that it may be very useful to have auto-wired
> consumers and producers cross composite boundaries. Some notion of
> "scope" might be appropriate. Two forms of scope probably make sense:
>
> - one bounded by the presence of a parent composite
> - the other tied to some notion of intent. For example, I want scope
> "sales", or "sales, northamerica", or "manufacturing, europe"
>
> Abstract proposal:
>
> Add to a component producer, and a component consumer an attribute
> @autowire (true/false). The presence of @autowire true prevents the use
> of the @target, and @source attributes. Also add an @autowireIntent
> attribute, which includes a space separated list of tags/intents to pair
> up.
>
> In conjunction with autowiring, a producer must declare the exact set of
> events it produces, and a consumer must declare the exact set it consumes.
>
>
> ---------------------------------------------------------------------
> 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