Java 企业服务总线的好处

Benefits of an enterprise service bus

提问by LBushkin

Where can I find some information on the uses and benefits of an enterprise service bus (ESB)?

在哪里可以找到有关企业服务总线 (ESB) 的用途和优势的一些信息？

I am looking for information about:

我正在寻找有关以下方面的信息：

1. the kinds of problems and ESB helps to solve
2. the alternatives to an ESB - and the tradeoffs in selecting between them
3. what you need to do as a developer to build ESB-compatible systems

1. 各种问题和 ESB 有助于解决
2. ESB 的替代方案 - 以及在它们之间进行选择的权衡
3. 作为开发人员，您需要做什么来构建 ESB 兼容的系统

I'm looking for a finer level of detail than just Wikipedia or online marketing brochures from vendors. Ideally, some example code would help to clarify what's involved in taking advantage of an ESB. Information from a .NET or Java perspective would be the most useful.

我正在寻找比维基百科或供应商在线营销手册更详细的信息。理想情况下，一些示例代码将有助于阐明利用 ESB 所涉及的内容。.NET 或 Java 角度的信息将是最有用的。

Thanks.

谢谢。

采纳答案by Mirko N.

I'd suggest To ESB or not to ESBto start with, written by the creator of Mule.

我建议To ESB 或不 ESB开始，由Mule的创建者编写。

回答by JP Alioto

There is a decent 3-part seriesover at IBM regarding ESB that's pretty concept oriented and vendor agnostic (for the most part). I have found lots of good stuff on ESB by poking around IBM's site. There is also some decent info and videos and stuff over at the BizTalk site.

IBM有一个由3 部分组成的不错的关于 ESB 的系列文章，它非常面向概念且与供应商无关（在大多数情况下）。通过浏览 IBM 的站点，我在 ESB 上发现了很多好东西。BizTalk 站点上还有一些不错的信息和视频以及其他内容。

回答by Robin

In addition to the sites that were already mentioned. You should read this article on "Don't use an ESB unless you absolutely have to". It was written by the CTO of MuleSource, one of the most popular open source ESB's available. Not exactly an answer to your question, more of making a point to ask yourself "Do I need an ESB"?

除了已经提到的网站。您应该阅读有关“除非绝对必要，否则不要使用 ESB”的文章。它由 MuleSource 的 CTO 编写，MuleSource 是最流行的开源 ESB 之一。不完全是对您问题的回答，更多的是问自己“我需要 ESB”吗？

回答by Jamie McCrindle

ESB's are a good way to implement Enterprise Integration Patterns.

ESB 是实现企业集成模式的好方法。

Kinds of problems that an ESB helps to solve

ESB 帮助解决的各种问题

• You have a number of protocols you'd like to normalize to a single protocol (e.g. FTP, email, SOAP, XMPP, etc. to a messaging system) e.g. ActiveMQ. This lets you decouple the implementation of services from the protocol.
• You want a consistent way to hook services into this architecture so that they can listen for messages, process messages and generate messages (Message Endpoints, Channel Adapters etc.).
• You may want a managed container to deploy these various components into (e.g. ServiceMix, Mule)
• You may want a number of prebuilt components and adapters into various protocols (e.g. ServiceMix, Mule and Camel have a lot of pre-built components).
• You may require long running workflows. Business Process Management is often something that is provided alongside an ESB (Apache ODE plugs into a number of Open Source ESBs).

• 您有许多协议要规范化为单个协议（例如，FTP、电子邮件、SOAP、XMPP 等到消息传递系统），例如 ActiveMQ。这使您可以将服务的实现与协议分离。
• 您需要以一致的方式将服务挂钩到此架构中，以便它们可以侦听消息、处理消息并生成消息（消息端点、通道适配器等）。
• 您可能需要一个托管容器将这些不同的组件部署到（例如 ServiceMix、Mule）
• 您可能需要一些预构建的组件和适配器到各种协议中（例如 ServiceMix、Mule 和 Camel 有很多预构建的组件）。
• 您可能需要长时间运行的工作流。业务流程管理通常与 ESB 一起提供（Apache ODE 插入许多开源 ESB）。

Alternatives to an ESB

ESB 的替代品

The alternatives really depend on the problem that you're trying to solve.

替代方案实际上取决于您要解决的问题。

• To provide distributed services, people often use application servers exposing services via some point to point RPC protocol (like EJBs over RMI or Web Services over HTTP). So, rather than putting a message onto a 'bus', a client directly calls a server.
• To respond to specific protocols, you could just build a client that responds to that protocol for example writing an application that listens for emails using JavaMail or one that listens to XMPP using Smack. If your problem is constrained to one or two protocols it may not be worth bringing in a full ESB.

