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

[Anish Karmarkar <Anish.Karmarkar@ORACLE.COM>]

One issue I have with these usecases is:
I do think these are pathalogical cases, but more importantly I can't 
quite wrap my head around it. In eventing, as I see it, most of the 
times you think about which "channel" you want to be connected to as a 
consumer or a producer. Not which components in which composites are 
connected together -- when that does happen and there is a composition 
hierarchy, you have to look within all the composites and figure out if 
you are doing the right thing. You can't think of connecting consumers 
A, B, C and producers D, E, F together regardless of composition and 
regardless of their position in the hierarchy without having to look 
within the composite hierarchy.

-Anish
--

On 9/14/2010 8: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.
>
> 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. 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
>
> 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.
>
> 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.
> 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.
> 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).
> 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).
>
>
>
> [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)
>
>
>
>
> From: Peter Niblett/UK/IBM@IBMGB
> To: Danny van der Rijn <dannyv@tibco.com>
> Cc: OASIS Assembly <sca-assembly@lists.oasis-open.org>
> Date: 31/08/2010 13:01
> Subject: Re: [sca-assembly] A look at use-cases for composition with
> eventing, alternate approaches to make them work better
> ------------------------------------------------------------------------
>
>
>
> Danny
>
> I don't have a problem with a use case that has A,B,C as various kinds
> of producer, and D,E,F as consumers (two of them being loggers and one a
> visual display). Our discussion has been around the grouping of these
> things into composites - and the rationale for doing that.
>
> As I said in my earlier note, the main reasons for using composites are
> a) to simplify the resulting picture, b) to allow someone to reuse a
> composite component by treating it as a component in its own right,
> without having to understand its internal structure (which may involve
> further nested composites).
>
> So I think we are all happy with the pictures on Eric's first page. The
> first one doesn't have composites at all, and does what you would
> expect. The second one groups together all the producers, so they become
> a "composite producer" which can be used by an assembler just like a
> simple producer, and likewise groups the consumers together to make a
> "composite consumer". So far so good.
>
> Now let's suppose you want to group together producer A and consumer D
> into a composite, as suggested by the picture on top of page 2. Why are
> you doing this? Well, several possible reasons
>
> i) You want to let people consume the events produced by A, but also
> make sure that they are logged by D. To do this you connect A to D by a
> channel that is private to the composite and promote A. As far as the
> outside world is concerned the composite is a producer, it just happens
> to log the events that it produces as well. This use case works well
> with the current WD
>
> ii) You want the composite to be able to log things from the outside, as
> well as the events produced by A. In this case you connect A to D by a
> local channel (as in the previous case), but this time you promote D, so
> the users of the composite can view it as a consumer. It just happens to
> consume events that are produced internally as well. Again no problem
> with the current WD,
>
> iii) You are grouping them together for administrative convenience - a
> bit like an old 74XX integrated circuit which would include (for
> example) 4 NAND gates in a single DIL package. In this case you would
> promote both A and D, but not wire them internally. The documentation
> for the component would say (in natural language) that it contains a
> producer and a consumer, and it would then be up to the assembler to
> decide whether to wire A to D or not, depending on the needs of the
> application.
>
> It is this last bit that you and Eric are contesting, as I think your
> use case is along the lines of..
>
> iv) A+D and B+E are siloed apps, that should work either in isolation or
> when composed together. When composed together cross-connects come in to
> play so that events from A have to go to E, and events from B go to D.
> Doing this with local channels is a problem (since you would want a
> local channel between A/D and B/E in the siloed case, bit not in the
> cross-connect case since the connections there are done at the next
> level up). However this scenario can be realised by using global
> channels. Some time ago I suggested that what you are really asking for
> is a way of parameterising the global channel name, so that it could be
> modified by the assembler who uses the composite.
>
> Regards
>
> Peter Niblett
> IBM Senior Technical Staff Member
> Member of the IBM Academy of Technology
> +44 1962 815055
> +44 7825 657662 (mobile)
>
>
>
>
> From: Danny van der Rijn <dannyv@tibco.com>
> To: OASIS Assembly <sca-assembly@lists.oasis-open.org>
> Date: 25/08/2010 23:00
> Subject: Re: [sca-assembly] A look at use-cases for composition with
> eventing, alternate approaches to make them work better
> ------------------------------------------------------------------------
>
>
>
> Some responses inline
>
> On 8/24/2010 8:03 AM, Peter Niblett wrote:
> Hi Eric
>
> I have taken another look at PC #1 and I think I understand your
> analysis. Underlying all this is the question of what encapsulation /
> assembly is for and what it means for events.
>
> My view is that its main purposes are to simplify the depiction of
> complex event processing applications, and to allow common subassemblies
> to be reused. The most common use case I see is where an assembler
> groups together a set of components, with well defined producers and /
> or consumers, that can be then treated as a single component by some
> higher level user. The examples in the WD and your "easy scenario" on
> page 1 are examples of this kind of use case. The approach we have in
> the WD is well suited to this use case, and I think it is important to
> preserve the simplicity that it provides for this case. In this case the
> composite is a way of implementing a component
>
> What makes the Pathological Case different is that
>
> a) you have events spontaneously produced by components in the contained
> assembly, and consumed by components in the assembly as well as being
> emitted by the assembly
> b) the consumer in the contained component consumes events (on a single
> channel)
>
> It's the combination of both these points that makes it difficult, and I
> am still left wondering how important a case it is.
>
> <vdR>
> IMO it's a pretty standard case. To repeat my use case from the meeting
> yesterday, I'll make an analogy to slf4j. Consider some subsystem that
> includes D as a log sink that writes to logfiles. 'A' represents any
> number of components that emit log events. Compose that with B/E where B
> represents more emitters, and E represents another sink, this time to a
> database. And compose again with C/F where F filters some of the events
> and shows them on a user console. The point of using events for logging
> is exactly that you don't know who's producing the events, and
> furthermore, there are so many ways and reasons to consume them that you
> don't want to be tied down to using a service.
>
> IMO the "fir tree" is exactly correct here: the A/D component needs to
> say that A and D are coupled, but doesn't care to say on what channel
> binding. B/E are coupled in a similar fashion, and furthermore, B/E are
> coupled to the same channel binding. Etc.
> </vdR>
>
>
> Of all your options, the last one is the cleanest, but it does raise a
> question, and that is whether the composite implements a component, or a
> channel - or both. As you have drawn it, it looks like it is a
> combination of both, and I am worried that complicates things by
> muddling the concepts.
>
> <vdR>
> In the last two options, I think Eric is trying to show that the
> *coupling* of the producer and consumer as part of the componentType. In
> this last example that you're highlighting, since the consumer and
> producer are shown separated, there's certainly the possibility of
> ambiguity in what this might mean in the graphical form. If you overlay
> the semantics that the runtime merely treats them as referring to the
> same thing, then this is just constraining/delegating to the runtime to
> connect producers and consumers, in the same way that the runtime
> connects services and references.
> </vdR>
>
> On the direct wiring point, I agree with your "shorthand" comment. I see
> them as useful shorthand for simple non-shareable channels used within
> an assembly.. You would still use explicit channels for the more complex
> cases.. I am not suggesting we get rid of explicit channels.
>
> 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>_ <mailto:eric@tibco.com>
> To: Anish Karmarkar _<Anish.Karmarkar@oracle.com>_
> <mailto:Anish.Karmarkar@oracle.com>
> Cc: _sca-assembly@lists.oasis-open.org_
> <mailto:sca-assembly@lists.oasis-open.org>
> Date: 17/08/2010 19:40
> Subject: Re: [sca-assembly] A look at use-cases for composition with
> eventing, alternate approaches to make them work better
> ------------------------------------------------------------------------
>
>
>
> Hi Anish,
>
> Let me take a stab at answering some of this. This might be repeating
> some of what we discussed in the call today. Sorry about that.
>
> On 08/16/2010 11:52 PM, Anish Karmarkar wrote:
>  > Eric,
>  >
>  > Thanks for taking the time to do this. I have a few questions/comments
>  > on the material (listed below). It would be a good idea to have you
>  > present this on one of our calls. I should also note that we should
>  > evaluate this from the POV of existing usecases that we want to solve.
>  >
>  > 1) page 1, last two bullets: Isn't that the same? IOW, if you promote
>  > channels won't they have to appear in the CT of the composite that
>  > they occur in?
>
> The difference here is perhaps just how you think about it. Do you
> primarily promote producers and consumers, and occasionally tie them
> together (and that shows in the CT), or do you indicate channels in the
> CT, but (we expect) mostly only use one half of the channel from the
> component?
>
>  >
>  > 2) page 2, diagram for PC#1, following current WD, but avoiding global
>  > channels and bindings:
>  > why are there two channels in the outermost and middle composite? Not
>  > that this is wrong, but one channel would suffice and be simpler.
>
> Depends on how you think of compositions. If I build A & D, and know
> that I want to send messages from A & D, somehow the intent has to be
> carried to the developer/designer of the outermost composite to know
> that A should be linked back to D. You've hit the fundamental question
> - how do I enable composability, achieve a clear result, and also convey
> that intent?
>
> As near as I can tell, from going through this exercise, if I cannot
> convey the intent somehow in the CT, then you cannot address any of the
> use-cases I drew up here, and still achieve a clear result, or
> composability.
>
>  >
>  > Another alternative for the same is to not have any channels in the
>  > innermost and middle composite, promote all the consumer/producers all
>  > the way to the outermost composite and have a single channel that
>  > connects C, F and the promoted consumer/producer.
>
> And you've conveyed the intent that that needs to happen how?
>
>  >
>  > 3) page 3, direct wires: I see this as problematic. It does not scale
>  > well and has problems with dynamic systems. Consider domain-level
>  > components that want to use eventing and everyone connected to the
>  > same channel (as a producer and as a consumer). Any single component
>  > being undeployed (or deployed) causes changes to all other components.
>
> I'm perfectly happy to treat the wires as a short-hand. Unlike wires
> from references, I don't see multiple wires from references implying
> multiple channels. That is, if component A wires to D, E, and F, that
> could perfectly well be a single channel/Destination when ultimately
> deployed. If you go with the direct wires approach, you might question
> whether or not that is an appropriate short-hand, but it seems possible,
> at least.
>
>  >
>  > 4) page 4, PC#1: Option: Channels as components, coupled
>  > producers/consumers:
>  > I'm not sure I understand this option. More explanation would help.
>
> Let me try again. Drop the current notion of channel altogether.
> Instead, replace it, in your head, with the notion that *any* component
> type can couple a producer and consumer in a way that indicates
> "pass-through". That is, "all" (approximately) events sent to the
> consumer will end up at the coupled producer.
>
> Or, if you want to think about it in reverse, "channels" are just a
> specialization of a component that follows specific characteristics in
> the formation of its component type. For that matter, since it is just
> a specialization of a component type, there's no reason to exclude all
> the other attributes of a component type, including services,
> references, and properties.
>
>  >
>  > 5) page 6, PC#2, per WD: avoiding global channels and bindings:
>  > You don't need three channels in the outermost composite. One channel
>  > would suffice.
>
> As we discussed in the call today, if you don't have the multiple
> channels, what is implied, at least is that at least two copies of each
> message would be delivered to certain destination components. Having
> thought about it a while, at deployment time, even if all the "channels"
> have exactly the same characteristics, I don't know for certain that a
> runtime could infer that the multiple channels can be collapsed into
> one, and then only one copy of a message would be received. I drew it
> that way to prevent the duplicate message scenario.
>
>  >
>  > 6) page 7, PC#2, Using channels as components, producer and consumer
>  > tied:
>  > Not sure I understand this. Seems like direct wiring.
>  >
>  > 7) page 8, PC#3, per WD avoiding global channels and bindings:
>  > You can simplify this by using only one channel in the outer composite.
>
> Again, you might, but that only makes sense if you've communicated that
> intent somehow. If that communication on intent appears in the model,
> presumably I'll find it in the component type? Otherwise, I think I
> just have to "know" what to do. And that just circles back to the point
> of the issue - that isn't composability, that's just a monolithic batch
> of components/composites that happened to be built as many pieces, when
> either of the two versions on the first page would be simpler.
>
> -Eric.
>
>  >
>  > -Anish
>  > --
>  >
>  >
>  > On 8/4/2010 10:29 PM, Eric Johnson wrote:
>  >> I've had an action item to pull together use cases relevant for
>  >> discussing the various options around how to think about composing with
>  >> eventing.
>  >>
>  >> Well, maybe it wasn't an official action item at first, but I took it as
>  >> a useful exercise to apply some rigor to what I proposed, and actually
>  >> put my proposal through its paces, along with a bunch of other options,
>  >> to see how they all fare.
>  >>
>  >> I definitely tried to do this fairly. it is possible that I've
>  >> overlooked some aspect of the current WD, or that I didn't implement
>  >> other options fairly, or that there are yet alternate ways that we could
>  >> try to tackle the problem.
>  >>
>  >> Which, by way of introduction, I mean to say, please send back comments,
>  >> arrows, darts, alternate use-cases/scenarios you'd like to see me pursue
>  >> in any of the different approaches. Or, please feel free to suggest
>  >> alternate approaches.
>  >>
>  >> Unfortunately, I'm on vacation next week, so I'll be tardy in catching
>  >> up with whatever discussion we might have, at least any that happens
>  >> after Friday afternoon.
>  >>
>  >> Attached, please find both the PDF and ODG format.
>  >>
>  >> -Eric.
>  >>
>  >>
>  >>
>  >> ---------------------------------------------------------------------
>  >> 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_
>
> ---------------------------------------------------------------------
> 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/
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> /
> /
>
> /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/
>
>
>
>
>
>