End to End Example - A Mule 3.5.0 App with Domains

Recently, I've added to my gradle plugin for building mule apps the ability to build domain-based (A.K.A. mule shared resources) projects. While the plugin gains maturity and is getting ready for prime time, I've started eating my own dog food with it and as a result I've produced a sample application that uses some features of Mule 3.5.0 Community Edition. Please checkout the instructions on how to run the sample project.

The Use Case

Let's imagine that we have in our premises a database of cooking recipes, but we have the requirement of exposing a REST API so users can check available recipes and post new ones.

This is a simple use case but we have some additional requirements as well as some constraints:

1. The Backend APP needs to have the less down time possible.
2. We need to be able to change the API since it will evolve and gain new features.
3. We need to be able to scale the backend so when thousands of users access it at the same time it does not become extremely unresponsive.
4. Upon an upgrade in the backend it would be desirable that users can still post recipes. 

Implementation

For the implementation of these requirements, I've decided to divide and conquer, this is create two modules:

1. API Module: This is responsible for receiving requests through HTTP, and adapt them in a way the backend can understand and process them. Also is responsible for representing appropriately the information provided by the back-end.
2. Backend Module: This module is responsible for accepting requests, processing them and returning the results.

The following is a diagram of the implemented architecture:

The communication between the modules is leveraged through JMS, initially as the app has only a couple of users, we don't want to have a separate JMS Broker, so we'll leverage an embedded broker, but this is easily upgradable to an external broker without making any changes to the Modules.

Backend Implementation

For implementing the backend (source code) I've leveraged the brand new Database Module. This module allows to easily run parameterized queries. The backend module's main interface are JMS queues, and for the operations that require a response, we'll take advantage of mule's automatic reply when ReplyTo-type headers are present.

API Implementation

For implementing the front end (source code), I've used APIKit, this module allows us to easily expose a REST-like API out of a RAML file, so before starting the implementation I went to the Anypoint Platform website and created a RAML File with the API Editor.

In order to implement the requirement of accepting recipes even if the backend is missing I used a Asynchronous approach, this is the create operation returns a Task ID, and it's up to the client to check if the task has been completed, normally it is desirable that the APP itself notifies the clients when their tasks have been completed, nevertheless due to the nature of the HTTP transport, this is not possible.

There are some tasks that require a synchronous response, these are: check the list of recipes and check the status of a given task. These calls have been implemented with JMS queues as well, but leveraged mule's request-reply router for synchronizing these calls, so if a redeployment of the backend happens in a reasonable time-frame, requests from the client will last a little longer but not fail.

Conclusions

The use of Mule ESB 3.5.0 allowed me to implement this use case in a matter of a couple of hours. In particular this version with the ability of sharing the JMS connector I can easily do Inter-APP communication (which is easier in Mule Enterprise by sharing a VM connector) and still have the ability to scale, add more servers, cluster etc.

Testing Anypoint Studio 3.5.0 and Mule ESB 3.5.0

Today I've been playing with the new Anypoint Studio (formerly known as MuleStudio) that was released last week. Among many features I'd like to highlight a couple that I regard very useful, apart from this, Studio has gained a lot in usability and user experience.

WebService Consumer Element

This is a new feature for MuleESB 3.5.0 and it has a really nice integration with studio. Traditionally, in order to consume a SOAP web service from Mule, one would have needed to either generate a Java-based client or deal with raw SOAP XML payloads. Now, by simply specifying a WSDL, studio helps us presenting the available bindings and ports. Finally, thanks to Data sense and DataMapper (these features were present on previous versions of MuleStudio), you can easily populate the request and take advantage of the response.

This is how our flow would look like:

This approach is very lightweight and is by far easier than the previous approach with the CXF Module.

Request-Reply Element

Finally, request-reply has gained visual support, this element is particularly useful when we have to call asynchronous services but need to synchronously wait for the response. This element is not new but for long time has been something we'd need to go to the XML view to take advantage of. Now we have nice visual integration.

This is a sample flow demonstrating the use of the request-reply element:

This flow places a call into a VM queue (could be JMS as well) and waits for the response in the reply queue. This allows us to synchronize the call to the second flow within the first one but at the same time keep it's asynchronous nature for other consumers.

Scatter-Gather

This element allow us to run multiple routes but in parallel, and take advantage of the result, this is, an asynchronous counterpart for the existing 'All' router. Previously, this behavior could have only been achieved in an 'artificial' way, this is mixing request-reply, all and collection aggregator. Now it is available to use in a general form.

Here are sample flows showing the parallel processing of this component:

The invoked flow, sleeps for 2 seconds and produces a log statement before the sleep happens.

Database Access Reloaded

Previously, MuleESB had the JDBC transport, which was sort of un-natural for new MuleESB versions but at the time of it's release Mule didn't have features such as poll or watermark. Now, database access has been transformed into a shiny module that tackles access to databases in a very consistent and easy way. The following example shows how to run a query every 30 seconds and log the resulting records.

This module allows easy creation of parameterized queries (before these queries were also possible but somehow unnatural to produce), easy access to stored procedures and other interesting features.

Source Code

The following snippet is the XML source for the previous examples that demonstrates a more comprehensive view of the settings applied to the components:

Final Words

Studio and Mule 3.5.0 are very promising versions of this integration platform. It has a great deal of features that are not 'visual' but extremely important for our integration architecture, I.E. shared domains, which allows us to split our integration into multiple apps and be able to internally communicate between them.