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).
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.
Though a veteran language and platform, Erlang has recently gained a lot of traction, as very visible web sites and open source projects decided to use it in order to leverage its intrinsic support for highly concurrent, fault tolerant and distributed applications. To name a few, let’s mention: Facebook Chat, Mochiweb, ejabberd, RabbitMQ, riak and CouchDB.
Without opting for Erlang as a development platform, companies may still be tempted to leverage an Erlang-built middleware: most of them offer public interfaces accessible over generic protocols, like HTTP, and are easy to integrate quickly and efficiently. That said advanced scenarios can require a tighter integration like, for example, creating a module for ejabberd that requires to call custom Java code or reaching server functions on RabbitMQ that are not accessible through AMQP.
This is when the Duke meets Erl. And this is when Mule ESB can help, thanks to the new and coming Erlang Transport for Mule 3. Read on for more information about the transport and a walk-through a simple use-case of RabbitMQ integration.
Most people who ever worked in real-world data integration projects agree that at some point custom code becomes necessary. Pre-fabricated connectors, filter and pipeline logic can only go so far. And to top it off, using those pre-fabricated integration logic components often becomes cumbersome for anything but the most trivial data integration and processing tasks.
With RESTx – a platform for the rapid creation of RESTful web services – we recognize that custom code will always remain part of serious data integration tasks. As developers, we already know about a concise, standardized and very well defined way to express what we want: The programming languages we use every day! Why should we have to deal with complex, unfamiliar configuration files or UI tools that still restrict us in what we can do, if it is often so much more concise and simple to just write down in code what you want to have done?
Therefore, RESTx embraces custom code: Writing it and expressing your data integration logic with it is made as simple as possible.
Let me illustrate how straight forward it is to integrate data resources using just a few lines of clear, easy to read code.
Developers are interesting creatures – curiosity and the urge to explore are their second nature. The way it goes today (until quantum computers replace everything ) we still need to share our findings in some way, which happens to be a code repository. For years, Mule has been using Subversion (and CVS before that), and today there are new kids on the block fighting for our attention. While we aren’t yet ready to make a full switch (infrastructure tools need to mature, non-developers need some training, etc.), we’re happy to play with Git. Lucky us, they came up with a way to marry two worlds, which gives Subversion a ‘lease extension’.
This post describes a workflow which worked quite nicely for us. Who knows, maybe it helps your organization keep developers happy, while preserving sysadmin’s good night sleep too? Post your findings in the comments.