企业信息化的动机除了提高效率，还包括增强企业对环境(客户、供应商和竞争者)的应变能力，从而提升竞争力。然而研究发现，一旦环境真的改变，很多企业即使能够应变也不愿意改变，因为一旦响应外界的变化，那么已有的信息系统不再适用，甚至推倒重来，先前的信息化投资付之东流。因此，我们总结出这样一条悖论：企业谋求信息化提升应变能力，实际上信息化却阻碍了企业变革的意愿和能力。悖论存在的一个重要原因，就是过去开发的信息系统适应性太低，难以有效地响应外界的变化。这在客观上要求信息系统具备适应各种变化的能力，具备良好的柔性，因此有关信息系统柔性的研究应运而生。

　1、信息系统柔性的相关研究

　　柔性是系统所拥有的处理环境或由环境引起的不确定性的能力。柔性表现为处理变化的能力，按照能力的高低可将柔性分为三个级别：集成和缓冲的能力、适应能力和创新能力。信息系统的柔性，通常被划分为三个层次：界面层次的柔性、数据层次的柔性与逻辑层次的柔性。界面层次的柔性是最低层次的柔性，是指在客户端为用户提供多种输入输出格式，满足用户根据实际情况自主变换界面显示的需求。数据层次的柔性是指系统能灵活地定义和修正系统的数据模式，并能根据定义和修改后的数据模式自动地调整各种记录界面、输出界面和界面信息等显示界面。逻辑层次的柔性能使系统逻辑灵活变动，调用并组合后台应用程序的各种功能，既能适应动态变化的业务需求，还能创造新的业务流程，使系统具有强的适应能力与创新能力。

　　阮观润采用C/S模式开发信息系统。在客户端建立可由用户主动选择输出模式的友好界面，实现对用户的柔性。同时，在服务器端，充分利用软件重用技术，以及XML技术集成数据，只对原有系统做最低程度的修改或添加即可适应变化，实现对开发者的柔性。C/S架构虽具有可重用性，但并不具有敏捷性与可变性。方旭升提出基于数据库的柔性MIS的概念，但这种研究着重从底层数据人手，采用自底向上的开发模式，从系统的数据结构柔性出发，逐步向子系统、系统的柔性发展，其结果可能使得研究工作变得越来越复杂，不仅增加系统开发成本，还可能降低灵活性。陈兵在数据库中使用附加表的方法对所有表结构进行登记，通过这种方法来提高数据结构的柔性，但该方法只能实现较小的数据结构变动。朱连江采用分布式技术开发一个“即时开发一即时接入一即时使用”的集群开发信息系统管理平台。但随着业务的发展，必将扩展平台，开发更多新系统。这可能产生技术瓶颈，而且新老系统缠绕在一起，会带来平台运行与管理上的混乱，还会造成一定的安全隐患。李绪蓉利用构件技术开发快速可重构的信息系统。但构件的重用性仅仅体现在系统开发阶段，一旦开发完毕，各种构件就被解析并组装成具有固定逻辑和行为的紧耦合系统，这种方法在提高软件开发效率的同时牺牲了系统的逻辑可扩充性。

　　针对存在的不足，近年的研究转向，从面向流程视角来探讨如何实现信息系统柔性。Masahim Nakagawa提出将Web Service集成技术引入到业务流程管理中，以适应快速变化的业务环境，实现实时管理。Frank Leymarm等在分析web Service与业务流程之间关系的基础上，提出采用Web Service实现业务流程中的各种活动，以使Web Service技术更好地支持动态业务流程管理。Jtm Shen等通过分析在Web Service环境中的业务流程集成现状，提出采用OwL-S描述Web Service，以提高流程描述的语义准确性，理清流程对象问的关系，实现高层次的业务流程集成。

　　SOA具有的开放性、自治性、自描述性、实现无关性、松散耦合等特性，为信息系统柔性的实现提供了技术支撑。Raghu Varadan等采用SOA架构构建信息系统，并通过SOA治理来提高系统柔性；Minglun Ren等运用SOA提供的松耦合服务架构来有效协调同步的业务流程设计与实现，以此实现敏捷性与柔性。

