Some responses inline|
On 8/24/2010 8:03 AM, Peter Niblett wrote:
I have taken another look at PC
I think I understand your analysis. Underlying all this is the
of what encapsulation / assembly is for and what it means for
My view is that its main purposes
to simplify the depiction of complex event processing
to allow common subassemblies to be reused. The most common use
see is where an assembler groups together a set of components,
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
"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,
I think it is important to preserve the simplicity that it
this case. In this case the composite is a way of implementing a
What makes the Pathological Case
a) you have events spontaneously
by components in the contained assembly, and consumed by
the assembly as well as being emitted by the assembly
b) the consumer in the contained
consumes events (on a single channel)
It's the combination of both
that makes it difficult, and I am still left wondering how
case it is.
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.
Of all your options, the last one
the cleanest, but it does raise a question, and that is whether
implements a component, or a channel - or both. As you have
it, it looks like it is a combination of both, and I am worried
things by muddling the concepts.
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
On the direct wiring point, I
with your "shorthand" comment. I see them as useful shorthand
for simple non-shareable channels used within an assembly.. You
still use explicit channels for the more complex cases.. I am
we get rid of explicit channels.
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)
A look at use-cases for composition with eventing, alternate
to make them work better
Let me take a stab at answering some of this. This might be
some of what we discussed in the call today. Sorry about
On 08/16/2010 11:52 PM, Anish Karmarkar wrote:
> Thanks for taking the time to do this. I have a few
> 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
> 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
> channels won't they have to appear in the CT of the
> they occur in?
The difference here is perhaps just how you think about it.
primarily promote producers and consumers, and occasionally
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
> 2) page 2, diagram for PC#1, following current WD, but
> channels and bindings:
> why are there two channels in the outermost and middle
> that this is wrong, but one channel would suffice and be
Depends on how you think of compositions. If I build A &
that I want to send messages from A & D, somehow the
intent has to
carried to the developer/designer of the outermost composite
that A should be linked back to D. You've hit the fundamental
- how do I enable composability, achieve a clear result, and
As near as I can tell, from going through this exercise, if I
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
> Another alternative for the same is to not have any
channels in the
> innermost and middle composite, promote all the
> the way to the outermost composite and have a single
> 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
> components that want to use eventing and everyone
connected to the
> same channel (as a producer and as a consumer). Any
> being undeployed (or deployed) causes changes to all
I'm perfectly happy to treat the wires as a short-hand.
from references, I don't see multiple wires from references
multiple channels. That is, if component A wires to D, E, and
could perfectly well be a single channel/Destination when
deployed. If you go with the direct wires approach, you might
whether or not that is an appropriate short-hand, but it seems
> 4) page 4, PC#1: Option: Channels as components, coupled
> I'm not sure I understand this option. More explanation
Let me try again. Drop the current notion of channel
Instead, replace it, in your head, with the notion that *any*
type can couple a producer and consumer in a way that
"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
specialization of a component that follows specific
the formation of its component type. For that matter, since
a specialization of a component type, there's no reason to
the other attributes of a component type, including services,
references, and properties.
> 5) page 6, PC#2, per WD: avoiding global channels and
> You don't need three channels in the outermost composite.
> would suffice.
As we discussed in the call today, if you don't have the
channels, what is implied, at least is that at least two
copies of each
message would be delivered to certain destination components.
thought about it a while, at deployment time, even if all the
have exactly the same characteristics, I don't know for
certain that a
runtime could infer that the multiple channels can be
one, and then only one copy of a message would be received. I
that way to prevent the duplicate message scenario.
> 6) page 7, PC#2, Using channels as components, producer
> Not sure I understand this. Seems like direct wiring.
> 7) page 8, PC#3, per WD avoiding global channels and
> You can simplify this by using only one channel in the
Again, you might, but that only makes sense if you've
intent somehow. If that communication on intent appears in
presumably I'll find it in the component type? Otherwise, 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
of components/composites that happened to be built as many
either of the two versions on the first page would be simpler.
> On 8/4/2010 10:29 PM, Eric Johnson wrote:
>> I've had an action item to pull together use cases
>> discussing the various options around how to think
>> 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
>> put my proposal through its paces, along with a bunch
>> to see how they all fare.
>> I definitely tried to do this fairly. it is possible
>> overlooked some aspect of the current WD, or that I
>> other options fairly, or that there are yet alternate
>> try to tackle the problem.
>> Which, by way of introduction, I mean to say, please
>> arrows, darts, alternate use-cases/scenarios you'd
like to see
>> in any of the different approaches. Or, please feel
>> alternate approaches.
>> Unfortunately, I'm on vacation next week, so I'll be
>> up with whatever discussion we might have, at least
any that happens
>> after Friday afternoon.
>> Attached, please find both the PDF and ODG format.
>> To unsubscribe from this mail list, you must leave
the OASIS TC
>> generates this mail. Follow this link to all your
> To unsubscribe from this mail list, you must leave the
OASIS TC that
> generates this mail. Follow this link to all your TCs in
To unsubscribe from this mail list, you must leave the OASIS
generates this mail. Follow this link to all your TCs in
Unless stated otherwise
IBM United Kingdom Limited - Registered in England and Wales
Registered office: PO Box 41, North Harbour, Portsmouth,