專利名稱：用于對等服務(wù)編排的可互操作系統(tǒng)和方法
技術(shù)領(lǐng)域：
本發(fā)明一般性涉及對數(shù)字信息和服務(wù)的分發(fā)和使用。更具體地，公開了提供和/支持對等服務(wù)編排的系統(tǒng)和方法。
背景技術(shù)：
和發(fā)明概述如今，要實現(xiàn)建立一個互操作和安全的媒體相關(guān)服務(wù)環(huán)境的目標，還存在許多障礙。例如，多個事實上相互重疊的正式標準會限制直接的互操作性；定位和連接到所需的服務(wù)通常很困難；實現(xiàn)技術(shù)通常是不可互操作的；并且在不同的信任和保護模式之間經(jīng)常存在阻抗不匹配。
盡管新興Web服務(wù)標準正在著手解決web上的這些問題，但這些方法并不完善。另外，這種方法不能跨個人和局域網(wǎng)、家用、企業(yè)和部門網(wǎng)關(guān)以及廣域網(wǎng)等多層次的網(wǎng)絡(luò)節(jié)點解決此類問題。而且，這些標準也不能通過利用各種本地和遠程的允許集成許多傳統(tǒng)應(yīng)用的服務(wù)接口綁定(例如WS-I、Java RMI、DCOM、C函數(shù)調(diào)用和.Net等等)對簡單和復(fù)雜服務(wù)進行動態(tài)編排。
本發(fā)明的實施例可用于解決部分或全部這些問題。例如，在某些實施例中，服務(wù)提供者可以使用最適合于參與給定異類服務(wù)網(wǎng)絡(luò)的設(shè)備、服務(wù)或應(yīng)用的服務(wù)發(fā)現(xiàn)協(xié)議。因而，可以將BlueTooth，UpNp，rendezvous？，JINI，UDDI等集成在同一個服務(wù)中，并且每個節(jié)點可以使用最適合承載該節(jié)點的設(shè)備的發(fā)現(xiàn)服務(wù)。
在媒體環(huán)境中，主要參與者群體(例如內(nèi)容發(fā)布者、分發(fā)者、零售商、消費設(shè)備提供者和用戶)所需要或喜歡的系統(tǒng)和接口常常有很大的不同。因此，希望將這些實體所提供的功能統(tǒng)一到能夠迅速發(fā)展為滿足所有參與實體的最佳配置的集成服務(wù)中。通過使用對等(“P2P”)服務(wù)編排，本發(fā)明的實施例可以用來實現(xiàn)該目標。
盡管已經(jīng)看到P2P架構(gòu)對于諸如音樂分發(fā)和如今的視頻分發(fā)這種應(yīng)用的優(yōu)勢，P2P技術(shù)還可以使用得更為廣泛。例如，在各種企業(yè)服務(wù)，特別是兩個或更多企業(yè)的交互中，也存在很多應(yīng)用機會。企業(yè)大多是按照一定的層次結(jié)構(gòu)進行組織的，其信息系統(tǒng)通常反映了這種組織結(jié)構(gòu)，當兩個企業(yè)的人員進行交互時，通過對等接口他們的交互往往更有效。A公司中的收貨人員/服務(wù)可以通過與B公司的發(fā)貨人員進行對話來更直接地解決問題或獲得有用的信息。交叉層次或不必要的接口一般是沒有用的。一些送貨公司(例如FedEx和UPS)認識到這一點，因此他們允許客戶直接看到其處理，直接對事件進行監(jiān)視。公司和市政當局正在通過企業(yè)門戶來組織其服務(wù)，從而形成自然的自助服務(wù)。但是，迄今為止，對等架構(gòu)并不允許一個企業(yè)向其用戶和提供者公開自己的各種服務(wù)接口，讓這些實體在自然的對等級別上進行交互，這樣這些實體就不能以最適合自己的方式編排該企業(yè)的服務(wù)。本發(fā)明的實施例將允許這樣做。
公開了用于在連成網(wǎng)絡(luò)的計算機環(huán)境中提供服務(wù)編排的系統(tǒng)和方法。應(yīng)該理解可以用各種不同的途徑實現(xiàn)所公開的實施例，包括過程、設(shè)備、系統(tǒng)、裝置、方法或計算機可讀介質(zhì)。下面說明幾種有創(chuàng)造力的實施例。
在一組實施例中，提供了一種服務(wù)架構(gòu)，它能使得用戶或企業(yè)媒體空間中的參與者(例如，用戶、內(nèi)容提供者、設(shè)備制造商、服務(wù)提供者、企業(yè)部門)彼此找到對方、建立信任關(guān)系并通過信任的服務(wù)接口以豐富的動態(tài)方式交換價值。這個服務(wù)架構(gòu)可以被描述成在不同種類的消費設(shè)備、媒體格式、通信協(xié)議和安全機制的環(huán)境實現(xiàn)可操作的、安全的、與媒體相關(guān)的電子商務(wù)的平臺。
將通過下面的詳細說明以及附圖更詳細地闡明本發(fā)明的這些和其它特性、優(yōu)勢和實施例。
附圖概述通過結(jié)合附圖參考下面的詳細說明將更容易理解本發(fā)明的實施例，在附圖中相同的引用編號表示相同的結(jié)構(gòu)組件，在附圖中

