面向服務的架構

1、(一)基礎：什么是BPM商業(yè)流程管理？ HYPERLINK %20 CNET中國PC類型:轉載 作者: csdn 責編:小蝎 時間:2006-10-23 BPM是流程自動化的應用，幫助企業(yè)進行業(yè)務流程的分析之外，另可利用IT技術，自動化組織內(nèi)各部門的原本以人力及公文傳遞的流程。 根據(jù)數(shù)據(jù)整合軟件供貨商Ultimus的定義，BPM主要精神在于管理企業(yè)的流程。除工作流程自動化系統(tǒng)之外，還必需提供企業(yè)應用軟件整合（EAI）與交換的功能、流程成本效率評量與績效管理，以及流程初始設計的模型最佳化工具，用以涵蓋企業(yè)管理流程中所有的必要環(huán)節(jié)。 分析師建議，決定BPM工具之前，企業(yè)必須用嚴謹?shù)膽B(tài)度檢討目前使用

2、的軟件，決定業(yè)務角色的授權，權衡數(shù)據(jù)模型（data model）與分析工具（analytical applications），并建立未來采用BPM后的假想情境。 目前包括IBM、微軟、BEA也努力催生商業(yè)模型標準，聯(lián)合起草網(wǎng)絡服務（Web Services）商業(yè)流程執(zhí)行語言（BPEL4WS）。業(yè)界相信，先建立商業(yè)流程模型，再從這些流程模型中建立應用程序進而監(jiān)視這些模型，將有助在企業(yè)內(nèi)部的IT部門與業(yè)務主管之間建立起環(huán)環(huán)相扣的自動化流程（二）體系架構藍圖-SOA和BPM的合并 HYPERLINK %20 CNET中國PC類型:投稿 作者: BEA 責編:小蝎 時間:2006-10-23 面向服務

3、的體系架構（Service-oriented architecture，SOA）已經(jīng)成為軟件工程中一個最重要的主題。無疑，隨著Web服務的推廣和廣泛接受，以及支持基于SOA解決方案開發(fā)的case風格的IDE這一新浪潮的興起，SOA已經(jīng)成為構建企業(yè)級分布式應用程序的首選藍圖。與此同時，業(yè)務流程管理（business process management，BPM）作為操作靈活的新企業(yè)并為其建模的主要支持者，正在強力反彈。 面向服務的體系架構（Service-oriented architecture ，SOA）已經(jīng)成為軟件工程中一個最重要的主題。無疑，隨著Web服務的推廣和廣泛接受，以及支持基于S

4、OA解決方案開發(fā)的case風格的IDE這一新浪潮的興起，SOA已經(jīng)成為構建企業(yè)級分布式應用程序的首選藍圖。與此同時，業(yè)務流程管理（business process management ，BPM）作為操作靈活的新企業(yè)并為其建模的主要支持者，正在強力反彈?；A結構廠商已經(jīng)使BPM成為他們出售的系列產(chǎn)品的主要組件，瞄準機會的廠商使用專用的BPM系統(tǒng)提供垂直的業(yè)務解決方案，純使用BPM的廠商正在得到更加廣泛的接受。 盡管兩種趨勢均顯露出了征兆，它們的趨同現(xiàn)象仍不明顯，而且關于這種現(xiàn)象沒有統(tǒng)一的看法。它們是互補的表示法嗎？它們會重疊嗎？我該如何一起使用它們？這樣做有沒有另外的優(yōu)點？此外，為什么80年代

5、末期的企業(yè)流程重構（BP reengineering）失敗了，而第三次BPM浪潮卻將要取得成功呢？ 在這一系列三篇文章中，我將解決這些問題。首先，我將討論一個體系架構藍圖的最佳實踐如何將面向服務體系架構與BPM框架合并，從而為構建健壯的企業(yè)級集成解決方案并對其建模提供可重復的方案。我描述了為什么在當今，任何使用技術支持其任務陳述需要的企業(yè)比以往更能擁有合適的體系架構藍圖。最后，我討論了什么是實時交易的挑戰(zhàn)，以及BPM方法如何能夠實現(xiàn)企業(yè)靈活性、智能企業(yè)建模、系統(tǒng)開發(fā)和以客戶為中心的運作優(yōu)點。 在第二篇文章中，我將應用BPM技術來為一個支持“用于汽車保險”業(yè)務場景的軟件解決方案建模和設計體系架構

6、。我將講述兩種設計：一種純BPM設計和一種混合型設計。我還將講述一些新興的建模工具和標準，并討論一些建模和各種體系架構選擇和策略方面的難題。 在第三篇（也是最后一篇）文章中，我將使用BEA的WebLogic Platform 8.1 構建一個POC。我將討論BEA的IDE新引入的可視化編程范型及其優(yōu)缺點，和構建完全分布式的企業(yè)級應用程序所需的一些技術。我還將解釋，為什么流行的請求/響應模式的WEB協(xié)議與基于事件的流程建模，以及它在進行架構決策時的意義不一致的原因。 體系架構模式 誰需要它們? 軟件工程是藝術還是科學？在科學中，我們有明確的定義、定理和證據(jù)。在藝術中，我們有工具和技術、趨勢以及最

7、佳實踐?？茖W中提出了一些假設，其中一些變成定理，另外一些在經(jīng)過數(shù)個世紀的研究之后得到驗證，還有一些永遠沒有答案。在藝術中，新技術帶來新的趨勢，比如新聞和數(shù)字攝影。如果軟件工程是一門科學，定義我們在日常業(yè)務語言中使用的所有術語不應該是一件困難的事情，像服務、Web服務、面向服務的體系架構、BPM和BPM系統(tǒng)（BPMS）。的確，我可以利用數(shù)學精度來證明一個數(shù)據(jù)庫查詢算法的正確性。但是，我能夠以一種干脆、簡潔且通常會被接受的方式來回答，J2EE中的B2B集成是與純.NET Web服務解決方案相對的正確答案嗎？據(jù)我了解，對于我們中間的一些人來說，這不是問題。最后，任一種常見的貿(mào)易出版物的隨機調(diào)查指出，

8、每個人都可以給出自己的定義，而有些人甚至質疑IT存在的本質。我不得不得出結論，軟件工程仍然是藝術多于科學。這正好是我們需要合適的最佳實踐、框架和可重復過程的原因。 模式封裝了最佳實踐，簡練地定義了域問題，描述了使問題值得關注的原因，并提出了解決方案。模式并沒有解決獨特的問題。專業(yè)人員結合各種模式來解決更為復雜而且有時更為獨特的問題。Christopher Alexander說：“模式同時也是發(fā)生在世界上的事件和告訴我們?nèi)绾蝿?chuàng)建該事件的規(guī)則，以及我們必須創(chuàng)建它的時刻。它既是過程，也是事件?！蔽一叵肫鹞乙恢币詠碜钕矚g的定義：對象是帶有狀態(tài)或數(shù)據(jù)及行為的數(shù)據(jù)結構。就目前來說，可以把Web服務看作帶有

