MuleSource is about to celebrate another milestone with its second annual MuleCon conference for users and developers of the Mule Enterprise Service Bus.
In an exclusive interview with eWEEK at TheServerSide Java Symposium in Las Vegas, MuleSource Chief Technology Officer Ross Mason said MuleSource will present new technology and opportunities for its user base at MuleCon, which runs April 1-2 in San Francisco.
Mason said MuleSource will deliver a new version of its ESB. Moreover, Mason told eWEEK about a couple of projects he hopes to work on in the near future.
"A pet project waiting to happen for me is I'd like to have a generic DSL [domain-specific language] for service consumption," Mason said in the interview with eWEEK. In a subsequent blog post, Mason said: "On the Mule project we need a DSL to make Java-based configuration more usable and intuitive. We are about to embark on this part of the project, but it seems to me that we need to stop and think about the bigger picture."
Mason said he sees two possible ways of defining this DSL. One would be, "Define a set of Java APIs for building services. This would consist of a set of interfaces, some helper builders and well-defined extension guidelines. The problem with this is that it is Java-specific; we really want to write services in other languages such as C# and Ruby."
The other possible method would be to, "Define the DSL in pseudo-code with clear guidelines of how to implement the DSL interface in any language," Mason said. "The actual DSL interface would still need to be implemented for a specific technology, but no matter what technology or platform I am using, the DSL is familiar to me."
Overall, he said, "My preference would be for No. 2, as it would be platform-agnostic and have a much better chance for adoption. But it also has the added benefit that it would create a universally accepted glossary of concepts for constructing SOA [service-oriented architecture]."
Yet, despite acknowledging the need for a DSL in the Mule environment, Mason said, "While I think we'll probably be in DSL hell in about two years where there are thousands of new languages for doing everything and nothing, there is one DSL I would like to propose for Service Composition."
"Essentially, this would use SAAS technologies such as Amazon SQS [Simple Queue Service] as the message bus, S3 [Amazon Simple Storage Service] for data storage and a service container running on EC2 [Amazon Elastic Compute Cloud]," Mason said. "You could then utilize things like Mule's support for REST [Representational State Transfer] to do things like grab events feeds using Atom, and expose and invoke services in a 'REST-ful' way."
Mason founded the Mule project in 2003. "The technology has been battle-tested and we have 2,000-plus people using it in production," Mason said. He noted that the Mule ESB has a breadth of connectivity features, including up to 80 connectors to support integration with technologies such as Java Message Service, IBM's WebSphere MQ and mainframe environments.
"We're one of the few universal ESBs," Mason said. However, when compared with closed-source ESB offerings like Iona and Sonic Software, he said, "they have a lot more tools and all that proprietary IP. But the reason people like to use Mule is its simplicity. And they can build best-of-breed ESB and SOA solutions with Mule because we offer a lot of flexibility."
Indeed, a typical Mule scenario might include WebSphere MQ, Mule, a TIBCO integration solution, and possibly a business process management solution such as JBoss' jBPM or Oracle's BPM offering, Mason said.
"Mule allows you to seamlessly integrate between different providers," he said. The company also has a relationship with SpringSource to support the Spring Framework. "We've always worked pretty well with Spring and integrate well with Spring applications," Mason said.