In his “To ESB or not to ESB” series of post, Ross Mason has identified four common architectures for which Mule is a great fit: ESB, Hub’n'Spoke, API/Service Layer and . In this post we are going to detail an example for the latter architecture. We will use Mule to build a scalable image resizing service.

Here is the overall architecture of what we intend to build:

As you can see, we allow end users to upload images to a set of load balanced Mule instances. Behind the scene, we rely on Amazon S3 for storing images waiting to be resized and Amazon SQS as the queuing mechanism for the pending resizing jobs. We integrate with any SMTP server for sending the resized image back to the end user’s email box. As the number of users will grow, we will grow the processing grid simply by adding more and more Mule instances: indeed, each instance is configured exactly the same way so the solution can easily be scaled horizontally.

Read on to discover how easy Mule makes the construction of such a processing grid…

Ross Mason on Monday, July 29, 2013

Raspberry Pi gets an API


In the Internet of things no device is an island. And while Raspberry Pi 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 ‘ 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.

I just read yet another amazing achievement in the world of 3D printing: directly printing sand-grain-sized rechargeable batteries. It’s not that manufacturing things at that scale is revolutionary any more, it’s that we can see the path to mass accessibility: anyone will soon be able to do this. Just like desktop publishing, and later the web, and later any of a slew of self-expression and DIY-distribution possibilities like Facebook and YouTube and Twitter, that accessibility and enablement will surely create Yet Another Revolution (TM). No doubt.

Uri on Wednesday, July 24, 2013

Mind Your APX


There’s a saying that goes something like: to err is human, to really screw up big time takes a computer. But if you really want to have some fun, connect that computer to another computer, and you soon have a veritable nuclear chain reaction. The key to unlocking this energy? The lowly API, a programmer’s best friend, the little enabler that placed Google Maps in the center of mashup mania, drove the Ajax revolution, and is now generating over half of’s revenues.

You may have read about our mountain trek, new release cycle, and the increased pace of delivering. We’ve  climbed our first mountain and we’re happy to announce the availability of our first release in our trek: Andes! This delivers major usability improvements around our platform, new connectivity to applications such as Marketo and ZenDesk, and expanded API management capabilities. We’ll summarize what’s new for you here and we’ll be doing deeper dives over the coming days for you to learn more.

Ken Yagen on Monday, July 22, 2013

Climbing mountains faster


In a recent post, James outlined how MuleSoft is using Lean Startup principles to build Enterprise Software. We have been doing this for a while in our cloud platformsCloudHub, Anypoint Service Registry and; however, our core enterprise tools and products – Mule ESB, Mule Studio, Anypoint DataMapper, and Mule Management Console have always been on a much longer release cadence. Mule ESB Enterprise is the core platform on which many of our customers build hundreds if not thousands of services and integration processes on, so frequent releases and updates can be expensive for them to consume. Typically we release new Mule ESB enterprise versions every 9 months. As a hybrid product company with multiple products, we need to manage the demands of both the cloud and on-premise. Recently, we decided to make some changes to our development cycles and team orientation. We’re using names of famous  mountain ranges for these new releases, the first is named Andes after the iconic mountain range in South America (relatively) close to our development labs in Buenos Aires, Argentina. The next is Big Horn, Cascade and then Dolomite.

james.donelan on Thursday, July 18, 2013

Lean Startup…meet Enterprise


There is a lot of talk about the lean startup and whether it works or not. Some proclaim it is critical to the success of any startup and that it is even the DNA of any modern startup. Others claim that it’s unproven, unscientific and gets your product to market in a haphazard way that is ungrounded in quality.

But the lean startup model, when you boil it down, simply says that when you launch any new business or product you do so based on validated learning, experimentation and frequent releases which allow you to measure and gain valuable customer feedback. In other words, build fast, release often, measure, learn and repeat.

john.demic on Tuesday, July 16, 2013

Getting started with JPA and Mule


Working with managed entities in Mule applications can be difficult.  Since the session is not propagated between message processors, transformers are typically needed to produce an entity from a message’s payload, pass it to a component for processing, then serialize it back to an un-proxied representation for further processing.

Transactions have been complicated too.  Its difficult to coordinate a transaction between multiple components that are operating with JPA entity payloads.  Finally the lack of support for JPA queries makes it difficult to  load objects without working with raw SQL and the JDBC transport.

In the new enterprise, the “one big database” paradigm is being progressively eroded as it becomes more apparent that the ACID qualities of traditional SQL are not always needed, and can actually get in the way of massive scalability. In order to respond to the imperative of cloud deployments, new data stores have emerged.

One of them is Riak, a highly-available, fault-tolerant and scalable distributed key-value store built by Basho Technologies, Inc. on the design principles laid out in the famous Amazon Dynamo paper. One of the key features of Riak is that it “embraces failure” in the sense that, instead of sweeping under the carpet the problematic scenarios (like net-splits), it provides developers with the tools needed to deal with these issues as part of the normal operation mode instead of a leaving them to a (seldom addressed) failure mode. As such, data in Riak is said to be “eventually consistent” because it is only when all the pending replications have been done and the related conflicts have been resolved that data is consistent.

The new Riak Connector for Mule allows you to interact with this data store from your Mule applications, opening the door to new integration scenarios. Let’s review an example of such a scenario.

users have always felt at home in Mule Studio, but users have often asked for to “play well with others” — specifically, that it support plugin-style into existing Eclipse environments they already use every day.

With Mule Studio 3.4, we have delivered this wish list item. Specifically, users of Eclipse 3.8 can now install Mule Studio as plugins into their existing environments.

The old-fashioned way to do this is via the Eclipse Update Manager, using the update site

Screenshot of Eclipse Update Manager with Mule Eclipse Plugin Install Site

Using the Mule Eclipse Plugin Install Site