9、一個方法的對象。就像BEA WebLogic Platform 8.1所實現(xiàn)的那樣，會話式Web服務看起來更像是真正的對象：對它進行一次初始化，然后一直執(zhí)行方法。萬一您仍然不能肯定Web服務是粗粒度的對象，考慮：(1) IBM、BEA和 Microsoft宣布了WS-Eventing規(guī)范。它就像是優(yōu)秀但老式的對象觀察者模式。(2) 開放式網(wǎng)格服務體系架構（Open Grid Services Architecture）實現(xiàn)了網(wǎng)格服務協(xié)議的Web服務接口繼承。因此，Web服務提供數(shù)據(jù)和行為（Alexander的定義中的事件和規(guī)則），而BPMS 實現(xiàn)模式的流程組件。SOA是一個用于解決企業(yè)集成和系

10、統(tǒng)開發(fā)問題的體系架構模式。 我們已經(jīng)看到，SOA不是體系架構趨勢的革命，而是它經(jīng)過一段時間發(fā)展的演變成果。它圍繞為企業(yè)構建分布式系統(tǒng)而發(fā)展。誠然，Web服務以一種普遍接受且無二義性的方式提供底層技術，以解決系統(tǒng)連接性問題。也許是頭一次，Web服務成功地解決了互操作性的問題，而這是 CORBA、COM、 DCOM和 RPC 做夢也從未想過的事情。我肯定，作為中立語言，XML對此也準備一展身手。然而，SOA中包括進來的BPMS框架是一個新的、革命性的元素。Howard Smith 和Peter Fingar 描述的第三次浪潮是指一組全新的概念、框架和主流產(chǎn)品。它正在顯著改變企業(yè)轉化的方式，從而靈活

11、地管理和運行全局的和協(xié)作的電子商務實體。 業(yè)務流程管理的出現(xiàn)已經(jīng)有一段時間，它更多地用于工業(yè)中，而與IT無關。并發(fā)工程和六西格瑪被開發(fā)用來解決生產(chǎn)和流程改進中的及時協(xié)作問題，并且確實取得了相當?shù)某晒?。然而，?0年代晚期，出于多方面的原因，業(yè)務流程重構管理獲得的成功非常有限。但是最根本的原因是，重構是紙上談兵。沒有軟件來支持這樣一個復雜的任務。BPM在沒有考慮IT系統(tǒng)的情況下設計了自適應的企業(yè)。正如David Taylor 所寫： “對連續(xù)性流程優(yōu)化的需要要求從根本上重新考慮如何設計和構建信息系統(tǒng)。提出解決固定問題的固定解決方案已經(jīng)不再夠用?！?信息系統(tǒng)，像它們支持的業(yè)務模型一樣，必須在本質上

12、就是自適應的。 Taylor提出一種基于OO的開發(fā)技術，作為開發(fā)自適應IT的一種方法，這種技術稱為聚合工程（convergent engineering）。然而，OOP無法成功解決分布式計算和企業(yè)集成的問題。另外，負責對企業(yè)建模的業(yè)務分析人員也沒有采用OO。 BPMS將流程建立為用于建模、軟件設計和運行時執(zhí)行的統(tǒng)一結構。過去，開發(fā)趨勢一直在影響我們對企業(yè)建模的方式。功能式編程使功能需求技術流行起來。關系數(shù)據(jù)庫帶來了RDBS分析和設計的流行。面向對象的編程則為OO分析和用例開發(fā)鋪平了道路。但是在大多數(shù)情況下，業(yè)務分析人員不會使用開發(fā)專門術語，因此產(chǎn)生了對需求可跟蹤性中通常影響的另一種翻譯的需要。

13、 BPM規(guī)范正在快速演變?yōu)闃藴?。市場中已?jīng)出現(xiàn)了支持業(yè)務建模、優(yōu)化和運行時執(zhí)行的產(chǎn)品。正如BEA的WebLogic Platform 8.1和其他BPMS產(chǎn)品所實現(xiàn)的那樣，以流程為中心的BPMS 方法用于系統(tǒng)開發(fā)生命周期，它消除了對運行時阻抗不匹配的業(yè)務需求。 靈活的企業(yè)擁有自適應的業(yè)務和自適應的IT系統(tǒng)。如果構建企業(yè)解決方案的過程中出現(xiàn)一個新的問題，那么它一定是需求變化的速度。它的速度之快是前所未有的。BPMS引擎添加了一個新的層到傳統(tǒng)的開發(fā)堆棧（參見圖1）中，并引入服務質量來解決企業(yè)集成中的根本問題。BPMS引擎使編程最易變的部分集成點的軟布線變得容易。軟布線是以正式語言顯式描述的，并由B

14、PMS引擎（又名有限狀態(tài)機引擎）執(zhí)行。正如BEA WebLogic Integrator和其他BPMS產(chǎn)品所實現(xiàn)的那樣，業(yè)務與IT資源可以同時在一個可視化的只能IDE中查看和修改流程。只需輕擊鼠標，便可部署到運行時BPMS執(zhí)行引擎。業(yè)務模擬可以運行，而性能工程可以在系統(tǒng)完成之前完成；這種方式聽起來就像CASE工具。SOA和BPMS工具將靈活企業(yè)的實時執(zhí)行儀表板帶向主流。（圖01） 在本文余下的部分中，我將描述一個典型的金融服務企業(yè)的開發(fā)，并提出一條通向基于BPMS的SOA的遷移路徑。該路徑是增量的，但是它需要戰(zhàn)略思考和對未來遠景的承諾。作為回報，它將允許投資的早期回報，并將遺留企業(yè)轉化為完全自

15、適應的靈活企業(yè)。 從企業(yè)遠景到組織筒倉（Silo） 企業(yè)從遠景開始。CEO和董事會采用遠景和行業(yè)使命陳述。C級管理人員定義策略，并適當?shù)匕才帕鞒虂砉芾韴?zhí)行（參見圖1）。定義功能角色和責任，然后創(chuàng)建企業(yè)界線。業(yè)務分類（Line of business，LOB）在本質上可以是水平或垂直的（參見圖2）。垂直LOB具有以下特征： 獨立的操作域。 特有的管理和策略。 開發(fā)和維護自己的IT自動化孤島。 足夠大以至于可以創(chuàng)建多種業(yè)務分類；例如，抵押貸款證券、市政公債、貨幣市場，等等。（圖02）水平LOB具有不同的特征集合： 提供業(yè)務控制。 管理的支配和一致。 需要訪問由垂直LOB管理的數(shù)據(jù)。 合適的手動流程

