In this blog post I will show how to extend Mule in a simple way using the recently released Mule DevKit. The goal of the Mule DevKit is to accelerate the development of Mule extensions by abstracting you from Mule specific stuff so that you just focus on what your are trying to build.
My idea here is to create a simple Cloud Connector to interact with Google Maps API but the concepts covered here can be used in other scenarios as well. Since the Mule DevKit is intended for developers, expect many code snippets so that you can go through this example on your own and play around with the code. You can get the full source code here.
This post is all about developing Cloud Connectors and deploying apps to Mule iON, but rather than just using words I created a screencast that demonstrates how to use Cloud connectors and Mule Flow to build applications that can be run on Mule or Mule iON.
Cloud Connectors provide simple and reusable integration with Social Media APIs (like Facebook and Twitter) and Cloud platforms (for example Amazon Web Services). You have many options: browse our existing Cloud Connectors, create new ones yourself and share them with our growing community (and take credit for it!), or turn your existing public API client into a reusable Cloud Connector. In this particular example, I will use GeoNames API and Google Maps.
Once you have a working Mule ESB application you may be wondering how fast it can run. Here we will discuss a simple method for measuring the throughput of your application using Apache JMeter.
Bear in mind there are many ways to improve performance (simple changes can yield great performance boosts). We will explore them in greater detail in a follow-up blog post covering Mule application tuning.
Last time that I blogged about Studio was when we had a limited private beta. The program went really well and we got a lot of great feedback. Now, I’m really happy to announce that we have released Mule Studio (beta) to the public. You can download it from here. Mule Studio is free and anyone can use it.
When an issue arises in production it can be quite daunting to reproduce it in a test environment. Ideally one debugs the live application. But logs don’t tell the whole story. And a severe issue may require the application be taken down. How can it be stopped and debugged at the same time? With Mule composite sources and Mule Management Console (MMC) end-point control you can eat your cake and have it, too.
Mule 3 defined a simple, universal structure for Mule ESB applications. It’s a simpler version of war file format, consisting of a zip file with three sorts of entries:
- At the top level, configuration files and application properties files
- In the lib directory, jar files
- In the classes directory, classes and resource files
We also created a maven plugin to build Mule apps. And we haven’t forgotten about the Ant fans in our community. There are two new Ant tasks to make creating and working with Mule applications a snap.
How many web sites/web services have you wished you could just interact with over the command line? Sometimes, you just want to type commands in your shell. I can name at least 3 of our products which I’ve wished I could do that with: iON, MMC, and Tcat.
There are some challenges though. Bash/BAT file scripts don’t provide facilities to interact with web services. Then, if you go with a cross platform language, you have to write cross platform scripts and provide a way to distribute it.
We thought we’d make this easier, so we wrote Mule Jockey, a tool to turn annotated groovy scripts into a cross platform distribution of shell scripts.
It’s really easy. First, write your command. For example:
I’m really happy to give you more details about Mule Studio. This is a project that started early last year and we are finally getting to a point that we are ready to share a first beta version with the entire Mule Community.
Mule Studio is an Eclipse-based developer tool, that allows to graphically create and test Mule ESB Flows.