　　David Margulius指出成功的SOA起始于IT人员与企业管理者的合作，业务流程建模正是由于SOA的出现才显示出真正的实力，SOA加快了业务流程优化。于是，有学者结合业务流程管理技术与SOA的优势来构建敏捷企业，增强信息系统柔性。OMG组织提出利用BPM与SOA建设敏捷企业，BPM可帮助SOA划分服务粒度，定义元数据，而SOA又可更好地实现BPM；王辉等从不同角度阐述了BPM与SOA互补所产生的柔性优势，构建实时企业；潘昊等指出BPM使业务流程随业务需要而改变，SOA屏蔽底层IT系统的复杂性，使高层业务整合更加方便，进而提出构建以BPM为中心的SOA系统，不但有效地整合已有的企业资源，还能最大限度地提升业务敏捷性。

　　基于上述分析，本文提出以业务敏捷性为导向，结合BPM与SOA的优势，采用BPM技术优化流程，通过SOA技术实现改进的流程，使得系统能随着流程的改变进行动态响应，实现信息系统的柔性，从而能使系统具备对环境的适应能力。

　　2、SOA与BPM相结合提升信息系统柔性的可行性

　　2.1 BPM提升信息系统柔性的优势BPM旨在

　　利用IT技术重用原有流程，建立一种贯穿于整个企业流程生命周期的管理机制，达到持续管理、全局优化的柔性效果，以使业务流程可分析、可管理、快响应、易变更，并确保业务流程与业务目标相一致。BPM的柔性优势表现在以下两个方面：从战略思想上看，BPM涵盖企业营运的各个职能部门活动，甚至扩及到上下游的供应商、经销商以及客户的活动，强调建立、管理和维护整个价值链的、以客户为导向的、端到端的业务流程。串连原本相互独立而未协调的职能活动，使之成为步步增值的企业营运流程，并辅以各项管理手法使其落实运行，从而达到优化流程、影响环境的目的。

　　从软件技术上看，BPM倡导利用IT架构和技术，以业务流程模型为输入的自上而下的柔性资源集成和整合方式，试图将生产流程层、运作层、计划层、战略层等四个层面上的流程管理统一到一个框架下，并整合到企业的信息系统中，强调业务驱动、业务人员的友好建模以及业务的可视化，从而拉近了业务与IT的距离，搭建起沟通管理与技术的桥梁。

　　2.2 SOA提升信息系统柔性的优势SOA具备以下实现架构柔性的关键优势：

　　2.2.1面向业务的粗粒度。SOA提倡从业务需求出发，自上而下从业务层到技术层逐层分解业务目标和需求，然后自下而上将底层应用从功能角度抽象为上层所需服务，从而实现IT技术为业务和管理服务的目的。粗粒度减少了重用的复杂性以及通信开销，从而增加了业务可重用性。

　　2.2.2自治。服务相比组件提供更加明确的功能和更为狭窄的接口，并且自行管理生命周期，维持自身事务和运行状态。服务调用者无需考虑服务运行的细节，只需了解其功能并通过标准接口调用即可。

　　2.2.3异步调用。异步调用是实现技术和业务松散耦合的前提，尤其是在跨越Internet集成和互操作的情境下。这是因为采用异步调用无需等待回复便可继续执行，以此可以提高程序的运行效率。

　　2.2.4基于消息。消息是实现松散藕合的又一前提。因为远程对象基于Stub-Skeleton或Proxy-Stub的方式要求远程状态同步，一般远程调用的内在不协调是造成IT架构难以实现互操作和可扩展性的关键原因，而消息是一种打包数据，不是远程对象指针，不需要维持其状态并将状态通知所有需要知道的调用者。