16、和書面報告。 在第二個信息紀元（不要與第二次浪潮混淆）中，我們使用了各種編程技術來鏈接自動化孤島，從FTP、數(shù)據(jù)庫復制、EAI和消息收發(fā)開始。此方法產(chǎn)生了一整套新問題： 接口的多重性: 一份Morgan Stanley Dean Witter報告表明，通常的金融服務客戶需要維護6000個接口，為此每年花費2500萬美元，而且每年還需構建900個新的點到點接口，為此需另外花費2500萬美元進行構建，并且還要花費400萬美元進行維護。 調(diào)停流程: 必須在每一個倉庫上實現(xiàn)，需要消耗有價值的時間和昂貴的資源。這是一項常用技術，用于檢驗由多個實體修改的引用數(shù)據(jù)。 流程: 在中間件中進行硬布線。在分析過程

17、中捕捉流程所花費的時間和金錢屬于浪費。企業(yè)最重要的資產(chǎn)流程隱藏在n(n-1)個意大利面式接口的迷宮中。 開發(fā)新的水平流程：需要多個LOB 的協(xié)調(diào)。 實現(xiàn)特定和專用的接口：需要專門化和一次性編程。重用消失，維護方面的投入顯著增加。 異常難于跟蹤： 錯誤解析通常需要訪問多個系統(tǒng)。人工干預和解釋是不可避免的。找尋答案需要花費大量寶貴時間，并對客戶滿意程度和收益性方面的大致情況有著直接影響。 流程無處不在。您能發(fā)現(xiàn)它們嗎？ 對于企業(yè)來說，流程可以是客戶層面上的，也可以是內(nèi)部的，或者可以是更大流程的組成部分。我們在同樣的企業(yè)中可以找到內(nèi)部流程。流程通常涉及到人與系統(tǒng)的交互，或者只是系統(tǒng)之間的交互（參見圖

18、3）。交易流程是大規(guī)模流程的一個很好的例子。行政管理部門的交易人員在他的銷售訂單系統(tǒng)中接收一個來自對沖基金管理人員的交易執(zhí)行命令，或者他接到一份傳真或一個電話。交易人員檢查庫存系統(tǒng)的安全性或資金，并借助他的交易對手執(zhí)行交易。可以制造紙質入場券，而交易助手可能必須在下行系統(tǒng)中進入它。（圖03） 當因為下行系統(tǒng)之一錯誤地再進入，而幫助臺分析人員收到一份異常報告時，另一個內(nèi)部流程啟動了。然后，他在內(nèi)部記事薄之一中查找數(shù)據(jù)（原始進入記錄），請求來自事務部門的傳真（我們假定討論的交易超過了結算日期），而且因為他在兩天內(nèi)沒有收到回復，也許他會再次重復同樣的行為。這個流程最終當分析人員解決了問題時終止，當然

19、，除非他調(diào)到另一個部門或者調(diào)出公司。然后，顧問們必須參與進來，跟蹤問題和流程，這通常需要一大筆錢。每月的客戶聲明是定期性企業(yè)范圍內(nèi)流程的一個傳統(tǒng)例子，通常為水平LOB所特有。在大多數(shù)情況下，客戶在被不同LOB支持的產(chǎn)品中擁有帳號，例如，股票、U.S.證券和外匯。在月末發(fā)送多個聲明將會十分混亂。法律和一致性問題還需要交叉引用多個倉庫的數(shù)據(jù)。Patriot和 Sarbanes-Oxley Acts (一個新的業(yè)務流程，但是不賺錢)的一個主要問題是要訪問由大量LOB所擁有的數(shù)據(jù)，有時還要環(huán)繞半個世界。EAI技術和消息收發(fā)試圖借助早先闡明的限制解決這些問題。 通向靈活性的道路：以BPM為中心的SOA

20、讓我們考慮帶有Web服務的、以BPM為中心的SOA如何將現(xiàn)有的遺留企業(yè)轉換為自適應性的企業(yè)。水平流程和異常管理是用于SOA啟用的理想候選者，可以演示可調(diào)整的和速度快的ROI。沒有經(jīng)歷業(yè)務流程再造的嚴謹，我們必須定義良好的流程圖。流程圖也是實行業(yè)務流程重新設計的第一步。如果使用BPMS 設計工具(Proactivity, Intalio, Interfacing Technologies)，您可以把度量關聯(lián)到流程和行為，例如，性能、開銷、IT資源、FTE、逝去的時間、容量，等等。許多BPMS設計工具允許您運行模擬，并繼續(xù)進行流程優(yōu)化（運行what-if場景），但是這并非本文的重點。對于我們的重點

21、來說，以下列出的是良好流程圖的一些特征： 考慮流程而不是功能 : 流程告訴您完成什么工作以及如何完成。功能描述誰在哪里來完成它。 從客戶的觀點出發(fā)： 考慮從外部業(yè)務事件開始的流程，例如，一次交易、一份訂單、一個主張、一個報價請求。 在更寬泛的意義上并基于不同的服務質量來劃分客戶類別： 您生態(tài)系統(tǒng)中的性能、供應商、業(yè)務伙伴。 流程反映狀態(tài)變化：交易訂單、現(xiàn)金支付。從可管理的流程數(shù)量610開始。記住，大多數(shù)人最多只能保留一個頁面上的七樣東西。 定義核心流程和子流程：這里沒有科學理論，只有最佳實踐。然而，要當心P-calculus2 和Petri-nets；它們將在接下來的10年內(nèi)帶給BPM科學的嚴

22、密性。 將流程分解為行為 下一個目標是通過分解行為來定義小單元。我們將這項工作稱為Elementary Business Services (EBS)。如果您從多維矢量代數(shù)開始回想，空間中的任意一點都可以被定義為單元矢量的線形組合。在我們的例子中，我們以可以通過編排EBS子集來構造任何流程的方式定義了所有EBS。正如您可能猜想的那樣，我們將EBS實現(xiàn)為Web服務。識別EBS的正確集合和粒度水平很重要。這與設計對象的重要程度相同。相同的規(guī)則和技術封裝、狀態(tài)相關性、內(nèi)聚性、松散耦合和重構同樣適用，這并不使人驚奇。 EBS的業(yè)務量體現(xiàn)出了大量實際優(yōu)點： 1. 它是要重用的最終指南。可以通過任何想像得

