OpenAdaptor白皮書

介紹

?

競爭不斷地要求如今的企業集中他們的能力，迅速地結合，移動和度量他們的電腦系統，以滿足不斷改變的市場需求。

成功的公司必須確保他們的系統是通過無縫地結合多個應用軟體來建造的。

IT 基礎設施不僅要設計得強大，可靠，而且要靈活，可升級，以滿足以後的新要求。

openadaptor^TM 是能夠對付這些挑戰的解決辦法。

opendaptor^TM 公司提供他們結合資料所需要的，應用軟體之間的資訊流，也就是資料來自何處，誰對它感興趣，以及該資料怎樣能被每個系統使用。明確地，它將資訊的提供者和消費者分離開來，這樣就產生了不受資料實際位置影響，不受要訪問資訊的消費者數目影響的，靈活的系統。這樣，資訊就可以在系統之間結合，而不需要用戶化每一個應用軟體。

?

什麼是 openadaptorTM ？

openadaptorTM 是一個用 Java 語言編寫的軟體工具包，一個適配器框架。這一適配器框架的目的是要簡化多個系統之間的結合，而這些系統不結合就很難共用資料。

在大組織里存在連接多個不同的系統，以相互傳送資訊的要求是很正常的。這通常都需要一條專用的，點到點的資料連線，以及用戶化的編程，以允許系統相互交談。隨著新系統的產生，專線的數目和用戶化編輯都增加了，最終產生了資訊流動中的瓶頸。

?

一些組織通過開發像應用程式之間的資料代理一樣的中間件產品，從而專注於這一問題。中間件大大地減低了系統體系結構的復雜性，因為每個新的資訊提供者都在相同的中心介面程式中編碼，而該程式通過網路與其他程式建立連接。因此，隨著新應用程式的引進，只要編寫一條資訊介面與系統的其他部分通話。



不幸地，中間件解決辦法也有它的局限性。當它為某個中心點提供通信時，它就不能自動化自定義介面編程。另外，中間件產品還使組織受困于信任某些產品賣主。

openadaptor^TM 通過創建一個應用軟體管道設備解決辦法，專注於該問題，這一辦法自動化了系統結合所需的自定義編碼的大部分。它通過為開發者提供一組標準的，能用來連接系統與系統，或系統與中間件的連接器，或適配器，來做到這一點。

openadaptor^TM 現在為以下傳送器或產品提供一組標準的適配器：
- TIBCO ETX 和 Rendezvous
- IBM MQ 系列
- JMS
- JDBC
- RMI
- Flat Files
- 插座

?

openadaptorTM 也提供關於系統結合問題的適配器，如文件轉換，過濾和充實，以及對資料交流標準的支援，如 XML ， FIX ， SWIFT 等。該產品能做的事情要將處理和標準檢測除外。所有這些種類的適配器都可以無縫地結合到出版和訂閱系統中去。

openadaptorTM 解除了開發者們對某一個中間件提供者的依賴，因為它為許多不同種類的中間件介面提供適配器。這是通過代碼包實現的，它提煉介面協定要求，并將適當的介面 openadaptorTM 框架與潛在的中間件產品一起使用。

新適配器可以迅速地，簡單地執行。感謝 openadaptorTM 的 open source 許可，一旦某個工程生產了一種新的適配器類型，它可以自動地產所有工程使用。

對行業標準的支援
openadaptorTM 被設計來利用現存的標準。例如，資訊可以先映射為 XML ，通過資訊基礎設施進行傳送，然後重新映射成網路中每個訂閱系統所要求的特定資訊格式。

可升級
openadaptorTM 出版 / 訂閱 包含了一個內在的可升級的設計，它確保成長，而不犧牲性能。這樣就使新系統迅速地，簡單地連接，而不影響生產能力。這樣，組織就可以在全球范圍內結合應用軟體。

?

普通特徵
openadaptorTM 普通介面標準允許的企業級的功能執行有：
。資料壓縮 -- 壓縮減少帶寬瓶頸。
。例外處理 -- 建立和維護資訊醫院，它們是介面，保留了一些因為某些原因而不能處理的資訊。這些例外資訊被修理，然後送回去重新處理。
。標準檢測 -- 允許對比性地測試元件運行得怎麼樣，特別是相互關聯的元件。
。程式管理 -- 提供簡單的工具運行和監控 openadaptorTM 程式。這包括一個瀏覽器介面上的遠端控制功能，以及記錄功能。

