iweroulsdjf

學(xué)習(xí)如何為企業(yè)開發(fā)面向服務(wù)的體系結(jié)構(gòu)（Service Oriented Architecture，SOA）移植策略，該企業(yè)的 IT 基礎(chǔ)架構(gòu)包括業(yè)務(wù)筒倉（silo）的單獨(dú)業(yè)務(wù)線，并擁有許多集成的遺留應(yīng)用程序來支持業(yè)務(wù)目標(biāo)。本文包括開發(fā)成功的 SOA 移植策略所需行為的工作細(xì)化結(jié)構(gòu)范例，最終生成符合 IBM 客戶合約中 SOA 原則的實(shí)際應(yīng)用程序。

SOA 介紹

自從 Gartner Group [1]提出面向服務(wù)的體系結(jié)構(gòu)（Service Oriented Architecture，SOA）和企業(yè)服務(wù)總線（Enterprise Service Bus，ESB）以來，這些術(shù)語已經(jīng)用了好幾年了。然而，應(yīng)用 SOA 解決方案的實(shí)際細(xì)節(jié)僅僅是最近才出現(xiàn)的。

那么，準(zhǔn)確地說面向服務(wù)的體系結(jié)構(gòu)是什么呢？“SOA 是一種組件模型，它通過應(yīng)用程序功能單元（稱為服務(wù)）之間定義完善的接口和契約，來聯(lián)系應(yīng)用程序中的不同服務(wù)。”[2]。通過以上的定義，當(dāng)提取應(yīng)用程序作為服務(wù)時(shí)，SOA 是在應(yīng)用程序之間構(gòu)建企業(yè)級(jí)集成層的模式集。SOA 解決方案提倡使用開放標(biāo)準(zhǔn)，然而當(dāng)集成應(yīng)用程序時(shí)，在某些地方還是需要使用專有技術(shù)。

SOA 依賴于將應(yīng)用程序功能發(fā)布為服務(wù)，這些服務(wù)可被外部各方調(diào)用。通常，對(duì) SOA 服務(wù)定義的一致觀點(diǎn)是[3]：

• 服務(wù)通過明確的、與實(shí)現(xiàn)無關(guān)的接口來定義。
• 服務(wù)被松散綁定，并且可以通過強(qiáng)調(diào)位置透明性和互操作性的通信協(xié)議進(jìn)行調(diào)用。
• 服務(wù)封裝了可重用的業(yè)務(wù)功能。

服務(wù)可存在于不同的級(jí)別上，并提供不同的粒度。通常認(rèn)為有以下服務(wù)級(jí)別[4]：

• 技術(shù)功能（例如，日志記錄）
• 業(yè)務(wù)功能（例如，getCustomerInfo）
• 業(yè)務(wù)事務(wù)（例如，openAccount）
• 業(yè)務(wù)流程（例如，processOrder）

每一個(gè)粒度級(jí)別可能都需要一些合成度。在每個(gè)粒度級(jí)別上，服務(wù)定義以可復(fù)用的方式封裝其功能是很重要的。

將應(yīng)用程序功能發(fā)布成服務(wù)使應(yīng)用程序可以高效解耦，這是 SOA 的一種需求。通過接口將功能發(fā)布成服務(wù)，該接口將針對(duì)這項(xiàng)功能創(chuàng)建會(huì)話虛包（fa?ade）。可以通過直接修改應(yīng)用程序或者通過創(chuàng)建適配器（將請(qǐng)求轉(zhuǎn)換成特定于應(yīng)用程序的調(diào)用）來創(chuàng)建這樣的接口。

當(dāng)應(yīng)用程序功能作為服務(wù)公開時(shí)，創(chuàng)建服務(wù)消費(fèi)者和提供者之間路由消息的機(jī)制是很重要的。SOA 解決方案通過使用企業(yè)服務(wù)總線（Enterprise Services Bus，ESB）來滿足此需求。企業(yè)服務(wù)總線是為各種服務(wù)請(qǐng)求者和服務(wù)提供者提供連接層的一種消息代理，它確保二者之間合適的消息路由。服務(wù)請(qǐng)求者是組件，它調(diào)用由服務(wù)提供者發(fā)布的服務(wù)來實(shí)現(xiàn)內(nèi)部邏輯。

