用户上下文感知：高科技仪器的远程控制框架

理论计算机科学电子札记146（2006）17-32www.elsevier.com/locate/entcs支持用户上下文的复合Web服务提供高科技仪器Christophe GRAVIER1法国圣艾蒂安大学SATIn集团DIOM实验室雅克·法约尔2法国圣艾蒂安大学SATIn集团DIOM实验室摘要本文旨在为高科技仪器的远程控制提供一个完整的、独立于平台的框架。这是由实体之间共享资源（本用例中的工具）的想法引起的，每个实体当然都利用自己的信息系统。主要地，为了足够通用以满足所寻址的资源的相应通用性，共享必须在一定的约束下进行，这些约束是安全性、可扩展性、认证、“实时”访问、多平台和多用户访问。 本文的目的是讨论Web服务作为这种通用框架的骨架的可能用途，以及根据使用的上下文（即，关于用户在会话中扮演的角色http://www.istase.com/satin/eINST.html网站。关键词：用户上下文感知，安全性，可扩展性，电子实验室，电子仪器，计算机支持的协同工作-CSCW，复合Web服务，面向消息的中间件。1电 邮 地址：christophe. univ-st-etienne.fr2电 子 邮件：jacques. univ-st-etienne.fr1571-0661 © 2006 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2005.11.004C. Gravier，J.Fayolle/Electronic Notes in Theoretical Computer Science 146（2006）17181引言科技研究对高科技资源的需求是不可否认的。人们普遍认为，许多研究主题需要获得特定的高科技仪器，以便进行一些实验和/或验证其结果。然而，实验室通常无法订购他们认为必要的此外，可能有一个准时的需要，这将不会证明投资，但这将是一个很好的观察理论范式解决，如果研究人员被授予一个单一的访问特定的工具。这种实验室环境可以我们的建议是提供一种高科技资源的远程控制机制，以便在实体之间共享它，• eLaboratories领域的研究人员• Companies’ employees• 学生，在具体的实践活动中使用该仪器作为教学法的支持。我们建议的要点是提供一个通用框架，依赖于控制资源的本地接口，以满足研究/公司和教学需求。我们的目标是支持客户端和传统或/和本地接口之间的实时通信由于所控制资源的性质，这必须在强安全环境下进行请注意，安全性不仅包括完整性，还包括可用性和健壮性。本文的目的是澄清Web服务如何帮助这样一个框架的阐述。限制因素很多，覆盖了很大的兴趣领域，例如• 安全作为一种资源，在未经许可的情况下，不得被监听、破坏或使用，• 应用程序群体意识，以协同访问仪器（计算机支持的协同工作），• 通过用户使用Web服务的上下文适应用户• 可扩展性，因为可能同时涉及的潜在工具和用户很重要，• ”Real-time” Asynchronous Middleware ”Asynchronous” has to be 这意味C. Gravier，J.Fayolle/Electronic Notes in Theoretical Computer Science 146（2006）1719”receive”• 多平台，因为访问仪器的人来自许多不同的来源，如前所述（研究人员，公司员工或学生）。• 记录对资源的所有访问（成功和不成功）的历史在这里，我们专注于Web服务的实用性和可用性，作为我们的通用框架的解决方案，更特别的是，根据上下文（即时间和手段，他们正在使用的资源）的用户服务的适应为了支持我们的目的，我们将首先讨论我们框架的设计步骤。这意味着我们将解释为什么以及如何考虑将Web服务作为解决方案的潜在基础然后，我们将重点关注用户角色及其与上下文的适应性（目的是提供适应用户上下文的Web服务在这些解释之后，我们将把我们必须支持的所有约束都放在Web服务行为上，看看它是否最后，我们将提供一套完整的插图，其中Web服务为基础的框架可以采用。最后是本文的结论和后续工作。2带有一个Web服务的基本框架从功能上讲，最难提供的功能可能是对多用户活动的支持事实上，一种通常被接受的设计计算机支持的协同工作（从现在开始称为CSCW）的方法，包括在[4]中解释的两个主要思想中。(i) 协作透明：看起来是协作的（环境是共享的）(ii) 协作感知：协作（应用程序本身是共享的）正如[4]中所指出的，每种方法都有其缺点：第一，缺乏群体意识，第二，耗时。我们在这里的目的是支持使用[1]中描述的ObjectWeb Joram[9]实现的协作，特别是ObjectWeb Joram实现。通过这种方式，我们的目标是在访问仪器的应用程序层的顶部定位一个通用解决方案。我们可以说，我们不再是在情况i或ii，但我们正在提供一个完整的原始方法，包括分享3消息中间件C. Gravier，J.Fayolle/Electronic Notes in Theoretical Computer Science 146（2006）1720用户1Environnement用户1用户3用户2App 2App 1用户3办法（a）环境是共享的办法（b）应用程序共享EnvironnementApp 2App 1用户2Environnement框架消息代理框架端点用户3用户1用户2App 2App 1接口不仅指向单个应用程序，而且实际上指向同一感兴趣组中的若干应用程序，所述感兴趣组是同时访问仪器的应用程序组（协作访问）。该接口位于包含要访问的应用程序的环境与在其自己的环境中运行其自己的应用程序的用户之间下面的图1可以帮助我们在这里发展这个想法办法（c）为应用程序提供服务端点的框架图1.一、我们的CSCW方法：使用一个框架来支持协作访问我们可以在消息代理上添加一些文字。在这里，它被视为一个广泛的定义：消息代理是一个代理的心脏，因为他负责将消息传递给应用程序。当使用“发布/订阅”模式时，创建一个“主题4“，这是一个应用程序可以在其上进行通信的通信信道。当一个消息是在一个单一的主题，该消息是多播到所有的应用程序已订阅到频道。这与邮件列表的原理相同：如果有人向列表发送消息，则每个订阅的人都会收到该消息。在我们的体系结构中，消息代理（通过其消息代理）的目的是在用户的应用程序和本地控制资源的应用程序（本文用例中的高科技工具）之间传递消息这为我们提供了对主机主题是负责在面向消息中间件的“发布/订阅”模型中传递消息的结构C. Gravier，J.Fayolle/Electronic Notes in Theoretical Computer Science 146（2006）1721连接到仪器：如果用户1和用户2都想访问仪器，则每个命令将由路由器转发，响应将多播到用户1和用户2。我们的第一个想法是使用Web服务作为由于Web服务的端点应该可以用几种语言（如C或Java）来开发，并且由于Java（至少是Java虚拟机）可以在多个平台下使用，因此Java编码的Web服务及其端点都提供了对Java的访问，这本质上可以满足多平台的需求。图2给出了这种想法的说明，通过框架发送命令的步骤，图3说明了用户访问仪器的应用程序发送的响应图二、通过我们的框架向仪器发布命令图2给出了“命令消息”所经历的步骤。必要的步骤是，为了通过向仪器请求订单的消息绕过它们（我们假设有两个用户(i) 首先，用户“用户1”使用其虚拟地表示仪器的应用程序来向远程仪器请求命令。消息在此步骤中建立(ii) 用户1因此，消息是通过经典的SOAP序列化来管理的(iii) Web服务的实例创建基于MOM的消息（满足JMS5标准，我们选择Java作为框架的语言5Java消息服务：简单来说，这是所有基于Java的Environnement话题远程应用消息代理妈妈框架用户2仪器用户1WS发布终结点WS发布逻辑C. Gravier，J.Fayolle/Electronic Notes in Theoretical Computer Science 146（2006）1722Web服务使用特定的主题来发布消息。(iv) 最后，由于用户1为了避免这种不必要的网络请求，必须注意的是，主题结构允许过滤（有时称为选择器，取决于所使用的过滤器这样，可以保证只有远程应用程序将接收消息。（因此，在通过框架发送消息的步骤中，多播被简化为点对点通信）。一旦消息被传递到远程应用程序，连接到仪器的应用程序就启动了两个进程：• 对集团进行系统的评价。这有助于访问同一仪器的应用程序通知其用户订单已生成，并且此命令已正确传递到控制仪器的远程应用程序。此通知使用Web服务发布这样，用户• 处理接收到的消息，以便调用授予对仪器的访问的本机方法确认实际上是一个简单的回复：应用程序收到一条消息，因此它自动向组发出通知。此外，处理消息是更复杂的事情，因为它处理本机接口。然后，它必须将响应多播到组中响应与命令消息的发送对称，如图3所示(i) 完成请求的操作后，远程应用程序使用Web服务创建JMS消息。(ii) Web服务将结果消息中继到主题(iii) 承载主题的Message Broker将计算结果多播到User 1消息代理。参见[8]C. Gravier，J.Fayolle/Electronic Notes in Theoretical Computer Science 146（2006）1723(iv) 用户图3.第三章。向用户的应用程序发布对请求命令的响应概要1该架构有助于构建仪器的协作访问框架。 事实上，多亏了它，用户然而，使用这种简单的架构无法满足一些必要条件，即资源的安全性，所提出的解决方案的可扩展性以及所有发出的消息的日志记录。下一节将讨论为满足这些额外目标所需的改进。3具有复合Web服务的基本框架关于网络负载从本文第2节的第一部分可以推断出，可扩展性没有被考虑，并且不满意前面提出的简单架构。其主要目的是，如果只有一个Web服务实例将其端点暴露给框架，则不可否认，它将不足以支持数据流，即使是低速率。我们可以理所当然地认为，如果Web服务接受一个突发的请求（请求在服务器上发布一条消息），那么在继续处理另一个请求之前，它必须按照4Web服务的这种使用称为协作Web服务访问。在我们的体系结构中，这是要避免的，因为如果有多个客户端访问Web服务的单个实例以获得一致的服务，那么只有一个实例运行该服务的事实不足以支持用户2远程应用Environnement话题消息代理用户1妈妈框架仪器WS发布终结点WS发布逻辑C. Gravier，J.Fayolle/Electronic Notes in Theoretical Computer Science 146（2006）1724框架.然而，这具有将单个Web服务的输出多播到多个客户端的优点，这意味着扮演与主题结构相同的角色（甚至有可能管理后期加入者）。第二种要考虑的方法是协作复制Web服务，参见[3]。这提供了复制Web服务实例的机会。这允许支持客户端应用程序的更多请求。然而，有一个很大的需要保持一致的副本，以同步不同实例的所有输出这应该在大量传输期间保持，因为复制并不简单，需要消耗资源和一些通信信道时间来提供同步。也许人们可以设想通过根据上下文将Web服务的访问从协作访问切换到复制访问，从而在两个世界中取得最佳效果，即：Web服务的负载然而，这已经是一个理论问题：如果负载条件在网络的点，它被认为是更好地从一个合作访问切换到另一个），你需要把某种看门狗，将不允许重新切换，如果你最近切换。选择正确的时间限制的问题，在该时间限制内不能改变列模式，这意味着一个共识问题（见[2]），可以被认为是一个很难处理的问题此外，在观察这种切换过程的实际实现的同时，必须提供过程以• 复制Web服务• 如果实例之间存在差异，则在几个实例之间确定一致的一个实例，并且同时杀死其他实例以便仅保留一个实例。总而言之，我们可以理解，试图将网络负载考虑到单个服务的访问会指出很多问题，并且可能不会带来足够的响应来轻松实现它这将被引用为本文相应章节下的未来工作组合服务除了可伸缩性之外，该架构还应该旨在提供所有访问的认证和日志记录基本上，这可以是C. Gravier，J.Fayolle/Electronic Notes in Theoretical Computer Science 146（2006）1725非主题的出版物WS前WSDBMS目录认证WS1WS测井2WS测井通过使用目录和相应的协议（例如用于认证的LDAP6）以及DBMS7（例如PostgreSQL）来实现需要注意的是，身份验证和日志记录是可以（必须！）实现为Web服务。此外，如果新考虑的体系结构包含三个Web服务，• 发布Web服务，用于发布关于该主题的消息• 用于检查相应用户在“eInstrument”上的访问权限的认证Web服务• 一个日志Web服务，它记录通过框架传递的消息，我们现在可以为我们的解决方案设计一个新的视图，如图4所示，它组成Web服务来响应用户这直接基于[6]中的观察，因为我们的目标也是提供一种“组合将多个独立的Web服务合并为一个单一的、一致的服务。这种组合也可以帮助考虑负载平衡，为请求更多的服务提供更多的Web服务实例（可能是日志记录，这可能是一个执行时间更长的任务组合可以通过使用BPEL4WS8来实现，以便编排这些Web服务之间的伙伴关系图四、一种用于高科技仪器远程控制的复合Web服务总结2首先，我们评估了复制Web服务的解决方案，6轻量级目录访问协议7 数据库管理系统8Web服务的业务流程执行语言C. Gravier，J.Fayolle/Electronic Notes in Theoretical Computer Science 146（2006）1726服务实例，以便考虑网络负载上下文，从而为客户端提供更好的然而，这似乎是一个不容易处理的真正挑战，仅仅因为这种协作模式适合于高负载，并且适配（即，协作模式之间的切换）实际上在理论上与实际上一样困难。然而，我们遇到了一件非常聪明的事情：提供关于这个主题的出版物的Web服务不能单独存在。实际上，它必须被额外的服务所包围，例如提供身份验证和日志记录，以满足我们在1中公开的需求。4框架中的用户上下文从上下文确定用户角色用户将不得不从一个被称为eInstrument的虚拟仪器中发出命令。关于用户的背景，可能存在用于使用仪器对群体进行不同分割的仪器的不同虚拟表示，甚至取决于目的，存在用于相同用户的不同表示例如，用户扮演教师的角色，用于对教学内容的教学协作访问，这对他来说可能更有趣（当然对学生来说也是如此！）以便仅显示应该在实践课程期间操作的图形控件。相反，如果同一个用户，现在像一个研究人员一样，想要访问仪器，很明显，默认情况下，所有的功能都必须可用于他的操作会话。主要问题是获取上下文，即。用户当前登录时扮演的角色是研究员还是教师。在这方面可以提出几个问题：• 用户是否开始了教学会话？• 用户是否开始了研究活动？• 根据用户的状态（可以是学生、研究人员、公司• 公司是否与拥有仪器的实体保持更重要的合作关系，以便显示的控件数量不会相同？不像其他更多的上下文无关的命题（见[5]），我们希望在这里能够回答前面的问题。答案必须是自动化的，以便提供虚拟表示的动态适应。C. Gravier，J.Fayolle/Electronic Notes in Theoretical Computer Science 146（2006）1727工具取决于上下文。主要的一点是识别上下文属性，它可以帮助评估用户访问仪器的上下文。回到一个研究人员的例子，他有一些教学活动。我们可以从用户应用程序使用的IP地址确定有人可能会争辩说，IP地址不能完全确定用户在认可教师或研究人员的角色时访问仪器我们认为这是完全正确的，并且不能通过对单个上下文属性的评估来根据前面的例子，我们可以补充说，用户在操作中扮演的角色可以从他正在访问的仪器中推断出来。对于我们的研究人员/教师用户，我们可以很容易地想象，这样的用户的研究活动导致他使用标记为A的电子仪器，并且用户不必在与学生的实践课程中使用相同的在最好的情况下，他只能访问第二个电子工具，标注为B，用于教学，A用于研究活动。这将有助于我们显示正确的eInstrument，这意味着图形控件的正确数量，根据用户扮演的角色，从上下文中推断出来然而，在最坏的情况下，我们可以假设上下文属性一（IP地址）或第二（被访问的仪器）不足以正确评估用户的角色。这就是为什么我们可以提供另一个上下文属性的原因，它可以是研究人员/教师的时间表。事实上，如果一个Web服务能够向我们的框架提供用户在一个时间范围内连接时，他应该是在实验教室里，教学生，这将最有可能意味着研究人员/教师是作为教师为这个会议（因此，显示的eInstrument将被调整）。然而，在某些情况下，这意味着存在上下文，其中所扮演的角色的决定不能被简化为单个上下文属性（如前所述此外，可能存在某些上下文属性比其他属性更能揭示信息的评估在这种情况下，可以提出一种关于上下文约束的思考机制，以帮助选择正确的上下文。在我们的示例中，时间表上下文属性可能比IP地址更能说明问题，IP地址本身比正在访问的仪器更如图5所示，我们的主张使用了一个前端的“上下文感知”Web服务协作，它决定了用户的角色。为了做出决定，这个Web服务使用一个组合服务，该组合服务是与每个Web服务一起构建的，每个Web服务都提供它正在访问的上下文属性考虑机制可以在前端Web服务内部实现，以便提供更多的信任C. Gravier，J.Fayolle/Electronic Notes in Theoretical Computer Science 146（2006）1728为给定上下文决定Web服务1前端上下文WS根据加权上下文Web服务提供的值，提供用户的估计...31,5Web 服务检索上下文返回上下文WS仪器请求返回上下文WSIP地址返回上下文WS时间表上下文属性仪器IP地址时间表...返回上下文WS...如果一个Web服务传递的上下文属性比另一个Web服务传递的上下文属性更具揭示性，那么它就比另一个然而，上下文对于应用程序来说是如此重要，以至于可以引入更复杂的方法来预测角色，例如融合图论和概率。这样的数学模型存在：这是例如隐马尔可夫模型或贝叶斯网络。“w”图五.支持基于上下文属性的用户角色自适应的通用eInstrumentation框架在图5中，人们可以很容易地理解我们的命题的分层组织。此图显示了如何根据上下文实现Web服务。实际上，对应的此外，如前所述，由于我们处理的是上下文，因此我们可以强调更多重要的属性，在这个例子中，很明显，知道一个研究者/教师在给定的时间段内在一门课程中是一个非常重要的线索，关于他想要在上下文适当性方面发挥的作用，例如正在访问的工具在我们的框架中。这个整合的任务其实很简单。我们可以使用前面讨论的上下文Web服务（参见4）来定制发送给用户的图形用户界面，而不是服务整个eInstrument（这是该仪器的整个虚拟表示这样我们就可以实现WC. Gravier，J.Fayolle/Electronic Notes in Theoretical Computer Science 146（2006）1729DBMS目录非主题的WWWW1234...时间表IP地址仪器返回上下文WS...返回上下文WS时间表返回上下文WSIP地址返回上下文WS仪器请求出版物WS认证WS前端上下文WS用于另一个上下文目的，复合上下文属性前端上下文WS根据加权上下文Web服务提供的值，提供估计的用户角色前WS测井WSe仪器的构造取决于上下文，并且因此动态地如这里所示6。见图6。基于服务的上下文层，考虑上下文属性5关于被远程控制的仪器的插图和示例。为 了 便 于 说 明 ， 我 们 将 在 此 列 出 我 们 实 验 室 拥 有 的 仪 器 清 单 。eInstrumentation项目涉及的仪器清单如下• a网络分析器• 超高频分析仪• 光纤拉伸器• 超高频椭偏仪读者必须明白，这些仪器都在同一个领域的利益，这是超高频测量在一个简短的描述。然而，必须考虑的是，共享不是在-C. Gravier，J.Fayolle/Electronic Notes in Theoretical Computer Science 146（2006）1730但在访问仪器的应用程序上。实际上，这意味着人们可以使用我们的框架，不仅可以访问控制仪器的应用程序，还可以访问任何可能做任何事情的C/C++ dll或基于Java的应用程序，即使这些应用程序不会访问任何仪器，但可以访问任何其他类型的资源。总结3总而言之，取决于一些上下文属性，例如（不是穷尽列表）• 用户应用程序使用的IP地址• 正在访问• 用户连接到eInstrument的时间架构可以这样确定用户应该在发起的会话中扮演的角色。这就是为什么显示的图形控件可以根据用户正在构建的会话的上下文自动适应用户的原因。然而，不可否认的是，人们很难相信，在每个连接和所有用户中，完全可以正确地猜测要支持的相应角色，依赖于一组很少的上下文属性。 这是因为没有一个可以完全揭示每一种情况（即。每一个背景！）. 然而，必须注意的是，某些上下文属性可能比其他属性更能说明问题，因此在角色评估时更需要考虑。当然，由于评估可能导致对上下文的错误解释，因此必须有一个安全机制，以使用户能够在我们的示例中从教学界面切换到研究界面。(that应该被称为而且，这种上下文Web服务，对于用户的角色，可以扩展到其他上下文服务。在我们的框架中，上下文Web服务是通过在连接初始化时添加一个新的控制层来集成的，如图6所示，表示我们的整个框架。6结论本文旨在展示一个完整的Web服务用例，该Web服务作为发布消息的接口和根据上下文调整服务的接口（实际上，本文关注的是对建立会话的用户所扮演角色的评估）为整个框架提供服务在该建立期间，必须考虑用户访问框架的上下文，这是为了提供适配的服务。为了满足这一要求，该体系结构经历了不同的步骤：C. Gravier，J.Fayolle/Electronic Notes in Theoretical Computer Science 146（2006）1731• 只有一个Web服务通过面向消息的中间件• 复合服务意味着服务由不同的Web服务提供• 上下文层，在该层处，“上下文Web服务”做出关于上下文的决定。这个上下文Web服务使用一个组合服务，该组合服务由单个Web服务构建，每个Web服务访问一个上下文属性。然而，问题可以提出，可能是未来工作的问题例如，人们可以争辩说，建立对访问上下文属性的每个Web服务的权重是不容易的，并且可能存在优化上下文Web服务的决策的成功的最佳权重集这意味着可能存在一种基于上下文属性来最小化错误决策的方法此外，是否有一个点，在上下文的变化是一个反思？这意味着，对于给定的上下文，是否存在最佳的思考集合？这将倾向于有可能建立“元上下文”，该元上下文将关于上下文本身不同地最后，本文讨论了用户在会话建立中的角色评估有两件事可以启发：一方面，可以假装在我们的框架中集成其他上下文Web服务，确定系统中的另一个属性，另一方面，可以定期重新评估上下文，以便这种评估不仅在一个确定的时间受到限制，而且在整个会话时间内定期被质疑。例如，这可以通过考虑用户的点击速度来实现引用[1] 作 者 ： Bernstein ， Philip A. Middleware ： A Model for Distributed System Services ，Communications of the ACM，1996年2月，卷。39，No.2，86-98.[2] 陈晓，“分布式计算系统的发展趋势”，北京：计算机科学出版社，1997年[3] Sangmi Lee、Sunhoon Ko、Geo Gangrey Fox、Kangseok Kim和Sangyoon，协作服务中通用可访问性的Web服务方法，第一届Web服务国际会议论文集，拉斯维加斯，（ICWS'03），2003年6月[4] Stephan Lukosch ， Jrg Roth ， Reusing Single-user Applications to Create Multi-userInternet Applications，Innovative Internet Computing Systems（I2CS），2001，79-90C. Gravier，J.Fayolle/Electronic Notes in Theoretical Computer Science 146（2006）1732[5] F. Pianegiani，D. Macii和P. Carbone，基于抽象客户端-服务器范式的分布式测量系统管理，特伦托大学技术报告，2004年[6] J. Rykowski 和 W. Cellary ， Virtual Web Services -Application of Software Agents toPersonalization of Web Services，第六届电子商务国际会议（ICEC[7] http://www.w3.org/TR/soap/”SOAP”,[8] http://java.sun.com/products/jms/”JMS: Java Messaging Service”,[9] http://joram.objectweb.org/”JORAM”,