Hi, my name is Ryan Slobojan, and I'm here with Ross Mason of MuleSource. Could you please tell us a little bit about Mule, give us the overview of what it is?

Sure. So, Mule is an open source project that I founded in 2003. It's goal is to be... it's an integration platform and an ESB. What that really means is that we focus a lot of different features around how you actually move information around the enterprise and integrate different applications together. Mule itself is a service container and it provides services for mediation, for transporting information, for orchestration and also message routing. It gives you all the tools you need to actually move information around your organization using transactions, having it fully monitored, fully secure and things like that.

What is the role of an Enterprise Service Bus, or an ESB, inside of an application?

Well, usually the ESB... Most people, they understand the ESB looks like it has a message bus in between and applications hanging off either side of it, and the point of that is, is that you get all these applications talking over the bus rather than directly. That way, you remove the point-to-point integration that doesn't scale very well and locks you into a brittle architecture. ESBs in the market place, in the marketeering that goes around, they've been been bloated to all sorts of things, but essentially an ESB is really about being able to connect your applications and do message routing, but essentially... people don't often use an ESB with an ESB deployment - there are other ways of using it such as like an Enterprise broker, so rather than having a message bus, they have a number of services that all sit in 1 or 2 or 3 instances that is clustered and then they use that to do their integration. Certainly, with Mule you have a lot of flexibility, you don't have to do the ESB route, you can do even client server or sort of enterprise broker type of deployments, as well.

There are 2 versions of Mule which currently exist: there is Mule Enterprise and the open source version of Mule. What are the differences between the two?

Good question. So, the open source version of Mule is the same Mule that has always been. We actually continue to build open source features into it. The enterprise offering builds on top of the open source version, but gives you premium connectors and premium features around how you manage reconnections to things that get lost. We have some tooling, so we have a management monitoring console for monitoring Mule instances and obviously, in Enterprise you also get the support from MuleSource.

So the model is kind of nice, I think... There's lots of different types of commercial open models you can use, but with Mule we have actually decided to go with this, "keep developing the community but add enterprise value in additional modules on top". But what it does mean is that when people are adopting our technology, there's a very easy migration path to EE but also from EE because that it's very clear whether you are using EE or CE.

One of the other areas that you had mentioned was the idea of monitoring. Can you describe more how you would monitor a Mule installation?

We have a monitoring product called MuleHQ; it gives you a 360 view of your environment on any given box. So the way it works is there's a small agent that sits on the box and discovers different types of application servers or the operating system and obviously Mule and other pieces. What the monitoring tool allows you to do is actually discover Mule instances in your network and actually manage them all from one place. So at a very high level you can see whether everything is fine or if there is a red light somewhere. You can actually then drill down and you can see things like where the CPU utilization was at that time, how many files were open, any logs - because the logs are also sort of time indexed. It's a very easy way to actually monitor but also troubleshoot things that go wrong.

What environments or solutions is Mule a good fit for?

It is used in a variety of areas, I tend not to say it's a jack of all trades, but we get used a lot within the enterprise, so inside the firewall and typically those sort of applications are message-centric, sometimes XML-centric, sometimes legacy formats. We also see a fair bit of web services work, both in the enterprise, but also another sort of pattern of customer we have is gateways to the outside world that use web services there for their partners - like a B2B type of scenario. The third trend we're seeing and which I think is very interesting and is widening the appeal of Mule is the REST interfaces. How do you leverage the power of Mule from the web? Dan Diephouse was having a talk here about that, but we have a REST pack that sits on top of Mule and gives it a lot of features to be able to build RESTful-type services.

Mule supports both the WS-* stack and the REST stack? One of the other questions which comes to my mind is that, it seems that with Mule being an integration layer, that there might be potential for using it as a component of a cloud-based deployment?

We are actually already seeing that. A lot of the new guys like Cloudera for example are thinking of using it. There is CohesiveFT, who have deployment stories for putting Mule on the cloud. We also have some customer references like OpSource who use us as their cloud infrastructure to do provisioning. We are quite a good fit on the cloud as well, because of the lightweight nature, and with Galaxy for governance, it makes it easier to just deploy things on the cloud where you don't really have full control over the environment.

