英国电信设计模式最佳实践

英国电信设计模式最佳实践
——层次化的SOA架构

作者：崔晓波 BEA系统（中国）有限公司资深技术顾问

典型的企业SOA平台连接许多企业应用资源和用户，并且可以把企业应用资源分成服务提供者和服务消费者两种类型。可以通过把服务划分为不同的层次来得到良好的管理效果。一个服务层次用来使后台系统（BES）资源可用，而另一个服务层次连接前端系统（FES）到SOA平台，第三个服务层次组装第一个服务层次的基本服务并连接业务用户在一起成为复杂的复合类型服务。
类似的服务分组做法可以有效的阐述SOA平台分层管理的特点。对于每个层次来讲，都有对应的不同的技术，开发模式，测试装置，部署配置和系统管理制度等等。

一、层次划分
分层架构是最灵活的实现方法。简单来说，SOA可以仅仅由基本的存取服务来组成。这些存取服务直接封装由BES提供的一组接口。
然而，这组服务并不能满足最基本的整合项目的整合需求。在大多数实际项目中，整合不同后端系统的逻辑是需要的。这个整合逻辑也可以被看作一组服务，此服务有良好定义的对外发布接口。这些服务是更高水平的服务，它利用更低水平的BES存取服务。这些服务实现是通过编排或协调的方式。
最后，在一个企业整合环境中，这些更高水平协调服务或更低水平存取服务的大多数消费应用将不直接支持对外的服务接口。因此，另一组服务被要求包装服务到每个FES可以方便使用的形式。
于是提出了分层架构的基础，如图所示：
这个架构中有三层。每层都有相应的一组技术需求和作用。
q 存取服务层负责发布一组BES的接口作为一个标准的服务。
q 组装服务层重新分组服务来实现整合逻辑。
q 消费服务负责使FES可以访问其它两层发布的服务，这些服务通常是FES不能直接进行调用的。

一个独立的企业信息系统（EIS）能够执行FES或BES角色中的一个或两个，它可以通过存取层暴露服务，也通过消费层调用服务。
另外非常重要的一点是任何层的服务能够被FES调用，你不必通过架构中的所有层来进行。

（1） 存取服务层
存取服务层提供由SOA平台其余层次服务调用的基础服务。该层关键架构的中心是设计和管理服务的重用。设计和开发存取服务需要应用访问异构资源的技术（如WTC、JCOM、Web Service等），适配器开发设置技术、消息中间件技术。
存取服务层是通过访问BEA发布的服务来提供单一的接口，主要目标是在平台上实现最大化的重用。其它层通过控件或通过一个发布接口来访问这些服务。它最简化的形式仅仅是一个通过控件来暴露的BES。例如一个J2EE连接架构适配器（J2EECA）数据库适配器被安装和设置来把一个特殊的系统和每个需要的SQL语句所产生的服务连接到一起。然后这能够通过整合应用视图控件来存储。
什么服务属于这一层?
这一层主要考虑所有发布的接口是基于BES设计的，并非是每个FES或同层的需要。实现对BES多个调用的复合服务将是这层的一部分。
例如，为了产生一个给定BES的用户，有必要产生用户ID，然后是用户名，再然后是用户地址等。每个部分都作为一个不同的调用，然后一个“产生用户”复合服务将被实现绑定所有这些调用。这种复合的原因是更方便的、更大程度的重用BES提供的服务。
总体来说，一个适合存取的流程将满足以下几点：
q 仅仅连接一个BES
q 接口的所有者和服务的实现和BES在一起

