简介

在我的文章 “用开放标准补充 Creative Commons”（参见 参考资料）中，我阐释了专有的 DRM 技术的问题并提出了一些解决方案。我提供了一个跨浏览器菜单示例，用户可以从该菜单选择使用权的标准权限约束和要求。我的另一篇文章 “使用 ccREL 将 Creative Commons Licensing 集成到内容中”（参见 参考资料）描述了 ccREL 模型，有哪些许可类型可用。我还提供了一个用基于 RDFa 的 XHTML 代码编写的应用程序示例。

在我的文章 “减少在线协作漏洞”（参见 参考资料）中，我解释了如何缓解 SOA 漏洞暴露的风险，如何降低对正常运行时间可用性的服务水平协议（SLA）承诺造成不利影响的几率。我检查了如何为一个 Web 服务确定中断阈值的问题，该服务无法通过 HTTP 对一个要求获得漏洞信息的请求作出响应。

在本文中，我将探索如何解决下载 DRM 内容时遇到的频繁中断问题。我考虑了使用 SLA 来涵盖 DRM 资源，探讨了关于共享资源的正常运行时间可用性的性能测量标准。我还介绍了中断阈值和延迟问题对 DRM 使用标准的影响并提出了一些解决方案。

RDF 概述

Digital Rights Management (DRM) 中的权限实体展示了如何消费资产，如何传递和重用资产上的权利，以及如何管理数字资产 — 无论是否拥有 “共享” 权利。内容所有者能够限制对他们的作品的重用，这导致了众多浏览器选项的产生，这些选项涵盖了各种消费者使用权选择。

内容所有者可以指定约束和价格要求。在消费者访问内容的次数达到某个数量后，内容所有者有权禁用某些使用、传输和共享权利。消费者应该能够使浏览器在一个给定时段内显示或隐藏来自一个数据库的采购历史。

表 1 展示了消费者能够在浏览器上看到的一些使用权选项样例。

问题：频繁中断

数以千计的消费者通过一个包含多种平台的全球网络从浏览器中选择重用、传输、访问和共享来自 DRM 资源的资产。无论他们使用何种使用权，有限的网络资源可能导致长时间的内容下载过程频繁中断。稀缺的 DRM 资源 — CPU、磁盘存储等 — 相互争用以满足每个用户的资源需求。如果这些需求不能在一个指定的时间内得到满足，正常运行时间可用性将低于承诺的标准（99.9 % 或 99.999%），以至于对系统负载造成不利影响，甚至导致出现网络系统崩溃等极端情况。

测试：DRM 服务特性

要确定导致频繁中断的根源，您需要测试 DRM 服务应用程序的特性。每个服务特性的测试包含一些样例问题，它们将帮助您发现问题的原因并建议一些解决方案。

解决方案：SLA

一个可行的解决方案是考虑使用一个 SLA 来涵盖 DRM 资源。SLA 是服务供应商和客户之间的正式协议，承诺根据已定义的水平提供可以量化的网络性能。服务供应商可能是内部 IT 组织、应用程序服务供应商（ASP）、管理服务供应商（MSP）或其他任意类型的服务供应商。

SLA 要么非常笼统，要么非常详细；它通常包含故障发生时服务供应商和客户应该采取的步骤。服务供应商承诺其提供的服务将在某个时间百分比（比如 99.9%）内可用。

服务供应商还能做三件事。首先，它能对最大或平均响应 DRM 服务器时间实施限制。其次，它能限制内容可以被访问或 DRM 资源可以被共享的最大次数。第三，它能在 SLA 停用或网络接口发生更改前通知客户。

如果服务供应商在指定的期限内未能兑现定义的性能水平，客户将获得权利和补救措施。这些权利、补救措施和例外情况随 SLA 不同而不同。客户也许还同意接受一般协议条款的例外情况。

限制包损失

当 SLA 关注最大上传可用性和承诺的带宽时，它们不能为对延迟敏感的应用程序保证一致的响应时间。延迟是一个时间量（通常以毫秒为单位），它表示数据包在两个点之间实现一次往返所需的时间。延迟问题只指数据包完成往返过程所需的时间超过了正常时间。当应用程序生成的音频开始时断时续，或者鼠标光标开始轻微抖动时，您将会注意到延迟问题。

SLA 应该指定一个给定时段（例如 1 个月）内的平均往返延迟和包损失。它应该将平均往返延迟定义为网络和目的地之间的平均往返包传输，将包损失定义为在往返数据传输期间损失的包的百分比。协议应该将这种损失限制到一定水平 — 例如，1% 或更少 — 并指定补救措施，包括付款和赔款，前提是这种损失在协议约定的时期内超过这个水平。

设置中断阈值

从发起请求到发送对此请求的响应之间的时间差可能决定了企业是否会遭受完全拒绝服务（DoS）攻击或关键系统资产被破坏。如果这个时间差非常大，中断阈值会降低到对正常运行时间可用性保证产生负面影响的水平。当正常运行时间可用性将要低于承诺的时间，那么必须要将中断阈值作为性能指标包含进来。

