[3.4.1][3.5 M1][CORE] Dynamic Round Robin Router

PM Use Cases: Registry PRD Jira: http://www.mulesoft.org/jira/browse/MULE-6918

Motivation / Context

Mule has a variety of message routers that includes choice, all, round-robin and first-successful. However, all of these routers require the routes to use, or conditions under which they should be used, to be configured at design time.

Derived from a requirement from the Service Registry to support dynamic lookup of endpoints, a new set of dynamic routers was implemented in Mule 3.4.0 which included a dynamic-all and a dynamic-first-successful router. Both of which have the capability to have routes configured on runtime.

This story addresses the inclusion of a new dynamic router: the dynamic round robin. This processor is similar to the round robin router but it will not be restricted to be configured at design time and will be part of the dynamic router set along with the dynamic all and the dynamic first successful.

Use cases

• As a user I want to be able to configure a round robin router with routes resolved dynamically at runtime.
• As a user I want to be able to identify the route resolver and keep an iteration state based on the router identity. For example: In the Service Registry we do a round robin based on the endpoints resolved according to a given contractId. This contractId is an expression in the route resolver which value might vary with each invocation. I want the round robin to keep a state for each contractId.

Design

The dynamic round robin is going to be a new Dynamic Route Resolver, and as such, needs to implement the DynamicRouteResolver interface. Since we also want to be able to provide an identifier for the route resolver, and to avoid backwards compatibility, a new IdentifiableDynamicRouteResolver interface is provided. This interface extends the DynamicRouteResolver interface, adding a new method:

String getRouteIdentifier(MuleEvent event) throws MessagingException;

This capability, however, is not a requirement and a DynamicRouteResolver can be configured. The DynamicRoundRobin message processor is going to rely on the DynamicRouteResolverAdapter, which is going to provide a default identifier if the route resolver is not an IdentifiableDynamicRouteResolver.

The RoundRobinRoutingStrategy will be responsible for implementing the round robin logic and keeping the iteration state. It extends the AbstractRoutingStrategy Mule class, and as such, provides an implementation for the route method.

The XML configuration is similar to the existing dynamic-first-successful and dynamic-all message processors:

    <spring:bean id="beanRouteResolver" class="org.mule.test.routing.CustomRouteResolver"/>

    <flow name="dynamicRoundRobin">
        <dynamic-round-robin>
            <custom-route-resolver ref="beanRouteResolver"/>
        </dynamic-round-robin>
    </flow>

The behavior of the dynamic round robin routing strategy when the list of message processors is null or empty, is to throw a RoutePathNotFoundException. This is the same behavior the current MulticastingRoutingStrategy implements.

Risks

No risks

Mule Studio Impact

The dynamic routers are only provided in Studio through the Service Registry component named: Dynamic Router. The Routing Strategy combo will have to include the round robin strategy along with the existing two: First Successful and all. The Service Round Robin checkbox will have to be removed as well because that logic is now extracted to its own dynamic router instead of being contemplated in the route resolver as it was before (this caused many inconsistencies)

This task is addressed in the following Jira: http://www.mulesoft.org/jira/browse/STUDIO-3403

Devkit Impact

None

MMC Impact

None

CH Impact

None

Service Registry Impact

It will impact the Service Registry agent that currently is holding the round robin logic inside the lookup components. This logic will now be extracted to a new routing strategy, therefore, the service registry lookup route resolver will need to only provide a route resolver identifier, using the new interface. This will also affect the use of the new agent with Mule version 3.4.0.

This task is addressed in the following Jira: http://www.mulesoft.org/jira/browse/HABITAT-856

Migration impact

None in Mule. It will only impact the service registry since the serviceRoundRobin attribute will no longer ve valid.

Documentation Impact

It will impact the service registry's dynamic lookup documentation