Announcement Announcement Module
No announcement yet.
Rounting Slip pattern Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Rounting Slip pattern

    Hi everyone,

    I need to implement the routing slip pattern. I cannot figure out how can I do it with the standard SI schema. I'm afraid this is impossible with the current set of schema elements or may be I'm wrong?
    Last edited by ajones; Jun 25th, 2009, 04:53 AM.

  • #2
    Can you describe your use case a bit? I'm wondering first how you are planning to define channels and how much variance you will have in the routing-slips that would be provided on the original request Messages.

    We are planning to add support for Routing Slip in 2.0, so the reason I ask is twofold: 1) interest in an actual use-case 2) considering interim solutions.


    • #3
      We have the banking application that a teller uses for serving a client payments. The server logic of the application uses external services to authorize card operations and replicate payments into systems of different partners and corporate clients. A concrete set of external services through a payment must pass depends on its content. Moreover a passing order may be important and may depend on a payment content too.

      Suggest, each external service can be presented by a service activator that has its own unique input channel. The conrete set of external services can be determined by the transformer that enriches the message header with the object representing routing slip. This object should contain the sequential list of channels through which the payment message must pass. The routing slip object can be invalidated if a service makes decision to stop processing. The first service in a chain determined by a content- based router. Each next service analyses the routing slip containing in the message header and resolves the next output channel. If the message has passed through all the route or one has broken then a service sends reply to its output channel, if no such, then to that containing in the message header.

      So we can implement above solution by adding a routing slip object to a message header and a kind of service activator with routing logic to the standard set that we already have in SI.
      Last edited by ajones; Jun 25th, 2009, 07:26 AM.


      • #4
        I have first successful results of implementing Routing Slip with the standard set of SI elements.

        The solution includes such building blocks:

        public class RoutingSlip<E> {
            public static final String HEADER_NAME = "routing_slip";
            private Queue<E> route = new LinkedList<E>();
            public void add(E channel) {
                if (route.contains(channel)){
                    throw new IllegalArgumentException("Routing slip is already contains channel: " + channel);
            public E pollNext(){
                return route.poll();
            public void invalidate(){
        public class SampleSlipRouter {
            public Object route(Message<?> message){
                RoutingSlip<String> slip = (RoutingSlip) message.getHeaders().get(RoutingSlip.HEADER_NAME);
                String nextChannelName = slip.pollNext();
                if (nextChannelName == null){
                    return message.getHeaders().getReplyChannel();
                return nextChannelName;
        The typical configuration looks like this:

        <router input-channel="entryChannel" ref="slipRouter"/>
        <chain input-channel="fooServiceChannel">
          <service-activator ref="fooService" method="processWithReply"/>
           <router ref="slipRouter"/>
        <chain input-channel="barServiceChannel">
          <service-activator ref="barService" method="processWithReply"/>
           <router ref="slipRouter"/>
        <beans:bean id="slipRouter" class="com.pb.biplane.integration.spring.SampleSlipRouter"/>


        • #5
          That looks *very* nice considering you're taking advantage of a yet-to-be-implemented feature!

          This is pretty similar to what I had in mind, but of course when we provide the official support in 2.0, we should make it even easier to configure... less explicit references to the routing-slip somehow.

          I am really looking forward to hearing more about your experience with this. For example, if you find other scenarios beyond routing as-planned and short-circuiting. So, please do keep us posted here.