The service framework in Mule has always existed for building integration solutions. The design is simple and highly scalable: 1) messages flow in on a channel to an inbound endpoint, 2) transformations and filters are applied (if necessary), 3) the service component processes the messages and, finally, 4) the outbound router sends them on their way to the desired outbound endpoint (again, applying any transformations or filters as necessary). Using this basic concept, many integration patterns can be solved, and since it is based on a SEDA architecture, when processing is asynchronous, Mule ensures high performance and scalability.
Mule Service Framework
Suddenly, Mule 3 trots along and you hear about this new concept called “flows“. Why change your deployments to use a new and what seems like a different framework? First of all, good news. If you have existing implementations based on services, nothing has to change when moving to Mule 3. Services are still a valid pattern for implementing integration solutions in Mule and your application will run and scale just fine on Mule 3. In fact, we will soon be releasing a hosted migration service that will make it easy to convert your existing Mule 2 (and even some Mule 1.x) configurations to run under Mule 3. Stay tuned for more on that.
Why Flow?
In talking to Mule users and reviewing numerous Mule implementations, we discovered that many implemented patterns that just didn’t fit cleanly into a strict, service-based framework. They were not simply wrapping a single component with endpoints to decouple it from protocols and routing requirements. Often they were performing service mediation or light process orchestration, attempting to automate a business process or replace a point to point integration solution with a more decoupled mechanism that can be reused or changed as systems or business needs change. Some common use cases that flow is well suited for, include:
- Simple integration tasks
- Scheduled data processing
- Connecting cloud and on-premise applications
- Event processing where multiple services need to be composed
When we implemented the new message processor architecture in Mule 3, this allowed us to offer new patterns to implement service mediation and orchestration in Mule. The first obvious one was <flow>. With flow, you can chain together any number of endpoints, routers, transformers and components to solve your integration problem. In Mule 2, this typically was solved by chaining together multiple services using queues and/or a chaining router. If users do not require horizontal distribution of the services, then this is just additional configuration to maintain. With Mule 3, the configuration is straightforward and just requires “walking the flow” to see what happens (with Mule Studio you even can see a visual representation of the flow). Most of the use cases supported with services continue to be supported in flow, along with many new ones based on new flow-specific routers we are implementing.
Some key advantages of flow:
- <choice>, <all>, <async>
- Create and reuse subflows
- Chain together multiple components in one flow
- Integrate endpoints or cloud connectors anywhere in a flow
What can’t I do?
Flow continues to evolve and improve with each new release. There are a few important features still to be implemented, most notably asynchronous request reply. Expect to see this later in the year. Flow also does not yet support transactions on outbound routers (you can still perform transactions on endpoints, just like in services). Pretty much everything else you could do, still works just fine or better in flow. If you find something, let us know on the forums or in jira and we will gladly take a closer look.
Simplify your services using patterns
Another new alternative in Mule 3 are configuration patterns. Patterns provide a template to implement common solutions in Mule with greatly simplified configuration. You use them in place of a service or flow configuration. Mule ships with several common patterns, including, simple service, web service proxy, bridge, and validator. You can even extend Mule and add your own patterns. If you have an idea to suggest as a pattern, contribute it on the patterns forum.
So far, the response from the community on flow has been overwhelming positive. If you have tried flow in Mule 3 and have feedback to give, please comment on the blog or open a discussion in the forums. We are very interested in your feedback.