　　2.2.5纯文本协议与元数据。当需要跨越众多异构硬件平台和软件系统时，基于二进制的远程调用方案总是存在着难以彻底解决可理解性的问题，而凭借纯文本的结构透明性加上元数据的自描述特性，可以实现基于机器的语义互通和透明性，使得各种中间层都能够以通用的方式传递经过的消息，并理解其中需要理解的部分。

　　2.2.6可动态发现与动态绑定。SOA的服务不仅是可描述的，而且是可动态发现的，从而使服务的延迟绑定、服务的即插即用和热插拔成为可能。因此服务位置透明，我们可以动态更换一个服务提供者而无需影响调用端应用程序的配置。

　　2.3 SOA与BPM相结合提升信息系统柔性的优势分析SOA是先进的软件架构模式，但需要正确的业务管理思想来指导，才能发挥优势。BPM是先进的流程管理思想，但需要一定的技术体系来支撑，SOA恰好能够给予BPM支持，它的松散耦合、服务重用和共享等特点，能够使BPM的管理思想落到实处。

　　2.3.1 BPM需要SOA来灵活调用后端应用程序。BPM的核心是流程，而流程的执行则涉及对底层各应用系统的同时操作。现有的企业应用系统的开发大多是以职能(功能)为中心，跨职能部门的业务流程会表现出低效率缺陷。以客户下订单这一跨职能流程为例，客户先与销售部联系下达订单，销售部验证客户信息后与仓库联系查询库存量，若库存不足则通知采购部向供应商订购配件，到货后通知生产部门制造产品，最后通过物流企业将成品配送至客户。这是一套复杂的跨职能部门、跨组织的流程，需要调用多个异构系统的功能与数据。比如，首先调用CRM获取客户信息，然后调用SCM获取供应商信息，最后调用ERP获取库存信息与安排生产计划。然而这些系统间的功能由于缺少适当的IT架构支持而无法集成，数据无法共享，造成流程刚性强，效率低下。

　　可见，BPM需要一种全新的技术架构，使它在企业应用集成中充分表达业务需求，对原本根植在应用系统中的流程做出清晰的定义，将业务流程作为独立的对象提取出来管理，以提高企业的灵活性。这是SOA可解决的典型问题，它能在不改变流程的前提下。动态灵活地调用后端应用程序与数据。

　　2.3.2 SOA需要BPM来定义服务。SOA确定服务模块的一个方法是将现有应用系统中所有提供的功能以列表的形式列出，按照功能域进行划分，然后封装成服务。这种方法虽然可以作为建立新系统的依据，但是，由于过多考虑了软件系统的功能要求，而不是从业务需求出发，不能充分发挥SOA的作用。而BPM恰好可以解决这一问题。通过BPM分析企业的业务流程，将主要流程以图形化方式表示，然后层层分解，这样可以知道企业需要完成什么样的工作，对于这些工作又需要什么样的服务模块。通过运用BPNkN对业务流程建模，可以帮助定义服务编排，通过分析业务规则与业务对象，可以帮助定义服务元数据。此外，通过业务流程分析，使管理者更清楚地了解信息系统所提供的功能，以及这些信息系统对于企业运作的真正价值。

　　2.3.3引入领域本体，实现业务流程对动态业务需求的适应性，也能支持信息系统对流程变化的适应性。

　　本体是概念模型明确的规范化说明。构建领域本体，能够捕获相关领域的知识，提供对该领域知识的共同理解，确定该领域内共同认可的词汇，并从不同层次的形式化模式上给出这些词汇(术语)和词汇之间相互关系的明确定义，实现知识的共享和重用。

　　在BPM中引入领域本体，构造业务流程知识库，储备特定领域通用的业务知识，帮助流程设计者理解领域，用业务专家与IT专家都能理解的语言规范地表现出来，使需求表达更加方便、清晰，降低了业务人员与IT人员的沟通障碍。同时，当系统的业务需求发生变化时，只需要改动描述该业务流程的本体模型，不必对软件代码进行任何变动。

3、基于BPM-SOA的信息系统构架

