Re: [sca-assembly] Action item: 01-18-2: Distinction between global andlocal channels

[Peter Niblett <peter_niblett@uk.ibm.com>]

Hi Eric

Thanks for this helpful set of thoughts.
I have put some responses in.. I started out just by commenting on what
I think the current spec draft says and doesn't say.. but further on down
it turns into my own thoughts.

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:      
 OASIS SCA Assembly
<sca-assembly@lists.oasis-open.org>
Date:      
 25/01/2011 05:25
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). 
<pn> I don't think the draft permits
/ inside the name, see your comment about NCNames</pn>In
this scenario (as exemplified by Oracle presentation at Sept. 2010 F2F),
the ultimate use of JMS might will probably create multiple JMS destinations.
<pn>There's nothing in the spec that
requires multiple JMS Destinations. You might be able to use one JMS Destination
to implement more than one channel if there's appropriate additional filtering
(though I wouldn't recommend doing this)</pn>
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.<pn>
I don't understand the difference between a "topic destination"
and a "logical scope". Do you mean the ability to exchange messages
between two separate composites by having them use the same channel? At
the moment the spec permits this if the channel exists at domain level
and both composites wire to that global channel. Or are you suggesting
that if two composites use local channels which happen to have the same
name then events should flow between them? That is definitely not in the
spec at the moment  - indeed the official name for a local channel
is "private channel", which is intended to suggest just that.
 </pn>
Consider the aspects that we (currently) can tie to a
channel:

• policy intents & policy sets
• a binding
• filters
• events <pn> what do you mean by "events" here? You can attach event type filters, but they are just a kind of filter.

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?).<pn> You don't need any special syntax to make the channel global this - you just put it in a composite that you deploy directly to the domain, and that automatically gives it a URI that starts //.  What you don't seem to be able to do is to specify a channel name (like your earlier examples) that has a URI with multiple / separated elements in it.</pn>

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? <pn> at the moment it's your
choice. You can define one channel (and use filters to segregate the information)
or two separate ones. I think your issue here is that you want some 

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? <pn> The spec
explicitly allows producers and consumers to be unconnected (though interestingly
the description of source and target says that they are lists of one or
more URIs), but I couldn't say anything about what happens if they are
wired to a non-existent channel. </pn>

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. <pn>
We haven't really talked about policies yet, but doesn't this give you
a way of asserting a policy that applies to all users of the channel? Isn't
it better to do this once on the channel, rather than in all the producers
and consumers? </pn>

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....<pn> Similarly,
if I want to map the channel to a JMS topic, so that applications outside
SCA can send/receive, then the global channel gives me a single place where
you can do this. Is there a reason why we would think this is a bad thing
to allow? </pn>

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?<pn>
What we are touching on here is whether the channel should just provide
a venue that producers and consumer attach to, or whether it also defines
the content that a consumer receives if it connects. Many event distribution
systems are strongly typed, and permit only a single event type per channel
- indeed some have a 1-1 identification of event type with channel. So
we have filters on channels to allow people to follow that model if they
wish. It also means that they don't need to remember to code filters on
their consumers (so the answer to your question is "no error").
If you adopt this model then of course you have to be careful when you
change the filters on your channels - just like you have to do when changing
the interface implemented by an Object in an OO language.</pn>

Events: Can't really declare which events end up on a global domain
channel.  At least not usefully.  After they are *global*.<pn>
As above, I don't know what you mean by "events" here </pn>

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. <pn>
I assume you mean a channel local to a composite used in an implementation.
These are by definition private channels, and so you shouldn't be able
to bind them to an existing JMS destination at all. This removes the problems
that you mention below </pn>

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

 <pn> To my
mind, you can only do this (today) using global channels, and since these
destinations lie outside SCA that doesn't sound unreasonable to me. So
isn't this the same as case #1 ? </pn>

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?  <pn>
My interpretation of #2 and #3 seems to differ from yours, so I have #1
and #3 being the same, and #2 somewhat different </pn> 

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.

<pn> Well I would use #1 to do the binding
to the outside world, which makes it more than scope </pn> 

In addition, the naming seems arbitrary.  Is "//Sales/North America"
different from "//North America/Sales"? <pn>
We punt on this at the moment, by leaving naming to the user, and we don't
impose/allow any hierarchical names. Topic based pub/sub systems often
do have hierarchical topic namespaces, and getting the hierarchy right
is a genuine challenge for application developers </pn>

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.

<pn> Ok, I think I see what you mean
by "scopes" now.. it's a kind of non-hierarchical categorisation
of the events that can flow in the system (topics if you will), but that
raises a lot of questions, which will take us back round in circles if
we aren't careful..

i) What's the relation between these topics
and event types?
ii) Is there any overlap between topics? For
example does "north america" include "sales, north america",
or the other way round, or not all ?
iii) Can I apply policies at a topic level,
or do I have to mark up all the producers and consumer?
iv) Can I segregate the producers/consumers
using a single topic into different groups, or does every consumer associated
with a topic get all events produced by any producer associated with that
topic? 

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