Shadowfax 架構（自己翻譯）
早就聽說在gotdotnet社區出了個SOA的典範叫Shadowfax（後來叫Enterprise Development Application Framework，好像意思是要擴大它的影響範圍了。），但一直沒有時間去仔細學習研究一下，今天借第一天申請BLOG的高興勁，將EDAF wiki上的第一篇文章翻譯一下，和大家一起提高一下。在翻譯過程中，我傾向於採用候捷的風格，即對很多英文術語不作翻譯。原文參考http://weblogs.asp.net/hernandl/archive/2004/02/23/shadowfaxintro.aspx ，這篇文章寫於2004年2月。
<!--譯文開始-->
我們正在完成微軟.NET參考架構（codename是Shadowfax），我們現在已經有了一個穩定的代碼庫，我現就將開始對這個架構不同方面的特性來表達自己的想法和見識。
SOA已經被廣泛的的宣傳（一個好的描述是Clemens的blog），現在我們有了一個真實的已經爲商業應用做好準備（或者說，基本上已經準備好了）的包容各個方面的優秀架構的實現。如果你是 patterns andpractice以及指引和現成的Application Blocks的關注者，我敢打賭你會猜想這幫人什麼時候才能做出一個可以在廣泛企業解決方案中應用的完美管制代碼的商業架構。
呵呵，這個時候已經到了，Shadowfax將要發佈了。但是先等等，如果你認爲這個Shadowfax只是對那些Application Bolocks做了一個漂亮的學術形式的包裝並附加了一些比較酷的功能，那你肯定錯了。當然Application Blocks已經被廣泛地使用，但是我後面會說到還有很多事情需要做更多地考慮。這個項目的一個有趣的特點源於它的一個出發點。
在這個項目的最初階段，即構思和設計階段，這些架構師決定收集從全世界的微軟的合作伙伴和微軟的諮詢機構中獲取最成功的.NET企業架構實現的最佳經驗。他們收集了最好的3個（其中一個是我們開發成功的MBI項目）以及這些項目的知識，開始設計一個全新的模型來解決我們下面將要提到的問題。這一點很重要，因爲所有這些成功的架構真正解決了客戶的需求並且也將成爲Shadowfax架構的最重要的目的。
在深入描述之前讓我澄清一下，現在這個架構的文檔已經有幾百頁了，一個BLOG帖子是不可能將這個架構描述得更加清楚並給出一個完整的架構圖，所以我會非常簡單地介紹一下一些主題，其他的一些主題我將做更深入的研究再給出。提醒一下，你可以在Shadowfax 的 gotdotnet的 Workspace中發現一些有用的信息和關於這個架構的有趣討論和用戶反饋。
架構的需求和考慮
Shadowfax服務架構是爲了達到幾個重要的架構需求和目標而開發的。下面就是一些重要需求的列表：
* 保證穩定的服務接口和易變的不穩定服務實現的分離
* 讓程序員實現那種handlers-like的邏輯（如：監控和審計日誌）和服務實現邏輯的分離。這種所謂的 Handlers將在pipeline中執行。（不要擔心你暫時不懂這些概念，我們下面會詳細介紹這些細節）
* 幫助開發人員建立可以被客戶端的一種或多種組合傳輸通道訪問的強壯服務。我們現在支持的通道有：Web Services、MSMQ、Remoting、和DCOM。
* 建立一定層次上的在服務調用和服務實現2者間的間接關係來緩衝應用的變化。這就是double pipeline模型。
因爲我並不想對這整個架構做過多的展開描述，我傾向於描述一下我所關心的這個項目包含的主題和子系統。
我一直在設計/實現幾個Block，我寧可有偏見地寫那些內容，所以我會首先羅列出來（用中括號標註）然後等以後發帖子詳細描述。我會爲這些模塊寫一些關於性能和安全考慮的主題。
從客戶端開始考慮，第一個接入點是Service Interface。Shadowfax框架的這個接口幫助暴露一個建立在多個通道之上的一個服務接口（譯者注：原文是【service interface over multiple transports】）。一個服務請求首先是客戶端通過多個不同的通道發起如：WebServices、MQ、或者一個.NET Remoting。（甚至是DCOM）
通道的listener接受到請求信息（請求的格式根據通道的選擇有所變化），將其放入到叫context的信封中去，並將context傳遞到一個叫【Service Interface pipeline】的實例中去。
簡而言之，pipeline包括消息預處理Handler的序列，跟着是Target（譯者注：真正的業務邏輯實現），最後是消息後處理的【Handler】的序列。
一個handler是一個滿足一些切入考慮的代碼塊如：認證、日誌、或者是事務支持（事實上會有很多內置的handler將會被實現，至少比現在多一打）。handler有3種風格：原子性、有狀態、無狀態handler。無狀態的handler是在Target之前和之後都將被執行。原子和有狀態handler在處理流中僅會被執行一次。之後的handler以鏈的方式執行，即每個handler調用下一個handler並以同步的方式等待迴應。
這個架構有2種pipeline，這2種pipeline給物理/邏輯層之間的分離提供了極大的靈活性（典型的是IIS－DMZ（第一種pipeline）和一個內部應用服務器（第二種pipeline））並且引入了一個“間接層”。然而如果應用不需要分佈式的場景，可以僅使用第一種pipeline將滿足【Target】的執行要求。
在雙pipeline共存的場景下，第一個pipeline，即Service Interface pipeline，是一個和通道有關的並且關注於服務邊界的handlers如：認真、監控和請求消息的驗證。Shadowfax是高度可配置的，所以一個pipeline可以被配置成以任何順序處理任何方面（譯者注：AOP中的A）。Target的第一個pipeline是一個端口。這個端口的責任是調用第二個pipeline，叫【service implementation pipeline】。
Service Implementation pipeline是一個和服務相關的並關注於業務handler如：觸發一個業務事件，記錄請求日誌或者給事務劃分界限。Target的第二個pipeline的責任是調用服務的實現即調用【BusinessActioon】。
一個business action是被請求服務的真正實現。這是一個內部實現的商業組件或者是一個調用遠端組件的服務代理。在這2種情況下，它都是最初服務請求的最終Target。在多數情況下，一個business action將產生一個迴應。
business action通過工廠模式的風格有3種調用機制：Context，Serialization和Explicit。第一個通過IBusinessAction接口，後兩個是通過反射、消息的deserialization後的參數傳遞、並順序反射。
一旦一個Business action結束了，這第二個pipeline收到了一個響應，應用一些其他的handlers，然後通過context迴應第一個pipelie。然後第一個handler執行剩下的handlers。最後又迴應客戶端的應用程序。
另外一個重要的子系統是配置子系統，它依賴於CMAB（Configuration Management Application Block）。這個子系統的一個重要優點是支持“on-the-fly”更新，所以配置文件中的一個更新可以在不停止或者重啓應用的條件下自動反映到應用程序（不同於ASP.NET中的更新，ASP.NET是通過文件系統）。這個子系統值得關注一下，因爲它控制了架構幾乎每個方面，包括handler、services，甚至business action。
到現在爲止我們已經完成了我前面說到的這個架構的主要模塊的簡單介紹，不久我將非常願意地post更多的關於這個架構更加細節的內容。
注意：本帖子中出現的一些術語和名字和最終發佈後的術語會有所區別。
<!--譯文結束-->