• 为了提供分布式服务，人们经常使用应用服务器通过一些点对点 RPC 协议（如 EJB 上的 RMI 或 Web 服务上的 HTTP）公开服务。因此，客户端不是将消息放到“总线”上，而是直接调用服务器。
• 要响应特定协议，您可以构建一个响应该协议的客户端，例如编写一个使用 JavaMail 侦听电子邮件的应用程序或使用 Smack 侦听 XMPP 的应用程序。如果您的问题仅限于一两个协议，则可能不值得引入完整的 ESB。

What you need to do as a developer to build ESB-compatible systems

作为开发人员，您需要做什么来构建 ESB 兼容的系统

This will depend on the ESB you select, although given that most of the good ones are designed to call out into all sorts of protocols as well as host POJOs, there isn't much you should need to do build ESB compatible systems. It is worth trying to make your code asynchronous.

这将取决于您选择的 ESB，尽管考虑到大多数好的 ESB 旨在调用各种协议以及主机 POJO，但构建 ESB 兼容系统并不需要做太多工作。尝试使您的代码异步是值得的。

For examples, Apache Camel probably has the most succinct configuration, here's a tutorial.

例如，Apache Camel 可能有最简洁的配置，这里有一个教程。

回答by Igor Zevaka

Check out this Hanselminutes podcast. It answers a few questions that you should really ask yourself before implementing a service bus.

看看这个Hanselminutes 播客。它回答了您在实现服务总线之前真正应该问自己的几个问题。

回答by Archimedes Trajano

Three key advantages:

三大优势：

• A bus provides a way for end points to connect to each other without having to directly talk to each other. It simplifies the communicationsfor the end points as they only have to conform to a standard communication interface, the bus. (This is with any technical bus, not just ESBs)
• An ESB provides a single placeto get some key end point metrics: frequency, availability, and performance.
• An ESB tends to provide more than one communication interface. However, a developer only needs to choose the easiest one to get and receive the data from the bus.

• 总线为端点相互连接提供了一种方式，而无需相互直接交谈。它简化了端点的通信，因为它们只需要符合标准的通信接口，即总线。（这适用于任何技术总线，而不仅仅是 ESB）
• ESB 提供了一个单一的地方来获取一些关键的端点指标：频率、可用性和性能。
• ESB 倾向于提供多个通信接口。但是，开发人员只需要选择最简单的一个就可以从总线上获取和接收数据。

However, make sure those will provide business valuefor your situation. Having an ESB is adding yet another complexity to your enterprise. Ideally you shouldn't choose this based on a few applications, but the entire organization. There should be only oneproduction ESB cluster for the organization.

但是，请确保这些将为您的情况提供商业价值。拥有 ESB 会给您的企业增加另一种复杂性。理想情况下，您不应根据少数应用程序选择此选项，而是应根据整个组织进行选择。该组织应该只有一个生产 ESB 集群。

Alternatives:

备择方案：

• Just connect things to each other directly especially if the communication protocols are the same. This is good for simple application clusters and does not require too much thinking. However, as your number of applications grow, maintaining the interconnections becomes difficult.
• Another alternative is an MQ implementation. This will provide you with a way of pushing data around without having complex interconnections, but then you are forced to use only one communication channel. Fortunately for Java, they have the JMS standard.

• 只需将事物直接相互连接，尤其是在通信协议相同的情况下。这对于简单的应用集群来说很好，不需要太多思考。但是，随着应用程序数量的增加，维护互连变得困难。
• 另一种选择是 MQ 实现。这将为您提供一种无需复杂互连即可推送数据的方法，但是您将被迫仅使用一个通信通道。幸运的是，Java 有 JMS 标准。

Practicality:

实用性：

I have stated the possible alternatives. They may seem lousy at first, but it is not to say you cannot start that way. I personally write things to talk to the remote directly without going through an ESB to make sure it works without worrying too much about integration issues.

我已经说明了可能的替代方案。一开始它们可能看起来很糟糕，但这并不是说您不能以这种方式开始。我个人编写了一些东西来直接与远程通信，而无需通过 ESB 来确保它可以正常工作，而不必过多担心集成问题。

If you don't have an ESB, I suggest you try Mule for development and WebSphere ESB for test and production. I tend to use two products that supposedly follow standards to make sure we keep the vendors honest and to make sure your developers are conforming to standards preventing inadvertent vendor lock-in.

