Anyone that has used DevKit to write a Mule extension and then wanted to add it to Studio, may have notice that the extension will appear under the Cloud Connectors category in the palette. This is not a problem when the extension is actually a Cloud Connector, but is sort of a problem when it was something else (for example a component like the LDAP connector). This is not an issue anymore since DevKit 3.3.2, as you can now use the @Category annotation at class definition level (Connector or Module) to select under which category you want your extension to be listed in:
Google Apps offers a cloud alternative to many of the office products. If you have a Gmail account then you have Google Apps including Spreadsheets, Docs, Presentations, Contacts, Calendars and Tasks. Of course Google Apps have APIS and of course we have the connectors to make it easy to connect Google Apps and your applications together. Lets get the connectors and then take a look at what you can do.
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.
What happens if you make changes to you project and it moves from version 1.0 to 1.1? We’ll take a very quick look at how to do that in this post.
First, modify your pom.xml to increase your version number. In this case, we’ll go from 1.0 to 1.1:
Mark Zuckenberg once said: “How can you connect the world if you leave out China”. Well, I now hereby 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. 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. To help you with that is that we proudly present to you the first release of the Google Cloud Connectors Suite.
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, we do offer certain services for some types of service providers. In this post I’m going to be talking about connection management, a feature in the DevKit that provides management and sharing of connections for those service providers that have stateful protocols.
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. Sounds exciting, isn’t it? Unfortunately this blog post is all about whats change since the last release, but if you want to learn more you can do so at our website here.
We added several features in this release but to keep this blog post short I will cover just a few of them.
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. In this scenario it would be nice to automatically stop delivery for a certain period of time to not exacerbate the situation.
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, particularly JSON, can be beneficial. In these cases a custom Message Processor is usually necessary to filter or sanitise the data.