 |
|
2004 年 11 月 01 日 本文討論了基于服務(wù)的建模和架構的重要部分，以及構建面向服務(wù)體系結構（SOA）所需的分析和設計的關(guān)鍵活動(dòng)。作者著(zhù)重強調了選擇鑒別、制定和實(shí)現 服務(wù)所需的技術(shù)，它們的 流程和組合，以及實(shí)現和確保 SOA 所需的服務(wù)質(zhì)量的企業(yè)級 組件。 目前，關(guān)于由 Service-oriented Architectures（SOA）和它的 Web 服務(wù)實(shí)現所表現的時(shí)機有許多傳言 -- 有一些是有事實(shí)根據的，但是一些卻沒(méi)有什么事實(shí)依據。分析家已經(jīng)預言，博學(xué)者已經(jīng)聲稱(chēng)，教授已經(jīng)講演，公司已經(jīng)匆忙的賣(mài)他們的產(chǎn)品，作為 SOA 產(chǎn)品 -- 經(jīng)常失去 SOA 不是一個(gè)產(chǎn)品的要點(diǎn)。它是業(yè)務(wù)和 IT 之間的橋梁，通過(guò)一系列使用一些設計原則、模式和技術(shù)的依賴(lài)于業(yè)務(wù)的 IT 服務(wù)來(lái)實(shí)現。 ZDNet 最近報道說(shuō)，“Gartner 預言到了 2008 年，至少 60% 的企業(yè)將使用 SOA 作為創(chuàng )建任務(wù)苛刻的應用程序和過(guò)程的“指導原則”。 開(kāi)發(fā)和實(shí)現 SOA 有很大的需求。因此如果 SOA 不僅僅和產(chǎn)品和幫助實(shí)現它的標準相關(guān)（比如通過(guò) Web 服務(wù)），那么為了實(shí)現 SOA 你還需要什么附加的元素嗎？ 基于服務(wù)的建模需要其他的行為和構件，這些在傳統的基于對象的分析和設計（OOAD）中是不存在的?！?基于服務(wù)的分析和設計的元素”這篇文章描述了一些最初的原因，解釋了為什么你需要 OOAD 之外更多的內容。它同樣描述了業(yè)務(wù)流程管理或企業(yè)架構（EA）和 OOAD 為什么不是管理分析和設計的適當手段。同樣，在 IBM Redbook 中名為 “ 模式：Service-Oriented Architecture 和 Web Services”的文章中，我舉例說(shuō)明了基于服務(wù)的建模方法的主要活動(dòng)。 然而，你還需要重視一些額外的重要的需要考慮的事項。首先，目前的 OOAD 方法沒(méi)有定位 SOA 三個(gè)重要的元素： 服務(wù)， 流，和實(shí)現服務(wù)的 組件。你同樣需要可以明確定位鑒別、制定和實(shí)現服務(wù)所需的技術(shù)和過(guò)程，它們的流程和組合，以及實(shí)現和確保所需服務(wù)質(zhì)量的企業(yè)級組件。 第二，需要進(jìn)行范例的替換，以便更好的區分 SOA 的兩個(gè)關(guān)鍵角色之間的截然不同的需求：服務(wù)提供者和服務(wù)消費者。第三，假設為一個(gè)企業(yè)或者業(yè)務(wù)線(xiàn)構建的應用程序，現在必須被提升到一個(gè)供應鏈中使用，并且公開(kāi)給合作伙伴，這些合作伙伴可能組合、聯(lián)合和封裝應用程序到一個(gè)新的應用程序中。這是服務(wù)生態(tài)系統或者服務(wù)價(jià)值網(wǎng)的概念。 這是僅從“分布式對象”的一個(gè)微小的進(jìn)步。它是關(guān)于通過(guò)網(wǎng)絡(luò )作用創(chuàng )造的價(jià)值：例如，當合作伙伴利用了 Amazon.com 與 Google 搜索的聯(lián)合，并且與 eBay 服務(wù)結合在一起，來(lái)構建他們自己的混合解決方案?；蛘弋斅眯猩缟钊氲綑C票預訂系統，并且與汽車(chē)租賃公司以及賓館相互協(xié)調，更新他們的記錄并且將旅行計劃發(fā)送到你的電子檔案中。無(wú)論什么樣的應用程序，你如果想成功地創(chuàng )建 SOA，需要的都不僅僅是好的工具和標準。你需要一些規范的步驟來(lái)支持你的 SOA 生命周期；用來(lái)分析、設計、實(shí)現服務(wù)、流程和組件的技術(shù)。因此，對于任何對企業(yè)應用程序開(kāi)發(fā)感興趣的人來(lái)講，理解基于服務(wù)的建模和架構中包含的細節步驟是非常重要的。 在我詳細描述這些步驟以前，我們首先應理解你打算要做什么： 什么是 SOA，以及它看起來(lái)像是什么？在定義了 SOA 后面的概念和觀(guān)點(diǎn)以后，我將描述 SOA 的層和你如何去記錄每個(gè)層中的關(guān)鍵架構決策，這些層幫助你為 SOA 構建藍圖，這些 SOA 正是那些你試圖同一系列實(shí)現了 SOA 服務(wù)、流程和組件集成以及出現的項目、業(yè)務(wù)線(xiàn)、企業(yè)級成果和價(jià)值鏈所需要的。
Service-Oriented Architecture：概念模型 這個(gè)概念基于一種架構樣式，該樣式在三個(gè)主要參與者之間定義了交互模型：服務(wù)提供者，公布服務(wù)描述并且實(shí)現服務(wù)，服務(wù)消費者，他既可以使用統一資源標記符（URI）來(lái)直接使用服務(wù)描述，也可以在服務(wù)注冊中心來(lái)查找服務(wù)描述并且綁定和調用服務(wù)。服務(wù)代理提供和維護服務(wù)注冊中心，然而現在并沒(méi)有通用公共注冊中心。 圖 1 是一個(gè)顯示了這些關(guān)系的元模型。 圖 1：SOA 架構樣式的概念模型 
定義 SOA 的架構樣式描述了一系列模式和指導方針來(lái)創(chuàng )建 松耦合，依賴(lài)業(yè)務(wù)的服務(wù)，由于描述、實(shí)現和綁定之間關(guān)系的分離，為新業(yè)務(wù)跡象和機會(huì )提供了空前的靈活性。 SOA 是企業(yè)級的 IT 架構，用來(lái)按需連接資源。在 SOA 中，資源對于價(jià)值網(wǎng)、企業(yè)、業(yè)務(wù)線(xiàn)內的參與者時(shí)可用的（典型的是在一個(gè)企業(yè)內或多個(gè)企業(yè)之間跨越多個(gè)應用程序）。它由一系列依賴(lài)業(yè)務(wù)的 IT 服務(wù)組成，這些服務(wù)共同滿(mǎn)足了組織的業(yè)務(wù)流程和目標。你可以將這些服務(wù)設計成合成的應用程序并且通過(guò)標準協(xié)議來(lái)調用它們，如下面的 圖 2所示。 服務(wù)是一種有具體服務(wù)描述的軟件資源（可發(fā)現）。服務(wù)消費者可以搜索、綁定和調用服務(wù)描述。服務(wù)提供者實(shí)現服務(wù)描述的功能并且向服務(wù)消費者提供所需的服務(wù)質(zhì)量。理論上服務(wù)應該統一由公布的方針來(lái)管理，并且因此支持動(dòng)態(tài)的 可配置架構樣式。 圖 2: SOA 的屬性 靈活的業(yè)務(wù)通過(guò)靈活的 IT 系統可以實(shí)現，主要通過(guò)接口、實(shí)現和 SOA 提供的綁定（協(xié)議）的分離，基于新業(yè)務(wù)需求，允許在及時(shí)給定的點(diǎn)延期 選擇 服務(wù)提供者，（功能和非功能（例如，性能、安全、可伸縮性等）需求）。 你可以在內部業(yè)務(wù)單元之間或者在業(yè)務(wù)伙伴之間的價(jià)值鏈之間以 不規則的實(shí)現模式來(lái)重用此服務(wù)。不規則的實(shí)現引用了架構樣式的能力來(lái)在他的交互模型中通過(guò)合成的方式來(lái)應用與參與者關(guān)聯(lián)的模式和角色。你可以在架構中的一層上應用它，也可以在貫穿企業(yè)架構的多個(gè)層上來(lái)應用它。在項目之間，它可以通過(guò)統一的、概念上可升級的方式在價(jià)值鏈內部的業(yè)務(wù)單元和業(yè)務(wù)伙伴之間。
在本文中，我介紹了鑒定、指定和實(shí)現的高級別的行為和一些基于服務(wù)建模的構件?；诜?wù)的建模是基于服務(wù)的分析和設計（SOAD）過(guò)程，來(lái)建模、分析、設計和生產(chǎn)依賴(lài)業(yè)務(wù)分析、過(guò)程和目標的 SOA。 首先我將看一下你想要構建什么，也就是 SOA 和它的層。接下來(lái)我將通過(guò)討論創(chuàng )建 SOA 所需主要的活動(dòng)和技術(shù)來(lái)描述如何構建 SOA。 作為一個(gè)示例，我們假設你正在開(kāi)發(fā)一個(gè)項目，并且目標是將一部分具有自服務(wù)帳目系統的銀行業(yè)務(wù)線(xiàn)移植到 SOA上。 為了移植到 SOA，你需要一些超出服務(wù)建模的附加元素。它們包括：
上面的關(guān)于移植到 SOA 和實(shí)現以后附加活動(dòng)的討論應該得到它們自己的文章，本系列中我將在隨后的列中接觸到這個(gè)。目前，讓我們假設你為項目定義了范圍，并且決定了集中在什么地方：已經(jīng)定義了一個(gè)焦點(diǎn)，用來(lái)將現有的系統或服務(wù)轉化到一系列新的系統和服務(wù)?，F在你可以開(kāi)始基于服務(wù)建模來(lái)構建你的基于服務(wù)的架構。
SOA 的一個(gè)抽象觀(guān)點(diǎn)將它描述為與業(yè)務(wù)過(guò)程結合在一起的合成服務(wù)的部分分層架構。 圖 3 呈現了這種類(lèi)型的架構。 服務(wù)和組建之間的關(guān)系是，企業(yè)級的組件（大粒度的企業(yè)或者業(yè)務(wù)線(xiàn)組件）實(shí)現該服務(wù)并且負責提供它們的功能和維持它們的服務(wù)質(zhì)量。通過(guò)組合這些公開(kāi)的服務(wù)到合成的應用程序，就可以支持業(yè)務(wù)過(guò)程流。綜合的架構通過(guò)使用 Enterprise Service Bus（ESB）支持這些服務(wù)、組件和流程的路由、中介和轉化。為了服務(wù)質(zhì)量和非功能性的需求，必須監視和管理已經(jīng)部署的服務(wù)。 圖 3：SOA 層 對于每一層，你都必須做設計和架構決定。因此，為了幫助用文件說(shuō)明你的 SOA，你可能應該創(chuàng )建文檔，由每個(gè)層相應的部分所組成。 這里是為你的 SOA 架構文檔設計的模板：
層 1：操作系統層。本層包含現有的自定義構建的應用程序，也叫做 遺留系統，包含現有的 CRM 和 ERP 打包應用程序，以及 較舊的基于對象的系統實(shí)現，還有業(yè)務(wù)智能應用程序。SOA 的復合層架構可以利用現有的系統并且用基于服務(wù)的集成技術(shù)來(lái)集成它們。 層 2：企業(yè)組件層。本層由那些負責實(shí)現功能和保持公開(kāi)服務(wù) QoS 的企業(yè)組件組成。這些特殊的組件是企業(yè)和業(yè)務(wù)單元級支持的企業(yè)資產(chǎn)的受管理和控制的集合。 同企業(yè)范圍資產(chǎn)一樣，他們通過(guò)架構最佳實(shí)踐應用程序來(lái)負責確保 SLAs 的一致。大多數情況下，本層使用基于容器的技術(shù)，比如實(shí)現組件、負載均衡、高可用性和工作量管理的應用服務(wù)器。 層 3：服務(wù)層。業(yè)務(wù)選擇來(lái)支持和公開(kāi)的服務(wù)處在這一層。它們可以被 發(fā)現或者直接靜態(tài)綁定，接下來(lái)被調用，或者可能的話(huà)，編排到合成服務(wù)中。這個(gè)服務(wù)公開(kāi)層同樣提供了獲取企業(yè)范圍組件，業(yè)務(wù)單元特定組件，以及有些情況下，特定項目組建的機制，并且以服務(wù)描述的形式具體化了他們的接口子集。因此，企業(yè)組件使用它們接口提供的功能在運行時(shí)提供服務(wù)實(shí)現。在這一層的接口公開(kāi)為一個(gè)服務(wù)描述，在這層中他們被公開(kāi)以提供使用。他們可以獨立存在或者作為合成服務(wù)。 層 4：業(yè)務(wù)過(guò)程合成或編排層。第三層中公開(kāi)的服務(wù)的合成和編排在這一層中被定義。通過(guò)配合、編排，服務(wù)被綁定成一個(gè)流程，并且從而作為單獨的應用程序而共同作用。這些應用程序支持特殊的用例和業(yè)務(wù)過(guò)程。這里，可視的流程合成工具，比如 IBM? WebSphere? Business Integration Modeler 或者 Websphere Application Developer Integration Edition，都可以用來(lái)設計應用程序流程。 層 5：訪(fǎng)問(wèn)或表現層。盡管這一層經(jīng)常超出了圍繞 SOA 討論的范圍，但是它卻變得越來(lái)越有意義。在這里我描述它因為標準越來(lái)越集中，比如用于 Remote Portlets Version 2.0 的 Web 服務(wù)和其他技術(shù)，這些技術(shù)追求在應用程序接口或者表現層來(lái)利用 Web 服務(wù)。你可以把它作為將來(lái)的層用來(lái)滿(mǎn)足將來(lái)的解決方案的需求。注意到以下這兩點(diǎn)是非常重要的：SOA 將用戶(hù)接口從組件中分離出來(lái)；最終你需要提供從訪(fǎng)問(wèn)路線(xiàn)到服務(wù)或者合成服務(wù)的端到端解決方案。 層 6：集成（ESB）。這一層使服務(wù)可以集成，通過(guò)引入一系列可靠的性能的集合，比如智能路由，協(xié)議中介和其他轉化機制，經(jīng)常被描述為 ESB（參閱 參考資料）。Web Services Description Language（WSDL）制定了綁定，其包含提供服務(wù)的地址。另一方面，ESB 為集成提供了位置獨立機制。 層 7：QoS。這一層提供了監視，管理和維持諸如安全，性能和可用性等 QoS 的能力。這是一個(gè)通過(guò) sense-and-respond 機制和監測 SOA 應用程序健康的工具來(lái)進(jìn)行的后臺處理過(guò)程，包括 WS-Management 和其他相關(guān)協(xié)議的所有的重要的標準實(shí)現以及為 SOA 實(shí)現服務(wù)質(zhì)量的標準。
通過(guò)什么步驟來(lái)進(jìn)行基于服務(wù)的建模和架構 本節描述了如何利用遺留的投資，來(lái) 聯(lián)合自頂向下的，業(yè)務(wù)驅動(dòng)的手段和自底向上的手段。 基于服務(wù)的建模手段提供了建模、分析、設計技術(shù)和活動(dòng)來(lái)定義 SOA 的基礎。它通過(guò)在 SOA 的每一層定義元素以及在每一層作嚴格的架構決策來(lái)起到幫助作用。它通過(guò)聯(lián)合服務(wù)鑒別的自頂向下、業(yè)務(wù)驅動(dòng)方式和通過(guò)利用遺留資產(chǎn)和系統引導服務(wù)鑒別來(lái)實(shí)現這一點(diǎn)。 這樣，高級別的業(yè)務(wù)過(guò)程功能性為大粒度的服務(wù)更加的具體化。小粒度的服務(wù) -- 這些可以幫助實(shí)現高級別的服務(wù) -- 通過(guò)檢查遺留功能性和決定如何創(chuàng )建適配器、封裝器，或者組合遺留系統來(lái)具體化系統內經(jīng)常調用的期望功能性可以來(lái)鑒別。 最后，使用 針對服務(wù)的建模，你使用 跨部分手段來(lái)削減候選的可能已經(jīng)被確定的服務(wù)的絕對數量。一個(gè)比較明智的手段應該是首先按照自頂向下來(lái)做，接下來(lái)進(jìn)行目標服務(wù)建模，最后是自底向上的現有資產(chǎn)的遺留分析。消息是：你將項目的范圍定義至一個(gè)可管理、實(shí)現的集合越快，你就能更快的通過(guò)聚焦在關(guān)鍵服務(wù)來(lái)公開(kāi)組成 SOA 基礎的服務(wù)描述來(lái)實(shí)現價(jià)值。 這個(gè)功能性業(yè)務(wù)需求和遺留系統中現有投資利用的結合，為那些想要快速贏(yíng)得和移植他們的企業(yè)到一個(gè)現代的 SOA 的組織提供了有效的解決方案。通過(guò)基于服務(wù)的集成的軟件應用程序的聯(lián)合因此變得具備可能性。 基于服務(wù)的集成是 Enterprise Application Integration（EAI）的一個(gè)進(jìn)化，在 EAI 中，所有的連接通過(guò)位置透明的 ESB 概念被基于標準的鏈接替換，并提供了一系列靈活的路由、中介和轉化能力。
迄今為止，我已經(jīng)通過(guò)描述 SOA 設定了階段。我同樣展示了要想構建 SOA，你需要在你 SOA 的每個(gè)層中做關(guān)鍵架構決策，并且你的設計必須反映一系列依賴(lài)業(yè)務(wù)的服務(wù)和關(guān)于他們如何通過(guò)編排來(lái)合成到應用程序的決策。 與對象不同，你在 SOA 中需要考慮兩個(gè)觀(guān)點(diǎn)；他們是服務(wù)消費者和服務(wù)提供者。服務(wù)代理目前不是主流，并且在后面的部分終將被涉及到。 SOA 的設計策略并不從“自底向上”開(kāi)始，這是 Web 基于服務(wù)途徑常有的事情。你必須記住，SOA 更加有戰略意義，并更加依賴(lài)于業(yè)務(wù)。Web 服務(wù)是 SOA 的巧妙實(shí)現。許多關(guān)鍵的活動(dòng)和決策存在不僅僅影響集成架構，而且還影響企業(yè)和應用程序架構。他們包含兩個(gè) 圖 4 中描述的消費者和提供者的活動(dòng). 圖 4：基于服務(wù)建模的活動(dòng) 圖 4顯示了通過(guò)提供者和消費者的每個(gè)角色來(lái)管理的活動(dòng)。注意，提供者的活動(dòng)是消費者活動(dòng)的父集（例如，提供者同樣參與服務(wù)鑒別、分類(lèi)等）。在許多情況下，角色的區別來(lái)自如下的事實(shí)，消費者指定他們想要的服務(wù)，經(jīng)常的搜索它，并且一旦他們確信和他們尋找的服務(wù)規范相匹配，并且是由服務(wù)提供者提供，他們就會(huì )根據需要綁定和調用服務(wù)。提供者需要依次發(fā)布他們想要支持的服務(wù)；即在功能方面，更重要的是在消費者所需的 QoS 方面。這個(gè)在消費者和提供者之間的隱含的契約可能在 SLA 方面成熟為明確的契約；自動(dòng)的或者通過(guò)業(yè)務(wù)和合法區域來(lái)處理。 上面描述的活動(dòng)可以被描述為在基于服務(wù)的建模和架構方法內流動(dòng)，如下面的 圖 5 所示。 圖 5：基于服務(wù)的建模和架構方法 基于服務(wù)的建模和架構過(guò)程包含三個(gè)主要的步驟：服務(wù)，組件和流程（典型地，服務(wù)的編排）的鑒別，指定和實(shí)現。 這個(gè)過(guò)程由域分解、現有資產(chǎn)分析和目標服務(wù)建模的自頂向下、自底向上、中間向外技術(shù)的聯(lián)合組成。在 自頂向下視圖中，業(yè)務(wù)用例的藍圖提供了業(yè)務(wù)服務(wù)的規范。這個(gè)自頂向下的過(guò)程作為 域分解來(lái)被引用，域分解由業(yè)務(wù)領(lǐng)域到它的功能區域和子系統的分解組成，包含它的流程或過(guò)程分解成過(guò)程、自過(guò)程和高級別業(yè)務(wù)用例。很多情況下，這些用例是公開(kāi)在企業(yè)邊緣的業(yè)務(wù)服務(wù)，或者在貫穿業(yè)務(wù)線(xiàn)企業(yè)邊界內所用的非常好的候選。 在過(guò)程的 從下到上的部分或者 現有系統分析中，現有的系統被分析和選擇作為可行的候選，來(lái)為支持業(yè)務(wù)過(guò)程的底層服務(wù)功能性實(shí)現提供低消耗的解決方案。在這個(gè)過(guò)程中，你分析和利用了來(lái)自遺留和打包應用程序的 API、事務(wù)和模塊。在有些情況下，為了支持服務(wù)的功能重新模塊化現有的資產(chǎn)需要遺留系統的組件化。 中間向外視圖由 目標服務(wù)建模組成，來(lái)驗證和發(fā)現自頂向下或自底向上的服務(wù)鑒別手段中沒(méi)有捕捉到的其他服務(wù)。它將服務(wù)連結到目標和子目標、關(guān)鍵性能指示和尺度。 這個(gè)活動(dòng)在服務(wù)被指定時(shí)開(kāi)始。將服務(wù)分級為服務(wù)層次是非常重要的，反映了服務(wù)的復合或者不規則的本性：服務(wù)可以也應該由良好粒度的組建和服務(wù)組成，分級幫助決定合成和分層，以及基于層次的相互依賴(lài)服務(wù)的協(xié)同構建。同樣，它幫助減輕服務(wù)增值綜合癥，這種癥狀中，越來(lái)越多的小粒度的服務(wù)被定義、設計和部署，卻缺乏控制，導致了主要的性能、可伸縮性和管理問(wèn)題。更加重要的是，服務(wù)增值未能提供服務(wù)，這些服務(wù)對業(yè)務(wù)是非常有用的。 這個(gè)活動(dòng)獲取上面域分解過(guò)程中發(fā)現的子系統，并且指定子系統之間的相互依賴(lài)和流程。它同樣將域分解過(guò)程中鑒別的用例作為子系統接口上公開(kāi)的服務(wù)。子系統的分析包含創(chuàng )建對象模型來(lái)表現內部工作方式，以及所包含的公開(kāi)服務(wù)并且實(shí)現它們的子系統設計。這時(shí)，“子系統”的設計結構將實(shí)現為大粒度組件實(shí)現構造，在下面的活動(dòng)中實(shí)現服務(wù)。 在下面的主要活動(dòng)中，實(shí)現服務(wù)的組件的細節將指定：
服務(wù)分配包括分派服務(wù)到目前鑒別的子系統。這些子系統具有實(shí)現了他們所公布的功能的企業(yè)組件。你經(jīng)常會(huì )簡(jiǎn)單化假定，子系統同企業(yè)組件有一對一的聯(lián)系。 結構化組件在你使用模式來(lái)構造企業(yè)組件時(shí)會(huì )通過(guò)以下幾點(diǎn)的聯(lián)合的形式出現：
這個(gè)步驟指出實(shí)現給定服務(wù)的軟件必須被選擇或者自定義構建。其他可用的選項包括使用 Web 服務(wù)來(lái)集成、轉化、訂閱和外購不同功能。在這個(gè)步驟中，你決定哪個(gè)遺留系統模塊用來(lái)實(shí)現給定的服務(wù)，以及哪個(gè)服務(wù)將從基礎來(lái)構建。服務(wù)的其他實(shí)現決策不同于業(yè)務(wù)功能包括：服務(wù)的安全、管理和監視。 事實(shí)上，項目趨向于利用任意數量的相應的努力來(lái)滿(mǎn)足關(guān)閉的機會(huì )窗口。因此，我推薦并行的管理三個(gè)流。 自頂向下的域分解（過(guò)程建模和分解，基于變更的分析，方針和業(yè)務(wù)規則分析，領(lǐng)域特定行為建模（使用語(yǔ)法和圖表））是同供組件化（模塊化）和服務(wù)公開(kāi)候選的現有遺留資產(chǎn)的分析并行控制。為了獲得項目背后的業(yè)務(wù)意圖和使服務(wù)同業(yè)務(wù)意圖密切合作，目標服務(wù)建?？梢詠?lái)控制。
本文中，我以基于服務(wù)架構、它的層和架構決策的相關(guān)類(lèi)型的基礎知識來(lái)開(kāi)始。接下來(lái)，我通過(guò)一種方法，描寫(xiě)了基于服務(wù)建模的活動(dòng)，以及從服務(wù)消費者和提供者角度來(lái)看活動(dòng)的重要性（服務(wù)代理將在后面的文章中涉及到）。這種方式為決定基于服務(wù)架構的三個(gè)基礎方面提供了在分析和設計活動(dòng)方面詳細的指導：服務(wù)，流程和實(shí)現服務(wù)的組件。我還描述了一個(gè)模板，你可以用它來(lái)在 SOA 的每個(gè)層上為你的架構進(jìn)行決策。 我提到了，對于服務(wù)鑒別，自頂向下、自底向上和跨部分、目標模型分析三種手段的結合非常重要。接下來(lái)我關(guān)注了一下服務(wù)指定和實(shí)現的主要活動(dòng)。 這一系列的下一篇文章中，我將應用該方法到帳戶(hù)管理的空領(lǐng)域中，并且用例子來(lái)描述每個(gè)步驟。除鑒別、指定和實(shí)現之外，我還將討論基于服務(wù)建模手段的其余活動(dòng)，包含用來(lái)支持完整的 SOA 生命周期的部署、監視、管理和控制。 作者希望象下面這些尊敬的同事和朋友致謝，感謝他們寶貴的建議和反饋（無(wú)特定順序）：Luba Cherbakov，Kerrie Holley，George Galambos，Sugandh Mehta，David Janson，Shankar Kalyana，Ed Calunzinski，Abdul Allam，Peter Holm，Krishnan Ramachandran，Jenny Ang，Jonathan Adams，Sunil Dube，Ralph Wiest，Olaf Zimmerman，Emily Plachy，Kathy Yglesias-Reece，以及 David Mott。
| ||||||||||||||||||||||||||||||||||||
聯(lián)系客服
