REST API 出現之前，SOAP (Simple Object Access Protocol) 一直都是基于 web 的標準協議，雖然現在 REST 大行其道，但在平時開發中總會遇到對接第三方服務采用的是基于SOAP協議的場景，在這篇文章中，我們將會討論如何在 ASP.Net Core 中對接 WCF。

創建 WCF

WCF 是一個安全可靠的消息平臺，它提供統一的編程模型便于開發基于面向服務的應用程序，你可以使用 WCF 構建基于 SOAP 協議的服務，并使用 xml 作為數據交換格式，或者基于 REST 的 json 數據交換格式。

這一節中首先創建一個 WCF SOAP 服務，在創建項目模板的時候選擇 WCF Service Application 即可，如下圖所示：

值得注意的是，WCF 通常由以下幾個部分組成。

• Service 類

• Service 契約

• Operation 契約

• Endpoints 端點

• Hosting 環境

當要使用 WCF，需要在類和方法上分別加上：ServiceContract 和 OperationContract，下面的代碼展示了一個契約類僅包含一個契約方法的代碼定義。

    [ServiceContract]
    public interface IAuthorService
    {
        [OperationContract]
        List<string> GetAuthorNames();
    }

接下來定義一個 AuthorService 服務類實現一下 IAuthorService 接口，下面的代碼展示了 AuthorService 類的具體定義。

    public class AuthorService : IAuthorService
    {
        public List<string> GetAuthorNames()
        {
            List<string> lstAuthors=new List<string>();
            lstAuthors.Add("Joydip Kanjilal");
            lstAuthors.Add("Steve Smith");
            lstAuthors.Add("Michael Stevens");
            return lstAuthors;
        }
    }

這就是構建 WCF 服務的所有步驟，接下來就可以打開瀏覽器對服務進行簡單測試了。

在 ASP.Net Core 中使用 SOAP 服務

與傳統的 ASP.NET 不同，ASP.Net Core 中并沒有 Add Service Reference 選項去添加對 WCF 服務地址的引用，新的操作方式需要利用 Microsoft WCF Web Service Reference Provider 來進行服務引用，如下圖所示：

當點擊圖中的 Finish 之后，VS會自動幫你完成一系列的初始化，比如從SOAP服務中下載元數據，生成客戶端的代理代碼，自動生成 Reference.cs 文件，等等。

好了，接下來可以在 Controller 中初始化 SOAP Service ，然后再調用 Service 端的 GetAuthorNamesAsync() 方法，如下代碼所示：

        [HttpGet]
        public async Task<string[]> Get()
        {
            ServiceReference1.AuthorServiceClient authorServiceClient=new ServiceReference1.AuthorServiceClient();
            var data=await authorServiceClient.GetAuthorNamesAsync();
            return data;
        }

WCF Connected Service 是 Visual Studio 的一個擴展插件，它允許在 ASP.Net Core 項目中實現對 WCF 服務的引用，當然，除了WCF還可以引用 Azure Storage 服務，關于 Azure Storage 的更多細節，我會在后面的文章中和大家細聊。

譯文鏈接：https://www.infoworld.com/article/3323584/how-to-consume-a-wcf-soap-service-in-aspnet-core.html

　軟件架構邏輯

　　框架從層次結構上分主要分為：表示層、服務層、業務層、數據層

　　◆表示層

　　表示層由UI(User Interface)和UI控制邏輯組成。

　　c/s選用wpf+智能客戶端,b/s選用asp.net mvc

　　WPF的出現解決了三個問題:

