企业服务总线的好处
在哪里可以找到有关企业服务总线 (ESB) 的用途和优点的信息？
我正在寻找以下信息：
- 问题类型以及 ESB 有助于解决
- ESB 的替代方案 - 以及在它们之间进行选择时的权衡
- 作为开发人员构建 ESB 兼容系统需要做什么
我正在寻找比维基百科或供应商提供的在线营销手册更详细的信息。理想情况下，一些示例代码将有助于阐明利用 ESB 所涉及的内容。从 .NET 或 Java 角度来看的信息将是最有用的。
谢谢。
Where can I find some information on the uses and benefits of an enterprise service bus (ESB)?
I am looking for information about:
- the kinds of problems and ESB helps to solve
- the alternatives to an ESB - and the tradeoffs in selecting between them
- what you need to do as a developer to build ESB-compatible systems
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.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
我建议 ESB 或不首先是 ESB，由 Mule 的创建者编写。
I'd suggest To ESB or not to ESB to start with, written by the creator of Mule.
ESB 是实现企业集成模式的好方法。
ESB 帮助解决的问题类型
ESB 的替代方案
替代方案实际上取决于您要解决的问题。
作为开发人员，您需要做什么来构建 ESB 兼容系统
这将取决于您选择的 ESB，尽管考虑到大多数好的 ESB 都被设计为调用各种协议以及托管 POJO，但没有构建 ESB 兼容系统不需要做太多事情。值得尝试使您的代码异步。
例如，Apache Camel 可能具有最简洁的配置，这里有一个教程。
ESB's are a good way to implement Enterprise Integration Patterns.
Kinds of problems that an ESB helps to solve
Alternatives to an ESB
The alternatives really depend on the problem that you're trying to solve.
What you need to do as a developer to build ESB-compatible systems
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.
For examples, Apache Camel probably has the most succinct configuration, here's a tutorial.
三个关键优势：
但是，请确保这些将为您的情况提供商业价值。拥有 ESB 会给您的企业增加另一种复杂性。理想情况下，您不应基于少数应用程序而应基于整个组织来选择此选项。组织应该只有一个生产 ESB 集群。
替代方案：
实用性：
我已经阐述了可能的替代方案。它们一开始可能看起来很糟糕，但这并不是说你不能这样开始。我个人会编写一些东西来直接与远程通信，而不需要通过 ESB，以确保它可以正常工作，而不必过多担心集成问题。
如果您没有 ESB，我建议您尝试使用 Mule 进行开发，使用 WebSphere ESB 进行测试和生产。我倾向于使用两种据称遵循标准的产品，以确保我们保持供应商的诚实，并确保您的开发人员符合标准，防止无意中的供应商锁定。
最后，只需回答以下问题：从长远来看，为简化企业的其他复杂性而增加一点复杂性的时间值得吗？
Three key advantages:
However, make sure those will provide business value for 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 one production ESB cluster for the organization.
Alternatives:
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.
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.
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?
除了已经提到的网站之外。您应该阅读这篇文章“除非绝对必要，否则不要使用 ESB ”。它是由 MuleSource 的 CTO 编写的，MuleSource 是最流行的开源 ESB 之一。不完全是你问题的答案，更多的是问自己“我需要 ESB 吗”？
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"?
有一个不错的三部分系列位于IBM 认为 ESB 非常面向概念且与供应商无关（大部分情况下）。通过浏览 IBM 网站，我发现了很多关于 ESB 的好东西。 BizTalk 网站<上还有一些不错的信息、视频和内容< /a>.
There is a decent 3-part series over 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.
看看这个Hansel 分钟播客。它回答了您在实施服务总线之前应该真正问自己的几个问题。
Check out this Hanselminutes podcast. It answers a few questions that you should really ask yourself before implementing a service bus.
企业服务总线（ESB）是一种中间件软件架构，为更复杂的架构提供基础服务。例如，ESB 包含实现面向服务的架构 (SOA) 所需的功能。一般来说，ESB 可以被认为是一种管理对应用程序和服务（尤其是遗留版本）的访问的机制，通过基于 Web 或表单的客户端向最终用户提供单一、简单且一致的界面前端。
从本质上讲，ESB 为分布式异构后端服务和应用程序以及分布式异构前端用户和信息消费者实现了中间件真正应该做的事情：隐藏复杂性、简化访问、允许开发人员使用通用、规范的查询、访问和访问形式。交互，在后台处理复杂的细节。 ESB 吸引力的关键，也可能是其未来成功的关键，在于它能够支持由业务需求驱动的增量服务和应用程序集成，而不是由可用技术控制。
http://searchsoa.techtarget.com/definition/enterprise-service-bus
WSO2 企业服务总线（产品）
WSO2 企业服务总线 (ESB) 4.7.0 文档！ WSO2 ESB 是一种快速、轻量级、100% 开源且用户友好的 ESB，根据 Apache 软件许可证 v2.0 分发。 WSO2 ESB 允许系统管理员和开发人员方便地配置消息路由、中介、转换、日志记录、任务调度、故障转移、负载平衡等。它支持最常用的企业集成模式 (EIP)，并支持传输交换、事件、基于规则的中介和基于优先级的中介，以满足高级集成要求。 ESB 运行时被设计为基于 Apache Synapse 中介引擎的完全异步、非阻塞和流式传输。
WSO2 ESB 是在革命性的 WSO2 Carbon 平台之上开发的，该平台是一个基于 OSGi 的框架，通过组件化为您的 SOA 提供无缝模块化。它包括许多可以安装在 ESB 中的功能和可选组件（附加组件），并且您可以轻松删除环境中不需要的功能，从而允许您完全自定义和定制 WSO2 ESB 以满足您的确切 SOA 需求。
架构
企业的应用程序基础设施可能本质上很复杂，包括数百个具有完全不同语义的应用程序。其中一些应用程序是定制的，一些是从第三方获取的，还有一些可以是两者的组合并且可以在不同的系统环境中运行。
这些异构应用程序之间的集成对于企业至关重要。不同的服务可能使用不同的数据格式和通信协议。服务的物理位置可以任意更改。所有这些限制意味着您的应用程序仍然紧密耦合在一起。 ESB 可用于放松不同服务和服务使用者之间的耦合。
WSO2 ESB 是一个成熟的、企业级的 ESB。它基于 Apache Synapse 项目构建，而 Apache Synapse 项目又使用 Apache Axis2 项目构建。所有组件均构建为 OSGi 捆绑包。
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.
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.
http://searchsoa.techtarget.com/definition/enterprise-service-bus
WSO2 Enterprise Service Bus(Product)
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 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.
Architecture
Application 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.
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.
看看我的演示文稿“选择多多 - 如何选择正确的 ESB"。
我解释了何时使用 ESB、集成套件或仅使用集成框架（例如 Apache Camel）。我还讨论了开源 ESB 和专有 ESB 之间的差异。
Take a look at my presentation "Spoilt for Choice - How to choose the right 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 的理由为零。不要这样做。不必要的复杂性。既然可以直接去，为什么还要通过中介呢？ ESB 人员会告诉您点对点不好，但不知何故点对点和来自 ESB 是好的。
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通常用于Event SOA分布式架构，这似乎是当今的热门词。在您进入 ESB 之前，让我提醒您 Martin 的 Fowler 分布式系统第一定律：
http://martinfowler.com /bliki/FirstLaw.html
“我的分布式对象设计第一定律：不要分发你的对象（来自 EAA 的 P）。
相关章节可在线获取。”
当您构建新系统时，最重要的方面是它是面向未来的，这意味着易于扩展和可维护。如果您围绕松散服务的概念构建系统，并在网络环境中分布静态定义的契约，则可以“隐藏”该特定服务所需的体系结构，因为接口仍然存在。
ESB 与异步消息传递系统密切相关，因此在开始进行这种实现之前，请知道架构不必是同构的，即所有服务都以相同的方式实现，不要犯最大的错误：从一开始就分发您的系统，您应该只在需要扩展时分发，而不是事先分发。不过，您需要确保的是，您的服务应该能够在需要时轻松分发，而不会破坏任何合同，这意味着该服务的客户会发生变化。
至于ESB的好处，和SOA一样，ESB增加了异步消息（事件）操作的上下文。
The first question you need to ask yourself is why do you need an 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:
http://martinfowler.com/bliki/FirstLaw.html
"My First Law of Distributed Object Design: Don't distribute your objects (From P of EAA).
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.
As for the benefits of ESB, they are the same as SOA, ESB adds the context of asyn messages (events) operations.
首先让我解释一下SOA。它将架构构建为一组可重用的软件模块，公开为具有明确定义的接口的“服务”。这些服务促进松散耦合并从客户端抽象其实现细节。
如果每个组件都直接调用服务，SOA 最终可能会变得混乱。因此它有以下常见问题。
ESB 是上述问题的解决方案。 ESB……
可以找到一些示例用例此处。请注意，它们来自 AdroitLogic 的开发人员站点，并与 AdroitLogic 的 ESB UltraESB 严格耦合。
First let me explain SOA. It it about building an architecture as a set of reusable software modules exposed as “Services” with well defined interfaces. The services facilitate loose coupling and abstracts its implementation details from the clients.
SOA might end-up messy if each component called on services directly. Therefore it has following common issues.
The ESB is the solution to above issues. ESB…
Some sample use cases can be found here. Note that they are from AdroitLogic's developer site and strictly coupled with UltraESB, AdroitLogic's ESB.