Hi Mike,
Good questions! Some thoughts below.
On 10/29/10 2:52 AM, Mike Edwards wrote:
OFD2A18D6C.0F2FF3DF-ON802577CB.00355AE3-802577CB.0035EF9B@uk.ibm.com"
type="cite">
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.
OFD2A18D6C.0F2FF3DF-ON802577CB.00355AE3-802577CB.0035EF9B@uk.ibm.com"
type="cite">
However, there seems to be a
flavour
here of not using channels at all, which I'd like to
explore.
Indeed.
OFD2A18D6C.0F2FF3DF-ON802577CB.00355AE3-802577CB.0035EF9B@uk.ibm.com"
type="cite">
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.
OFD2A18D6C.0F2FF3DF-ON802577CB.00355AE3-802577CB.0035EF9B@uk.ibm.com"
type="cite">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.
OFD2A18D6C.0F2FF3DF-ON802577CB.00355AE3-802577CB.0035EF9B@uk.ibm.com"
type="cite">
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.
OFD2A18D6C.0F2FF3DF-ON802577CB.00355AE3-802577CB.0035EF9B@uk.ibm.com"
type="cite">
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
|