　　(1) 更快速的去開發更豐富的用戶體驗:使用WPF,可以在更加快速的時間內開發出來更加豐富的界面,滿足用戶的需求。WPF 借助 XAML 來利用標記而不是編程語言(如 C#)來構造精美逼真的用戶界面 (UI), 只要稍微具備一些HTML基礎知識，就可以快速地掌握XAML中的大部分內容。

　　(2) 消除用戶界面差異:wpf可以以IE為宿主的。或Silverlight

　　(3) 軟件開發團隊的協作問題: 在軟件團隊中,我們比較熟悉Developer、DBA、Tester、IT Pro、Architect等。Designer可能往往被我們忽視,但實際上,Designer的工作成果才是與客戶距離最近的。而且Designer與Developer如何配合工作,是很多團隊所頭疼的,而WPF正可以解決此問題。

　　智能客戶端的優勢

　　1)充分利用終端設備的優勢

　　2)能夠調用wcf

　　3)支持在線和離線兩種狀態

　　4)能夠如同Web應用程序一般簡單方便的部署

　　asp.net mvc內置AJAX支持。

　　本身含的MVC(模型-視圖-控制器)和本系統MVVM(Model-View-ViewModel)就是雙胞胎，在demo里已經有很好的集成

　　*注：因xaml和html是標記語言，此層大部分可用代碼生成器生成。

　　◆服務層

　　采用微軟的WCF，Windows Communication Foundation (WCF)是Microsoft為構建面向服務的應用提供的分布式通信編程框架平臺，是.NET Framework 3.5的重要組成部分。使用該框架，開發人員可以構建跨平臺、安全、可靠和支持事務處理的企業級互聯應用解決方案。WCF從一開始就是工程化的，能夠簡化應用程序的開發與部署，降低開發成本。用于構建面向服務的應用程序，不管這些程序是獨立的桌面應用程序，還是Web應用程序和服務，還是高端的企業應用程序。

　　◆邏輯、業務層

　　業務層封裝了實際業務邏輯，包含數據驗證，事物處理，權限處理等業務相關操作，是整個應用系統的核心。因此設計一個能夠真實反映實際需要的業務層是非常必要的，我們將實際業務具體分為業務數據與業務操作兩部分。

　　l 業務數據

　　Domain Model則是根據實際業務按照現實方式用OO思想建模，這樣很適合業務復雜的系統。通常采用自定義數據實體(Custom Data Entity)方式表達。自定義數據實體，有著良好的性能，編譯時的類型檢查，數據表現方式非常直觀符合實際業務的操作方式等優點，但需要自己定義維護類，在分布式環境下需要自己編寫序列化方法。

　　此階段負責數據交換(傳輸)的業務實體被稱之為DTO(Data Transfer Object)。

　　DTO要能夠支持：數據綁定、數據驗證、歷史記錄、級聯觸發、合并集合、序列化與反序列化，要實現一個大的遞歸，從其中的任何一個對象開始，能夠找出整個傳遞的所有數據。

　　(1)、數據的綁定支持。要實現IEditableObject接口，對于狀態的變化要實現INotifyPropertyChanged接口，這樣才能夠實現數據的觸發，這樣就要實現一個對象能夠找到其所有的集合，一個集合要能夠其所有的對象，這樣一樣，就必須實現從對象、集合、對象的遞歸，再深入一點，就實現了數據的級聯觸發，實現了雙向數據觸發、綁定。數據源的每個屬性變更，要能夠在界面上反映出來，綁定界面的改變，能夠記錄到后臺的數據源，并且要能夠支持回滾。對于容納這些數據的ObservableCollection集合也支持綁定處理。

　　(2)、數據驗證。實現IDataErrorInfo接口

　　(3) 對于歷史記錄。當實現IEditableObject這個接口，則必然實現了歷史記錄。能夠找到集合的所有更改的記錄，包括刪除的記錄。對于單個對象而言是能夠得到歷史記錄和當前數據，對于集合而言，則能夠找出差異集，同時，集合也要具備集合回滾的功能。

　　(4) 級聯觸發，則是在實現數據綁定的基礎上的，對于常見的主從結構，當從對象的一個屬性改變了，要能夠自動通知其所在的集合、集合再通知所在的對象數據改變了，如果是多層結構，則能夠自動的從最底層開始一路通知到頂層。