使用 openadaptorTM 的優勢
。未來證明 -- 通過將應用軟體聯合或分離，這樣就使介面在系統環境中更可維持。對介面的改變被掩蓋在 openadaptorTM 通用介面的後面。相似的， openadaptorTM 使取代過時應用軟體大大地變易。
。重新使用 -- 全球性的 openadaptorTM 框架提供重新使用應用軟體代碼所必需的框架。

容易使用
每個 openadaptorTM 適配器都是用一個簡單的配置文件定義的。因為 openadaptorTM 提供一套有現貨的元件，因此有可能建造一個適配器而根本不用編寫任何實際的程式碼。

更多資訊
你可以在 openadaptorTM 的網站中找到更多關於 openadaptorTM 的資訊（ http://www.openadaptor.org ）。

?

openadaptorTM 框架

?

openadaptor^TM 框架是一個以資訊為基礎的系統集成工具包。系統集成工作，簡單的可以像處理一個文件一樣，復雜的可以像建立系統之間的即時饋送一樣。

該框架提煉在系統（或傳送器）之間發送資訊的程式。它提供一個已經建造好了的元件框架，可以馬上組裝起來集成系統（通過使用簡單的配置文件，而不是編寫實際的程式碼）。

該框架現在允許適配器的建造（這一框架也將被擴充，允許以資訊為基礎的服務和閘道的建造）。

適配器是一個或多個起源地與一個或多個目的地之間的單向連線。起源地和目的地可以是一些不同的東西，如平面文件， TCP/IP 插座，資料庫，特定系統 API （應用編程介面），中間件， RMI 服務， JMS 佇列等。

發送資訊所要求的不同工作步驟如下所示：



首先，要有與起源地的連接（連接器）。一旦做到了這一點，還要有一些資料憑以壓入和拉出的機制（協定）。那時資料就被轉換成資訊（資訊格式化）。在目的地連接那里也反過來進行同樣的步驟。

?

還有一些其他的選擇性功能：

。壓縮和加密
出於性能的原因而將資訊壓縮（和解壓），和 / 或為安全目的而加密（和解密），都是必要的。

。資料充實
充實資訊的內容是正當的。這要以對另一個系統的查看為基礎，或是以嚴重編碼的規則為基礎。檢查資料的統一性，以及資訊內容的完整性都是有必要的。

。資訊過濾
以內容為基礎確認某些種類的資訊可能也是正當的。這可能是出於放棄這一資訊，或是對它應用特別規則的目的。

。資訊轉換
它涉及將資訊從一個系統翻譯到另一個系統，以確保相容。

。例外處理
被拒絕了的資訊需要特別的對待和處理。

?

一個適配器是一個單獨的程式 -- 每個原始資料元件都是作為一個單獨的執行線程運行的。以下是一些很簡單的適配器的例子：

例 1 ：


該適配器讀取來自資料庫的資料，然後將它發布給 TIBCO （一個出版 / 訂閱基礎設施）。

例 2 ：



該適配器從一個 MQ 序列拉出資訊，以內容為基礎，過濾該資訊，然後將它寫入一個文件。

導管可以像雛菊花環一樣串起來。這樣設計提供了高度的模組性和配置性。它像 UNIX 外殼中使用的命令行導管。一個典型的適配器如下：

?

適配器并不限定於線性結構。扇入和散開適配器也可以創建，像這樣：


或像這樣：


或可能像這樣：



或甚至像這樣：

?

openadaptor^TM 現在提供以下種類的已經建造好了的原始資料和接收器：

平面文件：

允許對平面文件進行讀和寫。它對於移動工作和測試是很有用的。這些元件是不能交易的。

插座：

允許對 TCP/IP 插座進行讀和寫。它使用簡單的協定進行換手和事項協調。

JDBC

允許對相關的資料庫的資料進行讀和寫，如 Sybase, Oracle, MS SQL 伺服器。

RMI

允許將該適配器介紹為一個 RMI 服務，或是向 RMI 服務發送資訊。

TIBCO ETX &Rendezvous

允許出版和訂閱 TIBCO 中間件產品。

