面向服務的架構培訓文件

PAGE49/NUMPAGES49(一)基礎：什么是BPM商業(yè)流程治理？CNET中國·PC

類型:轉載

作者:csdn

責編:小蝎

時刻:2006-10-23

BPM是流程自動化的應用，關心企業(yè)進行業(yè)務流程的分析之外，另可利用IT技術，自動化組織內(nèi)各部門的原本以人力及公文傳遞的流程。

依照數(shù)據(jù)整合軟件供貨商Ultimus的定義，BPM要緊精神在于治理企業(yè)的流程。除工作流程自動化系統(tǒng)之外，還必需提供企業(yè)應用軟件整合（EAI）與交換的功能、流程成本效率評量與績效治理，以及流程初始設計的模型最佳化工具，用以涵蓋企業(yè)治理流程中所有的必要環(huán)節(jié)。

分析師建議，決定BPM工具之前，企業(yè)必須用嚴謹?shù)膽B(tài)度檢討目前使用的軟件，決定業(yè)務角色的授權，權衡數(shù)據(jù)模型（datamodel）與分析工具（analyticalapplications），并建立以后采納BPM后的假想情境。

目前包括IBM、微軟、BEA也努力催生商業(yè)模型標準，聯(lián)合起草網(wǎng)絡服務（WebServices）商業(yè)流程執(zhí)行語言（BPEL4WS）。業(yè)界相信，先建立商業(yè)流程模型，再從這些流程模型中建立應用程序進而監(jiān)視這些模型，將有助在企業(yè)內(nèi)部的IT部門與業(yè)務主管之間建立起環(huán)環(huán)相扣的自動化流程（二）體系架構藍圖SOA和BPM的合并CNET中國·PC

類型:投稿

作者:BEA

責編:小蝎

時刻:2006-10-23

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

面向服務的體系架構（Service-orientedarchitecture，SOA）差不多成為軟件工程中一個最重要的主題。無疑，隨著Web服務的推廣和廣泛同意，以及支持基于SOA解決方案開發(fā)的case風格的IDE這一新浪潮的興起，SOA差不多成為構建企業(yè)級分布式應用程序的首選藍圖。與此同時，業(yè)務流程治理（businessprocessmanagement，BPM）作為操作靈活的新企業(yè)并為其建模的要緊支持者，正在強力反彈?；A結構廠商差不多使BPM成為他們出售的系列產(chǎn)品的要緊組件，瞄準機會的廠商使用專用的BPM系統(tǒng)提供垂直的業(yè)務解決方案，純使用BPM的廠商正在得到更加廣泛的同意。

盡管兩種趨勢均顯露出了征兆，它們的趨同現(xiàn)象仍不明顯，而且關于這種現(xiàn)象沒有統(tǒng)一的看法。它們是互補的表示法嗎？它們會重疊嗎？我該如何一起使用它們？如此做有沒有另外的優(yōu)點？此外，什么緣故80年代末期的企業(yè)流程重構（BPreengineering）失敗了，而第三次BPM浪潮卻將要取得成功呢？

在這一系列三篇文章中，我將解決這些問題。首先，我將討論一個體系架構藍圖的最佳實踐如何將面向服務體系架構與BPM框架合并，從而為構建健壯的企業(yè)級集成解決方案并對其建模提供可重復的方案。我描述了什么緣故在當今，任何使用技術支持其任務陳述需要的企業(yè)比以往更能擁有合適的體系架構藍圖。最后，我討論了什么是實時交易的挑戰(zhàn)，以及BPM方法如何能夠實現(xiàn)企業(yè)靈活性、智能企業(yè)建模、系統(tǒng)開發(fā)和以客戶為中心的運作優(yōu)點。

在第二篇文章中，我將應用BPM技術來為一個支持“用于汽車保險”業(yè)務場景的軟件解決方案建模和設計體系架構。我將講述兩種設計：一種純BPM設計和一種混合型設計。我還將講述一些新興的建模工具和標準，并討論一些建模和各種體系架構選擇和策略方面的難題。

在第三篇（也是最后一篇）文章中，我將使用BEA的WebLogicPlatform8.1構建一個POC。我將討論BEA的IDE新引入的可視化編程范型及其優(yōu)缺點，和構建完全分布式的企業(yè)級應用程序所需的一些技術。我還將解釋，什么緣故流行的請求/響應模式的WEB協(xié)議與基于事件的流程建模，以及它在進行架構決策時的意義不一致的緣故。體系架構模式——誰需要它們?

