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

[Eric Johnson <eric@tibco.com>]

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:

OFBD238C97.A9B1732F-ON80257815.0038F300-80257815.003998B6@uk.ibm.com" type="cite">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