英语原文共 6 页，剩余内容已隐藏，支付完成后下载完整资料

针对服务型企业的服务管理框架

Ying Huang Santhosh Kumaran Jen-Yao Chung

IBM T.J. Watson Research Center, Yorktown Heights, NY 10598

yxh@us.ibm.com

摘要

随着面向服务的体系架构被稳健地采用，在实现各种web服务以及将已有的应用转变为面向服务的架构方面很多公司已经取得了重大的进步。由于大量的服务已经实现并投入实际使用，许多服务企业面临的问题是如何以有效的方式管理这些服务。在这篇论文中，我们提出了一个框架去更有效的管理这些服务。在这个框架中，企业解决方案的创建和维护通过夹杂在正式模型中的“工作流”和有限状态机（FSM）所模拟。例如，每一个企业解决方案将建模为复合服务，这些服务可以被各种的流和FSM所描述。这些解决方案模型可以被存储，然后取出去执行混合的服务。此外，正式模型的优于面向服务架构的优点也会被使用去维持和更新这些面向服务无法解决的方案以提高服务管理的效率和质量。在本文中，我们将首先提供一个企业服务的规范化分类。我们也将讨论这个框架如何帮助我们更有效地管理企业级服务。最后我们将给出一个实际的例子去说明这个框架在现实中如何被使用。

1.介绍

随着面向服务的体系架构被稳健地采用，在实现各种web服务以及将已有的应用转变为服务型架构（SOA）方面，很多公司已经取得了重大的进步。由于大量的服务已经实现并投入实际使用，许多服务企业面临的问题是如何以有效的方式管理这些服务。通过定义，服务可以被分配并且被内部和外部的服务提供商所提供。没有刻意地努力去收集、组织和维护关于目前正在使用的服务的信息，包括它们的来源花费和使用方式，服务器企业将快速进入一个不佳的管理状态并且经济上将太过昂贵到难以置信。这将失去SOA带来的大部分好处。

在这个框架里，企业解决方案的创建和维护被夹杂在正式模型中的工作流和FSM模拟。例如，每一个企业解决方案将建模为复合服务，这些服务可以被各种的流和FSM描述。这些解决方案模型可以被存储，然后取出去执行混合的服务。更重要的是，正式模型也被用于维护和更新服务型解决方案。例如，监视一个独特的面向服务的解决方案的执行将需要详细的关于参与其中的组件服务和它们之间的关系的信息。此外，知道它们在哪，状态如何，服务提供者是谁以及服务使用费是多少是非常重要的。没有适当的对服务管理的支持的话仅仅会增加在服务型企业部署服务的困难和成本。为了减轻这些问题，完全实现在企业中采用SOA的好处需要一个结构化的连贯的方式。为此，我们提出了一种在服务型企业中通过模型驱动的架构去管理基础服务解决方案的框架，去帮助服务型企业更有效地管理服务。此外，这个框架也规定了这些模型如何被使用去支撑各种服务管理活动。传统上，模型驱动的架构概念已经被应用在企业解决方案的开发。本文中这个框架将继承面向服务的解决方案以及相关服务管理的概念。

使用模型驱动的方式去管理企业服务的主要好处包括能够通过问题的准确识别以及快速、高性价比的方法去解决各种服务管理相关的问题。而且，它使得整个服务型企业解决方案变得更适应商业和IT环境的变化。本文将首先提出一个标准化的企业服务分类。然后描述这个服务型企业的管理服务框架。也将讨论这个框架如何使得管理企业服务更加的高效。最后，我们将给出一个实际中的例子去说明这个框架在实际中如何被使用。

2.服务型企业和模型驱动的框架

2.1服务型企业

传统上，企业被等级化地组织为一个牢固的指挥控制结构，并且在计划和执行时期各个功能单元处于严密的监督控制之下。例如在内部（企业内部）和外部（

客户和企业的供应商），企业有清晰的责任划分。这种类型的企业倾向于在经济上表现的很好而不受持续变化的影响。由于商业环境变得更加动态，并且质量标准被广泛地接受，企业不断地探索不同的着眼点去减少成本，通过精简内部流程以及与合作伙伴的关系。在最近几年，服务型的商业模式已经形成，企业的功能被定义为商业和信息技术服务。在这种模式下，企业使用基于组件的方式重新定义他们的商业和IT活动。在这种组件内，商业或IT功能被分解成一系列标准的已经被很好地定义了基础服务提供和接口并允许灵活地重组的流程或IT服务。为了更加正确地定义这样的服务型商业模式，我们推广已经被体系和IT社区使用的SOE项目。从系统和IT的角度，SOE是一个用于构建软件和IT基础设施的模型。它协调当前的平台结构并使得业务流程驱动架构。从商业角度来看，SOE的概念也应该将商业功能的组件化转化为服务，这些服务重组正在使用的业务流程将带来各种业务功能。