如果您没有 ESB，我建议您尝试使用 Mule 进行开发，尝试使用 WebSphere ESB 进行测试和生产。我倾向于使用两种据称遵循标准的产品，以确保我们保持供应商诚实，并确保您的开发人员符合标准，防止无意中锁定供应商。

In the end, just answer the following question: is the time adding the bit of complexity to simplify other complexities your enterprise worth the cost in the long run?

最后，只需回答以下问题：从长远来看，为简化其他复杂性而增加一点复杂性的时间是否值得您的企业付出代价？

回答by MeTitus

The first question you need to ask yourself is why do you need an ESB?

您需要问自己的第一个问题是为什么需要 ESB？

ESB is usually used in Event SOA distributed architectures, which seem to be a hot buzzword nowadays. Before you jump into ESB let me remind you of Martin's Fowler First Law of distributing Systems:

ESB 通常用于 Event SOA 分布式架构中，这似乎是当今的热门词。在您进入 ESB 之前，让我提醒您 Martin 的 Fowler 分布式系统第一定律：

http://martinfowler.com/bliki/FirstLaw.html

http://martinfowler.com/bliki/FirstLaw.html

"My First Law of Distributed Object Design: Don't distribute your objects (From P of EAA).

“我的分布式对象设计第一定律：不要分发你的对象（来自 EAA 的 P）。

The relevant chapter is available online."

相关章节可在线获取。”

When you're build a new system, the most important aspect is that it is future proof, that means easy scalability and maintainability. If you build your system around the concept of loosed services with static defined contract distributed in a networked environment, you can "hide" the architecture you want for that particular service, because the interfaces are still there.

当您构建一个新系统时，最重要的方面是它是面向未来的，这意味着易于扩展和可维护。如果您围绕松散服务的概念构建您的系统，并使用分布在网络环境中的静态定义契约，您可以“隐藏”该特定服务所需的体系结构，因为接口仍然存在。

ESB is close related to asyn messaging systems, so before you start jumping into that kind of implementation, know that an architecture does not have to be homogeneous, that is all services be implemented the same way, don′t start the biggest mistake which is distributing your system from the start, you should only distribute as you need to scale, no before hand. What you need to make sure though, is that your services should be able to be easily distributed should the need arise, without breaking any contracts which would mean, changes to clients of that service.

ESB 与异步消息传递系统密切相关，所以在你开始进入那种实现之前，要知道一个架构不必是同构的，也就是说所有的服务都以相同的方式实现，不要开始犯最大的错误，那就是从一开始就分发您的系统，您应该只在需要扩展时分发，而不是事先分发。但是，您需要确保的是，您的服务应该能够在需要时轻松分发，而不会违反任何合同，这意味着更改该服务的客户端。

As for the benefits of ESB, they are the same as SOA, ESB adds the context of asyn messages (events) operations.

至于ESB的好处，它们和SOA一样，都是ESB增加了异步消息（事件）操作的上下文。

回答by Kai W?hner

Take a look at my presentation "Spoilt for Choice - How to choose the right ESB".

看一看我的演示文稿“被宠坏了选择 - 如何选择正确的 ESB”。

I explain when to use an ESB, Integration Suite, or just an Integration Framework (such as Apache Camel). I also discuss the differences between open source and proprietary ESBs.

我解释了何时使用 ESB、集成套件或仅使用集成框架（例如 Apache Camel）。我还讨论了开源 ESB 和专有 ESB 之间的区别。

回答by Rashod Chamikara Bandara

An enterprise service bus (ESB) is a software architecture for middleware that provides fundamental services for more complex architectures. For example, an ESB incorporates the features required to implement a service-oriented architecture (SOA). In a general sense, an ESB can be thought of as a mechanism that manages access to applications and services (especially legacy versions) to present a single, simple, and consistent interface to end-users via Web- or forms-based client-side front ends.

企业服务总线 (ESB) 是一种用于中间件的软件架构，可为更复杂的架构提供基础服务。例如，ESB 包含实现面向服务的架构 (SOA) 所需的功能。一般而言，ESB 可以被认为是一种管理对应用程序和服务（尤其是旧版本）的访问的机制，以通过基于 Web 或基于表单的客户端向最终用户呈现单一、简单且一致的界面前端。

In essence, ESB does for distributed heterogeneous back end services and applications and distributed heterogenous front-end users and information consumers what middleware is really supposed to do: hide complexity, simplify access, allow developers to use generic, canonical forms of query, access and interaction, handling the complex details in the background. The key to ESB's appeal, and possibly also its future success, lies in its ability to support incremental service and application integration as driven by business requirements, not as governed by available technology.