　　图1给出了基于BMP-SOA的信息系统架构，该构架以流程为导向，以服务为基础。

 

 

自底向上，各层的功能及相互关系如下：

　　3.1应用层应用层可对现有的企业IT资源进行有效利用：第一，为上层提供底层技术支持，这种技术不仅包含原有系统(如CRM、SCM、ERP等)拥有的相关功能，还包括各种构件所实现的功能；第二，不同数据模式的数据库和不同格式的数据，通过数据库适配器为服务层或企业服务总线(ESB)提供数据服务。

　　3.2服务层服务层承上启下，向上承接业务流程，向下连接具体实现技术。该层以Web服务平台为基础设施，包含封装的Web服务(如应用服务、业务服务和流程服务)，以及OWL-S/UDDI服务信息中心。信息中心为服务请求提供语义搜索和智能的服务发现功能，搜索到的服务将与BPEL过程模型直接绑定或者作为服务合成的备选服务，这些备选服务将通过服务合成模块的本体进行二次建模，建立的本体模型是服务合成的基础服务形式。这时候，服务合成模块中的服务匹配将负责搜索符合要求的服务模型和判断服务与目标服务的语义关系来确定服务合成的完成状况。服务合成后通过消息与应用层的ESB进行通信，调用相应的web服务。

　　3.3业务流程层业务流程层基于BPM与本体思想。包含BPM解决方案的管理工具、BPEL引擎与基于本体的业务流程知识库。根据表示层传递的消息，从业务流程本体库中查询并调用相应的业务流程模型。通过BPEL引擎的执行为服务层提供服务发现与组合的依据。当系统的业务流程发生改变时，只需要改动描述该业务流程的本体模型，并通过BPM管理工具对流程进行重新分析与设计。

　　3.4表示层表示层是系统对外的应用接口，为外部访问提供操作与可视化的界面，包括远程客户端、本地客户端等。通过提供用户交互界面，方便用户访问企业系统的业务流程和具体功能。

　　3.5服务质量控制、安全管理与监控为业务功能提供补充，它的作用包括质量、安全、管理、事务处理方面的控制，通过特定工具、响应机制和标准来监视以上各层的运行，提供日志服务和身份验证功能，保证服务的健壮性，确保服务质量。

　　4、案例分析

　　4.1案例背景 RMO是一家著名的经营运动装备的公司，其制造以组装零配件为主，并已建立起JIT装配流水线。公司本身并不生产配件，而是向供应商订购，并拥有完备的物流配送中心，且与多个实力雄厚的物流企业关系良好。

　　随着业务的发展，RMO管理者意识到信息系统对于企业管理的重要性，先后实施了SCM、CRM系统，两年前不惜重金购买SAP公司的ERP系统，还建立了电子商务网站，实现在线交易，迅速提高市场占有率。伴随进一步的信息化建设，企业的经营管理却遇到难以突破的瓶颈。近来，管理层发现企业正处于不良状态：一方面，每月的销售订单及品种规格很多，大多数订单的订货数量却很少；另一方面，又会经常接到一些临时订单，且客户要求的交货时间很急。在这种情况下，由于每次从客户订货到配送整个核心流程需要调用多个异构系统的功能，系统间的数据又无法共享，造成数据繁冗，反应迟缓。于是只能以高的配件库存量来换取响应客户需求的速度，如此产生了占用大量资金等一系列问题。

　　4.2柔性障碍分析从信息系统的角度分析主要存在以下柔性障碍：

　　a.传统ERP系统的实施通常是向已经设定好的ERP模块中套用企业的业务流程，并进行少量的二次开发，其实施模式是以产品为中心而不是以客户需求为中心，如此内化和固化流程导致流程刚性，陷入无法快速响应客户需求的困境。

　　b.企业IT架构环境复杂，存在大量分布式异构信息系统，在数据和应用集成上采用紧耦合的非柔性方式。从客户订货到配送整个核心流程需要调用多个异构系统的功能与数据，然而这些系统间的功能无法衔接，数据无法共享，造成流程复杂刚性，反应迟缓，效率低下。

