Hi Mike,
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:
Eric,
In my opinion, you are trying to
draw
a distinction between to Global channel and a Private channel
that simply
does not
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
the
same functionality - the only real difference between global
channels and
private channels
is the set of component producers
and
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.
In all cases, the
Channel is the means
by which a specific community of producers and consumers is
formed. In
principle, all the
events from all of the producers
go
to all of the consumers. Filters can modify this - and filters
can
be expressed in two locations
depending on the aim of the
assembler:
a) on the Channel, which then
apply
to all consumers
And yet, this makes no sense, as I see it, when applied to global
domain channels.
b) on the consumer,
which then applies
only to that specific consumer
Understood. No complaints here.
There is no implied
"scope"
and the naming of a Channel is only intended to provide identity
and uniqueness.
The name of a
Channel has no other meaning and
has
no direct link to event types (or to "Topics" either, for that
matter)
I'm saying something different. I agree, channels don't imply
scope. Rather, they define it.
I recognise that this may not be
your
view of the current spec - but it is mine. There may be
deficiencies
in the spec but it does
not have the implications that
you draw
out below.
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.
-Eric.
Yours, Mike
Dr
Mike Edwards
Mail Point
146, Hursley
Park
STSM
Winchester,
Hants SO21
2JN
SCA
& Services
Standards
United
Kingdom
Co-Chair
OASIS SCA
Assembly TC
IBM
Software Group
Phone:
+44-1962
818014
Mobile:
+44-7802-467431
(274097)
e-mail:
From:
Eric Johnson
<>
To:
OASIS SCA Assembly
<>
Date:
25/01/2011 05:32
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:
1. 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.
2. 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.
3. 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 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
attribute?).
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 constraints applied to
the global
channel, or we have a myriad different bottom-up perspectives,
and they
don't necessarily mesh in obvious ways.
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 intend that //Sales/North America encompass both? If not,
why
not?
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?
What if the global domain channel is redeployed after some
components that
use it have already been deployed? What does that mean?
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 policy 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.
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....
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?
Events: Can't really declare which events end up on a
global domain
channel. At least not usefully. After they are *global*.
Conclusion: Global 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.
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.
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 sending 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 same details - helps find
errors, and
further, if promoted past the edge of the composite, helps
identify the
purpose of the logical construct.
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?
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. 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"?
My suggestion is that we simply don't refer to global domain
channels as
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
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"
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.
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.
Sorry, that turned out to be a lot, but it seems there's a lot
to the discussion.
-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
