RDIFramework.NET框架SOA解決方案（集Windows服務、WinForm形式與IIS形式發佈）-分佈式應用

RDIFramework.NET框架SOA解決方案（集Windows服務、WinForm形式與IIS形式發佈）-分佈式應用

RDIFramework.NET，基於.NET的快速信息化系統開發、整合框架，給用戶和開發者最佳的.Net框架部署方案。該框架以SOA範式做爲指導思想，做爲異質系統整合與互操做性、分佈式應用提供了可行的解決方案。

一、SOA平臺簡介

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.二、SOA基本特徵

SOA的實施具備幾個鮮明的基本特徵。實施SOA的關鍵目標是實現企業IT資產的最大化做用。要實現這一目標，就要在實施SOA的過程當中牢記如下特徵：

可從企業外部訪問

隨時可用

粗粒度的服務接口分級

鬆散耦合

可重用的服務

服務接口設計管理

標準化的服務接口

支持各類消息模式

精肯定義的服務契約

1.三、爲何選擇SOA

　　不一樣種類的操做系統，應用軟件，系統軟件和應用基礎結構（application infrastructure）相互交織，這即是IT企業的現狀。一些現存的應用程序被用來處理當前的業務流程（business processes），所以從頭創建一個新的基礎環境是不可能的。企業應該能對業務的變化作出快速的反應，利用對現有的應用程序和應用基礎結構（application infrastructure）的投資來解決新的業務需求，爲客戶，商業夥伴以及供應商提供新的互動渠道，並呈現一個能夠支持有機業務（organic business）的構架。SOA憑藉其鬆耦合的特性，使得企業能夠按照模塊化的方式來添加新服務或更新現有服務，以解決新的業務須要，提供選擇從而能夠經過不一樣的渠道提供服務，並能夠把企業現有的或已有的應用做爲服務， 從而保護了現有的IT基礎建設投資。

二、服務的定義

2.一、概述

　　關於SOA平臺服務的定義，目前來講通常有兩種形式，一種是定義標準接口的形式，一種是以標準的WebService的形式來下定義服務的實現。

 

　　

 

 

 

 

 

 

 

　　在上圖中是以接口的形式來定義SOA平臺服務的，RDIFramework.NET的SOA實現也是採用這種方式。具體的實現是以.NET技術的WCF來實現的，服務能夠以如下幾種方式寄存（發佈）：Windows服務模式（經常使用）、WinForm界面模式、IIS服務模式等等。在後面的文章咱們會分別介紹。 

2.二、SOA服務設計原則

　　1、SOA要求一致性

　　有不少可用於建立、發佈、發現和調用服務的候選技術。SOA 應提供一個參考體系結構，以指定服務提供者和使用者將使用的特定機制；咱們應以在 SAO 全部參與者間實現一致性爲目標。此類一致性能夠減小開發、集成和維護工做。

　　若是須要使用參考體系結構以外的元素，咱們推薦使用補充性方法。例如，假如咱們爲服務發佈和發現選擇的機制是 UDDI，但某個特定的開發團隊已在使用一個基於其餘存儲庫技術的開發流程，此時該如何處理呢？咱們將選擇投入精力將該團隊的服務同時發佈到兩個存儲庫。這樣，現有的服務使用者就可使用其熟悉（但可能並不標準）的存儲庫了。而運行於公共 SOA 基礎結構上的使用者則能夠爲全部服務使用標準存儲庫——例如 UDDI。

　　2、SOA 簡化開發

　　咱們但願任何企業級的 SOA 基礎結構都具備可伸縮性和彈性；還應包含行業級的企業服務總線（Enterprise Service Bus，ESB）和安全技術。或者，換種說法，以 SOA 爲目標的服務和流程的開發人員可利用成熟的中間件，依賴 SOA 基礎結構提供問題的解決方案，如身份驗證、消息轉換和可靠消息交付。

　　這些中間件功能的提供應以一個重要的原則爲基礎：服務和流程開發人員應遠離中間件實現的複雜細節。咱們的理想目標是，在咱們的 SOA 環境中工做的開發人員應只須要業務領域的相關知識和基本的編程技巧。

　　服務具備標準的、通過正式定義的可由計算機處理的接口

　　瞭解了工具和代碼生成在 SOA 實現中可扮演重要角色以後，咱們如今要強調使用可由計算機處理的接口的重要性。當使用定義良好的可由計算機處理的語言描述了接口時，實際上就爲各類工具支持功能提供了支持。咱們但願改善分離情況，所以咱們強烈建議使用 WSDL 之類正式定義的開放標準語言，而不要使用專用格式。

　　可由計算機處理的方法的概念應該從服務接口描述（如 WSDL）擴展到全部其餘形式的聲明信息或元數據。只有同時強調聲明技術和可由計算機處理的元數據，才能將其相關的複雜性從業務應用程序開發人員轉移到基於標準的中間件中。新興的 WS-Policy 之類的技術在支持此方法方面充當着重要的角色。

　　3、服務應設計爲可重用

　　服務設計人員應該記住，他們所開發的任何服務均可能成爲可重用資產。設計人員不該只關注服務的最初使用者的需求，而應該進行更爲普遍的業務分析，以肯定更全面的需求。咱們建議，設計人員應考慮服務可能的發展方向：

　　設計必須能適應不斷增長的吞吐量；若是服務在使用服務的數量增長的狀況下仍可成功運行，那麼使用率也會成級數遞增。

　　若是使用服務的數量增長，則數據量和併發數據訪問模式可能會與最初投入使用時的狀況大爲不一樣。

　　咱們必須對服務請求的將來增加進行預計；新使用者可能須要其餘的功能，或者須要對現有功能進行更改

　　4、服務應具備精心選擇的粒度

　　在選擇服務粒度時，咱們可能須要在多個因素間進行折衷，如可維護性、可操做性和易用性。任何給定的 SOA 都應向服務設計人員提供指南，以便肯定此類折衷方案。

　　5、服務應是內聚而完整的

　　既然認識到了在肯定服務粒度時須要考慮周全，那麼在肯定哪些操做應組成服務時有什麼注意事項呢？咱們認爲有兩個對象設計概念頗有用：內聚性和完整性。

　　6、服務應對實現細節進行封裝

　　咱們封裝服務實現的細節——所用的算法和資源——的動機在於增長服務使用者和提供者之間的分離，從而爲未來擴展提供靈活性。

　　7、操做設計應考慮併發性

 

三、框架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.一、服務端以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.二、服務端以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.三、服務端以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），及時瞭解最新動態。

       掃描二維碼當即關注