sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: [ASSEMBLY-250] Need an equivalent to "autowire" for the eventing world
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
- Date: Fri, 29 Oct 2010 10:52:56 +0100
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?
However, there seems to be a flavour
here of not using channels at all, which I'd like to
explore.
Does this issue attempt to provide a
means of connecting Producers and Consumers
without needing to explicitly declare
any channels? Are the implied connections then
completely determined by the configuration
of each Producer and each Consumer, in
a pairwise fashion?
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?
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]