MQ 系列

允許對 IBM MQ 系列中間件進行讀和寫。

JMS

允許向 JMS （ Java 資訊服務）序列和主題收發資料。

另外，一些工程已經為某些特定的系統（如 Fidessa 和 DROM ）編寫了原始資料和接收器元件。

原始資料和接收器主要是負責支援起源地和目的地的傳送器和協定。內部地， openadaptor^TM 聲稱資料是叫做 DateObject （看第 13 頁的 DataObject ）的自我描述的資料結構。框架內的資訊被描述為 DataObjects 序列。 openadaptor^TM 已經開發了一種可以用來描繪 DataObjects 序列的，以 ASCLL 碼為基礎的字串格式。這一格式也支援壓縮，并且將被擴充，支援安全功能，如加密和資訊領會。這一格式被稱作 DataObject XML 。

在沒有特定的 API （應用編程介面）時，這就是起源地和目的地之間交流的資料格式。如果那時使用了文件接收器，默認行為就是將一則資訊作為 DataObjectXML 寫出來。

?

然而，還是有可能接通不同的資料格式。 Source 可以被分配為一個能將不同種類的以 ASCLL 碼為基礎的格式轉換為 DataObjects 的閱讀器。相反的，接收器可以被分配為一個能用 DataObjects 為生不同種類的以 ASCLL 碼為基礎的格式的復寫器。現在， openadaptor^TM 只提供一些普通的閱讀器和復寫器，以支援定界領域，固定帶寬領域，以及 XML 。 openadaptor^TM 還為容易執行的自定義格式提供框架。一些貢獻者正致力於標準資料格式，包括 SWIFT 和 FIX 。

openadaptor^TM 現在提供以下種類的普通導管元件：

別名：

允許資訊結構和內容的轉換。

過濾：

允許以結構和內容為基礎放棄或發送電報。

例外處理：

允許抓住應程式例外，并且改道發送資訊。

加密：

允許以資訊內容和種類為基礎，將之加密（解密）。

審計：

允許記錄已經被成功地處理的消息的資訊，以及察覺復制的應用程式消息。

典型的工程都是通過結合和配置這些普通導管，或在自定義導管中編寫少量的代碼，來執行自定義行為。

?

DataObjects

DataObjects 是 openadaptorTM 作為基礎的基本資料結構。當某則資訊被稱作是 openadaptorTM 出版 / 訂閱基礎結構（ ETX ）資訊時，它實際上是意味著某些 DataObjects 的連續表示。當某個程式要將資訊發布到出版 / 訂閱基礎結構時，或是要將資訊寫入某個文件時，它就需要創建 DataObjects 。

DataObjects 是在 openadaptorTM 適配器中內部地使用的。在 Source 元件中產生的資訊，擠過導管，然後在接收器元件中結束，這就是 DataObjects 的序列。

在最簡單的級別， openadaptorTM 可以被認為是一個 名稱 - 值 線對的集合 -- 該集合有一個種類，并且每個 名稱 - 值 線對都被叫做一個屬性。例如，一個類型為 "Person" 的 DataObject 可能有兩個屬性，名字和年齡，這些屬性各自的值可能為 Fred 和 21 。

為了支援更復雜的資料結構，某些屬性的值不應該只是原始值（整數，雙數，字串，布林值，等）；它也可以是 DataObjects 的一個序列。例如，一個類型為 "Team" 的 DataObjects 可能有兩個屬性，名稱和成員；這些屬性各自的值可能是 openadaptor 和 DataObjects 中的一個 Person 序列。

DataObjects 被開發出來了，因此就有一種簡單的輕便的資料結構可以在服務和應用軟體之間交流。 openadaptorTM 最重要的方面就是自我描述。這就意味著任何寫得很好的代碼都可以收到任何 DataObject ，以及提取資訊。

?

控制器

下圖說明了一個正在運行的適配器中所有在工作的元件：



像原始資料，導管和接收器一樣，也有一個控制器。控制器負責為動 source 元件中線程，協調元件之間的通信，以及管理事項。

每個 source 元件在一個單獨的線程中運行。在所有的元件都被初始化了之後，控制器為動所有這些線程。

當 source 元件創造了一則資訊時，它將向控制器請求下一個可用的事項。

