rdiframework.net架構soa解決方案（集windows服務、winform形式與iis形式釋出）-分布式應用
rdiframework.net，基于.net的快速資訊化系統開發、整合架構，給使用者和開發者最佳的.net架構部署方案。該架構以soa範式作為指導思想，作為異質系統整合與互操作性、分布式應用提供了可行的解決方案。
soa（service-oriented architecture，也叫面向服務的體系結構或面向服務架構）是指為了解決在internet環境下業務內建的需要，通過連接配接能完成特定任務的獨立功能實體實作的一種軟體系統架構。soa是一個元件模型，它将應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，它應該獨立于實作服務的硬體平台、作業系統和程式設計語言。這使得建構在各種這樣的系統中的服務可以以一種統一和通用的方式進行互動。
傳統的web（html/http）技術有效的解決了人與資訊系統的互動和溝通問題，極大的促進了b2c模式的發展。web服務(xml/soap/wsdl）技術則是要有效的解決資訊系統之間的互動和溝通問題，促進b2b/eai/cb2c的發展。soa（面向服務的體系)則是采用面向服務的商業模組化技術和web服務技術，實作系統之間的松耦合，實作系統之間的整合與協同。web服務和soa的本質思路在于使得資訊系統個體在能夠溝通的基礎上形成協同工作。
對于面向同步和異步應用的，基于請求/響應模式的分布式計算來說，soa是一場革命。一個應用程式的業務邏輯（business logic）或某些單獨的功能被子產品化并作為服務呈現給消費者或用戶端。這些服務的關鍵是他們的松耦合特性。例如，服務的接口和實作相獨立。應用開發人員或者系統內建者可以通過組合一個或多個服務來建構應用，而無須了解服務的底層實作。舉例來說，一個服務可以用。net或j2ee來實作，而使用該服務的應用程式可以在不同的平台之上，使用的語言也可以不同。
soa的實施具有幾個鮮明的基本特征。實施soa的關鍵目标是實作企業it資産的最大化作用。要實作這一目标，就要在實施soa的過程中牢記以下特征：
可從企業外部通路
随時可用
粗粒度的服務接口分級
松散耦合
可重用的服務
服務接口設計管理
标準化的服務接口
支援各種消息模式
精确定義的服務契約
不同種類的作業系統，應用軟體，系統軟體和應用基礎結構（application infrastructure）互相交織，這便是it企業的現狀。一些現存的應用程式被用來處理目前的業務流程（business processes），是以從頭建立一個新的基礎環境是不可能的。企業應該能對業務的變化做出快速的反應，利用對現有的應用程式和應用基礎結構（application infrastructure）的投資來解決新的業務需求，為客戶，商業夥伴以及供應商提供新的互動管道，并呈現一個可以支援有機業務（organic business）的構架。soa憑借其松耦合的特性，使得企業可以按照子產品化的方式來添加新服務或更新現有服務，以解決新的業務需要，提供選擇進而可以通過不同的管道提供服務，并可以把企業現有的或已有的應用作為服務， 進而保護了現有的it基礎建設投資。
關于soa平台服務的定義，目前來說一般有兩種形式，一種是定義标準接口的形式，一種是以标準的webservice的形式來下定義服務的實作。
在上圖中是以接口的形式來定義soa平台服務的，rdiframework.net的soa實作也是采用這種方式。具體的實作是以.net技術的wcf來實作的，服務可以以以下幾種方式寄存（釋出）：windows服務模式（常用）、winform界面模式、iis服務模式等等。在後面的文章我們會分别介紹。
一、soa要求一緻性
有很多可用于建立、釋出、發現和調用服務的候選技術。soa 應提供一個參考體系結構，以指定服務提供者和使用者将使用的特定機制；我們應以在 sao 所有參與者間實作一緻性為目标。此類一緻性可以減少開發、內建和維護工作。
如果需要使用參考體系結構之外的元素，我們推薦使用補充性方法。例如，假如我們為服務釋出和發現選擇的機制是 uddi，但某個特定的開發團隊已在使用一個基于其他存儲庫技術的開發流程，此時該如何處理呢？我們将選擇投入精力将該團隊的服務同時釋出到兩個存儲庫。這樣，現有的服務使用者就可以使用其熟悉（但可能并不标準）的存儲庫了。而運作于公共 soa 基礎結構上的使用者則可以為所有服務使用标準存儲庫——例如 uddi。
二、soa 簡化開發
我們希望任何企業級的 soa 基礎結構都具有可伸縮性和彈性；還應包含行業級的企業服務總線（enterprise service bus，esb）和安全技術。或者，換種說法，以 soa 為目标的服務和流程的開發人員可利用成熟的中間件，依賴 soa 基礎結構提供問題的解決方案，如身份驗證、消息轉換和可靠消息傳遞。
這些中間件功能的提供應以一個重要的原則為基礎：服務和流程開發人員應遠離中間件實作的複雜細節。我們的理想目标是，在我們的 soa 環境中工作的開發人員應隻需要業務領域的相關知識和基本的程式設計技巧。
服務具有标準的、經過正式定義的可由計算機處理的接口
了解了工具和代碼生成在 soa 實作中可扮演重要角色之後，我們現在要強調使用可由計算機處理的接口的重要性。當使用定義良好的可由計算機處理的語言描述了接口時，實際上就為各種工具支援功能提供了支援。我們希望改善分離狀況，是以我們強烈建議使用 wsdl 之類正式定義的開放标準語言，而不要使用專用格式。
可由計算機處理的方法的概念應該從服務接口描述（如 wsdl）擴充到所有其他形式的聲明資訊或中繼資料。隻有同時強調聲明技術和可由計算機處理的中繼資料，才能将其相關的複雜性從業務應用程式開發人員轉移到基于标準的中間件中。新興的 ws-policy 之類的技術在支援此方法方面充當着重要的角色。
三、服務應設計為可重用
服務設計人員應該記住，他們所開發的任何服務都可能成為可重用資産。設計人員不應隻關注服務的最初使用者的需求，而應該進行更為廣泛的業務分析，以确定更全面的需求。我們建議，設計人員應考慮服務可能的發展方向：
設計必須能适應不斷增加的吞吐量；如果服務在使用服務的數量增加的情況下仍可成功運作，那麼使用率也會成級數遞增。
如果使用服務的數量增加，則資料量和并發資料通路模式可能會與最初投入使用時的情況大為不同。
我們必須對服務請求的未來增長進行預計；新使用者可能需要其他的功能，或者需要對現有功能進行更改
四、服務應具有精心選擇的粒度
在選擇服務粒度時，我們可能需要在多個因素間進行折衷，如可維護性、可操作性和易用性。任何給定的 soa 都應向服務設計人員提供指南，以便确定此類折衷方案。
五、服務應是内聚而完整的
既然認識到了在确定服務粒度時需要考慮周全，那麼在确定哪些操作應組成服務時有什麼注意事項呢？我們認為有兩個對象設計概念很有用：内聚性和完整性。
六、服務應對實作細節進行封裝
我們封裝服務實作的細節——所用的算法和資源——的動機在于增加服務使用者和提供者之間的分離，進而為将來擴充提供靈活性。
七、操作設計應考慮并發性
rdiframework.net架構的soa（wcf服務端）可以通過以下幾種方式進行寄存（釋出）： 以windows服務方式寄存，以winform形式寄存和以iis形式寄存。
要想架構以wcf模式運作，首先必須配置rdiframework.net架構可運作檔案所在檔案夾的“config.xml”檔案，找到“軟體服務提供程式”項，其取值有兩種：rdiframework.serviceadapter與rdiframework.serviceclient
系統預設為“rdiframework.serviceadapter”，即傳統資料通路方式（邏輯上的三層結構），要想系統以wcf模式運作，必須設定其值為：rdiframework.serviceclient
通過這樣的設定，再簡單部署一下，即可以wcf模式運作本程式。wcf模式運作config.xml檔案配置如下圖所示。
當然了，對于wcf模式的用戶端與服務端的正确配置以及綁定的方法，可以參考相關文章，在我們架構的配置檔案中也進行了詳細的說明。
要想我們的架構以windows服務寄存，必須部署架構的wcf服務“rdiframework.winservice”目錄包含的内容即為我們的架構以windows服務進行寄存所必須的檔案，如圖7.3.1所示。圖中含有兩個批處理檔案可以很好的幫助我們安裝與解除安裝架構的windows服務，他們分别是：
install rdiframeworkservice.bat：用于安裝架構的wcf服務以寄存到windows服務上。
uninstall rdiframeworkservice.bat：用于解除安裝已經安裝好架構wcf服務。
如下圖：rdiframework.net以windows服務進行寄存所需檔案所示。
輕按兩下install rdiframeworkservice.bat檔案進行服務的安裝，如圖7.3.2所示，輸入:y，即可對服務進行安裝。如下圖所示：
安裝成功會出現下圖所示的字樣。
到windows服務管理器中，可以看到我們架構的服務已經安裝成功，首次安裝成功預設沒有啟動，就請手動啟動即可，如下圖所示。
對于安裝成功的服務，我們也可以對他進行解除安裝，解除安裝服務使用uninstall rdiframeworkservice.bat檔案，輕按兩下此檔案，輸入”y”即可對已成功安裝的架構服務進行解除安裝，如下圖所示。
或者用installutil.exe指令解除安裝架構服務也可以，如下圖所示：
架構以wcf模式運作的效果如下圖所示，可以看到其與傳統的方式運作效果完全一樣。
因為我們開啟了wcf的日志功能，我們可以通過vs2010自帶的“服務跟蹤檢視器”檢視wcf的調用過程，當然建議在系統投入正常使用後，關閉wcf的日志記錄功能，以免影響整個架構的效率，在此僅做測試使用，要打開vs的服務跟蹤檢視器，到開始菜單vs的安裝菜單名下，找到“服務跟蹤檢視器”，即可打開，如下圖所示。
通過“服務跟蹤檢視器”我們可以很清楚的看到我們架構是如何調用wcf服務的，整個過程都詳細的進行了記錄，如下圖所示。對于“服務跟蹤檢視器”的使用方法可以參考相關文檔，也可以檢視其自帶的幫助檔案。
以上就是我們架構的分布式架構部署方案（以windows服務為寄存宿主）。
我們的架構不僅可以寄存在windows服務程式中，還可以以winform形式寄存，使用方式與windows服務寄存類似。以winform形式寄存意思是說，服務端以窗體界面形式來啟動，這種方式比較簡單易懂，使用者可以把啟動架構服務的窗體主程式放在windows自啟動菜單，讓開機時自動啟動我們的架構服務。rdiframework.net服務端以winform形式寄存運作目錄：bin\frameworkservice\rdiframework.servicehost.exe即可，開啟後的效果如下圖所示：
服務端已經開啟，現在運作rdifrmework.net用戶端，效果與windows服務方式一至。要測試我們啟動的服務，我們可以使用“wcf測試用戶端”來進行測試。wcftestclient.exe是一個gui的工具用于測試wcf，隻需在visual studio command line 視窗中鍵入wcftestclient，就啟動這個程式。如下圖：
可以右鍵“我的服務項目”選擇“添加服務（a）…”來添加wcf服務，在上圖中，我們輸入“net.tcp://127.0.0.1:8888/rdiframework.serviceadapter/userservice/mex”添加了對使用者服務的測試調用。
我們的架構不僅可以windows服務、winform界面形式寄存，還可以使用iis的web服務形式來寄存。
要以iis方式來寄存架構的wcf服務，首先我們需要把“rdiframework.wcfservice”項目釋出到iis下，釋出的方法與正常的web釋出方式一樣，可以參照相關的文章，rdiframework.wcfservice項目如下圖所示：
釋出到iis後的效果如下圖所示：
在這兒需要說明的時，架構的服務釋出到iis下後，對應的應用程式池的.net framework版本要選擇.net framework v4.0以上版本。如下圖所示：
至此，我們可以用浏覽器來浏覽我們釋出的服務，測試釋出的服務是否成功，如下圖所示，我們測試staffservice服務。
我們也可以用“wcf測試用戶端”來測試我們釋出到iis下的wcf服務，如下圖所示：
以上面三種方式釋出wcf服務端，來進行分布式應用的部署，都可以成功運作我們架構的用戶端，使用者在使用過程中，可以根據實際情況做出自己的選擇。
本文出自 “” 部落格，請務必保留此出處