Welcome to OpenESB community blog center where OpenESB people and users exchange views about the project, the best practices, the new requirements and its future. Your comment and feedback helps us to stay in touch together
This week searching some information on Google, I typed “OpenESB vs …” and I got an interesting link from our competitor but friend “Mulesoft” (www.mulsoft.com) where one of their writers compares Mule with OpenESB (http://www.mulesoft.com/understanding-integration-needs-based-perspective-mule-vs-open-esb-glassfish-esb). It is understandable that a software editor compares his product with that of the competitors and he does his best to promote his product and emphasise its best parts. On the other hand it is fair that the editor hits the competitor where it hurts the most. However, when reading the document, I was amazed by the writer’s arguments weakness and his poor understanding of OpenESB and integration knowledge in general. The first part of this paper has been written in a way that shows how Mule’s writer arguments are weak and flimsy. In the second part I took great pleasure to show from my point of view, how OpenESB is far superior to Mule when we want to design and implement more than simple point to point integration and we want to implement real and complex business processes or composite applications. Of course this is just my point of view!!!
In order to demonstrate OpenESB is not good for integration, Mule’s author talks about JBI, WSDL imposed by JBI, JBI vs. OSGI, JBI and finally JBI. But what is JBI?
JBI is a specification issued in 2005 by Sun Microsystem (www.jcp.org/en/jsr/detail?id=208) that describes a clever and powerful architecture to build integration tools based on Java. As explained at the beginning of the specification: The primary audience for this specification is system level software engineers who will develop the following: “implementations of the JBI infrastructure itself” …… This specification is not appropriate for application developers or business analysts.
So, thousands of OpenESB users develop powerful, reliable and scalable applications with OpenESB without any JBI understanding. JBI is part of the internal OpenESB Architecture. The general OpenESB users need not to worry about or understand it any more than the ones who use Oracle SOA Suite, WebSphere Middleware or Mule internal architecture? We all need simple, productive and efficient tools to develop and implement our project.
Everyone aware about SOA/ESB history knows that JBI specifications did not have the same audience than JEE specifications and was not accepted by large vendors like BEA and IBM not for technical reasons, but because they wanted to protect their new ESB product (Aqualogic and Websphere). JBI has many advantages and a few drawbacks and is a bit complex at the first glance. It requires more discipline from developers but provide a wonderful guide for SOA development.
In order to be a bit more concrete about JBI, we can compare JBI to the timing chain in a motor. It is a fundamental piece for your car but who cares about the timing chain technology!
Let’s take this comparison to illustrate Mule’s paper with a short and simple story:
One day, you want to buy a car and visit two garages. The first garage proposes M’s cars and the second O’s car. During your visit to the first garage you inform the salesman that whatever his arguments, you will have a look on O’s cars before taking a decision. Suddenly, the salesperson seems upset and argues against O’s cars
Sales: “Don’t think O’s cars, timing chain technology in O’s car is not a real standard accepted by other car companies”.
You: “May be, but I heard they are economic cars”
Sales: “Yeah, but you have to be careful about timing chain technology”
You: “Many say that the cars ars reliable and comfortable”
Sales: “Again, as I told you, O’s cars timing Chain technology force us to be more rigorous during services and it can cost you more”
You: “Consequently, if you are more rigorous during services, O’s car will be more reliable with less breakdown and maintenance”
Sales: “The technology for O’s timing chain is not a standard and has been supersede by another technology “IGSO”.
You: “Hmm, so do you use it for you cars?”
Sales: “Not at all our CEO said that “IGSO” technology is a terrible technology (http://blogs.mulesoft.org/tag/osgi/ )”
You: “I’m fed up with your timeline chain technology, is it the only argument you have to stop me to have a look on O’s cars”?
This story is exactly the process used by Mule’s writer. He writes and argues against JBI but he does not talk about what the features we really expect from a modern integration development tools that fosters simplicity, productivity, reliability, efficiency, scalability, SOA development. Why did he do it? I think, simply because on all these points, OpenESB outperforms Mule.
In this chapter, I review the main arguments provide by Mule’s paper
“OpenESB is tied to Sun Microsystems product and JEE”
OpenESB is an autonomous Java framework that works on any Java platform. Today OpenESB runs on Glassfish Server V2-V3, JBoss V4-5, standalone JDK and could run on any other platforms with time and volunteers. Regarding the development tools, Netbeans is used as Eclipse is used for Mule development. Saying that OpenESB is tightly coupled with Java EE is an additional piece of evidence that Mule’s writer has a weak skill or background on OpenESB. If OpenESB can use JEE entities like EJB or Servlet as component, it has no link with JEE specifications.
“Organisations who choose Open ESB or Glassfish ESB need to tightly couple their infrastructure to JBI”
OpenESB is a JBI implementation. JBI is a great advantage since it provides clear and well defined architecture basis. JBI defines the way the component and the bus behave and no more. JBI rules the exchange within a JVM and no more. There is no impact on any part of the infrastructure. Communications between the infrastructure and OpenESB is made through a connector as do Mule, ServiceMix, Oracle SOA Suite or any other ESB.
“Organisations who choose Open ESB or Glassfish ESB need open source solution that will allow incremental migration to proprietary Oracle middleware”
Here, we have the most senseless sentence of this paper. Can Mule’s writer explain how is it possible that a company chooses an open source solution that allows incremental migration to proprietary Oracle middleware? Are organisations so foolish not to see a cul-de-sac when they buy a strategic product? Is Mule to proud and full of itself to ignore that a small but efficient community exists around OpenESB (www.open-esb.net ). This community works hard to promote, improve and support the project. OpenESB community proposes a complete set of professional services and many large companies have put on production OpenESB projects in the last two years. It is a new proof of lack of preparation before writing this article.
“Already using Glassfish, and need tightly integrated ESB solution”
Glassfish is just a container for OpenESB as a JVM is a container for any Java application. Using OpenESB does not force you to develop on glassfish at all and partners can be any other platform like “Mule”, JBoss, SAP, .Net… You don’t have to be “already using Glassfish” since OpenESB comes along with a Glassfish instance and the application server is embedded in the same open source license. So Except for Fake and FUD purposes, this assertion has no sense.
In the second part of this blog let’s compare a real SOA and ESB criteria between the two products.
In integration, using real standards is the key of interoperability.
Mule’s writer said: “Instead, Mule uses a simple, POJO and XML-based architecture and configuration which boasts one of the smallest learning curves in the industry thanks to its similarity to standard Java”.
Mule product is Java centric and proposes integration mainly based on Java technologies like POJO and XML. Even if Java is used for a large part of professional projects, it is not the only technology found in IT systems and infrastructure. POJO is far from the "standards agnostic approach to integration” described by Mule people. Java is a standard for Java applications and no more. On the other hand, even if using XML is agnostic, it is insufficient for a reliable communication with heterogeneous partners. Partners must agree on message structures, operation patterns, faults, access rights, protocol security …
OpenESB defines and implements a real integration system platform by using real and agnostic standards like XML, XSD, WSDL, and BPEL to define exchange between partners. Any platform on the market (C#, Mainframe, PHP, SAP, C++…) understands and uses these standards. OpenESB has been designed to communicate with all the platforms using real integration standard. OpenESB strength is to use them natively.
Mule’s writer presents contract of services (WSDL) as a constraint for integration project (“tightly coupled to WSDL description of Services”). He explains that POJO and XML are native and consequently the most natural way to do integration. This is a big mistake from the integration expert’s mouth, since WSDL has the huge advantage of not creating dependency between partners. The following paragraph explains this concept.
Let’s take an example: Two applications A and B communicate through a Java interface. This interface Client contains a simple method Public Client getClient (int id).
Any Java developer understands that we provide an integer as Customer ID and in return, we get the Client with his detail. Many people think that using Java (C#...) interface is a good way to decouple partners (or applications) since we hide interface implementation to the service consumer. Unfortunately, it is a big mistake!!! The main issue here, is that Client is defined nowhere in the interface (by default) and consequently Client definition is an agreement by default between A and B and A has to embed a Client implementation in its business domain. Any modification in B Client implementation impacts A business domain.
On this other side, defining a WSDL as contract between partners does not create dependency between partners since the contract is an agreement on the messages the partners exchange and not the content of internal business domains. So any modification on the message definition does not affect the internal entities in the applications
This is a fundamental difference between Java Interface and WSDL.
Other obvious and important point:
Using Java interfaces to define services and exchange structure contract has a huge limitation since the contract can be understood by Java applications only. It is never a drawback for integrators who work on Java application only. They seem to be unaware that IT ecosystems are made up with dozens of technologies. This is the lowest level of integration technologies.
A WSDL contract is language and platform neutral documents. It can be understood by any application on any platform.
The same WSDL is understood and used by Java or C# applications but by legacy applications like SAP or Mainframe CICS or IMS as well.
A real integration system must be neutral and able to communicate with many other technologies. Promoting limited standards for integration focused on one platform or one language as many integration tools editors have do, is for us nonsense.
Some designers think that exchanging XML messages is doing integration. They look like teenagers who know three chords on their guitar and think they are a rock star. Exchanging simple XML documents between partners provides a poorer integration than the one obtained with Java Interfaces. Indeed, exchanging simple XML messages does not procure clear and well defined message structures definitions. Contrary to Java interface or WSDL, when a business or technical error occurs, error or fault messages are not explicitly published (Java Exception or WSDL fault). When simple XML exchange is used to communicate, it indicates that specific error messages were defined at the design time and subject to an agreement between partners. However, since there is not standards technical ways to express this agreement, A and B must implement this agreement within the applications.
This is a very poor integration that crystalizes very quickly, generates many dependencies between partners and consequently has a very high maintenance cost. Unfortunately, knowing three chords on a guitar is not enough to be a rock star.
Moreover, OpenESB proposes through its wizard a simple an efficient development process based on:
This development process is so efficient that Oracle chose it for its SOA suite. OpenESB is an SOA tool to define and embedded existing services and put them together to compose business processes. It has been designed from the beginning for that goal. It aims at service designers and developers and at a higher level, Business Process conductors.
Mule on the other side relies on a point to point communication between partners. A message is put in a pipe and sent to another component, then sent again in a pipe to another component, etc.
Using this architecture for development has two main drawbacks.
Pipe Architecture is efficient when we content ourselves with data exchange between heterogeneous platforms. However, when we really want to do integration at the business process level or even when data communication becomes more complex, “Pipe Architecture” becomes complex, inefficient and hard to maintain. This is the main reason why Mule developers talk about Flow and OpenESB about processes.
OpenESB has been designed for business process implementation and complex integration. It defines clear boundaries between partners with contract of services, provides two intermediation levels between them (the bus and the contract). Mainly based on an Orchestrator (BPEL), OpenESB supports very complex processes, intermediate states. It provides native correlation and compensation during runtime execution. These features are very useful for process designers who orchestrate service like a conductor manage musicians.
This is certainly the most important differences between the two products. They don’t aim at the same target and not the same complexity level.