（2） 组装服务层
组装服务层主要是完成传递新的服务的功能，这些新的服务是对存取服务层提供服务的一个重新组织。本层的主要架构特点是灵活性。组装服务层通过正确实现数据集中、流程定义、以及创建理想服务的工作流工具实现了这种灵活性。设计和实施组装服务需要精通集成业务流程和规则，并在数据集成、流程建模、工作流开发上有丰富开发技巧的专家。
在这层中需要实现各种的集成逻辑，并发布成为一个完整的服务。本层利用访问存取层向FES提供有意义的服务。
本层中需要包含哪些服务？
任何利用多于一个EIS系统的服务都需要纳入到这一层中来。对于通过worklist实现人为交互的服务也需要纳入到本层中来。正如上文中对于访问存取层的描述，一些协作层中的服务可能仅访问一个BES系统。如果这些服务需要完成功能包含集成的需求而不仅仅是来自单个BES系统，他们也同样应台包含在协作服务层中。适用于本层的一个简单原则：任何不属于消费层或访问存取层的服务都属于协作服务层。
独立的数据集成服务，如提供数据转换、数据映射（包括主键映射）、数据依赖路由的服务需要驻留在协作层。这些服务可能不会通过访问存取层访问BES系统。

（3）消费服务层
消费服务层的主要目的是负责平台和应用服务请求者（例如FES系统）之间的连接，本层服务提供：
q 协议映射——映射为服务发布接口协议：JMS和Web Services。
q Paradigm映射——同步到异步以及vice-versa。
q 数据映射——数据格式映射，聚集等。
服务请求者包括基于多种架构的应用，还有包括胖客户端、消息系统、套接字协议等在内的遗留系统服务请求者。一般都需要协议解释服务。对于支持诸如Portal，B2B服务，多渠道等平台协议，paradigm和数据格式的请求者，可以与平台直接接口。将服务请求者集成到SOA平台需要对特定服务请求者的技术有丰富的知识，此外还需要数据转换的技巧。
消费服务层应当包含哪些服务？
消费服务层重组了特定存取服务层和协调服务层的各项服务。重新组装的目的是为了让服务能够以更方便的形式被FES调用，典型的如把一个JPD流程包装成一个Web Service就是如此。另外把一个JPD对应的前端的Page Flow包装成一个Portlet，也可以更方便的让前端的Portlet系统进行组装和调用。
例如一个消费层服务收到某个FES发出的事件，但是这个事件不具备足够的信息来调用相应的协作层，请求服务层的服务将完成接收事件，并向FES查询相关信息的功能。这是一个明显的功能加强，这类场景适合于消费服务层。当然，如果这个强化的过程需要向一个独立的系统进行查询，则意味着通过一个集成过程后成为请求服务层的一个独立服务。

二、端到端的视角
值得指出的一点是在审视从FES到BES系统之间的端到端通信时，这些层次都不是强制必须实现的。正如前文所讲述的，请求服务层仅当需要提供对SOA平台的标准接口技术进行访问时才是必要的。若一个FES本身支持SOA平台的标准，那么FES就可以直接访问其提供的服务，而跳过请求服务层。同样的，对于一些简单的集成需求，如查询独立系统中的可用数据就不需要进行服务的重组。当然，我们推荐的方式是永远不要忽略访问存取层，它保证了BES提供的各种服务在整个平台中保持一致性和灵活性。它还避免了跳过所有层次的设计场景的出现，因此可以保证满足平台管理原则。
还有一点值得一提，在一个集成场景中，很多系统既是BES又是FES，当然也不排除一些纯前端系统（如Portal）和固有后端系统（如数据库）的存在。当进行双向松耦合通信（如使用JMS）时，一个双向的集成需求可以转为实施两个单向的通信。这是一个在相同业务流程中既作FES又做BES系统的例子。

三、服务资源库
需要建立一个服务资源库来记录有关服务的信息，籍此可以实现不同项目之间服务的易重用性。这个资源库不需要是一个自动的运行时系统（类似UDDI），而多用于设计和开发阶段的系统参考。这个资源库可以简单到一个共享文件夹的形式，或者依靠文档管理工具来完成。资源库中服务的定义最少需要包含以下服务相关信息：
q 服务名称和版本。
q 服务功能和意图的概要。
q 功能和非功能性需求。
q 服务驻留的层次以及层次之间的粒度。
q 服务详细的接口描述。包括发布的和/或私有的接口，以及对接口诸如URL，方法，参数类型以及所需的值和使用方式的详细描述。
q 服务所有者。是指负责维护服务的独立个体或组织（更常见的一种情形）。