軟件工程是藝術依舊科學？在科學中，我們有明確的定義、定理和證據(jù)。在藝術中，我們有工具和技術、趨勢以及最佳實踐。科學中提出了一些假設，其中一些變成定理，另外一些在通過數(shù)個世紀的研究之后得到驗證，還有一些永久沒有答案。在藝術中，新技術帶來新的趨勢，比如新聞和數(shù)字攝影。假如軟件工程是一門科學，定義我們在日常業(yè)務語言中使用的所有術語不應該是一件困難的情況，像服務、Web服務、面向服務的體系架構、BPM和BPM系統(tǒng)（BPMS）。的確，我能夠利用數(shù)學精度來證明一個數(shù)據(jù)庫查詢算法的正確性。然而，我能夠以一種干脆、簡潔且通常會被同意的方式來回答，J2EE中的B2B集成是與純.NETWeb服務解決方案相對的正確答案嗎？據(jù)我了解，關于我們中間的一些人來講，這不是問題。最后，任一種常見的貿(mào)易出版物的隨機調(diào)查指出，每個人都能夠給出自己的定義，而有些人甚至質(zhì)疑IT存在的本質(zhì)。我不得不得出結論，軟件工程仍然是藝術多于科學。這正好是我們需要合適的最佳實踐、框架和可重復過程的緣故。

模式封裝了最佳實踐，簡練地定義了域問題，描述了使問題值得關注的緣故，并提出了解決方案。模式并沒有解決獨特的問題。專業(yè)人員結合各種模式來解決更為復雜而且有時更為獨特的問題。ChristopherAlexander講：“模式同時也是發(fā)生在世界上的事件和告訴我們?nèi)绾蝿?chuàng)建該事件的規(guī)則，以及我們必須創(chuàng)建它的時刻。它既是過程，也是事件。”我回想起我一直以來最喜愛的定義：對象是帶有狀態(tài)或數(shù)據(jù)及行為的數(shù)據(jù)結構。就目前來講，能夠把Web服務看作帶有一個方法的對象。就像BEAWebLogicPlatform8.1所實現(xiàn)的那樣，會話式Web服務看起來更像是真正的對象：對它進行一次初始化，然后一直執(zhí)行方法。萬一您仍然不能確信Web服務是粗粒度的對象，考慮：(1)IBM、BEA和Microsoft宣布了WS-Eventing規(guī)范。它就像是優(yōu)秀但老式的對象觀看者模式。(2)開放式網(wǎng)格服務體系架構（OpenGridServicesArchitecture）實現(xiàn)了網(wǎng)格服務協(xié)議的Web服務接口繼承。因此，Web服務提供數(shù)據(jù)和行為（Alexander的定義中的事件和規(guī)則），而BPMS實現(xiàn)模式的流程組件。SOA是一個用于解決企業(yè)集成和系統(tǒng)開發(fā)問題的體系架構模式。

我們差不多看到，SOA不是體系架構趨勢的革命，而是它通過一段時刻進展的演變成果。它圍繞為企業(yè)構建分布式系統(tǒng)而進展。誠然，Web服務以一種普遍同意且無二義性的方式提供底層技術，以解決系統(tǒng)連接性問題。也許是頭一次，Web服務成功地解決了互操作性的問題，而這是CORBA、COM、DCOM和RPC做夢也從未想過的情況。我確信，作為中立語言，XML對此也預備一展身手。然而，SOA中包括進來的BPMS框架是一個新的、革命性的元素。HowardSmith和PeterFingar描述的第三次浪潮是指一組全新的概念、框架和主流產(chǎn)品。它正在顯著改變企業(yè)轉化的方式，從而靈活地治理和運行全局的和協(xié)作的電子商務實體。

業(yè)務流程治理的出現(xiàn)差不多有一段時刻，它更多地用于工業(yè)中，而與IT無關。并發(fā)工程和六西格瑪被開發(fā)用來解決生產(chǎn)和流程改進中的及時協(xié)作問題，同時確實取得了相當?shù)某晒?。然而，?0年代晚期，出于多方面的緣故，業(yè)務流程重構治理獲得的成功特不有限。然而最全然的緣故是，重構是紙上談兵。沒有軟件來支持如此一個復雜的任務。BPM在沒有考慮IT系統(tǒng)的情況下設計了自適應的企業(yè)。正如DavidTaylor所寫：

“對連續(xù)性流程優(yōu)化的需要要求從全然上重新考慮如何設計和構建信息系統(tǒng)。提出解決固定問題的固定解決方案差不多不再夠用。”

信息系統(tǒng)，像它們支持的業(yè)務模型一樣，必須在本質(zhì)上確實是自適應的。

Taylor提出一種基于OO的開發(fā)技術，作為開發(fā)自適應IT的一種方法，這種技術稱為聚合工程（convergentengineering）。然而，OOP無法成功解決分布式計算和企業(yè)集成的問題。另外，負責對企業(yè)建模的業(yè)務分析人員也沒有采納OO。

BPMS將流程建立為用于建模、軟件設計和運行時執(zhí)行的統(tǒng)一結構。過去，開發(fā)趨勢一直在阻礙我們對企業(yè)建模的方式。功能式編程使功能需求技術流行起來。關系數(shù)據(jù)庫帶來了RDBS分析和設計的流行。面向對象的編程則為OO分析和用例開發(fā)鋪平了道路。然而在大多數(shù)情況下，業(yè)務分析人員可不能使用開發(fā)專門術語，因此產(chǎn)生了對需求可跟蹤性中通常阻礙的另一種翻譯的需要。

