CharlieShen

新人,大家多关照啦@_@

  博客中心 :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 登录 ::
  3994 随笔 :: 0 文章 :: 20 评论 :: 0 Trackbacks
Cached @ 2025/4/26 19:09:27Control ASP.skins_cogitation_controls_blogstats_ascx
<2007年8月>
2930311234
567891011
12131415161718
19202122232425
2627282930311
2345678

留言簿(14)

随笔档案

文章档案

搜索

最新评论

阅读排行榜

评论排行榜

Cached @ 2025/4/26 19:09:27Control ASP.skins_cogitation_controls_singlecolumn_ascx
在本系列文章中给出的示例和场景全部基于虚构的 Posts-R-Us 公司,该公司各个业务部门拥有不同的现有异构系统和解决方案,希望能提高这些系统的可访问性、连接性和集成。该公司决定使用企业服务总线 (Enterprise Service Bus) 的体系结构模式来实现这些目标,从而开始建立面向服务的体系结构(Service Oriented Architecture,SOA)的初始步骤。

  虽然 Posts-R-Us 不是真实的企业,但我们在实际项目中遇到了与此非常相近的很多情况。现有业务功能和业务流程的工作越来越多地由服务层(通过 ESB 实现)加以表示,从而保留在这些解决方案中所做的投资的价值。从最简单的层面而言,ESB 必须提供对一组网络协议的支持,并必须能够在消息通过系统时进行转换。而这正是我们在这些文章中所提到的场景类型,我们已经说明了如何方便地使用 WebSphere ESB 对其加以实现。

  第 1 部分介绍了 ESB 的基本功能及新 WebSphere ESB 产品相对于其旧版本(IBM WebSphere Application Server 中的 SIBus 功能)的功能定位。WebSphere ESB 所添加的功能包括更好的工具 (WebSphere Integration Developer) 和新的面向服务的编程模型——服务组件体系结构(Service Component Architecture,SCA)。

  第 2 部分介绍了一个基本的但非常强大的场景:在基于 JMS 的服务请求者和基于 JMS 的服务提供者之间插入 ESB,使用消息驱动的 Bean (MDB) 表示。请求者与提供者的这个分离带来了二者之间一定的独立性,从消息格式和网络协议的角度均是如此。也就是说,可以在消息通过 ESB 时对其进行更改,这一点对请求者和提供者都是透明的。而且,尽管在这种情况下请求者和提供者都使用 JMS 作为传输协议,但任意一方都可以在不影响另一方的情况下切换到其他协议。我们在此示例中构建的交互是“单向的”,即请求消息以异步方式发出,没有任何响应。

  第 3 部分介绍了 WebSphere ESB 对 Web 服务的支持。WebSphere ESB 中的中介是遵循 SCA 标准的服务组件,因此可以作为 Web 服务进行访问。反过来,中介组件可以通过 Web 服务接口调用外部服务提供者。和第 2 部分中一样,服务请求者和服务提供者使用了相同的协议,即 SOAP/HTTP。ESB 仅仅充当二者之间的中间层,以对二者进行分离。第 3 部分还说明了如何在运行时使用 WebSphere ESB 管理控制台更改服务提供者的端点地址。不过,随着 IBM WebSphere Services Registry and Repository 产品的出现,可以采用更为成熟和可靠的方法进行动态路由。(我们稍后将再次对此进行讨论。)

  最后,第 3 部分介绍了 WebSphere ESB 的一个非常重要的功能,其也可用于在运行时更改中介的行为方式:提升的属性。中介流组件中的每个中介原语都具有一组能进行“提升”的属性,以便在运行时通过管理控制台进行更改,从而向中介添加动态行为。这种情况下的交互是同步的,服务请求者发送请求消息,并阻止所有消息,直到收到相应的响应消息为止。

  在前面的示例场景中使用 JMS 和 SOAP/HTTP 作为基础协议之后,第 4 部分利用了针对 WebSphere MQ 的本机 WebSphere ESB 支持(在 Version 6.0.2 中引入)。文章中的示例突出说明了 SCA 一个非常强大的功能:能够向现有中介添加其他协议支持,而不会影响组件本身,也不会影响任何已经存在的请求者或提供者。第 4 部分对第 2 部分的 JMS 示例进行了重用,仅添加了一个新的服务提供者。请求消息现在不仅通过 JMS 发送到基于 JMS 的服务提供者,而且通过 WebSphere MQ 转发到远程 MQ 队列管理器控制的队列。服务请求者和中介流组件本身根本不会发生改变,因此不涉及到编程工作。

  第 5 部分讨论了在服务请求者和服务提供者支持的协议之间进行切换的场景。此部分没有向场景添加新服务提供者(如第 4 部分中所述),而添加了一个额外的服务请求者。事实上,我们进行了两次此工作:我们重用了之前部分的 JMS 场景和 SOAP/HTTP 场景,从而形成了请求者与提供者之间非常复杂的协议与交互方式。对于异步 JMS 示例,我们添加了(同步)SOAP/HTTP 服务请求者。对于(同步)SOAP/HTTP 示例,我们添加了(异步)基于 MQ 的服务请求者。同样,所有这些都是在不涉及中介流组件本身且不更改任何现有代码的情况下进行的。我们转而采用了 SCA 所提供的导入和导出支持(可以通过 WebSphere Integration Developer 中的组装编辑器开发)。

  第 6 部分是对全系列中所有文章的回顾与总结,并将提供可进行进一步研究的更高级场景的概述。

分享按钮发布于: 2007-08-25 21:49 CharlieShen 阅读(201) 评论(0)  编辑 收藏