[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] Re: [ASSEMBLY-250] NEW ISSUE: Need an equivalentto "autowire" for the eventing world
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]