有人可以用非buzzspeak向我解释企业服务总线吗?

Jas*_*ker 33 integration messaging soa esb

我们的一些合作伙伴告诉我们,我们的软件需要与企业服务总线进行交互.在对此进行了一些研究后,我的直觉就是说这只是嗡嗡声说我们需要一种以平台为依据的方式来回传递消息.我只是想了解我们的合作伙伴告诉我们的事情.我是否正确地拒绝合作伙伴的要求,只是试图让我们的软件更符合流行语,或者他们是否告诉我们应该听的东西(即使用buzzspeak编码)?

T.R*_*Rob 38

尽管ESB基于消息传递,但它不仅仅是"消息",而不仅仅是一个流行语.

因此,如果您从普通的旧异步消息开始,早期网络往往是非常点对点的.你必须连接(即通过一些管理界面配置)每个连接和每对目的地,如果你敢于移动任何东西,总是有些东西坏了.由于连接点是手动连接的,因此这些网络从未实现高连接密度.增量成本太高而且没有扩展.拓扑中还嵌入了大量访问控制和策略.缺乏连接密度实际上有利于这种安全方法,即使它抑制了灵活性.

ESB尝试用......解决这些问题

  • 目标/服务/资源的运行时解析
  • 位置透明度
  • 任意连接和最大连接密度
  • 专为冗余,水平可扩展性,故障转移而设计
  • 策略,访问控制,拓扑外部化的规则
  • 在物理消息传递网络层上实现的逻辑消息传递网络层
  • 通用命名空间

因此,当您的客户要求ESB兼容性时,他们需要上述内容.从应用的角度来看,这也意味着......

  • 避免消息亲和性,例如要求严格按顺序处理或仅向特定节点而不是通用网络目的地处理请求
  • 能够在运行时动态解析目标(即添加队列的另一个实例,它会自动开始获取流量,删除一个流量并将流量路由到其余节点)
  • 请求者和提供者应用程序与知道彼此"活着"的位置分离.无论可能需要调用多少服务,请求者都会建立一个连接
  • 按策略而不是拓扑授权
  • 能够识别和处理欺骗的服务提供商应用程序(根据JMS规范,由于会话处理,请参阅"功能重复")
  • 能够运行服务提供者应用程序的多个活动实例
  • 检测服务提供商应用程序,以便您可以查询网络状态或执行测试而无需发送实际事务

另一方面,如果您的客户无法清楚地表达这些内容,那么他​​们可能只想查看一个"与ESB一起工作"的方框.


Nei*_*eil 25

我会尝试保持它的流行语免费(但一个嗡嗡声的缩写可能会蔓延).

当服务/应用程序/大型机/等...想要集成(所以相互发送消息)时,你最终会陷入混乱.一个ESB隐藏那些乱七八糟的本身(或itselves)的内部,使得组织可以假装没有一个烂摊子,它有什么管理.然后它围绕着这一点包含了大量功能,使得这个盒子对于那些决定购买如此昂贵的产品的组织中的高级人员更具吸引力.这些人通常会想要引入一项大型计划,这项计划花费了大量资金来证明他们"做某事"并且知道如何花费大量资金.如果这是一项SOA计划,那么各种供应商都会告诉他们,ESB需要让供应商了解SOA的工作原理(通常一旦他们想要的服务数量通过一个微不足道的数字).

所以ESB是:

  1. 供应商赚很多钱的工具;
  2. 顾问赚很多钱的工具;
  3. 高级管理人员(IT主管等)的一种方式,表明他们可以花很多钱;
  4. 一个隐藏乱七八糟的盒子;
  5. 完整的PITA,供技术团队使用.

  • 而那些讽刺的回答引发了轩然大波.: - /很难说这是真诚还是诙谐,但无论如何,我希望能够产生一个答案,为那些不管是好还是坏,最终都在ESB项目上工作的人提供一些指导,这不是它.我不是在争论这里的任何事情都是不真实的(这只是一些有趣的谈话)只是对于那些需要加快速度并产生一些成果的人而言,这并不是非常有效. (4认同)

kd7*_*kd7 9

在对此进行了一些研究后,我的直觉就是说这只是嗡嗡声说我们需要一种平台相关的方式来回传递消息

你是对的,部分是因为术语ESB总是很好用,与其他流行语很合适,合法与否 - 这就是治理(即帮助你管理谁正在访问你的终端并报告指标 - 指标btw是所有适合的看,这可能是一个贡献者)

他们可能需要平台中立设备的另一个原因是,他们使用的任何服务始终作为端点从中心位置而不是特定的机器资源公开.ESB使您的服务的实际物理端点与它们无关,无论如何它们都不应该太在意,但是这使您可以移动服务,但它们只会消耗ESB端点.

除了Discovery的集中存储库之外,ESB还可以更轻松地并排版本化服务.如果我有一个选择并且我的公司有预算,我们就会购买IBM的x150设备:(

第三,许多更先进的总线,如我记得的SoftwareAG的产品,本身能够公开遗留数据,例如从作为服务的主框架上的数据,而不需要通过适配器编码

我不知道他们的意图是利用ESB提供的所有好处,还是正如您所说,使其符合流行语.


Joh*_*lla 7

在对此进行了一些研究后,我的直觉就是说这只是嗡嗡声说我们需要一种平台相关的方式来回传递消息

那是对的.有时,ESB会更进一步,并包含其他功能,如邮件传递保证,确认/确认消息等.ESB的存在通常也明确地或隐含地创建一个以前都不存在的新协议,这是另一个重要的考虑因素.(也就是说,必须根据消息的格式设置某种标准或接口.)

我是否正确地拒绝合作伙伴的要求,只是试图让我们的软件更符合流行语,或者他们是否告诉我们应该听的东西(即使用buzzspeak编码)?

你应该经常听你的顾客,即使它最初听起来很傻.通常值得至少花费精力来决定发生了什么.阅读这些内容,您的合作伙伴可能意味着他们希望您的服务方式能够更轻松地与自己的服务和产品集成.


Chu*_*nes 6

企业服务总线以标准方式处理系统之间的消息传递.这允许您以相同的方式在所有平台上与总线通信,并且总线处理实际转换为特定端点所需的单独通信机制.这意味着您使用通用消息传递方案编写所有代码以与总线通信,并且总线处理采用您的通用方案并进行转换,以便端点理解它.