BPM規(guī)范正在快速演變?yōu)闃藴?。市場中差不多出現(xiàn)了支持業(yè)務建模、優(yōu)化和運行時執(zhí)行的產(chǎn)品。正如BEA的WebLogicPlatform8.1和其他BPMS產(chǎn)品所實現(xiàn)的那樣，以流程為中心的BPMS方法用于系統(tǒng)開發(fā)生命周期，它消除了對運行時阻抗不匹配的業(yè)務需求。

靈活的企業(yè)擁有自適應的業(yè)務和自適應的IT系統(tǒng)。假如構建企業(yè)解決方案的過程中出現(xiàn)一個新的問題，那么它一定是需求變化的速度。它的速度之快是前所未有的。BPMS引擎添加了一個新的層到傳統(tǒng)的開發(fā)堆棧（參見圖1）中，并引入服務質(zhì)量來解決企業(yè)集成中的全然問題。BPMS引擎使編程最易變的部分——集成點——的軟布線變得容易。軟布線是以正式語言顯式描述的，并由BPMS引擎（又名有限狀態(tài)機引擎）執(zhí)行。正如BEAWebLogicIntegrator和其他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è)轉化為完全自適應的靈活企業(yè)。

從企業(yè)遠景到組織筒倉（Silo）

企業(yè)從遠景開始。CEO和董事會采納遠景和行業(yè)使命陳述。C級治理人員定義策略，并適當?shù)匕才帕鞒虂碇卫韴?zhí)行（參見圖1）。定義功能角色和責任，然后創(chuàng)建企業(yè)界線。業(yè)務分類（Lineofbusiness，LOB）在本質(zhì)上能夠是水平或垂直的（參見圖2）。垂直LOB具有以下特征：

獨立的操作域。

特有的治理和策略。

開發(fā)和維護自己的IT—自動化孤島。

足夠大以至于能夠創(chuàng)建多種業(yè)務分類；例如，抵押貸款證券、市政公債、貨幣市場，等等。（圖02）水平LOB具有不同的特征集合：

提供業(yè)務操縱。

治理的支配和一致。

需要訪問由垂直LOB治理的數(shù)據(jù)。

合適的手動流程和書面報告。

在第二個信息紀元（不要與第二次浪潮混淆）中，我們使用了各種編程技術來鏈接自動化孤島，從FTP、數(shù)據(jù)庫復制、EAI和消息收發(fā)開始。此方法產(chǎn)生了一整套新問題：·