23、到的方式編排EBS，以形成新的LOB。 2. 連續(xù)性流程改進不必等到IT適應新的業(yè)務模型。 3. EBS對企業(yè)生態(tài)系統(tǒng)中的企業(yè)和業(yè)務伙伴可用。 4. 放棄使用一個系統(tǒng)并不是一個一蹴而就的過程，而是一個循序漸進的過程。 5. 可以以一種易于管理且性價比高的方式合并和獲得IT。 6. 可以幾乎實時地設計和執(zhí)行一個新的業(yè)務流程。 從圖4中可以看出，我們可以使EBS在BEA WebLogic Platform 8.1（集成組件）的一個實例中可用。從技術上說，在BEA WebLogic Integration中，Web服務被稱為業(yè)務流程資源。我們使用IDE編排新流程，使用門戶添加UI，然后將它部署為一組

24、EJB來執(zhí)行。就是這么簡單！現(xiàn)在流程是一項IT資產(chǎn)了，就像數(shù)據(jù)庫表、存儲過程、遺留COBOL書籍和專用的計算c庫。（圖04） 許多金融服務機構的業(yè)務分類是水平的，管理高凈值的私有客戶。在啟用了BPMS SOA的企業(yè)中，開發(fā)IT基礎結構來支持這樣的新LOB完全可以與正確放置業(yè)務模型并行完成（參見圖5）（圖05） 考慮A 現(xiàn)象，它們并沒有創(chuàng)造任何新的EBS。所有EBS位于任何其他郵件訂單一覽表書店中的恰當位置：定購書籍，檢查庫存，信用卡付帳，打印聲明，準備裝運，給客戶發(fā)送電子郵件。但是它沒有創(chuàng)建新流程，沒有質疑已經(jīng)建立好的流程，甚至不用花費什么力氣。 正如Howard Smith 和 Peter

25、Fingar所說的那樣：“在BPM的第三次浪潮中，筒倉式思考和點到點的技術集成被靈活的、基于業(yè)務流程的體系架構所代替?！贝送?，Gartner Group 現(xiàn)在聲明，繼續(xù)將業(yè)務邏輯硬布線到軟件或中間件中或者堅持人工步驟的公司將輸給部署流程管理體系架構的競爭對手。 實時處理業(yè)務 退一步說，預測將來是很困難的事情，但是我們用非?？茖W的態(tài)度對待它，而且始終試著這么做，不管對還是錯。統(tǒng)計和預測是關于預測將來的兩門科學。投資組合評估和保險統(tǒng)計研究是有關預測的科學。實際上，我們的預測僅僅基于我們已經(jīng)經(jīng)歷過的、過去的性能和趨勢。實時處理業(yè)務需要預測未來的業(yè)務情況。然而，基本的業(yè)務協(xié)議和框架必須合適。今天，技術

26、革新、BPMS和SOA是將業(yè)務目標與IT相結合的基礎。流程提供一個封裝了變化的新層。90年代早期，PowerBuilder和VB風格的工具使客戶端/服務器和關系數(shù)據(jù)庫系統(tǒng)的開發(fā)流行開來，通過與此相同的方式，BPMS引擎將在未來建立流程驅動的企業(yè)。事實上我預測，在我們的一生中，我們將看到對運行時流程的需求，該類流程用于實時變化或對自修改流程的需要。無疑，人類希望能夠掌管該類變化，但是通過使用UDDI- ( 代表流程)找出最可能的服務契約和使用描述域專業(yè)知識和市場情況的規(guī)則進行決策，BMPS能夠使這項工作更加容易。隨著BPMS的普及，靈活性將被極端自適應所代替。結束語 在本文中，我描繪了合并SOA

27、和BPM的藍圖。從一幅企業(yè)的自頂向下流程圖開始，我們定義了基本業(yè)務服務的組合選擇。垂直LOB擁有并部署EBS。Web服務實現(xiàn)它們，并使它們對企業(yè)可用。通過使用BPMS引擎的一個實例，可以設計、開發(fā)、測試新的流程，并通過結合現(xiàn)有的EBS，在數(shù)日內(nèi)添加業(yè)務值。 在我的下一篇文章中，我將：(1) 講述用于給現(xiàn)實世界業(yè)務保險流程建模的BPM技術，并提出一個純BPM解決方案和一個混合解決方案；(2) 使用Web服務和JMS連接設計EBS并實現(xiàn)它們；(3) 提出一個使用WebLogic Platform 8.1的物理基礎結構；并 (4)討論面向服務體系架構中的BPMS難題和新出現(xiàn)的模式。 直到：流程無處不

28、在。您能發(fā)現(xiàn)它們嗎？(三)簡單到復雜，BPM技術促進SOA發(fā)展 HYPERLINK %20 CNET中國PC類型:轉載 作者: csdn 責編:小蝎 時間:2006-10-23 BPM(企業(yè)流程管理，Business Process Management) 與 SOA (服務導向架構，Service Oriented Architecture)各自歷經(jīng)多年的發(fā)展，越來越成為人們的焦點。 眾多廠商成為了SOA技術架構的推動者，其中包括IBM、BEA、HP、Oracle和SAP。 SOA可以看作是B/S模式、XML/Web Service技術與管理軟件的結合。它通過組合單獨業(yè)務和流程實現(xiàn)復雜的業(yè)務

29、應用，而這些業(yè)務功能和流程稱為服務， SOA把業(yè)務流程視為獨立于應用程序及其運行的平臺的可復用組件。 從SOA概念提出以來，越來越多的主流廠商開始了BPM與SOA的應用。今年3月，BEA收購Fuego擴展SOA到BPM軟件，以此使用新的BPM升級SOA平臺。2月，HP和Oracle集團宣布，HP的服務咨詢和集成（Services Consulting & Integration）將會同Oracle的Fusion中間件，加入到它的SOA的投資組合以及HP OpenView管理軟件套件，以Fusion融合SOA。去年，Oracle收購了BPM專業(yè)公司Collaxa；SAP重新設計軟件，以便集成自由

30、版本的面向BPM的中間件NetWeaver。 除平臺提供商以外，開源廠商也試圖占領擁有自己的SOA卻缺乏服務的市場。JBoss公司在2005年10月發(fā)布的企業(yè)過程管理引擎，圍繞業(yè)務過程執(zhí)行語言（Business Process Execution Language BPEL）提供了一種可插拔的體系結構、擴展的任務管理以及新的可擴展性。BPEL雖然是用來編排Web服務的，但依然適合用來集成，而不是深入的業(yè)務邏輯。 BPM無論從技術還是方法上都將促進SOA的發(fā)展。在此過程中，大型平臺廠商IBM、BEA、SAP、Oracle等將會嘗試建立一種新SOA標準；而開源廠商努力構建一套工具，不把自己禁錮于用