You mentioned Galaxy. Can you describe a little further what that is?

Sure. So Galaxy is our newest product, it's been around for a little while now - we are on version 1.5. Essentially it's in 2 pieces: it's a registry, and it's an SOA governance platform. The registry most people understand to be looking after service artifacts; Galaxy goes a step further and allows you to look after all types of artifacts that you typically would deploy inside an organization.

So some registries only deal with WSDLs, we obviously deal with that, but we deal with things like JARs with annotated service components in - so, JAX-RS or JAX-WS - and we actually index those, you can discover them. Also things like BPEL configurations. We could even support things like JBI and SCA - we don't at the moment, but it's a very extensible model to do that. So that's the registry side, and what the registry gives you is control over lifecycle, dependency management and deployment.

It provides a 360 view of what you are really running inside your organization, but the good thing is it allows people to collaborate because they can see other services as they are made available. Essentially, it's sort of a one-stop-shop to understand what's running inside your organization. On the governance side, there is a whole set of policies you might want to actually enforce when you create a new artifact. So for example, I have a Mule configuration, I want to make sure that all my endpoints are always secured, so I don't have people putting any configuration into a test environment where it's not secure, so I can set up policies like that very easily. You can do the same for Spring configurations, you can do the same for, again, JAR artifacts, OSGi bundles, as well. It's kind of a Web 2.0 meets governance really - you have access to all the cool features and it's actually very usable.

You mentioned Spring and OSGi. What other integrations exist and how are those combined into Mule? Were they created by you? Where they created by the community?

There are literally hundreds of integrations. Spring is one - we actually use Spring for our XML configuration. By having that integration it means that we can do all the nice things in Spring, but you are still dealing with Mule under the covers. We have a lot of connectivity options. I think, shipped with the product there's probably about 35 and they cover everything from JMS, web services, REST, file, HTTP, XMPP - all sorts of different protocols. That's with the standard distribution, but then we also have the MuleForge.org, which is a place where our community actually submits projects.

So they might create small things like transformers, or bigger things like a transport. On there, there is probably another 90-100 projects at the moment and it's very active, there is a lot of stuff happening there. To give you an idea, there's things like AS/400 data queue support there, there is terminal support, there's integration with things like Guice, so there is... it's a good forum where the community actually builds up cool features. Honestly, running a big open source project like Mule, you get a lot of contributions from people and you really want to make sure that they're exercised to the fullest. Having the Forge really helps us deal with the huge flux of input we get from our community.

Given the current economic situation, what impact has that had upon MuleSource and other open source companies?

It's interesting - I think it depends where you are on the curve for open source. Guys like us, Alfresco, SugarCRM, they already had a sort of a fairly baked-up model and were making money. With the downturn of the economy, what it's done is cause people to re-evaluate what they are spending money on and ensuring that they are getting the right value out of what they are paying for.

Certainly I've seen it... I talked to other open source companies and they're seeing a real uptake in the last 2 quarters as people start saying, "Well hang on a minute! I'm paying 3 million to BEA here, but I can use an open source app server, or I can use an open source ESB." It's causing the guys that were sitting on the fence wondering about open source just to take the plunge because it's by far the most cost-effective option. The total cost of ownership and the time-to-market, given that these tools are open source is very appealing. It's something we've been barking on about for a long time, but I think we needed a big change in the market to make people really listen to it.

What are your future plans both around Mule and around Galaxy?

We are going to be doing a lot more stuff to integrate the two better, so we can do more runtime monitoring and management through Galaxy on Mule. OSGi has been a feature of our roadmap for about a year - again, what we've tried not to do is sort of come out with a big bang like "Hey, we're OSGi compliant" but actually do nothing with it. That isn't in the works; we've got a lot of it done, but there's still more we want to do there. Also more integrations into other platforms as they come up because there is always good software coming out and things maturing and we know we work with open source and closed-source partners to offer the best solutions for customers.