From: Eric Johnson
[mailto:eric@tibco.com]
Sent: 25 January 2011 05:24
To: OASIS SCA Assembly
Subject: [sca-assembly] Action item: 01-18-2:
Distinction between global and local channels
As per my
action item 2011-01-18-2: "Johnson to propose more
concretely what the different roles of global vs local
channels might be"
In the discussion of ASSEMBLY-250, Peter and I found
ourselves looping back to ASSEMBLY-227. Specifically, I
highlighted a problem with understanding the meaning of a
"channel". Consider that a channel might stand for:
- A (global) logical scope:
//Sales/North America (vs.
//Sales/EMEA, //Sales/APAC). In this scenario (as
exemplified by Oracle presentation at Sept. 2010 F2F), the
ultimate use of JMS might will probably create multiple
JMS destinations.
- A specific binding to an
existing system: Attach a "binding.jms" (assuming we
define how this works) to a particular channel inside of
composite. This specific binding can attach to an
existing use with an existing non-SCA system.
- A bottom-up definition of a
particular "topic" destination, to be late-bound by a
higher-level composite.
Consider the aspects that we (currently)
can tie to a channel:
- policy intents & policy
sets
- a binding
- filters
- events
Further, a channel is defined in two
different ways:
- As part of a composite used
in an implementation
- As part of a composite
deployed directly to the domain - I'm just noticing now
that this needs more desc! ription
(name of a channel is an NCName - so how do I know in the
composite that I'm defining a global domain channel, since
I can't put "//" in the name attribute?).
[MC] Regardless of where it is
defined the semantics are the same, so im not sure why
this is a relevant distinction at this stage.
Case #1: global logical scope -
One problem we've identified with global logical scope is
that it undermines composability (ASSEMBLY-227). For
example, many different components of type
implementation.composite might be deployed to the domain,
and all of them might reference a global domain channel.
Either we're imposing a significant top-down burden on those
components, in that before they can be deployed, they must
adhere to the constrain! ts
applied to the global channel, or we have a myriad different
bottom-up perspectives, and they don't necessarily mesh in
obvious ways.
[MC] Indeed you do need to know
something about the domain, and it does support a top down
model.
For example, in my //Sales/North America channel, I might be
producing information gleaned from public sources about
sales by competitors. I might also be producing information
about internal sales successes, and key information like the
value, which must be kept extremely confidential. Do we i!
ntend
that //Sales/North America encompass both? If not, why not?
[MC] This would be a design
decision. One way to design this at the domain level is to
define event filters that only pass on events of certain
types.
When I go to deploy a component that references a global
domain channel, what if it hasn't been defined? What does
that mean? Must that be an error? Why?
[MC] good question. Two choices
1) reject the deployment or 2) create all undefined
channels
What if the global domain channel is redeployed after some
components that use it have already been deployed? What
does that mean?
[MC] I don’t see global channels
as being special here, though we would have to define
this, and what is possible.
Now, assuming the global domain channel has been defined
& deployed, the problems we face:
Policies: Some deployed components might use the
global channel (a "scope"), and indicate a policy of
confidentiality. Others might not care. Since the actual
implementation can assign these two different scenarios to
different JMS topics, this doesn't seem to be a problem.
But is the policy on a global domain channel actually
meaningful? One hypothetical polic! y intent
I think is of use - something like "jms", or
"apple-bonjour", "tibco-rv", or "amqp". That is, I don't
care to bind to specific JMS details, but I want to indicate
JMS.
[MC] Its still early days on the
policy discussion, but again I think you have to be
careful about design intentions and consequences. A bad
policy design might make any part of a system meaningless.
Binding: I suspect this is utterly useless on a
global domain channel. Why would I want to allow a global
domain channel to bind to a single JMS topic, when I've
defined myriad components that only want to listen for
specific kinds of
events....
[MC] Why not if you want to. If
you don’t want to define a different type of binding.
Filters: Seriously bad - I've defined all sorts of
components that reference the global domain channel, and in
its initial definition it has no filter. Then it gets
redeployed with a filter that blocks some of the events that
used to get through. Conversely, the GDC is already
deployed, but now I go to deploy a component that sends
messages to that channel and those events will be filtered
out. Error or no?
[MC] Be careful what you design.
This is not an architectural error! Design time tools can
help to analyse changes to a system.
Events: Can't really declare which events end up on a
global domain channel. At least not usefully. After they
are *global*.
[MC] No but you can define which
event types a channel will pass on to its consumers, so I
don’t understand the point here.
Conclusion: Glo! bal
domain channels are really a notion of "scope". It makes no
sense to assign most policy intents to them (possible
exception of transport intents). A concrete binding is
likely a mistake. Filters make no sense. Declaring events
makes no sense. In other words, a global domain channel is
merely a scoping label.
[MC] I don’t agree with these
conclusions, since your arguments seem mostly about good
or bad design not about the semantics of what a channel is
and does.
Case #2: A specific binding to an existing system.
This scenario supposes a channel definition within a
composite, where the assembler! puts a
specific binding on the channel.
Very useful - within a composite.
[MC] Why is this very useful.
How did you reach this conclusion?
Policies: In the most general case, policy intents
and policy sets are unlikely to be unenforceable in
practice, because it will be difficult or impossible to
verify that an existing JMS destination meets the
constraints dictated by SCA, since the SCA runtime is not
deploying the destination. We've dealt with this in the
context of existing SCA bindings by punting to the
implementation. Same considerations likely apply here, so
this concern is a wash.
Filters: Not clear what this really
means. Since the existing use of the JMS topic likely sends
messages not modeled in the SCA space, what do event filters
mean? They can't mean filtering out messages for all
recipients - at best only those recipients defined by SCA.
The filtering can only be done once the message is received
by the consumer. Certainly possible to apply filters, but
certainly of odd utility.
Events: Provides incomplete information, but then it
has always been thus.
Case #3: Bottom up definition of a transport concept,
such as a destination
In this scenario, I'm defining an application that delivers
messages via logical placeholders for destinations in the
ultimate transport (such as JMS Topics, or RV subjects). In
my composite, I define one or more "channels" - the
placeholders, if you will - and for each producer or
consumer I connect to them, I want to fully specify which
events I produce or consume.
If the se! nding
and receiving is not limited to my particular composite, I
may want to promote the logical information about the
channel, rather than the producers and consumers separately
- see the diagrams I've drawn with respect to 227 for the
weird cases one might run into.
Policies: Useful, as this constrains how others might
also use a promoted channel, and provides meaningful
information about how the channel should be used.
Filters: Possibly useful for consumers. Unlikely to
be relevant to the channels themselves, as I wouldn't create
a channel in a composite, wire it to producers, and then
block some of those messages from going through.
Binding: Perhaps very useful. Early binding of where
messages should be sent, but sometimes appropriate.
Events: Critical meta-data about what's being sent
and processed via this logical construct. Helps identify
places where producers and consumers might not be talking
the s! ame
details - helps find errors, and further, if promoted past
the edge of the composite, helps identify the purpose of the
logical construct.
[MC] sounds ok
Some Conclusions
Case #1 seems to differ radically from cases #2 & #3.
Perhaps I've explained them poorly above, and I should go
into more detail, or that others see solutions that I don't?
[MC] the semanti! cs of a
channel should be exactly the same. How and why you use
them might be different, but these are design choices.
Contemplating case #1, I wonder why we bother to call the
"global domain channels" channels. They seem like message
scopes. I don't know why we'd require that they exist
before the first producer/consumer that uses them is
deployed.
[MC] so you can to some broad
segmentation of event types, policies and bindings if you
chose. If you don’t chose, there’s always the default
global channe1!
If we assign policies to them, I don't
know what that means. I cannot imagine ever allowing them
to be redeployed with any meaningful changes to policies,
filters, or events, which makes them seem quite static. I
don't know what a binding means for them.
In addition, the naming seems arbitrary. Is "//Sales/North
America" different from "//North America/Sales"?
[MC] no semantics to a name so
this is a design decision.
My suggestion is that we simply don't refer to global domain
channels as channe! ls any
more. For now, let me call them "scopes".
[MC] You really have to define
the semantics of scopes before it’s even possible to
contemplate changing domain channels.
I would want to see a componentType expose the "scopes" that
it uses, either via producers or consumers - whether or not
the producers and consumers on those scopes are themselves
"promoted" is somewhat silly, because by binding to the
scopes, the producers/consumers are promoted.
A scope, it seems to me, is just a collection of names. The
distinction between "//North America/Sales", and
"//Sales/North America" is arbitrary! and
capricious - our systems are difficult enough as it is. So
why not just "sales, north america"
[MC] what is the semantics of a
scope and its collection of names?
In a radical departure from what we've currently got, I
don't see why scopes have a definition at the domain level,
rather they are an emergent property of what has been
deployed. If someone starts putting intents on uses of
"scopes", then what that simply means is that only consumers
and producers with matching intents will get paired up.
[MC] The policy model is in its
infancy wrt channels so this may or may not be a valid
argument.
As for channels, I see those as being useful within a
composite, as they've been defined today. However, as per
the proposals for 227, I want to see it as possible to
expose the information about the defined logical message
source/destination in the component, so that it can be used
by higher up composites, as components are composed.
[MC] Agreed, but this is ! issue
227
Sorry, that turned out to be a lot, but it seems there's a
lot to the discussion.
[MC] Not seeing it I’m afraid.
Most of what you talk about concern design decisions not
core architecture.
-Eric.