31、一種方法構建SOA。 從BPM的IT需求與SOA技術角度上看，BPM與SOA的融合也具有先天優(yōu)勢。BPM的范圍覆蓋了企業(yè)運營的各個環(huán)節(jié)，如生產(chǎn)、銷售、物流、財務等企業(yè)經(jīng)營活動，甚至延伸到供應商和經(jīng)銷商。其產(chǎn)品開發(fā)包括6個部分，從基礎開始為：開發(fā)語言，如BPEL、Java等；BPM服務器，包含EAI/BPM平臺產(chǎn)品；BPM工具，包括用戶接口工具、過程建模工具、軟件需求工具等；BPM套件；BPM知識架構；BPM系統(tǒng)和其應用。由此可見，BPM的IT需求與SOA技術具有以下相似點： 1BPM涵蓋范圍廣泛，需要完成因事件觸發(fā)的完全不相干的事件，此特點正與SOA的松散耦合特點相吻合。 2BPM需要多部門、

32、區(qū)域的協(xié)同。在此中環(huán)境中網(wǎng)絡環(huán)境的安全性可由SOA技術構架中的WS-Security、LDAP(Lightweight Directory Access Protocol-輕量級目錄訪問協(xié)議)、PKI(Public Key Infrastructure-公鑰基礎設施)架構和數(shù)位簽章等機制來完成。 3BPM系統(tǒng)構成元素種類繁多而復雜，包含分布于各模塊的企業(yè)邏輯和規(guī)則。而SOA可以看作是B/S模式、XML/Web Service技術與管理軟件的延續(xù)。 當前多數(shù)SOA環(huán)境能提供系統(tǒng)管理工具給系統(tǒng)管理員使用，協(xié)助管理SOA架構下模塊的安裝、移除、啟動等。目前能夠實現(xiàn)SOA的產(chǎn)品包括：Microsoft

33、 Biztalk Server, webMethods Business Integrator, IBM SeeBeyond, TIBCO和Vignette。在SOA提出以前，大部分BPM產(chǎn)品在流程圖中采用自有定義流程邏輯。 4企業(yè)BPM系統(tǒng)的實施往往從最簡單的開始，逐漸提升為復雜的BPM系統(tǒng)。而SOA模塊化的特性正好吻合了此特性。 (四)分析:BPM與SOA之間的區(qū)別及聯(lián)系 HYPERLINK %20 CNET中國PC類型:轉載 作者: newhappy2008 責編:小蝎 時間:2006-10-23 關于業(yè)務流程管理(BPM)和面向服務架構(SOA)之間關系的討論熱鬧非凡。二者也是多年來的

34、熱門話題，但是關于它們的討論通常都出現(xiàn)在互不相關的論壇上，討論它們的人通常也屬于不同的圈子。不過現(xiàn)在這種情況正在改變，因為這兩個概念以及相關技術的使用者和提供者正日漸將二者結合起來看待。 BPM陣營通常聲稱，SOA對于實現(xiàn)BPM來說不是必需的。只需部署一個BPM套件，就可以更快地實現(xiàn)目標而不會帶來多少復雜性。SOA陣營則注重于如何從一般意義上解決企業(yè)IT的復雜性。該陣營通常聲稱BPM是SOA的一個特性，但是它是SOA解決方案的一部分，而不是一個單獨的東西。當SOA領域的人士談到BPM時，該術語通常與服務編排或流程整合同義，而不強調(diào)對業(yè)務分析人員友好的建?；蛉藛T交互，而后者對BPM陣營來說非常重

35、要。 為了澄清這些誤解，我認為有必要闡明BPM與SOA的不同本質:SOA是一種架構方法;BPM則是一組協(xié)調(diào)活動。 因此，可以很容易地得到使用SOA或不使用SOA的BPM，反之亦然。我們來看看不同組合的優(yōu)點。 如果部署一個不使用SOA的BPM套件，則可以獲得快速創(chuàng)建、執(zhí)行和監(jiān)控/管理業(yè)務流程的能力。業(yè)務流程的模型可以由業(yè)務分析人員創(chuàng)建，但是其完整實現(xiàn)則需要與底層IT系統(tǒng)的集成(以及定義用戶如何與該流程交互，但是現(xiàn)在我們暫不考慮)。BPM套件(如BEA的AquaLogic BPM Suite)支持使用各種不同的技術(面向服務的或不是面向服務的)對應用程序和數(shù)據(jù)庫進行輕松訪問。實現(xiàn)由代碼和來自于并依

36、賴于底層系統(tǒng)接口的元數(shù)據(jù)組成，因此，對底層數(shù)據(jù)庫和應用程序的任何更改都將導致對業(yè)務流程的更改。 如果組織和IT環(huán)境規(guī)模比較小，并且由同樣一組人來控制所有的系統(tǒng)(包括BPM套件)的話，這是完全可以的。如果底層系統(tǒng)完全不更改的話，這種方法同樣運行良好。 但是，如果BPM套件由一個小組部署，并消費來自另一個小組的系統(tǒng)的服務，那么協(xié)調(diào)和管理每個小組中的更改的任務很快就會變得非常困難。這是SOA要解決的典型問題，因此，SOA可以應用于BPM套件的部署，就像應用于其它地方一樣。 如果BPM作為SOA的一部分進行部署，這意味著當一個業(yè)務流程連接到底層系統(tǒng)時，它連接到由企業(yè)服務總線所提供的代理服務，這樣就隱藏

37、了底層應用程序和數(shù)據(jù)庫的復雜性。這具有以下優(yōu)點: 將業(yè)務流程連接到系統(tǒng)的過程會更簡單，因為IT可以公開更有用的接口，比如聚合的數(shù)據(jù)服務或使用標準協(xié)議而不是專有協(xié)議的服務。這減少了實現(xiàn)流程所需的IT工作量，并允許流程人員將精力集中于流程，而不是粘合流程與底層系統(tǒng)所需的技術。 它使得實現(xiàn)更為健壯，因為對底層IT系統(tǒng)的更改不必影響流程所使用的接口。 它在BPM套件之外提供了一個獨立的控制和管理層。這允許IT小組更好地管理他們所擁有和維護的服務的策略和資源。 SOA還支持從BPM套件中獲得對它所連接到的系統(tǒng)的更好可見度。IT小組可以在服務注冊庫中注冊服務，流程開發(fā)人員(甚至可能是業(yè)務分析師)可以在構建