雖然 ESB 最重要的任務(wù)是提供連接框架，但它也提供現(xiàn)代 IT 所需要的合適的服務(wù)級(jí)別和可管理性。實(shí)質(zhì)上，ESB 允許在基于 SOA 的架構(gòu)中集成服務(wù)，并提供“服務(wù)請(qǐng)求者和服務(wù)提供者之間使用分布式中介功能的單一管理點(diǎn)”[4]。

ESB 在服務(wù)請(qǐng)求者和提供者之間提供松耦合，允許用一個(gè)服務(wù)實(shí)現(xiàn)來替換另一個(gè)，而且不會(huì)對(duì)該服務(wù)的消費(fèi)者造成影響。

在 ESB 提供了服務(wù)之間連接性的同時(shí)，其他 SOA 組件也提供了對(duì)發(fā)布、發(fā)現(xiàn)和調(diào)用服務(wù)的支持。這些組件包括業(yè)務(wù)服務(wù)目錄、業(yè)務(wù)服務(wù)編排和 ESB 網(wǎng)關(guān)。然而，這些組件的部署需要根據(jù)實(shí)際的業(yè)務(wù)需求來決定。舉個(gè)例子，許多較小的企業(yè)可能發(fā)現(xiàn)他們實(shí)際上并不需要 ESB 網(wǎng)關(guān)，因此，將不必建立這些網(wǎng)關(guān)，導(dǎo)致架構(gòu)過于復(fù)雜。

業(yè)務(wù)服務(wù)目錄提供 ESB 所依賴的服務(wù)路由信息，同時(shí)支持服務(wù)請(qǐng)求者和提供者之間的通信。然而，業(yè)務(wù)服務(wù)目錄的主要任務(wù)是提供服務(wù)細(xì)節(jié)，這些服務(wù)細(xì)節(jié)可用于執(zhí)行基礎(chǔ)架構(gòu)所支持的業(yè)務(wù)功能。實(shí)質(zhì)上，業(yè)務(wù)服務(wù)目錄是服務(wù)消費(fèi)者尋找支持他們操作的服務(wù)的地方。

在業(yè)務(wù)服務(wù)目錄提供關(guān)于現(xiàn)有服務(wù)的信息的同時(shí)，業(yè)務(wù)服務(wù)編排組件允許通過現(xiàn)有的低級(jí)服務(wù)組成新的服務(wù)。例如，可以通過定義包含幾個(gè)較低級(jí)別業(yè)務(wù)功能的工作流來創(chuàng)建新的業(yè)務(wù)事務(wù)。這樣的工作流成為新的服務(wù)，并發(fā)布在業(yè)務(wù)服務(wù)目錄中。

開發(fā) SOA 移植策略

許多提供多種服務(wù)的大企業(yè)如今發(fā)現(xiàn)，他們的 IT 已經(jīng)被嚴(yán)重拆分。主要是因?yàn)樵S多企業(yè)選擇允許每個(gè)業(yè)務(wù)部門維護(hù)它自己的 IT 需求，而不是依賴于集中管理的 IT 組織。因此，許多部門只創(chuàng)建與自身相關(guān)的應(yīng)用程序。通常，公司可能有一些賬單、帳目管理以及類似的支持不同業(yè)務(wù)方面的系統(tǒng)。而且，許多公司希望安裝“最佳”軟件，而不考慮同其它應(yīng)用程序的集成。后來他們發(fā)現(xiàn)，將新的應(yīng)用程序加入 基礎(chǔ)架構(gòu)時(shí)經(jīng)常需要特定的方案。下面的圖 1 正是目前一些企業(yè)中 IT 基礎(chǔ)架構(gòu)的例子：

圖 1.常見的遺留企業(yè) IT 基礎(chǔ)架構(gòu)

