BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Interview With Ross Mason On The Release Of Mule 3

Interview With Ross Mason On The Release Of Mule 3

 Mulesoft recently released Mule 3, their next generation ESB platform. Some of the significant features in the release include [From the release]

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

Mule 3 embraces the web platform with Native REST support, support for a wide variety of javascript frameworks with AJAX/JavaScript integration, support for protocols and formats such as ATOM, RSS and JSON. Mule 3 also introduces Flow; an integration construct that provides users with a very simple yet very flexible way of implementing message processing and integration solutions by simply building solutions from Building Blocks.

Flow

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:
http://blogs.mulesoft.org/new-mule-ide-coming/

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: One of the common scenarios we see in web applications; especially mashups; is the need for secure javascript  invocation either via using a centralized mashup server or via services that support JASONP. How much support does the product support these kinds of scenarios?

RM: Sure, the AJAX/JSON support in Mule 3 is extensive. So much so JSON has been made a first-class data format along with XML which means you can do things like bind JSON data to Java objects automatically. Regarding how JSON is served, a central AJAX Server is managed, this means that a Mule application can make JavaScript calls to request data for external services such as Salesforce.com or Facebook. The AJAX channel from the server to the browser can also be secured.

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?

RM: Mule has JSR-223 scripting support which means it is really easy to write components and transformers using dynamic languages such as Groovy and Jython. We also, have an extensive expression language in Mule that makes it easy to query and manipulate messages and drop into any JSR-223 supported language.  We are seeing a trend in server-side JavaScript and more usage of Mule and Python together so we plan to offer more support for these 2 languages. We will offer more natural ways for Python and JavaScript developers to work with Mule and explore Scala too.

Rate this Article

Adoption
Style

BT