Re: Fw: [sca-assembly] A look at use-cases for composition with eventing,alternate approaches to make them work better

[Eric Johnson <eric@tibco.com>]

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:

OF5BB00102.D3159F94-ON8025779E.0053EB02-8025779E.00541899@uk.ibm.com" type="cite">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.

OF5BB00102.D3159F94-ON8025779E.0053EB02-8025779E.00541899@uk.ibm.com" type="cite">
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!

OF5BB00102.D3159F94-ON8025779E.0053EB02-8025779E.00541899@uk.ibm.com" type="cite"> 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.)

OF5BB00102.D3159F94-ON8025779E.0053EB02-8025779E.00541899@uk.ibm.com" type="cite">
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.)

OF5BB00102.D3159F94-ON8025779E.0053EB02-8025779E.00541899@uk.ibm.com" type="cite">
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.

OF5BB00102.D3159F94-ON8025779E.0053EB02-8025779E.00541899@uk.ibm.com" type="cite">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.

OF5BB00102.D3159F94-ON8025779E.0053EB02-8025779E.00541899@uk.ibm.com" type="cite">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.

OF5BB00102.D3159F94-ON8025779E.0053EB02-8025779E.00541899@uk.ibm.com" type="cite">
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.

OF5BB00102.D3159F94-ON8025779E.0053EB02-8025779E.00541899@uk.ibm.com" type="cite">


[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)