总结：精通SOA：基于服务总线的StrutsEJBWeb Service整合应用开发.docVIP

企业服务总线（ESB） 基于BEA公司的AquaLogic Service Bus（服务总线）可以构建SOA，IBM的产品也可以构建ESB。 ESB本质上是对SOA各种服务进行集成管理的核心架构，而不是一个真正的产品。 企业服务总线是指由中间件基础设施产品技术实现的、通过事件驱动和基于XML消息引擎，为更复杂的面向服务的架构提供的软件架构的构造物。企业服务总线通常在企业消息系统上提供一个抽象层，使得集成架构师能够不用编码而是利用消息的价值完成集成工作。 企业服务总线提供可靠消息传输，服务接入，协议转换，数据格式转换，基于内容的路由等功能，屏蔽了服务的物理位置，协议和数据格式。 在SOA中，我们还需要这样一个中间层，能够帮助实现在SOA架构中不同服务之间的智能化管理。最容易想到的是这样一个HUB-Spoke结构，在SOA 架构中的各服务之间设置一个类似于Hub的中间件，由它充当整个SOA架构的中央管理器的作用。请看图三，现在服务的请求者和提供者之间有了一个智能的中转站， 服务的请求者不再需要了解服务提供者的细节。Enterprise Application Integration (EAI)的目标是支持对现有IT系统的重新利用，通过EAI技术能够将不同的软件和系统串联起来，延长这些应用系统的生命周期。传统的EAI，往往使用如 CORBA和COM等的消息中间件进行分布式，跨平台的程序交互，修改企业资源规划以达到新的目标，使用中间件、XML等方法来进行数据分配。因此，实际 上传统的EAI是部件级的重用。很不幸的是，基于部件的架构没有统一的标准，因此，各个厂商都有各自不同的EAI解决方案，你会看到各种各样的中间件平 台。如果EAI碰到了异构的IT环境，就必须分别考虑怎样在各个不同的中间件之间周旋，来实现合理的互联方式，你不得不考虑各种复杂的可能性。因此，你所 见过的大多数传统EAI解决方案都比较笨重。现在该ESB登场了，请看我们的正解： * 面向服务的架构 - 分布式的应用由可重用的服务组成 * 面向消息的架构 - 应用之间通过ESB发送和接受消息 * 事件驱动的架构 - 应用之间异步地产生和接收消息 其次，ESB明确强调消息(Message)处理在集成过程中的作用，这里的消息指的是应用环境中被集成对象之间的沟通。以往传统的EAI实施中碰到的最大的问题就是被集成者都有自己的方言，即各自的消息格式。作为基础架构的EAI系统，必须能够对系统范畴内的任何一种消息进行解析。传统的EAI系统中的消息处理大多是被动的，消息的处理需要各自中间件的私有方式支持，例如API的方式。因此尽管消息处理本身很重要，但消息的直接处理不会是传统EAI系统的核心。ESB系统由于集成对象统一到服务，消息在应用服务之间传递时格式是标准的，直接面向消息的处理方式成为可能。如果ESB能够在底层支持现有的各种通讯协议，那么对消息的处理就完全不考虑底层的传输细节，而直接通过消息的标准格式定义来进行。这样，在ESB中，对消息的处理就会成为ESB的核心，因为通过消息处理来集成服务是最简单可行的方式。这也是ESB中总线(Bus)功能的体现。其实，总线的概念并不新鲜，传统的EAI系统中，也曾经提出过信息总线的概念，通过某种中间件平台，如CORBA来连接企业信息孤岛，但是，ESB的概念不仅仅是提供消息交互的通道，更重要的是提供服务的智能化集成基础架构。 最后，事件驱动成为ESB的重要特征。通常服务之间传递的消息有两种形式，一种是调用(Call)， 即请求/回应方式，这是常见的同步模式。还有一种我们称之为单路消息(One-way)，它的目的往往是触发异步的事件， 发送者不需要马上得到回复。考虑到有些应用服务是长时间运行的，因此，这种异步服务之间的消息交互也是ESB必须支持的。除此之外，ESB的很多功能都可以利用这种机制来实现，例如，SOA中服务的性能监控等基础架构功能，需要通过ESB来提供数据，当服务的请求通过ESB中转的时候，ESB很容易通过事件驱动机制向SOA的基础架构服务传递信息。 ESB应该具备的基本功能。ESB承担的重任还包括怎样将企业架构中已存在的业务服务连接到总线上来，我们称之为适配器(Adapter)功能尽管服务本身已经用公开的接口来描述，但具体的实现还是运行在不同的环境中，因此，ESB还应该提供对服务底层协议的，譬如应用协议J2，.Net， 通讯协议如Http，JMS等等还需要对具体应用中涉及到的服务加以管理，如性能，可靠性，安全性等等。 图7-3 进入RAD主页面 Project Explorer是RAD的主要项目管理界面，它用来管理RAD下面的各种项目，主要包括创建项目、修改项目的内容、删除各种项目等。下面对其所管理的项目进行一个总