SOA架构电子政务全程优化原理.doc

长 风 开 放 标 准 平 台 软 件 联 盟 Chang Feng Open Standards Platform Software Alliance 长风联盟电子政务全程优化原理研究报告长风开放标准平台软件联盟二七年五月目 录第一章 引言11.1 编写目的11.2 背景11.3 定义21.4 参考资料3第二章 全程优化基本原理12.1 需求规定12.2 运行环境12.3 全程优化中的服务质量（QoS）22.4 全程优化中的服务粒度控制42.5 基本设计概念和处理流程72.6 全程优化平台82.7 全程优化开发和部署策略102.8 全程优化相关技术11第三章 SOA13.1 SOA基础13.2 SOA的元素33.3 SOA中的服务粒度63.4 SOA的作用73.5 SOA的风险评估8第四章 业务流程建模14.1 BPM简介14.2 BPM相关标准24.3 基于BPM的开发过程5第五章 价值链评价指标体系的建立75.1 评价指标体系简介75.2 建立评价指标体系的意义75.3 建立评价指标体系的原则85.4 建立评价指标体系的流程95.5 建立评价指标体系的步骤105.6 多指标综合评价方法155.7 评价指标体系示例22第六章 结束语- 25 -6.1 结束语- 25 - 长风联盟SOA-AP-TF第一章 引言1.1 编写目的本文档描述全程优化的技术原理，预期读者为全程优化子任务承担单位及长风联盟成员单位的相关人员。1.2 背景从SOA在国内外的发展现状来看，SOA逐步进入应用为主的阶段。随着SOA的实践深入，越来越多的客户开始接受SOA框架提供的服务，并希望SOA能为企业或行业带来成本降低、灵活性增加的优势。今后SOA的应用趋势将是集成化、协同化，也就是为客户提供一个系统集成平台，提供一套协同解决方案。集成化与协同化具体体现在：1. 组合应用：集成是组合应用的核心，推动流程流动，合并、分析或展示数据，跟踪关键绩效指标，支持跨组织或跨应用的流程。SOA将组合应用同更多的应用功能和数据连接起来。2. 实时商务智能与分析：数据集成的大趋势是实时商务智能与分析，以便更迅速地根据商业洞察采取商业行动。企业信息集成平台可用于查询和整合，业务活动监控系统负责跟踪、整合和报告主要的业务事件，它们都使用底层的集成来访问、操作和移动数据。3. 内部协同：许多组合应用涉及到多名协同工作的用户或团队，通常使用平台的协同特性能够较好地解决这个问题。4. 外部协同：企业需要集成同客户接触的所有流程，这便构成了协同平台的外部使用。全程优化正是顺应这些趋势，将服务的相关信息资源集成于一个平台中。全程优化是一种新的设计思想建立企业内外部的资源管理及运营支撑系统，通过对企业内部所提供的服务及所需要的跨企业协助服务(考虑到可能的未知第三方)的灵活编排, 形成价值链的IT支持系统，为实现价值链的总体业务目标服务。全程优化是一种新的系统架构与运营平台，由平台和一系列的WEB SERVICE构成，这些WEB服务提供价值链上的IT应用功能，及企业内部与企业间间数据交换，流程的集成，协同运转，以及其他运营服务。从另外一个角度看，全程优化系统是由一系列的WEB服务在一个具有自学习、 智能化并可以提供容错和可靠性运营支持的服务编排平台上运营（软网格），对流程进行智能分析和匹配，并保证服务间的协同，和与外部接入服务系统和应用系统的协同。全程优化的研究和实现作为企业计算中示范性的应用，必将推动SOA从理念到实践的普及，并且为软件产业指出新的发展方向，以更好地促进社会资源优化。全程优化的理念由李安渝博士提出和倡导，由神州商桥进行研究和开发。1.3 定义面向服务架构(Service-Oriented Architecture, SOA)：SOA是英文面向服务架构的缩写。本质上说，SOA体现的是一种新的系统架构。在基于SOA架构的系统中，具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件(也就是service)组合构建起来的。SOA的出现，将为整个企业级软件架构设计带来巨大的影响。全程优化（End to End Resource Planning，EERP）：全程优化是指基于客户需求规格，立足技术环境，借助技术手段与技术工具，半自动或自动地、智能地形成最优的应用与服务提供的一体化集成方法与环境。业务流程建模（Business Process Modeling，BPM）：是对业务流程进行表述的方式，它是过程分析与重组的重要基础。在跨组织业务流程重组的前提下，流程建模的主要目的就是提供一个有效的跨组织流程模型并辅助相关人员进行跨流程的分析与优化。企业服务总线(Enterprise Service Bus，ESB)：ESB是集中化的、逻辑上的，具有架构层次的组件，提供在分布式异构环境中高度可扩展性、容错、消息服务等服务框架的一种实现。服务质量(Quality of Service，QoS)：与SOA服务相关的服务质量。QoS的关键元素有安全需求（如认证和授权），可靠通信（指确保消息“仅且仅仅”发送一次，从而过滤重复信息），以及服务的调用策略。Web服务管理：为Web服务提供了可见性和管理。监控服务可用性，以确保服务质量、执行SLA(服务级别协议)。还负责处理负载均衡、故障替换及Web服务可靠消息传送。Web服务安全：为外部用户或者应用程序访问的Web服务提供了安全环境。包括加密、数字签名、验证、授权、机密性、数据完整性和不可否认性。可能与联合身份管理解决方案结合在一起。 1.4 参考资料本文档的参考文件包含：a. 长风联盟SOA-AP-TF EERP子任务工作方案书；b. 长风联盟电子政务全程优化功能设计研究报告；c. 长风联盟电子政务全程优化设计研究报告； -25- 长风联盟SOA-AP-TF第二章 全程优化基本原理2.1 需求规定全程优化是基于SOA，根据用户的业务目标，动态地对价值链进行构造或优化的软件平台及其相关理论。2.2 运行环境全程优化的目的为分布式、跨平台、松耦合的系统上运行，并提供系统间集成和流程编排的方法。图1 全程优化的技术基础全程优化建立在web service之上，以松耦合的方式连接应用。通过service对运行环境和系统进行解耦，达到更健壮、提高开发效率、增加灵活性的效果。从web标准的发展趋势看，XML、XSD、HTTP构成了基本的web标准框架，SOAP提供了在互联网上对象调用的方式，WSDL可以描述web service契约，UDDI的出现，可以在intranet或internet上发现web service，而全程优化则在intranet或internet上发现最符合业务目标适合的service，并将其构建为价值链。图2 web标准的发展趋势全程优化的服务和传统的web服务也有所不同。全程优化中的服务对web服务进行了描述、考核、管理等方面的扩展，代表一个可基于标准web协议和全程优化协议访问的可考核的业务逻辑单元。全程优化的目的是达到实时的价值链优化，这是通过对业务目标的分解和评价完成的，业务目标通常包含由多个考核目标构成的一个指标体系，可以通过综合决策方法进行求解。2.3 全程优化中的服务质量（QoS）服务质量（Quality of Service，QoS）是全程优化中的重要概念之一。全程优化中对QoS的处理包含下列几个问题：l QoS分类l QoS需求l QoS衡量和评价l QoS控制服务分类是QoS定义的基础，服务可以在下列基础上进行分类：1、应用环境（电子商务、电子政务、能源、通信等产业）2、目标3、QoS需求（时间敏感、成本敏感）QoS分类的质量水平可以通过两种方式评价：1、基于客户满意度：优秀、良好、一般、差、很差；2、通过收集的质量数据（如可以用110级表示）；QoS类型可以包含：时间、成本、技术难度、技术工作量、易用性、稳定性、可获得性；在QoS需求的分解方面，一个服务可以由一系列服务构成，所以其服务质量也由这些服务决定；一个服务的服务质量必须分解到一系列构成它本身的子服务；QoS可以在不同的层次上定义；在高层的QoS和低层的QoS之间存在着映射关系（mapping relationship）；在QoS的衡量和评价方面，采集QoS信息的相关技术有：技术架构、采集服务、QoS管理平台等；QoS评价的相关研究内容有：QoS评价方法、QoS评价时间段、QoS评价粒度等。在QoS控制方面的主要研究内容有：QoS需求或评价指标；QoS状态采集方法；QoS评价方法；QoS优化控制。QoS优化控制有基于反馈的控制和面向目标的控制。全程优化中的QoS考核和管理主要有三个特征：独立的QoS管理、动态考核、与UDDI的动态数据交换。动态寻找合适服务有两种实现途径：只在（扩展）注册库中查找、同时在注册库和质量管理中心查找。图3全程优化中实现QoS管理的两种方式全程优化中的质量考核指标包括：通过率；给定参数的变化范围 (如, 成本、时间)；给定参数的精度；可获得性；质量考核可以是复合目标，如：成本/时间/精度/或者它们的任意组合。2.4 全程优化中的服务粒度控制全程优化中的服务管理包括：服务描述、服务构造与重构、服务考核、服务生命周期管理。其中的关键问题就是服务粒度的控制。服务粒度根据业务含义确定，可分为：细粒度服务、中等粒度服务、粗粒度服务。服务的粒度是用来描述所提供服务的粗细程度的量化，或者说是所提供服务的计算量的大小。服务的粒度可用服务所实现的业务逻辑的长度，也就是实现服务所包含的处理指令的条数来描述，但通常难以精确的度量。粒度是影响复用性能的重要因素。图4服务粒度对软件平台的影响针对服务粒度的优化目标为：尽可能消除大粒度构件内部的不稳定元素，充分利用大粒度所带来的优越性，复用性能也会得到提高。我们提出了服务重组在整个基于服务的开发过程中的位置，如图5所示。图5 服务重组在整个基于服务的开发过程中的位置服务粒度可以通过下列方式衡量：服务提供的计算量；服务实现的商务流程，或服务源程序包含的源代码行数。但通常来说，服务粒度是一个相对的概念，精确地衡量服务的粒度是比较困难的。一个基于Bayesian方法的服务重组过程示意图见图6。图6基于Bayesian方法的服务重组过程服务可以在不同的层次进行复用，复用数据的采集也可以在这些层次进行：图7 基于cache的服务复用体系在全程优化中，需要在业务目标和服务之间建立映射关系，以保证业务目标的达成，如图8。图8业务目标和服务之间的映射2.5 基本设计概念和处理流程全程优化的基本处理流程如图9所示。图9全程优化的基本处理流程2.6 全程优化平台在全程优化的研发中将采用理论探索与研发实现相结合的研究方法。对服务颗粒度、服务质量（QoS）考核、服务编排、流程优化等方面进行探索。并实现全程优化平台，支持服务的发现、QoS考核和流程自动编排。下面给出全程优化平台的框架图如图10。图10全程优化平台框架在全程优化平台框架下，在三个层面展开研究：在理论探索层面，重点研究服务颗粒度对服务重用的影响、优化指标体系、QoS的采集和综合评价、服务的智能编排四个问题；在标准制定层面，结合长风开放标准软件联盟的标准工作，形成服务颗粒度、QoS评价、全程优化等相关的技术标准；在平台实现层面，运用前两个层面的研究成果，实现全程优化的原型平台。全程优化平台的参考实现如图11所示。图11全程优化平台参考实现2.7 全程优化开发和部署策略全程优化的开发和部署过程如图12。图12全程优化的开发和部署过程下面给出一个基于敏捷方法的服务改进策略。图13一个基于敏捷方法的服务改进策略服务编排策略是全程优化中的重要环节。一个自顶向下的服务编排策略如图14所示。图14自顶向下的服务编排策略2.8 全程优化相关技术全程优化的相关技术有：1. SOA架构2. BPM3. 价值链评价指标体系的建立4. 综合评价方法在本文档中将对这些技术进行描述。第三章 SOA3.1 SOA基础全程优化平台建立在SOA基础上。面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，这种方式非常脆弱。对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然SOA是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），它已经出现很长时间了，其定义的概念与 SOA 相似。目前的 SOA 技术依赖于可扩展标记语言（eXtensible Markup Language，XML）为基础的技术。通过使用基于 XML 的语言（称为 Web 服务描述语言（Web Services Definition Language，WSDL）来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言（Interface Definition Language，IDL）可比了。Web 服务并不是实现SOA的惟一方式。前面刚讲的 CORBA 是另一种方式，这样就有了面向消息的中间件（Message-Oriented Middleware）系统，比如 IBM 的 MQseries。但是为了建立体系结构模型，所需要的并不只是服务描述。还需要定义整个应用程序如何在服务之间执行其工作流。尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流程，而更新零件数据库，以包括进新供应的货物却是技术流程。因而，工作流还可以在SOA的设计中扮演重要的角色。此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为所控制的外部合作伙伴进行的操作。因此，为了提高效率，需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。 所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何SOA中都起着重要的作用。SOA帮助企业信息系统迁移到“leave-and-layer”架构之上，这就意味着在不用对现有的企业系统做修改的前提下，系统可对外提供Web服务接口，因为它们已经被可以提供Web服务接口的应用层做了一层封装，SOA可以将系统和应用迅速转换为服务。SOA不仅覆盖来自于打包应用、定制应用和遗留系统中的信息，而且还覆盖来自于如安全、内容管理、搜索等IT架构中的功能和数据。因为基于SOA的应用能很容易地从这些基础服务架构中添加功能。所以，基于SOA的应用能更快地应对市场变化，使企业业务部门设计开发出新的功能应用。与传统的企业应用集成架构的主要区别在于，基于SOA的企业应用系统使用基于标准的服务，并包括过程/数据服务、编排和组合。基于标准的服务成了应用间的集成点。服务的编排和组合增加了服务的灵活性、重用性和集成性。3.2 SOA的元素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(Service Level Agreement，服务级别协议)模板的一部分。5. 服务的事务属性及服务的各个操作。这包括读、写、更新特性，操作是否等幂以及相关的补充逻辑信息。有必要区分服务的“开发时绑定”和“运行时绑定”。“绑定”指如何找到服务定义和服务实例，将其集成到客户应用程序，并最终在网络级别绑定。1. 开发时绑定如果在开发时发现和绑定服务，则能预先了解服务操作的签名，以及服务的服务协议和物理位置（至少是服务在目录中的精确名称）。开发时绑定是一个非常简单的模型，但可以满足绝大多数环境下的要求。当前项目可以识别先前项目已经创建的功能，并重用这些服务。2. 运行时绑定运行时绑定比开发时绑定复杂得多，运行时绑定包含多个级别：按名称查找运行时服务：这是最直接的动态绑定服务的方式，但也是最常用的方式：在开发时已经知道服务定义，并相应开发客户逻辑。客户段在目录中查找特定名称的服务，动态地绑定到不同的服务实例。按属性查找运行时服务：这与上面的方式相似，不同的地方仅在于按属性，而不是按名称发现服务。基于反射发现运行时服务：开发时并不了解服务定义的实际规范。例如，客户端可能查找一个属性正确的服务，但不了解服务接口。此时必须在客户段实现一些反射机制，以便客户端动态地发现服务的语义和有效请求的格式。此类服务异常复杂，极少使用；因为只有非常复杂的逻辑，才能动态解释未知服务接口的语义。应该尽量简化服务绑定。因为随着服务绑定过程动态级别的提高，复杂性和风险级别呈指数级上升。在绝大多数情况下，利用预定义服务，按名称查找服务是灵活性和实现复杂性之间最完美的平衡。3.2.4服务总线服务总线将SOA的所有参与者（服务和应用程序前端）相互连接在一起。如果两个参与者需要通信（例如，应用程序前端调用基本服务的一些功能），就必须依靠服务总线。服务总线类似于CORBA上下文中定义的软件总线概念。不过，这些概念之间存在巨大的差别。服务总线并不一定由单个技术组成，它可能包含多种产品和概念。下面简要介绍服务总线的一些特性。连结性：服务总线的首要作用是将SOA的参与者连结近来。它提供了必要的工具，使SOA的参与者（应用程序前端和服务）能调用服务的功能。技术异质性：服务总线必须支持多种不同的技术。企业使用的技术多种多样，因此，服务总线必须将基于不同编程语言、操作系统或运行时环境的参与者连接在一起。另外，企业有多种不同的中间件产品和通讯协议，这些都需要服务总线的支持。通信概念的异质性：与技术异质性类似，服务总线还必须支持各种不同的通信概念。由于不同的应用程序有不同的要求，因此服务总线必须支持多种不同的通信模式，包括同步和异步通信。技术服务：服务总线的主要作用是通信，但也必须支持技术服务，如日志记录、审计、安全、消息转换或事务。3.3 SOA中的服务粒度可以按基于服务的功能及发送和接收的数据数量来定义服务，如细粒度服务、粗粒度服务或组合服务。在SOA中服务粒度有两种相关的意思，即服务是如何实现的，服务使用和返回了多少数据或多少消息。细粒度服务执行了最小的功能，发送和接收少量的数据。粗粒度服务执行了较大的业务功能，并交换了更多的数据。细粒度服务是供粗粒度服务或组合服务使用的，而不是由终端应用直接使用的。如果应用是使用细粒度服务建立的，则应用将不得不调用网络上多个服务，并且发生在每个服务上的数据量较少，因而会对对系统整体性带来影响。所以，粗粒度服务的用户不能直接调用他所使用的细粒度服务。然而，由于粗粒度服务可能使用多个细粒度服务，因此它们不能提供粒度级的安全和访问控制。组合服务可以使用粗粒度服务和细粒度服务进行组装。数据数量不是粗粒度服务和组合服务之间的区别。粗粒度服务例子，如创建新客户，在这一过程的操作是：需要通过一些外部服务验证对客户进行验证，并在CRM应用系统中创建客户记录。组合服务例子可以是提供一个新的DSL线，这需要一个服务调用来验证订单、创建或验证客户，确认产品库存及为数据线分配资源。通过一组有效设计和组合的粗粒度服务，业务专家能够有效地组合出新的业务流程和应用程序。3.4 SOA的作用SOA是一种企业架构，从企业的需求开始。但是，SOA和其它企业架构方法的不同之处在于SOA提供的业务敏捷性。业务敏捷性是指企业对变更快速和有效地进行响应、并且利用变更来得到竞争优势的能力。对架构设计师来说，创建一个业务敏捷的架构意味着创建这样一个IT架构，它可以满足当前还未知的业务需求。要满足这种业务敏捷性，SOA的实践必须遵循以下原则：1、业务驱动服务，服务驱动技术从本质上说，在抽象层次上，服务位于业务和技术中间。面向服务的架构设计师一方面必须理解在业务需求和可以提供的服务之间的动态关系，另一方面，同样要理解服务与提供这些服务的底层技术之间的关系。2、业务敏捷是基本的业务需求SOA考虑的是下一个抽象层次：提供响应变化需求的能力是新的“元需求”，而不是处理一些业务上的固定不变的需求。从硬件系统而上的整个架构都必须满足业务敏捷的需求，因为，在SOA中任何的瓶颈都会影响到整个IT环境的灵活性。3、一个成功的SOA总在变化之中SOA工作的场景，更象是一个活的生物体，而不是象传统所说的“盖一栋房子”。IT环境唯一不变的就是变化，因此面向服务架构设计师的工作永远不会结束。对于习惯于盖房子的设计师来说，要转向设计一个活的生物体要求崭新的思维方式。如下文所写的，SOA的基础还是一些类似的架构准则。3.5 SOA的风险评估作为一种概念，SOA已成熟。但实现SOA的Web服务技术并不成熟。XML、SOAP、WSDL和UDDI等核心标准在整个行业已得到接受，而其他标准如安全所需的标准还处在发展中。许多组织要投资于SOA，势必要进一步确定SOA与经营业绩有什么明确关系。SOA没有Web服务也可以实施，也已有先例，这个事实很鼓舞人心。这意味着，由于Web服务的进入成本较低，而且能够重复使用现有的IT资产，SOA获得成功的可能性就更大了。SOA可以采用诸多方案通过诸多方法来实施，不过对每个组织来说，它们各自的好处还不明显。如果用户在设计和扩建方面的需求压倒一切，SOA和Web服务会带来巨大影响。衡量成功的尺度要与组织的目标和业绩联系起来。即便业务和IT没有紧密联系，SOA也会给内部的IT系统带来好处，从而提高内部客户的满意度。SOA存在两个风险：一个风险是，向SOA迁移过早或者过晚、未能充分发掘节省成本的潜力；另一个风险就是，SOA实施不当（也就是说，没有用Web服务），可能会导致组织被过时、专有的技术缚住手脚。第四章 业务流程建模4.1 BPM简介在全程优化中，为了编排业务，构建和优化价值链，首先需要一种描述业务的方法。业务流程建模(BPM，Business Process Modeling)是对业务流程进行表述的方式，它是过程分析与重组的重要基础。在跨组织业务流程重组的前提下，流程建模的主要目的就是提供一个有效的跨组织流程模型并辅助相关人员进行跨流程的分析与优化。目前有大量的流程建模技术能够支持业务流程的重组，但同时这也给相关人员带来困惑：面对如此众多的技术，他们很难选择一种合适的技术或工具。同时，目前对流程建模技术的研究大多集中于建模技术的提出与应用，缺乏对现有技术的整理与分类以及技术之间的横向对比，这也就加深了建模技术选择的复杂性。BPM是一套设计、执行、管理及监控业务流程的技术和标准。一个业务流程是指为了实现某种业务目的行为每个行为可以是一个人的操作、一个内部系统、或一个合作公司的流程的流程或一系列动作。今年来业务流程和BPM的范围已经被扩展。就在几年前，BMP或工作流 (workflow)用来管理和驱动在公司部门内大型人力和纸制流程的组件。例如，处理一个申请(保险申请)，将扫描的纸制申请表格作为输入，电子化地从一个索赔受理者的电子邮箱(或者worklist)传到另一个那里。这相当于模仿各办公室邮件在办公桌之间传递的传统动作。现在BM是一种企业集成技术，作为对面向服务系统架构(Service-Oriented Architecture(SOA)、企业应用集成(Enterprise Application Integration(EAI)、企业服务总线(Enterprise Service Bus(ESB)的补充。当代的流程成功地处理了复杂系统的交互，其本身作为一种服务依照良好定义的技术契约可以与其它公司的流程交互、交流。例如，零售商处理购买订单的流程运用Xml消息与基于服务的顾客和仓库流程交互。BPM是一个不完整的规则，其中有许多不同的形式、表示法和资源。另一种常用的技术是定义表示概念性流程流的事件驱动流程链，正如Barker和 Longman所定义的。这第二种技术使用了不同于UML的表示法。此外，还有许多专用方法(如BPM技术)可能被咨询公司和企业资源规划(Enterprise Resource Planning，ERP)软件包厂商视为具有竞争优势。ARIS Implementation Platform就是这样的产品的一个例子。其他的方法包括：Line of Visibility Enterprise Modeling (LOVEM)和IBM的组件业务建模(Component Business Modeling，CBM)战略。最近的趋势是定义表示可执行流模型(如用于Web服务的业务流程执行语言(Business Process Execution Language for Web Services，BPEL)的标准方法。BPEL 将流程的范围从分析扩展到实现。这样的可执行模型引发了一系列的新问题，其中包括：哪些方面应该用BPEL描述，哪些方面应该用WSDL描述?流程模型和传统的编程模型之间的区别在什么地方?如何将非功能性要求和服务质量特征这样的方面加入模型之中?同更传统的编码(例如在J2EE中)相比，在BPEL引擎的编程语言扩展中执行多少逻辑?如何评定可执行流程模型的质量，其应用的最佳实践是什么?什么工作角色进行 BPEL流管理，是业务专家(分析人员)，还是开发角色(软件架构师)?必须利用所有现有的BPM方法作为SOAD的起点。然而，必须使用流程模型中用于驱动候选服务和它们的操作的附加技术来对其加以补充。此外，SOAD 中的流程建模必须与设计层用况建模保持同步，并且必须给出与BPEL有关的问题的答案。4.2 BPM相关标准BPM的相关标准如表1所示。表1BPM相关标准标准组织类型业务流程执行语言(BPEL：Business Process Execution Language)OASIS执行语言(Execution Language)业务流程建模标记(BPMN：Business Process Modeling Notation)Business Process Management Initiative(BPMI)标志语言(Notation Language)业务流程建模语言(BPML：Business Process Modeling Language)Business Process Management Initiative(BPMI)执行语言业务流程查询语言(BPQL：Business Process Query Language)管理与监测接口工作流XML（WfXML：Workflow XML）WfMC编排（Cheoreography）(或与之类似)业务流程定义元模型（BPDM：Business Process Definition Matamodel）OMG执行语言与/或标记语言，如MDA元模型业务流程运行时接口（BPRI: Business Process Runtime Interface）OMG管理与监测，用户交互，系统交互，如MDA元模型Web服务Choreography接口(WSCI: Web Services Choreography Interface) W3C编排Web服务Choreography描述语言（WS-CDL: Web Services Choreography Description Language）W3C编排Web服务转换语言（WSCL: Web Services Conversion Language）XLANGW3C, Microsoft编排，执行语言Web服务流语言（WSFL: Web Services Flow Language）IBM执行语言业务流程设计规范（BPSS: Business Process Schema Specification） OASIS编排（及协作）图15BPM体系如图15，在这个体系结构的核心部位是一个执行流程的运行时引擎，其流程的源码是由基于XML的BPEL语言写成，BPEL是当今最著名、广泛应用的BPM标准，及最优秀的BPM执行语言。这些流程是由业务和技术分析家使用支持可视化流程图语言BPMN最好的BPM图形语言的图形编辑器设计出来的。此编辑器包括一个导出器，可以从BPMN图生成BPEL代码(之后部署到引擎)。(在当前许多Java开发工具中，BPMN到BPEL的流程与UML到Java的流程相类似) 。人和计算机的交互驱动引擎里的流程的执行。作为参与者的人使用一个图形化工作列表应用程序浏览并执行未执行完毕的手工工作(在流程运行的引擎里)。依附于公司网络的但在引擎地址空间外的内部IT系统，被诸如web服务，J2EE，或COM的集成技术，通过XML作为选用的消息格式所访问；用编程语言如java、C#写出的内部交互可以是更轻便的内嵌代码片断。外部交互是典型的基于web服务的通信，由编排控制，例如那些用新兴的XML语言WS-CDL这个领先的编排语言所创作出的外部交互。虽然编排描述了多个参与者流程交互(在business-to-business电子商务里很典型)的整体、引人注意的视图，但是编排工具包可以用来生成一个基本的BPMN模型，其可以捕捉某个特定参与者流程所要求的通信，同时这个工具还可以验证一个给定的流程是否满足编排的要求。(WS-CDL文献建议由WS-CDL生成BPEL而不是BPMN。但是在现在的体系结构中，BPMN作为一种设计语言是一个必要的间接层)。BPM系统管理员里利用一个图形化的监视控制台来维护和跟踪引擎流程的状态。控制台使用一种管理语言与引擎衔接。实时引擎将流程状态持久化到数据库，控制台直接与数据库碰面，而不是用管理语言来沟通。运行时引擎将流程状态持久化到数据库，控制台直接与数据库碰面而不是使用管理语言来专门执行流程的请求。监控构造也支持业务活动监控(Business Activity Monitoring (BAM)或者仪表板式的业务监控。4.3 基于BPM的开发过程在这个平台上的开发过程如下：1. 从一个WS-CDL choreography生成一个初始的BPMN模型。如果流程并不是从一个编排衍生而来则越过此步。 2. 设计BPMN模型 3. 从BPMN模型生成BPEL 4. 开发必要的人和系统(内部和外部)的接口 5. 部署BPEL代码和其必要的接口到引擎 6. 使用管理和监控接口跟踪正在运行的流程。这个体系结构的全貌(由WFMC的参考模型形成)，类似许多集成厂商(如，IBM、BEA、Oracle、Tibco、SeeBeyond和Vitria)所提供的平台。使这个体系结构特别的地方是其标准的选择。BPEL、BPMN和 WS-CDL都被包含进来，因为他们分别是执行、设计和编排的最好解决方案，BPM最重要的三个部分。图16BPM发展趋势(如图16所示，未来可能包括新兴标准BPQL用于监控，BPSM和BPDM用于元模型建模，BPRI用于运行时接口，BPXL用于BPEL扩展)。事实上，很多厂商支持或正在实现支持BPEL。但是BPMN的支持非常少(大多数厂商提供各自的方案)，WS-CDL的支持几乎没有。BPEL并不够。这个体系很理想化，需要实际的实现。与BPMN和ws-CDL不同的是，BPEL有很多好的工具，例如Oracle的BPEL Process Manager。第五章 价值链评价指标体系的建立5.1 评价指标体系简介要实现价值链的全程优化QoS评价和顾客满意战略，就必须有一套衡量、评价、提高顾客满意度的科学指标体系。这套体系至少应该具有下面三点功能： 1、测量和评价企业目前的顾客满意度；2、提供提高顾客满意度的思路；3、寻求实现顾客满意度的具体方法；由于顾客期望、顾客对质量的感知、顾客对价值的感知、顾客满意度、顾客抱怨和顾客忠诚均为隐变量，都不是可以直接测评的。我们需要对隐变量进行逐级展开，直到形成一系列可以直接测评的指标，这些逐级展开的测评指标构成了顾客满意度测评指标体系。5.2 建立评价指标体系的意义全程优化为产业链提供面向顾客满意度的优化。顾客满意指标（CSI）首先是由设在美国密西根大学商学院的国家质量研究中心和美国质量协会共同发起并研究、提出的一个经济类指数。过去五年研究显示，ACSI（美国顾客满意度指数）与道琼斯指数有着明显的一致性，但它比道琼斯更具前瞻性。迄今为止，共有包括韩国、台湾、欧共体在内的22个国家和地区设立了自己的研究机构，并开始逐步推出全部或部分行业的顾客满意指标。通过顾客满意指标体系，可以实现以下几方面的用途：1. 测定企业过去与目前经营管理水平的变化，分析竞争对手与本企业之间的差距；2. 了解顾客的想法，发现顾客的潜在要求，明确顾客的需要、需求和期望；3. 检查企业的期望，以达到顾客满意和提高顾客满意度，有利于制定新的质量或服务改进措施，以及新的经营发展战略与目标；4. 明确为达到顾客满意，企业在今后应该做什么；是否应该转变经营战略或经营方向，从而紧随市场的变化而变化；5. 增强企业的市场竞争能力和企业盈利能力。5.3 建立评价指标体系的原则在建立顾客满意指标体系时，必须遵循下列四大原则：1. 建立的顾客满意度测评指标体系，必须是顾客认为重要的。“由顾客来确定测评指标体系”是设定测评指标体系最基本的要求。要准确把握顾客的需求，选择顾客认为最关键的测评指标。2. 测评指标必须能够控制。顾客满意度测评会使顾客产生新的期望，促使企业采取改进措施。但如果企业在某一领域无条件或无能力采取行动加以改进，则应暂不采用这方面的测评指标。3. 测评指标必须是可测量的。顾客满意度测评的结果是一个量化的值，因此设定的测评指标必须是可以进行统计、计算和分析的。4. 建立顾客满意度测评指标体系还需要考虑到与竞争者的比较，设定测评指标时要考虑到竞争者的特性。顾客满意指标体系会随着市场及顾客的变化而变化，今天顾客不在意的因素，有可能成为顾客明天关注的“焦点问题”，因此对顾客的期望和要求应做连续跟踪研究，从而了解顾客期望和要求的变化趋势，并对顾客满意指标体系做出及时的调整和采取相应的应对措施。5.4 建立评价指标体系的流程图17 顾客满意指标（CSI）体系建立流程 在建立顾客满意指标（CSI）体系时，首先要对该行业有一个大致的了解，只有在对行业背景有大致理解后，项目执行人员才能明确需要进一步深入的问题。由于构建顾客满意指标体系基本上是一个基于顾客调查的过程，故对调查方法的选择将直接影响最终结果的客观性与科学性。除了二手资料