Cloud’s really changed the landscape in the way we think about deploying things. I don’t think today people are really rushing there and saying "We got to go and build applications there", but there is certainly a lot of focus from vendors in the industry at large. From the integration side, we just released Mule 3. One of the big things we had in there was the Mule Cloud Connect and this is a trend we’re all seeing in that you still have a lot of data behind the firewall, even though data is moving slowly into the Cloud. How do I integrate that data with all the great stuff that’s out there? Whether it’s Facebook or interacting with Twitter or using any one of these other social media platforms or even SaaS applications.
Typically, if people are doing integration in the Cloud with Mule, it’s always Salesforce and some other things. What’s interesting there for integration is what we can do to help manage that flow of information from behind the firewall and outside the firewall. That’s what we’re focusing now with Mule 3 and beyond.
2. How has Mule changed over the years and what are the main reasons to use it now?
ESB’s and integration has changed generationally. The first generation was the proprietary products fairly heavy weight. The second generation I think was Mule and the things that followed where there was much lighter developer focused easy to scale up and down and test and things like that. I think generation three is getting outside the firewall and that both means "How do I integrate outside the firewall?" but we also have customers for example who run this on Amazon EC2 and they integrate just Cloud applications. There is enough information out there now to build apps that way. I think the third generation ESB ultimately is going to end running in the Cloud. We were exploring models with various partners right now on doing that, so you can expect to hear more messaging from us over the next 6 months about what we’re doing in the Cloud, above and beyond Mule Cloud Connect.
3. What does it mean for an ESB to run in the Cloud?
I think there is a big debate on it. There are two schools of thought: you’ve got the CastIron’s of the world who do the browser-based point and click integration. That’s good for departmental stuff, but it doesn’t scale very well. Then the other side, what’s interesting and I’m exploring is what services do an ESB offer that you’d want as an infrastructure app, whether it’s queuing, task management, just mashing up some of the stuff that’s already out there, but making it really easy through that kind of interface. Ultimately, the ESB in the Cloud today, looks like the ESB behind the firewall, but integrating with Cloud apps. I think there is a lot more scope of the kind of things you can do and the services you can provide to people. One idea I like is: if I’m an app developer I don’t really want to think about ESB, but if I want to offload certain tasks, I should be able to do that through the SaaS interface.
I think it’s still very early. I think what we are seeing is one reason to have the ESB in the Cloud is just not to own the infrastructure. That’s the obvious one and the challenge there is once it’s out there, if you need enterprise data, do you have ways of getting the enterprise data and connecting it with the Cloud data? Mule provides things there; we can do more there as well to make it super streamlined. I think beyond that, the use cases are wide open right now. fFr example, we have some customers who have self-service portals in the Cloud using Salesforce, Marketo, Success factors -they’ve gone almost completely without a datacenter inside their organization and they are just using Mule to connect this stuff together.
5. Mule 3 recently came out. Tell us what’ new and what’s interesting.
I’m very excited about Mule 3 - it’s our third generation product. Actually I had one remit for the team, which was "Make everything simpler" and that’s an ongoing thing. In 3.0 we made a lot of things simpler in the architecture, in the way you configure it and also even in the documentation how you navigate between things. I will continue to do that because I think the way you win in middleware is not through features but through simplicity. That’s the thing that really hurts people: that it’s all still too complicated.
Feature-wise, what we looked at Mule 3; there were three areas; there was Mule Cloud Connect that I mentioned and that consists of basically a set of connectors for different SaaS and social media platforms like Facebook and Twitter and Salesforce and the Amazon APIs and Google APIs.That’s being given a lot of attention; people seem to be interested in going in that direction.
With that we actually made REST a core part of the platform. Mule supported REST since 2007, but it was almost like a companion to the ESB. I now believe that REST is really taking over web services; I think it’s a much better way for certain types of applications to communicate over the web. We’ve put REST at cores. It is now very easy to consume and produce RESTful services and we’ve also added better support for Atom, so you can publish and consume feeds very easily.
Another interesting thing I don’t think anyone else have done is we made JSON a first-class data format. ESB is almost always XML-based. We’ve never been focused on just XML, we’ve handled everything, but by putting JSON as a first-class citizen, you can now bind JSON objects, there are a lot of good transformation options for JSON and we even developed our own query language for JSON to make it easier to do things like Xpath queries on that.
6. In what kind of Scenarios would someone want to use JSON to talk to an ESB?
There are a number of scenarios. We see a lot more people publishing RESTful services from our platform and they do that either because they got this hairy backend systems but they want a RESTful API in front of it and they can just use Jersey and bind with JSON - that’s a common task. JSON is a much better format for mobile on the web. Javascript has native support for it, a lot of the mobile platforms are now using Javascript as the frontend language as well, so it’s a very good interchange format and it’s easier to optimize than XML as well. XML is just harder to use generally and probably it should be reserved for enterprise.
The other thing we are seeing people do is actually front existing APIs to make them simpler. And we’re doing this with about 4-5 customers and there are a bunch more in the pipeline, where they’ve really got APIs or they’ve made acquisitions and they got all these different APIs and they are putting Mule in front as an API layer to just clean up and put out a single interface. There are some interesting directions we could go around throttling and things like that, but there are also good companies out there doing that today.
7. Do you see Mule as potentially being the backend to mobile and client browser applications?
We’re really seeing it. There are two ways of looking at that: one is the server takes care of the presentation that takes the client and formats it correctly, but that’s not really what the world is being pushed in the app store. The app store is "I write an app in the native language on the native widget platform of the phone that I’m using and I get a better user experience." If you are doing that, what you really need from the server is a purely data interchange format and that fits perfectly in what we do. That’s what we’ve been doing for years.
So yes, I personally am very interested in exploring that further and seeing what else we can enable there and who we can partner with in the mobile space - the guys like PhoneGap and Strobe and those guys are doing some interesting stuff. It’s still early days, we’re still learning. We, now, as an enterprise company are just coming outside the firewall and the next step is to go to the mobile, but yet it’s a fascinating space for me, for sure.
With mobile it’s pretty interesting because it actually changes the dynamic of the typical application architecture that we’ve been used to building. I think you still have a three-tier architecture and you have a presentation tier, a logic tier and a data tier, but the role of the data tier has changed dramatically. It’s no longer just a database, but it’s all sorts of other things, whether that would be SaaS applications, different data storage formats, unstructured data like Hadoop and of course databases themselves. I think the role there has changed: you want a tool that helps you work with those types of things.
The logic on the server remains quite the same, which is good because you want something to anchor on. What really changes is the presentation. We’re very used to building Struts or Spring apps or JSF where the server renders the markup and we send it to the browser. That doesn’t work for mobile because mobile doesn’t know how to render that. it knows to render it, but it’s not rendered for its platform. What you really want is the data going to the mobile and then the presentation tier is handled by the mobile device. They are smart enough to do that, they have the kits. I think that’s one big change, that the location of the presentation tier gets moved down to the device that’s rendering it and this is exactly what Javascript does in the browser as well. It’s the same thing. I really like that model; it provides a nice, clean separation.
I see other frameworks out there trying to change the way they format the data for the device and we’ve done that with WAP and other things. It doesn’t really work that well. What you want for the best experience is for the device to read the data and know how to format it. That’s very interesting, that’s where the ESB then sits because we can manage the logic on the data side of things and you delegate all the presentation to either the browser or the mobile device.