sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] Fw: [sca-assembly-comment] NEW ISSUE: (1.2) Promotion ofconsumers and producers undermines composability
- From: Peter Niblett <peter_niblett@uk.ibm.com>
- To: Eric Johnson <eric@tibco.com>
- Date: Tue, 18 May 2010 15:53:50 +0100
Hi Eric
Apologies for not replying earlier,
but I have been travelling, and I won't be able to make today's call.
Rather than giving detailed replies
to you points, there are a few general things that I would like to say.
Firstly, a minor point, I thought the
issue has already been opened, so I am not arguing that point. Since the
main subject of the issue is the composability question, I think we should
focus on that (which is point 1). My reason for listing the other ones
is that you have been raising them in the correspondence, and you draft
change to the spec seems to be tackling them in addition to point 1.
Wiring a producer or consumer to a global
channel does indeed break encapsulation, which I guess could be a composability
concern. However, provided your implementation supports "private"l
channels, you can avoid using global channels - except at the domain level
- and thus you have completely composable components.
If you have three consuming components
in your composite, and you wish to ensure they all receive the same stream
of events, then all you do is to promote all three of them as a single
consumer on the composite (I think Mike has already made this point). The
assembler then either promotes this consumer still further, or connects
it up to a channel. Either way all three consuming components are going
to get the same events.
You also discuss the case where you
want to have composite that contains a producer and consumer connected
to the same logical destination. I assume that this is because one component
wishes to send events to the other (see components 1 and 4 in fig 2.4).
If you also, for some reason wish to have someone else send events to component
4, you just promote its consumer keeping it still connected to the channel,
so it still receives events from component 1. If you want others outside
the composite boundary to be able to receive events from component 1, you
promote its producer. The only issue I can see is one where you promote
component 1's producer and component 4's consumer AND keep them both connected
to the private channel as well. That way there's a risk that some higher
level assembler might connect the promoted producer and consumer to the
same channel thus establishing two routes between the two components. But
I would see this as a strange thing for the assembler of the first composite
to do.
Two other things
1. I'm not happy with the idea of changing
producer + consumer to channel. To me, a producer represents the "port"
that a component uses to emit events, and the consumer is the "port"
it uses to receive them. A channel is a way that events travel between
components. Combining producer/consumer and calling it a channel would
seem to lose this distinction.
2. You said that you didn't like the
idea of direct wiring, because the semantics of pub/sub is different from
point/point communications. That is really my point. If I were able to
create a direct wire between two components, the first of which is emitting
a stream of events and the second of which is receiving them, then it isn't
really pub/sub (or at best it is a very degenerate case). I'd still want
to model the output port on the first component as a producer, because
I might want to use the same component type in a genuine pub/sub pattern,
by wiring it to a channel.
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:
| Peter Niblett/UK/IBM@IBMGB
|
Cc:
| OASIS Assembly <sca-assembly@lists.oasis-open.org>
|
Date:
| 13/05/2010 04:40
|
Subject:
| Re: [sca-assembly] Fw: [sca-assembly-comment]
NEW ISSUE: (1.2) Promotion of consumers and producers undermines composability |
Hi Peter,
On 05/11/2010 04:24 AM, Peter Niblett wrote:
Eric
I have read your correspondence with Dave Booz, and taken a quick look
at your revisions. I have a number of things to ask about that, but first
I would like to understand the issues here.
I think your points relative to the Feb 12 draft can be summarized as
1. Components within a composite can be directly wired to a domain-level
channel (see the example in figure 2-6). As Dave points out, this can be
viewed as breaking encapsulation as there is nothing explicit in the component
types of components D1 and D2 that tells you that this is going on (since
you can't reconfigure it when assembling the composite). You have to look
inside the definitions of composites X and Y to see this, and if there
is a deep nesting of composites you have to look down all the levels.
2. The mechanism of linking up producing and consuming components within
a composite, e.g. in the case shown in figure 2-5, is awkward. You have
to configure the @sources of the consumers and the @targets of the producers
to point to the same channel
Not just awkward - it breaks encapsulation. It hides a critical detail.
3. At the moment channels are either completely private (scoped only within
a single composite), or completely global (when they are in the domain).
There is no mechanism for promoting a channel so that it is visible only
to a given composite and its subcomponents.
4. Domain level channels don't seem to be necessary since we could do the
same thing by binding to JMS topics.
On this last point, you're construing my point as being
overly specific. Any binding could do, not just a JMS binding. UDP,
AMQP, TIBCO Rendevous, Apple's Bonjour are others that I can think of.
We could equally well have an "binding.scaeventing".
Some additional points:
5. Policies
assigned to producers and consumers are likely to need to be the same,
or to align. It makes more sense to assign those policies to a shared
concept of a "channel", rather than treat the producers and consumers
as independent.
6. SCA
already has the means to "break encapsulation" by way of a well
understood pattern - bindings. The existing eventing draft allows
"sources"/"targets" that provide an alternate means
of breaking encapsulation without justifying why an alternate means is
necessary.
7. Channels
have bindings, not producers and consumers. Suppose I have a producer
and a consumer in a composite - on both I "target/source" the
same transport destination, but here's a weirdness - I could put a binding
on both, and perhaps it isn't the same. Does that imply, behind the
scenes, that the runtime has to do automatic bridging from one transport
to the other? That no longer sounds like we're modeling eventing,
but modeling a system in which we hope transport level details can be modeled
as if they don't exist. My gut tells me that hope will be squashed
by an unfriendly reality.
Please correct me if this is wrong.
In "defence" of the OSOA spec, what we were trying to do is
a) Allow true decoupling of event-centric components, so that it is possible
to author a component as a pure consumer and/or producer of events without
knowing how these components are going to be assembled. This means keeping
details of the channels out of the component types. This is the main motivation
for having <producer> and <consumer> elements in the component
type and for declaring filters as part of the consumer (if there's no way
a component can handle a particular kind of event, it should say so)
b) Allow an assembler - if he/she wishes - to define a tight coupling of
components so that they can be wired up without "leakage" of
events outside a composite, and without external events coming into the
composite uninvited. This is needed when you are modelling event processing
applications. This is why we have private channels scoped within components,
as shown in figures 2-4, 2-5 and 2-7.
c) Allow loose binding of components, where producers are not aware of
the identities of the consumers and vice versa, and where there is some
kind of global event distribution mechanism (an event bus if you will)
that spans all application components. This is done by having global channels
at the domain level
d) Provide an abstraction that allows event distribution to be modelled
in a protocol neutral fashion. This is the reason for having channels in
the model at all.
Again, I maintain, as I stated on the conference call, that my proposal
only adds additional use-cases, it does not remove any.
Maybe the confusion is caused by accommodating both b) and c) simultaneously.
Returning to the points
1. It is true that you can do this, see figure 2-6, but you don't have
to. The alternative is to promote the producers and consumers, so they
do become visible at the next level up and then can be wired to a channel
(or promoted further) by the person assembling that composite. That's what
you would do if you were designing libraries of reusable nested event processing
components. On the other hand if you really do have a uniform event bus
concept that spans all your components, we felt it would be unnecessarily
tedious for people to have to do this all the time.
Well, except if my use case is that some of the producers and consumers
from a composite are listening on the same logical destination, and they
want to share that destination outside of the composite, the only way they
can do that is to specify "source" & "target".
At which point, I can no longer compose as freely.
With the proposal I've submitted, I have added the ability to directly
associate producers and consumers, and model that they share the underlying
transport destination, without having to specifically tie that to any "target"
or "source" for that destination. In other words, it preserves
composability without sacrifice.
Further, in my proposal, a binding is associated with a channel, not with
an individual producer or consumer, which means that the additional bullet
point #7 above of having to automatically generate a bridge goes away.
Designers would have to intentionally create a bridge. This
strikes me as an important feature.
2. I agree that this is awkward. I have always favoured being able to wire
a producer directly to a consumer (effectively having an implicit channel).
You should also be able to choose whether you establish this by setting
@target on the producer or @source on the consumer. That same mechanism
could be used if you have an explicit channel, so you could set the @targets/@sources
on the channel to point at the producers/consumer (effectively what Eric
does in his example of figure 2-4) rather than the other way round.
I think wiring directly is a mistake, and implies a different kind of transport.
I think, if you're talking about producers & consumers, you want
to graphically depict that as wiring via an indirection. The semantics
and behavior of publish/subscribe are dramatically different from direct
point-to-point communications, and shouldn't be confused by identical/very
similar graphics.
My proposal has a simple unification. Producers and consumers go
away - components always "wire" to channels when they want to
produce/consume. The difference with my proposal is that channels
are either private to the composite, or promoted.
3. At the moment we accommodate both use cases (completely private or completely
global). Intermediate cases sound interesting, but I am not sure whether
anyone really needs them. Just to be clear on how we'd expect things to
work at the moment... if you look at figure 2-4 you would normally either
wire a producer/consumer (the yellow triangles) to a channel or promote
them. That's what the figure shows. You could promote the consumer for
component 4, in which case it would receive events from the outside AND
events from channel A (which can only have come from components 1 and 2).
One other thing one could consider is allowing the input or output of the
channel (which are in effect producers and consumers themselves) to be
promoted, to allow events from the outside to go directly into channel
A without having to go via components 1 or 2, but again I'm not sure why
that would be useful.
You've fundamentally hit the nail on the head here, perhaps unintentionally.
The notion of completely private or completely global simply isn't
composable.
I think it is fair to turn this question around - why wouldn't I
want to abstractly model and promote the channel that my composite wishes
to send and receive on, rather than be forced to early bind to some notion
of a global "source/target" for where those messages are coming
from. The essential value of an abstract concept of channel is the
model of which events are being sent and received over it, not its name!
4. I think modelling the distribution mechanism is a good thing.
And yet, where do I model a notion of a channel that crosses composite
boundaries, but for which I don't yet have a specific concrete name for
the destination? We model services and references abstractly in this
manner as part of the component type, yet for some reason you seem to be
resistant to including the channel in the component type.
My take on the above:
- You agree that it isn't composable (see your #3), so shouldn't
we open the issue?
- For the notion of promoting channels, I don't see any
problems/objections identified above, except that it is different from
promoting producers and consumers.
- My proposal doesn't remove any use cases/functionality,
and it adds composability
I admit that my proposal
is *not* perfect - it needs work on the artwork, and the policy details
probably need more detail, and perhaps a discussion of channel hopping
(channel bridging), but I do think it adds functionality, and solves problems
that the current draft specifically identifies as areas needing work.
All of this discussion, I note, is in service of the question: should we
open the issue? Seems like you've acknowledge that the current approach
isn't composable. Further, I've provided an approach that covers
additional use-cases, without taking any away, while simultaneously solving
the problems raised by the issue. So maybe we don't take my solution,
but the issue ought to be opened.
-Eric.
Regards
Peter Niblett
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)
Follow up....
I've just posted to the OASIS documents repository a proposal for ASSEMBLY-227.
http://www.osoa.org/jira/browse/ASSEMBLY-227
I posted in PDF and Word format:
http://www.oasis-open.org/committees/document.php?document_id=37272
http://www.oasis-open.org/committees/document.php?document_id=37273
These documents are *not* in anything close to final form:
- OpenOffice did a number of things to slightly mangle the
word document
- We need new pictures to show the new channel promotion
notion. I've included my notion of what it would look like below,
in the hopes that it will help, although I should add that so far within
TIBCO, I've gotten the some disagreement about the proposed artwork.
- I haven't vetted the schema changes.
- Obviously this is still a fork of the current spec, based
off of the copy that Anish started from.
However,
before I spent many hours trying to get everything perfect, I figured I
should at least know whether the intent is even close to acceptable to
the TC.
-Eric.
P.S. My current conception of a channel might look like - see diamond at
the bottom edge of the component.
On 04/09/2010 01:19 AM, Mike Edwards wrote:
Folks,
Forwarding to the main sca-assembly TC list....
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
----- Forwarded by Mike Edwards/UK/IBM on 09/04/2010 09:18 -----
Target: sca-assembly-1.2-spec-wd01.doc
Title: Promotion of SCA consumers and producers undermines composibility
Description:
In the assembly 1.2 WD 01, consumers and producers are identified as part
of the "component type" of a component, whereas "channels"
are limited in scope to the boundaries of a composite. This is contrary
to the rest of SCA, where the indication of the communication between components
surfaces in the component type, currently as a service or reference. When
needed, services or references can establish concrete bindings, but otherwise
communication needs are exposed at the boundary of a composite. In
the case of producers, consumers, and channels, not only can bindings be
applied, but also "targets", which then either hide endpoints
within a composite, or expose them globally as part of the "global
domain."
This makes composition of applications using eventing more difficult.
Further, although producers and consumers can refer to the same target,
this is an awkward way for these two constructs to establish that they
intend to operate on the same "destination". When building
a composite the composite developer may wish for one component to produce
for a channel, and a different component to publish on the same channel,
and then promote the combination of producer and consumer. If the
developer only promotes the consumer, or only promotes the publisher, that
would be misleading to the composites using that component. Perhaps
it is even an error.
Here, then, are two problems:
- "target" channel references are a weak way to
couple the use of the same destination.
- target channel references can be to a domain channel,
thus undermining composability - either by collisions in the naming of
target channels, or by forcing special knowledge of which channels are
used where.
Proposal:
Instead of promoting consumers and producers, promote channels. Move
the filter and eventType information on consumers and producers into the
channel.
-Eric
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]