專利名稱：注冊表驅動互用性和文件交換的制作方法
技術領域：
本發(fā)明涉及用于在商家或應用之間交換的文檔的注冊表驅動語義變換的系統(tǒng)和方法。本發(fā)明尤其涉及使用一個或多個公共可訪問注冊表來在不同接口之間變換電子商務文檔的系統(tǒng)和協(xié)議，所述文檔最好是XML文檔。
背景技術：
商家對商家(B2B)和應用對應用(A2A)電子商務正在取代用于電子數據交換的在先協(xié)議。由于使用B2B和A2A系統(tǒng)的商家致力于改善其效率，涌現出許多不兼容的平臺和互相競爭的標準。共識的需要是將文檔從一個系統(tǒng)轉換到另一個系統(tǒng)。
由于必須被應用于創(chuàng)建內嵌標記的XML的嚴格的語法規(guī)則使得計算機程序解釋和處理起來相對簡單，因此XML已經成為廣泛使用的數據類型。例如，以XML寫成的定購單可以由定購單項(entry)應用軟件處理，所述定購單項應用了解怎樣讀取用于描述購買的物品和購買人等信息的標記注釋。作為文檔編碼模式逐漸接受的XML，已經導致企業(yè)適配器工具(EAI)廠商開發(fā)了許多合法應用的XML化應用程序接口。
EAI廠商在一個應用接一個應用的基礎上，將一個系統(tǒng)與下一個系統(tǒng)橋接起來。在設計期間，通過設計實現互用性。系統(tǒng)或應用之間的連接是靜態(tài)的。應用的新版本的實施需要修改靜態(tài)連接。應用之間的路由通常是在企業(yè)內部。基于點對點開發(fā)集成(integration)邏輯。語義邏輯編碼成EAI例程。語義邏輯和句法邏輯混合在編碼中。文檔的發(fā)送方或源負責保證它們所發(fā)送的部分正是通告目標或接受方所接收的部分。與要求完整的兼容性相反，沒有模擬接口兼容程度的概念。由于其要求所有的客戶機更新到服務接口的最新版本并且同時更新這些接口，所以很難實現極好的兼容性。很難重新使用變換部分。沒有提供可公共訪問的資料庫來抓取個人變換首選或支持基于用戶簡檔的變換。EAI廠商途徑很難使變換例程從一對系統(tǒng)或應用改編到另一對系統(tǒng)或應用，并且需要大量的成本。
圖1圖解了EAI廠商途徑，其應用于將新的(incoming)定購單輸入四個不同的系統(tǒng)中的供應廠商處理。在該圖中，從三個源101，即電子數據交換(EDI)購買者、在線商店的客戶和遵從開放式應用組商家對象文檔(OAGBOD)的購買者，產生新定購單。每個源具有用于產生輸入到EAI基礎結構103中定購單的本地接口102。文件的格式可以包括EDI、XML和OAG。四個目標系統(tǒng)106包括SAP財務系統(tǒng)、SAP MRP系統(tǒng)、Biz IQ系統(tǒng)和Granger(美國農民協(xié)進會會員)發(fā)貨系統(tǒng)。由這些目標系統(tǒng)接受的文檔本地格式105包括IDOC、BAPI、OAG和自定義應用程序接口(API)。為了連接源和目標，需要克服句法和語義兩者的差別。點對點適配器104一對一對地將源文檔變換為目標文檔。甚至在利用相同句法的系統(tǒng)之間的文檔變換(諸如OAG到OAG變換)也包含不同的語義，因此需要適配器。當源或目標系統(tǒng)更新(例如Oracle財務系統(tǒng)替換為SAP財務系統(tǒng)或安裝升級的發(fā)貨系統(tǒng))時，需要寫入新的適配器。很可能EAI基礎結構保留舊的和新的適配器。當系統(tǒng)更新時，越來越多的適配器需要接受修改或替換。單一變換引擎管理變換處理并且提供變換資源。
因此，存在設計一種能夠公共管理不同接口之間的文檔變換的方法和結構的機會，從而提供實時互用性和分布式變換執(zhí)行。

發(fā)明內容
本發(fā)明涉及用于在商家或應用之間交換的文檔的注冊表驅動變換的系統(tǒng)和方法。本發(fā)明尤其涉及使用一個或多個公共可訪問注冊表來在不同接口之間變換電子商務文檔的系統(tǒng)和協(xié)議，所述文檔最好是XML文檔。本發(fā)明的具體各方面描述在權利要求書、說明書和附圖中。