接口的多重性:一份MorganStanleyDeanWitter報告表明，通常的金融服務客戶需要維護6000個接口，為此每年花費2500萬美元，而且每年還需構建900個新的點到點接口，為此需另外花費2500萬美元進行構建，同時還要花費400萬美元進行維護?！ふ{(diào)停流程:必須在每一個倉庫上實現(xiàn)，需要消耗有價值的時刻和昂貴的資源。這是一項常用技術，用于檢驗由多個實體修改的引用數(shù)據(jù)?！?/p>

流程:在中間件中進行硬布線。在分析過程中捕捉流程所花費的時刻和金鈔票屬于白費。企業(yè)最重要的資產(chǎn)——流程——隱藏在n(n-1)個意大利面式接口的迷宮中?！?/p>

開發(fā)新的水平流程：需要多個LOB的協(xié)調(diào)。·

實現(xiàn)特定和專用的接口：需要專門化和一次性編程。重用消逝，維護方面的投入顯著增加?！?/p>

異常難于跟蹤：錯誤解析通常需要訪問多個系統(tǒng)。人工干預和解釋是不可幸免的。找尋答案需要花費大量寶貴時刻，并對客戶中意程度和收益性方面的大致情況有著直接阻礙。流程無處不在。您能發(fā)覺它們嗎？

關于企業(yè)來講，流程能夠是客戶層面上的，也能夠是內(nèi)部的，或者能夠是更大流程的組成部分。我們在同樣的企業(yè)中能夠找到內(nèi)部流程。流程通常涉及到人與系統(tǒng)的交互，或者只是系統(tǒng)之間的交互（參見圖3）。交易流程是大規(guī)模流程的一個專門好的例子。行政治理部門的交易人員在他的銷售訂單系統(tǒng)中接收一個來自對沖基金治理人員的交易執(zhí)行命令，或者他接到一份傳真或一個電話。交易人員檢查庫存系統(tǒng)的安全性或資金，并借助他的交易對手執(zhí)行交易。能夠制造紙質(zhì)入場券，而交易助手可能必須在下行系統(tǒng)中進入它。（圖03）

當因為下行系統(tǒng)之一錯誤地再進入，而關心臺分析人員收到一份異常報告時，另一個內(nèi)部流程啟動了。然后，他在內(nèi)部記事薄之一中查找數(shù)據(jù)（原始進入記錄），請求來自事務部門的傳真（我們假定討論的交易超過了結算日期），而且因為他在兩天內(nèi)沒有收到回復，也許他會再次重復同樣的行為。那個流程最終當分析人員解決了問題時終止，因此，除非他調(diào)到另一個部門或者調(diào)出公司。然后，顧問們必須參與進來，跟蹤問題和流程，這通常需要一大筆鈔票。

每月的客戶聲明是定期性企業(yè)范圍內(nèi)流程的一個傳統(tǒng)例子，通常為水平LOB所特有。在大多數(shù)情況下，客戶在被不同LOB支持的產(chǎn)品中擁有帳號，例如，股票、U.S.證券和外匯。在月末發(fā)送多個聲明將會十分混亂。法律和一致性問題還需要交叉引用多個倉庫的數(shù)據(jù)。Patriot和Sarbanes-OxleyActs(一個新的業(yè)務流程，然而不賺鈔票)的一個要緊問題是要訪問由大量LOB所擁有的數(shù)據(jù)，有時還要圍繞半個世界。EAI技術和消息收發(fā)試圖借助早先闡明的限制解決這些問題。通向靈活性的道路：以BPM為中心的SOA

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

考慮流程而不是功能:流程告訴您完成什么工作以及如何完成。功能描述誰在哪里來完成它?！?/p>

從客戶的觀點動身：考慮從外部業(yè)務事件開始的流程，例如，一次交易、一份訂單、一個主張、一個報價請求?！?/p>

在更寬泛的意義上并基于不同的服務質(zhì)量來劃分客戶類不：您生態(tài)系統(tǒng)中的性能、供應商、業(yè)務伙伴?！?/p>

流程反映狀態(tài)變化：交易訂單、現(xiàn)金支付。從可治理的流程數(shù)量6－10開始。記住，大多數(shù)人最多只能保留一個頁面上的七樣東西?！?/p>

定義核心流程和子流程：那個地點沒有科學理論，只有最佳實踐。然而，要當心P-calculus2和Petri-nets；它們將在接下來的10年內(nèi)帶給BPM科學的嚴密性。·

將流程分解為行為

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

它是要重用的最終指南。能夠通過任何想像得到的方式編排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在BEAWebLogicPlatform8.1（集成組件）的一個實例中可用。從技術上講，在BEAWebLogicIntegration中，Web服務被稱為業(yè)務流程資源。我們使用IDE編排新流程，使用門戶添加UI，然后將它部署為一組EJB來執(zhí)行。確實是這么簡單！現(xiàn)在流程是一項IT資產(chǎn)了，就像數(shù)據(jù)庫表、存儲過程、遺留COBOL書籍和專用的計算c庫。（圖04）

許多金融服務機構的業(yè)務分類是水平的，治理高凈值的私有客戶。在啟用了BPMSSOA的企業(yè)中，開發(fā)IT基礎結構來支持如此的新LOB完全能夠與正確放置業(yè)務模型并行完成（參見圖5）（圖05）

考慮A現(xiàn)象，它們并沒有制造任何新的EBS。所有EBS位于任何其他郵件訂單一覽表書店中的恰當位置：定購書籍，檢查庫存，信用卡付帳，打印聲明，預備裝運，給客戶發(fā)送電子郵件。然而它沒有創(chuàng)建新流程，沒有質(zhì)疑差不多建立好的流程，甚至不用花費什么力氣。

正如HowardSmith和PeterFingar所講的那樣：“在BPM的第三次浪潮中，筒倉式考慮和點到點的技術集成被靈活的、基于業(yè)務流程的體系架構所代替?！贝送猓珿artnerGroup現(xiàn)在聲明，接著將業(yè)務邏輯硬布線到軟件或中間件中或者堅持人工步驟的公司將輸給部署流程治理體系架構的競爭對手。實時處理業(yè)務

退一步講，預測今后是專門困難的情況，然而我們用特不科學的態(tài)度對待它，而且始終試著這么做，不管對依舊錯。統(tǒng)計和預測是關于預測今后的兩門科學。投資組合評估和保險統(tǒng)計研究是有關預測的科學。實際上，我們的預測僅僅基于我們差不多經(jīng)歷過的、過去的性能和趨勢。實時處理業(yè)務需要預測以后的業(yè)務情況。然而，差不多的業(yè)務協(xié)議和框架必須合適。今天，技術革新、BPMS和SOA是將業(yè)務目標與IT相結合的基礎。流程提供一個封裝了變化的新層。90年代早期，PowerBuilder和VB風格的工具使客戶端/服務器和關系數(shù)據(jù)庫系統(tǒng)的開發(fā)流行開來，通過與此相同的方式，BPMS引擎將在以后建立流程驅動的企業(yè)。事實上我預測，在我們的一生中，我們將看到對運行時流程的需求，該類流程用于實時變化或對自修改流程的需要。無疑，人類希望能夠掌管該類變化，然而通過使用UDDI-?(?代表流程)找出最可能的服務契約和使用描述域專業(yè)知識和市場情況的規(guī)則進行決策，BMPS能夠使這項工作更加容易。隨著BPMS的普及，靈活性將被極端自適應所代替。結束語

在本文中，我描繪了合并SOA和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)提出一個使用WebLogicPlatform8.1的物理基礎結構；并(4)討論面向服務體系架構中的BPMS難題和新出現(xiàn)的模式。