38、流程時瀏覽這樣的注冊庫。這確保了服務可以被正確地使用和重用，而且通常簡化了業(yè)務流程，因為使用正確的服務可以將流程本身的復雜性降至最低。 無疑，這些優(yōu)點只有在IT基礎架構足夠復雜，并且/或者BPM項目達到一定的范圍和規(guī)模時才能顯現(xiàn)出來。因此，在很多情況下，應該首先開發(fā)出BPM，而將SOA組件留待以后考慮。 最好的方法是一開始就讓業(yè)務運作團隊和IT企業(yè)架構小組保持良好的對話，并針對未來進行規(guī)劃，同時支持戰(zhàn)術性執(zhí)行。這就需要正確地組合產(chǎn)品。例如，BPM套件本身應該能夠提供豐富的連通性，以便無需全面應用完善的SOA來使得BPM運行，這一點非常重要。類似地，BPM套件應該支持SOA，這樣BPM與SOA才

39、不至于存在于獨立的豎井中，這也很重要。 (五)OASIS總裁Patrick Gannon談SOA與開放標準 HYPERLINK %20 CNET中國PC類型:轉載 作者: Cnet 責編:小蝎 時間:2006-10-23 Patrick Gannon：今天來給大家介紹一下SOA 對產(chǎn)業(yè)的一些好處和標準對產(chǎn)業(yè)的一些影響。這一頁是我的簡單介紹。主要介紹一下開放標準和SOA 對公司的發(fā)展有哪些影響。今后的電子商務將會搭建在SOA 的平臺上，現(xiàn)在SOA 和開放標準還處于初期階段。這一頁幻燈片是介紹了一下SOA 的基本情況。為了達到SOA 所承諾的前景，需要建立一個共同的框架體系和標準體系。公司要在SO

40、A 投資，必須要獲得一些收益，這樣保證他們的資產(chǎn)有更好的流動性，也保證他們的資產(chǎn)有長期保值的能力。所謂流動性就是靈活多樣的意思，也就是說SOA 的標準體系和核心技術要能夠滿足各式各樣應用的需求。SOA 很重要的特性是能夠讓你對軟件的投資有長期的保值性，能夠避免重復投資，可以讓你的軟件模塊可以重復地使用。 為了達到這些目標，有一些很基本的工作需要做。我們必須要有一個共同的體系結構和一套共同的詞匯表，大家都知道每一個軟件的變量代表了什么意思?，F(xiàn)在的問題是各個行業(yè)一些主要的技術廠商，他們看的都局限于他們這個行業(yè)或者是自己的技術體系來考慮整個軟件應用的問題。這個問題是不同的詞匯表，不同詞匯的意義和不同

41、的表示方法都對使用軟件技術的發(fā)展帶來了障礙。我們的解決方法是什么？在商業(yè)業(yè)務層面創(chuàng)造互操作性。 其中一個方法是實現(xiàn)跨部門的應用互動和應用的集成。為了達到這個目標，開放標準是其中一個很重要的措施。很多公司問為什么我們需要標準？我們看到為了建立標準體系需要很多的投入，一個標準組織就是為了讓業(yè)界的企業(yè)一起共同做標準的工作，降低大家分頭做標準的成本。軟件公司需要知道他們做什么標準、同時應該了解標準是怎么產(chǎn)生的，通過什么樣的方式使標準有一個基本的接受情況。我們請了Delphi Group Research 做一個標準的調(diào)研，看整個企業(yè)對標準的認識，和目前對標準研究的看法。有三個重要的調(diào)研結果。采用開放標

42、準使得企業(yè)的軟件可以重復使用，數(shù)據(jù)也可以在不同的平臺上進行共享。第二個結論是采用了開放標準，企業(yè)的研發(fā)工作可以在更大的協(xié)同范圍，甚至是攝入最終用戶來進行共同的開發(fā)。我們看到開放標準對于Web Service 的使用是非常重要的。 OASIS 是一個國際標準組織，主要是針對先進的結構化數(shù)據(jù)的信息標準。OASIS 不光只是研究和產(chǎn)生標準，同時也跟其他國際組織一起合作來推動標準的采用和技術的發(fā)展。OASIS 有一個非常開放的組織結構，可以讓會員很容易在組織里面表達自己，目前有650 個不同的企業(yè)會員，來自80個國家。OASIS 在Web Service 、電子商務、eBusiness 和文檔管理方面

43、是目前世界上權威的標準組織。通過13年的努力，OASIS 已經(jīng)得到廣泛的承認，OASIS 不僅可以直接向國際標準組織、國際電聯(lián)和聯(lián)合國相關標準組織直接提交標準提案。 OASIS 不光只是由技術廠商參加的標準技術組織，實際上有35的成員來自于客戶，也就是說可以對甲方有影響力的部門，還有大概15的研究單位。OASIS 也是一個發(fā)展很快的組織，我來中國很重要的目的是希望能夠參與快速發(fā)展的亞太地區(qū)的經(jīng)濟活動。 這是OASIS 在亞太地區(qū)目前的成員，這是在大陸地區(qū)的會員成員，我已經(jīng)參觀過了書生、長風聯(lián)盟和神州數(shù)碼，以及互聯(lián)網(wǎng)中心。根據(jù)我這個星期在這邊的感覺，我認為很快會有更多的公司參加OASIS 這個組

44、織。我邀請大家能夠參與OASIS 這個組織。 OASIS 是為SOA 和Web 服務的發(fā)展提供重要的指導作用。OASIS 的工作覆蓋了SOA 和Web 服務一些非常重要的領域。這是OASIS 在SOA 和Web 服務里重要的領域和技術工作組所覆蓋的一些SOA 和Web 服務的重要領域。OASIS 不但是推動標準的研發(fā)和發(fā)布，也推動標準的全面采用。OASIS 是有25個技術委員會在SOA 領域里展開技術的研究工作。對于公司對eBusiness 有興趣的公司，有一個商業(yè)編排工作組。標準、訪問權限控制也是OASIS 在SOA 和Web 服務領域里的重要工作。 Web 服務的管理也是我們一個很重要的技

45、術研究工作?？煽康南鬏斠彩俏覀兊墓ぷ髦弧＿@是UDDI部分的工作。你們看到在OASIS 里對SOA 和Web 服務做了大量的研究和標準建設工作，這也是很多公司參加OASIS 的直接目的。大家都知道當一個公司在新技術方面做投入時都會涉及到一個潛在的風險。SOA 可以幫助公司降低采用新技術的風險。企業(yè)今天可以做什么呢？一個是可以參加OASIS 組織，或者是可以觀察、了解一下OASIS 組織能做什么。因為這些標準都是在全世界推廣和采用的，所以非常重要的是要讓在中國的軟件企業(yè)或者是中國的最終用戶能夠對他們的技術需求和他們的一些要求很明確地表示出來。表示出來以后，能夠影響標準的產(chǎn)生，而且標準是在全球

