Paul Perez

In this blog, I'll try to inform OpenESB community and user on OpenESB improvement, community event. As French speaker, I write in broken English. I apologize to the reader and my English teacher in High school Mrs Posteck. English reviewers are welcome.

Paul Perez

Paul Perez

Paul Perez is Chief Software Architect of Pymma. He is an author, software architect, consultant and speaker. He brings more than 17 years experience helping corporations for mission-critical information systems. Prior to co-found Pymma, Paul was an independent software consultant, working for large financial services companies in France, UK, Benelux, Israel and Germany Paul's extensive experiences in high-performance architecture design helps the company's clients solve real-world business problems through technology. As chief software architect, Paul assists current and future client engagements and develops best practices based on his domain expertise. Paul holds a post master degree from Paris University and is a Sun Certified Enterprise Architect, Togaf certified and holds several other certifications. You can contact paul at: paul.perez (at)

Short story

One day one of my friends, a bit “show-off”, decided to travel to Africa for visiting one of his friends who got a one year job there for a French doctor’s organisation. Impressed by her initiative, he tried, in return, to impress her with a nice car he booked on internet. Once at the airport, he got a nice sports car, one of the fastest on circuit, set up his navigator and started to drive to the village where his friend worked. Unfortunately after few kilometres, bitumen let place to a small muddy road. Quickly the car got stuck in the mud and my friend understood that he would not able to go one kilometre further. The end of the story is luckier since his friend worried not seeing him, took her car to the airport and met and rescued him before the night.

Benchmark for ESB

This week during a break, I typed “ESB Benchmark and performances” on my favourite search engine. The first answers provided links to [1]. web site has been developed and sponsored by AndroidLogic[2]. It proposes a performance benchmark framework for ESB and proclaims that the framework “has become the de-facto ESB Performance test suite”.

There is a famous proverb that says: There are 4 lying levels in IT, the little lie, the average lie, the big lie and the benchmark. Once again, the proverb seems right since ESBPerformance’s benchmark provides surprising results and indicates that AndroidLogic has a strange understanding of what an ESB is in the real world.

Benchmark with strange results

Reading ESBPerformance’s benchmark overview, we learn that the benchmark has been written by AdroitLogic. 8 products have been tested in the same environment and AdroitLogic stresses that they spent many days and nights to get the other ESBs to work under identical conditions as much as possible.

Benchmark results show that AdroitLogic’s products get the best results and ESBPerformance points out that “The UltraESB Enhanced version had a very clear lead above all ESBs across all scenarios”[3]. UltraESB enhanced version had the best results followed by UltraESB “Vanilla version”. The two products are designed and developed by AndroidLogic[4]. What a surprise!!!

In the benchmark, I listed 7 scenarios with 8 products and we learn that the same product is the most efficient for all the scenarios. It looks like a decathlon where one competitor leads above all the tracks. Two hypotheses can be considered, either the competitor is Superman or something is rigged in the competition.

Don’t use benchmark to compare products

Never use benchmarks published on internet to compare products since they are always subjective and this subjectivity is not yours but the one of the benchmark designer. Create your own benchmark with your own subjectivity that often matches your company requirements and is useful to select the best product for your company.

Let’s give a simple example to illustrate how a benchmark can be furtively fake or unfair. In ESBPerformance benchmark, AdroitLogic explains that they allocate 2GB per ESB during the benchmark: “Each ESB was allocated 2GB of Java Heap memory”. Why did they decide to limit the memory to 2 GB? Regarding the cost of the Ram, it seems ridiculous to limit the memory to 2 GB. At the first glance, we agree with this setting and suppose that it does not affect the results. But it is also possible to think that if AdroitLogic would allocate 16 GB of Heap memory, other ESBs would provide better performances and scalability than UltraESB. We will never know where the right hypothesis. Because of this subjectivity, benchmarks could not be used to compare products, especially when the benchmarker is involved in the competition.

Setting up a benchmark for yourself or your company is an excellent idea to evaluate a tool in a well-defined context. Ex: A company which does not want to invest more than 50K€ in hardware must benchmark the ESBs within this limited configuration and see if they provide results accurate with the business requirements. Once again, there is always subjectivity in a benchmark, it pollutes the results and the conclusion since this subjectivity is not yours. Put your subjectivity in the benchmark and get the most accurate results for your project.

