擁抱面向遺留領域的 SOA

面向服務的體系結構（Service-Oriented Architecture，SOA）正逐漸被廣泛接受，但整個行業在方法、經驗水平以及對如何將 SOA 應用到企業 IT 環境的理解之間存在較大的差異。本文將探索如何使用基于 SOA 的技術將關鍵業務功能作為業務服務公開，從而擴大遺留平臺（如大型機）的 IT 投資回報。

面向服務的體系結構（SOA）是存在時間已超過 20 年但一直未得到廣泛應用的技術之一。但由于 Web 服務的出現以及隨后被廣泛接納，SOA 終于迎來了自己的“春天”。就開發體系結構方面而言，SOA 是將來的一個發展趨勢。SOA 將數據和信息作為服務公開的模型使其成為了一個非常強大的概念，與當前的應用程序構建塊范例截然不同。當與廣受追捧的普及計算（ubiquitous computing） 或效用計算（utility computing） 模型（在此模型中，可以像在手電筒中添置和拆卸電池一樣添加或刪除處理容量）結合使用時，SOA 可提供巨大的大型企業計算潛能。

SOA 中一個正在逐漸受到廣泛關注的領域是遺留應用程序的生命周期增長。本文說明了一些很有幫助的方法，以便通過 SOA 從遺留應用程序和大型機應用程序獲得更大的投資回報（ROI）。大型機技術是一項非常成熟的技術，在本文中，您將了解各種方法，以通過為這些大型機應用程序提供 SOA 支持來延長其生命周期，從而便于信息技術（IT）組織繼續利用大型機投資。

向面向服務的世界進發

SOA 的基本思想是將企業或組織封裝在服務 組成的構造中，其中從數據到邏輯和業務功能都成為了某種類型的服務。

例如，可以使用一個采取以下方式公開功能的服務：傳入一個郵政編碼后，服務將返回關聯的地區名稱。盡管這并不特別復雜，但更為復雜的服務可能會涉及多個后端數據源、業務流程等等。

這些事務間的粘合劑主要是 Web 服務，Web 服務通常在超文本傳輸協議（HTTP）的基礎上使用簡單對象訪問協議（SOAP）。我之所以用“主要”一詞，是因為還可以通過其他方式連接到使用 IBM WebSphere® MQ 等技術的 SOA 總線。

回頁首

大型機是否已成為歷史？

大部分企業級組織都擁有大型機。這些大型機要么用于數據中心，要么仍然在執行核心的業務關鍵型功能。而且不難發現，這些大型機內應用的基礎技術的存在時間均已超過了 15 年。

COBOL 就是其中之一，目前仍是企業大型機環境日常操作中很重要的一部分。事實上，Gartner Group 于 1999 年指出，仍然存在超過 2000 億行 COBOL 代碼。來自 Gartner 的最新消息表明，從那時起，COBOL 業務應用程序的數量并未減少。TSG Inc. 的總裁 Bill Ulrich 指出，新 COBOL 代碼的數量以每年 5 百萬行的速度遞增，與 15 年前相比，IBM 的大型機事業部銷售的成套產品也多了很多。顯然，大型機尚未成為歷史。由于在過去 20 年到 25 年間在大型機和遺留系統方面進行了這么多投資，將其全部拋開，使用更為商品化的平臺進行替換，這種做法并不一定合理。

回頁首

了解面臨的挑戰

IT 組織在大型機領域面臨的挑戰是復雜的、多方面的。首先，這些遺留平臺上的很多應用程序都是多年前編寫的，最初的開發人員已無從尋找。其次，應用程序通常非常復雜，也非常關鍵，自然使得很多組織在使其退役或移植到中型平臺方面都感到非常緊張。

這個挑戰是非常關鍵的。當將新的應用程序和功能添加到核心大型機之外的其他平臺體系結構時，可能會給 IT 組織內部帶來不和諧的因素；此類其他平臺包括 Microsoft® .NET® 或 Java™ 2 Platform, Enterprise Edition（J2EE）以及基于 Java Platform, Enterprise Edition（Java EE）的各種平臺等。此類設計通常要求具有復雜的互操作機制，以將大型機連接到中型平臺，而這會導致結構化的企業體系結構變得“支離破碎”。

再次，在 Internet 驅動的計算模型方面也有挑戰，即 Internet 站點和門戶要求訪問存儲在后端系統的數據的情況。此處的問題是，將這些后端遺留系統直接連接到 Internet 并不是一個很好的做法。大型機（以及其中的應用程序）設計為處理長時間運行的任務，通常支持數百或五千以下的并發用戶負載。他們并未設計為同時以實時的方式支持數十、數百甚至數百萬用戶。

