Perhaps the most useful email to respond to in this thread, because
you circle back to the key question.
On 1/25/11 8:05 AM, Mike Edwards wrote:
In my opinion, you are trying to
a distinction between to Global channel and a Private channel
exist in the current model.
I argue that the distinction does exist, precisely because the
"global domain channel" has an existence and life-cycle separate
from the producers and consumers that use it. That is in the spec,
and I'm trying to highlight the consequences.
In my opinion, all channels have
same functionality - the only real difference between global
is the set of component producers
component consumers that can be connected to them.
That's why I went to highlighting the specific features of a
channel, and the specific scenarios.
I don't think we're expecting them to have the same functionality.
We've not answered the question as to what policies mean on
channels, so it's hard for me to agree that they actually have the
same meaning on global domain channels and local channels. In my
scenario, producers & consumers could specify intents while
using a global domain channel, and that doesn't imply that
everyone is using the same intents for that channel. Is that a
valid use case? I think so. If you don't, perhaps you can describe
an alternate way of thinking about the problem?
I cannot see why it would *ever* make sense to put filters on a
global domain channel. They are, after all, global, and if they
happen to filter out events unexpectedly, some consumers will simply
never see messages they were expecting to see. Sharp person that
you are, I can imagine you saying "but then the act of contributing
it to the domain should catch that error." OK, fine, but the spec
doesn't say that. Neither does the spec say anything about
redeploying an existing global domain channel - perhaps updating a
filter. Sure, I can make it more lenient, but can I make it
stricter? Can I break what is deployed? If not, why not? All
these interesting questions, and I think they're all a distraction -
filters simply shouldn't be defined for global domain channels. If
you've got an implementation that thinks there's something useful to
do here, that sounds great, and let's leave the door open for
implementations to do that.
type="cite">In all cases, the
Channel is the means
by which a specific community of producers and consumers is
principle, all the
events from all of the producers
to all of the consumers. Filters can modify this - and filters
be expressed in two locations
depending on the aim of the
a) on the Channel, which then
to all consumers
And yet, this makes no sense, as I see it, when applied to global
type="cite">b) on the consumer,
which then applies
only to that specific consumer
Understood. No complaints here.
type="cite">There is no implied
and the naming of a Channel is only intended to provide identity
The name of a
Channel has no other meaning and
no direct link to event types (or to "Topics" either, for that
I'm saying something different. I agree, channels don't imply
scope. Rather, they define it.
I recognise that this may not be
view of the current spec - but it is mine. There may be
in the spec but it does
not have the implications that
Hmmm. Whereas I think I'm just interpreting the model as it
currently stands. Except we don't know what certain things mean
(example, policies), haven't defined other areas closely, and leave
a broad swath of interpretation elsewhere, so I can either highlight
that, or make my own interpretation. I've done both, and you don't
seem to like what I conclude.
Which is my point. We need to fix things in the spec.
|| Mail Point
As per my action item 2011-01-18-2: "Johnson to
more concretely what the different roles of global vs local
In the discussion of ASSEMBLY-250, Peter and I found ourselves
back to ASSEMBLY-227. Specifically, I highlighted a problem
understanding the meaning of a "channel". Consider that
a channel might stand for:
(global) logical scope: //Sales/North America (vs. //Sales/EMEA,
In this scenario (as exemplified by Oracle presentation at Sept.
the ultimate use of JMS might will probably create multiple JMS
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
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
Further, a channel is defined
in two different ways:
- policy intents & policy sets
- a binding
#1: global logical scope -
- As part of a composite used in an
- As part of a composite deployed directly to
- I'm just noticing now that this needs more description
(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
One problem we've identified with global logical scope is that
composability (ASSEMBLY-227). For example, many different
of type implementation.composite might be deployed to the
domain, and all
of them might reference a global domain channel. Either we're
a significant top-down burden on those components, in that
can be deployed, they must adhere to the constraints applied to
channel, or we have a myriad different bottom-up perspectives,
don't necessarily mesh in obvious ways.
For example, in my //Sales/North America channel, I might be
information gleaned from public sources about sales by
I might also be producing information about internal sales
key information like the value, which must be kept extremely
Do we intend that //Sales/North America encompass both? If not,
When I go to deploy a component that references a global domain
what if it hasn't been defined? What does that mean? Must that
be an error? Why?
What if the global domain channel is redeployed after some
use it have already been deployed? What does that mean?
Now, assuming the global domain channel has been defined &
the problems we face:
Policies: Some deployed components might use the global
"scope"), and indicate a policy of confidentiality. Others
might not care. Since the actual implementation can assign
two different scenarios to different JMS topics, this doesn't
seem to be
a problem. But is the policy on a global domain channel
meaningful? One hypothetical policy intent I think is of use -
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.
Binding: I suspect this is utterly useless on a global
Why would I want to allow a global domain channel to bind to a
topic, when I've defined myriad components that only want to
specific kinds of events....
Filters: Seriously bad - I've defined all sorts of
reference the global domain channel, and in its initial
definition it has
no filter. Then it gets redeployed with a filter that blocks
of the events that used to get through. Conversely, the GDC is
deployed, but now I go to deploy a component that sends messages
channel and those events will be filtered out. Error or no?
Events: Can't really declare which events end up on a
channel. At least not usefully. After they are *global*.
Conclusion: Global domain channels are really a notion of
It makes no sense to assign most policy intents to them
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.
Case #2: A specific binding to an existing system.
This scenario supposes a channel definition within a composite,
assembler puts a specific binding on the channel.
Very useful - within a composite.
Policies: In the most general case, policy intents and
are unlikely to be unenforceable in practice, because it will be
or impossible to verify that an existing JMS destination meets
dictated by SCA, since the SCA runtime is not deploying the
We've dealt with this in the context of existing SCA bindings by
to the implementation. Same considerations likely apply here,
this concern is a wash.
Filters: Not clear what this really means. Since the
use of the JMS topic likely sends messages not modeled in the
what do event filters mean? They can't mean filtering out
for all recipients - at best only those recipients defined by
The filtering can only be done once the message is received by
Certainly possible to apply filters, but certainly of odd
Events: Provides incomplete information, but then it has
Case #3: Bottom up definition of a transport concept, such
as a destination
In this scenario, I'm defining an application that delivers
logical placeholders for destinations in the ultimate transport
JMS Topics, or RV subjects). In my composite, I define one or
"channels" - the placeholders, if you will - and for each
or consumer I connect to them, I want to fully specify which
events I produce
If the sending and receiving is not limited to my particular
I may want to promote the logical information about the channel,
than the producers and consumers separately - see the diagrams
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
Filters: Possibly useful for consumers. Unlikely to be
to the channels themselves, as I wouldn't create a channel in a
wire it to producers, and then block some of those messages from
Binding: Perhaps very useful. Early binding of where
should be sent, but sometimes appropriate.
Events: Critical meta-data about what's being sent and
this logical construct. Helps identify places where producers
consumers might not be talking the same details - helps find
further, if promoted past the edge of the composite, helps
purpose of the logical construct.
Case #1 seems to differ radically from cases #2 & #3.
I've explained them poorly above, and I should go into more
that others see solutions that I don't?
Contemplating case #1, I wonder why we bother to call the
domain channels" channels. They seem like message scopes.
I don't know why we'd require that they exist before the first
that uses them is deployed. If we assign policies to them, I
know what that means. I cannot imagine ever allowing them to be
with any meaningful changes to policies, filters, or events,
them seem quite static. I don't know what a binding means for
In addition, the naming seems arbitrary. Is "//Sales/North
different from "//North America/Sales"?
My suggestion is that we simply don't refer to global domain
channels any more. For now, let me call them "scopes".
I would want to see a componentType expose the "scopes" that
it uses, either via producers or consumers - whether or not the
and consumers on those scopes are themselves "promoted" is
silly, because by binding to the scopes, the producers/consumers
A scope, it seems to me, is just a collection of names. The
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"
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
of what has been deployed. If someone starts putting intents on
of "scopes", then what that simply means is that only consumers
and producers with matching intents will get paired up.
As for channels, I see those as being useful within a composite,
been defined today. However, as per the proposals for 227, I
to see it as possible to expose the information about the
message source/destination in the component, so that it can be
higher up composites, as components are composed.
Sorry, that turned out to be a lot, but it seems there's a lot
to the discussion.
Unless stated otherwise
IBM United Kingdom Limited - Registered in England and Wales
Registered office: PO Box 41, North Harbour, Portsmouth,