圖1示出了該媒體驅(qū)動架構(gòu)的一個示范實施例。
圖2是一個媒體驅(qū)動節(jié)點的概念視圖。
圖3示出了媒體驅(qū)動節(jié)點之間的一般交互方式。
圖4示出了服務(wù)適配層的一個實施例。
圖5a示出了客戶端MSDL交互中涉及的服務(wù)代理。
圖5b示出了客戶端本地交互中涉及的服務(wù)代理。
圖6示出了服務(wù)端指向-中間交互模式中涉及的服務(wù)代理。
圖7示出了媒體驅(qū)動工作流程整理器的交互模式。
圖8示出了發(fā)現(xiàn)了支持通知處理器服務(wù)的節(jié)點的一組通知處理節(jié)點。
圖9示出了依照一個優(yōu)選實施例的通知發(fā)送。
圖10示出了請求節(jié)點向目標服務(wù)提供節(jié)點進行服務(wù)查詢請求的客戶端-驅(qū)動情況。
圖11示出了請求節(jié)點想要向另一節(jié)點注冊它的描述的節(jié)點注冊情況。
圖12示出了正在被通知服務(wù)存在的具有媒體驅(qū)動功能的節(jié)點。
圖13示出了根據(jù)顯式的交換建立信任的過程。
圖14示出了受策略管理的服務(wù)訪問。
圖15示出了如何在向參與者傳送CRM-相關(guān)服務(wù)的環(huán)境中使用媒體驅(qū)動。
詳細說明下面提供對有本發(fā)明的有效實體的詳細說明。盡管這個說明是結(jié)合了幾個實施例而提供的，但應(yīng)該理解本發(fā)明并不僅限于任何一個實施例，而是包括各種不同的可選方案、改進和等效方案。例如，盡管一些實施例是在面向用戶的內(nèi)容和應(yīng)用的環(huán)境中說明的，但本領(lǐng)域中的技術(shù)人員將認識到所公開的系統(tǒng)和方法適用于更廣泛的應(yīng)用。例如，沒有限制，本發(fā)明的實施例可以被很容易地應(yīng)用到企業(yè)內(nèi)容和應(yīng)用環(huán)境中。另外，盡管在下面的說明中闡述了大量具體細節(jié)以便提供對本發(fā)明的透徹理解，但不要這些細節(jié)中的一些或全部也可以實踐本發(fā)明。此外，為明確起見，沒有詳細說明一些本領(lǐng)域中已知的涉及本發(fā)明的特定技術(shù)材料以避免不必要地模糊本發(fā)明。
這里說明了一種新穎的、受策略管理的、對等的服務(wù)編排架構(gòu)(媒體驅(qū)動架構(gòu))的實施例。該架構(gòu)最初被設(shè)計用來支持能帶來豐富媒體體驗的基層自組織服務(wù)網(wǎng)絡(luò)的形成。如同本領(lǐng)域中的普通技術(shù)人員將理解的那樣，該架構(gòu)本身新穎，它的很多特性、方面和應(yīng)用也新穎。
在一個優(yōu)選實施例中，該架構(gòu)被設(shè)計用來用服務(wù)描述語言(媒體驅(qū)動服務(wù)描述語言“MSDN”)激活很多不同服務(wù)類型的動態(tài)配置和進展。服務(wù)可以跨越對等的通信節(jié)點分布，每個對等通信節(jié)點用專為這個架構(gòu)設(shè)計的消息泵和工作流整理器提供消息路由和編排。媒體驅(qū)動服務(wù)接口的分布式策略管理可以用來幫助提供信任和安全，由此促進價值的商業(yè)交換。
對等計算通常被定義為計算機和其它智能設(shè)備之間的資源(例如硬盤和處理周期)共享。參見http://www.intel.com/cure/peer.htm。這里，P2P可以被看作是允許網(wǎng)絡(luò)節(jié)點對稱地消耗并提供所有種類的服務(wù)的通信模型。P2P消息傳送和工作流整理允許從不同組的更原始的服務(wù)動態(tài)創(chuàng)建豐富的服務(wù)。這樣能夠在共享資源是很多不同類型的服務(wù)，甚至使用不同服務(wù)綁定時對P2P通信的可能性進行檢查。媒體驅(qū)動的實施例可以用來提供使各參與者(例如用戶、內(nèi)容提供者、設(shè)備制造商和服務(wù)提供者)彼此找到對方、交互、交換價值并以多種動態(tài)方式合作的媒體服務(wù)架構(gòu)?？梢杂妹襟w驅(qū)動的實施例來協(xié)調(diào)的不同類型的服務(wù)從基本的服務(wù)(發(fā)現(xiàn)、通知、查找和文件共享)到更復(fù)雜更高級的服務(wù)(例如鎖定、許可、匹配、授權(quán)、支付事務(wù)和更新)以及這些服務(wù)中的任意或全部的組合。
媒體驅(qū)動的企業(yè)應(yīng)用在企業(yè)轉(zhuǎn)向面向服務(wù)的體系結(jié)構(gòu)時尤其能引起企業(yè)的興趣。通過對等服務(wù)編排和分布式策略管理的使用，企業(yè)能夠允許它們的部門發(fā)布可以由客戶和提供者配置成豐富的個性化服務(wù)的服務(wù)接口，分解人工層次并允許內(nèi)部和外部實體優(yōu)化它們與該企業(yè)的交互。
為說明方便起見，將使用下列術(shù)語服務(wù)-由一些提供者提供的任何明確定義的功能。例如，可以是像蜂窩電話這樣的設(shè)備中提供的初級功能(例如語音識別服務(wù))或者在萬維網(wǎng)上提供的多-方功能(例如購物服務(wù))。
服務(wù)接口-與一個或多個服務(wù)交互的任何明確定義的途徑。
服務(wù)綁定-用來調(diào)用服務(wù)接口的約定和協(xié)議。它們可以用大量明確定義的方式來表示，例如WS-I標準XML協(xié)議、基于WSDL定義的RPC或來自DLL的函數(shù)調(diào)用。
服務(wù)編排-將服務(wù)組裝、調(diào)整成符合服務(wù)提供者指定的規(guī)則的可管理的、粗粒度的服務(wù)、可重用的組件或完整的應(yīng)用程序。例如，規(guī)則基于提供者標識、服務(wù)類型、訪問服務(wù)的方法和組織服務(wù)的順序等等。
管理-進行授權(quán)或控制一些對象(例如音樂文件、文檔或像下載或安裝軟件升級的能力這樣的服務(wù)操作)上的影響的過程。管理通常與信任管理、策略管理和內(nèi)容保護相交互。
對等(P2P)原則-支持參與者對服務(wù)進行對稱訪問的通信模型。
媒體驅(qū)動節(jié)點-媒體驅(qū)動架構(gòu)中的參與者。在一個優(yōu)選實施例中，一個節(jié)點可以充當多種角色，包括服務(wù)用戶和/或服務(wù)提供者?？梢杂枚喾N形式實現(xiàn)節(jié)點，包括消費類電子設(shè)備、軟件代理(例如媒體播放器)或虛擬服務(wù)提供者(例如服務(wù)搜索引擎、DRM許可提供者或內(nèi)容箱)?？梢跃幣琶襟w驅(qū)動服務(wù)以提供更健壯的組合服務(wù)。
媒體驅(qū)動服務(wù)描述語言(MSDL)-在一種實施例中，一種基于XML模式的語言定義并描述了用于媒體驅(qū)動架構(gòu)的實施例中節(jié)點之間通信的可擴展的數(shù)據(jù)類型和消息集合。
7.邏輯模型圖1示出了媒體驅(qū)動架構(gòu)的一個相對簡單的實例。在一個優(yōu)選實施例中，該媒體驅(qū)動架構(gòu)由以P2P方式交互的在邏輯上相連的一組節(jié)點構(gòu)成。
在一個優(yōu)選實施例中，這種交互的一些特征是-媒體驅(qū)動節(jié)點通過進行服務(wù)調(diào)用請求并接收響應(yīng)而交互。請求和響應(yīng)消息的格式和有效載荷以MSDL定義。媒體驅(qū)動架構(gòu)支持不同通信模型的構(gòu)造，從與單個服務(wù)提供者的直接交互到來自多個服務(wù)提供者的精心策劃的服務(wù)集合的復(fù)雜聚集。在一個優(yōu)選實施例中，該架構(gòu)支持用于使用現(xiàn)有服務(wù)設(shè)計標準的基本機制并且還允許服務(wù)提供者使用它們自己的規(guī)則。
-一個服務(wù)接口可以有一個或多個服務(wù)綁定。在一個優(yōu)選實施例中，服務(wù)綁定的說明以MSDL表示。在這個實施例中，媒體驅(qū)動節(jié)點可以調(diào)用另一節(jié)點的接口，只要那個節(jié)點的接口綁定可以用MSDN表示，以及只要該請求節(jié)點能夠支持與該綁定相關(guān)的規(guī)則和協(xié)議。例如，如果一個節(jié)點支持web服務(wù)接口，可能要求請求節(jié)點支持SOAP、HTTP、WS-安全等等。
-可以用直接提供了權(quán)限管理特征的標準化方式控制(例如，受權(quán)限管理的)任何服務(wù)接口。媒體驅(qū)動節(jié)點之間的交互可以看作是被管理的操作。
實際上任何類型的設(shè)備(物理的或虛擬的)都可以看作是潛在的具有媒體驅(qū)動功能，并且能夠?qū)崿F(xiàn)媒體驅(qū)動架構(gòu)的關(guān)鍵特征。例如，設(shè)備類型有消費類電子設(shè)備、網(wǎng)絡(luò)化服務(wù)或軟件客戶端。在一個優(yōu)選實施例中，具有媒體驅(qū)動功能的設(shè)備(節(jié)點)通常包括下列邏輯模塊中的一些或全部-本地服務(wù)API-該設(shè)備實現(xiàn)的一個或多個服務(wù)的集合。對媒體驅(qū)動節(jié)點在媒體驅(qū)動架構(gòu)中直接或間接地公開什么服務(wù)沒有要求。
-本地服務(wù)實現(xiàn)-本地服務(wù)API的對應(yīng)實現(xiàn)集合。
-媒體驅(qū)動適配層-一個邏輯層，通過它可以用以MSDL描述的一個或多個可發(fā)現(xiàn)的綁定訪問一個實體的本地服務(wù)公開的子集。
-媒體驅(qū)動架構(gòu)支持庫-為和包括對調(diào)用服務(wù)接口、消息處理、服務(wù)編排等等的支持的媒體驅(qū)動架構(gòu)合作提供支持功能的組件。
圖2提供了媒體驅(qū)動節(jié)點的一個示范實施例的概念視圖。上述模塊中的每一個所對應(yīng)的實際設(shè)計和實現(xiàn)通常會隨設(shè)備而不同。
8.基本的交互模式圖3示出了兩個媒體驅(qū)動節(jié)點，服務(wù)請求者和服務(wù)提供者，之間通常的邏輯交互模式。
從請求節(jié)點的角度來說，事件流通常是-進行服務(wù)發(fā)現(xiàn)請求以定位能夠用指定的服務(wù)綁定提供必要服務(wù)的具有媒體驅(qū)動功能的節(jié)點。節(jié)點可以選擇將與所發(fā)現(xiàn)的服務(wù)有關(guān)的信息緩存起來。媒體驅(qū)動節(jié)點之間的服務(wù)發(fā)現(xiàn)的交互/機制可以只是媒體驅(qū)動節(jié)點選擇實現(xiàn)的另一服務(wù)。
-一旦找到了候選的服務(wù)提供節(jié)點，請求節(jié)點可以選擇根據(jù)具體的服務(wù)綁定將請求分派到一個或多個服務(wù)提供節(jié)點。
-在一個優(yōu)選實施例中，希望彼此進行安全通信的兩個節(jié)點出于交換MSDL消息的目的而建立了信任關(guān)系。例如，它們可以協(xié)商一組可以用在確定身份、授權(quán)、建立安全通道等等之中的兼容的信任憑證(例如，X.500鑒定、設(shè)備密鑰，等)。有些情況下，這些憑證的協(xié)商可以是服務(wù)接口綁定(例如，如果WS-I XML協(xié)議就是WS-安全，或者是兩個眾所周知的節(jié)點之間的SSL請求)的隱含屬性。有些情況下，信任憑證的協(xié)商可以是明確的單獨步驟。在一個優(yōu)選實施例中，是由一個特定的節(jié)點來確定什么憑證對與別的媒體驅(qū)動節(jié)點交互來說足夠，并做出它能夠信任特定節(jié)點的判斷。
-請求節(jié)點創(chuàng)建對所請求的服務(wù)對應(yīng)的適當?shù)腗SDL請求消息。
-一旦消息被創(chuàng)建，它就被分發(fā)到目標服務(wù)提供節(jié)點。例如，該請求的通信方式可以是同步或異步的RPC方式，或者基于服務(wù)綁定的面向消息的方式。服務(wù)請求的分發(fā)和響應(yīng)的接收可以由設(shè)備直接完成或通過媒體驅(qū)動服務(wù)代理完成。服務(wù)代理(下面有說明)為發(fā)送消息到媒體驅(qū)動架構(gòu)中的其它參與者提供了抽象和接口，并且可以隱藏特定的服務(wù)綁定問題，例如兼容的消息格式、傳輸機制、消息路由問題或類似的問題。
-在分發(fā)了請求之后，請求節(jié)點通常將接收到一個或多個響應(yīng)。根據(jù)服務(wù)接口綁定的細節(jié)以及請求節(jié)點的選擇，響應(yīng)可以用多種方式被返回，例如包括RPC-方式的響應(yīng)或通知消息。在到目標節(jié)點途中的響應(yīng)可以通過能夠提供多種媒體驅(qū)動服務(wù)(包括，例如路由、信任協(xié)商、整理和相關(guān)功能等)的其它中間節(jié)點。
-請求節(jié)點驗證響應(yīng)以確保它符合在它和服務(wù)提供節(jié)點之間所協(xié)商的信任語義。
-隨后根據(jù)消息有效負載類型和內(nèi)容進行適當?shù)奶幚怼?br> 再來參考圖3，從服務(wù)提供節(jié)點的角度，事件流是-確定是否支持所請求的服務(wù)。在一個優(yōu)選實施例中，媒體驅(qū)動架構(gòu)不要求服務(wù)接口如何映射成服務(wù)入口點的方式或粒度。在最簡單的情況中，服務(wù)接口可以明確地映射到特定的服務(wù)和綁定動作并且調(diào)用它可以構(gòu)成對該服務(wù)的支持。但是，在一些實施例中單個服務(wù)接口可以處理多種類型的請求并且一個特定的服務(wù)類型可以包括在做出該節(jié)點支持具體想要的功能的判定之前要檢查的附加屬性。
-一些情況下服務(wù)提供者必須確定它是否信任請求節(jié)點并協(xié)商一組兼容的信任憑證。在一個優(yōu)選實施例中，不管服務(wù)提供者是否判定為可信的，與該服務(wù)接口相關(guān)的任何策略仍將適用。
-服務(wù)提供者判定并將授權(quán)請求分發(fā)到那些負責(zé)授權(quán)對該接口的訪問的媒體驅(qū)動節(jié)點以便確定該請求節(jié)點是否能夠訪問。很多情況下，授權(quán)節(jié)點和服務(wù)提供節(jié)點可以是相同實體，并且對授權(quán)請求的分發(fā)和處理可以是通過輕量級媒體驅(qū)動服務(wù)接口綁定(例如C函數(shù)入口點)調(diào)用的本地操作。
-在接收到授權(quán)響應(yīng)后，如果請求節(jié)點獲得了授權(quán)，服務(wù)提供者將滿足該請求。反之，可以生成適當?shù)捻憫?yīng)消息。
-響應(yīng)消息是根據(jù)服務(wù)接口綁定和請求節(jié)點的選擇而被返回的。在到請求節(jié)點的途中，該消息可以通過能夠提供必要的或“附加值”服務(wù)的其它中間節(jié)點。例如中間節(jié)點可以提供路由、信任協(xié)商以及到傳送到能夠以可接受的方式傳送消息到請求節(jié)點的通知處理節(jié)點?！案郊又怠狈?wù)的一個例子是贈券服務(wù)，如果它知道請求節(jié)點的興趣就將贈券附加到消息上。
9.MSDL與服務(wù)調(diào)用相關(guān)的消息語法優(yōu)選地以相對靈活和可移值的方式進行描述，是媒體驅(qū)動架構(gòu)中所用的核心數(shù)據(jù)類型。在一個優(yōu)選實施例中，這是用服務(wù)描述語言(這里稱為媒體驅(qū)動服務(wù)描述語言，或MSDL)實現(xiàn)的。另外，MSDL提供了簡單的方式用于引用與所說明的服務(wù)相關(guān)的語義描述。
在一個優(yōu)選實施例中，MSDL是基于XML模式的描述語言，它包括了能夠?qū)崿F(xiàn)服務(wù)和它們相關(guān)的接口綁定的描述和組成的擴展的數(shù)據(jù)類型集合。MSDL中的很多對象類型是多態(tài)的并且可以對其進行擴展以支持新功能。在一個優(yōu)選實施例中，基本的MSDL輪廓將被稱作“MSDL內(nèi)核”。MSDL用戶可以直接以特定方式或者通過一些形式的標準化過程定義在MSDL內(nèi)核之上構(gòu)建的添加了新數(shù)據(jù)和服務(wù)類型并擴展已有的數(shù)據(jù)和服務(wù)類型的其它MSDL輪廓。在一個實施例中，MSDL內(nèi)核包括對下列主要的基本數(shù)據(jù)類型的一些或全部的定義-節(jié)點-媒體驅(qū)動架構(gòu)中的參與者的表示。
-設(shè)備-封裝了虛擬設(shè)備或物理設(shè)備的表示。
-用戶-封裝了客戶端用戶的表示。
-內(nèi)容引用-封裝了內(nèi)容對象的引用或指針的表示。這種引用通常將利用描述內(nèi)容格式、位置等的其它標準化方式。
-DRM引用-封閉了對數(shù)字權(quán)限管理格式描述的引用或指針的表示。
-服務(wù)-封裝了對從節(jié)點輸出的一組明確定義的功能的表示。
-服務(wù)綁定-封裝了與服務(wù)通信的具體方式。
-請求-封裝了對一組目標節(jié)點的服務(wù)請求。
-請求輸入-封裝了請求的輸入。
-響應(yīng)-封裝了與請求相關(guān)的響應(yīng)。
-請求結(jié)果-封裝了與某請求相關(guān)的響應(yīng)中的結(jié)果。
在一個實施例中，MSDL內(nèi)核包括對下列基本服務(wù)的一些或全部的定義-授權(quán)-授權(quán)某個參與者訪問服務(wù)的請求或響應(yīng)。
-消息路由-提供消息路由功能，包括使服務(wù)提供節(jié)點轉(zhuǎn)發(fā)該消息或收集消息并對消息進行整理的功能的請求或響應(yīng)。
-節(jié)點注冊-為節(jié)點進行注冊操作，由此允許該節(jié)點通過中間節(jié)點被發(fā)現(xiàn)的請求或響應(yīng)。
-節(jié)點發(fā)現(xiàn)(查詢)-與媒體驅(qū)動節(jié)點的發(fā)現(xiàn)相關(guān)的請求或響應(yīng)。
-通知-發(fā)送或傳送目標通知消息到特定節(jié)點集合的請求或響應(yīng)。
-服務(wù)發(fā)現(xiàn)(查詢)-與由某個一個或多個節(jié)點的集合提供的服務(wù)的發(fā)現(xiàn)有關(guān)的請求或響應(yīng)。
-安全憑證交換-與允許節(jié)點交換安全有關(guān)信息(例如密鑰對、憑證等等)有關(guān)的請求或響應(yīng)。
-升級-表示與接收功能升級有關(guān)的請求或響應(yīng)。在一個實施例中，這個服務(wù)是完全抽象的，而其它輪廓提供具體的表示。
10.體系結(jié)構(gòu)概述10.1服務(wù)適配層再次參見圖2，服務(wù)適配層可以用來公開媒體驅(qū)動架構(gòu)中的參與者的本地服務(wù)。在一個優(yōu)選實施例中，MSDL被用來描述如何具體地在一個或多個接口上綁定到服務(wù)。服務(wù)描述還可包括其它信息，包含了下列中的一些或全部-將負責(zé)授權(quán)訪問服務(wù)的一個或多個服務(wù)提供者的列表。
-對服務(wù)的目的和用途的語義描述的指針。
-如果該服務(wù)是來自一組其它服務(wù)的精心設(shè)計的執(zhí)行的復(fù)合服務(wù)，對必要的編排的說明。
除了充當以MSDL發(fā)布服務(wù)的邏輯點之外，在一個優(yōu)選實施例中服務(wù)適配層還封裝了由特定參與者支持的那些平臺的任何MSDL輪廓中包含的MSDL數(shù)據(jù)類型和對象的具體表示。它還包含將對服務(wù)請求對應(yīng)的MSDL消息映射成適當?shù)谋镜胤?wù)實現(xiàn)的邏輯。
通常，服務(wù)適配層的實現(xiàn)包括圖4所示的組件。尤其，典型的服務(wù)適配層實現(xiàn)在分層實現(xiàn)中將包括下列組件-封裝了服務(wù)接口的MSDL綁定中說明的服務(wù)接口入口點的層。通過這些接入點，可以進行服務(wù)調(diào)用，傳入輸入?yún)?shù)數(shù)據(jù)并輸出結(jié)果。
-對應(yīng)于MSDL消息處理邏輯的層。這一層通常包含驅(qū)動處理的某種消息泵、某種類型的XML數(shù)據(jù)綁定支持以及初級XML分析器和數(shù)據(jù)表示支持。
-表示對應(yīng)的以MSDL描述的服務(wù)消息被映射到其上的可用本地服務(wù)的層。
10.2架構(gòu)支持庫再來參見圖2，該架構(gòu)支持庫提供了使得實體參與媒體驅(qū)動架構(gòu)更容易的可選支持功能集。如何分解該庫(對象集、功能集等)以及如何實現(xiàn)它將根據(jù)目標平臺而變化。可能有支持不同功能的多種版本的支持庫。通常情況下，該支持庫中的可用功能包括下列中的一些或全部-服務(wù)代理-封裝了使得媒體驅(qū)動節(jié)點能夠向服務(wù)提供節(jié)點的目標集合進行服務(wù)調(diào)用請求并接收一組響應(yīng)的功能。
-MSDL語言處理程序-用于處理MSDL語言部分的功能。
-服務(wù)緩存接口-允許節(jié)點管理所發(fā)現(xiàn)的節(jié)點和它們支持的服務(wù)之間的映射的公共服務(wù)提供者接口。
-工作流整理器接口-允許節(jié)點管理并處理MSDL的整理的服務(wù)提供者接口。它提供了基本的程序模塊以編排服務(wù)。目前，這個接口一般是由支持消息路由并支持中間排隊和消息整理的節(jié)點實現(xiàn)。
-通知處理器接口-服務(wù)提供者接口，用于勾住支持到一些明確定義的通知處理引擎的通知處理的媒體驅(qū)動節(jié)點。
-混合支持功能-用于生成消息ID、時間戳等等的程序。
10.3通信方式給出媒體驅(qū)動架構(gòu)的優(yōu)選實施例中支持的以及用在不同支持庫組件(例如服務(wù)代理)中的一般通信方式的基本概述是有幫助的。有多種基本類型的通信方式，包括異步RPC傳送方式-在預(yù)計滿足一個請求將占用延長的一段時間而客戶端不想等待時這個模型有效。這里，客戶端提交帶有其將由一些服務(wù)提供節(jié)點以異步模式處理的預(yù)期的請求。一個服務(wù)提供端點可能響應(yīng)表示它不支持這種模型，或者如果該服務(wù)提供節(jié)點不支持這種模型，它可以返回一個響應(yīng)，攜帶有可以在后續(xù)請求中被提交給該服務(wù)請求節(jié)點以確定它是否對該客戶端的請求有響應(yīng)的標簽。在一個優(yōu)選實施例中，支持這種模型的服務(wù)請求端點將根據(jù)一些內(nèi)部策略將未決請求的響應(yīng)緩存起來。如果一個客戶端試圖挽回與這種請求相關(guān)的標簽，并且沒有響應(yīng)可用，或者響應(yīng)已經(jīng)被該服務(wù)提供節(jié)點丟棄，那么可以返回適當?shù)某鲥e響應(yīng)。
同步RPC傳送方式-這里，客戶端提交了一個請求然后等待返回一個或多個響應(yīng)。提供服務(wù)的具有媒體驅(qū)動功能的端點可能以它不支持這種模型的指示來響應(yīng)。
基于消息的傳送方式-這里，客戶端提交了一個請求，指示它想通過與它的通知處理服務(wù)接口的一個或多個相關(guān)的消息通知接收任何響應(yīng)。一個節(jié)點可能回以它不支持這種模型。下面說明該通知架構(gòu)的示范實施例。
上述交互模式都不需要阻塞或等待響應(yīng)或者顯式地輪詢?？梢允褂镁€程或其它平臺特定的機制以用上述傳送方式機制模擬阻塞和非阻塞語義。
10.4服務(wù)代理具有媒體驅(qū)動功能的端點可以使用各種發(fā)現(xiàn)、名字解析和傳輸協(xié)議。結(jié)果，通?？梢云谕褂渺`活的可擴展的通信API。服務(wù)代理API對允許媒體驅(qū)動節(jié)點進行服務(wù)請求并接收一組目標媒體驅(qū)動節(jié)點的響應(yīng)的功能提供公共接口?？梢杂每蛻舳朔秶鷥?nèi)(以共享庫形式)或共享庫范圍之外(以運行在不同進程中的代理形式)的多種形式實現(xiàn)服務(wù)代理。服務(wù)代理實現(xiàn)的確切形式優(yōu)選地是根據(jù)平臺或客戶端的需要而設(shè)計的。服務(wù)代理的使用是可選的，盡管通常它提供了重要的功能。服務(wù)代理的一些常見用途包括-服務(wù)調(diào)用的公共的可重用的API。
-對圍繞傳輸通道的協(xié)商和使用的問題的封裝。一些傳輸通道需要TCP/IP之上的SSL會話建立，一些通道可能只支持UDP/IP上的不可靠通信，其它信道可能根本不基于IP。在一個優(yōu)選實施例中，通常對客戶端隱藏了這些細節(jié)。
-對圍繞用于消息路由的初始的媒體驅(qū)動節(jié)點集的發(fā)現(xiàn)的問題的封裝。例如，有線機頂盒可以有專用的網(wǎng)絡(luò)連接并且需要所有消息通過特定的路由和介質(zhì)流動，而家庭網(wǎng)絡(luò)中的便攜媒體播放器可以使用UPnP發(fā)現(xiàn)來找到可直接訪問的多個端點。另外，優(yōu)選地對客戶端隱藏了這些細節(jié)。
-“傳統(tǒng)”客戶端不能或不能選擇通過MSDL消息的創(chuàng)建與其它媒體驅(qū)動節(jié)點進行直接對話。這里可以創(chuàng)建理解客戶端所支持的任何本地協(xié)議的服務(wù)代理版本。
服務(wù)代理可以被實現(xiàn)成靜態(tài)組件，只支持固定集合的協(xié)議綁定，或者被實現(xiàn)為能夠動態(tài)地支持新的綁定。一般的服務(wù)代理模型的兩個例子是(1)服務(wù)代理直接接收并返回MSDL消息給客戶端，和(2)服務(wù)代理支持客戶端所理解的一些本地協(xié)議。服務(wù)代理可以被看作具有兩端請求參與者使用的客戶端，和與其它具有媒體驅(qū)動功能的端點交互的服務(wù)端。
客戶端和服務(wù)代理之間的兩種主要交互模式是模式1(圖5a)?？蛻舳酥苯有纬蒑DSL請求消息并將它們提交給服務(wù)代理。它接收到MSDL格式的一個或多個消息，通常它需要對它們進行收集、解析和處理?？蛻舳诉€可以提交顯式的服務(wù)綁定集合以用在為請求的傳送指定目標中。這些服務(wù)綁定可能已經(jīng)由進行服務(wù)查找操作的客戶端獲得，或者通過使用從先前的請求響應(yīng)中獲得的信息而獲得。
模式2(圖5b)。服務(wù)代理適應(yīng)客戶端可以通過一些本地通信協(xié)議交互的客戶端模型，服務(wù)代理將接受這些本地通信協(xié)議并且這些本地通信協(xié)議轉(zhuǎn)換自MSDL或轉(zhuǎn)換成MSDL以允許客戶端參與到媒體驅(qū)動架構(gòu)中。這里，本地協(xié)議或本地協(xié)議和執(zhí)行環(huán)境的組合提供了服務(wù)代理所需的任何信息以生成適當?shù)腗SDL請求并在必要時確定適當?shù)哪繕朔?wù)綁定。
在服務(wù)端，支持服務(wù)代理和提供服務(wù)的具有媒體驅(qū)動功能的端點之間的多種類型的交互模式，并且像客戶端一樣，可以設(shè)計交互模式并且交互模式可以根據(jù)多種標準(包括請求的本質(zhì)、下面的通信網(wǎng)絡(luò)、應(yīng)用的本質(zhì)和/或與任何目標服務(wù)綁定相關(guān)的傳輸協(xié)議)而變化。
在一種模式下，服務(wù)代理直接啟動與多個潛在的服務(wù)提供者的通信，并接收送回的響應(yīng)。這種交互模式可能符合正被從客戶端轉(zhuǎn)播以由服務(wù)代理使用的多個服務(wù)綁定，或者它表示存在服務(wù)代理在轉(zhuǎn)播消息中使用的廣播或多播。服務(wù)代理可以選擇收集響應(yīng)并整理或者只是返回第一個可接受的響應(yīng)。
在圖6所示的模式中，服務(wù)代理并不直接與目標服務(wù)提供端點通信，而是通過中間節(jié)點發(fā)送請求，中間節(jié)點轉(zhuǎn)播請求、接收任何響應(yīng)并將它們送回服務(wù)代理。這種交互模式是由于-服務(wù)代理不能/不希望直接支持與服務(wù)提供端點相關(guān)的任何服務(wù)綁定但能夠與希望充當網(wǎng)關(guān)的中間節(jié)點建立關(guān)系。
-客戶端也許能夠發(fā)現(xiàn)或確定任何合適的服務(wù)提供節(jié)點的服務(wù)綁定，并希望允許一個中間節(jié)點試圖發(fā)現(xiàn)任何適當?shù)姆?wù)提供者。
-服務(wù)代理想要利用支持更健壯的收集和整理功能的中間節(jié)點，這些更健壯的收集和整理功能允許服務(wù)代理和服務(wù)提供者之間有更靈活的通信模式。
或者，除了上述基本的服務(wù)端交互模式之外，還可以有實現(xiàn)了上述模式或新模式的組合的服務(wù)代理實現(xiàn)。
10.5工作流整理器在一個優(yōu)選實施例中，對大多數(shù)有效的媒體驅(qū)動服務(wù)請求的完成通常需要某一類型的協(xié)作機制，該協(xié)作機制能夠管理請求事件流、管理包括短暫的中間結(jié)果在內(nèi)的任何相關(guān)數(shù)據(jù)并確保遵循與完成相關(guān)的規(guī)則(如果有的話)。這個功能可以用事務(wù)協(xié)商程序的形式提供，從關(guān)系數(shù)據(jù)庫中簡單的事務(wù)監(jiān)控程序到在微軟MTS/COM+中所看到的更通用的代理。在一個優(yōu)選實施例中，工作流整理器是可編程的機制，通過它媒體驅(qū)動節(jié)點編排對服務(wù)調(diào)用的處理和完成。
在一個優(yōu)選實施例中，可以根據(jù)特定媒體驅(qū)動端點的特征和需求設(shè)計工作流整理器，并且它被設(shè)計用來支持大量功能，從傳統(tǒng)的消息排隊到更復(fù)雜的分布式事務(wù)協(xié)商。簡單的工作流整理器為任意MSDL消息的存儲和檢索提供了接口。通過構(gòu)建工作流整理器，可以支持大量的功能，包括-對服務(wù)請求的收集以進行更有效的處理。
-將服務(wù)響應(yīng)簡單地聚集成復(fù)合響應(yīng)。
-對多個服務(wù)請求和服務(wù)響應(yīng)的手工編排以便創(chuàng)建復(fù)合服務(wù)。
-對多個服務(wù)請求和服務(wù)響應(yīng)的自動編排以便創(chuàng)建復(fù)合服務(wù)。
圖7示出了另一潛在的交互模式。這個交互模式從服務(wù)請求到達媒體驅(qū)動節(jié)點并通過該節(jié)點的服務(wù)適配層被接受開始。消息被傳送到MSDL消息泵，它將首先驅(qū)動然后由工作流整理器驅(qū)動以滿足請求并返回響應(yīng)。這個模式是多個服務(wù)處理模式的基礎(chǔ)。在一般的簡單情況下，服務(wù)請求的完成可以用單個請求/響應(yīng)交互模式表示，其中處理是相同的并且處理請求的規(guī)則被用MSDL完全表示為請求的一部分。但是，服務(wù)請求的完成可能取決于在某段時間上被異步處理的到達的多個MSDL消息。這種情況下，處理是由工作流整理器監(jiān)控的潛在的長期事務(wù)的一部分。
在更復(fù)雜的情況下，特定服務(wù)請求的完成可能需要多個節(jié)點以協(xié)同方式參與。可以用MSDL表示處理請求的規(guī)則，MSDL可以隨意包裝來自其它服務(wù)編排描述標準(例如BPEL)的消息。在請求的完成中，節(jié)點的工作流整理器可能通過某組邏輯接口依靠功能或者可以和其它媒體驅(qū)動節(jié)點交互。
當一個MSDL請求消息被給到工作流整理器時，它確定處理該請求的正確規(guī)則是什么。根據(jù)工作流整理器的實現(xiàn)，可以用該節(jié)點所公開的一組服務(wù)的固定狀態(tài)機的形式表示服務(wù)描述邏輯，或者用支持對更自由的表達形式的服務(wù)處理邏輯(例如用BPEL4WS描述)的處理的方式表示它。工作流整理器體系結(jié)構(gòu)優(yōu)選地是模塊化并且可擴展的，支持插件。在一個優(yōu)選實施例中，MSDL自身支持表示將多個媒體驅(qū)動服務(wù)編排成復(fù)合服務(wù)的規(guī)則的簡單方式。
除了解釋服務(wù)組成和處理規(guī)則外，在一個優(yōu)選實施例中工作流整理器將需要確定在啟動服務(wù)完成處理周期的環(huán)境中是否應(yīng)該使用MSDL消息、或者是否只是進一步將MSDL消息輸入正在進行的事務(wù)鏈中。MSDL消息包括可用于進行這些類型的判定目的的ID和元數(shù)據(jù)；還可以擴展MSDL消息以包括促進消息處理的附加信息，可以是服務(wù)事務(wù)特有的附加信息。
10.6通知服務(wù)除了異步和同步RPC-類通信模式外，在客戶端明確啟動請求并隨即或者等待響應(yīng)或者通過對標簽的輪詢周期性地檢查響應(yīng)的情況下，媒體驅(qū)動架構(gòu)的優(yōu)選實施例還支持基于通知意圖的通信模式的純消息傳送類型。下面的組件構(gòu)成了在一個優(yōu)選實施例的通知架構(gòu)中使用的核心MSDL數(shù)據(jù)和消息類型-通知-目標是感興趣的具有媒體驅(qū)動功能的端點(節(jié)點)的包括指定類型的有效負載的消息。
-通知意向條件-用來確定特定節(jié)點是否將接收特定通知的標準。通知意向條件可能包括基于特定類型標識(例如節(jié)點ID、用戶ID等)、事件(例如，節(jié)點發(fā)現(xiàn)、服務(wù)發(fā)現(xiàn)等)、近似性分組(例如，新的jazz俱樂部成員)或者一般分類(例如，廣告)。
-通知有效負載-通知中標有類型的內(nèi)容。有效負載類型可以從簡單的文本消息到更復(fù)雜的對象。
-通知處理器服務(wù)接口-可以在其上接收通知的服務(wù)提供者接口的類型。服務(wù)提供者還描述了與該接口相關(guān)的通知意向條件，以及可接受的有效負載類型。支持這個接口的節(jié)點可能是該通知的最終目標或者是中間處理端點。
-通知處理器服務(wù)-能夠?qū)⑼ㄖヅ涞礁信d趣的節(jié)點、根據(jù)某一策略傳送通知的節(jié)點。
-通知發(fā)起者-向一組感興趣的節(jié)點和/或通知處理節(jié)點的一個中間集合發(fā)出通知的節(jié)點。
像所有的MSDL數(shù)據(jù)類型和消息一樣，通知、通知意向條件和通知有效負載優(yōu)選地也是可擴展的。另外，通知處理器服務(wù)接口優(yōu)選地受任何其它媒體驅(qū)動服務(wù)接口從屬的相同授權(quán)過程所支配。因而，即使一個特定的通知可能就意向條件和可接受有效負載來說相匹配，節(jié)點也可能根據(jù)與該通知的中間發(fā)送者或發(fā)起源相關(guān)的某一相關(guān)接口策略而拒絕接受它。
圖8示出了發(fā)現(xiàn)了支持通知處理器服務(wù)的節(jié)點的一組通知處理節(jié)點。作為它的服務(wù)描述的一部分，支持接收通知的節(jié)點指定它的通知意向條件是什么以及什么通知有效負載類型是可接受的。
圖9示出了如何傳送通知。任何節(jié)點都可以是發(fā)起源以及通知的處理者，也可負責(zé)傳送它。選擇處理來自外部通知-發(fā)起節(jié)點的通知的通知處理器可以和商用通知處理引擎(例如微軟通知服務(wù))結(jié)合在一起以提高效率。
10.7服務(wù)發(fā)現(xiàn)媒體驅(qū)動架構(gòu)的優(yōu)選實施例支持一組靈活的發(fā)現(xiàn)服務(wù)模式。這些模式可以被映射到現(xiàn)有的發(fā)現(xiàn)模式上。在一個實施例中，該架構(gòu)支持這些基本的服務(wù)發(fā)現(xiàn)模式-客戶端驅(qū)動-媒體驅(qū)動節(jié)點明確地發(fā)出請求到支持“服務(wù)查詢”服務(wù)接口的某組目標節(jié)點詢問它們是否支持指定的服務(wù)集合。如果該請求節(jié)點獲得了授權(quán)，該服務(wù)提供節(jié)點將報告它支持所請求的接口和相關(guān)的服務(wù)接口綁定。如果那些節(jié)點公開了任何服務(wù)這是它們將支持的更普通的接口中的一個。
-節(jié)點注冊-節(jié)點能夠向其它節(jié)點注冊它的描述，包括它所支持的服務(wù)。如果一個節(jié)點支持這個接口，它希望從其它節(jié)點接收請求并隨即根據(jù)某一策略緩存那些節(jié)點描述。這些節(jié)點描述隨后可由接收節(jié)點或向具有緩存起來的節(jié)點描述的節(jié)點進行服務(wù)查詢的其它節(jié)點直接使用。
-基于事件-節(jié)點發(fā)出表示狀態(tài)變化(例如節(jié)點活動/可用)的通知，或者一個節(jié)點通告它支持某些具體服務(wù)。通知可以包含對該節(jié)點和它的服務(wù)的完整描述，或者只包含與該事件相關(guān)的節(jié)點的ID。感興趣的節(jié)點隨后可以選擇接受并處理該通知。
圖10示出了客戶端驅(qū)動的情況，其中某一請求節(jié)點向目標服務(wù)提供節(jié)點進行服務(wù)查詢請求并接收指出該服務(wù)提供者是否支持所請求的服務(wù)的響應(yīng)。
圖11示出了節(jié)點注冊情況，其中某一請求節(jié)點想要向打算接收它的描述并根據(jù)某一內(nèi)部策略將其緩存起來的另一目標節(jié)點注冊它的描述。該請求節(jié)點向目標服務(wù)提供節(jié)點發(fā)出注冊請求并接收表示該服務(wù)提供者是否緩存了它的描述的響應(yīng)。
圖12示出了正通過通知(這種通知可能以多種形式到來，包括與節(jié)點狀態(tài)中的一般狀態(tài)變化有關(guān)的通知)被告知服務(wù)存在的具有媒體驅(qū)動功能的節(jié)點或者明確發(fā)送與服務(wù)可用性有關(guān)的通知的節(jié)點。
10.8服務(wù)授權(quán)在媒體驅(qū)動節(jié)點允許訪問指定服務(wù)之前，它優(yōu)選地首先確定該請求節(jié)點是否被允許訪問。在一個優(yōu)選實施例中，允許訪問是根據(jù)兩個不同但相關(guān)的標準。第一個是該服務(wù)提供節(jié)點對于這次通信是否相信該請求節(jié)點，第二個是是否存在允許該請求節(jié)點訪問所請求的服務(wù)的接口的策略。
10.8.1建立信任在一個優(yōu)選實施例中，媒體驅(qū)動架構(gòu)對任意節(jié)點集如何達到彼此信任沒有具體的要求、標準或決策邏輯。信任語義可以隨節(jié)點而完全改變。媒體驅(qū)動架構(gòu)努力提供允許節(jié)點協(xié)商相互可接受的信任關(guān)系的標準工具集。在節(jié)點間的信任判定和建立過程中，媒體驅(qū)動架構(gòu)的優(yōu)選實施例支持可用于建立信任關(guān)系的節(jié)點憑證交換。在該媒體驅(qū)動架構(gòu)內(nèi)，可以用多種不同模式交換與信任有關(guān)的憑證。例如-服務(wù)綁定屬性-信任憑證作為服務(wù)接口綁定一部分被隱含交換的模式。例如，如果一個節(jié)點以SSL上的HTTP發(fā)送或作為需要WS-安全XMLt簽名的Web服務(wù)公開它的服務(wù)，那么這個服務(wù)綁定的實際屬性可以傳送所有必要的與信任有關(guān)的憑證。
-請求/響應(yīng)屬性-通過MSDL請求和響應(yīng)消息交換信任憑證的模式，可以選擇包括消息上的屬性作為憑證。
-顯式交換-通過允許查詢與特定節(jié)點包含的信任憑證有關(guān)的信息的服務(wù)-提供者接口明確地交換信任憑證的模式。這是最普遍的模式，通常需要單獨的來回會話以交換憑證。服務(wù)接口綁定自身提供相互可接受的信任通道。
可以直接作為請求和響應(yīng)消息上的屬性交換與信任有關(guān)的憑證。例如，數(shù)字證明可以被附加到請求和響應(yīng)消息上并隨著請求和響應(yīng)消息而流動，并可以用于形成信任關(guān)系。
在圖13所示的情況中，節(jié)點可以通過安全憑證服務(wù)直接交換憑證，如果特定節(jié)點支持這個接口的話。
除了這些基本模型之外，該媒體驅(qū)動架構(gòu)優(yōu)選地支持這些不同途徑的組合。例如，可以用與半信任服務(wù)綁定相關(guān)的通信通道更直接地引導(dǎo)其它安全-相關(guān)憑證的交換或者直接交換安全-相關(guān)憑證(它們可能有某種類型的內(nèi)在完整性)并將它們用于與某一服務(wù)接口綁定相關(guān)的安全通信通道的建立。
總之，建立信任必須遵循的信任模型語義和過程隨實體而變化。有些情況下可以不需要節(jié)點之間的相互信任。這種類型的動態(tài)混合環(huán)境要求提供允許不同實體協(xié)商對環(huán)境敏感的信任語義的公共工具集的靈活模式。
10.8.2受策略管理的訪問除了在一組交互節(jié)點之間建立信任關(guān)系之外，在服務(wù)提供節(jié)點允許請求節(jié)點訪問服務(wù)之前它優(yōu)選地還必須根據(jù)與該服務(wù)接口相關(guān)的任何策略確定是否允許這個訪問。該媒體驅(qū)動架構(gòu)提供了一致、靈活的方式進行這個判定。在一個優(yōu)選實施例中，作為服務(wù)描述的一部分，將指定一個或多個媒體驅(qū)動節(jié)點作為授權(quán)服務(wù)提供者。將要求這些授權(quán)服務(wù)提供節(jié)點中的每一個都實現(xiàn)用于處理并響應(yīng)“授權(quán)”查詢請求的標準服務(wù)。例如，在允許訪問一個服務(wù)接口之前，目標服務(wù)提供者可以分發(fā)一個“授權(quán)”查詢請求到授權(quán)訪問它的服務(wù)的所有媒體驅(qū)動節(jié)點，并可以只在所有授權(quán)實體都響應(yīng)表示允許該訪問時才允許訪問。
如圖14所示，服務(wù)提供節(jié)點向管理對所請求的服務(wù)的訪問的所有節(jié)點發(fā)出授權(quán)請求，然后根據(jù)結(jié)果或者處理并返回適用的服務(wù)響應(yīng)或者返回表示該訪問被拒絕的響應(yīng)。除了提供一致的機制之外，還希望有授權(quán)節(jié)點用來做出判定的機制在實踐上盡可能公開以便能夠為具體的平臺和客戶端實現(xiàn)最合適的策略判定機制。媒體驅(qū)動優(yōu)選地是策略管理系統(tǒng)中樞；它對授權(quán)節(jié)點如何根據(jù)授權(quán)查詢做出與對服務(wù)的授權(quán)有關(guān)的決策沒有要求。
盡管媒體驅(qū)動優(yōu)選地對由特定平臺的授權(quán)節(jié)點使用的具體策略引擎和策略語言沒有要求，但在一個優(yōu)選實施例中要求它具有互操作性，即授權(quán)請求具有可交換和處理的某種標準形式。“授權(quán)查詢請求”是可擴展的，能夠攜帶靈活的有效負載以便它能夠適應(yīng)不同策略管理系統(tǒng)環(huán)境中的不同類型的授權(quán)查詢。在一個實施例中，提供對至少兩種授權(quán)格式的支持(1)用某一最小的通用的命名標準作為輸入(例如簡單的請求者ID、資源ID、動作ID、)提供非常簡單的包裝的簡單格式和(2)SAML格式，它提供了傳送包裝好的安全確認標記語言形式的查詢請求的方式。
在一個優(yōu)選實施例中，要求任何授權(quán)節(jié)點至少識別并支持該“簡單”格式并且能夠?qū)⑺成涞皆撌跈?quán)節(jié)點上存在的任何本地策略表示格式。對其它格式，如果該授權(quán)節(jié)點不能處理或不能理解“授權(quán)”查詢請求的有效負載它應(yīng)該返回適當?shù)某鲥e響應(yīng)。對該基本媒體驅(qū)動架構(gòu)的擴展可以包括節(jié)點在可接受格式的授權(quán)請求上協(xié)商的能力，以及節(jié)點查詢以確定特定的授權(quán)服務(wù)提供者節(jié)點支持什么格式的能力。
在一個實施例中，“授權(quán)”查詢響應(yīng)，盡管是可擴展的，但由簡單形式組成以表示訪問是否被許可。也可以有對這個服務(wù)的這個響應(yīng)的其它形式，包括如果對該特定接口的訪問得到許可對該請求節(jié)點必須要完成的義務(wù)的規(guī)定。
11.消費類媒體應(yīng)用媒體驅(qū)動的實施例可以用來將不同的消費類設(shè)備鏈接到包括個人和局域網(wǎng)、家庭網(wǎng)關(guān)、基于IP和非IP的廣域網(wǎng)的多級環(huán)境中的大量不同服務(wù)。例如，已經(jīng)在一個使用蜂窩電話、游戲平臺、PDA、PC基于web的內(nèi)容服務(wù)、發(fā)現(xiàn)服務(wù)、通知服務(wù)和更新服務(wù)的互連系統(tǒng)中成功地證明了互操作性。本實施例支持多種媒體格式(例如MP4、WMF等)、多種發(fā)現(xiàn)協(xié)議(用于在藍牙上并通過像UDDI、LDAP、活動目錄這樣的注冊的服務(wù)發(fā)現(xiàn))以及基于IP的通知和相同設(shè)備上的無線SMS(短消息)通知。編排功能用來幫助用戶克服互操作障礙。當有對內(nèi)容的查詢時，不同的服務(wù)被協(xié)調(diào)起來以完成，包括發(fā)現(xiàn)、查找、匹配、更新、權(quán)利交換和通知服務(wù)。在優(yōu)選實施例中，希望用戶能夠使用大多數(shù)任何設(shè)備、發(fā)出對內(nèi)容的期望、并且?guī)缀趿⒓幢粌?nèi)容和權(quán)利以及交付能力滿足以使用且共享該內(nèi)容。編排能力允許用戶在動態(tài)多級網(wǎng)絡(luò)中在任意點從實際上的任何設(shè)備察看家庭和基于Internet的內(nèi)容緩存?？梢詫⑦@個能力擴展到促進流和播放列表共享的更高級服務(wù)，使得臨時廣播和小范圍廣播容易發(fā)現(xiàn)和連接，并用很多不同的設(shè)備同時確保權(quán)利得到尊重。
在消費-中心端之外，通常想要找到一種方式來提供不依賴于對媒體格式、權(quán)限管理和完成協(xié)議的單組標準的端到端可互操作的媒體發(fā)布系統(tǒng)。在包括了內(nèi)容創(chuàng)作者、發(fā)布者、設(shè)計者、服務(wù)提供者、設(shè)備制造商和用戶的價值鏈中，在各個段中都有大量本地化的需求。就權(quán)限管理來說這尤其正確，這種情況下內(nèi)容創(chuàng)作者需要向不同的下游價值鏈元素表達使用權(quán)利，使用權(quán)利在不同環(huán)境中有不同的應(yīng)用。用戶網(wǎng)關(guān)通常其關(guān)注集合要窄得多，并且終端用戶設(shè)備通常只有非常簡單的關(guān)注集合，即只播放內(nèi)容。
采用動態(tài)自配置分布服務(wù)的充分自動化系統(tǒng)，內(nèi)容創(chuàng)作者可以產(chǎn)生并打包內(nèi)容、表達權(quán)利并放心地依賴由其它服務(wù)提供者增加的價值以幾乎實時地將該內(nèi)容提供給所有感興趣的用戶，不管他們在哪里或者他們在使用什么種類的設(shè)備。媒體驅(qū)動的實施例可以用來完成(或近似完成)這個目標，或其中的特征，并且能夠提供用于多個服務(wù)提供者不必等待或依賴單組端到端標準就能創(chuàng)建并引入使用戶和服務(wù)提供者都受益的新服務(wù)的方法。一個可能的途徑允許數(shù)據(jù)權(quán)限管理被分解成具有集中在服務(wù)接口的策略管理而不是復(fù)制保護上的更自然的關(guān)注劃分的組件。這種途徑可能會在數(shù)字內(nèi)容領(lǐng)域中改變用戶和內(nèi)容創(chuàng)作者之間的緊張關(guān)系，因為是以向用戶提供有用的信息和即時滿意的豐富的服務(wù)基礎(chǔ)結(jié)構(gòu)提供內(nèi)容。策略管理能夠限制盜版者利用他們的合法服務(wù)的程度。事實上，設(shè)計媒體驅(qū)動是為了允許網(wǎng)絡(luò)效果鼓勵非常豐富的合法服務(wù)集的進展產(chǎn)生超出盜版者所能提供的價值。
12.一般企業(yè)應(yīng)用受策略管理的P2P服務(wù)編排看來在商業(yè)世界的一些領(lǐng)域中也有有趣的應(yīng)用，例如供應(yīng)鏈管理(SCM)和客戶關(guān)系管理(CRM)。CRM是關(guān)于發(fā)現(xiàn)、獲得并保持客戶。幾乎在任何以客戶為中心的電子商務(wù)戰(zhàn)略中它都是核心部分，在那里能夠方便地使用集成信息系統(tǒng)和能讓客戶通過任何想要的通信通道通信的聯(lián)系中心實現(xiàn)專注于客戶。對供應(yīng)商來說也是如此。大多數(shù)企業(yè)具有某種類型的分層結(jié)構(gòu)和部門化，并且在內(nèi)部工具良好的部門和過程觀點不一定對客戶和供應(yīng)商也能工作良好。希望能讓企業(yè)的部門為它們的部門發(fā)布全面的服務(wù)接口集合，以使那些服務(wù)能由不同客戶和供應(yīng)商(根據(jù)策略)以優(yōu)化他們的過程和服務(wù)的方式使用。這是超越企業(yè)信息入口的一大步。
今天，大多數(shù)企業(yè)用相對昂貴的預(yù)先包裝好的應(yīng)用程序組(表現(xiàn)為使用專有客戶端/服務(wù)器基礎(chǔ)結(jié)構(gòu)的單一軟件應(yīng)用)實現(xiàn)了CRM。這些應(yīng)用程序組在大量的配置后在企業(yè)內(nèi)互相協(xié)作。web服務(wù)允許在通信不僅發(fā)生在封閉的LAN還發(fā)生在MAN和WAN上的地方使用開放協(xié)議和分布式web服務(wù)基礎(chǔ)結(jié)構(gòu)。這個模式使得遠程應(yīng)用服務(wù)提供者(ASP)能夠管理CRM應(yīng)用程序?qū)⑵渥鳛榉?wù)集合交付給來自不同數(shù)據(jù)中心的商業(yè)中的多個實體。企業(yè)單位和部門變成了這些服務(wù)的入口，有些情況下變成了這些服務(wù)的聚集者。在IT產(chǎn)業(yè)正在面向服務(wù)體系結(jié)構(gòu)/應(yīng)用(SOA)的領(lǐng)域中經(jīng)歷的發(fā)展環(huán)境中可以看到這一點。企業(yè)和客戶到應(yīng)用相關(guān)服務(wù)的接口都可以從簡單的基于瀏覽器的應(yīng)用到更大型的以PC為中心的應(yīng)用。
這個新模型仍然面對一些重大的障礙，對它被主流接受帶來了困難，例如信息機密性和訪問控制。當ASP提供一個CRM解決方案時，企業(yè)可能遇到圍繞別的公司手中的敏感客戶數(shù)據(jù)的位置的問題。該公司必須確保只有合法的實體能夠訪問這個信息。從客戶的角度來看，他們現(xiàn)在可能與別的公司有新的關(guān)系(可能是明顯的或隱藏的)。所需要的是讓客戶和企業(yè)都能在他們的信息上進行訪問控制的基礎(chǔ)機制。
應(yīng)用可擴展性。ASP通常與一小組特殊的技術(shù)提供商和他們的相關(guān)產(chǎn)品或服務(wù)結(jié)盟。企業(yè)通常更喜歡平衡來自不同供應(yīng)商的不同技術(shù)集的靈活性。應(yīng)用架構(gòu)不必受限于特定ASP的當前商業(yè)關(guān)系或技術(shù)選擇，而希望具有能夠讓ASP快速有效地集成從不同技術(shù)提供商或其它ASP提供的新功能的基礎(chǔ)機制。應(yīng)用架構(gòu)還應(yīng)該能夠集成由基于(例如)內(nèi)部開發(fā)的擴展的企業(yè)單位自己直接提供的CRM服務(wù)。
服務(wù)層協(xié)議(SLA)。企業(yè)的服務(wù)需要通常不是靜態(tài)的。相反，它們通常會根據(jù)變化的商業(yè)條件而變化，包括由競爭驅(qū)動的新功能、基于內(nèi)部商業(yè)活動的運轉(zhuǎn)負載特征和正在為特定活動支持客戶數(shù)量以及平衡較低費用服務(wù)選擇的能力。有些情況下這些變化可能需要大量時間的人的干預(yù)，但其它情況下可以根據(jù)一組指定規(guī)則自動化或快速重新配置這些變化。對于這兩種情況來說，可以將CRM應(yīng)用服務(wù)看作是根據(jù)已有的環(huán)境和ASP和商業(yè)單位之間授權(quán)的協(xié)議編排成新的配置。這些類型的應(yīng)用可以被表征為自-組織。
媒體驅(qū)動的實施例在解決這些需要的一些或全部中可以扮演一個角色。例如，媒體驅(qū)動的實施例可以用來提供解決構(gòu)建動態(tài)的、面向服務(wù)的、自組織的應(yīng)用(例如CRM，其中只有信任的、獲得授權(quán)的實體能夠訪問有關(guān)的服務(wù)和信息)中的上述要求所需必要的基礎(chǔ)構(gòu)建模塊。
圖15示出了展示媒體驅(qū)動如何被用在向不同方面交付CRM-相關(guān)服務(wù)的環(huán)境中的情況。在圖15所示的場景中，商業(yè)單位能夠使用大量不同ASP提供構(gòu)造不同類型的CRM應(yīng)用或提供客戶數(shù)據(jù)上的不同視圖給它的組織內(nèi)的不同部門或它的客戶所必需的服務(wù)。
該場景示出了使用由該媒體驅(qū)動架構(gòu)的優(yōu)選實施例提供的功能的幾個方面，包括下列中的一些或全部-不同CRC技術(shù)提供商之間隱式或顯式的互操作性。通過說明必要的接口并在ASP一級或直接在現(xiàn)有的CRM軟件包上(用服務(wù)適配層)提供適當?shù)慕壎ǎ髽I(yè)就能夠使用具有來自不同提供商的各種CRM技術(shù)的單個ASP或多個ASP。
-通過經(jīng)由該媒體驅(qū)動架構(gòu)訪問客戶數(shù)據(jù)，能夠控制它用于訪問控制的豐富的策略管理架構(gòu)。
-部門能夠通過服務(wù)代理訪問對它的應(yīng)用必需的CRM有關(guān)服務(wù)，由此將圍繞該商業(yè)單位與傳輸協(xié)議、數(shù)據(jù)格式等的兼容性的問題隔離。
-可以控制該媒體驅(qū)動架構(gòu)中部門、數(shù)據(jù)倉庫和應(yīng)用服務(wù)提供商之間的交互。優(yōu)選地，只有合法授權(quán)的實體能夠訪問該服務(wù)、并且服務(wù)調(diào)用將只在不同的媒體驅(qū)動架構(gòu)參與者能夠在它們的交互中建立可接受的信任級別時才會發(fā)生。
-服務(wù)組合和編排。CRM應(yīng)用是自組織的，因為應(yīng)用由來自若干不同ASP被編排在一起的服務(wù)組成，或者應(yīng)用是從單個ASP被交付但仍然由多個服務(wù)構(gòu)成，這多個服務(wù)的組成和使用需要對不同客戶視角動態(tài)配置。由服務(wù)提供商公開的功能由服務(wù)級協(xié)議(SLA)和運行環(huán)境驅(qū)動而隨時間變化。媒體驅(qū)動工作流整理器可以用來編排服務(wù)。用于控制這個交互的規(guī)則可以用MSDL直接指定或者在SLA中用某種標準方式編碼，只要存在為理解并解析該描述的工作流整理器所寫的插件。想起工作流整理器與媒體驅(qū)動消息泵合作收集并處理必要的消息以確定如何根據(jù)需求提供指定服務(wù)。
在當前的實施例中，是用一組基于相互信任的PolicyWorks和PolicySpeak策略表示語言的分布式策略管理服務(wù)實現(xiàn)媒體驅(qū)動。但是，媒體驅(qū)動被設(shè)計為使用其它策略管理架構(gòu)和語言，例如IBM的PolicyDirector和XACML，并且在一個優(yōu)選實施例中媒體驅(qū)動提供了策略管理服務(wù)接口，以便能夠使用任何適當?shù)牟呗怨芾砑軜?gòu)和/或策略表示語言。
作為背景，PolicyWorks是一組軟件組件，可被配置用來發(fā)起、部署和實施關(guān)于在企業(yè)內(nèi)和企業(yè)之間企業(yè)和客戶之間對基于網(wǎng)絡(luò)的內(nèi)容、服務(wù)和資源的使用的規(guī)則、權(quán)利和策略。注意企業(yè)策略或控制通常需要和用于識別用戶、憑證、目錄、內(nèi)容元數(shù)據(jù)和其它策略和控制的裝置交互。PolicyWorks被設(shè)計為被有效地集成到企業(yè)中以控制已有的應(yīng)用、目錄和識別系統(tǒng)。PolicyWorks的一個目標是簡化對統(tǒng)一對跨越從網(wǎng)絡(luò)和文件系統(tǒng)訪問管理、企業(yè)信息入口和資產(chǎn)管理到供應(yīng)鏈管理、web服務(wù)、數(shù)字柜服務(wù)和消費媒體訂購應(yīng)用的大量主要應(yīng)用的策略和規(guī)則的安全管理。
在一個優(yōu)選實施例中，PolicyWorks體系結(jié)構(gòu)基于公開了大量基本接口的邏輯模型-受管理選項-這個接口由應(yīng)用程序(例如上面提到的那些)用來管理這些應(yīng)用程序關(guān)于具體的資源、內(nèi)容對象或服務(wù)的動作。實際上可以用PolicyWorks管理任何對象，提供持久的安全保護、訪問控制、用途監(jiān)控和檢查或事務(wù)管理。通過這個接口，應(yīng)用程序可以使對象、服務(wù)或資源可用、在策略控制下、確保使用規(guī)則和要求得到了遵守。管理組件封裝了管理對象必需的方法和操作。PolicyWorks允許為這種管理使用大量可定制的和非定制的解決方案，例如Microsoft Office和Adobe Acrobat中的文檔保護機制，以及由J2EE EJB和Microsoft.Net架構(gòu)提供的代碼資源和服務(wù)保護機制。
-策略查詢-這個接口用來精確地判斷對所管理的對象、資源、或給特定用戶的服務(wù)、條件集合、環(huán)境數(shù)據(jù)以及任意其它有關(guān)因素允許什么動作。對查詢的響應(yīng)可以包括許可和/或附加條件以及該對象的使用所伴隨的義務(wù)。該管理組件在接收到對查詢的響應(yīng)后負責(zé)實施該策略并執(zhí)行(或使執(zhí)行)任何義務(wù)并監(jiān)控所請求的使用的結(jié)果。
-憑證查詢-這個接口由策略管理器用來確定可能在與所管理的操作相關(guān)的策略中扮演角色的用戶的屬性。這個邏輯模塊在實際實現(xiàn)中得到了豐富，以便，例如，策略管理器訪問內(nèi)部和外部的大量接口和資源以確定對策略查詢的響應(yīng)，因為可能有大量目錄、以及與活動者(用戶、策略創(chuàng)建者、資源管理者等等)和所管理的對象自身有關(guān)的規(guī)則和元數(shù)據(jù)資源。
-安全服務(wù)-這個接口用來為所管理的動作的請求者獲得身份管理服務(wù)，并為所管理的對象獲得持久的保護服務(wù)。
-策略管理-這個接口用來管理適合所管理的對象的規(guī)則和控制的分布式策略管理數(shù)據(jù)庫。用于創(chuàng)建并維護策略的各種工具使用這個接口。這些工具能夠提供非常直接的方式來應(yīng)用并管理策略。例如，使用這個接口可以創(chuàng)建將策略與文件系統(tǒng)中的共享文件夾相關(guān)的工具，并能夠允許用戶簡單地通過在該文件夾中拖放文檔就能將該策略應(yīng)用到文檔(或?qū)ο?。其它工具可以使用更復(fù)雜的創(chuàng)建技術(shù)，它們使用任意數(shù)量的策略表示語言以非常精確和有目標的術(shù)語指定策略。
SCM是另一應(yīng)用，在那里實際上任何企業(yè)的成員都能將他們的外部提供商網(wǎng)絡(luò)看作一個大的虛擬庫房，具有由媒體驅(qū)動服務(wù)管理的發(fā)送順序策略，并且記帳是通過媒體驅(qū)動兼容的通知服務(wù)協(xié)商的。
盡管為了明確起見已經(jīng)用一些細節(jié)說明了前述發(fā)明，但顯然在不偏離本發(fā)明的基本原理的前提下可對其進行特定的變化和改進。應(yīng)該注意到有很多可靠方式實現(xiàn)本發(fā)明的過程和設(shè)備。因此，現(xiàn)有的實施例將被看作說明性而非限制性的，并且本發(fā)明也不限于這里所給出的具體細節(jié)。
媒體驅(qū)動框架的示范實施例圖1(附件A的部分)
媒體驅(qū)動節(jié)點的概念視2(附件A的部分)
一般交互模式示例圖3(附件A的部分)
服務(wù)適配層圖4(附件A的部分)
服務(wù)代理-客戶端MSDL交互模式圖5a 服務(wù)代理-客戶端本地交互模式圖5b(附件A的部分)
服務(wù)代理-服務(wù)端-中間點交互模式圖6(附件A的部分)
媒體驅(qū)動工作流整理器的交互模式圖7(附件A的部分)
通知-服務(wù)發(fā)現(xiàn)圖8(附件A的部分)
通知-傳送圖9(附件A的部分)
服務(wù)發(fā)現(xiàn)-客戶端驅(qū)動圖10(附件A的部分)
服務(wù)發(fā)現(xiàn)-給定注冊圖11(附件A的部分)
服務(wù)通知-基于事件圖12(附件A的部分)
根據(jù)直接交換建立信任圖13(附件A的部分)
受策略管理的方向圖14(附件A的部分)
圖15(附件A的部分)
附錄B數(shù)字權(quán)限管理引擎系統(tǒng)和方法相關(guān)專利申請附錄B對應(yīng)美國臨時專利申請第60/504,524號，名為“數(shù)字權(quán)限管理引擎系統(tǒng)和方法”，申請人為Gilles Boccon-Gibod，于2003年9月15日提交。該專利申請(附錄B)與共同所有的美國臨時專利申請第60/476,357相關(guān)，后者的發(fā)明名稱為“用于對等服務(wù)編排的系統(tǒng)和方法”，申請人為William Bradley和David Maher，于2003年6月5日提交(“the Bradley et al.application”；附錄A)。這里，在附錄B中對“the Bradley et al.application”的引用指的是附錄A。
版權(quán)授權(quán)本專利文檔的公開部分包含受版權(quán)保護的內(nèi)容。版權(quán)所有人并不反對任何人將本專利文檔或?qū)＠_部分復(fù)制到WIPO或U.S.專利商標局的專利文件或記錄中，但保留其他所有版權(quán)。
背景技術(shù)：
本發(fā)明一般性涉及數(shù)字信息和服務(wù)的分發(fā)和使用。更具體地，公開了用于提供、支持和/或使用數(shù)字權(quán)限管理引擎的系統(tǒng)和方法。
諸如Internet之類的網(wǎng)絡(luò)已經(jīng)成為傳遞數(shù)字內(nèi)容的主要媒介。Web服務(wù)標準的出現(xiàn)有望加速這一趨勢，使公司能夠提供合并多個軟件平臺并且通過標準化機制與其他web服務(wù)協(xié)作的復(fù)雜服務(wù)。

發(fā)明內(nèi)容
本發(fā)明的實施例提供一種利用web服務(wù)模型的數(shù)字權(quán)限管理引擎。與要求相對復(fù)雜和重量級的客戶端引擎以處理受保護內(nèi)容的傳統(tǒng)的數(shù)字權(quán)限管理(DRM)系統(tǒng)相比，本發(fā)明使得客戶端的DRM引擎相對簡單，而管理策略由在服務(wù)層運行的更豐富的策略管理系統(tǒng)設(shè)置。本發(fā)明的實施例還在選擇媒體格式和加密協(xié)議方面提供了更大靈活性，并且能夠幫助實現(xiàn)DRM系統(tǒng)之間的互操作。
本發(fā)明的優(yōu)選實施例提供了一種能夠用來構(gòu)建支持DRM的強大應(yīng)用的簡單、開放和靈活的客戶端DRM引擎。在一個優(yōu)選實施例中，將DRM引擎設(shè)計為能夠容易地集成到web服務(wù)環(huán)境中，諸如在Bradley等的應(yīng)用中所描述的，以及實際上集成到任何主機環(huán)境或軟件體系結(jié)構(gòu)中。在一個優(yōu)選實施例中，DRM引擎與具體的媒體格式和加密協(xié)議無關(guān)，允許設(shè)計者按照需要使用靈活地使用標準化的或?qū)Ｓ玫募夹g(shù)。另外，優(yōu)選實施例使用的管理模式相對簡單，但可以用來表示復(fù)雜的關(guān)系和業(yè)務(wù)模型。
本發(fā)明的優(yōu)選實施例能夠用來實現(xiàn)下面的部分或全部目標簡單。在一個優(yōu)選實施例中，DRM引擎使用最低要求的基于棧的虛擬機(VM)來執(zhí)行控制程序(例如，執(zhí)行管理策略的程序)。例如，在一個實施例中VM可以僅由幾頁代碼組成。
模塊化。在一個優(yōu)選實施例中，我們把DRM引擎設(shè)計成一個單一的模塊，它集成在一個支持DRM的更大型應(yīng)用內(nèi)?，F(xiàn)在，我們可以從宿主環(huán)境中請求許多以前由單個DRM內(nèi)核執(zhí)行的功能(例如加密服務(wù))，該宿主環(huán)境可以向其他代碼模塊提供這些服務(wù)。這使得設(shè)計人員能夠相對容易地整合標準或?qū)Ｓ眉夹g(shù)。
靈活性。由于采用模塊化設(shè)計，DRM引擎的優(yōu)選實施例可用于從嵌入式設(shè)備到通用PC的各種軟件環(huán)境。
開放。DRM引擎的優(yōu)選實施例適合作為參考軟件，這樣，用戶就可以使用幾乎任何編程語言和在他們能夠完全控制的系統(tǒng)中實現(xiàn)代碼模塊和API。在一個優(yōu)選實施例中，系統(tǒng)并不強制要求用戶采用特定的內(nèi)容格式或限定內(nèi)容編碼。
無關(guān)乎語義。在一個優(yōu)選實施例中，DRM引擎的基礎(chǔ)是一種簡單的基于圖的模型，該模型將授權(quán)請求轉(zhuǎn)換為對圖結(jié)構(gòu)的查詢。圖中的頂點表示系統(tǒng)中的實體，有向邊表示這些實體之間的關(guān)系。但是，DRM引擎并不需要知道這些頂點和邊在任何特定的應(yīng)用中表示什么。
與Web服務(wù)無縫集成。DRM客戶端引擎可以采用多種方式使用Web服務(wù)。例如，可以通過服務(wù)來動態(tài)發(fā)現(xiàn)授權(quán)圖中的頂點和邊。也可以通過高級Web服務(wù)來發(fā)現(xiàn)內(nèi)容和內(nèi)容許可，并將其傳遞給DRM引擎。盡管優(yōu)選實施例的DRM引擎的具體實施例可以配置在許多方面影響Web服務(wù)，但是其體系結(jié)構(gòu)與Web服務(wù)無關(guān)，可以用作一個獨立的客戶端DRM內(nèi)核。
簡化的密鑰管理。在一個實施例中，可以重新使用授權(quán)圖拓撲來簡化內(nèi)容保護密鑰的派生，而不需要加密重定位。這種密鑰派生方法是DRM引擎一個可選特性，但其功能非常強大——系統(tǒng)也可以或者能夠與其他密鑰管理系統(tǒng)集成。
管理、加密與內(nèi)容的分離。在一個優(yōu)選實施例中，管理內(nèi)容的控制在邏輯上與用于執(zhí)行管理的加密信息不同。同樣，控制和加密信息在邏輯上也與內(nèi)容和內(nèi)容格式不同。可以采用分離的方式或一個統(tǒng)一數(shù)據(jù)包傳遞每個元素，這樣就可以在設(shè)計內(nèi)容傳遞系統(tǒng)時具有高度的靈活性。
本發(fā)明的優(yōu)選實施例可以用來實現(xiàn)前述的部分或全部目標；但是，應(yīng)該認識到本發(fā)明也可以由不實現(xiàn)以上目標的系統(tǒng)實現(xiàn)。
在一個優(yōu)選實施例中，DRM引擎包括一個虛擬機(VM)，用于決定是否允許對受保護內(nèi)容進行某些特定操作。我們可以利用最小限度的一組指令將這一控制VM實現(xiàn)為一個簡單的基于棧的機器。在一個實施例中，它能夠執(zhí)行邏輯和算術(shù)計算，并從主機環(huán)境中查詢狀態(tài)信息，以便檢查諸如系統(tǒng)時間和計數(shù)器狀態(tài)等參數(shù)。
在一個優(yōu)選實施例中，DRM引擎使用基于圖的算法檢驗DRM價值鏈中的實體之間的關(guān)系。圖1示出了這樣的授權(quán)圖的一個示例。如圖1所示，該圖包括一個節(jié)點的集合，這些節(jié)點由鏈路連接。在一個優(yōu)選實施例中，鏈接的語義可能會隨應(yīng)用特定的方式發(fā)生變化。例如，從Mac頂點到Knox頂點的有向邊可能表示Knox是Mac的所有者。從Knox到公共圖書館的邊可能表示Knox是該公共圖書館的一名成員。在一個優(yōu)選實施例中，DRM引擎并不強加或解釋這些語義，它只是確定圖中是否存在路徑。
例如，內(nèi)容所有者可以創(chuàng)建一個由控制VM解釋的控制程序，如果使用設(shè)備歸公共圖書館的成員所有并被RIAA認可，則允許播放特定的音樂片斷。當運行于該設(shè)備的控制VM評估此控制程序時，DRM引擎確定在便攜式設(shè)備和公共圖書館之間以及便攜式設(shè)備和RIAA認可之間是否存在鏈接。圖中的邊與頂點可以是靜態(tài)的，內(nèi)置在設(shè)備之中，也可以是動態(tài)的，通過與主機應(yīng)用通信的服務(wù)被發(fā)現(xiàn)。
由于沒有對頂點和鏈接強加語義，因此該優(yōu)選實施例的DRM引擎可以支持更大的靈活性。該系統(tǒng)可適用于從傳統(tǒng)的基于委托的策略系統(tǒng)到授權(quán)域和個人局域網(wǎng)。
在一個優(yōu)選實施例中，DRM客戶端還可以重用授權(quán)圖來派生內(nèi)容保護密鑰。系統(tǒng)設(shè)計人員可能會選擇允許鏈接的存在也表示某些加密信息的共享。在這些情況下，授權(quán)圖可用于派生內(nèi)容密鑰，而無需顯式加密重定位到使用設(shè)備。
DRM引擎的優(yōu)選實施例是模塊化的，因而能夠集成到許多不同的設(shè)備和軟件環(huán)境中。圖2示出了將DRM客戶端引擎集成到內(nèi)容使用設(shè)備中的典型集成。在諸如圖2所示的系統(tǒng)中，典型的內(nèi)容使用事件如下進行主機應(yīng)用202一般通過其用戶接口204接收一個訪問特定內(nèi)容片段的請求。然后主機應(yīng)用202將請求和所有相關(guān)的DRM引擎對象(最好對于主機應(yīng)用是不透明的)發(fā)送到DRM引擎206。DRM引擎206通過定義良好的接口向主機服務(wù)模塊208請求附加的信息和加密服務(wù)。例如，DRM引擎206可能會詢問主機服務(wù)208特定鏈接是否是可信任的，或者要求某些對象被解密。有些必需的信息可能是遠程的，這種情況下，主機服務(wù)208可通過服務(wù)接入點214請求網(wǎng)絡(luò)化服務(wù)提供信息。
一旦DRM引擎206確定特定操作是允許的，它將表明這一點，并將必要的加密密鑰返回給主機服務(wù)208，主機服務(wù)208啟動媒體表現(xiàn)210(例如，通過通過揚聲器播放內(nèi)容，在顯示屏上顯示內(nèi)容等)，其按照需要與加密服務(wù)212協(xié)作。
圖2所示的系統(tǒng)體系結(jié)構(gòu)是如何在應(yīng)用中使用DRM引擎的簡單例子，但是它只是多種可能之一。例如，在其它實施例中，DRM引擎可以在相對復(fù)雜的策略管理系統(tǒng)的管理下集成到打包應(yīng)用中。
應(yīng)認識到，公開的實施例可以以多種方式實現(xiàn)，包括進程、設(shè)備、系統(tǒng)、裝置或計算機可讀介質(zhì)。通過以下的附圖和詳細說明，將更詳細地說明本發(fā)明的實施例的這些和其它特征和優(yōu)點。
本發(fā)明的簡要描述通過參考以下結(jié)合附圖的詳細說明，將容易理解本發(fā)明的實施例，其中相同的參考標號指示相同的結(jié)構(gòu)部件，其中圖1示出了依照本發(fā)明一個實施例的授權(quán)圖。
圖2示出了依照本發(fā)明實施例的數(shù)字權(quán)限管理系統(tǒng)。
圖3示出了在本發(fā)明的優(yōu)選實施例中DRM引擎可以用于內(nèi)容保護和管理的各種對象。
圖4示出了依照本發(fā)明實施例的節(jié)點和鏈接對象。
圖5示出了依照本發(fā)明實施例的控制虛擬機和DRM引擎的集成。
圖6依照本發(fā)明一個實施例的編碼模塊圖7示出了使用節(jié)點圖來幫助實現(xiàn)內(nèi)容加密和解密。
詳細描述這里描述新穎的數(shù)字權(quán)限管理引擎的實施例。如本領(lǐng)域普通技術(shù)人員將會理解的，該引擎本身是新穎的，如同它的許多特征、方面、組件和應(yīng)用一樣。下面給出對本發(fā)明的有效主體的詳細描述。盡管在進行說明時結(jié)合了若干實施例，但應(yīng)該認識到，本發(fā)明并不局限于任一實施例，而是包括各種替代、修改和等效體。舉例來說，盡管一些實施例是在面向用戶的內(nèi)容和應(yīng)用的環(huán)境下描述的，但熟悉本領(lǐng)域的技術(shù)人員會認識到，所公開的系統(tǒng)和方法可以很容易地應(yīng)用到更廣泛的應(yīng)用中。例如，這些實施例可以很容易地應(yīng)用于企業(yè)內(nèi)容和應(yīng)用環(huán)境，而沒有任何限制。另外，盡管為了幫助全面理解本發(fā)明而在以下說明中列出了各種具體細節(jié)，但是不具備部分或全部此類細節(jié)的一些實施例也可以實施。此外，為了清晰起見，對于與本發(fā)明相關(guān)的本領(lǐng)域共知的某些技術(shù)資料沒有進行詳細說明，以避免不必要地模糊本發(fā)明。
在一個優(yōu)選實施例中，DRM引擎在一組基本對象或組裝塊上運行。圖3提供了對這些對象的高層次的舉例說明。如圖3所示，在一個優(yōu)選實施例中，由內(nèi)容(Content)對象302表示的數(shù)據(jù)利用密鑰加密。該密鑰由內(nèi)容密鑰(ContentKey)對象304表示，內(nèi)容和密鑰之間的綁定由保護器(Protector)對象306表示。管理對象的使用以便對內(nèi)容解密的規(guī)則由控制(Control)對象308表示，內(nèi)容密鑰304和控制308之間的綁定由控制器(Controller)對象310表示。服從系統(tǒng)在內(nèi)容對象308中的字節(jié)碼表示的規(guī)則的管理下使用內(nèi)容解密密鑰。
內(nèi)容對象302在優(yōu)選實施例中，內(nèi)容對象302是一個“外部”對象。該對象的格式和存儲不是在DRM引擎的控制下，而是在主機應(yīng)用(例如，它可以是MP4電影文件或MP3音軌等)的內(nèi)容管理子系統(tǒng)的控制下。但是，在一個優(yōu)選實施例中，內(nèi)容的格式使得允許ID和內(nèi)容有效負載相關(guān)。內(nèi)容有效負載以獨立于格式的方式加密(例如，利用對稱加密程序，例如AES)。
內(nèi)容密鑰對象304在一個優(yōu)選實施例中，內(nèi)容密鑰對象304包括唯一的加密密鑰和相關(guān)ID。ID的目的是使得保護器對象306和控制器對象310能夠引用內(nèi)容密鑰對象304。內(nèi)容密鑰對象304中封裝的實際密鑰數(shù)據(jù)是它自身的加密，這樣它僅能由被授權(quán)解密該內(nèi)容的接收者讀取。內(nèi)容密鑰對象304優(yōu)選還可以指定用于加密該密鑰數(shù)據(jù)的密碼系統(tǒng)。用于保護該內(nèi)容密鑰數(shù)據(jù)的密碼系統(tǒng)被稱為密鑰分發(fā)系統(tǒng)?？梢允褂貌煌拿荑€分發(fā)系統(tǒng)。
保護器對象306在一個優(yōu)選實施例中，保護器對象306包含使得DRM引擎能夠找出使用了哪個密鑰加密內(nèi)容對象302中包含的數(shù)據(jù)的信息。保護器對象306還包含關(guān)于使用了哪個加密算法加密該數(shù)據(jù)的信息。保護器對象306包含一個或多個引用內(nèi)容對象302的ID，一個引用內(nèi)容密鑰對象304的ID，內(nèi)容密鑰對象中包含加密該數(shù)據(jù)所使用的密鑰。在一個優(yōu)選實施例中，如果保護器306指向多于一個內(nèi)容對象302，則所有這些內(nèi)容對象表示已經(jīng)使用相同的加密算法和相同密鑰加密的數(shù)據(jù)。
控制對象308控制對象308中包含的信息使得DRM對象能夠在主機應(yīng)用請求時做出關(guān)于是否允許對內(nèi)容的特定操作的決定。管理內(nèi)容密鑰的使用的規(guī)則被作為控制字節(jié)碼編碼在控制對象308中?？刂茖ο?08還包含唯一的ID，以便它們可以被控制器對象310引用。在一個優(yōu)選實施例中，控制對象308是已簽名的，這樣DRM引擎在使用它做決定之前，可以驗證該控制字節(jié)碼是有效和可信的?？蛇x的，控制對象308的有效性也可以通過驗證控制器對象310中包含的安全哈希(當這個信息可用時)而得到。
控制器對象310控制器對象310包含使得DRM對象能夠找出哪個控制對象308管理由內(nèi)容密鑰對象304表示的一個或多個密鑰的使用的信息。在一個優(yōu)選實施例中，控制器對象310還包含它們引用的內(nèi)容密鑰對象304中包含的密鑰數(shù)據(jù)的哈希值，這樣密鑰數(shù)據(jù)和內(nèi)容密鑰對象304之間的綁定就不容易被篡改?？刂破鲗ο?10還可以包含幫助驗證它們所關(guān)聯(lián)的控制對象308的完整性的信息?？刂破鲗ο?10優(yōu)選是已簽名的，這樣DRM引擎能夠信任內(nèi)容密鑰304和管理它的控制對象308之間的綁定的有效性，以及內(nèi)容密鑰ID和實際的密鑰數(shù)據(jù)之間的綁定的有效性。在控制器對象310中包括控制器對象310所引用的控制對象308的哈希的實施例中，不需要單獨驗證控制對象308的簽名就能夠推導(dǎo)出控制對象308的有效性。
如同前面結(jié)合圖1所示，在一個優(yōu)選實施例中，DRM引擎使用一種基于圖的算法檢驗DRM價值鏈中的實體之間的關(guān)系。如圖1所示，該圖包括以鏈接相連的節(jié)點的集合。節(jié)點對象表示DRM概要中的實體。在一個優(yōu)選實施例中，DRM引擎不具有關(guān)于節(jié)點表示什么的隱式或顯式的語義。
使用DRM引擎的給定部署(DRM概要)將定義存在哪種類型的規(guī)則，以及不同的節(jié)點對象代表什么角色和身份。如圖4所示，通常使用節(jié)點對象的屬性表示語義信息。鏈接對象表示節(jié)點之間的關(guān)系。鏈接對象還可選地包含某些加密數(shù)據(jù)，這些數(shù)據(jù)使得DRM引擎能夠使用該鏈接進行內(nèi)容密鑰的派生計算。與節(jié)點相似，在一個優(yōu)選實施例中，DRM引擎不具有關(guān)于鏈接關(guān)系表示什么的隱式或顯式的語義。在特定DRM概要中，取決于鏈接發(fā)自哪個節(jié)點和到達哪個節(jié)點，鏈接關(guān)系的意義可以表示成員關(guān)系、所有關(guān)系、關(guān)聯(lián)和/或其它類型的關(guān)系。例如，在一個典型的DRM概要中，一些節(jié)點對象可以表示用戶，其它節(jié)點對象可以表示用戶，另一些可以表示用戶群。在這個環(huán)境中，設(shè)備和用戶之間的鏈接可以表示所有關(guān)系，用戶和用戶群之間的鏈接可以表示成員關(guān)系。圖4示出了節(jié)點和鏈接對象的例子。
節(jié)點402節(jié)點對象表示系統(tǒng)中的實體。節(jié)點對象的屬性定義節(jié)點表示什么的某些方面，諸如節(jié)點對象在DRM概要的環(huán)境中表示的角色或身份。在一個優(yōu)選實施例中，節(jié)點對象還具有機密性不對稱密鑰對，該密鑰對用于將機密信息定位到對該節(jié)點對象的機密部分具有訪問權(quán)限的子系統(tǒng)(通常是該節(jié)點表示的實體，或者是負責(zé)管理該節(jié)點的一些實體)。定位到一個節(jié)點的機密信息優(yōu)選利用該節(jié)點的機密性公共密鑰加密。在使用用于內(nèi)容密鑰分發(fā)的可選的內(nèi)容密鑰派生系統(tǒng)的實施例中，內(nèi)容保護非對稱密鑰對和內(nèi)容對象對稱密鑰結(jié)合鏈接對象一起使用。
鏈接404在一個優(yōu)選實施例中，鏈接對象404是已簽名的聲明，其聲明在其頂點是節(jié)點對象的圖中，在“發(fā)出”和“到達”節(jié)點之間存在一條有向邊。對于給定的節(jié)點和鏈接結(jié)合，如果在圖中的節(jié)點X頂點和節(jié)點Y頂點之間存在一條有向路徑，那么在節(jié)點X和節(jié)點Y之間存在一條路徑。當節(jié)點X和節(jié)點Y之間存在路徑的時候，說節(jié)點Y是從節(jié)點X可到達的。因而使用鏈接對象所表示的聲明表達哪個節(jié)點是從其它節(jié)點可到達的。管理內(nèi)容對象的控制可以使用特定的目標節(jié)點從表示請求對內(nèi)容對象進行操作的實體的節(jié)點的可到達性，作為允許特定操作發(fā)生的條件。例如，如果節(jié)點D表示想要對一個內(nèi)容對象執(zhí)行播放操作的設(shè)備，管理該內(nèi)容對象的控制可以測試表示特定用戶的特定節(jié)點U是否是可到達的。為了確定節(jié)點U是否是可到達的，DRM引擎檢驗是否存在一個鏈接集合能夠建立節(jié)點D和U之間的路徑。
DRM引擎優(yōu)選在使用鏈接對象確定節(jié)點圖中存在路徑之前先驗證它們。取決于用來簽署鏈接對象的證書系統(tǒng)(例如x509v3)的特定特征，可以給予鏈接對象有限的生命周期，廢止鏈接對象等。在一個優(yōu)選實施例中，管理哪些實體可以簽署鏈接對象、可以創(chuàng)建哪些鏈接對象和鏈接對象的生命周期的策略也可以不直接由DRM引擎處理。這些策略在DRM引擎之外存在，并且通常將利用節(jié)點的屬性信息。例如，在某個策略下已經(jīng)被授予創(chuàng)建設(shè)備節(jié)點和用戶節(jié)點之間的鏈接對象的能力的實體，很可能要檢測它只創(chuàng)建了在具有指示它們確實代表一個設(shè)備的屬性的節(jié)點對象和具有指示它們代表一個用戶的屬性的節(jié)點之間的鏈接。
最后，鏈接對象可以包含加密數(shù)據(jù)，該數(shù)據(jù)使得節(jié)點的內(nèi)容保護密鑰能夠用于密鑰分發(fā)。在一些實施例中，所述加密數(shù)據(jù)除了元數(shù)據(jù)之外還包含“發(fā)出”節(jié)點的私有密鑰和/或?qū)ΨQ內(nèi)容保護密鑰，其是利用內(nèi)容保護公共密鑰或“到達”節(jié)點的內(nèi)容保護對稱密鑰加密的。在下面的題為“節(jié)點、鏈接和內(nèi)容保護”的章節(jié)中提供了關(guān)于節(jié)點和鏈接的關(guān)系和操作的其它信息。
因為在一個優(yōu)選實施例中，DRM引擎不隱式或顯式地指定附加到這些基本對象上的語義，使用DRM引擎的系統(tǒng)將參與到那些對象的一個或多個使用模式中，其將那些對象放入一個語義環(huán)境中。這些語義環(huán)境將被稱為DRM概要。在這個意義上，可以將DRM引擎對象看作用于構(gòu)建DRM系統(tǒng)的組裝塊。
以下的段落舉例說明了可以使用DRM引擎對象構(gòu)建的DRM概要的典型類型。
示例1用戶、PC和設(shè)備在這個DRM概要示例中，定義了以下實體用戶(使用內(nèi)容的個體)、PC(運行使用內(nèi)容的軟件的計算機)和設(shè)備(使用(例如播放)內(nèi)容的硬件和軟件組合)。在這個示例概要中，任何用戶可以擁有無限數(shù)目的設(shè)備，并且可以與最多預(yù)定數(shù)目的PC(例如，4臺PC)相關(guān)聯(lián)?？梢酝ㄟ^允許將內(nèi)容綁定到用戶的規(guī)則(例如，可以檢測播放內(nèi)容的PC或設(shè)備屬于給定用戶或與之相關(guān)聯(lián))管理內(nèi)容。
用戶、PC和設(shè)備，每一個都被分配了一個節(jié)點對象。這些節(jié)點對象具有指示它們是否表示一個用戶、PC或設(shè)備的“類型”屬性。
后端系統(tǒng)管理用戶身份，并且創(chuàng)建用戶節(jié)點以及PC節(jié)點和用戶節(jié)點之間的鏈接對象。在將一個用戶節(jié)點發(fā)送到PC軟件實例之前，后端服務(wù)器將會通過在用戶信息數(shù)據(jù)庫中查找用戶和確定希望同特定PC關(guān)聯(lián)的該用戶是否達到了4的限制條件，來執(zhí)行“每個用戶4臺PC”的策略。在一些實施例中，系統(tǒng)可以為用戶提供刪除已有的PC-用戶關(guān)聯(lián)的方法，使得他們能夠隨著時間過去改變與他們相關(guān)聯(lián)的PC的設(shè)置。PC軟件將保持PC-用戶鏈接對象，并且使用它們(只要它們有效)。
PC軟件被授予了與設(shè)備和用戶關(guān)聯(lián)的能力。這意味著，除了管理PC節(jié)點外，PC軟件還被給定了管理用戶節(jié)點對象的責(zé)任。該軟件具有訪問那些節(jié)點的機密部分的權(quán)限。當一個用戶想同一個設(shè)備相關(guān)聯(lián)的時候(因為她想在該設(shè)備上播放她的內(nèi)容)需要存在從該設(shè)備節(jié)點到該用戶節(jié)點的一個鏈接對象。如果該鏈接對象不存在，PC軟件將創(chuàng)建它，并且令其對所述設(shè)備可用。該設(shè)備將保持該鏈接對象，并且使用它(只要它保持有效)。
為了將內(nèi)容綁定到用戶，打包者應(yīng)用將為該內(nèi)容選擇一個ID或使用現(xiàn)有的一個ID。打包者創(chuàng)建一個加密密鑰和相關(guān)的內(nèi)容密鑰對象，以及將內(nèi)容對象和內(nèi)容密鑰對象綁定的保護器對象。然后該打包者創(chuàng)建一個具有控制程序(優(yōu)選以控制VM字節(jié)碼編譯)的控制對象，該控制程序?qū)⒃诓⑶抑辉谡埱髨?zhí)行一個播放操作的用戶節(jié)點是從PC或設(shè)備節(jié)點可到達的時候，允許“播放”操作。通常，將把控制、控制器、保護器和內(nèi)容密鑰對象嵌入在打包的內(nèi)容中(如果合適的話)，這樣PC和設(shè)備就不需要單獨獲取它們。
當一個設(shè)備或PC想要播放內(nèi)容的時候，DRM引擎將為該內(nèi)容的內(nèi)容ID找到保護器對象，然后找到該保護器引用的內(nèi)容密鑰對象，然后是引用該內(nèi)容密鑰對象的控制器對象，最后找到該控制器引用的控制對象。DRM引擎將執(zhí)行該控制器對象的控制程序，該程序?qū)z測用戶節(jié)點是否是可到達的。如果設(shè)備或PC對象具有證明在它們的節(jié)點和所述用戶節(jié)點之間存在路徑的必要鏈接，那么控制器程序?qū)⒃试S使用內(nèi)容密鑰對象中表示的密鑰，并且該設(shè)備或PC的媒體表現(xiàn)引擎將解密該內(nèi)容并且表現(xiàn)該內(nèi)容。
示例2短暫登錄第二個示例使用了一個幾乎與前面的例子所使用的相同的系統(tǒng)，該系統(tǒng)具有新增的特征管理創(chuàng)建PC節(jié)點和用戶節(jié)點之間的鏈接對象的策略允許不超過例如12個小時的短暫登錄，只要用戶還沒有在其他PC上擁有短暫登錄。這個特征的目的是允許，例如，用戶將他的內(nèi)容拿到朋友的PC上，登錄到那臺PC一段時間和在朋友的PC上播放他的內(nèi)容。當用戶想要登錄到朋友的PC，他輸入他的登錄憑證(這可以是用戶名/密碼、移動電話身份認證、智能卡、或該系統(tǒng)的策略下允許的任何身份認證系統(tǒng))，后端系統(tǒng)檢驗該鏈接所需的用戶節(jié)點和PC節(jié)點的屬性，并且證實不存在仍然有效的短暫登錄。如果滿足了這些條件，后端服務(wù)創(chuàng)建連接該PC和該用戶的鏈接對象，該鏈接對象具有符合要求的登錄持續(xù)時間限制(例如，少于12個小時)的有效周期，以遵守該策略。令該鏈接現(xiàn)在允許PC播放該用戶的內(nèi)容，直到鏈接期滿。
控制虛擬機控制虛擬機(或“控制VM”)是由DRM引擎的優(yōu)選實施例使用以便執(zhí)行管理訪問內(nèi)容權(quán)限的控制程序的虛擬機。以下是對適合DRM引擎體系結(jié)構(gòu)的控制VM的描述，以及對該VM的基礎(chǔ)元件的描述，其后是關(guān)于存儲模型和指令集合的更詳細的說明。
在一個優(yōu)選實施例中，控制VM是一個相對較小的虛擬機，經(jīng)設(shè)計它可以使用多種編程語言來簡單實現(xiàn)。在一個優(yōu)選實施例中，控制VM基于一個面向棧的指令集，該指令集實際上按最低要求設(shè)計，沒有過多地考慮執(zhí)行速度或代碼密度。但是，應(yīng)理解，如果特定的應(yīng)用需要考慮執(zhí)行速度和/或代碼密度，可以使用常規(guī)技術(shù)(如數(shù)據(jù)壓縮)來提高性能。
在一個優(yōu)選實施例中，控制VM適合用低級語言或高級語言編寫，支持匯編、C和FORTH等語言。也可以容易地實現(xiàn)其他語言的編譯器，如Java語言或定制語言等。
在一個優(yōu)選實施例中，與直接在處理器上或在硅片中運行相反，控制VM被設(shè)計為駐留在主機環(huán)境中?？刂芕M的實際主機環(huán)境是DRM引擎。圖5示出了在本發(fā)明的優(yōu)選實施例中控制VM如何和DRM引擎集成。
控制VM在其主機環(huán)境中運行，主機環(huán)境實現(xiàn)了VM執(zhí)行程序時所需的一些功能。通常，控制VM在DRM引擎內(nèi)運行，DRM引擎實現(xiàn)它的主機環(huán)境。
控制VM通過執(zhí)行存儲在代碼模塊內(nèi)的指令來運行程序。有些指令可以通過系統(tǒng)調(diào)用來調(diào)用在程序自身外實現(xiàn)的功能；系統(tǒng)調(diào)用可由控制VM自身實現(xiàn)，也可委托給主機環(huán)境。
現(xiàn)在將描述控制VM的優(yōu)選實施例的一些基本元素。
執(zhí)行模型控制VM執(zhí)行存儲在代碼模塊中的指令，執(zhí)行時，這些代碼作為載入到內(nèi)存的字節(jié)代碼流?？刂芕M維護著一個名為程序計數(shù)器(PC)的虛擬寄存器，指令執(zhí)行時，該計數(shù)器遞增。VM順序執(zhí)行每條指令，直到遇到OP_STOP指令，在調(diào)用棧為空時遇到OP_RET指令，或發(fā)生異常。指令跳轉(zhuǎn)被指定為相對跳轉(zhuǎn)(指定為從當前PC值的字節(jié)偏移量)或絕對地址。
內(nèi)存模型在優(yōu)選實施例中，控制VM的內(nèi)存模型相對比較簡單。VM內(nèi)存分為數(shù)據(jù)段(DS)和代碼段(CS)。數(shù)據(jù)段是單一、平面、連續(xù)的內(nèi)存空間，起始地址是0。數(shù)據(jù)段一般是在主機應(yīng)用或主機環(huán)境的堆內(nèi)存內(nèi)分配的一列字節(jié)。對于特定的VM實現(xiàn)，內(nèi)存空間的大小優(yōu)選固定為最大值，試圖訪問內(nèi)存地址范圍之外的地址將導(dǎo)致出錯，并終止程序的運行。數(shù)據(jù)段可能由VM同時載入的多個代碼模塊共享。數(shù)<p>

.Horz_mux Slice0 PLA0(每位都具有單獨的使能).HMUX
是16個水平狀態(tài)行之一；.每個mux(多路復(fù)用)也都需要三態(tài)使能。

圖6示出了一個示例性代碼模塊，下文中予以描述。
pkCM Atom該pkCM Atom是頂級代碼模塊單元，包含一個次級單元序列。
pkDS Atom該pkDS Atom包含一個可載入數(shù)據(jù)段的內(nèi)存映像。該單元的載荷是一個原始八位字節(jié)數(shù)值序列。
pkDS Atom該pkDS Atom包含一個可載入代碼段的內(nèi)存映像。該單元的載荷是一個原始八位字節(jié)數(shù)值序列。
pkEX Atom該pkEX Atom包含一個導(dǎo)出項列表。每一個導(dǎo)出項的組成部分有名稱，以8位名稱長度編碼，隨后是名稱的字符，包括一個結(jié)尾的0，接著是一個32位的整數(shù)，代表該指定項的字節(jié)偏移(這是相對儲存于pkCS Atom單元中的數(shù)據(jù)的起點的偏移)。
模塊載入器在一個優(yōu)選實施例中，控制VM負責(zé)載入代碼模塊。當一個代碼模塊被載入時，編碼于pkDS Atom之中的內(nèi)存映像被載入到數(shù)據(jù)段中的一個內(nèi)存地址。該地址是由VM載入器選擇的，并存儲于DS的偽寄存器內(nèi)。編碼于pkCS Atom之中的內(nèi)存映像被載入到代碼段的一個內(nèi)存地址。該地址是由VM載入器選擇，并存儲于代碼段的偽寄存器內(nèi)。
系統(tǒng)調(diào)用控制VM程序可以調(diào)用在其代碼模塊的代碼段以外實現(xiàn)的功能。這是通過使用OP_CALL指令來實現(xiàn)的，該指令帶有一個指定系統(tǒng)調(diào)用號的整數(shù)棧操作數(shù)。根據(jù)該系統(tǒng)調(diào)用，該實現(xiàn)可能是位于另一不同代碼模塊(例如公用圖書館)中的控制VM字節(jié)代碼例程，由VM以VM本地執(zhí)行方式直接執(zhí)行，或者委托給一個外部軟件模塊，例如VM的主機環(huán)境。
在一種實施例中，指定了幾個系統(tǒng)調(diào)用號SYS_NOP＝0這一調(diào)用是非操作調(diào)用，它只是返回(并無操作)，主要用于測試VM。
SYS_DEBUG_PRINT＝1打印出一串文本以便調(diào)試輸出。這一調(diào)用會得到一個單一棧自變量，指定包含所要打印之以零位終止的字符串的內(nèi)存位置的地址。
SYS_FIND_SYSCALL_BY_NAME＝2確定VM是否執(zhí)行一個指定系統(tǒng)調(diào)用。如是的話，將系統(tǒng)調(diào)用號返回到棧上；否則返回數(shù)值-1。這一調(diào)用會得到一個單一棧自變量，指定包含所請求之以零位終止的系統(tǒng)調(diào)用名稱的內(nèi)存位置的地址。
系統(tǒng)調(diào)用號分配在一種優(yōu)選實施例中，控制VM保留0到1023系統(tǒng)調(diào)用號用于強制性系統(tǒng)調(diào)用(VM的所有概要必須執(zhí)行的系統(tǒng)調(diào)用)。
系統(tǒng)調(diào)用號16384到32767可供VM動態(tài)分配(例如由SYS_FIND_SYSCALL_BY_NAME返回的系統(tǒng)調(diào)用號可由VM動態(tài)分配，而且在所有VM實施例中不必都是同樣號碼)。
標準系統(tǒng)調(diào)用在一個優(yōu)選實施例中，提供了幾個標準系統(tǒng)調(diào)用以便于編寫控制程序。這種標準系統(tǒng)調(diào)用可能包括旨在從主機獲得一個時間戳的調(diào)用、確定一個節(jié)點是否可訪問的調(diào)用和/或類似者。系統(tǒng)調(diào)用最好具有動態(tài)確定的號碼(即其系統(tǒng)調(diào)用號可通過調(diào)用系統(tǒng)調(diào)用SYS_FIND_SYSCALL_BY_NAME、并且將其名稱作為傳遞的參數(shù)而獲得)。
鏈接，規(guī)則和內(nèi)容加密下面提供了在DRM引擎和/或系統(tǒng)的優(yōu)選實施例中的元素、群組、規(guī)則、聲明和密鑰管理之間的關(guān)系的其它信息。
鏈接和節(jié)點如前所述，DRM系統(tǒng)可以概念化為具有節(jié)點和鏈接的集合。節(jié)點可以表示不同的實體，但是通常表示實體的群組(一些只有一個身份的組)，并且節(jié)點可以由鏈接相連。一個鏈接可以視為表示一個節(jié)點“屬于”它所鏈接的節(jié)點表示的群組的聲明。
在一個策略的管理下，鏈接通常是由實體而不是用戶和/或DRM引擎創(chuàng)建者建立的聲明。如何建立聲明和管理聲明可以用任何合適的方式進行；但是，鏈接優(yōu)選是可信的。在實踐中，這通常將意味著存在一個鏈接的聲明表示將被簽署，這樣需要基于該鏈接做出決定的部分系統(tǒng)可以以可信模式工作。
由節(jié)點之間存在鏈接表示的關(guān)系是可傳遞的。鏈接可以由節(jié)點圖中的有向邊表示，如果在圖中在Na和Nx之間存在有向路徑，那么可以說節(jié)點Na屬于群組節(jié)點Nx。
下面的段落解釋了如何使用這些節(jié)點圖表示規(guī)則條件，以及如何管理加密密鑰。
規(guī)則和成員關(guān)系條件所述系統(tǒng)可以用來通過規(guī)則管理內(nèi)容，所述規(guī)則以控制程序表示，控制程序確定請求的特定操作(和意向)是否被允許，并且，如果是被允許的，結(jié)果或義務(wù)是什么。在一個優(yōu)選實施例中，規(guī)則是小的控制程序，其采用數(shù)個參數(shù)作為輸入(諸如內(nèi)容身份識別信息、時間/日期、特定計數(shù)器的值、請求操作的元素的ID等)，并且決定是否允許特定的操作發(fā)生。如果允許一個操作發(fā)生，程序還能夠執(zhí)行該規(guī)則聲明的義務(wù)(例如，更新一個計數(shù)器)。在一些實施例中，該程序能夠處理的輸入和輸出的類型可能相當有限。
一條規(guī)則可以表示如下事實一個元素能夠執(zhí)行一個操作的條件是從表示請求操作的元素的節(jié)點到一個目標節(jié)點或一組目標節(jié)點存在一條路徑(或一組路徑)，每條路徑表示一個規(guī)則(例如，表示諸如“如果一個元素是內(nèi)容的訂閱者群組中的一個成員，則它能播放該內(nèi)容”的規(guī)則)。兩個節(jié)點Na和Nb之間的鏈接是聲明Na屬于Nb表示的群組的可信任的聲明。如果在規(guī)則的執(zhí)行點(例如運行規(guī)則程序的地方)可能獲得經(jīng)過圖到達所有要求的目標節(jié)點所需的所有鏈接，那么所述條件被滿足。這個節(jié)點圖有時將被稱為成員關(guān)系圖，該圖中的鏈接稱為。
內(nèi)容加密設(shè)計與所述系統(tǒng)一起工作的適應(yīng)元素將能夠理解和執(zhí)行合適的規(guī)則，當它們想要對受保護的內(nèi)容片斷執(zhí)行操作時。但是，通常不能信任非適應(yīng)系統(tǒng)以這種方式使用內(nèi)容。因而，希望通過使用加密技術(shù)保護內(nèi)容。在一個優(yōu)選實施例中，利用內(nèi)容密鑰Kc加密內(nèi)容，通常對于要保護的內(nèi)容內(nèi)容密鑰是唯一的。當一個元素想要對內(nèi)容執(zhí)行操作，它將首先運行規(guī)則程序，得到答案是/否。如果規(guī)則允許該元素執(zhí)行該操作，該要素將需要獲取內(nèi)容密鑰Kc。在一個優(yōu)選實施例中，在規(guī)則系統(tǒng)、節(jié)點/鏈接圖和內(nèi)容保護系統(tǒng)(能夠使該要素以有效方式獲得密鑰，而不需要外部實體“顯式”地將Kc發(fā)送給請求節(jié)點)之間存在關(guān)系。
在有個優(yōu)選實施例中，這是通過概念化作為圖中節(jié)點的元素/對象之間的關(guān)系實現(xiàn)的。一些節(jié)點可以同成員關(guān)系圖中使用的節(jié)點相同，但這不是必要的。但是，在簡單系統(tǒng)中，期望這個圖是成員關(guān)系圖的一個子集。這個圖將被稱為保護圖。
系統(tǒng)中的每個節(jié)點N除了其它屬性，可以具有一個關(guān)于內(nèi)容保護密鑰Kc[N]或密鑰對的屬性。其它屬性可能包括用于簽名的公共/私有密鑰對和該節(jié)點的潛在目標信息。為了說明起見，下面的例子顯示使用單個密鑰，但是應(yīng)該理解相同元素也可以使用密鑰對。在這個圖中，兩個節(jié)點Na和Nb之間的鏈接是可信聲明，其聲明具有Kc[Na]的任何節(jié)點可以計算Kc[Nb]。通常，這意味著該鏈接將包含用Kc[Na]加密的Kc[Nb]的表示。這允許追蹤節(jié)點之間的鏈接和計算目標節(jié)點的Kc。
用于創(chuàng)建到密鑰的路徑的圖和用于表示成員關(guān)系條件的圖可以不相同，但是在簡單的例子中，可以重用相同的圖和鏈接，從而創(chuàng)建節(jié)點圖的“平行”或可替換的使用現(xiàn)在經(jīng)過為檢驗規(guī)則條件而經(jīng)過的相同路徑來計算內(nèi)容包含密鑰。有權(quán)訪問能夠跟隨它到達節(jié)點Nb的鏈接的任何節(jié)點Na能夠計算Kc[Nb]，即使沒有顯式地將Kc[Nb]定位為Na的目標。
通常可以以如下方式使用這些密鑰利用內(nèi)容密鑰K[Ci]加密內(nèi)容Ci?？梢詣?chuàng)建一個或多個規(guī)則，該規(guī)則能夠除了其它之外能夠檢驗在請求操作的節(jié)點和表示群組的一列“條件”目標節(jié)點之間存在路徑。該規(guī)則可以包括能夠執(zhí)行對條件(可能還包括義務(wù)方面)的檢驗的程序，以及包括受保護的K[Ci]的拷貝，對K[Ci]的保護是通過利用請求節(jié)點必需屬于的節(jié)點的Kc[Ni]節(jié)點內(nèi)容加密密鑰的每一個進行連續(xù)加密而實現(xiàn)的。
當一個節(jié)點Na想要對內(nèi)容Ci執(zhí)行一個操作時，它將運行管理該內(nèi)容的規(guī)則程序。如果該規(guī)則要求Na在一個或多個群組Np、Nq等中的成員關(guān)系，它將檢驗到Np、Nq等的必要鏈接是否存在，并且決定是否允許該操作。如果允許該操作，該系統(tǒng)將確定在保護圖中它是否具有到節(jié)點Nm、Nn等(其內(nèi)容保護密鑰Kc[Nm]和Kc[Nn]等在獲取內(nèi)容密鑰K[Ci]的過程中需要使用，在規(guī)則中能夠發(fā)現(xiàn)內(nèi)容密鑰K[Ci]的加密拷貝)的一組鏈接。通過按照由保護元數(shù)據(jù)為該內(nèi)容密鑰指定的順序，利用所述節(jié)點的內(nèi)容加密密鑰Kc[Nm]和Kc[Nn]等解密這個加密的內(nèi)容密鑰，將獲得K[Ci]。又，在簡單系統(tǒng)中，節(jié)點Np、Nq的集合通常和Nm、Nn的集合相同。
圖7示出了說明節(jié)點圖的雙重使用的示例場景。參看圖7，iPOD是內(nèi)容播放設(shè)備。Nip1是表示該設(shè)備的節(jié)點。Kip1是與Nip1相關(guān)聯(lián)的內(nèi)容加密密鑰。Gilles是iPod1的所有者，Ng是代表Gilles的節(jié)點。Kg是與Ng相關(guān)的內(nèi)容加密密鑰。
PubLib是一個公共圖書館。Np1代表該圖書館的成員，Kp1是與Np1相關(guān)聯(lián)的內(nèi)容加密密鑰。ACME代表所有ACME制造的音樂播放器。Namp代表設(shè)備的類別，Kamp是與此組相關(guān)聯(lián)的內(nèi)容加密密鑰。
L1是一個從Nip1到Ng的鏈接，意味著iPod1屬于Gilles。L2是一個從Ng到Np1的鏈接，意味著Gilles是公共圖書館的成員。L3是一個從Nip1到Namp的鏈接，意味著iPod1是一臺ACME設(shè)備。
C1是一個由公共圖書館供其成員使用的電影文件。Kc1是一個用以為C1加密的密鑰。GB[C1]是C1的管理信息(例如，用于管理對該內(nèi)容的訪問的規(guī)則和相關(guān)信息)。E(a，b)表示用密鑰“a”來加密“b”。
為說明起見，假定需要制定一條規(guī)則，使設(shè)備只要滿足下列條件即可播放內(nèi)容C1(a)該設(shè)備的擁有者是圖書館的成員，而且(b)該設(shè)備是由ACME制造的。
內(nèi)容C1是用Kc1來加密的。創(chuàng)建規(guī)則程序以及加密的內(nèi)容密鑰RK[C1]＝E(Kamp，E(Kp1，Kc1))。規(guī)則程序和RK[C1]都可以納入該內(nèi)容的管理模塊GB[C1]。
iPod1接收C1和GB[C1]。例如，此二者均可打包在同一文件中，或分別接收。iPod1在Gilles購買后首次安裝設(shè)備時即接收L1。在Gilles向公共圖書館支付收視費時iPod1即接收L2。iPod1在制造時接收L3(例如L3是內(nèi)置的)。
iPod1從L1、L2和L3可以檢查出Nip1有一條通向Ng(L1)、Np1(L1+L2)和Namp(L3)的圖路徑。iPod1打算播放C1。iPod1運行從GB[C1]中找到的規(guī)則。該規(guī)則可以檢查Nip1是否確實是一ACME設(shè)備(到Namp的路徑)，并屬于公共圖書館的成員(至Np1的路徑)。因此，規(guī)則返回“是”，以及所定列表(Namp、Np1)。
iPod1用L1計算出Kg，然后用L2從Kg計算出Kp1。iPod1還使用L3計算出Kamp。iPod1將Kp1和Kamp應(yīng)用于GB[C1]中找到的RK[C1]并計算出Kc1，然后用Kc1來解密并播放C1。
如同上例所示，當節(jié)點密鑰是對稱密鑰時，內(nèi)容打包者需要有權(quán)訪問它想要將內(nèi)容“綁定”于其上的節(jié)點的密鑰。要實現(xiàn)這一點，可創(chuàng)建一個代表打包者的節(jié)點，以及連接該節(jié)點與它要將規(guī)則綁定于其上的節(jié)點之間的鏈接。例如，這一點亦可通過一項服務(wù)“帶外”實現(xiàn)。但在某些情況下，采用對稱密鑰不可能，也不實際。這種情況下，可以向需要綁定的節(jié)點分配一個密鑰對而無需共享知識。此時，打包者可使用目標節(jié)點的公共密鑰將內(nèi)容密鑰加密，從而把內(nèi)容密鑰綁定到這個節(jié)點。欲獲得解密密鑰，客戶端須有權(quán)通過到該節(jié)點的鏈接訪問節(jié)點的私有密鑰。
在最一般的情況下，用于規(guī)則的節(jié)點和用于計算內(nèi)容加密密鑰的節(jié)點不必是同一個。使用相同節(jié)點是很自然的，因為管理內(nèi)容的規(guī)則和用來加密內(nèi)容的密鑰之間關(guān)系密切，但使用相同節(jié)點不是必需的。在一些系統(tǒng)中，若干節(jié)點可用于內(nèi)容保護密鑰，但不用于表示成員關(guān)系條件，或正相反，并且在某些情況下，可以使用兩個不同的節(jié)點圖，一個用于規(guī)則，另一個用于內(nèi)容保護。例如，一條規(guī)則可能說所有Np1組的成員均可訪問內(nèi)容C1，但是內(nèi)容密鑰Kc1可能不受Kp1保護，卻受代表所有公共圖書館、不單是Np1的節(jié)點Nf的節(jié)點密鑰Kf保護。或者一條規(guī)則可能說你必須是Namp的成員，然而內(nèi)容加密密鑰卻只綁定到Np1。
盡管為了說明起見前面描述了一些細節(jié)，應(yīng)理解在不偏離本發(fā)明的原則的情況下可以進行某些變化和修改。應(yīng)注意到，存在很多實現(xiàn)本發(fā)明的過程和設(shè)備的替代措施。因此，本發(fā)明的實施例被認為是說明性的，而不是限制性的，并且本發(fā)明并不局限于這里給出的特定細節(jié)。
媒體驅(qū)動框架的示范實施例圖1(附件B的部分)
媒體驅(qū)動節(jié)點的概念視2(附件B的部分)
一般交互模式示例圖3(附件B的部分)
服務(wù)適配層圖4(附件B的部分)
服務(wù)代理-客戶端MSDL交互模式圖5a 服務(wù)代理-客戶端本地交互模式圖5b(附件B的部分)
服務(wù)代理-服務(wù)端-中間點交互模式圖6(附件B的部分)
媒體驅(qū)動工作流整理器的交互模式圖7(附件B的部分)
附錄C服務(wù)定義和概要模式定義









































為清晰起見而在前述部分做了詳細說明，但顯而易見，在隨附權(quán)利要求范圍內(nèi)可能實施某些更改和修正。須注意的是，本發(fā)明的過程和設(shè)備的實現(xiàn)可有許多不同的方法。因此，現(xiàn)有實施例應(yīng)被視為說明性的而非限制性的，而且發(fā)明的有效主體不應(yīng)局限于此處所給的細節(jié)，而是可以在隨附權(quán)利要求的等同范圍內(nèi)加以修訂
權(quán)利要求
1.一種用于編排由具有充分可互操作性的網(wǎng)絡(luò)對等方提供的服務(wù)以便能夠通過參與分布式應(yīng)用交換價值的系統(tǒng)，系統(tǒng)組成部分如下a.具有第一服務(wù)適配層的第一服務(wù)提供者，所述第一服務(wù)適配層公開第一服務(wù)接口，該接口使網(wǎng)絡(luò)對等方能夠通過第一可發(fā)現(xiàn)服務(wù)綁定，訪問由第一服務(wù)提供者所提供的第一服務(wù)；b.具有第一服務(wù)接入點的第一服務(wù)用戶，訪問由第一服務(wù)提供者所公開的第一服務(wù)接口，發(fā)現(xiàn)第一綁定并使用該綁定調(diào)用第一服務(wù)；及c.第一工作流整理器，編排必要的步驟使第一服務(wù)提供者能夠為第一服務(wù)用戶執(zhí)行第一服務(wù)。
2.權(quán)利要求1中的系統(tǒng)，其中第一服務(wù)提供對位于遠程的基于Internet服務(wù)器中的加密媒體內(nèi)容的限制訪問，第一工作流整理器包含確認第一服務(wù)用戶是否有權(quán)訪問該內(nèi)容的第一控制程序，若有權(quán)，則通過第一服務(wù)適配層找到內(nèi)容并提供給第一服務(wù)用戶。
3.權(quán)利要求1中的系統(tǒng)，其中第一服務(wù)接口是采用WSDL規(guī)定的。
4.一種用于編排由網(wǎng)絡(luò)對等方提供的服務(wù)的系統(tǒng)，該系統(tǒng)包括a.具有第一服務(wù)適配層的第一服務(wù)提供者，該第一服務(wù)適配層公開第一服務(wù)接口，該接口使網(wǎng)絡(luò)對等方能夠通過第一可發(fā)現(xiàn)服務(wù)綁定，訪問由第一服務(wù)提供者所提供的第一服務(wù)；b.具有第一服務(wù)接入點的第一服務(wù)用戶，訪問由第一服務(wù)提供者所公開的第一服務(wù)接口，發(fā)現(xiàn)第一綁定并使用該綁定調(diào)用第一服務(wù)；c.第一工作流整理器，其編排必要的步驟使第一服務(wù)提供者能夠為第一服務(wù)用戶執(zhí)行第一服務(wù)；及d.具有第二服務(wù)適配層的第二服務(wù)提供者，公開第二服務(wù)接口，使網(wǎng)絡(luò)對等方能夠通過第二可發(fā)現(xiàn)服務(wù)綁定訪問由第二服務(wù)提供者所提供的第二服務(wù)，該第二服務(wù)提供對服務(wù)注冊中心的訪問，其中有一目錄項包含用以查找和訪問第一服務(wù)的信息，其中第一服務(wù)接入點訪問該目錄項并使用該信息查找并調(diào)用第一服務(wù)。
5.權(quán)利要求4中的系統(tǒng)，其中服務(wù)注冊中心是一個UDDI注冊中心。
6.一個系統(tǒng)，包括a.具有第一服務(wù)適配層的第一服務(wù)提供者，該服務(wù)適配層公開第一服務(wù)接口，該接口使網(wǎng)絡(luò)對等方能夠通過第一可發(fā)現(xiàn)服務(wù)綁定，訪問由第一服務(wù)提供者所提供的第一服務(wù)；b.具有第一服務(wù)接入點的第一服務(wù)用戶，訪問由第一服務(wù)提供者所公開的第一服務(wù)接口，發(fā)現(xiàn)第一綁定并使用該綁定而調(diào)用第一服務(wù)；c.第一工作流整理器，編排必要的步驟使第一服務(wù)提供者能夠為第一服務(wù)用戶執(zhí)行第一服務(wù)；d.一個信任管理證書，用于確認第一服務(wù)只能由授權(quán)的服務(wù)使用者訪問；及e.一個控制程序，使用信任管理證書提供對第一服務(wù)的限制性訪問，其中第一接入點使用信任管理證書確證第一服務(wù)用戶有權(quán)訪問第一服務(wù)。
7.權(quán)利要求6中的系統(tǒng)，其中信任管理證書是一個X.509證書。
8.權(quán)利要求6中的系統(tǒng)，其中信任管理證書是一個SSL證書。
9.一種用于編排由具有充分可互操作性的網(wǎng)絡(luò)對等方提供的服務(wù)以便能夠通過參與分布式應(yīng)用交換價值的方法，該方法包括以下步驟a.公開，從第一服務(wù)提供者的第一服務(wù)適配層公開第一服務(wù)接口，該接口使網(wǎng)絡(luò)對等方能夠通過第一可發(fā)現(xiàn)服務(wù)綁定訪問由第一服務(wù)提供者所提供的第一服務(wù)；b.訪問，從一服務(wù)用戶的第一服務(wù)接入點訪問由第一服務(wù)提供者所公開的第一服務(wù)接口，發(fā)現(xiàn)第一綁定并使用該綁定調(diào)用第一服務(wù)；及c.編排，使用第一工作流整理器編排必要的步驟使第一服務(wù)提供者能夠為第一服務(wù)用戶執(zhí)行第一服務(wù)。
10.權(quán)利要求9中的方法，其中第一服務(wù)提供對位于遠程的基于Internet的服務(wù)器中的加密媒體內(nèi)容的限制訪問，第一工作流整理器包含確認第一服務(wù)用戶是否有權(quán)訪問該內(nèi)容的第一控制程序，若有權(quán)，則通過第一服務(wù)適配層找到該內(nèi)容并提供給第一服務(wù)用戶。
11.權(quán)利要求9中的方法，其中第一服務(wù)接口是采用WSDL規(guī)定的。
12.一種編排服務(wù)的方法，包括以下步驟a.公開，從第一服務(wù)提供者的第一服務(wù)適配層公開第一服務(wù)接口，該接口使網(wǎng)絡(luò)對等方能夠通過第一可發(fā)現(xiàn)服務(wù)綁定訪問由第一服務(wù)提供者所提供的第一服務(wù)；b.訪問，從一服務(wù)用戶的第一服務(wù)接入點訪問由第一服務(wù)提供者所公開的第一服務(wù)接口，發(fā)現(xiàn)第一綁定并使用該綁定調(diào)用第一服務(wù)；c.編排，使用第一工作流整理器編排必要的步驟以使第一服務(wù)提供者能夠為第一服務(wù)用戶執(zhí)行第一服務(wù)；及d.公開，從第二服務(wù)提供者的第二服務(wù)適配層公開第二服務(wù)接口，該接口使網(wǎng)絡(luò)對等方能夠通過第二可發(fā)現(xiàn)服務(wù)綁定訪問由第二服務(wù)提供者所提供的第二服務(wù)，第二服務(wù)提供對服務(wù)注冊中心的訪問，注冊中心中有一目錄項包含用以查找和訪問第一服務(wù)的信息，其中第一服務(wù)接入點訪問所述目錄項并使用該信息查找并調(diào)用第一服務(wù)。
13.權(quán)利要求12中的方法，其中服務(wù)注冊中心是一個UDDI注冊中心。
14.一種方法，包括以下步驟a.公開，從第一服務(wù)提供者的第一服務(wù)適配層公開第一服務(wù)接口，該接口使網(wǎng)絡(luò)對等方能夠通過第一可發(fā)現(xiàn)服務(wù)綁定，訪問由第一服務(wù)提供者所提供的第一服務(wù)；b.訪問，從一服務(wù)用戶的第一服務(wù)接入點訪問由第一服務(wù)提供者所公開的第一服務(wù)接口，發(fā)現(xiàn)第一綁定并使用該綁定調(diào)用第一服務(wù)；c.編排，使用第一工作流整理器編排必要的步驟以使第一服務(wù)提供者能夠為第一服務(wù)用戶執(zhí)行第一服務(wù)；d.使用信任管理證書確認第一服務(wù)，只能由被授權(quán)的服務(wù)用戶訪問；及e.執(zhí)行一個控制程序，以便使用信任管理證書對第一服務(wù)提供限制性訪問，其中第一接入點使用信任管理證書驗證第一服務(wù)用戶有權(quán)訪問第一服務(wù)。
15.權(quán)利要求14中的方法，其中信任管理證書是一個X.509證書。
16.權(quán)利要求14中的方法，其中信任管理證書是一個SSL證書。
17.一種編排服務(wù)的方法，包括以下步驟a.從一服務(wù)用戶的第一服務(wù)接入點訪問由第一服務(wù)提供者所公開的第一服務(wù)接口，第一服務(wù)接口可用來使網(wǎng)絡(luò)對等方能夠通過第一可發(fā)現(xiàn)服務(wù)綁定，訪問由第一服務(wù)提供者所提供的第一服務(wù)；b.發(fā)現(xiàn)第一可發(fā)現(xiàn)綁定；及c.通過使用該綁定而調(diào)用第一服務(wù)，其中，使用第一工作流整理器編排執(zhí)行第一服務(wù)所必需的步驟。
18.權(quán)利要求17中的方法，其中第一服務(wù)提供對位于遠程的基于Internet的服務(wù)器中的加密媒體內(nèi)容的限制訪問，第一工作流整理器包含確認第一服務(wù)用戶是否有權(quán)訪問該內(nèi)容的第一控制程序，若有權(quán)，則找到該內(nèi)容并通過第一服務(wù)適配層提供給第一服務(wù)用戶。
19.一種方法，包括以下步驟a.從第一服務(wù)提供者的第一服務(wù)適配層公開第一服務(wù)接口，該接口使網(wǎng)絡(luò)對等方能夠通過第一可發(fā)現(xiàn)服務(wù)綁定訪問由第一服務(wù)提供者所提供的第一服務(wù)；b.從第一服務(wù)用戶的第一服務(wù)接入點接收第一服務(wù)請求；及c.使用第一工作流整理器編排必要的步驟以使第一服務(wù)提供者能夠為第一服務(wù)用戶執(zhí)行第一服務(wù)。
20.一種方法，包括以下步驟a.從第一服務(wù)提供者的第一服務(wù)適配層公開第一服務(wù)接口，該接口使網(wǎng)絡(luò)對等方能夠通過第一可發(fā)現(xiàn)服務(wù)綁定訪問由第一服務(wù)提供者所提供的第一服務(wù)；b.從第一服務(wù)用戶的第一服務(wù)接入點接收第一服務(wù)請求；c.使用一個信任管理證書確認第一服務(wù)只能由被授權(quán)的服務(wù)用戶訪問；d.執(zhí)行一個控制程序，以便使用信任管理證書對第一服務(wù)提供限制性訪問；及e.使用第一工作流整理器編排必要的步驟以使第一服務(wù)提供者能夠為第一服務(wù)用戶執(zhí)行第一服務(wù)。
全文摘要
本說明書描述用于以某種方式執(zhí)行由策略管理的對等服務(wù)編排的系統(tǒng)和方法，采用這種方式，可以支持構(gòu)建能夠帶給用戶豐富媒體體驗的自組織服務(wù)網(wǎng)絡(luò)。在一個實施例中，服務(wù)分布在多個對等通信節(jié)點上，每個節(jié)點都利用消息泵和工作流整理器來提供消息路由和消息編排。服務(wù)接口的分布式策略管理有助于提供信任和安全，從而支持商業(yè)價值交換。通過對等消息傳遞和工作流整理，可以從一組異類原語服務(wù)動態(tài)創(chuàng)建服務(wù)。共享資源是一些不同類型的服務(wù)，它們使用不同于基于UDDI、SOAP和WSDL的Web服務(wù)部署中通常支持的那些服務(wù)接口綁定。在一個優(yōu)選實施例中，提供了一種媒體服務(wù)框架，它支持節(jié)點在從WAN到PAN的網(wǎng)絡(luò)層之間相互查找、交互、交換價值和協(xié)作。
文檔編號G06F21/00GK1860761SQ200480021795
公開日2006年11月8日 申請日期2004年6月7日 優(yōu)先權(quán)日2003年6月5日
發(fā)明者W·B·布拉德利, D·P·馬赫爾, G·博坎－吉布 申請人:英特特拉斯特技術(shù)公司