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 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.