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

Springing into Tcat

Reading Time: 9 minutes

Spring has become a highly popular framework for the development of web applications, thanks to a compelling support for web features, both at its core and within extensions modules. When it comes to deployment time, Spring shines again by its container agnosticism. Because Spring web applications are pretty much self contained, they can get deployed on any JavaEE container. With a plethora of containers available, picking one can be a daunting task.

As you may know already, MuleSoft Tcat Server is a plain vanilla Apache Tomcat enriched with management web applications in order to deliver state-of-the-art application provisioning, configuration management and monitoring capabilities.

In this post, we’ll look at two scenarios where deploying on Tcat can help you to go further with your Spring web applications. For this, we will leverage Tcat’s configuration profile mechanism that, among other things, allows an orderly deployment of files anywhere within a Tomcat’s directory hierarchy.

Continue reading

RESTx version 0.9.4: JavaScript everywhere, MIME types and more

Reading Time: 12 minutes

Version 0.9.4 of RESTx – the fastest way to create RESTful web services – has just been released. The main features introduced by this version are the ability to write components in server-side JavaScript, the addition of a JavaScript client library and much improved handling of content types for input and output. You can download it now.

Continue reading

Sweet XML: How pattern-based configuration will sugarize your Mule

Reading Time: 4 minutes

Configuring Mule involves XML, and though using a decent XML editor can help a lot (thanks to the contextual help it provides from Mule’s schemas), there is still a enough angle brackets to warrant a coffee break as projects get more complicated.

As the number of services in a Mule project increases, so does the amount of noise in its configuration files, making it harder to understand and maintain them. We recommend splitting service configuration files, but in Mule 3 we’ve decided to go further and tackle this problem with the introduction of pattern-based configuration.

Continue reading