Introducing the New Mule Agent Architecture

March 24 2015

0 comments 0
motif

Hi folks, in this fourth post of the new Mule Agent blog post series I will introduce the Mule Agent architecture and the main advantages it provides.If you missed the previous posts in this series, check them out below:

During its development, we discussed the best ways to make the agent extensible and configurable, allowing users to customize it depending on their main use cases, adapting it to their current development cycle and practices. So please enter and take a look at the architecture we defined and implemented for those purposes.

Architecture Overview

The Mule Agent is a plugin that exposes an API through and Websockets, highly configurable and extensible, providing access to the main Mule ESB management and monitoring capabilities. An overview of the architecture is exposed in the diagram below:

Mule Agent Architecture
Let’s take a deeper look at each component.

Transports: This layer handles the communication with external clients through the API. We currently support two different implementations: calling the API using REST HTTP or Websockets.

External Handlers: Handle any external message and call the corresponding to perform the requested operation.

Agent Services: Include the logic to perform the operation, injecting the corresponding Mule Services to interact with the ESB management and monitoring API. These services are the only component that call directly the ESB API.

Internal Handlers: Injected into the Agent Services, they give support to call external services (e.g. Monitoring Systems, Logging platforms) and send messages produced by Agent Services (e.g. Mule Event Tracking notifications, JMX metrics).

Example: How Deployment Works

So now that we have a better understanding of the Agent architecture we will take a common feature, deploying applications, to exemplify how each component interacts in the process.

The first step to deploy an application is calling the API (we will use REST) sending the application information. The request should look like this:

PUT http://localhost:9999/mule/applications/testingapp HTTP/1.1
Content-Type: application/json

{
“url”: “file:////Users/mulesoft/testingapp.zip”
}

This request will be handled by the REST API at the Transport Layer which will dispatch it to the Deployment External Handler.

Once the external handler gets the message it will decide which services should be called to perform the operation, in this case the Mule Agent Application Service, which receives the request and call the Mule ESB Deployment Service to perform the operation.

Here is when the internal handlers take place. The Mule Agent Application Service injects every handler able to manage application deployment notifications (this means that you can provide your own handler implementation just adding your libraries to the classpath. In future posts we will dig into how extending the agent). After the service sends the deployment request it will process every notification from the Mule ESB Deployment Service and call all the injected internal handlers (you can have more than one per message type) to dispatch the notifications.

Now the process should generate the message back for the client which called the API. The response is originated in the Mule Agent Service and enhanced by the Deployment External Handler.

You should get a response like:

{
“application”: {
“name”: “testingapp”
},
“status”: “Deployment attempt started”
}

What’s Next

You can find more about the new Mule Agent at MuleSoft documentation portal (http://www.mulesoft.org/documentation/display/current/The+Mule+Agent). Please stay tuned for new Mule Agent posts and share your comments or questions, we will be more than happy to hear of you!

See you soon!


We'd love to hear your opinion on this post