← Prev in month
← Prev in thread
Re: [sca-assembly] A look at use-cases for composition with eventing, alternateapproaches to make them work better
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. 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. 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 <> To: Anish Karmarkar <> Cc: 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
← Prev in month
← Prev in thread