Interview With Ross Mason On The Release Of Mule 3
Mule Cloud Connect
Which provides out-of-the-box connectors for popular cloud, SaaS, and Web 2.0 providers (e.g., Amazon Web Services and Facebook), as well as an easy way for users to create their own cloud connectors
Flow is a new powerful way of creating message flows in Mule. Many people struggle with the rigid nature of the service model in Mule because they don’t naturally think in terms of services. Flow allows developers to create integration flows they way they think about solving the problem. We’ll be talking a lot more about this in future posts.
Also provides richer support for patterns by providing pattern based configuration options, that allow users to apply common integration scenarios e.g RESTful Web Services using the pattern based building blocks. The product is also advertised to offer new deployment mode that offers features such as automatic hot deployment.
This revision of the product comes with a lot of architectural changes under the hood to support the features that are aimed at making the product easier to use, configure and deploy.
InfoQ caught up with Ross Mason to learn more about the product release and get a glimpse into what to expect from the new features in the product offering.
InfoQ: Most commercial EAI tools and frameworks provide tools that allow you to model services as workflows. Typically seen in BPM tools that model process as an orchestration of services. How does flow fit into that ecosystem. Could you elaborate what you mean by Flow?
RM: Flow is a new construct model in Mule. To the user they see an XML schema-based DSL that offers rapid development of service flows. We do have graphical tooling in the pipeline, but the schema-based approach has some nice benefits - Rapid development of integration flows, no need to learn a new interface, it's just XML - the schema offers auto complete and validation - there is comprehensive context help for every element and attribute that pops up in the code window making learning on the job easy We have an open source Eclipse-based tooling product underway, we blogged the prototype recently:
InfoQ: Could you explain the use of patterns in service configuration. Is this an evolution of the product where we have a pallete of scenarios that can be put together using an IDE integrated tool-chain? How much of that support exists today?
RM: Yes Patterns are an evolution of the ESB. We have farmed a lot of patterns from our users and customers and put features in place to make it easy to realise these patterns in Mule. The patterns wrap common (sometimes complex) functionality into a single configuration element that developers can use without having to understand all the details. Mule has always embraced patterns and was the first ESB in 2004 to implement the Enterprise Integration Patterns. These new patterns offer bigger building blocks for common service and integration scenarios. Developers can also define there own patterns. We plan to have a palette for these patterns in our Eclipse tooling as well.
InfoQ: This is a quote from DZone. Could you throw more light on this please?
Originally, MuleSoft wanted to modularize Mule 3, but they ultimately decided against it. "There's no easy way for vendors to shield end users from the complexity of OSGi without adding a lot of extra abstraction on top of it," said Mason. They even converted everything in Mule to OSGi bundles and had a demo one year ago. Unfortunately, developers would have had to manage the bundles explicitly and the deployment model would not have been as simple as it is today. "We haven't written it off, because there are some new things happening around OSGi," but right now, Mason says OSGi is not a good technology for the average end user.
RM: Regarding "Originally, MuleSoft wanted to modularize Mule 3, but they ultimately decided against it"; Mule has always been modularised, this author is actually talking about running Mule in an OSGi container (wedid convert all Mule modules into OSGi bundles). I was very excited about OSGi a few years ago when it started hitting our radars. But it turns out that OSGi is great specification for software vendors, but a terrible specification for end users due to the additional complexity around configuring and bundling. For Mule 3 we had one goal - simplify everything. With the OSGi spec where it is we couldn't make our deployment model as simple as we wanted for our users, so decided to build our own deployment model based on the principles of OSGi. We have by no means closed the door on OSGi, if the
specifications improves and addresses these concerns around end-user complexity we would definitely re-evaluate that path.
InfoQ: In the video, you briefly describe the availability of language bindings to access mule services. Could you speak a little to the currently available support and future plans?