A bit further on software editor’s benchmark

If using editor benchmark is not very useful to select a product, reading them proves to be very instructive. Benchmark scenarios provide informations on the way an editor designed and implemented its product. It often represents the perfect use case for its product the one where it is the most performing. In a benchmark, software editors highlight the best part of their products and demonstrate their excellent performances in the scenarios they design and implement. So a short analysis of AdroitLogic’s scenarios teaches us more on UltraESB strength and weakness that many hours with the presale team. 

The scenarios proposed by AdroitLogic are as follows: [5]

  • Direct Proxy Service
  • Content Based Routing Proxy  
    • on SOAP body payload
    • on SOAP header
    • on Transport Header   
  • XSLT Transformation Proxy   
  • WS-Security Proxy

I have to admit that I was a bit disappointed by the poorness of the scenarios and consequently the limited view AdroitLogic has on ESB role and features. Let me explain my point of view: An enterprise services bus allows internal or external IT partners to communicate together and collaborate in implementing new business processes. On the real world, internal and external IT partners communicate through multiple protocols and technologies. In the same business process, it is usual to deal with FTP, File, JMS, TCP clients and server, database, UDDI and LDAP servers, mainframes, Java legacy systems. An efficient benchmark on ESB must be focused on protocol and partner diversity and its capability to associate them together to create new business processes. Only focussing on SOAP and HTTP shows a poor understanding on what an ESB is. ESB and integration and are not limited to SOAP messages.

To conclude, we understand that since AdroitLogic focuses all its scenarios on SOAP/HTTP there is no doubt that Ultra ESB must be efficient when processing SOAP messages. However, regarding AdroitLogic’s fixation on SOAP technology, we are concerned about UltraESB capability to support real world project constraints and AdroitLogic capability to understand real integration requirements where protocols and partners are many and varied.

As explained at the beginning of this post, having one of the fastest sports cars on circuit does not mean you are able to move from one place to another one in the real world.

Tags: Untagged
Hits: 15274


During exhibitions, lectures, and conferences and on ESB forums, architects and developers ask us regularly “What is the difference between Mule and OpenESB”. It is a recurrent question since the two products share lot of common points.

  • Both come from open sources projects supported by a community.
  • Both contain the same acronym “ESB” (enterprise service bus) and aim to make integration easier.
  • Both are running on Java and packaged with graphic tools to develop projects, …

So at the first look, the products seem similar and people are wondering what the key differences between the two products are?

In my response, I’ll try to list and explain the key differences between the two ESB products. Obviously, I propose Mule fans to reply to this post and bring their arguments to complete the discussion and the reader will mould her or his opinion. I would be happy if this paper could be the kick-off of a positive debate.

Before going on, I would like to precise that I have a great respect for Mule people and the job they do. Even if we are competitors, first we are friends.

Let’s avoid a technical comparison

In this answer, I’ll try my best to avoid the trap that pushes technical writers to an exhaustive technical comparison between two products. Starting a debate about Mule or OpenESB technical pros and cons is inefficient and debatable. Usually, each editor comes and pushes forward the best features of his ESB, with benchmark as evidence and claims that his product is the most efficient. Everyone knows the famous IT proverb that says: “There are 4 lie levels: The little lie, the average lie, the big lie and the benchmark”.  To avoid a huge lie, this paper is not focus on technical points but I underline the differences vision of integration between Mule and OpenESB teams. I explain how each team sees integration and at which level it implements the integration concepts. At that level, we shall avoid sterile technical discussions and anyone will be able to understand the key differences between the two ESBs.

Mule: View on Integration

On we can read:

“Mule is a lightweight integration platform that enables you to connect anything, anywhere. Rather than creating multiple point-to-point integrations between systems, services, APIs, and devices, you can use Mule to intelligently manage message routing, data mapping, orchestration, reliability, security, and scalability between nodes. Plug other systems and applications into Mule and let it handle all the communication between systems, enabling you to track and monitor everything that happens. Mule is so named because it “carries the heavy development load” of connecting systems.”