46、范圍內(nèi)推動的。其中軟件公司在OASIS 的工作是提出新的研究方向。其中一個例子就是書生公司已經(jīng)在上個星期提出了UOML在OASIS 里立項。我相信肯定有很多其他的公司可以把他們創(chuàng)新性的技術提案通過OASIS 這個平臺建立起來。對于小的公司，沒有很多錢來參加像這種標準組織的話，也可以多看一看標準組織能不能對你們的市場活動帶來好處。 除了標準的研究工作以外也跟很多組織合辦活動，把會員的一些技術在更大的范圍里展示。對于最終客戶來說，OASIS 對他們也有很多好處。對于最終用戶如果能夠把他們對技術的需求明確提出來之后，可以在明確的過程中考慮進去。OASIS 有很多會員是政府部門，這些政府部門參加的原因

47、是他們希望觀察標準的研究情況，對標準提出一些建議。這些政府部門也利用OASIS 平臺來了解哪些技術方向值得政府的資助，對參加這些研究方向的企業(yè)優(yōu)先考慮進行資助。對于開放標準和SOA 的研究，希望能夠邀請和OASIS 一起共同討論SOA 和開放標準的工作(六)業(yè)界觀察：為什么SOA如此得勢？【正文】作為未來的技術趨勢之一，SOA正無可爭議地引領著軟件業(yè)的新一輪浪潮，并在未來給軟件和網(wǎng)絡帶來革命性的變化。為什么SOA如此得勢?這是因為SOA改變了過去開發(fā)應用的模式，將軟件按照業(yè)務需求定義成“組件”，作為共享資源，提供以服務為中心的應用軟件設計方法。這種方法，能夠提高IT對業(yè)務的響應能力，使企業(yè)得以

48、實時支持業(yè)務的變化，最終幫助企業(yè)轉變?yōu)榉镇寗有推髽I(yè)。 早在2002年Gartner就預測，到2008年，SOA將成為占有絕對優(yōu)勢的軟件工程實踐方法，它將結束傳統(tǒng)的整體軟件體系架構長達40年的統(tǒng)治地位，屆時，將有70%的企業(yè)在進行企業(yè)IT建設時會轉向SOA。從技術上講，SOA并不是一個新概念，早在20世紀90年代中期，Gartner就提出了SOA的概念，但當時的軟件技術發(fā)展和信息化水平還不足以使它走入實用階段。進入21世紀，隨著Web服務等相關標準的出現(xiàn)和成熟，SOA開始從概念走向實用。 SOA不是某個產(chǎn)品，也不是某個技術，而是一種軟件設計架構和方法。SOA要求開發(fā)者從服務集成的角度來設計應用

49、軟件，它將應用程序的不同功能組件定義為“服務”，通過“服務”之間的良好接口聯(lián)系起來。(也就是“服務”之間的松耦合。)接口是采用中立方式進行定義的，獨立于實現(xiàn)“服務”的硬件平臺、操作系統(tǒng)和編成語言。而且這些構建在各種各樣系統(tǒng)中的“服務”可以以一種統(tǒng)一和通用方式進行交互。保證系統(tǒng)靈活性，另外，還可以保證“服務”的重復利用。 由此可以看出，SOA的核心概念是“重用”和“互操作”，從而使企業(yè)的IT系統(tǒng)擁有極大的靈活性。SOA的另一層意義就是整合，它將企業(yè)的IT資源整合成標準的、可操作的服務，使其能被重新組合和應用。在這種架構下，IT系統(tǒng)的復雜性并沒有增加，相反，隨著系統(tǒng)的不斷完善，整個系統(tǒng)的架構將變得

50、更加清晰。 現(xiàn)在隨著網(wǎng)絡技術的發(fā)展，企業(yè)在信息化建設中產(chǎn)生了大量為滿足產(chǎn)品或服務需要的軟件系統(tǒng)，如:ERP、CRM、OA、SCM等一系列IT軟件系統(tǒng)。但這些系統(tǒng)一般都是單獨實施、獨立存在的，由于數(shù)據(jù)標準不統(tǒng)一，接口不一致，系統(tǒng)間往往缺少聯(lián)系與合作，這也就導致了一個系統(tǒng)成為一個“孤島”。而基于SOA的理念，則使企業(yè)在需要改變IT系統(tǒng)時的靈活性大為增加。 SOA架構定義了搭建企業(yè)軟件架構的一種新方法，它的出現(xiàn)使所有應用在交換數(shù)據(jù)和處理過程中，不需要考慮應用軟件是用什么編程語言開發(fā)的或在什么操作系統(tǒng)下運行。在這種模式下，一個應用或應用的一部分其實是一種服務，其他的應用和客戶都可以在無需編寫大量代碼的

51、情況下使用這些服務，這一切都使一些大企業(yè)或在地理上分布范圍比較廣的開發(fā)隊伍能夠更好地合作，因為這些SOA架構下的中間件業(yè)務模塊都能夠被重新配置或以新方式優(yōu)化來滿足新的需求。正是SOA的重用性和互操作性所帶來的靈活性實現(xiàn)了企業(yè)IT資源整合，使企業(yè)IT資源真正面向于服務。 SOA作為一種概念雖然已經(jīng)成熟，并得到了國內(nèi)外主流軟件開發(fā)商和企業(yè)客戶的認可，目前主流軟件廠商均已經(jīng)完成了基于SOA的改造，但在客戶端大規(guī)模的應用還有許多事情要做。首先，它包括一系列技術和規(guī)范，面臨諸多挑戰(zhàn)，尤其在項目開發(fā)初始，付出的代價要比傳統(tǒng)軟件項目大得多。其次，實現(xiàn)SOA的Web服務技術尚不成熟，標準還處在發(fā)展之中。目前，

52、很多企業(yè)對于SOA的認識還僅限于一種“整合”IT技術的概念，人們對于SOA認識的誤區(qū)還有很多。面向服務架構（SOA）的原則Web service已經(jīng)不再是新婚的娘子。眾多企業(yè)都已經(jīng)創(chuàng)建各種實驗性Web Services 項目，事實證明，這項新興的分布式計算技術確實能夠降低集成和開發(fā)的成本。另外，一些關鍵的Web Ser vices標準紛紛制定，強安全（robust security）和管理方面的產(chǎn)品也陸續(xù)問世。對于志向遠大的企業(yè)來說，他們已經(jīng)在考慮下一步了。對大多數(shù)公司來說，下一步要考慮的不再是點對點的應用，而是Web services在企業(yè)間以及業(yè)務伙伴間更為寬廣的應用。這種技術的變遷需要更

