基于面向服务架构的系统改造与实现探讨

摘要：本文阐述了面向服务架构的实质及Web Service技术与面向服务架构的契合性，然后结合一个现有系统的业务，分析其现有架构的弊端，利用面向服务架构设计理念对系统业务进行整合分析，提出一个基于面向服务架构改造方案。方案基于．NET平台和其Web Service技术。文中还就利用现有技术的实现环节及其细节进行描述与分析。最后阐述了面向服务架构的优越性及其一些不足之处，并得出面向服务架构是无关具体技术，以业务为主导的开发理念。

关键词：面向服务架构；SOA；Web Service；企业服务总线

中图分类号： TP311 文献标识码：A文章编号：1009-3044(2008)11-20353-03

面向服务架构(SOA)的提出给软件设计带来了新的理念，这个新事物的优越性大家都已有共识，但在实现上，却存在不同的理解和争议。本文根据一个现有系统为基础，阐述基于面向服务的系统改造与实现模式，希望能从实践的角度出发，更加实际的认识SOA。

1 面向服务架构概念

1.1 SOA的实质

这里引用一下IBM关于SOA的定义：“面向服务的架构是一种架构模型，它将应用程序的不同功能单元（称为服务）通过这些服务间定义好的接口和契约联系起来。接口是通过中立方式定义的，它独立于实现服务的硬件平台、操作系统、编程语言。这使得构建在不同的系统中的服务可以以一种统一的通用的方式进行交互。”

从这个定义中可以看出，其专著点着眼于“服务”这个概念。从面向对象到组件开发，服务概念也不是横空出世的，它与组件的联系是不可分割的，只是服务关注点有更加的深入业务领域。将业务逻辑抽象出来作为可被重用的功能单元，即建立一个业务组件，并规定该业务组件的契约，即其业务功能和业务数据，任何满足该契约的消息，都可以使用该组件。该业务组件的契约用一些符合标准协议的接口形式暴露出来，其内部实现被隐藏封装，并可实现灵活的替换，这其实就是服务的概念。服务即是以包装业务功能组件形式出现的灵活通用的业务组件，也可以称之为服务组件。面向服务架构其实就是以这些统一通讯的服务组件为基础构建的一个高度分布式的架构。

服务契约的定义与实现的分离，使业务真正驱动技术的实现，提高了开发的效率，同时由于统一的通讯协议，也为业务重用、流程组合和异构系统交互提供了很大的便利。

1.2 SOA 与 Web Service

谈到SOA就不得不提Web Service技术，SOA的实现需要一种统一的通用的方式进行交互，这种统一的交互方式可以是任意的协议，其实现不受SOA定义的限制，但在当前，无论从统一交互可行性或者是技术的普及型来讲，Web Service技术都是当前实现SOA最佳技术。所以Web Service由于其本身的特性，成为当下实现跨平台，服务接口与实现分离的首选技术。它在这方面的特性主要有：(1)传输SOAP消息；(2)自描述、自发现特性。

在传统的分布式应用中，Web Service总是充当远程调用方法的角色，典型的架构分为客户端、服务层、Web Service层、数据层，Web Service作为客户请求的终端，是架构的主要业务实现层。而在SOA设计理念中，Web Service的责任被减弱，根据本身特性，它只负责处理信息交互及服务描述，而真正的业务处理逻辑由具体平台的业务组件承担。这样不仅增加了灵活性，降低了平台依赖性，而且具有复杂类型的消息，也更利于系统间基于业务的交互与集成。

2 业务简介

北京医疗保险财务支付系统（下文简称系统）是北京市医疗保险信息系统的一个子系统，介于收缴系统与审核结算系统之间，它的核心业务之一是针对北京市各种参保人群提供保险的收取、费用支付、记账、统计等业务。由于北京医保政策的变动及参保人群不断的增多，使得系统本身变得臃肿复杂和难以维护。

