專利名稱：建立用于發(fā)送文件的路由的方法
建立用于發(fā)送文件的路由的方法本案是申請日為2003年7月10日、申請?zhí)枮?3821615. 9、發(fā)明名稱為“電子商務 社區(qū)網(wǎng)絡和社區(qū)內(nèi)/間安全路由實現(xiàn)”的發(fā)明專利申請的分案申請。版權聲明本專利文獻的一部分公開包含受版權保護的資料。版權擁有者不反對任何人以它 出現(xiàn)在專利和商標局專利文獻或記錄中那樣對該專利文獻或該專利公開進行傳真復制，但 是在其他方面是保留全部版權的。
背景技術：
本發(fā)明涉及一種系統(tǒng)和協(xié)議，該系統(tǒng)和協(xié)議支持社區(qū)(community)的參加者之間 以及加入到社區(qū)網(wǎng)絡中的社區(qū)的參加者之間的電子商務文檔的通信。具體地說，它涉及一 種系統(tǒng)和協(xié)議，該系統(tǒng)和協(xié)議用于在參加者之間路由電子商務文檔以及用于確保沿該路由 的傳輸。事務對事務(business-to-business, B2B)禾口應用對應用 (application-to-application,A2A)電子商務正在代替電子數(shù)據(jù)交換(EDI)的以前協(xié)議。 由于事務努力改善它們關于B2B和A2A系統(tǒng)的效率，出現(xiàn)了大量不兼容的平臺和競爭的標 準。在兼容的標準中，存在著有待填補的不兼容。例如，工業(yè)上已經(jīng)定義了簡單Web服務是 什么。涉及簡單Web服務的標準包含UDDI、WSDL、XSDL和S0AP。然而，這些標準并非完全 地意味著實際B2B和A2A電子商務的安全性、可靠性、易管理性以及靈活性(choreography) 要求?；谔幚砹?process flow)的會話和合作web服務構成具有合作和復雜web服務 的組成部分，它們不是任何綜合性的或統(tǒng)一的標準的主體。大量工業(yè)倡導者倡導對可應用于B2B和A2A電子商務的標準進行擴展。 choreography 努力成果包含 OASIS 的 ebXML/BPSS、IBM 的 WSFL 和 Microsoft 的 XLANG。會 話努力成果包含OASIS的ebXML/TRP和Microsoft的WS-routing。主導的安全性努力成 果是IBM和Microsoft的WS-security，還有OASIS的稱為SAML補充安全性努力成果。對 于可靠性，有Microsoft的建議、OASIS的ebXML/TRP和IBM的HTTPR。W3C正在解決所有 這些領域中的標準化問題。關鍵的工業(yè)參與者已經(jīng)形成了稱為WSI的競爭集團。沒有處理 流的真正標準，盡管有很多處理流的專用實現(xiàn)(propietaryimplementation)。對于易管理 性，中心地定義信息可能有用，該信息通過規(guī)定在電子商務中涉及的策略和實體的能力，授 權web服務的互操作性。中心定義(central definition)的一個工業(yè)標準是ebXML CPP/ CPA合同定義，它是由OASIS公布的。因此，有機會設計用于包含、統(tǒng)一以及填補很多相關Web服務標準之間的不兼容 的方法和結構，這些相關Web服務標準包含S0AP、UDDI、ebXML、WSDL、WS-security、SAML和 XSDL?？傊藢Χ朔找约皩嶓w之間電子商務文檔的安全傳遞能力是有用的。

發(fā)明內(nèi)容
本發(fā)明包含一種設備和方法，用于建立社區(qū)網(wǎng)絡、在具有互異接口的社區(qū)之間路 由文檔，并且以被信(trusted)和可信(trustworthy)方式來進行。本發(fā)明的具體方面在權利要求書、說明書和附圖中描述。


