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

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

Eric

One point of possible confusion in last
week's discussion concerns what gets autowired to what.

I had imagined that you were proposing
that we still had channels that provided the decoupling between producers
and consumers - and that the autowiring was just a convenience for attaching
producers and consumers to an appropriate channel.  From reading your
email, I see now that you would like to eliminate the need for channels
altogether and have producers directly autowired to appropriate consumers,
where "appropriate" I guess means "event types match".

In the current spec, a channel is the
mechanism that is used to decouple producers from consumers (as you may
recall, I am in favour of allowing producers to be directly connected to
consumers without and explicit channel, but that's for the opposite use
case to yours - one where you want to force a strong coupling between a
producer/consumer pair - and so that's not relevant to this discussion).
So at present events are delivered to consumer only if three conditions
are satisfied

i) The producer and consumer are using
the same channel
ii) The event satisfies any filter conditions
imposed by the consumer 
iii) The event satisfies any filter
conditions imposed by the channel

So if you have a single channel with
no filter conditions, all producers and consumers wired to that channel
and event type filters on all your consumers, then the behaviour you get
is similar to what you would describe as autowire with global scope. We
provide a default domain level channel that does this.

If you have more than one channel, again
with no filters on these channels, then again, the effect of the channel
is to autowire all the producers and consumers associated with that channel.
So these channels perform the scoping function. Your second paragraph is
suggesting that it would be simpler for users if each composite has a corresponding
default channel. This could then be used to meet Danny's isolation / maintenance
use case.

I am not sure exactly what you mean
by the concept of "destination". I assume you are thinking of
JMS Topics here. This makes things more complex, as different JMS providers
implement JMS Topics in different ways - for example IBM implementations
allow topic wildcard matching where you can publish a message on one topic
and receive it on a different one, provided the receiving topic contains
the publishing one. In this kind of pub/sub users do spend some time designing
their topic hierarchy in the manner you discuss.  I would open to
formalizing this kind of matching using the existing filter mechanism (i.e.
match on topic in addition to matching on event type), but I think we would
need a different issue to discuss that.

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:      
 Peter Niblett/UK/IBM@IBMGB
Cc:      
 sca-assembly@lists.oasis-open.org
Date:      
 18/01/2011 01:29
Subject:    
   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

---

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