然後 source 元件會將資訊傳送給控制器，控制器就將它傳送到管道中的下一個元件，等等。這是一個同步的呼叫，如果資訊成功地處理，最終將返回 source, 否則就會產生例外。

如果 source 元件收到了例外，它將退回這一事項，否則，它會答應負責這一事項。

控制器負責傳播呼叫，以開始，提交和退回事項。

¹ 也可以選擇性的有一個遠端控制器和遠端記錄器。遠端控制器可以在適配器運行時，與之相互影響，并管理它。遠端記錄器可以過濾適配器，并向遠端客戶廣播資訊。
² openadaptor^TM 現在提供一個控制器的執行。它叫做簡單控制器，也是默認控制器。使用配置文件可以推翻這一點。

?

DataObjects 字串閱讀器和復寫器

DataObjects 字串閱讀器和復寫器是用來在 DataObjects 和字串表示法之間進行轉換。它們主要是被引進來，為接收器和 source 的擴散提供解決辦法的。以前的 openadaptorTM 版本包含了以定界的，固定帶寬的，私人擁有的格式文件為基礎的接收器和 source 的變體。除了這一點，像 MqSink 等接收器還提供固定帶寬格式化。如果某個開發者想要處理一個自定義文件格式，那時他就要編寫一個自定義 source 元件。

從今以後，每個傳送器就都只有一個接收器和 source 。每個接收器和 source 都能夠分配一個 DOString 復寫器和閱讀器。當某個 source 被分配了一個 DOString 閱讀器時，它就會把將字串轉換成 DataObjects 的任務委托給閱讀器。

這就意味著 DOString 閱讀器和復寫器可以與接收器和 source 聯合起來，以產生每一個功能結合。那些想要讀（或寫）一個自定義文件格式的開發者，現在只需要編寫一個閱讀器（或復寫器）。通常這只是一個執行 chop 和 stick 方法的問題，這兩種方法將記錄砍成欄位字串，或將欄位字串粘貼成記錄。

?

資訊醫院

在理想的世界中，資訊在系統之間相互發送，并且每個系統都能夠成功地處理每則資訊。明顯地，事情并不是這樣的，應用軟體和系統通常要拒絕某則資訊，然後繼續處理。

資訊醫院可以被認為是不受任何適配器處理的， DataObjects 的修理佇列。現在已提供了一個使用 Sybase 和一個命令行介面的基本執行。還有一些帶有資訊醫院的，用來集成適配器的適配器元件，在例外發生時接納資訊，并在晚一點的時候排出資訊。

?

為什麼一個框架就好了？

一個框架給了我們以下好處：

標準化
因為每個適配器都建立在相同框架的基礎之上，所以它們都擁有相同的 " 外觀和感覺 " 。從支援和維護的觀點看，這是一個很大的好處。

發展速度
因為 openadaptorTM 提供一套有現貨的元件（ source ，接收器和導管），因此有可能不用編寫任何代碼就能建造一個適配器。

靈活性
與為每個需要建造特定的適配器相反，一個框架允許我們動態地配置適配器。簡簡單單地改變一個文本配置文件，該框架就允許動態地混合和匹配不同的 source 和接收器元件。這在測試中會有幫助，因產可以用一個能夠讀取測試實例文件，或指定一則產生問題的資訊的文件 source ，來代替一般的 source 。

隨意用戶化
在某個工程需要建造特定工程 source 和接收器（如某個老的套接協定的橋接器）時，就可以遵照 source 和接收器框架介面建造。它馬上就可以用配置將文本拉入那一適配器 -- 就跟預先建造的元件一模一樣。開發者只需要編寫最小部分的代碼，因為其他的是免費獲取的。

用於重新使用的平臺
因為框架元件定義得很好，并且可以在運行時結合起來，因此開發工程要建造一些能被更廣泛的工程重新使用的元件是很容易的。標準檢測工具允許對元件進行單元測試。

普通功能
一個框架免費提供普通功能，這樣減少了冗余和重復。另外，該框架所有的用戶，只需要最小的努力，就可以馬上獲得框架更新的好處。

?

openadaptor^TM 框架包含的普通功能有：

- 錯誤記錄和通知
- 程式管理和監控
- 例外 / 修理佇列
- 資訊壓縮和安全
- 標準檢測和回歸率測驗

