1引言

1．1 SOA的产生背景

随着计算机软件技术的不断发展，各企业都倾向于应用特定的信息系统(如：MIS，LES，SMS)来管理企业的内外事务。这砦系统为企业节约了专项人工开支，提高了商业运作反应速度。但从企业内部信息沟通的角度上来看，由于各种软件的开发应用平台和设计结构可能不尽相同，从而不可避免地会产生“信息孤岛”，即企业内部各特定系统之间的信息数据如不实行人工干预模式就难以互通。这种情形对整合企业内部事务结构，梳理企业内外运作关系是极其不利的，也正是这种“孤岛”效应的产生成为了企业自身发展的瓶颈之一。

面向服务的架构(Service—Oriented Architecture，SOA)技术能够给企业提供一种构建信息系统的标准和方法。通过建立可组合、重用的服务体系以减少企业的信息业务冗余，加快项目开发进程，从而提高企业信息系统利用率并有效降低系统开发成本。近年来，Web服务的出现使得异构系统的交互成为可能，特别是随着Web服务标准和规范的出台(如：简单对象访问协议、Web服务描述语言、统一描述一发现一集成协议等等)使之越来越趋于现实化。在此基础上，SOA的推广和普及工作高速运转，各大厂商如国外的IBM、SUN、SAP，国内的中软、普元、用友都纷纷协作努力进行SOA的标准化定制。人们已经把关注点从简单的Web服务拓展到面向服务体系架构的各个方面。各种支持SOA的开发平台、工具、中间件纷纷出台，为SOA的普及化提供了有利的外部环境。这些举措标志着SOA进入到了实施阶段。

1．2 SOA的技术特点

SOA作为一种分布式组件体系结构。其核心特点是跨平台和松耦合：不管在企业内部还是企业外部，SOA组件都是透明的，并且可以通过一系列统一支持的、可互操作远程过程调用和消息传递协议来统一访问。接口定义标准支持开发人员工具之间的互操作性。网络上协议互操作性相对于代码可移植性是SOA组件的中心部分．支持统一访问和平台独立。调用方无需知道组件的基础实现技术，如J2EE、Micmsofi．Net和PHP。SOA组件封装功能，并支持通过业务分析人员和业务模型建模的抽象级别的重用。这使IT功能和它所支持的业务功能之间的映射更加直接，从而提高了可靠性。计算机可处理的约定允许第三方访问SOA组件提供的服务。这些约定显式声明功能性特征以及非功能性(服务质量或QoS)特征和需求，SOA组件使用WSDL记录它们的操作，还可以使用用Web服务的业务流程执行语言(BPEIAWS)来定义组件的有效操作序列，从而动态发现、选择、绑定(通过其声明性属性)和集成SOA组件。松耦合特性简单来说即是被整合的各种系统除附加增值属性外还应保持自身原有的特有属性功能。

总的说来，SOA强调的是一种体系架构模型，它可以根据企业的业务需求通过网络对松耦合的不同业务服务进行灵活的分布式部署、整合和使用，这些业务服务独立于编程语言、实现方式和运行平台。

2构建适用于中小企业的SOA“核心业务”颗粒度模型

