《2010.2-8=从软件服务组合到软件服务自主协同》由会员分享，可在线阅读，更多相关《2010.2-8=从软件服务组合到软件服务自主协同（6页珍藏版）》请在金锄头文库上搜索。
1、专栏第 6 卷 第 2 期 2010 年 2 月64从软件服务组合到 软件服务自主协同关键词：软件服务曹健上海交通大学服务概念的引入长久以来，“服务”这一词汇被广泛用 于社会生活。然而在不知不觉中，服务这一概 念逐渐登上了信息技术领域的舞台，有些场合 还占据中心地位。服务呈现出各种形态，表现 为硬件服务、平台服务、软件服务、万维网 （We b）服务以及网格服务等等。尽管有时我 们还会对这些形态产生一些困惑，但是它们已 经成为了现实。 推动服务走上前台的是计算技术本身的 发展。在技术发展的早期，应用这些技术需要 许多专业知识，迫使业务必须去适应技术。然 而，随着硬件、软件和网络能力的提升，应用
2、的关注点重新回归业务本身，技术已经变得或 者需要变得“看不见”。这时，技术的作用就 以所谓的服务形式表现出来，因而，服务实际 上是从业务角度看待技术。过其动态发现和调用使跨企业的动态业务协作 变得易于实现。软件服务在万维网的变革中也 扮演着重要角色，它促使万维网从信息共享的 平台进化为功能共享、资源共享的平台。许 多时候，硬件服务、平台服务也通过软件服 务得到体现，例如，通过万维网服务可以获 得亚马逊（Amazon）的EC2（Elastic Compute C l o u d ，弹性云）和S 3 （S i m p l e S t o r a g e Service，简单存储服务）1。软件服务组
3、合对于用户而言，某些时候单项的软件服 务可以提供有价值的业务功能。例如，天气 预 报 就 是 一 项 用 户 能 够 直 接 访 问 的 原 子 服 务，而某些协议如W S U I2等也使终端用户直 接访问单项服务成为可能。但是，实际 上大 多数功能相对单一的原子服务是无法 满足用 户需求的，这时，必须依靠一组服 务相互协3软件服务作才能达到目的 。因此，将多个服务组合起为了更好地支持业务实现，软件的服务化 也包含了一系列新的概念和技术进步，例如标 准化的服务描述、服务发现、服务动态调用和 服务组合等。软件服务化给多个领域带来了诱 人的前景：可使企业的应用集成建立在开放的 标准上，组件的封装性
4、增强，耦合性减少；通来形成功能更为强大的服务（复合服务）， 就成为目前信息技术领域的一个研究和开发 的热点。 对于软件服务组合，工业界已经提供了 相应的解决方法。借助于工作流领域的研究成 果，工业界制定了一些协议，如用B P E L4W S（Business Process Execution Language for Web第 6 卷 第 2 期 2010 年 2 月65S e r v i c e s，网络服务业务流程执行语言）4、 BPML（Business Process Modeling Language， 业务流程建模语言）5来显式定义服务之间的 逻辑关系和数据关系，从而形成一项复合
5、服 务。此外，这些协议还考虑到异常处理和补偿 机制，增强了软件服务组合的可用性。工业界 的解决方案固然能够聚合单独的服务形成功能 更加强大的服务，但是这些协议或多或少更像 一种编程语言，依靠它们还无法完全实现软件 服务的前景。为此，学术界在这一领域开展了 许多研究工作。为了增强服务组合的灵活性，我们先定义 一个独立于具体服务的服务过程。当创建服务 过程实例时，依据具体的场景为每一个活动选 择相应的服务，进而构成一个复合服务。一些 规范比如O W L-S6也为此提供了技术基础。在 M E T E O R-S万维网服务复合框架中，过程中的 各个活动可以定义为某一万维网服务实现、服 务接口或者语义模
6、板。它们在运行时可以依据 需求为这些活动选择服务7。各种服务查找的 算法89可以运用到那些选取的服务上。尽管这 种方案的灵活性与固定的服务组合相比在一定 程度上得到了提高，但是固定的服务过程结构 还是限制了其功能的适应性。从理想的角度看，软件服务组合就是依 据输入的需求，在由软件服务构成的空间中建 立一条执行路径。显然，这一问题对于学术研 究具有挑战性，因而极大地吸引了研究者的兴 趣。目前许多方法是通过人工智能中的规划和 推理技术实现服务的动态复合1016，研究者采 用了包括基于图的计算方法14、基于线性规划 的方法1213和基于约束求解1516的方法等对问 题进行求解。尽管自动服务组合在学术
7、界十分受关注， 但是这种方法在实际应用中面临着诸多的限制： 服务数量庞大 例如万维网服务搜索引擎 seekda!（）上收录的公 开的万维网服务数已经超过了25000个，而且数量还在不断增长。在这样庞大的空间中进行 搜索，是十分困难的； 查找服务依据的是功能需求、接口需求 和质量需求 目前，网络服务描述语言（We b Services Description Language，WSDL）和 SAWSDL（Semantic Annotations for Web service description language and XML Schema）17分别 提供了接口定义和基于语义的接口定义，而
8、对 高层功能的直接描述和质量，特别是在软件服 务所代表的领域服务质量（例如天气预报服务 提供的天气预报的准确性）的刻画方面，还欠 缺有效手段。即使这些描述已经达成了统一的 标准，描述的可信性依然是一个复杂的问题； 由于服务提供者具有独立性，因此各项服 务 的变化并不受那些引用它们的复合服务的制 约 当某一服务发生变化时，复合服务的受影 响程度无法预知。因此，一个复合服务的生命 周期也许非常短暂，这对于利用复合服务的系 统而言是一种显著的风险。 面对上述问题， 我们一方面需要继续从 研究的角度进行深入探索，以期提供解决的方 法；另一方面，也要从技术实现的现实性角度 进行考虑。从这一点出发，我们需
9、要对服务过 程在服务组合中的地位进行重新认识。 既 然 服 务 过 程 是 一 种 从 业 务 角 度 对 业 务流程的抽象，因此它提供了一个间接层 （Indirection），从而可以把业务逻辑和具体的 服务实现进行解耦。由于业务模型具有相对通 用性，因此与服务实现相比，它也是相对稳定 的。这种相对稳定的特点使得服务过程可以成 为软件服务组合中的业务领域模式或者模板。 服务过程的这种特点已经开始为学术界和 工 业界所认识。通过对服务过程模型的实例化 （为活动匹配服务），可以生成具体服务组合 方案，然而，这些做法还不能充分体现服务过 程的独特地位。我们可以在以下4个方面进行 深化研究： 第一，
10、既然服务过程具有普遍性，那么它专栏第 6 卷 第 2 期 2010 年 2 月66的共享就很有意义。对于一个服务过程，特别 是抽象的服务过程，其语义表示显然与单项软 件服务的表示不同，而表示一个服务过程特别 是抽象的服务过程的质量则更加困难，以此为 基础实现的服务过程发现方法也与软件服务不 一样。我们初步研究了通过目标语义对服务过 程进行语义标注和查询的方法18。这方面显然 还需要研究更为合理和完整的方法； 第二，业务环境的动态性要求业务过程具 有高适应性。虽然通过为活动选择服务增加了 服务过程的适应性，但是，服务过程的结构又 给适应性带来了制约，因此，如何平衡通过结 构服务过程定义带来的问题
11、简化和灵活性降 低是值得深入探讨的问题； 第三，业务模型的相对稳定并不意味着业 务过程的一成不变。一方面，新的业务模式不 断推出，新的技术也将推动业务模型的革新。 事实上，在现在动态的业务环境中，业务过程 模型正在承受越来越快的变化需求。虽然新的 模型可以重建，但是原有模型作为一种资产， 也应合理利用；另一方面，业务过程模型的变 化在许多时候表现为一种渐变性，即从原模 型 上的小变化开始（对原来模型的修改）， 直到 原来的模型不再可用之后产生新的模型。 按照 这一思路，我们初步试验了基于规则挖 掘的方 式实现模型的演化19。在共享业务过程模型的 基础上，如何结合We b2.0的思想实 现过程模
12、型 的有序演化具有研究价值； 第四，考虑到服务过程模型的多层次特 性，一个服务过程模型中的活动可以链接到一 个或多个其他的服务过程模型，因此，服务过 程模型之间也形成一种网状结构。在开放的万 维网环境下，对服务过程模型之间的层次链接 关系进行刻画并考虑它们的应用尚待探索。软件服务自主协同无论基于何种具体的方法，软件服务组合一般采用的都是集中式体系架构，即由一个中 央节点掌握所涉及的服务的信息和知识，因而 可以采用特定的方法去完成服务的组合。这种 “全知”或“全能”节点的假设带来方便的同 时，也相应地带来以下不足： 第一，针对特定的需求，服务组合节点 需要去查找匹配的服务。如果这种查找发生在 整
13、个开放的网络环境中，其计算量就会非常庞 大，即使能够快速找到服务，如果是初次使用 该服务，它的质量难以确信；简化上述问题的 一种方法是让服务组合发生在特定的经过事先 筛选后的服务集合上，显然，这种建立在封闭 系统上的方法将难以真正满足现实中不可预知 的需求； 第二，由于服务提供者的相对独立性，使 得服务的变化不可控，这次成功应用的服务未 必下次依然可用；新的更好的服务也会不断出 现。当然我们可以去跟踪服务的状态或者动态 维护相关的服务集合。不过，这种工作耗费大 量的资源，服务组合节点难以应付； 第三，为服务流程的活动选取服务需要专 业化的知识。尽管语义手段等应用为服务匹配 提供了通用的方法，但
14、是如果将领域质量等因 素考虑在内，服务的选取需要专业化的领域知 识。考虑到服务空间的动态性，需要这种知识 能够扩充和演化，依靠中央节点去管理这种知 识是难以满足要求的； 第 四 ， 服 务 之 间 本 身 存 在 局 部 化 的 联 系，伴随着服务的动态变化，局部化的联 系 也在发生变化。这种局部联系可以为形 成服 务组合方案提供帮助。由于联系的普 遍性， 很难用一个集中的数据库去保存和 维护这种 局部化的联系； 第五，如前所述，软件服务代表的是从 业务角度看待的软件组件，因此现实中的业 务模型对于软件服务而言同样具有意义。在 现实中，企业之间通过联盟建立互信、合作 机制，可以控制业务成本、降
15、低业务风险和第 6 卷 第 2 期 2010 年 2 月67提高服务质量，现有的服务组合无法体现这 种业务模型。 不难发现，解决上述问题的思 路是将处理 分散化或者让服务自主化，依靠软件服务之间 的自主协同去适应连续变化、不确定和开放的 业务环境。 事实上，工业界已经注意到这一需求，例 如服务事件规范（W S-E v e n t i n g）20和服务协 调语言（Web Service Choreography Description Language，WSCDL）21都与此相关。但是， 这些规范和协议并没有对上述问题提供根本的 解决方法。 为了使软件服务具有自主协同的能力， 一个自然的选择就
16、是软件服务的A g e n t （代 理、本体或智能体）化，或者A g e n t 的服 务 化，因为A g e n t 具有的自治性、社会性、 反 应性和主动性22等特性，这些都是软件 服务 目前所不具备的。事实上，许多研 究者认 为，将A g e n t 技术与万维网服务相 结合，代 表了未来万维网服务的发展方 向。例如， 胡恩斯（H u h n s）认为未来的 万维网服务就 是A g e n t 2 3 。正是认识到这一点，目前有不 少研究正在将A g e n t 和服 务技术相结合。例 如，Agent方面的研究组 织FIPA（Foundation for Intelligent Physical Ag
