我们的一些合作伙伴告诉我们,我们的软件需要与企业服务总线交互。在对此进行了一些研究之后,我的直觉是说这只是说我们需要一种独立于平台的方式来来回传递消息。我只是想了解我们的合作伙伴告诉我们的内容。我是否正确地驳回了我们合作伙伴的要求,因为只是试图让我们的软件更符合流行语,还是他们告诉我们应该听的东西(即使是用流行语编码)?
6 回答
尽管 ESB 基于消息传递,但它不仅仅是“消息传递”,也不仅仅是一个流行语。
因此,如果您从普通的旧异步消息传递开始,早期的网络往往是非常点对点的。您必须连接(即通过一些管理界面配置)每个连接和每对目的地,如果您敢于移动任何东西,总是会坏掉。由于连接点是手工连接的,因此这些网络从未达到高连接密度。增量成本太高,无法扩展。拓扑中还嵌入了许多访问控制和策略。缺乏连接密度实际上有利于这种安全方法,尽管它抑制了灵活性。
ESB 试图通过...解决这些问题
- 目的地/服务/资源的运行时解析
- 位置透明度
- 任意连接和最大连接密度
- 专为冗余、水平可扩展性、故障转移而设计
- 从拓扑外部化的策略、访问控制、规则
- 在物理消息网络层之上实现的逻辑消息网络层
- 公共命名空间
因此,当您的客户要求 ESB 兼容性时,他们想要上述内容。从应用的角度来看,这也意味着......
- 避免消息相关性,例如要求以严格的顺序处理或仅将请求发送到特定节点而不是通用网络目标
- 能够在运行时动态解析目的地(即添加另一个队列实例,它会自动开始获取流量,删除一个并将流量路由到其余节点)
- 请求者和提供者应用程序与了解彼此的“生活”位置脱钩。请求者建立一个连接,无论它可能需要调用多少服务
- 通过策略而非拓扑授权
- 能够识别和处理欺骗的服务提供者应用程序(根据 JMS 规范,由于会话处理,请参阅“功能重复”)
- 能够运行服务提供商应用程序的多个活动实例
- 检测服务提供商应用程序,以便您可以查询网络状态或执行测试,而无需发送实际交易
另一方面,如果您的客户不能清楚地表达这些事情,那么他们可能只想能够选中一个“与 ESB 一起工作”的框。
我会尽量保持它免费流行语(但流行语首字母缩略词可能会蔓延)。
当服务/应用程序/大型机/等...想要集成(因此相互发送消息)时,您可能会遇到一团糟。ESB 将混乱隐藏在自身(或自身)内部,以便组织可以假装没有混乱并且它有一些可管理的东西。然后,它围绕这个包装了一大堆功能,使这个盒子对组织中决定购买如此昂贵产品的高级人员更具吸引力。这些人通常会想要引入一项花费大量资金的大型计划,以证明他们正在“做某事”并且知道如何花费大量资金。
所以 ESB 是:
- 供应商赚钱的工具;
- 顾问赚大钱的工具;
- 高级管理人员(IT 主管等)展示他们可以花很多钱的一种方式;
- 一个用来隐藏乱七八糟的盒子;
- 供技术团队使用的总 PITA。
在对此进行了一些研究之后,我的直觉是说这只是说我们需要一种独立于平台的方式来来回传递消息。
您是对的,部分原因是 ESB 一词始终是一个很好的词,它与另一个流行词(合法与否)非常吻合——这就是治理(即帮助你管理谁在访问你的端点和报告指标——指标 btw 是所有西装都喜欢的看,所以这可能是贡献者)
他们可能需要平台中立设备的另一个原因是,他们使用的任何服务始终作为来自中心位置的端点公开,而不是特定的机器资源。ESB 使您的服务的实际物理端点与它们无关,无论如何它们都不应该太在意,但这使您能够移动服务,但它们只会使用 ESB 端点。
除了Discovery的集中存储库之外,ESB 还使服务的并行版本控制更加容易。如果我有选择并且我的公司有预算,我们会购买 IBM 的 x150 设备 :(
第三,许多更高级的总线,比如我记得的 SoftwareAG 的产品,本身就能够公开遗留数据,比如来自主机上的数据作为服务,而无需通过适配器进行编码
我不知道他们是否打算利用 ESB 提供的所有好处,或者如您所说,使其符合流行语。
在对此进行了一些研究之后,我的直觉是说这只是说我们需要一种独立于平台的方式来来回传递消息。
这差不多。有时,ESB 会走得更远,并包括附加功能,如消息传递保证、确认/确认消息等。ESB 的存在通常也会显式或隐式地创建一个以前不存在的新协议,这是另一个重要的考虑因素。(也就是说,必须针对消息的格式设置某种标准或接口。)
我是否正确地驳回了我们合作伙伴的要求,因为只是试图让我们的软件更符合流行语,还是他们告诉我们应该听的东西(即使是用流行语编码)?
您应该始终倾听客户的意见,即使最初听起来很傻。通常至少值得花费精力来决定发生了什么。从字里行间看,您的合作伙伴可能的意思是,他们希望您的服务能够更轻松地与他们自己的服务和产品集成。
企业服务总线以标准方式处理系统之间的消息传递。这允许您在所有平台上以完全相同的方式与总线通信,并且总线处理实际转换为特定端点所需的单个通信机制。这意味着您编写所有代码以使用通用消息传递方案与总线通信,并且总线处理采用您的通用方案并对其进行翻译,以便端点能够理解它。
最简单的解释是解释它提供了什么:
多年来,公司获得了不同的平台和技术来实现其业务中从财务到人力资源的特定功能。这些系统需要相互通信以共享数据,因此中间件成为允许它们连接的粘合剂。在企业知道之前,他们为这些系统和中间件中的每一个的支持和维护付费。随着业务需求的变化,各部门决定创建自己的定制解决方案来满足特殊需求,而不是试图使老化的解决方案足够灵活以满足他们的需求。不知不觉中,他们就为支持和维护遗留系统、中间件和定制解决方案付费。有了像 Sarbanes Oxley 这样的新法律,公司需要有更好的信息用于报告目的。单一视图要求它们从所有系统中捕获数据。此外,CIO 现在面临着降低成本和增加客户服务的压力。一种明显的解决方案是消除冗余系统、昂贵的支持和维护合同以及需要专家支持的高成本遗留解决方案。迁移到新平台可以实现这一点,但需要进行过渡。没有可以复制业务的交钥匙解决方案。为了满足移动信息的需求,他们使用 SOA,因为它允许通过通用实体访问信息。如果我从服务总线询问 AllEmployees,它会从 15 个 HR 系统还是 1 个系统中获取它们。当 15 个 HR 系统变为 1 个系统时,调用和结果不会改变,只是在幕后完成的。