Today I would like to talk a little bit about releasing a new version of your Mule extensions. As you may know Mule is a an extensible platform with well defined integration points for plugging in your own connectors transformations, components and even routers. Suppose you have used The Mule Devkit to create your very own extension or cloud connector, and your project is so cool that it was accepted on MuleForge.
Mark Zuckerberg once said: “How can you connect the world if you leave out China”. Well, I now at this moment say: “How can you connect the cloud if you leave out Google.” I know I don’t have his net worth, but I have a point nevertheless. The reality is that Google has done a great job building a Gazillion of different and very cool APIs, and you’d be right to feel that it’s hard to keep their pace.
Mule ESB 3.3.1 represents a significant amount of effort on the back of Mule ESB 3.3 and our happiness with the result is multiplied by the number of products that are part of this release. We are releasing new versions with multiple enhancements and bug fixes to all of the major stack components in our Enterprise Edition. This includes:
The DevKit is a tool for accelerating the development of Mule extensions. A popular Mule extension is what we call a Cloud Connector. A Cloud Connector provides Mule with the ability to receive and send messages to/from a cloud service provider. We do not make assumptions about whether that service provider is a REST-based service, a SOAP endpoint or a custom protocol on top of TCP. Having said that,
Less than a month ago we released the DevKit 3.0 and we are on a roll here. Just in case you are jumping onto the bandwagon a little late, the DevKit is a tool for authoring Mule extensions. The model is quite easy. First you write a POJO, then you annotate your POJO with Mule concepts and then when you run DevKit on the code you authored it will generate all the needed boiler plate code including a Mule-compatible schema.
One of my favorite patterns from Michael Nygard’s excellent Release It! is the Circuit Breaker. A circuit breaker is an automatic switch that stops the flow of electricity in the event of a failure. This sort of behavior is also useful when integrating with remote systems.
We might want to stop message delivery on an outbound-endpoint after a certain exception is thrown. A remote system under load or the target of a denial-of-service attach is a good example.
Validating data can be easy with Mule if your message payloads are in certain formats. XML payloads, for instance, can be verified for correctness via XML schema or XPath filters. Payload type filters and OGNL expression evaluation can go a long way in asserting your POJO payloads are correct. Payloads with less structure, like Map or JSON data, are a little bit trickier to validate. This is particularly true on the front-end of web-services where leniency in data format,
In this blog post I will show how to extend Mule in a simple way using the recently released Mule DevKit. The goal of the Mule DevKit is to accelerate the development of Mule extensions by abstracting you from Mule specific stuff so that you just focus on what your are trying to build.
My idea here is to create a simple Cloud Connector to interact with Google Maps API but the concepts covered here can be used in other scenarios as well.
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.