　　c.大多数关键数据来自车间和仓库。而系统又缺乏对底层生产流程数据的采集，产生管理流程和解决能力的瓶颈，从而使得优化流程的能力十分有限。

　　随着业务的发展，RMO迫切需要实现信息系统柔性的解决方案，不仅能够管理、修改、完善和优化流程以适应业务需求变化，尽量保持信息系统功能与业务需求最贴近，还能够重用企业原有特殊流程。为此构建一套基于BPM-SOA的信息系统。

　　4.3分层实现基于BPM-SOA的信息系统

　　4.3.1业务流程层。图2为细化的业务流程层模型。根据用户发出的流程调用消息，通过查询组件与推理引擎进行语义分析与推理，确定流程目标。从实例库中搜索能完成目标的业务流程实例。如果存在相似实例，则选择最合适的，作为完成目标的业务流程；如果不存在相似或部分类似的实例，则调用BPM管理工具进行业务流程建模，将新定制定或修改的实例存储在实例库中。获得相应实例后便进行BPEL编码，生成BPEL文档。流程执行引擎翻译BPEL文档，能根据文档执行流程实例，包括等待业务逻辑的处理、接受处理结果、选择流程处理路径、发送消息给服务信息中心调用相应的服务、返回消息给相关人员等。执行引擎往往需要流程管理模块对其执行进行监控，一旦出现异常就得中止。

 

 

例如，柔性优化客户订货流程。改变传统的依靠增加库存来满足订单需求的批量备货式生产，变“推动式”生产为“拉动式”生产，以客户需求为导向，采用定货组装的方式组织生产，由客户订单驱动整个生产流程，根据订单选择配件，装配产品。

　　流程设计如下：

　　a.客户通过ROM公司门户网站发送订单消息到企业系统，由此触发了订购流程。

　　b.将订单插入订单数据库。

　　c.获取客户信息活动，调用客户数据库中有关客户的信息，包括：账号、姓名、地址、身份证号、会员等级、信用卡信息等。

　　d.检查客户的信用卡的有效性，如果信用卡无效，则取消订单，反之则继续流程。

　　e.根据客户订购的要求计算生产该产品所需配件。

　　f.读取库存信息，检查配件库存数量，以确定是否能够满足生产需要。若配件不足，则与供应商交涉，询问报价以及到货时间。反之，则开始计算订单价格，并安排生产和配送计划。

　　g.得出订单价格后，判断是否需要人工审核批复订单。采用工作列表的形式将需要审核批复或确认的消息发送给相关人员(如销售经理)。如果审核未通过，则取消订单，否则，继续流程。

　　h.将有关订单的价格以及到货时间等信息通过Email告知客户，然后等待客户接受订单并确认的消息事件，以触发生成合同、若库存不足向供应商订货、按前面已确定的生产计划生产与配送等活动。若客户同意(这里有超时机制)，则进行后续活动，反之，则取消订单。采用BPNDa Modeler软件，以上述流程中的步骤(a)-(e)为例进行BPMN建模，如图3所示。

 

　最后，由于BPNEN与BPEL之间存在映射关系，可利用转换机制，将图2转换为可执行代码(见以下代码)，并通过BPEL引擎调用相应服务。

 

业务流程定义元模型(Business Process Definition Metamodel，BPDM)提供流程模型之间的共通语义，BPMN和BPEL各自的元模型能通过BPDM相互映射并转换成一种非私有的、语义完备的、基于MOF(Meta Object Facility)的XMI(XML格式的元数据交换标准)，并利用XMI实现元模型的描述和相互转换。同时，将新制定的流程用OWL语言进行形式化描述，建立本体模型，存储到业务流程本体库中，下面为流程(a)-(e)的形式化描述片段：

 

 

