Announcement Announcement Module
No announcement yet.
Filter or Router needed? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Filter or Router needed?


    Quick question.

    If I need to perform a task when a filter drops a message can I do that using a filter or do I need to use a router?

    From what I can tell a filter simply drops rejected messages and you cannot do anything with them. Obviously I can do something with the rejected messages within the filter itself but I'm presuming that should be avoided to avoid coupling of concerns.

    It would be useful to send them to a rejected queue (just like the error queue functionality) so that they can be acted upon. Or maybe there's something like this already? Would a channel interceptor fulfil this role and is that how it is intended to be done?

    I guess the intrinsic difference in that case between a filter and a router is that a router can send to any number of destinations whereas a filter can only accept or reject. I've had a look at the EIP book to see what they say about these two patterns.

    Last edited by Narada; Feb 3rd, 2009, 06:06 AM.

  • #2
    Currently, this would be easiest with a router. However, can you describe the use-case a bit more - just in abstract terms? I'm wondering if we should add a 'discardChannel' property to the filter...


    • #3
      Sure Mark.

      (By the way I have converted my filter to a router for the time being.)

      The use case is quite simple. Basically I have an authorisation service which either accepts or rejects messages based on complex criteria and processing. I need to process both accepted and rejected messages and be able to define how rejected messages progress in the overall flow. In this case I want rejected messages to go to a service activator or outbound channel adapter. However there are only two states: accept or reject. Therefore it is analogous to the two states of a filter action - relay or drop which in turn is analogous to a true/false use-case.

      Below I discuss the pros and cons to let you know what I'm thinking.

      • It would be similar to and consistent with the provision of the errorChannel attribute that already exists.
      • It would allow an extra hook for generic handling of dropped messages without the use of an interceptor or a router.

      • A two state filter has a small syntactic (but not semantic) overlap with a router.
      • It may blur the line as to which of the two to use (although I don't think it will).

      Overall I would say that the reason that the addition of a discardChannel is compelling is that it allows the flow definition to be more semantically correct and more descriptive of the function it fulfills. If it really is two-state filtering that you are doing then it would be nice to call your endpoint a filter rather than a router.

      For example - for an accept/reject use case I would use a filter with a discard channel. For a hotDrink/coldDrink use case I would use a router as this is not a boolean use-case. For a solids/liquids/gases use-case I would use a router as there are more than two options. This is what I mean regarding making my flow definition semantic and intuitive to the reader.

      Maybe I overdid my explanation a little but I hope it was helpful.
      Last edited by Narada; Feb 3rd, 2009, 08:27 AM. Reason: Added additional comment in italics.


      • #4
        Interesting use case, thanks for the detailed explanation! I'll oppose your argument.

        In my opinion the main reason for a filter to exist is to be able to silently drop messages. If you turn on the throwExceptionOnRejection flag you can send messages to an error channel, if you want to call that "discardChannel" that is of course fine.

        Adding a mode of operation to do boolean routing is an (unneccessary) specialization of the router and not of the filter in my opinion.

        If you use a filter with an error channel or a router should be based on the fact if a rejection is exceptional/unexpected/erronous or if it is part of the expected business logic. Filters are meant for things you don't want to process in your normal flow.


        • #5
          Iwein. Thanks. After reading your comment I realised you are absolutely right. I also had a look at the filter section of the EIP book. There they make a mention of a null channel but I guess, given the definition of a filter, there shouldn't be a handle to it. There is also a boolean routing example given in there which is implemented using a publish/subscribe channel broadcasting to a widget consumer and gadget consumer but each preceded by a filter which drops the incompatible type. However this is far more complex than just using a router! I changed my filters to routers where appropriate. Thanks again. With these patterns I am finding at least initially that it takes some dwelling upon to arrive at an endpoint type or a combination of them to use for a given flow as there are usually a number of ways of implementing a given flow.


          • #6
            Originally posted by Narada View Post
            With these patterns I am finding at least initially that it takes some dwelling upon to arrive at an endpoint type or a combination of them to use for a given flow as there are usually a number of ways of implementing a given flow.
            Finding the right solution to a complex problem, not just one that works, that's what it's all about. Canned solutions distract you in this process, and I think you've just proven that SI doesn't.