　　(5)合并集合、集合的處理。集合的處理與數據綁定是直接相當的。數據源找出差異集之后，要對差異集進行處理，處理完之后，要對原始集合進行更進一步的處理，要把兩個集合進行合并處理，主要是為了同步引用。

　　(6)同時，另外要實現的就是Data與SDO之間的轉換以及其他格式的數據與SDO、Data數據之間的數據轉換，比如Binary/Xml/Text/Key/文件/等，最基本的是SDO與Data之間的轉換，這些轉換根據需要，有時候是單向的，有時候是雙向的，根據業務需求而定。

　　(7)序列化與反序列化，主要是涉及到Binary和XML序列化。

　　l 業務操作

　　業務操作負責對業務數據進行各種業務相關的處理，例如驗證，流向，整合，事物，權限等，但它不負責有關對數據源的操作。

　　采用整合業務數據與業務方式來操作，將業務數據與相關的業務操作封裝在一起稱為業務實體，業務實體作為統一的業務層為表示層提供服務，同時也負責作為DTO在各個層次間傳輸，這樣完整的Domain Model設計方式，每個業務實體都可以做為一個單獨組件形式存在，對于組件化復用有著莫大的好處。

　　◆數據層

　　數據層的宗旨就是為數據源提供一個可供外界訪問的接口，我們應該選用一種能夠提供數據源無關的抽象數據訪問接口并通過在其下掛接各種不同的DataProviador來訪問數據源的數據層組件，這樣做便于移植到不同的數據源上。

　　從紛繁蕪雜的關系數據模型中抽象出概念模型。這樣開發人員可以只需著眼概念模型，而不必要去關心紛繁蕪雜的關系數據模型，從而提高開發效率。那么如何能夠做到這一點?

　　答案就是：Linq 和 ADO.NET Entity Framework

　　l LINQ幾乎支持你所期望的所有數據源：數據對象、SQL Server數據庫、XML和數據集，當然也支持ADO.NET Entity(LINQ to Entities),LINQ有如下優勢：

　　1、 無需復雜學習過程即可上手

　　下面我給出一個簡單的C#示例。

　　String[] QueryString=

　　{ "One", "Two", "Three", "Four", "Five" };

　　要想查找其中長度大于3的字符串，你可以使用以下查詢語句：

　　var ThisQuery=

　　from StringValue

　　in QueryString

　　where StringValue.Length > 3

　　select StringValue;

　　2、 編寫更少代碼即可創建完整應用。

　　3、 更快開發錯誤更少的應用程序。

　　4、 無需求助奇怪的編程技巧就可合并數據源。

　　5、 讓新開發者開發效率更高。

　　l ADO.NET Entity Framework包括

　　1. 實體數據模型(Entity Data Model),開發人員通過EDM抽象出非常合適的模型。

　　2. 非常強大的client-view/mappping引擎，用于映射數據關系

　　3. Entity SQL語言和LINQ查詢對EDM schemas的全面支持

　　4. ojbect services layer供您選擇以何種方式去處理查詢結果。比如(行，列或作為對象)。

　　5. 提供一個開放的模型使ADO.NET Entity Framework可以處理其他的數據存儲。

　　6. Entity Framework 實現了樂觀的并發模式(Optimistic Concurrency Model)

　　7. 事務處理

　　三、具體功能簡述

　　3.1工作流解決方案

　　工作流引擎：該部分為工作流模型的核心部分，用于生成、管理、角度和監控工作流的各個活動執行情況，并實現相應的人機交互。由于采用XPDL等語言定義的工作流文件記載了相應的業務邏輯，隱藏工作流引擎通過解析該文件來了解業務流轉的邏輯。然后依據某種運行模式按照解析出來的業務邏輯進行驅動，最終實現業務流程的流轉。