a.服务发布(Provide)。服务提供者首先采用本体描述语言(如OWL)建立领域本体，即对问题域中涉及的概念进行建模。采用WSDL对服务进行描述，并利用WSDL-S的语义IOPE标注引用该本体中的概念。从而将WSDL中的元素或者复杂类型与本体某个概念关联和映射，生成WSDL文档。通过基于SOAP的服务发布消息传递，将服务描述发布到UDDI注册中心，其中需要将wSDL-S数据结构映射到UDDI的数据结构。

 

b.服务请求(Request)。服务请求者需要对本体建模和注册，或查询公共本体库获取本体模型。对自身流程进行建模，抽象出所需高层服务，并给所需服务加上IOPE语义需求信息。通过基于黜的服务请求消息，用扩展的UDDI的API查询服务，如查询关键字或者服务IOPE等，按照发布与请求概要信息中的分类属性过滤服务，筛选出与需求接近的部分服务。通过引擎接口与匹配引擎相连接，进行服务发现的匹配计算，匹配需求描述与本体知识库中的模型，最后返回匹配服务的标准WSDL接口。

 

 

服务合成模块负责服务合成，该过程基于领域本体，消除服务合成过程中的语义问题。服务匹配是判断服务本体模型中的服务语义关系，从而确定服务合成的可行性和合成服务的组合方案。这部分的服务合成将该模块的逻辑算法自动运行完成，体现了服务合成的灵活性和动态性。

　　4.3.3应用层。ESB(企业服务总线)是一组实现与支持SQA的核心中间件技术，支持异构环境中的服务、消息，以及基于事件的交互，并且具有适当的服务级别和可管理性。因此底层技术可通过与ESB的连接有效地进行集成。

　　a.原有系统与ESB的连接。原有系统通过应用适配器接入ESB总线，为服务层提供所需服务(如图5所示)。首先，应用适配器将传递过来的消息转换成传输适配器能识别的统一信息表示方式，并将其发送给ESB的消息确认队列；然后，传输适配器从底层通信消息中获取SOAP消息，并接收服务适配器返回的SOAP响应消息；最后，服务适配器通过静态方式查找web服务，或者向UDDI注册中心通过服务路由目录查找相应服务描述信息，实现对web服务的动态调用。而在整个消息传递的过程中，ESB的三个部件(核心服务、元数据和系统管理)起着重要的支撑作用，其中核心服务是传输适配器和服务适配器用来对ESB传输的SOAP消息进行控制的一些基础服务，元数据为ESB运行、管理需要的基础数据及其配置数据，并通过系统管理对整个ESB进行协调与监控。此外，ESB也可通过数据库适配器对本地数据库进行数据操作与维护。数据库适配器有两项功能，一是实现数据格式的转换，二是执行对数据库的访问。它由数据库监听模块、数据库访问模块和结果集转换模块构成。数据库监听器负责接收访问请求；调用数据库访问模块对数据库进行数据操作；结果集转换模块与数据库访问模块相连，主要负责将数据库查询的结果集转换成统一的XML格式，以屏蔽异构数据库的差异，以及将接收的XML格式的访问请求转换成结构化的SQL数据库语言，通过数据库访问模块对数据库进行操作。若有多个消息对同一数据的多个副本要求更新时，ESB中采用冲突检测算法来处理冲突，使用有效的更新消息更新多副本数据表；同时将被撤消的消息发送给数据库适配器，试图撤消相应的更新操作。另外，若更新成功，ESB将同步发送更新消息到其他副本，从而使得各数据副本保持一致。

　　b.构件库与ESB的连接。ESB与构件库的连接如图6所示。首先，利用接口定义语言(IDL)将构件接口转化为web服务接口，然后将web服务接口形成的目录及web服务的UDDI映射到ESB的服务路由目录中。

　　映射过程如下：