圖1是現有技術的、使用點對點連接的變換處理的高級方框圖；
圖2是使用網絡服務引擎的變換處理的高級方框圖；圖3是文檔族和版本的分級圖；圖4是文檔庫、名稱空間、模式和文檔族的方框圖；圖5是文檔族成員和成員間變換的網絡圖；圖6和7是變換順序和用于實現變換順序的邏輯組件的表；圖8是包括文檔庫、名稱空間、文檔類型和模式、文檔族和變換的類圖；圖9是實現變換的軟件組件的高級方框圖；圖10是對應的行動圖；圖11圖解變換順序；圖12和13是描述確定將源文檔轉換為目標文檔的變換的優(yōu)選順序的流程圖；以及圖14和15圖解支持文檔族的管理和查找變換的搜索的用戶接口。
具體實施例方式
下面參照附圖進行詳細描述。描述優(yōu)選實施例來說明本發(fā)明而不是限制權利要求書所定義的范圍。本領域普通人員可以認識到，有許多與下面的描述等同的變換。
圖2描述以四個不同系統(tǒng)為目的地的新定購單的供應者處理。新定購單源于三個源201，即EDI購買者、在線商店客戶和遵從OAG的購買者。由這三個源210利用的本地格式包括EDI、XML和OAG。四個目標系統(tǒng)206包括IDOC、BAPI、OAG和自定義API。在該系統(tǒng)中，網絡服務引擎211使用公共句法庫(base)執(zhí)行語義變換。例如，EDI和OAG文件轉換為XML，作為公共句法庫。從XML到XML的變換處理源和目標文檔之間的語義差異。XML文檔可以重新轉換為本地格式(如EDI、OAG、IDOC或BAPI)。從XML或到XML的句法變換可以作為網絡服務引擎211的一部分來處理，或由與源201和目標206相關聯的接口或適配器202、205來處理。
網絡服務引擎211訪問包括使用公共句法庫的變換的各種變換213。這些變換可以重新使用?？梢哉{用一個以上的變換來將文檔從源語義轉換到目標語義?？梢钥紤]利用公共語義庫來進行變換，例如，將新文檔變換為被廣泛了解的、諸如用于電子商務文檔212的xCBL模式的文件模式。通過將新文檔變換為公共語義庫，降低點對點變換的需要?？梢枣溄硬⑶铱梢灾匦率褂米儞Q。變換可以是同構或同態(tài)的。即，變換不需要是完全可逆的。通常將通過先驗方法或通過在變換前或后比較源和目標語義來評價變換，以便估計變換所導致的損失程度。變換成功分值可以用來選擇從源到目標語義的變換的替換順序。通過在目標文檔中包含一個或多個用于從源文檔中獲取沒有很好地翻譯的信息的字段，可以補償變換所導致的損失。用戶可以查看這些字段，以便與源相關的用戶、目標或中間服務提供商可以響應計算機實現的變換服務的不完整性?；蛘?，利用對已經不完全地變換或懷疑沒有完全變換的的源文檔的各部分的引用，可以將源文檔和目標文檔發(fā)送到目標。這些引用可以是部分目標文檔或分離的文件，如錯誤文件。它們可以是字符串、指針或某些其他引用格式。引用可以提供給非完全變換的信息所屬于的目標文檔的一個或多個部分。對目標文檔的引用可以是目標文檔的單元(element)或小節(jié)(subsection)，或者是在單元或子部分內的具體位置。在另一實施例中，利用對源文檔的摘錄和對任意目標文檔的引用，可以將源文檔的摘錄和目標文檔發(fā)送到目標。
使用基于XML模式定義(XSD)的XML電子商務文檔、或更一般地利用編碼文本字符的字符數據的句法模式和根據文檔的邏輯結構標識存儲單元組的標記數據，圖2中部分地圖解的公共可訪問注冊表使團體管理變得容易。在需要變換的設計和執(zhí)行中，在至少一個注冊表中保持變換使重新使用變得更容易。變換的公共可訪問注冊表還可以允許分布式執(zhí)行。網絡服務引擎可以使用源、目標或中間服務的資源。一旦確定了由源和目標使用的接口，就可以從公共可訪問注冊表或從保存事先從公共可訪問注冊表獲得的變換邏輯的高速緩沖器中，獲得適合的變換邏輯。根據在一個或多個注冊表中的條目和在一個或多個資料庫中駐留的邏輯，在運行時間建立互用性。在運行時間，動態(tài)確定在源和目標之間的連接。當源或目標執(zhí)行版本變化，連接的動態(tài)確定是版本變化的原因。
公共可訪問注冊表可以提供所謂的語義中樞(hub)。公共可訪問注冊表可以保持用于提供服務(例如電子商務服務)的應用的服務描述。最好以XSD定義的格式，將到達(inbound)和發(fā)出(outbound)文檔接口注冊為服務描述的一部分。服務可以自由注冊多個接口，例如自由支持多個電子商務文檔標準(即，xCBL2.0、xCBL3.0或xCBL3.5)的多個版本，或自有支持多個文檔標準(即，xCBL、IDOC、OAG或BAPI)。文檔族概念的引入提供了一種跨多種文檔標準和標準版本以及自定義系統(tǒng)來管理模式和文檔類型的方式。文檔族將代表相同商務事件的文檔類型關聯到文檔族中。變換映射或變換將管理標準和自定義邏輯，以便在文檔族成員間轉換。使用特定變換的成本可能反映文檔的不完整翻譯。另外，根據現有經驗，通過先驗方法，或通過動態(tài)比較應用變換前和后的文件語義內容，可以將變換成功分值與變換相關聯。
首選使用XML作為公共句法庫保持變換，但不是必要的。XML是豐富的、自我描述的數據表示，其有利于聲明的映射邏輯(declarative mappinglogic)。幾種語義庫(諸如xCBL組件模型)提供一致的語義庫來利用XML的強大語義。XML文檔對語義注冊表的模擬有利于重新使用和新的變換的快速開發(fā)，從而提高現有變換的價值。使用公共句法庫甚至公共語義庫，集中于語義映射降低了開發(fā)新的變換的復雜程度。商業(yè)分析家而不是程序員可以有能力使用變換授權工具來定義XML到XML的語義轉換。
如圖3所示，文檔族允許分類或分組文檔。相關的文檔在相同的文檔族300下分組。通過文檔標識指定文檔。文檔標識符邏輯結構用于表示消息的根元素，例如XML電子商務文檔的根元素。文檔標識符可以指定文檔ID、其關系、版本和族關聯。XML和非XML文檔都可以配有標識符并且儲存在公共注冊表中。文檔標識符的屬性可以包括文檔標識符(如，名稱“Order”)；名稱空間(如，urnx-commerceonedocumentcomcommerceoneXCBL30XCB-L30.sox)；文檔庫名(如，xCBL、DTD、EDIFACT)；模式語言(如，SOX、XSDL)；版本(如，3.0)；和文檔族名(如，PurchaseOrderFamily、PriceInquir-yFamily、QuoteFamily)。文檔族通過文檔標識符以版本級的方式組織文件。在圖3中，文檔族樹300或其他數據結構用于組織單獨族310、320。例如，定購單族310可以包括一個或更多主要版本311、312、313。在類似的樹型結構中，一個或更多主要版本可以與次要版本(未示出)相關聯。版本屬性可以記錄主要和次要版本(versioning)。主要和次要版本之間可能的區(qū)別是主要版本具有需要變換的顯著變化，而次要版本不具有結構上的差異，僅僅是子元素的擴展。系統(tǒng)用戶可能公共地擴展文件的子元素而不修改文檔類型本身。該子元素擴展可以按照處理文檔類型的修改那樣的方式，作為次要版本進行處理。因此，文檔類型節(jié)點代表文檔類型模式和標記文件元素的所有模式。例如，如果擴展LineItem元素，并且該擴展類型用于定購單的實例中，則定購單文檔類型被版本化(version)。當版本化子元素時，用戶注冊新的文檔類型。它們指定父文檔類型節(jié)點并且給該父類型分配新的次要版本關系。生成版本ID并且分配給新的節(jié)點。
如圖4所示，注冊表將模式細分為名稱空間。使用模式名稱空間管理組件，可以注冊并管理XML名稱空間(如，XSD、SOX、RosettaNet、CIDX)和非XML名稱空間(例如，EDI，EDIFACT)。模式名稱空間可以具有不同的屬性，這些屬性包括名稱空間URI；名稱；分類、名稱空間狀態(tài)；有效狀態(tài)(對于XSD名稱空間)；名稱空間版本；描述；文檔庫名；模式語言(對于XSD名稱空間)；模式文件；豆罐(bean jar)文檔名；從屬名稱空間(如果有，對于XSD和SOX名稱空間)；和外部或信息URL。通常，名稱空間的不同版本具有不同的URI。例如，用于主要xCBL版本3.0 401和用于主要xCBL版本3.5 402的文檔庫可能分別具有一個或更多的名稱空間(411、412、413)和414，這可以用于支持次要版本。一種包括模式的方式是使用用于n個文件模式的n個文件。名稱空間管理員可以存儲有關名稱空間的元數據(meta data)、與名稱空間相關聯的模式文件和包含對應于模式文件的JavaBeans和類的Java罐文件。使用基于瀏覽器工具的圖形用戶接口可以用于管理注冊、激活、去激活和名稱空間族的刪除?？梢允褂弥T如XML工具的有效API之類的工具先確認公布的名稱空間涵蓋相關的模式文件。在圖4中，有兩個文檔庫401、402。每個文檔庫分別包括三個模式名稱空間(411、412、413)和414。名稱空間與模式文件421-425和426相關聯。用于為定購單(例如分別為xCBL3.0和xCBL3.5型的定購單432、433)從名稱空間族431備份樹的行動分別與特定的文件模式421、426相關聯。
圖5表示文檔族的另一個圖表，在這里描述為通過變換互連的文檔族成員的網絡。在該定購單族中，文檔501、502、503由庫(library)、文檔標識符、版本和模式類型標識。例如，文檔501A來自于xCBL庫，被標識為Order(定購單)、版本4.0、使用模式類型XSD。文檔501C也來自于xCBL庫，被標識為Order、版本3.5、使用模式類型SOX。文檔502A來自于X1 2標記庫，被標識為850文檔、版本4200、使用模式類型XSD。文檔502B是以XML標記的自定義平面文件(flat file)。這是可以用諸如模板或文字處理軟件準備的文檔類型。在該圖中，為每個文檔族成員之間的轉換方向標識單獨的變換。標識的變換類型包括Contivo映射、XST映射、XSLT映射、在XSD和SOX之間的Java類翻譯、Java子串替換和Java映射(XDK)。不同變換類型可以用于文檔族成員之間的變換和反向變換。系統(tǒng)可以用于新的或不同變換類型，例如，作為現有類的擴展。例如，從xCBL版本3.5 501B翻譯成xCBL3.0 501F牽涉應用XSLT變換。翻譯相對方向牽涉應用Java組件。通過變換互連的文檔族成員的網絡，在節(jié)點(文檔族成員)之間的互連是具有不同屬性的定向鏈接(單方向變換)的意義下，可以考慮為定向圖?？梢詰霉乃惴▉肀闅v(traverse)該網絡而避免循環(huán)或循環(huán)引用。在該圖中未示出，先驗變換成功分值或基于經驗變換成功分值可以與鏈接文檔族成員的每個變換相關聯。
圖6和圖7描述可以用于在如圖5描述的文檔族中標識變換的表。這些表可以在運行時間通過變換引擎訪問，來標識優(yōu)選的變換?？梢詫⒛承┳儞Q高速緩沖。在圖6中，通過以列出的次序應用一個或多個邏輯組件，實現從一個文檔族601向另一個文檔族602的變換。這些邏輯組件可以是Java類文件、XSLT映射、XST映射或任何其他通用或自定義變換，其適應當前和未來的文檔標準和變換標準。變換成功分值610測量從翻譯源601到目標文檔602引起的不完整性。在這個實例中，變換項(entry)由源和目標文檔屬性索引。這些屬性集包括文檔族名稱空間、族名、協(xié)議、模式語言、文檔類型、XML Qname和版本ID。當搜索變換項時，可在搜索中使用通配符。變換項可以選擇性地包括用于特殊規(guī)則603-608的標記符。自定義變換可以應用到貿易伙伴級、服務級或行動級。源或目標貿易伙伴ID可以標記為603、604，來指示特殊的邏輯組件應該用于特定的源或目標貿易伙伴。類似地，服務和行動可以標記為605-608，來表示特殊的邏輯組件應該用于特定的服務或行動。變換引擎應該使用可用的最明確的變換定義。例如，貿易伙伴的特定定義、服務和行動三元組應該被認為對于由貿易伙伴指定的變換是更明確的。在為不同的變換定義不同三元組元素的情況下，可以將分級重要性分配給貿易伙伴、服務或行動。例如，如果兩個變換匹配源和目標文檔類型，則可以認為貿易伙伴比服務更重要，這里的一個變換是專用于貿易伙伴的，而另一變換是專用于服務的。變換的其他屬性可以引出(evoke)特殊的規(guī)則。本發(fā)明不限于由貿易伙伴、服務和行動分類的特殊規(guī)則。圖7提供關于用作列611中的變換組件的邏輯組件701的附加信息。為邏輯組件710提供類型702、實現703、配置704、包(package)705和版本706。
圖8描述可以用于表示文檔族的類。這些類的某些方面對應于在圖3和4中描述的邏輯結構。文檔庫801是針對文件和模式的組織的最高級。文檔庫名由諸如“xCBL”之類的字符串表示。庫可以任意版本化802。庫版本由字符串表示。對于版本化或非版本化的庫，可以提供名稱空間811。在名稱空間中，可以存在從屬關系，如由從名稱空間類回指到名稱空間類的關系循環(huán)所指示的那樣。名稱空間的屬性包括名稱空間URI、名稱、分類、模式語言、名稱空間狀態(tài)、有效狀態(tài)、名稱空間版本和描述。這些屬性可以由字符串表示。此外，可以提供標記符和標記值來表示名稱空間是有激活的、不活動的、舊的或廢棄的。也可以提供標記符和標記值來表示名稱空間是有效的或無效的。與名稱空間相關聯的是外部鏈接803、全局元素821、模式文件824和外部文件827。在該實施例中，名稱空間可以由URL外部地鏈接到統(tǒng)一資源名。還可以提供外部鏈接803的描述。名稱空間可以鏈接到一組全局元素821。這些全局元素表示XML文檔的有效根元素名，其對應于在名稱空間中識別的文檔類型。該全局元素類可能對于其他類中保持的數據來說是冗余的。名稱空間也可以鏈接到一組模式文件824。可以提供到根模式文件和到其他模式文件盒(container)的兩個不同的鏈接。根模式文件是連接或包括其他模式文件的根文件。模擬名稱空間之中的從屬關系，允許檢索名稱空間的所有模式文件和所有從屬名稱空間，以及確保模式不被意外地移除而導致其他名稱空間處于不一致狀態(tài)。模式文件的屬性可以包括文檔名字符串和相關路徑字符串?？梢赃x擇性地提供絕對路徑。模式文件元素824由外部文件827表示。外部文件對象用于模擬文件的物理位置，并且可以由需要物理文件表示的任何實體引用。例如，外部文件可以為直接鏈接到名稱空間的豆罐文件。
在該實施例中，名稱空間通過文檔ID類812鏈接到文件和文檔族。文檔ID 812可以實際上具有到名稱空間的兩種類型的鏈接，二者之一是屬于根名稱空間，另一個用于擴展名稱空間。這支持主要版本和次要版本。主要版本文檔ID可以是沒有擴展文件的先前版本的文件的新版本。次要版本文檔ID可以擴展主要或次要版本文檔ID。主要版本文檔ID將只具有單一的名稱空間關系，其引用其中定義了根元素的名稱空間。次要版本文檔ID引用父(主要版本)文檔ID的名稱空間連同其中存在任何擴展的任何其他名稱空間。文檔ID 812可以與文檔族804、外部ID 805、文件規(guī)則813、變換映射823和XML文檔ID 822。文檔ID的屬性可以包括名稱、URI和主要替換URI。URI是利用以下三個組件自動產生的名稱空間URI、DocID名稱DocID版本。這個Doc Id URI用于引用這個DocID。如果用戶想要自定義DocID命名方案，則它們可以輸入它們自己URI，并且這在主要AltId關系中設置。用戶還可以具有多于一個命名方案，在這種情況下，其他Id關系模擬這些名稱。所有這些名稱應該是唯一的。文檔ID的屬性還可以包括顯示名稱、描述和文件版本。所有這些屬性可以保持為字符串。對于XML文檔來說，文檔ID的專門化是XML文檔ID 822。專門化的屬性可以包括XML元素名、版本類型、豆類名及主要和次要版本。作為XML的特性，關系循環(huán)指示可以表示嵌套(nested)元素的XML文檔ID。外部ID 805可以與文檔ID相關聯。外部ID 805可以是注冊密鑰或URI的別名。主要的默認鏈接和一個或多個用戶提供的別名都可以鏈接文檔ID和外部ID。
可以充分概括文檔ID規(guī)則813來支持變換、有效性和顯示映射。有時稱為變換映射的變換823是文檔ID規(guī)則的專門化。實現變換的邏輯通過一組變換組件825鏈接到文檔ID規(guī)則813。變換組件依次鏈接到外部文件827。變換映射823的屬性可以包括成本(cost)或變換成功分值、變換URI和位置URI。變換URI在注冊表中唯一標識變換映射。位置URI是可選的標識符，用于表示應該在哪里發(fā)生變換。例如，如果在網絡中只有一個主機能夠執(zhí)行變換，那么，其URI分配給位置URI屬性，并且變換/路由器將要執(zhí)行的變換發(fā)送到該主機。變換組件825的屬性可以包括變換組件URI、名稱、說明、組件類型、實現文件、包名和執(zhí)行次序。變換組件825可以作為一個組鏈接到文檔ID規(guī)則813。如果需要多于一次的變換，則執(zhí)行次序屬性確認應用變換的順序。在該實施例中，變換邏輯可以包括XSLT映射、XST映射、Java組件或Contivo映射中的一個或多個。變換組件鏈接到一組配置元素826上。配置元素的屬性可以包括名稱或值。文檔ID規(guī)則813還鏈接到一組映射上下文(context)字符串814上。如圖6和7的上下文中所述，這些字符串將文檔ID規(guī)則813與特定的貿易團體(發(fā)送/源或接收/目標團體)相關聯，或與特定的服務或行動相關聯。
如圖9所示，可以方便地通過XML變換模塊訪問用于重新得到或執(zhí)行變換的邏輯。XTM模塊由注冊表服務905支持，其服務來自本地和遠程注冊表的變換邏輯。注冊表客戶應用程序接口904保持關于變化是否從本地高速緩沖器或注冊表906或遠程注冊表中檢索的透明度。檢索到的變換或變換引用可以傳送到文檔變換應用程序接口907，在該實施例中，其包括用于各種變換類型908的資源。如果在替換實施例中，可以從也稱為文檔變換服務的文檔變換API 907中調用注冊表客戶API 904?？梢杂稍诜站用裆鐓^(qū)中或來自遠程社區(qū)的XTM模塊902調用文檔變換服務907，諸如正在向居民社區(qū)發(fā)送文件的社區(qū)。變換服務的更新可以包括添加新的變換908的類型和變換引擎907的新版本。在更新文檔變換API 907和組件變換908后，可以協(xié)調地更新在XTM模塊和文檔變換API之間的連接器?？梢詮姆蔷用裆鐓^(qū)的不同社區(qū)中調用文檔變換服務。例如，從社區(qū)A向社區(qū)B發(fā)送定購單的服務可以調用社區(qū)B中的服務。為了執(zhí)行所需的變換以便將使用社區(qū)A的語義的、準備的定購單(PO)對于社區(qū)B是可接受的，可能需要調用僅僅在社區(qū)B中的變換引擎上運行的變換。在這種情況下，社區(qū)A中的XTM模塊將調用社區(qū)B中的文檔變換API，來遠程執(zhí)行一個或多個變換，將定購單從社區(qū)A的語義轉換為社區(qū)B的語義。
變換可以在到達(inbound)消息901中標識，但是其可能最好不包括應該應用哪個變換(transform)來完成變換的詳細信息。在圖10中，將所謂互用性契約文檔(ICD)1011以像要變換的消息那樣的信封901，發(fā)送到XTM 1001。ICD可以包括變換命令的路徑和沿將文檔從源轉移到目標路徑的連接器。在一個實施例中，XTM模塊與B2B應用的社區(qū)中的連接器組件相關聯，該社區(qū)可以屬于一個或多個通信網絡。在執(zhí)行任何變換時，XTM模塊可以訪問ICD并且確定其包含的變換命令是否標識其連接器。如果沒有當前連接器或變換的XTM模塊執(zhí)行變換，則XTM模塊可以返回成功，并且可以選擇性地登錄通過事件。如果由當前XTM模塊執(zhí)行變換，則其解析變換命令，并且從注冊表客戶API 1002中獲得執(zhí)行變換的順序1002、1003。XTM從信封901中提取源文檔。它將源文檔屬性與將要執(zhí)行的第一變換相匹配，如果出現不匹配則指示錯誤。在步驟1014，其使用將要檢索并執(zhí)行的變換的列表來調用文檔變換API 1003。如果在變換處理中產生錯誤，則可以標明錯誤，或者中斷變換并且返回錯誤消息。XTM模塊1001可以實現源和變換的目標文檔的安全性、認可(non-repudiation)、調試或其它目的(未示出)。XTM模塊確定目標是否首選含有所發(fā)送的源文檔以及變換后的目標文檔，如果是這樣的話，則當在步驟1016創(chuàng)建發(fā)出的信封903時將其附加上。XTM模塊應該以線程安全的方式實現。變換后的信封903在步驟1017返回。
ICD包含在像要變換的消息那樣的信封901中，可以使用下列模式來標識所需的變換<？xml version＝“1.0”encoding＝“UTF-8”2>
<xsschema xmlnsxs＝“http//www.w3.org/2001/XMLSchema”elementForm Default＝“qualified”attributeFormDefault＝“unqualified”>
<xselement name＝“WransformationContract”>
<xsannotation>
<xsdocumentation>Transformation Instructions</xsdocumentation>
</xsannotation>
<xscomplexType>
<xssequence>
<xselement name＝“Attachment”type＝“xsboolean”minOccurs＝“0”/>
<xselement name＝“Transformation”minOccurs＝“0”maxOccurs＝“unbounded”>
<xscomplexType>
<xssequence>
<xselement name＝“Connector”type＝“xsanyURI”/>
<xselement name＝“StartDocTypeName”type＝“xsQName”/>
<xselement name＝“StartDocVersion”type＝“xsstring”/>
<xselement name＝“EndDocTypeName”type＝“xsQName”/>
<xselement name＝“End DocVersion”type＝“xsstring”/>
<xselement name＝“CommunityID”type＝“xsstring”minOccurs＝“0”/>
<xselement name＝“ComponentID”type＝“xsstring”maxOccurs＝“unbounded”/>
</xssequence>
</xscomplexType>
</xselement>
</xs sequence>
</xscomplexType>
</xselement>
</xsschema>
根據上述模式，變換命令的實例為<xselement name＝ “Transformatio” minOccurs＝ “0” maxOccu rs＝ “unbounded”>
<xscomplexType>
<xssequence>
<xselement name＝“Connector”type＝“xsanyURI”/>
<xselement name＝“StartDocTypeName”type＝“xsQName”/>
<xselement name＝“StartDocVersionID”type＝“xsstring”/>
<xselement name＝“EndDocTypeName”type＝“xsQName”/>
<xselement name＝“EndDocVersionID”type＝“xsstring”/>
<xselement name＝“CommunityID”type＝“xsstring”minOccurs＝“0”/>
<xselement name＝“ComponentID”type＝“xsstring”maxOccurs＝“unbounded”/>
</xssequence>
</xscomplexType>
</xselement>
在該實例中，源文檔類型由StartDocTypeName和StartDocVersion標識。StartDocTypeName應該是完全合格的文檔類型，在XML術語中為QName，包括名稱空間和文檔類型的根元素的本地名稱?；蛘?，利用適合的管理規(guī)定，能夠使用唯一的命名以加強在相關范圍內的唯一性。應該提供版本標識符來區(qū)別相同文件的變化。用戶可以在定購單中擴展地址元素，例如，擴展具有不同的次要版本ID而不是主要版本。EndDocTypeName和EndDocVersion標識通過變換得出的目標文檔。社區(qū)ID指定了注冊變換的社區(qū)。例如經由變換組件825，組件ID用于查找變換邏輯。
在下面的模式摘錄中表達了指定用于接收(或不接收)除變換后的目標文檔外的原始源文檔的ICD的目標的首選的實現<xselement name＝“TransformationContract”>
<xsannotation>
<xsdocumentation>Transformation Instructions</xsdocumentation>
</xsannotation>
<xscomplexType>
<xssequence>
<xselement name＝“Attachment”type＝“xsboolean”minOccurs＝“0”/>
附加標注表示是否應該附加原始源文檔。在該元素缺失的情況下，默認值可以附加文檔或不附加文檔。
圖11描述用于將文檔從源語義轉換到目標語義的變換的鏈。在該圖中，由方框表示文檔狀態(tài)，而由實線或虛線表示狀態(tài)-狀態(tài)變換。實線和虛線表示替換變換。這些變換可以是公用和專用變換，也可以是通?？捎煤蛯ｉT選擇的變換。在第一實例中，源1101希望向目標1104發(fā)送定購單。源的文檔標準或本地(native)接口為IDOC。在IODC語義內，該定購單的文檔名和版本是ORDERS2。模式類型是XSD。目標的本地接口是OAG。該文檔名是Purchase Order(定購單)。這個定購單的版本是7.2.1。模式類型是XSD。在該實例中，來自源或發(fā)送方注冊表1131和目標或接收方注冊表1132兩者的變換都要使用。這一系列變換被追蹤1141。源文檔接受源注冊表1131變換1101-1102和1102-1112。這些變換將ORDERS02文件轉換為xCBL版本4.0定購單文檔。然后，應用來自目標注冊表的兩個附加變換1103-1113和1113-1104。因此，通過應用四個變換，IDOC接口文檔轉換為OAG接口文檔。在該實施例中，公共中間語義庫是xCBL?；蛘撸ㄟ^檢查圖11，很明顯的是可以使用發(fā)送方注冊表1131的三個變換和接收方注冊表1132的單個變換來轉換IDOC接口文檔。另一路徑已經使用在發(fā)送方注冊表1131中的變換1112-1122從xCBL版本4.0轉換到了版本3.5。然后，將不需要使用具有相似功能1103-1113的接收方注冊表1132變換。此轉換的路徑選擇1141可以通過接收方注冊表中1103和1113之間的虛線解釋。這意味著目標首選使用其自身的變換用于版本4.0和3.5之間的轉換。在第二個實例中，源1121希望向目標1124發(fā)送其XYZ定購單。在1142中，使用三個變換1121-1122、1113-1123和1123-1124。此外，變換的語義庫是xCBL。使用自定義變換來將標記的平面文件轉換為xCBL版本3.5。其后，使用非自定義變換來將文件轉換為X12標記格式。雖然這些實例說明了在源和目標注冊表中存儲的變換，但可以很好地使用其他注冊表的配置，諸如單個公共注冊表，或公共注冊表和用于具有自定義邏輯組件的源和目標的補充注冊表。
在圖12和13中提供關于使用變換的源和目標注冊表的變換順序的計算的詳細內容。圖12是整體流程圖。圖13描述能夠用于跟蹤通過一個或多個文檔族成員的注冊表的路徑的多種算法中的一種。圖12從關于源文檔和源與目標的標識符的信息開始1201。源文檔由文檔類型屬性集說明。源和目標由團體、服務和行動三者說明。第一邏輯分支1202確定是否已經設置了反對變換的政策。在目標要求源來承擔錯誤變換的所有風險的情況下，可能應用這種類型的政策，所以公用變換元素的使用處于源自身的風險中。如果存在反對變換的政策，則在1211返回不能變換命令消息。通過邏輯分支1202，在1203檢索目標的文檔類型。這可以從上述的注冊表檢索。給出關于源和目標文檔的信息，在1204確定替換變換順序或路徑，其可以包括路徑的變換成功分值，還可以包括源和目標的變換首選。在1205檢查替換路徑的列表，并且標識用于產生理想的目標文檔類型的候選路徑。如果在列表中沒有出現產生理想的目標文檔類型的路徑，則在1211返回不能變換命令消息。通過邏輯分支1206，在1207選擇并提取優(yōu)選路徑。優(yōu)選路徑可以具有優(yōu)選變換成功分值，或其符合源、目標或兩者的變換首選。在1208創(chuàng)建變換命令并在1209返回。
圖13圖解從特定文檔族成員開始跟蹤通過源和目標注冊表的變換順序路徑。概括地說，算法查詢源和目標注冊表，以獲得源和目標文檔族中相同的文檔類型的交集。在該圖中沒有圖解其執(zhí)行完整性和錯誤檢查。對于多部分消息的每一部分，其確定目標文檔，并且運行用于遞歸遍歷文檔族圖的成本算法，下面的變換鏈接在文檔狀態(tài)節(jié)點之間。如果節(jié)點的文檔類型在預先確定的相同文檔類型的交集中，算法分解為通過注冊表二者的路徑。如果應用變換政策需要無損變換(最好的變換成功分值)，則忽略有損變換路徑。這種遍歷和成本是Dijkstra’s算法的變型，該算法用于解決關于其中所有權是非負數的邊緣加權(edge-weighted)的單一源、最短路徑問題。其逐一地從某些起始節(jié)點找出到所有其他節(jié)點的最短路徑。在Dijkstra’s算法中，以其加權長度的次序，從最短的開始遍歷路經，一直到最長為止。通常，可以使用從源文檔到目標文檔的可用文檔族的遍歷，并且文檔族可以足夠小，以使得所使用的特定遍歷對計算成本影響很小。
參照圖13中的流程圖，這個部分的算法開始于1204起始節(jié)點或文檔族成員，以及標識源和目標的團體/服務/行動三者。在步驟1301，計算源和目標注冊表之間的節(jié)點的交集。例如，源和目標都處理xCBL版本3.0或xCBL版本3.5文件么？如果在源和目標處理的文件語義之間沒有交集時，則變換順序不可用。參照圖11，交集可以是xCBL版本4.0和3.5(1112-1103和1122-1113)。由源節(jié)點、處理過的節(jié)點和變換順序的該處理算法保持列表。這些列表的某些或所有可以保持在堆棧中或遞歸分配和處理的變量的堆中。參照圖5，方框(如，501、502或503)是源節(jié)點，其中定向圖從源節(jié)點開始行進。根據行進進程，可以標注或不標注源節(jié)點。通過將起始節(jié)點添加到源節(jié)點列表1302開始行進。在1303和1305限制的循環(huán)和通過由1311和1324限制的內循環(huán)中處理列表。在1303，開始在源節(jié)點列表中的所謂i節(jié)點的處理。標注當前的i節(jié)點。然后，在1311考慮還沒有標注的文檔族的連接的成員。例如，參照圖5，對于i節(jié)點501B，連接的文檔族成員節(jié)點是501A、501C、501F和502C。沒有標注的連接的節(jié)點稱為y節(jié)點1311。在1312測試y節(jié)點來確定其是否在處理節(jié)點列表中，如果不是，則在1321將其加入到列表并且在1313進行處理。如果y節(jié)點在處理的節(jié)點列表中，則算法確定到y(tǒng)節(jié)點的當前路經是否好于預先計算的路徑。在步驟1313，將到達當前y節(jié)點的成本與到達相同節(jié)點的先前成本進行比較。如果當前的成本好于先前成本，則處理前進到步驟1314，在這里更新處理的節(jié)點的列表。在步驟1315，y節(jié)點被添加到源節(jié)點列表，用于后面的處理。此外，在步驟1313，如果當前成本不是更好的，則處理前進到步驟1322，在這里測試成本是否相同。如果成本相同，則在323可能使用各種標準來斷開連接(tie)。當相同的節(jié)點出現在接收方和發(fā)送方注冊表中時，一個標準是提供在接收方注冊表中的y節(jié)點的實例。另一個標準是提供在發(fā)送方注冊表中的y節(jié)點的實例。再一個標準是提供包含最少節(jié)點或轉發(fā)的路徑。在步驟1324，處理循環(huán)到1311，在這里處理沒有標注的下一個連接節(jié)點。如果處理了所有的未標注的連接節(jié)點，則下一個步驟是1305，在這里處理循環(huán)到1303，處理源節(jié)點中下一個i節(jié)點。在1305，當處理了所有的源節(jié)點時，該處理的結果在1306返回。
替換變換順序和優(yōu)選變換順序的計算可以在不同的環(huán)境中運行。下面的使用情況說明了這些環(huán)境中的某些環(huán)境。在第一種使用情況下，不需要變換。調用用于確定變換順序的模塊，但是源和目標文檔是相同類型的。不需要變換。在第二種使用情況中，在源和目標之間沒有可用變換。這種情況可能是在不同的源和目標文檔之間不能計算出變換順序，或變換政策是“沒有變換”并且源和目標文檔不同，或只接受無損變換但所有所計算出的變換順序是有損的，如它們的變換成功分值所示。產生操作異常。在第三種使用情況中，源和目標處在同一的社區(qū)中，所以僅僅查詢一個變換注冊表，并且存在有效的路徑。確定一個或更多變換順序。確定優(yōu)選的順序。在第四種使用情況中，源和目標在分離的社區(qū)中，并且存在有效路經。查詢兩個變換注冊表。與在第三種情況中相同，確定一個或多個變換順序，并且確定優(yōu)選的順序。
可以通過經驗或動態(tài)地、或更一般地通過有損語義變換的任何度量來確定上述先驗變換成功分值。根據分序和測試的組合，將先驗分值分配給變換。分值不隨著經驗改變?；诮涷灥姆种悼梢砸韵闰灧种祷蚰J分值開始，并且根據經驗調整。例如，可以應用下面解釋的用于動態(tài)計算成功的方法，用于使用的所選擇的變換，并且更新對應的變換成功分值，例如作為加權或移動平均數，不是放棄最舊的歷史成功分值就是分配相對的權來忽略并表示成功分值。動態(tài)確定成功分值的一種途徑是將變換應用到候選文件并且分析變換的文件。變換應用到源或中間源文檔，產生目標或中間目標文檔。列出源和目標文檔的元素的內容(在XML或相似的文件中)，例如頻率表。無論差異是正數還是負數，源和目標頻率之間的差異降低變換成功分值。選擇性地報告差異。成功分值可以依賴于元素內容之間的精確匹配，或通過程度加權。下面的實例幫助說明動態(tài)評分的途徑。分值文件片斷是<NameAddress>
<Name>Pikachu Pokemon</Name>
<Addressl>125 Henderson Drive</Addressl>
<City>Pleasanton</City>
<State>CA</State>
</NameAddress>
變換的目標文檔片斷是<NameAddress>
<Name>Pikachu Pokemon</Name>
<Street>Henderson Drive</Street>
<HouseNumber>125</HouseNumber>
<City>Pleasanton</City>
<State>CA</State>
</NameAddress>
根據源文檔片段的元素和調整(key)到精確匹配的頻率比較是

