Re: Issue 250 - autowire, underlying the 227 question.

Our last conference call help me consolidate my thoughts on this
    one.

    

    I see a matrix of possibilities:

    

    For implementations that choose to map "channel" to "Destination",
    autowire helps, because it eliminates the need to define the
    individual channels - it lets the implementation do the work for the
    assembler.  Without autowire, I run the risk of mis-connecting.

    

    For implementations that merely use "channel" as a scoping mechanism
    (in which case, shouldn't we call it "eventScope"?), what's the
    likelyhood that 80% of the composites will only really need a single
    channel?  That is, the composite *is* the scope.  If that's the
    case, what good comes of forcing the assembler to define the
    channel, and then have every component producer/consumer to wire to
    that single channel?

    

    What I see now is that this issue highlights an underlying problem
    with channels as we've discussed them.  What they really amount to
    is a scoping mechanism with constraints (where the constraints are
    policies and event types).  However, my understanding from what I've
    heard about the way customers deploy JMS implementations, customers
    carefully manage the deployed topics and queues.  In the latter
    environment, if you don't associate channel to "Destination" the
    assembler cannot design around one of the most critical aspects of
    the messaging infrastructure, namely the scarce resource of
    destinations.

    

    So here I am, building a composite, and I want to, from the bottom
    up discover precisely how many topics I need in order for my
    application to deploy.  If channels are merely scopes, I have *no*
    way to do that.

    

    So here's a radical thought.  We split the notion of channel into
    two parts: the notion of "eventScope" and the notion of
    "destination."

    

    Destinations get bindings, whereas scopes merely have intents for
    bindings.  I think this split solves a number of conceptual
    difficulties.

    

    -Eric.

    

    On 1/11/11 2:29 AM, Peter Niblett wrote:
    Eric
      

      

      I don't think that the fact that
        something
        has been defined for service/references necessarily means we
        have to have
        it for events. We already have indirection between the event
        producers
        and consumers via channels, so I would like to explore what the
        problem
        is with channels.
      

      

      In your description of 250, you
        indicate
        that some sort of scoping mechanism is required, to avoid a
        complete free
        for all - but isn't that just what channels are intended for? If
        you want
        free exchange of events between any producer and consumer you
        just attach
        them to a global channel - for example the default domain
        channel which
        is provided for exactly this purpose. If you want to restrict
        the scope
        to the local composite, you attach them to a local channel.  
      

      

      Is the issue here that you see a
        need
        for scopes somewhere in between these two extremes?  This,
        incidentally,
        is something I think also underlies the 227 question.
      

      

      Regards
      

      

        Peter Niblett

        IBM Senior Technical Staff Member

        Member of the IBM Academy of Technology

        +44 1962 815055

        +44 7825 657662 (mobile)

        

      
      

      

      
      

        

        
      
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