Re: [sca-assembly] [ASSEMBLY-250] Need an equivalent to "autowire"for the eventing world

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

 > From what I can tell, it does seem to map to the use case that Oracle
 > outlined at the F2F. My take-away from their presentation was that
 > references to named "global" channels were really just an alias for
 > "scoping" or "intent", and that calling these channels was slightly
 > confusing, if only because a single "global" domain channel could map
 > to many underlying transport destinations.

Yes, we currently take advantage of the abstract nature of the SCA 
channel concept. Channel, any channel (global named, global default, 
local), is viewed as the scope for event distribution. So channel can 
potentially be mapped to multiple underlying concrete destinations, as 
long as the scope is maintained. For example, a channel C1 that deals 
with only 3 event types E1, E2, and E3, may have two underlying JMS 
topics, T1 and T2. T1 is for event type E1, and T2 is for E2 and E3. 
This can in fact be changed dynamically (say based on load). As long as 
the runtime does the Right Thing (correctly connected the appropriate 
consumers/producers to the right underlying JMS topics) wrt SCA 
producers/consumers connected to C1, one would not notice the difference.

-Anish
--

On 10/29/2010 11:51 AM, Eric Johnson wrote:
>   Hi Mike,
>
> Good questions! Some thoughts below.
>
> On 10/29/10 2:52 AM, Mike Edwards wrote:
>>
>> Eric,
>>
>> In some ways this seems to be a parallel to the "Global Unnamed
>> Channel" that is in the
>> current spec. Can you explain the difference?
> Key differences that I see:
>
>     * An explicit notion of "scoping"
>     * Not associating with a notion of a single modeled "channel", when,
>       in fact many underlying channels might be used.
>     * Where these autowire producers and consumers exist, I suspect it
>       is appropriate to automatically expose them as part of a
>       composite's componentType. This is different from autowire with
>       references, but I suspect appropriate.
>
> When one of my astute co-workers pointed out that we didn't have
> autowire for events, but we do for services, I started trying to sketch
> out in my feeble brain what it might mean. From what I can tell, it does
> seem to map to the use case that Oracle outlined at the F2F. My
> take-away from their presentation was that references to named "global"
> channels were really just an alias for "scoping" or "intent", and that
> calling these channels was slightly confusing, if only because a single
> "global" domain channel could map to many underlying transport destinations.
>>
>> However, there seems to be a flavour here of not using channels at
>> all, which I'd like to
>> explore.
> Indeed.
>>
>> Does this issue attempt to provide a means of connecting Producers and
>> Consumers
>> without needing to explicitly declare any channels?
> In nailing down the concrete details, that seems like one possible
> outcome. Another could be that we require that deployers declare
> channels that will "attach" to the "autowire" producers & consumers
> before deployment succeeds.
>
>> Are the implied connections then
>> completely determined by the configuration of each Producer and each
>> Consumer, in
>> a pairwise fashion?
>
> Perhaps, but as I suggest above, we could allow for enforcing attachment
> to explicitly declared channels.
>>
>>
>> What are the implied rules for connecting some Producer and some
>> Consumer?
>> Do the event type sets for each have to match exactly? Does the
>> Consumer merely
>> have to have a subset of the Producer set?
>
> Those were some questions that occurred to me as well. One possibility
> is exact matching. Seems like your suggestion of consumers subsetting
> producers fits better.
>
> -Eric.
>>
>>
>> Yours, Mike.
>>
>> Strategist - Emerging Technologies, SCA & SDO.
>> Co Chair OASIS SCA Assembly TC.
>> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
>> Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
>> Email: mike_edwards@uk.ibm.com
>>
>> Eric Johnson <eric@tibco.com> wrote on 29/10/2010 00:38:37:
>>
>> > [image removed]
>> >
>> > [sca-assembly] NEW ISSUE: Need an equivalent to "autowire" for the
>> > eventing world
>> >
>> > Eric Johnson
>> >
>> > to:
>> >
>> > OASIS SCA Assembly
>> >
>> > 29/10/2010 00:43
>> >
>> > 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
>> >
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> /
>> /
>>
>> /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/
>>
>>
>>
>>
>>
>>