在以前的工作中,有很多关于"企业服务总线"(ESB)的讨论.我阅读了关于它的概念书的部分内容,但从未真正理解如何以具体的术语实现/集成它.我熟悉SOA /排队/目录服务/等.但我不明白ESB到底是什么.
它是一个具体的东西(服务/服务器/经纪/等),你只需勾所有的应用程序到它以不同的方式,或者是更多的只是设计系统的概念呢？
任何解释或链接到良好的例子将不胜感激.谢谢.
这是一个相当高级别的抽象概念.中心概念是ESB提供中间件和接口,允许企业在不编写代码的情况下连接应用程序.
这可能包括调解以协调不兼容的协议,数据和交互.
一切都通过的中央总线的想法为额外的抽象层提供了机会.使用行业标准将其他应用程序,客户端等"插入"此总线使得连接新服务,数据源,具有不同需求的客户端相对容易.
就实际实施而言,这是非常大的企业支持业务的领域.虽然这是非常流行的,但目标是通过与互联网比较在一定程度上理解的理想:
一种大型通信总线,具有广泛不同的用途和数据,但都运行标准化协议.
事实上,人们可以将HTTP写入FTP连接器,允许浏览器访问FTP站点而无需调用FTP客户端(现在通常内置在浏览器中).
Mashups演示了一个有趣的实现 - 从旧金山当局获取一些公交路线数据,从谷歌地图和雅虎的寿司栏位置评级并运行一个简单的查询,为您提供最接近的寿司吧,加权它以便您成为愿意为了更好的酒吧而进一步旅行.
所有完全不同的服务,与它们自身不相容,但使用标准连接器(例如雅虎管),它们可以被拉到一起,形成一个有凝聚力和有用的整体.
-亚当
免责声明:我在IBM工作并咨询WebSphere ESB,这是一个旨在构建ESB的IBM产品.以下是我的意见,并不一定反映IBM的立场.
不幸的是,ESB对不同的人来说是不同的东西.
对我来说,ESB是一种可以插入SOA(面向服务的体系结构)的技术,允许您将不同的系统连接在一起.它通常执行协议转换,消息修改,路由,日志记录,充当安全网关等功能.例如,您可以使用ESB公开以前仅作为基于JMS的服务的Web服务提供的服务.
在这方面,ESB实现(或更确切地说,出售用于构建ESB的软件 - 例如我咨询的软件)在技术上通常类似于过去被称为消息传递或排队经纪人,尽管目的有所不同,因为(正如首字母缩略词所暗示的那样)它围绕服务而不是将消息从一个地方移动到另一个地方.技术上的区别有多重要,这是一个意见问题.
我对商业ESB的经验是,它是一种过于昂贵且昂贵的技术,可以解决许多问题.ESB将链接新系统和遗留系统,消息将通过总线传输,所有内容都可以无缝地与其他所有内容进行通信.抛出一些弹性,编排,你就拥有了一个非常强大的企业应用软件.
当您尝试将它们用于实际,为总线编写的开销,创建消息结构等等时,问题就出现了,可能会增加优势.作为一个高成本项目,ESB被视为解决所有技术问题的灵丹妙药,它不是花费在总线上而是在连接的应用程序/数据上花费太多时间.通常情况下,多个竞争标准将在同一组织中争夺至高无上的地位,导致这些系统实际应该修复的经典技术主导的孤岛.
恕我直言,使用创建少量特定接口要好得多,通常只在那些需要它的系统之间使用Web服务.
它基本上是一种设计系统的概念性方法 - 软件公司试图通过坚持上面的"ESB"标签来销售给你更多,而管理者喜欢因为ESB从"更高级别"看起来更好.
ESB基本上是一个MOM(面向消息的中间件),具有附加的数据模型和结构定义管理.您对该总线上的所有应用程序和适配器都有一个通用数据定义(可以是带有共享XSD的XML).连接的任何东西必须发送它遵守此数据定义的信息.ESB支持加载,共享和版本化此公共数据定义.将新组件连接到ESB时,开箱即可获得比将其连接到MOM时更多的"兼容性".该总线上的每个组件在概念上被视为"资源" - 因此引入了额外的抽象来将发送器与接收器分离.
示例:假设您希望在标准的面向消息的中间件中将应用程序A与应用程序B连接,让我们使用JMS.您与从事应用程序B的同事交谈,就主题,消息类型和字段达成一致并发送它(伪代码):sendJms("TRADE.MSFT",{MapMessage trader ="pete"price = 101.4 vol = 100})
如果您在面向服务的体系结构中执行相同的操作,则需要执行此操作
安装附加软件
学习很多新概念
在ESB的admin gui中定义新的Java组件
实现一些由ESB控制的接口
sendJms(getDestination(),{MapMessage trader ="pete"price = 101.4 vol = 100}) - 注意目的地是从ESB注入的
第一次它可能有点痛苦,但我想你可以习惯它,就像你可以习惯EJB的那样;-)
你可以说MOM系统是'无类型'(动态结构),而ESB是'打字'(静态结构).原始Messaging与ESB的权衡取舍类似于其他无类型/类型选择:
REST与SOAP
使用XSD验证的未经验证的XML与XML
Groovy与Java
解释语言与编译语言
对于较小的项目,快速散列功能很好(例如Groovy代码),但对于较大的项目,最好有一个调试器(例如Java),在事情发生时提前发出警告,并在人们提交之前为人们制定标准项目.
因此,如果您的项目受到太多人通过检查未经验证的更改而破坏系统的影响 - 转向更多结构(ESB而不是MOM).如果你的项目没有及时完成足够的事情 - 选择更简单,无类型的解决方案.如果是两个 - 得到一个顾问(只是开玩笑;-)
京公网安备 11010802040832号 | 京ICP备19059560号-6 