专利名称：用于对等服务编排的可互操作系统和方法
技术领域：
本发明一般性涉及对数字信息和服务的分发和使用。更具体地，公开了提供和/支持对等服务编排的系统和方法。
背景技术：
和发明概述如今，要实现建立一个互操作和安全的媒体相关服务环境的目标，还存在许多障碍。例如，多个事实上相互重叠的正式标准会限制直接的互操作性；定位和连接到所需的服务通常很困难；实现技术通常是不可互操作的；并且在不同的信任和保护模式之间经常存在阻抗不匹配。
尽管新兴Web服务标准正在着手解决web上的这些问题，但这些方法并不完善。另外，这种方法不能跨个人和局域网、家用、企业和部门网关以及广域网等多层次的网络节点解决此类问题。而且，这些标准也不能通过利用各种本地和远程的允许集成许多传统应用的服务接口绑定(例如WS-I、Java RMI、DCOM、C函数调用和.Net等等)对简单和复杂服务进行动态编排。
本发明的实施例可用于解决部分或全部这些问题。例如，在某些实施例中，服务提供者可以使用最适合于参与给定异类服务网络的设备、服务或应用的服务发现协议。因而，可以将BlueTooth，UpNp，rendezvous？，JINI，UDDI等集成在同一个服务中，并且每个节点可以使用最适合承载该节点的设备的发现服务。
在媒体环境中，主要参与者群体(例如内容发布者、分发者、零售商、消费设备提供者和用户)所需要或喜欢的系统和接口常常有很大的不同。因此，希望将这些实体所提供的功能统一到能够迅速发展为满足所有参与实体的最佳配置的集成服务中。通过使用对等(“P2P”)服务编排，本发明的实施例可以用来实现该目标。
尽管已经看到P2P架构对于诸如音乐分发和如今的视频分发这种应用的优势，P2P技术还可以使用得更为广泛。例如，在各种企业服务，特别是两个或更多企业的交互中，也存在很多应用机会。企业大多是按照一定的层次结构进行组织的，其信息系统通常反映了这种组织结构，当两个企业的人员进行交互时，通过对等接口他们的交互往往更有效。A公司中的收货人员/服务可以通过与B公司的发货人员进行对话来更直接地解决问题或获得有用的信息。交叉层次或不必要的接口一般是没有用的。一些送货公司(例如FedEx和UPS)认识到这一点，因此他们允许客户直接看到其处理，直接对事件进行监视。公司和市政当局正在通过企业门户来组织其服务，从而形成自然的自助服务。但是，迄今为止，对等架构并不允许一个企业向其用户和提供者公开自己的各种服务接口，让这些实体在自然的对等级别上进行交互，这样这些实体就不能以最适合自己的方式编排该企业的服务。本发明的实施例将允许这样做。
公开了用于在连成网络的计算机环境中提供服务编排的系统和方法。应该理解可以用各种不同的途径实现所公开的实施例，包括过程、设备、系统、装置、方法或计算机可读介质。下面说明几种有创造力的实施例。
在一组实施例中，提供了一种服务架构，它能使得用户或企业媒体空间中的参与者(例如，用户、内容提供者、设备制造商、服务提供者、企业部门)彼此找到对方、建立信任关系并通过信任的服务接口以丰富的动态方式交换价值。这个服务架构可以被描述成在不同种类的消费设备、媒体格式、通信协议和安全机制的环境实现可操作的、安全的、与媒体相关的电子商务的平台。
将通过下面的详细说明以及附图更详细地阐明本发明的这些和其它特性、优势和实施例。
附图概述通过结合附图参考下面的详细说明将更容易理解本发明的实施例，在附图中相同的引用编号表示相同的结构组件，在附图中
图1示出了该媒体驱动架构的一个示范实施例。
图2是一个媒体驱动节点的概念视图。
图3示出了媒体驱动节点之间的一般交互方式。
图4示出了服务适配层的一个实施例。
图5a示出了客户端MSDL交互中涉及的服务代理。
图5b示出了客户端本地交互中涉及的服务代理。
图6示出了服务端指向-中间交互模式中涉及的服务代理。
图7示出了媒体驱动工作流程整理器的交互模式。
图8示出了发现了支持通知处理器服务的节点的一组通知处理节点。
图9示出了依照一个优选实施例的通知发送。
图10示出了请求节点向目标服务提供节点进行服务查询请求的客户端-驱动情况。
图11示出了请求节点想要向另一节点注册它的描述的节点注册情况。
图12示出了正在被通知服务存在的具有媒体驱动功能的节点。
图13示出了根据显式的交换建立信任的过程。
图14示出了受策略管理的服务访问。
图15示出了如何在向参与者传送CRM-相关服务的环境中使用媒体驱动。
详细说明下面提供对有本发明的有效实体的详细说明。尽管这个说明是结合了几个实施例而提供的，但应该理解本发明并不仅限于任何一个实施例，而是包括各种不同的可选方案、改进和等效方案。例如，尽管一些实施例是在面向用户的内容和应用的环境中说明的，但本领域中的技术人员将认识到所公开的系统和方法适用于更广泛的应用。例如，没有限制，本发明的实施例可以被很容易地应用到企业内容和应用环境中。另外，尽管在下面的说明中阐述了大量具体细节以便提供对本发明的透彻理解，但不要这些细节中的一些或全部也可以实践本发明。此外，为明确起见，没有详细说明一些本领域中已知的涉及本发明的特定技术材料以避免不必要地模糊本发明。
这里说明了一种新颖的、受策略管理的、对等的服务编排架构(媒体驱动架构)的实施例。该架构最初被设计用来支持能带来丰富媒体体验的基层自组织服务网络的形成。如同本领域中的普通技术人员将理解的那样，该架构本身新颖，它的很多特性、方面和应用也新颖。
在一个优选实施例中，该架构被设计用来用服务描述语言(媒体驱动服务描述语言“MSDN”)激活很多不同服务类型的动态配置和进展。服务可以跨越对等的通信节点分布，每个对等通信节点用专为这个架构设计的消息泵和工作流整理器提供消息路由和编排。媒体驱动服务接口的分布式策略管理可以用来帮助提供信任和安全，由此促进价值的商业交换。
对等计算通常被定义为计算机和其它智能设备之间的资源(例如硬盘和处理周期)共享。参见http://www.intel.com/cure/peer.htm。这里，P2P可以被看作是允许网络节点对称地消耗并提供所有种类的服务的通信模型。P2P消息传送和工作流整理允许从不同组的更原始的服务动态创建丰富的服务。这样能够在共享资源是很多不同类型的服务，甚至使用不同服务绑定时对P2P通信的可能性进行检查。媒体驱动的实施例可以用来提供使各参与者(例如用户、内容提供者、设备制造商和服务提供者)彼此找到对方、交互、交换价值并以多种动态方式合作的媒体服务架构。可以用媒体驱动的实施例来协调的不同类型的服务从基本的服务(发现、通知、查找和文件共享)到更复杂更高级的服务(例如锁定、许可、匹配、授权、支付事务和更新)以及这些服务中的任意或全部的组合。
媒体驱动的企业应用在企业转向面向服务的体系结构时尤其能引起企业的兴趣。通过对等服务编排和分布式策略管理的使用，企业能够允许它们的部门发布可以由客户和提供者配置成丰富的个性化服务的服务接口，分解人工层次并允许内部和外部实体优化它们与该企业的交互。
为说明方便起见，将使用下列术语服务-由一些提供者提供的任何明确定义的功能。例如，可以是像蜂窝电话这样的设备中提供的初级功能(例如语音识别服务)或者在万维网上提供的多-方功能(例如购物服务)。
服务接口-与一个或多个服务交互的任何明确定义的途径。
服务绑定-用来调用服务接口的约定和协议。它们可以用大量明确定义的方式来表示，例如WS-I标准XML协议、基于WSDL定义的RPC或来自DLL的函数调用。
服务编排-将服务组装、调整成符合服务提供者指定的规则的可管理的、粗粒度的服务、可重用的组件或完整的应用程序。例如，规则基于提供者标识、服务类型、访问服务的方法和组织服务的顺序等等。
管理-进行授权或控制一些对象(例如音乐文件、文档或像下载或安装软件升级的能力这样的服务操作)上的影响的过程。管理通常与信任管理、策略管理和内容保护相交互。
对等(P2P)原则-支持参与者对服务进行对称访问的通信模型。
媒体驱动节点-媒体驱动架构中的参与者。在一个优选实施例中，一个节点可以充当多种角色，包括服务用户和/或服务提供者。可以用多种形式实现节点，包括消费类电子设备、软件代理(例如媒体播放器)或虚拟服务提供者(例如服务搜索引擎、DRM许可提供者或内容箱)。可以编排媒体驱动服务以提供更健壮的组合服务。
媒体驱动服务描述语言(MSDL)-在一种实施例中，一种基于XML模式的语言定义并描述了用于媒体驱动架构的实施例中节点之间通信的可扩展的数据类型和消息集合。
7.逻辑模型图1示出了媒体驱动架构的一个相对简单的实例。在一个优选实施例中，该媒体驱动架构由以P2P方式交互的在逻辑上相连的一组节点构成。
在一个优选实施例中，这种交互的一些特征是-媒体驱动节点通过进行服务调用请求并接收响应而交互。请求和响应消息的格式和有效载荷以MSDL定义。媒体驱动架构支持不同通信模型的构造，从与单个服务提供者的直接交互到来自多个服务提供者的精心策划的服务集合的复杂聚集。在一个优选实施例中，该架构支持用于使用现有服务设计标准的基本机制并且还允许服务提供者使用它们自己的规则。
-一个服务接口可以有一个或多个服务绑定。在一个优选实施例中，服务绑定的说明以MSDL表示。在这个实施例中，媒体驱动节点可以调用另一节点的接口，只要那个节点的接口绑定可以用MSDN表示，以及只要该请求节点能够支持与该绑定相关的规则和协议。例如，如果一个节点支持web服务接口，可能要求请求节点支持SOAP、HTTP、WS-安全等等。
-可以用直接提供了权限管理特征的标准化方式控制(例如，受权限管理的)任何服务接口。媒体驱动节点之间的交互可以看作是被管理的操作。
实际上任何类型的设备(物理的或虚拟的)都可以看作是潜在的具有媒体驱动功能，并且能够实现媒体驱动架构的关键特征。例如，设备类型有消费类电子设备、网络化服务或软件客户端。在一个优选实施例中，具有媒体驱动功能的设备(节点)通常包括下列逻辑模块中的一些或全部-本地服务API-该设备实现的一个或多个服务的集合。对媒体驱动节点在媒体驱动架构中直接或间接地公开什么服务没有要求。
-本地服务实现-本地服务API的对应实现集合。
-媒体驱动适配层-一个逻辑层，通过它可以用以MSDL描述的一个或多个可发现的绑定访问一个实体的本地服务公开的子集。
-媒体驱动架构支持库-为和包括对调用服务接口、消息处理、服务编排等等的支持的媒体驱动架构合作提供支持功能的组件。
图2提供了媒体驱动节点的一个示范实施例的概念视图。上述模块中的每一个所对应的实际设计和实现通常会随设备而不同。
8.基本的交互模式图3示出了两个媒体驱动节点，服务请求者和服务提供者，之间通常的逻辑交互模式。
从请求节点的角度来说，事件流通常是-进行服务发现请求以定位能够用指定的服务绑定提供必要服务的具有媒体驱动功能的节点。节点可以选择将与所发现的服务有关的信息缓存起来。媒体驱动节点之间的服务发现的交互/机制可以只是媒体驱动节点选择实现的另一服务。
-一旦找到了候选的服务提供节点，请求节点可以选择根据具体的服务绑定将请求分派到一个或多个服务提供节点。
-在一个优选实施例中，希望彼此进行安全通信的两个节点出于交换MSDL消息的目的而建立了信任关系。例如，它们可以协商一组可以用在确定身份、授权、建立安全通道等等之中的兼容的信任凭证(例如，X.500鉴定、设备密钥，等)。有些情况下，这些凭证的协商可以是服务接口绑定(例如，如果WS-I XML协议就是WS-安全，或者是两个众所周知的节点之间的SSL请求)的隐含属性。有些情况下，信任凭证的协商可以是明确的单独步骤。在一个优选实施例中，是由一个特定的节点来确定什么凭证对与别的媒体驱动节点交互来说足够，并做出它能够信任特定节点的判断。
-请求节点创建对所请求的服务对应的适当的MSDL请求消息。
-一旦消息被创建，它就被分发到目标服务提供节点。例如，该请求的通信方式可以是同步或异步的RPC方式，或者基于服务绑定的面向消息的方式。服务请求的分发和响应的接收可以由设备直接完成或通过媒体驱动服务代理完成。服务代理(下面有说明)为发送消息到媒体驱动架构中的其它参与者提供了抽象和接口，并且可以隐藏特定的服务绑定问题，例如兼容的消息格式、传输机制、消息路由问题或类似的问题。
-在分发了请求之后，请求节点通常将接收到一个或多个响应。根据服务接口绑定的细节以及请求节点的选择，响应可以用多种方式被返回，例如包括RPC-方式的响应或通知消息。在到目标节点途中的响应可以通过能够提供多种媒体驱动服务(包括，例如路由、信任协商、整理和相关功能等)的其它中间节点。
-请求节点验证响应以确保它符合在它和服务提供节点之间所协商的信任语义。
-随后根据消息有效负载类型和内容进行适当的处理。
再来参考图3，从服务提供节点的角度，事件流是-确定是否支持所请求的服务。在一个优选实施例中，媒体驱动架构不要求服务接口如何映射成服务入口点的方式或粒度。在最简单的情况中，服务接口可以明确地映射到特定的服务和绑定动作并且调用它可以构成对该服务的支持。但是，在一些实施例中单个服务接口可以处理多种类型的请求并且一个特定的服务类型可以包括在做出该节点支持具体想要的功能的判定之前要检查的附加属性。
-一些情况下服务提供者必须确定它是否信任请求节点并协商一组兼容的信任凭证。在一个优选实施例中，不管服务提供者是否判定为可信的，与该服务接口相关的任何策略仍将适用。
-服务提供者判定并将授权请求分发到那些负责授权对该接口的访问的媒体驱动节点以便确定该请求节点是否能够访问。很多情况下，授权节点和服务提供节点可以是相同实体，并且对授权请求的分发和处理可以是通过轻量级媒体驱动服务接口绑定(例如C函数入口点)调用的本地操作。
-在接收到授权响应后，如果请求节点获得了授权，服务提供者将满足该请求。反之，可以生成适当的响应消息。
-响应消息是根据服务接口绑定和请求节点的选择而被返回的。在到请求节点的途中，该消息可以通过能够提供必要的或“附加值”服务的其它中间节点。例如中间节点可以提供路由、信任协商以及到传送到能够以可接受的方式传送消息到请求节点的通知处理节点。“附加值”服务的一个例子是赠券服务，如果它知道请求节点的兴趣就将赠券附加到消息上。
9.MSDL与服务调用相关的消息语法优选地以相对灵活和可移值的方式进行描述，是媒体驱动架构中所用的核心数据类型。在一个优选实施例中，这是用服务描述语言(这里称为媒体驱动服务描述语言，或MSDL)实现的。另外，MSDL提供了简单的方式用于引用与所说明的服务相关的语义描述。
在一个优选实施例中，MSDL是基于XML模式的描述语言，它包括了能够实现服务和它们相关的接口绑定的描述和组成的扩展的数据类型集合。MSDL中的很多对象类型是多态的并且可以对其进行扩展以支持新功能。在一个优选实施例中，基本的MSDL轮廓将被称作“MSDL内核”。MSDL用户可以直接以特定方式或者通过一些形式的标准化过程定义在MSDL内核之上构建的添加了新数据和服务类型并扩展已有的数据和服务类型的其它MSDL轮廓。在一个实施例中，MSDL内核包括对下列主要的基本数据类型的一些或全部的定义-节点-媒体驱动架构中的参与者的表示。
-设备-封装了虚拟设备或物理设备的表示。
-用户-封装了客户端用户的表示。
-内容引用-封装了内容对象的引用或指针的表示。这种引用通常将利用描述内容格式、位置等的其它标准化方式。
-DRM引用-封闭了对数字权限管理格式描述的引用或指针的表示。
-服务-封装了对从节点输出的一组明确定义的功能的表示。
-服务绑定-封装了与服务通信的具体方式。
-请求-封装了对一组目标节点的服务请求。
-请求输入-封装了请求的输入。
-响应-封装了与请求相关的响应。
-请求结果-封装了与某请求相关的响应中的结果。
在一个实施例中，MSDL内核包括对下列基本服务的一些或全部的定义-授权-授权某个参与者访问服务的请求或响应。
-消息路由-提供消息路由功能，包括使服务提供节点转发该消息或收集消息并对消息进行整理的功能的请求或响应。
-节点注册-为节点进行注册操作，由此允许该节点通过中间节点被发现的请求或响应。
-节点发现(查询)-与媒体驱动节点的发现相关的请求或响应。
-通知-发送或传送目标通知消息到特定节点集合的请求或响应。
-服务发现(查询)-与由某个一个或多个节点的集合提供的服务的发现有关的请求或响应。
-安全凭证交换-与允许节点交换安全有关信息(例如密钥对、凭证等等)有关的请求或响应。
-升级-表示与接收功能升级有关的请求或响应。在一个实施例中，这个服务是完全抽象的，而其它轮廓提供具体的表示。
10.体系结构概述10.1服务适配层再次参见图2，服务适配层可以用来公开媒体驱动架构中的参与者的本地服务。在一个优选实施例中，MSDL被用来描述如何具体地在一个或多个接口上绑定到服务。服务描述还可包括其它信息，包含了下列中的一些或全部-将负责授权访问服务的一个或多个服务提供者的列表。
-对服务的目的和用途的语义描述的指针。
-如果该服务是来自一组其它服务的精心设计的执行的复合服务，对必要的编排的说明。
除了充当以MSDL发布服务的逻辑点之外，在一个优选实施例中服务适配层还封装了由特定参与者支持的那些平台的任何MSDL轮廓中包含的MSDL数据类型和对象的具体表示。它还包含将对服务请求对应的MSDL消息映射成适当的本地服务实现的逻辑。
通常，服务适配层的实现包括图4所示的组件。尤其，典型的服务适配层实现在分层实现中将包括下列组件-封装了服务接口的MSDL绑定中说明的服务接口入口点的层。通过这些接入点，可以进行服务调用，传入输入参数数据并输出结果。
-对应于MSDL消息处理逻辑的层。这一层通常包含驱动处理的某种消息泵、某种类型的XML数据绑定支持以及初级XML分析器和数据表示支持。
-表示对应的以MSDL描述的服务消息被映射到其上的可用本地服务的层。
10.2架构支持库再来参见图2，该架构支持库提供了使得实体参与媒体驱动架构更容易的可选支持功能集。如何分解该库(对象集、功能集等)以及如何实现它将根据目标平台而变化。可能有支持不同功能的多种版本的支持库。通常情况下，该支持库中的可用功能包括下列中的一些或全部-服务代理-封装了使得媒体驱动节点能够向服务提供节点的目标集合进行服务调用请求并接收一组响应的功能。
-MSDL语言处理程序-用于处理MSDL语言部分的功能。
-服务缓存接口-允许节点管理所发现的节点和它们支持的服务之间的映射的公共服务提供者接口。
-工作流整理器接口-允许节点管理并处理MSDL的整理的服务提供者接口。它提供了基本的程序模块以编排服务。目前，这个接口一般是由支持消息路由并支持中间排队和消息整理的节点实现。
-通知处理器接口-服务提供者接口，用于勾住支持到一些明确定义的通知处理引擎的通知处理的媒体驱动节点。
-混合支持功能-用于生成消息ID、时间戳等等的程序。
10.3通信方式给出媒体驱动架构的优选实施例中支持的以及用在不同支持库组件(例如服务代理)中的一般通信方式的基本概述是有帮助的。有多种基本类型的通信方式，包括异步RPC传送方式-在预计满足一个请求将占用延长的一段时间而客户端不想等待时这个模型有效。这里，客户端提交带有其将由一些服务提供节点以异步模式处理的预期的请求。一个服务提供端点可能响应表示它不支持这种模型，或者如果该服务提供节点不支持这种模型，它可以返回一个响应，携带有可以在后续请求中被提交给该服务请求节点以确定它是否对该客户端的请求有响应的标签。在一个优选实施例中，支持这种模型的服务请求端点将根据一些内部策略将未决请求的响应缓存起来。如果一个客户端试图挽回与这种请求相关的标签，并且没有响应可用，或者响应已经被该服务提供节点丢弃，那么可以返回适当的出错响应。
同步RPC传送方式-这里，客户端提交了一个请求然后等待返回一个或多个响应。提供服务的具有媒体驱动功能的端点可能以它不支持这种模型的指示来响应。
基于消息的传送方式-这里，客户端提交了一个请求，指示它想通过与它的通知处理服务接口的一个或多个相关的消息通知接收任何响应。一个节点可能回以它不支持这种模型。下面说明该通知架构的示范实施例。
上述交互模式都不需要阻塞或等待响应或者显式地轮询。可以使用线程或其它平台特定的机制以用上述传送方式机制模拟阻塞和非阻塞语义。
10.4服务代理具有媒体驱动功能的端点可以使用各种发现、名字解析和传输协议。结果，通常可以期望它使用灵活的可扩展的通信API。服务代理API对允许媒体驱动节点进行服务请求并接收一组目标媒体驱动节点的响应的功能提供公共接口。可以用客户端范围内(以共享库形式)或共享库范围之外(以运行在不同进程中的代理形式)的多种形式实现服务代理。服务代理实现的确切形式优选地是根据平台或客户端的需要而设计的。服务代理的使用是可选的，尽管通常它提供了重要的功能。服务代理的一些常见用途包括-服务调用的公共的可重用的API。
-对围绕传输通道的协商和使用的问题的封装。一些传输通道需要TCP/IP之上的SSL会话建立，一些通道可能只支持UDP/IP上的不可靠通信，其它信道可能根本不基于IP。在一个优选实施例中，通常对客户端隐藏了这些细节。
-对围绕用于消息路由的初始的媒体驱动节点集的发现的问题的封装。例如，有线机顶盒可以有专用的网络连接并且需要所有消息通过特定的路由和介质流动，而家庭网络中的便携媒体播放器可以使用UPnP发现来找到可直接访问的多个端点。另外，优选地对客户端隐藏了这些细节。
-“传统”客户端不能或不能选择通过MSDL消息的创建与其它媒体驱动节点进行直接对话。这里可以创建理解客户端所支持的任何本地协议的服务代理版本。
服务代理可以被实现成静态组件，只支持固定集合的协议绑定，或者被实现为能够动态地支持新的绑定。一般的服务代理模型的两个例子是(1)服务代理直接接收并返回MSDL消息给客户端，和(2)服务代理支持客户端所理解的一些本地协议。服务代理可以被看作具有两端请求参与者使用的客户端，和与其它具有媒体驱动功能的端点交互的服务端。
客户端和服务代理之间的两种主要交互模式是模式1(图5a)。客户端直接形成MDSL请求消息并将它们提交给服务代理。它接收到MSDL格式的一个或多个消息，通常它需要对它们进行收集、解析和处理。客户端还可以提交显式的服务绑定集合以用在为请求的传送指定目标中。这些服务绑定可能已经由进行服务查找操作的客户端获得，或者通过使用从先前的请求响应中获得的信息而获得。
模式2(图5b)。服务代理适应客户端可以通过一些本地通信协议交互的客户端模型，服务代理将接受这些本地通信协议并且这些本地通信协议转换自MSDL或转换成MSDL以允许客户端参与到媒体驱动架构中。这里，本地协议或本地协议和执行环境的组合提供了服务代理所需的任何信息以生成适当的MSDL请求并在必要时确定适当的目标服务绑定。
在服务端，支持服务代理和提供服务的具有媒体驱动功能的端点之间的多种类型的交互模式，并且像客户端一样，可以设计交互模式并且交互模式可以根据多种标准(包括请求的本质、下面的通信网络、应用的本质和/或与任何目标服务绑定相关的传输协议)而变化。
在一种模式下，服务代理直接启动与多个潜在的服务提供者的通信，并接收送回的响应。这种交互模式可能符合正被从客户端转播以由服务代理使用的多个服务绑定，或者它表示存在服务代理在转播消息中使用的广播或多播。服务代理可以选择收集响应并整理或者只是返回第一个可接受的响应。
在图6所示的模式中，服务代理并不直接与目标服务提供端点通信，而是通过中间节点发送请求，中间节点转播请求、接收任何响应并将它们送回服务代理。这种交互模式是由于-服务代理不能/不希望直接支持与服务提供端点相关的任何服务绑定但能够与希望充当网关的中间节点建立关系。
-客户端也许能够发现或确定任何合适的服务提供节点的服务绑定，并希望允许一个中间节点试图发现任何适当的服务提供者。
-服务代理想要利用支持更健壮的收集和整理功能的中间节点，这些更健壮的收集和整理功能允许服务代理和服务提供者之间有更灵活的通信模式。
或者，除了上述基本的服务端交互模式之外，还可以有实现了上述模式或新模式的组合的服务代理实现。
10.5工作流整理器在一个优选实施例中，对大多数有效的媒体驱动服务请求的完成通常需要某一类型的协作机制，该协作机制能够管理请求事件流、管理包括短暂的中间结果在内的任何相关数据并确保遵循与完成相关的规则(如果有的话)。这个功能可以用事务协商程序的形式提供，从关系数据库中简单的事务监控程序到在微软MTS/COM+中所看到的更通用的代理。在一个优选实施例中，工作流整理器是可编程的机制，通过它媒体驱动节点编排对服务调用的处理和完成。
在一个优选实施例中，可以根据特定媒体驱动端点的特征和需求设计工作流整理器，并且它被设计用来支持大量功能，从传统的消息排队到更复杂的分布式事务协商。简单的工作流整理器为任意MSDL消息的存储和检索提供了接口。通过构建工作流整理器，可以支持大量的功能，包括-对服务请求的收集以进行更有效的处理。
-将服务响应简单地聚集成复合响应。
-对多个服务请求和服务响应的手工编排以便创建复合服务。
-对多个服务请求和服务响应的自动编排以便创建复合服务。
图7示出了另一潜在的交互模式。这个交互模式从服务请求到达媒体驱动节点并通过该节点的服务适配层被接受开始。消息被传送到MSDL消息泵，它将首先驱动然后由工作流整理器驱动以满足请求并返回响应。这个模式是多个服务处理模式的基础。在一般的简单情况下，服务请求的完成可以用单个请求/响应交互模式表示，其中处理是相同的并且处理请求的规则被用MSDL完全表示为请求的一部分。但是，服务请求的完成可能取决于在某段时间上被异步处理的到达的多个MSDL消息。这种情况下，处理是由工作流整理器监控的潜在的长期事务的一部分。
在更复杂的情况下，特定服务请求的完成可能需要多个节点以协同方式参与。可以用MSDL表示处理请求的规则，MSDL可以随意包装来自其它服务编排描述标准(例如BPEL)的消息。在请求的完成中，节点的工作流整理器可能通过某组逻辑接口依靠功能或者可以和其它媒体驱动节点交互。
当一个MSDL请求消息被给到工作流整理器时，它确定处理该请求的正确规则是什么。根据工作流整理器的实现，可以用该节点所公开的一组服务的固定状态机的形式表示服务描述逻辑，或者用支持对更自由的表达形式的服务处理逻辑(例如用BPEL4WS描述)的处理的方式表示它。工作流整理器体系结构优选地是模块化并且可扩展的，支持插件。在一个优选实施例中，MSDL自身支持表示将多个媒体驱动服务编排成复合服务的规则的简单方式。
除了解释服务组成和处理规则外，在一个优选实施例中工作流整理器将需要确定在启动服务完成处理周期的环境中是否应该使用MSDL消息、或者是否只是进一步将MSDL消息输入正在进行的事务链中。MSDL消息包括可用于进行这些类型的判定目的的ID和元数据；还可以扩展MSDL消息以包括促进消息处理的附加信息，可以是服务事务特有的附加信息。
10.6通知服务除了异步和同步RPC-类通信模式外，在客户端明确启动请求并随即或者等待响应或者通过对标签的轮询周期性地检查响应的情况下，媒体驱动架构的优选实施例还支持基于通知意图的通信模式的纯消息传送类型。下面的组件构成了在一个优选实施例的通知架构中使用的核心MSDL数据和消息类型-通知-目标是感兴趣的具有媒体驱动功能的端点(节点)的包括指定类型的有效负载的消息。
-通知意向条件-用来确定特定节点是否将接收特定通知的标准。通知意向条件可能包括基于特定类型标识(例如节点ID、用户ID等)、事件(例如，节点发现、服务发现等)、近似性分组(例如，新的jazz俱乐部成员)或者一般分类(例如，广告)。
-通知有效负载-通知中标有类型的内容。有效负载类型可以从简单的文本消息到更复杂的对象。
-通知处理器服务接口-可以在其上接收通知的服务提供者接口的类型。服务提供者还描述了与该接口相关的通知意向条件，以及可接受的有效负载类型。支持这个接口的节点可能是该通知的最终目标或者是中间处理端点。
-通知处理器服务-能够将通知匹配到感兴趣的节点、根据某一策略传送通知的节点。
-通知发起者-向一组感兴趣的节点和/或通知处理节点的一个中间集合发出通知的节点。
像所有的MSDL数据类型和消息一样，通知、通知意向条件和通知有效负载优选地也是可扩展的。另外，通知处理器服务接口优选地受任何其它媒体驱动服务接口从属的相同授权过程所支配。因而，即使一个特定的通知可能就意向条件和可接受有效负载来说相匹配，节点也可能根据与该通知的中间发送者或发起源相关的某一相关接口策略而拒绝接受它。
图8示出了发现了支持通知处理器服务的节点的一组通知处理节点。作为它的服务描述的一部分，支持接收通知的节点指定它的通知意向条件是什么以及什么通知有效负载类型是可接受的。
图9示出了如何传送通知。任何节点都可以是发起源以及通知的处理者，也可负责传送它。选择处理来自外部通知-发起节点的通知的通知处理器可以和商用通知处理引擎(例如微软通知服务)结合在一起以提高效率。
10.7服务发现媒体驱动架构的优选实施例支持一组灵活的发现服务模式。这些模式可以被映射到现有的发现模式上。在一个实施例中，该架构支持这些基本的服务发现模式-客户端驱动-媒体驱动节点明确地发出请求到支持“服务查询”服务接口的某组目标节点询问它们是否支持指定的服务集合。如果该请求节点获得了授权，该服务提供节点将报告它支持所请求的接口和相关的服务接口绑定。如果那些节点公开了任何服务这是它们将支持的更普通的接口中的一个。
-节点注册-节点能够向其它节点注册它的描述，包括它所支持的服务。如果一个节点支持这个接口，它希望从其它节点接收请求并随即根据某一策略缓存那些节点描述。这些节点描述随后可由接收节点或向具有缓存起来的节点描述的节点进行服务查询的其它节点直接使用。
-基于事件-节点发出表示状态变化(例如节点活动/可用)的通知，或者一个节点通告它支持某些具体服务。通知可以包含对该节点和它的服务的完整描述，或者只包含与该事件相关的节点的ID。感兴趣的节点随后可以选择接受并处理该通知。
图10示出了客户端驱动的情况，其中某一请求节点向目标服务提供节点进行服务查询请求并接收指出该服务提供者是否支持所请求的服务的响应。
图11示出了节点注册情况，其中某一请求节点想要向打算接收它的描述并根据某一内部策略将其缓存起来的另一目标节点注册它的描述。该请求节点向目标服务提供节点发出注册请求并接收表示该服务提供者是否缓存了它的描述的响应。
图12示出了正通过通知(这种通知可能以多种形式到来，包括与节点状态中的一般状态变化有关的通知)被告知服务存在的具有媒体驱动功能的节点或者明确发送与服务可用性有关的通知的节点。
10.8服务授权在媒体驱动节点允许访问指定服务之前，它优选地首先确定该请求节点是否被允许访问。在一个优选实施例中，允许访问是根据两个不同但相关的标准。第一个是该服务提供节点对于这次通信是否相信该请求节点，第二个是是否存在允许该请求节点访问所请求的服务的接口的策略。
10.8.1建立信任在一个优选实施例中，媒体驱动架构对任意节点集如何达到彼此信任没有具体的要求、标准或决策逻辑。信任语义可以随节点而完全改变。媒体驱动架构努力提供允许节点协商相互可接受的信任关系的标准工具集。在节点间的信任判定和建立过程中，媒体驱动架构的优选实施例支持可用于建立信任关系的节点凭证交换。在该媒体驱动架构内，可以用多种不同模式交换与信任有关的凭证。例如-服务绑定属性-信任凭证作为服务接口绑定一部分被隐含交换的模式。例如，如果一个节点以SSL上的HTTP发送或作为需要WS-安全XMLt签名的Web服务公开它的服务，那么这个服务绑定的实际属性可以传送所有必要的与信任有关的凭证。
-请求/响应属性-通过MSDL请求和响应消息交换信任凭证的模式，可以选择包括消息上的属性作为凭证。
-显式交换-通过允许查询与特定节点包含的信任凭证有关的信息的服务-提供者接口明确地交换信任凭证的模式。这是最普遍的模式，通常需要单独的来回会话以交换凭证。服务接口绑定自身提供相互可接受的信任通道。
可以直接作为请求和响应消息上的属性交换与信任有关的凭证。例如，数字证明可以被附加到请求和响应消息上并随着请求和响应消息而流动，并可以用于形成信任关系。
在图13所示的情况中，节点可以通过安全凭证服务直接交换凭证，如果特定节点支持这个接口的话。
除了这些基本模型之外，该媒体驱动架构优选地支持这些不同途径的组合。例如，可以用与半信任服务绑定相关的通信通道更直接地引导其它安全-相关凭证的交换或者直接交换安全-相关凭证(它们可能有某种类型的内在完整性)并将它们用于与某一服务接口绑定相关的安全通信通道的建立。
总之，建立信任必须遵循的信任模型语义和过程随实体而变化。有些情况下可以不需要节点之间的相互信任。这种类型的动态混合环境要求提供允许不同实体协商对环境敏感的信任语义的公共工具集的灵活模式。
10.8.2受策略管理的访问除了在一组交互节点之间建立信任关系之外，在服务提供节点允许请求节点访问服务之前它优选地还必须根据与该服务接口相关的任何策略确定是否允许这个访问。该媒体驱动架构提供了一致、灵活的方式进行这个判定。在一个优选实施例中，作为服务描述的一部分，将指定一个或多个媒体驱动节点作为授权服务提供者。将要求这些授权服务提供节点中的每一个都实现用于处理并响应“授权”查询请求的标准服务。例如，在允许访问一个服务接口之前，目标服务提供者可以分发一个“授权”查询请求到授权访问它的服务的所有媒体驱动节点，并可以只在所有授权实体都响应表示允许该访问时才允许访问。
如图14所示，服务提供节点向管理对所请求的服务的访问的所有节点发出授权请求，然后根据结果或者处理并返回适用的服务响应或者返回表示该访问被拒绝的响应。除了提供一致的机制之外，还希望有授权节点用来做出判定的机制在实践上尽可能公开以便能够为具体的平台和客户端实现最合适的策略判定机制。媒体驱动优选地是策略管理系统中枢；它对授权节点如何根据授权查询做出与对服务的授权有关的决策没有要求。
尽管媒体驱动优选地对由特定平台的授权节点使用的具体策略引擎和策略语言没有要求，但在一个优选实施例中要求它具有互操作性，即授权请求具有可交换和处理的某种标准形式。“授权查询请求”是可扩展的，能够携带灵活的有效负载以便它能够适应不同策略管理系统环境中的不同类型的授权查询。在一个实施例中，提供对至少两种授权格式的支持(1)用某一最小的通用的命名标准作为输入(例如简单的请求者ID、资源ID、动作ID、)提供非常简单的包装的简单格式和(2)SAML格式，它提供了传送包装好的安全确认标记语言形式的查询请求的方式。
在一个优选实施例中，要求任何授权节点至少识别并支持该“简单”格式并且能够将它映射到该授权节点上存在的任何本地策略表示格式。对其它格式，如果该授权节点不能处理或不能理解“授权”查询请求的有效负载它应该返回适当的出错响应。对该基本媒体驱动架构的扩展可以包括节点在可接受格式的授权请求上协商的能力，以及节点查询以确定特定的授权服务提供者节点支持什么格式的能力。
在一个实施例中，“授权”查询响应，尽管是可扩展的，但由简单形式组成以表示访问是否被许可。也可以有对这个服务的这个响应的其它形式，包括如果对该特定接口的访问得到许可对该请求节点必须要完成的义务的规定。
11.消费类媒体应用媒体驱动的实施例可以用来将不同的消费类设备链接到包括个人和局域网、家庭网关、基于IP和非IP的广域网的多级环境中的大量不同服务。例如，已经在一个使用蜂窝电话、游戏平台、PDA、PC基于web的内容服务、发现服务、通知服务和更新服务的互连系统中成功地证明了互操作性。本实施例支持多种媒体格式(例如MP4、WMF等)、多种发现协议(用于在蓝牙上并通过像UDDI、LDAP、活动目录这样的注册的服务发现)以及基于IP的通知和相同设备上的无线SMS(短消息)通知。编排功能用来帮助用户克服互操作障碍。当有对内容的查询时，不同的服务被协调起来以完成，包括发现、查找、匹配、更新、权利交换和通知服务。在优选实施例中，希望用户能够使用大多数任何设备、发出对内容的期望、并且几乎立即被内容和权利以及交付能力满足以使用且共享该内容。编排能力允许用户在动态多级网络中在任意点从实际上的任何设备察看家庭和基于Internet的内容缓存。可以将这个能力扩展到促进流和播放列表共享的更高级服务，使得临时广播和小范围广播容易发现和连接，并用很多不同的设备同时确保权利得到尊重。
在消费-中心端之外，通常想要找到一种方式来提供不依赖于对媒体格式、权限管理和完成协议的单组标准的端到端可互操作的媒体发布系统。在包括了内容创作者、发布者、设计者、服务提供者、设备制造商和用户的价值链中，在各个段中都有大量本地化的需求。就权限管理来说这尤其正确，这种情况下内容创作者需要向不同的下游价值链元素表达使用权利，使用权利在不同环境中有不同的应用。用户网关通常其关注集合要窄得多，并且终端用户设备通常只有非常简单的关注集合，即只播放内容。
采用动态自配置分布服务的充分自动化系统，内容创作者可以产生并打包内容、表达权利并放心地依赖由其它服务提供者增加的价值以几乎实时地将该内容提供给所有感兴趣的用户，不管他们在哪里或者他们在使用什么种类的设备。媒体驱动的实施例可以用来完成(或近似完成)这个目标，或其中的特征，并且能够提供用于多个服务提供者不必等待或依赖单组端到端标准就能创建并引入使用户和服务提供者都受益的新服务的方法。一个可能的途径允许数据权限管理被分解成具有集中在服务接口的策略管理而不是复制保护上的更自然的关注划分的组件。这种途径可能会在数字内容领域中改变用户和内容创作者之间的紧张关系，因为是以向用户提供有用的信息和即时满意的丰富的服务基础结构提供内容。策略管理能够限制盗版者利用他们的合法服务的程度。事实上，设计媒体驱动是为了允许网络效果鼓励非常丰富的合法服务集的进展产生超出盗版者所能提供的价值。
12.一般企业应用受策略管理的P2P服务编排看来在商业世界的一些领域中也有有趣的应用，例如供应链管理(SCM)和客户关系管理(CRM)。CRM是关于发现、获得并保持客户。几乎在任何以客户为中心的电子商务战略中它都是核心部分，在那里能够方便地使用集成信息系统和能让客户通过任何想要的通信通道通信的联系中心实现专注于客户。对供应商来说也是如此。大多数企业具有某种类型的分层结构和部门化，并且在内部工具良好的部门和过程观点不一定对客户和供应商也能工作良好。希望能让企业的部门为它们的部门发布全面的服务接口集合，以使那些服务能由不同客户和供应商(根据策略)以优化他们的过程和服务的方式使用。这是超越企业信息入口的一大步。
今天，大多数企业用相对昂贵的预先包装好的应用程序组(表现为使用专有客户端/服务器基础结构的单一软件应用)实现了CRM。这些应用程序组在大量的配置后在企业内互相协作。web服务允许在通信不仅发生在封闭的LAN还发生在MAN和WAN上的地方使用开放协议和分布式web服务基础结构。这个模式使得远程应用服务提供者(ASP)能够管理CRM应用程序将其作为服务集合交付给来自不同数据中心的商业中的多个实体。企业单位和部门变成了这些服务的入口，有些情况下变成了这些服务的聚集者。在IT产业正在面向服务体系结构/应用(SOA)的领域中经历的发展环境中可以看到这一点。企业和客户到应用相关服务的接口都可以从简单的基于浏览器的应用到更大型的以PC为中心的应用。
这个新模型仍然面对一些重大的障碍，对它被主流接受带来了困难，例如信息机密性和访问控制。当ASP提供一个CRM解决方案时，企业可能遇到围绕别的公司手中的敏感客户数据的位置的问题。该公司必须确保只有合法的实体能够访问这个信息。从客户的角度来看，他们现在可能与别的公司有新的关系(可能是明显的或隐藏的)。所需要的是让客户和企业都能在他们的信息上进行访问控制的基础机制。
应用可扩展性。ASP通常与一小组特殊的技术提供商和他们的相关产品或服务结盟。企业通常更喜欢平衡来自不同供应商的不同技术集的灵活性。应用架构不必受限于特定ASP的当前商业关系或技术选择，而希望具有能够让ASP快速有效地集成从不同技术提供商或其它ASP提供的新功能的基础机制。应用架构还应该能够集成由基于(例如)内部开发的扩展的企业单位自己直接提供的CRM服务。
服务层协议(SLA)。企业的服务需要通常不是静态的。相反，它们通常会根据变化的商业条件而变化，包括由竞争驱动的新功能、基于内部商业活动的运转负载特征和正在为特定活动支持客户数量以及平衡较低费用服务选择的能力。有些情况下这些变化可能需要大量时间的人的干预，但其它情况下可以根据一组指定规则自动化或快速重新配置这些变化。对于这两种情况来说，可以将CRM应用服务看作是根据已有的环境和ASP和商业单位之间授权的协议编排成新的配置。这些类型的应用可以被表征为自-组织。
媒体驱动的实施例在解决这些需要的一些或全部中可以扮演一个角色。例如，媒体驱动的实施例可以用来提供解决构建动态的、面向服务的、自组织的应用(例如CRM，其中只有信任的、获得授权的实体能够访问有关的服务和信息)中的上述要求所需必要的基础构建模块。
图15示出了展示媒体驱动如何被用在向不同方面交付CRM-相关服务的环境中的情况。在图15所示的场景中，商业单位能够使用大量不同ASP提供构造不同类型的CRM应用或提供客户数据上的不同视图给它的组织内的不同部门或它的客户所必需的服务。
该场景示出了使用由该媒体驱动架构的优选实施例提供的功能的几个方面，包括下列中的一些或全部-不同CRC技术提供商之间隐式或显式的互操作性。通过说明必要的接口并在ASP一级或直接在现有的CRM软件包上(用服务适配层)提供适当的绑定，企业就能够使用具有来自不同提供商的各种CRM技术的单个ASP或多个ASP。
-通过经由该媒体驱动架构访问客户数据，能够控制它用于访问控制的丰富的策略管理架构。
-部门能够通过服务代理访问对它的应用必需的CRM有关服务，由此将围绕该商业单位与传输协议、数据格式等的兼容性的问题隔离。
-可以控制该媒体驱动架构中部门、数据仓库和应用服务提供商之间的交互。优选地，只有合法授权的实体能够访问该服务、并且服务调用将只在不同的媒体驱动架构参与者能够在它们的交互中建立可接受的信任级别时才会发生。
-服务组合和编排。CRM应用是自组织的，因为应用由来自若干不同ASP被编排在一起的服务组成，或者应用是从单个ASP被交付但仍然由多个服务构成，这多个服务的组成和使用需要对不同客户视角动态配置。由服务提供商公开的功能由服务级协议(SLA)和运行环境驱动而随时间变化。媒体驱动工作流整理器可以用来编排服务。用于控制这个交互的规则可以用MSDL直接指定或者在SLA中用某种标准方式编码，只要存在为理解并解析该描述的工作流整理器所写的插件。想起工作流整理器与媒体驱动消息泵合作收集并处理必要的消息以确定如何根据需求提供指定服务。
在当前的实施例中，是用一组基于相互信任的PolicyWorks和PolicySpeak策略表示语言的分布式策略管理服务实现媒体驱动。但是，媒体驱动被设计为使用其它策略管理架构和语言，例如IBM的PolicyDirector和XACML，并且在一个优选实施例中媒体驱动提供了策略管理服务接口，以便能够使用任何适当的策略管理架构和/或策略表示语言。
作为背景，PolicyWorks是一组软件组件，可被配置用来发起、部署和实施关于在企业内和企业之间企业和客户之间对基于网络的内容、服务和资源的使用的规则、权利和策略。注意企业策略或控制通常需要和用于识别用户、凭证、目录、内容元数据和其它策略和控制的装置交互。PolicyWorks被设计为被有效地集成到企业中以控制已有的应用、目录和识别系统。PolicyWorks的一个目标是简化对统一对跨越从网络和文件系统访问管理、企业信息入口和资产管理到供应链管理、web服务、数字柜服务和消费媒体订购应用的大量主要应用的策略和规则的安全管理。
在一个优选实施例中，PolicyWorks体系结构基于公开了大量基本接口的逻辑模型-受管理选项-这个接口由应用程序(例如上面提到的那些)用来管理这些应用程序关于具体的资源、内容对象或服务的动作。实际上可以用PolicyWorks管理任何对象，提供持久的安全保护、访问控制、用途监控和检查或事务管理。通过这个接口，应用程序可以使对象、服务或资源可用、在策略控制下、确保使用规则和要求得到了遵守。管理组件封装了管理对象必需的方法和操作。PolicyWorks允许为这种管理使用大量可定制的和非定制的解决方案，例如Microsoft Office和Adobe Acrobat中的文档保护机制，以及由J2EE EJB和Microsoft.Net架构提供的代码资源和服务保护机制。
-策略查询-这个接口用来精确地判断对所管理的对象、资源、或给特定用户的服务、条件集合、环境数据以及任意其它有关因素允许什么动作。对查询的响应可以包括许可和/或附加条件以及该对象的使用所伴随的义务。该管理组件在接收到对查询的响应后负责实施该策略并执行(或使执行)任何义务并监控所请求的使用的结果。
-凭证查询-这个接口由策略管理器用来确定可能在与所管理的操作相关的策略中扮演角色的用户的属性。这个逻辑模块在实际实现中得到了丰富，以便，例如，策略管理器访问内部和外部的大量接口和资源以确定对策略查询的响应，因为可能有大量目录、以及与活动者(用户、策略创建者、资源管理者等等)和所管理的对象自身有关的规则和元数据资源。
-安全服务-这个接口用来为所管理的动作的请求者获得身份管理服务，并为所管理的对象获得持久的保护服务。
-策略管理-这个接口用来管理适合所管理的对象的规则和控制的分布式策略管理数据库。用于创建并维护策略的各种工具使用这个接口。这些工具能够提供非常直接的方式来应用并管理策略。例如，使用这个接口可以创建将策略与文件系统中的共享文件夹相关的工具，并能够允许用户简单地通过在该文件夹中拖放文档就能将该策略应用到文档(或对象)。其它工具可以使用更复杂的创建技术，它们使用任意数量的策略表示语言以非常精确和有目标的术语指定策略。
SCM是另一应用，在那里实际上任何企业的成员都能将他们的外部提供商网络看作一个大的虚拟库房，具有由媒体驱动服务管理的发送顺序策略，并且记帐是通过媒体驱动兼容的通知服务协商的。
尽管为了明确起见已经用一些细节说明了前述发明，但显然在不偏离本发明的基本原理的前提下可对其进行特定的变化和改进。应该注意到有很多可靠方式实现本发明的过程和设备。因此，现有的实施例将被看作说明性而非限制性的，并且本发明也不限于这里所给出的具体细节。
媒体驱动框架的示范实施例图1(附件A的部分)
媒体驱动节点的概念视2(附件A的部分)
一般交互模式示例图3(附件A的部分)
服务适配层图4(附件A的部分)
服务代理-客户端MSDL交互模式图5a 服务代理-客户端本地交互模式图5b(附件A的部分)
服务代理-服务端-中间点交互模式图6(附件A的部分)
媒体驱动工作流整理器的交互模式图7(附件A的部分)
通知-服务发现图8(附件A的部分)
通知-传送图9(附件A的部分)
服务发现-客户端驱动图10(附件A的部分)
服务发现-给定注册图11(附件A的部分)
服务通知-基于事件图12(附件A的部分)
根据直接交换建立信任图13(附件A的部分)
受策略管理的方向图14(附件A的部分)
图15(附件A的部分)
附录B数字权限管理引擎系统和方法相关专利申请附录B对应美国临时专利申请第60/504,524号，名为“数字权限管理引擎系统和方法”，申请人为Gilles Boccon-Gibod，于2003年9月15日提交。该专利申请(附录B)与共同所有的美国临时专利申请第60/476,357相关，后者的发明名称为“用于对等服务编排的系统和方法”，申请人为William Bradley和David Maher，于2003年6月5日提交(“the Bradley et al.application”；附录A)。这里，在附录B中对“the Bradley et al.application”的引用指的是附录A。
版权授权本专利文档的公开部分包含受版权保护的内容。版权所有人并不反对任何人将本专利文档或专利公开部分复制到WIPO或U.S.专利商标局的专利文件或记录中，但保留其他所有版权。
背景技术：
本发明一般性涉及数字信息和服务的分发和使用。更具体地，公开了用于提供、支持和/或使用数字权限管理引擎的系统和方法。
诸如Internet之类的网络已经成为传递数字内容的主要媒介。Web服务标准的出现有望加速这一趋势，使公司能够提供合并多个软件平台并且通过标准化机制与其他web服务协作的复杂服务。
发明内容
本发明的实施例提供一种利用web服务模型的数字权限管理引擎。与要求相对复杂和重量级的客户端引擎以处理受保护内容的传统的数字权限管理(DRM)系统相比，本发明使得客户端的DRM引擎相对简单，而管理策略由在服务层运行的更丰富的策略管理系统设置。本发明的实施例还在选择媒体格式和加密协议方面提供了更大灵活性，并且能够帮助实现DRM系统之间的互操作。
本发明的优选实施例提供了一种能够用来构建支持DRM的强大应用的简单、开放和灵活的客户端DRM引擎。在一个优选实施例中，将DRM引擎设计为能够容易地集成到web服务环境中，诸如在Bradley等的应用中所描述的，以及实际上集成到任何主机环境或软件体系结构中。在一个优选实施例中，DRM引擎与具体的媒体格式和加密协议无关，允许设计者按照需要使用灵活地使用标准化的或专用的技术。另外，优选实施例使用的管理模式相对简单，但可以用来表示复杂的关系和业务模型。
本发明的优选实施例能够用来实现下面的部分或全部目标简单。在一个优选实施例中，DRM引擎使用最低要求的基于栈的虚拟机(VM)来执行控制程序(例如，执行管理策略的程序)。例如，在一个实施例中VM可以仅由几页代码组成。
模块化。在一个优选实施例中，我们把DRM引擎设计成一个单一的模块，它集成在一个支持DRM的更大型应用内。现在，我们可以从宿主环境中请求许多以前由单个DRM内核执行的功能(例如加密服务)，该宿主环境可以向其他代码模块提供这些服务。这使得设计人员能够相对容易地整合标准或专用技术。
灵活性。由于采用模块化设计，DRM引擎的优选实施例可用于从嵌入式设备到通用PC的各种软件环境。
开放。DRM引擎的优选实施例适合作为参考软件，这样，用户就可以使用几乎任何编程语言和在他们能够完全控制的系统中实现代码模块和API。在一个优选实施例中，系统并不强制要求用户采用特定的内容格式或限定内容编码。
无关乎语义。在一个优选实施例中，DRM引擎的基础是一种简单的基于图的模型，该模型将授权请求转换为对图结构的查询。图中的顶点表示系统中的实体，有向边表示这些实体之间的关系。但是，DRM引擎并不需要知道这些顶点和边在任何特定的应用中表示什么。
与Web服务无缝集成。DRM客户端引擎可以采用多种方式使用Web服务。例如，可以通过服务来动态发现授权图中的顶点和边。也可以通过高级Web服务来发现内容和内容许可，并将其传递给DRM引擎。尽管优选实施例的DRM引擎的具体实施例可以配置在许多方面影响Web服务，但是其体系结构与Web服务无关，可以用作一个独立的客户端DRM内核。
简化的密钥管理。在一个实施例中，可以重新使用授权图拓扑来简化内容保护密钥的派生，而不需要加密重定位。这种密钥派生方法是DRM引擎一个可选特性，但其功能非常强大——系统也可以或者能够与其他密钥管理系统集成。
管理、加密与内容的分离。在一个优选实施例中，管理内容的控制在逻辑上与用于执行管理的加密信息不同。同样，控制和加密信息在逻辑上也与内容和内容格式不同。可以采用分离的方式或一个统一数据包传递每个元素，这样就可以在设计内容传递系统时具有高度的灵活性。
本发明的优选实施例可以用来实现前述的部分或全部目标；但是，应该认识到本发明也可以由不实现以上目标的系统实现。
在一个优选实施例中，DRM引擎包括一个虚拟机(VM)，用于决定是否允许对受保护内容进行某些特定操作。我们可以利用最小限度的一组指令将这一控制VM实现为一个简单的基于栈的机器。在一个实施例中，它能够执行逻辑和算术计算，并从主机环境中查询状态信息，以便检查诸如系统时间和计数器状态等参数。
在一个优选实施例中，DRM引擎使用基于图的算法检验DRM价值链中的实体之间的关系。图1示出了这样的授权图的一个示例。如图1所示，该图包括一个节点的集合，这些节点由链路连接。在一个优选实施例中，链接的语义可能会随应用特定的方式发生变化。例如，从Mac顶点到Knox顶点的有向边可能表示Knox是Mac的所有者。从Knox到公共图书馆的边可能表示Knox是该公共图书馆的一名成员。在一个优选实施例中，DRM引擎并不强加或解释这些语义，它只是确定图中是否存在路径。
例如，内容所有者可以创建一个由控制VM解释的控制程序，如果使用设备归公共图书馆的成员所有并被RIAA认可，则允许播放特定的音乐片断。当运行于该设备的控制VM评估此控制程序时，DRM引擎确定在便携式设备和公共图书馆之间以及便携式设备和RIAA认可之间是否存在链接。图中的边与顶点可以是静态的，内置在设备之中，也可以是动态的，通过与主机应用通信的服务被发现。
由于没有对顶点和链接强加语义，因此该优选实施例的DRM引擎可以支持更大的灵活性。该系统可适用于从传统的基于委托的策略系统到授权域和个人局域网。
在一个优选实施例中，DRM客户端还可以重用授权图来派生内容保护密钥。系统设计人员可能会选择允许链接的存在也表示某些加密信息的共享。在这些情况下，授权图可用于派生内容密钥，而无需显式加密重定位到使用设备。
DRM引擎的优选实施例是模块化的，因而能够集成到许多不同的设备和软件环境中。图2示出了将DRM客户端引擎集成到内容使用设备中的典型集成。在诸如图2所示的系统中，典型的内容使用事件如下进行主机应用202一般通过其用户接口204接收一个访问特定内容片段的请求。然后主机应用202将请求和所有相关的DRM引擎对象(最好对于主机应用是不透明的)发送到DRM引擎206。DRM引擎206通过定义良好的接口向主机服务模块208请求附加的信息和加密服务。例如，DRM引擎206可能会询问主机服务208特定链接是否是可信任的，或者要求某些对象被解密。有些必需的信息可能是远程的，这种情况下，主机服务208可通过服务接入点214请求网络化服务提供信息。
一旦DRM引擎206确定特定操作是允许的，它将表明这一点，并将必要的加密密钥返回给主机服务208，主机服务208启动媒体表现210(例如，通过通过扬声器播放内容，在显示屏上显示内容等)，其按照需要与加密服务212协作。
图2所示的系统体系结构是如何在应用中使用DRM引擎的简单例子，但是它只是多种可能之一。例如，在其它实施例中，DRM引擎可以在相对复杂的策略管理系统的管理下集成到打包应用中。
应认识到，公开的实施例可以以多种方式实现，包括进程、设备、系统、装置或计算机可读介质。通过以下的附图和详细说明，将更详细地说明本发明的实施例的这些和其它特征和优点。
本发明的简要描述通过参考以下结合附图的详细说明，将容易理解本发明的实施例，其中相同的参考标号指示相同的结构部件，其中图1示出了依照本发明一个实施例的授权图。
图2示出了依照本发明实施例的数字权限管理系统。
图3示出了在本发明的优选实施例中DRM引擎可以用于内容保护和管理的各种对象。
图4示出了依照本发明实施例的节点和链接对象。
图5示出了依照本发明实施例的控制虚拟机和DRM引擎的集成。
图6依照本发明一个实施例的编码模块图7示出了使用节点图来帮助实现内容加密和解密。
详细描述这里描述新颖的数字权限管理引擎的实施例。如本领域普通技术人员将会理解的，该引擎本身是新颖的，如同它的许多特征、方面、组件和应用一样。下面给出对本发明的有效主体的详细描述。尽管在进行说明时结合了若干实施例，但应该认识到，本发明并不局限于任一实施例，而是包括各种替代、修改和等效体。举例来说，尽管一些实施例是在面向用户的内容和应用的环境下描述的，但熟悉本领域的技术人员会认识到，所公开的系统和方法可以很容易地应用到更广泛的应用中。例如，这些实施例可以很容易地应用于企业内容和应用环境，而没有任何限制。另外，尽管为了帮助全面理解本发明而在以下说明中列出了各种具体细节，但是不具备部分或全部此类细节的一些实施例也可以实施。此外，为了清晰起见，对于与本发明相关的本领域共知的某些技术资料没有进行详细说明，以避免不必要地模糊本发明。
在一个优选实施例中，DRM引擎在一组基本对象或组装块上运行。图3提供了对这些对象的高层次的举例说明。如图3所示，在一个优选实施例中，由内容(Content)对象302表示的数据利用密钥加密。该密钥由内容密钥(ContentKey)对象304表示，内容和密钥之间的绑定由保护器(Protector)对象306表示。管理对象的使用以便对内容解密的规则由控制(Control)对象308表示，内容密钥304和控制308之间的绑定由控制器(Controller)对象310表示。服从系统在内容对象308中的字节码表示的规则的管理下使用内容解密密钥。
内容对象302在优选实施例中，内容对象302是一个“外部”对象。该对象的格式和存储不是在DRM引擎的控制下，而是在主机应用(例如，它可以是MP4电影文件或MP3音轨等)的内容管理子系统的控制下。但是，在一个优选实施例中，内容的格式使得允许ID和内容有效负载相关。内容有效负载以独立于格式的方式加密(例如，利用对称加密程序，例如AES)。
内容密钥对象304在一个优选实施例中，内容密钥对象304包括唯一的加密密钥和相关ID。ID的目的是使得保护器对象306和控制器对象310能够引用内容密钥对象304。内容密钥对象304中封装的实际密钥数据是它自身的加密，这样它仅能由被授权解密该内容的接收者读取。内容密钥对象304优选还可以指定用于加密该密钥数据的密码系统。用于保护该内容密钥数据的密码系统被称为密钥分发系统。可以使用不同的密钥分发系统。
保护器对象306在一个优选实施例中，保护器对象306包含使得DRM引擎能够找出使用了哪个密钥加密内容对象302中包含的数据的信息。保护器对象306还包含关于使用了哪个加密算法加密该数据的信息。保护器对象306包含一个或多个引用内容对象302的ID，一个引用内容密钥对象304的ID，内容密钥对象中包含加密该数据所使用的密钥。在一个优选实施例中，如果保护器306指向多于一个内容对象302，则所有这些内容对象表示已经使用相同的加密算法和相同密钥加密的数据。
控制对象308控制对象308中包含的信息使得DRM对象能够在主机应用请求时做出关于是否允许对内容的特定操作的决定。管理内容密钥的使用的规则被作为控制字节码编码在控制对象308中。控制对象308还包含唯一的ID，以便它们可以被控制器对象310引用。在一个优选实施例中，控制对象308是已签名的，这样DRM引擎在使用它做决定之前，可以验证该控制字节码是有效和可信的。可选的，控制对象308的有效性也可以通过验证控制器对象310中包含的安全哈希(当这个信息可用时)而得到。
控制器对象310控制器对象310包含使得DRM对象能够找出哪个控制对象308管理由内容密钥对象304表示的一个或多个密钥的使用的信息。在一个优选实施例中，控制器对象310还包含它们引用的内容密钥对象304中包含的密钥数据的哈希值，这样密钥数据和内容密钥对象304之间的绑定就不容易被篡改。控制器对象310还可以包含帮助验证它们所关联的控制对象308的完整性的信息。控制器对象310优选是已签名的，这样DRM引擎能够信任内容密钥304和管理它的控制对象308之间的绑定的有效性，以及内容密钥ID和实际的密钥数据之间的绑定的有效性。在控制器对象310中包括控制器对象310所引用的控制对象308的哈希的实施例中，不需要单独验证控制对象308的签名就能够推导出控制对象308的有效性。
如同前面结合图1所示，在一个优选实施例中，DRM引擎使用一种基于图的算法检验DRM价值链中的实体之间的关系。如图1所示，该图包括以链接相连的节点的集合。节点对象表示DRM概要中的实体。在一个优选实施例中，DRM引擎不具有关于节点表示什么的隐式或显式的语义。
使用DRM引擎的给定部署(DRM概要)将定义存在哪种类型的规则，以及不同的节点对象代表什么角色和身份。如图4所示，通常使用节点对象的属性表示语义信息。链接对象表示节点之间的关系。链接对象还可选地包含某些加密数据，这些数据使得DRM引擎能够使用该链接进行内容密钥的派生计算。与节点相似，在一个优选实施例中，DRM引擎不具有关于链接关系表示什么的隐式或显式的语义。在特定DRM概要中，取决于链接发自哪个节点和到达哪个节点，链接关系的意义可以表示成员关系、所有关系、关联和/或其它类型的关系。例如，在一个典型的DRM概要中，一些节点对象可以表示用户，其它节点对象可以表示用户，另一些可以表示用户群。在这个环境中，设备和用户之间的链接可以表示所有关系，用户和用户群之间的链接可以表示成员关系。图4示出了节点和链接对象的例子。
节点402节点对象表示系统中的实体。节点对象的属性定义节点表示什么的某些方面，诸如节点对象在DRM概要的环境中表示的角色或身份。在一个优选实施例中，节点对象还具有机密性不对称密钥对，该密钥对用于将机密信息定位到对该节点对象的机密部分具有访问权限的子系统(通常是该节点表示的实体，或者是负责管理该节点的一些实体)。定位到一个节点的机密信息优选利用该节点的机密性公共密钥加密。在使用用于内容密钥分发的可选的内容密钥派生系统的实施例中，内容保护非对称密钥对和内容对象对称密钥结合链接对象一起使用。
链接404在一个优选实施例中，链接对象404是已签名的声明，其声明在其顶点是节点对象的图中，在“发出”和“到达”节点之间存在一条有向边。对于给定的节点和链接结合，如果在图中的节点X顶点和节点Y顶点之间存在一条有向路径，那么在节点X和节点Y之间存在一条路径。当节点X和节点Y之间存在路径的时候，说节点Y是从节点X可到达的。因而使用链接对象所表示的声明表达哪个节点是从其它节点可到达的。管理内容对象的控制可以使用特定的目标节点从表示请求对内容对象进行操作的实体的节点的可到达性，作为允许特定操作发生的条件。例如，如果节点D表示想要对一个内容对象执行播放操作的设备，管理该内容对象的控制可以测试表示特定用户的特定节点U是否是可到达的。为了确定节点U是否是可到达的，DRM引擎检验是否存在一个链接集合能够建立节点D和U之间的路径。
DRM引擎优选在使用链接对象确定节点图中存在路径之前先验证它们。取决于用来签署链接对象的证书系统(例如x509v3)的特定特征，可以给予链接对象有限的生命周期，废止链接对象等。在一个优选实施例中，管理哪些实体可以签署链接对象、可以创建哪些链接对象和链接对象的生命周期的策略也可以不直接由DRM引擎处理。这些策略在DRM引擎之外存在，并且通常将利用节点的属性信息。例如，在某个策略下已经被授予创建设备节点和用户节点之间的链接对象的能力的实体，很可能要检测它只创建了在具有指示它们确实代表一个设备的属性的节点对象和具有指示它们代表一个用户的属性的节点之间的链接。
最后，链接对象可以包含加密数据，该数据使得节点的内容保护密钥能够用于密钥分发。在一些实施例中，所述加密数据除了元数据之外还包含“发出”节点的私有密钥和/或对称内容保护密钥，其是利用内容保护公共密钥或“到达”节点的内容保护对称密钥加密的。在下面的题为“节点、链接和内容保护”的章节中提供了关于节点和链接的关系和操作的其它信息。
因为在一个优选实施例中，DRM引擎不隐式或显式地指定附加到这些基本对象上的语义，使用DRM引擎的系统将参与到那些对象的一个或多个使用模式中，其将那些对象放入一个语义环境中。这些语义环境将被称为DRM概要。在这个意义上，可以将DRM引擎对象看作用于构建DRM系统的组装块。
以下的段落举例说明了可以使用DRM引擎对象构建的DRM概要的典型类型。
示例1用户、PC和设备在这个DRM概要示例中，定义了以下实体用户(使用内容的个体)、PC(运行使用内容的软件的计算机)和设备(使用(例如播放)内容的硬件和软件组合)。在这个示例概要中，任何用户可以拥有无限数目的设备，并且可以与最多预定数目的PC(例如，4台PC)相关联。可以通过允许将内容绑定到用户的规则(例如，可以检测播放内容的PC或设备属于给定用户或与之相关联)管理内容。
用户、PC和设备，每一个都被分配了一个节点对象。这些节点对象具有指示它们是否表示一个用户、PC或设备的“类型”属性。
后端系统管理用户身份，并且创建用户节点以及PC节点和用户节点之间的链接对象。在将一个用户节点发送到PC软件实例之前，后端服务器将会通过在用户信息数据库中查找用户和确定希望同特定PC关联的该用户是否达到了4的限制条件，来执行“每个用户4台PC”的策略。在一些实施例中，系统可以为用户提供删除已有的PC-用户关联的方法，使得他们能够随着时间过去改变与他们相关联的PC的设置。PC软件将保持PC-用户链接对象，并且使用它们(只要它们有效)。
PC软件被授予了与设备和用户关联的能力。这意味着，除了管理PC节点外，PC软件还被给定了管理用户节点对象的责任。该软件具有访问那些节点的机密部分的权限。当一个用户想同一个设备相关联的时候(因为她想在该设备上播放她的内容)需要存在从该设备节点到该用户节点的一个链接对象。如果该链接对象不存在，PC软件将创建它，并且令其对所述设备可用。该设备将保持该链接对象，并且使用它(只要它保持有效)。
为了将内容绑定到用户，打包者应用将为该内容选择一个ID或使用现有的一个ID。打包者创建一个加密密钥和相关的内容密钥对象，以及将内容对象和内容密钥对象绑定的保护器对象。然后该打包者创建一个具有控制程序(优选以控制VM字节码编译)的控制对象，该控制程序将在并且只在请求执行一个播放操作的用户节点是从PC或设备节点可到达的时候，允许“播放”操作。通常，将把控制、控制器、保护器和内容密钥对象嵌入在打包的内容中(如果合适的话)，这样PC和设备就不需要单独获取它们。
当一个设备或PC想要播放内容的时候，DRM引擎将为该内容的内容ID找到保护器对象，然后找到该保护器引用的内容密钥对象，然后是引用该内容密钥对象的控制器对象，最后找到该控制器引用的控制对象。DRM引擎将执行该控制器对象的控制程序，该程序将检测用户节点是否是可到达的。如果设备或PC对象具有证明在它们的节点和所述用户节点之间存在路径的必要链接，那么控制器程序将允许使用内容密钥对象中表示的密钥，并且该设备或PC的媒体表现引擎将解密该内容并且表现该内容。
示例2短暂登录第二个示例使用了一个几乎与前面的例子所使用的相同的系统，该系统具有新增的特征管理创建PC节点和用户节点之间的链接对象的策略允许不超过例如12个小时的短暂登录，只要用户还没有在其他PC上拥有短暂登录。这个特征的目的是允许，例如，用户将他的内容拿到朋友的PC上，登录到那台PC一段时间和在朋友的PC上播放他的内容。当用户想要登录到朋友的PC，他输入他的登录凭证(这可以是用户名/密码、移动电话身份认证、智能卡、或该系统的策略下允许的任何身份认证系统)，后端系统检验该链接所需的用户节点和PC节点的属性，并且证实不存在仍然有效的短暂登录。如果满足了这些条件，后端服务创建连接该PC和该用户的链接对象，该链接对象具有符合要求的登录持续时间限制(例如，少于12个小时)的有效周期，以遵守该策略。令该链接现在允许PC播放该用户的内容，直到链接期满。
控制虚拟机控制虚拟机(或“控制VM”)是由DRM引擎的优选实施例使用以便执行管理访问内容权限的控制程序的虚拟机。以下是对适合DRM引擎体系结构的控制VM的描述，以及对该VM的基础元件的描述，其后是关于存储模型和指令集合的更详细的说明。
在一个优选实施例中，控制VM是一个相对较小的虚拟机，经设计它可以使用多种编程语言来简单实现。在一个优选实施例中，控制VM基于一个面向栈的指令集，该指令集实际上按最低要求设计，没有过多地考虑执行速度或代码密度。但是，应理解，如果特定的应用需要考虑执行速度和/或代码密度，可以使用常规技术(如数据压缩)来提高性能。
在一个优选实施例中，控制VM适合用低级语言或高级语言编写，支持汇编、C和FORTH等语言。也可以容易地实现其他语言的编译器，如Java语言或定制语言等。
在一个优选实施例中，与直接在处理器上或在硅片中运行相反，控制VM被设计为驻留在主机环境中。控制VM的实际主机环境是DRM引擎。图5示出了在本发明的优选实施例中控制VM如何和DRM引擎集成。
控制VM在其主机环境中运行，主机环境实现了VM执行程序时所需的一些功能。通常，控制VM在DRM引擎内运行，DRM引擎实现它的主机环境。
控制VM通过执行存储在代码模块内的指令来运行程序。有些指令可以通过系统调用来调用在程序自身外实现的功能；系统调用可由控制VM自身实现，也可委托给主机环境。
现在将描述控制VM的优选实施例的一些基本元素。
执行模型控制VM执行存储在代码模块中的指令，执行时，这些代码作为载入到内存的字节代码流。控制VM维护着一个名为程序计数器(PC)的虚拟寄存器，指令执行时，该计数器递增。VM顺序执行每条指令，直到遇到OP_STOP指令，在调用栈为空时遇到OP_RET指令，或发生异常。指令跳转被指定为相对跳转(指定为从当前PC值的字节偏移量)或绝对地址。
内存模型在优选实施例中，控制VM的内存模型相对比较简单。VM内存分为数据段(DS)和代码段(CS)。数据段是单一、平面、连续的内存空间，起始地址是0。数据段一般是在主机应用或主机环境的堆内存内分配的一列字节。对于特定的VM实现，内存空间的大小优选固定为最大值，试图访问内存地址范围之外的地址将导致出错，并终止程序的运行。数据段可能由VM同时载入的多个代码模块共享。数<p>
.Horz_mux Slice0 PLA0(每位都具有单独的使能).HMUX
是16个水平状态行之一；.每个mux(多路复用)也都需要三态使能。
图6示出了一个示例性代码模块，下文中予以描述。
pkCM Atom该pkCM Atom是顶级代码模块单元，包含一个次级单元序列。
pkDS Atom该pkDS Atom包含一个可载入数据段的内存映像。该单元的载荷是一个原始八位字节数值序列。
pkDS Atom该pkDS Atom包含一个可载入代码段的内存映像。该单元的载荷是一个原始八位字节数值序列。
pkEX Atom该pkEX Atom包含一个导出项列表。每一个导出项的组成部分有名称，以8位名称长度编码，随后是名称的字符，包括一个结尾的0，接着是一个32位的整数，代表该指定项的字节偏移(这是相对储存于pkCS Atom单元中的数据的起点的偏移)。
模块载入器在一个优选实施例中，控制VM负责载入代码模块。当一个代码模块被载入时，编码于pkDS Atom之中的内存映像被载入到数据段中的一个内存地址。该地址是由VM载入器选择的，并存储于DS的伪寄存器内。编码于pkCS Atom之中的内存映像被载入到代码段的一个内存地址。该地址是由VM载入器选择，并存储于代码段的伪寄存器内。
系统调用控制VM程序可以调用在其代码模块的代码段以外实现的功能。这是通过使用OP_CALL指令来实现的，该指令带有一个指定系统调用号的整数栈操作数。根据该系统调用，该实现可能是位于另一不同代码模块(例如公用图书馆)中的控制VM字节代码例程，由VM以VM本地执行方式直接执行，或者委托给一个外部软件模块，例如VM的主机环境。
在一种实施例中，指定了几个系统调用号SYS_NOP＝0这一调用是非操作调用，它只是返回(并无操作)，主要用于测试VM。
SYS_DEBUG_PRINT＝1打印出一串文本以便调试输出。这一调用会得到一个单一栈自变量，指定包含所要打印之以零位终止的字符串的内存位置的地址。
SYS_FIND_SYSCALL_BY_NAME＝2确定VM是否执行一个指定系统调用。如是的话，将系统调用号返回到栈上；否则返回数值-1。这一调用会得到一个单一栈自变量，指定包含所请求之以零位终止的系统调用名称的内存位置的地址。
系统调用号分配在一种优选实施例中，控制VM保留0到1023系统调用号用于强制性系统调用(VM的所有概要必须执行的系统调用)。
系统调用号16384到32767可供VM动态分配(例如由SYS_FIND_SYSCALL_BY_NAME返回的系统调用号可由VM动态分配，而且在所有VM实施例中不必都是同样号码)。
标准系统调用在一个优选实施例中，提供了几个标准系统调用以便于编写控制程序。这种标准系统调用可能包括旨在从主机获得一个时间戳的调用、确定一个节点是否可访问的调用和/或类似者。系统调用最好具有动态确定的号码(即其系统调用号可通过调用系统调用SYS_FIND_SYSCALL_BY_NAME、并且将其名称作为传递的参数而获得)。
链接，规则和内容加密下面提供了在DRM引擎和/或系统的优选实施例中的元素、群组、规则、声明和密钥管理之间的关系的其它信息。
链接和节点如前所述，DRM系统可以概念化为具有节点和链接的集合。节点可以表示不同的实体，但是通常表示实体的群组(一些只有一个身份的组)，并且节点可以由链接相连。一个链接可以视为表示一个节点“属于”它所链接的节点表示的群组的声明。
在一个策略的管理下，链接通常是由实体而不是用户和/或DRM引擎创建者建立的声明。如何建立声明和管理声明可以用任何合适的方式进行；但是，链接优选是可信的。在实践中，这通常将意味着存在一个链接的声明表示将被签署，这样需要基于该链接做出决定的部分系统可以以可信模式工作。
由节点之间存在链接表示的关系是可传递的。链接可以由节点图中的有向边表示，如果在图中在Na和Nx之间存在有向路径，那么可以说节点Na属于群组节点Nx。
下面的段落解释了如何使用这些节点图表示规则条件，以及如何管理加密密钥。
规则和成员关系条件所述系统可以用来通过规则管理内容，所述规则以控制程序表示，控制程序确定请求的特定操作(和意向)是否被允许，并且，如果是被允许的，结果或义务是什么。在一个优选实施例中，规则是小的控制程序，其采用数个参数作为输入(诸如内容身份识别信息、时间/日期、特定计数器的值、请求操作的元素的ID等)，并且决定是否允许特定的操作发生。如果允许一个操作发生，程序还能够执行该规则声明的义务(例如，更新一个计数器)。在一些实施例中，该程序能够处理的输入和输出的类型可能相当有限。
一条规则可以表示如下事实一个元素能够执行一个操作的条件是从表示请求操作的元素的节点到一个目标节点或一组目标节点存在一条路径(或一组路径)，每条路径表示一个规则(例如，表示诸如“如果一个元素是内容的订阅者群组中的一个成员，则它能播放该内容”的规则)。两个节点Na和Nb之间的链接是声明Na属于Nb表示的群组的可信任的声明。如果在规则的执行点(例如运行规则程序的地方)可能获得经过图到达所有要求的目标节点所需的所有链接，那么所述条件被满足。这个节点图有时将被称为成员关系图，该图中的链接称为。
内容加密设计与所述系统一起工作的适应元素将能够理解和执行合适的规则，当它们想要对受保护的内容片断执行操作时。但是，通常不能信任非适应系统以这种方式使用内容。因而，希望通过使用加密技术保护内容。在一个优选实施例中，利用内容密钥Kc加密内容，通常对于要保护的内容内容密钥是唯一的。当一个元素想要对内容执行操作，它将首先运行规则程序，得到答案是/否。如果规则允许该元素执行该操作，该要素将需要获取内容密钥Kc。在一个优选实施例中，在规则系统、节点/链接图和内容保护系统(能够使该要素以有效方式获得密钥，而不需要外部实体“显式”地将Kc发送给请求节点)之间存在关系。
在有个优选实施例中，这是通过概念化作为图中节点的元素/对象之间的关系实现的。一些节点可以同成员关系图中使用的节点相同，但这不是必要的。但是，在简单系统中，期望这个图是成员关系图的一个子集。这个图将被称为保护图。
系统中的每个节点N除了其它属性，可以具有一个关于内容保护密钥Kc[N]或密钥对的属性。其它属性可能包括用于签名的公共/私有密钥对和该节点的潜在目标信息。为了说明起见，下面的例子显示使用单个密钥，但是应该理解相同元素也可以使用密钥对。在这个图中，两个节点Na和Nb之间的链接是可信声明，其声明具有Kc[Na]的任何节点可以计算Kc[Nb]。通常，这意味着该链接将包含用Kc[Na]加密的Kc[Nb]的表示。这允许追踪节点之间的链接和计算目标节点的Kc。
用于创建到密钥的路径的图和用于表示成员关系条件的图可以不相同，但是在简单的例子中，可以重用相同的图和链接，从而创建节点图的“平行”或可替换的使用现在经过为检验规则条件而经过的相同路径来计算内容包含密钥。有权访问能够跟随它到达节点Nb的链接的任何节点Na能够计算Kc[Nb]，即使没有显式地将Kc[Nb]定位为Na的目标。
通常可以以如下方式使用这些密钥利用内容密钥K[Ci]加密内容Ci。可以创建一个或多个规则，该规则能够除了其它之外能够检验在请求操作的节点和表示群组的一列“条件”目标节点之间存在路径。该规则可以包括能够执行对条件(可能还包括义务方面)的检验的程序，以及包括受保护的K[Ci]的拷贝，对K[Ci]的保护是通过利用请求节点必需属于的节点的Kc[Ni]节点内容加密密钥的每一个进行连续加密而实现的。
当一个节点Na想要对内容Ci执行一个操作时，它将运行管理该内容的规则程序。如果该规则要求Na在一个或多个群组Np、Nq等中的成员关系，它将检验到Np、Nq等的必要链接是否存在，并且决定是否允许该操作。如果允许该操作，该系统将确定在保护图中它是否具有到节点Nm、Nn等(其内容保护密钥Kc[Nm]和Kc[Nn]等在获取内容密钥K[Ci]的过程中需要使用，在规则中能够发现内容密钥K[Ci]的加密拷贝)的一组链接。通过按照由保护元数据为该内容密钥指定的顺序，利用所述节点的内容加密密钥Kc[Nm]和Kc[Nn]等解密这个加密的内容密钥，将获得K[Ci]。又，在简单系统中，节点Np、Nq的集合通常和Nm、Nn的集合相同。
图7示出了说明节点图的双重使用的示例场景。参看图7，iPOD是内容播放设备。Nip1是表示该设备的节点。Kip1是与Nip1相关联的内容加密密钥。Gilles是iPod1的所有者，Ng是代表Gilles的节点。Kg是与Ng相关的内容加密密钥。
PubLib是一个公共图书馆。Np1代表该图书馆的成员，Kp1是与Np1相关联的内容加密密钥。ACME代表所有ACME制造的音乐播放器。Namp代表设备的类别，Kamp是与此组相关联的内容加密密钥。
L1是一个从Nip1到Ng的链接，意味着iPod1属于Gilles。L2是一个从Ng到Np1的链接，意味着Gilles是公共图书馆的成员。L3是一个从Nip1到Namp的链接，意味着iPod1是一台ACME设备。
C1是一个由公共图书馆供其成员使用的电影文件。Kc1是一个用以为C1加密的密钥。GB[C1]是C1的管理信息(例如，用于管理对该内容的访问的规则和相关信息)。E(a，b)表示用密钥“a”来加密“b”。
为说明起见，假定需要制定一条规则，使设备只要满足下列条件即可播放内容C1(a)该设备的拥有者是图书馆的成员，而且(b)该设备是由ACME制造的。
内容C1是用Kc1来加密的。创建规则程序以及加密的内容密钥RK[C1]＝E(Kamp，E(Kp1，Kc1))。规则程序和RK[C1]都可以纳入该内容的管理模块GB[C1]。
iPod1接收C1和GB[C1]。例如，此二者均可打包在同一文件中，或分别接收。iPod1在Gilles购买后首次安装设备时即接收L1。在Gilles向公共图书馆支付收视费时iPod1即接收L2。iPod1在制造时接收L3(例如L3是内置的)。
iPod1从L1、L2和L3可以检查出Nip1有一条通向Ng(L1)、Np1(L1+L2)和Namp(L3)的图路径。iPod1打算播放C1。iPod1运行从GB[C1]中找到的规则。该规则可以检查Nip1是否确实是一ACME设备(到Namp的路径)，并属于公共图书馆的成员(至Np1的路径)。因此，规则返回“是”，以及所定列表(Namp、Np1)。
iPod1用L1计算出Kg，然后用L2从Kg计算出Kp1。iPod1还使用L3计算出Kamp。iPod1将Kp1和Kamp应用于GB[C1]中找到的RK[C1]并计算出Kc1，然后用Kc1来解密并播放C1。
如同上例所示，当节点密钥是对称密钥时，内容打包者需要有权访问它想要将内容“绑定”于其上的节点的密钥。要实现这一点，可创建一个代表打包者的节点，以及连接该节点与它要将规则绑定于其上的节点之间的链接。例如，这一点亦可通过一项服务“带外”实现。但在某些情况下，采用对称密钥不可能，也不实际。这种情况下，可以向需要绑定的节点分配一个密钥对而无需共享知识。此时，打包者可使用目标节点的公共密钥将内容密钥加密，从而把内容密钥绑定到这个节点。欲获得解密密钥，客户端须有权通过到该节点的链接访问节点的私有密钥。
在最一般的情况下，用于规则的节点和用于计算内容加密密钥的节点不必是同一个。使用相同节点是很自然的，因为管理内容的规则和用来加密内容的密钥之间关系密切，但使用相同节点不是必需的。在一些系统中，若干节点可用于内容保护密钥，但不用于表示成员关系条件，或正相反，并且在某些情况下，可以使用两个不同的节点图，一个用于规则，另一个用于内容保护。例如，一条规则可能说所有Np1组的成员均可访问内容C1，但是内容密钥Kc1可能不受Kp1保护，却受代表所有公共图书馆、不单是Np1的节点Nf的节点密钥Kf保护。或者一条规则可能说你必须是Namp的成员，然而内容加密密钥却只绑定到Np1。
尽管为了说明起见前面描述了一些细节，应理解在不偏离本发明的原则的情况下可以进行某些变化和修改。应注意到，存在很多实现本发明的过程和设备的替代措施。因此，本发明的实施例被认为是说明性的，而不是限制性的，并且本发明并不局限于这里给出的特定细节。
媒体驱动框架的示范实施例图1(附件B的部分)
媒体驱动节点的概念视2(附件B的部分)
一般交互模式示例图3(附件B的部分)
服务适配层图4(附件B的部分)
服务代理-客户端MSDL交互模式图5a 服务代理-客户端本地交互模式图5b(附件B的部分)
服务代理-服务端-中间点交互模式图6(附件B的部分)
媒体驱动工作流整理器的交互模式图7(附件B的部分)
附录C服务定义和概要模式定义
为清晰起见而在前述部分做了详细说明，但显而易见，在随附权利要求范围内可能实施某些更改和修正。须注意的是，本发明的过程和设备的实现可有许多不同的方法。因此，现有实施例应被视为说明性的而非限制性的，而且发明的有效主体不应局限于此处所给的细节，而是可以在随附权利要求的等同范围内加以修订
权利要求
1.一种用于编排由具有充分可互操作性的网络对等方提供的服务以便能够通过参与分布式应用交换价值的系统，系统组成部分如下a.具有第一服务适配层的第一服务提供者，所述第一服务适配层公开第一服务接口，该接口使网络对等方能够通过第一可发现服务绑定，访问由第一服务提供者所提供的第一服务；b.具有第一服务接入点的第一服务用户，访问由第一服务提供者所公开的第一服务接口，发现第一绑定并使用该绑定调用第一服务；及c.第一工作流整理器，编排必要的步骤使第一服务提供者能够为第一服务用户执行第一服务。
2.权利要求1中的系统，其中第一服务提供对位于远程的基于Internet服务器中的加密媒体内容的限制访问，第一工作流整理器包含确认第一服务用户是否有权访问该内容的第一控制程序，若有权，则通过第一服务适配层找到内容并提供给第一服务用户。
3.权利要求1中的系统，其中第一服务接口是采用WSDL规定的。
4.一种用于编排由网络对等方提供的服务的系统，该系统包括a.具有第一服务适配层的第一服务提供者，该第一服务适配层公开第一服务接口，该接口使网络对等方能够通过第一可发现服务绑定，访问由第一服务提供者所提供的第一服务；b.具有第一服务接入点的第一服务用户，访问由第一服务提供者所公开的第一服务接口，发现第一绑定并使用该绑定调用第一服务；c.第一工作流整理器，其编排必要的步骤使第一服务提供者能够为第一服务用户执行第一服务；及d.具有第二服务适配层的第二服务提供者，公开第二服务接口，使网络对等方能够通过第二可发现服务绑定访问由第二服务提供者所提供的第二服务，该第二服务提供对服务注册中心的访问，其中有一目录项包含用以查找和访问第一服务的信息，其中第一服务接入点访问该目录项并使用该信息查找并调用第一服务。
5.权利要求4中的系统，其中服务注册中心是一个UDDI注册中心。
6.一个系统，包括a.具有第一服务适配层的第一服务提供者，该服务适配层公开第一服务接口，该接口使网络对等方能够通过第一可发现服务绑定，访问由第一服务提供者所提供的第一服务；b.具有第一服务接入点的第一服务用户，访问由第一服务提供者所公开的第一服务接口，发现第一绑定并使用该绑定而调用第一服务；c.第一工作流整理器，编排必要的步骤使第一服务提供者能够为第一服务用户执行第一服务；d.一个信任管理证书，用于确认第一服务只能由授权的服务使用者访问；及e.一个控制程序，使用信任管理证书提供对第一服务的限制性访问，其中第一接入点使用信任管理证书确证第一服务用户有权访问第一服务。
7.权利要求6中的系统，其中信任管理证书是一个X.509证书。
8.权利要求6中的系统，其中信任管理证书是一个SSL证书。
9.一种用于编排由具有充分可互操作性的网络对等方提供的服务以便能够通过参与分布式应用交换价值的方法，该方法包括以下步骤a.公开，从第一服务提供者的第一服务适配层公开第一服务接口，该接口使网络对等方能够通过第一可发现服务绑定访问由第一服务提供者所提供的第一服务；b.访问，从一服务用户的第一服务接入点访问由第一服务提供者所公开的第一服务接口，发现第一绑定并使用该绑定调用第一服务；及c.编排，使用第一工作流整理器编排必要的步骤使第一服务提供者能够为第一服务用户执行第一服务。
10.权利要求9中的方法，其中第一服务提供对位于远程的基于Internet的服务器中的加密媒体内容的限制访问，第一工作流整理器包含确认第一服务用户是否有权访问该内容的第一控制程序，若有权，则通过第一服务适配层找到该内容并提供给第一服务用户。
11.权利要求9中的方法，其中第一服务接口是采用WSDL规定的。
12.一种编排服务的方法，包括以下步骤a.公开，从第一服务提供者的第一服务适配层公开第一服务接口，该接口使网络对等方能够通过第一可发现服务绑定访问由第一服务提供者所提供的第一服务；b.访问，从一服务用户的第一服务接入点访问由第一服务提供者所公开的第一服务接口，发现第一绑定并使用该绑定调用第一服务；c.编排，使用第一工作流整理器编排必要的步骤以使第一服务提供者能够为第一服务用户执行第一服务；及d.公开，从第二服务提供者的第二服务适配层公开第二服务接口，该接口使网络对等方能够通过第二可发现服务绑定访问由第二服务提供者所提供的第二服务，第二服务提供对服务注册中心的访问，注册中心中有一目录项包含用以查找和访问第一服务的信息，其中第一服务接入点访问所述目录项并使用该信息查找并调用第一服务。
13.权利要求12中的方法，其中服务注册中心是一个UDDI注册中心。
14.一种方法，包括以下步骤a.公开，从第一服务提供者的第一服务适配层公开第一服务接口，该接口使网络对等方能够通过第一可发现服务绑定，访问由第一服务提供者所提供的第一服务；b.访问，从一服务用户的第一服务接入点访问由第一服务提供者所公开的第一服务接口，发现第一绑定并使用该绑定调用第一服务；c.编排，使用第一工作流整理器编排必要的步骤以使第一服务提供者能够为第一服务用户执行第一服务；d.使用信任管理证书确认第一服务，只能由被授权的服务用户访问；及e.执行一个控制程序，以便使用信任管理证书对第一服务提供限制性访问，其中第一接入点使用信任管理证书验证第一服务用户有权访问第一服务。
15.权利要求14中的方法，其中信任管理证书是一个X.509证书。
16.权利要求14中的方法，其中信任管理证书是一个SSL证书。
17.一种编排服务的方法，包括以下步骤a.从一服务用户的第一服务接入点访问由第一服务提供者所公开的第一服务接口，第一服务接口可用来使网络对等方能够通过第一可发现服务绑定，访问由第一服务提供者所提供的第一服务；b.发现第一可发现绑定；及c.通过使用该绑定而调用第一服务，其中，使用第一工作流整理器编排执行第一服务所必需的步骤。
18.权利要求17中的方法，其中第一服务提供对位于远程的基于Internet的服务器中的加密媒体内容的限制访问，第一工作流整理器包含确认第一服务用户是否有权访问该内容的第一控制程序，若有权，则找到该内容并通过第一服务适配层提供给第一服务用户。
19.一种方法，包括以下步骤a.从第一服务提供者的第一服务适配层公开第一服务接口，该接口使网络对等方能够通过第一可发现服务绑定访问由第一服务提供者所提供的第一服务；b.从第一服务用户的第一服务接入点接收第一服务请求；及c.使用第一工作流整理器编排必要的步骤以使第一服务提供者能够为第一服务用户执行第一服务。
20.一种方法，包括以下步骤a.从第一服务提供者的第一服务适配层公开第一服务接口，该接口使网络对等方能够通过第一可发现服务绑定访问由第一服务提供者所提供的第一服务；b.从第一服务用户的第一服务接入点接收第一服务请求；c.使用一个信任管理证书确认第一服务只能由被授权的服务用户访问；d.执行一个控制程序，以便使用信任管理证书对第一服务提供限制性访问；及e.使用第一工作流整理器编排必要的步骤以使第一服务提供者能够为第一服务用户执行第一服务。
全文摘要
本说明书描述用于以某种方式执行由策略管理的对等服务编排的系统和方法，采用这种方式，可以支持构建能够带给用户丰富媒体体验的自组织服务网络。在一个实施例中，服务分布在多个对等通信节点上，每个节点都利用消息泵和工作流整理器来提供消息路由和消息编排。服务接口的分布式策略管理有助于提供信任和安全，从而支持商业价值交换。通过对等消息传递和工作流整理，可以从一组异类原语服务动态创建服务。共享资源是一些不同类型的服务，它们使用不同于基于UDDI、SOAP和WSDL的Web服务部署中通常支持的那些服务接口绑定。在一个优选实施例中，提供了一种媒体服务框架，它支持节点在从WAN到PAN的网络层之间相互查找、交互、交换价值和协作。
文档编号G06F21/00GK1860761SQ200480021795
公开日2006年11月8日 申请日期2004年6月7日 优先权日2003年6月5日
发明者W·B·布拉德利, D·P·马赫尔, G·博坎－吉布 申请人:英特特拉斯特技术公司