對應于在目標文檔中作為字段逐字出現的源文檔中的字段的片段的動態(tài)成功分值，可以表示為75％成功，或25％成本被分配給該實例。由于目標文檔的房屋號元素匹配源文檔的地址1元素的一個標簽，如果算出部分匹配，則分配給不同的分值。成功分值可以對應于源文檔字段(其將逐字地出現在目標文檔的字段中)中的文本的片斷。為某些目的，分值順序的應用需要計算總成功分值。當單個分值組合為總變換成功分值時，組合可以是相加、平均或相乘。構造總變換成功的方法可能順序考慮這些變換(這與成功分值的相乘組合是相同的)，或者可能積累(不合成)錯誤(這與成本的相加組合是相同的)。例如，在相乘組合中，如果變換是T1、T2和T3，則可以為三個變換中的每一個計算有損百分比，并且組合為(1-T1)*(1-T2)*(1-T3)。通常，總變換成功分值可以是從源到目標文檔的有損變換的變換順序的任意度量。
在圖14和15中圖解了用于管理文檔族信息并用于搜索變換的用戶接口。圖14描述用于支持文檔族管理的用戶接口。文件樹1401顯示文件1402的主要1403和次要1404版本的分級的相互關系。對于族，在1411顯示族成員的公共文檔族信息。圖15描述支持搜索的用戶接口來找出可用變換，例如，來準備新變換順序。在1511顯示的結果標識變換順序的一部分23，該順序用于將源文檔(定購單、CBL、SOX、Y、200)從xCBL版本2.0轉換到版本3.0。使用標準1501或高級1502查詢接口指定搜索標準。結果中的一或多行1512可以被刪除或者用于創(chuàng)建新變換1513。在該實例中，通過所表達的發(fā)送方1514或接收方1515的首選、變換1516的成本或有損性和實現變換順序1517的邏輯組件，來改變返回的變換順序。
盡管已參照本發(fā)明的詳細優(yōu)選實施例和實例描述了本發(fā)明，但是將理解的是，這些實例適用于說明而不是用于限定的。計算機輔助處理暗含在描述的實施例中。因此，可以以計算機輔助處理、包含邏輯來實現變換處理的系統(tǒng)、具有邏輯來實現變換處理的媒體、具有邏輯來實現變換處理的數據流或計算機可訪問變換處理服務實現本發(fā)明。但本領域內的普通技術人員將理解的是，可在不背離由所附權利要求書限定的本發(fā)明宗旨和范圍的前提下對本發(fā)明進行各種形式和細節(jié)上的修改。
權利要求
1.一種變換使用源語義版本編碼并且向目標發(fā)送的文檔的語義計算機輔助方法，包括從接口注冊表中確定由目標使用的至少一個目標語義版本，所述接口注冊表包括目標使用的語義版本；從文檔族注冊表中標識將文件從源語義版本轉換到目標語義版本的一個或多個變換，文檔族注冊表包括由文檔族成員使用的語義版本和語義版本之間的可用變換；及將所述變換應用到所述文檔。
2.如權利要求1所述的方法，其中文檔族注冊表是可訪問的，但區(qū)別于源和目標。
3.如權利要求2所述的方法，其中文檔族注冊表是公共地保持的。
4.如權利要求1所述的方法，還包括接收文件并且輸出轉換過的文件。
5.如權利要求1所述的方法，其中語義版本包括通過系統(tǒng)區(qū)分的主要版本和在特定系統(tǒng)標準中通過發(fā)布版本區(qū)分的次要版本。
6.如權利要求1所述的方法，其中對于文檔族注冊表包括關于文檔族成員的系統(tǒng)標準標識符、文檔標識符、發(fā)布版本和模式類型。
7.如權利要求1所述的方法，其中變換包括Contivo映射、XSLT映射、XST映射、XSD-SOX類和JAVA映射中的一個或多個。
8.如權利要求1所述的方法，其中由文檔族注冊表支持的變換包括Contivo映射、XSLT映射和JAVA映射。
9.如權利要求1所述的方法，其中應用變換包括使用與文檔族注冊表的處理資源不同的源處理資源。
10.如權利要求9所述的方法，其中應用變換還包括從公共地保持的變換資料庫中檢索變換。
11.如權利要求10所述的方法，其中從公共地保持的資料庫中將變換取回到本地資料庫中。
12.如權利要求11所述的方法，其中在應用前檢查在本地資料庫中的變換的通用性。
13.如權利要求1所述的方法，其中依據附加的源和附加的目標的語義版本，所述變換對附加的源和附加的目標是可重新使用的。
14.如權利要求1所述的方法，其中當源語義信息的變換令人懷疑時，應用變換包括在轉換過的文檔的用戶可見字段中保存文檔的源語義信息。
15.如權利要求1所述的方法，還包括根據變換成功分值在替換變換中選擇變換。
16.如權利要求1所述的方法，其中文檔族注冊表分布在多個物理設備中。
17.一種陳列可應用于文檔族的語義變換的計算機輔助方法，包括保持文檔族注冊表數據結構，對于特定的文檔族包括由庫、文檔標識符、發(fā)布版本和模式類型標識的文檔族成員；文檔族成員之間的語義變換，包括遠程執(zhí)行來實現語義變換的邏輯；源和目標文檔族成員和語義變換的關聯；通過提供將要遠程執(zhí)行的邏輯，響應用于語義變換的請求。
18.如權利要求17所述的方法，還包括遍歷文檔族成員之間的語義變換的關聯，以及標識從源文檔族成員到目標文檔族成員的一個或多個變換的一個或多個順序。
19.如權利要求18所述的方法，其中保持語義變換還包括保持變換成功分值；及響應請求還包括計算變換的順序的綜合成功分值。
20.如權利要求19所述的方法，其中變換成功分值對應于從源文檔的字段逐字地翻譯成目標文檔的字段的片斷。
21.如權利要求19所述的方法，其中變換成功分值對應于在目標文檔的字段中逐字地找出的源文檔的字段中的文本片斷。
22.如權利要求17所述的方法，其中保持文檔族注冊表數據結構還包括保持對應于在文件交換中的一個或多個參與者的、將要應用的變換的特定規(guī)則；及通過提供將要遠程執(zhí)行的邏輯的響應通過引用與文檔族注冊表數據結構分離地保持的、專門保持的變換來實現。
23.一種選擇可應用于文檔族的語義變換的計算機輔助方法，包括保持文檔族注冊表數據結構，對于特定的文檔族包括由庫、文檔標識符、發(fā)布版本和模式類型標識的文檔族成員；文檔族成員之間的語義變換，包括遠程執(zhí)行來實現語義變換的邏輯；源和目標文檔族成員和語義變換的關聯；通過將文檔族注冊表數據結構作為定向圖遍歷并且輸出通過遍歷確定的一個或多個變換順序，響應用于將文件從源語義版本向目標語義版本轉換的語義變換的請求。
24.如權利要求23所述的方法，其中保持語義變換還包括保持變換成功分值；及遍歷文檔族注冊表數據結構還包括計算變換順序的綜合成功分值。
25.如權利要求24所述的方法，其中變換成功分值對應于從源文檔的字段逐字地翻譯成目標文檔的字段的片斷。
26.如權利要求24所述的方法，其中變換成功分值對應于在目標文檔的字段中逐字地找出的源文檔的字段中的文本片斷。
27.如權利要求17所述的方法，其中保持文檔族注冊表數據結構還包括保持對應于在文件交換中的一個或多個參與者的、將要應用的變換的特定規(guī)則；及
28.輸出還包括引用與文檔族注冊表數據結構分離地保持的、專門保持的變換。
29.如權利要求17所述的方法，其中保持文檔族注冊表數據結構還包括保持對應于在文件交換中的一個或多個參與者的、將要應用的變換的特定規(guī)則；及輸出還包括引用安全地保持在文檔族注冊表數據結構中的、專門保持的變換。
全文摘要
本發(fā)明涉及用于在商家或應用之間交換的文件的注冊表驅動變換的系統(tǒng)和方法。本發(fā)明尤其涉及用于使用一個或多個公共可訪問注冊表來在不同接口之間變換電子商務文檔的系統(tǒng)和協(xié)議，其中文檔最好是XML文檔。在權利要求書、說明書和附圖中描述了本發(fā)明的各特定方面。
文檔編號G06F12/00GK1685312SQ03822498
公開日2005年10月19日 申請日期2003年7月10日 優(yōu)先權日2002年7月19日
發(fā)明者克里斯托弗·T·英格索爾, 杰亞拉姆·R·卡西, 亞歷山大·霍姆斯, 邁克爾·克拉克, 阿肖克·阿萊蒂, 薩蒂什·B·K·塞納西, 海倫·S·尤安 申請人:Jgr阿奎西申公司