I think Sun is making good progress. A lot of our customers are taking a lightweight approach. They don't necessarily need a lot of the stuff in Java EE, so I think the Profile thing has been a good move for Sun, but it's a ways out. Right now we see a lot of people doing a best-of-breed approach, which is how we get brought in. People say: "Okay, I'm going to use JMS. I'm going to use Spring. And I'm going bring in Mule for integration. It [Java EE] is progressing in the right direction, but I still see people doing best-of-breed approach for a while. Is it possible that best-of-breed will be the best approach in the long run?
Personally, I think it's the best approach. A lot of people are looking for something out of the box, but what people are using is best-of-breed. They're using JMS and Spring and Mule. Spring seems to be very popular with developers. Are you seeing a lot of use of it?
A lot of our users use it. Mule actually bundles Spring so our configuration is built on top of Spring. It's a very powerful lightweight framework. It's pretty pervasive. If Spring is pervasive, what are your thoughts on EJB? If given your druthers of going down the Spring or EJB route, which one do you prefer?
I prefer to go the Spring route because it's way simpler. They've got so much stuff built in there that's easy to use. Turning to your work at MuleSource, what are you focusing on? What new things are we going to be seeing in the coming months?
You may be familiar with Galaxy, our registry/repository. We looked at the market and we saw an opportunity for an open source registry/repository. We see a need for people to manage their services and applications, but there's a larger need as well for the open source community because the whole registry space is something that one of my colleagues calls "a rich man's sport." It's very expensive to get into. The solutions are very Web services centric, which doesn't necessarily reflect a lot of developer infrastructures these days. A lot of people are doing RESTful stuff and other things, but you still need to be able to manage all these things. Registry/repositories are expensive, they're Web services-centric, they can be heavyweight, and they don't integrate with open source tools. So when we started off on our own registry/repository we said let's develop this in an open source manner. Let's make it lightweight. Let's make it easy to use. Let's make it integrate with all the tools that developers use from mainframes to Spring to Mule. Let's make it extensible through a RESTful API. Let's use the Atom Publishing Protocol API, which people can tie into and is a lot easier to use than UDDI.
So we're just trying to build a solution that people need and can use and help educate people on how to use it. So my primary focus at the moment is working to build this out. What's the status of the Mule Galaxy registry/repository project at the moment? Are you in beta with it?
We're in beta right now. We're going GA here in May, so this month we'll have our 1.0 GA. In June, we'll have an enterprise version. You've mentioned REST and Atom, but can you give us more details on what will be available when Galaxy goes GA? What will developers find when they download the GA version?
At the core of it is an extensible artifact and metadata repository, so you can store things in it and manage the metadata. Then we've added features around it like lifecycle management for services or artifacts so I can ask: "What in the repository is in QA? What is in production?" There's dependency management so I can visualize what other things are dependent on this artifact or WSDL. That gives you a better idea of who is using what, and backwards compatibility, that sort of thing. There's a policy management piece so I can enforce policy. I can say: "I need to ensure all WSDLs are WS-I Basic Profile compliant." So we have a policy inside Galaxy that is actually enforced and we'll make sure all WSDLs are WS-I Basic Profile compliant, so they'll be interoperable with all the other Web services that are out there. There are also security policies that you can apply. You can say: "I need to ensure that everybody uses WS-Security in their Web services." The policy management piece is pretty important. Then there's this visibility collaboration piece. Customers may have hundreds of services and they need help just being able to figure out what services are available to people and how to actually use those.
So one of the cool things actually is not only can we work with Web services, we can work with things like OSGi services. A customer might have all their services inside JARs or OSGi bundles. You want to be able to index and search for these from the IDE. So within Galaxy they are all searchable, query-able. You can see what's out there. Then with the Atom API, a very simple plug-in, you can pull things out and visualize as a developer in your IDE what services are available. You can click and see what's available. Contrasting it with other registry/repository offerings, what are Galaxy's advantages?
One of our advantages is we're not so focused on Web services. We try to work with anything. Two, we're open source so we're very accessible. We already have people coming in and writing plug-ins for various platforms that might not come bundled with a registry/repository. Another advantage is we integrate with the open source infrastructure that's already out there like Maven, Spring, Mule, Apache. And again it's very easy to write your own plug-in.
Dig Deeper on Development implications of microservices architecture