[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,alternate approaches to make them work better
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/ > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]