在企业中应用SOA就意味着将业务流程或功能用服务来描述，所谓服务颗粒度(Service Granularitv)就是指一个服务包含的功能大小。服务颗粒度的正确定位将直接影响到服务的质量，包括灵活性和效率等诸多方面。因此。选择合适的颗粒度划分对服务设计是至关重要的。目前，国内许多中小企业虽看好SOA的发展趋势，却难以接受其高昂的系统成本。这是因为应用SOA技术做标准化信息系统整合时，所惯用的企业服务颗粒度划分标准为粗粒度划分模式12l。我们崩粒度来表示一个服务的大小，或者说是服务操作的范围，粗粒度的服务，涉及的内容广而且杂；细粒度的服务，涉及的内容细而且简单。粗粒度的服务设计，可以减小服务之间的耦合性，但付出的代价就是增加服务的复杂性。服务具备了太多的功能．增加了设计的复杂性和维护的难度；细粒度的服务，可以让服务的实现变得简单，但这样会增加服务的数量，服务过细过多，这样必然有一些服务需要组合才能实现一定的功能，那样就增加了服务之间的耦合度，只要其中一个服务发生了改变，势必影响整个系统架构。从以上两种颗粒度的对比我们不难看出，服务粗粒度的划分虽符合SOA技术要求达到了松耦合的目的，但增加了服务复杂度，提高了系统开销。因此，在对中小企业SOA系统服务颗粒度划分时必须考虑设计成本与SOA标准化之间的平衡。

在SOA颗粒度模型构建上，本文提出一种构建“核心业务”颗粒度流程模型的方法来寻找一种折中的途径。这里对“核心业务”的定义是企业内外运营中最为重要、使片j频率最高的业务(服务)项目或流程。我们的SOA设计遵循这样的设计思路：先从企业信息系统的各功能模块中分离出核心业务，各个功能模块可以看作核心业务的阶段性表达；然后在核心业务的基础上设计组件和业务对象；设计完组件和业务对象之后再来设计系统服务整合。这样不管所需整合的服务范围多广，服务多复杂。都可以通过核心业务和企业工作流程把各种形式的服务整合起来。就算是这种整合服务经常需要变动，但是这种变动相对于核心业务层次来说是较为稳定的。因而能够有效地加强系统的复用性并且降低系统构件成本。

这样的设计思路也体现了SOA自顶向下的设计方法：功能模块一>服务一>组件和业务对象。服务不是凭空想象出来的，它必须要满足客户的需求，而客户需求的体现就是系统要提供的功能，所以功能模块的设计是服务设计的前提。

3中小企业SOA系统的可靠性度量

衡量可靠性的两个粗略的指标是平均故障间隔时间(MTTF)和平均恢复时间(MTTR)。这两项指标对于服务用户是非常重要的，因为这些指标在确定服务合同方面将发挥重要作用。然而，对于服务部署者来说，还有一些需要优先了解的指标，这些指标经常会受到这些服务可能使用的机器的影响。因此，监视和度量机器和分布式系统中的网络连接的MTTF和MTTR也是必要的。另一方面，SOA中的一项莺要指标是系统的服务灵活性，而服务灵活性优劣是与开发和部署此项服务的时间成反比的。因此这种灵活性将随着开发时间的增加而变得难以度量，从而直接对SOA系统可靠性衡量带来了额外的负担。换句话说，SOA系统的可靠性度量复杂程度与系统中涉及服务的质量有关，越精细的服务质量所需求的可靠性程度越高，度量丁作量越大，反之度量工作量较小。目前在SOA可靠性研究领域依然沿用着软件可靠性分析的那一套方法，仅仅从全局的角度来考究系统的可靠性，而SOA系统的核心内容是面向服务的架构，特别是中小企业的SOA系统。其个性化程度相当高，并不满足于全局考量，企业用户总希望能够获得更优服务质量同时对单个构架的可靠性有较好的把握。

SOA可靠性的衡量需要考虑许多指标，并非每一个治理实施都将帮助衡量这些因素。SOA系统架构需要从初始研发的时候就贯穿可靠性分析。单个服务的可靠性分析也许不容易立即实现，特别是在架构部署的起步阶段规模很小并且正在增长的时候。但是，如果你要保证你所架构的服务项目在未来不过时，这些步骤是必要的。

4结语

SOA作为一种新生的软件架构其自身还有许多不尽完善的地方，如：中小企业SOA系统的技术标准、语义网服务、资产服务、自适应SOA模型、虚拟服务平台，灵活的行业采用等等。这些技术点的研究都将加速SOA的平民化进程，使得SOA服务得到充分的拓展。