直到：流程無處不在。您能發(fā)覺它們嗎？(三)簡單到復雜，BPM技術促進SOA進展CNET中國·PC

類型:轉載

作者:csdn

責編:小蝎

時刻:2006-10-23

BPM(企業(yè)流程治理，BusinessProcessManagement)與SOA(服務導向架構，ServiceOrientedArchitecture)各自歷經(jīng)多年的進展，越來越成為人們的焦點。眾多廠商成為了SOA技術架構的推動者，其中包括IBM、BEA、HP、Oracle和SAP。

SOA能夠看作是B/S模式、XML/WebService技術與治理軟件的結合。它通過組合單獨業(yè)務和流程實現(xiàn)復雜的業(yè)務應用，而這些業(yè)務功能和流程稱為服務，SOA把業(yè)務流程視為獨立于應用程序及其運行的平臺的可復用組件。從SOA概念提出以來，越來越多的主流廠商開始了BPM與SOA的應用。今年3月，BEA收購Fuego擴展SOA到BPM軟件，以此使用新的BPM升級SOA平臺。2月，HP和Oracle集團宣布，HP的服務咨詢和集成（ServicesConsulting&Integration）將會同Oracle的Fusion中間件，加入到它的SOA的投資組合以及HPOpenView治理軟件套件，以Fusion融合SOA。去年，Oracle收購了BPM專業(yè)公司Collaxa；SAP重新設計軟件，以便集成自由版本的面向BPM的中間件NetWeaver。

除平臺提供商以外，開源廠商也試圖占據(jù)擁有自己的SOA卻缺乏服務的市場。JBoss公司在2005年10月公布的企業(yè)過程治理引擎，圍繞業(yè)務過程執(zhí)行語言（BusinessProcessExecutionLanguageBPEL）提供了一種可插拔的體系結構、擴展的任務治理以及新的可擴展性。BPEL盡管是用來編排Web服務的，但依舊適合用來集成，而不是深入的業(yè)務邏輯。BPM不管從技術依舊方法上都將促進SOA的進展。在此過程中，大型平臺廠商IBM、BEA、SAP、Oracle等將會嘗試建立一種新SOA標準；而開源廠商努力構建一套工具，不把自己禁錮于用一種方法構建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技術具有以下相似點：1．BPM涵蓋范圍廣泛，需要完成因事件觸發(fā)的完全不相干的事件，此特點正與SOA的松散耦合特點相吻合。2．BPM需要多部門、區(qū)域的協(xié)同。在此中環(huán)境中網(wǎng)絡環(huán)境的安全性可由SOA技術構架中的WS-Security、LDAP(LightweightDirectoryAccessProtocol-輕量級目錄訪問協(xié)議)、PKI(PublicKeyInfrastructure-公鑰基礎設施)架構和數(shù)位簽章等機制來完成。3．BPM系統(tǒng)構成元素種類繁多而復雜，包含分布于各模塊的企業(yè)邏輯和規(guī)則。而SOA能夠看作是B/S模式、XML/WebService技術與治理軟件的連續(xù)。

當前多數(shù)SOA環(huán)境能提供系統(tǒng)治理工具給系統(tǒng)治理員使用，協(xié)助治理SOA架構下模塊的安裝、移除、啟動等。目前能夠實現(xiàn)SOA的產(chǎn)品包括：MicrosoftBiztalkServer,webMethodsBusinessIntegrator,IBMSeeBeyond,TIBCO和Vignette。在SOA提出往常，大部分BPM產(chǎn)品在流程圖中采納自有定義流程邏輯。4．企業(yè)BPM系統(tǒng)的實施往往從最簡單的開始，逐漸提升為復雜的BPM系統(tǒng)。而SOA模塊化的特性正好吻合了此特性。(四)分析:BPM與SOA之間的區(qū)不及聯(lián)系CNET中國·PC

類型:轉載

作者:newhappy2008

責編:小蝎

時刻:2006-10-23

