sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Fw: [sca-assembly] A look at use-cases for composition with eventing, alternateapproaches to make them work better
- From: Peter Niblett <peter_niblett@uk.ibm.com>
- To: OASIS Assembly <sca-assembly@lists.oasis-open.org>
- Date: Tue, 14 Sep 2010 16:18:32 +0100
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>
To: Anish
Karmarkar <Anish.Karmarkar@oracle.com>
Cc: 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]