Wiring new message-channel implementation into SI

[grenner]

I would like to implement a new PollableChannel implementation, but how could I bind it into the framework. This question might be better placed in the "Reference manual feedback" thread, since the reference manual contains litte about the beans and their wirings behind the (xml configuration) curtain... and debugging is not always a pleasure

Back to my use-case: my messages has dependencies on each other; processing order is defined by some timestamp-segment in the filename. Each file represent an event of an item in a DB ("new/update/delete item"). It can happen that an update arrives for such an item which is not in the DB at that time (because some asynch external system processes (and stores) the items). In this case I have to "delay" the update, more percisely have to delay all updates for that item and maintain the order of the delayed update files! So have to delay following updates irrespectively of the actual state of the DB item if a preceding update is currently beeing delayed!
(The original order can seamlessly be enforced by a custom comparator in the fileSource)
So thats why I've considered writing a custom MessageChannel, maintaining a list of PriorityQueues for each related delayed messages, and one queue for the 'normal', undelayed msgs. An interceptor in the external system reply queue might toggle enablement state of the related PriorityQueue.
Is it reasonable solution, or I missed something?
Lets suppose I write such a channel implementation, but how could i wire it into the SI infrastructure?

thx,
Gabor

[Mark Fisher]

My initial reaction is that you should not need to implement a new channel type. In fact, it sounds like you are trying to put too much responsibility into the channel. Consider this: a channel's primarily role is to decouple producers and consumers. There are a number of ways that can be done - point-to-point or publish/subscribe, synchronous or asynchronous, pollable or subscribable (for event-driven consumers) - AND we already handle all of those options within Spring Integration. So, I would like to suggest that what you are trying to accomplish does not necessarily belong IN the channel implementation. In fact, the behavior you are describing sounds to me like consumer-side responsibilities. Have you looked at resequencer, delayer, and aggregator components to consider how they might help you realize the use-case?

[grenner]

You are right, i was able to implement the desired use-case employing a delayer and a resequencer with custom correlation- and release-strategy. Yes, it is too much responsibility for a channel. Thanks for the suggestion!
Gabor