Not much time before the meeting to write a response, but here are some
On 06/14/2010 06:50 PM, Peter Niblett wrote:
I'm still having difficulty getting
the right mental picture of what you mean by promoting a channel, but
it's just an artifact of the terminology we are using.
Does seem to be some terminology question here, as "channel" by your
definition sounds like it might be something different from what I'm
I think I understand what it means
promote a service/reference or producer/consumer is promoted. This is
these things are "aspects" of a component, and therefore also
aspects of a composite. So when you combine a set of components to
a composite you can identify e.g. a reference or a consumer of the
with the reference or consumer of one of the components contained in
On the other hand a channel is not
aspect of a component, instead it is a kind of peer to a component - it
is a different kind of artefact that just does routing between real
So you can't identify it directly with anything on the composite. You
could imagine promoting the producer or consumer aspects of a channel,
so that they become producers and consumers of the composite (alongside
any producers and consumers of components in the composite that were
promoted). That way any components in the composite that are connected
to that channel stay using it, but other users of the composite have
ability to send events or receive events from that channel. However I
think that's what you had in mind, since you wouldn't be able to tell
the promoted producer and consumer are attached to the same channel
peeking inside the composite definition.
Yes, this definitely highlights a terminology distinction. For
composability purposes, what I see is that the current model
proposed for eventing allows me to couple a producer and consumer by
way of the @target and @source attributes pointing at the same global
domain channel. If I have a way to couple the producer and consumer
within a component type, then my concerns are quite diminished. I can
now couple them without reference to a domain channel, and thus have
Now, I call that coupling a "channel", but that might be the
terminology that is confusing you. We could equally well call it
"event-coupling", or "paired-eventing", or any other mangling. In my
head, that coupling is a logical reference to (not a definition of) an
entity which could be a TIBCO Rendevous subject, or a JMS Topic, for
At the moment, when constructing
a composite, we say that you can
a) Connect components using a local
channel. Such a channel is private to the composite and so not visible
to anyone else
b) Connect them using a global
This isn't defined at all in the composite.. all the composite contains
are references to it, but these references are hidden inside the
definition and not visible at its externals.
So I think what you are asking for
a way to do
c) Connect them using a non-local
This isn't defined in the composite, but is given a kind of symbolic
That name then becomes a property of the composite, and when an
creates the next higher composite they can either choose to map it to a
real channel defined locally in that next higher composite, or map it
a global channel, or promote it up one more level.
I think you're pretty close here, but it is time to call in to the
conf. call, so I'll wrap for now.
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)
Am I missing something here?
I don't see how this is any different from a service or reference that
is promoted to the boundaries of a containing composite.
For that matter, the current eventing proposal promotes consumers and
and those in turn could be promoted to the boundary of the next
composite. The *only* difference I see is that my proposal leaves
open the possibility that consumers and providers would be subject to
same policies set in the same place - for example an expectation of
set on a channel - and that seems more appropriate to me.
In any case, I don't see why you perceive that this question around
is specific to channels.
On Jun 8, 2010, at 8:24 AM, Anish Karmarkar wrote:
> One of the things that has been proposed by Eric is promotion of
outside of a composite. I'm assuming that such promotions will allow
intents/policies to be added on promoted channels by composites at
levels. I'm not sure what that means to consumers/subscribers that are
deeper down in the hierarchy.
> I imagine that channel policies/intents will impact all the
connected to it. When a channel is promoted with additional/different
on it, what happens to consumers/producers that are connected to the
channel at a lower level. Are they affected by the additional
If they are that would be very counter-intuitive. If they are not
is it still the same channel? For example, if it is a JMS topic, it is
going to be the same topic for the consumers/producers at all levels.
topic has to be created with particular guarantees/persistence that are
going to affect all consumers/producers. This changes the intent model.
The intents would now flow up *and* down the hierarchy.
> To unsubscribe from this mail list, you must leave the OASIS TC
> generates this mail. Follow this link to all your TCs in OASIS
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:
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6