在它的核心，SOE采用服务网络的使用去达到一定的目的。服务网络采用接口无处不在的概念，多种应用使用相同的基础交流机制就像使用在一个应用内部，包括贸易伙伴之间也是如此。接口减少了整合力度并创建一个去采用的网络效用。

SOE为一线的商业和IT系统设计带来了协调性和灵活性。SOE的一个主要主题是去假定商业和IT系统将从一开始就有一体化的需求，而不是在后来加上它们。

2.2企业服务

使用面向业务模型的服务，企业服务可能包括主要两组服务：业务服务和IT服务。业务服务捕获一个企业基本的每天运行的操作。然后IT服务在另一方面被提供作为IT基础设施的一部分去支撑各种业务服务需求和他们的整合。下边的图表说明了这两组服务的分类：

2.4模型驱动型架构

模型驱动架构型在另一方面已经被工业联盟OMG主张。根据OMG的阐释，MDA是一个全生命周期整合的一种途径以及企业资源的组成:软件、硬件、人和商业资源的互相协调。它提供一个系统的使用工程方法和工具的框架去理解、设计、操作以及发展企业系统的所有方面。这个框架是基于模型的各个方面和系统的抽象的水平以及利用这些模型自己的互相关系。

这个模型驱动型架构以著名的并且建立很久的从方法的细节分离系统的操作规范这个思路开始。

MDA提供了一个途径和工具去提供：

指定一个系统独立于支持它的平台

为系统指定平台

为系统选择一个确定的平台

转化系统规范到一个特定的平台

MDA的三个初级目标是通过关联的结构分离实现可移植、协同工作以及可重用。下边的示意图说明了一个MDA中的模型:

目前的MDA讨论集中于计算机系统域。更明确地说，MDA已经被主要应用在企业解决方案或服务的开发。然而，它将是同样的关键对于确保服务型企业的解决方案和相关服务的开发和部署的适当管理。由于这个原因，本文中我们将在更加细节的方面审问怎样去管理基于MDA概念和原则的企业级服务。

3.模型驱动的服务管理框架

3.1企业级服务生命周期

由于转向SOA商业模型，企业将改变他们的商业和IT策略，经营方针和执行规则为了去实现面向服务的框架可能带来的整个费用和效率提升带来的益处。 一个典型的企业级服务将包括三个主要的阶段：服务开发、服务执行、服务管理。下边的示意图说明了企业级服务的三个主要阶段之见相互的关系：

3.2服务管理框架

在上边的企业级服务生命周期的描述中，管理阶段涵盖了典型服务型解决方案的从头到尾的阶段。它起始于一个服务的创建或已经存在的服务的更新请求。然后，取决于是新的或是已经存在的服务，服务将被创建或更新。一旦服务组成，它将被部署和执行。在整个过程中，这些服务将被监视并且任何潜在的问题将被发现和解决。本文提出的服务管理框架会捕获企业级服务生命周期内的所有步骤，并且展示在下图当中：

a.模型驱动：除了别的之外，这个框架的一个重要特征是模型驱动。在每个关键阶段，模型将被建立用于排序和控制每个活动的执行。作为结果，这些服务的管理是完全基于模型的不同的细节层次。

b.结构化支持：这个框架为服务的更好管理提供了一个结构化的支持。有了底层模型的支持，所有的关键活动和流程作为服务管理的一部分将被模型化。这使得比起没有模型驱动的方法，支持是更加结构化的。

c.虚拟化：这个框架的底层模型使得服务管理变得虚拟化，它使得整个服务的管理变成虚拟模型包括这些模型间的相互作用。

d.响应性：一旦知识基于底层模型被虚拟化，作为相应的模型这个框架允许服务管理由于掌握了关键知识而针对改变的环境变得更加具有响应性。

e.精确性：这使得对持续改变的环境的具体的需求变得更加精确。比起没有模型支持，它可以用一个更加精确的方法指出问题和因素。

f.透明性：由于模型驱动的方法，这个框架将允许服务管理全面的透明。任何请求和问题解决方案可以通过底层模型被确认。这些底层模型被使用标准的可以通过相关的员工或控制电脑程序完全理解模型语言所描述。

3.3服务管理框架结构

在这一章节，我们将考察这个框架的更多细节并且讨论在企业服务管理中，模型在不同阶段如何被使用。

这个框架为所有角色的企业级服务管理参与者提供了一个首尾相接的支持。这些参与者包括用户，开发这，服务提供者和服务管理与控制者。这个框架允许服务请求和这些请求的解决方案的基于模型的捕获。在这个框架中下边三种正式的模型将被包括：

