Mule 3 Architecture, Part 1: Back to Basics

Reading Time: 13 minutes

As you may have heard, Mule 3 has undergone a streamlining of its internal architecture. It’s now my job to explain what’s changed, why and what this means to you. I can’t promise it will be as exciting as a children’s movie but I will attempt to explain things as clearly as possible so that everyone can understand the concepts which in turn will help you use Mule 3 to its fullest.

This series of posts should be very useful both for existing Mule users wanting to understand the changes in Mule 3 and also for people who want to learn more about how Mule can be used to satisfy integration and messaging needs.

In this first blog post I’ll be taking a step back, away from Mule and its architecture and internals. We’ll remind ourselves what integration and messaging are all about, before going on to talk about the type of architecture that should ideally be used for integration or message-processing projects or frameworks.

Continue reading

Hot Deploy from Mule IDE

Reading Time: 5 minutes

The Mule IDE does not natively support Mule 3’s new application structure yet, but not to worry, with the new 2.1 release of the Mule IDE you can still keep it hot when working in the IDE. Just follow a few simple steps and your apps will be doing the tango with Mule 3 while you code away in Eclipse.

If you haven’t installed the Mule IDE, follow the instructions here to get up and running. Don’t forget to download and install Mule 3.

Continue reading

Come See us at Oracle Openworld

Reading Time: 2 minutes
Tomkatsu

MuleSoft will be at Oracle OpenWorld at booth #1833 (Moscone South) again this year. Come join us to experience firsthand the simplicity of Tcat Server and how it makes running Tomcat in production painless. We will also preview exciting new features of Tcat Server including dashboards, monitoring, alerting and fine-grained security permissions.


Learn how Tcat Server helps to close critical gaps in “plain vanilla” Apache Tomcat, such as lack of visibility into performance, manual configuration and application deployment, reacting to problems instead of proactively preventing them, and the age-old disconnect between dev and ops.

Continue reading

Mule And ActiveMQ – A Perfect Match

Reading Time: 2 minutes

ActiveMQ in Action, an upcoming book from Manning Publications, may well end up being the perfect companion book for Mule In Action.

Happily Ever After…

Thanks to Mule ESB’s native support for Apache ActiveMQ and the capacity to transparently use Spring for advanced configuration needs, Mule has long been the ESB of choice to tap into ActiveMQ’s JMS goodness.

With the release of Mule 3 getting closer every day, it seems like a perfect time to celebrate the lengthy love affair between these two fine open source projects. I’ve written up a nice long article to introduce you to some of the juicier benefits of pairing Mule ESB and ActiveMQ.

Click here to read the article on MuleSoft.org, which includes:

  • a tour of common Mule+ActiveMQ usage topologies
  • new configuration examples (complete with GitHub download links)
  • tips to help you configuring Mule+ActiveMQ infrastructures for production
  • …and more!

Start hacking Mule 3 – with Mule IDE

Reading Time: 3 minutes

While the rest of the team was still busy with Mule 3 release preparations I took some time to update Mule IDE to be compatible with Mule 3.

What’s new?

I have put most work into creating new projects from the examples that come with the Mule distribution. This feature was rewritten to match the examples layout in Mule 2.2.x as well as in Mule 3. You’ll notice that the entire example is now copied over (minus a few files that do not make sense in an Eclipse project, such as build files). If the example requires additional jar files, they will be downloaded into the project. A lib folder will be created inside the new project to host those additional jars and they will be added to the project’s classpath.

Continue reading

Say Hello to Mule 3

Reading Time: 14 minutes

The Mule team are really excited to announce Mule 3, the next generation open source ESB platform. It’s been a long time coming and the team have done a stellar job redefining what you should expect from an ESB. This release marks some significant new features as well as changes to Mule itself that result in the most powerful, light-weight and simple to use ESB out there.

Continue reading

Improvements to exception handling for Mule 3

Reading Time: 5 minutes

Background

You may recall that in Mule 2.x, there were two places where you could configure exception handling strategies: 1. on the service 2. on the connector

Since the service receives events from endpoints which depend on the connector, and transformers are a grey area, it turned out that this scheme was very confusing, because it was never clear which strategy was going to handle which exception, and in some cases the same exception was even handled by both strategies!

Concept

For Mule 3, we have tried to simplify and improve our approach to exception handling. There are basically two scenarios for exception handling in Mule:

1. A message is in play – e.g., a routing or transformer exception
2. No message is in play – e.g., a connection exception or an initialization issue

#1 we are calling Messaging exceptions, and have defined the following interface:

Continue reading

Beyond Integration, Part 3: Towards Eventing

Reading Time: 7 minutes

In the previous installment of the Beyond Integration series, we talked about some strategies for evolving legacy monolithic systems into finer grained services orchestrated by Mule ESB. As mentioned in this earlier post, following such a path opens the door for implementing new business operations by using the newly created services in novel and previously impossible ways.

One of the main concerns of modernizing legacy application consists in reducing coupling in all its forms. This is why reducing systems and components coupling, by establishing cleaner and clearer interfaces, is often one of the very first steps taken in such an evolution process. Another form of coupling that needs to be taken care of is temporal coupling. Systems that tended to synchronously depend on each other are time-decoupled by the introduction of a messaging intermediation tier, leading to an overall architecture that scales better and is more resilient to failures.

In essence, reducing time-coupling generally translates into evolving from an invocation-driven architecture to an event-driven architecture. In today’s post, I will present how using Mule can be an enabling first step towards the roll-out of such an architecture.

Continue reading

Transactions: Joining the outside world

Reading Time: 5 minutes

One of the strengths of the Mule ESB is its ability to share many kinds of resources with the rest of the software environment: libraries, Spring beans, transaction managers, and many more.  Starting in Mule 2.2.6 and 3.0, there’s another thing Mule can share: transactions.

In JTA, the Java Enterprise Edition API for transaction processing, transactions are tied to threads.    When Mule is entered from user code it’s possible that a transaction has already been started on the current thread, and Mule might want to join it rather than starting a new (nested) transaction.    You can control this with a new, optional boolean attribute on the <xa-transaction> element called interactWithExternal.  The default value is false, which make Mule act like it did in previous versions.  The way that the two transaction-controlling attributes action and interactWithExternal combine is straightforward if you keep in mind what the two interactWithExternal settings mean:

Continue reading