SOA架构电子政务全程优化原理.docx
《SOA架构电子政务全程优化原理.docx》由会员分享，可在线阅读，更多相关《SOA架构电子政务全程优化原理.docx（46页珍藏版）》请在冰豆网上搜索。
SOA架构电子政务全程优化原理
长风联盟电子政务
全程优化原理研究报告
长风开放标准平台软件联盟
二○○七年五月
目录
第一章引言1
1.1编写目的1
1.2背景1
1.3定义2
1.4参考资料3
第二章全程优化基本原理1
2.1需求规定1
2.2运行环境1
2.3全程优化中的服务质量（QoS）2
2.4全程优化中的服务粒度控制4
2.5基本设计概念和处理流程7
2.6全程优化平台8
2.7全程优化开发和部署策略10
2.8全程优化相关技术11
第三章SOA1
3.1SOA基础1
3.2SOA的元素3
3.3SOA中的服务粒度6
3.4SOA的作用7
3.5SOA的风险评估8
第四章业务流程建模1
4.1BPM简介1
4.2BPM相关标准2
4.3基于BPM的开发过程5
第五章价值链评价指标体系的建立7
5.1评价指标体系简介7
5.2建立评价指标体系的意义7
5.3建立评价指标体系的原则8
5.4建立评价指标体系的流程9
5.5建立评价指标体系的步骤10
5.6多指标综合评价方法15
5.7评价指标体系示例22
第六章结束语-25-
6.1结束语-25-
第一章引言
一.1编写目的
本文档描述全程优化的技术原理，预期读者为全程优化子任务承担单位及长风联盟成员单位的相关人员。
一.2背景
从SOA在国内外的发展现状来看，SOA逐步进入应用为主的阶段。
随着SOA的实践深入，越来越多的客户开始接受SOA框架提供的服务，并希望SOA能为企业或行业带来成本降低、灵活性增加的优势。
今后SOA的应用趋势将是集成化、协同化，也就是为客户提供一个系统集成平台，提供一套协同解决方案。
集成化与协同化具体体现在：
1.组合应用：
集成是组合应用的核心，推动流程流动，合并、分析或展示数据，跟踪关键绩效指标，支持跨组织或跨应用的流程。
SOA将组合应用同更多的应用功能和数据连接起来。
2.实时商务智能与分析：
数据集成的大趋势是实时商务智能与分析，以便更迅速地根据商业洞察采取商业行动。
企业信息集成平台可用于查询和整合，业务活动监控系统负责跟踪、整合和报告主要的业务事件，它们都使用底层的集成来访问、操作和移动数据。
3.内部协同：
许多组合应用涉及到多名协同工作的用户或团队，通常使用平台的协同特性能够较好地解决这个问题。
4.外部协同：
企业需要集成同客户接触的所有流程，这便构成了协同平台的外部使用。
全程优化正是顺应这些趋势，将服务的相关信息资源集成于一个平台中。
全程优化是一种新的设计思想建立企业内外部的资源管理及运营支撑系统，通过对企业内部所提供的服务及所需要的跨企业协助服务（考虑到可能的未知第三方）的灵活编排,形成价值链的IT支持系统，为实现价值链的总体业务目标服务。
全程优化是一种新的系统架构与运营平台，由平台和一系列的WEBSERVICE构成，这些WEB服务提供价值链上的IT应用功能，及企业内部与企业间间数据交换，流程的集成，协同运转，以及其他运营服务。
从另外一个角度看，全程优化系统是由一系列的WEB服务在一个具有自学习、智能化并可以提供容错和可靠性运营支持的服务编排平台上运营（软网格），对流程进行智能分析和匹配，并保证服务间的协同，和与外部接入服务系统和应用系统的协同。
全程优化的研究和实现作为企业计算中示范性的应用，必将推动SOA从理念到实践的普及，并且为软件产业指出新的发展方向，以更好地促进社会资源优化。
全程优化的理念由李安渝博士提出和倡导，由神州商桥进行研究和开发。
一.3定义
面向服务架构（Service-OrientedArchitecture,SOA）：
SOA是英文面向服务架构的缩写。
本质上说，SOA体现的是一种新的系统架构。
在基于SOA架构的系统中，具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件（也就是service）组合构建起来的。
SOA的出现，将为整个企业级软件架构设计带来巨大的影响。
全程优化（EndtoEndResourcePlanning，EERP）：
全程优化是指基于客户需求规格，立足技术环境，借助技术手段与技术工具，半自动或自动地、智能地形成最优的应用与服务提供的一体化集成方法与环境。
业务流程建模（BusinessProcessModeling，BPM）：
是对业务流程进行表述的方式，它是过程分析与重组的重要基础。
在跨组织业务流程重组的前提下，流程建模的主要目的就是提供一个有效的跨组织流程模型并辅助相关人员进行跨流程的分析与优化。
企业服务总线（EnterpriseServiceBus，ESB）：
ESB是集中化的、逻辑上的，具有架构层次的组件，提供在分布式异构环境中高度可扩展性、容错、消息服务等服务框架的一种实现。
服务质量（QualityofService，QoS）：
与SOA服务相关的服务质量。
QoS的关键元素有安全需求（如认证和授权），可靠通信（指确保消息“仅且仅仅”发送一次，从而过滤重复信息），以及服务的调用策略。
Web服务管理：
为Web服务提供了可见性和管理。
监控服务可用性，以确保服务质量、执行SLA（服务级别协议）。
还负责处理负载均衡、故障替换及Web服务可靠消息传送。
Web服务安全：
为外部用户或者应用程序访问的Web服务提供了安全环境。
包括加密、数字签名、验证、授权、机密性、数据完整性和不可否认性。
可能与联合身份管理解决方案结合在一起。
一.4参考资料
本文档的参考文件包含：
a.长风联盟SOA-AP-TFEERP子任务工作方案书；
b.长风联盟电子政务全程优化功能设计研究报告；
c.长风联盟电子政务全程优化设计研究报告；
第二章全程优化基本原理
二.1需求规定
全程优化是基于SOA，根据用户的业务目标，动态地对价值链进行构造或优化的软件平台及其相关理论。
二.2运行环境
全程优化的目的为分布式、跨平台、松耦合的系统上运行，并提供系统间集成和流程编排的方法。
图1全程优化的技术基础
全程优化建立在webservice之上，以松耦合的方式连接应用。
通过service对运行环境和系统进行解耦，达到更健壮、提高开发效率、增加灵活性的效果。
从web标准的发展趋势看，XML、XSD、HTTP构成了基本的web标准框架，SOAP提供了在互联网上对象调用的方式，WSDL可以描述webservice契约，UDDI的出现，可以在intranet或internet上发现webservice，而全程优化则在intranet或internet上发现最符合业务目标适合的service，并将其构建为价值链。
图2web标准的发展趋势
全程优化的服务和传统的web服务也有所不同。
全程优化中的服务对web服务进行了描述、考核、管理等方面的扩展，代表一个可基于标准web协议和全程优化协议访问的可考核的业务逻辑单元。
全程优化的目的是达到实时的价值链优化，这是通过对业务目标的分解和评价完成的，业务目标通常包含由多个考核目标构成的一个指标体系，可以通过综合决策方法进行求解。
二.3全程优化中的服务质量（QoS）
服务质量（QualityofService，QoS）是全程优化中的重要概念之一。
全程优化中对QoS的处理包含下列几个问题：
●QoS分类
●QoS需求
●QoS衡量和评价
●QoS控制
服务分类是QoS定义的基础，服务可以在下列基础上进行分类：
1、应用环境（电子商务、电子政务、能源、通信等产业）
2、目标
3、QoS需求（时间敏感、成本敏感……）
QoS分类的质量水平可以通过两种方式评价：
1、基于客户满意度：
优秀、良好、一般、差、很差；2、通过收集的质量数据（如可以用1~10级表示）；QoS类型可以包含：
时间、成本、技术难度、技术工作量、易用性、稳定性、可获得性；
在QoS需求的分解方面，一个服务可以由一系列服务构成，所以其服务质量也由这些服务决定；一个服务的服务质量必须分解到一系列构成它本身的子服务；QoS可以在不同的层次上定义；在高层的QoS和低层的QoS之间存在着映射关系（mappingrelationship）；
在QoS的衡量和评价方面，采集QoS信息的相关技术有：
技术架构、采集服务、QoS管理平台等；QoS评价的相关研究内容有：
QoS评价方法、QoS评价时间段、QoS评价粒度等。
在QoS控制方面的主要研究内容有：
QoS需求或评价指标；QoS状态采集方法；QoS评价方法；QoS优化控制。
QoS优化控制有基于反馈的控制和面向目标的控制。
全程优化中的QoS考核和管理主要有三个特征：
独立的QoS管理、动态考核、与UDDI的动态数据交换。
动态寻找合适服务有两种实现途径：
只在（扩展）注册库中查找、同时在注册库和质量管理中心查找。
图3全程优化中实现QoS管理的两种方式
全程优化中的质量考核指标包括：
通过率；给定参数的变化范围（如,成本、时间）；给定参数的精度；可获得性；质量考核可以是复合目标，如：
成本/时间/精度/……或者它们的任意组合。
二.4全程优化中的服务粒度控制
全程优化中的服务管理包括：
服务描述、服务构造与重构、服务考核、服务生命周期管理。
其中的关键问题就是服务粒度的控制。
服务粒度根据业务含义确定，可分为：
细粒度服务、中等粒度服务、粗粒度服务。
服务的粒度是用来描述所提供服务的粗细程度的量化，或者说是所提供服务的计算量的大小。
服务的粒度可用服务所实现的业务逻辑的长度，也就是实现服务所包含的处理指令的条数来描述，但通常难以精确的度量。
粒度是影响复用性能的重要因素。
图4服务粒度对软件平台的影响
针对服务粒度的优化目标为：
尽可能消除大粒度构件内部的不稳定元素，充分利用大粒度所带来的优越性，复用性能也会得到提高。
我们提出了服务重组在整个基于服务的开发过程中的位置，如图5所示。
图5服务重组在整个基于服务的开发过程中的位置
服务粒度可以通过下列方式衡量：
服务提供的计算量；服务实现的商务流程，或服务源程序包含的源代码行数。
但通常来说，服务粒度是一个相对的概念，精确地衡量服务的粒度是比较困难的。
一个基于Bayesian方法的服务重组过程示意图见图6。
图6基于Bayesian方法的服务重组过程
服务可以在不同的层次进行复用，复用数据的采集也可以在这些层次进行：
图7基于cache的服务复用体系
在全程优化中，需要在业务目标和服务之间建立映射关系，以保证业务目标的达成，如图8。
图8业务目标和服务之间的映射
二.5基本设计概念和处理流程
全程优化的基本处理流程如图9所示。
图9全程优化的基本处理流程
二.6全程优化平台
在全程优化的研发中将采用理论探索与研发实现相结合的研究方法。
对服务颗粒度、服务质量（QoS）考核、服务编排、流程优化等方面进行探索。
并实现全程优化平台，支持服务的发现、QoS考核和流程自动编排。
下面给出全程优化平台的框架图如图10。
图10全程优化平台框架
在全程优化平台框架下，在三个层面展开研究：
在理论探索层面，重点研究服务颗粒度对服务重用的影响、优化指标体系、QoS的采集和综合评价、服务的智能编排四个问题；在标准制定层面，结合长风开放标准软件联盟的标准工作，形成服务颗粒度、QoS评价、全程优化等相关的技术标准；在平台实现层面，运用前两个层面的研究成果，实现全程优化的原型平台。
全程优化平台的参考实现如图11所示。
图11全程优化平台参考实现
二.7全程优化开发和部署策略
全程优化的开发和部署过程如图12。
图12全程优化的开发和部署过程
下面给出一个基于敏捷方法的服务改进策略。
图13一个基于敏捷方法的服务改进策略
服务编排策略是全程优化中的重要环节。
一个自顶向下的服务编排策略如图14所示。
图14自顶向下的服务编排策略
二.8全程优化相关技术
全程优化的相关技术有：
1.SOA架构
2.BPM
3.价值链评价指标体系的建立
4.综合评价方法
在本文档中将对这些技术进行描述。
第三章SOA
三.1SOA基础
全程优化平台建立在SOA基础上。
面向服务的体系结构（service-orientedarchitecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。
接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。
这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。
松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。
而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，这种方式非常脆弱。
对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。
我们称能够灵活地适应环境变化的业务为按需（Ondemand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。
虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。
虽然基于SOA的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。
由于它考虑到了系统内的对象，所以虽然SOA是基于对象的，但是作为一个整体，它却不是面向对象的。
不同之处在于接口本身。
SOA系统原型的一个典型例子是通用对象请求代理体系结构（CommonObjectRequestBrokerArchitecture，CORBA），它已经出现很长时间了，其定义的概念与SOA相似。
目前的SOA技术依赖于可扩展标记语言（eXtensibleMarkupLanguage，XML）为基础的技术。
通过使用基于XML的语言（称为Web服务描述语言（WebServicesDefinitionLanguage，WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前CORBA中的接口描述语言（InterfaceDefinitionLanguage，IDL）可比了。
Web服务并不是实现SOA的惟一方式。
前面刚讲的CORBA是另一种方式，这样就有了面向消息的中间件（Message-OrientedMiddleware）系统，比如IBM的MQseries。
但是为了建立体系结构模型，所需要的并不只是服务描述。
还需要定义整个应用程序如何在服务之间执行其工作流。
尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。
因此，SOA应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。
例如，给供应商付款的操作是商业流程，而更新零件数据库，以包括进新供应的货物却是技术流程。
因而，工作流还可以在SOA的设计中扮演重要的角色。
此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为所控制的外部合作伙伴进行的操作。
因此，为了提高效率，需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。
所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。
因此，安全、信任和可靠的消息传递应该在任何SOA中都起着重要的作用。
SOA帮助企业信息系统迁移到“leave-and-layer”架构之上，这就意味着在不用对现有的企业系统做修改的前提下，系统可对外提供Web服务接口，因为它们已经被可以提供Web服务接口的应用层做了一层封装，SOA可以将系统和应用迅速转换为服务。
SOA不仅覆盖来自于打包应用、定制应用和遗留系统中的信息，而且还覆盖来自于如安全、内容管理、搜索等IT架构中的功能和数据。
因为基于SOA的应用能很容易地从这些基础服务架构中添加功能。
所以，基于SOA的应用能更快地应对市场变化，使企业业务部门设计开发出新的功能应用。
与传统的企业应用集成架构的主要区别在于，基于SOA的企业应用系统使用基于标准的服务，并包括过程/数据服务、编排和组合。
基于标准的服务成了应用间的集成点。
服务的编排和组合增加了服务的灵活性、重用性和集成性。
三.2SOA的元素
SOA的元素包括应用程序前端、服务、服务库和服务总线。
3.2.1应用程序前端
应用程序前端是SOA的活跃元素，负责发起和控制企业系统的所有活动。
应用程序前端有多种类型。
包含图形用户接口的应用程序前端（如web应用程序或富客户端）与最终用户直接交互。
有些应用程序前端不一定要与最终用户直接交互。
周期性调用功能（或在特定时间驱动下调用功能）的批处理程序或长期流程也属于应用程序前端范畴。
应用程序前端完全可能将业务流程的大多数指责委托给一个或多个植物，但应用程序前端负责发起业务流程并接收结果。
应用程序前端类似于传统的多层应用程序的较高层。
但不要误认为服务更类似于较低层。
服务有一个不同的结构，有垂直分层的特点。
3.2.2服务
服务是一个软件组建，具有明确的功能，通常封装着高级业务概念。
服务由下面几个部分组成。
合约：
服务合约提供一个信息规范，说明服务的作用、功能、约束和使用。
规范的格式因服务类型而异。
服务合约的一个可选元素是基于IDL或WSDL等语言的正式接口定义。
正式服务接口定义虽然不是强制的，但拥有明显的优势：
提供更高的技术（如编程语言、中间剪、网络协议和运行时环境等）的抽象性和独立性。
服务合约还提供正式规范以外的内容，提供不属于IDL或WSDL规范的功能和参数的详细语义。
在现实中，很多项目都必须处理不能提供正式服务接口描述的服务。
在此类情况下，服务可能提供访问库或网络协议级别的详细技术描述。
每个服务都需要服务合约，如果没有可用的基于WSDL或IDL等标准的正式描述，情况尤其如此。
接口：
服务接口将服务的功能向服务客户（客户通过网络连接到这个服务）公开。
接口描述是服务合约的一部分，但接口的物理实现包含服务占位程序，占位程序被嵌入到服务或调度程序的客户中。
实现：
服务实现在物理上提供所需的业务逻辑和适当数据。
在技术上实现服务合约。
服务实现由一个或多个工件组成：
如程序、配置数据和数据库。
业务逻辑：
业务逻辑由服务封装，是服务实现的一部分。
可通过服务接口访问业务逻辑。
无论是否运用面向服务的方法，都要对照接口编写程序。
数据：
服务还包含数据，而且服务以数据为中心。
如前所述，服务不仅是封装了应用程序较低层的一些代码，由于各个服务都是一个明确的功能实体，服务是应用程序的垂直切片，定义整个系统的粗粒度结构，这类似于面向组件的软件设计。
因此，从客户角度分析，服务是一个黑盒实体。
3.2.3服务库
通过服务库，可以发现服务，获得使用服务的所有信息。
如果必须在创建服务的功能和时间范围以外发现服务，则服务库显得更重要。
虽然服务合约提供了大多数必要的信息，但是服务库补充了一些信息，例如物理位置、提供者信息、合约人、使用费用、技术限制、安全问题和可用服务级别。
我们主要讨论单个企业范围内使用的服务库。
用于跨企业服务集成的库一般会有不同的要求（这些库通过internet对外公开）。
这些要求可以包含法律问题（使用条款和限制）、表示形式、安全、用户注册、服务订阅、收费和版本控制。
服务库是SOA中的一个非常有用的元素。
在构建SOA时，如果不建立服务库，似乎能获得一些短线利益。
但长远来看，服务库是必不可少的。
如果服务的范围仅限于一个项目，服务数量很少或由一个团队处理所有项目，则架构可以不使用服务库。
但实际情况是，大多数企业都并发地开展多个项目，开发团队时常变化，而且服务类型多种多样，这些环境都离不开服务库。
服务库可能非常简单，一些服务合约就可以构成一个服务库。
但可以有更好的方法来提供信息，并保持服务库的简单性。
我们经常可以遇到一类专用的数据库，它包含一些正式管理数据，以及各服务版本的接近正式的服务合约。
有些企业可以开发自定义工具以从正式的服务定义自动生成服务描述（例如将WSDL作为输入的HTML生成器，以及JavaDoc生成器）。
如果正式的服务定义包含关于服务附加信息的注释，则这种方法特别有用。
注意，该信息通常与低级API（如Java类）提供的元信息有很大的区别。
在SOA中，服务定义担当另一种角色。
服务一般粒度更大、更独立，并能支持不同使用模式。
一般不作为代码库而连接，而在运行时绑定。
综上所述，服务有不同的文档记录要求。
下面列举企业级服务库应当包含的示例信息。
1.服务、操作和参数签名，采用WSDL和XML模式定义等形式。
2.服务所有者。
在企业SOA中，服务所有者可以在业务级别（负责功能级别的问题和更改请求）、开发级别（负责技术问题和更改请求）和操作级别（负责关于链接服务的最佳方式的问题或操作问题）工作。
3.访问权限。
例如关于访问控制列表和底层安全机制的信息，以及为企业中新系统使用特殊服务的过程描述。
4.关于服务预期性能和扩展性的信息，包括平均响应时间以及可能的吞吐量限制，这些信息可以作为普通SLA（ServiceLevelAgreement，服务级别协议）模板的一部分。
5.服务的事务属性及服务的各个操作。
这包括读、写、更新特性，操作是否等幂以及相关的补充逻辑信息。
有必要区分服务的“开发时绑定”和“运行时绑定”。
“绑定”指如何找到服务定义和服务实例，将其集成到客户应用程序，并最终在网络级别绑定。
1.开发时绑定
如果在开发时发现和绑定服务，则能预先了解服务操作的签名，以及服务的服务协议和物理位置（至少是服务在目录中的精确名称）。
开发时绑定是一个非常简单的模型，但可以满足绝大多数环境下的要求。
当前项目可以识别先前项目已经创建的功能，并重用这些服务。
2.运行时绑定
运行时绑定比开发时绑定复杂得多，运行时绑定包含多个级别：
按名称查找运行时服务：
这是最直接的动态绑定服务的方式，但也是最常用的方式：
在开发时已经知道服务定义，并相应开发客户逻辑。
客户段在目录中查找特定名称的服务，动态地绑定到不同的服务实例。
按属性查找运行时服务：
这与上面的方式相似，不同的地方仅在于按属性，而不是按名称发现服务。
基于反射发现运行时服务：
开发时并不了解服务定义的实际规范。
例如，客户端可能查找一个属性正确的服务，但不了解服务接口。
此时必须在客户段实现一些反射机制，以便客户端动态地发现服务的语义和有效请求的格式。
此类服务异常复杂，极少使用；因为只有非常复杂的逻辑，才能动态解释未知服务接口的语义。
应该尽量简化服务绑定。
因为随着服务绑定过程动态级别的提高，复杂性和风险级别呈指数级上升。
在绝大多数情况下，利用预定义服务，按名称查找服务是灵活性和实现复杂性之间最完美的平衡。
3.2.4服务总线
服务总线将SOA的所有参与者（服务和应用程序前端）相互连接在一起。
如果两个参与者需要通信（例如，应用程序前端调用基本服务的一些功能），就必须依靠服务总线。
服务总线类似于CORBA上下文中定义的软件总线概念。
不过，这些概念之间存在巨大的差别。
服务总线并不
升级会员 