RE: [sca-assembly] Re: [ASSEMBLY-250] NEW ISSUE: Need an equivalentto "autowire" for the eventing world

[Martin Chapman <MARTIN.CHAPMAN@oracle.com>]

Personally I think the default global channel satisfies the autowire use case, as without some additional semantics I don't think we can do anything else. What criteria would the run time use to select one channel over another?

Martin.


> -----Original Message-----
> From: Anish Karmarkar
> Sent: 01 November 2010 21:25
> To: sca-assembly@lists.oasis-open.org
> Subject: [sca-assembly] Re: [ASSEMBLY-250] NEW ISSUE: Need an equivalent to
> "autowire" for the eventing world
> 
> 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
> 
> ---------------------------------------------------------------------
> 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
>