3 系统现有架构分析

3.1 架构描述

系统采用传统的基于Web Service的多层分布式C/S架构实现，如图1所示。在这个架构中，Web Service层负责业务逻辑的实现，针对特定人群提供相应的业务流程操作实现。主要是一些标记[Web Method]属性的方法，通过与数据库层交互返回数据或执行结果;服务层，即Web Service，负责与远程Web Service的通讯。客户端通过层与远程的Web方法实现通讯。这是个典型的．NET平台基于Web Service的分布式应用。

3.2 优缺点分析

这样的架构在使用Web Service作为数据传输的中介，因此充分利用了Web Service的跨平台、松耦合的特性。同时对新增的参保人群，创建不同的Web Service集中处理该人群的业务，使开发效率也大大的提高。因此在系统开发前期能发挥积极的作用。但是随着新人群不断的增加，系统的负担越来越大，同时业务的变更，也往往涉及每个服务实现的变化以及系统各层的改动。

4 SOA架构改造实现方案

由于业务的积累使得原有系统的优势变成了劣势，因此适应业务的变化，增加系统的灵活性成为系统重构的目标。下文根据SOA的理念给出一个设计方案。

4.1 业务分析

SOA是离不开业务的，因为它本身就是为适应业务变更的需要而出现的。但其业务分析的关注点更多的是偏向于以功能单元出现的流程形式，以便能更好的实现业务灵活性与重用。例如在系统中由于参保人群的划分，相对应的业务就会出现无保障老年人业务、在职退休业务、普通单位业务等业务类型的差异，不同的业务有着不同的操作流程。但这些并不是SOA所关注的。SOA对业务的关注更多的是完整的流程及其各个环节。

依据此理念分析各个业务形式的流程的相似性，对各个业务流程横切出不同的业务单元得到如图2示，每个单元都是一个独立的功能模块。而业务类型可以作为业务数据或业务规则作为消息传入，这样使得每个功能模块都能做到最大的复用。同时通过组合不同的功能模块，可以得到不同业务类型的业务流程，这样便更快地适应了流程的变化。

如果某个业务形式新增加了新的功能环节，那么也很容易就可以添加实现这个环节的服务。相比于基于参保人群的业务划分，除灵活性外，也使系统重用性大大提高。

4.2 定义服务模块契约

服务契约的定义是建立在之前对业务和现有业务资产充分了解和分析的基础上的对业务模块需求的描述。是关于对外服务模块的功能和其处理消息的架构的约定。消息的架构主要是指与业务模块交互的业务数据类型定义。消息不同于一般的参数列表，因为直接关系业务，因此消息往往是复杂数据类型，可以使用XSD架构定义，在．NET中使用XML序列化的类来定义契约消息。在改造过程中，这些契约消息的架构往往是实现同类业务原Web Service方法参数的集合。如下为在业务分析后，在．NET环境下对一个服务模块契约的定义示例。

