PDF设计便携式协作网络
Lyn Bartram 和 Michael Blackstock，Colligo Networks
一个中间件解决方案，旨在跟上移动工作人员不断变化的协作方式。
点对点技术和无线网络为远离办公桌的协同工作提供了巨大的潜力，但它们也带来了独特的软件和基础设施挑战。传统的工作环境概念锚定在一个中心位置——办公桌和办公室——工作所需的资源都位于那里。即使在许多专业领域，从业人员需要在不同的现场地点之间移动，例如专业咨询、医疗保健或资源勘探，全套信息和技术资源也只能在固定的地点获得，工作人员定期“签到”以将其现场结果整合回更大的图景中。
然而，工作场所的性质正在发生变化。人们越来越需要并期望能够随时随地插入并工作——在办公桌旁、在办公室漫游或完全离开办公室。[例如，请参阅以下参考文献：“远离桌面计算机：产品设计团队中的分布式协作和移动性”，V. Bellotti 和 S. Bly，CSCW ‘96 会议论文集， Press，1996 年；“应对移动性：随时随地理解访问”，M. Perry 等人，《人机交互学报》，第 323-347 页，2001 年；“IT 移动性路线图”，英特尔公司，2002 年；“驾驭软件的未来”，技术预测：2002-2004 年，第 1 卷，普华永道，2002 年。]
这种工作移动性的概念给希望协作的人们带来了独特的挑战。在长期预测无纸化办公室将被普遍接受的时代，纸张仍然是移动工作人员最常用的共享技术（实际上，对于一般的协作工作也是如此）。[请参考 A. Sellen 和 R. Harper 的《无纸化办公室的神话》，MIT Press，2001 年。]
为什么？简而言之，因为纸张可以在任何地方使用，而数字技术仍然受到不灵活的网络要求和僵化的设计的阻碍。网络基础设施并非总是可用；安全始终是一个问题；即使用户能够相互连接，他们的系统也没有设置为使协作变得轻松高效。更复杂的是，协作工具和设备差异很大，尤其是当它们来自不同的企业时。
根本问题在于，这两个问题——移动性和协作——一直被视为企业软件解决方案的独立部分。作为软件设计师，我们需要从两个基本方面重新思考这个问题
- 将协作视为基础设施层面要提供的基本能力。协作不是映射到特定应用程序的专门任务；它是完成工作的基本过程。
- 将问题重新定义为便携性而不是移动性问题。工具和服务应该适应用户的环境，而不是强迫用户采用特定于位置的不同模式。
主要的设计挑战包括如何
- 提供与网络无关的服务，并优雅地适应不同的网络环境。
- 将这些服务和功能与现有工具无缝集成，并在现有工具之间无缝集成。
- 设计服务和任何新工具，以灵活地映射到人们协同工作的多种实际方式，从结构化的会议到即兴的会面。
支持移动个人
大多数企业系统和应用程序现在都为断开连接的工作人员提供了一些规定，以便将离线完成的工作集成到集中式系统中，一旦工作人员再次连接到企业网络或互联网门户。
标准的做法是通过以下一种或多种方式解决在移动场景中确保访问企业信息的问题
- 使用拨号、虚拟专用网络 (VPN)、中间件和广域网 (WAN) 技术的组合创建返回企业服务器的链接。当连接受到访问或性能的限制时，工作人员会批量下载、上传和同步数据。
- 使用瘦客户端来增加设备对持续连接的依赖性，同时减少为特定设备量身定制的实现的需求。
- 通过使用本地分区在功能强大的设备上部分复制数据来支持断开连接的工作。这涉及到对应用程序逻辑和层进行分区，以允许透明地进行连接和断开连接操作。这种方法的问题在于数据并不总是最新的，并且需要大量的本地存储空间。
使用这些方法意味着，当两个移动工作人员想要通信和共享信息时，他们必须连接到某些基础设施（图 1）。在许多移动场景中，该基础设施要么不可靠，要么不可用。由于安全策略，连接到本地网络通常是不可行的。即使本地相互连接可能也不够，因为许多数据同步策略需要服务器干预。此外，如果他们使用 802.11* 无线网络，他们的点对点连接是不安全的，因为其有线等效保密 (WEP) 安全协议存在重大缺陷 [请参阅 T. Karygiannis 和 L. Owens 的“无线网络安全：802.11”，《蓝牙和手持设备》，美国国家标准与技术研究院，2002 年]。
这种安全性的缺乏也限制了公共互联网连接：使用来自家庭或机场的无线互联网连接到办公室网络需要额外的保护。由于这些原因，许多移动工作人员仍然依赖于缓慢的 WAN 连接和定期的拨号连接来链接回办公室。如果无法访问某些固定基础设施，他们甚至会被拒绝基本的通信和文件共享协作服务。
工作场所的协作
在过去的十年中，无数的协作应用程序和中间件进入了工作场所，范围从基于 Web 的群件到基于组件的框架，再到日益普及的即时消息 (IM) 网络。方法（企业内部和企业之间）的组合包括电子邮件、Lotus Notes 等专用群件平台、基于 Web 的门户、IM 网络，以及最近基于开放标准并由业务规则驱动的中间件平台。
这些方法中的每一种都支持一种类型的协作交互（正式/非正式、实时/异步、受限/开放），但没有一种方法能够灵活地适应人们在企业内部和企业之间协同工作的所有方式。特别是，标准群件系统往往是一个大型的、包容性的服务器-客户端应用程序，托管用户的工作。这意味着要么导入和导出使用其他企业工具创建的文档，要么使用群件内部的专门附加工具。
这种应用程序方法可能非常适合营销（销售独立的解决方案更容易），但它并没有反映人们的工作方式。协作与其说是单独的任务，不如说是一个过程和完成其他主要任务的手段。
因此，大多数协作工作仍然涉及工具和服务的组合，其中一些工具和服务彼此集成不良，需要参与者管理不同的工具和信息孤岛。人们可能不想不断增加他们的工具集，但当他们的工具被证明不足时，他们会很快采用新技术来帮助他们完成工作。最明显的例子是消费者 IM 的使用量激增，即使面对企业抵制也是如此。IM 从青少年现象到标准工作场所实用程序的不可预测的转变，正是因为 IM 具有更不受约束和更轻松的交互范例。它允许用户立即查看他们的哪些联系人通过状态呈现可用，并支持与他们进行轻量级、即时、非正式的通信，而无需大量的应用程序开销或准备工作。然而，这种非正式性与企业对强大安全性和 IT 批准的参与的要求直接冲突。
应用程序集成的发展趋势已经看到许多大型企业框架（例如，客户关系管理、内容管理或项目管理）采取相反的方法，嵌入或与一些基本的协作服务（如电子邮件、文档版本控制、消息传递和主题讨论论坛）互操作。即使信息便携性越来越好地定义为可扩展标记语言 (XML)，并且标准服务描述语言开始流行，但在没有额外中间件的情况下，对跨应用程序路径的支持仍然很差。（我如何将此电子邮件连接到我的电子表格，然后将它们嵌入到我的工作区中？）
远程访问和跨企业协作的一个基本问题是安全地识别和验证来自受信任组织的用户身份，并能够向这些用户提供适当级别的访问权限。强大的身份验证机制必须由应用程序本身或额外的集中式身份管理服务（如 Microsoft Passport、IBM Federation 或 VeriSign）提供。从 IT 部门的角度来看，IM 的主要缺点是缺乏安全的基础设施。现在正在发布大量企业 IM (EIM) 产品和消费者 IM 的扩展，它们具有完整的身份验证和加密功能。
这些群件、IM 和企业应用程序集成 (EAI) 方法有一些共同之处
- 它们都是基于服务器的，并且依赖于集中式基础设施。
- 其次，每种方法都侧重于两种协作方式中的一种：要么擅长启用异步、正式、计划的协作，要么倾向于消息传递方法来支持实时、非正式或自发的协作。
- 协作功能主要针对拥有资源来容纳要求苛刻的客户端的桌面或功能强大的笔记本电脑用户。
- 这些方法仍然受到专有的、供应商依赖的协议的限制，这些协议需要网关和其他代码才能互操作。
- 所有这些方法——包括 IM——都只通过服务器提供有限的状态呈现支持，并且对发现的支持很差。状态呈现技术是一种应用程序类型，它使得在计算设备（包括例如手持计算机以及桌面型号）上定位和识别用户成为可能，无论它可能在哪里，只要用户连接到网络即可。发现是指在不事先了解其他用户和活动的情况下，了解其状态呈现的能力。
移动协作怎么样？
这些系统与移动工作人员（无论是个人还是团队成员）日益流动的需求不太匹配。有人说，移动协作的关键是离线工作的能力 [请参阅 S. Sanborn 和 C. Moore 的“协作汇聚在一起”，《InfoWorld》，2001 年]，但实际上，关键问题是在移动场景中与位于同一地点和远程地点的人员（不一定来自同一企业）共享有价值的业务信息的能力。与以门户为中心的观点（始终可以完全连接到互联网）相反，移动工作人员的访问权限可能会因地点和工作人员的角色而异。此外，即使通过互联网链接连接到另一家公司的同事是可行的，但位于不同的企业网络意味着没有共同的安全基础设施，因此，工作人员无法保证连接是安全的，并且对方已得到充分验证。
协作工作发生在许多不同的地方，基础设施和远见条件差异很大。两个人可能会抓住机会在机场的短暂会面中交换文档；审计团队可能会在客户现场花费数周时间审查数据，而对客户网络和互联网的访问受到限制；销售团队可能会在贸易展览会上与一群客户进行预定的演示，同时远程邀请其他办公室的专家参与；或者顾问可能想要与客户共享文件，但他们没有共同的网络和安全基础设施。时间和精力在机会主义场景中尤为重要，这些场景经常是移动协作的特征。如果设置、邀请和验证会话中的其他用户过于麻烦，则可能会失去协作的优势。
这些场景因使用的不同设备而变得更加复杂：笔记本电脑、个人数字助理 (PDA) 和新兴的智能手机在网络和计算能力方面并不相同。群件系统和现场 Web 服务器的大尺寸和计算要求使得它们对于较小的便携式设备而言不可行。
移动工作人员通常会沦为将断开连接模式的某些方面与共享和更新信息的繁琐方式相结合。考虑一个来自审计团队的例子。团队成员在前往客户现场之前，从总部复制了一个著名的数据库。然而，一旦到达现场，他们就无法使用他们获得的信息更新彼此的数据库副本。相反，在每天结束时，每个团队成员都会通过拨号连接到主服务器并复制个人数据库。然后，一旦每个人都上传了数据，每个人都必须依次重新连接以下载现在最新的数据库。这个例子突出了缺乏过渡支持的另一个问题：在不同的基础设施环境之间转换工作模式和工具使用既耗时又笨拙。
跨企业协作引入了其他问题。在同一房间但在不同企业网络中的两个用户可能只能通过电子邮件进行通信，如果我想向您发送一个 8MB 的文件，而您的电子邮件配额为 5MB，那么这是一种无效的解决方案。
短距离无线网络、较新的移动设备功能和点对点架构网络的结合可以通过将 LAN 子网的概念扩展到独立于任何外部基础设施的随时随地的即时网络来缓解其中一些问题。没有任何网络访问权限的工作人员可以即时建立即时网络并交换信息；来自不同企业的人员可以直接相互连接，而无需确保各自的服务器可以协调。然而，在这些点对点网络可用之前，必须解决状态呈现、发现、寻址、安全性和隐私的实质性问题。当目标是将范围扩展到短距离子网的边界之外以包括远程对等方时，这些问题会变得更加复杂。
PCN：用于协作的中间件
协作意味着什么？简单的定义是“共同工作，尤其是在智力工作中”。在操作上，这转化为以下部分或全部特征
- 共享信息和数据（包括创建新信息）。
- 沟通，从随意的谈话到有分寸的讨论。有时一种类型会变成另一种类型，例如，有人在电话交谈中做笔记，然后以纸质形式转发以供确认。
- 共享流程并合理地移交它们以实现工作流程。（您执行此操作，而我执行彼操作，Bob 可以执行下一步操作。）
- 共享上下文。信息和沟通存在于共享它们的人员的给定上下文中。
- 状态呈现和活动感知。人们喜欢知道人们在哪里，其他人在做什么，以及对他们有什么期望。
我们这里的重点是探讨在本地和远程团队情况下，为移动工作人员和工作组设计和开发有效的实时协作支持的问题。协作支持最好作为一种普遍存在的框架提供，该框架支撑着各种计算设备、网络基础设施和软件工具。
将移动工作视为断开连接的过程的方法的一个主要问题是，它鼓励开发一种专门针对该条件的策略（具有签入、签出和复制程序来学习和遵循），而不是将工作完成地点的概念扩展到一系列可能的基础设施场景。中间件层可以为协作提供基础设施基础，而无需强制应用程序如何使用它们，而不是让每个应用程序设计人员以另一种专有方式适应这些场景。
这绝不是一个新颖的想法。当前企业软件开发的趋势正在超越特定的应用程序集成，转向基于开放标准和 Web 服务的中间件的定义，以将协作功能和现有企业应用程序组件缝合在一起。企业希望管理其现有的应用程序组件，希望业务逻辑驻留在与供应商无关的中间件中，并且不想编写新代码来集成每个应用程序 [请参阅 D. Margulius 的“协作挑战”，《InfoWorld》，2002 年]。
基于 Web 的门户在作为结合协作服务和应用程序功能的前端方面正变得越来越流行。企业青睐它们，因为它们有可能向用户隐藏应用程序边界，并且是后端应用程序集成的对应物。此模型隐含的概念是中间件驻留在集中式基础设施上，用户通过 Web 浏览器或专用客户端访问它。然而，依赖于与某些中心点的连接的方法仍然无法充分支持人们协作的所有环境和上下文。需要针对一系列场景、任务和设备优化的新型协作软件基础设施来支持这些多样化的环境。
设计这些新基础设施的挑战不仅与用户何时何地协同工作有关，还与他们如何将针对这些多样化环境优化的软件和服务集成回集中式服务环境有关。数据便携性和服务框架仍处于起步阶段，并且存在许多未解决的问题。根据定义，由于用户需要在各种断开连接和连接模式下、跨各种网络类型和架构工作，因此基础设施需要同时具有分布式和中心组件。我们将我们的方法称为便携式协作网络 (PCN)。PCN 是一种软件中间件框架，它可以适应各种网络和设备约束，与标准企业基础设施互操作，并支持为移动用户开发和部署面向分布式的、面向协作的应用程序。PCN 模型的灵感来自人们如何协同工作（“群体-”）而不是来自当前的软件参数（“-件”）。PCN 可以解决在支持移动协作中发现的许多问题，但它们也引入了自己的一组设计问题。
PCN 设计原则
我们将 PCN 建模为一个有组织的框架，包括
- 人员和设备（例如台式机、笔记本电脑、PDA 或手机）。
- 协作会话，包括即时会议和结构化的、持久的空间。
- 上下文，包括位置、时间、目的。
- 协作服务。基本服务包括消息传递、文件传输、通知、访问控制、分布式存储和元数据同步。这些可以扩展以支持聊天、白板、数据共享、个人信息共享和专用应用程序共享。
- 资源（对外围设备的访问权限）。
- 信息（文档、数据库）。
- 网络（无线、有线、即时、管理的、点对点）。
根据 John Grundy 和 John Hosking [“工程插件软件组件以支持协作工作”，《软件实践与经验》，第 983-1013 页，2002 年]，实时群件组件架构基于三个支柱
- 通信支持是交换状态呈现、数据和消息传递的底层框架，无论是同步的还是异步的。
- 协调支持为数据、元数据、对象和活动的通知、同步和锁定提供事件机制。
- 协作工作支持是对应用程序共享、视图同步和实时共享工作（例如共享编辑）的细粒度支持。
我们添加了分布式数据管理支持的第四个支柱，以提供对 PCN 中各种对等设备上驻留的数据对象的信息的访问、聚合、同步和管理。
我们的理念是，灵活的轻量级中间件解决方案应该关注通信、协调和数据分发支持，为开发人员提供网络和传输层，以实现其特定应用程序所需的更专业的协作工作支持。
PCN 方法基于以下几个指导原则，每个原则都有自己的一组挑战和未解决的问题。因为我们意识到移动工作的关键挑战之一是如何将知识从更大的工作环境中整合回来并整合到其中，所以我们关注的是便携性而不仅仅是移动性，以及持久性以及即时协作上下文。最后，遵循供应商中立中间件的一般原则，PCN 应基于开放标准。
异构性。 PCN 软件必须适应异构网络和硬件环境。它在各种便携式、手持式和台式计算设备上运行，并覆盖底层网络协议，在有线、无线、本地、个人和广域网之间进行适当切换。对于容量较小的设备，如何提供服务将必须经过仔细设计，并制定策略以最大限度地利用资源。例如，手持设备上的文件传输限制可能需要缩减以匹配设备的容量。
适当的数据分发可以收集有关网络上所有共享对象的信息，并且仅在较小的设备上复制元数据，从而提供对对象的访问权限，而无需资源来托管它。这将需要适当灵活的元数据模式来适应新兴的协作协议，例如 Web 分布式创作和版本控制 (WebDAV) 和工作流，以及管理零星连接的同步机制。用户界面将对适应便携式和移动设备差异很大的外形尺寸提出设计挑战。
便携性和基础设施之间的无缝过渡。 PCN 理念的一个结果是，我们不再提出移动解决方案。相反，我们说涉及协作的工作和工作工具应该是便携式的——也就是说，无论您走到哪里，您都有协作所需的工具，而不是依赖外部提供的基础设施。
此原则有几个相关的要求
- 首先，我们需要确保强大的、安全的 PCN 所需的基本基础设施驻留在智能的、“胖”的、非浏览器客户端实用程序中，以便一组用户可以自动建立具有基本通信、协调和数据分发服务的即时点对点网络。
- 其次，PCN 应该能够在现有基础设施可用时利用它，并在不必要地涉及应用程序或用户的情况下适当调整其服务。例如，点对点连接可能更适合最佳数据传输，但服务器可能需要用于存储和转发消息给离线同事。
- 第三，网络架构之间的过渡应该是无缝的，以便用户或应用程序不会明显地停止一种模式并开始另一种模式。目标是自动化并减少“签入和签出”到家庭基础设施的开销。正如无线技术将用户从硬件限制中解放出来，以便基于 IP 的系统可以在任何支持 IP 的网络上运行（IP 是通用协议），PCN 将使应用程序至少部分地与底层网络架构（点对点或服务器-客户端）无关。
在完成这些目标时，我们必须解决几个与寻址、状态呈现和通信相关的具有挑战性的问题。显然，点对点技术构成了此策略的重要组成部分。在点对点网络中，设备使用状态呈现信号来广告自身。这些公告的范围通常限制在本地子网，因为它们可能会在传播到网关之外时产生性能问题。但是，一旦点对点网络扩展到子网之外，由于动态 IP 寻址、网络地址转换 (NAT) 和防火墙，它们就会受到寻址和范围限制。
动态 IP 地址意味着对等方如何依靠定位和查找另一个对等方是不确定的，因为与具有可通过域名系统 (DNS) 发现的固定 IP 地址的服务器或计算机不同，该对等方每次加入网络时都会具有不同的 IP 地址。由于目前尚不存在通用的点对点寻址协议，因此每个系统都以不同的方式处理寻址，从而使互操作性变得复杂。当前的方法包括将某些节点指定为广告中心（例如 JXTA 的 rendezvous 节点）或使用服务器来接受和中继消息（如 Groove 中）。
公司互联网安全进一步使寻址复杂化，这可能不允许 PCN 通信协议通过公司防火墙。许多防火墙阻止除最常见协议之外的所有协议，因此通常的方法是将通信流包装在常见的 HTTP/S Web 协议中（称为通过防火墙隧道传输）。这样做的缺点是需要 HTTP 服务器来中继防火墙外部的消息以及消息有效负载的限制：HTTP 的设计目的不是为了实现大数据块（如文件传输）的有效传输。在更全面的寻址协议（如互联网协议版本 6 (IPv6)）到位之前，几乎肯定需要某种形式的服务器目录和中继。
状态呈现信息构成了点对点、IM 和实时协作的支柱，但这些元素之间的集成受到缺乏任何通用状态呈现协议的阻碍。迄今为止，这意味着任何依赖状态呈现的应用程序都必须维护专用的状态呈现流。PCN 确保设备每个 PCN 仅维护一个状态呈现流，而不是每个应用程序维护一个状态呈现流。我们没有看到向通用状态呈现和 IM 标准 [即时消息和状态呈现协议 (IMPP) 工作组，2002 年] 迈进的明显迹象。因此，将通信层建立在 IM 之上是最有可能支持供应商中立、可互操作的中间件的方法。由于所有主要的 IM 网络都是基于服务器的，因此 PCN 状态呈现和寻址协议应包括直接（如果可能）和通过服务器地址联系对等方的方式。后续的状态呈现广告将需要仔细管理，以避免冗余流量。我们预计，随着点对点协作变得更加成熟，行业范围的标准将会发展，最有可能是在国际工程任务组 (IETF) 的主持下。
最后一个问题与提供 IT 部门对 PCN 范围的控制有关。在某些情况下，IT 部门可能希望通过公司服务器限制对内部网或外联网的访问，并出于安全原因禁用本地点对点访问。
对上下文的适当支持。 PCN 建立在全面的协作模型之上，该模型基于上下文的概念，并跨越实时和异步时间范围。人员、数据、服务和资源可以根据上下文进行组织，上下文可以基于许多事物：例如，位置（会议室中的所有人和所有人）或共同目标（研究项目）。PCN 上下文旨在封装人们参与的不同类型的正式和非正式协作，因此其服务和范围必须是可配置的。例如，公共即时网络中的两个成员之间的简短聊天是一个简单的临时上下文；具有共享资源、分布式数据同步和成员资格限制的工作区是持久性的上下文。围绕人员和定义的资源组织上下文是众所周知的。
然而，基于较新的状态呈现和发现技术的上下文交互具有一些令人兴奋的含义。基于位置的交互是一个明显的候选者（“会议室中的所有人”、“Mike 在他的办公室时”），服务发现也是如此（“贸易展览会上所有带有数码相机的人”）。这些暗示上下文由静态和动态属性定义。蓝牙和其他短距离无线传感技术为此类位置敏感的上下文建立提供了特别的希望。
状态和发现服务是实时协作的关键。虽然大多数协作系统明确地将用户、设备和服务建模为存在和活动的实体，但它们尚未支持对共享上下文和活动的更广泛的感知。正如InfoWorld测试中心的首席分析师Jon Udell所指出的，不属于私有的共享空间、对话和活动应该是可以偶然发现的[“Extending Groove,” InfoWorld, 2002]。这对于支持人们可以自发加入的轻量级、非正式互动尤其重要，并且这是一种基于计算机的框架中尚不支持的实时人际互动方式。因此，在PCN中，协作上下文被认为是其自身独立的显式实体，具有状态、服务和活动信息。上下文具有隐私和可见性属性。它可以定义为私有（访问权限仅限于成员）、公共（任何人都可以加入）、不可见（对等方需要被明确告知如何找到它）或可发现。
对发现方法的研究主要集中在面向Web的计算和企业对企业框架的服务发现上[例如，参见S. Vinoski的“Service Discovery 101”，IEEE Internet Computing，第69-71页，2003年]。消息传递和协作系统提供状态信息，但参与者需要以某种方式注册他们对另一个人的兴趣（即找到）。一旦找到，他们将该人（或“presentity”）添加到他们的好友列表中，该列表维护在服务器上。然后，服务器将该列表上每个实体的状态信息转发给他们。
当在具有数百或数千用户的庞大网络上管理状态信息时，这种方法具有明显的扩展优势。没有用户可以管理来自所有其他用户的状态信息，即使服务器经过优化以传递它。诸如Apple的iChat、Groove和Colligo Workgroup Edition之类的对等系统支持在本地子网上自动发现：对等方的状态信息通过IP组播进行广播或轮询。然而，一旦用户对子网之外的人的状态信息感兴趣，发现就会让位于使用目录服务器的显式搜索，将负担重新放回用户身上。PCN设计中的挑战是如何在不通过简单地返回网络中当前活动的所有人来压垮用户的情况下，支持跨PCN整个范围的上下文发现。虽然诸如Apple的Rendezvous之类的方法可能很有希望，但目前还没有针对presentities的标准发现协议。
出于先前讨论的寻址和状态原因，发现很可能通过混合方法发生，将本地发现与对远程状态服务器的访问相结合。由于PCN客户端也将在纯对等模式下运行，因此它必须维护自己的已保存presentities数据库（好友列表），从而增加了与服务器同步的额外挑战。最后，对发现信息的访问将不可避免地受到与上下文相关的隐私限制（“当我在会议室时，我想隐身”）。类似于IM系统中状态订阅模型，用户可以拒绝另一个用户监视状态的权利，用户必须有权拒绝在已定义的上下文中被发现，这必须构成发现协议的一部分。
安全性。安全性是移动专业人士最关心的问题，也是企业全面部署移动数据共享和通信的最大障碍。协作会话需要通过稳健且易于使用的方法进行安全身份验证和加密。PCN安全框架必须在两个方面既严格又灵活
- 首先，它必须基于公钥基础设施（PKI）的行业标准。然而，由于它必须在纯对等模式下运行，而无需依赖对标准PKI证书颁发机构服务器的访问，因此它必须能够在需要时提供适当的对等身份验证方法，并在证书颁发机构（CA）可用时依赖证书颁发机构。（Groove和Colligo Workgroup Edition都采用了这种方法）。
- 其次，并非所有类型的协作都需要相同程度的身份验证和隐私。在某些情况下，用户可能很乐意与使用低安全级别的某人互动（例如，在随意聊天中），但可能不愿意进行风险更高的互动（例如，打开对文件的访问权限）。这种方法的含义是，安全要求不一定必须绑定到用户或上下文，而应与协作服务类型相关联。此外，企业IT部门将希望配置和控制这些绑定。
尽管PKI方法尚不具备互操作性，但行业内正在朝着实现互操作性的方向努力[OASIS PKI Member Forum, 2002]。尽管计算限制限制了PKI的使用，但随着手持设备变得越来越强大，这种情况似乎正在减少。这可能是我们可以安全地依靠摩尔定律来解决硬件限制的一个领域。
对PCN的需求
在解决移动协作问题时，我们得出结论，需要一个更全面的框架来支持在构成现代工作场所的各种地点和上下文中发生的协作工作。这种方法扩展了即将到来的趋势，即提供基于组件的中间件，以在各种计算设备和网络上集成企业应用程序和协作服务。我们将这种普遍存在的协作软件层称为便携式协作网络，或PCN。
PCN支持便携式和设备无关的协作。这意味着框架及其关联的用户界面和API必须具有扩展到不同设备约束（如内存和屏幕空间）的能力，并在协议级别上在各种设备之间互操作。设备连接配置必须优雅地适应不同的设备和网络环境。例如，这可能需要消除对固定服务器的依赖，并且仅在可用或需要用于状态和发现时才利用它们。对于许多便携式场景，对等架构可能是最合适的。
由于协作支持是以基础设施而不是应用程序的形式提供的，因此PCN允许轻量级、特定、适当的协作功能。开发人员可以轻松地将其协作服务集成到他们自己的产品中，或将它们与现有的数据、知识或工作流管理工具耦合。这意味着协作支持实际上是透明的。服务直接集成到标准的办公和企业工具中，以及打包到轻量级实用程序中，这些实用程序不会妨碍用户的标准工具和任务。因此，最终用户功能必须在适当的情况下集成到现有的用户界面中（例如，作为Microsoft Office应用程序的插件）。它还应作为API提供，以供其他开发人员扩展。应提供一些基本实用程序和熟悉的用户界面，用于基本消息传递和文件传输等任务。
结果是用户界面直观且易于使用。用户只在需要时使用他们需要的东西。此外，由于协作支持是基于上下文的，因此它更准确地反映了不同的协作风格。特别是，用户、活动和上下文的状态和发现使人们能够在不参与这些活动的情况下了解其他人在做什么。这种感知引导着他们自己的工作策略，并成为围绕共享资源进行自发协作的触发器。这种机会主义协作是所有工作的重要组成部分。
最后，基于适当现有安全标准的自适应身份验证框架确保了用户无论身在何处都能获得安全的协作网络，并根据任务的安全需求进行适当的调整。同样，该框架需要减少对服务器的依赖，仅在可用时才利用固定的企业或公共可用的密钥基础设施进行身份验证。
尽管这些原则源于我们移动工作团队的核心客户群，但它们支持的许多实践在更传统的、固定位置的群件环境中也同样相关。进一步推进PCN方法所需的许多技术和标准仍处于起步阶段。我们预计未来几年将证明是PCN概念以及相关的行业范围协议和开放标准发展的肥沃试验场。问
MICHAEL BLACKSTOCK创立了Colligo Networks，这是一家提供对等无线生产力工具的供应商。在此之前，他曾担任Infowave Software的研发副总裁，Infowave Software是一家将企业应用程序连接到无线设备的软件供应商。他获得了不列颠哥伦比亚大学的电气工程学士学位和西蒙弗雷泽大学的计算机科学硕士学位。
LYN BARTRAM是Colligo Networks的高级研究科学家，也是西蒙弗雷泽大学的兼职教授，她于1991年在该大学获得了计算机科学博士学位。
最初发表于Queue vol. 1, no. 3—
在数字图书馆中评论这篇文章
更多相关文章
Andre Charland, Brian LeRoux - 移动应用开发：Web 与原生
几年前，大多数移动设备，用一个更好的词来说，是“哑的”。当然，有一些早期的智能手机，但它们要么完全以电子邮件为中心，要么缺少可以在不使用手写笔的情况下使用的复杂触摸屏。即使更少的设备配备了能够显示简单文本、链接，甚至可能是一张图片之外的任何内容的像样的移动浏览器。这意味着，如果你有其中一种设备，你要么是一个沉迷于电子邮件的商务人士，要么是一个希望今年将成为智能手机年的alpha 极客。
Stephen Johnson - 茶杯中的 Java
很少有技术领域像无线行业那样发展迅速。随着市场和设备的成熟，移动应用程序的需求（和潜力）也在增长。越来越多的移动设备在交付时安装了 Java 平台，这使得大量的 Java 程序员可以尝试嵌入式编程。不幸的是，并非所有 Java 移动设备都是相同的，这给新的 J2ME（Java 2 平台，微型版）程序员带来了许多挑战。本文使用一个示例游戏应用程序来说明与 J2ME 和蓝牙编程相关的一些挑战。
- 流媒体和标准：交付移动视频
不相信我？跟着我来……手机无处不在。每个人都有一部。想想你上次在飞机上的情景，航班在地面上延误了。在可怕的公告之后，你立刻听到每个人都拿起手机开始拨号。
Fred Kitson - 移动媒体：使其成为现实
许多未来的移动应用程序都基于丰富、交互式媒体服务的存在。此类服务的承诺和挑战是在最恶劣的条件下，并以低成本向期望很高的用户社区提供应用程序。情境感知服务需要关于用户是谁、在哪里、何时以及正在做什么的信息，并且必须以最小的延迟及时交付。本文揭示了一些当前最先进的“魔力”和研究挑战。
© 保留所有权利。