關于業(yè)務流程治理(BPM)和面向服務架構(SOA)之間關系的討論喧鬧非凡。二者也是多年來的熱門話題，然而關于它們的討論通常都出現(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陣營來講特不重要。

為了澄清這些誤解，我認為有必要闡明BPM與SOA的不同本質(zhì):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的AquaLogicBPMSuite)支持使用各種不同的技術(面向服務的或不是面向服務的)對應用程序和數(shù)據(jù)庫進行輕松訪問。實現(xiàn)由代碼和來自于并依靠于底層系統(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è)服務總線所提供的代理服務，如此就隱藏了底層應用程序和數(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è)務分析師)能夠在構建流程時掃瞄如此的注冊庫。這確保了服務能夠被正確地使用和重用，而且通常簡化了業(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才不至于存在于獨立的豎井中，這也專門重要。(五)OASIS總裁PatrickGannon談SOA與開放標準CNET中國·PC

類型:轉載

作者:Cnet

責編:小蝎

時刻:2006-10-23

PatrickGannon：今天來給大伙兒介紹一下SOA對產(chǎn)業(yè)的一些好處和標準對產(chǎn)業(yè)的一些阻礙。這一頁是我的簡單介紹。要緊介紹一下開放標準和SOA對公司的進展有哪些阻礙。今后的電子商務將會搭建在SOA的平臺上，現(xiàn)在SOA和開放標準還處于初期時期。這一頁幻燈片是介紹了一下SOA的差不多情況。為了達到SOA所承諾的前景，需要建立一個共同的框架體系和標準體系。公司要在SOA投資，必須要獲得一些收益，如此保證他們的資產(chǎn)有更好的流淌性，也保證他們的資產(chǎn)有長期保值的能力。所謂流淌性確實是靈活多樣的意思，也確實是講SOA的標準體系和核心技術要能夠滿足各式各樣應用的需求。SOA專門重要的特性是能夠讓你對軟件的投資有長期的保值性，能夠幸免重復投資，能夠讓你的軟件模塊能夠重復地使用。

為了達到這些目標，有一些專門差不多的工作需要做。我們必須要有一個共同的體系結構和一套共同的詞匯表，大伙兒都明白每一個軟件的變量代表了什么意思?，F(xiàn)在的問題是各個行業(yè)一些要緊的技術廠商，他們看的都局限于他們那個行業(yè)或者是自己的技術體系來考慮整個軟件應用的問題。那個問題是不同的詞匯表，不同詞匯的意義和不同的表示方法都對使用軟件技術的進展帶來了障礙。我們的解決方法是什么？在商業(yè)業(yè)務層面制造互操作性。

其中一個方法是實現(xiàn)跨部門的應用互動和應用的集成。為了達到那個目標，開放標準是其中一個專門重要的措施。專門多公司問什么緣故我們需要標準？我們看到為了建立標準體系需要專門多的投入，一個標準組織確實是為了讓業(yè)界的企業(yè)一起共同做標準的工作，降低大伙兒分頭做標準的成本。軟件公司需要明白他們做什么標準、同時應該了解標準是如何產(chǎn)生的，通過什么樣的方式使標準有一個差不多的同意情況。我們請了DelphiGroupResearch做一個標準的調(diào)研，看整個企業(yè)對標準的認識，和目前對標準研究的看法。有三個重要的調(diào)研結果。采納開放標準使得企業(yè)的軟件能夠重復使用，數(shù)據(jù)也能夠在不同的平臺上進行共享。第二個結論是采納了開放標準，企業(yè)的研發(fā)工作能夠在更大的協(xié)同范圍，甚至是攝入最終用戶來進行共同的開發(fā)。我們看到開放標準關于WebService的使用是特不重要的。

OASIS是一個國際標準組織，要緊是針對先進的結構化數(shù)據(jù)的信息標準。OASIS不光只是研究和產(chǎn)生標準，同時也跟其他國際組織一起合作來推動標準的采納和技術的進展。OASIS有一個特不開放的組織結構，能夠讓會員專門容易在組織里面表達自己，目前有650個不同的企業(yè)會員，來自80個國家。OASIS在WebService、電子商務、eBusiness和文檔治理方面是目前世界上權威的標準組織。通過13年的努力，OASIS差不多得到廣泛的承認，OASIS不僅能夠直接向國際標準組織、國際電聯(lián)和聯(lián)合國相關標準組織直接提交標準提案。

OASIS不光只是由技術廠商參加的標準技術組織，實際上有35％的成員來自于客戶，也確實是講能夠對甲方有阻礙力的部門，還有大概15％的研究單位。OASIS也是一個進展專門快的組織，我來中國專門重要的目的是希望能夠參與快速進展的亞太地區(qū)的經(jīng)濟活動。

這是OASIS在亞太地區(qū)目前的成員，這是在大陸地區(qū)的會員成員，我差不多參觀過了書生、長風聯(lián)盟和神州數(shù)碼，以及互聯(lián)網(wǎng)中心。依照我那個星期在這邊的感受，我認為專門快會有更多的公司參加OASIS那個組織。我邀請大伙兒能夠參與OASIS那個組織。

OASIS是為SOA和Web服務的進展提供重要的指導作用。OASIS的工作覆蓋了SOA和Web服務一些特不重要的領域。這是OASIS在SOA和Web服務里重要的領域和技術工作組所覆蓋的一些SOA和Web服務的重要領域。OASIS不然而推動標準的研發(fā)和公布，也推動標準的全面采納。OASIS是有25個技術委員會在SOA領域里展開技術的研究工作。關于公司對eBusiness有興趣的公司，有一個商業(yè)編排工作組。標準、訪問權限操縱也是OASIS在SOA和Web服務領域里的重要工作。

Web服務的治理也是我們一個專門重要的技術研究工作。可靠的消息傳輸也是我們的工作之一。這是UDDI部分的工作。你們看到在OASIS里對SOA和Web服務做了大量的研究和標準建設工作，這也是專門多公司參加OASIS的直接目的。大伙兒都明白當一個公司在新技術方面做投入時都會涉及到一個潛在的風險。SOA能夠關心公司降低采納新技術的風險。企業(yè)今天能夠做什么呢？一個是能夠參加OASIS組織，或者是能夠觀看、了解一下OASIS組織能做什么。因為這些標準差不多上在全世界推廣和采納的，因此特不重要的是要讓在中國的軟件企業(yè)或者是中國的最終用戶能夠對他們的技術需求和他們的一些要求專門明確地表示出來。表示出來以后，能夠阻礙標準的產(chǎn)生，而且標準是在全球范圍內(nèi)推動的。其中軟件公司在OASIS的工作是提出新的研究方向。其中一個例子確實是書生公司差不多在上個星期提出了UOML在OASIS里立項。我相信確信有專門多其他的公司能夠把他們創(chuàng)新性的技術提案通過OASIS那個平臺建立起來。關于小的公司，沒有專門多鈔票來參加像這種標準組織的話，也能夠多看一看標準組織能不能對你們的市場活動帶來好處。

除了標準的研究工作以外也跟專門多組織合辦活動，把會員的一些技術在更大的范圍里展示。關于最終客戶來講，OASIS對他們也有專門多好處。關于最終用戶假如能夠把他們對技術的需求明確提出來之后，能夠在明確的過程中考慮到里面去。OASIS有專門多會員是政府部門，這些政府部門參加的緣故是他們希望觀看標準的研究情況，對標準提出一些建議。這些政府部門也利用OASIS平臺來了解哪些技術方向值得政府的資助，對參加這些研究方向的企業(yè)優(yōu)先考慮進行資助。關于開放標準和SOA的研究，希望能夠邀請和OASIS一起共同討論SOA和開放標準的工作(六)業(yè)界觀看：什么緣故SOA如此得勢？【正文】

作為以后的技術趨勢之一，SOA正無可爭議地引領著軟件業(yè)的新一輪浪潮，并在以后給軟件和網(wǎng)絡帶來革命性的變化。什么緣故SOA如此得勢?這是因為SOA改變了過去開發(fā)應用的模式，將軟件按照業(yè)務需求定義成“組件”，作為共享資源，提供以服務為中心的應用軟件設計方法。這種方法，能夠提高IT對業(yè)務的響應能力，使企業(yè)得以實時支持業(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的概念，但當時的軟件技術進展和信息化水平還不足以使它走入有用時期。進入21世紀，隨著Web服務等相關標準的出現(xiàn)和成熟，SOA開始從概念走向有用。

SOA不是某個產(chǎn)品，也不是某個技術，而是一種軟件設計架構和方法。SOA要求開發(fā)者從服務集成的角度來設計應用軟件，它將應用程序的不同功能組件定義為“服務”，通過“服務”之間的良好接口聯(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)的架構將變得更加清晰。

現(xiàn)在隨著網(wǎng)絡技術的進展，企業(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)下運行。在這種模式下，一個應用或應用的一部分事實上是一種服務，其他的應用和客戶都能夠在無需編寫大量代碼的情況下使用這些服務，這一切都使一些大企業(yè)或在地理上分布范圍比較廣的開發(fā)隊伍能夠更好地合作，因為這些SOA架構下的中間件業(yè)務模塊都能夠被重新配置或以新方式優(yōu)化來滿足新的需求。正是SOA的重用性和互操作性所帶來的靈活性實現(xiàn)了企業(yè)IT資源整合，使企業(yè)IT資源真正面向于服務。

SOA作為一種概念盡管差不多成熟，并得到了國內(nèi)外主流軟件開發(fā)商和企業(yè)客戶的認可，目前主流軟件廠商均差不多完成了基于SOA的改造，但在客戶端大規(guī)模的應用還有許多情況要做。首先，它包括一系列技術和規(guī)范，面臨諸多挑戰(zhàn)，尤其在項目開發(fā)初始，付出的代價要比傳統(tǒng)軟件項目大得多。其次，實現(xiàn)SOA的Web服務技術尚不成熟，標準還處在進展之中。目前，專門多企業(yè)關于SOA的認識還僅限于一種“整合”IT技術的概念，人們關于SOA認識的誤區(qū)還有專門多。面向服務架構（SOA）的原則Webservice差不多不再是新婚的娘子。眾多企業(yè)都差不多創(chuàng)建各種實驗性WebServices項目，事實證明，這項新興的分布式計算技術確實能夠降低集成和開發(fā)的成本。另外，一些關鍵的WebSer

vices標準紛紛制定，強安全（robustsecurity）和治理方面的產(chǎn)品也陸續(xù)問世。關于志向遠大的企業(yè)來講，他們差不多在考慮下一步了。對大多數(shù)公司來講，下一步要考慮的不再是點對點的應用，而是Webservices在企業(yè)間以及業(yè)務伙伴間更為寬廣的應用。這種技術的變遷需要更松散耦合、面向基于標準的服務的架構。如此一個架構要求對IT在組織中的角色有新的觀點和認識，而不僅僅是一種實現(xiàn)方法。通過對業(yè)務的敏捷反應，企業(yè)能夠得到實實在在的回報，而要達到這一點，面向服務架構設計師的角色特不關鍵。除此之外，潛在的回報更是不可勝數(shù)－分布計算技術能夠保證對業(yè)務需求足夠靈活的反應，而這種業(yè)務上的敏捷正是各公司夢寐以求而目前還遙不可及的。分布式計算將網(wǎng)絡上分布的軟件資源看作是各種服務。面向服務架構是一種不錯的解決方案。但這種架構不是什么新思想；CORBA和DCOM就專門類似，然而，這些過去的面向服務架構都受到一些難題的困擾：首先，它們是緊密耦合的，這就意味著如分布計算連接的兩端都必須遵循同樣API的約束。打比方講，假如一個COM對象的代碼有了更改，那么訪問該對象的代碼也必須作出相應更改。其二，這些面向服務架構受到廠商的約束。Microsoft操縱DCOM自不必講，CORBA也只是一個偽裝的標準化努力，事實上，實現(xiàn)一個CORBA架構，經(jīng)常差不多上在某個廠商對規(guī)范的實現(xiàn)上進行工作。Webservices是在改進DCOM和CORBA缺點上的努力。今天應用Webservices的面向服務架構與過去不同的特點就在于它們是基于標準以及松散耦合的。廣泛同意的標準（如XML和SOAP）提供了在各不同廠商解決方案之間的交互性。而松散耦合將分布計算中的參與者隔離開來，交互兩邊某一方的改動并可不能阻礙到另一方。這兩者的結合意味著公司能夠實現(xiàn)某些Webservices而不用對使用這些Webservices的客戶端的知識有任何了解。我們將這種基于標準的、松散耦合的面向服務的架構簡稱為SOA。SOA的強大和靈活性將給企業(yè)帶來巨大的好處。假如某組織將其IT架構抽象出來，將其功能以粗粒度的服務形式表示出來，每種服務都清晰地表示其業(yè)務價值，那么，這些服務的顧客（可能在公司內(nèi)部，也可能是公司的某個業(yè)務伙伴）就能夠得到這些服務，而不必考慮其后臺實現(xiàn)的具體技術。更進一步，假如顧客能夠發(fā)覺并綁定可用的服務，那么在這些服務背后的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è)務敏捷的架構意味著創(chuàng)建如此一個IT架構，它能夠滿足當前還未知的業(yè)務需求。要滿足這種業(yè)務敏捷性，SOA的實踐必須遵循以下原則：*業(yè)務驅動服務，服務驅動技術從本質(zhì)上講，在抽象層次上，服務位于業(yè)務和技術中間。面向服務的架構設計師一方面必須理解在業(yè)務需求和能夠提供的服務之間的動態(tài)關系，另一方面，同樣要理解服務與提供這些服務的底層技術之間的關系。*業(yè)務敏捷是差不多的業(yè)務需求SOA考慮的是下一個抽象層次：提供響應變化需求的能力是新的“元需求”，而不是處理一些業(yè)務上的固定不變的需求。從硬件系統(tǒng)而上的整個架構都必須滿足業(yè)務敏捷的需求，因為，在SOA中任何的瓶頸都會阻礙到整個IT環(huán)境的靈活性。*一個成功的SOA總在變化之中SOA工作的場景，更象是一個活的生物體，而不是象傳統(tǒng)所講的“蓋一棟房子”。IT環(huán)境唯一不變的確實是變化，因此面向服務架構設計師的工作永久可不能結束。關于適應于蓋房子的設計師來講，要轉向設計一個活的生物體要求嶄新的思維方式。如下文所寫的，SOA的基礎依舊一些類似的架構準則。SOA基礎在IT行業(yè)有兩個越來越普遍的進展方向，一個是架構方面的，一個是方法學方面的，面向服務的架構設計師能夠從中有所收獲。第一個確實是MDA（模型驅動架構），由提出CORBA的OMG模型提出。MDA認為架構設計師首先要對待創(chuàng)建的系統(tǒng)有一個形式化的UML（也是由OMG提出）的模型。MDA首先給出一個平臺無關的模型來表示系統(tǒng)的功能需求和usecases，依照系統(tǒng)搭建的平臺，架構設計師能夠由那個平臺無關的模型得到平臺相關的模型，這些平臺相關模型足夠詳細，以至于能夠用來直接生成需要的代碼。MDA的核心就在于在設計時期系統(tǒng)就差不多完全描述，如此，在創(chuàng)建系統(tǒng)的時候，幾乎就沒有錯誤解釋的可能，模型也就能夠直接生成代碼。但MDA有一些局限性：首先，MDA假設在創(chuàng)建模型之前，業(yè)務需求差不多全部描述，而這一點，在當前典型的動態(tài)業(yè)務環(huán)境中幾乎是不可能的。第二，MDA沒有一個反饋機制。假如開發(fā)人員對模型有需要改動的地點，并沒有提供給他們這么一個途徑。