從上圖中可以注意到一個(gè) IT 難題，那就是大多數(shù)應(yīng)用程序之間直接相互通信。當(dāng)應(yīng)用程序需要修改或淘汰時(shí)，這種依賴便成為一個(gè)實(shí)際問題。任何修改都可能會(huì)按其自身的方式更新每條唯一的通信線路。因此，這種變更可能代價(jià)高昂。這種情況被稱為應(yīng)用程序間的緊耦合，也逐漸成為讓一些企業(yè)頭疼的問題。

另一方面，SOA 將松耦合作為成功的企業(yè)級(jí)應(yīng)用程序集成的一個(gè)主要原則。與緊耦合相反，松耦合是：

限制請(qǐng)求者應(yīng)用程序代碼和提供者應(yīng)用程序代碼的相互了解。如果耦合的服務(wù)任何方面有所變化，那么，請(qǐng)求者或提供者的應(yīng)用程序代碼（更可能是兩者同時(shí)）必須改變。如果任何一方（請(qǐng)求者、提供者或中介基礎(chǔ)架構(gòu)）對(duì)解耦的服務(wù)任何方面作出改變，那么其它幾方不必隨之改變。[5]

圖 1 也示例了當(dāng)在幾個(gè)業(yè)務(wù)區(qū)域內(nèi)部署具有所需功能的應(yīng)用程序時(shí)（例如，應(yīng)用程序 1 和應(yīng)用程序 1'），一些企業(yè)所采用的實(shí)踐行動(dòng)。通常，用每個(gè)部署稍微修改應(yīng)用程序以滿足特定業(yè)務(wù)區(qū)域的獨(dú)特需求。雖然讓多個(gè)應(yīng)用程序具有相同功能并沒有明顯的缺點(diǎn)，但它們的存在可能表明：

• 企業(yè)中可能存在數(shù)據(jù)副本，這會(huì)影響操作數(shù)據(jù)的準(zhǔn)確性。這是由以下原因造成的：大部分此種應(yīng)用程序依賴于相同的數(shù)據(jù)源， 且為了性能或其他原因，一部分?jǐn)?shù)據(jù)被本地存儲(chǔ)。
• 維護(hù)多個(gè)應(yīng)用程序比支持單個(gè)解決方案需要更高的花費(fèi)。
• 當(dāng)對(duì)這些應(yīng)用程序進(jìn)行合并，以減少對(duì)那些與被淘汰的方案互相依賴的應(yīng)用程序的影響時(shí)，需要特別注意。

通過采用 SOA 原則在企業(yè)級(jí)別上成功集成應(yīng)用程序可解決這些問題。

值得注意的是，當(dāng)企業(yè)還未被深入劃分時(shí)，應(yīng)用 SOA 是合理的。然而，當(dāng)公司內(nèi) IT 部門的數(shù)量很多，而且它們托管的應(yīng)用程序數(shù)量更多時(shí)，實(shí)現(xiàn)基于 SOA 的企業(yè)體系結(jié)構(gòu)將是一項(xiàng)具有挑戰(zhàn)性的工作，需要精心規(guī)劃。

將復(fù)雜的深入劃分的企業(yè)分割成一些單獨(dú)的域，事情可能會(huì)變得容易很多。第一，通過 ESB 發(fā)布特殊的應(yīng)用程序服務(wù)，每一個(gè)域可以與企業(yè)其余部分解耦。第二，以后域內(nèi)的應(yīng)用程序可以啟用 SOA，而不會(huì)影響企業(yè)其余部分。

按照業(yè)務(wù)功能（例如，銷售、賬戶管理、客戶服務(wù)等等）或?qū)崿F(xiàn)（比如大型機(jī)和 Unix 服務(wù)器）來對(duì)域的劃分進(jìn)行組織。然而，實(shí)質(zhì)上，域?qū)o密連接的應(yīng)用程序，因此，相比它們與企業(yè)的其余部分的關(guān)系，這些應(yīng)用程序彼此之間將具有更嚴(yán)重的依賴性。

如果一組服務(wù)屬于單獨(dú)的域，那么可用下列準(zhǔn)則來定義：