　　工作流定義接口：通過該接口可以進行工作流程的分析、建模、描述和歸檔等工作，并將設計完畢的業務流程生成工作流引擎能夠識別的語言。

　　工作流客戶接口：處理工作流運行過程中需要人為參與的操作。

　　工作流調用應用程序接口：工作流引擎調用外部應用程序的規范。

　　工作流引擎協作接口：不同工作流引擎之間的協作。

　　工作流管理監控接口：監控和管理工作流所有實例狀態。

　　3.2多語言&用戶自定義標簽方案

　　數據庫結構

　　3.3消息發布/訂閱系統方案

　　使用WCF創建發布/訂閱系統有多種不同的方式，

　　(1)使用回調契約的發布/訂閱系統

　　(2)使用MSMQ實際通用組播的發布/訂閱系統

　　(3)使用流的發布/訂閱系統

　　方法1,2適合通知數據量較大并且發布頻率比較低的應用場景。

　　當通知的數據量較小而且發布頻率又較高時，應該使用方法3。

　　3.4報表&打印方案

　　四、系統平臺&支撐組件

　　l Wpf (UI)

　　l Asp.net mvc(UI)

　　l ClickOnce(智能客戶端。可自動升級，離線操作)

　　l Linq(借助于LINQ技術，我們可以使用一種類似SQL的語法來查詢任何形式的數據,普通開發人員不必學習MsSql, mysql, orcale, access等數據庫語法，節省開發時間)

　　l ADO.NET Entity(讓應用程序可以用完全對象化的方法連接與訪問數據庫, 修改Provider就可遷移到不同的數據庫)

　　l IIS6或以上

　　l Windows server 2003或以上

　　l WCF(服務層)

　　l Unity(是微軟模式與實踐團隊開發的一個輕量級、可擴展的依賴注入&反轉控制容器)

　　l SQL Server Compact Edition(用作智能客戶端離線操作)

　　l WF(Microsoft Windows Workflow Foundation是一個可擴展框架，用于在 Windows 平臺上開發工作流解決方案)

　　五、系統網絡結構

、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. 可從企業外部訪問
2. 隨時可用
3. 粗粒度的服務接口分級
4. 松散耦合
5. 可重用的服務
6. 服務接口設計管理
7. 標準化的服務接口
8. 支持各種消息模式
9. 精確定義的服務契約

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

通過這樣的設置，再簡單部署一下，即可以SOA模式運行本程序。SOA模式運行Config.xml文件配置如下圖所示。

當然了，對于SOA模式的客戶端與服務端的正確配置以及綁定的方法，可以參考相關文章，在我們框架的配置文件中也進行了詳細的說明。

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命令卸載框架服務也可以，如下圖所示：

框架以SOA模式運行的效果如下圖所示，可以看到其與傳統的方式運行效果完全一樣。

因為我們開啟了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服務，如下圖所示：

　　
以上面三種方式發布SOA服務端，來進行分布式應用的部署，都可以成功運行我們框架的客戶端，用戶在使用過程中，可以根據實際情況做出自己的選擇。　

全新跨平臺版本.NET敏捷開發框架V5.0-RDIFramework.NET震撼發布

敏捷開發框架助力企業BPM業務流程系統的開發與落地

RDIFramework.NET代碼生成器全新V5.0版發布

一路走來數個年頭，感謝RDIFramework.NET框架的支持者與使用者，大家可以通過下面的地址了解詳情。

RDIFramework.NET官方網站：http://www.rdiframework.net/

RDIFramework.NET官方博客：http://blog.rdiframework.net/

特別說明，框架相關的技術文章請以官方網站為準，歡迎大家收藏！

RDIFramework.NET框架由海南國思軟件科技有限公司專業團隊長期打造、一直在更新、一直在升級，請放心使用！

歡迎關注RDIFramework.NET框架官方微信公眾號（微信號：guosisoft），及時了解最新動態。