专利名称：用于对等服务编排的可互操作系统和方法
用于对等服务编排的可互操作系统和方法
技术领域：
本发明是下述申请的分案申请
发明名称用于对等服务编排的可互操作系统和方法
申请号:200480021795. 9
国际申请号PCT/US2004/018120
国际申请申请日2004年6月7日
最早的优先权日2003年6月5日
相关专利串请
本专利申请要求共同所有的美国临时专利申请第60/476，357号和第60/504，524号的优先权，前者的发明名称为“用于对等服务编排的系统和方法”，申请人为William Bradley和David Maher，于2003年6月5日提交，后者的发明名称为“数字权限管理引擎系统和方法”，申请人为Gilles Boccon-Gibod，于2003年9月15日提交，这两项专利申请均以全文引用的方式在本文中使用；这两个美国临时专利申请构成了当前说明书/详细说明的一部分，并且附加在此分别作为附录A和B。
版权授权
本专利文档的公开部分包含受版权保护的内容。版权所有人并不反对任何人将本专利文档或专利公开部分复制到专利商标局的专利文件或记录中，但保留其他所有版权。 技术背景
诸如Internet之类的网络已经成为传递数字内容和媒体相关服务的主要媒介。 标准Web服务协议的出现有望加速这一趋势，使公司能够通过标准化机制可以提供跨多个软件平台进行互操作并支持业务服务和用户之间协作的服务。
但是，要实现建立一个互操作和安全的媒体相关服务环境的目标，还存在许多障碍。例如，多个事实上相互重叠的正式标准实际上会限制直接互操作性，由于其迫使不同的实现在基本标准但是另外不兼容的可选技术方法之间进行选择以便解决相同的基本互操作性或互连问题。在某些情况下，这些不兼容性是由于试图集成不同代的技术引起的问题所造成的，在另外一些情况下，这些问题是由于同时运营但处于不同地点、具有不同需求的各方作出的市场选择的结果。因此，尽管存在标准化，但定位和连接提供所需服务的设备并与之交互经常会很困难。而且在不同的信任和保护模型之间经常存在不兼容问题。
尽管诸如WSDL(Web服务描述语言)之类的新兴Web服务标准正在着手为面向 Internet的系统解决一些此类问题，但这些方法并不完善。它们不能跨个人和局域网、家用、企业和部门网关以及广域网等多个网络层解决此类问题。而且，这些标准也不能通过利用各种服务接口绑定(例如，CORBA、WS-1、Java RM1、DCOM、C函数调用和· Net等等)对简单和复杂服务进行动态编排，完全满足互操作性的需要，从而限制了集成许多传统应用的能力。被广泛部署和采用的对等(P2P)应用与网络的出现，进一步增加了创建可互操作的媒体相关服务的困难，其部分原因在于，没有关于如何体现和执行数字内容使用权的统一概念。发明内容
这里描述的系统和方法的实施例可用于解决上述部分或全部问题。在一个实施例中，提供了一种服务框架，该框架使得用户或企业媒体空间中的多个参与者(例如，用户、 内容提供者、设备制造商、服务提供者)能够通过公开的服务接口以丰富的动态方式相互查找、建立信任关系并交换价值。此框架的实施例一般被称为“媒体编排网络环境(NEMO) ”， 它可以提供一个平台，来支持异类消费设备、媒体格式、通信协议和安全机制环境下媒体相关的可互操作的安全的电子商务。服务接口的分布式策略管理可用于帮助提供信任和安全，从而帮助实现商业价值交换。
新兴的Web服务标准正在着手为面向Internet的服务解决互操作性问题，而NEMO 的实施例可用于解决跨个人和局域网、家用、企业和部门网关以及广域网等多个网络层的互操作性问题。例如，NEMO可以在一个使用移动电话、游戏平台、PDA、PC、基于web的内容服务、发现服务、通知服务和更新服务的互连系统中提供互操作性。NEMO的实施例可进一步用于通过各种本地和远程接口绑定(例如，WS-1 [I]、Java RM1、DCOM、C、· Net，等等)来提供对简单和复杂服务的动态对等编排，从而支持传统应用的集成。
在媒体环境中，主要参与者群体(例如内容发布者、分发者、零售商、消费设备提供商和用户)所需要或喜欢的系统和接口常常有很大的不同。因此，最好是将这些实体所提供的功能统一到能够迅速 发展为最佳配置的集成服务中，以满足参与实体的需要。
例如，各种服务发现协议和注册中心(例如蓝牙、UPnP> Rendezvous、JINI> UDDI 和LDAP等等)可共存于同一服务中，这样每个节点都能使用对承载该节点的设备最合适的发现服务。而另一服务可能会支持基于IP和无线SMS通知或各种媒体格式(MP4和WMF等坐')寸/ ο
NEMO的实施例利用对等(P2P)服务编排来实现这些目标。现在人们已经看到P2P 框架在音乐和视频分发等方面的优势，P2P技术的应用可以更加广泛。
Web服务中的大多数活动都集中于具有相对静态网络配置的机器到机器交互和客户端服务交互。NEMO还能处理以下情况，即一个人携带其个人局域网(PAN)设备靠近LAN 或另一个PAN，希望立即重新配置服务访问并在对等基础上连接许多其他服务。
在媒体和各种其他企业服务中，也存在很多应用机会，尤其是两个或多个企业之间的交互。企业大多是按照一定的层次结构进行组织的，其信息系统通常反映了这种组织结构，来自不同企业的人员常常可以通过对等接口更为有效地进行交互。例如，A公司中的收货人员/服务可以通过与B公司的发货人员进行对话来更直接地解决问题或获得有用的信息。交叉层次或不必要的接口一般是没有用的。一些送货公司(例如FedEx和UPS)认识到这一点，因此他们允许客户直接看到其处理，直接对事件进行监视。公司和市政当局通过企业门户来组织其服务，从而形成自然的自助服务。
但是，现有对等框架并不允许一个企业向其用户和提供者公开自己的各种服务接口，让这些实体在自然的对等级别上进行交互，这样这些实体就不能以最适合自己的方式编排该企业的服务。这将要求对那些对等接口的实行某种信任管理机制。利用本发明的优选实施例，不仅允许而且可以促进以P2P方式公开服务接口。
对于诸如DRM(数字权限管理)等特定应用，NEMO的实施例可用于提供面向服务的体系结构，以便解决封闭的同类DRM系统的缺陷与局限性问题。优选实施例可用于为不同的消费设备、媒体格式和安全机制提供媒体相关的可互操作安全商务与操作。
许多传统的DRM系统需要相对复杂的重量级客户端引擎来处理受保护内容，本发明的优选实施例与此不同，它允许客户端DRM引擎相对简单，能够执行由在服务级运行的、 功能更强大的策略管理系统设定的管理策略。本发明的优选实施例还可以在媒体格式和加密协议的选择方面提供更大的灵活性，并且可以促进DRM系统之间的互操作性。
可以使用一种简单、开放且灵活的客户端DRM引擎来构建功能强大的、支持DRM的应用。在一个实施例中，DRM引擎被设计为可以很容易地集成到Web服务环境和几乎任何宿主环境或软件体系结构中。
可利用服务编排来克服互操作性障碍。例如，在出现内容查询请求时，可协调各种服务(例如，发现、搜索、匹配、更新、权限交换和通知)来满足请求。使用具有编排功能的优选实施例，用户可以在动态多层网络的任何一点、从任何设备中查看所有家用和基于 Internet的内容缓存。可以扩展这一功能以促进流和播放列表的共享，使临时广播与小范围广播易于通过许多不同的设备发现和连接，同时确保权限不受侵犯。NEMO的优选实施例提供了一种端到端的可互操作媒体分发系统，该系统不依赖于单一的一组媒体格式、权限管理和实现协议标准。
在包括内容制作者、分发者、零售商、服务提供者、设备制造商和用户的价值链中， 每一环节通常都有许多局部需要。这在权限管理方面尤其如此，在权限管理中，内容制作者可以明确使用权，即对不同的下游价值链元素在各种环境下赋予不同的使 用权。用户网关所关注的范围一般要窄得多，最终用户设备关注的范围可能还要窄一些，具体来说就是仅播放内容。利用自动化程度足够高的动态自配置分发服务的系统，内容制作者可以制作和打包内容，明确权限，并放心地依靠其他服务提供者所提供的增值服务，向感兴趣的用户快速提供内容，而不用考虑用户位于何处，也不用考虑他们使用的是哪种设备。
NEMO的优选实施例通过为多个服务提供者提供创新和引入新服务的途径来实现这一目标，这些新服务让用户和服务提供者均可获益，而不必等待或依赖于单一的一组端到端标准。策略管理可以限制盗版者利用这些合法服务的范围。NEMO所产生的网络效应将鼓励大量合法服务的发展，合法服务提供的价值比盗版者提供的价值更高。
下面讨论一些在许多NEMO实施例中常见的“最佳实践”技巧，其中包括以下内容
将复杂的面向设备的策略和面向服务的策略分开
将比较简单的服务组合成复杂服务
动态配置和广告服务
动态发现和调用异类环境中的各种服务
利用来自简单设备的网关服务
此外，还将介绍一种可以用于NEMO框架的新颖DRM引擎和体系结构。此DRM系统可用于实现以下部分或全部目标
简单。在一个实施例中，提供了一种DRM引擎，它使用最低要求的基于栈的虚拟机 (VM)来执行控制程序(例如，执行管理策略的程序)。例如，此VM可以仅由几页代码组成。
模块化。在一个实施例中，我们把DRM引擎设计成一个单一的模块，它集成在一个支持DRM的更大型应用内。现在，我们可以从宿主环境中请求许多以前由单个DRM内核执行的功能(例如加密服务)，该宿主环境可以向其他代码模块提供这些服务。这使得设计人员能够相对容易地整合标准或专用技术。
灵活性。由于采用模块化设计，DRM引擎的优选实施例可用于从嵌入式设备到通用PC的各种软件环境。
开放。DRM引擎的实施例适合作为参考软件，这样，用户就可以使用几乎任何编程语言和在他们能够完全控制的系统中实现代码模块和API。在一个实施例中，系统并不强制要求用户采用特定的内容格式或限定内容编码。
无关乎语义。在一个实施例中，DRM引擎的基础是一种简单的基于图的模型，该模型将授权请求转换为对图结构的查询。图中的顶点表示系统中的实体，有向边表示这些实体之间的关系。但是，DRM引擎并不需要知道这些顶点和边在任何特定的应用中表示什么。
与Web服务无缝集成。DRM客户端引擎可以采用多种方式使用Web服务。例如， 可以通过服务来动态发现图中的顶点和边。也可以通过高级Web服务来发现内容和内容许可，并将其传递给DRM引擎。尽管一个DRM引擎的具体实施例可以配置在许多地方用于支持Web服务，但是其体系结构与Web服务无关，可以用作一个独立的客户端DRM内核。
简化的密钥管理。在一个实施例中，可以重新使用图拓扑来简化内容保护密钥的派生，而不需要加密重定位。这种密钥派生方法是DRM引擎一个可选特性，但其功能非常强大——系统也可以或者能够与其他密钥管理系统集成。
管理、加密与内容的分离。在一个实施例中，管理内容的控制在逻辑上与用于执行管理的加密信息不同。同样，控制和加密信息在逻辑上也与内容和内容格式不同。可以采用分离的方式或一个统一数据包传递每个元素，这样就可以在设计内容传递系统时具有高度的灵活性。
下面描述NEMO框架的实施例及其应用和组成部分。应该认识到，此框架本身是新颖的，其许多组件和应用也是新颖的。还应该认识到，我们可以采用多种方式来实施本发明，其中包括流程、设备、系统、装置、方法、计算机可读媒介或这些元素的组合。下面的具体说明和附图将详细介 绍这些特点与优势以及其他特点与优势，并且以示例的方式阐释本发明有效主体的原理。
附图简要说明
参照以下结合附图的具体说明，可以很容易地理解本发明的有效主体的实施例，在附图中，类似的参考编号表示类似的结构元素，其中
图1所示为系统框架的示例实施例。
图2a所示为系统节点的概念性网络。
图2b所示为P2P网络中的系统节点。
图2c所示为在Internet运行的系统节点。
图2d所示为系统网关节点。
图2e所示为系统代理节点。
图2f所示为系统设备适配器节点。
图3所示为DRM设备的概念性网络。
图4所示为概念性DRM节点授权图。
图5a所示为系统节点体系结构的概念性视图。
图5b所示为由一个系统节点的服务适配层支持的多个服务接口绑定。
图6a所示为提供服务的系统节点和使用服务的系统节点之间的基本交互。
图6b为提供服务的系统节点和使用服务的系统节点之间的基本交互的另一示例。
图7a所示为客户端WSDL交互中所涉及的服务接入点。
图7b所示为客户端本地交互中所涉及的服务接入点。
图7c所示为服务端点对点交互模式中所涉及的服务接入点。
图7d所示为服务端点对多点交互模式中所涉及的服务接入点。
图7e所示为服务端点对中介体交互模式中所涉及的服务接入点。
图8所示为服务适配层的体系结构的一个实施例。
图9a所示为依赖外部服务提供者的工作流整理器的交互模式。
图9b所示为与客户端节点进行的直接多阶段通信中所涉及的工作流整理器的交互模式。
图9c所示为工作流整理器的基本节点内交互模式。
图9d所示为工作流整理器的相对复杂的交互模式。
图10所示为DRM引擎的系统集成。
图11所示为DRM引擎的体系结构的一个实施例。
图12a所示为客户端系统节点内的DRM引擎和相关元素。
图12b所示为服务端系统节点内的DRM引擎和相关元素。
图13所示为内容保护和管DRM对象的一个实施例。
图14所示为节点和链接DRM对象的一个实施例。
图15所示为DRM加密密钥元素的一个实施例。
图16所示为客户端和服务提供系统节点之间的基本交互模式。
图17a所示为一组通知处理节点，它发现支持通知处理程序服务的节点。
图17b所示为传递通知的过程。
图18a所示为一种客户端驱动的服务发现情形，其中，请求节点向目标服务提供节点发出服务发现请求。
图18b所示为一种对等体注册服务发现情形，其中，请求节点寻求通过服务提供节点注册其说明。
图18c所示为一种基于事件的服务发现情形，其中感兴趣的节点接收一个关于服务可用性变化的通知(例如，服务提供节点中存在一个服务)。
图19a所示为通过与隐式可信信道的服务绑定建立信任的过程。
图19b所示为基于请求/响应模型建立信任的过程。
图19c所示为基于显式安全凭证交换建立信任的过程。
图20所示为由策略管理的服务访问。
图21所示为具有成员身份和密钥访问链接的示例DRM节点图。
图22所示为DRM VM代码模块的格式的一个实施例。
图23所示为系统功能概要的层次结构。
图24所示为DRM音乐播放器的应用情形。
具体实施方式
下面详细说明本发明的有效主体。尽管在进行说明时结合了若干实施例，但应该认识到，本发明的有效主体并不局限于任一实施例，而是包括各种替代、修改和等效体。举例来说，尽管一些实施例是在面向用户的内容和应用的环境下描述的，但熟悉本领域的技术人员会认识到，所公开的系统和方法可以很容易地应用到更广泛的应用中。例如，这些实施例可以很容易地应用于企业内容和应用环境，而没有任何限制。另外，尽管为了帮助全面理解本发明的有效主体而在以下说明中列出了各种具体细节，但是不具备部分或全部此类细节的一些实施例也可以实施。此外，为了清晰起见，对于本领域的技术人员所熟知的某些技术资料没有进行详细说明，以避免不必要地模糊对本发明的有效主体的理解。
1.概念
1. l.ffeb 服务
Web服务体系结构(WSA)是面向服务的体系结构(SOA)的一个具体实例。SOA 本身是一种由松散耦合的协作软件代理组成的分布式系统。SOA中的代理可以提供服务、请求(使用)服务或执行这两种操作。我们可以将服务看作一组定义良好的独立 (self-contained)操作，它们由充当服务提供商角色的代理管理。在一些网络可寻址的位置(称为端点)，可以使用标准协议和数据格式通过网络调用这些操作。“独立”的意思是指，该服务并不直接依赖于另一服务或所涵盖应用的状态或环境。
支持SOA概念的现有技术的例子包括C0RBA、DC0M和J2EE。WSA非常有吸引力，因为它并不局限于特定的平台、编程语言、应用协议栈或数据格式约定。WSA使用基于XML的标准格式来描述服务和交换消息，这促进了提供者与用户之间的松散耦合和互操作性；并且支持多种标准Internet协议(特别是HTTP)，这方便了潜在全局分布式系统中的部署和 参与。
一种新出现的趋势是在“即插即用”服务总线环境中查看S0A。服务总线方法通过利用描述、消息传递和传输标准来提供服务编排。此基础结构还可融入用于发现、转换、安全和其他可能目的的标准。由于其中融入的通用标准的本质特性，因此WSA具有灵活性、可扩展性和可伸缩性，这就为构建编排服务总线模型提供了适当的基础。在这种模型中，基本工作单元(服务)被称为Web服务。
Web服务有很多种定义。以下定义来自万维网联盟(W3C) Web服务体系结构工作草案(2003 年 8 月 8 日，请参阅 www. w3. org/TR/ws-arch)
Web服务是一种软件系统，用于支持通过网络进行的可互操作的机器到机器交互。 它具有一种用机器可处理的格式(具体为WSDL)描述的接口。其他系统使用SOAP消息并以其描述中规定的方式与Web服务进行交互，这些SOAP消息通常通过具有XML序列化的HTTP 协议并结合其他Web相关标准进行传送。
尽管W3C定义提供了一个有用的起点，但应该认识到，这里所使用的术语“Web服务”具有更广泛的意义，而不存在例如使用特定标准、格式和协议(例如WSDL、S0AP、XML和 HTTP等等)的限制。
可以将一个特定Web服务描述为用于一组逻辑上相干的操作的抽象接口，它为服务提供者和服务请求者之间的关系(可能是临时关系)提供基础。
当然，实际的Web服务具有具体的实现。提供者的具体实现有时被称为服务(以与Web服务相区别)。实际上实现服务提供者的功能的软件称为提供者代理，实际上实现服务请求者的功能的软件称为请求者代理。拥有该代理的个人或组织相应地称为提供者实体或请求者实体。当单独使用时，根据上下文，请求者或提供者可以指相应的实体或代理。
Web服务的存在是为了达到一个目的，如何实现这一目的是由特定的Web服务消息交换的技术细节和语义指定的。技术细节是指机器可处理的准确技术规范，其允许通过网络进行消息交换。虽然技术细节具有准确的定义，但语义可能并非如此。语义是指管理请求者实体和提供者实体对于Web服务的理解和总体期望的显式或隐式“契约”，它可以是任意形式的。
通常利用三个角色的交互来建立Web服务的模型(i)服务提供者；(ii)服务请求者；以及(iii)服务注册中心。在这一模型中，服务提供者向服务注册中心“发布”描述其Web服务的信息。服务请求者通过某种发现机制“找到”这一信息，然后利用这一信息“绑定”到服务提供者，以利用此服务。绑定只是表示请求者将通过利用由提供者在发布的服务描述中指定的消息格式化、数据映射和传输协议约定来调用提供者提供的操作。用于描述这一信息的基于XML的语言称为Web服务描述语言(WSDL)。
服务提供者提供对用于某种特定的目的一些操作集合的访问，这些操作通过WSDL 服务描述进行说明；此服务描述被发布到一个注册中心(发布方法多种多样，任一种方法均可)，这样，该服务就能够被发现。注册中心可以是公共的，也可以是在一个特定域内专有的。
服务注册中心是一种通过返回预先发布的服务描述来响应服务搜索请求的软件。 服务请求者是一种软件，它根据从注册中心获得的WSDL中所指定的绑定信息来调用提供者所提供的各种操作。
服务注册中心可以仅在概念上存在，也可以作为实际软件真实存在，提供用于查询、定位和绑定到特定服务 的服务描述的数据库。但是，无论是请求者对一个服务实际进行主动搜索，还是静态或动态地提供服务描述，注册中心都是Web服务模型的一个逻辑上独立的方面。注意到这一点非常重要在实际实现中，服务注册中心可以是服务请求者平台和服务提供者平台的一部分，也可以驻留在另一位置，这一位置完全由某一已知地址或通过一些其他方式提供的地址进行标识。
WSDL服务描述支持松散耦合，而松散耦合是SOA的主旨所在。尽管服务请求者最终将理解服务接口的语义，但是要获得某种期望的结果还是比较耗时的，服务描述将服务接口与特定服务绑定信息隔离开来，并支持高动态的Web服务模型。
面向服务的体系结构可以构建在许多可能的技术层之上。根据目前的实际应用， Web服务通常包括或涉及以下技术层面
HTTP——一种用于大多数Web服务通信的标准应用协议。尽管可以通过各种网络协议(例如，SMTP和FTP等等)部署Web服务，但HTTP是目前使用的最为常见、最容易为防火墙接受的传输协议。对于某些应用，特别是内部网中的一些应用，根据具体要求，其他网络协议可能更为适合；但在当今构建的几乎所有Web服务平台中，都有HTTP的身影。
XML——一种用于格式化和访问结构化信息的内容(以及关于该内容的信息)的标准。XML是一种基于文本、用于在Web服务代理之间传递信息的标准。请注意，使用XML并不意味着Web服务的消息有效载荷不能包含任何二进制数据；但它确实意味着将根据XML 约定设计这些数据的格式。大多数Web服务体系结构不一定要求将消息和数据序列化为字符流——可以仅将它们序列化为有意义的二进制流——但如果使用XML，这些流将代表XML 文档。也就是说，在传输机制层次上，通常使用XML文档进行Web服务消息传递。
对于许多Web服务都特别重要的两个XML技术子集是“XML命名空间”和“XML架构”。XML命名空间用于解决命名冲突和声明XML文档中所包含元素的特定含义。XML架构用于定义和约束XML文档中所包含的各种信息项。尽管有可能(可选)通过其他方式实现这些目标，但使用XML可能是目前最常用的技术。用于Web服务文档本身的XML文档格式描述由XML架构定义，大多数实际Web服务操作和消息本身是结合XML架构进一步定义的。
SOAP——一种基于XML的标准，用于将指令和信息封装在一个具有特定格式的数据包中，以传送给其他接收者并由其进行处理。SOAP(简单对象访问协议)是一种标准机制，用于对Web服务消息进行打包，以在代理之间进行传输。SOAP的命名多少有些用词不当，它的原意是作为一种调用分布式对象的方法，在这方面，它确实比其他替代方式“更简单”;但是近来有一种趋势，就是将SOAP看作一种基于XML的有线通信协议，因为它已经超越了该缩写词的原始含义。
SOAP定义了一个相对轻量级的约定，用于结构化消息，并提供关于内容的信息。每个SOAP文档都包括一个封套，封套分为报头和正文两部分。尽管在结构上有些类似，但报头通常用于元信息或指令，以便相关接收者处理正文中所包含的内容。
SOAP还指定了一种方法，用于识别要素和完成所述要素的功能所需的处理。消息交换模式(MEP)是一个为如何在节点之间交换消息定义模式的要素。一种常见的MEP是请求-响应，它在请求节点和响应节点之间建立单一完整的消息事务(请参见http://ww w. w3. orR/TR/2003/REC-soapl2-part2-20030624/#soapsupmep)。
WSDL——一种基于XML的标准，用于描述如何使用Web服务。从WSDL的角度来看，服务涉及一组在服务请求者和服务提供者之间交换的消息。消息是采用一种可以映射到特定协议的抽象方式来描述的。调用某些功能的消息交换称为操作。一组特定操作定义一个接口。接口通过命名绑定与具体的消息格式和协议相关联。绑定(接口到具体协议的映射)与一个适合该协议的URI相关联，从而得到一个端点。一个或多个相关端点(在特定URI上将接口映射到具体协议)的集合构成一个服务。
这些定义映射到特定的WSDL元素
类型用于类型定义的容器元素消息正在发送的数据的类型的抽象定义操作基于输入、输出和默认消息的组合对一个动作的抽象说明portType操作的抽象集合-接口绑定指定接口(portType)的具体协议和数据格式端口绑定和实际网络地址的组合——端点服务一■组相关端口(端点)
WSDL定义了一种通用绑定机制，并相应地定义了对SOAP、HTTP GET/POST和MME 的特定绑定扩展。因此，绑定并不一定意味着直接绑定到一种传输协议，而是绑定到一种特定的有线格式。最常见的Web服务绑定是S0AP，不过实际的SOAP消息交换通常是通过HTTP 在端口 80上进行的(通过http://URI)。但是，可以将接口直接绑定到HTTP;或者(举例来说)，S0AP的绑定可以使用SMTP (通过mailto://URI))。实现甚至可以定义自己的有线格式，并使用自定义的绑定扩展。
WSDL通过对〈import〉元素提供支持来促进可维护性和可重用性。通过导入，可以采用适合一个组织的方式将WSDL文档分为若干单独的部分。对于一个希望在接口定义和实现定义之间有一定隔离的内聚Web服务环境而言，将WSDL文档分为以下三个文档是比较合理的
架构(.xsd)文档-根节点为<schema>，命名空间为“http://www.w3 .org/2001/XMLSchema”。服务接口描述，包含被认为是可重^分的内容 〈message〉<portType>〈binding〉服务实现定义，包含特定服务端点 〈service〉
WSDL接口与Java(或IDL，或某些其他编程语言)接口不完全一致。例如，Java接口声明指定一组方法，这组方法必须与声明实现该接口的类的至少一个方法子集相匹配。 可以实现接口的类不止一个，而且每个实现可以各不相同；但方法签名(方法名称和任何输入或输出类型)通常必须相同。这是该语言所要求的，并在编译时、运行时或这两个时间执行。
WSDL接口是不同的，它更类似于单独使用时并不非常有用的实际抽象类。一个 Web服务的各种WSDL接口或portType在逻辑上是相关的，也就是说，这组操作名称应该是相同的(就像PortType事实上确实实现了在其他某一位置定义的特定契约，但实际上并不存在这一元素，并且不存在用于执行portType对称性的机制)。通常对每个portType都进行命名以标识其支持的绑定类型(即使portType本身并不创建绑定)。尽管相关portType 的portType操作的名称相同，但是输入、输出和默认消息(如果存在)映射到特定的消息， 该消息中包含对于支持特定绑定所必需的命名部分。这样就得出一个结论消息本身并不是完全抽象的。Web服务可以且经常需要为各种所需绑定定义类似但不同的消息。
如下所述，通过利用新出现的Web服务和相关标准，可以开发一种系统体系结构来促进网络化的可互操作媒体相关服务的创建，这些服务利用跨各种各样的硬件和软件平台以及操作环境的多种不同协议和接口。
1.2.角色
本发明的优选实施例旨在实现、促进和/或积极支持对等环境，在此环境中，对等方可以通过公开服务自发地提供各种功能。该框架的一个实施例不鼓励将对等方看作具有一组固定的功能，相反，鼓励这样一种模型，即其中对等方在任何时刻都是一个或多个角色的参与者。
角色可由给定对等方结合特定行为模式公开的一组服务定义。在任意给定时刻， 一个支持NEMO的节点可以根据以下多种因素扮演多个角色它的实际实现工作(提供用于支持一组给定服务的功能)、管理配置、声明该对等方能够公开的服务的信息，以及服务接口上的载荷和运行时策略。
可以根据各种不同类型的服务定义一组显式角色。随着时间的推移，在确定公共参与模型以及引入新服务之后，就可以定义一个更为正式的角色分类方案。可以随着时间的推移而正式确定的一组主要角色可能包括
客户端——一个相对简单的角色，其中没有公开服务，此对等方只使用其他对等方的服务。
授权者——此角色代表一个充当策略决定点(PDP)的对等方，确定请求委托者是否可以访问具有一组给定前置条件和后置条件的指定资源。
网关——在某些情况下，对等方也许不能直接发现其他服务提供者或者不能与之交互，其原因包括传输协议不兼容、不能协商信任环境，或者不具备创建和处理与某个给定服务相关的必要消息的处理能力。网关是一个对等方，它用作通往另一对等方的桥梁，以便该允许对等方与服务提供者进行交互。从身份和建立操作的授权及信任环境的角度来看，请求对等方可以将其身份实际委托给网关对等方，并让该对等方代表自己进行协商并作出决定。或者，网关对等方可以充当一个简单的中继点，转发或路由请求和响应。
编排器——当与一组服务提供者的交互涉及重要的服务协调时(可能包括事务、 分布式状态管理等等)，一个对等方的能力可能不足以参与。编排器是网关角色的具体化。 对等方可以请求编排器作为其代表，参与提供一个或多个服务。编排对等方可以使用特定的附加NEMO组件(如适当配置的工作流整理器)，以满足编排需要。
考虑到“通过在符合任何一组适合的使用规则的任何设备上、在任何时间、在任何位置满足来自任何来源、对任何媒体的任何格式的请求，做到即时满意”的目标，以下非正式模型阐释了如何利用NEMO框架的实施例来实现这一目标。从该模型的最高层中可以清楚看到N EMO如何支持将来自模型中各层的较低层服务组合成更丰富的端到端媒体服务 (没有一一列举NEMO如何支持人们可以想到的所有媒体服务的各个方面)。
在该模型的一个实施例中，有四个服务组件层1)内容创制、组合和打包服务；2) 基于Web的内容收集和发布服务；3)家用网关服务；4)消费电子设备。
这四个层中的每一层在安全、权限管理、服务发现、服务编排、用户界面复杂性和其他服务特性方面通常都有不同的要求。前两层大体适合于我们在“传统"Web服务中看到的模型，而后两层更适合可称为“个人逻辑网络模型”的模型，家用网关的某些服务处于这两种类型的模型之间。但是，消费电子设备的服务有时可以出现在任一层中。
这里存在一种两难选择，即一方面希望框架的组成部分专门化，以提高实现效率， 另一方面又希望其通用化程度足够高，以包括端对端解决方案。例如，UDDI目录和发现方法对于相对静态和集中的Web服务可以正常工作，但对于更为动态的个人网络的瞬时组合， 象UPnP和Rendezvous中使用的发现模型可能更合适。因此，在一些实施例中，在框架中提供了多个发现标准。
与此类似，在将权限管理应用于通过批发、聚合、零售分发子层进行的媒体分发时，就可能有许多不同类型的复杂权限和责任需要表达和跟踪，这就需要一种具有丰富表达能力的复杂权限语言、高级内容管理和清除服务以及全局信任模型。但是，用于家用网关和消费电子设备层的权限管理和内容管理可能需要一种不同的信任模型来强调合理使用权，从用户的角度来看，它们较为简单。个人逻辑网络中的对等设备可能希望使用该网络中比较简单的信任模型进行交互，并且能够利用全局信任模型通过广域网与对等方进行交互 (可能通过代理网关服务)。在用户端，跨设备对内容可用性进行自动管理会带来复杂性， 这些设备中的一部分是可移动的，并且有时会跨多个网络。因此，在支持端对端分发的同时进行有效权限管理的方法也可能是异类的，支持各种权限管理服务，其中包含的一些服务可以解释分发权的表达式，并根据上下文将它们转换为与销售事务编排在一起的事务(或者可能执行预定权的另一事件)中各个用户的使用权。
1.3.逻辑模型
在一个实施 例中，系统框架由一组在逻辑上连接在一起的节点的集合组成，这些节点以对等(P2P)方式进行交互。对等计算通常定义为计算机和其他智能设备之间的资源 (如硬盘和处理周期)共享。请参见http://www.1ntel.com/cure/peer.htm。在这里,P2P 可看作是一种通信模型，它允许网络节点对称地使用和提供各种类型的服务。通过对等消息传递和工作流整理，可以从一组更基础的异构服务动态创建多种服务。这样在共享资源为许多不同类型的服务时，甚至在使用不同服务绑定时，可以检查P2P计算的可能性。
不同实施例可以提供媒体服务框架，使参与者(例如，用户、内容提供者、设备制造商和服务提供者)能够相互查找、交互、交换价值和以丰富的动态方式进行协作。这些不同类型的服务的范围包括从基本服务(发现、通知、搜索和文件共享)到更复杂更高级的服务(例如保险箱、许可、匹配、授权、支付交易和更新)以及这些服务的部分或全部的组合。
服务可以分布在多个对等通信节点上，每个节点都利用为此框架设计的消息泵和工作流整理器(在下文中将进行更详细的说明)来提供消息路由和消息编排。
节点之间通过发出服务调用请求和接收响应来进行交互。请求和响应消息的格式和有效载荷最好采用基于标准XML架构的Web服务描述语言(例如WSDL)定义，所述语言包括一组可扩展的数据类型，支持对服务及其相关接口绑定进行描述和组合。WSDL中的许多对象类型是多态的，可以对其进行扩展以支持新功能。此系统框架支持构建各种通信模式， 其中既有与单一服务提供者的直接交互，也有将来自多个服务提供者的服务重新编排所得到的复杂聚合。在一个实施例中，该框架支持使用现有服务编排标准(WSCI和BPEL等)的基本机制，此外，还允许服务提供者使用自己的约定。
与服务调用相关的消息语法最好采用一种相对灵活和可移植的方式来描述，与系统框架中所使用的核心数据类型一样。在一个实施例中，使用WSDL提供相对简单的方式来引用与所描述服务相关的语义描述，从而完成对消息语法的描述。
一个服务接口可以具有一个或多个服务绑定。在这样一个实施例中，只要节点的接口绑定可以用(举例来说)WSDL表示，并且请求节点可以支持与该绑定相关的约定和协议，请求节点就可以调用所述另一节点的接口。例如，如果一个节点支持Web服务接口，则可能会要求一个请求节点支持SOAP、HTTP和WS-Security等等。
可以通过直接提供权限管理要素的标准化方式来控制(例如通过权限管理)任何服务接口。节点之间的交互可以看作受控操作。
实际上，可以将任何类型的设备(实际的或虚拟的)看作是潜在支持NEMO的，并能够实现NEMO框架的关键方面。例如，设备类型包括消费电子设备、网络服务和软件客户端。在一个优选实施例中，支持NEMO的设备(节点)通常包括以下部分或全部逻辑模块 (在下文中将进行更详细的讨论)
本地服务API——设备实现的一个或多个服务的集合。不需要NEMO节点直接或间接地在NEMO框架中公开任何服务。
本地服务实现——本地服务API的相应实现集。
服务适配层——一种逻辑层，通过该逻辑层，可以使用一个或多个用(举例来说) WSDL描述的可发现绑定来访问实体的本地服务中的公开子集。
框架支持库——为使用NEMO框架提供支持功能的组件，包括对调用服务接口、消息处理和服务编排等的支持。
1. 4.术语
在一个实施例中，一个基本WSDL概要定义了最小的一组“核心”数据类型和消息， 用于支持交互模式和基础结构功能。用户既可以基于这一核心采用特殊方式直接定义或通过某种形式的标准化过程来定义其他概要，添加新的数据和服务类型以及扩展现有的数据和类型。在一个实施例中，这一核心概要包括对以下部分或全部主要基本数据类型的定乂
节点——代表系统框架中的一个参与者。一个节 点可以扮演包括服务用户和/或服务提供者在内的多种角色。节点可以采用多种形式实现，其中包括消费电子设备、软件代理(如媒体播放器)、虚拟服务提供者(如内容搜索引擎)、DRM许可证提供商或内容保险箱。
设备——-封装对虚拟或物理设备的表示。
用户——-封装对客户端用户的表示。
请求-封装对一组目标节点的服务请求。
请求输入. 封装请求的输入。
响应——-封装与请求相关的响应。
请求结果——封装与某请求相关的响应中的结果。
服务——-封装对一组定义良好的功能的表示，这些功能由提供者节点公开或提供。例如，它可以是在移动电话之类的设备中提供的低级功能(例如语音识别服务)，也可以是通过万维网提供的复合功能(例如购物服务)。服务可以涵盖各种各样的应用，其中包括与DRM相关的服务，例如客户端个性化和许可证获取。
服务提供者——公开某组服务的实体(例如节点或设备)。潜在的服务提供者包括消费电子设备(如移动电话、PDA、便携式媒体播放器和家用网关)以及网络运营商(如有线电视运营商)、移动网络提供商、基于Web的零售商和内容许可证提供商。
服务接口——与一个或多个服务交互的定义良好的方式。
服务绑定——封装与服务进行通信的特定方式，包括用于调用服务接口的约定和协议。它们可以通过各种定义良好的方式进行表示，例如WS-1标准XML协议、基于WSDL定义的RPC或者来自DLL的函数调用。
服务接入点(SAP)——封装使得节点可以对一组目标服务提供节点发出服务调用请求并接收一组响应的必要功能。
工作流整理器(WFC)——一种服务编排机制，它提供一个公共接口，通过该接口， 节点可以管理和处理与服务调用相关的请求与响应集合。此接口提供一些基本构造块，用于通过管理与服务相关的消息来编排服务。
对于特定的应用(如数字权限管理[DRM])，典型概要可能包括用于下列内容保护和管理对象的各种DRM相关服务(在下文中将进行说明)，这些对象表示系统中的实体，保护内容，将使用规则与内容相关联，并在接收到请求时确定是否准予访问
内容弓丨用——封装对内容项的引用或指针的表示。此类引用通常利用其他标准化方式来描述内容格式和位置等。
DRM引用——封装对数字权限管理格式的说明的引用或指针的表示。
链接——实体(如节点)之间的链接。
内容——表示媒体或其他内容。
内容密钥——表示用于加密内容的加密密钥。
控制——表示控制与内容的交互的使用规则或其他规则。
控制器——表示控制与内容密钥对象之间的关联。
投射器——表示内容与内容密钥对象之间的关联。在一个实施例中，核心概要包括对以下部分或全部基本服务的定义
授权——授权某参与者访问一个服务的请求或响应。
管理——对某项(例如，音乐文件、文档或服务操作)执行授权或控制影响的过程，例如下载或安装软件升级版本的功能。管理通常与提供如信任管理、策略管理和内容保护的功能的服务进行交互。
消息路由——提供消息路由功能的请求或响应，消息路由功能包括使服务提供节点转发消息或收集和组合消息的功能。
节点注册——为节点执行注册操作从而使该节点可以通过中间节点被发现的请求或响应。
节点发现(查询)-与发现节点相关的请求或响应。
通知——将目标通知消息发送或传递到一组给定节点的请求或响应。
安全凭证交换——与允许节点交换安全相关信息(如密钥对和证书等)有关的请求或响应。
服务发现(查询)——与发现由某组节点(包含一个或多个节点)提供的服务相关的请求或响应。
服务编排——根据服务提供者指定的规则，将服务组合成可管理的粗粒度服务、 可重用的组件或完整的应用。这样的例子包括基于提供者身份的规则、服务类型、访问服务的方法、组合服务的顺序，等等。
信任管理——提供一组通用的约定和协议，用于为节点之间的交互创建授权和信任环境。在某些实施例中，NEMO信任管理可利用和/或扩展现有的安全规范与机制，包括 Web 服务领域中的 WS-Security 和 WS-Policy。
升级——表示有关接收功能升级的请求或响应。在一个实施例中，完全抽象此服务以及提供具体表示的其他概要。
1.5.节点之间的交互情况说明
如下文中更为详细的讨论所述，两个系统节点(服务请求者和服务提供者)之间的基本逻辑交互通常包括以下事件序列。从服务请求节点的角度来看
服务请求节点发出服务发现请求，以定位支持NEMO的节点，这些节点能够利用所指定的服务绑定来提供必要服务。节点可以选择缓存关于被发现的服务的信息。节点之间用于服务发现的接口 /机制可以恰恰是NEMO节点选择实现的另一服务。
在发现候选服务提供节点之后，请求节点可以向基于特定服务绑定的一个或多个服务提供节点发送请求。
在一个实施例中，希望相互安全通信的两个节点将建立信任关系，以便交换WSDL 消息。例如，它们可以协商一组兼容的信任凭证(例如X. 500证书和设备密钥等)，这些凭证可用于确定身份、验证授权和建立安全通道，等等。在某些情况下，这些凭证的协商可能是服务接口绑定(例如WS-Security (在使用WS-1 XML协议的情况下)或两个已知节点之间的SSL请求)的一个隐式属性。在其他情况下，对信任凭证的协商可能是一个显式的单独步骤。在一个实施例中，由一个给定节点负责确定哪些凭证足以与另一节点交互，并决定它是否可以信任一个给定节点 。
请求节点生成与请求的服务相对应的适当WSDL请求消息。
在生成消息后，即将其发送到目标服务提供节点。根据服务绑定，请求的通信方式可以是例如同步或异步RPC方式，也可以是面向消息的。服务请求的发送和响应的接收可以由设备直接完成，也可以通过NEMO服务代理完成。服务代理(将在下文中进行描述)提供了用于向其他参与者发送消息的抽象和接口，并可以隐藏某些服务绑定问题，例如兼容消息格式、传输机制和消息路由问题，等等。
在发送请求之后，请求节点通常会接收到一个或多个响应。根据服务接口绑定的细节和请求节点的首选设置，可以采用多种方式返回响应，其中包括(举例来说)RPC方式的响应或通知消息。所述响应在到目标节点的途中可以通过其他中间节点，这些中间节点可以提供许多相关服务，其中包括(举例来说)路由、信任协商、整理和关联功能，等等。
请求节点对响应进行验证，以确保响应符合它与服务请求节点之间已协商好的信任语义。
然后根据消息载荷类型和内容进行适当处理。
从服务提供节点的角度来看，事件序列通常包括以下内容
确定是否支持请求的服务。在一个实施例中，NEMO框架并没有规定服务接口如何映射为服务的入口点的方式和粒度。在最简单的情况下，服务接口可以明确地映射到给定服务，而绑定服务和调用服务的动作可以构成对服务的支持。但是，在一些实施例中，单个服务接口可以处理多种类型的请求；给定服务类型可能会包含其他属性，在确定节点支持特别期望的功能之前，需要对这些属性进行检查。
在一些情况下，服务提供者需要确定它是否相信请求节点，并协商一组兼容的信任凭证。在一个实施例中，无论服务提供者是否确定信任请求节点，都将应用与服务接口相关的策略。
服务提供者确定授权请求，并将其发送给负责授权对接口的访问的节点，以确定请求节点是否具有访问权限。在许多情况下，授权节点和服务提供节点是相同的实体，授权请求的发送与处理是本地操作，可以通过一种轻量级服务接口绑定(例如C函数入口点) 调用这些操作。
接收到授权响应后，如果请求节点获得授权，服务提供者将满足该请求。如果未获得授权，则生成一个适当的响应消息。
根据服务接口绑定和请求节点的首选设置返回该响应消息。在路由到请求节点的过程中，消息可以通过其他中间节点，这些中间节点可以提供必要的服务或“增值”服务。例如，中间节点可能提供路由和信任协商，或向可以采用请求节点可接受的方式来传递消息的通知处理节点传递消息。“增值”服务的一个例子是赠券服务，如果该服务了解到请求节点的意向，就会将赠券追加到消息中。
2.系统体系结构
请看NEMO系统框架的一个示例实施例，如图1所示，它实现了一个DRM应用。
如上所述，NEMO节点可以通过发出服务调用请求和接收响应进行交互。NEMO框架支持构建多种不同的通信模式，既有与单个服务提供者的简单点对点交互，也有将来自多个服务提供者的服务编排成一组服务的复杂聚合。
在图1中，NEMO节点与另一节点进行交互，以提供各种服务，这些服务聚合起来实现一个音乐许可系统。Web音乐零售商120可以提取存储在用户音乐保险箱110中的音乐， 并通过娱乐家用网关130将其提供给在家中的终端用户。来自用户音乐保险箱110的音乐可能包括一些管理规则，在规则允许范围内，可以向Web音乐零售商120提供此类音乐，然后由他们将其提供给其他用户，进一步使用和分发。娱乐家用网关130是一种可以用来播放此类音乐(及其视频和其他内容)的工具，例如，在用户的家用PC上(例如，通过PC软件视频播放器140)，或者在用户的便携式播放设备上(例如，便携式音乐播放器150)。例如，用户可以带着便携式音乐播放器150旅行,通过无线Internet连接(例如连接到数字权限许可服务160)获得许可，以购买其他歌曲，或者增加重新播放现有的歌曲次数，甚至通过软件升级服务170给便携式音乐播放器150增加新功能。
NEMO节点可以采用多种不同的方式相互交互和与其他设备交互。如图2a所示， NEMO主机是承载至少一个NEMO节点的某种型号的机器或设备。主机可以位于个人局域网 210内，或者位于可以通过Internet访问的远程位置220。例如，主机可能是服务器230、桌面PC 240、便携式计算机250或个人数字助260。
NEMO节点是一种软件代理，它可以向其他节点(例如提供第三方Web服务的主机 235)提供服务，也可以调用NEMO管理的框架中其他节点的服务。一些节点270通过专用通信信道(如蓝牙)系留到另一主机。这些主机240和250具有网络连接性，并具有足够的处理能力向其他参与的NEMO节点提供一个虚拟节点。
如图2b所示，NEMO节点可以是本地或个人局域网210中的一个完整对等方。节点共享公开和调用服务的对称功能；但是，每个节点提供的服务集合通常并不完全相同。节点可以广告自己的服务，也可以接收对它们提供的服务的查询。
如果存在Internet连接,如图2c所示,则本地NEMO节点(例如位于个人局域网 210中)也可以访问远程节点220的服务。取决于本地网络配置和策略，本地节点和远程节点(例如支持Internet的NEMO主机280)也可以作为NMEO对等方进行互操作。
如图2d所示，并不是所有的NEMO节点都可以位于能够与其他主机通信的主机上， 无论本地节点还是远程节点，情况均是如此。NEMO主机280可以提供一种网关服务，通过这种网关服务，一个节点可以调用另一节点(例如系留节点285或个人局域网210中的节点)的服务。
如图2e所示，系留设备上的节点295可以通过网关访问其他节点的服务，如上文中所讨论的。其他节点也可以通过另一主机290上的代理服务对节点295进行访问。代理服务创建一个运行于NEMO主机上的虚拟节点。这些代理节点可以是完整的NEMO对等方。
如图2f所示，NEMO主机可以通过NEMO节点适配器为系留设备提供专门支持。专用通信信道296用于主机/NEMO设备适配器297和系留节点298之间的通信，可以使用任何适合的协议。系留节点298并不能看到其他NEMO对等节点，其他NEMO对等节点也看不到它。
接下来请看数字权限管理(DRM)的功能示例，DRM可以由某些实施例中支持NEMO 的设备提供，也可以用于NEMO环境之外。如上所述，NEMO系统框架的优选实施例的主要目的之一就是，支持开发跨商业网络层和面向用户的媒体网络层的媒体相关服务之间的可互操作安全互连。除了服务连接性之外，媒体相关服务之间的互操作性经常需要对通过这些服务施加到可用内容上的使用权进行协调管理。NEMO服务和这里描述的示例DRM引擎可以组合起来使用，以实现互操作性，所述互操作性允许基于NEMO框架的设备就可以为用户提供无缝呈现的感觉和使用体验，甚至在面对异类的DRM和媒体格式基础结构时同样如此。
对于DRM应用程序，如图3所示，支持NEMO的DRM设备的网络可以包括内容提供者/服务器310 (为其他DRM设备打包内容)以及用户PC播放器330和用户PC包装器/ 播放器320(不仅可以播放受保护的内容，而且还可以打包内容，以便将其传递到便携式设备 340)。
在每个DRM设备中，DRM引擎都执行特定的DRM功能(例如，执行许可条款和向主机应用提供密钥等等)，并依赖于主机能够最有效地提供的服务(例如，加密、解密和文件管理)的主机应用。
如下文中更为详细的讨论所述，在一个实施例中，DRM引擎包括一个虚拟机(VM)， 用于决定是否允许对受 保护内容进行某些特定操作。我们可以利用最小限度的一组指令将这一控制VM实现为一个简单的基于栈的机器。在一个实施例中，它能够执行逻辑和算术计算，并从主机环境中查询状态信息，以便检查诸如系统时间和计数器状态等参数。
在一个实施例中，DRM引擎利用一个基于图的算法来验证DRM价值链中两个实体之间的关系。图4说明了此类图的概念性实施例。该图包括一组由链接连接的节点或顶点。系统中的每个实体都可以由顶点对象表示。只有当实体需要由链接对象引用或者作为加密目标信息的接收方时，才需要具有对应的顶点对象。在一个实施例中，顶点通常代表用户、设备或组。顶点对象也具有相关属性，这些属性表示与该顶点相关的实体的某些特定属性。
例如，图4显示了两个用户(Xan和Knox)、两台设备(Mac和便携式设备)和若干代表组的实体(Carey家庭的成员、公共图书馆的成员、特定音乐服务的订户、RIAA认可的设备，以及由特定公司生产的设备)。其中每个都具有与之相关的顶点对象。
链接的语义可能会随应用特定的方式发生变化。例如，从Mac顶点到Knox顶点的有向边可能表示Knox是Mac的所有者。从Knox到公共图书馆的边可能表示Knox是该公共图书馆的一名成员。在一个实施例中，DRM引擎并不强加或解释这些语义，它只是确定图中是否存在路径。可以将此顶点图看作一个“授权”图，因为两个顶点之间存在路径或(直接或间接)关系可以解释为授权一个顶点访问另一顶点。
例如，因为Knox链接到Carey家,并且Carey家链接到音乐服务,所以在Knox和音乐服务之间存在路径。当存在从另一个顶点到音乐服务的路径时，就认为可以从该顶点访问音乐服务顶点。从而可以编写一个控制，该控制允许基于以下条件访问受保护内容，即可以从其中正在执行请求访问的应用(例如，DRM客户端主机应用)的便携式设备访问音乐服务。
例如，内容所有者可以创建一个由控制VM解释的控制程序，如果使用设备归公共图书馆的成员所有并被RIAA认可，则允许播放特定的音乐片断。当运行于该设备的控制VM 评估此控制程序时，DRM引擎确定在便携式设备和公共图书馆之间以及便携式设备和RIAA 认可之间是否存在链接。图中的边与顶点可以是静态的，内置在设备之中，也可以是动态的，通过与主机应用通信的服务被发现。
由于没有对顶点和链接强加语义，因此DRM引擎可以支持更大的灵活性。该系统可适用于从传统的基于委托的策略系统到授权域和个人局域网的许多使用模型。
在一个实施例中，DRM客户端还可以重用授权图来派生内容保护密钥。系统设计人员可能会选择允许链接的存在也表示某些加密信息的共享。在这些情况下，授权图可用于派生内容密钥，而无需显式加密重定位到使用设备。
3.节点体系结构
3.1.概述
任何类型的设备(物理的或虚拟的)，包括消费电子设备、网络服务或软件代理， 都可以潜在支持ΝΕΜ0，这意味着可以采用某种方式扩展设备的功能，使其能够参与到 NEMO系统中。在一个实施例中，支持NEMO的设备(节点)在概念上由某些特定的标准模块组成，如图5a所示。
本地服务API 510表示设备实现的一个或多个服务的逻辑组合。不需要NEMO节点直接或间接公开任何服务。本地服务实现520表示本机服务API对应的一组实现。
服务接入点530提供对调用公开服务接口的支持。它封装了必要的功能，使用这些功能，NEMO节点可以向一组目标服务提供NEMO节点发出服务调用请求，并接收一组响应。支持NEMO的节点可能会使用各种发现、名称解析和传输协议，因此有必要创建一种灵活且可扩展的通信API。服务接入点可以采用适合特定执行环境和应用框架样式的各种方法来实现。用于其接口的一个通用模型将是一个能够以某种形式接收XML消息和返回XML 消息的接口。也可以支持具有多个本地接口的其他模型。
NEMO服务适配层540表示一个可选层，通过该层，可以利用一个或多个可发现绑定来访问一个实体的本地服务的公开子集。它提供了一个高于本地服务API的抽象级别， 从而使服务提供者能够更容易地支持多种类型的服务接口绑定。在服务适配层不存在的情况下，如果它支持必要的通信协议，那么它仍然有可能通过服务接入点530直接与服务交互。
服务适配层540为服务提供者提供了一种通用的方法，用于公开服务、处理请求和响应，以及在NMEO框架中编排服务。它是发布服务的一个逻辑点，并且为实现其他特定服务接口绑定提供了基础。
除了提供一种通用方法来向其他支持NEMO的节点公开服务提供者的本地服务之外，服务适配层540还提供一个自然位置，在这个位置上对组件进行分层，以支持附加的服务接口绑定560，如图5b所示。通过支持附加的服务接口绑定，服务提供者增加了通过服务接入点或某一其他本地API协商和使用兼容绑定的可能性。
在图5a中，工作流整理器550提供对服务消息管理和服务编排的支持。它提供一个公共接口，允许节点管理和处理请求集合以及响应消息。此接口反过来还提供了一些基本构造块，用于通过管理与这些服务相关的消息来编排服务。此接口通常由支持消息路由功能以及中间消息队列和消息整理的节点来实现。
在一些实施例中，NEMO框架包括一组可选支持服务，这些服务便于实体参与到网络中。可以根据各种功能类型以及需要此类服务(例如支持客户端应用的服务，与服务提供者所需要的服务相对)的实体类型对这些服务进行分类。典型的支持服务包括
WSDL格式化和处理例程——提供创建和处理基于WSDL的服务消息的功能。
服务缓存——提供一个公共接口，通过该接口，节点可以管理发现的节点及其所支持的服务之间的一组映射。
通知处理器接口——提供一个通用服务提供者接口，用于将支持通知处理的NEMO 节点扩展到某些定义良好的通知处理引擎。
其他支持功能——包括消息ID生成、时间戳等例程。
3. 2.基本的节点交互
在更具体地讨论NEMO节点的单个体系结构元素之前，理解这些节点之间的交互和通信的方式是十分有益的。NEMO节点支持多种通信方式，包括同步RPC通信、异步RPC通信以及单向接口调用和客户端回调等通信方式。
异步RPC传递方式——如果请求需要在较长的时间内才能处理完成，而客户端又不想等待，则特别适合使用此模型。客户端提交一个请求，希望服务提供节点以异步方式处理请求。在这种情况下，服务提供端点可能做出响应，表明它不支持这种模型，或者，如果服务提供节点支持此模型，它返回的响应将携带一个标签，在其后的请求中可以将这个凭证提交给指定的服务提供节点，以确定该指定节点有一个对该客户端的请求的响应。
在一个实施例中，支持此模型的任何服务提供端点都必须根据内部策略缓存对未决的客户端请求的响应。如果客户端想要收回与此类请求相关的标签，但是得不到任何响应，或者响应被服务提供节点丢弃，那么将会返回一个相应的出错响应。在这一实施例中， 将由客户端确定何时做出此类后续请求，以尝试收回响应标签。
同步RPC传递方式——客户端提交请求，然后等待返回一个或多个响应。支持 NEMO的服务提供端点可能做出响应，表明它不支持此模型。
基于消息的传递方式——客户端提交一个请求，表明它想要通过与其一个或多个通知处理服务接口相关联的消息通知来接收任何响应。支持NEMO的服务提供端点可能做出响应，表明它不支持此模型。
从客户端应用的角度看，使用上述任何一种交互模式都不需要必需阻塞和等待响应或显式轮询的体系结构。采用以上传递方式机制，我们可以使用线程或其他与平台有关的机制来模拟拥塞和无拥塞语义。另外，以上任何一种方式都不是为了解决特定通信信道的延迟问题——只有在实际处理请求时才有可能产生延迟。通信信道的延迟问题应该在组件(例如服务接入点)具体实现时或直接在客户端的实现中解决。
3. 3.服务接入点
如上所述，服务接入点(SAP)可作为通用的可重复使用API，供服务调用。它可以封装协商结果(negotiation),并可使用传输信道。例如,一些传输信道可能要求通过TCP/ IP建立的SSL会话，而另外一些信道可能仅支持UDP/IP上的相对不可靠通信，还有一些信道则可能根本不是基于IP的。
SAP可以封装对一组初始NEMO节点的发现，以进行消息路由。例如，一个有线机顶盒可能会有一个专用网络连接，而且要求所有消息都必须通过特定的路径和中间转发设备。家庭网络中的便携式媒体播放器可以使用UpnP发现来查找多个可直接访问的节点。客户端可能不能够或不选择通过交换XML消息来直接与其他NEMO节点进行会话。在这种情况下，可以使用公开和使用所支持的本地接口的SAP版本。
在优选实施例中，SAP模式支 持以下两种常见的通信模型(当然也支持结合了这两种模型的混合模型以及其他一些通信模型)(i)基于消息的通信模型(如上所述)—— SAP生成XML请求消息，并通过一些接口绑定直接与服务提供者交换NEMO消息。(il)本地通信模型——SAP可以通过一些本地通信协议与服务提供者进行交互。SAP可以在内部转换为XML消息，也可以将在框架内其他地方定义的XML消息转换为SAP。
图6a是两个NEMO对等节点之间的交互示例。客户端节点610通过使用NEMO服务接入点(SAP) 620与服务提供节点660进行交互。在本例中，使用了 Web服务协议和标准来公开服务和进行传输。服务提供节点660使用其Web服务层670 (例如，使用基于WSDL 和SOAP的消息传递机制)向节点610等客户端公开其服务。在映射层640 (将SOAP消息映射到SAP接口 620，并反向映射)和信任管理处理层650 (例如，通过在SOAP报头内传送的凭证，该层可以利用WS-Security)的帮助下,客户端节点610的Web服务层630创建并解释SOAP消息。
图6b是另外一个NEMO节点之间的交互示例。服务提供节点682使用SAP 686与客户端节点684进行交互。在本例中，与客户端684相比，服务提供节点682包括一个不同的、但可互操作的信任管理层。具体地说，服务提供节点682包括信任引擎688和授权引擎 690。在本例中，信任引擎688 —般负责加密和解密SOAP消息、验证数字证书和进行其他基本的加密运算，而授权引擎690则负责进行高级别的策略制定。在图6b的示例中，客户端节点684包括一个信任引擎692，但不包括授权引擎。因此，在本例中，客户端节点684能够进行基本的加密运算，并执行一些相对简单的策略(例如，与消息验证级别、机密级别相关的策略等)，但是可能需要依靠节点682评估和执行更高级别的策略，即管理客户端对服务提供节点682所提供的服务和/或内容的使用以及与之的交互。应该注意到，图6b是一个是为了举例说明，而不是为了限制，在其他实施例中，客户端节点684也可能包含一个授权引擎，如果客户端需要遵守一组与指定策略有关的约束，可能就会这样。因此，我们可以看出，根据节点的要求，不同的NEMO对等端可能包含信任管理框架的不同部分。图6b还表明，节点之间的通信链路对传输可以是不可知的。即使在SOAP处理模型中，也可以使用合适的数据编码和/或处理规则。例如，可以用另一种支持不同编码方案的安全模型替代XML安全模型。
服务接入点有多种实现形式，例如在客户端边界内实现(以共享库的形式)和在客户端边界外实现(以在不同进程中运行的代理的形式)。根据特定平台类型或客户端的需要，可以自定义服务接入点的具体实现形式。从客户端的角度看，服务接入点的使用是可选的，尽管一般来说它具有通用性。下面将进行详细的阐述。
可以将服务接入点实现为静态组件，仅支持一组固定的服务协议绑定，也可以动态地支持新的协议绑定。
我们至少可以从两个角度来表征涉及服务接入点的交互，即请求参与者所使用的客户端和与其他支持NEMO的端点(节点)交互的服务端。
在一个客户端实施例(如图7a所示)中，服务接入点710直接与客户端720交换 XML消息。客户端720直接生成请求消息740，并将它们提交到服务接入点710，服务接入点 710生成一个或多个响应消息750，并将它们发送给客户端720，由客户端720收集、分析并处理这些消息。另外，客户端720(提出请求时)还可能会提交显式服务绑定集730，用于确定请求传递的方向。这些服务绑定可以通过多种方法来获得。例如，客户端720可以执行服务发现操作，然后选择合适的服务绑定，或者可以使用从先前的响应中获得的信息。
在另一个客户端实施例(如图7b所示)中，服务接入点760直接支持客户端780 的本地协议770。服务接入点760在内部进行XML和本地协议770之间的消息转换，从而使客户端780能够参与NEMO系统。要想使此支持生效，本地协议770 (或本地协议770与运 行环境的组合)必须以某种形式向服务接入点760提供必要的信息，服务接入点760将生成适当的请求，并确定合适的目标服务绑定(如果必要)。
在服务端，可以支持在客户的服务接入点与支持NEMO的服务提供端点之间的多种交互模式。对于客户端，这些交互模式可以定制，并且可以根据不同条件而变化，这些条件包括请求的性质、基础通信网络、应用的性质和/或与选定的服务绑定相关的传输协议坐寸ο
图7c描述了一种相对简单的服务端交互模式，其中服务接入点711以点对点的方式直接与目标服务提供节点712进行通信。
现在我们转到图7d，服务接入点721可能开始与多个可能的服务提供者725的进行直接通信(也可能直接接收725发出的响应)。通过从客户端转发多个服务绑定，可以实现这种交互模式，供服务接入点721使用；或者，服务接入点721也可以利用广播网络或多播网络来转发消息。根据在请求中指定的首选设置，服务接入点721可以选择收集和整理响应,或者简单地返回第一个可接受的响应。
在图7e中，服务接入点731并不直接与任何选定的服务提供端点735直接通信。 相反，请求要通过中间节点733进行路由，由中间节点733转发请求，接收任何响应，并将它们转发回服务接入点731。
如果服务接入点731不能够或者不希望直接支持任何与服务提供端点735相关的服务绑定，但是却可以与中间节点733建立关系(中间节点733愿意作为网关)，那么这种交互模式可能就比较理想。另一方面，客户端可能无法发现任何适当的服务提供节点或为服务提供节点确定服务绑定，但是可能愿意让中间节点733尝试发现适当的服务提供者。 最后，服务接入点731可能想要利用中间节点733的作用，因为它支持更强大的收集和整理功能，而反过来，这允许在服务接入点731与服务提供者(例如端点节点735)之间使用更加灵活的通信模型。
除了以上的基本服务端交互模式，还可以在服务接入点内实现这些模式的组合或新模式。尽管服务接入点的目的是为了提供一个通用接口，但是其实现一般与通信模型的特性密切相关，而且与给定的支持的NEMO的端点所使用的相关协议也密切相关。
在实际运用中，服务接入点可用于封装处理IO相关数据的列集和散集的逻辑，例如将对象序列化为适当的表示(例如WSDL格式的XML表示)，或者以适当的格式封装XML 编码对象的逻辑。
在优先的实施例中，SAP还封装用于通过一个或多个支持的应用、会话和/传输协议进行通信的逻辑，例如使用SOAP封装进行HTTP上的服务调用。
最后，在某些实施例中，SAP可能会封装提供消息完整性和机密性的逻辑，例如支持建立SSL/TLS会话和/或通过XML签名和XML加密等标准支持签名/验证。服务接口的具体地址未知或者没有指定时(例如，根据搜索条件跨多个节点调用服务时)，SAP可以通过封装逻辑建立至一组默认/初始NEMO节点的初始连接，这些节点能够发现或处理服务。
下面是一个示例，它是由一个SAP实施例导出的高级API描述的无限制实施例。
ServiceAccessPoint: : Create (Environment [])
- > ServiceAccessPoint-这是一个 singleton 接口，它返回一个初始化的 SAP实例。可以根据一组可选的环境参数对SAP进行初始化。
ServiceAccessPoint::1nvokeService (Service Request Message,Boolean)- >Service Response Message-支持同步服务调用API,其中客户端(使用WSDL)生成一个XML服务请求消息，并接收响应的XML消息。这个API还接受Boolean标识，这个标识表明客户端是否应该等待响应。通常情况下，这个标识应该为true，除非消息没有相关的响应， 或者消息的响应将通过另一个信道(例如通过通知信道)异步发送回来。产生的消息还可能传送结果出错情况。
ServiceAccessPoint::ApplyIntegrityProtection(Boolean, Desc[])- > Boolean——这个API允许调用者指定是否应使用完整性保护，以及对消息中的哪些元素进行完整性保护。
ServiceAccessPoint:: ApplyConfidential ity (Boolean, Desc [])- > Boolean——这个API允许调用者指定是否使用机密性策略，以及对消息中的哪些对象使用机密性策略。
ServiceAccessPoint::SetKeyCallbacks(SigningKeyCallback,
Signature VerificationKeyCallback,
EncryptionKeyCallback,
DecryptionKeyCallback)- >
Boolean
如前面的API中所示，在发送或接收消息时，它可能包含一些需要进行完整性保护或保持机密性的对象。本API允许客户端在它本身与SAP之间设置一些必要的指令，从而使SAP能够获得与 特定类型的信任管理操作相关的密钥。在一个实施例中，接口以回调为基础，回调通过数字签名和验证支持完整性保护，通过加密和解密支持机密性。在一个实施例中，每个回调的形式如下
KeyCallback (KeyDesc) - > Key[]
在这里，KeyDesc是一个描述所要求的密钥的可选对象，回调将返回一个适当的密钥列表。使用InvokeService (…)API时,接收响应服务消息时要对签名进行验证。如果消息元素未能通过验证，InvokeService (…)可以返回一个XML消息，提示状态，并表明元素未能通过验证。
3.4.服务适配层
如上所述，服务适配层提供一个通用方法，供服务提供者公开它们的服务、处理请求和生成服务响应以及在NEMO框架内编排服务。在其上可以实现其他特定的服务接口绑定的基础。在一个实施例中，WSDL用于描述系统内的服务的接口。
除了定义如何将服务绑定到特定的接口之外，这样的服务描述还可能包含一个授权服务提供者列表(该列表中的授权服务提供者将负责服务访问授权)、一个指向语义描述(它描述服务的用途和用法)的指针以及对组合服务的必要编排的描述(因为要设计其他一个或多个服务的执行)。
除了作为公开服务的逻辑点之外，服务适配层还封装NEMO数据类型的具体表示， 以及在NEMO服务概要中为给定参与者支持的平台指定的对象。它还包含一个机制，用于将与服务相关的消息映射到相应的本地服务实现。
在一个实施例中，NEMO框架并不规定如何实现指定平台或参与者的服务适配层。 有些情况下，服务提供节点并不需要转换其本地服务协议，也就是说，仅向可以通过本地协议进行通信的客户端节点公开其服务，在这种情况，该服务提供节点并不需要包含服务适配层。
否则，服务提供节点的服务适配层通常应包含以下元素，如图8所示
A 口点——它是一个封装服务接口入口点810和相关WSDL绑定的层。其他节点通过这些接入点调用服务、传递参数数据和收集结果。
消息处理逻辑——层820，它对应于消息处理逻辑，通常包含用于驱动消息处理的消息泵825，一些类型的XML数据绑定支持826，以及低级XML分析器和数据表示支持827。
本地服务——一个表示可用本地服务的层(相应的服务消息被映射到该层)，它包含本地服务API 830和相应的实现840。
3. 5.工作流整理器
在优选实施例中，工作流整理器(WFC)通过协调请求事件流、管理任何相关数据 (包括临时结果和中间结果)、执行与实现请求相关的规则来帮助实现最重要的NEMO服务请求。各种类型的事务协调器，从关系数据库中的简单事务监控器到Microsoft MTS/C0M+ 中更为常见的监控器，都属于此种功能类型的例子。
在一个实施例中，工作流整理器是一个可编程机制，NEMO节点通过它来编排对服务调用的处理和实现。可以根据特定NEMO节点的特征和要求来定制WFC，而且，经过设计， WFC可以支持各种功能，包括从传统的消息队列到更为复杂的分布式事务协调器。一个相对简单的WFC可能会提供一个接口，用于存储和检索任何与服务有关的消息。在此基础上，它可以支持多种功能，包括(i)收集服务请求，以提高处理效率；(ii)简单地将服务响应聚合为一个复合响应；(iii)手动编排多个服务请求和服务响应，以创建一个复合服务；(iv)自动编排多个服务请求和服务响应，以创建一个复合服务。
基本的服务交互模式是这样开始的一个服务请求通过节点的服务适配层到达某个NEMO节点。消息被转交给WSDL消息泵；开始时是WSDL消息泵驱动WFC，接下来消息泵被WFC驱动，以实现请求并返回响应。更复杂的情况是，实现服务请求可能需要多个消息、 响应和多个节点协作参与。请求处理规则可以用系统的服务描述语言来表示，也可以用其他服务编排描述标准Hf^BBPEL)来表示。
消息被交给WFC时，WFC将确定此请求的正确处理规则。根据WFC的实现，可以用固定状态机的形式来表示节点公开的一组服务的服务描述逻辑，也可以用支持处理更为自由的服务处理逻辑表达形式的方式表示。
在优选实施例中，WFC体系结构是模块化和可扩展的，并且支持插件。除了解释服务组合和处理规则外，WFC还需要确定是否在启动服务实现处理生命周期的情况下使用 NEMO消息，或者将NEMO消息用作正在进行的事务链中的输入。在一个实施例中，NEMO消息包括用于完成这些确定工作的ID和元数据。我们还可以对NEMO消息进行扩展，使之包含可能是服务事务所特有的附加信息，方便消息处理。
在后面更为详细的论述中，NEMO系统的各种实施例直接支持通知服务。通知表示在指定的服务接口接收以进行处理的一则消息，它以有意向的支持NEMO的节点为目标。通知还可以包含用于转发信息的一组不同的载荷类型和用于确定通知所选定的节点是否可扩展的条件(包括基于身份的条件和基于事件的条件)。
在一个实施例中，如图9a所示，服务提供NEMO节点910提供一个服务，这个服务需要由其工作流整理器914完成一个编排过程(例如收集和处理其他两个服务提供者生成的结果)，以便实现客户端节点940对该服务的请求。
客户端节点940上支持NEMO的应用942发出一个请求调用服务提供者910提供的服务时，工作流整理器914相应地生成消息，(代表应用942)分别向节点920上的服务提供者“Y” 922和节点930上的服务提供者“Z” 932发出自己的请求。然后，工作流整理器将整理并处 理这两个服务提供节点生成的结果，以实现客户节点940发出的原始请求。
或者，所请求的服务可能不需要多个服务提供节点的服务，相反，可能需要服务提供节点与发出请求的客户端节点之间进行多个回合或多个阶段的通信。如图％所示，当客户端节点940上支持NEMO的应用942发出请求要求调用服务提供者910提供的服务时，工作流整理器914接下来将与客户端节点940进行多阶段的通信，以实现原始请求。例如，工作流整理器914可能生成消息并(通过接入点944)将消息发送给客户端节点940，然后接收和处理响应，并在后继通信过程中生成附加信息(和接收附加响应)，最终实现客户端节点940发出的原始请求。
在这个例子里，服务提供者910使用工作流整理器914 (可能根据服务请求的特定服务会话ID或事务ID部分)来跟踪它与客户端正处于哪一个操作阶段，以保证正确处理请求。如上所述，可以使用状态机或类似机制或技术来处理这些多阶段的通信950。
图9c描述了一个相对基本的交互的实施例，该交互在服务提供节点960内部、在工作流整理器914和消息泵965 (在该节点的服务适配层内部，没有表示出来)之间发生。 如上所述，工作流整理器914处理一个或多个服务请求962，并生成响应964，采用存储和检索机制966维护编排过程的状态。在这个简单的示例中，工作流整理器914能够处理多个服务请求和响应，而且可用相当简单的状态机来实现。
对于更复杂的处理，图9d描述了一个节点体系结构，它可以在进行服务编排时起到驱动作用或被驱动。在这里，该体系结构的功能包括收集多个服务请求、将多个响应聚合为一个复合响应、手动或自动编排多个服务请求和响应以创建一个复合服务。
在图9d中，以工作流整理器914为核心的体系结构支持各种情形。例如，假如外部协调器970理解过程编排的语义(例如，由与服务相关的高级过程描述驱动的业务流程处理语言引擎)或资源使用语义(例如，可以由资源相互关系语义驱动的资源描述框架引擎)，那么让NEMO节点将自己的功能和外部协调器970的功能结合在一起，就可以创建功能强大的服务。自定义外部BPL 972和/或RDF 973处理器可以利用外部消息泵975通过手动编排过程966 (即人为干预的过程)来执行过程描述。
除了依靠手动驱动的过程(这个过程依靠与NEMO节点的消息泵协同工作的外部协调器)外，还可以创建一个体系结构，在这个体系结构内，模块可以直接与工作流整理器 914集成，以支持自动形式的服务协调和编排968。例如，对于常规类型的服务编排模式，例如那些以BPEL和EBXML表示、通过与服务接口相关的Web服务绑定通信的模式，工作流整理器914可以直接由陆续到达的请求和响应消息967的描述和集合驱动。在这种情况下， 只有当与给定的编排处理器插件(例如，BPEL 982或EBXML 983)相关的状态机认为时机适当时，才会向消息泵965推入复合响应消息。
下面是一个相对高级的API描述实施例，它是由一个NEMO工作流整理器实施例导出的。
WorkflowCollator: : Create (Environment []) - > WorkflowCollator-这是一个singleton接口，它返回一个已初始化的WFC实例。可以根据一组可选的环境参数对WFC 进行初始化。
WorkflowCollator: : Store (Key [], XML Message) - > Boolean-这个 API 允许 调用者通过一组特定键值在WFC内存储服务消息。
WorkflowCol lator: : RetrieveByKey (Key [] , XML Message) - > XML Message []——该API允许调用者通过一组指定的键值检索一组消息。返回的消息将不再包含在WFC内。
WorkflowCollator::PeekByKey (Key[], XML Message)- > XML Message[]-该API允许调用者通过一组指定的键值检索一组消息。返回的消息仍然包含在WFC之内。
WorkflowCollator: : Clear O - > Boolean-该 API 允许调用者清除存储于 WFC之内的任何消息。
作为相对比较严格的BPEL编排标准的替代，另一个实施例采用了非正式的基于 XML的编排描述，例如用于更动态的应用(如分布式搜索)。请注意以下描述，该描述可以由NEMO工作流整理器进行解释(在语言足够丰富的情况下，甚至还可能替代整个服务)
<WSDL>〈NEMO Orchestration Descriptor〉〈Control Flow>例如，EXECUTE Service A;If result =Yes then Service B;Else Service C<Shared State/Context>例如，DeviceState〈Transactions〉例如，State、Rollback 等<Trust/Authorization>请注意，Trust 并不一定是可传递性的。3. 6. DRM引擎体系结构示例
在前面所述的多个NEMO节点体系结构实施例中，图10描述了将一个模块化DRM 引擎实施例1000集成到NEMO内容使用设备中，有助于将它集成到许多不同的设备和软件环境之中。
主机应用1002 —般通过其用户接口 1004接收一个访问特定内容片段的请求。然后主机应用1002将请求和相关的DRM引擎对象(最好对于主机应用是不透明的)发送到 DRM引擎1000。DRM引擎1000通过定义良好的接口向主机服务模块1008请求附加的信息和加密服务。例如，DRM引擎1000可能会询问主机服务1008特定链接是否是信任的，或者要求某些对象被解密。有些必需的信息可能是远程的，这种情况下，主机服务1008可通过服务接入点1014请求网络化服务提供信息。
一旦DRM引擎1000确定特定操作是允许的，它将表明这一点，并将必要的加密密钥返回给主机服务1008。主机服务1008根据主机应用1002的指令，依靠内容服务1016来获得所需要的内容，并管理对内容的使用。然后主机服务1008可能会根据需要与加密服务 1012协作，启动媒体表现过程1010(例如，通过扬声器播放内容、在屏幕上显示内容等)。
图10中的系统体系结构是一个相对简单的示例，它描述了如何在应用中使用DRM 引擎，但是DRM引擎还有许多可能用法。例如，在其他一些实施例中，在相对复杂的策略管理系统管理下，DRM引擎可集成到打包应用中。下面将讨论DRM引擎的客户端(内容使用) 和服务器(内容打包)应用，包括这些应用依赖的不同类型的DRM相关对象的描述，随后将介绍一个DRM引擎本身内部体系结构的实施例。
如图11所示，DRM引擎1100依赖一个虚拟机即控制VM1110，在多种主机平台上进行内部DRM处理(如执行管理内容访问的控制程序)，从而利用主机环境1120(如上所述， 下面进行了更详细的论述)与节点的主机应用1130进行交互，并最终与NEMO或其他系统内的节点进行交互。
在一个实施例中，控制VMl 110是由DRM引擎1100的实施例使用的虚拟机，以执行用于管理内容访问的控制程序。下面描述了如何将控制VMlllO集成到DRM引擎1100的体系结构中，还介绍了控制VM的基本元素，包括其指令集、内存模型、代码模块以及通过系统调用1106与主机环境1120的交互。
在一个实施例中，控制VMlllO是一个相对较小的虚拟机，经设计它可以使用多种编程语言来简单实现。它基于一个面向栈的指令集，该指令集实际上按最低要求设计，没有过多地考虑执行速度或代码密度。但是，应理解，如果特定的应用需要考虑执行速度和/或代码密度，可以使用常规技术(如数据压缩)来提高性能。
控制VMlllO适合用低级语言或高级语言编写，支持汇编、C和FORTH等语言。也可以容易地实现其他语言的编译器，如Java语言或定制语言等。
控制VM 1110设计为驻留在DRM引擎1100内(包括主机环境1120)，而不是直接在处理器或芯片上运行。控制VM 1110通过执行存储在代码模块1102内的指令来运行程序。有些指令可以通过一个或多个系统调用1106来调用在程序外实现的功能；系统调用 1106可由控制VMlllO实现，也可委托给主机环境1120。
执行模型
控制VM 1110执行存储在代码模块1102中的指令，执行时，这些代码作为载入到内存1104的字节代码流。控制VM 1110维护着一个名为程序计数器(PC)的虚拟寄存器， 指令执行时，该计数器递增。VM顺序执行每条指令，直到遇到0P_ST0P指令，在调用栈为空时遇到0P_ST0P指令，或发生异常。指令跳转被指定为相对跳转(指定为从当前PC值的字节偏移量)或绝对地址。
内存模型
在一个实施例中，控制VM 1110的内存模型相对比较简单。VM内存1104分为数据段(DS)和代码段(CS)。数据段是单一、平面、连续的内存空间，起始地址是O。数据段一般是在主机应用1130或主机环境1120的堆内存内分配的一列字节。对于特定的VM实现， 内存空间的大小优选固定为最大值，试图访问内存地址范围之外的地址将导致出错，并终止程序的运行。数据段可能由VM同时载入的多个代码模块1102共享。数据段中的内存可以由内存访问指令访问，该访问可能是32位的，也可能是8位的。32位内存访问可以使用 big-endian字节顺序来完成。这里并没有假定VM可见内存与主机管理的内存(主机CPU 虚拟内存或物理内存)完全对应。
在一个实施例中，代码段是平面、连续的内存空间，起始地址为O。代码段一般是在主机应用1130或主机环境1120的堆内存内分配的一列字节。
控制VM 1110可以加载多个代码模块，所有代码模块可以共享同一个数据段(每个模块的数据最好载入到不同的内存地址)，但是每个代码模块都有自已的代码段(举例来说，最好代码模块1102的跳转指令不可能导致直接跳转到另一代码模块1102中的代码)。
数据栈
在优选的实施例中，VM具有数据栈的概念，它表示存储在数据段中的32位数据单元。VM维护一个名为栈指针(SP)的虚拟寄存器。在重置后，SP指向数据段的末尾，栈向下增长(数据推入数据栈时，SP寄存器的值减小)。根据引用栈数据的指令，栈上的32位值被解释为32位的带地址整数、32位带符号整数。
调用栈
在一个实施例中，控制VM 1110管理一个调用栈，用于嵌套式子程序调用。内存访问指令不能直接读写被推入栈的值，但是VM在执行OP-JSR指令和OP-RET指令时可以间接使用被推入栈的值。对于给定的VM概要，该返回地址栈的大小最好固定为最大值，这样将允许一定数量的嵌套调用，不能超过这个数量。
指令集
在一个实施例中，控制VM 1110使用相对简单的指令集。即使指令的数量有限，还是可用它们来编写简单的程序。指令集是基于栈的除了 OP-PUSH指令，任何指令都没有直接操作数。操作数从数据栈读取，并且结果被推入数据栈中。VM是32位的VM:本图解实施例中的所有指令都在32位栈操作数上工作，这些操作数表示内存地址或带符号整数。带符号整数用2的补数二进制编码表示。
下面示出了一个实施例中使用的指令集
操作码名称操作数描述OP 一PUSHPush ConstantN (direct)将一个常量推入栈OP_DROPDrop删除栈顶元素OP—DUPDuplicate复制栈 顶元素OP—SWAPSwap找顶两个元素互换OP—ADDAddA5B将A加B的和(A+B)推入栈0P_MULMultiplyA, B将A乘B的积(A*B)推入栈OP_SUBSubtractA, B将A和B间的差(A-B)推入栈OPDIVDivideA, B将A除以B的商(A/B)推入找OP—MODModuloA5B将A以B取模的值(A%B)推入栈OP—NEGNegateA将A的2s补值负数(-A)推入栈OP—CMPCompareA如果A为负，则将-1推入栈；如果A为0，则将O推入找，如果A 为正，则将I推入栈OP_ANDAndA, B将A和B的按位取与值(A &B)推入栈OP OROrA5B将A和B按位取或值(A|B)推入找OP_XORExclusive OrA5B将A和B的按位异或值(ΑΛ B)推入找OP—NOTLogical NegateA将A逻辑取反入栈(如果A是O则为I;如果A是非0，则为O)OPSHLShift LeftA, B将A逻辑左移B位的值(Α Β )推
权利要求
1.一种授权对在计算机系统上的电子内容片段的访问的方法，所述方法包括 接收来自所述计算机系统的用户的访问电子内容片段的请求； 重新获得与所述电子内容片段相关的许可，所述许可包括控制对象、控制器对象、保护器对象和内容密钥对象； 从所述控制对象重新获得控制程序；以及 使用运行在所述计算机系统上的数字权限管理引擎执行所述控制程序以确定所述请求是否被认可，其中执行所述控制程序包括评估一个或多个链接对象以确定是否满足由所述控制程序所表达的一个或多个条件，其中每个链接对象表示两个实体之间的关系，以及其中评估所述一个或多个链接对象包括确定与第一实体相关的第一节点对象是否能从与第二实体相关的第二节点对象获得。
2.如权利要求1所述的方法，其中所述控制器对象能操作地将所述控制对象安全地绑定到所述内容密钥对象。
3.如权利要求1所述的方法，其中所述保护器对象能操作地将所述内容密钥对象安全地绑定到所述电子内容片段。
4.如权利要求3所述的方法，其中所述内容密钥对象包括加密的密钥，所述加密的密钥当被解密时能够解密所述电子内容片段。
5.如权利要求4所述的方法，进一步包括 从所述一个或多个链接对象获得解密密钥，所述解密密钥能够解密加密的密钥。
6.如权利要求4所述的方法，其中所述一个或多个链接对象中的至少一个链接对象包括第一密钥的加密版本，所述第一密钥能够解密加密的密钥，所述方法进一步包括 使用与所述计算机系统相关的第二密钥来解密所述第一密钥； 使用所述第一密钥来解密所述加密的密钥；以及 使用所述密钥来解密所述电子内容片段。
7.如权利要求1所述的方法，其中所述第一实体包括用户，并且其中所述第二实体包括能够呈递电子内容的装置。
8.一种授权要对电子内容片段执行给定动作的方法，所述方法包括 使用在第一数字权限管理引擎上运行的虚拟机执行控制程序，所述控制程序能操作地确定是否能够对所述电子内容片段执行所述给定动作，其中所述控制程序能操作地评估必须要被满足的一组一个或多个条件以便使所述给定动作的执行被授权，并且其中所述一组一个或多个条件中的至少第一条件包括表示第一实体的第一节点能够从表示第二实体的第二节点获得的要求；其中 评估所述数字权限管理引擎能得到的一个或多个链接对象以确定所述第一节点是否能从所述第二节点获得，每个链接对象表达两个实体之间的关系。
9.如权利要求8所述的方法，其中所述一组一个或多个条件中的至少第二条件包括表示第三实体的第三节点能够从所述第二节点获得的要求。
10.如权利要求8所述的方法，进一步包括 从所述一个或多个链接对象获得第一密钥，所述第一密钥能够解密第二密钥，所述第二密钥能够解密所述电子内容片段。
11.如权利要求8所述的方法，其中所述控制程序被包括在控制对象中。
12.如权利要求11所述的方法，其中所述控制对象加密地绑定到内容密钥对象，所述内容密钥对象包括加密的密钥，所述加密的密钥能够解密所述电子内容片段。
13.—种管理电子内容片段的方法，所述方法包括 加密所述电子内容片段； 将许可与所述电子内容片段关联起来，所述许可包括控制程序，所述控制程序要求，作为授权所述电子内容片段的解密的条件，占有一组一个或多个链接对象，所述链接对象逻辑地将第一节点对象与第二节点对象连接起来，所述许可进一步包括能操作地解密所述电子内容片段的第一密钥的加密版本； 发送所述电子内容片段至远程计算机系统； 确定所述远程计算机系统占有一组一个或多个链接对象，所述链接对象逻辑地将第一节点对象与第二节点对象连接起来，其中所述一个或多个链接对象中的至少一个链接对象包括能操作地解密所述第一密钥的第二密钥的加密版本； 在完成所述确定步骤时，使用与所述远程计算机系统相关联的密钥来解密所述第二密钥； 使用所述第二密钥来解密所述第一密钥；以及 使用所述第一密钥来解密所述电子内容片段。
14.如权利要求13所述的方法，其中所述许可进一步包括安全地将所述控制程序绑定到所述第一密钥的控制器对象。
15.如权利要求14所述的方法，其中所述控制器对象包括内容密钥对象和控制对象的无用信息，其中所述内容密钥对象包括所述第一密钥的加密版本，并且所述控制对象包括所述控制程序。
16.一种用于控制对计算机系统上的电子内容片段的访问的系统，所述系统包括 用于接收来自所述计算机系统的用户的访问所述电子内容片段的请求的装置； 用于重新获得与所述电子内容片段相关的许可的装置，所述许可包括控制对象、控制器对象、保护器对象和内容密钥对象； 用于从所述控制对象重新获得控制程序的装置；以及 使用运行在所述计算机系统上的数字权限管理引擎执行所述控制程序以确定所述请求是否会被认可的装置，其中执行所述控制程序包括评估一个或多个链接对象以确定是否满足所述控制程序所表达的一个或多个条件，其中每个链接对象表示两个实体之间的关系，以及其中评估所述一个或多个链接对象包括确定与第一实体相关的第一节点对象是否能从与第二实体相关的第二节点对象获得。
17.如权利要求16所述的系统，其中所述控制器对象能操作地将所述控制对象安全地绑定到所述内容密钥对象。
18.如权利要求16所述的系统，其中所述保护器对象能操作地将所述内容密钥对象安全地绑定到所述电子内容片段。
19.如权利要求18所述的系统，其中所述内容密钥对象包括加密的密钥，所述加密的密钥当被解密时能够解密电子内容片段。
20.如权利要求19所述的系统，进一步包括 从所述一个或多个链接对象获得解密密钥的装置，所述解密密钥能够解密加密的密钥。
全文摘要
本说明书描述用于以某种方式执行由策略管理的对等服务编排的系统和方法，采用这种方式，可以支持构建能够带给用户丰富媒体体验的自组织服务网络。在一个实施例中，服务分布在多个对等通信节点上，每个节点都利用消息泵和工作流整理器来提供消息路由和消息编排。服务接口的分布式策略管理有助于提供信任和安全，从而支持商业价值交换。通过对等消息传递和工作流整理，可以从一组异类原语服务动态创建服务。共享资源是一些不同类型的服务，它们使用不同于基于UDDI、SOAP和WSDL的Web服务部署中通常支持的那些服务接口绑定。在一个优选实施例中，提供了一种媒体服务框架，它支持节点在从WAN到PAN的网络层之间相互查找、交互、交换价值和协作。
文档编号H04L9/00GK103001923SQ20111026051
公开日2013年3月27日 申请日期2004年6月7日 优先权日2003年6月5日
发明者W·B·布拉德利, D·P·马赫尔, G·博坎－吉布 申请人:英特特拉斯特技术公司