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:
OF816D37EE.DCED51F5-ON80257823.00571498-80257823.0057BBD9@uk.ibm.com" type="cite">
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.
OF816D37EE.DCED51F5-ON80257823.00571498-80257823.0057BBD9@uk.ibm.com" type="cite">
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.
OF816D37EE.DCED51F5-ON80257823.00571498-80257823.0057BBD9@uk.ibm.com" type="cite">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.
OF816D37EE.DCED51F5-ON80257823.00571498-80257823.0057BBD9@uk.ibm.com" type="cite">b) on the consumer, which then applies only to that specific consumerUnderstood. No complaints here.
OF816D37EE.DCED51F5-ON80257823.00571498-80257823.0057BBD9@uk.ibm.com" type="cite">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.
OF816D37EE.DCED51F5-ON80257823.00571498-80257823.0057BBD9@uk.ibm.com" type="cite">
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.
OF816D37EE.DCED51F5-ON80257823.00571498-80257823.0057BBD9@uk.ibm.com" type="cite">
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: mike_edwards@uk.ibm.com
From: Eric Johnson <eric@tibco.com> To: OASIS SCA Assembly <sca-assembly@lists.oasis-open.org> 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:Further, a channel is defined in two different ways:
- policy intents & policy sets
- a binding
- filters
- events
Case #1: global logical scope -
- 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?).
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
