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.
Defining what constitutes a service when building service-orientated applications seems to be a common problem for developers and architects who are new to building services. The main issue seems to be the scope, i.e. what is the granularity of the service. This is actually quite difficult since the granularity of a service can vary depending on the application. The trick with any fuzzy problem is to break it into smaller pieces. There is a very simple service taxonomy defined in Thomas Erls SOA in Principals of Service Design book which I believe makes the approach to defining services much easier.
With so many integration points and applications of Mule, troubleshooting issues can be a daunting task for those just starting out with Mule. This post will provide a few tips on how to get to the root of issues you may encounter.