In order to use the hot deployment feature that was introduced with Mule 3 you need to package your application as a zip file.
If you are using Maven to build your Mule applications then packaging zip files for hot deployment is very easy. All you need is to declare your packaging to be Mule:
Recently I saw this question posted in a forum: “Does REST have better performance than SOAP”?
This question is symptomatic of a fundamental misunderstanding of REST, I think. SOAP is a particular protocol used to implement RPC functionality. REST, on the other hand, is not a technology or protocol, but an architectural style. Systems that were built with the REST architectural style are fundamentally different from RPC based systems. For REST, we think in resources and data. For RPC we think in methods and actions. You can’t just swap one out for the other, because they are not even in the same category of things.
Comparing the performance of REST to SOAP is like asking: “What tastes better? ‘Stir fried’ or ‘zucchini’?” or “Which one is better? ‘Darth Vader’ or ‘Star Trek’?” Those question just don’t make any sense. People who think that they do are probably the same who think that REST is nothing but “RPC via URI”, which of course it is not.
You can ask whether a RESTful system, using HTTP as protocol, would have certain advantages or disadvantages compared to an RPC based system, using SOAP (over HTTP) as protocol. And even then you need to look at the system you are trying to implement and its specific requirements.
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.
We begin with a very basic flow that reads files from a File endpoint, checks that they’re XML, and and sends their contents to an HTTP endpoint:
Hi all!
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:
I wanted to write about a little project I have been working on which I added to the Mule testing framework recently: dynamic port testing. As long as I have been working on the Mule ESB project, we have had weird random intermittent test failures which fail with a message like this:
Caused by: org.mule.transport.ConnectException: Failed to bind to uri at org.mule.transport.tcp.TcpMessageReceiver.doConnect(TcpMessageReceiver.java:81) at org.mule.transport.http.HttpMessageReceiver.doConnect(HttpMessageReceiver.java:83) at org.mule.transport.AbstractConnectable$3.doWork(AbstractConnectable.java:238) at org.mule.retry.policies.AbstractPolicyTemplate.execute(AbstractPolicyTemplate.java:67) ... 50 more Caused by: java.
BindException: Address already in use
Most of the time, the condition is not reproducible and re-running the test again would pass. After a lot of investigation/poking around, I traced the cause of the problem to be the OS not releasing the port quickly enough for the next test to use it. This usually happened when the build machine was under high load. That’s where dynamic port testing comes in. Using variable substitution in our Mule test configuration files, I wrote a wrapper test framework class which looks for and assigns free ports to tests so we can avoid the ‘Address already in use’ condition.
If you are writing functional test cases for Mule ESB and would like to use dynamic ports, you simply need to do the following:
There have been bubbles of interest about OSGi in the Java community over recent years. I for one was very excited about the advent of a modular Java platform that freed us from the classloader issues in the JDK manifested best by Jakarta commons-logging (clogging our app servers).
OSGi was going to change everything, dependencies would be completely isolated (no more tripping over conflicting dependency versions), visibility and would be strictly enforced between each ‘bundle’. I was so bought into the promise of OSGi, like many others, I focused our engineering team on making Mule OSGi-enabled.
One of the key point of Mule ESB Management Console (MMC) is facilitating administration of your Mule instances.
On top of all the features we plan for next releases we are starting to think about Mule instance remote bootstrapping. The idea would be to facilitate installation/upgrade of whole mule instances on remote machines, including new ones.
Because the world does not need yet another agent, MMC could leverage SSH to remotely:
* push well known Mule distribution images (eventually customized)
* setup environment
* setup Mule
* start and register in MMC this fresh instance