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.
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,
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.
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:
Most of the time, the condition is not reproducible and re-running the test again would pass.
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,
The Mule team is please to announce the availability of Mule ESB 3.0.1. This is a follow-up release to Mule 3.0.0, which continues MuleSoft’s commitment to making Mule the industry’s most powerful, simplest to use, and innovative open source ESB.
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).
Also, we’ve made a number of changes to the documentation for our latest release of Mule ESB. We hope these improvements will make it easier than ever to get started quickly using our best-of-breed integration platform.
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.
MuleSoft provides the most widely used integration platform for connecting any application, data source or API, whether in the cloud or on-premises. With Anypoint Platform®, MuleSoft delivers a complete integration experience built on proven open source technology, eliminating the pain and cost of point-to-point integration. Anypoint Platform includes CloudHub™ iPaaS, Mule ESB™, and a unified solution for API management™, design and publishing.