Hi Peter,
On 05/11/2010 04:24 AM, Peter Niblett wrote:
OF2A680098.9414579C-ON80257720.003672D3-80257720.003EA5F8@uk.ibm.com"
type="cite">
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.
OF2A680098.9414579C-ON80257720.003672D3-80257720.003EA5F8@uk.ibm.com"
type="cite">
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:
- 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.
- 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.
- 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.
OF2A680098.9414579C-ON80257720.003672D3-80257720.003EA5F8@uk.ibm.com"
type="cite">
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.
OF2A680098.9414579C-ON80257720.003672D3-80257720.003EA5F8@uk.ibm.com"
type="cite">
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.
OF2A680098.9414579C-ON80257720.003672D3-80257720.003EA5F8@uk.ibm.com"
type="cite">
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.
OF2A680098.9414579C-ON80257720.003672D3-80257720.003EA5F8@uk.ibm.com"
type="cite">
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!
OF2A680098.9414579C-ON80257720.003672D3-80257720.003EA5F8@uk.ibm.com"
type="cite">
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.
OF2A680098.9414579C-ON80257720.003672D3-80257720.003EA5F8@uk.ibm.com"
type="cite">
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
|