namespace Contract{

//行为接口定义;

public interface IBiz{

BizObj1 MyBiz(BizObj2 _bizobj);

}

[XmlType (Namespace ="…")]

public class BizObj1{//消息定义类，代码略}

[XmlType (Namespace ="…")]

public class BizObj2{//消息定义类，代码略}

}

4.3 服务组件实现与使用

契约的定义，分离了业务逻辑接口与业务逻辑的实现，建立了对外交互的接口规范，接口的实现由平台代码完成。业务逻辑接口的对外还是使用Web Service，因为它的特性使然。而在具体的开发中，契约以Web Service的形式后，具体的实现就可以与其他的服务、流程或客户端同时开发了，因为具体的业务逻辑实现并不会影响到服务对外接口的变化。

此时在Web Service内部实现业务逻辑，由于不再受平台的限制，完全可以整合原系统已经开发的业务组件。推荐的实现方式是使用单独的组件层负责实际的业务逻辑实现，使Web Service只负责契约接口和消息传递。图3在．NET环境下，使用Web Service封装业务组件构造服务组件的UML图。在图中Web Service与业务实现组件BizImp同时实现契约接口，使得契约得以通过Web Service对外，同时具体的业务逻辑实现又组件层的业务组件完成。

此时的服务组件如图4示，对外以定义好的契约形式出现，内部为系统业务功能实现组件。客户端使用WSDL命令获取服务描述信息，通过传递符合契约定义的xml形式的消息，来使用系统内部组件功能，Web Service在此屏蔽了平台的差异。

4.4 服务的高级应用

此时，作为SOA架构的业务基础已经构建完成，并且也做到了最大的复用性，此时客户端通过传递相应的消息给不同的服务即可使用各种业务功能，完成具体的业务流程。服务组件作为企业业务资产的储备，如何重用服务产生新的业务价值才是SOA架构的最大价值所在。企业服务总线作为SOA的基础设施，业务人员可以直接使用总线构造自己的服务和消息格式，然后再将服务端口与具体的服务地址绑定以实现逻辑，这提供了灵活的服务使用方式，同时企业服务总线也为服务提供流程组合和流程自动化提供了很好的支持，其原理图如图5所示。在此使用微软的BizTalk作为总线服务器，通过其流程编排工具实现不同的业务流程。图6是使用BizTalk的流程编排器组合的一个收款制证业务流程。

这个自动化的新业务流程，组合了两种收款方式及制证过程，它以应用程序的方式在BizTalk服务器上，通过配置相应的端口至实际的服务实现，即可使用。该应用程序可以接受来自SOAP协议、文件、POP3协议等形式的消息数据。以方便与各种异构系统的数据交互。

图中的消息窗体连接不同的服务端口，每个服务端口规定了这个服务端口的所要求的服务契约，服务端口通过与具体服务地址绑定完成契约消息传递的完整通道，最后通过消息的流转完成业务流程，其中可以根据需要更换服务端口具体绑定的服务地址。在消息传递过程中，还可以通过其映射工具为对消息进行加工以匹配相应的消息定义类型。

利用服务总线，在现有及其他业务系统的基础上，重用原有的服务组件，针对不同的参保人群组合出不同的业务流程，至此，新改造的SOA架构实现如图7所示。

在这样的架构中，服务总线负责组合已有的服务组件产生新业务流程，这些已有的服务组件可以是任何系统业务组件的封装，因此这也为整个企业的流程规划提供了极大的便利性。

4.5 优缺点分析

改造后的系统使业务模块得到充分的复用，服务契约定义与实现的分离，大大提供了开发的效率和系统扩展能力，同时基于服务组件灵活组合业务流程也可以快速的适应业务的变化，需要注意的是，传输的业务消息体积变大，且消息可能跨越多个系统，因此在业务分析时应把握好服务组件的粒度，以减少网络传输提高性能。

5 总结

从改造方案中可以看出，SOA并没有引入新的技术，而是提出了一种以业务为主导的架构理念，将系统复用的层次由功能框架复用提升到业务组件的复用。无论是从系统开发的角度还是从业务人员与开发人员沟通的角度，他都大大的提高了效率。同时基于标准的传输协议和XML消息的交互，也为适应未来的变化和集成复用做好了准备。

参考文献：

[1] David S. Linthicum．12 Steps to Implementing a Service Oriented Architecture [EB/OL]．http：// www.grandcentralcom,2005．

[2] Service Oriented Architecture (SOA) in the Real World[EB/OL]．http：//www．Microsoft．com，2006．

[3] 孙华林，赵正文．基于Web Services的面向服务架构(SOA)的探索与研究[J]．信息技术，2007，(01)：23．

[4] Eric Newcomer．Understanding SOA with Web Services[M]．北京：电子工业出版社，2006．

注：本文中所涉及到的图表、注解、公式等内容请以PDF格式阅读原文