Mule creators gave this name because they considered their product behaving like a mule. This animal makes its jobs efficiently and without tiredness. Many countries see Mule as an essential animal for local economy and people. On the same way, Mules ESB transports and transforms messages efficiently; it takes messages from sources and bears them to the addressees. Mule ESB uses the “Enterprise Integration Patterns” (Router, Filter…) to route, filter and transform messages. Originally Hohpe and Woolf listed and explained EIPs in their famous book “Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions”.  

Like a real Mule, Mule ESB accepts any load without balking. Mulesoft designed this tool to create communication between partners where messages are safely transported.

So, from Mule claims, we understand that Mule ESB’s designer vision of the integration focuses principally on message transport. Mule’s designers understand the integration as an elegant way to transport and transform messages from a provider to a message consumer.

However this basic integration does not consider the other facets of integration. As in the real life, working together in a strong partnership calls for more than sending emails to your partner, a real and efficient integration needs more than sending message between partners.

OpenESB: View on Integration

OpenESB designers understand the integration in a different way. They understand integration in a broader scope. The next points list the key concepts used to design OpenESB.

Integration is a pooling of service proposed by partners (internal or external) who take part in the same business process.

To take part in a business process, a partner must clearly define the services he or she proposes. To do it, he or she publishes a document named “contact of service”. It fixes the services features like message types, operation patterns, protocol, address….

To make up new integration processes, we pool services proposed by the partners. An orchestrator is used as a conductor to manage services and business process state.

Services and Orchestration promote Services Oriented Development (SOD), service reusing and allow complex applications development. They decrease maintenance and evolution costs

Let’s detail these sentences.

Contract of services

In the real word, integration cannot rely just on message exchange. If a project limits exchanges between partners to message exchanges, it results a poor and inefficient integration, reusing and services orientation.

At OpenESB we think the Business Process is the right level to define services and integration rules. Partners and Services must be set and designed at that level to be well-defined, accurate with business needs and reusable by analysts who write business requirements. Contrary to popular belief, reusing is not efficient at development level but at the business level. Business never cares about messages but the pay attention to services.