回頁首

解決挑戰

在以后幾年，隨著整個行業開始廣泛采用 SOA，IT 架構師將開始購買業務流程包，而不是應用程序包。他們會隨后將這些業務流程包作為現有業務服務聚合體的一部分進行部署，以便連接到企業服務總線（ESB），并與各個組成應用程序集成。知道了這一點后，IT 架構師應該如何使用面向服務的方法來幫助解決這些挑戰呢？

首先，必須在大型機上（或在遺留環境中）對應用程序進行概念化，不是將其作為應用程序，而是作為服務的一個“部分”。必須從理念上將應用程序與基礎平臺體系結構（在這種情況下為大型機）分離開來。SOA 改變了應用程序的概念，使其成為了一組可通過服務接口訪問的邏輯功能組。本文重點討論各種可繼續從大型機平臺獲得積極投資回報（ROI）的方法，從而探索上文列出的 IT 組織面臨的主要挑戰的解決方案。

大型機的 SOA 策略

可以使用 SOA 作為大型機應用程序的包裝，從而使得這些遺留應用程序成為 ESB 的一部分。對架構師而言，如果能夠以普遍的方式提供企業服務編錄，以便可以在此基礎上著手開發新的應用程序和業務功能，則再理想不過了；只需要簡單地將新應用程序加入 ESB，然后就可以重用已公開的服務。

之所以聽起來非常簡單，是因為事實真的如此。如果您將本文中討論的概念性大型機視為 IBM 系列產品之一（例如 IBM OS/390® 或 zSeries® 計算機），您的工作就非常輕松了。IBM 提供大量供開發人員使用的工具和工作臺，SOA 架構師和設計人員可通過其采用拖放和 Point-and-Click 建模的方式連接到遺留服務。

例如，WebSphere Studio Enterprise Developer 等 IBM 產品允許開發人員或設計人員通過拖入遺留大型機環境公開的服務來設計其應用程序。此設計成果的運行時視圖將提供服務總線構造（即 ESB），其中包括總線本身、代理以及中間的消息傳遞層。

此外，通過混和使用 IBM WebSphere Host Aclearcase/" target="_blank" >ccess Transformation Services（HATS）、SOAP for Customer Information Control System（CICS®）甚至 WebSphere Information Integrator 等 IBM 技術，可以將大型機的應用程序適配器和接口公開給其他也連接到共用 ESB 的任何對象（甚至是 Microsoft .NET 應用程序）。

這樣，所開發的新應用程序就可以直接調用已經存在的服務，Java 開發人員就不需要知道所請求的服務駐留在大型機平臺上。這是完全透明的。對于有些細節，這可能有些夸張，但不要誤會——如果考慮到大型機的復雜性、成本以及狀態，使用這些工具為遺留應用程序提供“新生”的確相當簡單。

拖放功能

您可能已經使用過集成開發環境（Integrated Development Environment，IDE）的拖放功能，如 IBM Rational® Application Developer for WebSphere Software 中的此類功能。如果是這樣，您可能已經注意到開發人員（或業務分析人員）在 IDE 中拖動組件來構建應用程序的基本內容的方便性。

對于支持 SOA 的環境，也提供了這樣的功能?？梢酝蟿酉鄳姆眨ㄎ挥谀夸浕蚍樟斜碇校?，然后將此服務連接到其他應用程序流。隨后，通過手動編碼或使用 IDE 工具的“所見即所得”功能，可以將這些服務放入從目錄列表中拖出的工作流中，然后將其連接到端到端業務流程中。

示例：面向 Internet 的門戶應用程序

假定您有一個面向 Internet 的應用程序，允許客戶訂購各種美容產品。通過門戶應用程序，客戶可以從目錄中選擇產品，然后下訂單。（請參閱圖 1。）

應用程序的訂購模塊包括來自大型機的客戶詳細信息。不過，由于基于大型機的 COBOL 應用程序的遺留配置非常復雜或者在設計上存在缺陷，大型機僅能存儲郵政編碼，而不能存儲對應的地區。利用企業開發 IDE，您可以通過從 ESB 服務存儲庫拖放一個服務來創建門戶應用程序的 Customer Suburb，并創建檢索客戶詳細信息的流程，在此流程中使用 Postal Code 字段作為 IBM eServer® pSeries™ 中型應用程序（承載郵政編碼到地區查詢服務）的輸入參數。由于郵政編碼到地區查詢服務與公開的大型機應用程序的服務位于同一 ESB，因此將所有這些服務分組到一起來形狀單個流程就再簡單不過了。

