理论计算机科学电子笔记189（2007）35-50www.elsevier.com/locate/entcs基于服务上下文一致性判定的Marcel Cremene1DEP.克卢日-纳波卡通信技术大学罗马尼亚克卢日-纳波卡米歇尔·里维尔2实验室I3S，方程式Rainbow，CNRS Universit'edeNi ceSophia-Antipolis，法国克里斯蒂安·马特尔3实验室SysComUniversit'edeSavoieChambery，France摘要自主适应是一个非常雄心勃勃的新兴领域，旨在建立自适应系统。 这些系统最重要的优点是：更容易的复杂性管理，自主服务演化和主动行为。在“经典”服务自适应系统中，开发人员必须“手动”解决两个问题。第一个是先验地确定每个可能的上下文的服务充分性。 第二个依赖于第一个，它是指定一个战略，一个重组套件，它将把一个不充分的服务变成一个充分的服务。为了取代基于开发人员的推理与基于机器的，我们提出了一个元模型描述的服务和它的上下文到一个共同的图形表示。 应用于该元模型的一组通用规则和操作符使机器能够检查服务是否适合其上下文。相同的元模型用于搜索自适应策略。保留字：自主，适应，服务，语境，可理解性，元模型1 电子邮件地址：cremene@com.utcluj.ro2电子邮件地址：riveill@unice.fr3电子邮件：christian. univ-savoie.fr1571-0661 © 2007 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2007.05.04636M. Cremene等人/理论计算机科学电子笔记189（2007）351介绍1.1背景我们今天生活在一个计算/电信基础设施和在该基础设施之上运行的软件服务越来越普遍和多样化的世界我们认为服务是由互连组件（有时也称为服务）组成的分布式架构实现的可重用组件可以由不同的提供商不断发布、升级和删除。我们认为服务a. 基础设施相关部分包括可用资源和可能影响该基础设施的元素，例如，无线网络吞吐量可能会受到雨水的影响。b. 用户相关部分包括用户需求和可能影响这些需求的因素，例如，可能改变用户兴趣/需求的某些对象的接近度动态服务适配意味着重新配置执行中的服务，以使其更适合其上下文。根据我们的服务定义，重构原语包括：添加、替换、删除、参数化、迁移组件和连接/断开组件端口。在“传统”自适应系统中P1. 先验地确定每个可能的上下文状态的服务充分性。通常，这个问题是使用一些规则和条件来测试一些上下文属性。P2. 制定一项战略，将不适当的服务转变为适当的服务。策略是一套重构原语。第二个问题取决于第一个问题。因此，在本文中，我们特别坚持这第一个问题，我们提出了第二个问题的一些部分解决方案1.2问题事实上，开发人员必须“手动”解决- 复杂性/成本高基础设施、服务以及用户需求都在不断多样化。日益增加的复杂性成为开发人员/管理员的一个重要问题，[13]中也注意到了这个问题。如果上下文包含大量具有许多属性的元素，并且我们有一个具有许多组件的服务，则确定服务对上下文的充分性可能导致组合爆炸。此外，开发人员还必须解决可能的规则冲突。- 无法完全预测上下文/服务的演变。 在开放的环境中-M. Cremene等人/理论计算机科学电子笔记189（2007）3537在移动系统[7]中，不可能预测在给定时刻将影响服务的所有上下文元素/属性。与其让服务只提供服务开发人员预期的功能，我们可能更愿意让主动服务能够发现并向用户建议新的、未预期的功能。此外，仅使用先验定义的组件的服务不能使用在其创建后发布的新组件- 后验的非理性干预。对于某些分布式服务来说，开发人员在服务创建后进行干预可能是不可能的，因为它们无法停止（没有一些重要的成本），或者可用于重新配置的时间太短。在这种情况下，用一些自动解决方案来代替开发人员的干预是很有用的。1.3总目标前面描述的问题有一个共同的原因：只有服务开发人员才能理解服务S是否适合给定的上下文C，并决定应用什么策略。我们的目标是用“智能”算法取代之前描述的开发人员的工作。该算法将能够自己确定服务和上下文之间的适当性。一旦这个问题得到解决，策略搜索就成为可能，因为我们可以生成任何服务上下文配置并检查其充分性。1.4方法为了使基于机器的推理的服务充分性的上下文，我们提出了一个服务上下文元模型。 这个元模型使用一个通用的图表示来描述：服务，上下文和它们的交互。所提出的元模型将用于适应平台的控制部分。元模型必须随着上下文和服务的变化而动态地扩展/更新，它必须在每个时刻都反映关于服务和上下文的知识1.5文件纲要本文的组织如下：下一节介绍了几个现有的自适应系统;第三节介绍了服务上下文元模型，它是如何使用的，最后它在自适应平台架构中的位置第四部分描述了一个简单的原型，我们已经实现，以测试我们的模型。最后一部分是对本文的评价、结论和未来的工作。2可靠的解决方案、局限性和可重用方面在本节中，我们将分析一些具有代表性的自适应平台。根据我们的目标，主要的问题是：它是如何确定的服务充分性的上下文？如何制定适应战略？开发者的角色是什么？38M. Cremene等人/理论计算机科学电子笔记189（2007）35我们也有兴趣分析自适应平台架构是否适合我们的目标，以及这些架构中可以重用的元素是什么。为了避免可能的混淆，在本文中，我们使用2.1自适应平台示例第一个有趣的例子是加兰等人该平台架构基于适配部分（服务）和适配部分（探测器、控制器、触发器）之间的分离。使用规则和策略来控制适应例如，该规则指示何时必须应用特定策略，并指定要执行的特定策略一个规则示例是：此策略指定位置（服务器组）以及要重新配置的内容（添加新服务器）。该策略本身包括一些其他规则（分离规则/策略不是很强）。必须存在addServer（）方法才能使适配成为可能。上下文的服务充分性由规则给出;适配解决方案是应用特定的策略。 我们可以观察到，规则和策略是：开发人员制定的，预先定义的，并且它们是特定于服务和上下文的。要考虑新的上下文元素，需要添加至少一个规则或策略。确定服务对上下文的充分性和策略搜索，是开发人员制定的任务。一些作者讨论了“意料之外的适应”。根据J. Keeney [11]的说法，在一个作者提出了支持动态规则修改的“Chisel”平台。让我们分析以下示例：关于WirelessNetworkDisconnectNetworkConnectionService.WiredConnectionBehaviourIF（NetworkConnectionService.WiredConnectionAvailable ==TRUE&&WirelessNetworkDisconnect.IsTemporary == TRUE）||（UserPreferences.getPref erre dCom ms（））.c ompa reT o（“W ireless“）！= 0该规则是，如果无线网络断开连接，则应用策略“Wired-ConnectionBehaviour”，但仅当有线连接存在并且无线断开连接不仅仅是暂时的。自适应技术基于相应的语言支持，这里不再详述。我们可以观察到，即使这些规则可以在运行时改变（如作者所声称的），策略仍然是预先定义的（即“WiredConnectionBehaviour”策略），并且来自上下文的事件也是预先定义的（即“WirelessNetworkDisconnect”）。另一个不便之处在于，添加新规则需要开发者干预，因为用户通常不能编写这种复杂的语法或处理不同规则之间的可能冲突。基本上，我们在这里遇到了与“Rainbow”平台相同的限制M. Cremene等人/理论计算机科学电子笔记189（2007）3539自主计算[13]是一个非常有趣的新兴领域，具有很高的野心。IBM有一个部门专门负责这方面的工作。他们创建了这个工具包带有一个受生物模型启发的通用架构：神经探针，大脑控制器和肌肉电子传感器。重新配置决策基于日志消息，但没有给出通用解决方案，自适应控制是特定于服务的。我们还没有找到一个解决方案，允许自动确定服务的充分性，其上下文。事实上，我们今天没有一个真正完整的解决方案，自主适应，而是围绕这个问题的几个建议。K. Fujii在[9]中提出了一个名为“CoSMoS”的语义组件模型和一个名为“SegSeC”的平台。所提出的平台能够自动部署基于组件的服务，只从用户的需求（这是表示为自然语言句子）。其主要思想是在构件模型中加入语义概念，然后利用本体和语义图在语义相关概念所描述的构件/服务之间建立联系。这个想法很有趣，因为它提供了一些自主性：服务的组装不需要开发人员的干预。然而，该平台的一些限制是：服务在部署后不能动态地重新配置，唯一考虑的上下文是用户需求，用户需求必须足够简单，并且必须遵守一定的语法（单词顺序）。这个建议仍然没有对服务和它的上下文之间的充分性确定问题做出一般性的回应在研究了其他一些平台，如：”K-component”- 平台架构。主动自适应平台一般有三个主要部分：a）具有一些可重构元素（参数）的自适应部分（服务），b）定期监视上下文和服务状态的观察部分（探针，传感器）和c）使用规则和策略的控制部分最常用的原理是经典的闭环，它类似于人类神经系统模型。- 控制部分。平台控制部分基于服务和特定于上下文的规则/策略，这些规则/策略由开发人员预先定义。添加新的上下文元素/属性需要人工干预，特别是因为不是平台而是开发人员能够推理服务到上下文充分性。2.2平台评估在所分析的平台中，我们还没有发现自动解决方案的服务上下文充分性的判断。然而，我们可以重用一些元素，例如：适配平台的闭环原则，适配技术（如响应式中间件），上下文发现解决方案[4]，向组件模型添加语义信息的想法为了支持自主自适应，自适应平台中唯一必须进行重大更改的部分是控制部分。40M. Cremene等人/理论计算机科学电子笔记189（2007）35我SU3建议的自主适应本节以“自下而上”的方式组织3.1什么是服务上下文元模型？服务上下文Meta模型描述了以下方面：S -服务，I -基础设施，IC -基础设施上下文，U -用户，UC -用户这些部件如图1所示连接。Fig. 1. 服务上下文元模型，一般结构服务直接与其基础设施I和其用户U交互。基础结构受其上下文IC的影响，并且用户也受其上下文UC的影响。根据引言中给出的上下文定义，上下文C ={ I，IC，U，UC}。我们有两种类型的一般相互关系：- 信息交换关系涉及S-U相互作用。用户通过HMI（人机接口）与服务交换信息，组件也彼此交换信息- 资源利用关系涉及S-I相互作用。该服务使用一定量的基础设施资源（即内存、带宽等）。服务模式服务元模型将服务体系结构描述为具有作为节点的组件和作为弧的互连的图，类似于ADL（体系结构描述语言）描述。我们观察到，“管道-过滤器”的视角极大地简化了我们的模型，而没有限制它。过滤器有一个输入和一个输出，接收器只有一个输入，源只有一个输出。具有多个输入和多个输出的复杂组件将在Meta级别上表示为分解为多个不同的过滤器/源/汇。上下文模型目前，上下文使用不同的模型类型表示：属性列表，面向对象的模型，基于本体的模型[15]，上下文图[2]。为了有一个共同的模型，我们建议使用相同的模型的上下文和服务。这意味着，上下文也被视为由相互关联的上下文组件组成的架构：用户，终端，网络，环境等。ICUCM. Cremene等人/理论计算机科学电子笔记189（2007）3541普罗菲莱斯一个问题是，实际的服务和上下文模型并没有揭示服务-上下文的相互关系.为了解决这个问题，我们引入了轮廓的概念。轮廓的作用是描述组件，并显示它们如何相互作用。概要文件是与组件、软件或上下文相关的元数据（XML文件）。描述一个过滤器的基本要素是：- 类型. 类型可以是软件、上下文或观察者。观察者是一种用于服务和上下文观察的特殊软件组件，它提供关于其他服务/上下文组件的信息。- 组件属性。组件属性与整个组件相关。这些属性的例子有：内存、CPU、API、OS，它们通常与物理和逻辑资源相关。每个属性都有一个名称和定义域（值）。- 流属性。流属性与进入或退出组件端口的输入和输出信息流相关。这些属性表征了信息内容。一些例子是：数据类型，语言，压缩，延迟，比特率。每个属性都有一个名称和一个定义域。对于每个属性，我们定义一个传递函数H，就像对于电滤波器一样。此函数指示特定属性的输出值和输入值之间的关系H函数可以具有与组件参数相关联的参数。如果H关系不能被先验地知道，它将被标记为未知（我们使用特殊符号每个复分量可以分解成几个滤波器。例如，从'account-ory'属性的角度来看，终端被视为内存源，而组件则英语到法语的翻译组件是一个记忆池，但也是一个语言过滤器。组件开发人员必须始终指定组件配置文件;否则适配平台无法了解组件功能。情景和说明为了便于模型的解释，我们建议将其应用于一个具体的场景。此场景基于论坛服务。论坛架构由客户端和论坛服务器组成，客户端本身由消息编辑器TreeViewUI和消息编辑器EditorUI组成。该服务图2说明了此场景的服务上下文涉及到几个上下文组件：通过HMI与论坛服务交互的用户，包括两个组件的终端：作为输出设备的显示器和作为输入设备的键盘终端设备介于用户和软件组件之间。终端屏幕可视性可能会受到外部因素的影响，例如外部光线。网络将终端与互联网接入点连接，并最终与服务器连接42M. Cremene等人/理论计算机科学电子笔记189（2007）35外部光T、存储器RAM、CPU、操RAM，CPU，HD，客户端TreeViewUI论坛服务器编辑器UI图二、服务上下文模型-体系结构说明机可以连接多个网络。上行链路和下行链路被视为分离的滤波器。网络比特率可能会受到外部条件（例如下雨）的影响。服务器机器是论坛服务器的主机（我们可以考虑这个上下文组件来进行负载平衡）。以图适配平台将服务上下文元模型作为图进行操作图3中描绘的图对应于图4中描绘的架构。二、为了简化图表，与图2相比，我们省略了一些元素。图形节点对应于软件（白色）和上下文（灰色）组件。观察者组件没有包含在这个图中，但我们使用它们来更新它。节点是一个包含所有profile属性的对象：组件属性，流程属性和传递函数。图中的弧是定向的，对应于信息流（正常箭头）或资源利用率（虚线箭头）。你，视图T、显示TreeViewUINet.（向下）论坛服务器你，手T、钥匙编辑器UINet.（上）图三. 以图3.2我们如何确定服务上下文的充分性？为了形式化“适当性”的含义，我们认为适当性可以是真的或假的。根据前面定义的相互关系类型，我们表达了一个一般的充分性规则：真实性=真M. Cremene等人/理论计算机科学电子笔记189（2007）3543C1C2属性：XD_out属性：XD_in如果对于任何两个互连的滤波器Ci -> Cj，Ci输出值包括在Cj输入区间中和对于每种类型的消耗资源，提供的同类资源的价值更高信息流相关充分性规则的第一部分涉及信息流兼容性，第二部分涉及基础设施资源兼容性。对于论坛服务，如果用户（上下文组件）产生具有“language”属性“FR”的信息，但服务输入需要相同“language”属性的值“EN”，则我们决定此服务不适合其上下文。图4说明了信息流兼容性的概念。见图4。 流动相容性信息流直接通过互连进行循环（但可以通过过滤器进行修改）。对于每个属性，链效应由链中每个滤波器的传递函数的数学组成给出（函数H在组件配置文件中指定）。如果一个过滤器配置文件没有指定一个属性，我们假设过滤器没有指定该属性，并且其输出值等于其输入值。一个未指定的函数H等价于恒等函数，这允许我们组合函数。如图所示，≡图五. 组件链组成在图5中，由两个组件C1（翻译器）和C2（归档器）组成的链等价于组件C3 = C1 oC2（合成）。C3配置文件可以自动计算，并包含C1和C2配置文件的所有属性。符号“*”表示任何值，符号“？”表示未知值。可以使用专门的组件、观察器（即语言检测器）来检测未知值。链流属性由每个过滤器的所有流属性的重新组合给出。如果两个过滤器选择相同的属性（由C1C2language：简体->类型：大小：C3 =C1oC2语言：类型：大小：44M. Cremene等人/理论计算机科学电子笔记189（2007）35他们的profiles），我们使用标准的数学函数组合，以确定链全局传递函数。信息合成是用于电滤波器链的模拟信号合成。与结构相关的充分性如果一个服务不需要比现有资源更多的资源，那么它就适合于它的上下文（物理基础设施：终端、机器、网络）资源的性质例如，如果TreeViewUI（参见图3）占用100KB内存，EditorUI占用300KB内存，那么这两个组件将需要至少400KB。正如我们在3）中看到的，这两个组件消耗终端内存T.memory。如果可用的终端内存低于400KB，我们有一个不足。在某些情况下，资源利用率不符合简单的加法关系。例如，两个视觉组件可以同时或连续地显示在同一显示器上。在这两种情况下，所需的屏幕表面是不同的。为了使开发人员能够表达不同的情况，我们可以使用不同的组合和验证操作符，而不仅仅是加法和劣性操作符（见图7）。属性定义和操作符必须由所有组件开发人员共享，以便能够集成由不同开发人员开发的组件。3.3如何找到正确的适应策略？找到一个适应策略就是建立一个将被应用的重构原语列表有两种类型的决策是必要的：a）决定重构类型（替换、插入、移除、迁移、参数化）和b）决定将什么组件/互连重构到现有的服务上下文系统中。所提出的元模型并不能解决策略搜索问题，但它允许我们生成不同的服务上下文配置并检查它们的充分性。我们在下面给出了一个简单的例子，展示了元模型如何帮助我们找到一个策略。例如果不足是由信息流不兼容引起的，一个通用的解决方案是插入一个额外的过滤器，它的作用类似于适配器。 译者两个组件（软件或上下文）之间的适配器“说”不同的语言。必要的组件是通过其轮廓来搜索的：所搜索组件的输入/输出函数必须解决不足问题。插入点通过验证概要文件和语法接口（IDL）兼容性来搜索。正如我们在图6中看到的，图模型使我们有可能遵循信息流。在论坛的情况下，一个新的语言翻译过滤 器 可 能 会 被 插 入 到 EditorUI 输 出 之 后 （ 如 果 在 终 端 上 存 在 ） ， 或 者 在ForumServer输入之前（如果翻译器是一个远程Web服务）。相同的思想可以用于服务输出：第二翻译组件可以M. Cremene等人/理论计算机科学电子笔记189（2007）3545安必恩光T、存储器‘language’‘language’在ForumServer输出之后插入。正如我们所看到的，该模型使我们能够区分用户你，视图T、显示TreeViewUINet.（向下）论坛服务器你，手T、钥匙编辑器UINet.（上）图六、搜索与流程相关的不足之处的解决原则上，如果满足以下两个条件，则可以在过滤器链的任何点插入新的过滤器：a）IDL（接口定义语言）兼容，b）它不会因其自身的特性而造成新的不足。如果满足相同的条件，则可用另一个过滤器替换现有的过滤器。作为一个观察，服务重新配置不是适应服务上下文系统的唯一方法。在某些情况下，系统可能会建议用户自己做一些事情，使服务上下文系统进入适当的状态，例如，将其终端移动到具有更好网络覆盖的地方3.4我们如何使用和扩展元模型？控制部分（图7）使用一个公共定义的、独立于服务的表，该表包含属性定义和用于组合和验证的运算符。这个表必须由人类操作员创建，其想法是为所有服务提供唯一的定义。此外，组件开发人员在描述概要文件时必须遵守概要文件属性名称。组件配置文件更新见图7。 轮廓属性定义每个组件都必须有一个概要文件，这意味着组件开发人员必须尽可能完整地描述该组件组件简介服务执行平台控制器：- 轮廓验证算法- 策略选择- 策略应用与解决方案搜索语言{FR，EN，.. ？，*}：==存储器最大+
下载后可阅读完整内容，剩余1页未读，立即下载