OpenESB development process promotes partners and services definition among Business and IT teams before starting any development. If Mule accepts nondefined messages, OpenESB deals with messages defined in the contract of services. Often developers see this constraint as a burden, but years of service oriented development prove that defining a contract of service is the only way to control efficiently message coherency and avoid vicious side effects. On its website, Mule develops its view on SOA ( and does not say any word about the contract of services. This fundamental concept is not present in Mule ESB.

Besides, using contract of services comes with an elegant way to separate service definition and implementation and distinguish between a service and the partner who proposes this service. Defining a contract of services makes easy version management as well and adds an intermediation level between the consumer and the service provider.

Flows vs. Orchestration

Mule developments rely mainly on flow diagrams and even if it proposes light tools for orchestration, message flows remain the core of Mule development process. Flows are a set of sequential operations or evaluations applied on message (Ex: route, filter, data mapping…). If message flows are easy to understand and develop, they are not accurate to manage complex business processes. Indeed, if a Business Process sends and receives messages, message flows are not powerful enough to represent real Business Process with “Compensation”, “Correlation”, and “Complex fault management”. These features are beyond message flows capabilities.

Using flow message to develop a complex process with many services and partners, increases exponentially complexity and maintenance cost. Integration application becomes a huge and inextricable plumbing.

OpenESB propose sophisticated and powerful orchestrators for critical processes management. It allows developers to create complex application where the flow messages philosophy is inefficient and costly.  Orchestration allows you to organise complex exchanges between multiple partners like a conductor does with many musicians and members of chorus. That’s one of the fundamental differences between the two products.


To keep this answer short, I propose you to talk about the others key differences between the two ESBs in another blog. However with the help of these two examples (Contract of Service and Orchestration), we understand the main difference between Mule and OpenESB is due to the way each one understands integration. On one side, Mule’s designers see integration as message exchanges between partner and business process as a set of message flows. Key SOA concepts like Contract of Services or partners are nonexistent and orchestration seems optional on the tools proposed in Mule.

At OpenESB, we think that this view limits dramatically the quality and the efficiency of integration at the enterprise level because messages are mainly a developer team concern or topic and does not impact or involve the other teams in the company (ex: Business analysts)

OpenESB promotes services oriented developments, services reusing through definition of service orchestration and composition. It pushes business analysts, developers, architects, and other teams to Services Oriented designs and developments.

So to summarize, we understand that Mule targets Integration at the development level with an efficient message management product. OpenESB invests in Service Orientation Architecture and Development and see Business processes as the right level for integration. It pushes companies to real, concrete and virtuous Services Oriented Development.

Thanks for your comments


Tags: Untagged
Hits: 15461


This week searching some information on Google, I typed “OpenESB vs …” and I got an interesting link from our competitor but friend “Mulesoft” ( where one of their writers compares Mule with OpenESB ( 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 (Java Business Integration)

JBI is a specification issued in 2005 by Sun Microsystem ( 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:

Short 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 ( )”

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.

OpenESB vs. Mule: Inaccuracies and fake

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 ( ). 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.

OpenESB VS Mule: Choose the right standards for integration projects   

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.  

OpenESB VS Mule: WSDL vs. Java Interface

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.

WSDL vs XML exchange

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.

OpenESB VS Mule: The plumber and the conductor (conclusion)

Moreover, OpenESB proposes through its wizard a simple an efficient development process based on:

  • “XML/XSD “ to define message type exchanged between partners
  • “WSDL” to define a communication agreement between partners
  • “BPEL” to orchestrate the services proposed by your application or the external partners.
  • “Composite Application” to compose coarse grain components

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.

  1. When you link two components together, you create automatically dependencies between components. 
  2. If the business process you defined contains intermediate states where are these states stored? 2 ways to solve this constraints with a “Pipe Architecture”
    1. You can put the state in the message itself and in that case you change the message structure regarding your context.
    2. You create a state exchange feature between your components and then increase dependencies between them

 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.  

Hits: 12605

Today, the community is working on OpenESB migration to new container (GF V3-V4 or Jboss V5-6). If OpenESB framework and JBI component are relatively easy to migrate, some peripheral applications or features (ex: the console, Netbeans plugins) aNew OpenESB pluging for Netbeansre strongly tied with GF V2 and make the migration tricky. We cannot blame SUN designers who certainly made it to promote their application server but this migration forces us to transform these applications into agnostic tools accurate to any containers. Ex: Until now, deploying a Service Assembly on many OpenESB instance was made through Glassfish V2 cluster architecture. Since we want to be platform agnostic, we have to design and implement agnostic multi instance deployment features. In the community, some developers are working OpenESB Netbeans plugin (see the screenshot on the right) and our team was given new console development management. In order to start the project, I wrote a draft document with the first basis for the new console architecture. There are many points where I pose design questions without having any solution (for the moment I hope). In the community there are many really good architects and developer. Guys we rely on you to refine the document and propose technical solution certainly more accurate than mine. I don’t expect any congratulation but shape criticisms and technical propositions. Any serious technical proposition will be taken into account, thinks are completely open for the moment, please feel free to participate to the key project in OpenESB community.

The document can be downloaded here:  New administrator console for OpenESB

I propose you to discuss about this document and the console on our OpenESB community forum

Thanks for your help. 


Tags: Untagged
Hits: 7218
Last month, Pymma had a stand at the Devoxx exhibition Paris 2012 and made evangelisation on OpenESB. Even if delegates were more web pages development oriented, the exhibition was interesting since we had the pleasure to discuss with kind people who expressed unexpected thinking and point of view on ESB and integration. In our stand, we received many people working with ESB competitors like Mule or ServicesMix and consorts. They asked us information about OpenESB and naturally we started our presentation by talking about JBI which is the basis layer of OpenESB. The main part of our visitors never heard about JBI and the others told us that they thought that JBI did not exist anymore or at least it is a legacy technology is close to death.
Since I had this conversation 2-3 times, I asked them from where they get that opinion? They replied that many ESB gurus announce JBI’s end and its replacement by X and Y technologies. I had to confess that I had no expertness on these X and Y technologies and I was not able to estimate if they are better or not than a JBI implementations like OpenESB. So, I was very interested in understanding reasons for JBI’s death and the same day, I typed “JBI dead” on Google and I found papers and forums on that topic. I cannot detail here all the arguments provided but two often came across on Internet.
·         The first is that there is no JBI version 2
·         Companies and editors supporting JBI are migrating to other technologies

Replying to the first argument is very easy since you can note that XML itself is in version 1.x and 99% of wsdl found on the market follow the specification 1.1 (event if V2 exists). High version number for a specification is not proof of maturity. Regarding the JBI supports number, it is true that when Sun Microsystems disappears, the main JBI support disappears as well. However, I never think that developers or end users are really concerned about internal architecture. They evaluate tools easiness and their impacts on development and organisation more than tools internal architecture. Who takes care about SCA when it uses Oracle SOA suite or Websphere products? Very few!!!
So in this blog, I will not talk about JBI architecture benefits but just provide the reader with our feedback on JBI impacts on development and maintenance improvement. As you certainly know, JBI defines many technical concepts and the most famous is the bus named NMR (Normalized Message Router). From my point of view, JBI key feature is not The NMR but the way it constraints people to use WSDL. “JBI defines an architecture that allows the construction of integration systems from plug-in components that interoperate through the method of mediated message exchange. The message exchange model is based on the web services description language 2.0 [WSDL 2.0] or 1.1 [WSDL 1.1]”.

Figure 1: In JBI partners are known through their WSDL

In other words, JBI forces any entity which wants a connection to the bus (NMR), to define first a WSDL which describes the services it proposes. This constraint has always been seen as a burden by developers since it forces them to follow external definitions and proposes a way of thinking different from the one the developers are used to. A simple proof is the number of WSDLs found in integration applications generated by Java or C# tools which mimic Java or C# classes’ behaviour and workaround WSDL handmade definition. WSDL specifications require effort for a good understanding and XSD knowledge to be efficient. So we can understand that some people are reluctant to read pages of specification before starting wsdl definition.Using standard, clean WSDL documents designed from business specifications defines a strict relationship stable and understandable between partners. It fixes messages exchange patterns, message content, etc...Consequently, partner’s knowledge and understanding is limited at the technical level, to one or more WSDLs which define boundaries between partners.
When components, applications are defined by a WSDL interface, it reinforces encapsulation, decreases dependencies and consequently makes easier parallel designs, developments and reduces dramatically the maintenance cost. During the two last years, I had the opportunity to work on large OpenESB projects. These projects took a great advantage from strong components and applications encapsulation which had a beneficial impact on IT teams and development process too. When development tasks are limited by boundaries, it’s easier to assign precise agenda and objectives to the teams. When focusing on contract fulfilment only, the developer shrug off others team progress or delay and follow their own ways without pressure from the other teams.  In very few cases, this way of working is obtained by a clever management who has to impose a strict respect of limit and boundaries in during specification, design and development stages. Since JBI forces development teams to define contracts and boundaries, it made the project manager work easier. This is the key advantage of JBI!!!
Figure 2: JBI virtuous circle

Moreover, we also observed that when development teams mention the word “contract” hundreds times a day and WSDLs become a referent for they works, this has a great influence on other teams. Very quickly business analysts understand that functional contract definitions between internal and external partners cannot just be fixed by technical teams who have not a business understanding of the business processes. Very quickly, BAs make effort to move from literal to service oriented business specifications. When service definition and reusing are understood at the business level, companies take a great benefit from Service Oriented Technologies since the services reusing is really efficient when business makes its own SOA concepts. This evolution to services orientation at the company level seen in many projects is not complete in one day or event one month and takes time to be mature. Each time this evolution has been initiated by development teams forced by OpenESB and JBI to use WSDL. Once convert to service orientation they push their colleague to adopt it.
I spent now many decades in IT environment and I saw many technologies waves disrupt IT development without impacting business way of thinking IT specifications. Neither distributed architecture nor object oriented technologies change literal business specification. For the first time service and contract orientation technologies impact the way companies have thought about their processes.

Cancelling such architectures would a major loss for Service Oriented Technologies adoption.
Tags: Untagged
Hits: 9935