?

商標

openadaptor^TM 是 Dresdner Kleinwort Wesserstein 公司的商標。

此文件中使用的其他產品商標是它們各自所有者的財產。

?

openadaptorTM 簡史

?

看看軟體發展的前後關系通常都是很有趣的。

1997 年， Dresdner Kleinwort Wesserstein 公司（那時的 Dresdner Kleinwort Benson 公司）決定大修它的資訊技術系統，以并入當時可用的最好的技術解決辦法。

很明顯，這樣會涉及大量的集成和移動工作。出版 / 訂閱被看作是能做這一工作的主要的技術范例。這一工程叫做 Dealbus 。

有很多產品受到了評估，并且， TIBCO 企業事務快車（ ETX ）和 TIBCO Rendezvous 被選為那時最好的品種。 TIBCO ETX 和 Rendezvous （ Dealbus 的基礎設施）最初是在倫敦大量生產的。負責這一基礎設施的小組曾經在法克福，紐約，東京和香港安裝了節點。

它提供了基本的基礎設施，但還有一些重大問題不能解決：
1 　 我們怎樣才能使工程容易地使用這一基礎設施？
2 　 我們怎樣避免賣主禁閉？
3 　 我們怎樣才能控制人們用它來做什麼，明確地，也就是匯流排上的資訊格式將是什麼？

同時，有一些工程正在建造使用 CORBA 的分散式系統。一致同意， COBRA 服務傳達的資料與匯流排上發行的資料要是相同的格式。另外，它還要以 ASCLL 碼為基礎，并且是自我描述的。這樣就產生了 DataObjects 和 DataObject 轉換器。它原本是用 Java 語言編寫的，作為使用 COBRA 的分散式系統的一部分。

1998 年中， DataObjects 和 DataObject 轉換器被引入到了被開發來提煉 TIBCO 產品 API （應用編程介面）的 C++ 和 C++ 程式庫。這就是人們了解的通用出版 / 訂閱程式庫。現已開發了一些通用應用軟體，允許來自 Sybase 資料庫和平面文件的出版和訂閱。開發了 COBRA 服務之後， Java 應用軟體也可以出版和訂閱。這一工作形成了 Dealbus 軟體早期版本的基礎。

?

這時， XML 作為一個不斷成長的資料交流標準冒了出來。 DataObjects 轉換器被增強了，以將 DataObjects 佇列描述為 XML 文件。這就是知名的 DataObjectXML 。

Dealbus 下一版本的驅動因素就是，使用出版 / 訂閱基礎設施，開發者們不需要編寫軟體這一基本觀念。它包括連接到 TIBCO ，以及我們所擁有的任何內部系統，也包括與資料轉換，資料充實，統一性檢查和例外處理相關的典型工作。在我們的觀念中，勾入 Dealbus 只是一件幾分種和幾小時的事情，而不是幾天和幾周。另外，通過提供一個框架和已經建造好了的元件，我們可以確保可靠性，通過重新使用，我們可以將行為標準化。這就是 Infobus 適配器框架（ IBAF ）。

該適配器框架，允許開發者們通過編寫配置文件，而不是軟體來建立系統和出版 / 訂閱基礎設施之間的連接。這一配置文件指定那些像雛菊花一樣串起來的，已經建造好了的元件，與 UNIX 命令行中的導管的工作方式是一樣的。如果用戶要執行一些已建造好了的元件不提供的功能，就會提供框架來執行這些功能。苛刻一點的就是，開發者需要編寫可能的，最少的代碼。

Dealbus 框架的第一版于 1999 年初發行。在核心框架沒有重大改變的同時，已建造好元件的數目和框架功能卻在繼續擴充和發展。最近的版本包含完整的 Java 源代碼。 Dealbus 開發小組以外的開發者捐獻數目繼續增加。

最重要的改變就是認識到了，這一框架并不是具體針對 TIBCO 基礎設施和出版 / 訂閱的。越來越多使用 Dealbus 的工程不再使用 ETX 和 Rendezvous 了。 Dealbus 框架真的是一個以資訊為基礎的，系統集成和移動工具包。現在，在 Dresdner Kleinwort Wesserstein 公司中有 50 多個使用 Dealbus 軟體的工程。