A couple of months ago, I reviewed the process for deploying Mule Galaxy, our SOA governance platform, onto Amazon’s EC2. Not long after that, I was introduced to cloudtools, a set of tools for deploying, managing, and testing Java EE applications on EC2. With these tools, it becomes trivial to deploy an application like Mule Galaxy to the cloud in minutes, rather than hours.
Mule provides different approaches to handling errors. You can set exception strategies for connectors, models, and individual services. You can use the exception router to specify where the message goes when an error occurs. And you can use the exception type filter for fine-grained control. Following is an introduction to these approaches.
When wiring your Mule services together, new users sometimes get confused about when to use an outbound router and when it’s sufficient to simply get a reply. Following is a description of the three message styles you can use to get a response from your Mule services.
Continuing my whirlwind speaking tour on Mule, I landed in Dallas this week to talk to the JavaMUG. This was my first MUG (I’ve been to JUGs, SIGs, Camps, and Meetups, but never a MUG), and I was blown away to walk into a room of 75+ people all there to hear about Mule (okay, the free pizza and soda probably helped, too). Supposedly it was their largest attended event in several years. I gave a similar talk last month in San Francisco, but in Dallas I expanded a little on my thoughts about SOA and the Cloud.
We have been running Galaxy successfully on our in-house servers and laptops for demo purposes for some time now and decided that having a running image of Galaxy on Amazon’s EC2 was the next logical step. Galaxy in the cloud gives us the opportunity to expose a running instance to a much wider audience than might otherwise interact directly with the product.
Are you currently using Mule or evaluating Mule for use with your WebSphere MQ messaging system? Do you need to utilize WebSphere MQ specific messaging headers, message types, and character code IDs with Mule? Would you like to know how to deploy Mule for maximum reliability when coupled with WebSphere MQ?
Learn from the MuleSource technical team how to integrate Mule with WebSphere MQ using the premium WebSphere MQ transport that is packaged with Mule Enterprise. A common scenario supported by Mule Enterprise will be demonstrated: namely, how to exchange messages with native MQ applications. The solution will demonstrate implementing synchronous request-reply using replyTo headers and correlation IDs.
- What Mule is and what is the difference between integration and SOA
- Why use a Mule for integration
- How Mule helps with integration in the Cloud
- Best practices for planning and implementation
- Test driven development with Mule
Recently, there was a great question on one of the Mule mailing lists about where to store runtime data that can be used across the app. If you need to store runtime data that is available across your Mule application, you can store the data as objects in the Mule Registry. You can get a handle to the Registry from anywhere that you have access to the MuleContext, as in most Mule entities. For example, you could store the object as follows:
As some may know, we have been working on our open source Mule IDE based on Eclipse. However, with the schema-based configuration in Mule, IntelliJ IDEA users get some great features to help them build mule applications quicker too.