• 功能域是基于業(yè)務(wù)功能選擇的。這些域中的服務(wù)消費(fèi)域外部的有限數(shù)量的服務(wù)，并對(duì)外部公開有限數(shù)量的服務(wù)。
• 基于技術(shù)的域根據(jù)所利用的一系列技術(shù)來選擇。這些可能包括大型機(jī)應(yīng)用程序、分布式應(yīng)用程序等等。
• 基于應(yīng)用程序的域是緊耦合的應(yīng)用程序集合。共享相同數(shù)據(jù)庫的電子商務(wù)應(yīng)用程序或大型機(jī)應(yīng)用程序的集合是這種劃分的一個(gè)例子。

域的初始劃分也可以是純概念上的，對(duì)那些需要作為服務(wù)向企業(yè)其余部分公開的應(yīng)用程序功能進(jìn)行確認(rèn)。

一旦確認(rèn)了服務(wù)，需要通過使用網(wǎng)關(guān)和防火墻建立明確的邊界，從而使域彼此分離。這種分離提供了對(duì)應(yīng)用程序交互的更好的控制，并可進(jìn)一步對(duì)應(yīng)用程序進(jìn)行靈活的變更，而不會(huì)對(duì)企業(yè)其余部分產(chǎn)生重大影響。這種分離可通過幾種不同的方法實(shí)現(xiàn)：

• 將公開域功能的業(yè)務(wù)功能定義為粗粒度服務(wù)：業(yè)務(wù)功能由企業(yè)需求驅(qū)動(dòng)，而并非內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)。業(yè)務(wù)功能可以在域內(nèi)部調(diào)用細(xì)粒度的技術(shù)服務(wù)，對(duì)外部消費(fèi)者提供服務(wù)。定義業(yè)務(wù)功能的主要目的是限制域之間的交互。
• 添加網(wǎng)關(guān)可以將一個(gè)域設(shè)定轉(zhuǎn)換為另一個(gè)域設(shè)定：通過添加更好的控制功能，網(wǎng)關(guān)也允許在外部實(shí)體間（例如業(yè)務(wù)伙伴）建立明確的界限。通常，網(wǎng)關(guān)可與業(yè)務(wù)功能合成為一個(gè)邏輯實(shí)體。然而，添加網(wǎng)關(guān)是由業(yè)務(wù)需求決定的，如果域共享相同的設(shè)定就不需要添加網(wǎng)關(guān)。使用下列方法之一可以實(shí)現(xiàn)網(wǎng)關(guān)：
  • 透明/代理網(wǎng)關(guān)以消費(fèi)者認(rèn)為能直接與業(yè)務(wù)功能進(jìn)行交互的方式公開域服務(wù)。這種網(wǎng)關(guān)也可以基于企業(yè)基礎(chǔ)架構(gòu)需求對(duì)輸入和輸出的消息進(jìn)行轉(zhuǎn)換。當(dāng)域數(shù)據(jù)以非常特殊的格式（與企業(yè)級(jí)約定完全不同）存儲(chǔ)時(shí)，需要進(jìn)行轉(zhuǎn)換。例如，按照企業(yè)策略，特定于域的二進(jìn)制數(shù)據(jù)可能需要轉(zhuǎn)換成 XML。
  • 防火墻允許增強(qiáng)對(duì)域的封裝。盡管，防火墻不去執(zhí)行任何轉(zhuǎn)換，但是它們限制消費(fèi)者僅能訪問域邊界內(nèi)預(yù)先定義的點(diǎn)。而且，防火墻的引入提供了對(duì)不遵循域的封裝規(guī)則的服務(wù)進(jìn)行檢測(cè)。

分析發(fā)布到域外部的應(yīng)用程序功能時(shí)，會(huì)發(fā)現(xiàn)實(shí)際的服務(wù)是細(xì)粒度功能的結(jié)合。將應(yīng)用程序功能編制為業(yè)務(wù)服務(wù)的一種機(jī)制是引入本地服務(wù)總線（Local Service Bus，LSB），將服務(wù)編排組件添加到這些域。

本地服務(wù)總線是為單個(gè)域提供連接支持的企業(yè)服務(wù)總線的實(shí)例。通過服務(wù)編排組件進(jìn)行擴(kuò)展，使域可以組成 ESB 可消費(fèi)的更高級(jí)別的業(yè)務(wù)功能。

