One of the joys of Mule 3’s new Message Processor (MP for short) architecture is the power that arises from being able to combine message processors into different patterns. To make this as flexible as possible, the routing message processors that were designed to be used in flows each do a single job, making them highly reusable. This allows you to build up a flow piece by piece, or alternatively modify an already working flow, without having to change its basic structure. Let’s look at an example.
A couple of weeks ago I started the integration between Mule ESB and Activiti BPMN. Activiti is a Business Process Management (BPM) and workflow system targeted at business people, developers and system admins. Its core is a super-fast and rock-solid BPMN 2 process engine for Java. It’s open-source and distributed under the Apache license. Activiti is being written from the ground up with the requirement that the engine should be easily embedded and that the project would be aimed at developers not the business. This is a very natural fit for MuleSoft since our approach to middleware starts with the developer. We have been working with the Activiti guys since July focusing in the integration aspects of the project.
The idea behind Mule’s Activiti transport is that you are able to perform several administrative actions in an Activiti server from Mule. For example, let’s suppose that you would like to retrieve the candidate tasks of the user kermit, do some processing and CLAIM a subset of those tasks. The following configuration will work for you:
We all recognize the need for both server and application monitoring in a production environment and Tcat Server makes this easy. However, the development and QA process can also benefit from this feature.
At MuleSoft I’m often asked to write small one-off webapps for different parts of our internal infrastructure — often they are interim solutions or somewhat experimental; since these are somewhat less critical applications, at best I’ll create some unit tests, create a plan on our CI Server, and do some “developer QA” — which amounts to clicking around the basic flow and cajoling some co-workers into basic sanity and acceptance testing. Since I’m also responsible for provisioning the server and deploying the application, I like to take as many shortcuts as I can. Fast and informal is the name of the game here.
However, lately I’ve been using Tcat’s Alerting with these applications in both the production and QA cycles. This has allowed me to spend less time tracking issues and to catch obscure errors and performance issues before I deploy into production.
There are some cool new features in Mule 3 for building AJAX applications. I figured I’d take you through a tour of the GPS Walker, an small example that demonstrates how to use AJAX to communicate from a Mule Service to the browser. This example uses other new features in Mule 3 including automatic JSON bindings, the @Schedule annotation and Flow.
The Mule IDE does not natively support Mule 3’s new application structure yet, but not to worry, with the new 2.1 release of the Mule IDE you can still keep it hot when working in the IDE. Just follow a few simple steps and your apps will be doing the tango with Mule 3 while you code away in Eclipse.
In order to make sure that the migration path is straightforward and well-documented, I just finished migrating the SFTP MuleForge project from Mule ESB 2.2.1 to 3.0. It was extremely helpful to have a good set of unit tests in the SFTP transport code. That makes it easier to tell if your project still has all of the necessary functionality after the migration. If you are interested in migrating your own MuleForge project, check out the following links:
Right now TCP inbound endpoints are implemented as TCP servers that listen for data coming from different clients. In Mule ESB 2.2.6 we are adding a new feature to inverse the control: TCP inbounds can now poll data from remote servers.
It is really easy to switch to this strategy. Let’s take a look of how a mule configuration looks like:
Organizations running Apache Tomcat in production on Windows often want to run Tomcat as a Windows service. This removes the need for someone to be actively logged into the server and provides an easy way to integrate with Windows management tools. In this blog, I will explain the easiest way to run Tomcat as a Windows service and how you can do this for multiple instances as well.
Running an instance of Apache Tomcat as a Windows service is not complicated, if you download the correct distribution of Tomcat (Windows service Installer). However, running multiple instances of Tomcat as Windows services is a more complicated process. To avoid issues, you would have to:
1. Uninstall the service that the installer has installed ( if you used the service installer)
2. Run the service.bat command and give it an unique name ( so, next service install would not fail )
service.bat install MyTomcat2 ( you have to download the zip distribution to get service.bat )
2. For each instance, edit server.xml and manually modify all ports to unique non-default numbers
3. Go to Service Control Manager by running ‘services’ from Start menu and change the startup type for each instance to be “Automatic”
You would have to repeat this process for each instance that you want to install, which can get tedious and potentially quite error-prone.
The Tcat Server installer provides a much better experience by enabling you to select a name for the service and also by enabling you to install multiple Tomcat instances on the same box. All you have to do is to run a standard install of Tcat Server on Windows, and it will automatically install Apache Tomcat as a Windows service. It can detect name conflicts and pick unique service names for the Windows services. (The installer also detects port conflicts, so you don’t run into start-up issues due to port conflicts).
We have put up a screencast that shows you how to get started with RESTx, our platform for the rapid, easy creation of RESTful web services.
RESTx allows developers to contribute data access, integration and processing components in Java or Python, using a very simple API. Then, with nothing more than a browser and a simple HTML form, users provide parameters for those components, which the RESTx server uses to create new RESTful web services, resulting in easy to use, safe URIs that give users access to the data they need. For example, a developer may contribute a component for access to the API of a legacy application, but the users now provide different sets of query parameters, resulting in resources such as ‘customer list’, ‘order queue’, etc.
Our RESTx project – a platform for the rapid and easy creation of RESTful web services and resources – is largely written in Python. Python is a dynamic, duck-typed programming language, which puts very little obstacles between your idea and working code. At least that’s the feeling I had when I started to work with Python several years ago: Never before was I able to be so productive, so quickly with so few lines of code. I was hooked. No wonder some people describe it as ‘executable pseudo code’: Just write down what you want and for the most part, it will actually work.
Now there’s a price to pay for this increased developer productivity, where the interpreter somehow figures out at run time what it is that you actually want to do and how to let your code deal with all sorts of different types: Python is interpreted, it’s dynamic and this means that for the most part it’s slower than compiled languages.
In this article here, I will talk about an interesting optimization technique for Python, which will come as a surprise to many Python developers.