sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] Issue 227: what does promotion of channels mean wrtintents/policies
- From: Peter Niblett <peter_niblett@uk.ibm.com>
- To: Eric Johnson <eric@tibco.com>
- Date: Tue, 22 Jun 2010 15:39:19 +0100
Hi Eric
I am afraid I missed last week's call,
so I don't know if you discussed this or not, but here's a quick reply.
Yes you CAN connect two components in
an assembly by point the @source of one and the @target of the other to
the same global channel, but that's not the only way of connecting them
together. The alternatives are
a) Connect them using a what the spec
calls a "local channel". This is a logical construct that is
scoped just within a single level of the assembly, and it indicates that
events from the producers connected to it are to be routed to the consumers
connected to it (subject to any filters on those consumers) - nothing more
and nothing less (i.e. no events coming in from outside the assembly, and
no events leaking out to the outside world). It could be implemented using
a JMS topic with a special name that no-one else knows, or by a simple
in-memory multicastor, or by some other mechanism used by the SCA runtime.
b) Syntactically the local channel could
be eliminated and we could allow @source and @targets to be directly wired,
e.g. allow the Consumers X and Y to be specified as @targets of Producer
A, or allow Producers A and B to be specified as @sources for Consumer
X. However the spec currently does not allow this, and requires you to
use a local channel construct instead.
Regards
Peter Niblett
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)
From:
| Eric Johnson <eric@tibco.com>
|
To:
| Peter Niblett/UK/IBM@IBMGB
|
Cc:
| OASIS Assembly <sca-assembly@lists.oasis-open.org>
|
Date:
| 15/06/2010 16:01
|
Subject:
| Re: [sca-assembly] Issue 227: what does
promotion of channels mean wrt intents/policies |
Hi Peter,
Not much time before the meeting to write a response, but here are some
quick thoughts:
On 06/14/2010 06:50 PM, Peter Niblett wrote:
Hi Eric
I'm still having difficulty getting the right mental picture of what you
mean by promoting a channel, but maybe 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 thinking of.
I think I understand what it means to promote a service/reference or producer/consumer
is promoted. This is because these things are "aspects" of a
component, and therefore also aspects of a composite. So when you combine
a set of components to produce a composite you can identify e.g. a reference
or a consumer of the composite with the reference or consumer of one of
the components contained in that composite.
On the other hand a channel is not an 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 components. 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 also promoted). That way any components in the
composite that are connected to that channel stay using it, but other users
of the composite have the ability to send events or receive events from
that channel. However I don't think that's what you had in mind, since
you wouldn't be able to tell that the promoted producer and consumer are
attached to the same channel without 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 enhanced composability.
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 example.
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 channel. This isn't defined at all in the
composite.. all the composite contains are references to it, but these
references are hidden inside the composite definition and not visible at
its externals.
So I think what you are asking for is a way to do
c) Connect them using a non-local channel. This isn't defined in the composite,
but is given a kind of symbolic name. That name then becomes a property
of the composite, and when an assembler 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 to 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.
-Eric.
Regards
Peter Niblett
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)
Hi Anish,
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 providers,
and those in turn could be promoted to the boundary of the next containing
composite. The *only* difference I see is that my proposal leaves
open the possibility that consumers and providers would be subject to the
same policies set in the same place - for example an expectation of "confidentiality"
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 policies
is specific to channels.
Eric.
On Jun 8, 2010, at 8:24 AM, Anish Karmarkar wrote:
> One of the things that has been proposed by Eric is promotion of channels
outside of a composite. I'm assuming that such promotions will allow for
intents/policies to be added on promoted channels by composites at higher
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 consumers/producers
connected to it. When a channel is promoted with additional/different intents/policies
on it, what happens to consumers/producers that are connected to the same
channel at a lower level. Are they affected by the additional intents/policies?
If they are that would be very counter-intuitive. If they are not affected,
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. The
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.
>
> -Anish
> --
>
>
>
> ---------------------------------------------------------------------
> 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
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
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]