53企业服务总线解决方案剖析-第6页
上亿文档资料，等你来发现
53企业服务总线解决方案剖析-6
本文基于一个示例场景讲述了应用WBI5系列产品构；第4部分:企业服务总线的实施策略与总线集成；军张,IBM中国软件开发实验室SOA设计中心软件；珉李,IBM中国软件开发实验室SOA设计中心高级；俊刘朝,IBM中国软件开发实验室SOA设计中心软；引言；在企业服务总线应用解决方案系列的前面三篇文章中，；IBM对ESB的产品支持；到目前为止，IBM专门支持ESB实
本文基于一个示例场景讲述了应用 WBI 5系列产品构建 Enterprise Service Bus 的基本方法，使用到的产品和技术，并提供了示例场景实现。是作者在多个 SOA 实际项目经验的总结和提炼，希望能够对有意在企业架构中应用 SOA并实现 ESB 的IT架构师提供一定的帮助。 第 4 部分: 企业服务总线的实施策略与总线集成军 张, IBM 中国软件开发实验室 SOA设计中心 软件工程师珉 李, IBM 中国软件开发实验室 SOA设计中心 高级软件工程师俊 刘朝, IBM 中国软件开发实验室 SOA设计中心 软件工程师引言在企业服务总线应用解决方案系列的前面三篇文章中，作者对ESB的技术特征，ESB在WAS6 SIBus上的实现，以及在WBI MB5上的实现分别作了较为详细的论述，相信大家都对ESB已经有了一定程度的理解。总而言之，ESB是SOA体系架构中的信息流动与交换的基础。ESB的参与主体是服务，总线提供了服务间消息的识别，转换与路由的载体。但是，看起来，读者可能还会有一定的疑惑，ESB首先是一种概念，实现的方案又很灵活，最终支持ESB的产品也很多，那么，前面介绍过的ESB实施方案与具体技术各自适用的场合有什么特点？基于不同实施方案的ESB又是如何互联的呢？本文将对上述问题加以总结。 IBM对ESB的产品支持到目前为止，IBM专门支持ESB实施的主要有3种产品，WAS6 SIBUS，WAS ESB，和WBI Message Broker。这里按照他们出现的先后顺序简单地介绍一下他们的使用场合：1） WBI Message Broker最早提出Message Broker(或它的前身Event Broker)的主要目的，是针对中间件平台不同消息格式的自动转换与路由，支持Web Service(SOAP), MQ, JMS 等不同中间件平台的消息互联以及与现有系统的消息集成。因此，虽然Message Broker一开始主要是针对EAI的一种集成方案，你仍然可以从中看出Message Broker的设计初衷与我们现在的ESB的思想是基本一致的。尽管Message Broker出现的时候还没有明确的ESB概念，但是，随后IBM在SOA上投入了巨大的努力，作为SOA基础架构的ESB，也得到了非常的关注。Message Broker逐渐发展成为专门的ESB实施工具，而且依托完善的MQ消息平台，它对ESB的支持是重量级的，是目前构建ESB最强大的产品。确实，理论上大多数常见类型的消息都可以通过WBI Message Broker加入到SOA的实施场景中。而且，更重要的是Message Broker是真正适合复杂企业环境的ESB实施方式，它的成熟性与性能都是几个方案中最好的。唯一的不足是，如果应用在不很复杂的企业应用环境中，会略显笨重。而它使用的ESQL语言，由于不是基于开放标准的，也会对使用者的学习曲线有一定影响。2） WAS6 SIBus我们前面已经提及SOA架构与面向消息的中间件之间密不可分的关系。为了更好的支持SOA， IBM重新开发了内嵌在WAS应用服务器中的消息服务实现。因此，从WAS6 以后的内嵌消息引擎不再是原来的MQ的简版，而是一种功能更强的更稳定的消息平台-WPM(WebSphere Platform Messaging)。它是一个纯JAVA的实现，符合JMS的规范，而且提供了很多扩展。能够很好的同时支持面向服务和面向消息两种编程模式。因此，能够将服务与消息很好的整合在一起。SIBus是一种依托WAS6 应用服务器平台的ESB实现，支持Web Service, JMS 和MQ的消息互联与转换。它的应用场景应该是基于WAS的环境中，面向Web service与JMS类型的企业服务。它的问题主要是开发的难度比较大，由于没有很好的开发工具的支持，开发者需要有较丰富的J2EE/EJB的开发经验，而且还需要通晓WAS6 SIBus的相关API与配置，这无疑限制了SIBus的进一步发展。3） WAS ESBWebSphere ESB是 IBM 正式发布的独立ESB产品。它目前所能覆盖的平台只有WAS。看起来与SIBus有些相似，但实际上它发布的目的主要是补充WBI Message Broker。我们前面讲过，WBI Message Broker实施的场景是复杂的企业IT架构，但是一般规模的企业可能对采用这种昂贵的解决方案有所顾虑。那么在这种环境下，小规模的ESB解决方案，WAS ESB是性价比更好的选择。但是，WAS ESB将更倾向于提供只涉及Web服务的总线，这与Message Broker的广泛适用性有一定差距。WAS ESB对SIBus，如果单从体系结构的角度他们都基于WAS的WPM，象一对孪生兄弟。他们最重要的区别在于WAS ESB提供了基于SCA的开发模式和完备的开发工具，并且提供了预先定义的元中介(Mediation Bean)。这样用户通过工具WID (WebSphere Integration Developer），可以采用拖拽/配置的方式简单地开发中介的信息流, 实现ESB不再是复杂的任务。而SCA（Services Component Architecture）组件对用户屏蔽了底层的实现细节，WPM或SIBus中介句柄(Mediation Handler)对用户来说是不可见的。关于WAS ESB中的SCA开发模式，笔者将另外撰文，这里不再赘述。总而言之， WAS ESB可以被视为ESB实施的简化版，适用于不需要Message Broker复杂性的相对简单的环境。它相比SIBus而言，具有开发界面友好的优势，但由于采用SCA封装底层的服务，可以想见在它的早期版本可能会带来性能上的一定损失。 图 1：WAS ESB与 WBI Message Broker的比较 这是一张关于WAS ESB与WBI Message Broker关系的预测图，希望大家能从中得到感性的认识。针对不同的场景和开发者的技术经验，采用更合理的设计方案。 SIBus与Message Broker的集成根据我们前面的讲解，无论采用哪一种ESB解决方案，ESB的各个总线之间应该是可以互联的。至少采用IBM产品所开发的ESB总线都因该能够顺利地集成在一起，这样ESB的设想才能成立。用户在SOA和ESB上的投资能得到有效的保护，这也是SOA倡导的核心思想-重用。单纯用SIBus或Message Broker构建的同类ESB总线，它们之间的交互方式我们在这里就不再讨论了，欢迎大家阅读WAS的信息中心（infocenter）找到答案，技术上的实现并不困难。比较难办的是SIBus(或WAS ESB)与WBI Message Broker如何实现互联。下面我们将就这一问题加以讨论。在本系列文章的第二和第三部分中，我们已经分别介绍了两个实例，这里我们将在他们的基础上延伸出一个新的案例场景，实现SIBus的总线与Message Broker 总线的互联。本样例首先包含一个的零部件价格查询模块，某制造企业所需要的零配件可能来自各个厂商，也有可能是自己制造的，同时，它所制造的零件也可能被它的内部用户或者外部用户来查询。由于零件的价格变化比较频繁，所以这些价格的查询需要是即时的价格。这一零件价格查询的样例已经在本系列的第二部分中以WAS6 的SIBus的方式上实现。同时，在这家企业的订单请求处理系统中，企业中的订单管理系统接收到客户的订单请求后，首先到库存管理系统中检查当前库存能否满足订单的要求，如果不能满足则需要到生产制造系统中去安排生产，最后向用户发出订单确认。在本系列的第三部分中，订单系统在WBI Message Broker上实现。我们现在设计这样一个场景，用户在查询订单价格的时候，可以直接选择，当某零件是自己制造的且库存为零的时候，向订单子系统直接发出订单请求。这是一个单向的服务调用，订单的生产状态被放到一个队列中供查询。这样一个案例涉及两个ESB总线的互联。实质上我们要考虑的是两个ESB底层消息中间件如何进行不同格式的消息转换以及不同体系的消息目的地地址如何相互定位。 SIBus与MQ的消息集成我们在Message Broker中实现了一个消息流，其中集成了两个生产系统暴露出的订单请求的Web服务。一个是公司内部的甲地的制造企业的生产产品的Web服务接口，而另外一个则是公司内部的乙地的制造企业的订单请求的Web服务接口。而产品的订单请求具体是到甲厂还是乙厂生产，则取决下订单时所携带的路由信息。Message Broker的消息流处理的是MQ的队列的消息，因此SIBus与Message Broker的互联实质上只是SIBus与MQ的互联。SIBus只会与WBI Message Broker的消息流的入队列和出队列交互。SIBus将订单请求放到Message Broker的入队列中，而Message Broker会将消息处理完后放到出队列中。因此在我们这个场景中，我们需要做的就是在用户查询自己的零件的价格时，如果该零件的库存量为零，就需要通过SIBus向Message Broker部署的消息流的入队列发送一条消息。并且通过读写Message Broker处理完放入到其MQ出队列中的消息查询所下订单的状态。 图2：SIBus与MB之间连接时的业务流程 Websphere 6支持服务集成总线（SIBus）与Websphere MQ的互联，通过两者的互联，可以实现消息在SIBUS与MQ平台之间信息流的互通，而用户则无需考虑其中的消息格式的转换和寻址。实现SIBus与MQ互联，需要做的主要工作是在SIBus和MQ中配置与对方通信的相应配置。由于SIBus与MQ是两个单独的产品，所以它们之间的通信需要在配置时使用相同的名称来达到识别的目的。在SIBus上需要定义外部总线，消息引擎的MQ链接等。其中的消息引擎的MQ链接是关键之处，其发送方通道的配置告诉SIBus如何找到Websphere MQ的队列管理器，而接受方通道则是从MQ接受消息。在Websphere MQ中的配置相对来说则更易理解，因为MQ中的配置其实就是与远程队列管理器的配置一样。在MQ看来，SIBus上的消息引擎似乎就是一个远程主机上的MQ队列管理器，通过在MQ上定义发送方通道和传输队列，就可以实现两者的连接。如果需要从MQ上发送一个消息到达SIBus上只需在MQ上定义一个远程队列。远程队列的作用就是将消息映射回SIBus上定义的本地队列中。下面分别介绍在SIBus与MQ中需要做的配置，以及在配置完成后如何定义队列使的消息可以实现在SIBus和MQ之间自由发送。详细的配置步骤会在样例下载中有安装文档说明，这里只是介绍重要的概念。 SIBus中的配置1）首先需要在SIBus中定义外部总线，需要注意的是必须将&路由定义类型&选为&直接，MQ链接&，这说明了外部总线的类型。当需要在Websphere中互联SIBus时就需要定义外部总线。这里我们虽然不是SIBus之间的互联，但是为了和Websphere之外的MQ连接，也需要定义外部总线。在外部总线上我们可以定义属于其的外部目标，而这个外部目标将扮演MQ中的队列在SIBus中的代理。下面我们在配置消息传递引擎上的MQ链接时，需要使用这个外部总线名。2）定义消息传递引擎，把服务器作为总线成员添加后，总线上就会有对应的消息传递引擎。消息传递引擎会实际负责与MQ通信的处理。我们需要在消息传递引擎中创建&Websphere MQ链接&来设置其与MQ互联的参数。选择&LOCALBUS&的&其他属性&=&&消息传递引擎&。单击引擎名，选择&其他属性&=&&Websphere MQ链接&，一共有四个步骤需要完成。分别详细说明如下。步骤1、链接名称设置为&BusToMQ&,外部总线选择&FOREIGN_BUS&,队列管理器名称&QM_TheBus&，单击&下一步&。链接名称是一个可选的参数，可以自由命名。但是外部总线名称必须选择在此之前创建的外部总线，例中为&FOREIGN_BUS&。队列管理器的名称也很重要，前面说过，消息传递引擎在MQ看来就类似一个远程的MQ,而MQ与SIBus的通信方式与普通的远程主机上的MQ的通信的配置并没有什么不同。既然消息传递引擎模拟MQ，那么我们就需要定义队列管理器的名称。例中为QM_TheBus,这个名称在后面MQ的配置仍然会发挥作用。它必须与MQ中定义的发送方通道的传输队列的名称一致。它也是在MQ中定义一个远程队列时所映射到的SIBus上的本地队列的队列管理器的名称。 图 3：设置一般Websphere MQ链接属性 步骤2：发送方通道 WebSphere MQ 链接属性。发送方通道和接收方通道成对地起作用。该通道将成为用于将消息从总线发送到 WebSphere MQ 的连接。它需要与我们的MQ的队列管理器所使用的名称、主机名和端口相匹配，以接收来自总线的消息。缺省情况下，队列管理器使用端口 1414 接收传入的消息。由于我们的样例中MQ与SIBus存在于同一台主机上，因此主机名为localhost。这也是Message Broker所部署的消息流所在的主机名。 需要注意的是这里定义的发送方MQ通道名必须与后面MQ配置中定义的接受方通道名一致。在没有启用安全性的情况下，传输链选择如图所示的OutboundBasicMQLink图4：设置发送方通道Websphere MQ链接属性包含各类专业文献、专业论文、外语学习资料、幼儿教育、小学教育、行业资料、生活休闲娱乐、高等教育、53企业服务总线解决方案剖析等内容。　
　技术, 新的组件模型, 比如说 Web S 从架构设计师的角度, SOA 就是一种新的设计模式, 方法学;从业务分析人员的角度,SOA 就是基于标准的业务应用服务。... 　 ESB企业服务总线解决方案剖析_计算机软件及应用_IT/计算机_专业资料。ESB 企业服务总线解决方案剖析(1)
15:31 ... 　 理解面向服务的体系结构中企业服务总线场景和解决方案_IT/计算机_专业资料。理解...(Enterprise Service Bus,ESB)的这个系列的第二部分中,作者描述和分析了实 现 ... 　企业服务器总线解决方案
来源:畅享网 我要评论 导读:本文介绍了企业服务总线 ESB 解决方案,如果使用正确,这种技术能够利用 SOA 的原则,同时扩大老式... 　 企业服务总线解决方案剖析 37页 2财富值 Oracle 企业服务总线体系结... 暂无... 第1 部分 企业服务总线中的工作角色 Rick Robinson (rick_robinson@uk.ibm.... 　 SOA集成平台普元ESB新版即将发布,企业服务总线,集成解决方案_互联网_IT/计算机_...服务查找等功能,尤其提供了便捷的 服务监控和运行日志分析功能,为有效的部署和... 　 谈及企业服务总线_计划/解决方案_应用文书。谈及企业服务总线 (ESB) ,在有...? 分析: 分析: 为了在 ESB 市场上抢占有利位置, 各大厂商提供的 ESB 产品... 　 2014教师资格材料分析辅... 2014小学教师资格考试《... 2014年幼儿园教师资格... 企业服务年方案 3页 免费 企业服务总线解决方案剖... 37页 1下载券 关于... 　 基于SOA的企业服务总线研究与实现_企业管理_经管...使得电力企业迫切需要一个能够解决企业间集成的方案,...和企业产出的瓶颈,并且难以提供企业级的决策分析支持...什么是ESB，企业服务总线 - 会飞的鱼 - ITeye技术网站
CodeHaus发布了ESB的实现Mule 1.0，在SOA被大肆鼓吹的氛围下成长起来的ESB总算揭开了一个面纱！那么什么是ESB呢？我们知道SOA体系结构要求企业里面所有的和业务相关的应用程序都应该提供webservice的接口。那么一旦这一步实现了之后，所有的应用程序面临的问题就是如何去调用这些或者说这么多接口，当然使用webservice的客户端采取同步调用的方式当然是可以的。同时如果企业应用有可伸缩性要求，那么也可以采取异步的消息调用机制。而ESB就是采用了消息封装这一思想，把所有对服务的调用都通过统一的消息接口封装起来，无论消息是同步的还是异步的。此外ESB还可以对企业的其他消息服务也提供同样的借口，例如mail,JMS,IBM MQ,MSMQ等等。ESB可以有那些用 ?ESB不是万能的,他不是一个应用程序框架,也不是一个企业应用的解决方案.它只是一个基于消息的调用企业服务的通信模块!你可以把它嵌入到你的应用程序框架中,例如嵌入到spring容器里面,或者嵌入到工作流系统中.它的作用是对企业里面的SOA服务的调用提供一个框架和简便的方法.ESB距离实际的企业应用还有哪些不足?ESB目前有很多商业方案,也有很多开源产品,例如ObjectWeb,CodeHaus,Sourceforge都有这样的开源项目.距离真正成熟还有一段距离,另外各家厂商都各自为阵,目前JCP还没有这项技术的草案,标准的指定也还有很长的距离.当然,目前的状态和SOA一样.相信等SOA真正普及的时候,ESB会更加的成熟.
浏览: 197954 次
来自: 杭州
&property name=&srcDir& ...
非常好，谢谢分享。
exception handlers 译成
例外处理 倒是第 ...