《soa agents：当网格遇上soa》由会员分享，可在线阅读，更多相关《soa agents：当网格遇上soa（7页珍藏版）》请在金锄头文库上搜索。
1、最近几年，SOA获得了巨大进步。它由软件爱好者的实验性实现走向了今天IT的主流。这一进步背后的一个主要驱动力就是对服务接口背后现有企业IT资产的合理运用和虚拟化能力，而这一能力又是与企业业务模型和当下及今后的企业流程高度对齐的。此外，通过引入企业服务总线实现了SOA的进步，而它正是一个虚拟化服务基础设施的模式。通过利用仲裁、服务位置解析、服务水平协议（SLA）支持等，ESB允许软件架构师显著地简化服务基础设施。整个SOA中所缺失的最后一个环节就是企业数据访问。文献1,2引入了针对该问题的一个可行性解决方案，企业数据总线（EDB 一种统一访问企业数据的模式）。EDB为SOA虚拟化加入了第三维度，
2、这使得SOA虚拟化可以被分解成：服务：IT资产的虚拟化；ESB：企业服务访问的虚拟化；EDB：企业数据访问的虚拟化；在其它SOA开发中，一些文章3,4,5建议使用网格技术来增进SOA实现的可伸缩性、高可用性和吞吐量。在这篇文章中，我将讨论如何把网格运用到整体的SOA架构中，并介绍一种在服务实现中利用网格的编程模型。我同时还会讨论一个支持这一架构提议的实验性网格实现。包含EDB的SOA整体架构按照1,2，带EDB的SOA整体架构如图1所示图1：包含企业数据总线的SOA架构在这里，ESB负责调用合适的服务，这是通过利用EDB访问这些服务可能需要的企业数据来实现的1。这一架构提供了如下的优势：显式地
3、分离了服务功能实现（业务逻辑）与企业数据访问逻辑之间的关注点。 企业数据总线有效地创建了一个抽象层，将企业数据访问的细节封装在内，为服务实现提供了“标准化接口”。EDB通过将所有对企业数据的访问进行封装，为服务使用的企业语义数据模型2与企业应用数据模型之间的所有转换提供了单一的场所。结果，服务实现可以通过SOA语义模型来访问企业数据，从而极大简化了企业服务的设计与实现。服务实现得以访问由EDB提供的所需企业数据，大大简化了服务接口，并在服务消费者和提供者之间提供了松耦合： 因为服务(消费者)可以直接访问数据2，例如，服务调用并不要求真实的参数值(输入/输出)作为服务调用的一部分来发送。所以作为
4、结果，服务接口可以按照数据引用(键)而不是真实数据来表达。虽然企业服务模型会随SOA实现的成熟而演化，但数据引用的定义却很少发生变化。其结果是，基于键数据的服务接口将更加稳定。使用额外数据来扩展服务实现可以在不影响其消费者的情况下办到。加入网格EDB的一个可行实现是使用数据网格，如Websphere eXtreme Scale，Oracle Coherence数据网格，GigaSpaces数据与应用网格或者NCache分布式数据网格。数据网格是为构建某类解决方案而设计的软件系统，其适用的解决方案范围从简单的内存数据库到分布于规模达数千台服务器之上的强大分布式一致缓存。典型的数据网格实现会将数据
5、分割到跨机器存储于内存里的不重合的块中。其结果是，通过标准的流程可达到极高水平的性能和伸缩性。性能是通过并行执行更新和查询(数据的不同部分可以在不同的机器上同时访问)实现的，而伸缩性和容错性则通过在多台机器上复制同一数据得以实现。图2展示了使用网格作为EDB的实现。网格维持了企业数据的内存拷贝，它代表了企业数据库和应用的状态。图2 作为EDB的网格网格的引入允许重新分割存在于多个数据库和应用的数据，以便让它符合企业语义模型。这需要将企业中不同应用/数据库中逻辑相关的数据一起并入到一个统一、内聚的数据表示中，并不可避免地伴随着对企业中重复数据进行合理化。网格的实现典型的是由发布/订阅机制来支持的
6、，这使得数据变更在网格内存和现有企业应用及数据间保持同步。一个基于网格的仲裁可以利用专为该服务使用而优化的数据模型高速访问企业数据。尽管基于网格的EDB(图2)简化了对企业数据的高速访问，它仍然有可能要求EDB和服务实现之间进行大量的数据交换。服务必须加载所有所需数据，执行其处理，然后将结果存储回网格中去。一个更优的架构是让服务执行点离企业数据更近；将服务实现为Agent(代理)的协调人7，而这些Agent则在包含企业数据的内存空间里执行(图 3)。在这个例子中，服务实现接收一个请求并启动一个或多个Agent，它们在网格节点的上下文里执行，将结果返回给服务实现，服务实现再组合Agent 的执行
7、结果并将服务执行结果返回。图3 作为Agent协调人的服务较发布/订阅数据交换模型而言，这一方式提供了如下优势：它允许操纵本地数据，这极大的提升了整体的服务执行性能，特别是当处理大量数据时（MB或GB的数据）类似于数据分割，真正的执行被分割到多个网格节点之间，因此更进一步提升了这一架构的性能、伸缩性和可用性。因为所有服务都可以访问同一数据，当服务执行仅仅只通过最少数目的请求/响应处理数据时，根本没必要传输数据。软件AgentAgent的概念可以回溯到分布式人工智能(DAI)的早期研究，当时引入了这一自完备、可交互、并发执行的对象概念。这一对象有某些被封装好的内部状态并能对其它类似对象发来的消息
8、作出响应。根据文献7，“一个Agent是一个能精确行动以代表用户完成任务的软件组件以及/或硬件。”在文献7中认定的几类Agent如下：协作式Agent接口Agent移动Agent信息/因特网Agent反应式Agent智能Agent基于（图3）的服务实现架构，我们所说的Agent属于多个类别：协作式：一个或多个Agent共同实现服务功能。移动：Agent执行于网格节点上，服务上下文之外。信息：Agent的执行直接利用了位于网格节点的数据。在本文接下来的篇幅中，我们将会讨论一个网格的简单实现以及一种可用于构建基于网格的EDB和基于Agent的服务实现的编程模型。网格实现在实现网格最困难的挑战之中，
9、包括高可用性，可伸缩性以及数据/执行分割机制。保证网格高可用性和可伸缩性的一种最简单方式是在网格内部通信中使用消息传递。网格实现可同时从点对点和发布订阅消息传递中获得益处：在点对点通信中使用消息传递可支持消费者和提供者之间的解藕。请求并不是直接发送给提供者，而是发送给提供者监视的队列。作为结果，队列提供了： 通过增加监听同一队列的网格节点的数量可以透明地提升整体吞吐量。通过控制监听队列的线程数量可简单地调节网格节点的负载。简化负载均衡。不是由消费者来决定调用哪个提供者，而是将请求写入到队列中。提供者在线程能够处理请求时选取请求进行处理。透明的故障转移支持。如果监听同一队列的一些进程终止了，剩下
10、的仍然会继续选取并处理消息。发布/订阅消息传递的使用简化了在网格基础设施内实现“广播”。这一支持在同步一个网格配置时将会非常有用。取决于网格实现，数据/执行分割方式的范围可以从单纯的负载均衡策略(在相同节点的情况下)到对网格数据的动态索引。这一机制既可被硬编码到网格实现里，也可被抽取出来由专门的网格服务（分割管理器）完成。分割管理器的角色是在节点和服务器间分割网格数据，同时还作为在路由请求过程中用来定位节点(节点队列)的“注册中心”。将分割管理器外部化为单独的服务给整体架构引入了附加的灵活性，其实现方式可以是通过使用“可插拔”的分割管理器实现，甚至也可是为不同类型请求实现不同路由机制的多个分割
11、管理器。整体的网格基础设施，包括分割管理器和网格节点通信，既可以直接以API的形式暴露给网格消费者，在网格请求提交过程中使用；也可以被封装进一系列特别的网格节点（网格Master控制器）当中。在第一种情况里，一个特定的网格包将负责实现请求分发和(可选的)组合必须对应到一个网格消费者实现的响应。尽管这一选择能够从理论上提供最佳的整体性能，但它通常会在网格实现和消费者之间产生更紧密的耦合3。在第二种情况里，网格Master为网格实现了一个外观模式8，并带来了这一模式的所有优点在网格消费者看来，它完整地封装了网格功能（以及基础设施）。尽管网格Master实现增加了额外的网络跳跃（因此会有一些性能开销），但松耦合的实现通常更为重要。