本质上，ESB 为分布式异构后端服务和应用程序以及分布式异构前端用户和信息消费者做了中间件真正应该做的事情：隐藏复杂性，简化访问，允许开发人员使用通用的、规范的查询、访问和访问形式。交互，在后台处理复杂的细节。ESB 的吸引力及其未来成功的关键在于它能够支持由业务需求驱动的增量服务和应用程序集成，而不是由可用技术控制。

http://searchsoa.techtarget.com/definition/enterprise-service-bus

http://searchsoa.techtarget.com/definition/enterprise-service-bus

WSO2 Enterprise Service Bus(Product)

WSO2企业服务总线（产品）

WSO2 Enterprise Service Bus (ESB) 4.7.0 documentation! WSO2 ESB is a fast, lightweight, 100% open source, and user-friendly ESB distributed under the Apache Software License v2.0. WSO2 ESB allows system administrators and developers to conveniently configure message routing, mediation, transformation, logging, task scheduling, failover, load balancing, and more. It supports the most commonly used Enterprise Integration Patterns (EIPs) and enables transport switching, eventing, rule-based mediation, and priority-based mediation for advanced integration requirements. The ESB runtime is designed to be completely asynchronous, non-blocking, and streaming based on the Apache Synapse mediation engine.

WSO2 企业服务总线 (ESB) 4.7.0 文档！WSO2 ESB 是一种快速、轻量级、100% 开源且用户友好的 ESB，在 Apache 软件许可证 v2.0 下分发。WSO2 ESB 允许系统管理员和开发人员方便地配置消息路由、中介、转换、日志记录、任务调度、故障转移、负载平衡等。它支持最常用的企业集成模式 (EIP)，并支持传输交换、事件、基于规则的中介和基于优先级的中介以满足高级集成需求。ESB 运行时被设计为基于 Apache Synapse 中介引擎的完全异步、非阻塞和流式传输。

WSO2 ESB is developed on top of the revolutionary WSO2 Carbon platform, an OSGi-based framework that provides seamless modularity to your SOA via componentization. It includes many features and optional components (add-ons) you can install in the ESB, and you can easily remove features not required in your environment, thereby allowing you to fully customize and tailor WSO2 ESB to meet your exact SOA needs.

WSO2 ESB 是在革命性的 WSO2 Carbon 平台之上开发的，这是一个基于 OSGi 的框架，通过组件化为您的 SOA 提供无缝模块化。它包括许多可以安装在 ESB 中的功能和可选组件（附加组件），并且您可以轻松删除环境中不需要的功能，从而允许您完全自定义和定制 WSO2 ESB 以满足您确切的 SOA 需求。

ArchitectureApplication infrastructure on the enterprises may be inherently complex, comprising hundreds of applications with completely different semantics. Some of these applications are custom built, some are acquired from third parties, and some can be a combination of both and can be operating in different system environments.

架构企业上的应用程序基础设施可能天生就很复杂，包括数百个具有完全不同语义的应用程序。这些应用程序中的一些是定制的，一些是从第三方获得的，还有一些可以是两者的组合并且可以在不同的系统环境中运行。

Integration among these heterogeneous applications is vital to the enterprise. Different services may be using different data formats and communication protocols. Physical locations of services can change arbitrarily. All these constraints mean your applications are still tightly coupled together. An ESB can be used to loosen these couplings between different services and service consumers.

这些异构应用程序之间的集成对企业至关重要。不同的服务可能使用不同的数据格式和通信协议。服务的物理位置可以任意更改。所有这些限制意味着您的应用程序仍然紧密耦合在一起。ESB 可用于放松不同服务和服务使用者之间的这些耦合。

WSO2 ESB is a full-fledged, enterprise-ready ESB. It is built on the Apache Synapse project, which is built using the Apache Axis2 project. All the components are built as OSGi bundles.

WSO2 ESB 是一个成熟的企业级 ESB。它基于 Apache Synapse 项目构建，该项目使用 Apache Axis2 项目构建。所有组件都构建为 OSGi 包。

回答by user671731

there is zero reason to use an ESB. Don't do it. Needless complexity. Why go through an intermediary when you can go direct? The ESB folks will tell you point to point is bad, yet somehow point to point to and from the ESB is good.

使用 ESB 的理由为零。不要这样做。不必要的复杂性。当你可以直接去的时候，为什么要通过中介？ESB 人员会告诉您点对点是坏的，但不知何故，点对点和来自 ESB 是好的。