Flow in Action: Simple Orchestrations Pwned!

Reading Time: 4 minutes

Three months ago, I’ve introduced the newly created Erlang Transport for Mule 3 in this blog. To illustrate a usage scenario for this transport, which allows fast and seamless bi-directional communications between the JVM and the Erlang worlds, I presented an example where Mule was exposing a JSON over HTTP service for provisioning users in RabbitMQ.

At that time, the new configuration mechanism named Flow was not fully baked so I implemented the example “Mule 2 style“, which means that I used Services tied together with VM queues.

Now that Mule 3.0.0 is out, my challenge for today’s post was to redo the configuration “Mule 3 style“, i.e. using by Flows.

mule_flow
Continue reading

Taking a Rest from Code Camp 2010

Reading Time: 3 minutes

Code Camp continues to grow by leaps and bounds each year. For those not familiar with Code Camp, it’s an all volunteer run conference at Foothill College each October and is on version 5.0. It lasts the whole weekend and this year over 3000 people registered and over 1900 ended up spending their weekend attending technical sessions ranging from How to Teach Programming to Kids to HTML5 Crash Course.

What I love about Code Camp is it represents the long tail of conferences and learning. Anyone can propose and lead a topic making it a great place for those that have an interest in speaking to technical audiences to cut their teeth. Even more important, you can find a talk on just about any subject. And with 3000 registrants, you are bound to find at least a dozen or more other people interested in the same. From a small sampling of my audience, this year’s hot topic was HTML5.

Continue reading

Implementing Kanban for Sustaining Engineering

Reading Time: 10 minutes

I’ve been working at MuleSoft on the Sustaining Engineering team for a few months. In this time I watched how things work and find out what type of challenges we deal everyday have and how we solved them. I watched a great team working long hours to solve customers problems as fast as possible. Our primary goal is to enable our customers to meet their deadlines, and remove any problem they might have with MuleSoft’s products in the process.

Context on the type of work

The sustaining engineering team works on solving problems for our customers, improving the code, implementing new features and reviewing how things behave to answer questions. Usually questions come from our customers, and sometimes we get high priority issues with high visibility. Critical issues may appear without any planning and they need to be solved as soon as possible. This type of events cause disruption in the team’s work. If any disruption propagates over time, it causes bigger or permanent problems. There is a mixture of high priority things popping up, with planned features or improvements.

Problems and challenges

This is the list of problems I’ve seen during this time.

Continue reading

Introducing Tcat Server 6 R4

Reading Time: 6 minutes

With a focus on production ready features, Tcat Server has become the leading enterprise Apache Tomcat in the world. As more and more leading organizations are adopting Tcat Server and using it to run their most demanding applications, we have been hearing from them about the features they need for gaining better visibility and for managing their applications in production.

We are pleased to announce General Availability of Tcat Server 6 R4, which represents the result of this feedback and is the most comprehensive product in the market for organizations using Tomcat in production.

This release includes:

  • Global dashboards: Our customers have been telling us that while Tcat Server provides a single pane of glass for managing their Tomcat instances, they wanted to see a summary of all of their instances, the status of their applications as well as actionable information, all without drilling into each server instance. Global dashboards address this by providing a view of your entire Tomcat environment, web applications, status of current deployments and potential issues on one single screen. Similarly, the ability to view important metrics on a per-server basis is now also possible via server dashboards. Many of our customers’ applications expose data via JMX metrics, and being able to graph them to see the trends is now possible via these server dashboards.
Continue reading

Mule Speaks Java: Towards a programmatic configuration of Mule

Reading Time: 3 minutes

True to our goal of simplifying the configuration of Mule, we will be adding the capacity to programmatically configure Mule 3 in the coming releases.

With configuration patterns aiming at reducing the amount of XML configuration and a new IDE in the works for graphically configuring Mule, the third angle we wanted to take on simplification was the creation of an API fluent enough that it becomes possible to configure Mule with your favorite JVM language.

If you’ve peeked into Mule 3’s source code, you may have noticed that this effort is already on-going. Indeed, each of the newly introduced configuration patterns is backed by a builder class that is used to instantiate it. Read on for a quick demonstration of how this can be used…

Continue reading

Pattern-Based Configuration: Hello Validator!

Reading Time: 6 minutes

The pattern-based configuration series continues! After a first set of fairly generic patterns, this new addition will demonstrate how highly specialized patterns can provide value too.

When processing messages, a certain format is always assumed to have been respected so that the required data can be retrieved. It is possible and oftentimes desirable to be very liberal with the data representation used by incoming messages: as long as you can find the needed pieces of information, the rest doesn’t matter.

But sometimes, a strict up-front validation of incoming messages is needed. This is that kind of scenarios that the Validator configuration pattern addresses.

Continue reading

Pattern-Based Configuration: Hello Bridge!

Reading Time: 7 minutes

Web Service Proxy was the last configuration pattern presented in this blog. Time for a new one!

Connecting systems together is one of the most essential task of integration. Mule ESB offers the necessary building blocks for achieving such connections. One of these building blocks allows establishing bridges between message sources and destinations. Known as the messaging bridge pattern, this building block is available in Mule 3 as the newly introduced Bridge configuration element.

So we’ve built a bridge: it’s time we get over it!

Continue reading

Configuring Message Processors on Endpoints

Reading Time: 6 minutes

One of the big architectural changes in Mule 3 is that everything has become a Message Processor1. What is a message processor? It’s a very simple interface for anything which takes a Mule message2 and does something with it (transforms it, filters it, splits it, etc.). One of the big advantages to everything implementing this simple interface is that message processors can be chained together in any order, there can be any number of them, and they can easily be swapped around. This sort of thing was not at all possible prior to Mule 3.

In the case of endpoints, the following message processors are allowed:

Continue reading

Pattern-Based Configuration: Hello Web Service Proxy!

Reading Time: 7 minutes

After the introduction of Simple Service, the configuration patterns series continues!

The second pattern we would like to introduce is Web Service Proxy. Proxying web services is a very common practice used for different reasons like security or auditing. This pattern allows a short and easy configuration of such a proxy.

Continue reading

Pattern-Based Configuration: Hello Simple Service!

Reading Time: 7 minutes

As announced before, Mule 3 will offer pattern-based configuration artifacts that will allow you to perform common configuration tasks with the least amount of XML. This first post opens the series where each of these patterns will be introduced.

The first configuration pattern we’d like to present is called: Simple Service. Its goal is as simple as its name suggests: provide a simple way to expose request-response services. In other terms, it is used to expose some business logic in a synchronous manner over the transport of your choice.

Continue reading