模板
教程
環境
性能
功能
管理
SOA融合開發與集成實現按需服務倉庫
發表于：2008-02-02來源：作者：點擊數：
標簽：開發
從IT的"黑洞"談起 最近參加了一個IT的高層年會，在會上眾多的社會學家、 金融 專家和IT人士都談到了IT的黑洞問題。讓人們覺得IT似乎已經成為阻礙行業發展，乃至社會進步的障礙。IT的'丑陋面'競相暴露： IT部門，實實在在的成本中心 IT正在從支撐業務、引導業
從IT的"黑洞"談起 最近參加了一個IT的高層年會，在會上眾多的社會學家、金融專家和IT人士都談到了IT的黑洞問題。讓人們覺得IT似乎已經成為阻礙行業發展，乃至社會進步的障礙。IT的'丑陋面'競相暴露：
IT部門，實實在在的成本中心
IT正在從支撐業務、引導業務變為限制業務發展
80%-90%的IT預算和IT人力都花在了維護老系統上
新業務的推出都需數月，乃至年計，跟不上客戶的需求和市場的反應
難道IT真的成了雞肋？難道我們可以舍棄IT？我想原因很簡單，IT與業務其實就是一對發展中的矛盾共同體，互相依存、促進與平衡：
互相依存?，F在一定沒有人會懷疑業務離不開IT，如果沒有了IT,任何的金融、電信、政務和生產制造業務都將癱瘓；而如果沒有了業務的需求，IT也將失去存在和發展的價值。
互相促進。業務的發展要求IT不斷地創新，如各個行業對于異地交易（通存通兌、通保通賠）的需求帶來了消息中間件的發展；而同樣地IT的創新也帶來了新的業務模式，互聯網的發展毫無質疑地帶動了諸如金融業的網上銀行、網上證券、網上保險，帶動了電信的網上營業廳，甚至于直接影響我們衣食住行的網上商旅、網上商城，帶來了許多新的商務模式。
互相平衡。業務與IT既然是一對矛盾體，那么任何一方的滯后或是超前都會帶來另一方的"不安"，都會表現為矛盾的激化，都會涉及到現有平衡的打破與再建。
因此，我們看到的其實是如何發展IT的問題，而不是那些聳人聽聞的需不需要IT的問題。正是有了這種矛盾的持續存在，IT才會有持續發展的土壤。
傳統的開發或是集成，帶來了復雜
傳統來講，IT實現業務的方式無外乎定制開發項目或是專業集成項目。也就是為了開發而開發，為了集成而集成。
當立為開發項目時，就根據需要確定集成商、開發商。然后選擇相關的開發平臺，如服務器、數據庫、應用服務器、開發工具等。而在不同的開發項目中很有可能選擇了不同的應用商，而采用了不同的開發平臺。這樣就帶來了開發越多，未來集成越是困難。
而在專業集成項目中，由于大型企業的應用必須與一個或多個數據源進行業務數據交互，部分數據源可能就是其他的應用。換句話來說，應用在沒有集成的情況下無法進行開發。應用集成會包含一定的應用開發任務，如開發和組裝組件，將它們連接到后端系統，實現過程流和工作流，開發用戶界面，以及進行測試和調試。而如果在集成項目中只根據現有的各種系統，選擇一個集成商，采用一個專門的集成服務器，如門戶集成服務器或是信息集成服務器或是應用集成服務器，這樣是遠遠不夠得，因為對于在集成過程中新的業務流程所需的再次開發就會捉襟見肘。
傳統的三種最通用的應用集成方法是點到點集成、企業消息總線或中間件的集成（EAI）、基于業務流程的集成，都不十分理想，主要問題在于：
消息總線和應用之間的定制或專有集成。與對等方法相比，EAI 和基于業務流程的集成減少了集成點的數量。但是，三種方法都需要在消息總線和每項應用間進行定制化或專有集成，并且，在每個集成點都需要采用不同的專有數據格式。
消息總線和應用之間的緊密耦合。所有的應用都需要知道與其集成的其它應用的內部工作機制。系統之間的集成是粒度化的，并與消息類型存在緊密耦合關系。傳統的 EAI 實現所使用的業務流程管理 (BPM) 工具是專有的。這妨礙了其他優秀標準產品的應用。
程序化而非抽象式的數據訪問。大部分數據訪問、集成和轉換工作（企業信息集成）都留給了開發人員采用人工編碼方式來完成。企業IT環境中存在多個不同的數據源，開發人員要有不同的適配器來訪問這些數據源、要有轉換引擎來重新定義數據格式、還需要進行數據復制以實現數據的物理整合。要實現數據源的集成，開發人員需使用以上工具將集成需求編寫到應用中去。盡管以上方法是可行的，但這既沒有效率也缺乏靈活性。
所以，當用孤立的眼光來看開發與集成時，矛盾重重。而其實開發與集成已是一對矛盾共同體。任何定制開發的應用都需要去訪問別的應用，也需要被別的應用來訪問，因此開發離不開集成；而任何集成也都是為了新的應用需要而來，當然會有新的業務流程的開發，所以集成也離不開開發。
結論很簡單，如果獨立地考慮應用開發和應用集成是毫無價值的。而且傳統的應用開發和集成方法不夠靈活，未能基于標準。因此，傳統方法無法構建能夠滿足動態企業變化需求的、敏捷的企業IT環境。
SOA融合開發與集成，化繁為簡
三種傳統的應用集成方法都很復雜、昂貴，并且不靈活。這些集成方法難于快速適應基于企業現代業務變化不斷產生的需求?；诿嫦蚍占軜?(SOA) 的應用開發和集成可以很好的解決其中的許多問題。
不同的行業分析家或專家對SOA有不同的定義和理解。Gartner 提出了SOA 這一術語，并定義如下： "面向服務的架構是一種客戶機/服務器軟件設計方法，其中應用由軟件服務和軟件服務使用者組成（也稱為客戶機或服務請求者）" 。SOA 與多數一般的客戶機/服務器模型不同，它明確地強調了軟件組件之間的松散耦合，以及其獨立標準界面的使用。CBDI 論壇如下定義了"面向服務" (SO)，重點強調了服務的提供和管理： "SO 是業務和技術服務的提供、使用和生命周期管理，這些業務和技術服務是自描述、松散耦合和以技術中立的方式來實現的。"SOA 描述了一套完善的開發模式來幫助客戶端應用連接到服務上。這些模式定制了系列機制用于描述服務、通知及發現服務、與服務進行通信。
不同于傳統的應用集成方法，在 SOA 中，圍繞服務的所有模式都是以基于標準的技術實現的。大部分的通信中間件系統，如 RPC、CORBA、DCOM、EJB 和 RMI，也同樣如此?？墒撬鼈兊膶崿F都不是很完美的，在權衡交互性以及標準定制的可接受性方面總是存在問題。
SOA 試圖排除這些缺陷。因為幾乎所有的通信中間件系統都有固定的處理模式，如RPC 的功能、CORBA 的對象等等。然而，服務既可以定義為功能，又可同時對外定義為對象、應用等等。這使得 SOA 可適應于任何現有系統，并使得系統在集成時不必刻意遵循任何特殊定制。
SOA 幫助企業信息系統遷移到"leave-and-layer"架構之上，這意味著在不用對現有的企業系統做修改的前提下，系統可對外提供 Web 服務接口，這是因為它們已經被可以提供 Web 服務接口的應用層做了一層封裝，所以在不用修改現有系統架構的情況下，SOA 可以將系統和應用迅速轉換為服務。SOA 不僅覆蓋來自于打包應用、定制應用和遺留系統中的信息，而且還覆蓋來自于如安全、內容管理、搜索等 IT 架構中的功能和數據。因為基于 SOA 的應用能很容易地從這些基礎服務架構中添加功能，所以基于SOA的應用能更快地應對市場變化，為使企業業務部門設計開發出新的功能應用。
與傳統的企業應用集成架構的主要區別在于該系統使用基于標準的服務，并包括過程/數據服務、編排和組合?；跇藴实姆粘闪藨瞄g的集成點。服務的編排和組合增加了服務的靈活性、重用性和集成性。
下表強調了分布式組件架構和 SOA 的區別：
表1：分布式服務與面向服務的架構比較
| 分布式組件架構 |
面向服務的架構 |
| 面向功能性 |
面向流程 |
| 設計目的是為了維持現狀 |
設計目的是為了適應變化 |
| 開發周期長 |
交互式和重用性開發 |
| 成本為中心 |
業務為中心 |
| 應用阻塞 |
服務協調 |
| 緊密耦合 |
敏捷的和可適應的 |
| 同構技術 |
異構技術 |
| 面向對象 |
面向消息 |
| 需深入了解實施細節 | 對實施細節進行概要抽象 |
與傳統方法相比，SOA具有以下更多優勢：基于標準、松散耦合、共享服務、粗粒度和聯合控制。
服務是網絡中可用的軟件資源。服務提供者通過標準機制提供服務，服務使用者通過網絡有計劃性地使用服務。服務代理發布服務所在位置，并在使用者請求服務時定位服務。服務使用者和提供者的角色不是惟一的；服務提供者也可以是使用者，反之亦然。
提供者在服務約定中以標準語言描述其服務，并向代理發布服務?？蛻魪姆沾硖帲ɑ虻怯浱帲┎樵兯璧姆?，并接收有關服務訪問的約定和信息。隨后，客戶或使用者便可綁定到服務，并可與提供者直接通信。
服務實現包含了服務的功能或業務邏輯。對于服務使用者來說，服務實現應該是一個"黑匣子"；用戶沒必要知道服務的功能實現細節。 有五種類型的服務：
1. 數據訪問-允許對不同數據源進行統一訪問
2. 組件-提供對打包應用服務的訪問，如ERP
3. 業務-提供使用一個以上打包應用或定制應用功能的復雜服務
4. 組合-使用以上三種類型的服務來創建包括新功能和現有功能的新服務
5. 共享的或企業基礎架構服務?-?消息日志之類的低級服務，其重用性使快速創建新的高級服務成為可能
在SOA的架構下，不管是數據訪問、組件訪問還是業務訪問，都是對于服務的訪問，并可在此基礎上組合和共享。企業就此有了標準的服務規范和接口，計算環境變得簡單了。
BEA WebLogic，構建SOA的“服務倉庫”
企業基礎架構服務或共享服務為 SOA 增加了很大價值。共享服務由于自身的功能和位置特點，通常是在邏輯層實現的。這些特性由共享服務層實現，該層在邏輯上由幾個服務層組成。
讓我們再來看看部署及其后續工作：
部署
部署模型的選擇需要依賴于網絡架構，同時還取決于應用、運行和管理需要如何從邏輯和物理上進行分離。而以上這些通常是由企業的IT策略決定的。BEA提供了聯合部署或獨立部署的靈活性，因此可以選擇任意的部署模型來支持IT策略?？梢园磳樱ū硎?、集成、流程和數據）分離應用，也可以從經營和管理來分離應用。這樣可以實現最佳的控制和靈活性，但額外的硬件服務器和軟件許可也確實增加了成本。采用WSM產品增加了需要在同一服務器中部署的組件數量，或增加了所需管理的服務器數量。
運行、經營和管理（OA&M）
但是，SOA將開發和OA&M分離開來，這顯著減少了不同類型用戶所使用的接口數量。采用基于策略的計算模式，絕大部分控制交由OA&M人員來操作。這意味著他們可以采用WSM產品的用戶界面，而非WebLogic控制臺。
這樣在BEA的WebLogic框架之上，不斷地構筑業務需要的各種標準服務，實實在在地形成一個“服務倉庫”。按需服務，最終實現企業的商務自主！
