第1章：藍月亮
商業和市場對軟件系統新的功能性需求看起來無比貪婪。我曾經聽到一個產品經理在一個產品發布會後河我說：“這個產品可以做客戶想做的任何事情；下一個版本沒什麼可設計的。我們都會老家吧”。發布日期到來的時候，你最可能聽到的就是，“不，這個版本不干不了這個，我們或許可以再下一個版本之後加上這個功能。”在軟件的世界裡，這些功能性需求偶然的集中到一起，遠處看來就貌似一個通用的需求。有時候，其中一個普通的需求就產生了一個攜帶滿足這個通用需求諾言的新的通用概念。一旦時機到來，對新技術的興趣會推動一個新技術的發展，這個新技術可以使得開發者把這個概念應用到他們的應用中，因此進而可以滿足那個通用需求。每次這種百年一遇的時機，通用需求，通用概念和隨之而來的新技術如此巨大和重要，迫使我們不得不重新考慮軟件的設計。我不確定你是否注意到這些，但是微軟WCF的發布影意義重大。是我們應該重新思考如何設計和構造分布式應用的時候了。
注釋：The moon is Blue,月亮是藍色的：這個話需要了解西方國家的文化背景，這個表示千載難逢或者百年一遇的事情。通常是極少有的影響巨大的事情，具有化時代的疑義，比如相對論的提出。人類第一次登月等等。作者使用這個標題來強調WCF的出現具有深遠的意義。詳細參才文章末尾文章的解釋。
普遍需求：
絕大大部分來說，商業不再去尋求能夠解決他們所有計算問題的神奇應用系統。隨著時間推移，許多軟件廠商，比如打的企業資源規劃（ERP）和中間件廠商已經不同程度地成功賣出了這種系統。商業，然而，提出了如此多的需求，以至於沒有那個軟件廠商的產品可以滿足全部需求。此外，隨著商業的發展，它們經常需要概念自己的基礎結構和流程去適應成長。軟件可以在公司100人規模的時候運行，然後卻不一定能在1000個員工的時候正常工作。當考慮並購和收購的時候問題會更加復雜。遷移一個收購的公司去使用總公司的軟件系統式非常痛苦、乏味和代價昂貴的。
結果是大部分公司的計算架構包含的是一個既能滿足部門級又能滿足企業級需求的應用混合系統。這個混合經常被稱作非主流架構。最可能是就是這些系統是由內部或者外部的供應商開發，去解決特定的業務問題，並且每個系統都經常管理隔離的信息。偶爾這些非主流架構也被標准化運行在特定的硬件、操作系統和平台上，但是這種標准化通常難以推廣。更多的是，這些企業內的計算系統經常由獨立的、隔離的應用系統組成，它們運行在不同的硬件，操作系統和平台，為了改進企業的業務（但願）。如果你看到右邊的圖片，就也許會記起 M. C. Escher的繪畫。
從商業角度來看，應用系統很少會獨立存在，正如他們之間緊密的聯系，在某些形態和樣子上去幫助商業更加高效地運轉。結果，一些人免不了要求，以削減成本、增加銷售、或者變相的要求：“我想在應用系統A裡知道系統B的一些東西。”這種需求的變現說法就是連接。
連接很顯然有兩種方式：應用-應用和應用-企業。只不過，應用-應用是連接兩個應用，比如應收賬款系統和運輸系統。一個應用-企業的例子就是航線想發布每次一個飛機起飛和降落信息給所有關心它的應用系統。這些信息都會深遠地影響企業，包括運營，員工調度，和質量保證。人、市場和商業現在的需求關鍵點就是他們系統之間的連接，這已經非常普遍。不管你為軟件廠商還是公司內部IT部門工作，你很可能已經看過這種系統互聯的要求。如果這個是你第一次聽說，只需要讀一些這些主流軟件公司的評論，然後記下他們關於未來如軟件產品和服務的發布的話。幾乎沒有例外，你至少會聽到和看到關於集成、互聯和互操作這些詞語。這些都暗示著連接。簡而言之，連接時新的普遍需求。
普遍概念
滿足這個普遍需求的任務有點艱巨，特別是當我們想要連接的應用運行在不同的硬件、操作系統和平台的時候。畢竟每個硬件、操作系統和平台有自己的系統、內存管理模式、傳輸和協議。當深入內部研究大部分組織的非主流架構時，我們需要一種廠商中立的方式。隨著時間的過去，工業已經幾次試圖標准化跨越硬件、操作系統和平台邊界的類型系統、內存管理模式、傳輸和協議。這些包括CORBA, DCE / RPC, RMI, COM+ and DCOM。大部分程度上，從長遠來說，每次努力都沒有能夠獲取行業范圍內廣泛的接受。
然而，工業已經普遍接受了Internet 極其標准。無一例外，現在的硬件、操作系統和平台能夠通過Internet通信。對於Internet標准的接受來自於HTTP, HTML,XML的本來屬性。本質上說，基於Internet的通信需要依賴這些標准發送和接受數據而不需要類型系統、內存管理模式或者內部協議。簡單來說，Internet 通信關注與傳輸的數據而不是特定的類型系統、操作系統或者平台。
底層協議可以抽象化為應用-應用和應用-企業連接提供概念模型。這個名字就是面向服務。面向服務的普遍概念肩負著實現兩種形式的普遍需求互聯的承諾。面向服務的應用系統關注的是使用特定的結構來發送和接受消息，很像一個網站如何通過Http發送和接受html.那些接受這些消息的應用系統通常被稱為服務。
注釋：服務嚴重過載，並且可能為讀者帶來許多不同的想法。這本書裡，一個服務是功能性地通過一個結構消息scheme暴露出來。這個消息scheme的結構可以是任何世界的東西(SOAP, XML, JavaScript 對象符號等等)並且傳輸這些消息可以經過任何媒介 (HTTP, TCP/IP, UDP, SMTP, CD/DVD, 或者 信鴿).
從商業角度來看,面向服務的普遍需求承諾要簡化和提高這些需要連接、版本化和取代應用系統工作的效率。可以通過復用現在系統的功能暴露出來的服務而減少內部開發工作量。此外，服務可以被更新（帶有一些約束）而不會被調用它的應用系統察覺這些變化，或者必須更新它本身。例如，一個應用系統要求制定出完成計劃，是完全開發一個一樣的系統還是使用現有像虛擬地球的服務更便宜呢？可以確定一些特定的情形給出了這個答案，但對於大多數商業應用系統而言，我斷言使用像虛擬地球這樣的服務會更加廉價，更實用和可靠的選擇。理論上說，內部重用別人已經開發、測試和暴露的服務比重新開發和測試相同功能的服務會更加容易、廉價和可靠。此外，只要消息和契約兼容，服務可以更新而不需要關注調用它的服務的變化。這些好處，然而，會需要依賴這個服務。一個服務調用者為了功能需要對服務承擔一些責任。如果服務提供者停止或者中斷，那些功能都不能夠被調用者使用。此外，一些服務提供者限制了調用服務的方式。
公平地講，這個故事和組件剛出現的時的情形有些相似。與之前的技術相比組件發展迅猛，但是組件架構也有不足，特別是滿足連接行的普遍需求，例如，組件架構需要一個公共平台和操作系統，並且根據組件架構構建的分布式應用系統需要同時更新。這種緊密耦合使得更新組件和底層平台非常艱難。但是這種模型可以工作在應用-應用的連接。但是卻不能在應用-企業平台之間的連接。正如你將在本書裡看到的一樣，面向服務的應用能夠使用更加靈活的方式進行版本化，而且是滿足兩種不同形式連接的普遍需求很好的選擇。
從開發者角度來看，面向服務的概念與實現、平台或者服務本身的運行時相比專注的是消息。發送一個消息從一個應用系統到另外一個應用系統或許看起來沒什麼大不了的，並且咋一看，並不是連接普遍需求的答案。畢竟，不同外形和大小的應用系統已經穿越大型機的邊界發送消息到其它系統。這個概念推廣的最大阻礙就是缺少消息框架的共識。軟件廠商傳統上為自己的工具集合范圍裡開發它們自己的消息框架，但是這些消息架構從來不會被廣泛采納，結果，互操作性實際上是遙不可及。但是就認為的普遍結構來說什麼樣子的消息結構是廣泛接受的？如果一個消息架構被全世界采用，任何采納它的應用系統可以與任何其它別的支持此消息結構的應用通信。連接普遍需求的關鍵在於開發出標准的消息架構和這個架構被廣泛采納。
那麼怎麼才能達成消息結構的共識呢？一個可能性就是，像 Microsoft, IBM, BEA, Sun Microsystems還有其它的軟件廠商一起工作創建可以互操作的消息結構。考慮到眼前工作的復雜性，它們可能幾年時間來研究，幾個會議，並且我個人喜歡不停地開會。經過充分的研究，會議討論（當然，不停地開會），一個標准的消息結構應該被合並或者戰斗爆發了，任何一個結果看上去都是非常有趣的。
最近你或許聽說過這個術語： WS-*（讀著WS-星）。 WS-*是個規范家族，它定義了不同系統，普遍的消息架構和消息編排。這個規范家族 WS-Addressing, WS-Security, WS-Trust, WS-SecureConversation, WS-Federation, WS-ReliableMessaging, WS-AtomicTransaction, WS-Coordination, WS-MetadataExchange, WS-Policy, and WS-PolicyAttachment。整體上來說，它們代表一種獨立與廠商的可以使得應用系統可以進行可靠、安全和事務的通信的方式。這些規范使用基於XML和SOAP的消息結構；它們是由大多數廠商的代表共同撰寫而成，並且是很多年經過專家會議討論的結果。這些規范被廣泛采納，因為許多主流軟件廠商已經加入到這些規范的制定中。實際上說，那些主流的軟件廠商已經認可了這個標准的消息格式。
基於SOAP的規范還未制定完成，其它的消息結構已經出現，JavaScript 對象標記（JSON）久是最著名的的例子。JSON大量用於異步JavaScript和XML (AJAX）的Web應用程序，一種浏覽器可以回發消息給服務器而不需要刷新整個頁面的機制。JSON 與基於XML的消息格式分道揚镳，它是基於javascript eval函數調用，不符合WS-*規范。純正意義上說，JASON在浏覽器和服務器之間的交互是面向服務的。重點就是服務必須認可消息格式。隨著時間的流逝，應用系統中的消息格式毫無疑義的會演化以適應不同時代的需求。
【地址】：http://www.cnblogs.com/frank_xl/
