RDIFramework.NET框架SOA解決方案（集Windows服務、WinForm形式與IIS形式發布）-分布式應用
RDIFramework.NET，基於.NET的快速信息化系統開發、整合框架，給用戶和開發者最佳的.Net框架部署方案。該框架以SOA范式作為指導思想，作為異質系統整合與互操作性、分布式應用提供了可行的解決方案。
1、SOA平台簡介
1.1、概述
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來實現，而使用該服務的應用程序可以在不同的平台之上，使用的語言也可以不同。
1.2、SOA基本特征
SOA的實施具有幾個鮮明的基本特征。實施SOA的關鍵目標是實現企業IT資產的最大化作用。要實現這一目標，就要在實施SOA的過程中牢記以下特征：
可從企業外部訪問
隨時可用
粗粒度的服務接口分級
松散耦合
可重用的服務
服務接口設計管理
標准化的服務接口
支持各種消息模式
精確定義的服務契約
1.3、為什么選擇SOA
不同種類的操作系統，應用軟件，系統軟件和應用基礎結構（application infrastructure）相互交織，這便是IT企業的現狀。一些現存的應用程序被用來處理當前的業務流程（business processes），因此從頭建立一個新的基礎環境是不可能的。企業應該能對業務的變化做出快速的反應，利用對現有的應用程序和應用基礎結構（application infrastructure）的投資來解決新的業務需求，為客戶，商業伙伴以及供應商提供新的互動渠道，並呈現一個可以支持有機業務（organic business）的構架。SOA憑借其松耦合的特性，使得企業可以按照模塊化的方式來添加新服務或更新現有服務，以解決新的業務需要，提供選擇從而可以通過不同的渠道提供服務，並可以把企業現有的或已有的應用作為服務， 從而保護了現有的IT基礎建設投資。
2、服務的定義
2.1、概述
關於SOA平台服務的定義，目前來說一般有兩種形式，一種是定義標准接口的形式，一種是以標准的WebService的形式來下定義服務的實現。
在上圖中是以接口的形式來定義SOA平台服務的，RDIFramework.NET的SOA實現也是采用這種方式。具體的實現是以.NET技術的WCF來實現的，服務可以以以下幾種方式寄存（發布）：Windows服務模式（常用）、WinForm界面模式、IIS服務模式等等。在后面的文章我們會分別介紹。
2.2、SOA服務設計原則
一、SOA要求一致性
有很多可用於創建、發布、發現和調用服務的候選技術。SOA 應提供一個參考體系結構，以指定服務提供者和使用者將使用的特定機制；我們應以在 SAO 所有參與者間實現一致性為目標。此類一致性可以減少開發、集成和維護工作。
如果需要使用參考體系結構之外的元素，我們推薦使用補充性方法。例如，假如我們為服務發布和發現選擇的機制是 UDDI，但某個特定的開發團隊已在使用一個基於其他存儲庫技術的開發流程，此時該如何處理呢？我們將選擇投入精力將該團隊的服務同時發布到兩個存儲庫。這樣，現有的服務使用者就可以使用其熟悉（但可能並不標准）的存儲庫了。而運行於公共 SOA 基礎結構上的使用者則可以為所有服務使用標准存儲庫——例如 UDDI。
二、SOA 簡化開發
我們希望任何企業級的 SOA 基礎結構都具有可伸縮性和彈性；還應包含行業級的企業服務總線（Enterprise Service Bus，ESB）和安全技術。或者，換種說法，以 SOA 為目標的服務和流程的開發人員可利用成熟的中間件，依賴 SOA 基礎結構提供問題的解決方案，如身份驗證、消息轉換和可靠消息交付。
這些中間件功能的提供應以一個重要的原則為基礎：服務和流程開發人員應遠離中間件實現的復雜細節。我們的理想目標是，在我們的 SOA 環境中工作的開發人員應只需要業務領域的相關知識和基本的編程技巧。
服務具有標准的、經過正式定義的可由計算機處理的接口
了解了工具和代碼生成在 SOA 實現中可扮演重要角色之后，我們現在要強調使用可由計算機處理的接口的重要性。當使用定義良好的可由計算機處理的語言描述了接口時，實際上就為各種工具支持功能提供了支持。我們希望改善分離狀況，因此我們強烈建議使用 WSDL 之類正式定義的開放標准語言，而不要使用專用格式。
可由計算機處理的方法的概念應該從服務接口描述（如 WSDL）擴展到所有其他形式的聲明信息或元數據。只有同時強調聲明技術和可由計算機處理的元數據，才能將其相關的復雜性從業務應用程序開發人員轉移到基於標准的中間件中。新興的 WS-Policy 之類的技術在支持此方法方面充當着重要的角色。
三、服務應設計為可重用
服務設計人員應該記住，他們所開發的任何服務都可能成為可重用資產。設計人員不應只關注服務的最初使用者的需求，而應該進行更為廣泛的業務分析，以確定更全面的需求。我們建議，設計人員應考慮服務可能的發展方向：
設計必須能適應不斷增加的吞吐量；如果服務在使用服務的數量增加的情況下仍可成功運行，那么使用率也會成級數遞增。
如果使用服務的數量增加，則數據量和並發數據訪問模式可能會與最初投入使用時的情況大為不同。
我們必須對服務請求的未來增長進行預計；新使用者可能需要其他的功能，或者需要對現有功能進行更改
四、服務應具有精心選擇的粒度
在選擇服務粒度時，我們可能需要在多個因素間進行折衷，如可維護性、可操作性和易用性。任何給定的 SOA 都應向服務設計人員提供指南，以便確定此類折衷方案。
五、服務應是內聚而完整的
既然認識到了在確定服務粒度時需要考慮周全，那么在確定哪些操作應組成服務時有什么注意事項呢？我們認為有兩個對象設計概念很有用：內聚性和完整性。
六、服務應對實現細節進行封裝
我們封裝服務實現的細節——所用的算法和資源——的動機在於增加服務使用者和提供者之間的分離，從而為將來擴展提供靈活性。
七、操作設計應考慮並發性
3、框架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模式的客戶端與服務端的正確配置以及綁定的方法，可以參考相關文章，在我們框架的配置文件中也進行了詳細的說明。
3.1、服務端以Windows服務寄存運行
要想我們的框架以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服務為寄存宿主）。
3.2、服務端以WinForm形式寄存運行
我們的框架不僅可以寄存在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”添加了對用戶服務的測試調用。
3.3、服務端以IIS形式寄存運行
我們的框架不僅可以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服務端，來進行分布式應用的部署，都可以成功運行我們框架的客戶端，用戶在使用過程中，可以根據實際情況做出自己的選擇。
歡迎關注RDIFramework.net框架官方公眾微信（微信號：guosisoft），及時了解最新動態。
掃描二維碼立即關注