下面，圖 2 演示了以上步驟生成的基礎(chǔ)架構(gòu)：

圖 2.已定義并分離的 IT 域

一旦封裝了所有的域并公開了業(yè)務(wù)功能，通過 ESB 對(duì)其集成，并采用業(yè)務(wù)編排來創(chuàng)建更高級(jí)別的業(yè)務(wù)流程和事務(wù)就變得更加容易。一旦 ESB 是到位并且企業(yè)正在使用，就可以對(duì)域內(nèi)遺留應(yīng)用程序進(jìn)行移植，且對(duì)企業(yè)其余部分影響很小。

下面（表 1）的工作細(xì)化結(jié)構(gòu)范例描述了企業(yè)將遺留基礎(chǔ)架構(gòu)移植到基于 SOA 的企業(yè)體系結(jié)構(gòu)所需要采取的主要步驟。盡管實(shí)際的任務(wù)清單是特定于對(duì)具體企業(yè)的，但是下面的清單為需要考慮的內(nèi)容提供了一種思路。

表 1. 工作細(xì)化結(jié)構(gòu)

ID	任務(wù)名稱
1	SOA 移植規(guī)劃
2	? ? ? ? ? ?管理
3	? ? ? ? ? ? ? ? ? ? ? ?項(xiàng)目管理
4	? ? ? ? ? ? ? ? ? ? ? ?技術(shù)管理
5	? ? ? ? ? ?實(shí)現(xiàn)活動(dòng)
6	? ? ? ? ? ? ? ? ? ? ? ?收集信息
7	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?協(xié)商
8	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?文檔分析
9	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?創(chuàng)建文檔
10	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?評(píng)審
11	? ? ? ? ? ? ? ? ? ? ? ?分析
12	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?功能方面
13	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?收集信息
16	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?創(chuàng)建信息
17	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?評(píng)審
18	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?技術(shù)方面
19	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?收集信息
22	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?創(chuàng)建文檔
23	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?評(píng)審
24	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?應(yīng)用程序方面
25	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?收集信息
26	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?協(xié)商
27	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?文檔分析
28	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?創(chuàng)建文檔
29	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?評(píng)審
30	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?域方面
31	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?信息分析
32	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?創(chuàng)建文檔
33	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?評(píng)審
34	? ? ? ? ? ? ? ? ? ? ? ?規(guī)劃變更
35	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ESB 規(guī)劃
36	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?開發(fā) ESB 組織原則
37	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?工作量估計(jì)
38	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?創(chuàng)建文檔
39	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?評(píng)審
40	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?LSB 規(guī)劃
41	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 開發(fā) LSB 組織原則
42	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 工作量估計(jì)
43	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 創(chuàng)建文檔
44	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 評(píng)審
45	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?相關(guān)性規(guī)劃
46	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?相關(guān)性分析
47	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?創(chuàng)建文檔
48	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?評(píng)審
49	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?接口規(guī)劃
50	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?接口開發(fā)
51	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?創(chuàng)建文檔
52	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?評(píng)審

結(jié)束語

基于 SOA 的企業(yè)體系結(jié)構(gòu)的方法使得在對(duì)企業(yè) IT 基礎(chǔ)架構(gòu)進(jìn)行變更時(shí)，相關(guān)的移植風(fēng)險(xiǎn)更小。通常，公司認(rèn)識(shí)到支持舊的基礎(chǔ)架構(gòu)是代價(jià)高昂的；然而，劇烈的變化是很有風(fēng)險(xiǎn)的。將企業(yè)劃分為多個(gè)域，并引入本地服務(wù)總線（Local Service Bus）的概念可以減輕風(fēng)險(xiǎn)，并可用良好可控制步驟來將其移植到新的基礎(chǔ)架構(gòu)中。

請(qǐng)記住解決方案只可以被有效地應(yīng)用于不同類的環(huán)境中，這點(diǎn)非常有用。同類環(huán)境不太可能從這種策略中獲益。