• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆 - 181, 文章 - 2, 評論 - 85, 引用 - 0
            數(shù)據(jù)加載中……

            4月17日-----初期的團隊分工

            由April進行SOA技術(shù)文章的篩選和轉(zhuǎn)載。
            篩選了50篇關(guān)于SOA技術(shù)方面的文章,有助于加強團隊初期對SOA技術(shù)的熟悉。以最快的速度了解SOA,在此基礎(chǔ)上發(fā)揮想象力,創(chuàng)造出一個合理可行的解決方案。

            團隊的初期分工:
            ????? 組長:Merlin.
            ??????組員:April,Tory
            ??????
            Merlin和Tory大量閱讀技術(shù)文檔,研究提出解決方案。April負責blog的建設(shè)。

            posted @ 2006-04-17 16:10 wsdfsdf 閱讀(200) | 評論 (0)編輯 收藏

            觀點與展望,第 1 部分: 選擇 SOA 的原因和時機-----IBM 技術(shù)帶頭人回答有關(guān) IT 體系結(jié)構(gòu)的各種亟待處理的問題

            了解 IBM 有洞察力的專家和領(lǐng)先技術(shù)開拓者對 IT 架構(gòu)師在目前及將來面臨的問題的評述,了解他們的觀點與展望。本月,他們將對以下問題進行討論:為什么應(yīng)該考慮 SOA?何時應(yīng)當選擇 SOA,何時又不應(yīng)該選擇 SOA?

            歡迎閱讀觀點與展望專欄

            歡迎閱讀第一期觀點與展望,IBM 技術(shù)專家將在此 developerWorks 專欄中就 IT 架構(gòu)師需要及時解決以完成其工作的問題提供指導(dǎo)。每個月,我們都將拜訪 IBM 內(nèi)部架構(gòu)師社區(qū)(包括最知名的有洞察力的人、標準組織的投稿人、我們產(chǎn)品團隊的架構(gòu)師和每天與客戶接觸的顧問),邀請他們與大家分享他們對目前 IT 和軟件架構(gòu)師面臨的最重要問題的看法。

            無論您是跨越全球的大型團隊的架構(gòu)師,還是剛剛開始學(xué)習 IT 體系結(jié)構(gòu)技術(shù)與實踐的新手,他們的回答都將給您提供幫助,為您帶來靈感并促進您的積極參與。這些觀點和看法并不一定十分全面。有關(guān)此處涉及的主題的更多指導(dǎo)信息,可以參考 developerWorks Architecture area 的另一部分:IT Architecture resource round-up。另外,如果您有具體問題需要詢問專家,或希望發(fā)表討論,則請訪問 developerWorks IT 體系結(jié)構(gòu)討論論壇







            引言

            面向服務(wù)的體系結(jié)構(gòu) (SOA) 已成為了一項事實標準,用于開發(fā)基于組件的應(yīng)用程序,可使用標準接口通過網(wǎng)絡(luò)(Internet 或其他網(wǎng)絡(luò))訪問這些應(yīng)用程序。至少 IBM 高級管理人員和很多其他供應(yīng)商、分析師、顧問和軟件開發(fā)人員都這么說。他們還將告訴您,整個行業(yè)都在逐步采用 SOA,如果您尚未開始 SOA 開發(fā),將很快跟不上時代的步伐了。

            贊譽之詞。但這些看法是否真的很有吸引力,能讓您開始著手您自己的 SOA 嗎?讓我們來看看一位參加 Open Group 主辦的 SOA 大會的架構(gòu)師的問題。在 IBM Global Services 副總裁 Michael Liebow 的主題發(fā)言后的提問期間,這位架構(gòu)師問道:“SOA 是不是我們需要知道的唯一體系結(jié)構(gòu)?(順便提一下,Liebow 先生的回答是“是的”)在稍后,另一位架構(gòu)師大聲問道:“SOA 和我們多年前就知道的組件體系結(jié)構(gòu)很相似。如果我們采用了它,是否意味著我們又多添了一個技術(shù)豎井(另一個開發(fā)死胡同),從而需要進行更多的集成?”(而這次,會議參加者——包括平臺供應(yīng)商、企業(yè) IT 架構(gòu)師、顧問、系統(tǒng)集成商和其他人員——回答的是“不是。”)

            這就提出了我們本月要向我們的專家詢問的問題。如果您和 IBM 最近接觸的很多架構(gòu)師一樣,那么您可能正在評估甚至采用 SOA 的過程中。但您可能仍在懷疑這是否是體系結(jié)構(gòu)樣式的必由之路,新東西很快由更為流行的東西取代,或者,這個體系結(jié)構(gòu)是否真的適用。

            我們的專家對此問題的回答包含了很多您之前聽到的說法:SOA 促進了可重用性,提供了接口和實現(xiàn)之間的抽象級別以最小化依賴關(guān)系,將業(yè)務(wù)需求與 IT 功能結(jié)合,從而可以為您提供用于將業(yè)務(wù)需求轉(zhuǎn)換為編程服務(wù)來實現(xiàn)流程自動化的機制,以及當前競爭激烈且快速變化的業(yè)務(wù)環(huán)境中所必需的靈活性,等等。另外,這些專家還根據(jù)他們與 IBM 內(nèi)外開發(fā)先驅(qū)合作的實踐經(jīng)驗提供了一些新穎的看法,將幫助您了解 SOA 在何時如何(甚至為什么)適合在您的 IT 體系結(jié)構(gòu)和開發(fā)計劃中使用。

            在此對本月的專欄供稿編輯 Holt Adams 表示感謝。Holt 是 IBM Software Group 團隊一位經(jīng)驗豐富的 IT 架構(gòu)師,就您將要讀到的內(nèi)容為內(nèi)部 IBM 社區(qū)提供了指導(dǎo)。他還提供了他自己對這個問題的回答“何時采用 SOA,何時不采用 SOA。”

            好了,不再多說,下面就請了解一下我們的專家的觀點吧。(有關(guān)回答問題的專家的更多信息,請參閱本專欄最后的關(guān)于專家。)我們邀請您就 SOA 提出您的看法。您可以訪問我們的 IT 體系結(jié)構(gòu)討論論壇,或通過以下地址給我發(fā)電子郵件:pdreyfus@us.ibm.com

            Paul Dreyfus,編輯
            developerWorks SOA and Web services







            何時采用 SOA,何時不采用 SOA

            Holt Adams IBM 的目標之一是在其產(chǎn)品內(nèi)開發(fā)和采用開放標準。通過這樣做,就能在您公司的 IT 基礎(chǔ)結(jié)構(gòu)中實現(xiàn) SOA 的價值主張。SOA 能夠優(yōu)化業(yè)務(wù)需求與 IT 的一致性,能夠?qū)I(yè)務(wù)流程活動從服務(wù)實現(xiàn)中分離出來,還能夠降低操作成本。只有在不固定供應(yīng)商的情況下才能真正實現(xiàn)這些功能,此時面向 SOA 實現(xiàn)的技術(shù)可以無縫集成(考慮:“開放標準”),以構(gòu)造全面的端到端解決方案。

            不可輕易決定實現(xiàn) SOA。這與改變生活方式有些類似,因為開發(fā)和操作團隊遵循的 IT 控制模式將完全不同。
            ——Holt Adams

            當考慮了策略業(yè)務(wù)目標和活動時,理論上的 SOA 概念非常具有吸引力,更加容易得到支持。不過,不可輕易決定要實現(xiàn) SOA。這與改變生活方式有些類似,因為開發(fā)和操作團隊遵循的 IT 控制模式將完全不同。我提倡進行業(yè)務(wù)驅(qū)動開發(fā)。此過程涉及到將業(yè)務(wù)需求細化為 IT 要求,然后將 IT 要求細化為 IT 功能,以確定滿足這些需求所需的技術(shù)。根據(jù)我過去四年開發(fā)基于 Web 服務(wù)的解決方案和更為成熟的基于 SOA 的解決方案的經(jīng)驗,以下這些相關(guān)因素通常會讓我建議采用面向服務(wù)的體系結(jié)構(gòu):

            • 集成成本持續(xù)增長,而并未因為可提供真正投資回報 (ROI) 的新業(yè)務(wù)機會而得到緩解。
            • 兼并和收購是您公司擴大市場份額和獲得新發(fā)展機會的業(yè)務(wù)模式的核心。
            • 解決方案要求對來自異構(gòu)系統(tǒng)和編程模型的業(yè)務(wù)功能進行集成。
            • 業(yè)務(wù)的生存依賴于根據(jù)市場變化快速調(diào)整或即時響應(yīng)競爭威脅的能力。
            • 全球經(jīng)濟的影響要求您的公司事半功倍地開展業(yè)務(wù),而且有必要依賴業(yè)務(wù)合作伙伴提供非核心業(yè)務(wù)功能。
            • 就提高收益而言,與業(yè)務(wù)合作伙伴協(xié)作的效率對您的公司十分關(guān)鍵。
            • 您公司業(yè)務(wù)資產(chǎn)的價值在減少,因為不能對其進行評估,以在最初用途之外的其他地方使用。
            • 您公司員工的效率出現(xiàn)了問題,因為他們的大部分時間并沒有花在提供公司業(yè)務(wù)模型的核心功能和服務(wù)上。
            • 您公司的業(yè)務(wù)充滿了機會型的業(yè)務(wù)工作。
            • 您公司從頭開始開發(fā)新應(yīng)用程序。(我認為 SOA 應(yīng)當作為定位將來的新應(yīng)用程序的缺省體系結(jié)構(gòu)樣式,業(yè)務(wù)條件有其他限制時除外。)

            在理想情況下,您和您的業(yè)務(wù)合作伙伴間沒有預(yù)算限制、計劃期限、技能差距和優(yōu)先級差異,我想,此時完全可以說每個人都會采用 SOA,或者至少會考慮采用 SOA。不過,我們的選擇實際上經(jīng)常受到過去的決策的影響和限制(例如,技術(shù)投資、編程模型采用、服務(wù)的合同協(xié)定等)。因此,我們并不能總是自由地采用看起來能滿足某個業(yè)務(wù)需求或技術(shù)要求的最佳選項。以下的注意事項會讓我不建議采用面向服務(wù)的體系結(jié)構(gòu)或說明現(xiàn)在實現(xiàn) SOA 的邊際收益:

            • 您公司只將小部分 IT 預(yù)算用于集成活動。
            • 您公司的大部分流程都是手動的或以文檔為中心的,自動化的機會幾乎為零。
            • 您公司的大部分應(yīng)用程序開發(fā)都使用相同的編程模型。
            • 您公司的操作由一個或兩個客戶關(guān)系管理 (CRM) 和企業(yè)資源規(guī)劃 (ERP) 應(yīng)用程序管理,幾乎沒有集成要求。
            • 您公司的現(xiàn)有技能庫與實現(xiàn)支持 SOA 的基礎(chǔ)結(jié)構(gòu)所需的技能庫之間存在重大差異。
            • 未發(fā)現(xiàn)可從 SOA 提供的功能受益的業(yè)務(wù)需求或機會。
            • 新業(yè)務(wù)服務(wù)的可用性將對現(xiàn)有的收益流帶來負面影響。
            • 您公司依賴的業(yè)務(wù)合作伙伴對公司間流程的自動化采用了不同的優(yōu)先級。
            • 您公司的主要業(yè)務(wù)的開展涉及到海量且同步性和實時性要求非常高的事務(wù)。

            前面的列表只是一個示例,用以說明 SOA 是否是您公司最佳選擇的原因。當然,每個合同或項目都具有唯一的要求,因此關(guān)于何時采用 SOA 的決策取決于您公司的業(yè)務(wù)狀況。SOA 的價值主張十分誘人,但選擇何時讓您的公司采用 SOA 必須考慮業(yè)務(wù)環(huán)境的實際情況。采用 SOA 不一定要跨一大步,而通常是采用循序漸進的方式進行的。首先找到可以利用 SOA 概念和原則的項目,然后使用主要性能指標測定其價值,這是一種讓大家受益的好方法。







            將業(yè)務(wù)與 IT 結(jié)合起來

            Ali Arsanjani SOA 不僅是一個開發(fā)范例。該體系結(jié)構(gòu)用于在業(yè)務(wù)和 IT 之間構(gòu)建中間地段,其中包含雙方都同意的一組與業(yè)務(wù)一致的 IT 服務(wù),這些服務(wù)結(jié)合在一起,以實現(xiàn)組織的業(yè)務(wù)流程和目標。此范例提供了前所未有的靈活性:它允許將業(yè)務(wù)流程的結(jié)構(gòu)化組成從為流中每個活動提供功能的服務(wù)中分離出來。它還允許將業(yè)務(wù)實現(xiàn)與其描述分離開來。進行了此分離后,公司能以增量的方式更改其后端遺留系統(tǒng),并添加新功能來支持新需求,而不用受到供應(yīng)商選擇的限制。因此,可以在最小化對業(yè)務(wù)流程和 IT 系統(tǒng)的影響的前提下對軟件包和自定義應(yīng)用程序進行替換。

            將訪問功能從其實現(xiàn)分離的下一步工作就是 SOA。而且,除了此功能方面外,我們還可以將非功能方面外部化。例如,我們可以根據(jù)建立的業(yè)務(wù)策略確定哪些人應(yīng)該可以訪問特定的功能。我們還可以定義如何管理希望以靈活的、可重構(gòu)的方式訪問的技術(shù)資源。

            使用 SOA 技術(shù)時,實時或被動系統(tǒng)通常不是進行實現(xiàn)的最佳選擇,因為當前的技術(shù)不支持將 SOA 用于有大量并發(fā)使用情況的實時系統(tǒng)。不過,這些系統(tǒng)的建模也可以從 SOA 提供的分離和獨立概念獲益。
            ——Ali Arsanjani

            軟件工程發(fā)展的下一步就是此體系結(jié)構(gòu)。它使我們從結(jié)構(gòu)化對象轉(zhuǎn)向分布式對象和組件,然后以一組公共服務(wù)為中心來將業(yè)務(wù)和 IT 加以結(jié)合(這些服務(wù)結(jié)合在一起,可以實現(xiàn)組織的流程和目標)。SOA 還允許將公司的部分業(yè)務(wù)流程向生態(tài)系統(tǒng)中的合作伙伴公開。

            當需要支持業(yè)務(wù)靈活性的 IT 靈活性時,就可以使用 SOA。因此,對于兩個程序需要進行通信并訪問組合業(yè)務(wù)流程的行業(yè)應(yīng)用程序而言,就非常適合選擇 SOA。

            使用 SOA 技術(shù)時,實時或被動系統(tǒng)通常不是進行實現(xiàn)的最佳選擇,因為當前的技術(shù)不支持將 SOA 用于有大量并發(fā)使用情況的實時系統(tǒng)。不過,這些系統(tǒng)的建模也可以從 SOA 提供的分離和獨立概念獲益。

            SOA 非常適合用于消除冗余及將業(yè)務(wù)與未緊密耦合到特定服務(wù)實現(xiàn)的 IT 功能相結(jié)合。它可以允許服務(wù)使用者選擇后備服務(wù)提供者(不僅基于功能進行選擇——我需要類似的功能,但不要此版本的服務(wù)中的額外依賴項,還可以基于設(shè)計及運行時策略和 Web 服務(wù)管理功能進行選擇)。

            企業(yè)體系結(jié)構(gòu)基于 SOA 的公司具有穩(wěn)定的基礎(chǔ),能從現(xiàn)有系統(tǒng)概念地抽象業(yè)務(wù)功能。它們還具有允許隨著新軟件包、系統(tǒng)和資產(chǎn)的提供和新需求的出現(xiàn)以增量的方式進行業(yè)務(wù)驅(qū)動的 IT 轉(zhuǎn)換的基礎(chǔ)。







            一個重要但略顯不足的機制

            Grady Booch 在企業(yè)范圍中,大量的創(chuàng)新都出現(xiàn)在以下兩個方面:企業(yè)邊緣和企業(yè)之間。在邊緣上,我們可以看到在中間件之上的框架投入了很多精力(獨立于領(lǐng)域的框架,如 Ajax,以及特定于領(lǐng)域的框架,以特定行業(yè)為中心進行結(jié)合),也投入了很多精力進行與設(shè)備相關(guān)的工作 [ 典型的移動設(shè)備和具有無線頻率識別(Radio Frequency Identification,RFID)標記的設(shè)備 ]。而在企業(yè)之間,我們可以看到系統(tǒng)(遺留系統(tǒng)和新系統(tǒng))的系統(tǒng)的形成。

            在邊緣,服務(wù)提供超越基礎(chǔ)技術(shù)的行為。而在企業(yè)之間,服務(wù)提供了各種系統(tǒng)間語義豐富的強大通信方式。
            ——Grady Booch

            在此類以 Web 為中心的系統(tǒng)中,服務(wù)已被證實為這兩個方面的重要機制。在邊緣,服務(wù)提供超越基礎(chǔ)技術(shù)的行為。而在企業(yè)之間,服務(wù)提供了各種系統(tǒng)間語義豐富的強大通信方式。

            雖然這樣說,但在系統(tǒng)的構(gòu)造中,服務(wù)是一個重要卻略顯不足的機制。這樣說有些過于簡單化,但總的說來,服務(wù)對于高頻率或非常小粒度的連接而言,并不非常適合。而且,服務(wù)當然不是唯一適合各個系統(tǒng)的體系結(jié)構(gòu)的分解機制。







            SOA、Web 服務(wù)與優(yōu)勢保持

            Sanjay Bose SOA 是一個使用得有些過量的首字母縮寫,被從高級管理人員到開人員等各方面的人用(濫用)來傳達多種(有時候是不一致的)語義。在我看來,面向服務(wù)的體系結(jié)構(gòu)是一個框架,用于將業(yè)務(wù)流程和支持技術(shù)基礎(chǔ)結(jié)構(gòu)作為標準化且管理良好的組件——服務(wù)——進行集成,可以對服務(wù)進行組合、重用和調(diào)整以滿足不斷變化的業(yè)務(wù)優(yōu)先級。

            SOA 新手認為 SOA 和 Web 服務(wù)是等效的??赡艽嬖诓皇褂萌魏?Web 服務(wù),而使用現(xiàn)有 IT 資產(chǎn)(從大型機事務(wù)到基于對象的系統(tǒng))的基于 SOA 的有效解決方案。而且,我曾經(jīng)看到過幾個從部門級別發(fā)展出來的不是有效 SOA 應(yīng)用程序的 Web 服務(wù)實現(xiàn)。這些 Web 服務(wù)島通常并不完全遵循所有的核心 SOA 原則和特征——它們可能不是松散耦合、未抽象、不可重用、未組件化或不是獨立于平臺和協(xié)議的,最重要的是,它們可能不提供真正的業(yè)務(wù)價值。

            由于 Web 服務(wù)提供了一個 Level 字段,供基礎(chǔ)結(jié)構(gòu)和應(yīng)用程序供應(yīng)商進行創(chuàng)新和互操作,很多規(guī)范、概要、術(shù)語都使得這一混淆擴大化了。Web 服務(wù)僅是一個標準和技術(shù)的集合(還有很多其他技術(shù)支持選項),用以實現(xiàn)基于 SOA 的解決方案。

            在快速發(fā)展的全球經(jīng)濟環(huán)境中,企業(yè)要保持競爭優(yōu)勢,必須保持足夠的靈活性。通過使用 SOA 原則將 IT 基礎(chǔ)結(jié)構(gòu)與核心企業(yè)流程結(jié)合,可以提供和保持這個優(yōu)勢。因此,理解和采用 SOA 所面臨的問題不是如何或為什么,而是什么時候?基于 SOA 的企業(yè)解決方案已被證實能簡化業(yè)務(wù)操作、提高效率、降低成本及消除冗余。

            我們正處在對解決方案生命周期的每個方面進行改革的浪尖上,而 SOA 則是關(guān)鍵的催化劑。不過,從長遠來看,如果我們不謹慎的話,這個抽象和易用性可能會使 IT 架構(gòu)師或開發(fā)人員和計算機科學(xué)與技術(shù)的根本基礎(chǔ)脫離聯(lián)系。
            ——Sanjay Bose

            不過,為了獲得這些好處,必須正確地應(yīng)用 SOA。必須具有相應(yīng)企業(yè)范圍內(nèi)的遠景和轉(zhuǎn)換路線圖,必須有業(yè)務(wù)執(zhí)行人員的財務(wù)支持和承諾,并由有經(jīng)驗的架構(gòu)師以增量迭代的方式進行部署。這些增量步驟應(yīng)該首先針對關(guān)鍵業(yè)務(wù)問題進行,最終的解決方案應(yīng)該能提供業(yè)務(wù)價值。這樣可以幫助保持和促進使用 SOA 進行端到端企業(yè)轉(zhuǎn)換。在采用 SOA 的過程中,SOA 將不斷遇到各種重大的挑戰(zhàn),其中包括政治和文化的多樣性。

            從純技術(shù)角度而言,SOA 平臺(包括工具和運行時)也在經(jīng)歷著巨大的轉(zhuǎn)變。開發(fā)工具環(huán)境包含大量的建模工具、行業(yè)根深蒂固的場景、重用模式、方案和豐富的可視表示和控件以及模擬技術(shù)。運行時也同樣在不斷發(fā)展,從而提供增強的服務(wù)質(zhì)量、聲明性的和基于策略的管理和吸引人的管理和監(jiān)視 Dashboard(針對 IT 事件和業(yè)務(wù)事件),并使用具有自我修復(fù)功能的自動工具進行檢測。我們正處在對解決方案生命周期的每個方面進行改革的浪尖上,而 SOA 則是關(guān)鍵的催化劑。不過,從長遠來看,如果我們不謹慎的話,這個抽象和易用性可能會使 IT 架構(gòu)師或開發(fā)人員和計算機科學(xué)與技術(shù)的根本基礎(chǔ)脫離聯(lián)系。

            [ 編者注:有關(guān)此主題的更多觀點,可以參考 Sanjay Bose 最近與人合著的新書 SOA Compass:Business Value, Planning, and Enterprise Roadmap(此書是 IBM Press 和 Prentice-Hall 聯(lián)合出版的 developerWorks 系列叢書之一)。







            模型驅(qū)動的開發(fā)和虛擬企業(yè)

            Don Ferguson 您可能已經(jīng)選擇使用 SOA 了。大部分中型和大型企業(yè)都在其應(yīng)用程序設(shè)計中應(yīng)用了 SOA 元素。結(jié)構(gòu)良好的 CICS? 和 IMS? 程序通常符合 SOA 的要求。很多公司已構(gòu)建了由消息驅(qū)動的應(yīng)用程序組成的分布式系統(tǒng)。會話 Enterprise JavaBean 就是“類 SOA 的”。很多 ISV 系統(tǒng)都采用類似于服務(wù)的構(gòu)造;例如 SAP IDocs。SOA 將結(jié)構(gòu)良好的分布式系統(tǒng)的指南系統(tǒng)化,是結(jié)構(gòu)化編程、模型對象 (OO) 的概念的子集和消息驅(qū)動的處理的自然發(fā)展。

            在很短的時間內(nèi),我們行業(yè)的運行時互操作性和開發(fā)工具間的互操作性就達到了前所未有的水平。這個互操作性降低了遷移到 SOA 的成本,從而更容易獲得其帶來的好處。
            ——Don Ferguson

            Web 服務(wù)是一組用于構(gòu)建 SOA 解決方案的標準。基礎(chǔ)結(jié)構(gòu)供應(yīng)商 (IBM、BEA、Microsoft) 和應(yīng)用程序供應(yīng)商 (SAP、Oracle) 正像采用任何軟件技術(shù)一樣迅速地采用 Web 服務(wù)。在很短的時間內(nèi),我們行業(yè)的運行時互操作性 [簡單對象訪問協(xié)議(Simple Object Access Protocol,SOAP)、HTTP、WS-Security、WS-ReliableMessaging] 和開發(fā)工具間的互操作性 [Web 服務(wù)描述語言(Services Description Language,WSDL)、WS-Policy、Business Process Execution Language for Web Services (BPEL4WS) ] 就達到了前所未有的水平。這個互操作性降低了遷移到 SOA 的成本,從而更容易獲得其帶來的好處。

            都有什么好處呢?此處將不詳細討論全部或任何單個好處。我將簡要地提一下兩個好處:

            • SOA 支持模型驅(qū)動的開發(fā)和從業(yè)務(wù)透視圖進行解決方案監(jiān)視。我們通過使用 WebSphere? Business Modeler 產(chǎn)生一個允許分析人員和業(yè)務(wù)專業(yè)人員進行推斷和設(shè)計他們的業(yè)務(wù)流程的工具,從而有了很大進步。SOA 操作是流程中的任務(wù)或步驟的自然呈現(xiàn),而組合服務(wù)的實現(xiàn)(BPEL4WS,業(yè)務(wù)狀態(tài)機)則是流程的自然表示。根據(jù)簡單業(yè)務(wù)規(guī)則(使用 WebSphere Process Server 啟用),WS-Policy 和服務(wù)實現(xiàn)這兩種方法都是業(yè)務(wù)策略的自然表示。
            • Web 服務(wù)支持“虛擬企業(yè)”。MQ 和 Common Object Request Broker Architecture (CORBA) 等以前的技術(shù)主要針對企業(yè)內(nèi)計算進行了優(yōu)化。Web 服務(wù)協(xié)議和 WSDL 在 Internet 和內(nèi)部網(wǎng)絡(luò)中均可工作。這樣就能使用以前用于企業(yè)內(nèi)部應(yīng)用程集成的相同模型來在 Internet 上實現(xiàn)簡單的、快速開發(fā)的機會型 B2B 了。







            控制問題

            David K. Jackson SOA 與已在 IT 行業(yè)存在了 30 年甚至更長時間的其他軟件模塊化流程相似。SOA 所不同的硬件和網(wǎng)絡(luò)已足夠成熟,可以支持這項基于標準的技術(shù)。從任何方面而言,SOA 都不是過去行業(yè)內(nèi)的風行的熱潮技術(shù),但包含了廣泛的行業(yè)標準和支持。

            SOA 為企業(yè)提供了一個機會,以標識其核心能力和決定是否將這些核心能力作為服務(wù)向其行業(yè)和業(yè)務(wù)合作伙伴提供。另一方面的事實是;企業(yè)可以對作為其核心基礎(chǔ)結(jié)構(gòu)(不是核心能力)一部分的流程和應(yīng)用程序進行標識,然后確定進行購買。請注意,其中一些服務(wù)(提供的或購買的)可能僅為業(yè)務(wù)流程。企業(yè)架構(gòu)師可以牽頭開展相應(yīng)的工作,以發(fā)現(xiàn)企業(yè)中具有公共功能集的業(yè)務(wù)流程和 IT 流程。可以將執(zhí)行功能打包為外部依賴性很小的組件,并作為服務(wù)提供。這就使得業(yè)務(wù)流程創(chuàng)建者或應(yīng)用程序開發(fā)人員的工作得到簡化,以將精力放在能滿足股東的業(yè)務(wù)動力的唯一功能上。

            讓 SOA 正常工作在很大程度上不是技術(shù)問題。讓 SOA 正常工作是一個業(yè)務(wù)控制和 IT 控制問題。
            ——David K. Jackson

            讓 SOA 正常工作在很大程度上不是技術(shù)問題。讓 SOA 正常工作是一個業(yè)務(wù)控制和 IT 控制問題。技術(shù)專家可以根據(jù)很多存在的成功模式構(gòu)造一個 SOA 實現(xiàn)。然后讓企業(yè)使用這些服務(wù),而不再自己進行創(chuàng)建,這是另一個問題。恰當?shù)捏w系結(jié)構(gòu)控制將對其服務(wù)可供新應(yīng)用程序使用的項目進行標識。要使得 SOA 投資最終能物有所值,唯一的辦法就是讓高級管理人員承諾控制預(yù)算,或采取某種方式保證業(yè)務(wù)線能不受干擾。IT 架構(gòu)師還需要向執(zhí)行股東報告業(yè)務(wù)從其 SOA 投資和投入方面獲得的價值。

            為了讓 SOA 與業(yè)務(wù)合作伙伴協(xié)作,需要涉及企業(yè)已經(jīng)建立的關(guān)系?,F(xiàn)在,很少(如果有)客戶在其建立的合同關(guān)系之外為合作伙伴提供或購買服務(wù)。服務(wù)級別協(xié)議和爭議解決的相關(guān)事項要求配備封閉的協(xié)作系統(tǒng)。有關(guān)信任和安全的結(jié)構(gòu)化信息系統(tǒng)發(fā)展組織(Organization for the Advancement of Structured Information Systems,OASIS)標準在過去兩年中取得了長足的發(fā)展,但在等式的法律和業(yè)務(wù)一邊,仍然更傾向于和企業(yè)已經(jīng)了解的伙伴開展此類業(yè)務(wù)。







            這里沒有神話

            Christina Lau 關(guān)于為什么應(yīng)該考慮 SOA 有三個簡單的理由:

            1. 這是目前最熱門的領(lǐng)域之一;不要落后于時代的步伐。

            2. 工具、基礎(chǔ)結(jié)構(gòu)和標準經(jīng)過組合,可為整個 SOA 生命周期提供全面支持。了解我們的端到端編程模型。按照其中提供的詳細步驟開展工作,親身體驗成功。

            3. 如果您和我們一樣不斷地追求事半功倍,那么 SOA 可以為您提供幫助。尋找您可以再次利用的東西;不要所有東西都自己從頭做起。尋找現(xiàn)有服務(wù),對其進行調(diào)整,并加以使用。然后對其中一些服務(wù)進行共享。幫助創(chuàng)建一個生態(tài)系統(tǒng),以便在將來能更快地裝配更多有意義的解決方案。

            可以通過常識來看這個問題。如果您的項目處于十分關(guān)鍵的位置,而您的團隊必須投入大量精力學(xué)習工具和 API,SOA 就有可能是錯誤的選擇。如果可以在小項目中試用 SOA,則是不錯的選擇。
            ——Christina Lau

            開始采用 SOA 與采用任何其他技術(shù)或體系結(jié)構(gòu)沒有什么區(qū)別。可以通過常識來看這個問題。如果您的項目處于十分關(guān)鍵的位置,而您的團隊必須投入大量精力學(xué)習工具和 API,它就有可能是錯誤的選擇。如果可以在小項目中試用 SOA,則是不錯的選擇;利用這個經(jīng)驗,可以幫助您定義和擴展到下一個更大的項目。循序漸進,這里沒有神話。





            回頁首


            只是業(yè)務(wù)而已

            Calvin Lawrence SOA 的支持者不斷不畏余力地宣傳 SOA 的主要技術(shù)優(yōu)勢:松散綁定,能夠通過組件封裝可重用業(yè)務(wù)功能,最后(但沒有像通常那樣刻意強調(diào))還能提供更好的集成。

            包括我自己也是 SOA 的支持者之一,但我不斷在問自己一個問題:客戶真的對這種技術(shù)推論感興趣嗎?

            在過去兩年,我一直在與希望獲得 SOA 產(chǎn)生的價值主張的客戶全面合作。在與客戶溝通時,我經(jīng)常發(fā)現(xiàn)客戶認為,有很多其他體系結(jié)構(gòu)能提供比我所提到的更多的技術(shù)價值。有些客戶可能一廂情愿地得出結(jié)論,認為非常有經(jīng)驗的架構(gòu)師和開發(fā)團隊可以通過使用傳統(tǒng)企業(yè)應(yīng)用程序集成 (EAI) 體系結(jié)構(gòu)獲得很大價值。很多客戶會爭辯說,這些方法經(jīng)過驗證,實現(xiàn)風險并沒有直接采用 SOA 進行設(shè)計的風險大。

            雖然我們不知道其解決方案到底是什么樣的,但應(yīng)當客觀地看待每一個問題。請同時根據(jù)技術(shù)指標和業(yè)務(wù)指標來確定是否采用 SOA。
            ——Calvin Lawrence

            這個觀點可能會讓架構(gòu)師認識到在有些情況下,SOA 是錯誤的選擇,或者,至少不是最好的選擇。SOA 的技術(shù)可行性是否是選擇其作為解決一系列業(yè)務(wù)問題的體系結(jié)構(gòu)方法的原因?我會說不是:很多業(yè)務(wù)及 IT 相關(guān)的問題(例如缺乏有力的企業(yè)控制模型和策略)將減慢或阻礙任何構(gòu)思良好的技術(shù) SOA 活動的實現(xiàn)。

            在最近一次為期三天的 SOA 研討會上,一位汽車行業(yè)的首席技術(shù)官 (CTO) 告訴我下面的話:“我對 SOA 看法是‘只是業(yè)務(wù)而已’?!彼嬖V我他采用 SOA 的原因在于:

            • 提高他和他的團隊實現(xiàn)新產(chǎn)品和流程或更改現(xiàn)有項目的速度
            • 降低實現(xiàn)和擁有成本
            • 通過外包業(yè)務(wù)元素或從固定定價改為可變定價(根據(jù)業(yè)務(wù)量),從而支持靈活的定價模型
            • 簡化合并和收購所需的集成工作
            • 實現(xiàn)更好的 IT 使用率和投資回報

            這位 CTO 和他的團隊僅關(guān)心如何使用其現(xiàn)有的技能(而不必放棄其現(xiàn)有的基礎(chǔ)結(jié)構(gòu))在預(yù)算內(nèi)按時達成這些目標。他們已經(jīng)在其現(xiàn)有 EAI 基礎(chǔ)結(jié)構(gòu)中進行了大量投資。

            這位特別的 CTO 的話與很多其他人的說法都不一樣。他們只關(guān)心關(guān)鍵之處:我如何為股東提供回報?

            當然,作為一個有經(jīng)驗的架構(gòu)師(微笑),我知道一些解決此問題的體系結(jié)構(gòu)備選方案:

            1. 擴展其現(xiàn)有的 EAI 基礎(chǔ)結(jié)構(gòu)
            2. 計劃采用更多的事件驅(qū)動體系結(jié)構(gòu)(完全分離的、發(fā)布/訂閱,等等)
            3. 或許可采用 SOA

            由于這是一個 SOA 研討會,而客戶為此付費,因此我最初準備選擇第三個選項。實際上,對于這個情況,我使用了一點 EAI,一點事件驅(qū)動和很多 SOA 方面的東西。SOA 允許在必要時包含 EAI 和事件驅(qū)動方法。

            對于高速發(fā)展的汽車行業(yè),為了保持競爭優(yōu)勢和按時在預(yù)算內(nèi)提供產(chǎn)品,企業(yè)必須具有靈活性。這個客戶的難點集中在對其業(yè)務(wù)流程進行管理和合并。正如我的同事在此討論中指出的,將 IT 基礎(chǔ)結(jié)構(gòu)與核心業(yè)務(wù)流程結(jié)合,對于達成目標十分關(guān)鍵。SOA 相關(guān)的原則已被證明可以簡化業(yè)務(wù)操作,能減少與實際代碼關(guān)系很小而集中在人機交互和人員活動上的冗余項。在資金有限的業(yè)務(wù)環(huán)境中,幾乎沒有客戶能為解決特定的業(yè)務(wù)問題無限制地投入資金,而有時間并愿意對其控制流程進行修整的客戶則更少了。這樣做聽起來不錯,但卻不會實際這樣做。

            關(guān)鍵在于對現(xiàn)有基礎(chǔ)結(jié)構(gòu)、流程和現(xiàn)有控制模型加以利用和擴展。通過恰當?shù)厥褂矛F(xiàn)有 SOA 原則,可以對整個設(shè)計和實現(xiàn)流程進行管理,如:

            1. 標識問題。
            2. 標識組成業(yè)務(wù)并是難點所在的流程。
            3. 對這些流程進行建模,以對其進行簡化。
            4. 標識現(xiàn)有服務(wù),并編寫表示這些流程的其他服務(wù)。
            5. 將這些服務(wù)部署到可提供運行時功能且操作效率高的環(huán)境中。
            6. 監(jiān)視這些服務(wù)和流程,以獲得更高的效率。

            那么,網(wǎng)絡(luò)呢?雖然我們不知道其解決方案到底是什么樣的,但應(yīng)當客觀地看待每一個問題。請同時根據(jù)技術(shù)指標和業(yè)務(wù)指標來確定是否采用 SOA。如果合適,就使用它。如果不合適,就不用它。SOA 概念和原則將始終可以通過某種方式應(yīng)用到您的體系結(jié)構(gòu)中。







            康莊大道

            Andras Szakal 我們現(xiàn)在都應(yīng)該知道了整個行業(yè)對 SOA 的 ROI 和采用的贊頌之詞——松散耦合、重用更好、推向市場的時間更短、易于集成以及互操作性更好。不過,務(wù)必了解,我們目前對 SOA 的關(guān)注只是實現(xiàn)即插即用企業(yè)(或者說是按需企業(yè))的歷程中重要的一步而已。

            隨著我們進入下一個十年,我們將開始著手大幅度減少將來自不同 IT 供應(yīng)商的產(chǎn)品或組件組合成可行的有價值的端到端解決方案所需的工作量。供應(yīng)商提供的業(yè)務(wù)組件將不依賴于基礎(chǔ)結(jié)構(gòu),可以在各種平臺上執(zhí)行。因此,軟件開發(fā)人員會將更多的精力放在有效集成供應(yīng)商組件和確保有效的互操作性上。

            IT 業(yè)務(wù)操作部門所屬的人員將是業(yè)務(wù)和企業(yè)體系結(jié)構(gòu)專業(yè)人士。無論您是如何定義業(yè)務(wù)或企業(yè)架構(gòu)師的:為了實現(xiàn)這個遠景,整個行業(yè)將需要更多的具有 IT 和企業(yè)體系結(jié)構(gòu)背景的人士。
            ——Andras Szakal

            客戶的 IT 操作部門將主要負責選擇最適合業(yè)務(wù)需求的運行時平臺;即提供恰當部署和管理業(yè)務(wù)組件所需的必要服務(wù)質(zhì)量和運行時支持的平臺。

            相反,IT 業(yè)務(wù)操作部門將主要關(guān)注如何通過定義業(yè)務(wù)組件(將由其對應(yīng)的操作人員部署和管理)中包含業(yè)務(wù)規(guī)則實現(xiàn)組織的業(yè)務(wù)策略。這將通過 WebSphere Business Process Server 之類的業(yè)務(wù)流程管理系統(tǒng)完成。

            IT 業(yè)務(wù)操作部門所屬的人員將是業(yè)務(wù)和企業(yè)體系結(jié)構(gòu)專業(yè)人士。無論您是如何定義業(yè)務(wù)或企業(yè)架構(gòu)師的:為了實現(xiàn)這個遠景,整個行業(yè)將需要更多的具有 IT 和企業(yè)體系結(jié)構(gòu)背景的人士。

            雖然這個遠景可能十分誘人,仍然存在很大的風險,在進入組件天堂之前,我們必須小心地減小這些風險。在開始進行實現(xiàn)模型服務(wù)的體系結(jié)構(gòu)的任務(wù)時,最重要的減小風險方法可能就是要求有強有力的管理良好的控制流程和策略。只有通過強有力的企業(yè)服務(wù)控制策略才能夠避免更改管理問題、服務(wù)間的語義不匹配和系統(tǒng)功能結(jié)合方面出現(xiàn)的難于調(diào)試的問題。IT 部門可以通過制定的控制策略來減少風險,這些控制策略由執(zhí)行監(jiān)督團隊(其中包括 CIO、CTO 和業(yè)務(wù)線執(zhí)行官)提出并加以支持。







            改善信息

            Dan Wolfson 當然,您已經(jīng)對 SOA 有所了解了。您也知道 Web 服務(wù)、業(yè)務(wù)流程的重要性、模型驅(qū)動的體系結(jié)構(gòu)和所有這些讓人誠惶誠恐的 WS-* 標準。

            但或許您是一名信息人員。您需要負責組織的信息的完整性和對其進行分析。您關(guān)心表示業(yè)務(wù)狀態(tài)的數(shù)據(jù)庫的性能和穩(wěn)定性。正如您所知的,真正重要的部分。因此,您可能會問:“為什么我應(yīng)該關(guān)心 SOA?”

            SOA 表示的不僅是服務(wù)提供者和使用者的協(xié)定,而且也是信息提供者和使用者間的協(xié)定
            ——Dan Wolfson

            作為信息人員,我很關(guān)心 SOA。我之所以關(guān)心 SOA,是因為 SOA 具有直接和間接影響信息管理系統(tǒng)的能力——事實上可以影響信息本身。為了獲得成功,我們需要在業(yè)務(wù)服務(wù)所涉及的信息的上下文中對其進行考慮。我們需要知道檢索到的信息是準確的。被更新的信息經(jīng)過了驗證。交換的信息的意義對于服務(wù)提供者和使用者都是一樣的。如果忽略了這些事情,服務(wù)的價值和可重用性就會減少。

            直接來說,使用 SOA 時,我們需要在提供者和使用者之間形成一個信息協(xié)定,以便讓各方知曉信息意義的內(nèi)涵,并且仍然支持異構(gòu)系統(tǒng)——換句話說,我們必須假定世界是雜亂無章的,必須對其進行整理,以提高信息的價值,了解不同的結(jié)構(gòu)和意義之間的關(guān)系,并在可能的情況下就公共對象達成一致。

            將信息作為服務(wù)公開還將讓我們配備額外的信息服務(wù)器拓撲來容納增加的信息負載。它還會要求我們建立可以對信息訪問進行虛擬的點(這樣用戶就無需知道信息的真正位置以及其組織方式)。它還引入了一些方法,允許我們有效地對這些信息進行組合——通過集合或聯(lián)合。如果沒有建立更多的公共機制或引入經(jīng)過改進的清除機制,則我們稍后很可能被迫投入巨額的額外資金和資源進行清除,從而導(dǎo)致將來的靈活性下降。

            可以采用很多辦法實現(xiàn)信息協(xié)定。其中一個變得越來越重要的就是主數(shù)據(jù)管理 (MDM) 領(lǐng)域。MDM 系統(tǒng)可為業(yè)務(wù)應(yīng)用程序或服務(wù)提供經(jīng)過清除、整合且特定于域的信息。最常見的 MDM 系統(tǒng)是作為客戶和產(chǎn)品信息的信息集線器使用的系統(tǒng)。每個集線器都作為中心點使用,可以在此對信息進行添加、更新、審核、清除、搜索和查詢。集線器放置于可以將更改傳播到相關(guān)數(shù)據(jù)庫或可以生產(chǎn)相關(guān)服務(wù)的事件的位置。MDM 系統(tǒng)可以是事務(wù)型的(在操作業(yè)務(wù)流程的主線中更新),也可以是引用型的(提供業(yè)務(wù)流程所引用的信息的一致來源)。但最重要的是,我們可以將 MDM 系統(tǒng)看作其本身提供了一個一致的服務(wù)集,以供在各種業(yè)務(wù)流程內(nèi)使用和進行重用。

            通過 MDM 等方法顯式地實現(xiàn)信息提供者和使用者之間的協(xié)定,可以幫助我們實現(xiàn) SOA 所承諾的靈活業(yè)務(wù)流程和服務(wù)可重用性,并同時為我們提供提高所管理信息的質(zhì)量的機會。







            適合與不適合的場合,以及需要注意的地方

            Bobby Woolf SOA 是一種組織化的方法,用于應(yīng)用到由面向服務(wù)和分布式對象計算組合而成的應(yīng)用程序體系結(jié)構(gòu)中。讓我們來將這個定義分為幾部分進行分析。應(yīng)用程序體系結(jié)構(gòu) 是應(yīng)用程序各部分的寬泛組織,通常作為層實現(xiàn)。體系結(jié)構(gòu)指定包含哪些部分以及它們?nèi)绾我黄鸸ぷ鳌C嫦蚍?wù)將功能封裝為服務(wù)——寬泛的可重用任務(wù),可以在沒有任何前一上下文(除承載服務(wù)的系統(tǒng)的當前域狀態(tài)外)的情況下運行。服務(wù)的上下文是作為從調(diào)用方傳遞的參數(shù)提供的,和函數(shù)調(diào)用的參數(shù)非常相似。分布式對象 以特定方式運行在獨立進程中,通過這種方式,一個進程中的對象可以調(diào)用另一個進程中的對象上的方法。

            服務(wù)支持對訪問通過寬泛任務(wù)的經(jīng)過良好定義的 API 公開的已良好封裝的功能,從而可以通過低頻率的調(diào)用實現(xiàn)功能的高重用性。SOA 或許是所有方法中最好的一個。
            ——Bobby Woolf

            SOA 向分布式對象添加面向服務(wù),從而可以在進程之間調(diào)用服務(wù)。它是一種用于設(shè)計應(yīng)用程序體系結(jié)構(gòu)的方法,以便應(yīng)用程序的各個部分可以在不同的進程中運行,而且還允許不同的應(yīng)用程序共享和重用正在運行的部分。它是分布式對象計算的演變,用以在多個對立方之間獲得更好的平衡:需要訪問彼此功能的應(yīng)用程序;需要封裝自己功能的應(yīng)用程序;需要限制在其應(yīng)用程序編程接口 (API) 中描述的對外公開的功能的應(yīng)用程序;需要限制分布式調(diào)用的交互應(yīng)用程序。服務(wù)支持訪問通過各種任務(wù)定義良好的 API 公開的封裝良好的功能,從而可以通過低頻率的調(diào)用實現(xiàn)功能的高重用性。SOA 或許是所有方法中最好的一個。

            以下給出了一些簡單的技巧,用以確定何時采用 SOA 和何時不應(yīng)采用 SOA 以及需要提高警惕的情況。

            首先,適合采用 SOA 的情況:

            • 當數(shù)據(jù)分布程度非常高時,使用 SOA。將操作數(shù)據(jù)的代碼放置在與數(shù)據(jù)較近的位置,然后將其包裝為服務(wù),以供在任何地方進行訪問。
            • 希望功能具有高可用性時,使用 SOA。將功能作為服務(wù)部署在多個冗余的提供程序中,以在其中一些不可使用時,可以使用其他的對等服務(wù)。
            • 當應(yīng)用程序的各個部分需要獨立開發(fā)、維護和更新時,使用 SOA。只要保持各個部分之間的接口,每個團隊(如兩個不同的 B2B 公司)就可以使用其喜愛的技術(shù)按照自己的計劃實現(xiàn)各自的部分。
            • 當多個應(yīng)用程序需要重用功能和數(shù)據(jù)時,使用 SOA。共享的代碼僅重用功能;服務(wù)則允許各個獨立應(yīng)用程序重用一組共享的企業(yè)數(shù)據(jù),而無需將數(shù)據(jù)分發(fā)給所有應(yīng)用程序。

            以下是不適合使用 SOA 的情況:

            • 當希望開發(fā)盡可能簡單時,不要使用 SOA。使用一種語言實現(xiàn),在單個線程中運行,且沒有遠程訪問問題的應(yīng)用程序復(fù)雜性較低一些,因此構(gòu)建和調(diào)試更為方便。
            • 當希望操作環(huán)境盡可能簡單時,不要使用 SOA。要對松散耦合、事件驅(qū)動的分布式應(yīng)用程序進行故障排除要困難得多,要求對應(yīng)用程序?qū)崿F(xiàn)細節(jié)和操作環(huán)境配置細節(jié)及其當前狀態(tài)有全面的了解。
            • 當網(wǎng)絡(luò)不可靠或網(wǎng)速慢時,不要使用 SOA。服務(wù)組件運行于獨立的計算機上,通過網(wǎng)絡(luò)進行通信,因此,其速度和可靠性依賴于這些計算機及連接這些計算機的網(wǎng)絡(luò)。
              (注:分布式冗余服務(wù)可以幫助減少硬件不可靠和網(wǎng)絡(luò)延遲的影響。)
            • 進行原型設(shè)計時,不要使用 SOA。原型開發(fā)應(yīng)該簡單,而 SOA 并不簡單。

            對于何時需要提高警惕的問題,坦白地說,隨時都要提高警惕才行。以下是一些需要謹慎行事的具體情況:

            • 當服務(wù)接口不確定時,使用 SOA 需小心。服務(wù)接口允許使用者和提供者獨立地進行更改,但接口本身必須穩(wěn)定。SOA 中的接口變化比在單個應(yīng)用程序(特別是非分布式應(yīng)用程序)中復(fù)雜得多,因為有很多在其他情況下不相關(guān)的開發(fā)團隊必須就接口的更改進行合作。
            • 當安全性極為重要時,使用 SOA 需小心。每個服務(wù)都是一個新的易受攻擊的點,必須保證其安全性??梢暂p易訪問服務(wù)的人越多(如在公共 Internet 上的服務(wù)),可以嘗試攻擊該服務(wù)的人就越多。
            • 當性能極為重要時,使用 SOA 需小心。進程之間的每個服務(wù)調(diào)用都比進程內(nèi)的方法慢得多。
            • 希望功能具有高可用性時,使用 SOA 需小心。正如所指出的,冗余服務(wù)可以提高可靠性;但同時,活動部分越多出現(xiàn)故障的可能性就大。SOA 應(yīng)用程序只與其服務(wù)一樣可靠。

            這些列表根本不足以包含所有方面,但我希望這能讓您更好地了解什么是 SOA 以及適合使用 SOA 的情況。如果您需要這方面的專業(yè)幫助,請訪問 IBM Software Services for WebSphere,在其中可以找到各種參考資料。

            祝您好運!

            posted @ 2006-04-17 04:22 wsdfsdf 閱讀(240) | 評論 (0)編輯 收藏

            面向服務(wù)的體系結(jié)構(gòu)(SOA):對 IBM Workplace 和 Lotus 開發(fā)人員的采訪

            面向服務(wù)的體系結(jié)構(gòu)(Service Oriented Architecture),更多的時候被稱作 SOA,最近有很多關(guān)于它的報道。但是它到底是什么,又能夠為您做些什么呢?在該采訪中,IBM development 的三名成員將就 SOA 以及 IBM 和 Lotus 產(chǎn)品如何與 SOA 概念相結(jié)合進行探討。

            面向服務(wù)的體系結(jié)構(gòu)(SOA) 為對業(yè)務(wù)應(yīng)用程序進行智能且有效的設(shè)計、開發(fā)、部署和管理提供了一個廣闊的基礎(chǔ)設(shè)施。為了幫助更好地理解 SOA 是如何影響 Lotus 和 IBM Workplace 產(chǎn)品和技術(shù)的,我們訪問了 Lotus 和 IBM Workplace 開發(fā)團隊的幾名成員,并探討了 SOA 為您現(xiàn)實的工作帶來了什么。

            請簡單談一下你們在 IBM 的職責。
            Fernando Salazar:我是 IBM Workplace 團隊的高級技術(shù)人員。負責 Workplace Server 組件的整體體系結(jié)構(gòu)和內(nèi)容。

            Robert Duffner:我是 WebSphere Portal 和 Workplace 產(chǎn)品的產(chǎn)品經(jīng)理。還負責在 Workplace、Portal 和 Collaboration (WPLC) 產(chǎn)品部門中圍繞 SOA 策略提供幫助信息。

            Doug Wilson:我是 WPLC 部門的主要技術(shù)負責人,還是體系結(jié)構(gòu)指導(dǎo)委員會和顧問組的成員。我的工作是確???WPLC 產(chǎn)品的產(chǎn)品空間體系結(jié)構(gòu)的一致性,并保證它們適合于整體 Software Group 體系結(jié)構(gòu)策略。

            概括地說,什么是 SOA?
            Robert:SOA(面向服務(wù)的體系結(jié)構(gòu))并非新的思想。SOA 一直主要是關(guān)于如何正確地進行構(gòu)建,如何創(chuàng)建一種體系結(jié)構(gòu)藍圖,該體系結(jié)構(gòu)藍圖允許進行可重用的構(gòu)建,允許以更加松散耦合的方式工作,例如您構(gòu)建了這樣一個體系結(jié)構(gòu)并要進行修改,那么無需打破原有設(shè)計。還有,如何在流模式下集成異構(gòu)的 IT 系統(tǒng)。SOA 是真正支持使用可重用的組件或服務(wù)裝配業(yè)務(wù)流程的體系結(jié)構(gòu),這些組件或服務(wù)獨立于應(yīng)用程序和它們運行的平臺。

            這里的關(guān)鍵點是服務(wù)為真正可重用的構(gòu)建塊。這些概念確實不是新的了。我認為現(xiàn)在很多供應(yīng)商創(chuàng)建的產(chǎn)品開始支持 SOA 標準,比如 Web 服務(wù)這樣的產(chǎn)品,使 SOA 在很多 CIO 的心中占據(jù)了優(yōu)先和中心地位。大型跨平臺供應(yīng)商,如 IBM、Microsoft、Oracle 以及 SAP 都開始以能吸引客戶的方式支持這些標準 —— 因為支持更多的標準能幫助客戶降低風險,很多標準都是這樣產(chǎn)生的。在這種形勢下構(gòu)建 SOA 的能力開始變得很有前景,這可能是今天的 SOA 最激動人心的地方。在這一過程中標準起到了很重要的作用。

            Doug:我還要強調(diào) SOA 包括面向服務(wù)的體系結(jié)構(gòu)、對業(yè)務(wù)結(jié)構(gòu)以及支持業(yè)務(wù)的 IT 系統(tǒng)進行推理的方法。事實上,SOA 是從頂層開始的,通過分析業(yè)務(wù)是如何運行的,以及如何把支持業(yè)務(wù)的業(yè)務(wù)流程分割為基本步驟 —— 人為執(zhí)行的或者是通過多個自動片斷執(zhí)行的任務(wù)。SOA 的強大之處在于它給出了一種一致的方法,用于推理業(yè)務(wù)的結(jié)構(gòu),以及推理支持該業(yè)務(wù)的 IT 基礎(chǔ)設(shè)施和組織。

            Fernando:幫助推動 SOA 的新事物是企業(yè)服務(wù)總線(Enterprise Service Bus,ESB)這個概念。我們能夠通過標準定義所有的服務(wù),這樣非常棒。但是,ESB 允許我們安排這些服務(wù),并以滿足應(yīng)用程序需要的方式同步或異步地調(diào)用它們。接口和松散耦合是兩個由來已久的軟件工程概念,但是我認為企業(yè)服務(wù)總線是使這個概念成為可能的關(guān)鍵因素。企業(yè)服務(wù)總線是促使 SOA 產(chǎn)生的因素之一。

            你們提到 SOA 不是一個新事物,但是看起來直到最近人們才開始關(guān)注它。關(guān)注背后的主要原因是什么呢?
            Doug:我認為在該行業(yè)中有兩個關(guān)鍵的變化,為考慮如何構(gòu)造 SOA 重新注入了力量。Web 服務(wù)的描述功能與使用無處不在的互聯(lián)網(wǎng)的 IT 系統(tǒng)相組合,可能是過去兩年中許多 SOA 的思想重新熱起來的驅(qū)動因素。什么都比不上公眾的說服力,以及無處不在的技術(shù)解決方案,推動著前進的步伐。在過去,一些系統(tǒng)間互連的其他方式要通過專有的或是難于使用的協(xié)議,像 CORBA 和 IIOP,結(jié)果就我們需要取得一個單一的、通用的中間件基礎(chǔ)設(shè)施 —— 具體內(nèi)容要與規(guī)則保持高度的一致。Web 服務(wù)規(guī)范使人們只需很少的 IT 投資就能夠解決這個問題。


            Doug Wilson
            Doug Wilson

            哪類行業(yè)和公司是 SOA 的主要受益者?
            Doug:這是一個很難回答的問題。推動 SOA 實施的一個因素是通過很低的投資,就能夠為小型企業(yè)提供技術(shù)。我認為這在很大程度上能夠促使人們接受它,因為您不會被限制在某個范圍,就是說不是大型企業(yè)或小型企業(yè)的問題。問題是 —— 也是機會 —— 任何規(guī)模的企業(yè)都可以使用 SOA 策略。其中的一個驅(qū)動因素是在大多數(shù)情況下,小型企業(yè)都是較大型企業(yè)的服務(wù)提供者。例如,如果我想外包運輸業(yè)務(wù),或者是外包客戶滿意度跟蹤,或者是一個較大業(yè)務(wù)流程中的幾個小型業(yè)務(wù),那么我需要一個 IT 結(jié)構(gòu)允許我將行為或服務(wù)委托給小型企業(yè)??赡茉趯嵤┑某跫夒A段,大型企業(yè)將是服務(wù)的中心,但是許多小型企業(yè)將作為較大型企業(yè)的服務(wù)提供者形式出現(xiàn)。

            Robert:這一點十分好。顯然,能夠從 SOA 得到最大受益的組織,很可能是那些具有處于較高穩(wěn)定狀態(tài)的 IT 基礎(chǔ)設(shè)施的組織。其中所有遺留下來的程序都不能進行及時修改,它們無法支持業(yè)務(wù)需求的變化。通常,您能夠看到許多這樣的組織可能支付這樣的開銷。一些即將成為行業(yè)先鋒的公司正是那些具有投資和 IT 的公司,并且在這些公司中 IT 的使用比在其他公司中占有更大的比重。但是 SOA,在這一方面,能夠從根本上轉(zhuǎn)變 IT 基礎(chǔ)設(shè)施,使其從業(yè)務(wù)的阻礙轉(zhuǎn)變?yōu)闃I(yè)務(wù)變化的推動力。所以,如果您看一下像金融服務(wù)和銀行之類的組織,它們通常都具有非常尖端的組織。

            我還注意到,如果您稍微關(guān)注一下,就能夠發(fā)現(xiàn)一些組織還建立了體系結(jié)構(gòu)控制部門,或者是跨學(xué)科和跨區(qū)域的群組,他們實際上是整體地研究整個組織的 IT 基礎(chǔ)設(shè)施和體系結(jié)構(gòu)。這預(yù)示著在未來 SOA 將取得成功。

            除了 IT 方面外,SOA 會以哪些其他方式影響公司經(jīng)營業(yè)務(wù)的方式?
            Doug:我認為事實上恰恰相反。業(yè)務(wù)方式的自我演化正迫使 IT 部門作出響應(yīng),SOA 就是由此而產(chǎn)生的強大支持模型。業(yè)務(wù)在不斷地合并、放棄和重構(gòu),以及自我重組,并對 IT 部門跟上其發(fā)展提出了實質(zhì)性的挑戰(zhàn)。如果 IT 和企業(yè)能夠為業(yè)務(wù)結(jié)構(gòu)的推理形成統(tǒng)一的模型,并因此得到相應(yīng)的 IT 結(jié)構(gòu),那么這將成為 IT 部門滿足它們業(yè)務(wù)需要的強有力的推動力。

            Robert:看一下很多關(guān)于 IBM 幫助開始隨需應(yīng)變業(yè)務(wù)的討論,當我們考慮一個隨需應(yīng)變的業(yè)務(wù)時,我們認為企業(yè)需要跨他們的組織以及他們所需的全部合作伙伴、供應(yīng)商和客戶,對業(yè)務(wù)過程進行集成。但是更重要的是,他們能夠做出非常靈活的響應(yīng),并且能夠隨客戶的需求、市場機會或其他可能出現(xiàn)的任何類型的機會和威脅做出響應(yīng)。從這一觀點出發(fā),只是一味地花費、花費、花費和不進行調(diào)整的日子結(jié)束了。IT 和業(yè)務(wù)線正在以過去未曾有的方式結(jié)合到了一起。你不再為所有這些 IT 系統(tǒng)持續(xù)地花費資金,并且還得不到最初進行這些投資時所預(yù)期的回報。有了 IT 和業(yè)務(wù)線的密切合作,將幫助推動使用 SOA,幫助實現(xiàn)隨需應(yīng)變的業(yè)務(wù)這一目標。

            Fernando:我們描述的過程部分不僅采用了技術(shù)、標準和基礎(chǔ)設(shè)施;并且還從工程的角度進行了分析,以確定什么是您所依靠的(我們將其稱作 “原始的”)業(yè)務(wù)功能。原始的業(yè)務(wù)功能可能是像運輸產(chǎn)品、重新進貨報表或支付帳單這樣的功能。當將它們作為服務(wù)進行嵌入時,就能夠分離調(diào)用這些服務(wù)的邏輯,并且可以放到一個不同的位置。這是您真正獲得適應(yīng)性的地方 —— 如果這樣做了,現(xiàn)在就可以用新的算法管理庫存或運送包裹。邏輯是從原始的服務(wù)中分離出來的。當這樣做時,就能夠開始從適應(yīng)性中獲益。

            SOA 將會成為新的 IBM 特性和產(chǎn)品嗎?
            Doug:當然。最近,我們宣布了整個產(chǎn)品系列,目的非常明確,是要在我們的客戶中推動 SOA 實施。關(guān)于我們在世界范圍內(nèi)推動 SOA 這一事件,各種論壇上都有具體和詳細的報導(dǎo)。

            Robert:SOA 確實觸及到了我們所有的軟件生產(chǎn)線。請您看一下我們是如何定義 SOA 參考體系結(jié)構(gòu)的,其中涉及建模、部署、變更和管理,我們有幫助實施 SOA 整個周期的產(chǎn)品。SOA 最大的優(yōu)點是,公司不必一次性地完全加以實施;這里有很多的入口點,他們能夠從這些入口點開始。這要依據(jù)組織正在做什么。一些組織可能非常依賴集成解決方案,例如消息傳遞。這些客戶會問 “如何將系統(tǒng)集成到一起?如何確保可靠性和保證消息的傳遞?”。通常,當考慮高速消息傳遞和消息傳遞框架時,您將想到企業(yè)服務(wù)總線。我們有一個整套的產(chǎn)品線,主要為 WebSphere 品牌,我們還有已經(jīng)宣布的帶有業(yè)務(wù)集成的新產(chǎn)品,這些新產(chǎn)品還具有一些其他功能以支持 SOA 的核心。我們的其他產(chǎn)品,如 WebSphere Portal 和 IBM Workplace 產(chǎn)品,能夠作為 SOA 的最好的組成部分。


            Robert Duffner
            Robert Duffner

            某些組織可能會選擇從一些有機會的項目開始。這可能比較簡單,“我需要構(gòu)建門戶中的一部分。我該如何開始組織、構(gòu)建并將其放在具有面向服務(wù)體系結(jié)構(gòu)特征的系統(tǒng)中?換句話說,在可以較高程度的重用的地方該如何做?”。您可以從定義服務(wù)開始。一個服務(wù)可以簡單到只有一個業(yè)務(wù)流程,或是客戶必須進行的一個操作,例如檢查某個產(chǎn)品訂單的狀態(tài)。這個服務(wù)可以在客戶將要登錄的門戶中自我顯示。這個門戶和服務(wù)將顯示為一個 portlet,占用屏幕的一小部分。我將登錄到系統(tǒng)中 —— 我能夠快速地查看訂單狀態(tài)。這就是客戶將會看到的??蛻暨€會問 “我們?nèi)绾芜M行構(gòu)建?我們?nèi)绾芜M行軟件生命周期管理?我們?nèi)绾伍_發(fā)和部署這些產(chǎn)品?”。所以我們在支持 SOA 的 Rational 品牌中還有另外一組完整的產(chǎn)品線。這里還有 Tivoli 產(chǎn)品集,使您能夠進行安全性管理,并保證這些系統(tǒng)能夠正常運行。我們的另外一個產(chǎn)品線用于信息管理;例如 DB2 產(chǎn)品線。它們帶來了一整套的產(chǎn)品用于 SOA 策略的所有方面。

            最終情況依賴于我們的客戶的需要。我們可以把更多的精力放在某些組織的整個能力的廣度上,他們試圖進行部署、考慮部署或者是想要部署面向服務(wù)的體系結(jié)構(gòu)。在他們想從投資中獲得回報時,就是他們開始的時機,這要根據(jù)業(yè)務(wù)的需求而定。

            我們可以詳細闡述一下在 SOA 中 WebSphere Portal 技術(shù)所扮演的角色嗎?
            Robert:按照 Gene Phifer 的說法,他是 Gartner Research 的一個門戶權(quán)威,WebSphere Portal 是 SOA 出名之前的一種 SOA。回到互聯(lián)網(wǎng)剛產(chǎn)生的時候,當我們過去使用門戶時,我們中的很多人都理解門戶和 portlet 的概念,這些門戶如今在 Yahoo、AOL 和諸如此類的站點中變得十分流行。但是猜一猜怎么樣?企業(yè)和大型組織想做同樣的事情,但是在這種情況下內(nèi)容不是必需的,卻是有 “如何將所有的系統(tǒng)進行集成并提供單點訪問?” 這一問題。因此,創(chuàng)建一個平臺供重復(fù)使用這一想法實際上已經(jīng)非常接近面向?qū)ο蟮捏w系結(jié)構(gòu)。對許多組織而言,門戶代表進入 SOA 的邏輯上的過渡,因為它允許組織做我們正在談?wù)摰氖虑?。您可以在一個基礎(chǔ)設(shè)施上進行標準化,這樣如果您開發(fā)了一個雇員門戶,然后必須進行另外一個項目,那么您能夠重用許多資產(chǎn)和基礎(chǔ)設(shè)施,并開始從 SOA 中獲益。對一些組織而言,門戶是一個邏輯上、戰(zhàn)略上的 SOA 入口點,這并不意味著您必須從這里開始,但是它為您提供了一個平滑的入口點。

            Doug:大多數(shù)的業(yè)務(wù)流程在處理過程中需要用戶的參與。門戶為構(gòu)造人與面向服務(wù)的體系結(jié)構(gòu)之間的用戶交互提供了一種較好的方法。將服務(wù)的用戶界面映射到屏幕上特定的小矩形中,例如 portlet,是一種非常常見的操作。portlet 還對用戶能夠訪問的服務(wù)類型進行管理,并安排這些服務(wù)呈現(xiàn)在用戶前的方式。這些功能,諸如 WebSphere Portal 的處理功能,允許用戶安排一組服務(wù)和一組用戶界面間的用戶活動流。我們將門戶的這些非常常見的部分作為體系結(jié)構(gòu)中 Web 服務(wù)的基本表現(xiàn)工具。想像一下門戶作為 SOA 的前端。正是在這里 SOA 觸及到了用戶。

            SOA 會影響其他 IBM 產(chǎn)品嗎,例如 Notes/Domino 和 IBM Workplace?
            Doug:Domino 作為一項集成技術(shù),通過在 Domino 基礎(chǔ)設(shè)施中添加定義 Web 服務(wù)并執(zhí)行這些 Web 服務(wù)的功能,在支持 SOA 的過程中邁出了重大的一步。這是一個重要的新功能。許多 SOA 工作的初始階段包括調(diào)整現(xiàn)有的系統(tǒng),使之適應(yīng)面向服務(wù)的體系結(jié)構(gòu)。通常,這意味著在 Web 服務(wù)中封裝這些系統(tǒng)的一些業(yè)務(wù)功能,并且在環(huán)境中顯示 Web 服務(wù)。Domino 是這個領(lǐng)域中新的參與者。而 IBM Workplace 一開始就被設(shè)計為基于面向服務(wù)體系結(jié)構(gòu)的應(yīng)用程序系列。

            Fernando:確實是這樣。IBM Workplace 是一組協(xié)作功能,會在門戶中用到這些功能,但是其本質(zhì)結(jié)構(gòu)都是面向服務(wù)的體系結(jié)構(gòu)。主要協(xié)作功能有一些服務(wù)接口,例如創(chuàng)建文檔、發(fā)送電子郵件消息、創(chuàng)建 Web 會議等等。這些接口可以被調(diào)用、組合并與想開發(fā)的任何其他應(yīng)用程序中的其他服務(wù)集成。例如,使用 Workplace,完全有可能調(diào)整組織中新員工的注冊以及他們在想?yún)⒓拥恼n程中的注冊,這些課程是由 Workplace Learning 提供的。所有這些都可以通過 Workplace 提供的 Web 服務(wù) API 來實現(xiàn)。我們從一開始就將這作為我們的功能的整體意圖,并且我們一直在努力提高這些 API 的功能以與其他流程集成,并提高整個系統(tǒng)的功能以支持這些用戶交互。


            Fernando Salazar
            Fernando Salazar

            需要些什么才能夠使 IT 部門對 SOA 的理解同對業(yè)務(wù)線的理解相匹配?
            Robert:顯然,要對 IT 部門進行創(chuàng)新。同時也要讓業(yè)務(wù)線以不同于以前的方式加入進來。在我所工作過的某些組織中,技術(shù)從來不是阻礙成功的因素;而阻礙成功的因素通常與組織問題、部門問題、政治、組織間合作方式、設(shè)置管理方式等問題有關(guān)。用戶不想定義業(yè)務(wù)線試圖去做什么,而是將那些需求收集工作都交給 IT 人員,然后希望在 9 到 12 個月內(nèi)就能取得巨大成果。

            組織正在重新思考他們當前的組織方式?,F(xiàn)在可以看到 IT 和業(yè)務(wù)線的跨學(xué)科、跨功能角色的信息都聚集到一起,以更好地理解什么是業(yè)務(wù)需求,從而更好地理解技術(shù)如何幫助他們從一種組織方式轉(zhuǎn)換到另一種組織方式。這就是 IBM 的業(yè)務(wù)咨詢服務(wù)的重要作用,他們能幫助公司了解他們?nèi)绾沃匦绿幚砘蛑匦滤伎甲鳛橐粋€組織應(yīng)該如何運作,以及如何以不同于以前的方式來利用 IT,因此 IT 能成為組織的極具競爭性的優(yōu)勢。

            我希望 SOA 在組織中能像它在技術(shù)領(lǐng)域中那樣流行,但通常并非如此。它實際上是讓業(yè)務(wù)線和 IT 人員以更好地理解什么是需求的方式工作,從而確保項目取得成功,并理解每個需求在取得整個成功過程中都有其作用。而不是用戶將項目交給 IT 人員,IT 人員又將其交給業(yè)務(wù)線這樣一種運作方式。

            Doug:從入門角度來說,有多種可能的方法。一種是自頂向下的方法,從業(yè)務(wù)開始,然后是業(yè)務(wù)分析、為組織建模,最后是對業(yè)務(wù)流程進行建模。這種方法受 Rational Software Architect 套件的工具支持。更常見的是 “雙向逼近” 戰(zhàn)略,IT 人員從認識 Web 服務(wù)和 SOA 的封裝和集成戰(zhàn)略開始,并構(gòu)建一定數(shù)量的體系結(jié)構(gòu),然后加入到業(yè)務(wù)中以便在可能的情況下利用這些體系結(jié)構(gòu)。正如 Robert 所說的,SOA 實際上是關(guān)于將業(yè)務(wù)和 IT 組織合并到一起,在粒度級和業(yè)務(wù)行為方面達成一致,從而由服務(wù)對其進行建模。

            IT 組織如何能夠使 SOA 被業(yè)務(wù)線獲得和使用?
            Robert:這又回到了我們剛才談?wù)摰脑掝},就是關(guān)于如何使用 WebSphere Portal 技術(shù)來實現(xiàn) SOA,并將 Workplace 作為 Portal 技術(shù)的一種超集。通過將服務(wù)目錄映射到 portlet 目錄(即為所提供的服務(wù)創(chuàng)建用戶界面),并且通過使用 WebSphere Portal 來驅(qū)動服務(wù)和用戶之間的用戶交互,這是一個很好的過渡,適合于很多客戶已經(jīng)進行的 IT 工作。因此我們認為 WebSphere Portal 是業(yè)務(wù)線用戶能夠訪問 SOA 的關(guān)鍵。

            Fernando:要詳細描述這一點,也可以這么說,IT 領(lǐng)域和業(yè)務(wù)線領(lǐng)域之間的常見分工是,開發(fā)人員在 IT 方構(gòu)建標準的組件。這些界面可以作為 portlet,這些 portlet 訪問企業(yè)服務(wù),然后 IT 組織會將 portlet 組織到模板中。模板是服務(wù)的可重用組合,不同業(yè)務(wù)線的終端用戶都可以訪問這些服務(wù),并根據(jù)他們的自身需要對這些服務(wù)進行定制(這是一個關(guān)鍵部分)。同時使用 WebSphere Portal 和 Workplace,用戶的系統(tǒng)可以變得更靈活,由此可以為銷售群組或研發(fā)部門定制能訪問這些企業(yè)服務(wù)的標準模板,以包括特定類型的表單,從而收集自己的信息或涵蓋您所感興趣的項的特定文檔集,或上面標記了對您的團隊來說非常重要的事件和里程碑的特定日歷。這是一種本地定制,這些本地格式化的企業(yè)工作空間使這些組織內(nèi)的各個群組可以利用 SOA 的價值。

            Robert:的確如此,他說出了我們工作的意義和 WPLC 組織是什么。隨著組織開始使他們的基礎(chǔ)設(shè)施變得合理,并試圖提高工作效率,您將看到這些流程驅(qū)動的門戶、企業(yè)工作空間、企業(yè)桌面 —— 這些是您所聽到的用于描述這些事情的術(shù)語 —— 作為公司跨企業(yè)優(yōu)化他們的協(xié)作業(yè)務(wù)流程的首選方法而出現(xiàn)。WebSphere Portal 和 Workplace 能扮演如此重要角色是因為它們是商業(yè)人士實際所用的工具。用戶無需接觸很多集成技術(shù),因為這些都是底層技術(shù)。但是他們的確接觸到了這些桌面 —— 這些企業(yè)工作空間。

            你們?nèi)绾慰创?SOA 將塑造軟件工業(yè)的未來(或是這方面的其他工業(yè))?
            Doug:我將更清晰地預(yù)測一下未來,我們已經(jīng)說過 SOA 是業(yè)務(wù)和 IT 組織很好的交匯場所。我認為這將導(dǎo)致根本上的變化。我們還略微提到了一些 Web 服務(wù),尤其是互聯(lián)網(wǎng)上的 Web 服務(wù),允許小型業(yè)務(wù)和大型業(yè)務(wù)集合到一起,使 IT 基礎(chǔ)設(shè)施的花費同時適用于它們。并且其通過互聯(lián)網(wǎng)創(chuàng)建大型的、面向服務(wù)的系統(tǒng)的能力,我認為前景非常廣闊。隨著互聯(lián)網(wǎng)支持大量其他新出現(xiàn)的業(yè)務(wù)模型,我認為在服務(wù)提供者和服務(wù)消費者的領(lǐng)域,將會有一整套新的業(yè)務(wù)模型。

            Robert:我認為服務(wù)的重點是繼續(xù)強調(diào)虛擬化和適應(yīng)的作用,這就像軟件產(chǎn)品的交付。如今,我們經(jīng)常需要深入了解軟件系統(tǒng)的參數(shù)和選項才能進行安裝,然后再來調(diào)整這些參數(shù)和選項。軟件在某種程度上來說本身就是一種服務(wù),用戶將其添加到網(wǎng)絡(luò)基礎(chǔ)設(shè)施中并讓其工作,現(xiàn)在該軟件即是可以作為端點來訪問的服務(wù)。可以對該服務(wù)進行管理,將其連接到其他服務(wù),但是不需要深入了解這些服務(wù)的內(nèi)部工作原理。用戶更多的是注意它所帶來的價值。作為軟件開發(fā)人員,這對我們來說并不容易,實際上,我認為這是一件很難的事情。但是讓我們所有的產(chǎn)品以相同的方式互相通信是我們的預(yù)期目標。

            有什么需要補充嗎?
            Doug:我要再強調(diào)一下,我們將 WebSphere Portal 和 IBM Workplace 技術(shù)作為該行業(yè)的關(guān)鍵技術(shù)。隨著人們在互聯(lián)網(wǎng)上提供服務(wù)的改進和增加、組織內(nèi)部對服務(wù)可用性的改進、業(yè)務(wù)線幫助他們自身和創(chuàng)建新的最適合其業(yè)務(wù)需要的服務(wù)組合的機會,這些都將越來越多地需要 IT 基礎(chǔ)設(shè)施。IBM Workplace 是一種旨在允許業(yè)務(wù)線用戶創(chuàng)建和構(gòu)建他們自己的結(jié)構(gòu)、能力以及應(yīng)用程序的產(chǎn)品,以可用的協(xié)作服務(wù)和由 IT 組織或應(yīng)用程序供應(yīng)商帶入到應(yīng)用環(huán)境中的其他服務(wù)為基礎(chǔ)。因此我們認為自我服務(wù)和用戶驅(qū)動這兩者相結(jié)合非常重要。

            Robert:我將借用一下別人的展望和預(yù)測 —— 如果您看一下 IDC 上系統(tǒng)專家的分析,那么就會看到他們的確相信一個新的用戶工作環(huán)境將在今后的五年中出現(xiàn),一種新的、統(tǒng)一的、模塊化的企業(yè)軟件組合將為該環(huán)境提供支持,該環(huán)境構(gòu)建在面向服務(wù)的體系結(jié)構(gòu)之上。他們稱其為企業(yè)工作空間,它將極大地改進應(yīng)用程序和工作人員之間的交互,以及工作人員之間的協(xié)作。您將看到前所未有的效率水平。

            posted @ 2006-04-17 04:19 wsdfsdf 閱讀(216) | 評論 (0)編輯 收藏

            IBM WebSphere 開發(fā)者技術(shù)期刊: 使用服務(wù)組件體系結(jié)構(gòu)構(gòu)建 SOA 解決方案——第 2 部分-----組裝 SCA 組件

            檢驗 IBM WebSphere Integration Developer 組裝的SCA 組件的上下文中的引用和連線。

            摘自 IBM WebSphere 開發(fā)者技術(shù)期刊。

            引言

            在這一系列文章的第 1 部分,我們引入了服務(wù)組件體系結(jié)構(gòu)(Service Component Architecture,SCA)作為編程模型來構(gòu)建和組裝集成解決方案,包括簡要介紹什么是 SCA,以及一些相關(guān)術(shù)語的定義。我們還提供了一個通過 IBM WebSphere Integration Developer 使用 Java? 構(gòu)建 SCA 組件的示例,測試了該 SCA 組件,并使用 SCA 客戶端編程模型構(gòu)建了一個調(diào)用該 SCA 組件的示例 JSP 文件。在第 2 部分中,我們將繼續(xù)描述引用和連線,并介紹如何使用它們來組裝 SCA 組件。







            概述

            第 1 部分介紹的示例中,我們使用了一個簡單的 JSP 客戶端來調(diào)用 SCA 組件。該示例只用于演示;當構(gòu)建您自己的實際自定義應(yīng)用程序時,您可能會使用標準 J2EE? 組件模型來實現(xiàn)應(yīng)用程序邏輯。J2EE Web 應(yīng)用程序?qū)⒗^續(xù)調(diào)用 Enterprise JavaBean 來訪問特定于應(yīng)用程序的功能。實際上,SCA 編程模型是用于業(yè)務(wù)集成、應(yīng)用程序組合和解決方案組裝的,而不是用于 J2EE 應(yīng)用程序開發(fā)的。SCA 客戶端(它可以是 J2EE)通常在進程管理器外,例如它可以使用 BPEL 流程來編排工作流。與 BPEL 流程聯(lián)合部署的 Web 應(yīng)用程序也可以使用 SCA 編程模型來調(diào)用特定于應(yīng)用程序的功能。圖 1 顯示了 SCA 生態(tài)系統(tǒng)的一個示例。


            圖 1. SCA 生態(tài)系統(tǒng)
            圖 1. SCA 生態(tài)系統(tǒng)

            SCA 位于集成層。SCA 組件可以通過導(dǎo)入來調(diào)用 SCA 運行時外的應(yīng)用程序。非 SCA 客戶端可以通過導(dǎo)出調(diào)用 SCA 組件。在集成層內(nèi),可以通過定義引用和使用連線來組合 SCA 組件,這將在本文中重點介紹。有了連線和引用,您就可以在開發(fā)時定義運行時調(diào)用的特性;例如,使調(diào)用同步或異步,標記調(diào)用的轉(zhuǎn)換邊界,等等。這些特性是在部署時讀取的,它們可以啟用所需的運行時行為。圖 2 闡釋了這些高級概念。


            圖 2. 引用和連線的高級視圖
            圖 2. 引用和連線的高級視圖

            再次說明,我們關(guān)注的是集成層,而不是應(yīng)用層。另外,我們介紹的是較高級的集成,例如工作流編排或與 EIS 系統(tǒng)的高級集成。然而,出于演示目的,我們使用簡單的 Java 示例來顯示如何將組件連接到集成層中,強調(diào)的是連線和引用的功能而不是組件本身的實現(xiàn)。(在后續(xù)文章中,我們將介紹如何將 SCA 組件實現(xiàn)為 BPEL 流程和狀態(tài)機,以及如何應(yīng)用連線技術(shù)。)因此我們使用一個按比例縮減的模型來闡釋引用和連線,如圖 3 所示;然而,我們要記住圖 2 中合適的 SCA 使用遠景。


            圖 3. 簡化的引用和連線模型
            圖 3. 簡化的引用和連線模型






            引用

            正如第 1 部分所討論的,SCA 組件被打包成一個 SCA 模塊。一個模塊中的 SCA 組件通過對調(diào)用的 SCA 組件定義引用來彼此交互,并且將這些引用連線到相同模塊中的其他 SCA 組件。圖 4 闡釋了這一概念。


            圖 4. 引用和連線概念
            圖 4. 引用和連線概念

            對調(diào)用組件的引用是用 SCDL 表示的,如下所示:


            清單 1
            												
            																		
            <scdl:component xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns:java="http://www.ibm.com/xmlns/prod/websphere/scdl/java/6.0.0"
            xmlns:ns1="http://CreditApproval/CreditRequest"
            xmlns:scdl="http://www.ibm.com/xmlns/prod/websphere/scdl/6.0.0"
            xmlns:wsdl="http://www.ibm.com/xmlns/prod/websphere/scdl/wsdl/6.0.0"
            displayName="CreditApproval" name="CreditApproval">
              <interfaces>
                <interface xsi:type="wsdl:WSDLPortType" portType="ns1:CreditRequest">
                  <method name="calulateCreditScore"/>
                </interface>
              </interfaces>
              <references>
                <reference name="CreditHistoryPartner">
                  <interface xsi:type="java:JavaInterface" 
                  interface="approval.credit.credit.history.CreditHistory">
                    <method name="getCreditLimit"/>
                  </interface>
                  <wire target="CreditHistory"/>
                </reference>
                <reference name="CreditAgencyPartner">
                  <interface xsi:type="java:JavaInterface" 
                  interface="approval.credit.credit.agency.CreditAgency">
                    <method name="getCreditScore"/>
                  </interface>
                  <wire target="CreditAgency"/>
                </reference>
              </references>
              <implementation xsi:type="java:JavaImplementation" 
              class="sca.component.java.impl.CreditApprovalImpl"/>
            </scdl:component>
            												
            										

            引用的好處之一是能夠定義調(diào)用期間的服務(wù)質(zhì)量。當在 Assembly Editor 中連線組件時,可以指定服務(wù)質(zhì)量 (QoS) 限定符。這些限定符定義了調(diào)用期間在 SCA 運行時管理組件的必要條件。







            限定符

            使用 SCA,您無需編程或更改服務(wù)實現(xiàn)代碼就可以對組件應(yīng)用 QoS 限定符(例如事務(wù)、安全性和可靠的異步調(diào)用)。在連線組件時,您可以指定限定符來為組件以及訪問服務(wù)的客戶端提供擴展的服務(wù)質(zhì)量。在 IBM WebSphere Process Server 中,您可以在三個地方定義 SCA 限定符:

            • 引用
            • 接口
            • 實現(xiàn)

            在運行時,這些規(guī)范確定了客戶端如何與目標組件進行交互。運行時環(huán)境可以提供所需的任何額外處理,這取決于所指定的限定符。

            用于引用的限定符

            引用限定符可以指定異步調(diào)用的可靠性,以及是否應(yīng)該聯(lián)合目標組件的方法,使之成為任何客戶端事務(wù)的一部分。

            引用限定符包括:

            • Asynchronous reliability - 允許發(fā)生異步調(diào)用。這些限定符還允許您指定消息的可靠性、請求和響應(yīng)超時。同時也能配置 Service Integration Bus——它在 IBM WebSphere Application Server 運行時中提供消息傳遞平臺,因此對 WebSphere Process Server 可用。(有關(guān) Service Integration Bus 的信息,請參閱參考資料。)

            • Suspend transaction - 對于同步調(diào)用,當使用同步編輯模型進行調(diào)用時,客戶端全局事務(wù)上下文始終會被傳播到目標組件。(此限定符只影響客戶端全局事務(wù),因為本地事務(wù)從不傳播到目標組件。)對于客戶端不想讓目標組件與客戶端事務(wù)聯(lián)合的用例,需要使用掛起事務(wù)限定符設(shè)置來進一步限定引用:

              • True 會在通過服務(wù)引用調(diào)用組件之前掛起當前全局事務(wù)。
              • False(缺省值)指示運行時在通過服務(wù)引用調(diào)用組件之前不要掛起全局事務(wù)。
            • Asynchronous invocation - 確定是否應(yīng)該進行異步調(diào)用(作為任何客戶端事務(wù)的一部分)。值:

              • Call(缺省值)指示運行時在進行服務(wù)調(diào)用的同時將消息提交給異步調(diào)用的目的地。
              • Commit 指示運行時將消息提交給異步調(diào)用的目的地的工作交給當前工作范圍單元處理。
            • Suspend activity session - 活動會話能夠?qū)赡懿恢С址植际绞聞?wù)的資源進行更高級的協(xié)調(diào)。集成解決方案中更可能出現(xiàn)此類情況;客戶端不想讓目標組件與客戶端的活動會話相聯(lián)合,所以需要使用掛起活動會話限定符設(shè)置來進一步地限定引用:

              • True 會在通過服務(wù)引用調(diào)用組件之前掛起當前活動會話(如果存在)。
              • False(缺省值)指示運行時在通過服務(wù)引用調(diào)用組件之前不要掛起任何處于活動狀態(tài)的活動會話。

            您可以指定引用限定符,以便它們應(yīng)用于服務(wù)組件的所有引用或者只應(yīng)用于獨立引用。如果需要,您還可以為每個引用指定這些限定符,在這種情況下它們將重寫任何頂級限定符設(shè)置。在 Properties 視圖中以灰色表示繼承的限定符,以黑色表示已賦值的限定符。繼承的限定符不能更改,除非您選擇定義它們的所在元素。

            用于接口的限定符

            接口限定符說明了被目標服務(wù)支持的QoS,因此代表了一個與該服務(wù)客戶端的約定。

            接口限定符包括:

            • Join activity session - 確定目標服務(wù)是否愿意加入傳播的活動會話范圍。值:

              • True 指示運行時不要在接口邊界掛起活動會話(如果存在)。
              • False(缺省值)指示運行時在接口邊界掛起活動會話(如果存在)。
            • Join transaction - 確定目標服務(wù)是否愿意加入傳播的全局事務(wù)。值:

              • True 指示運行時不要在接口邊界掛起全局事務(wù)(如果存在)。
              • False(缺省值)指示運行時在接口邊界掛起全局事務(wù)(如果存在)。
            • Security permission - 使您能夠在 SCA 組件上定義 J2EE 角色。只有與聲明的角色相關(guān)聯(lián)的客戶端才能調(diào)用該組件。

            所有接口限定符都可以應(yīng)用于組件的三個級別:

            • 用于其所有接口
            • 用于單個接口
            • 用于某個接口的單個操作。

            操作的限定符覆蓋接口的限定符;接口的限定符覆蓋組件的所有接口的限定符。

            用于實現(xiàn)的限定符

            實現(xiàn)限定符提供確定服務(wù)權(quán)限和/或表示其對事務(wù)環(huán)境的需求的功能。

            接口限定符包括:

            • Activity session - 確定組件的處理是否在一個活動會話中執(zhí)行,除了全局事務(wù)上下文所提供的,它還提供一個備選的工作范圍單元。值:

              • True:組件將在活動會話的上下文中執(zhí)行。如果活動會話是在調(diào)用時出現(xiàn)的,則會添加該組件。
              • False(缺省值):組件將在現(xiàn)有的全局事務(wù)(如果存在)或本地事務(wù)的上下文中執(zhí)行。實現(xiàn)限定符為 activitySession=false 的組件必須使用接口限定符 joinActivitySession=false。
              • Any:如果存在活動會話,則組件會加入當前活動會話。如果不存在活動會話,則組件會在現(xiàn)有的工作范圍單元或本地事務(wù)的上下文中執(zhí)行。
            • Transaction - 確定組件處理執(zhí)行的邏輯工作單元。對于邏輯工作單元,事務(wù)期間所做的全部數(shù)據(jù)修改都是作為一個單元一起提交或作為一個單元回滾的:

              • Global:組件將在全局事務(wù)的上下文中執(zhí)行。如果在調(diào)用時存在一個全局事務(wù),則該組件會被添加到該全局事務(wù)范圍。如果不存在全局事務(wù),則會建立新的事務(wù)范圍。
              • Local(缺省值):組件將在本地事務(wù)的上下文中執(zhí)行。
              • Any:如果存在一個全局事務(wù),則組件將加入當前全局事務(wù)范圍。如果不存在全局事務(wù),則組件將在本地事務(wù)的上下文中執(zhí)行。
            • Security identity - 使您能夠指定組件擔當?shù)纳矸?,與部署描述符上的 J2EE Run-As 約束類似。

            限定符是在 SCDL 文件中定義的:接口限定符是在接口部分定義的,實現(xiàn)限定符是在實現(xiàn)部分定義的,引用限定符是在引用部分定義的。(有關(guān)詳細信息,請查閱 WebSphere Process Server Information Center。)







            連線組件

            在對引用有了新的理解之后,我們現(xiàn)在可以將一些組件通過連線連接起來。我們將使用的示例十分簡單,但在這個過程中我們也會檢查各種可用的服務(wù)質(zhì)量。我們將繼續(xù)介紹在第 1 部分使用的信貸審批示例。

            在我們的示例中:

            • Credit Approval 組件必須調(diào)用 Credit History 組件以及 Credit Agency 組件。
            • Credit Approval 組件將作為這兩個服務(wù)的一個 Facade。
            • Credit Approval 組件需要連線到其他組件。

            這一練習所需要的文件可以從本文所附帶的下載文件中獲得。

            設(shè)置工作區(qū)

            1. 啟動 WebSphere Integration Developer 并創(chuàng)建一個新的工作區(qū)(圖 5)。


              圖 5. 在 WebSphere Integration Developer 中創(chuàng)建工作區(qū)
              圖 5. 在 WebSphere Integration Developer 中創(chuàng)建工作區(qū)
            2. 關(guān)閉歡迎屏幕(圖 6)。


              圖 6. WebSphere Integration Developer 歡迎屏幕
              圖 6. WebSphere Integration Developer 歡迎屏幕
            3. 要從下載的文件導(dǎo)入項目交換文件,請右鍵單擊 Business Integration 視圖并選擇 Import(圖 7)。


              圖 7. 導(dǎo)入下載文件
              圖 7. 導(dǎo)入下載文件
            4. 選擇 Project Interchange,然后單擊 Next(圖 8)。


              圖 8. 導(dǎo)入項目
              圖 8. 導(dǎo)入項目
            5. 假設(shè)您已經(jīng)將下載的文件解壓縮到 C: 驅(qū)動器,則選擇 CreditApprovalPart2.zip 文件,然后單擊 Select All Finish(圖 9)。


              圖 9. 導(dǎo)入項目
              圖 9. 導(dǎo)入項目

            檢查組件

            在我們的示例中,我們將使用自底向上的開發(fā)風格:我們有一個現(xiàn)有的 SCA 組件集并準備對它們進行集成。從 Business Integration 視圖中,您可以檢查該 SCA 模塊:

            1. 展開 CreditApproval 模塊(圖 10)。


              圖 10. 展開的 Credit Approval 模塊
              圖 10. 展開的 Credit Approval 模塊
            2. 請注意,它有三個接口和三個 Java 實現(xiàn)。打開 CreditApprovalImpl Java 實現(xiàn)并轉(zhuǎn)到 calculateCreditScore() 方法。請注意,calculateCreditScore 同時與 CreditAgency 組件和 CreditHistory 組件進行交互來完成其服務(wù)。您很容易想到將 CreditApproval Service 實現(xiàn)為 BPEL 流程或其他組件類型,但在本例中,我們用一個簡單的 Java 組件來作為 Facade。


              清單 2
              																
              																								
              public DataObject calulateCreditScore(DataObject creditApp) {
              		
              	ServiceManager serviceManager = new ServiceManager();
              
              	BOFactory bof = (BOFactory)serviceManager.locateService("com/ibm/websphere/bo/BOFactory");
              
              	DataObject creditRating = bof.create("http://CreditApproval", "CreditRating");
              
              	creditRating.setString("customerId", creditApp.getString("customerId"));
              		
              	CreditAgency creditAgency = (CreditAgency) 
              	serviceManager.locateService("CreditAgencyPartner");
              
              	Integer creditScore = creditAgency.getCreditScore(creditApp);
              
              	CreditHistory creditHistory = (CreditHistory) 
              	serviceManager.locateService("CreditHistoryPartner");
              		
              	Double creditLimit = creditHistory.getCreditLimit(creditApp);
              
              		
              	creditRating.setInt("creditScore", creditScore.intValue());
              	creditRating.setDouble("creditLimit", creditLimit.doubleValue());
              
              	return creditRating;
              	}
              																
              														

            3. 要打開 Assembly Editor,請雙擊 CreditApproval 集合(圖 11)。當 Assembly Editor 打開時,會顯示三個組件(圖 12)。


              圖 11. 打開 Assembly Editor
              圖 11. 打開 Assembly Editor

              圖 12. Assembly Editor 中的組件
              圖 12. Assembly Editor 中的組件

            連線組件

            CreditApproval 組件通過使用簡單的 SCA 客戶端 API 來與 CreditAgency 和 CreditHistory 進行交互。然而,要讓運行時正確地調(diào)用這些服務(wù),需要將組件“連線”起來,使用 WebSphere Integration Developer 來進行這一操作非常簡單。在我們的示例中,我們將接受缺省值。

            1. 選擇 CreditAproval 組件并將其連線到 CreditAgency 組件(圖 13)。


              圖 13. 連線組件
              圖 13. 連線組件
            2. 將顯示一個對話框(圖 14),表明將在 CreditApproval 組件上創(chuàng)建一個引用。選擇 OK


              圖 14. 匹配引用對話框
              圖 14. 匹配引用對話框
            3. 由于 CreditApproval 組件是一個 Java 組件,所以我們需要用 WebSphere Integration Developer 生成 Java 接口以便能夠調(diào)用該組件。因此,在下一個對話框(圖 15)中選擇 Yes。如果 CreditApproval 已經(jīng)是一個完整的 BPEL 流程,則選擇 No。(請記住,在大多數(shù)情況下將使用 WSDL 作為集成層中的接口選擇。如果 User Interface 是與集成解決方案聯(lián)合部署的,則可以使用 Java 接口。)


              圖 15. 生成 Java 接口對話框
              圖 15. 生成 Java 接口對話框
            4. 重復(fù)步驟 9 到 11,將 CreditApproval 組件連線到 CreditHistory 組件。結(jié)果應(yīng)該與圖 16 類似。


              圖 16. 組件連線完成
              圖 16. 組件連線完成

            單元測試組件

            因為我們使用 Java 作為我們的實現(xiàn),所以可以在 Java SE 環(huán)境中對組件進行單元測試。正如在第 1 部分所做的,我們很容易在 WebSphere Integration Developer 中調(diào)出單元測試工具:

            1. 右鍵單擊 CreditApproval 組件并選擇 Test Component(圖 17)。


              圖 17. 測試組件
              圖 17. 測試組件
            2. 將顯示單元測試工具。該單元測試功能的一個很好的優(yōu)點是它允許獨立測試組件,并且可以檢測引用和創(chuàng)建模擬器。在我們的例子中,我們自己測試集成,所以需要刪除模擬器。

            3. 切換到 Configurations 選項卡。

            4. 展開 Module CreditApproval 模塊,突出顯示 CreditAgency CreditHistory,并將它們從 Emulators 列表中刪除(圖 18)?,F(xiàn)在,測試 CreditApproval 組件將導(dǎo)致調(diào)用 CreditHistory 和 CreditAgency 組件,而不會模擬交互。


              圖 18. 刪除模擬器
              圖 18. 刪除模擬器
            5. 切換回 Events 選項卡并突出顯示 Invoke 項(圖 19)。


              圖 19. Events 選項卡
              圖 19. Events 選項卡
            6. 填充輸入,如圖 20 所示。


              圖 20. 數(shù)據(jù)參數(shù)
              圖 20. 數(shù)據(jù)參數(shù)
            7. 單擊 Continue。

            8. 選擇 Eclipse 1.4 JVM 選項(圖 21)。


              圖 21. 選擇部署位置
              圖 21. 選擇部署位置
            9. 檢查每個步驟的流程。您可以實際看到流經(jīng)組件的數(shù)據(jù)(圖 22)。


              圖 22. 事件流
              圖 22. 事件流
            10. 最終結(jié)果應(yīng)該與圖 23 類似。


              圖 23. 測試結(jié)果
              圖 23. 測試結(jié)果
            11. 關(guān)閉測試編輯器,不進行保存。

            檢查服務(wù)質(zhì)量

            引用和連線是集成解決方案的關(guān)鍵,因為它們抽象出調(diào)用的方式和場合。當在 WebSphere Process Server 中運行時,您可以定義想為調(diào)用設(shè)定的服務(wù)質(zhì)量。例如,您可以使調(diào)用異步化、可以更改事務(wù)上下文,或者使異步調(diào)用更加可靠。這里我們將通過檢查引用屬性來查看各種 QoS 選項。

            1. 選擇 CreditApproval 組件上的 CreditAgency 引用,如圖 24 所示。


              圖 24. 組件引用
              圖 24. 組件引用
            2. 轉(zhuǎn)到 Properties 視圖。您將注意到該引用被選中。


              圖 25. 選中的引用
              圖 25. 選中的引用
            3. Details 選項卡上(圖 26),將顯示被調(diào)用的接口和多樣性,以及作為目標的連線。您可以更改調(diào)用的多樣性;對于異步調(diào)用,這樣可以以一種發(fā)布/訂閱方式調(diào)用幾個組件。


              圖 26. 引用詳細信息
              圖 26. 引用詳細信息
            4. 切換至 Qualifiers 選項卡(圖 27)以設(shè)置特定服務(wù)質(zhì)量。


              圖 27. Qualifiers 選項卡
              圖 27. Qualifiers 選項卡
            5. 單擊 Add 按鈕來查看幾個可用的服務(wù)質(zhì)量(圖 28)。


              圖 28. 服務(wù)質(zhì)量限定符
              圖 28. 服務(wù)質(zhì)量限定符
            6. 作為自我練習,您可以試驗這些限定符,請記住,這些質(zhì)量需要在 WebSphere Process Server 運行時中測試。這些限定符包括事務(wù)質(zhì)量和異步質(zhì)量;要測試事務(wù)工作,您需要與資源交互的組件。特定服務(wù)質(zhì)量是在接口中定義的。這使得該組件能夠控制其他組件調(diào)用它的方式。

            7. 突出顯示 Assembly Editor 中的 CreditApproval 接口(圖 29),或者導(dǎo)航至 Properties 編輯器。


              圖 29. Assembly Editor 中選定的 CreditApproval
              圖 29. Assembly Editor 中選定的 CreditApproval
            8. 檢查服務(wù)質(zhì)量限定符(圖 30)和實現(xiàn)限定符。請注意,這些限定符是在被調(diào)用的服務(wù)(而不是調(diào)用它的服務(wù))上定義的。


              圖 30. 檢查限定符
              圖 30. 檢查限定符

            在 WebSphere Process Server 測試環(huán)境中測試

            要測試服務(wù)質(zhì)量,您通常需要在 WebSphere Process Server 中運行,或者在 WebSphere Integration Developer 中為測試提供的 WebSphere Process Server 運行時運行。

            1. Servers 視圖中,右鍵單擊該服務(wù)器并選擇 Start(圖 31)。


              圖 31. 啟動測試環(huán)境中的服務(wù)器
              圖 31. 啟動測試環(huán)境中的服務(wù)器

              圖 32. 服務(wù)器已啟動
              圖 32. 服務(wù)器已啟動
            2. 當服務(wù)器啟動后,您可以按照管理控制臺中的指示(圖 32),以一種類似于添加 J2EE 應(yīng)用程序的方式將該 SCA 模塊添加到服務(wù)器中,因為 SCA 模塊被包裝成 EAR 文件(如第 1 部分所提到的)。再次右鍵單擊服務(wù)器并選擇 Add and remove rojects...(圖 33)。


              圖 33. 添加和刪除項目
              圖 33. 添加和刪除項目
            3. 選擇 CreditApprovalApp 并將它添加到已配置的項目一側(cè)(圖 34)。


              圖 34. 將項目添加到服務(wù)器
              圖 34. 將項目添加到服務(wù)器
            4. 檢查管理控制臺,確保 SCA 模塊已啟動(圖 35)。


              圖 35. 表明 SCA 模塊已啟動的控制臺消息
              圖 35. 表明 SCA 模塊已啟動的控制臺消息
            5. 要使用同一 WebSphere Integration Developer 單元測試功能來測試該組件,請按照前面所執(zhí)行的操作,再次右鍵單擊該組件,然后選擇 Test Component(圖 36)。


              圖 36. 測試 SCA 組件
              圖 36. 測試 SCA 組件
            6. 再次說明,請刪除模擬器,以使測試能夠流經(jīng) SCA 組件(圖 37)。


              圖 37. 刪除模擬器
              圖 37. 刪除模擬器
            7. 鍵入輸入?yún)?shù),如圖 38 所示。


              圖 38. 數(shù)據(jù)參數(shù)
              圖 38. 數(shù)據(jù)參數(shù)
            8. 選擇 WebSphere Process Server V6.0 作為部署位置(圖 39)。


              圖 39. 選擇部署位置
              圖 39. 選擇部署位置
            9. 檢查測試結(jié)果。

            作為自我練習,請更改組件以進行數(shù)據(jù)庫更新,然后試驗事務(wù)屬性。您也可以在管理控制臺中使調(diào)用異步化以及檢查基礎(chǔ) Service Integration Bus 配置。







            結(jié)束語

            本文介紹了使用 WebSphere Integration Developer 組裝服務(wù)組件體系結(jié)構(gòu)組件的上下文中的引用和連線。這一系列的下一篇文章將討論導(dǎo)入和導(dǎo)出,以便您能夠集成 SCA 模塊。該系列以后的文章還將介紹更復(fù)雜的組件以及與非 SCA 組件相集成。







            致謝

            作者真誠感謝 Eric Herness、Keys Botzum 和 Paul Ilechko 對本文的審閱。








            下載

            名字 大小 下載方法
            CreditApprovalPart2.zip 23 KB ?FTP|HTTP

            posted @ 2006-04-17 04:18 wsdfsdf 閱讀(287) | 評論 (0)編輯 收藏

            用于實現(xiàn) Web 服務(wù)的 SOA 編程模型,第 7 部分: 保護面向服務(wù)的應(yīng)用程序

            保護面向服務(wù)的體系結(jié)構(gòu)(service-oriented architecture,SOA)中的應(yīng)用程序具有挑戰(zhàn)性,因為 SOA 的松耦合特性可能暴露現(xiàn)有安全實現(xiàn)的弱點。以下解決方案包括定義明確的信任模型(基于可接受的驗證形式),并糅合了策略、Web 服務(wù)安全性和安全工程最佳實踐。

            引言

            對于任何應(yīng)用程序來說,保護信息訪問的安全都是最基本的要求。由于按 SOA 原則構(gòu)造的實現(xiàn)的服務(wù)、應(yīng)用程序以及跨組織操作的松耦合,因此安全對其甚至更為重要。這種環(huán)境往往會暴露現(xiàn)有安全實現(xiàn)的弱點或局限性。

            即使不考慮通過由模型驅(qū)動的開發(fā)和基于 SOA 的服務(wù)管理所提高的效率,業(yè)務(wù)應(yīng)用程序仍須保護信息。只保護周邊設(shè)施(如防火墻和路由器)是不夠的,因為隨需應(yīng)變的企業(yè)必須能夠隨著其合作伙伴、客戶和雇員之間的關(guān)系發(fā)展而建立和斷絕動態(tài)信任關(guān)系。因此,安全的隨需應(yīng)變企業(yè)需要靈活的、可自定義的基礎(chǔ)設(shè)施,以適應(yīng)新要求和規(guī)章制度。要提供這種靈活性,不應(yīng)將策略生搬硬套到基礎(chǔ)設(shè)施中;應(yīng)該通過由策略驅(qū)動的基礎(chǔ)設(shè)施滿足安全模型的要求,這任務(wù)可不簡單。

            本文將闡釋業(yè)務(wù)應(yīng)用程序利用隨需應(yīng)變安全基礎(chǔ)設(shè)施的安全功能的方式,以及建立用于保護面向服務(wù)的應(yīng)用程序的編程模型的設(shè)計原則。







            業(yè)務(wù)應(yīng)用程序和安全基礎(chǔ)設(shè)施

            安全集成以及對業(yè)務(wù)應(yīng)用程序和信息的訪問通常是通過身份驗證、授權(quán)和責任實現(xiàn)的。企業(yè)探討管理身份驗證、授權(quán)和責任的方式在很大程度上取決于其對客戶、雇員和合作伙伴之間的信任關(guān)系的看法;這些關(guān)系對業(yè)務(wù)應(yīng)用程序安全的影響;以及這些應(yīng)用程序的相對重要性和安全性。

            在業(yè)務(wù)合作伙伴之間交換敏感信息時,敏感信息必須受到保護??赡苓€需要用安全的方式保存敏感信息。必須保證消息源的完整性(如通過公證服務(wù))才能在必要時啟用驗證、審核和認可。可能需要對敏感信息進行加密以實現(xiàn)機密性,或?qū)ζ溥M行數(shù)字簽名以實現(xiàn)完整性。(數(shù)字簽名也可用于認可。)完整的 SOA 設(shè)計必須不但涵蓋消息級和傳輸級安全性,而且還要滿足保護保存的內(nèi)容以遵守政府規(guī)章制度和業(yè)界最佳實踐的需要。

            安全策略的制定和執(zhí)行以及所執(zhí)行的安全級別,基本上都取決于企業(yè)及其雇員、客戶和合作伙伴之間的信任關(guān)系。證書和密鑰之類的相關(guān)技術(shù)可用于反映和管理這些信任關(guān)系。工具可用于建立業(yè)務(wù)合作伙伴、客戶和企業(yè)等之間的信任關(guān)系模型并指定信任關(guān)系,還可以將信任定義轉(zhuǎn)換成適用于 IT 環(huán)境的技術(shù)。







            SOA 安全模型

            SOA 安全模型基于 Web 服務(wù)可能需要其中的傳入消息以驗證一系列聲明的過程。名稱、密鑰、權(quán)限和功能都是聲明的例子。根據(jù)所提供的證據(jù),會在請求者、服務(wù)端點和一系列可能的中介之間應(yīng)用適當?shù)男湃文P汀?/p>

            消息可能會通過請求者和目標服務(wù)之間的若干中介。端到端安全性必須考慮到請求者、中介和最終端點服務(wù)(提供者)之間的信任模型,如圖 1 所示。


            圖 1. 從請求者通過中介到提供者的信任模型
            信任模型

            對于消息處理,網(wǎng)絡(luò)和傳輸中介(如防火墻、路由器和代理服務(wù)器)一般不受信任。應(yīng)該防止傳輸中的所有消息受到不可靠中介的篡改。

            OASIS Web 服務(wù)安全性(Web Services Security,WSS)規(guī)范提供對傳輸中的簡單對象訪問協(xié)議(Simple Object Access Protocol,SOAP)消息的保護??捎?WSS 防止消息的真實性、完整性和機密性受到不可靠網(wǎng)絡(luò)和傳輸中介的攻擊。


            圖 2. 消息中介代理信任關(guān)系和聯(lián)合
            消息中介代理

            并不是所有中介都不可靠。Web 服務(wù)網(wǎng)關(guān)和企業(yè)服務(wù)總線中介服務(wù)都是消息轉(zhuǎn)換中介的例子,其在 SOA 內(nèi)的功能包括檢查,在某些情況下還包括對消息有效負載的修改 [請參閱此系列中的第 4 部分,“IBM 企業(yè)服務(wù)總線簡介”(developerworks,2005 年)]。在設(shè)計 SOA 安全基礎(chǔ)設(shè)施時,請考慮允許某些受信任的中介。

            處理請求者和應(yīng)用程序服務(wù)主機之間的信任關(guān)系的消息代理可能是另一個受信任的中介。在這種設(shè)計中,安全責任由代理和服務(wù)端點來分擔。如圖 2 所示,消息中介將負責消息級安全、請求者和提供者環(huán)境之間的身份聯(lián)合,以及管理請求者和服務(wù)提供者之間的信任關(guān)系。服務(wù)只有為了滿足特定于服務(wù)的安全要求(如建立(通過中介映射和聯(lián)合)訪問特定于消息有效負載中應(yīng)用程序數(shù)據(jù)的服務(wù)、完整性和機密性數(shù)據(jù)的身份)才會繼續(xù)起安全作用。通過分解業(yè)務(wù)應(yīng)用程序中脆弱或復(fù)雜的基礎(chǔ)設(shè)施代碼并將其委派給容器,基于 SOA 的安全方法可以提高靈活性并降低發(fā)生不測事件的可能性。







            消息安全性

            WSS 規(guī)范還提供一系列有助于 Web 服務(wù)開發(fā)人員保護 SOAP 交換的基本消息級完整性、機密性和身份驗證機制??捎酶鞣N方式組合這些機制,以便用各種加密技術(shù)建立各種安全模型。

            WSS 還提供可擴展的機制,以便將安全令牌與含有各種身份驗證及授權(quán)格式和機制的消息相關(guān)聯(lián)。例如,客戶機可能會提供身份證據(jù)及其具有特定業(yè)務(wù)證書的已簽名聲明。然后收到這種消息的 Web 服務(wù)就可以確定是否要信任其聲明和信任的程度。

            安全令牌聲明可由授權(quán)機構(gòu)核準或不核準。一組已核準的聲明通常表示為安全令牌(經(jīng)過數(shù)字簽名或受到授權(quán)機構(gòu)加密保護)。X.509 證書就是一個熟悉的已簽名安全令牌例子;它斷言某人的身份和公鑰之間的綁定關(guān)系。安全令牌可以“推送到”消息中或者在消息中攜帶安全令牌,也可以通過引用表示安全令牌,以便接收方從授權(quán)機構(gòu)“拉取”該聲明。

            因為安全令牌是在信任域內(nèi)起作用的,所以需要有鏈接信任域作用范圍的方式??赏ㄟ^協(xié)議或通過實現(xiàn)一系列規(guī)則強制執(zhí)行信任策略來手動鏈接。這樣,如果發(fā)送方和接收方之間有已確立的信任關(guān)系,則可信任未經(jīng)核準的聲明。例如,如果發(fā)送方和接收方使用的是其通過帶外信任關(guān)系建立的可靠連接,則發(fā)送方為 Bob 的未核準聲明足以讓某些接收方認為發(fā)送方實際上就是 Bob。在本例中,此可靠連接的存在可作為確鑿的證據(jù)。

            防止消息內(nèi)容受到非法訪問(機密性)或非法修改(完整性)是主要的安全事務(wù)。WSS 規(guī)范提供通過對主體、標題、附件或其任意組合(或部分)進行加密和/或數(shù)字簽名保護消息的方法。

            身份驗證請求基于可選網(wǎng)絡(luò)、由傳輸支持的安全性和消息中已批準的信息(聲明)的組合,這種技術(shù)稱為消息源身份驗證可能更好一些。通過網(wǎng)絡(luò)和由傳輸提供的安全性、消息中已批準的聲明,以及用收件人已知的密鑰對請求進行加密,請求者可以對收件人進行身份驗證。







            信任模型

            演示安全令牌已授權(quán)應(yīng)用的一種方式是,添加采用相關(guān)聯(lián)密鑰(來自于占有證據(jù)令牌)的數(shù)字簽名。這會使請求者可通過將安全令牌(如 X.509 公鑰基礎(chǔ)設(shè)施(Public Key Infrastructure for X.509,PKIX)證書或 X.509 證書)與消息相關(guān)聯(lián)來證明所請求的聲明組。

            如果請求者沒有向服務(wù)證明請求的聲明所必要的令牌,則可與相應(yīng)的授權(quán)機構(gòu)(我們稱為安全令牌服務(wù))聯(lián)系,并用正當?shù)穆暶髡埱笏璧牧钆啤0踩钆仆ㄟ^發(fā)布一系列安全令牌(可用于在不同的信任域之間代理信任關(guān)系)來形成信任的基礎(chǔ)。

            一種機制是應(yīng)用 WS-Trust(對于有關(guān) WS-Trust 規(guī)范的更多信息,請參閱參考資料)中所定義的質(zhì)詢回應(yīng)協(xié)議。這種機制由 Web 服務(wù)用來對請求者進行更多質(zhì)詢,以確保消息不過時,以及驗證安全令牌的使用是否已經(jīng)授權(quán)。圖 3 所示的就是此模型,可以看出任何請求者也都可以是服務(wù),請求者和目標服務(wù)都具有受信任的第三方安全令牌服務(wù),這種服務(wù)有助于驗證每個目標服務(wù)策略所需的安全令牌。


            圖 3. 安全令牌服務(wù)
            安全令牌服務(wù)

            此 SOA 安全模型(聲明、策略和安全令牌)還含有并支持若干特定模型,如基于身份的授權(quán)、訪問控制列表和基于功能的授權(quán)。通過該模型可使用現(xiàn)有的技術(shù),如 X.509 公鑰證書、基于 XML 的令牌、Kerberos 共享秘密票證,甚至口令摘要。SOA 模型結(jié)合 Web 服務(wù)安全對話語言(Web Services Secure Conversation Language,WSSC)和 Web 服務(wù)策略框架基本要素,這足以構(gòu)造高級密鑰交換、身份驗證、基于策略的訪問控制、審核和復(fù)雜的信任關(guān)系。

            將對 Web 服務(wù)應(yīng)用策略,Web 服務(wù)會從請求者收到可能包括安全令牌的消息,還可能會對其通過 WSSC 機制應(yīng)用某些保護措施。下面是由 Web 服務(wù)的信任引擎執(zhí)行的主要步驟:

            • 驗證令牌中的聲明是否足以遵從策略,以及消息是否與策略一致。
            • 驗證申請人的特征是否可由簽名來證明。在代理式信任模型中,簽名不可以證明申請人的身份;簽名可以證明中介(只是可斷言申請人的身份)的身份。聲明經(jīng)過批準或不是基于策略。
            • 驗證安全令牌(包括所有相關(guān)和即將頒發(fā)的安全令牌)的頒發(fā)者是否可信,可以頒發(fā)其所作的聲明。信任引擎可能需要外部驗證或代理令牌(也就是向安全令牌提供服務(wù)發(fā)送令牌,以便用其交換其他可直接用在其評估中的安全令牌)。

            如果滿足了這些條件,而且請求者有權(quán)執(zhí)行操作,則服務(wù)可以處理服務(wù)請求。

            可將 IP 安全(IP Security,IPSec)或傳輸層安全/安全套接字層(Transport Layer Security/Secure Sockets Layer,TLS/SSL)之類的網(wǎng)絡(luò)和傳輸保護機制與此 SOA 安全模型結(jié)合使用,以支持不同的安全要求和方案。如果可用,作為附加安全技術(shù),請求者應(yīng)該考慮采用網(wǎng)絡(luò)或傳輸安全機制,以便在頒發(fā)、驗證或更新安全令牌時對收件人預(yù)先進行身份驗證。







            編程模型設(shè)計原則

            從安全的角度來看,編程模型包括對于誰負責實現(xiàn)安全策略(如基礎(chǔ)設(shè)施或應(yīng)用程序)所作的決策,以及需要讓請求者得到此信息的哪一部分。除了操作方面,某些設(shè)計期間的策略(如在 J2EE 描述符中捕獲的)也有助于管理應(yīng)用程序。是通過使基礎(chǔ)設(shè)施能夠?qū)崿F(xiàn)安全模型,還是通過將安全的實現(xiàn)轉(zhuǎn)換成每個應(yīng)用程序中的代碼來最大程度地滿足業(yè)務(wù)需求,這是關(guān)鍵實現(xiàn)決策之一。要考慮的另一方面是調(diào)用服務(wù)的變數(shù)。服務(wù)的消費者是否通過可在訂閱期間定制的選擇得到了靈活性?最后,在實現(xiàn)安全解決方案時,應(yīng)該考慮安全工程——用于構(gòu)建安全應(yīng)用程序的工程方法。







            由基礎(chǔ)設(shè)施管理的安全與由應(yīng)用程序管理的安全

            每個組織通常都會讓某些人負責確定和實現(xiàn)其安全策略。在許多情況下此過程都是手動的,從而導(dǎo)致組織投入大量資源在不同的實體和應(yīng)用程序之間協(xié)調(diào)訪問。

            我們建議復(fù)雜的組織在基礎(chǔ)設(shè)施中集中實現(xiàn)與解決方案相關(guān)的安全策略——也就是驗證用戶質(zhì)詢(如用戶 ID/密碼)、控制對應(yīng)用程序的訪問(如對 travelService 執(zhí)行 reserve() 方法),以及委派身份(如運行方式 travelAgency id),以確保方法一致。可在某些部署構(gòu)件(如 J2EE 應(yīng)用程序的部署描述符)中定義初始應(yīng)用程序安全策略。部署完畢后,熟悉大部分應(yīng)用程序邏輯時就可以向部署環(huán)境提供策略信息了??蓪⒉呗月暶鞲爬ǔ筛呒壊呗砸?,以備將來細化成實現(xiàn)約束條件,這被認為是部署階段的工作。

            應(yīng)用程序設(shè)計中引入了有關(guān)由基礎(chǔ)設(shè)施管理的安全與由應(yīng)用程序管理的安全的決策。安全約束和條件是附加到實現(xiàn)構(gòu)件的。決定是讓基礎(chǔ)設(shè)施處理安全,還是將安全轉(zhuǎn)換成應(yīng)用程序中的代碼的時機在實現(xiàn)階段,此時通??梢缘玫接嘘P(guān)應(yīng)用程序平臺(如 Java? Platform Enterprise Edition (J2EE) 和 Microsoft? .NET)的信息。

            我們建議將應(yīng)用程序的重點放在業(yè)務(wù)邏輯、延遲服務(wù)訪問的保護和送往基礎(chǔ)設(shè)施的消息(承載應(yīng)用程序的運行時容器)上。在這種由基礎(chǔ)設(shè)施管理的方法中,附加到設(shè)計構(gòu)件的安全策略將被轉(zhuǎn)換成特定于平臺的策略 [例如,通過統(tǒng)一建模語言(Unified Modeling Language,UML)模型表示的要求將轉(zhuǎn)換成 J2EE 部署描述符]。

            在由應(yīng)用程序管理的方法中,安全實現(xiàn)是在應(yīng)用程序中實現(xiàn)的,必須實現(xiàn)相應(yīng)的安全調(diào)用。即使是由應(yīng)用程序管理的安全也必須通過 Java 身份驗證和授權(quán)服務(wù)(Java Authentication and Authorization Service,JAAS)將其安全調(diào)用(如 authenticate())轉(zhuǎn)換成相應(yīng)的特定于平臺的功能[如 loginContext.login()]。

            授權(quán)和訪問控制的粒度粗細不等。細粒度訪問(對于解決方案本身)與粗粒度訪問(對于其操作之一)的選擇通常取決于業(yè)務(wù)和技術(shù)考慮。粒度也會受各種因素的影響,包括信息實體的實例(如特定游客的信用帳戶概要信息)、上下文信息,如用戶特征(如旅行社)、時間約束(如從早上九點到下午五點)、訪問目的(如進行旅游預(yù)訂的目的)、訪問路徑(例如,內(nèi)部網(wǎng)請求與外部請求),以及許多其他因素。

            可通過定義應(yīng)用程序角色概括與授權(quán)相關(guān)的策略,其中的角色是指一組通過其可對特定應(yīng)用程序資源執(zhí)行某些操作的權(quán)限。例如,旅行應(yīng)用程序可聲明對 ReservationBean 執(zhí)行的 view()change() 預(yù)訂方法可由 TravelAgent 角色訪問。換句話說,TravelAgent 是由實現(xiàn)方案定義的角色,可以確定可由“旅行社”執(zhí)行的操作;根據(jù)一組用于對各自企業(yè) JavaBean(Enterprise JavaBean,EJB)調(diào)用特定方法的權(quán)限。在實現(xiàn)階段不大可能定義的是誰擁有 TravelAgent 特權(quán)。用戶到角色的指派通常是在部署時開始的,然后會在應(yīng)用程序的整個生命周期內(nèi)對其進行管理。清單 1 所示的是用于定義某些基于角色的方法權(quán)限的示例代碼。


            清單 1. 用于定義某些基于角色的方法權(quán)限的代碼
            												
            														<method-permission>
            <role-name>TravelAgent</role-name>
            <method>
               <ejb-name>ReservationBean</ejb-name>
            <method-permission>
            <role-name>TravelAgent</role-name>
            <method>
               <ejb-name>ReservationBean</ejb-name>
               <method-name> view</method-name>
               <method-name> change</method-name>
            </method>
            </method-permission>
            			
            												
            										

            在執(zhí)行某些業(yè)務(wù)邏輯之前要求提供通過身份驗證的身份信息的應(yīng)用程序必須從基礎(chǔ)設(shè)施中得到該信息。例如,在 J2EE 環(huán)境中,運行時會在身份驗證后確定用戶的身份;應(yīng)用程序可通過 API(如 getCallerPrincipal())檢索此信息。







            選擇的靈活性

            客戶機運行時有時需要某些對訪問服務(wù)本身的要求或約束(包括身份驗證、完整性和機密性要求)。而支持各種客戶機運行時(如瀏覽器客戶機、非瀏覽器客戶機和 PDA 瘦客戶機)可能是令人滿意的。要支持各種客戶機運行時,請發(fā)布斷言客戶機運行時必須確保消息機密性,并必須提供用戶身份的證據(jù)(用戶 ID/密碼或證書)的策略。身份驗證的策略概括可列出替代選項,如可接受的憑據(jù)類型,或所信任的憑據(jù)頒發(fā)機構(gòu)。

            例如,TravelService Web 服務(wù)可聲明其要求某些安全令牌類型的意圖和機密性要求。實現(xiàn)方案可通過描述符支持意圖聲明。工具則可進而生成必要的機器級詳細信息(如 WS-SecurityPolicy 表達式),如清單 2 所示。


            清單 2. WS-Security 策略描述符示例
            												
            														<wsp:Policy>
              <sp:SymmetricBinding>
                <wsp:Policy>
                  <sp:ProtectionToken>
                    <wsp:Policy>
                      <sp:KerberosV5APREQToken
                          sp:IncludeToken=".../IncludeToken/Once" />
                    </wsp:Policy>
                  </sp:ProtectionToken>
                  <sp:SignBeforeEncrypting />
                  <sp:EncryptSignature />
                </wsp:Policy>
              </sp:SymmetricBinding>
              <sp:SignedParts>
                <sp:Body/>
                <sp:Header
                   Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
                />
              </sp:SignedParts>
              <sp:EncryptedParts>
                <sp:Body/>
              </sp:EncryptedParts>
            </wsp:Policy>
            			
            												
            										







            安全工程

            在開發(fā)安全解決方案的過程中,安全工程是最佳實踐之一——請遵循定義明確的模式,以使您的應(yīng)用程序、服務(wù)或組件可以完全實現(xiàn)其設(shè)計者和用戶的期望。您應(yīng)該估計每個實現(xiàn)方案構(gòu)件中固有的風險,對其進行設(shè)計和實現(xiàn)以防其暴露在弱點下(例如,高效的內(nèi)存管理并避免出現(xiàn)隱蔽的通道)。工具支持和代碼評審也有助于將對從中部署解決方案的環(huán)境的損害降到最低(或徹底避免)。







            總結(jié)

            SOA 編程模型必須確保每個服務(wù)調(diào)用都符合對請求者和服務(wù)端點均有效的安全策略。安全基礎(chǔ)設(shè)施(包括對請求者進行身份驗證和對其授予服務(wù)訪問權(quán)的能力、基于基本信任模型跨 Web 服務(wù)請求傳播安全上下文、審核重要事件,以及有效地保護數(shù)據(jù)和內(nèi)容)形成了有助于保護組件和服務(wù)的 SOA 環(huán)境的結(jié)構(gòu)。所有 SOA 安全的核心都是基于策略的基礎(chǔ)設(shè)施和策略的管理。在理想的情況下,SOA 應(yīng)用程序的重點在于業(yè)務(wù)邏輯、委派安全策略的實現(xiàn),以及處理基礎(chǔ)設(shè)施的信任關(guān)系?;?Web 服務(wù)安全規(guī)范的 Web 服務(wù)安全模型和方法有助于解決保護面向服務(wù)的應(yīng)用程序的難題。

            posted @ 2006-04-17 04:14 wsdfsdf 閱讀(201) | 評論 (0)編輯 收藏

            實現(xiàn) Web 服務(wù)的 SOA 編程模型,第 6 部分: 不斷發(fā)展的組件模型-----實現(xiàn) SOA 的系統(tǒng)方法

            與語言無關(guān)、基于組件的面向服務(wù)的體系結(jié)構(gòu) (SOA) 編程模型簡化了實現(xiàn) Web 服務(wù)以及將其組裝到解決方案中的過程。使用編程模型,非編程人員可以在沒有掌握復(fù)雜的技術(shù)的情況下使用現(xiàn)有的 IT 資產(chǎn)。它滿足了解決方案設(shè)計人員和業(yè)務(wù)分析人員的需要,提供了更高級別的抽象來隱藏實現(xiàn)技術(shù)之間的差異,同時還提高了業(yè)務(wù)可靠性。

            為什么需要基于組件的編程模型?

            推動 IBM 的 SOA 編程模型的遠景依賴于兩個重要的觀察結(jié)果,請看以下兩段引言中的精辟描述:

            “根據(jù)時髦詞語設(shè)計 (Design-by-buzzword) 是一種常見的情況。至少在軟件行業(yè),這種行為或多或少與缺乏對一組給定的有用體系結(jié)構(gòu)約束的理解有關(guān)。換句話說,在選擇要重用的軟件體系結(jié)構(gòu)時,設(shè)計人員并沒有真正弄清楚這些體系結(jié)構(gòu)之所以好的原因?!?br />——Roy Thomas Fielding,“Architectural Styles and the Design of Network-based Software Architectures”(請參閱參考資料以獲得指向此研究報告的鏈接)。

            這個問題可以通過將詳細了解體系結(jié)構(gòu)約束的原因的人的經(jīng)驗融入一組模式、編程構(gòu)件和工具來解決。

            第二個重要的觀察結(jié)果同人以及人與技術(shù)的交互有關(guān):

            “創(chuàng)建面向服務(wù)的體系結(jié)構(gòu) (SOA) 意味著重新考慮當前用于構(gòu)建系統(tǒng)的實踐、組織的技能,以及團隊成員協(xié)作的方式。面向服務(wù)的作用在于通過組裝不同的應(yīng)用程序來開發(fā)解決方案,SOA 是體系結(jié)構(gòu)樣式,強調(diào)獨立服務(wù)提供者的松散耦合?!?br />——A.W. Brown 等,“Realizing service-oriented solutions with the IBM software development platform”(請參閱參考資料以獲得指向這篇文章的鏈接)。

            基于 XML 的 Web 服務(wù)標準使人想到了基于組件的編程模型的某些方面。諸如 Web 服務(wù)互操作性 (WS-I)、Web 服務(wù)描述語言 (WSDL) 和 Web 服務(wù)策略 (WS-Policy) 之類的標準嘗試創(chuàng)建與平臺無關(guān)的抽象和統(tǒng)一的框架來進行業(yè)務(wù)軟件集成。而 Web 服務(wù)的價值來源于在 SOA 中使用它們。

            大多數(shù)關(guān)于 Web 服務(wù)的資料都集中于互操作性協(xié)議和服務(wù)接口及其使用。而本文把重點放在用于實現(xiàn)服務(wù)并將服務(wù)組裝成解決方案的編程模型上。組件模型簡化了構(gòu)建和組裝服務(wù)的過程。

            良好定義的組件應(yīng)該支持生態(tài)系統(tǒng)中的各種用戶角色——例如業(yè)務(wù)分析人員、集成開發(fā)人員、適配器開發(fā)人員和解決方案管理員——通過實例化、使用、組裝和自定義符合用戶目標、技能和概念性框架的不同組件類型,來創(chuàng)建面向服務(wù)的應(yīng)用程序。(注意:編程人員作為專業(yè)人員和重要的軟件開發(fā)角色仍然存在,但并非每個人都必須成為專業(yè)編程人員才能高效地使用 SOA 構(gòu)件。)

            Web 服務(wù)標準中的組件模型明確地定義了組件和組件類型,以及定義和構(gòu)造組件的方式,以便由適合角色的工具重用和操作,這與我們對技術(shù)使用中人的方面的觀察結(jié)果是一致的。

            基于組件的編程模型有許多好處,最顯著的好處是可以減少復(fù)雜性。沒有哪個角色需要了解實現(xiàn)功能的所有方式或所有的系統(tǒng)接口。公開給每個角色的復(fù)雜性是有限的,而公開給開發(fā)人員角色的復(fù)雜性有助于他們使用適合于其任務(wù)的工具以定義良好的方式開發(fā)解決方案。

            組件模型必須是抽象的,并且與語言無關(guān),因為它的作用在于隱藏技術(shù)細節(jié)和差異。

            組件模型還必須簡化非編程人員組裝和定制“解決方案部分”的過程。因此,與組裝和調(diào)整有關(guān)的組件(或組件集合)的所有方面必須以與語言無關(guān)的方式顯式地聲明,這樣無需編程人員修改源代碼就可以通過工具操作它們。我們使用 XML 來表示這些聲明。

            SOA 的確切特征還有待探討,不過一些關(guān)鍵的方面已經(jīng)得到廣泛承認:

            1. SOA 是一種分布式組件 體系結(jié)構(gòu)。不管在企業(yè)內(nèi)部還是企業(yè)外部,SOA 組件都是透明的,并且可以通過一系列統(tǒng)一支持的、可互操作遠程過程調(diào)用和消息傳遞協(xié)議來統(tǒng)一訪問。接口定義標準支持開發(fā)人員工具之間的互操作性。網(wǎng)絡(luò)上 (on the wire) 協(xié)議互操作性——相對于代碼可移植性——是 SOA 組件的中心部分,支持統(tǒng)一訪問和平臺獨立。調(diào)用方不知道組件的基礎(chǔ)實現(xiàn)技術(shù),例如 Java? 2 Platform、Enterprise Edition (J2EE)、Microsoft? .Net 和 PHP。
            2. SOA 組件封裝功能,并支持通過業(yè)務(wù)分析人員和業(yè)務(wù)模型建模的抽象級別的重用。這使 IT 功能和它所支持的業(yè)務(wù)功能之間的映射更加直接,從而提高了可靠性。
            3. 聲明性的、計算機可處理的約定允許第三方訪問 SOA 組件提供的服務(wù)。這些約定顯式地聲明功能性特征以及非功能性(服務(wù)質(zhì)量或 QoS)特征和需求。SOA 組件使用 WSDL 記錄它們的操作。還可以使用用于 Web 服務(wù)的業(yè)務(wù)流程執(zhí)行語言 (BPEL4WS) 來定義組件的有效操作序列。
            4. 可以動態(tài)地發(fā)現(xiàn)、選擇、綁定(通過其聲明性屬性)和集成(使用組合機制,例如本系列第 3 部分“Process choreography and business state machines”(developerWorks,2005 年 7 月)中描述的組合機制)SOA 組件。







            組件實現(xiàn)和專用組件類型

            開發(fā)人員可以選擇使用 J2EE、PHP 或其他工具實現(xiàn)基本組件。作為一種編程模型,從根本上講,SOA 更多地關(guān)系到與組件的交互以及如何將這些交互集成到復(fù)合組件、應(yīng)用程序和解決方案。

            我們的編程模型還引入了一些定義良好的組件類型,可以建模開發(fā)人員生產(chǎn)和部署到解決方案中的常見構(gòu)件。其中包括 Plain Old Java Objects (POJOs)、Business Processes (BPEL4WS)、Structured Query Language (SQL) 服務(wù)、Adaptive Business Objects、通過 J2EE Connector (J2C) 體系結(jié)構(gòu)資源適配器訪問的 Customer Information Control System (CICS) 程序、使用 SAP 的業(yè)務(wù)應(yīng)用程序編程接口的應(yīng)用程序、J2EE 無狀態(tài)會話 Bean 和 IBM MQSeries? 應(yīng)用程序。

            因為在性質(zhì)上 SOA 組件模型是虛擬的,所以許多 SOA 組件自然支持多種實現(xiàn)技術(shù)。另一方面,不同的實現(xiàn)技術(shù)更好地適合于不同的任務(wù)。為了提高透明度,我們引入了服務(wù)組件類型的概念,每種類型都適合于具有特定技能、執(zhí)行特定任務(wù)和使用特定工具的開發(fā)人員。對于查詢,編程人員實現(xiàn)了一個 SQL 文件和一個包含一組 XQuery 語句的文件;對于文檔轉(zhuǎn)換,使用為此任務(wù)優(yōu)化的工具實現(xiàn) XSLT 樣式表等等。不需要知道 Web 服務(wù)、Enterprise JavaBean (EJB) 或其他組件是在部署時生成的,這是因為總體結(jié)果是作為通用 SOA 組件公開和使用的。

            編程人員構(gòu)建一種適合于該任務(wù)的特定組件類型,集中于要解決的問題和要使用的工具,而不是結(jié)果構(gòu)件。SOA 開發(fā)工具應(yīng)該集中于開發(fā)人員的技能和他或她理解的概念。后續(xù)文章將簡要介紹一些組件類型,通過三個完全不同的示例——Java 對象、信息管理系統(tǒng) (IMS) 事務(wù)和 SQL 語句——演示如何將任何實現(xiàn)技術(shù)映射到公共 SOA 組件模型,同時滿足特定開發(fā)人員的需要。






            組合

            雖然可以使用特定于平臺的技術(shù)實現(xiàn) SOA 組合,但是新的以 SOA 為中心的組合類型可以自己實現(xiàn),而無需轉(zhuǎn)換為另一種編程模型。

            使用組合模型,可以發(fā)現(xiàn)具有所需的接口和所需的基礎(chǔ)設(shè)施 (QoS) 策略的服務(wù),并且將這些服務(wù)聚合到新的服務(wù)、模塊和解決方案中。可以組合這些新的服務(wù)。

            我們的方法統(tǒng)一了創(chuàng)建和訪問業(yè)務(wù)邏輯的范型。我們的 SOA 編程模型比現(xiàn)有的編程構(gòu)造復(fù)雜,隱藏了實現(xiàn)技術(shù)之間的不同。在這種模型中,組件組裝到模塊中,而模塊又可以組合到解決方案中。組件公開了可以通過可尋址接口調(diào)用的接口。接口是使用 WSDL、Java 或其他語言描述的。實現(xiàn)可能有無法解析的對所需服務(wù)的引用,這些服務(wù)是執(zhí)行之前由連接在一起的組件提供的。可以由解決方案集成人員或解決方案組裝人員使用適合于角色的工具進行連網(wǎng)操作,他們可以運用可能不為最初開發(fā)這些組件的人所知的企業(yè)策略和企業(yè)服務(wù)總線 (ESB) 部署拓撲知識來進行工作。







            在沒有進行編程的情況下自定義

            不可能始終在沒有進行配置、自定義或調(diào)整的情況下按原樣重用服務(wù)。在需要更改時,當前的技術(shù)發(fā)展水平是修改源代碼。然而,是否能夠交付可以大量重用的組件在很大程度上取決于組件適應(yīng)其使用環(huán)境的功能。SOA 編程模型應(yīng)該支持構(gòu)建“編程人員”可以在沒有修改源代碼的情況下進行自定義的服務(wù)和模塊。當使用組件的編程人員與構(gòu)建組件的編程人員不在一個單位時,這一點尤為重要。

            基于組件的 SOA 編程模型提供了幾種在沒有進行編程的情況下自定義組件的機制。

            旨在重用的組件可以打包成具有可變點 (points of variability) 的模板,在將模板放入解決方案時可以對其做一些調(diào)整。這種適應(yīng)性是我們的編程模型最重要的部分,此外,編程模型還包括規(guī)則語言和相關(guān)工具,用于給新的用戶提供自定義功能。

            中介主要用于處理動態(tài)消息。通??梢栽跊]有進行編程的情況下組合中介。作為一個多協(xié)議構(gòu)造,企業(yè)服務(wù)總線發(fā)揮了重要的作用,可以將服務(wù)組件組合在一起進行無縫交互,另外,還允許在消息的路徑中插入稱為中介 的組件,以在不改變現(xiàn)有端點的情況下代理服務(wù)之間的交互,從而在主要方面解決整個企業(yè)范圍內(nèi)的問題,例如審核、記錄、路由、不匹配接口的適應(yīng)性、等效組件的增量替換和安全性。

            SOA 編程模型的另一個好處(來源于前面提到的特性)是能夠在軟件生命周期的不同階段用一個組件替換另一個組件。通過將聲明的接口延遲綁定到支持這些接口的實現(xiàn)可以做到這一點。企業(yè)為什么需要替換功能單元,有許多方面的原因。其中最重要的原因可能是減少在大型企業(yè)中管理更改的困難。以增量的方式引入更改并且通過遵循定義的接口限制其影響可以提高靈活性。這種做法也適合于松散耦合,而松散耦合常常是大型組織的特征。此外,使用服務(wù)組件,有不同的技能、需求和時間安排的組可以以人力資源和系統(tǒng)資源兩方面的效率都最高的方式在 IT 基礎(chǔ)設(shè)施中協(xié)同工作,這樣企業(yè)就可以快速地響應(yīng)業(yè)務(wù)級的更改,從而使企業(yè)大大獲益。







            組件定義

            我們的 SOA 是由以下規(guī)范定義的:

            1. 服務(wù)規(guī)范 以組件提供和使用的一組服務(wù)的形式提供了組件的視圖。它由以下三組規(guī)范定義:
              • 接口,通常是 WSDL portTypes。
              • 策略,記錄 QoS 屬性,例如事務(wù)行為和安全性。
              • 行為描述,例如 BPEL4WS 抽象流程。另一個例子可能是統(tǒng)一建模語言 V2 (UML2) 狀態(tài)模型,該模型指定了哪些操作對不同的狀態(tài)和操作所引發(fā)的狀態(tài)事務(wù)是有效的。調(diào)用方可以通過狀態(tài)模型計算有效的操作序列。
            2. 服務(wù)組件實現(xiàn) 是由以下四組規(guī)范定義的:
              • 提供的服務(wù)規(guī)范。
              • 需要的服務(wù)規(guī)范。
              • 可以在組件上設(shè)置以調(diào)整或自定義的屬性。
              • 為此提供基本支持的屬性;更復(fù)雜的方案使用可變點和對自定義組件的外部調(diào)用。
              • 對所有實現(xiàn)實例都保持不變的容器指示(策略)。
              • 定義組件實現(xiàn)的實現(xiàn)構(gòu)件(例如 Java 類、BPEL 文檔或 XSLT 規(guī)則集)。
            3. 服務(wù)組件(實例)由以下規(guī)范定義:
              • 名稱。
              • 服務(wù)組件實現(xiàn)。
              • 實現(xiàn)的任何屬性的值,設(shè)置用于調(diào)整實例。
              • 任何服務(wù)的規(guī)范,解析實現(xiàn)需要的服務(wù)規(guī)范。它們可以是連接組件實例的“網(wǎng)絡(luò)”,也可以是在運行時執(zhí)行以查找組件的“查詢”,所查找的組件實現(xiàn)相關(guān)接口,具有相關(guān)的 QoS 策略,并且匹配指定的行為(例如抽象流程或狀態(tài)模型)。

            有兩種定義 SOA 組件的基本方法。這些定義可以通過開發(fā)工具生成,也可以由開發(fā)人員手動創(chuàng)建。

            第一種方法是控制文件,顧名思義,控制文件即關(guān)聯(lián)或聯(lián)接組件的所有部分的文檔。例如,控制文件可以引用 WSDL 定義(提供的接口)、實現(xiàn)組件的 Java 類(實現(xiàn)構(gòu)件)或相關(guān)的策略文檔(策略斷言)。 它們可以是對文件系統(tǒng)、類路徑、源代碼管理系統(tǒng)或 Web URL 的引用??刂莆募椒▽⒍鄠€單獨開發(fā)的構(gòu)件聚合在一起組成組件。應(yīng)用程序開發(fā)工具可以幫助定義控制文件。

            第二種方法是使用 pragmas,指定相同信息的語言元素,但是包含在單個源文件的主體中。Java 方面的支持正在不斷增加(例如,JSR 175 中的 XDoclet 標記),以用 Java 語言編寫這些批注部分。但是這種方法尚不支持其他等同的有效 SOA 組件實現(xiàn)技術(shù)(如 SQL 或 XQuery 語句集)。每種組件類型都有用于其實現(xiàn)構(gòu)件的相關(guān)源文件格式,例如 Java 文件、狀態(tài)機或 SQL 文件。IBM WebSphere? Rapid Deployment 中的批注支持可以生成所有組成包含 pragmas 的源文件中的組件的單個元素。例如,Java 源文件中的結(jié)構(gòu)化注釋指示哪些 Java 方法將成為所生成的定義組件的服務(wù)接口中的 Web 服務(wù)操作。







            總結(jié)

            基于組件的編程模型——由面向任務(wù)的工具和運行時基礎(chǔ)設(shè)施支持——是快速采用 SOA 的關(guān)鍵。借助于期望的優(yōu)勢(如新的軟件重用方法),專業(yè)人員(不必是編程人員)可以在新的業(yè)務(wù)需求出現(xiàn)時使用 SOA 組件創(chuàng)建新的業(yè)務(wù)解決方案和改寫現(xiàn)有的業(yè)務(wù)解決方案。

            posted @ 2006-04-17 04:12 wsdfsdf 閱讀(174) | 評論 (0)編輯 收藏

            IBM WebSphere 開發(fā)者技術(shù)期刊: 使用服務(wù)組件體系結(jié)構(gòu)構(gòu)建 SOA 解決方案——第 1 部分-----太棒了,出現(xiàn)了另一個編程模型?

                 摘要: 隨著 IBM? WebSphere Integration Developer 和 WebSphere Process Server 的發(fā)布,出現(xiàn)了一種用于構(gòu)建面向服務(wù)的體系結(jié)構(gòu) (SOA) 的新編程范式,稱為服務(wù)組件體系結(jié)構(gòu),它是為在 SOA 中構(gòu)建和組裝業(yè)務(wù)解決方案而專門設(shè)計的一個新編程模型,旨在集成和組合服務(wù)。 摘自 IBM WebSphere 開發(fā)者技術(shù)期刊。...  閱讀全文

            posted @ 2006-04-17 04:10 wsdfsdf 閱讀(241) | 評論 (0)編輯 收藏

            在企業(yè)級 SOA 中使用 Web 服務(wù),第 7 部分: 使用 XML 二進制優(yōu)化打包規(guī)范加速 Web 服務(wù)應(yīng)用程序

            您是否希望了解如何使用 XML 二進制優(yōu)化打包 (XOP) 規(guī)范來優(yōu)化 Web 服務(wù)應(yīng)用程序?Judith M. Myerson 將向您展示在處理 Web 服務(wù)時,XOP 包比 XML 解析器更有效的原因。她將討論在多 SOA 中 Web 服務(wù)變得過于龐大的兩個場景。為了解決此問題,她討論了 XOP 包可以如何比 XML 解析器更為有效地處理二進制(而非文本)格式的大型文件。她給出了 XOP 處理前后的代碼示例,以幫助開發(fā)人員了解需要更改哪些元素。

            引言

            在本系列的第 2 部分中,我討論了可以如何實現(xiàn)原始應(yīng)用程序 Web 服務(wù)的業(yè)務(wù)流程并確定系統(tǒng)可以承載的可互操作 SOA 的最大個數(shù),以避免 SOA 過載。在本系列的第 5 部分中,我強調(diào)了將業(yè)務(wù)流程規(guī)則作為優(yōu)化 Web 服務(wù)的首要事項的重要性,并給出了一些示例,以說明可以如何減少 Web 請求的數(shù)量和執(zhí)行時間。

            在這一部分中,我將討論基于 XML 的 Web 服務(wù)應(yīng)用程序是如何變得過于龐大的。當大量使用 Web 服務(wù)時,這些 Web 服務(wù)將阻塞網(wǎng)絡(luò)通信,從而導(dǎo)致系統(tǒng)過載。為了解決此問題,我將討論可以如何應(yīng)用 XML 二進制優(yōu)化打包 (XOP) 規(guī)范(請參閱參考資料)來加速 Web 服務(wù)。

            此標準草案旨在比當前 XML 解析器更有效地處理 Web 服務(wù)。解析器的行為更像解釋器,而不是編譯器。當解析器讀寫大型文件(特別是文本格式的大型文件)時,并不能達到其讀取較小的文件或計算簡單函數(shù)時的性能。甚至加密也可能使 Web 服務(wù)陷于停頓,因為必須執(zhí)行復(fù)雜的計算才能獲得希望的結(jié)果。







            兩個場景

            我在第 2 部分中提到,從企業(yè)應(yīng)用程序提取組件,然后將其重新構(gòu)造為外部 Web 服務(wù),這種做法更為恰當。如果這樣,您就可以更改 Web 服務(wù)中的代碼,而不用重新設(shè)計并編譯長時間運行的大型復(fù)雜應(yīng)用程序。

            第一個 SOA 中經(jīng)過重新設(shè)計而顯得更加緊湊的應(yīng)用程序(請參見圖 1)可以通過發(fā)送 Web 請求來與第二個 SOA 中的外部企業(yè) MRP(托管資源原型)Web 服務(wù)進行動態(tài)鏈接。而 MRP Web 服務(wù)又指向第三個 SOA 中的外部企業(yè) CRM Web 服務(wù)。客戶關(guān)系管理 (CRM) Web 服務(wù)隨后將請求和信息發(fā)送到該應(yīng)用程序以進行進一步處理。


            圖 1. 動態(tài)鏈接到 Web 服務(wù)
            與 Web 服務(wù)動態(tài)鏈接

            讓我們假定在任何給定時間都可能出現(xiàn)對多個基于 XML 的 Web 服務(wù)的多個 Web 請求。鏈接到其他遺留系統(tǒng)或大型企業(yè)系統(tǒng)的企業(yè)應(yīng)用程序未在上圖中顯示,而這些系統(tǒng)又與接收多個 Web 請求的多個 Web 服務(wù)鏈接。當大量使用時,Web 服務(wù)會變得過于龐大,從而阻塞網(wǎng)絡(luò)通信。

            一個解決方案就是向基于 XML 的 MRP 和 CRM Web 服務(wù)應(yīng)用 XOP 包(請參見圖 2),從而以二進制格式進行處理。


            圖 2. 將 XOP 包應(yīng)用于 Web 服務(wù)
            圖 2. 將 XOP 包應(yīng)用于 Web 服務(wù)

            在第二個場景中,可以首先開發(fā)業(yè)務(wù)流程規(guī)則,然后開發(fā)根據(jù)現(xiàn)有 Web 服務(wù)構(gòu)建新的 Web 服務(wù)所需的基于 XML 的 Web 請求。如果新的 Web 服務(wù)(業(yè)務(wù)邏輯 Web 服務(wù)或以數(shù)據(jù)為中心的 Web 服務(wù))可以提供更好的或額外的服務(wù)和功能,則必須減少或完全消除冗余的 Web 請求、執(zhí)行時間、訪問時間和帶寬。

            問題在于,當創(chuàng)建新的 Web 服務(wù)并大量使用時,它們將會變得過于龐大。與第一個場景類似,您需要將 XOP 包應(yīng)用于 Web 服務(wù)。對于這兩個場景,您都需要與系統(tǒng)管理員協(xié)作,以確定在不引起系統(tǒng)過載的情況下可以使用 XOP 包的 Web 服務(wù)的最大數(shù)目。







            XOP 處理前的 Infoset

            為了理解 XOP 的工作方式,我將首先討論一個與 SOAP 消息相似的 XML Infoset,其中描述了包含一張圖片和一個簽名的 XML 文檔。在清單 1 中,我使用粗體來突出顯示原始 XML Infoset,以說明哪些原始元素在 XOP 處理之前。


            清單 1. XOP 處理前的 XML Infoset
            												
            																		
            
            <soap:Envelope
                xmlns:soap='http://www.w3.org/2003/05/soap-envelope' 
                xmlns:xop='http://www.w3.org/2003/12/xop/include' 
                xmlns:xmlmime='http://www.w3.org/2004/06/xmlmime'>
              <soap:Body>
                <m:data xmlns:m='http://example.org/stuff'>
                
                  
            														
            																
            																		
            																				<m:photo xmlmime:content-type='image/png'>
                    /aWKKapGGyQ=
                  </m:photo>
                  <m:sig xmlmime:content-type='application/pkcs7-signature'>
                    Faa7vROi2VQ=
                  </m:sig>
            																		`
                  
                </m:data>
              </soap:Body>
            </soap:Envelope>
              
            
            														
            												
            										

            正如您所看到的,其中有兩個元素:m:photo m:sig。m:photo 元素采用 base64 編碼的內(nèi)容為 /aWKKapGGyQ=,而 m:sig 元素采用 base64 編碼的內(nèi)容為 Faa7vROi2VQ=。這些元素也稱為元素信息項。內(nèi)容是元素的子項。請將該元素當作此子項的父項。子項是字符信息項,即包含字母數(shù)字字符的項。例如,m: photo 是子項 /aWKKapGGyQ= 的父項。該子項的名稱不便閱讀且難于發(fā)音,很容易出現(xiàn)鍵入錯誤。

            當通過 XOP 處理放置 XML Infoset 時,可以解決此問題。XOP 的工作方式是:從原始 Infoset 提取優(yōu)化內(nèi)容,然后創(chuàng)建 XOP Infoset。優(yōu)化內(nèi)容是我剛剛談到的經(jīng)過縮減的內(nèi)容。在清單 2 中,我突出顯示了要刪除的內(nèi)容。


            清單 2. 要刪除的內(nèi)容
            												
            																		
            
            <m:photo xmlmime:content-type='image/png'>
                    /aWKKapGGyQ=
                  </m:photo>
                  <m:sig xmlmime:content-type='application/pkcs7-signature'>`
                    Faa7vROi2VQ=
                  </m:sig>
            
            
            												
            										







            XOP 處理后的 Infoset

            XOP 處理涉及到三個步驟。第一步,使用 Infoset 中的二進制元素替換文本元素。第二步,在包含已替換元素的 Infoset 前添加 MIME 包。第三步,在該 Infoset 后添加另一個包。

            第 1 步:替換元素

            XOP 包使用名為 xop:Include 的新元素信息項來替換刪除的內(nèi)容。xop: Include 元素包含一個屬性信息項,帶有指向 XOP 包部分的鏈接,XOP 包承載從原始元素中刪除的數(shù)據(jù)的二進制表示。在清單 3 中,我突出顯示了替換原始 Infoset 中的圖片和簽名元素的內(nèi)容的 xop: Include。


            清單 3. 替換后的元素
            												
            																		
             <m:photo xmlmime:content-type='image/png'>
                    <xop:Include href='cid:http://example.org/me.png'/>
                  </m:photo>
                  <m:sig xmlmime:content-type='application/pkcs7-signature'>
                    <xop:Include href='cid:http://example.org/my.hsh'/>
                  </m:sig>
                   
             
            												
            										

            正如您所看到的, href='cid:http://example.org/me.png'/ 是圖片元素的屬性信息項,而 href='cid:http://example.org/my.hsh' 是簽名元素的屬性信息項。

            更新 Infoset 部分(請參見清單 4)。而行數(shù)保持不變。


            清單 4. 更新后的 XML Infoset 部分
            												
            																		
            <soap:Envelope
                xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
                xmlns:xop='http://www.w3.org/2003/12/xop/include'
                xmlns:xmlmime='http://www.w3.org/2004/06/xmlmime'>
              <soap:Body>
                <m:data xmlns:m='http://example.org/stuff'>
                  <m:photo xmlmime:content-type='image/png'>
                    <xop:Include href='cid:http://example.org/me.png'/>
                  </m:photo>
                  <m:sig xmlmime:content-type='application/pkcs7-signature'>
                    <xop:Include href='cid:http://example.org/my.hsh'/>
                  </m:sig>
                </m:data>
              </soap:Body>
            </soap:Envelope>
            
            												
            										

            第 2 步:在 Infoset 前添加 MIME 包

            為了完成更新,需要使用 MIME Multipart/Related 包中的 XOP 對原始 Infoset 進行序列化。XOP 是一種更有效的方法,用于序列化包含特定類型的 Xquery 和 Xpath 2.0 元素內(nèi)容的 XML Infoset。

            在更新后的 Infoset 前后各添加一個 MIME 包,以分別描述包含文本格式和二進制格式的圖片和簽名的 XML 文檔。在清單 5 中,我突出顯示了 XOP 包識別 8 位文本格式的 XML Infoset 的代碼。


            清單 5. Infoset 前的 XOP 包部分
            												
            																		
             MIME-Version: 1.0
            Content-Type: Multipart/Related;boundary=MIME_boundary;
            	      type=text/xml;start="<mymessage.xml@example.org>"
            Content-Description: An XML document with my picture and signature in it
            
            --MIME_boundary
            
            														
            																
            																		
            																				Content-Type: text/xml; charset=UTF-8
            Content-Transfer-Encoding: 8bit
            																		
            Content-ID: mymessage.xml@example.org
            
             
            														
            												
            										

            第 3 步:在 Infoset 后添加 MIME 包。

            清單 6 顯示了 XOP 包如何識別已被刪除的數(shù)據(jù)的二進制表示。


            清單 6. Infoset 后的 XOP 包部分
            												
            																		
              --MIME_boundary
            
            														
            																
            																		
            																				Content-Type: image/png
            Content-Transfer-Encoding: binary
            																		
            Content-ID: <http://example.org/me.png>
            
            // binary octets for png
            
            --MIME_boundary
            
            														
            														
            																
            																		
            																				Content-Type: application/pkcs7-signature
            Content-Transfer-Encoding: binary
            																		
            Content-ID: <http://example.org/my.hsh>
            
            // binary octets for signature
            
            --MIME_boundary--
                  
              
            														
            												
            										

            正如您所看到的,Infoset 后的 Content-ID 的二進制內(nèi)容,xop: Include element 中提到的鏈接代替了 Infoset 前的消息的文本內(nèi)容。







            最終結(jié)果

            清單 7 給出了序列化為 XOP 包的整個 XML Infoset。盡管其中還有其他行,但是此包比原始 Infoset 的 XML 解析器的效率高得多。


            清單 7. 序列化為 XOP 包的 XML Infoset
            												
            																		
            
            MIME-Version: 1.0
            Content-Type: Multipart/Related;boundary=MIME_boundary;
            	      type=text/xml;start="<mymessage.xml@example.org>"
            Content-Description: An XML document with my picture and signature in it
            
            --MIME_boundary
            Content-Type: text/xml; charset=UTF-8
            Content-Transfer-Encoding: 8bit
            Content-ID: <mymessage.xml@example.org>
            
            <soap:Envelope
                xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
                xmlns:xop='http://www.w3.org/2003/12/xop/include'
                xmlns:xmlmime='http://www.w3.org/2004/06/xmlmime'>
              <soap:Body>
                <m:data xmlns:m='http://example.org/stuff'>
                  <m:photo xmlmime:content-type='image/png'>
                    <xop:Include href='cid:http://example.org/me.png'/>
                  </m:photo>
                  <m:sig xmlmime:content-type='application/pkcs7-signature'>
                    <xop:Include href='cid:http://example.org/my.hsh'/>
                  </m:sig>
                </m:data>
              </soap:Body>
            </soap:Envelope>
            
            --MIME_boundary
            Content-Type: image/png
            Content-Transfer-Encoding: binary
            Content-ID: <http://example.org/me.png>
            
            // binary octets for png
            
            --MIME_boundary
            Content-Type: application/pkcs7-signature
            Content-Transfer-Encoding: binary
            Content-ID: <http://example.org/my.hsh>
            
            // binary octets for signature
            
            --MIME_boundary--
                    
            
            												
            										







            結(jié)束語

            為了運行具有 XOP 包的 Web 服務(wù),需要事先進行計劃,以確定應(yīng)該如何設(shè)計應(yīng)用程序,從而避免高峰時過載。應(yīng)該就優(yōu)化 Web 服務(wù)時應(yīng)采用何種編碼技術(shù)與系統(tǒng)管理員團隊進行溝通。

            您會發(fā)現(xiàn)解決這些問題后,您的 Web 服務(wù)應(yīng)用程序優(yōu)化工作變得容易得多。您可以使用 IBM Relational Web Developer for WebSphere? Software 來開發(fā)基于業(yè)務(wù)流程的 Web 服務(wù),然后在 SOA 內(nèi)部及各個 SOA 之間將其與 XOP 包一起使用。管理員會發(fā)現(xiàn),解決了這些問題也使得他們的網(wǎng)絡(luò)管理工作變得更加輕松。他們能確定在不引起系統(tǒng)過載的前提下,可以將多少應(yīng)用程序與 XOP 包一起使用。

            posted @ 2006-04-17 04:06 wsdfsdf 閱讀(220) | 評論 (0)編輯 收藏

            在企業(yè)級 SOA 中使用 Web 服務(wù),第 6 部分: 使用 WebSphere Application Server 平衡 Web 服務(wù)應(yīng)用程序的負載

            您希望了解 SOA 內(nèi)服務(wù)器間 Web 服務(wù)應(yīng)用程序的負載平衡么?在本文中,Judith M. Myerson 與我們一起探討了用戶在高峰流量期間所需求的快速響應(yīng)的重要性,并且列舉了一些負載平衡技術(shù)的示例。此外,她還與我們一起探討了負載平衡工具——WebSphere? Application Server 和 WebSphere Edge Server,開發(fā)人員、系統(tǒng)管理員和網(wǎng)絡(luò)管理員可以使用這些工具在服務(wù)器間平衡 Web 服務(wù)應(yīng)用程序的負載,從而確保網(wǎng)絡(luò)在高峰流量期間保持高性能、高可靠性和高可用性。

            引言

            在本系列第 4 部分“使用 Rational 開發(fā)工具構(gòu)建 SOA 中間件應(yīng)用程序”(請參閱參考資料)一文中,我講解了如何使用 Web 開發(fā)工具創(chuàng)建 SOA 中間件應(yīng)用程序。在本系列第 5 部分“使用 WebSphere Business Integration 工具優(yōu)化 Web 服務(wù)應(yīng)用程序”(請參閱參考資料)一文中,我講解了如何使用業(yè)務(wù)流程工具集成和優(yōu)化 Web 服務(wù)應(yīng)用程序。在第 5 部分,我還講解了減少 Web 請求數(shù)量、執(zhí)行時間、訪問時間和帶寬量的方法,這些方法都可以用來優(yōu)化 Web 服務(wù)應(yīng)用程序。

            在本文中,我介紹了負載應(yīng)用程序的某些問題如何影響了 Web 服務(wù)應(yīng)用程序間的互操作方式。文中包含了一個流量瓶頸的實例,導(dǎo)致該瓶頸的原因是:在特定期間有太多的訪問者基于業(yè)務(wù)流程發(fā)送了太多的請求到一個 Web 服務(wù)應(yīng)用程序。接著又講了如何從負載平衡技術(shù)中獲益。

            請記住,Web 請求與訪問者的請求是不同的。Web 請求的數(shù)量不僅依賴于訪問者的請求數(shù)量,也依賴于由訪問者請求生成的、已優(yōu)化的 Web 請求的類型和內(nèi)容。







            響應(yīng)遲緩

            為了更好地認清這種差異,請看接下來的這個實例。如果某個訪問者在將請求通過 Web 服務(wù)發(fā)送到一臺服務(wù)器后等了很久才得到回復(fù),那么該訪問者很可能為了獲得更快的響應(yīng)時間而轉(zhuǎn)向使用另一種 Web 服務(wù)或網(wǎng)站。該始發(fā)端 Web 服務(wù)將處理傳入的訪問者請求,以生成并優(yōu)化傳輸?shù)侥繕?Web 服務(wù)的 Web 請求。

            始發(fā)端 Web 服務(wù)響應(yīng)遲緩,可能表明目標服務(wù)器繁忙,或是沒有足夠的系統(tǒng)空間來處理多個訪問者請求(多線程處理)。處理這種負載問題的方法之一是平衡服務(wù)器間的負載,這樣訪問者就不會為得到答復(fù)而等待太久。這種技術(shù)稱為負載平衡。







            加快響應(yīng)

            平衡服務(wù)器間負載要優(yōu)于外包 Web 服務(wù),負載平衡技術(shù)不僅全面考慮到增加的服務(wù)器容量、改善的站點設(shè)計和使用獨立磁盤冗余陣列(Redundant Array of Independent Disk,RAID)的能力,而且也提供了處理預(yù)期高峰流量所需的帶寬。在服務(wù)器的長期運行中,它們會消耗更多的服務(wù)器資源。通過使用負載平衡技術(shù),我們有更好的機會來提高服務(wù)器的性能和可靠性,并同時減少帶寬量、執(zhí)行時間和訪問時間(假定服務(wù)器中包含故障轉(zhuǎn)移機制 )。

            由于上述原因,負載平衡技術(shù)成為了大多數(shù)公司在處理大流量時(尤其在高峰流量期間經(jīng)受服務(wù)器停滯時)的首選技術(shù)。這些公司希望更快地響應(yīng)用戶需求,從而在較短的時間內(nèi)完成更多的工作任務(wù)。

            您可以將負載路由到域名系統(tǒng)中不同的服務(wù)器主機地址,或者將一臺服務(wù)器要處理的工作總量分攤到兩臺或多臺服務(wù)器上。您不僅需要使用另外一臺服務(wù)器智能化地選擇出將工作分配給哪臺服務(wù)器,還需要使用故障轉(zhuǎn)移和備份服務(wù)將這些服務(wù)器聯(lián)合到一起,以防某臺服務(wù)器出現(xiàn)故障(尤其當服務(wù)器集散于不同地理位置時)。







            類比購物車

            作為一個類比,請把負載平衡服務(wù)器看為超市的 4 個付款臺。讓我們瞧瞧超市是如何在 4 個付款臺間實現(xiàn)“負載平衡”的。

            假設(shè)您排在 1 號付款臺前的長隊中,您可以粗略地估算出大概需要多久時間才能排到自己付款。如果您發(fā)現(xiàn)這條隊伍移動緩慢,而且此時看到一名收銀員走向 4 號付款臺打開機器準備工作,那您一定會推著購物車快速地跑到 4 號付款臺(請參見圖 1)。

            接著又有一名收銀員打開了 3 號付款臺,并揮手示意第一隊排在您前面的購物者到 3 號付款臺排隊。這些購物者當然會移到 3 號付款臺。2 號付款臺此時仍然保持關(guān)閉狀態(tài)。


            圖 1. 購物車的負載平衡
            購物車的負載平衡






            減少服務(wù)時間

            讓我們看看另一種負載平衡方式。如果您推著一輛滿滿的購物車,里面裝著您一家十口一個月的雜貨,您可能希望將貨物分給多個付款臺結(jié)帳。在沒有家人陪同的情況下,這種想法尤為強烈。您可以將購物車中的物品分為幾份,然后分從幾個清閑可用的付款臺結(jié)帳,這樣就減少了付款時間。

            雖然這在實際生活中是不可能的,但您可以使用負載平衡器實現(xiàn)類似的目的,它能把在線購物車(Web 服務(wù)應(yīng)用程序)的請求從繁忙的服務(wù)器上轉(zhuǎn)移到其他清閑可用的服務(wù)器上(請參見圖 2)。如果其他服務(wù)器通過優(yōu)化可以滿足服務(wù)需求,就沒必要再啟用新服務(wù)器。


            圖 2. 在線購物車請求的負載平衡
            在線購物車請求的負載平衡






            問題

            您該怎樣解決該問題?更快地跑到付款臺前(增加帶寬)?增加付款臺數(shù)量(增加服務(wù)器容量)?找其他人幫您買(外包)?這些方法都不適用。

            請您回答以下這些問題:

            • 您將要平衡哪種應(yīng)用程序的負載?
            • 在整個分布式網(wǎng)絡(luò)中,該應(yīng)用程序是否為長期運行?
            • 一臺服務(wù)器或一個服務(wù)器集群超時接收了多少請求?
            • 在高峰流量期間,需要多少流量和帶寬量?
            • 怎樣利用服務(wù)器平衡應(yīng)用程序負載?
            • 在不同時段,預(yù)計有多少訪問者?
            • 訪問者最多能夠發(fā)送多少請求?

            在您答完這些問題后,請與一名網(wǎng)絡(luò)管理員或系統(tǒng)管理員檢查和整理這些答案,以促進相互了解。然后使用某種算法、技術(shù)或工具開發(fā)一個負載平衡程序,實現(xiàn)將繁忙的服務(wù)器上的訪問者和 Web 請求重定向到清閑可用的服務(wù)器上。







            負載平衡技術(shù)

            負載平衡技術(shù)包括以下幾種:

            • 簡單路由
            • DNS Round Robin
            • 復(fù)雜算法
            • 智能路由

            由于實際工作中的流量需要按優(yōu)先級處理,所以在開發(fā) Web 服務(wù)應(yīng)用程序時,請考慮上述技術(shù)中的最后兩種技術(shù)。因為包含要求更快響應(yīng)的服務(wù)器和訪問者的分布式網(wǎng)絡(luò)正在不斷地擴張。由于前兩種技術(shù)不需要按流量的優(yōu)先級進行處理,所以我們將不在有關(guān)流量瓶頸的問題中討論它們。

            當您使用復(fù)雜算法時,分發(fā)請求是基于服務(wù)器性能、服務(wù)器使用的硬件種類和處理客戶優(yōu)先級的方法等等。這表明,最快的服務(wù)器將獲得更多具有最高客戶優(yōu)先級的請求。智能路由基于請求的內(nèi)容和(在始發(fā)端服務(wù)器發(fā)生故障時)流量重定向到另一臺服務(wù)器的方式。







            基于服務(wù)器的軟件

            雖然您可以使用軟件、硬件或兩者來達到負載平衡,但您最好還是在應(yīng)用程序服務(wù)器集群上使用基于服務(wù)器的軟件?;诜?wù)器的軟件的價格要遠低于基于硬件的專用服務(wù)器。硬件升級的價格要遠高于相應(yīng)軟件升級的價格。

            在將基于服務(wù)器的軟件添加到網(wǎng)絡(luò)中之前,請檢查網(wǎng)絡(luò)是否配置正確,負載平衡器是否“靈活”。“靈活”在這里的解釋是:雖然負載平衡器可能已為目前的 Web 服務(wù)應(yīng)用程序做好了充分的配置,但它還必須能夠通過擴展?jié)M足未來應(yīng)用程序的需求。

            IBM WebSphere Application Server 就是一款基于服務(wù)器的軟件,它在負載平衡和故障轉(zhuǎn)移中同時使用了復(fù)雜算法和智能路由。它的負載平衡器有能力根據(jù) Web 服務(wù)應(yīng)用程序的未來需求進行擴展。您需要為負載平衡建立一個服務(wù)器集群,并測試其故障轉(zhuǎn)移機制(請參閱參考資料)。

            面向多平臺的 WebSphere Edge Server V2.0 是另一款基于服務(wù)器的軟件。它專門設(shè)計用于改善服務(wù)器選擇、負載優(yōu)化和容錯。它還附帶了網(wǎng)絡(luò)地址轉(zhuǎn)換(Network Address Translation,NAT)和用于 Cisco CSS 交換機的 WebSphere Edge Server Consultant,并且支持內(nèi)核級的基于內(nèi)容路由(Content Based Routing,CSR)。(請參閱參考資料







            結(jié)束語

            Web 服務(wù)應(yīng)用程序的負載平衡需要提早計劃,以確定在高峰流量期間如何在服務(wù)器間平衡負載。在設(shè)計 Web 服務(wù)的過程中,請多與系統(tǒng)管理員交流負載平衡技術(shù)相關(guān)的問題。

            解決這些問題能使您更容易地創(chuàng)建負載平衡的 Web 服務(wù)應(yīng)用程序。您可以在 SOA 內(nèi)部(或跨 SOA)基于業(yè)務(wù)流程開發(fā) Web 服務(wù)和平衡 Web 服務(wù)負載。解決這些問題還能使管理員更容易地平衡 Web 服務(wù)應(yīng)用程序的負載,并確定在 SOA 中使用哪種負載平衡方法,以及能夠平衡多少應(yīng)用程序的負載。

            posted @ 2006-04-17 04:04 wsdfsdf 閱讀(161) | 評論 (0)編輯 收藏

            架構(gòu)設(shè)計師與SOA, 第 1 部分

            SOA(Service-Oriented Architecture),即面向服務(wù)的架構(gòu),這是最近一兩年出現(xiàn)在各種技術(shù)期刊上最多的詞匯了?,F(xiàn)在有很多架構(gòu)設(shè)計師和設(shè)計開發(fā)人員簡單的把SOA和Web Services技術(shù)等同起來,認為SOA就是Web Service的一種實現(xiàn)。本質(zhì)上來說,SOA體現(xiàn)的是一種新的系統(tǒng)架構(gòu),SOA的出現(xiàn),將為整個企業(yè)級軟件架構(gòu)設(shè)計帶來巨大的影響。本系列兩部分文章將根據(jù)作者自己的理解來幫助大家分析和了解什么是SOA架構(gòu),SOA將怎樣對企業(yè)系統(tǒng)架構(gòu)設(shè)計帶來積極的影響,什么是SOA架構(gòu)設(shè)計師的角色,以及SOA架構(gòu)師在設(shè)計SOA系統(tǒng)架構(gòu)時有哪些應(yīng)該特別注意的地方。

            1. 什么是架構(gòu)?什么是基于SOA的架構(gòu)?

            1.1 什么是架構(gòu)

            從架構(gòu)設(shè)計師的角度來看,架構(gòu)就是一套構(gòu)建系統(tǒng)的準則。通過這套準則,我們可以把一個復(fù)雜的系統(tǒng)劃分為一套更簡單的子系統(tǒng)的集合,這些子系統(tǒng)之間應(yīng)該保持相互獨立,并與整個系統(tǒng)保持一致。而且每一個子系統(tǒng)還可以繼續(xù)細分下去,從而構(gòu)成一個復(fù)雜的企業(yè)級架構(gòu)。

            當一名架構(gòu)設(shè)計師在構(gòu)建某個企業(yè)級的軟件系統(tǒng)時,除了要考慮這個系統(tǒng)的架構(gòu)以及其應(yīng)具有的功能行為以外,還要關(guān)注整個架構(gòu)的可用性,性能問題,容錯能力,可重用性,安全性,擴展性,可管理維護性,可靠性等各個相關(guān)方面。有的時候一名好的架構(gòu)設(shè)計師甚至還需要考慮所構(gòu)建的系統(tǒng)架構(gòu)是否合乎美學(xué)要求。由此我們可以看到,我們衡量一個好的架構(gòu)設(shè)計并不能只從功能角度出發(fā),還要考慮很多其他的因素,對任何一個方面的欠缺考慮都有可能為整個系統(tǒng)的構(gòu)建埋下隱患。

            1.2 什么是基于SOA的架構(gòu)

            SOA本身就是一種面向企業(yè)級服務(wù)的系統(tǒng)架構(gòu),簡單來說,SOA就是一種進行系統(tǒng)開發(fā)的新的體系架構(gòu),在基于SOA架構(gòu)的系統(tǒng)中,具體應(yīng)用程序的功能是由一些松耦合并且具有統(tǒng)一接口定義方式的組件(也就是service)組合構(gòu)建起來的。因此,基于SOA的架構(gòu)也一定是從企業(yè)的具體需求開始構(gòu)建的。但是,SOA和其它企業(yè)架構(gòu)的不同之處就在于SOA提供的業(yè)務(wù)靈活性。業(yè)務(wù)靈活性是指企業(yè)能對業(yè)務(wù)變更快速和有效地進行響應(yīng)、并且利用業(yè)務(wù)變更來得到競爭優(yōu)勢的能力。對企業(yè)級架構(gòu)設(shè)計師來說,創(chuàng)建一個業(yè)務(wù)靈活的架構(gòu)意味著創(chuàng)建一個可以滿足當前還未知的業(yè)務(wù)需求的IT架構(gòu)。

            利用基于SOA的系統(tǒng)構(gòu)建方法,如圖1中所示的一樣,一個基于SOA架構(gòu)的系統(tǒng)中的所有的程序功能都被封裝在一些功能模塊中,我們就是利用這些已經(jīng)封裝好的功能模塊組裝構(gòu)建我們所需要的程序或者系統(tǒng),而這些功能模塊就是SOA架構(gòu)中的不同的服務(wù)(services)。


            圖1
            圖1

            因此,SOA架構(gòu)本質(zhì)上來說體現(xiàn)了一種復(fù)合的概念:它不僅為一個企業(yè)中商業(yè)流程的組織和實現(xiàn)提供了一種指導(dǎo)模式,同時也為具體的底層service開發(fā)提供了指導(dǎo)。







            2. SOA架構(gòu)設(shè)計師的角色

            2.1 SOA架構(gòu)設(shè)計師應(yīng)該具備什么?

            談到SOA架構(gòu)設(shè)計師的角色,我們首先要了解架構(gòu)設(shè)計師應(yīng)具有的能力??傮w上來說,一個好的架構(gòu)設(shè)計師不僅應(yīng)該是一個成熟的,具有實際經(jīng)驗的并具有快速學(xué)習能力的人,而且他還應(yīng)該具有良好的管理能力和溝通能力。只有具備了必需的能力,架構(gòu)設(shè)計師才能在關(guān)鍵的時刻作出困難的決定,這就是一名架構(gòu)設(shè)計師應(yīng)該承擔的責任。從角色上來看,SOA 架構(gòu)師不僅會負責端到端的服務(wù)請求者和提供者的設(shè)計,并且會負責對系統(tǒng)中非功能服務(wù)請求的調(diào)研和表述。

            對于任何一名經(jīng)驗豐富的架構(gòu)設(shè)計師來說,不論他是采用基于傳統(tǒng)的架構(gòu)設(shè)計方法(基于J2EE架構(gòu)或者.NET架構(gòu))還是采用基于SOA的架構(gòu)設(shè)計方法來構(gòu)建一個企業(yè)級的系統(tǒng)架構(gòu),具有相關(guān)商業(yè)領(lǐng)域的知識對于架構(gòu)設(shè)計師來說都是必不可少的,架構(gòu)設(shè)計師往往可以通過實際的工作經(jīng)驗積累以及接受相關(guān)的專項培訓(xùn)來獲得這些商業(yè)領(lǐng)域的知識。除了具有相關(guān)商業(yè)領(lǐng)域的知識以外,一名合格的架構(gòu)設(shè)計師必須具有較廣泛的技術(shù)背景,這可能包括軟硬件,通信,安全等各個方面的知識。但這并不是意味著要成為一名架構(gòu)設(shè)計師就必須熟悉每一門具體技術(shù)的細節(jié),架構(gòu)設(shè)計師必須至少能對各種技術(shù)有一個整體上的了解,能夠熟知每種技術(shù)的特點以及優(yōu)缺點,只有這樣架構(gòu)設(shè)計師才能在特定的應(yīng)用場景下正確地選擇各種技術(shù)來設(shè)計企業(yè)整體架構(gòu)。

            2.2 什么是SOA架構(gòu)設(shè)計師的職責?

            那什么是企業(yè)級SOA架構(gòu)設(shè)計師的具體角色呢?什么是SOA架構(gòu)設(shè)計師與設(shè)計和開發(fā)人員之間的差別呢?相信這些都是使大家最容易產(chǎn)生迷惑的問題。舉個實際的例子來說,當構(gòu)建一個基于SOA架構(gòu)的系統(tǒng)的時候,針對一個具體的 service,系統(tǒng)設(shè)計人員主要應(yīng)該關(guān)注的是這個service能夠為外部用戶提供什么樣的服務(wù),也就是說系統(tǒng)設(shè)計人員關(guān)注的是這個service所提供的功能。而對于SOA架構(gòu)設(shè)計師來說,他們更關(guān)心的可能是當有一千個用戶同時調(diào)用這個 service的時候,什么會發(fā)生?也就是說架構(gòu)設(shè)計師關(guān)注的應(yīng)該是一些商業(yè)需求和服務(wù)級別(service-level)需求。所有的架構(gòu)設(shè)計師的角色都包含了在構(gòu)建一個系統(tǒng)的一開始就應(yīng)該盡量減少可能存在的技術(shù)風險。而技術(shù)風險一般指的是一切未知的、未經(jīng)證明的或未經(jīng)測試所帶來的風險。這些風險通常與服務(wù)級別(service-level)需求相關(guān),偶爾也會與企業(yè)具體的業(yè)務(wù)需求相關(guān)。無論是哪種類型的風險,在項目初期設(shè)計整體系統(tǒng)架構(gòu)的過程中更易于發(fā)掘這些風險,如果等到架構(gòu)實施時再發(fā)覺這些風險,那么很可能會致使大量的開發(fā)人員等在那里,直到這些風險被妥善解決。如果進一步的細化,我們可以看到SOA架構(gòu)設(shè)計師的主要任務(wù)包括對整個系統(tǒng)解決方案輪廓的構(gòu)建,需求分析,對體系結(jié)構(gòu)的整體決策,相關(guān)組件建模,相關(guān)操作建模,系統(tǒng)組件的邏輯和物理布局設(shè)計。

            作為SOA架構(gòu)設(shè)計師必須要能夠領(lǐng)導(dǎo)整個開發(fā)團隊,這樣才能保證設(shè)計和開發(fā)人員是按照構(gòu)建好的系統(tǒng)架構(gòu)來開發(fā)整個系統(tǒng)的,這一點十分的重要。這就要求一名架構(gòu)設(shè)計師不僅要有很好的技術(shù)洞察力,同時還要具有一定的項目管理和項目實施的能力。在系統(tǒng)開發(fā)的過程中,架構(gòu)設(shè)計師必須要有良好的溝通和表達能力,這就體現(xiàn)在由架構(gòu)設(shè)計師構(gòu)建的系統(tǒng)模型是否具有很好的可讀性和易理解性。如果由架構(gòu)設(shè)計師構(gòu)造出的系統(tǒng)模型不是很清晰的話,就可能會影響設(shè)計和開發(fā)人員對于整個系統(tǒng)架構(gòu)的理解。為了避免這種情況的出現(xiàn),定期由架構(gòu)設(shè)計師主持的開發(fā)團隊內(nèi)部討論是十分重要的。







            3. 構(gòu)建SOA架構(gòu)時應(yīng)該注意的問題

            3.1 原有系統(tǒng)架構(gòu)中的集成需求

            當架構(gòu)師基于SOA來構(gòu)建一個企業(yè)級的系統(tǒng)架構(gòu)的時候,一定要注意對原有系統(tǒng)架構(gòu)中的集成需求進行細致的分析和整理。我們都知道,面向服務(wù)的體系結(jié)構(gòu)是當前及未來應(yīng)用程序系統(tǒng)開發(fā)的重點,面向服務(wù)的體系結(jié)構(gòu)本質(zhì)上來說是一種具有特殊性質(zhì)的體系結(jié)構(gòu),它由具有互操作性和位置透明的組件集成構(gòu)建并互連而成?;赟OA的企業(yè)系統(tǒng)架構(gòu)通常都是在現(xiàn)有系統(tǒng)架構(gòu)投資的基礎(chǔ)上發(fā)展起來的,我們并不需要徹底重新開發(fā)全部的子系統(tǒng);SOA可以通過利用當前系統(tǒng)已有的資源(開發(fā)人員、軟件語言、硬件平臺、數(shù)據(jù)庫和應(yīng)用程序)來重復(fù)利用系統(tǒng)中現(xiàn)有的系統(tǒng)和資源。SOA是一種可適應(yīng)的、靈活的體系結(jié)構(gòu)類型,基于SOA構(gòu)建的系統(tǒng)架構(gòu)可以在系統(tǒng)的開發(fā)和維護中縮短產(chǎn)品上市時間,因而可以降低企業(yè)系統(tǒng)開發(fā)的成本和風險。因此,當SOA架構(gòu)師遇到一個十分復(fù)雜的企業(yè)系統(tǒng)時,首先考慮的應(yīng)該是如何重用已有的投資而不是替換遺留系統(tǒng),因為如果考慮到有限的預(yù)算,整體系統(tǒng)替換的成本是十分高昂的。

            當SOA架構(gòu)師分析原有系統(tǒng)中的集成需求的時候,不應(yīng)該只限定為基于組件構(gòu)建的已有應(yīng)用程序的集成,真正的集成比這要寬泛得多。在分析和評估一個已有系統(tǒng)體系結(jié)構(gòu)的集成需求時,我們必須考慮一些更加具體的集成的類型,這主要包括以下幾個方面:應(yīng)用程序集成的需求,終端用戶界面集成的需求,流程集成的需求以及已有系統(tǒng)信息集成的需求。當SOA架構(gòu)師分析和評估現(xiàn)有系統(tǒng)中所有可能的集成需求的時候,我們可以發(fā)現(xiàn)實際上所有集成方式在任何種類的企業(yè)中都有一定程度的體現(xiàn)。針對不同的企業(yè)類型,這些集成方式可能是簡化的,或者沒有明確地進行定義的。因而,SOA架構(gòu)師在著手設(shè)計新的體系結(jié)構(gòu)框架時,必須要全面的考慮所有可能的集成需求。例如,在一些類型的企業(yè)系統(tǒng)環(huán)境中可能只有很少的數(shù)據(jù)源類型,因此,系統(tǒng)中對消息集成的需求就可能會很簡單,但在一些特定的系統(tǒng)中,例如航運系統(tǒng)中的EDI(Electronic Data Interchange 電子數(shù)據(jù)交換)系統(tǒng),會有大量的電子數(shù)據(jù)交換處理的需求,因此也就會存在很多不同的數(shù)據(jù)源類型,在這種情況下整個系統(tǒng)對于消息數(shù)據(jù)的集成需求就會比較復(fù)雜。因此,如果SOA架構(gòu)師希望所構(gòu)建的系統(tǒng)架構(gòu)能夠隨著企業(yè)的成長和變化成功地繼續(xù)得以保持,則整個系統(tǒng)構(gòu)架中的集成功能就應(yīng)該由服務(wù)提供,而不是由特定的應(yīng)用程序來完成。

            3.2 服務(wù)粒度的控制以及無狀態(tài)服務(wù)的設(shè)計

            當SOA架構(gòu)師構(gòu)建一個企業(yè)級的SOA系統(tǒng)架構(gòu)的時候,關(guān)于系統(tǒng)中最重要的元素,也就是SOA系統(tǒng)中的服務(wù)的構(gòu)建有兩點需要特別注意的地方:首先是對于服務(wù)粒度的控制,另外就是對于無狀態(tài)服務(wù)的設(shè)計。

            服務(wù)粒度的控制

            SOA系統(tǒng)中的服務(wù)粒度的控制是一項十分重要的設(shè)計任務(wù)。通常來說,對于將暴露在整個系統(tǒng)外部的服務(wù)推薦使用粗粒度的接口,而相對較細粒度的服務(wù)接口通常用于企業(yè)系統(tǒng)架構(gòu)的內(nèi)部。從技術(shù)上講,粗粒度的服務(wù)接口可能是一個特定服務(wù)的完整執(zhí)行,而細粒度的服務(wù)接口可能是實現(xiàn)這個粗粒度服務(wù)接口的具體的內(nèi)部操作。 舉個例子來說,對于一個基于SOA架構(gòu)的網(wǎng)上商店來說,粗粒度的服務(wù)可能就是暴露給外部用戶使用的提交購買表單的操作,而系統(tǒng)內(nèi)部的細粒度的服務(wù)可能就是實現(xiàn)這個提交購買表單服務(wù)的一系列的內(nèi)部服務(wù),比如說創(chuàng)建購買記錄,設(shè)置客戶地址,更新數(shù)據(jù)庫等一系列的操作。雖然細粒度的接口能為服務(wù)請求者提供了更加細化和更多的靈活性,但同時也意味著引入較難控制的交互模式易變性,也就是說服務(wù)的交互模式可能隨著不同的服務(wù)請求者而不同。如果我們暴露這些易于變化的服務(wù)接口給系統(tǒng)的外部用戶,就可能造成外部服務(wù)請求者難于支持不斷變化的服務(wù)提供者所暴露的細粒度服務(wù)接口。而粗粒度服務(wù)接口保證了服務(wù)請求者將以一致的方式使用系統(tǒng)中所暴露出的服務(wù)。雖然面向服務(wù)的體系結(jié)構(gòu)(SOA)并不強制要求一定要使用粗粒度的服務(wù)接口,但是建議使用它們作為外部集成的接口。通常架構(gòu)設(shè)計師可以使用BPEL來創(chuàng)建由細粒度操作組成的業(yè)務(wù)流程的粗粒度的服務(wù)接口。

            無狀態(tài)服務(wù)的設(shè)計

            SOA系統(tǒng)架構(gòu)中的具體服務(wù)應(yīng)該都是獨立的、自包含的請求,在實現(xiàn)這些服務(wù)的時候不需要前一個請求的狀態(tài),也就是說服務(wù)不應(yīng)該依賴于其他服務(wù)的上下文和狀態(tài),即SOA架構(gòu)中的服務(wù)應(yīng)該是無狀態(tài)的服務(wù)。當某一個服務(wù)需要依賴時,我們最好把它定義成具體的業(yè)務(wù)流程(BPEL)。在服務(wù)的具體實現(xiàn)機制上,我們可以通過使用 EJB 組件來實現(xiàn)粗粒度的服務(wù)。我們通常會利用無狀態(tài)的Session Bean來實現(xiàn)具體的服務(wù),如果基于Web Service技術(shù),我們就可以將無狀態(tài)的Session Bean暴露為外部用戶可以調(diào)用的到的Web服務(wù),也就是把傳統(tǒng)的Session Facade模型轉(zhuǎn)化為了 EJB 的Web服務(wù)端點,這樣,我們就可以向 Web 服務(wù)客戶提供粗粒度的服務(wù)。

            如果我們要在 J2EE的環(huán)境下(基于WebSphere)構(gòu)建Web服務(wù),Web 服務(wù)客戶可以通過兩種方式訪問 J2EE 應(yīng)用程序??蛻艨梢栽L問用 JAX-RPC API 創(chuàng)建的 Web 服務(wù)(使用 Servlet 來實現(xiàn));Web 服務(wù)客戶也可以通過 EJB的服務(wù)端點接口訪問無狀態(tài)的Session Bean,但Web 服務(wù)客戶不能訪問其他類型的企業(yè)Bean,如有狀態(tài)的Session Bean,實體Bean和消息驅(qū)動Bean。后一種選擇(公開無狀態(tài) EJB 組件作為 Web 服務(wù))有很多優(yōu)勢,基于已有的EJB組件,我們可以利用現(xiàn)有的業(yè)務(wù)邏輯和流程。在許多企業(yè)中,現(xiàn)有的業(yè)務(wù)邏輯可能已經(jīng)使用 EJB 組件編寫,通過 Web 服務(wù)公開它可能是實現(xiàn)從外界訪問這些服務(wù)的最佳選擇。EJB 端點是一種很好的選擇,因為它使業(yè)務(wù)邏輯和端點位于同一層上。另外EJB容器會自動提供對并發(fā)的支持,作為無狀態(tài)Session Bean實現(xiàn)的 EJB 服務(wù)端點不必擔心多線程訪問,因為 EJB 容器必須串行化對無狀態(tài)會話 bean 任何特定實例的請求。 由于EJB容器都會提供對于Security和Transaction的支持,因此Bean的開發(fā)人員可以不需要編寫安全代碼以及事務(wù)處理代碼。 性能問題對于Web服務(wù)來說一直都是一個問題,由于幾乎所有 EJB 容器都提供了對無狀態(tài)會話 Bean 群集的支持以及對無狀態(tài)Session Bean 池與資源管理的支持,因此當負載增加時,可以向群集中增加機器,Web 服務(wù)請求可以定向到這些不同的服務(wù)器,同時由于無狀態(tài)Session Bean 池改進了資源利用和內(nèi)存管理,使 Web 服務(wù)能夠有效地響應(yīng)多個客戶請求。由此我們可以看到,通過把 Web 服務(wù)模型化為 EJB 端點,可以使服務(wù)具有更強的可伸縮性,并增強了系統(tǒng)整體的可靠性。







            4. 結(jié)束語

            本文簡要介紹了有關(guān)架構(gòu)設(shè)計師以及SOA架構(gòu)的知識,分析了SOA架構(gòu)師在設(shè)計SOA系統(tǒng)架構(gòu)時有哪些應(yīng)該特別注意的地方。

            本文的第二部分將向您介紹在構(gòu)建基于SOA架構(gòu)的企業(yè)系統(tǒng)時應(yīng)該怎樣保證所構(gòu)建的系統(tǒng)架構(gòu)能夠滿足系統(tǒng)中不同的服務(wù)級別需求。從架構(gòu)設(shè)計師的角度,SOA是一種新的設(shè)計模式,方法學(xué)。因此,SOA本身涵蓋了很多的內(nèi)容,也觸及到了系統(tǒng)整體架構(gòu)設(shè)計、實現(xiàn)、維護等各個方面。本文的內(nèi)容只是涉及到了有關(guān)于架構(gòu)方面的一部分內(nèi)容,希望能對廣大的SOA系統(tǒng)開發(fā)設(shè)計人員起到一定的幫助作用。

            posted @ 2006-04-17 04:03 wsdfsdf 閱讀(163) | 評論 (0)編輯 收藏

            僅列出標題
            共19頁: First 10 11 12 13 14 15 16 17 18 Last 
            国产精品久久久天天影视| 久久精品国产精品亚洲精品| 久久伊人五月天论坛| 久久久久久青草大香综合精品| 久久精品国产亚洲av瑜伽| 午夜精品久久久久久久无码| 亚洲午夜久久久久久噜噜噜| 久久ZYZ资源站无码中文动漫| 2020最新久久久视精品爱| 成人综合久久精品色婷婷| 久久99精品久久久久子伦| 久久久精品无码专区不卡| 色偷偷偷久久伊人大杳蕉| 久久99精品久久久久久不卡 | 亚洲va久久久噜噜噜久久| 好久久免费视频高清| 狠狠色丁香久久婷婷综合图片| 久久国产成人精品麻豆| 久久久久av无码免费网| 国产精品免费久久| 99久久国产综合精品麻豆| 国产香蕉久久精品综合网| 91精品国产91热久久久久福利 | 久久99精品久久久久久噜噜 | 久久久久免费精品国产| 亚洲午夜久久久影院伊人| 日日狠狠久久偷偷色综合0| 色综合久久88色综合天天| 久久久久亚洲AV片无码下载蜜桃| 看全色黄大色大片免费久久久| 国内精品久久久久久野外| 久久男人Av资源网站无码软件| 久久久久亚洲国产| 99久久综合国产精品免费| 一本色道久久88综合日韩精品 | 99久久精品免费| 久久中文字幕一区二区| 精品999久久久久久中文字幕| 久久香蕉国产线看观看精品yw| 国产成人久久精品一区二区三区 | 77777亚洲午夜久久多喷|