1.流模型：流模型使用控制流图表捕获流程活动的结果，这些图表可以使用BPEL进行描述。

2.有限状态机模型：商业工艺品的模型和它们的独立状态反应使用有限状态机器模式。

3.访问和业务控制模型：从安全和商业立脚点去捕获控制的水平和点允许服务管理是遵从具体的要求和标准。

这三种类型模型将被使用在服务管理流程的所有阶段。因为可以捕获服务管理框架的不同方面，这些模型都被选择使用。

定义服务管理活动的逻辑和信息顺序要求正式的不同水平的细节程度的流模型。

除了流程中活动的排序，通知各种服务管理活动和理财的目前执行状态。

服务管理的另一个维度是去确信所有适当的安全和商业控制政策及标准被模型化、嵌入在整个服务管理模型中。

这个框架中主要的模块是如Figure3和下边所示：

开发：它能承担一个特别服务的开发，包括服发现、服务创建和服务创作。这个服务是正常的响应被服务使用者通过服务管理模块的相互作用。

执行：所开发服务将贯穿绑定和部署，并最终被执行。它们互动使用服务管理模块用以下两种方法：接收开发服务和提供执行状态。

管理：管理服务要求捕获服务从头到尾生命周期，从来自各方用户的服务请求到服务的传送，包括正在传送的执行。

3.4一个模型驱动的方式

关键问题是如何使用正式的模型去支持以上三个模块。为此，我们进一步研究每个模块和他们的底层模型支持。如同之前讨论的，三种类型的正式模型将被使用在包括流模型，有限状态机模型和业务控制模型。

为了支撑服务管理，需要捕获创建新服务或更新已经存在的服务的请求。在这个框架下，我们应该为服务创建和执行过程使用流模型去描述进程和活动。所以，一个流模型可以被创建去记录整个生命周期中具体的步骤，以便不同的活动可以被适当地开始，结束和协调。通过这样做，当请求被接收，模型就会被创建，模型将筹划出服务生命周期必要的步骤。下面的示意图说明了由于这个原因一个典型的流模型：

在每个服务请求的收到后，以上流模型的实例将被请求并执行以处理服务请求的实现。根据需要，其他的模块将被启动去完成适当的任务。

除了流模型之外，服务管理的支撑可能也要求一个FSM去管理和跟踪一个特别的服务创建或执行的状态。当一个服务被执行，管理模块可能需要保持跟踪执行的精确状态。

通过结合流模型和FSM模型，它将被精确地使用去处理服务状态报告或精确的问题识别。例如，当一个问题发生时，它或许首先从独特的错误状态或来自服务用户的报告被查明。然后，流模型被服务关联将被取回，并且在FSM模型中的失败的状态将被流模型中相应的处理活动所关联。这将有助于辨别精确的失败步骤和通过检索并搜寻相应日志信息发现可能的原因。

为了完全支撑服务管理模型，开发相关的安全和业务控制模型是非常必要的。这样的模型可以通过相应的访问和控制政策以及精确的流程控制请求的模型去建立。

4.一个例子

本来讨论的服务管理框架提供了一个模型驱动的方式去有效地处理各种问题，管理服务开发和执行的整个流程中相关的问题。为了更好地说明这个框架的关键概念，我们将在这个章节讨论一个例子。

考虑一个服务于企业和合作伙伴的各种商业交易的企业网关。在这个网关中，所以的功能作为一个服务被实现，并且内部或外部服务商提供。网关的总体结构使用项目的示意图展示：

更具体地说，企业网关包含贸易伙伴，内外和外部的服务提供商。在这个例子中，我们假设它打算去发送一个PO到合作伙伴的后台实现系统。这个企业发现外包它的B2B连接和信息格式翻译给一个外部服务商更加经济。还有维护服务访问和业务控制以及在内部的服务控制和后台沟通。所有的这些功能都还没有被当作服务而实现。

为了管理这个服务，当贸易伙伴请求如此的一个服务时调用如图5所示的服务流模型。然后在框架开发阶段，有必要通过服务发现与整合去实现一个用于B2B交易的流模型。因此项目的流模型将首先被定义：

尽管sendPO交易服务可以使用以上的流模型描述，但是因为它包含了几倍的服务商，这些服务商的执行环境依赖于其他的服务商，所以它并不是一个简单的可以被执行的流模型。所以有必要描述交易状态通过FSM模型。sendPo交易的每个状态的改变将被发送给服务管理模块，这些服务管理模块导致相应FSM的状态交易。

通过结合以上的流模型和FSM模型，管理模块可以精确地监控交易的过程并且消除在交易期间

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[150754]，资料为PDF文档或Word文档，PDF文档可免费转换为Word