Choosing the Right ESB for Your Integration Needs
From: http://www.infoq.com/articles/ESB-Integration
中文翻译见： http://www.oschina.net/translate/understanding-integration-needs-based-perspective-mule-vs-servicemix-fuse-esb
Different applications within companies and between different companies need to communicate with each other. The Enterprise Service Bus (ESB) has been established as a tool to support application integration. But what is an ESB? When is it better to use an integration suite? And which product is best suited for the next project? This article explains why there is no silver bullet and why an ESB can also be the wrong choice. Selecting the right product is essential for project success.
Definition of the Term "Enterprise Service Bus"
Numerous products from different vendors include the name "Enterprise Service Bus". Unfortunately, there is no standard definition of this term. The products therefore offer many different features. The term ESB should always be clearly defined before it is used. In the following, an ESB is defined as a software product which assists the developer in application integration and therefore provides the necessary infrastructure to implement routing, translation, and other integration facilities. On the integration complexity path, an ESB usually falls between a framework and a suite as an alternative for application integration, as shown in the following picture:
Figure 1: Alternatives for application integration
After the term ESB has been defined, the next section explains when an ESB should be considered, and when an integration framework or an integration suite is a better choice.
Integration Framework
A framework helps implementing Enterprise Integration Patterns (EIP, http://www.eaipatterns.com), such as Splitter or Content Based Router, in order to integrate applications in a standardized way. Using standard APIs to integrate products noticeably lowers the implementation effort and the source code is easier to understand for other developers. A framework is well suited to integrate different applications with different protocols and technologies, and concepts such as endpoints, producer, consumer and EIPs are used to create the integration logic. Even implicitly supported test automation uses the same concepts.
A framework consists of a set of ordinary libraries and is therefore compatible with any development environment, even a classic text editor.
Known examples of frameworks are Apache Camel and Spring Integration in the Java environment and NServiceBus for .NET.
With frameworks the development team is more or less solely responsible for the project's success. Commercial support is generally not available. Tooling is also only partly available, and not necessarily suitable for "mission-critical" deployments. The rest of this article is therefore devoted to ESB and corresponding suites, which are often a better choice than a framework.
Enterprise Service Bus
Like a framework, an ESB is used to integrate applications. An ESB is based on a framework implicitly. However, it is a much more powerful product. Contrary to a framework, an ESB offers strong tool support for deployment, administration and monitoring at runtime, besides basic functionalities for application integration. In addition, graphical editors are used for the implementation of various integration scenarios. The integration logic can be modeled with "drag and drop", the corresponding source code being generated automatically. Commercial support completes the package of an ESB.
The great advantage of ESBs over the use of pure frameworks is therefore the better tooling, which reduces the cost and complexity significantly. Integration problems are solved at a higher abstraction level.
Integration Suite
A suite offers all features of an ESB. In addition, many other functions such as Business Process Management (BPM), Business Activity Monitoring, Master Data Management, or a Repository are included. If some of these additional features are required in addition to pure integration, then the use of a suite is advisable. The entire integration can be realized with a single software stack.
The differences between a framework, an ESB and a suite are hopefully now clarified. Next will be explained how to select the right ESB or suite.
Comparison Criteria
Notice: we will not provide a matrix that compares all the available products with respect to various criteria. ??From the perspective of the author, it is hardly possible to create a good and useful matrix because the products offer far too many (often different) functionalities and concepts. Besides, the feature list also changes virtually every day in the IT world.
Therefore, it is advisable to pre-define your own needs, and then to evaluate which products are best suited. Proprietary solutions are often very similar, and also the most used open source competitors offer similar characteristics. Therefore, it makes sense to think of at the beginning, whether a proprietary or an open source solution is the better choice.
In order to make this decision, you should use the following criteria:
- Usability: How complicated is the installation? How many tools are needed? Is the development environment intuitive?
- Maintainability: How do you administer the product? Is there a GUI for monitoring services?
- Community: Are there active public forums or mailing lists? Are numerous articles, tutorials, articles, and videos available? Is the product supported by several companies?
- Enterprise Support: What support options are offered ("business hours", "24/7" hotline vs. Email vs. on-site support, etc.)? Can the required service level agreements be guaranteed? Is support offered in your preferred language?
- Functionality: Are all the required functionalities offered?
- Flexibility: Can you customize functionalities of the product to fit my needs?
- Expandability: Is it possible to expand the product? Is the product and its interfaces based on standards?
- Connectors: Are adapters for all required technologies available? Are there adapters for B2B products such as SAP or Salesforce? How easily can I build your own adapter?
- Cost: What is the full cost (total cost of ownership) of the product - including maintenance, all required ancillary products, connectors, etc.)?
- Licensing: What licensing or subscription model is used? What happens when requirements change (more computers, more CPUs, switching to virtual machines, etc.)? Are upgrades for free? Are downgrades possible, too? Are the costs "foreseeable" at all, is the price list even understandable?
Table 1 compares the advantages and disadvantages of proprietary vs. open source ESBs and suites (green = good, yellow = medium, red = bad). The conclusion regarding the differences is the following: Proprietary solutions generally offer more features and "powerful" support. However, the question remains, "Are these really needed?" Remember that efforts, complexity, and costs are correspondingly higher. Open Source products score with easier usability, greater flexibility, easier extensibility and lower costs.
|
Criteria |
Proprietary |
Open Source |
|
Ease of use |
Very complex installation (consultants needed !?), „tool hell“ |
One Click Installer (also for Mac in some cases), start using after minutes, unified platform |
|
Maintainability and Monitoring |
Powerful tooling (e.g. for administration and monitoring), Analysis of source code not necessary, refactoring via GUI |
Less powerful tooling (e.g. for administration and monitoring, integration of further products from other vendors required sometimes), Analysis of source code not necessary, refactoring via GUI |
|
Community |
Buy support, forums (but no real community which helps) |
Based on open source projects, plus own community |
|
Enterprise Support |
24/7 enterprise support, SLAs as you wish, deployments with thousands of servers |
24/7 enterprise support, less guarantees than proprietary support, check for local consulting and support |
|
Functionality |
Integration features + many more (BAM, CEP, EDA, etc., etc., etc.) |
Integration features + some more |
|
Flexibility |
(Make a change request + wait long + pay) OR (pay a lot + get it quickly) |
Open source, change what you want |
|
Extensibility |
Do it yourself (tough) OR pay |
Standards-based, defacto standards |
|
Connectors |
Adapters for technologies and business products |
Adapters for technologies and business products |
|
Costs |
MUCH (and even more) |
LESS |
|
Licencing |
Complex price list, pay for everything (upgrades, migration to VM, „you-name-it“) |
Subscription model, upgrades inclusive, predictive costs, downgrades possible |
Table 1: Advantages and disadvantages of proprietary and open source products
Product Alternatives
After the main differences between proprietary and open source products have been explained, some specific products are introduced in the following. Thus, an overview of the various available alternatives will be given including a small practical insight.
Almost every vendor of proprietary integration products, such as IBM and Oracle, offers a solution for every conceivable function. Regarding open source alternatives, in particular the Unified Platform of Talend and the WSO2 Platform are worth mentioning, because they also offer complete suites. Besides, several alternatives concentrate solely on ESB. Perhaps the most important open source offerings are Mule ESB and Fuse ESB.
Oracle Service Bus / Fusion Middleware
Oracle Service Bus is the current ESB from Oracle. It is a component of Oracle Fusion Middleware (OFM) stack, which according to the definition of this article is an integration suite. Many other products are available in it, for example, the SOA Suite, Coherence, Complex Event Processing, BPEL Process Manager, Enterprise Messaging Service, Service Registry, and many more.
There is probably not much functionality which is not provided by Oracle’s suite. The tools are very powerful and stable. Graphical editors exist for most products. Support is also available for most conceivable service level agreements. If these powerful and SLAs are really needed, you are on the right side with Oracle. This power comes at a price of course. The high complexity of the products should not be underestimated. Besides, you should be aware of high licensing and support costs plus a non-transparent pricing model.
The OFM is based on standards such as Java EE, BPEL, SOAP, or SCA. The products are proprietary and come from multiple acquisitions made by Oracle over time. Therefore different codebases are used, and different products often need different development tools. The sum of the downloads can quickly exceed 20 Gb. The installation is tedious and can occasionally move over several days - even for a simple installation on your laptop. The products are rather heavy. Resource requirements at runtime are very high.
By the way, you could have just replaced "Oracle" with "IBM" and "Fusion Middleware" with "WebSphere". The content of this section would still be almost the same - except to mention that IBM has three different ESBs in the portfolio: the Message Broker, the ESB and the DataPower SOA Appliances. Also, Tibco, Microsoft and SAP play an important role in the market of proprietary ESBs and integration suites.
The conclusion of this section is therefore that proprietary integration suites can offer almost every conceivable function and cover almost all SLAs. However, many of these functionalities or SLAs are not required in most projects. In this case, be sure to also evaluate open source alternatives. The most important ones are described in the next sections.
Mule ESB
Mule ESB is one of the first successful open source ESBs. It has a lot of qualities in common with the other previously mentioned open source ESBs. These include a very simple ("one click") installation and intuitive, Eclipse-based tooling. Usually, open source ESBs are very lightweight and extensible solutions. Apart from the free open source version, a commercial enterprise version is available. This offers additional functionality and support for the product.
For those who still do not know it, it should be mentioned that “open source” does not mean “for free”. Even vendors of open source software have to make money and cannot develop products and offer support free of charge. However, the prices are much more customer friendly and not based on obscure price lists as most proprietary products. Nevertheless, the open source version can be used (even in production) without any licensing costs. Often, however, the open source version simply serves for playing around or doing a proof of concept to later upgrade to the enterprise version with additional features and support.
As the name suggests, Mule ESB is a pure ESB. Important advantages in contrast to frameworks like Apache Camel or Spring Integration are the graphical editors for an efficient implementation of integration scenarios and the available connectors for B2B products such as SAP or Salesforce. However, the functionality of a suite is missing in Mule ESB. For such use cases, the ESB has to be combined with products from other vendors. Negative aspects of Mule ESB are the small community, a restrictive licensing model and limited availability of the source code. Competitors have significant advantages at this.
Fuse ESB
The Fuse ESB is a pure ESB like Mule ESB, without a suite. It is based on de facto standards in the integration environment such as Apache CXF and Apache Camel. As a result, a great community is already secured from the ground up. The development environment is based on Eclipse and very intuitive.
Fuse ESB was part of FuseSource. However, FuseSource was recently acquired by Red Hat and now belongs to the JBoss division. Fuse ESB is contained in the current road map and will continue to be supported. It will be integrated into the JBoss Enterprise SOA Platform - just like the also acquired BPM solution Polymita. There is still a long way towards a unified suite, since the integration of FuseSource and Polymita will still take a few months, and with JBoss ESB, Switchyard and Fuse ESB now three ESB products need to be merged into one. Here, other open source vendors have already achieved better results.
Talend ESB / Unified Platform
Talend ESB is part of the suite of Talend. Talend ESB can be used independently or in combination with other components of Talend’s unified platform. All components are open source and freely available. The enterprise version offers additional features and support. The difference to proprietary products is that all the partial components are based on the same code base and the same tooling is used everywhere. The usage of different areas such as ESB, BPM, ETL, MDM, etc. is done fluently - and is not a separate integration project on its own.
All tooling of the Talend suite is built on Eclipse. The familiar "look and feel" and the intuitive use of Eclipse remain. Talend offers a visual designer for all product parts and uses a "zero-coding" approach. This allows an efficient implementation of integration scenarios. Of course, you can still write and integrate custom logic to your project, e.g. via Java classes (POJOs) or different scripting languages.
Like Fuse ESB, Talend ESB is based on several de facto standards in the integration environment such as Apache Camel, Apache CXF, Apache Karaf and Apache Zookeeper. Besides the available connectors for Apache Camel for technologies such as JMS, HTTP or FTP, many other B2B adapters are available, for example for Alfresco, Jasper, SAP, Salesforce or host systems. All 500+ connectors are included by default. One consequence is that Talend’s IDE has higher hardware requirements than its competitors. You should not install Talend on a too weak laptop. Another disadvantage is missing SOA governance features. This is planned for next releases.
WSO2 ESB / Platform
WSO2 is a relatively unknown vendor. However, WSO2 provides the entire range of components of a suite including Business Process Server, Business Rules Server, Business Activity Monitor or Governance Registry. The entire WSO2 platform can be installed very easily and offers a lightweight, Eclipse-based development studio. Like Talend and FuseSource, WSO2 also puts primarily open source projects such as Apache Synapse (lightweight ESB), Axis (Web Service Implementation) or ODE (Business Process Engine) into its components.
Besides Talend, WSO2 is the only vendor that offers a full suite that is based on a single code base and a single development environment. Therefore, nothing stands in the way for an iterative development process, beginning with a small couple of features, and by adding more functionality later step-by-step. A weakness is the graphical tooling. It supports all components of the platform, but it is not as intuitive to use as the tooling of its competitors.
“Do it yourself” Integration Suite?
A warning to the conclusion: The combination of several frameworks or products to build your own custom integration suite is usually unnecessary expensive and leads to many additional pitfalls. Since several solutions already exist, it is strongly discouraged to create one from various pieces. "Glue code" needs to be written, testing and bug fixing have to be done, and there is no specific contact in case of problems. Vendors usually just refer to the other side, i.e. if you try to combine an ESB with a BPM solution of another vendor, which one do you call when you have a problem? So why should you care about all of these problems if other people have already cared, and an entire stack (also open source) is already available?
Conclusion
There is no silver bullet to solve integration problems. First, a decision must be made whether a framework is sufficient. Be aware that most of the source code must be written by yourself, and tooling and support is scarce. Otherwise, an ESB is the better choice. However, if any additional features of a suite are required at some point later, it would be better to use the ESB of an integration suite from the beginning. This secures sustainability without any problems and additional expense for the combination of multiple products.
If an ESB or integration suite should be used, it must be decided whether a proprietary or open source product is a better choice. Proprietary solutions provide all possible features and strong support. However, this also leads to higher costs and a perceived higher complexity. Contrary, open source solutions score with lower cost, ease of use and flexibility. Once this issue is settled, a shortlist can be created to evaluate the alternatives in detail. It is strongly recommended to perform a proof of concept before making a final decision. Ensure that your team will implement this prototype (from the first installation to final deployment and monitoring), and not just the consultants of the vendor. Your team will have to install the product in the future alone and implement the integration problems independently of any consultants which may not be available.
About the Author
Kai Wähner is a Principal Consultant at Talend. His focus is in the areas of Java EE, SOA, Cloud Computing, BPM, Big Data, and Enterprise Architecture Management. Please give feedback via email (kontakt@kai-waehner.de), Twitter (@KaiWaehner) or social network (LinkedIn / Xing).
上一篇： 元数据驱动还是标签引擎？