The alarms go off. You get an alert on your cellphone. You look at your systems dashboard and notice that your Mule server, which was happily chewing messages until just a minute ago, is struggling. What can you do?
We recently pushed out an update to iON which makes building APIs in the cloud better than ever: zero downtime upgrades. Without you having to do anything, we ensure that your application is able to continually serve requests while you’re updating it.
The way this works is simple. Let’s say you have version 1.0 of your application in production and you’re about to release version 2.0. Because version 2.0 may take a few moments to start, iON will keep version 1.0 running while version 2.0 starts. Once version 2.0 is fully started, iON will update your domain name to point to your new Mule instance and shut down version 1.0. With no operations team at all, you’ll have managed to implement what many API providers find extremely challenging to do!
I just read a good post by Sam Charrington on RWW titled, The Disintegration of PaaS. He points out that early PaaS vendors had to build out the whole stack, including application server, database, file storage, etc. This locks applications into a specific stack. He goes on to say that we are now moving into a new evolution of PaaS, where some of the component pieces of the platform, e.g., databases, are available from other service vendors. However, the change we’re seeing is much broader than PaaS. This shift picks at the very fabric of software; we are witnessing the revolution of software development as we know it.
Last month we released Mule 3.3 M1, our first milestone on the way to Mule 3.3. While for production you should use Mule 3.2.1, we hope these milestones are a great way to play around with the latest and greatest features. This is a great opportunity to provide feedback and have an impact on what we are doing for the Mule 3.3 release.
Mule allows us to expose services to the web through CXF, but what happens when these services handle sensitive information that we don’t want just anybody to read or change? We need to be able to authenticate who is consuming the Web service and determine if the user should have access to the service or not.
Complex event processing engines are a natural fit for event driven platforms like Mule. Native CEP support has been available in Mule since version 3.2 by way of the Drools Module. The Esper Module now offers an alternate way to leverage CEP in your integration applications. Esper is a robust, performant, open source, complex event processing engine. Let’s take a look at how to use Esper with Mule and then see how it compares to Drools’ CEP support.
This question boils down to one thing: are you part of the transaction or not?
Data Integration grew out of the adoption of relational databases and the need to move information between them. Typically, data integration is batch-orientated and deals with data at rest. In other words, the process that created the data has already completed.
Application Integration, on the other hand, deals with integrating live operational data in real-time between two or more applications. Typically an “event” will occur. For instance, when a customer places an order, this triggers an integration flow that updates and enriches data in other applications in real-time.
Think an easier, more accessible way to build applications is only a dream?
With the release of Mule Studio, the graphical design tool for Mule, integration will never again be the same. Mule Studio is, by far, the easiest and most accessible way to build integration applications. Mule Studio also has no secrets, which means you have full control over the code for ease of use and flexibility.
Mateo Almenta Reca, Director of Product Management at MuleSoft, will take us through the functionality and highlights of Mule Studio, with demonstrations and focus on:
If you want to avoid including configuration parameters (probably connection related parameters) in your Mule configuration, you can use property placeholders, which will allow you to upload these parameters from a properties file. This enables you, for example, to have different property files for different environments (Dev, QA, Prod) or allows you to reuse the same value in different parts of your configuration.