当一个 DRM 服务需要很长的下载时间才能在您的显示器上查看或存储到您的硬盘驱动器上，在下载过程中发生的短暂中断和快速重新连接也许对用户来说不是很明显，即使在一个速度非常高的无线网络上也是如此。即使正在下载中的音乐中断了数次，该音乐听起来仍然像没有出现中断一样。当您移动鼠标时，鼠标光标能够从一个点平滑地移动到另一点，而实际上这种移动已出现数次中断。

这是因为大多数供应商通常并不向用户提供检查下载中断次数的工具，这使得用户很难计算通信中断的次数并确定合理的中断阈值。

解决方案 #1. 开启聊天对话

检查下载中断频率的一种方法是与客户服务或技术支持代表进行一段聊天对话。您将看到一条消息，告知您和该代表的连接已经中断并请求您等待几分钟以重新连接到通信线路上。多数情况下，您无需等待，因为重新连接在几秒内发生。

聊天对话供应商很明智地在聊天中包含一些消息，用于告知对话双方发生了什么连接问题，线路将中断多长时间，重新连接将在什么时间发生。当客户与客户服务或技术支持代表进行对话时，这种解决方案允许呼叫者了解正在使用的通信线路出现了什么问题。

解决方案 #2. 计算加载次数

检查给定时间内的中断频率的另一种方法是计算视频运行完成前 flash 消息重新加载的次数。但与聊天对话不同的是，这种方法并不能告知您每个下载片段停止和重新连接经历了多长时间。

解决方案 #3. 检查您的日志

第 3 种方法是检查您的日志以了解您的网络连接和重新连接的次数，尤其是当您将网络设置为在线路中断后自动重新连接时。例如，如果您发现半小时内有 10 次重新连接，那么您将知道这种频繁的中断是您之所以感到恼怒的原因。这说明中断阈值是不能接受的。如果一个低速网络和一个高速网络在一个给定时段内的网络重新连接次数相同，那么相比之下，低速网络上的这一重新连接次数更加令人难以接受。

如果无线网络通信线路频繁中断，您可能需要检查正在使用的无线设备的无线网络是否正在与您的邻居的无线网络争夺无线频道，即使您已经拒绝它们访问您的系统。

包含例外情况

通过在 SLA 中包含例外情况，服务供应商能够保护自己，免除对自身无法直接控制的事项的责任，比如故障、网络中断、计划维修和其他网络问题。在另一方面，如果竞争服务提供包含更少例外情况的 SLA，客户可以选择那些做出更好的服务承诺、在业务操作中提供更多的正常运行时间的协议。即使是 99.5%、99.9% 和 99.999% 的正常运行时间可用性承诺之间的微小差别也能左右用户对 SLA 的选择。

以下是 SLA 中可能包含的一些例外情况。

结束语

向您的用户提供快速下载是很重要的，下载速度缓慢将使用户选择其他 DRM 内容所有者和服务供应商。因此，DRM 内容所有者和服务供应商面临提供可靠的高正常运行时间可用性的挑战。要使您的开发团队的工作进展更顺利，您应该在用户下载您的基于 DRM 的内容前准备一个 SLA 并与用户签约，从而解决潜在的问题。

参考资料

学习

• 阅读 Judith 的文章 “用开放标准补充 Creative Commons”。
  
  
• 阅读 Judith 的文章 “减少在线协作漏洞”。
  
  
• 查看 My developerWorks，您可以在那里发现和创建关于 Web 开发和其他感兴趣的主题的小组、博客和活动。
  
  
• developerWorks 技术活动和网络广播：随时关注 developerWorks 技术活动和网络广播。
  
  
• developerWorks Web development 专区：通过专门关于 Web 技术的文章和教程，扩展您在网站开发方面的技能。
  
  

获得产品和技术

• 了解 IBM Rational Web Developer for WebSphere Software（架构管理）、IBM Rational ClearQuest（更改和发布管理）和 IBM Rational Functional Tester Plus（质量管理）如何对您开发 Ajax、DRM、Creative Commons Licenses 和其他应用程序提供帮助。这些来自 IBM 的工具能够帮助您减少测试时间，降低您的企业的测试实验室的成本，从而提高企业生产力。
  
  

关于作者

Judith M. Myerson 是一位系统工程师兼架构师。她感兴趣的领域包括中间件技术、企业级系统、数据库技术、应用程序开发、网络管理、安全性和项目管理。

为本文评分

评论

回页首

内容

• 简介
• RDF 概述
• 问题：频繁中断
• 测试：DRM 服务特性
• 解决方案：SLA
• 限制包损失
• 设置中断阈值
• 包含例外情况
• 结束语
• 参考资料
• 关于作者
• 建议