Noteworthy new features in Mule ESB Enterprise

December 16 2009

3 comments 0
motif

With the release of Mule ESB 2.2.4 Enterprise Edition, there are several new and interesting capabilities that have been enhanced in Mule. Reading through the release notes, you might miss them, so I decided to highlight them here on the blog.

SAML Web Services Security

Mule ESB has had support for WS-Security via CXF for some time now, but Mule 2.2.4 Enterprise goes further with the inclusion of the Mule SAML Module, allowing single sign-on for web service requests. Travis does an excellent job of describing how to use it in his recent post, and a new example has been created and ships with Mule ESB to make getting started with web services security even easier.

New Examples

Examples provide a great way to learn, and we have created two new examples to help developers learn how to configure and use some of the new enterprise features of Mule. As mentioned above, an example is available demonstrating SAML and Web Services security. A second new example demonstrates use of Mule with IBM Websphere MQ. This example also touches on the use of transactions. Another benefit of examples is that Mule IDE will automatically detect them in your installation and create a template for a new project from them. Just select the new Mule project wizard and select the example you want to use from the list.

Polling JMS

By polling a JMS endpoint, you can have more efficient use of broker connections. Even more important, when running inside Websphere Application Server, the use of the JMS APIs is restricted and configuring a JMS listener is not allowed from a Mule application. The transactional polling JMS receiver in Mule ESB works around this limitation and allows you to deploy into Websphere and monitor a JMS or Websphere MQ queue for messages. It also supports the use of transactions.

Tomcat Hot Deployment

If you need to be able to update configuration files and custom classes without restarting Mule, you can run Mule in MuleSoft Tcat Server or Apache Tomcat and deploy your applications as WAR files. You can then update files as needed, and Tomcat will redeploy them without any downtime for Mule. This allows you to deploy and manage each of your Mule flows independently and start, stop, or update them independently. When combined with the advanced deployment capabilities available in Tcat Server, suddenly you have a very easy way to manage your deployments of Mule in a web environment.

To try out any of these new features, download a trial of Mule ESB Enterprise Edition at http://www.mulesoft.com/mule-esb-enterprise-trial-download.


We'd love to hear your opinion on this post


3 Responses to “Noteworthy new features in Mule ESB Enterprise”

  1. Clarification on the polling jms receiver. Regular listener approach is the most efficient. Sometimes, though either environment or operations requirements may pose restrictions on its use, and this is when polling receiver steps in.

  2. Hi Ken,

    Just trying to clarify the difference between the JMS listener and polling receivers is as I understand it that a listener is constantly listening to a queue for messages and will process them as soon as it sees them where as a polling receiver only checks periodically for messages depending on the polling frequency? Is this correct?

    Regards,
    Kevin.

  3. Hi Kevin,

    At the lowest level a listener will leverage JMS MessageListener, while polling receiver will use JMS consumer.receive(timeout).