　　首先，对构件接口封装。将构件交互所需的基本信息封装在接口中，接口定义了对象实体的属性和行为。接口定义使用IDL来描述，通过IDL编译器进行客户端与服务器端的映射。其次，将构件接口映射为web服务接口。构件接口定义的内容主要包括类接口定义、操作定义和类型定义，而Web服务的接口定义语言WSDL采用基于XML的语法，其接口定义内容包括服务接口定义和服务实现定义两部分，其中，服务接口定义描述服务提供的操作以及操作调用时输入饰出的消息，服务实现定义描述服务的协议绑定、地址绑定等实现信息，二者结合构成一个完整的服务描述。在接口映射中，IDL接口定义与WSDL中接口定义部分具有基本的对应关系，按相应定义规则进行转换，转换的规则一一对应如下：

 

最后，将构件接口形成与Web服务一致的接口目录及UDDI映射到E岛的服务路由目录，以便系统对构件及相应Web服务的动态查找。

　　4.4柔性能力分析系统初步实现信息系统逻辑

　　层次上的柔性，能适应用户需求的动态变化，调用相应的业务流程，并根据不同的业务流程，通过服务发布、发现、组合等过程，利用ESB与原有系统、现有构件库、各种数据库之间实现了很好的通信，跨越技术平台地灵活调用所需功能。

　　该系统将流程视为一种新的抽象数据类型，成为用户直接操作和管理的对象。因此，可利用BPM管理工具进行业务流程建模、管理与维护，达到优化流程的目的，让企业根据自身的业务需求量身定做自己的流程，并方便地对其进行控制和管理。

　　对于已经完成的业务，系统可快速调用相应流程服务，通过流程执行将信息返回给用户；对于新业务，系统可通过构造新的业务流程模型，组合现有原子服务或组合服务来实现。此外，业务的调整也可以通过调整服务之间的松散耦合关系，动态组合来实现。

　　5、结束语

　　本文按照BPM和SOA的柔性优势互补这一思路，提出以业务敏捷性为导向，采用BPM与SOA结合的方式，并引入本体的思想实现信息系统柔性。首先采用BPM的管理理念与技术优化流程，再利用SOA将优化的流程与企业的信息系统进行无缝地结合，并能随着企业需求的改变进行快速动态地响应。这一理念克服以往的仅仅具有流程实施前柔性、而缺乏实施后柔性的缺点，实现全价值链、全生命周期的柔性能力特征。

　　下一步工作将完善系统功能，并从服务编排的角度，对企业与合作伙伴的信息交互和集成进行研究。最后，将构件接口形成与Web服务一致的接口目录及UDDI映射到E岛的服务路由目录，以便系统对构件及相应Web服务的动态查找。

　　4.4柔性能力分析系统初步实现信息系统逻辑

　　层次上的柔性，能适应用户需求的动态变化，调用相应的业务流程，并根据不同的业务流程，通过服务发布、发现、组合等过程，利用ESB与原有系统、现有构件库、各种数据库之间实现了很好的通信，跨越技术平台地灵活调用所需功能。

　　该系统将流程视为一种新的抽象数据类型，成为用户直接操作和管理的对象。因此，可利用BPM管理工具进行业务流程建模、管理与维护，达到优化流程的目的，让企业根据自身的业务需求量身定做自己的流程，并方便地对其进行控制和管理。

　　对于已经完成的业务，系统可快速调用相应流程服务，通过流程执行将信息返回给用户；对于新业务，系统可通过构造新的业务流程模型，组合现有原子服务或组合服务来实现。此外，业务的调整也可以通过调整服务之间的松散耦合关系，动态组合来实现。

　　5、结束语

　　本文按照BPM和SOA的柔性优势互补这一思路，提出以业务敏捷性为导向，采用BPM与SOA结合的方式，并引入本体的思想实现信息系统柔性。首先采用BPM的管理理念与技术优化流程，再利用SOA将优化的流程与企业的信息系统进行无缝地结合，并能随着企业需求的改变进行快速动态地响应。这一理念克服以往的仅仅具有流程实施前柔性、而缺乏实施后柔性的缺点，实现全价值链、全生命周期的柔性能力特征。

　　下一步工作将完善系统功能，并从服务编排的角度，对企业与合作伙伴的信息交互和集成进行研究。