不過，這個簡單示例的一個缺陷是，如果該面向 Internet 的門戶應用程序極為受歡迎，則可能在任何時候都有數萬在線并發用戶。為什么這是一個問題呢？因為此處要考慮的主要問題是，使用大型機公開的服務與與部署到 Internet 的應用程序之間的負載級差以及這個負載級差如何影響大型機。

正如我前面提到的，大型機并未設計為（或并不習慣）處理大量實時用戶請求。每秒 20,000 到 50,000 的實時在線請求會導致典型的大型機環境崩潰。不過，通過將大型機環境封裝在 SOA 層中，可以使用 WebSphere Process Server 等 ESB 提供的一些緩存和預讀功能，從而將大型機隔離開來。圖 2 重點說明了此類設置在典型環境中的情況。

策略：通過 ESB 緩存數據

此策略的工作方式是這樣的：可以通過 ESB 使某些數據（靜態數據或變化不頻繁的數據）變為持久性數據或可緩存數據。連接到 ESB 服務層的支持 SOA 的應用程序（如門戶）可以隨后以所需的性能進行事務處理，而不會使大型機后端崩潰。

例如，假定大型機上駐留了一個客戶記錄數據庫。在理論上，此數據庫將在 ESB 層進行緩存，從而不必每次直接從大型機應用程序獲取頻繁訪問的常用信息或數據?？梢酝ㄟ^ push-update 機制（大型機應用程序中進行了更新時，更改細節將 push 到 ESB 層）或將緩存設置為在定義的時段后過期來控制同步。

或者，可以對基于門戶的應用程序（以及創建的后續服務工作流）進行特殊設計，以便客戶首次登錄到門戶時，將通過異步后臺請求（pre-fetch）從大型機應用程序公開的服務檢索客戶的信息，然后在用戶會話期間將此信息緩存在 ESB 上。這種設置可減少大型機上的實時請求負載。

告訴每個人。將此請求提交到： Digg Slashdot

回頁首

收獲成果

這種類型的設計的實際好處在于，能以特定的方式公開駐留在大型機上的遺留業務功能，從而讓應用程序架構師和設計者能夠重用已存在的應用程序功能，而不必自己從頭進行開發。這樣做可以節省大量的成本，而且新的應用程序或功能也可以更快地投入使用。以銀行和金融機構為例，此類機構都具有龐大的運行其核心業務的大型機環境。如果讓這些大型機直接退役并替換為新的移植應用程序，成本將非常高，而且風險也很大。

您可能會問，通過進行 SOA 包裝和封裝遺留應用程序，我們是不是只是推遲了必然出現的情況呢？我們將來是不是仍然還要進行應用程序移植？我的答案是“是，也不是”，您是在延遲更改，但將以更為結構化的方式對更改進行管理。當然，隨著時間的流逝，大型機應用程序將需要進行移植，但通過為這些大型機應用程序提供 SOA 支持，我們提供了將其核心服務功能映射出去的固有結構，以便在將來的移植和重新開發工作中進行實現。

請記住，移植大型機應用程序的風險和成本不僅限于所移植的應用程序。與之通過接口連接的外部應用程序也需要進行修改和回歸測試。然而，通過在大型機上為其應用程序提供 SOA 支持，可以幫助減少將來進行移植的成本和影響，因為任何通過接口連接的應用程序僅需要關心其訪問的服務。例如，如果 ESB 上的服務契約仍然傳入輸入參數 postalcode 并接受地區名稱字符串，就不需要更改郵政編碼到地區的應用程序示例。只要服務契約未更改，應用程序就會像以前一樣工作。

因此，大型機并未退出歷史舞臺。IT 組織并不需要因為移植遺留應用程序而為其 IT 程序引入額外的風險、復雜性和成本。通過實現基于面向服務的方法，IT 組織可以繼續從大型機投資獲得回報，并同時順利地將其企業程序逐漸向純 SOA 模型過渡。不僅如此，組織還能獲得其他好處，例如，能夠通過恰當的企業級面向服務的體系結構的實現提高其平臺的可用性、性能和可訪問性。這樣，當需要執行實際的移植時，應用程序間的影響就可以忽略，因為企業中的所有一切都是面向服務的，而不是面向應用程序的。