【文章內容簡介】 這些需求寄希望于新的體系結構。而在第二部分中，我們將研究服務的類型，構造一個基于服務的組件的應用程序框架和一些將來的計算環(huán)境，這些環(huán)境將使得 SOA 的開發(fā)更加勢在必行。參考資料 查閱 IBM developerWorks Web services 專區(qū) 來獲得 Web 服務白皮書和工具。 要查找 Web 服務和面向服務的體系結構方面的客戶項目案例，請參閱 IBM jStart Web 站點。 閱讀文章 Best practices for determining the proper level of granularity of services within a SOA（developerWorks，2003年10月）。 閱讀 Accessing CICS transactions as services within a SOA（IBM）。 Zackman Framework for Enterprise Architecture 將是這一系列關于 SOA 的文章中另一篇的主題。在 Zachman 框架以外，還開發(fā)了幾個主要的體系結構框架，其中包括： o 聯邦企業(yè)體系結構框架（FEAF） o 用于命令、控制、通信、計算機、智能、監(jiān)視和偵查（C4ISR）體系結構 o 開放組織體系結構框架（TOGAF）關于作者 Kishore Channabasavaiah 獲得了印度 Bangalore 大學機械工程學士學位。他現在是 IBM 全球服務芝加哥創(chuàng)新中心（Chicago Innovation Center of IBM Global Services）的執(zhí)行架構師。他專門從事 Web 服務和端到端解決方案的研究，為電子商務的集成解決方案提供思想指導。目前，他側重于 Web 應用程序的解決方案、技術解決方案評論、Web 服務、面向服務的體系結構和普及計算（Pervasive Computing）。您可以通過 kishorec@ 與 Kishorec 聯系。Kerrie Holley 獲得了 DePaul 大學數學文學學士學位和法學博士學位。他現在是 IBM Global Services 的杰出工程師和電子商務集成解決方案首席架構師。在電子商務集成解決方案方面，他提供 Web 服務實踐的思想領導。他目前主要從事軟件工程最佳實踐、端到端高級 Web 開發(fā)、自適應的企業(yè)體系結構、體系結構評論、Web 服務和面向服務的體系結構。您可以通過 klholley@ 與 Kerrie 聯系。Edward M. Tuggle, Jr. 獲得了俄克拉何馬州大學數學理學士學位，目前是 IBM Software Group jStart Emerging Technology Solutions team 的高級軟件工程師。他在 IBM 從事操作系統(tǒng)設計、開發(fā)和維護工作有23年，在過去的6年里研究的是 Java 技術和其他新興技術?，F在，Edward 專攻 Web 服務和面向服務的體系結構。您可以通過 b391747@ 與 Edward 聯系。遷移到面向服務的體系結構，第 2 部分英文原文內容：服務的性質解決前面的問題體系結構中的集成需求部署面向服務的體系結構的好處未來 —— 新模型，新需求總結參考資料關于作者相關內容：Web Services 體系結構和最佳實踐遷移到面向服務的體系結構，第 1 部分在 Web 服務專區(qū)還有：教學工具與產品所有的文章簡介和概述（繼續(xù)） 級別：中級Kishore Channabasavaiah，執(zhí)行架構師，IBM Global ServicesKerrie Holley，杰出工程師，電子商務集成解決方案首席架構師，IBM Global ServicesEdward M. Tuggle, Jr.，高級軟件工程師，IBM Software Group2004 年 1 月這是一系列文章的第二部分。這一系列文章旨在幫助您更好地理解面向服務的體系結構（SOA）的價值，制訂出一個實際的計劃來評估您現在的基礎架構，并把它轉變成一個真正的面向服務的體系結構。其目的在于，當您讀完本文時，您將理解為什么聲稱 SOA 是把現有資產帶到未來的最好的平臺，同時也使得迅速而正確地開發(fā)未來的程序成為可能。另外，您將對在計劃這樣一次遷移的過程中主要考慮的事項有更好的理解。這一系列文章的第一部分描述了推動考慮 SOA 的動力和這樣的一個體系結構的需求?，F在，第二部分將繼續(xù)討論服務和接口。服務的性質什么是服務？如前所述，在一個典型的業(yè)務環(huán)境里，服務意味著業(yè)務函數、業(yè)務事務和系統(tǒng)服務。業(yè)務函數可能是 getStockQuote、getCustomerAddress 或 checkCreditRating。業(yè)務事務可能是 mitInventory、sellCoveredOption 或 scheduleDelivery。系統(tǒng)服務可能是 logMessageIn、getTimeStamp 或 openFile。請注意各種類型服務之間的區(qū)別。從應用程序的角度來看，業(yè)務函數實際上是原子的非系統(tǒng)函數。業(yè)務事務很像是調用應用程序的簡單函數，但是它們可能是作為自己的事務的上下文所包含的復合函數來實現的。它們可能包括多個底層函數，這些底層函數對調用者來說是透明的。系統(tǒng)函數是能夠從諸如 Windows 或者 Linux 這樣的特定平臺中抽象出來的廣義函數。應用程序框架可能提供像 openFile 這樣的廣義函數來有效地虛擬化數據源，從而可以在不考慮真實數據源的類型和位置的情況下使用這類函數。 這看起來像人為地規(guī)定服務之間的區(qū)別；您可以從應用程序的角度斷言，所有的服務都是原子的，而與它是業(yè)務服務還是系統(tǒng)服務無關。做出這樣的區(qū)別僅僅是為了引入粒度這個重要的概念。將業(yè)務程序分解成服務不僅僅是一個抽象的過程；它具有非常真實的現實含義。根據定義，服務可能是低級（細粒度的）函數，也可能是復雜的高級（粗粒度的）函數，并且在性能、靈活性、可維護性和可重用性方面都有很現實的折衷選擇。定義服務的過程通常是在更大的作用域（應用程序框架的作用域）內完成的。這才是必須做的實際工作：也就是開發(fā)基于組件的應用程序框架，其中，服務定義為一組可重用的組件，而這些組件又可以用來構建新的應用程序或集成現有的軟件資產。 現在，可以獲得很多這樣的框架；在 IBM，一些像 EWA、JADE 和 Struts （來自 Jakarta）的這樣的框架正用在客戶集成場景中。以 EWA （讀作“Eva”） 為例（它來自 IBM Software Group Advanced Technology Solutions 組），在一個較高的層次上，框架看起來如 圖 1 所示。在這個框架中，配置定義了一個應用程序，描述了該應用程序的組件以及它們調用的順序和方法。以源中立的方式接收輸入并將其傳送到應用程序。因此，舉例來說，用現有的 ATM 訪問將因特網連接添加到一個銀行應用