Mule Clustering is the easiest way to transparently synchronize state across Mule applications in a single data center. Mule Clustering, however, assumes that the Mule nodes are “close” to each other , typically on the same network, in terms of network topology. This allows Mule applications to be developed independently from the underlying cluster technology and not to explicitly account for scenarios like network latency or cluster partitioning.
These assumptions aren’t as sound when dealing with multi data center deployments. Unless you’re lucky enough to have fast and reliable interconnects between your DC’s you need to start accounting for latency between datacenters, the remote data center going offline, etc. In such situations the choice of a data synchronization mechanism becomes paramount.
Suppose that you have a Maven project and you want to download Node.js modules previously uploaded to NPM. One way of doing that without running node is by using the npm-maven-plugin. It allows the user to download the required Node modules without running node.js: It is completely implemented on the JVM.
First of all you will need to add the Mule Maven repo to you pom.xml file:
After doing that, you will need to add the following to the build->plugin section of your pom.xml file:
You probably heard we have been moving into a faster release cadence with the new mountain ranges releases in this post and this one. For many Product Managers or Business Owners releasing faster could be the difference between success and failure. Being able to shorten the cycle between an idea and valuable user feedback enables new companies to understand better market needs and improve based on it. Releasing valuable software earlier is the sweet spot for Agile and Lean methodologies.
Mule is already running on premise and in the cloud and is soon bound to run virtually everywhere thanks to a new project called Anypoint Edge. This initiative not only focuses on allowing Mule to run on lightweight platforms, like the Raspberry Pi, but also to support protocols and devices relevant to the embedded world, like MQTT and Zigbee. The “Internet of things” had its rabbit, it’s now going to have its Mule!
If you follow this blog, you may remember that we’ve already discussed MQTT before. We’ve introduced the Mule connector for this lightweight publish/subscribe protocol with an example where MQTT was used in the context of conference booth QR Code scanners. In this post, we’re circling back to this example but we add a new twist to it: we’re taking it to the Edge!
In the original architecture, Mule was running on a laptop, using its webcam to scan QR Codes but now that Mule is able to run on the Raspberry Pi, we will revisit the example to run on this tiny device. We will also use the brand new blink(1) connector, which will allow us to use this smart USB RGB LED to flash a visual confirmation when the scan correctly happened.
So let’s start by reviewing our architecture diagram and let’s unroll the example from there.
When we started thinking about the August 2013 release we decided to take it one step forward and make it easier than ever. And now that Mule 3.5-andes is available on CloudHub, you’ll be able to leverage all these improvements into your integrations. On Premise users will also be able to use when the final version of Mule 3.5.0 is released as GA.
In the Internet of things no device is an island. And while Raspberry Pi devices are pretty cool on their own adding an API makes them a lot more interesting. We have been playing around with Raspberry for a while now and have a small distribution of Mule, called ‘Anypoint Edge’ that happily runs on small embeddable devices like the Raspberry Pi. These ARM-based devices are taking the world by storm since they are lower powered, low cost and can be embedded into small hubs to control other things like lightbulbs, or be used inside anything from PoS kiosks to gas pumps to cars to medical devices.