sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: Fw: [sca-assembly] A look at use-cases for composition with eventing, alternateapproaches to make them work better
- From: Peter Niblett <peter_niblett@uk.ibm.com>
- To: Eric Johnson <eric@tibco.com>
- Date: Wed, 22 Sep 2010 20:21:41 +0100
Thanks Eric
Expanding a bit on option 2..
At the moment if I have a consumer in
a composite, I have three choices
1. Wire it to a local channel
2. Wire it to a global channel
3. Promote it
You raise two issues you have with global
channels
i) The fact that the consumer is using
it is not apparent in the component type of the composite. However it is
in effect part of the interface to the composite component., because any
events that happen to be published to that global channel find their way
into it (this is why I think of this as an encapsulation concern).
ii) Someone using the composite in a
higher level assembly has no way to reassign the composite to use a different
channel.
As I said in my previous note, i) js
d not be a problem if the raision d'etre of the channel is to handle events
of a particular genre,, e.g. where the channel is a set of fire alarm events.
It's just part of the internal operation of the composite component.
If someone uses this composite component as part of a higher level assembly,
they will naturally use the same global channel when it is right to do
so.
One reason you might want ii)
is to avoid the name clashing problem. This could be resolved by indirection
(like a Deployment Descriptor in JEE)
Option 2 was to use an indirect reference,
of the form
source ="/SCA/ChannelA"/
The /SCA/ or some similar
syntax indicates that it is a reference to some external channel.
An assembler can then define a local
channel at a higher level called Channel A with a flag to say it
should be visible from components inside nested composites.
This would meet the PC#1 in your use
case
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/09/2010 18:45
Subject:
Re: Fw: [sca-assembly]
A look at use-cases for composition with eventing, alternate approaches
to make them work better
Hi Peter,
Thanks for pulling this email together. As I mentioned on the call,
I think I have some minor points where I'd state the summary differently,
and/or expand.
On 09/14/2010 08:18 AM, Peter Niblett wrote:
As there have been no more postings
on this thread, I will try and summarise the discussion
We have been looking at the use cases in Eric's document [1]. These
involve three producers A,B,C each of which send events to three consumers
D,E,F and the use cases explore various ways in which these components
might be packaged into composites, and the consequent wiring involved.
Perhaps worth restating at this point - I picked this scenario because
it expresses the potential complexity with as few pieces as I think I could
get away with. In actual (eventual) use, I expect many more components,
and many more composites, combined in equally bizarre ways. The key
characteristics include many components (>4 or 5) coupled with composites
nested within other composites. and some relationship between producers
and consumers within the scope of a composite.
If all the components are in one composite, there is no problem, they can
use a channel local to that composite (as shown on page 1).
If all the components use a single global channel, then we achieve our
goal of getting all events from A,B,C to each of D,E,F with a simple model.
However the reason we are having this discussion at all is there is a concern
that this global approach breaks encapsulation.
Well, I don't think it is just a concern. ;-)
I'm not quite sure "encapsulation" covers exactly the same problem
space as "composability." But sure, let's address both!
In PC #1 shown on page 2 there's and
A/D composite nested in one that also contains B/E, in turn nested in one
that contains C/F. There's nothing in the externals of each composite to
tell the assembler of the next level up that it is using a global channel
internally. Thus
a) To get the behaviour we want in this case, the assembler at each level
needs to look inside the implementation of each composite to discover the
name of the global channel being used, and make sure they use the same
one themselves
... and further, that since nothing is exposed as part of the componentType,
the assembler needs to know the intent of the inner composites, and there's
nothing in the model that exposes the need to ask that question. (I
think this is a place where the distinction between encapsulation and composability
matters. We might devise clever ways to use namespaces or other tricks
to scope the use of global domain channels, and thus encapsulate the problem.
However, the absence of any detail in the componentType about which
global channels are in use - or even that there are global channels in
use - still makes it more difficult to compose composites with other composites.)
b) There could be cases where an assembler wants to make sure that
the same channel is used by themselves and all the components in the composites
that they contain - but not let anyone else higher up have access to that
channel, so they can be sure that events stay within the boundaries of
their assembly.
As we've discussed before, the word "access" is a little tricky.
That has room for misinterpretation related to security. I'd
state it as making sure the model isn't forced to expose the channel to
other composites (where the "model" includes global domain channels).
(Not previously discussed): To make the Java analogy,
as part of the Java programming model, a package scoped class is not exposed
to other packages (model exposure), but the runtime does have the ability
to circumvent those model restrictions (access). In the same way,
I'm suggesting that the current model doesn't quite have the correct model
that expresses a constraint similar to the package scoped Java class, but
for a channel. (Perhaps an OSGi analogy is more appropriate, but
I don't know how familiar all of you are with that.)
You could argue that both of these are reasonable characteristics of a
global channel. Such a channel is supposed to represent a stream of events
grouped for some purpose, and the individual component's relationship is
with this stream of events. For example, the channel might contain fire
alarm events, and we know that A, B ,C need to connect to this channel
regardless of what level of composition they are in. Likewise we know that
D, E, F have to consume fire alarm events regardless of where they
are.
We have also discussed using local channels at each level (e.g. a local
channel in the A/D composite) and promoting the producer of A, so that
events from A flow to D and also out to the next level up (B/F). This would
work fine in cases where that's all we want to do.. but in this case we
also want D to consume events from the next level up. If we also promote
the consumer of D, and have local channels in both the A/D and B/F composites
then there are two routes between A and D.. since A and D are connected
to both channels. Presumably this means that D will receive two copies
of each event. To avoid this, Eric had to introduce convoluted wiring with
an additional local channel at each level apart from the lowest.
I can think of the following options:
0. Do nothing. One could argue that global channels work a lot of the time,
and that these scenarios are pathological.
To further complete the record here, Danny has identified that the scenarios
are pathological in their outcomes, not necessarily in their intent.
Also, I've challenged people to come up with alternate uses of global channels
that fit the key characteristics that expose the complexity. If someone
passes along what they think is a real-world scenario with >5 components,
nested composites, and uses global channels, then I'm happy to take that
on and draw pictures. Otherwise, for the moment, we're stuck with
my scenarios, although I wish we weren't.
1. Introduce some kind of formal namespacing
of global channels. I think it was Danny who pointed to a non-pathological
scenario where the top level composites were being used to isolate different
applications, or perhaps dev and test versions of an application.
(Not discussed previously) In addition to the scenarios
that Danny has mentioned, I'm also concerned about scenarios that
include company acquisitions, departmental boundaries, and company reorganizations,
all situations in which managing a "global" namespace of channels
becomes difficult.
2. Introduce a kind of "non-global"
or "respecifiable global" channel. The idea would be like XML
namespace prefixes. Components use something like global namespace references,
but at any level in the assembly you can instantiate a channel (like we
do for local channels) but assign it a name, and any references to that
name in the composite, or in any composite that it contains resolve to
that name (unless the name is already respecified lower down).
Interesting. I don't recall you talking about this on the calls we've
had. If you have, I apologize for missing it. Can I impose
upon you to send a separate email that describes this in a little more
detail? If I can figure out how, after I've seen your email, I can
add some more pictures that represent this approach.
3. Introduce a mechanism where local channels can be promoted. This is
like 2, except that the assembler of each composite gets to choose their
own name. This means that composite components could contain producers,
consumers and channels.. and you would have to explain what the purpose
of that channel is.
4. Have some mechanism which asserts that a promoted producer and consumer
should (must) be connected together when a composite is used in a higher
level assembly (I think this was Eric's original suggestion).
The proposal I submitted to the TC is actually a variation on #3 - no longer
do producers and consumers get promoted via the component type, just channels.
Approach #4 was a suggestion by one of my colleagues at TIBCO, which
I added to the pictures. To my mind, proposal #4 subtly inverts my
original proposal, and has some curious implications. Graphically,
I think this naturally gets expressed as wiring components directly to
each other, instead of wiring them via a "channel" object in
a containing composite.
One other tidbit I think your summary doesn't quite cover - namely terminology.
Specifically, one of the points we've discussed is whether, if you
consider my original proposal, proposal #3, or proposal #4, then the bare
word "channel" is heavily overloaded. and perhaps we need a better
term. Unfortunately, I don't remember all of what others have suggested.
(What we might want to say is something slightly more precise, like
"logical channel", or "channel reference", or "channel
descriptor".)
-Eric.
[1] http://www.oasis-open.org/apps/org/workgroup/sca-assembly/email/archives/201008/pdf00000.pdf
Peter Niblett
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)
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]