eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.
MuleSource pulls big integration load
Mason said he decided to create MuleSource after years of working in financial services institutions with large IT needs. In one instance, “We were integrating six or seven back-end systems and there was a recurring pattern where up to 90 percent of the code we were doing was applicable to the next integration.” That gave Mason the idea to write MuleSource to handle that big part of the integration load. “A mule is a beast of burden and Mule can carry your payload,” Mason said.
MuleSource is a Java-based solution. However, Mason said he initially tried to create the product using Web services, “but the performance was not up to par,” so he moved to Java, he said.
Mason said MuleSource prototyped an online version of Mule “for simple interaction between ‘clouds.'” He added, “So we did a prototype of Mule in the cloud,” but the company has not created an on-demand version of the Mule technology for widespread use.
Chris Haddad, an analyst with Burton Group, summarized his view of Mule by saying, “If you want a lightweight, integration-centric ESB, you appreciate open source, and you have reasonably sophisticated developers, you’ll probably like Mule.”
“If you’re looking for a solution with a lot more bells and whistles and integration with third-party SOA infrastructure components, you should look elsewhere,” Haddad said. “Keep a close watch on MuleSource products; they hired a top-gun team, are rapidly closing the feature-function gap, and are a good strategic bet based on current feature breadth, mind share and future innovations.”
Moreover, Jason Bloomberg, an analyst with ZapThink, said he believes that of all the open-source ESB offerings, MuleSource is rapidly rising to the top as one of the most popular. Yet, “Be that as it may, there are still two huge challenges the ESB market faces: Too many organizations wrongly believe that buying an ESB can give them SOA, and there’s no single definition of ESB in the marketplace,” Bloomberg said.
In MuleSource’s case, Bloomberg said, its definition of an ESB is a lightweight messaging framework that contains a distributable object broker for managing communication between applications.
“The objects they are brokering are Java objects, making Mule a Java-only ESB, which is suitable for some organizations, but too limiting for others,” Bloomberg said. “It could also be argued that an object broker is not the best approach to an ESB. But regardless of Mule’s capabilities, organizations must let their architecture drive their technology selection in order to succeed with their SOA initiatives, not the other way around.”