53、松散耦合、面向基于標準的服務的架構。這樣一個架構要求對IT在組織中的角色有新的觀點和認識，而不僅僅是一種實現(xiàn)方法。通過對業(yè)務的敏捷反應，企業(yè)可以得到實實在在的回報，而要達到這一點，面向服務架構設計師的角色非常關鍵。除此之外，潛在的回報更是不可勝數(shù)分布計算技術能夠保證對業(yè)務需求足夠靈活的反應，而這種業(yè)務上的敏捷正是各公司夢寐以求而目前還遙不可及的。分布式計算將網(wǎng)絡上分布的軟件資源看作是各種服務。面向服務架構是一種不錯的解決方案。但這種架構不是什么新思想；CORBA和DCOM就很類似，但是，這些過去的面向服務架構都受到一些難題的困擾：首先，它們是緊密耦合的，這就意味著如分布計算連接的兩端都必須遵循

54、同樣 HYPERLINK /AP API的約束。打比方說，如果一個COM對象的代碼有了更改，那么訪問該對象的代碼也必須作出相應更改。其二，這些面向服務架構受到廠商的約束。Microsoft控制DCOM自不必說，CORBA也只是一個偽裝的標準化努力，事實上，實現(xiàn)一個CORBA架構，經(jīng)常都是在某個廠商對規(guī)范的實現(xiàn)上進行工作。Web services是在改進DCOM和CORBA缺點上的努力。今天應用Web services的面向服務架構與過去不同的特點就在于它們是基于標準以及松散耦合的。廣泛接受的標準（如 HYPERLINK /XML XML和 HYPERLINK /SOA SOAP）提供了在各不同

55、廠商解決方案之間的交互性。而松散耦合將分布計算中的參與者隔離開來，交互兩邊某一方的改動并不會影響到另一方。這兩者的結合意味著公司可以實現(xiàn)某些Web services而不用對使用這些Web services的客戶端的知識有任何了解。我們將這種基于標準的、松散耦合的面向服務的架構簡稱為SOA。SOA的強大和靈活性將給企業(yè)帶來巨大的好處。如果某組織將其IT架構抽象出來，將其功能以粗粒度的服務形式表示出來，每種服務都清晰地表示其業(yè)務價值，那么，這些服務的顧客（可能在公司內(nèi)部，也可能是公司的某個業(yè)務伙伴）就可以得到這些服務，而不必考慮其后臺實現(xiàn)的具體技術。更進一步，如果顧客能夠發(fā)現(xiàn)并綁定可用的服務，那么

56、在這些服務背后的IT系統(tǒng)能夠提供更大的靈活性。但是，要得到種強大和靈活性，需要有一種實現(xiàn)架構的新方法，這是一項艱巨的任務。企業(yè)架構設計師必須要變成“面向服務的架構設計師”，不僅要理解SOA，還要理解SOA的實踐。在架構實踐和最后得到的架構結果之間的區(qū)別非常微妙，也非常關鍵。本文將討論SOA的實踐，即：面向架構的設計師在構建SOA時必須要做的事情。SOA的原則SOA是一種企業(yè)架構，因此，它是從企業(yè)的需求開始的。但是，SOA和其它企業(yè)架構方法的不同之處在于SOA提供的業(yè)務敏捷性。業(yè)務敏捷性是指企業(yè)對變更快速和有效地進行響應、并且利用變更來得到競爭優(yōu)勢的能力。對架構設計師來說，創(chuàng)建一個業(yè)務敏捷的架構

57、意味著創(chuàng)建這樣一個IT架構，它可以滿足當前還未知的業(yè)務需求。要滿足這種業(yè)務敏捷性，SOA的實踐必須遵循以下原則：* 業(yè)務驅動服務，服務驅動技術從本質上說，在抽象層次上，服務位于業(yè)務和技術中間。面向服務的架構設計師一方面必須理解在業(yè)務需求和可以提供的服務之間的動態(tài)關系，另一方面，同樣要理解服務與提供這些服務的底層技術之間的關系。* 業(yè)務敏捷是基本的業(yè)務需求SOA考慮的是下一個抽象層次：提供響應變化需求的能力是新的“元需求”，而不是處理一些業(yè)務上的固定不變的需求。從硬件系統(tǒng)而上的整個架構都必須滿足業(yè)務敏捷的需求，因為，在SOA中任何的瓶頸都會影響到整個IT環(huán)境的靈活性。* 一個成功的SOA總在變化

58、之中SOA工作的場景，更象是一個活的生物體，而不是象傳統(tǒng)所說的“蓋一棟房子”。IT環(huán)境唯一不變的就是變化，因此面向服務架構設計師的工作永遠不會結束。對于習慣于蓋房子的設計師來說，要轉向設計一個活的生物體要求嶄新的思維方式。如下文所寫的，SOA的基礎還是一些類似的架構準則。SOA基礎在IT行業(yè)有兩個越來越普遍的發(fā)展方向，一個是架構方面的，一個是方法學方面的，面向服務的架構設計師可以從中有所收獲。第一個就是MDA（模型驅動架構），由提出CORBA的OMG模型提出。MDA認為架構設計師首先要對待創(chuàng)建的系統(tǒng)有一個形式化的UML（也是由OMG提出）的模型。MDA首先給出一個平臺無關的模型來表示系統(tǒng)的功能

59、需求和use HYPERLINK /corpCenter/249.html cases，根據(jù)系統(tǒng)搭建的平臺，架構設計師可以由這個平臺無關的模型得到平臺相關的模型，這些平臺相關模型足夠詳細，以至于可以用來直接生成需要的代碼。MDA的核心就在于在設計階段系統(tǒng)就已經(jīng)完全描述，這樣，在創(chuàng)建系統(tǒng)的時候，幾乎就沒有錯誤解釋的可能，模型也就可以直接生成代碼。但MDA有一些局限性：首先，MDA假設在創(chuàng)建模型之前，業(yè)務需求已經(jīng)全部描述，而這一點，在當前典型的動態(tài)業(yè)務環(huán)境中幾乎是不可能的。第二，MDA沒有一個反饋機制。如果開發(fā)人員對模型有需要改動的地方，并沒有提供給他們這么一個途徑。SOA的另一個基礎是敏捷方法（AM），其中非常有名的方法是極限編程（ HYPERLINK /Athlon+XP XP）。象XP這樣的AM提供了在需求未知或者多變的環(huán)境中創(chuàng)建軟件系統(tǒng)的過程。XP要求在開發(fā)團隊中要有一個用戶代表，他幫助書寫測試來指導開發(fā)人員的日常工作。開發(fā)團隊中的所有成員都參與到設計之中，并且設計要盡量小并且非形式化。AM的目標是僅僅創(chuàng)建用