PDFXML Web 服务移动缓存
Douglas B. Terry 和 Venugopalan Ramasubramanian，微软研究院
面对不可靠的连接和低带宽，缓存可以为 Web 服务提供可靠的无线访问。
Web 服务正在兴起成为互联网上的主导应用。Web 不再仅仅是信息的存储库，而是演变成服务提供商和消费者之间的活跃媒介：个人提供点对点服务以访问其他个人的个人联系信息或相册；个人为企业提供服务以访问个人偏好或税务信息；基于 Web 的企业提供消费者服务，例如旅行安排 (Orbitz)、购物 (eBay) 和电子邮件 (Hotmail)；以及若干企业对企业 (B2B) 服务，例如供应链管理，构成了互联网的重要应用。
尽管这些服务是通过静态或动态 Web 页面提供的，但它们正在演变成基于可扩展标记语言 (XML) 的 Web 服务，专为程序化访问而非人工访问而设计。例如，MapPoint.Net 提供地图和位置服务，以便整合到其他 Web 站点和应用程序中。因此，XML Web 服务是构建新一代 Web 应用程序的基石，这些应用程序利用了对 Web 技术的现有投资。
Web 服务成功的关键要求之一是普遍可用性。Web 服务往往在所有时间和所有地点都被访问。人们使用各种各样的设备，包括台式机、笔记本电脑、手持个人数字助理 (PDA) 和智能手机，这些设备使用非常不同的网络类型连接到互联网，例如无线局域网 (802.11b)、蜂窝网络 (WAP)、宽带网络（有线调制解调器）、电话网络（28.8-kbps 调制解调器）或局域网 (以太网)。偶尔到频繁的断开连接和不可靠的带宽是这些网络的特点。因此，对于使用移动设备并在各种无线和有线网络中工作的消费者来说，Web 服务的可用性是一个值得关注的重要问题。
改进 Web 服务可用性的一个好的解决方案应该是透明可部署且普遍适用。透明部署意味着该解决方案不得要求更改 Web 服务的实现，无论是服务器端和客户端模块，还是它们之间的通信协议。Web 服务的数量增长惊人；因此，对现有 Web 服务应用更改是不切实际的。出于同样的原因，该解决方案应该是可扩展的和通用的，足以应用于所有 Web 服务。为每个 Web 服务构建专门的组件来处理断开连接将是奢侈的。相反，一个好的解决方案应该适用于所有 Web 服务，并且将在客户端和服务器的通信路径中透明地插入存储和计算，而无需修改客户端或服务器上的 Web 服务实现。
在断开连接期间，通过客户端请求-响应缓存可以提供对移动设备 Web 服务的持续访问，该缓存在有限程度上模拟 Web 服务的行为。缓存满足了透明部署和普遍适用性的必要特性。缓存对于 Web 服务的客户端和服务器组件都是透明的。因此，缓存不需要更改 Web 服务的实现和通信协议，并且可以应用于符合万维网联盟 (W3C) 标准的现有 Web 服务。
各种系统已在移动设备上使用缓存，以支持对文件、数据库、对象和 Web 页面的断开连接访问。大多数现代商业 Web 浏览器允许用户在离线时访问缓存的页面。Web 浏览器缓存将 URL 映射到 HTML 页面，并且只需要担心一个操作——即 HTTP GET 操作。它们依赖于 Web 服务器提供的指令，这些指令指示页面是否可缓存以及可缓存多长时间。XML Web 服务由于此类服务导出的各种操作以及它们缺乏对缓存过程的参与而提出了新的挑战。
XML WEB 服务标准
缓存架构必须严格遵守 W3C 开发的基于 XML 的 Web 服务标准[参见 Tim Bray、Jean Paoli、C.M. Sperberg-McQueen 和 Eve Maler 于 2000 年 10 月 6 日发布的“可扩展标记语言 (XML) 1.0（第二版）”；www.w3.org/ TR/2000/REC-xml-20001006]。本节概述了此类标准。
Web 服务由服务提供商和基于客户端-服务器架构的多个消费者组成。每个 Web 服务都使用自定义通信协议供客户端访问服务器。Web 服务最常见的访问模式包括请求和响应。客户端向服务器发送请求消息，该消息指定要执行的操作以及执行操作的所有相关信息。服务器执行指定的操作并回复响应消息。服务器执行的操作可能会导致服务器状态的永久更改。
本质上，Web 服务为客户端提供类似于远程过程调用 (RPC) 的接口。例如，MyContacts 是 .NET My Services 之一[参见 Microsoft .NET My Services Specification，Microsoft Press，2001]，它是一个 Web 服务，允许用户维护其联系人的姓名、地址和电话号码。MyContacts Web 服务导出操作以插入、删除、替换和查询此联系人信息的部分内容。这些操作中的每一个都接受输入参数（查询字符串）并产生输出（查询响应或成功状态）。每个 Web 服务都提供自己的自定义接口，这些接口可能与其他 Web 服务提供的接口截然不同。例如，旅行 Web 服务将提供搜索机票、预订和购买机票以及查找行程的操作。
在包括 IBM 和 Microsoft 在内的多家领先公司的支持下，W3C 推荐了一套基于 XML 的 Web 服务标准。这些基于 XML 的标准为发现、描述和访问 Web 服务的自定义接口提供了全球公认的协议。[有关更多信息，请参见 P. Cauldwell 等人著的 Professional XML Web Services，Wrox Press Ltd.，2001。] 该标准由两个重要组成部分组成：简单对象访问协议 (SOAP) 和 Web 服务描述语言 (WSDL)。[有关更多信息，请参见 F. Curbera、M. Duftler、R. Khalaf、W. Nagy、N. Mukhi 和 S. Weerawarana 撰写的“Unraveling the Web Services Web: An Introduction to SOAP, WSDL, and UDDI”，IEEE Internet Computing，2002 年 3 月至 4 月，第 6 卷，第 2 期，第 86-93 页。]
SOAP。 SOAP 指定了在 Web 服务的不同实体之间发送消息的标准[参见 Martin Gudgin、Marc Hadley、Jean-Jacques Moreau、Henrik Frystyk Nielsen 于 2001 年 10 月 2 日发布的“SOAP 1.2 Part 1: Messaging Framework”；www.w3.org/ TR/soap12-part1]。SOAP 消息是从一个 SOAP 节点传输到另一个 SOAP 节点的 XML 文档。对于 Web 服务，SOAP 节点可以是客户端或服务器。每个 SOAP 消息都由一个称为信封的最外层元素组成。信封由两个元素组成：一个强制性的主体和一个可选的标头。主体元素携带消息的主要内容。对于请求消息，它将携带要执行的操作的名称和参数。标头元素由多个标头块组成，每个标头块都包含接收方或中间节点的元信息。标头块指定了其他有用的信息，例如用于身份验证的密码。
图 1 中的 SOAP 消息显示了来自客户端到服务器的 MyContacts Web 服务的示例请求消息。SOAP 消息通常使用超文本传输协议 (HTTP) 作为应用层协议进行传输，因为 SOAP-RPC 建议仅对 HTTP 是完整的。因此，来自客户端的操作请求由 HTTP 请求消息携带，而来自服务器的响应由相应的 HTTP 响应消息携带。
图 1
<?xml version=”1.0” encoding=”utf-8”?>
<s:Envelope xmlns:s=”http://schemas.xmlsoap.org/soap/envelope/”
xmlns:m=http://schemas.microsoft.com/hs/2001/10/myContacts xmlns:c=http://schemas.microsoft.com/hs/2001/10/core
xmlns:mp=”http://schemas.microsoft.com/hs/2001/10/myProfile” >
<s:Header>
<licenses xmlns=”http://schemas.xmlsoap.org/soap/security/2000-12”>
<c:identity> <c:kerberos>3240</c:kerberos> </c:identity>
</licenses>
<path xmlns=”http://schemas.xmlsoap.org/rp/”>
<action>http://schemas.microsoft.com/hs/2001/10/core#request</action>
<to>http://microsoft-m3we4f.microsoft.com</to>
<fwd><via /></fwd><rev><via /></rev>
<id>b55528a4-5d63-49f1-87a2-5fab8d76f658</id>
</path>
<c:request service=”myContacts” document=”content” method=”insert” genResponse=”always” >
<key puid=”3240” instance=”1” cluster=”1” />
</c:request>
</s:Header>
<s:Body>
<c:insertRequest select=”/m:myContacts/m:contact[mp:name/mp:givenName = ‘Joe’]/mp:emailAddress” >
<mp:email>[email protected]</mp:email>
</c:insertRequest>
</s:Body>
</s:Envelope>
WSDL。 WSDL 是一种用于提供 Web 服务描述的标准[参见 Roberto Chinnici、Martin Gudgin、Jean-Jacques Moreau 和 Sanjiva Weerawarana 于 2002 年 7 月 9 日发布的“Web Services Description Language (WSDL) Version 1.2”；www.w3.org/TR/wsdl12/]。每个 Web 服务的 WSDL 文档完整地描述了该 Web 服务向客户端提供的自定义接口。程序开发工具（例如 Microsoft 的 Visual Studio .NET）可以使用此文档自动生成代理存根，这些代理存根将远程 Web 服务封装为客户端上的本地对象。WSDL 文档列出了 Web 服务提供的操作名称，以及用于在客户端和服务器之间进行通信的 SOAP 消息的格式。WSDL 文档还完整描述了要传递给每个操作或作为响应接收的参数的数据类型。因此，WSDL 提供了对 Web 服务提供的各种接口的充分描述。
断开连接操作的缓存实验
为了研究缓存对支持 Web 服务断开连接操作的适用性，我们进行了一项实验，其中在 Microsoft 的 .NET My Services 和这些服务附带的示例客户端之间放置了一个缓存代理。.NET My Services 被选为本次实验的对象，因为尽管它们不是商业服务，但在研究时它们是公开可用的、文档齐全的，并且代表了支持查询和更新操作的非平凡 XML Web 服务。
Microsoft .NET My Services 软件开发工具包 (SDK) 包含许多 Web 服务，例如：MyContacts，它允许用户存储和检索地址和电话信息；MyProfile，它允许用户存储其个人信息；以及 MyFavoriteWebSites，它允许客户端管理收藏的 Web 站点。.NET My Services 系列中的每个 Web 服务都在共享数据库上导出四个重要的操作
- 查询 允许用户选择数据库的部分内容。此操作采用 XPath 字符串作为查询表达式。
- 插入 接受要插入数据库的数据，以及指定插入位置的 XPath 字符串。
- 删除 接受 XPath 查询字符串并删除数据库中指定的条目。
- 替换 在数据库中执行原子性的删除和插入。
SDK 还附带了几个调用这些服务的示例应用程序。通过运行示例应用程序，我们在网络连接以及故意断开网络连接的情况下对这些服务执行了各种操作。图 2 说明了我们的实验设置。
我们构建了一个 HTTP 代理服务器，如 HTTP 协议标准["RFC 2616: 超文本传输协议 - HTTP/1.1"，R. Fielding、J. Gettys、J.C. Mogul、H. Frystyk Nielsen 和 T. Berners-Lee，IETF，1997 年 1 月；www.ietf.org/rfc/rfc2616.txt] 中定义的那样，并将其部署在客户端设备上。在本例中，客户端设备是一台运行 Windows XP 的笔记本电脑。源自客户端的所有 HTTP 消息，包括 Web 客户端和 Internet 浏览器生成的消息，都被设置为通过代理服务器。对于所有非 SOAP 消息的 HTTP 数据包，代理服务器充当简单的隧道。
我们在代理服务器中添加了一个用于存储 SOAP 消息的缓存。将 Web 服务缓存集成到代理中提供了透明性。此缓存存储接收到的 SOAP 请求响应消息。所有缓存策略（用于过期和替换）均按照 HTTP 标准中的建议实施。在实验期间，此缓存仅用于存储实体为 SOAP 消息的 HTTP 数据包。每当网络连接时，接收到的 SOAP 请求将发送到服务器。接收到的 SOAP 响应存储在与请求关联的缓存中，替换旧的响应（如果存在）。当缓存包含同一请求的先前响应时，新的 SOAP 响应将与先前的响应进行比较，并将比较结果记录在日志文件中。这些比较为哪些类型的操作可以缓存以及哪些其他操作会影响缓存响应的有效性提供了有价值的见解。
如果网络断开连接，则缓存中存储的 SOAP 响应（如果存在）将返回给客户端，并且 SOAP 请求将存储在回写队列中。如果请求没有缓存响应，则客户端将超时等待响应，就像服务器不可访问时的正常情况一样。所有请求都存储在回写队列中以供稍后重放，因为缓存管理器无法确定哪些请求修改了服务状态，哪些请求只是查询。回写队列负责定期检查网络的连接性。每当与 Web 服务的连接恢复时，排队的 SOAP 请求将重放给服务器，并且 SOAP 响应将存储在缓存中。
该实验清楚地突出了使用 Web 服务缓存来支持断开连接操作的好处。具体而言，我们能够证明，.NET My Services Web 服务集（例如 MyContacts）可以在断开连接期间使用，而几乎无需意识到断开连接。只要缓存已预加载并且缓存管理器可以识别相似的请求，应用程序就可以在断开连接时正常运行，即使应用程序和服务都没有设计或修改为适应离线缓存。
缓存 WEB 服务中的问题
我们的缓存实验揭示了许多需要处理的问题，以显着提高离线访问 Web 服务的一致性和可用性。本节详细阐述了与为 Web 服务设计客户端缓存相关的问题。
回放和可缓存性。 Web 服务的多样性在识别 Web 服务公开的操作的语义方面提出了一个主要问题。在文件系统的情况下，可以清楚地理解诸如读取和写入之类的标准操作的语义。读取操作的结果可以存储在缓存中，而写入操作需要在连接恢复后回放到服务器。另一方面，Web 服务具有各种各样的接口，这使得缓存难以理解某个操作是否需要回放到服务器，以及缓存中的旧响应是否可以被客户端接受。
Web 服务缓存需要至少识别操作的两个属性才能有效运行。如果操作的执行对服务器状态进行了永久更改，则称该操作为更新操作。如果 Web 服务的操作是可缓存的，则表示在没有更新操作干预的情况下，使用相同参数进行的后续执行会产生相同的响应。Web 服务的操作可能既是可缓存的又是更新的，而其他操作可能两者都不是，或者只具有其中一个属性而没有另一个属性。例如，查询数据的请求是可缓存的，但通常不是更新。如果服务器需要维护所有请求的日志，则查询也可能会更新服务器状态。获取当前时间的请求既不可缓存也不是更新。
一致性。 缓存方案普遍面临的一个基本挑战，并且由于 Web 服务的多样性而变得更加复杂，是提供基本的一致性保证。在断开连接模式下运行时，缓存管理器无法提供强一致性保证，因为它无法访问其他用户执行的更新。但是，它至少可以努力提供与用户自身操作一致的缓存结果。特别是，本地用户执行的操作可能会更改缓存中存储的早期请求的某些结果。
一致性要求可能需要使缓存中存储的某些请求的响应由于稍后请求的执行而失效。例如，在 MyContacts Web 服务中，更改朋友的电话号码或完全删除条目的请求应使先前查询该朋友联系信息的响应失效。为了保持准确性，缓存中较早的响应必须被正确修改或从缓存中删除。否则，如果在网络中断期间重复查询，缓存可能会返回不正确的响应。对于预先存在的 Web 服务，了解正确的一致性要求（即操作之间的相互依赖性）是一个极其具有挑战性的问题。
Web 服务缓存的最终有效性取决于它在多大程度上可以支持各种 Web 服务的一致性语义。考虑 Web 服务应用程序连续执行的两个操作：request1 和 request2。假设 request1 的响应当前存储在缓存中。假设正在处理 request2。request2 是否使 request1 失效不仅取决于两个请求正在执行的操作，还取决于传递给这两个操作的参数。缓存管理器必须正确理解 request2 使 request1 失效的条件。
除了失效之外，缓存管理器实际上可以应用更智能的转换。转换可以修改 request1 的缓存响应以符合 request2 请求的更改，而不是指定 request2 是否使 request1 失效。例如，当收到删除请求时，智能缓存管理器可能会通过删除信息来修改先前查询请求的缓存响应。
用户体验。 评估支持断开连接的良好技术的一个重要标准是其对用户体验的影响。理想情况下，用户在断开连接时的体验应与连接时相同。但是，实现理想目标在实践中是不可行的，特别是如果 Web 客户端不知道缓存的存在。
Web 服务缓存保证的一致性保证与断开连接期间的用户体验质量之间存在直接的权衡。通过仅提供弱一致性保证，Web 服务缓存可以大大提高 Web 服务的可用性。例如，当缓存处理更新操作的请求时，除了存储该请求以供将来回放到服务器之外，它还可以向 Web 客户端发送虚假响应，报告此操作成功。但是，当请求实际在重新连接时回放到服务器时，服务器可能会出于各种原因决定中止该操作。另一方面，保证强一致性不会影响用户体验，但会阻止缓存使用某些技术来增强服务的可用性。
使 Web 客户端应用程序了解缓存可以帮助用户在离线访问 Web 服务期间。特别是，Web 服务客户端可以向用户告知断开连接和某些操作执行中的不确定性。但是，修改 Web 客户端以添加此报告功能可能并非易事。我们的实验表明，需要发现一种标准机制，用于向用户报告重要事件，而无需对 Web 客户端实现进行重大更改。
一种方法是缓存管理器向 SOAP 响应添加可选的缓存标头。未修改的 Web 服务客户端可以完全忽略缓存标头。了解缓存的 Web 客户端可以使用缓存标头提供的信息，例如，弹出一个窗口，通知用户响应是从缓存返回的，或者请求已存储在回放队列中以供稍后通信。
请求和响应消息。 理解 Web 服务客户端和服务器之间交换的消息的格式可能是缓存代理的另一个问题。尽管使用了标准协议（例如 SOAP），但 Web 服务在其请求和响应消息的结构上差异很大。甚至用于识别正在执行的操作名称的机制也因服务而异。例如，在图 1 中，该图显示了 MyContacts Web 服务的 SOAP 请求，操作名称 insert 是请求标头的属性字段之一。对于不同的 Web 服务，可能需要以完全不同的方式识别操作名称。
出于其他基本原因（例如比较请求和发送默认响应），也需要正确理解消息结构。通常，缓存管理器需要了解请求消息的哪些元素应作为缓存查找的键。例如，MyContacts Web 服务的每个 SOAP 请求消息都在标头字段之一中具有唯一的标识符（参见图 1 中的 id 字段）。缓存管理器在比较期间必须忽略此字段，以便它可以正确识别相似的请求。否则，每个请求都会有所不同，并且缓存将失效。
当缓存在断开连接期间收到更新操作的请求时，它应向客户端返回有意义的响应，以假装服务可用。如果此操作也是可缓存的，则缓存可以返回先前存储的响应；如果不是，则需要生成符合该服务消息格式的响应。当前的 WSDL 规范包含足够的信息以允许缓存管理器构造格式正确的响应，但缺少有关响应的每个元素的合理默认值的信息。例如，在 MyContacts Web 服务上插入请求的响应中，缓存管理器将需要将 status 属性设置为“success”，以防止客户端报告失败。缓存管理器还需要将请求消息中的唯一标识符的值复制到响应的 relatesTo 字段中。
预取。 缓存的有效性取决于未来请求与过去请求的相似性。缓存只能返回先前缓存看到的那些请求的存储响应。预取或“囤积”技术（预先将未来预期请求的响应加载到缓存中）可以显着提高可用性。但是，选择正确的请求进行囤积需要用户的参与。开发一种标准机制供用户指定可供 Web 服务缓存使用的囤积请求是一项挑战。
安全性。 安全性是在为 Web 服务构建缓存时要考虑的另一个重要问题。Web 服务通常在执行操作之前检查消息的身份验证和用户的权限。例如，Kerberos 安全系统票证的到期可能会禁止用户访问某些信息。缓存管理器可能需要包括机制以在断开连接期间从缓存响应之前执行这些授权检查。不幸的是，Web 服务使用几种不同的方法来确保安全性，从而使其难以在缓存实现中集成安全性。
最终目标：无缝的在线-离线转换
具有无线网络功能（例如笔记本电脑、手持 PDA 和智能手机）的移动设备正成为通过互联网进行交互的越来越流行的平台。此类设备上的未来应用程序将需要对 XML Web 服务进行高度可用的访问，XML Web 服务正在成为集成现有系统和提供新的平台无关服务的关键技术。应用程序设计人员面临的挑战是如何支持具有不完善网络连接的移动设备，同时整合驻留在 Internet 服务器上、导出一组丰富的操作并由各种组织提供的 Web 服务。
移动设备上的缓存是必要的，以适应低带宽、高延迟的连接，并允许在断开连接期间继续运行。缓存以提高文件系统和数据库系统的可用性是一种经过充分探索和广泛使用的技术。但是，Web 服务与这些传统的分布式系统有很大不同。文件系统和数据库系统都具有明确定义的客户端接口。例如，文件服务器导出标准操作，例如缓存管理器可以实现的读取、写入、打开和关闭。相比之下，每个 Web 服务都向客户端公开其自己独特的接口。
为了处理 Web 服务操作的多样性，HTTP 代理可以透明地缓存应用程序和 Web 服务之间发送的请求和响应数据包。然后，可以使用来自代理的缓存响应来为断开连接时执行的类似请求提供服务。代理还需要对断开连接时执行的某些操作进行排队，以便可以在恢复连接时在相应的 Web 服务上稍后执行这些操作。使用基于代理的方案允许在访问未设计为支持客户端缓存的 Web 服务时透明地执行缓存。
请求-响应缓存的替代方案是将 Web 服务的部分或全部复制到移动设备。许多 Web 服务都是 SQL 数据库的前端，并且存在用于使设备驻留数据与服务器驻留数据库保持同步的技术。在移动设备上维护数据库比请求-响应缓存具有优势，因为用户可以更好地控制断开连接期间可用的数据集，更重要的是，应用程序可以在本地数据上运行任意查询。
但是，仅复制 Web 服务数据是不够的。Web 服务将其数据封装在关键业务逻辑中。实际上，Web 服务的吸引力在于允许客户端应用程序利用这种高级逻辑。将服务器代码复制到资源有限的移动设备上可能不可行。更重要的是，Web 服务的代码通常被视为专有的，并且通常由与访问服务的各方不同的各方拥有。因此，尽管数据和代码复制可能适用于紧密耦合的应用程序和服务，但它不如 SOAP 级别的缓存那么普遍有用。
缓存管理器可以直接构建到应用程序中，而不是驻留在代理中。这种方法允许与应用程序更好地集成。例如，应用程序可能知道如何预取数据以供离线使用，并且可以提供视觉提示，指示哪些数据在断开连接时可访问。尽管手工制作的缓存管理器可能适用于访问少量稳定 Web 服务的应用程序，但缺点当然是开发成本以及在服务本身不可避免地发展时需要发展缓存代码。
我们对 Microsoft 的 .NET My Services 的实验表明，使用缓存代理，您可以实现对在构建时未考虑移动性的应用程序的离线访问。也就是说，缓存管理器可以在客户端应用程序和服务器之间透明地部署，而无需更改 Web 服务实现和通信协议。对于提供仅对相当静态的数据（例如地图、货币兑换和黄页服务）进行查询操作的大量 Web 服务，所有 SOAP 请求和响应的透明、服务无关的缓存效果良好。然而，特别是对于允许应用程序更新共享数据的 Web 服务，我们的实验表明，如果对 Web 服务的语义有合理的了解，Web 服务缓存可能会更有效。
需要扩展 WSDL 标准，以根据特定 Web 服务的语义自定义基于代理或应用程序嵌入的缓存管理器。放置在 Web 服务的 WSDL 描述中的其他信息可以指示哪些操作是更新，哪些是可缓存的，从而提高缓存方案的有效性。例如，可以注释 WSDL 操作元素，这些元素用于指定 Web 服务导出的每个操作的请求和响应格式。此类注释扩展了 Web 服务接口的描述。这些注释不会影响从 WSDL 规范自动生成 Web 服务客户端的工具，而只是用于调整缓存管理器的行为。可以将注释添加到 WSDL 描述中，而无需对 Web 服务的实现进行任何修改。这些注释可以由服务提供商或对 Web 服务的语义有合理了解的第三方提供商发布。促进缓存所需的 WSDL 扩展的完整集合仍有待探索和标准化。扩展的 WSDL 规范将允许客户端缓存提供更好的缓存一致性，从而提供更令人满意的移动用户体验。
未来 Web 服务的设计者应制定扩展的 WSDL 规范，以便在移动和固定设备上实现有效的缓存，从而支持断开连接的操作并提高性能。由 WSDL 规范驱动的开发工具可以帮助构建移动应用程序，这是一项众所周知的难题。最终目标是为使用新兴 Web 服务的移动应用程序用户提供无缝的离线-在线转换。Q
DOUG TERRY 是微软研究院硅谷实验室的高级研究员。他致力于为移动用户提供支持的新技术，以及用于从间歇性连接设备访问 Web 服务的架构。在加入微软之前，Terry 是 Cogenia 的创始人兼首席技术官，该公司提供复制平台，用于向移动设备交付情境相关信息。在 Cogenia 之前，他是 Xerox PARC 计算机科学实验室的首席科学家，在那里他帮助开创了普适计算的概念，并领导了多个关于弱一致性分布式系统的研究项目。Terry 拥有加州大学伯克利分校计算机科学博士学位，在那里他参与了 Berkeley Unix 的开发，开发了 BIND DNS 服务器的第一个版本，后来还担任兼职教师讲授课程。
VENUGOPALAN RAMASUBRAMANIAN 是康奈尔大学计算机科学博士生，他在移动计算和无线网络领域工作。他于 2002 年在微软研究院硅谷实验室实习。
最初发表于 Queue 杂志第 1 卷，第 3 期——
在 数字图书馆 中评论这篇文章
更多相关文章
Niklas Blum, Serge Lachapelle, Harald Alvestrand - WebRTC - 面向开放 Web 平台的实时通信
在这个疫情时期，世界比以往任何时候都更加依赖基于互联网的 RTC（实时通信）。在过去十年中，RTC 产品的数量呈爆炸式增长，这在很大程度上归功于更便宜的高速网络接入和更强大的设备，同时也归功于一个名为 WebRTC 的开放、免版税平台。WebRTC 正在从实现有用的体验发展成为至关重要的工具，使数十亿人能够在疫情期间继续工作和学习，并保持重要的人际交往。WebRTC 未来的机遇和影响确实令人着迷。
Benjamin Treynor Sloss, Shylaja Nukala, Vivek Rau - 重要的指标
衡量您的站点可靠性指标，设定正确的目标，并努力准确地衡量这些指标。然后，您会发现您的服务运行得更好，停机时间更少，用户采用率也更高。
Silvia Esparrachiari, Tanya Reilly, Ashleigh Rentz - 跟踪和控制微服务依赖关系
如果您曾将钥匙锁在房屋或汽车内，您就会熟悉依赖循环。没有钥匙您就无法打开锁，但没有打开锁您就无法拿到钥匙。有些循环是显而易见的，但更复杂的依赖循环可能很难在它们导致中断之前被发现。跟踪和控制依赖关系策略对于维护可靠的系统是必要的。
Diptanu Gon Choudhury, Timothy Perrett - 为互联网规模服务设计集群调度器
希望构建调度系统的工程师应考虑他们使用的底层基础设施的所有故障模式，并考虑调度系统的操作员如何在租户系统所有者进行故障排除期间配置补救策略，同时帮助保持租户系统的尽可能稳定。
© 保留所有权利。