圖1描述屬于幾個社區(qū)的幾個實體。圖2描述具有可選(alternate)通信信道的實體或連接器。圖3描述用作在使用相似通信信道的兩個連接器之間的集線器的連接器。圖4和5描述社區(qū)網(wǎng)絡中社區(qū)之間、跨越社區(qū)邊界的通信。圖6描述中間社區(qū)、通信鏈。圖7描述使用中間社區(qū)進行翻譯服務。圖8是支持社區(qū)內(nèi)路由的電子注冊數(shù)據(jù)的方框圖。圖9是更詳細的電子注冊圖。圖10是支持社區(qū)間路由的電子注冊數(shù)據(jù)的方框圖。圖11和12示出了可以編譯路由的XML格式。圖13和14是社區(qū)內(nèi)路由和社區(qū)間路由的高層示意圖。圖15描述社區(qū)內(nèi)的安全性實現(xiàn)。圖16描述社區(qū)間的安全性實現(xiàn)。圖17描述授權(delegation)安全性服務。圖18A和18B示出了將驗證(anthentication)授權于網(wǎng)關。在圖19A和19B中， 將MML和SAML安全協(xié)議之間的轉換擴展到社區(qū)之間的通信。圖20到圖25中呈現(xiàn)附加安全性使用的情況。圖20是方框圖(修改頁)(91條)。 圖21示出了使用圖20中的設計進行注冊服務本地驗證。圖22中示出了該使用情況的變 化，用于注冊服務遠程驗證。圖23和24示出了本地和遠程驗證。圖25示出了獲取文檔服 務預訂的屬性斷言(assertion)。圖26和27描述社區(qū)網(wǎng)絡的建立。
具體實施例方式以下參照附圖進行詳細說明。描述優(yōu)選實施例是為了說明本發(fā)明，而不是為了限 制其范圍，本發(fā)明的范圍由權利要求書限定。本領域技術人員將意識到關于描述的各種等 效變化。圖1示出了社區(qū)和社區(qū)網(wǎng)絡。在這些社區(qū)中，社區(qū)保持本地注冊，該本地注冊包含 如用戶、公司、服務以及連接器等信息，其中連接器是社區(qū)的一部分。社區(qū)能夠是市場、企業(yè) 或子企業(yè)。社區(qū)能夠屬于一個或多個社區(qū)網(wǎng)絡。一般地，社區(qū)和網(wǎng)絡具有一些共同的商業(yè) 興趣。在一個或多個社區(qū)網(wǎng)絡的成員社區(qū)之間具有互操作性。網(wǎng)絡包含黃金市場網(wǎng)絡1、貴 金屬市場網(wǎng)絡2、私人網(wǎng)絡3和全球貿(mào)易web網(wǎng)絡4。在該示例中，黃金市場網(wǎng)絡1和貴金 屬市場網(wǎng)絡2包含在全球貿(mào)易web網(wǎng)絡4中。貴金屬市場網(wǎng)絡2包含黃金和白銀市場14、 13。黃金市場消費者能夠在白銀市場13中進行白銀交易，而白銀市場消費者能夠在黃金市 場14中進行交易。一個社區(qū)，即PQR企業(yè)17，屬于黃金市場網(wǎng)絡1、私人網(wǎng)絡3和全球貿(mào)易 web網(wǎng)絡4;另一個社區(qū)，即ABC大提供商18，屬于私人網(wǎng)絡3。在該示例中，XYZ黃金市場 14是交易黃金的市場或社區(qū)。企業(yè)屬于該社區(qū)。諸如自身形成社區(qū)的PQR企業(yè)17之類的企業(yè)屬于黃金市場網(wǎng)絡1。這些社區(qū)是黃金市場網(wǎng)絡1和全球貿(mào)易web網(wǎng)絡4的一部分。 小提供商15是黃金市場社區(qū)的一部分。其他企業(yè)16是社區(qū)，這些社區(qū)是黃金市場社區(qū)網(wǎng) 絡1的一部分。XYZ黃金市場14和其他黃金市場實體15-17之間的連接表明黃金市場需要 企業(yè)(社區(qū)或其他)之間的所有通信，以便例如收集帳單和商業(yè)情報信息，這些企業(yè)處理將 要通過XYZ黃金市場14路由的黃金交易。PQR企業(yè)17是一社區(qū)，該社區(qū)是黃金市場的一部 分，并且還是包含提供商18的本地私人網(wǎng)絡的一部分。小提供商15可以是單獨的小提供 商，它們自身不需要形成社區(qū)，而是在黃金市場的注冊中注冊其例如用戶、組織、服務和變 換的元數(shù)據(jù)。另一方面，ABC大提供商18形成了它自身的私人網(wǎng)絡，例如，因為它希望相對 于普通公眾訪問而使元數(shù)據(jù)、內(nèi)部事務部門系統(tǒng)和變換保持隱藏，因為它們是以相當高的 成本開發(fā)出來的。因為PRQ17是ABC18的消費者，它加入私人網(wǎng)絡3中。金融服務提供商 DEF金融12想要給全球貿(mào)易web網(wǎng)絡4中的任何一個提供金融服務，這就形成了它自身的 社區(qū)，并且以全球貿(mào)易web根11注冊。社區(qū)網(wǎng)絡提供了社區(qū)的全球注冊。全球注冊允許查 找社區(qū)和確定到該社區(qū)或到外部連接器的一個或多個路由，可以通過外部連接器來路由前 往該社區(qū)的電子商務文檔。從一個社區(qū)路由到另一個社區(qū)的文檔，可以直接在兩個社區(qū)的 外部連接器之間路由，或通過一個或多個中間社區(qū)來非直接地路由。還能夠定義并且在社 區(qū)注冊中保持涉及社區(qū)的交易的商務和安全性規(guī)則。一般地，圖1示出了實體和社區(qū)的混 合成員(loyalty)，它創(chuàng)造了電子商務平臺間的互操作性的推動力。連接器是與其他應用程序通信的應用程序的通用術語。連接器可以通過充當集 線器、網(wǎng)關、外部端口、中央連接器等的其他連接器、基于定向進行通信或者基于對等(P2P) 進行通信?；赑2P通信的連接器能夠與使用相同傳輸/封裝(envelope)協(xié)議的其他連接 器通信?；赑2P通信的連接器可選地可以借助于執(zhí)行交易服務的其他集線器連接器，當 試圖與不使用相同的傳輸/封裝協(xié)議的連接器通信時，基于定向通信的連接器根據(jù)路由規(guī) 則、通過集線器連接器通信。連接器間的路由規(guī)則能夠映射在定向圖中，支持一個或多個傳 輸/封裝協(xié)議的一個或多個集線器和輪輻拓撲(spoke topology)。在一個或多個層(tier) 中，集線器和輪輻拓撲將通信以輪輻形式導向集線器。這便利于集中服務，例如帳單、商務 情報收集、跟蹤、審計、記帳或其他。多個集線器和輪輻機構可以覆蓋相同的連接器，來支持 不同的傳輸/封裝協(xié)議和技術，如圖2所示。例如，可以需要更強健的集線器和輪輻機構來 使用Sonic作為傳輸技術，而不使用HTTP或HTTPS?？蛇x地，可以根據(jù)源和目的地是否是相 同社區(qū)的一部分來進行通信路由。在子社區(qū)(它可以包含整個社區(qū))之內(nèi)，可能不需要集 中功能，并且允許在連接器間進行P2P通信，然而，當與其他子社區(qū)中的目的地通信時，引 導這些連接器與父連接器進行通信。連接器可以分為簡單連接器(有時簡單地稱為連接器)、集線器(有時稱為網(wǎng)關或 路由器)或者中心連接器?？商鎿Q地，它們可以被以功能性進行描述。簡單連接器用于經(jīng) 由集線器連接器通信，當允許它們在相同子社區(qū)的連接器間進行P2P通信時除外。所謂的 集線器由明確地指向或連接到它們的連接器使用。集線器可以提供多種功能，因此可以在 從源到目的地的路由中出現(xiàn)超過一次。集線器轉發(fā)電子商務文檔或消息。集線器還可以在 支持公共封裝協(xié)議的傳輸協(xié)議之間進行翻譯。例如，集線器可以翻譯封裝協(xié)議，并且當傳輸 時而不是接收時，還可以實現(xiàn)不同的傳輸協(xié)議。中心連接器是集線器的特殊情況，它們能夠 由沒有明確地指向或連接到它們的連接器使用。中心連接器是有用的，例如，當根據(jù)路由規(guī)則從源開始經(jīng)過連接器不會通向支持由目的地使用的傳輸/封裝協(xié)議的任何集線器時，中 心連接器用于執(zhí)行翻譯功能。圖2示出了三個連接器簡單連接器201和一對集線器202-203，它們中的一個已 被稱為網(wǎng)關203。連接器201受路由規(guī)則約束，當傳輸/封裝協(xié)議是SOAP/HTTP 204時，將 通信導向集線器202，而當使用MML/Sonic 205時，將通信導向集線器203。實際上，子201 具有兩個父202-203。相關的父依賴于所使用的通信協(xié)議204-205。所示出的對于通信協(xié) 議的定向路由的覆蓋還可以由傳輸安全性協(xié)議進一步覆蓋，使得通過父的路由依賴于傳輸 /封裝/傳輸安全性協(xié)議三者組成的一組?？商鎿Q地，正如本文所使用，傳輸/封裝協(xié)議可 以指支持封裝和傳輸兩者的簡單的統(tǒng)一協(xié)議。當前，傳輸和封裝協(xié)議是不同的，但是使用術 語傳輸/封裝協(xié)議旨在包含將來的任何統(tǒng)一協(xié)議。圖3-7示出了源A和目的地B的不同關系。在圖3中，源301和目的地302處于相 同的社區(qū)中。它們兩者都通過路由規(guī)則指向集線器303，該路由規(guī)則通過MML/Sonic 304、 305將通信導向集線器303。在圖4中，源401和目的地402處于由社區(qū)邊界403分隔開的 不同社區(qū)中。當使用S0AP/HTTPS協(xié)議406、407時，源和目的地都分別指向通過集線器404 和405的通信。因為社區(qū)之間的通信經(jīng)由外部連接器，所以該示例中的集線器還是注冊為 可訪問其他社區(qū)的外部連接器。在圖5中，源501和目的地502再次被社區(qū)邊界503分隔 開來。源501經(jīng)由ebXML/HTTPS協(xié)議507與集線器504通信。可以將集線器505、506看作 集線器504和連接器502沒有明確地指向或連接到的中心連接器。假設該目的地502使用 MML/HTTPS協(xié)議。集線器504沒有翻譯能力，但是集線器505、506有翻譯能力。集線器的公 共協(xié)議是SOAP/某傳輸協(xié)議。各集線器將ebXML/HTTPS翻譯成SOAP/某傳輸協(xié)議(505)，并 且將MML/HTTPS翻譯成相同的S0AP/某傳輸協(xié)議(506)。如果集線器執(zhí)行兩種翻譯功能，則 它們可以在從源到目的地的該路由中出現(xiàn)兩次。正如所示，集線器505、506還是外部連接 器，因為它們穿過社區(qū)邊界503進行通信。如果沒有社區(qū)邊界503，則集線器就不是外部連 接器。在圖6-7中，引入中間社區(qū)來提供服務。這些服務是網(wǎng)關和商務情報數(shù)據(jù)收集。中 間社區(qū)一般是市場，這些市場使用各種協(xié)議、通過網(wǎng)關、提供到企業(yè)的連接。它們還能夠充 當企業(yè)的被信中介，以便彼此交互。它們還能夠給它們的消費者提供商務情報數(shù)據(jù)。在圖6 中，服務橋接網(wǎng)絡中的兩個社區(qū)。如下的實現(xiàn)是有可能的，即該實現(xiàn)支持屬于多個網(wǎng)絡的中 介，并且充當允許橋接的兩個網(wǎng)絡的成員的網(wǎng)絡之間的橋接器。例如，在圖6中，源和目的 地社區(qū)601和602可以不屬于相同的社區(qū)網(wǎng)絡。假設社區(qū)603屬于與源601共同的一個社 區(qū)網(wǎng)絡，以及屬于與目的地602共同的另一個社區(qū)網(wǎng)絡，則社區(qū)603能夠在源和目的地的通 信中充當被信中介。在圖示的這種情況下，社區(qū)邊界608還是社區(qū)網(wǎng)絡邊界。這是簡單的 情況，因為由源601和目的地602使用的協(xié)議606、607相同。任何集線器603-605都不需 要翻譯。在圖7中，需要翻譯，因為連接器701使用ebXML/HTTPS協(xié)議706，而連接器702使 用MML/Sonic協(xié)議707。在該圖中，集線器711、712和713屬于由社區(qū)邊界708從源社區(qū)和 目的地社區(qū)分隔開的中間社區(qū)。全部三個集線器都涉及從源到目的地的傳輸。集線器711 是外部連接器，它從集線器704接收電子商務文檔。第一次翻譯是由集線器712執(zhí)行的，從 ebXML/HTTPS翻譯到soap/HTTPS。這仍然不是目的地所需的協(xié)議組合，所以文檔被轉發(fā)給 集線器713。集線器713執(zhí)行從soap/HTTPS到MML/sonic的進一步翻譯，MML/sonic是目的地的協(xié)議組合。文檔被轉發(fā)到集線器705。如圖3-7所示的傳遞消息所需的路由，由包含路由信息和路由算法的注冊來支 持。圖8是包含路由信息的部分注冊的簡化示意圖。連接器801是該數(shù)據(jù)結構的中心特 征。連接器具有例如封裝翻譯、傳輸翻譯、外部可視能力、對等路由、子社區(qū)中的成員資格以 及到相同子社區(qū)中的其他連接器的對等路由之類的能力802。因此，連接器801和能力802 之間的關系811支持零個或多個能力。一個或多個鏈接803將連接器801連接到協(xié)議804 和其他連接器。連接器801和特定傳輸/封裝協(xié)議804之間的關系816支持一個或多個協(xié) 議。從連接器801通過812、鏈接803通過815到協(xié)議804，關系是一對一的。也就是說，從 連接器801到特定傳輸/封裝協(xié)議804存在不超過一個的出站鏈接813，除了在圖8中未示 出的、根據(jù)安全考慮而進一步區(qū)分的傳輸協(xié)議的上述情況以外。出站鏈接813和入站鏈接 814與路由規(guī)則相對應。而且，出站鏈接813表達了如下路由規(guī)則，即根據(jù)特定傳輸/封裝 協(xié)議815、804而被傳送的消息需要被轉發(fā)到另一個連接器。鏈接803與子和父連接器801 相關聯(lián)。入站鏈接814將連接器801標識為由子連接器根據(jù)特定傳輸/封裝協(xié)議通信的目 的地，它由應用于該子連接器的路由規(guī)則來表達。對于傳輸/封裝協(xié)議804，存在傳輸信息 806和封裝格式信息805兩者。至于使對象結構正規(guī)化的問題，該傳輸和封裝信息806、805 可以被鏈接818、817到協(xié)議對804，而不是相同對象的一部分。在上述情況下，當路由依賴 于傳輸/封裝/安全性三者組成的一組時，可以進一步將所謂的信道對象引入到連接器801 和協(xié)議804之間，以便進一步對數(shù)據(jù)結構正規(guī)化。圖9提供了描述了連接器的部分注冊的替換圖。連接器901具有各種屬性。它具 有名稱，該名稱可以是社區(qū)名稱和單獨的連接器名稱的結合。它具有描述和統(tǒng)一資源指示 符(URI)。標志指示該連接器是否是中心連接器或外部連接器。外部連接器是用戶定義的 連接器。在社區(qū)之內(nèi)，子社區(qū)中的成員資格反映在屬性peerToPeerGroup中。該屬性可以 是包含管理范圍或子社區(qū)的名稱的字符串。連接器901的能力包含傳輸翻譯922、封裝翻譯 923和路由器動作924。連接器901可以具有超過一個的傳輸翻譯能力922。在當前實施 例中，傳輸與特定封裝協(xié)議相關聯(lián)。假設翻譯在傳輸1到傳輸2之間是雙向的。標志指示 兩個傳輸協(xié)議是否是軟件實現(xiàn)自身擁有的。一種軟件實現(xiàn)提供HTTP、HTTPS和sonic傳輸 協(xié)議的自動(native)傳輸支持。其他傳輸協(xié)議，例如FTP，可以是用戶實現(xiàn)的。連接器901 還可以具有超過一個的封裝翻譯能力923。再次假設翻譯是雙向的。連接器還可以具有路 由器能力924。路由器能力指集線器連接器轉發(fā)從其他連接器接收到的消息的能力。在本 實施例中，路由與特定封裝協(xié)議相關聯(lián)。連接器901還與傳輸/封裝協(xié)議904相關聯(lián)。支 持特定封裝協(xié)議和協(xié)議版本的傳輸規(guī)范?？梢允褂镁哂刑囟ǚ庋b協(xié)議的各種傳輸類型。物 理地址與特定傳輸類型相關聯(lián)?？蛇x地，傳輸安全性可以與特定傳輸類型相關聯(lián)。傳輸規(guī) 范904可以反映傳輸/封裝對或傳輸/封裝/安全性三者。標志根據(jù)傳輸規(guī)范來指示是否 可以忽略路由規(guī)則，以及是否可以基于對等原則、在該連接器與其為相同子社區(qū)的成員的 其他連接器之間引導通信。路由規(guī)則對應于允許的路由925。圖9中示出的注冊機構能夠 通過在連接器901和傳輸規(guī)范904之間引入信道對象而被正?；员憷梅庋b協(xié)議或傳 輸/封裝協(xié)議來組成傳輸規(guī)范。圖10提供了支持社區(qū)之間的路由的注冊部分的高層示意圖。目標1001是源試圖 到達的目的地。該目標可以是最終目的地，或者是接近該目的地的負責轉發(fā)到該目的地的點。目標與社區(qū)相關聯(lián)，社區(qū)提供地址，例如URL，能夠在該地址處訪問社區(qū)注冊。當前實施 例支持一個中間社區(qū)1003的指定，通過中間社區(qū)1003將消息轉發(fā)到目標1001。目標與目 的地連接器1004以及一個或多個傳輸/封裝協(xié)議1005相關聯(lián)。如圖8所示，傳輸/封裝 協(xié)議與封裝格式1006和傳輸1007相關聯(lián)。這里是使用該方案的XML文件示例，其中簡單集線器和輪輻拓撲中有兩個應用。< ？ xml version = “ 1.0" encoding = 〃 UTF-8" ？ >〈Registry xmlns:xsi = “ http://www.w3.org/2001/XMLSchema_instance"xsi:noNamespaceSchemaLocation = " D:\design\routing\registry.xsd" >〈Connector uuid = " A" ><TransportSpec uuid = " A01" ><Parent>Hub01</Parent><EnvelopeProtocol version =" CI" >S0AP</EnvelopeProtocol><TransportType>Sonic</TransportType><PhysicalAddress>String</PhysicalAddress></TransportSpec></Connector><Connector uuid = 〃 Hub" ><TransportSpec uuid = " HubOl" ><Parent>None</Parent><Child>A01</Child><Child>B01</Child><EnvelopeProtocol version =" CI" >S0AP</EnvelopeProtocol><TransportType>Sonic</TransportType><PhysicalAddress>String</PhysicalAddress></TransportSpec>〈Capability〉<Hub><EnvelopeProtocol version =" CI" >S0AP</EnvelopeProtocol></Hub>〈/Capability〉</Connector>〈Connector uuid = " B" ><TransportSpec uuid = " B01" ><Parent>Hub01</Parent><EnvelopeProtocol version =" CI" >S0AP</EnvelopeProtocol><TransportType>Sonic</TransportType><PhysicalAddress>String</PhysicalAddress></TransportSpec>〈/Connector〉
〈/Registry〉該注冊數(shù)據(jù)對應于圖3中的變化，其中源和目的地連接器301、302利用SOAP/ Sonic協(xié)議304、305。在該示例入口中，集線器303名稱為“集線器01 ”。數(shù)據(jù)一般地遵守 圖9的結構。路由方框的簡單格式能夠用于在社區(qū)內(nèi)路由和在社區(qū)間路由兩者。圖11和圖12 示出了能使用XML來表達路由的格式，隨后是示例。在圖11和圖12中，路由1101與具有 兩個或多個連接器1103/1203的1102相關聯(lián)。連接器1203與復雜數(shù)據(jù)類型1204相關聯(lián)， 復雜數(shù)據(jù)類型1204包含名稱1205、封裝類型1206、本地或外部傳輸標志1207、連接器功能 指定1208以及傳輸協(xié)議1209。傳輸協(xié)議1209還與傳輸?shù)刂废嚓P聯(lián)，該圖中沒有示出。路 由1101定義了從源到目的地將要越過的連接器的列表。連接器1103/1203提供沿路由的 單一功能。名稱1205可以是惟一名稱，例如發(fā)出授權前綴/連接器類型/社區(qū)名稱/本地 名稱的結合。封裝類型1206是到達該連接器時的封裝類型，例如S0AP、ebXML或MML。“Is Native”標志1207指示該傳輸類型是否是軟件系統(tǒng)固有的或者是否被支持為用戶實現(xiàn)的 擴展。連接器功能1208標識在該節(jié)點將要執(zhí)行的功能。傳輸1209標識用于到達該節(jié)點的 傳輸。該節(jié)點的傳輸/封裝協(xié)議對應于傳輸1209和封裝類型1206的組合。以下是一般遵 守該數(shù)據(jù)結構的XML代碼示例< ？ xml version = " 1.0" encoding = 〃 UTF-8" ？ >〈Route xmlns =" http://commerceone.com/wse/routing"xmlns:xsi = " http://www.w3.org/2001/XMLSchema_instance"xsi:schemaLocation = " http://commerceone.com/wse/routingD:\design\routing\route_block.xsd" ><Connector><Name>BUY:C:buySpice:nutmeg</Name><EnvelopeType>ebXML</EnvelopeType><isNative>true</isNative><ConnectorFunction>service-send</ConnectorFunction>〈Transport type = 〃 HTTPS" mode = 〃 sync" reliable =〃 false" ><Address>http://buyer. com/buy/nutmeg</Address></Transport></Connector><Connector><Name>BUY:C:buySpice:gwl</Name><EnvelopeType>ebXML</EnvelopeType><isNative>true</isNative><ConnectorFunction>envelope-gateway</ConnectorFunction>0098]〈Transport type = 〃 HTTPS" mode = 〃 sync" reliable =〃 false" >
0099]<Address>http://gateway, seller, com/external</Address>
0100]</Transport>
0101]〈/Connector〉
0102]<Connector>
0103]<Name>
0104]BUY:C:buySpice:exotic
0105]</Name>
0106]<EnvelopeType>SOAP-Cl</EnvelopeType>
0107]<isNative>true</isNative>
0108]<ConnectorFunction>service-receive</ConnectorFunction>
0109]〈Transport type =" Sonic" mode = " async" reliable =" true" >
0110]<Address>SonicClusterl:SellApp</Address>
0111]</Transport>
0112]〈/Connector〉</Route>該示例示出了與圖3的變化相對應的路由，其中源301使用ebXML/HTTPS協(xié)議304 來與集線器303通信。源連接器301是固有連接器，名稱為nutmeg。集線器連接器303也 是固有連接器，名稱為GW1，它執(zhí)行封裝網(wǎng)關功能。目的地302使用SOAP/Sonic協(xié)議305來 與集線器303通信。目的地302是固有連接器，名稱為exotic。所有三個連接器屬于社區(qū) BUY:C:buySpice0由源和目的地使用的傳輸協(xié)議是軟件實現(xiàn)固有的，所以集線器303將封 裝和傳輸協(xié)議翻譯作為單一功能來執(zhí)行。因此，它在該示例路由編碼中僅僅出現(xiàn)一次。圖13和14是社區(qū)內(nèi)路由和社區(qū)間路由的高層示意圖。路由包含源、目的地和它 們之間的一系列連接器。對于安全路由，路由還包含一個或多個安全區(qū)域，使得通信總保持 安全。在圖13中，可以是服務的源和目的地二者被映射到連接器1301。本地注冊1302包 含關于連接器的信息，來自該連接器的部分路徑列表能夠被構造成起始于源和目的地連接 器。構造電子商務文檔經(jīng)過的連接器的部分路徑列表包含幾個子步驟。注冊中的信息包含 連接器間通信的路由規(guī)則，它能夠表示為定向圖。構造部分路徑列表包含從子到父連接器 進行的穿越。在穿越中的每一個連接器處，對于下一個頂點可用的替換傳輸/封裝協(xié)議被 看作是分離的部分路徑。穿越從源或目的地的部分路徑的完成對應于到達連接器，該連接 器不具有使用該穿越的特定傳輸/封裝協(xié)議的可用的父連接器?？商鎿Q地，穿越部分路徑 的完成可以對應于到達使用該穿越的特定傳輸/封裝協(xié)議進行對等通信的連接器。如果將 標志設置為允許連接器忽略到相同的子社區(qū)中其他連接器的路由，則確定連接器是否進行 對等通信可能需要考慮該連接器所屬于的子社區(qū)。通過從子到父連接器進行穿越，建立了 對于源和目的地連接器的部分路徑列表，每一個列表中包含一個或多個部分路徑。源和目 的地部分路徑列表被鏈接1304。當各源和目的地部分路徑列表共享連接器，并且該共享連 接器的傳輸/封裝協(xié)議與兩個列表中的相同，或者該共享連接器具有在各列表的各傳輸/ 封裝協(xié)議之間進行翻譯的翻譯能力時，各源和目的地部分路徑列表能夠通過共享連接器被 鏈接。各列表還能夠在各列表中的相似連接器之間被鏈接，相似鏈接器是支持相同的傳輸/封裝協(xié)議的連接器。如上所述，對于該路由方法的擴展是使用傳輸/封裝/安全性三者組 成的一組作為構造部分路徑列表的基礎。鏈接各列表的另一個替換方案是通過一個或多個 中心連接器來鏈接，該中心的連接器具有在出現(xiàn)在各部分路徑列表中的傳輸/封裝/安全 性協(xié)議之間進行翻譯的能力。為了使用中心連接器，部分路徑列表可以從父連接器被擴展 到?jīng)]有明確地鏈接到父連接器的中心連接器。圖14應用路由交叉社區(qū)。路由交叉社區(qū)包含社區(qū)之間的跳躍以及社區(qū)之內(nèi)的連 接器到連接器的內(nèi)部跳躍?？梢允欠盏脑春湍康牡乇挥成涞竭B接器1401。各源和目的地 連接器屬于社區(qū)。反過來，源和目的地社區(qū)屬于社區(qū)網(wǎng)絡。一個或多個社區(qū)網(wǎng)絡從注冊1403 被標識1402為鏈接源和目的地社區(qū)。如果源和目的地社區(qū)在社區(qū)網(wǎng)絡中共享成員資格，則 各社區(qū)的外部連接器可以使用公共傳輸/封裝協(xié)議被直接鏈接。如果源和目的地社區(qū)沒有 公共傳輸/封裝協(xié)議，則一個或多個中間社區(qū)可以被添加到路由中來執(zhí)行翻譯服務。源和 目的地的外部連接器被鏈接到一個或多個中間社區(qū)的相似連接器。在一些實現(xiàn)中，中間社 區(qū)的數(shù)量可以被限制為1、2、3或一些其他少于5或10的小數(shù)目，以便簡化路由。當已經(jīng)確 定了潛在地通過中間社區(qū)的源和目的地社區(qū)的外部連接器之間的路由時，就計算每一個參 加社區(qū)之內(nèi)的社區(qū)內(nèi)路由。在源和目的地社區(qū)中，利用一個或多個注冊1405中的數(shù)據(jù)，計 算1404從源和目的地連接器到各外部連接器的路由。對于中間社區(qū)，計算從進入到離開外 部連接器的路由。通過組合社區(qū)內(nèi)和社區(qū)間路由1406來規(guī)定完整的路由，以便產(chǎn)生從源到 目的地的的連接器到連接器路由。路由交叉社區(qū)可以利用存儲在本地或全球注冊中的預先 計算的路由。預先計算的路由可以指定路由消息經(jīng)過的中間社區(qū)。中間社區(qū)可以提供翻譯、 記帳、商務情報或其他服務。當計算了用于從源到目的地發(fā)送消息的路由、以便節(jié)省路由供 以后使用時，它可能是有效率的?？商鎿Q地，可以有效地利用空閑CPU周期，來預先計算社 區(qū)網(wǎng)絡中到其他社區(qū)的路由，或者到可以通過當前社區(qū)網(wǎng)絡中的社區(qū)到達的任何非當前社 區(qū)網(wǎng)絡的社區(qū)的路由。
由于可能會遭遇到很多偷竊，電子商務文檔的路由最好遵循安全性和被信路由。 如果沒有加密，有線上的文檔處于危險之中。源或目的地可能受到危害，并且暴露被推測為 維持保密狀態(tài)的信息。源和目的地之間的連接器可能會惡意活動它們可能拋棄、延遲或重 發(fā)文檔，記錄它們接收到的并且暴露保密信息的文檔，或者修改文檔。負有翻譯責任的連接 器在翻譯期間可能惡意地或者簡單地改變文檔的語義。這些已知的問題制造了提供如下方 法和設備的機會，該方法和設備用于電子商務文檔的安全和被信通信。圖15到19描述安全和被信通信的一些使用情況。源和目的地之間的信任是通過 先前的契約而建立的。例如，作為交易伙伴的公司同意并且可以以合作契約的形式注冊它 們的契約。該合作契約可以包含使用的文檔類型以及相互認可安全性重點，例如簽名和加 密。安全性契約可以在交易伙伴之間達成，或者可以由各交易伙伴所屬于的社區(qū)通過。達 成契約的方式對于被信通信的安全性來說不是重要的。當沿從源到目的地的路徑上的連接器作為被信任的連接器而被列在注冊中時，它 們是被信任的。集線器被信任，以便根據(jù)路由沿路由中的下一個跳來發(fā)送文檔，并且保護它 對于內(nèi)容的任何了解或者甚至對該文檔沿路由的傳輸?shù)牧私狻．斔墓δ軆H僅是轉發(fā)該文 檔時，集線器無需關心文檔是否被加密或簽名。為了支持加密通信，例如虛擬私人網(wǎng)絡通信 或HTTPS通信，集線器可以擁有密鑰和證書，如實現(xiàn)PKI或其他安全模式那樣。
提供封裝翻譯服務的連接器，即所謂的網(wǎng)關，提出了更多復雜的信任問題。從一種 格式到另一種格式的文檔翻譯，需要集線器或連接器能夠解密它所接收到的東西，并且對 簽名進行確認。翻譯之后，網(wǎng)關重新簽名并且加密它翻譯的東西。為了完成所有這些，由網(wǎng) 關接收到的消息應當使用網(wǎng)關的密鑰被加密，而不是目的地的密鑰。最好是參照支持驗證 簽名的注冊，網(wǎng)關必須能夠驗證所接收的消息上的簽名。如果它接收到的消息是簽名的，當 網(wǎng)關已經(jīng)翻譯了文檔時，它就重新簽名該文檔。如果不需要進一步的翻譯，它還使用與沿路 由的下一個網(wǎng)關或者目的地相對應的密鑰來加密該消息。該網(wǎng)關可以具有多個密鑰對或證 書，能夠將不同的密鑰對用于加密、簽名以及用于安全、虛擬私人網(wǎng)絡連接。從源到目的地、通過網(wǎng)關進行的驗證是順序的。第一個網(wǎng)關檢驗源的簽名，并且重 新簽名該文檔。該網(wǎng)關必須信任該源，后續(xù)的網(wǎng)關必須信任它們從其接收消息的網(wǎng)關。該 鏈中的每一個網(wǎng)關都信任它前面的網(wǎng)關，驗證它接收的簽名，并且施加它自己的簽名。在建 立該安全鏈的過程中，例如，SAML斷言能夠被接受并且由網(wǎng)關施加。網(wǎng)關需要保持翻譯文 檔的擴展存檔，以便解決任何發(fā)生的爭端。文檔應當被存檔兩次，一次是解密之后作為初始 文檔，最好包含接收的簽名(如果有的話)，而另一次是翻譯之后，加密之前，最好顯示出網(wǎng) 關的簽名?？傊斣春湍康牡乇舜诵湃?，源和目的地信任執(zhí)行翻譯的網(wǎng)關，并且該路由中的 每一個連接器信任該路由中前面的和后續(xù)的連接器時，就可以建立路由中的信任。前面討 論了源和目的地之間的信任。在電子商務中，它對于在交換電子文檔之前彼此信任的伙伴 是有意義的。源和目的地應當信任網(wǎng)關，因為網(wǎng)關執(zhí)行翻譯功能。被信網(wǎng)關的列表可以保持 在注冊中。如果源或目的地缺少對于執(zhí)行翻譯服務的網(wǎng)關連接器的信任，就不應當使用該 網(wǎng)關。雖然不是全部的交易伙伴都對此非常敏感，但是意識到安全問題的交易伙伴，例如國 防工業(yè)參加者，則認為知道可能能夠讀取文檔內(nèi)容的每一個和全部的連接器是有利的。對 于僅僅轉發(fā)文檔而不解密或翻譯它們的那些連接器，可以放松信任要求。例如，考慮特定的源和目的地源使用MML封裝，目的地使用ebXML。一種可能的 路由將是從源到第一個網(wǎng)關，使用MML ；從MML到SOAP的封裝轉換；從第一個網(wǎng)關轉發(fā)到第 二個網(wǎng)關；從SOAP到ebXML的翻譯；以及從第二個網(wǎng)關到目的地的轉發(fā)。在這種情況下，該 源必須信任網(wǎng)關和目的地。該目的地必須信任該源和網(wǎng)關。如果源或目的地不信任執(zhí)行翻 譯的中間網(wǎng)關，則該路由是不可接受的。網(wǎng)關還應當信任前面一個的源或網(wǎng)關以及緊接著的網(wǎng)關或目的地。這可以被稱為 傳遞信任。該信任鏈中執(zhí)行翻譯的每一個元素都想肯定它正在與它能夠信任的元素進行交 互。接著前面的示例，假設路由從源穿越到網(wǎng)關1，繼續(xù)到網(wǎng)關2，和到網(wǎng)關3，接著到目的 地。沿該路由，第一個網(wǎng)關必須信任源和第二個網(wǎng)關。第二個網(wǎng)關必須信任第一個和第三 個網(wǎng)關。第三個網(wǎng)關必須信任第二個網(wǎng)關和目的地。實際上，網(wǎng)關3信任網(wǎng)關1，因為它信 任網(wǎng)關2，而網(wǎng)關2反過來信任網(wǎng)關1。當傳遞信任是由源和目的地之間的明確信任所組合 時，認為傳遞信任沿該種路由是充分的。當中間社區(qū)提供翻譯網(wǎng)關時，可以采用一種替換 的、簡化的信任模式。那么，信任提供翻譯服務的中間社區(qū)是充分的，而無需信任由中間社 區(qū)執(zhí)行翻譯服務所使用的每一個和全部網(wǎng)關。只有當涉及中間社區(qū)時，才認為可以應用這 種簡化的信任。例如，源和目的地處于相同的社區(qū)中，該源和目的地將彼此信任，但是可能 不信任執(zhí)行文檔翻譯的網(wǎng)關。在社區(qū)之內(nèi)，應當明確信任網(wǎng)關。在社區(qū)網(wǎng)絡之內(nèi)，可以信任中間社區(qū)來執(zhí)行確定的翻譯服務，而無需信任中間社區(qū)的翻譯機制的每一個和全部組成部分。可以使用很多不同的驗證和信任模式。三種目前使用的用于驗證的安全模式包 含用戶名和口令；SAML驗證斷言；和X. 509證書。這些和其他安全模式的操作被集體地稱 為獲得安全憑證(credential)。這些安全憑證可以由作為分離的處理或例程或代碼段而運 行的服務器提供。對于用戶名和口令驗證，接收方確認用戶名和口令。用戶名和口令的通 信應當經(jīng)由加密信道。SAML斷言更復雜。源和目的地之間的信任部分是目的地信任產(chǎn)生SAML斷言的管 理局。該信任可以是社區(qū)范圍水平的或者是關于由特定源使用的特定管理局。一般地，被信 SAML驗證管理局和其他被信管理局的證書被保持在注冊中，以便由需要檢驗該斷言的方面 訪問°在操作中，從SAML客戶機可以訪問SAML服務。SAML服務從SAML客戶機接收請 求，并且回應該客戶機。例如，可以使用SOAP封裝進行該通信。SAML服務可以支持驗證和 屬性請求。響應于驗證請求，它可以產(chǎn)生安全憑證。由SAML服務產(chǎn)生的斷言一般將被使用 SAML服務的簽名密鑰進行簽名。對于基本驗證，SAML服務可以從SOAP封裝的應用憑證頭 塊中提取交易伙伴或用戶id和口令。該服務調(diào)用注冊訪問應用程序接口，來獲取與交易伙 伴或用戶id相對應的口令。它比較接收的和注冊口令。如果它們匹配，則產(chǎn)生斷言并且簽 名。如果它們不匹配，則它報告錯誤。在替換實施例中，在被存儲到注冊中以前，可以對口 令進行散列處理。如果如此，則比較散列數(shù)據(jù)。對于X. 509驗證，信任應當基于發(fā)放該證書的證書管理局。被信證書管理局的列 表可以基于證書管理局的身份標識或證書管理局身份標識與通信方(correspondent)身 份標識的組合。被信證書管理局的列表，例如VeriSign三級證書，可以包含不管它們來自 哪個社區(qū)都被信任的證書?？商鎿Q地，被信證書管理局的列表可以是對于遠程社區(qū)特定的。 于是，Boeing證書可能僅僅在它們來自Boeing社區(qū)時才被信任。VeriSign證書可能對于 多個社區(qū)被信任。SAML服務可以響應于X. 509驗證證書。當接收到X. 509證書時，它可以從S0AP封 裝的應用憑證頭塊中提取該證書。它可以檢索存儲在附件中的處理信息。如果附件為空， 它將報告驗證失敗。它將比較從附件的處理信息字段中提取的客戶機證書與來自憑證頭塊 中的證書。如果證書不匹配，它就報告驗證失敗。如果它們匹配，它就調(diào)用注冊訪問應用接 口，來從該注冊中獲取交易伙伴或用戶id證書。它比較處理信息和注冊證書。如果它們不 匹配，它就報告驗證失敗。如果它們匹配，它就產(chǎn)生斷言并且可對其簽名。該斷言被返回給 客戶機。信任機制還可以用于實施電子商務文檔的不同級別的分類。例如，關鍵的軍用零 部件可能需要一組特殊的極機密的安全憑證，而物資供應所(commissary)商品可以使用 常規(guī)斷言來處理。特殊路由規(guī)則可以應用于特殊斷言。例如，極機密的文檔可能僅僅通過 特殊的被授權翻譯極機密文檔的被信網(wǎng)關來進行路由。特殊的被信網(wǎng)關可以服從附加安全 措施，例如加強的監(jiān)視、特別健壯的加密、專用傳輸介質(zhì)等等。假定源和目的地之間信任，安全和被信通信機制可以依賴于如下因素，例如源和 目的地是否處于相同的社區(qū)，它們是否與安全服務器直接交互或者通過代理進行交互，以及兩者是否都使用相同的安全機制。圖15描述一種社區(qū)內(nèi)的安全性實現(xiàn)。在該社區(qū)內(nèi)，全 部連接器，包含源1511和目的地1512彼此信任。在該示例中，安全服務器1501是該社區(qū) 本地的SAML服務器。源1511從SAML服務器1501獲取用于驗證的安全憑證，并且還可以 獲取管理局的屬性斷言。至少將安全憑證和電子商務文檔打包在封裝中，并且沿社區(qū)內(nèi)的 路由將其從源發(fā)送到目的地。該路由可以包含圖中未示出的連接器。圖16描述第一個社區(qū)1605中的源1611和第二個社區(qū)1606中的目的地1612。網(wǎng) 絡概念需要源和目的地具有關于它們與其交換文檔的其他社區(qū)的信息。當SAML被用作安 全機制時，關于其他社區(qū)的信息包含其他社區(qū)中的被信任提供安全服務的SAML服務器的 身份標識。其他社區(qū)中的SAML服務器被明確列表為受本地社區(qū)信任。在圖15中，每一個 社區(qū)1605、1606包含SAML服務器1601、1602以及源1611或目的地1612。當源發(fā)送文檔給 目的地時，該源請求其SAML服務器1601提供SAML斷言。該源還查詢目的地的SAML服務 器1602以便檢索驗證信息。來自兩個SAML服務器的斷言連同電子商務文檔被發(fā)送到目的 地。作為性能增強，源所屬于的社區(qū)或源的安全服務能夠保存從第二個社區(qū)1606檢索到的 SAML斷言或者本地和外部SAML斷言，以便以后使用，從而改善了系統(tǒng)性能。替換SAML機 制，當使用PKI機制時，給源發(fā)放證書的被信證書管理局的證書必須在目的地社區(qū)(1606) 中注冊。對于用戶名和口令安全性，有效的用戶名和口令組合在目的地社區(qū)和網(wǎng)關中注冊。圖17描述安全服務的授權。在該圖中，連接器1711提供安全服務，并且充當源 1721和1722的代理?？梢詫⒃?721和1722注冊為依賴代理1711提供安全服務。當代理 1711與SAML服務1701通信時，它標識它自己以及源，它代表該源來請求安全斷言。接著， SAML服務器給代表源的主機發(fā)出安全斷言，并且還可以發(fā)出屬性斷言。該主機至少將安全 斷言和電子商務文檔轉發(fā)給目的地。安全斷言可以伴隨公開主機在該安全處理中涉及的忠 告聲明。圖18A和18B示出了將驗證授權給網(wǎng)關1812。在圖18A中，連接器1821、1822處 于大社區(qū)1805的子社區(qū)1806中。這些連接器1821、1822利用MML協(xié)議與網(wǎng)關1812進行 通信。它們將MPID、用戶id和口令傳遞給網(wǎng)關。處理信息包含相同的信息。網(wǎng)關進行注冊 查找，來定位它接收到的MPID、用戶id和口令。如果在注冊中找到這三者，該網(wǎng)關就創(chuàng)建憑 證對象作為該MML封裝的附件。該網(wǎng)關將授權驗證請求發(fā)送到SAML服務。SAML服務使用 網(wǎng)關的憑證進行驗證。SAML服務返回驗證斷言，該驗證斷言可以包含忠告部分。該驗證斷 言是網(wǎng)關1812所轉發(fā)給目的地1811的一部分。在圖18B中，反轉通過網(wǎng)關1812進行的通信。源1811與子社區(qū)1806中的使用 MML協(xié)議的連接器1821、1822通信。源1811從SAML服務器1801獲取SAML安全憑證，并且 將其連同電子商務文檔一起轉發(fā)到網(wǎng)關1812。網(wǎng)關將SOAP封裝轉換成MML封裝。網(wǎng)關使 用他自己的MPID、用戶id和口令來創(chuàng)建安全憑證，并且將其附著到MML封裝中。MML封裝 被發(fā)送到使用MML的子社區(qū)1806。在圖19A和19B中，將匪L和SAML安全協(xié)議之間的翻譯擴展到社區(qū)1905、1906之 間的通信。源1922位于使用MML的社區(qū)中，而目的地1911位于使用SOAP的社區(qū)中。源交 易伙伴1922依靠入口路由器1921將安全憑證和電子商務文檔轉發(fā)到處理封裝和安全變換 的網(wǎng)關1912。路由器1921將安全憑證傳遞到網(wǎng)關1912。該安全憑證在MML封裝內(nèi)部。該 網(wǎng)關從MML封裝的安全憑證中提取CPID，并且將授權驗證請求發(fā)送到SAML服務。驗證是使用網(wǎng)關的憑證進行的。SAML服務返回驗證斷言，如上所述。驗證斷言和翻譯的電子商務文 檔被轉發(fā)到目的地911。在圖19B中，反轉通過網(wǎng)關1912進行的通信。源1911與使用MML 協(xié)議的子社區(qū)1906中的目的地1922通信。源1911從SAML服務器1901獲取SAML安全憑 證，并且將其連同電子商務文檔一起轉發(fā)到網(wǎng)關1912。該網(wǎng)關將SOAP封裝轉換成MML封 裝。該網(wǎng)關使用它自己的MPID、用戶id和口令來創(chuàng)建安全憑證，并且將其附著到MML封裝 中。該MML封裝被發(fā)送到使用MML的子社區(qū)1906。為了便利上述授權情形，可以如下擴展SAML協(xié)議方案。< ？ xml version = “ 1.0" encoding = 〃 UTF-8" ？ ><xsd:schema targetNamespace = " http://schemas.commerceone.com/wse/ security/delegation"xmlns: samlp = draft-sstc-schema-
http://www. oasis-open, org/committees/security/docs/
protocol-27. xsd" xmlns:ds =" http://www. w3. org/2000/09/xmldsig#〃 xmlns:xsd = “ http://www. w3. org/2001/XMLSchema"
xmlns:cldel = " http://schemas.commerceone.com/wse/security/
attributeFormDefault
delegation"e 1 ementFormDef au 11 = " qualified ="unqualified" version =" 0.1" ><xsd:import namespace = " http://www. w3. org/2000/09/xmldsig#〃schemaLocation = " xmldsig-core-schema. xsd" /><xsd:import namespace = " http://www.oasis_open.org/committees/ security/docs/draft-sstc-schema-protocol-27. xsd " schemaLocation ="draft-sstc-schema-protocol-27. xsd" /> =〃 xsd =〃 xsd =〃 xsd
<
/DelegateFor-代表正在為其進行驗證請求的TP或服務的ID /CommunitylD-定義TP或服務的社區(qū)ID /CommunityType-社區(qū)類型(例如 M0E4x) /Description-僅僅是信息
—>
<xsd:complexType name = “ DelegationType“ > <xsd:complexContent>
<xsd:extension base = " samlp:AuthenticationQueryType" > <xsd:attribute name = " DelegateFor " type
string" />
<xsd:attribute name = " CommunitylD " type
string" />
<xsd:attribute name = " CommunityType " type
string" />
<xsd:attribute name = " Description " type ="xsd:string" /></xsd:extension)</xsd:complexContent></xsd:complexType></xsd:schema)符合該方案的授權驗證請求如下< ？ xml version = “ 1.0" encoding = 〃 UTF-8" ？ >〈Request xmlns = “ http://www.oasis_open.org/committees/security/docs/ draft-sstc-schema-protocol-27. xsd" xmlns:ds = " http://www.w3.Org/2000/09/xmldsig#"xmlns:saml = " http://www.oasis_open.org/committees/security/docs/ draft-sstc-schema-assertion-27. xsd " xmlns: xsi = " http://www.w3.org/2001/ XMLSchema-instance"xmlns: cldel = " http://schemas.commerceone.com/wse/security/ delegation"xsi:schemaLocation = " http://www.oasis_open.org/committees/security/ docs/draft-sstc-schema-protocol-27. xsdC:\XMLSPY 2. 3\draft-sstc-schema-protocol-27. xsd"xsi:schemaLocation = " http://schemas.commerceone.com/wse/security/ delegationC:\XMLSPY 2. 3\sec-delegation_ext. xsd" RequestID = 〃 lfgtTGzMXSqpN++/ LcFpBmZffrQg =“MajorVersion = 〃 1 " MinorVersion = " 0 " Issuelnstant ="2001-09-11T09:30:47-05:00〃 ><Respondffith>AuthenticationStatement</Respondffith>< ！ —SAML服務將簽名塊看作一小塊一><ds: Signature Id = " ID01" >< ！—數(shù)字簽名一></ds:Signature)<AuthenticationQuery xsi:type = " cldel:DelegationType" DelegateFo
r=" TPxxx" >
s-the-TP" />
<saml:Subject)
<saml:NameIdentifier Name = " unique-string-that-identifie
<saml:SubjectConfirmation> < ！—對于基本驗證一>
<samlConfirmationMethod>http//www. oasis—open.org/committies/security/docs/draft-sstc-core-27/password< ！—對于基于X509證書的驗證<samlConfirmationMethod>http//www. oasis—open, org/committies/security/docs/draft-sstc-core_27/X509—></saml:ConfirmationMethod></saml:SubjectConfirmation></saml:Subject)</AuthenticationQuery></Request>注意，上面的DelegateFor和Nameldentif ier指相同的實體，為其執(zhí)行授權驗證 的參加者。包含授權的對于該請求的示例響應如下< ？ xml version = “ 1.0" encoding = 〃 UTF-8" ？ >〈！一由 XML Spy 4. 2U 產(chǎn)生的示例 XML 文件(http //www. xml spy. com)—>〈Response xmlns = " http://www.oasis_open.org/committees/security/ docs/draft-sstc-schema-protocol-27. xsd" xmlns:ds = " http://www.w3.Org/2000/09/xmldsig#"xmlns:saml = " http://www.oasis_open.org/committees/security/docs/ draft-sstc-schema-assertion-27. xsd " xmlns: xsi = " http://www.w3.org/2001/ XMLSchema-instance"xsi:schemaLocation = " http://www.oasis_open.org/committees/security/ docs/draft-sstc-schema-protocol-27. xsdC:\XMLSPY 2. 3\draft-sstc-schema-protocol-27.xsd “ ResponselD =〃 String"
lfgtTGzMXSqpN++/LcFpBmZffrQg = “ MajorVersion
MinorVersion =" 0"
Issuelnstant =" 2001-09-11T09:30:47-05:00" >InResponseTo =
=〃 r
<Status><StatusCode Value = " samlp:Success" ><SubStatusCode Value =〃 q:name〃 /></StatusCode><StatusMessage>String</StatusMessage><StatusDetail/>〈/Status〉<saml :Assertion MajorVersion = 〃 1〃 MinorVersion = 〃 0〃AssertionID = “ +!UyxJDBUza + ao + LqMrE98wmhAI = “ Issuer="String" Issuelnstant =" 2001-09-llT09:30:47-05:00〃 ><saml:Conditions NotBefore = " 2001-09-11T09:30:47-05:00〃NotOnOrAfter = " 2001-09-11T09:30:47-05:00〃 /><saml:Advice><saml:Subject)<saml:NameIdentifier Name = " ID—of—the—delegate" /></saml:Subject)<saml:AdviceElement xsi:type = " xsd:string " value ="somedescription" /></saml:Advice〉<saml:AuthenticationStatement><saml:Subject)<saml:NameIdentifier Name = " unique-string-that-ident ifies-the-TP" /><saml:SubjectConfirmation>< ！—對于基本驗證一><saml:ConfirmationMethod>http://www. oasis—open.org/committies/security/docs/draft-sstc-core-27/password< ！—對于基于X509證書的驗證<samlConfirmationMethod>http//www. oasis-
open, org/committies/security/docs/draft-sstc-core_27/X509—></saml:ConfirmationMethod></saml:SubjectConfirmation></saml:Subject)</saml:AuthenticationStatement><ds: Signature Id = 〃 ID 11〃 ></ds:Signature)</saml:Assertion>〈/Response〉當SAML服務通過授權創(chuàng)建了斷言時，它使用上面的〈Advice〉塊來披露該授權。沒
有授權，響應將是相似的，除了沒有〈Advice〉塊以外。在一個實施例中，斷言方案不允許單一的請求消息包含驗證和屬性請求兩者。在 該實施例中，SAML客戶機提出請求首先是驗證請求，接著是屬性請求。屬性請求跟隨驗 證。示例的屬性請求如下< ？ xml version = “ 1.0" encoding = 〃 UTF-8" ？ >//www. oasis-open, org/committees/security/docs/ xmlns : xsi = " http://www.w3.org/2001/ http://www. oasis-open, org/committees/security/<—由 XML Spy v4. 2U 產(chǎn)生的示例 XML 文件(http: //www. xmlspy. com)—>< ！—屬性請求一>〈Request xmlns = " http://www.oasis_open.org/committees/security/docs/ draft-sstc-schema-protocol-27. xsd" xmlns:ds = " http://www.w3.Org/2000/09/xmldsig#"xmlns :saml = " http: draft-sstc-schema-assertion-27. xsd " XMLSchema-instance"xsi:schemaLocation =" docs/draft-sstc-schema-protocol-27. xsdC:\XMLSPY 2. 3\draft-sstc-schema-protocol-27. xsd"RequestID = “ IfgtTGzMXSqpN++/LcFpBmZffrQg = “ MajorVersion ="1" MinorVersion =" 0"Issuelnstant =〃 2001-09-11T09:30:47-05:00〃 ><Respondffith>AttributeStatement</Respondffith><AttributeQuery><saml:Subject)<saml:NameIdentifier Name = " unique-string-that-identifie s-this-TP" /></saml:Subject)<saml :AttributeDesignator AttributeName ="attribute-name-string"AttributeNamespace = " attribute-name-space-string" /></AttributeQuery></Request>屬性斷言響應跟隨該請求。圖20到25中示出了安全使用情況的其他細節(jié)。圖20是簡單的客戶_服務設計 的方框圖。在該設計中，注冊服務驗證和費用授權基于CP級別身份標識。注冊管理者驗 證和授權基于用戶級別身份標識。注冊服務使用SAML進行驗證。它直接調(diào)用提供商應用 程序接口來確定特權；它基于經(jīng)過驗證的CP身份標識來進行它自己的授權。SAML客戶機 2012訪問存儲的SAML客戶機數(shù)據(jù)2011。SAML客戶機2012與SAML客戶機交換機2013通 信，該交換機2013在本地和遠程情況之間進行交換。在本地情況下，與SAML服務2016直 接通信。在遠程情況下，組成部分2014、2015處理交換機和遠程SAML服務之間的通信。憑 證和SAML斷言可以經(jīng)由HTTPS或另一個安全協(xié)議在組成部分之間交換。SAML服務2016與 服務和用戶管理提供商2017通信，服務和用戶管理提供商2017可以適應于基于證書的用 戶標識、基于用戶id和口令的驗證、或其他驗證方案。服務和用戶管理提供商2017與支持 公共對象架構(C0F)2018的模塊通信，該C0F 2018反過來訪問注冊2019。
圖21示出了使用圖20中的設計的注冊服務本地驗證。該圖中的編號與圖20相 同，除了增加注冊客戶機2101、注冊服務2105、C0F 2106和注冊2107以外。在這種使用情 況下，開始調(diào)用注冊客戶機2101。注冊客戶機2101調(diào)用SAML客戶機2112來獲取驗證。它 可以使用上述的任何驗證方案。SAML客戶機可以訪問存儲的SAML客戶機數(shù)據(jù)2111。它可 能能夠根據(jù)存儲的數(shù)據(jù)來確認驗證請求，并且返回有效的斷言。如果不是，它繼續(xù)進行遠程 驗證。SAML客戶機通過組件2114、2115與SAML服務2116通信。SAML服務執(zhí)行驗證，產(chǎn)生 安全憑證，可以簽名，并且將該安全憑證返回該SAML客戶機2112。圖22示出了這種使用 情況下對于注冊服務遠程驗證的變化。再次地，開始調(diào)用注冊客戶機2201。注冊客戶機確 定需要進行的遠程調(diào)用。它調(diào)用組件2202，來通過到對應的組件2204的通信信道一例如 https連接2203—進行通信，并且還與SAML客戶機2212通信。處理如上所述繼續(xù)進行。圖23和24分別示出了本地和遠程授權。在圖23中，注冊客戶機2301直接調(diào)用 注冊服務2305，傳遞如圖21所示所獲取的安全憑證。注冊服務用安全憑證調(diào)用SAML客戶 機2312，以便確認該安全憑證，并且獲得經(jīng)過驗證的CPID。利用該經(jīng)過驗證的CPID，注冊服 務2305調(diào)用用戶管理提供商數(shù)字(numeral) 2317，以便獲取對于經(jīng)過驗證的CPID的特權。 通過C0F 2318，從注冊2319獲取對于CP的特權。注冊服務數(shù)字2305執(zhí)行該特權。在圖 24中，將本地授權過程擴展到遠程授權。作為驗證，注冊客戶機2401通過組件2402、2403 通信，在這種情況下通過組件到達注冊服務2405。圖25示出了獲取對于文檔服務預訂的屬性斷言。組件2502和2503被進一步細 化為包含I⑶客戶機2511、2521和授權模塊2512、2522。I⑶客戶機2511調(diào)用與發(fā)送端注 冊2541相關聯(lián)的發(fā)送端I⑶服務2531。從發(fā)送端，到劃分線2500的左邊，I⑶服務2531 調(diào)用接收端ICD服務2532。安全計算器調(diào)用SAML客戶機2533來獲得屬性斷言。SAML客 戶機調(diào)用本地的接收端SAML服務2534。SAML服務調(diào)用服務提供商應用接口 2535來獲取 發(fā)送者信息，并且創(chuàng)建屬性斷言。服務提供商可以訪問注冊2542。屬性斷言被傳遞回到發(fā) 送端I⑶服務2531，并且被打包到I⑶安全塊2511中。授權模塊2512將屬性斷言放置在 封裝頭中，例如SOAP封裝頭中。將該封裝發(fā)送到組件2503，其中接收端的授權模塊2522讀 取屬性斷言，并且執(zhí)行預訂。圖26和27描述社區(qū)網(wǎng)絡的建立。在圖26中，兩個社區(qū)2601、2605參加社區(qū)網(wǎng)絡。 社區(qū)的操作者設置它們的社區(qū)，包含外部端口 2602、2606和本地注冊2603、2607。本地注冊 標識外部端口。社區(qū)的操作者進行操作配置2611，操作配置2611可以是常規(guī)合同或電子合 同。提供操作配置以便社區(qū)形成或加入網(wǎng)絡。社區(qū)將具有暴露給網(wǎng)絡中其他社區(qū)的一個或 多個服務。發(fā)現(xiàn)服務和推進服務允許網(wǎng)絡中的社區(qū)使用其他社區(qū)中的服務，而無需重復注 冊。社區(qū)的操作者還建立網(wǎng)絡搜索注冊，有時稱為全球黃頁目錄2614。當網(wǎng)絡操作時，社區(qū) 可以將服務信息從它們的本地注冊推進到全球黃頁，或者全球黃頁可以從參加的社區(qū)中拉 取信息。全球黃頁可以輪詢參加的社區(qū)或等待來自可以拉取信息的社區(qū)的通知。社區(qū)操縱 者可以將特定服務標記為本地社區(qū)可見、特定網(wǎng)絡可見、全部網(wǎng)絡可見、或者特定的其他社 區(qū)可見。全球黃頁中的服務信息列表應當與來自視野內(nèi)的標記服務相對應。這些全球黃頁 可以被實現(xiàn)為基于UDDI的注冊。它可以是社區(qū)外部的，或者由網(wǎng)絡中的一個社區(qū)提供。在 社區(qū)的網(wǎng)絡中，可能存在一個或多個全球黃頁。社區(qū)的操作者交換關于每一個其他社區(qū)的 外部端口細節(jié)和URL 2612的信息。該信息使能在外部端口 2602、2606之間進行通信。社區(qū)的操作者還交換涉及安全的信息，例如安全憑證或SAML證書2613。利用擁有的所交換的 信息，各社區(qū)的操作者用連接到外部社區(qū)所需的信息來裝載它們的注冊。例如，它們可以注 冊外部社區(qū)的外部端口和安全信息。它們還可以注冊與外部社區(qū)端口相對應的它們自己的 外部端口。社區(qū)的操作者還建立全球搜索注冊，有時被稱為白頁2615。它可以是社區(qū)外部 的，或者由網(wǎng)絡中的一個社區(qū)提供。當全球搜索注冊由一個社區(qū)提供時，它用作社區(qū)地址服 務器。要成為該社區(qū)地址服務器工作于其中的社區(qū)網(wǎng)絡的一部分的單獨社區(qū)，能夠通過與 社區(qū)地址服務器交換設置信息2611、2612、2613而加入到網(wǎng)絡中，并且能夠通過在它們的 本地注冊中注冊社區(qū)地址服務器的端口、來從社區(qū)地址服務器獲取其他外部社區(qū)的設置信 息，例如端口、安全憑證等，而不是通過特殊地設置網(wǎng)絡中每一個和全部社區(qū)的注冊入口。 可以通過社區(qū)地址服務器來建立互操作性。遵守社區(qū)網(wǎng)絡中的規(guī)則和慣例，并且潛在地服 從彼此做生意的社區(qū)中的雙邊契約2611。圖27描述超過兩個社區(qū)的網(wǎng)絡，其中一個社區(qū)提供社區(qū)地址服務器。社區(qū)2702 保持社區(qū)地址服務器2704。社區(qū)2701和2703與主社區(qū)交換信息，并且變得能夠發(fā)現(xiàn)它們 中的每一個提供的服務、允許的協(xié)議，以便彼此通信。根據(jù)網(wǎng)絡的規(guī)則，它們的通信可以是 直接的、由中間社區(qū)作為中介的、或者被強制經(jīng)過中間社區(qū)。在超過兩個社區(qū)的網(wǎng)絡中，可 以在參加的社區(qū)之間建立直接的私有鏈接，并且將其記錄在各社區(qū)注冊中，或者社區(qū)地址 服務器可以用于建立連接和信任。較少使用的情況是建立超過兩個社區(qū)的網(wǎng)絡而沒有社區(qū) 地址服務器，所有的成員基于點對點進行相互注冊。這種使用情況不會受益于新成員流水 線式地加入到網(wǎng)絡中。雖然已參照上面詳細描述的優(yōu)選實施例和示例公開了本發(fā)明，應該理解，這些示 例旨在進行說明而不用于限制意義。上述實施例包含了計算機輔助處理。因此，可以將本發(fā) 明實施為計算機輔助處理的方法、包含實施該方法的邏輯的系統(tǒng)、嵌入了執(zhí)行該方法的邏 輯的介質(zhì)、附加了執(zhí)行該方法的邏輯的數(shù)據(jù)流、或計算機可訪問的處理服務?？梢灶A料到， 本領域技術人員將容易地進行修改和組合，這種修改和組合將落在本發(fā)明的實質(zhì)和所附權 利要求的范圍內(nèi)。
2權利要求
一種在源和目的地社區(qū)之間建立電子商務文檔從源到目的地的安全路由的方法，包括確定所述源和目的地社區(qū)相互可接受的安全策略；對于SAML服務驗證所述源；從所述SAML服務接收SAML斷言；根據(jù)封裝協(xié)議來打包所述SAML斷言和電子商務文檔；通過被信連接器將該封裝路由到所述目的地；經(jīng)由該路由將該封裝發(fā)送到目的地。
2.如權利要求1所述的方法，還包含 從所述源接收所述封裝；比較所述SAML斷言的電子簽名與所述源社區(qū)關于目的地社區(qū)注冊的電子簽名；和 根據(jù)目的地社區(qū)注冊來確定所述源社區(qū)被信任來發(fā)送電子商務文檔。
3.如權利要求1所述的方法，其中，所述路由和發(fā)送步驟還包含 通過至少一個中間社區(qū)中的被信連接器來路由所述封裝；在所述被信社區(qū)接收所述封裝，并且比較所述SAML斷言的電子簽名與所述源社區(qū)關 于所述中間社區(qū)注冊的電子簽名；獲取與所述中間社區(qū)相對應的SAML斷言；將所述中間SAML斷言和所述封裝打包在被注釋的封裝中；和轉發(fā)所述被注釋的封裝。
4.如權利要求3所述的方法，其中，在超過一個中間社區(qū)中重復權利要求25所述的接 收、獲取、打包和轉發(fā)步驟。
5.如權利要求4所述的方法，其中，只有一個中間SAML斷言隨同所述被注釋的封裝傳送。
6.如權利要求4所述的方法，還包含 在所述目的地接收所述封裝；比較所述中間社區(qū)的SAML斷言的電子簽名與所述中間社區(qū)關于所述目的地社區(qū)注冊 的電子簽名；比較所述源社區(qū)的SAML斷言的電子簽名與所述源社區(qū)關于所述目的地社區(qū)注冊的電 子簽名；和根據(jù)目的地社區(qū)注冊來確定所述源社區(qū)被信任來發(fā)送電子商務文檔。
7.—種在源和目的地社區(qū)之間在目的地處建立電子商務文檔從源的安全路由的方法， 包括提供關于所述源和目的地可以使用的所支持的安全協(xié)議的描述； 從源接收封裝，該封裝包括電子商務文檔和SAML斷言；比較所述SAML斷言的電子簽名與所述源社區(qū)關于所述目的地社區(qū)注冊的電子簽名；和根據(jù)目的地社區(qū)注冊來確定所述源社區(qū)被信任來發(fā)送電子商務文檔。
8.如權利要求7所述的方法，還包含經(jīng)由至少一個中間社區(qū)從所述源接收所述封裝，所述封裝還包括所述中間社區(qū)的SAML斷言；和比較所述中間社區(qū)的SAML斷言的電子簽名與所述中間社區(qū)關于所述目的地社區(qū)注冊 的電子簽名。
9.一種經(jīng)由封裝翻譯網(wǎng)關在源和目的地社區(qū)之間建立電子商務文檔從源到目的地的 安全路由的方法，包括確定所述源和目的地社區(qū)相互可接受的安全策略；對于第一安全服務驗證所述源；從所述第一安全服務接收第一斷言；通過被信網(wǎng)關計算經(jīng)由被信連接器到所述目的地的路由；其中，所述被信網(wǎng)關包含一個或多個服務，用于確認(validate)所述第一安全憑證、 解密所述電子商務文檔和將其重加密、將第一封裝協(xié)議翻譯成第二封裝協(xié)議、以及根據(jù)所 述第二封裝協(xié)議轉發(fā)第二安全憑證和所述電子商務文檔；根據(jù)所述第一封裝協(xié)議經(jīng)由到目的地的路由來轉發(fā)所述第一斷言和所述電子商務文檔。
10.如權利要求9所述的方法，還包含 從所述被信網(wǎng)關接收所述封裝；比較所述第二安全憑證與所述被信網(wǎng)關關于所述目的地社區(qū)注冊的電子簽名；和 根據(jù)目的地社區(qū)注冊來確定所述被信網(wǎng)關，并且所述源社區(qū)被信任來發(fā)送電子商務文檔。
11.如權利要求9所述的方法，其中，驗證所述源包含提供授權中間連接器來關于驗證所述第一安全服務的所述源的注冊入口 ；和 從所述源調(diào)用所述中間連接器，以便代表所述源來關于所述第一安全服務進行驗證。
12.如權利要求10所述的方法，其中，驗證所述源包含提供授權中間連接器來關于所述第一安全服務驗證所述源的注冊入口 ；和 從所述源調(diào)用所述中間連接器，以便代表所述源來關于所述第一安全服務進行驗證。
13.如權利要求9所述的方法，其中，所述路由包含在所述源和目的地之間的所述電子 商務文檔經(jīng)過的被信連接器的列表。
14.如權利要求10所述的方法，其中，所述路由包含在所述源和目的地之間的所述電 子商務文檔經(jīng)過的被信連接器的列表。
15.一種經(jīng)由封裝翻譯網(wǎng)關在源和目的地社區(qū)之間在目的地處建立電子商務文檔從源 的安全的路由的方法，包括提供所述源和目的地社區(qū)可以使用的所支持的安全協(xié)議的描述； 經(jīng)由被信連接器從被信網(wǎng)關接收封裝，所述封裝包括來自所述源社區(qū)的電子商務文檔 和第二安全憑證；其中，所述被信網(wǎng)關包含一個或多個服務，用于確認來自所述源社區(qū)的第一安全憑證、 解密所述電子商務文檔和將其重加密、將第一封裝協(xié)議翻譯成第二封裝協(xié)議、以及根據(jù)所 述第二封裝協(xié)議轉發(fā)所述第二安全憑證和所述電子商務文檔；比較所述第二安全憑證的電子簽名與所述被信網(wǎng)關關于所述目的地社區(qū)注冊的電子 簽名；和根據(jù)目的地社區(qū)注冊來確定所述被信網(wǎng)關和所述源社區(qū)被信任來發(fā)送電子商務文檔。
16.一種建立商務社區(qū)網(wǎng)絡的方法，商務社區(qū)具有本地注冊服務器和至少一個可用于 其他商務社區(qū)的服務，所述方法包含在至少兩個商務社區(qū)中注冊操作方案、外部端口配置和地址、以及安全憑證；建立至少一個全球黃頁服務，將對于所述網(wǎng)絡中的所述商務社區(qū)的服務的引用暴露給 所述網(wǎng)絡的成員；建立至少一個全球白頁，包含所述商務社區(qū)的服務的細節(jié)、以及所述商務社區(qū)的外部 端口配置和地址。
17.如權利要求16所述的方法，其中，所述全球黃頁服務是根據(jù)UDDI標準實施的。
18.如權利要求16所述的方法，其中，所述全球黃頁是由所述社區(qū)網(wǎng)絡中的主社區(qū)負 責的，并且新社區(qū)能夠加入所述社區(qū)網(wǎng)絡，并且變得能夠通過與主社區(qū)交換操作方案、外部 端口配置和地址、以及安全憑證，來從所述全球黃頁服務中發(fā)現(xiàn)對于服務的引用，以及從所 述全球白頁中訪問服務的細節(jié)。
19.一種建立用于將電子商務文檔從源發(fā)送到不同社區(qū)中的目的地的路由的方法，包含將所述源和目的地映射到各社區(qū)之內(nèi)的連接器；識別各社區(qū)注冊于其中的一個或多個共享社區(qū)網(wǎng)絡，并且當相似的外部端口使用相同 的傳輸/封裝協(xié)議時，在各社區(qū)的相似的外部端口之間鏈接；計算從所述源和目的地連接器到各外部端口的各社區(qū)之內(nèi)的社區(qū)內(nèi)路由；和規(guī)定社區(qū)內(nèi)連接器和跨越源到目的地的外部端口的路由。
20.如權利要求19所述的方法，其中，識別還包含訪問本地注冊，以確定是否已知從源社區(qū)到目的地社區(qū)的直接路由；并且如果不是，訪問可用于源社區(qū)的一個或多個社區(qū)網(wǎng)絡的一個或多個全球注冊，并且確定是否已知 通過從源社區(qū)到目的地社區(qū)的社區(qū)網(wǎng)絡的路由。
21.如權利要求19所述的方法，其中可替換地，識別還包含識別可用于各社區(qū)的提供 翻譯服務的一個或多個實體，并且通過該翻譯實體從各外部端口進行鏈接。
22.如權利要求19所述的方法，其中，可替換地識別包含識別屬于可用于各源和目的 地社區(qū)的社區(qū)網(wǎng)絡的一個或多個中間社區(qū)，并且通過該中間社區(qū)從各源和目的地社區(qū)的外 部端口進行鏈接。
23.如權利要求22所述的方法，其中，所述中間社區(qū)還提供從源傳輸/封裝協(xié)議到目的 地傳輸/封裝協(xié)議的翻譯服務。
24.一種電子注冊服務器，包括注冊數(shù)據(jù)庫，存儲屬于社區(qū)的連接器的一個或多個入口，其中所述入口包括連接器的身份標識；該連接器支持的一個或多個特定傳輸/封裝協(xié)議；該連接器與其他連接器對等通信和在傳輸/封裝協(xié)議之間進行翻譯的能力；和確定電子商務文檔的路由的具體傳輸/封裝協(xié)議的規(guī)則，包含與其他連接器的入站和 出站鏈接；以及商務社區(qū)模塊，運行在服務器上且耦接到注冊數(shù)據(jù)庫，其接收電子連接請求并通過提供路由數(shù)據(jù)來響應該請求。
25.如權利要求24所述的電子注冊服務器，其中，所述連接器的身份標識包含其名稱、 描述和URI。
26.如權利要求24所述的電子注冊服務器，其中，所述具體傳輸/封裝協(xié)議包含 封裝協(xié)議標識符；傳輸協(xié)議標識符；和 傳輸協(xié)議的連接器地址。
27.如權利要求24所述的電子注冊服務器，其中，所述連接器的翻譯能力包含如下能力從一種封裝協(xié)議到另一種封裝協(xié)議進行翻譯；如果給定特定封裝協(xié)議，則從一種傳輸協(xié)議到另一種傳輸協(xié)議進行翻譯。
28.如權利要求26所述的電子注冊服務器，其中，所述連接器的翻譯能力包含如下能力從一種封裝協(xié)議到另一種封裝協(xié)議進行翻譯；如果給定特定封裝協(xié)議，則從一種傳輸協(xié)議到另一種傳輸協(xié)議進行翻譯。
29.如權利要求24所述的電子注冊服務器，其中，所述連接器的對等通信能力是由缺 少具體傳輸/封裝協(xié)議的出站鏈接所指示的。
30.如權利要求26所述的電子注冊服務器，其中，所述連接器的對等通信能力是由缺 少具體傳輸/封裝協(xié)議的出站鏈接所指示的。
31.如權利要求24所述的電子注冊服務器，其中，所述能力還包含充當中心連接器的 能力，無需明確的入站或出站鏈接，其中該中心連接器至少包含一種在傳輸/封裝協(xié)議之 間進行翻譯的能力。
32.如權利要求24所述的電子注冊服務器，其中，所述能力還包含充當外部連接器的 能力，對于其他社區(qū)可見，并且能夠和與其他社區(qū)相關聯(lián)的其他外部連接器通信。
33.如權利要求32所述的電子注冊服務器，其中，所述能力還包含充當外部連接器的 能力，對于其他社區(qū)可見，并且能夠和與其他社區(qū)相關聯(lián)的其他外部連接器通信。
34.一種電子注冊服務器，包括注冊數(shù)據(jù)庫，存儲交叉社區(qū)路由、源到目的地社區(qū)路由，其中所述路由包含 與該目的地社區(qū)相對應的注冊服務的地址； 該目的地社區(qū)中的外部連接器；和由電子商務文檔的源到目的地社區(qū)路由所支持的一個或多個傳輸/封裝協(xié)議；以及 商務社區(qū)模塊，運行在服務器上且耦接到注冊數(shù)據(jù)庫，其接收電子連接請求并通過提 供路由數(shù)據(jù)來響應該請求。
35.如權利要求34所述的電子注冊服務器，其中，所述外部連接器包含所述傳輸/封裝 協(xié)議的連接器地址和連接器URI。
36.如權利要求34所述的電子注冊服務器，還包含中間社區(qū)的標識，通過該中間社區(qū) 將所述電子商務文檔路由到所述目的地社區(qū)。
全文摘要
本發(fā)明公開了一種設備和方法，該設備和方法能夠以被信和可信方式、在位于具有互異接口的社區(qū)(1605、1606)之內(nèi)的源(1611)和目的地(1612)之間路由電子文檔。
文檔編號H04L29/06GK101853433SQ201010156040
公開日2010年10月6日 申請日期2003年7月10日 優(yōu)先權日2002年7月19日
發(fā)明者克里斯托弗·克拉爾, 托德·C·克勞斯, 拉古納思·薩普拉姆, 杰亞拉姆·R·卡西, 約瑟夫·桑菲利波 申請人:開放創(chuàng)新網(wǎng)絡有限責任公司