摘要:本文討論 Windows Communication Foundation (WCF) 承載方案和 WCF 服務(wù)的使用。傳統(tǒng)的 ASMX Web 服務(wù)通常僅由 Microsoft Internet 信息服務(wù) (IIS) 承載。在 Microsoft .NET Framework 3.0 中,WCF 服務(wù)的承載方案得到了極大的增強(qiáng)。我們將討論如何將承載模型擴(kuò)展為包括 Windows 服務(wù)和自承載方案。此外,我們還將詳細(xì)探討可用于 WCF 服務(wù)的 IIS 承載(版本 5.1、6.0 和 7.0)和 Windows 激活服務(wù) (WAS) 承載方案。本文內(nèi)容是根據(jù)
Apress 出版的
《Pro WCF: Practical Microsoft SOA Implementation》一書第 5 章內(nèi)容編撰的。這本書是由
Avanade 公司的全球顧問團(tuán)隊編寫的。其主要針對入門級到中級讀者。包括這本書在內(nèi),Apress 已出版了一系列有關(guān) Windows Presentation Foundation (WPF)、Windows Communication Foundation (WCF) 和 Windows Workflow Foundation (WF) 的叢書。
下載示例代碼。下載 QuickReturns 案例研究說明。本頁內(nèi)容
簡介研究承載方案自承載您的服務(wù)在 Windows 服務(wù)中進(jìn)行承載使用 Internet 信息服務(wù)進(jìn)行承載使用 WCF 服務(wù)結(jié)論簡介
如果企業(yè)依賴于面向服務(wù)的體系結(jié)構(gòu),就必須確保服務(wù)能夠正??煽康倪\(yùn)行。應(yīng)用程序可靠性背后最重要的動因是在哪里托管服務(wù)以及如何托管服務(wù)。在考慮托管服務(wù)時,您必須事先考慮幾個問題:服務(wù)有哪些可用性方面的要求?如何管理和部署服務(wù)?是否需要提供對舊版本服務(wù)的支持?
了解如何滿足這些業(yè)務(wù)要求對于開發(fā)成功的服務(wù)是至關(guān)重要的。在第 3 章中您將了解到,必須自己提供宿主來承載服務(wù)。Windows Communication Foundation (WCF) 本身沒有附帶宿主,而是提供了一個被稱為 ServiceHost 的類,該類允許您在自己的應(yīng)用程序中承載 WCF 服務(wù)。您不必考慮任何網(wǎng)絡(luò)傳輸方面的細(xì)節(jié),即可確保服務(wù)能夠被訪問。只需以編程方式或聲明方式對服務(wù)的端點進(jìn)行配置,然后調(diào)用 ServiceHost 的 Open 方法即可。ServiceHostBase 和 ServiceHost 中集成了第 3 章要介紹的有關(guān)綁定、通道、調(diào)度程序和偵聽器的所有一般功能。這意味著用于承載服務(wù)的應(yīng)用程序(運(yùn)行 ServiceHost 的應(yīng)用程序)的負(fù)載將遠(yuǎn)遠(yuǎn)低于您之前預(yù)期的水平。
本章討論何種類型的應(yīng)用程序可以為 ServiceHost 提供宿主環(huán)境。此外,您還會對使用不同應(yīng)用程序內(nèi)承載的服務(wù)時存在的差異有所了解。
讀完本章后,您將學(xué)到以下知識:
?
適用于您的各種不同的承載方案
?
每種承載方案有哪些優(yōu)點和缺點
?
根據(jù)具體情況選擇承載方案的指導(dǎo)
?
有關(guān) Microsoft 如何實現(xiàn)不同承載方案以及每種方案在哪些方面具有可擴(kuò)展性的體系結(jié)構(gòu)方面的指導(dǎo)
返回頁首研究承載方案
在 Microsoft .NET 平臺上,使用 Microsoft Visual Studio.NET 可以創(chuàng)建幾種不同類型的托管 Windows 應(yīng)用程序:
?
WinForms 應(yīng)用程序
?
控制臺應(yīng)用程序
?
Windows 服務(wù)
?
承載于 Internet 信息服務(wù) (IIS) 中的 Web 應(yīng)用程序 (ASP.NET)
?
IIS 7.0 內(nèi)提供的 WCF 服務(wù)以及 Windows Vista 或 Windows Server 2007 中的 WAS
如果您仔細(xì)研究 Microsoft Visual Studio 2005 附帶的項目模板,就會發(fā)現(xiàn)還有其他可選方案供您使用。很顯然,我們認(rèn)為沒有其他模板可以在服務(wù)世界中用作可行的方案。但值得注意的是,只要 WCF 能夠提供 .NET 應(yīng)用程序域,您就可以在其他任何類型的應(yīng)用程序中運(yùn)行服務(wù)。(如果您不了解 .NET 應(yīng)用程序域的原理,請參考下面“了解 .NET 應(yīng)用程序域”一節(jié)的有關(guān)內(nèi)容。)實際上這完全取決于您對宿主的要求??偨Y(jié)這些可選方案,我們主要考慮以下三類常見的 WCF 服務(wù)宿主:
?
在托管的 .NET 應(yīng)用程序中進(jìn)行自承載
?
在 Windows 服務(wù)中進(jìn)行承載
?
在不同版本的 IIS 中進(jìn)行承載
可想而知,如本節(jié)之前提到的,所有這些宿主在 Visual Studio 中都有相關(guān)聯(lián)的項目模板,并且都有自己的特征。要想更好地了解在每種情況下哪種宿主是最佳選擇,必須了解宿主通常的要求和功能。理解這一點后,我們將分別詳細(xì)介紹每種承載方案。
了解 .NET 應(yīng)用程序域
如果您了解 Windows 進(jìn)程的角色以及如何通過托管代碼與它們交互,那么您肯定會對 .NET 應(yīng)用程序域的概念有所了解。要在進(jìn)程中運(yùn)行托管 .NET 代碼,就需要創(chuàng)建程序集。這些程序集并不直接承載于 Windows 進(jìn)程中。而是由公共語言運(yùn)行庫 (CLR) 在進(jìn)程中創(chuàng)建稱為“應(yīng)用程序域”的單獨邏輯分區(qū)來對托管代碼進(jìn)行隔離。單個進(jìn)程可能會包含多個應(yīng)用程序域,每個域都會承載封裝于程序集內(nèi)的不同代碼片斷。這種對傳統(tǒng) Windows 進(jìn)程的劃分方式可以通過 .NET Framework 提供幾個好處。
主要好處如下所示:
?
由于不涉及可執(zhí)行文件或庫的概念,應(yīng)用程序域決定了 .NET 平臺的與操作系統(tǒng)無關(guān)的特性。
?
您可以根據(jù)自身需要控制、卸載和加載應(yīng)用程序域。
?
應(yīng)用程序域在應(yīng)用程序或多個應(yīng)用程序域共生的進(jìn)程中起到隔離的作用。進(jìn)程中的應(yīng)用程序域彼此相互獨立,雖然一個域出現(xiàn)故障,但其他域仍可正常工作。
承載環(huán)境特征
.NET 應(yīng)用程序需要一個作為宿主的 Windows 進(jìn)程。該 Windows 進(jìn)程內(nèi)部可以承載多個 .NET 應(yīng)用程序域。應(yīng)用程序域是 .NET CLR 將托管代碼與 Windows 進(jìn)行隔離所采用的一種手段。CLR 會在每個工作進(jìn)程中進(jìn)行初始化,并自動創(chuàng)建一個默認(rèn)的應(yīng)用程序域。該默認(rèn)應(yīng)用程序域運(yùn)行于某個進(jìn)程,并直到該進(jìn)程結(jié)束時才會卸載。默認(rèn)應(yīng)用程序域的關(guān)閉是由 CLR 來控制的。在大多數(shù)宿主中,默認(rèn)應(yīng)用程序域內(nèi)部并不運(yùn)行任何代碼。而是由宿主(或“進(jìn)程”)來新建應(yīng)用程序域,以便應(yīng)用程序域可以獨立于進(jìn)程而關(guān)閉。在很多應(yīng)用程序中,理想的情況是客戶端代碼和服務(wù)器端代碼分別在不同應(yīng)用程序域中執(zhí)行。通常這種要求是出于安全性和隔離等原因的考慮。
進(jìn)程和應(yīng)用程序域之間的關(guān)系類似于應(yīng)用程序和應(yīng)用程序域與 ServiceHostWCF 之間的關(guān)系。如圖 5-1 所示,每個進(jìn)程都至少有一個應(yīng)用程序域,并且每個應(yīng)用程序域都可以承載零個或更多的 WCF ServiceHost 實例。WCF 需要一個 Windows 進(jìn)程內(nèi)部至少要承載一個應(yīng)用程序域。
圖 5-1. 進(jìn)程、應(yīng)用程序域和 WCF ServiceHost 關(guān)系
注意 盡管可以實例化多個 ServiceHost 實例,但每個應(yīng)用程序域內(nèi)保留一個 ServiceHost 實例更便于操作。您可以在一個宿主內(nèi)使用多個端點公開多個服務(wù)接口。更高級的宿主(例如,IIS 和 WAS)確實可以實例化多個 ServiceHost 實例,以提供隔離和不同的安全上下文。
因此,宿主的主要任務(wù)是向 WCF ServiceHost 提供 Windows 工作進(jìn)程和應(yīng)用程序域。此外,WCF 依賴于應(yīng)用程序域提供的安全和配置功能。Windows 進(jìn)程始終使用默認(rèn)標(biāo)識運(yùn)行,WCF 服務(wù)可隨時使用這個現(xiàn)成的標(biāo)識。但是,WCF 提供了幾個級別的模擬用戶的功能(詳見本書第 7 章)。如果您不使用這些功能,則由運(yùn)行服務(wù)的 Windows 進(jìn)程提供安全上下文。前面幾章提到過,默認(rèn)情況下 WCF 依賴于 .NET Framework 中的配置功能,您可以通過應(yīng)用程序域?qū)ζ溥M(jìn)行訪問。
某些宿主還具有管理所運(yùn)行的應(yīng)用程序的其他功能。最為突出的是,IIS 還具備自動進(jìn)程回收、資源限制、日志記錄、運(yùn)行狀況指示器等其他功能。您可以通過整個章節(jié)的學(xué)習(xí)了解有關(guān)這些主題的詳細(xì)內(nèi)容。(不同 IIS 版本具有受 WCF 支持的不同的可管理性功能。最為明顯的,Windows XP 中的 IIS 5.1 在管理用戶界面方面就受到一些限制。)
承載環(huán)境特征
Microsoft 在確保服務(wù)開發(fā)人員無需過分考慮承載環(huán)境方面所做的努力是值得肯定的。ServiceHost 排除了所有技術(shù)性的難點,使您可以重點關(guān)注服務(wù)邏輯,而不必過多地考慮如何承載服務(wù)。您必須根據(jù)自己的具體要求選擇一個宿主。WCF 主要是作為編程模型而編寫的,其主要設(shè)計目的之一是為了實現(xiàn)“宿主的不可知”。ServiceHost 不關(guān)心自身在哪里被實例化,只要您希望服務(wù)可被訪問時它正在運(yùn)行即可。也就是說,它需要一個運(yùn)行 .NET 應(yīng)用程序域的進(jìn)程。
在選擇應(yīng)用程序類型時,必須考慮某些特定要求(例如,程序?qū)儆诳刂婆_應(yīng)用程序還是 WinForms 應(yīng)用程序等)。ServiceHost 必須被實例化才能提供運(yùn)行服務(wù)所需的承載環(huán)境。典型的 .NET 應(yīng)用程序(例如,控制臺應(yīng)用程序和 WinForms 應(yīng)用程序)通常運(yùn)行在用戶桌面計算機(jī)上。這些環(huán)境并非始終運(yùn)行,它們可以承載您的服務(wù),但卻并非典型的適用于企業(yè)的宿主。我們認(rèn)為適用于企業(yè)的宿主應(yīng)該能夠支持更大規(guī)模的面向服務(wù)的體系結(jié)構(gòu),在這種體系結(jié)構(gòu)中,多個系統(tǒng)需要依賴服務(wù)所公開的關(guān)鍵業(yè)務(wù)功能。這些適用于企業(yè)的宿主通常能夠滿足諸如高可用性的要求。因此,我們不能將控制臺或 WinForms 應(yīng)用程序做為適用于企業(yè)的宿主。
通常情況下,服務(wù)運(yùn)行在服務(wù)器上,并由操作員進(jìn)行管理和操作。管理服務(wù)器的操作員一般不希望在服務(wù)器重新啟動時手動啟動控制臺應(yīng)用程序或 WinForms 應(yīng)用程序。為了讓服務(wù)應(yīng)用程序能夠在數(shù)據(jù)中心運(yùn)行,對于企業(yè)級面向服務(wù)的情況來說,唯一可行的方案就是在 IIS 上承載服務(wù),或?qū)⑵渥鳛橐豁?Windows 服務(wù)。
有時,您需要在用戶的桌面計算機(jī)上實現(xiàn)進(jìn)程間通信。在這種情況下,只有當(dāng)用戶使用應(yīng)用程序時,服務(wù)才是活動的。需要進(jìn)行進(jìn)程間通信的典型應(yīng)用程序就是控制臺應(yīng)用程序和 WinForms 應(yīng)用程序。這些應(yīng)用程序適合承載這些類型的服務(wù)。
要能夠確定哪種宿主最適合您的情況,您應(yīng)當(dāng)考慮到非功能性要求。一般來講,非功能性要求規(guī)定了應(yīng)用程序的技術(shù)要求,以確保其達(dá)到應(yīng)用程序要求的質(zhì)量和可維護(hù)性。對于 WCF 應(yīng)用程序來說,非功能性要求實際涉及以下內(nèi)容:
?
可用性:希望何時能夠訪問您的服務(wù)?
?
可靠性:當(dāng)服務(wù)由于某些原因出現(xiàn)中斷時會發(fā)生什么問題?這將如何影響服務(wù)的其他使用者?
?
可管理性:是否需要便捷地了解承載 WCF 服務(wù)的宿主上所發(fā)生的情況?
?
版本控制:是否需要提供對舊版本服務(wù)的支持?是否知道誰在使用您的服務(wù)?
?
部署:要采用何種部署模型?是否要通過 Microsoft Installer 進(jìn)程和 Visual Studio 部署包進(jìn)行安裝,還是使用 xcopy 就可以滿足需要?
?
狀態(tài):服務(wù)是無狀態(tài)的嗎?是否需要會話?
根據(jù)這些非功能性要求,您可以確定哪些宿主是符合您的需求的。為了幫助您做出選擇,本章后面的內(nèi)容將介紹不同的承載環(huán)境及其優(yōu)缺點。
注意 由于對自身的運(yùn)行環(huán)境并不了解,因此 WCF 編程模型總是有可能切換到不同宿主,但這并不意味著您必須更改服務(wù)實施。首先,您需要在控制臺應(yīng)用程序中進(jìn)行自承載,以測試并確定服務(wù)的原型。
返回頁首自承載您的服務(wù)
承載 WCF 服務(wù)最靈活、最便捷的方法就是進(jìn)行自承載。要能夠自承載服務(wù),必須滿足兩個條件。第一,需要 WCF 運(yùn)行時;第二,需要可以承載 ServiceHost 的托管 .NET 應(yīng)用程序。您需要自己動手編寫啟動和停止宿主的代碼。
下面是自承載的優(yōu)點:
?
易用性:只需幾行代碼即可使服務(wù)運(yùn)行。
?
靈活性:通過 ServiceHost<T> 的 Open() 和 Close() 方法,可以輕松控制服務(wù)的生存期。
?
易調(diào)試性:可以使用熟悉的調(diào)試方式對自承載環(huán)境中承載的 WCF 服務(wù)進(jìn)行調(diào)試,而不必連接到單個應(yīng)用程序來激活服務(wù)。
?
易部署性:通常,部署簡單 Windows 應(yīng)用程序與使用 xcopy 一樣容易。您不必在服務(wù)器場和類似地方部署復(fù)雜的方案,即可部署簡單的 Windows 應(yīng)用程序來充當(dāng) WCF ServiceHost。
?
支持所有綁定和傳輸:自承載并不限制您僅能使用現(xiàn)有的綁定和傳輸技術(shù)。在 Windows XP 和 Windows Server 2003 上,IIS 限制您只能使用 HTTP。
下面是自承載的缺點:
?
可用性受到限制:服務(wù)只有在應(yīng)用程序運(yùn)行時才能被訪問。
?
功能受到限制:自承載的應(yīng)用程序在對高可用性、易管理性、可靠性、可恢復(fù)性、版本控制和部署方案的支持方面受到一定限制。至少,現(xiàn)有的 WCF 無法提供這些支持,因此在自承載的情況中,您必須自己實現(xiàn)這些功能;例如,默認(rèn)情況下 IIS 提供了這些功能中幾項。
換句話說,對于企業(yè)級方案來說不應(yīng)考慮自承載方式。自承載適用于企業(yè)項目的開發(fā)或演示階段。此外,當(dāng)您希望用戶桌面應(yīng)用程序進(jìn)行相互通信或在點對點情況下,可以對服務(wù)進(jìn)行自承載。本書第 12 章對此進(jìn)行了描述。
第 3 章介紹了幾個自承載的方案示例,這些示例全都使用簡單的控制臺應(yīng)用程序。為了在實際工作環(huán)境中更好地說明自承載,本章提供了一個 WinForms 應(yīng)用程序,該程序所承載的服務(wù)用于跟蹤 QuickReturns Ltd. 案例研究中證券商發(fā)布的報價。
在此方案中,有兩個不同的 WinForms 應(yīng)用程序。一個是證券商管理器應(yīng)用程序,證券商可以使用該程序發(fā)布報價并進(jìn)行證券交易。另一個程序是單獨的 WinForms 應(yīng)用程序,用于跟蹤發(fā)布的報價。如列表 5-1 所示,該程序公開一個服務(wù),所公開的服務(wù)實現(xiàn)了 ITradeTrackingService 約定,從而實現(xiàn)對報價的跟蹤。證券商管理器應(yīng)用程序會在成功通過 TradeService 發(fā)布報價后調(diào)用該服務(wù)。
列表 5-1. TradeTrackingService 的 ServiceContract
using System.ServiceModel;using QuickReturns.StockTrading.ExchangeService.DataContracts;namespace QuickReturns.StockTrading.TradeTrackingService.Contracts{[ServiceContract()]interface ITradeTrackingService{[OperationContract()]void PublishQuote(Quote quote);}}
返回頁首在 Windows 服務(wù)中進(jìn)行承載
在 Windows 服務(wù)中承載 WCF 服務(wù)是一種合理的選擇。不應(yīng)將 Windows 服務(wù)與 WCF 服務(wù)混為一談。它們都使用“服務(wù)”一詞,但卻具有不同的含義。Windows 服務(wù)是由操作系統(tǒng)管理的進(jìn)程。Windows 提供了服務(wù)控制管理器,用于控制操作系統(tǒng)上安裝的服務(wù)。Windows 通過服務(wù)來支持諸如網(wǎng)絡(luò)、USB、遠(yuǎn)程訪問、消息隊列等操作系統(tǒng)功能。您可以使用 Visual Studio 2005,利用 Windows 服務(wù)項目模板(如圖 5-2 所示)創(chuàng)建 Windows 服務(wù)。
圖 5-2. Visual Studio 2005 Windows 服務(wù)項目模板
Windows 服務(wù)項目模板會生成一個項目,其中包含兩個文件:service1.cs 文件和 program.cs 文件。其中 service1.cs 文件包含服務(wù)實現(xiàn),而 program.cs 文件則用于實例化并實質(zhì)上承載 Windows 服務(wù)。要在 Windows 服務(wù)內(nèi)部承載 WCF 服務(wù),只需執(zhí)行 Windows 服務(wù)的 Start() 方法和 Stop() 方法,如列表 5-2 所示。由于啟動 Windows 服務(wù)的范例與啟動 WCF ServiceHost 內(nèi)的服務(wù)相似,因此最后需要將 WCF 服務(wù)的生存期與 Windows 服務(wù)的生存期相連。
列表 5-2. 承載 WCF ServiceHost 的 Windows 服務(wù)
using System;using System.ServiceModel;using System.ServiceProcess;using QuickReturns.StockTrading.ExchangeService;namespace QuickReturns.StockTrading.ExchangeService.Hosts{public partial class ExchangeWindowsService : ServiceBase{ServiceHost host;public ExchangeWindowsService(){InitializeComponent();}protected override void OnStart(string[] args){Type serviceType = typeof(TradeService);host = new ServiceHost(serviceType);host.Open();}protected override void OnStop(){if(host != null)host.Close();}}}
由此可見,編寫用于承載 WCF 服務(wù)的 Windows 服務(wù)非常容易,而且與本章前面的自承載方案相比,它還有幾個好處。另一方面,編寫承載 WCF 服務(wù)的 Windows 服務(wù)也有一些您必須了解的缺點。
首先讓我們看一下優(yōu)點:
?
可以自動啟動:Windows 服務(wù)控制管理器允許將啟動類型設(shè)置為自動,從而可以在 Windows 啟動立即啟動服務(wù),而不必在計算機(jī)上進(jìn)行交互登錄。
?
可以恢復(fù):Windows 服務(wù)控制管理器內(nèi)建了對發(fā)生失敗后重新啟動服務(wù)的支持。
?
安全標(biāo)識:Windows 服務(wù)控制管理器允許您選擇運(yùn)行服務(wù)所使用的特定安全標(biāo)識,包括內(nèi)置的系統(tǒng)或網(wǎng)絡(luò)服務(wù)帳戶。
?
可管理性:通常情況下,Windows 操作員對那些用于進(jìn)行 Windows 服務(wù)安裝和配置的服務(wù)控制管理器和其他管理工具都非常熟悉。這將使 Windows 服務(wù)在實際工作環(huán)境中更容易被采納;但是,為了保證服務(wù)的可維護(hù)性,您可能需要添加某些檢測和日志記錄功能。
?
支持所有綁定和傳輸:自承載并不限制您僅能使用現(xiàn)有的綁定和傳輸技術(shù)。在 Windows XP 和 Windows Server 2003 上,IIS 限制您只能使用 HTTP。
接下來是 Windows 服務(wù)的一些缺點:
?
部署: 必須通過 .NET Framework Installutil.exe 實用工具或通過安裝包中的自定義操作來安裝服務(wù)。
?
功能受到限制:Windows 服務(wù)在對高可用性、易管理性、版本控制和部署方案的支持方面同樣也受到一定限制。實際上,您必須自己編寫自定義代碼來滿足這些要求,而 IIS 在默認(rèn)情況下就帶有這些功能的其中幾項。Windows 服務(wù)確實添加了可恢復(fù)性和一些安全功能,但有些任務(wù)仍然需要您親手去做。
要能夠在服務(wù)控制管理器中安裝服務(wù),必須在項目中添加安裝程序。Visual Studio 2005 允許您方便地完成該操作:
1.
在 Windows 服務(wù)項目中打開 Service 類的設(shè)計器視圖。
2.
單擊設(shè)計器背景以選擇服務(wù)本身,而并非其任何內(nèi)容。
3.
在“屬性”窗口中,單擊屬性列表下灰色區(qū)域中的“添加安裝程序”鏈接,如圖 5-3 所示。默認(rèn)情況下,該操作將在項目中添加一個包含兩個安裝程序的組件類。組件名為 ProjectInstaller,它包含的安裝程序是服務(wù)的安裝程序和該服務(wù)相關(guān)進(jìn)程的安裝程序。
圖 5-3. Windows 服務(wù)項目的“添加安裝程序”功能
4.
訪問 ProjectInstaller 的設(shè)計器視圖,并單擊 ServiceInstaller1。
5.
在“屬性”窗口中,將“ServiceName”屬性設(shè)置為“QuickReturns Exchange 服務(wù)”。
6.
將“StartType”屬性設(shè)置為“自動”,如圖 5-4 所示。
圖 5-4. QuickReturns Exchange 服務(wù)的屬性窗口
7.
訪問 ProjectInstaller 的設(shè)計器視圖,并單擊“serviceProcessInstaller1”。
8.
在“屬性”窗口中,將“帳戶”屬性設(shè)置為“網(wǎng)絡(luò)服務(wù)”,如圖 5-5 所示。
圖 5-5. QuickReturns Exchange 服務(wù)的屬性窗口
為了能夠創(chuàng)建可用于安裝 Windows 服務(wù)的安裝程序,必須向解決方案添加 Visual Studio 安裝程序和部署項目。以下步驟描述了如何向解決方案添加安裝程序和部署項目:
1.
選擇“文件” | “添加” | “新建項目”。
2.
在“新建項目”對話框中,選擇“其他項目類型”類別,選擇“安裝和部署”,然后選擇“安裝項目”,如圖 5-6 所示。
圖 5-6. Visual Studio 2005 安裝項目模板
3.
在解決方案資源管理器中,右鍵單擊安裝項目,指向“添加”,然后選擇“項目輸出”,如圖 5-7 所示。此時將顯示“添加項目輸出組”對話框。
圖 5-7. 添加 Windows 服務(wù)項目輸出
4.
選擇 Windows 服務(wù)項目。
5.
從列表框中,選擇“主輸出”,然后單擊“確定”。
此操作將向安裝項目添加 Windows 服務(wù)的主輸出的項目項?,F(xiàn)在,添加用于安裝可執(zhí)行文件的自定義操作。若要向安裝項目添加自定義操作,請執(zhí)行以下步驟:
1.
在解決方案資源管理器中,右鍵單擊安裝項目,指向“視圖”,然后選擇“自定義操作”,如圖 5-8 所示。此時將顯示“自定義操作”視圖。
圖 5-8. 打開“自定義操作”視圖
2.
右鍵單擊“自定義操作”,選擇“添加自定義操作”。
3.
雙擊列表框中的應(yīng)用程序文件夾將它打開,從 Windows 服務(wù)項目中選擇“主輸出”,然后單擊“確定”。主輸出將添加到自定義操作的所有四個節(jié)點中:安裝、提交、回滾和卸載。
4.
生成安裝項目。
編譯項目時,輸出的是 Microsoft 安裝程序文件 (.msi) ,通過該文件可以將服務(wù)安裝到 Windows 服務(wù)控制管理器中。
注意 本章介紹生成 Windows 服務(wù)和 Windows 服務(wù)安裝程序的基礎(chǔ)知識。如果將 Windows 服務(wù)設(shè)置為在不受限制的 Localsystem 帳戶下運(yùn)行或基本合適的網(wǎng)絡(luò)服務(wù)帳戶下運(yùn)行,就安全最佳方法而言,這并非最佳選擇。通常,操作員能夠在安裝期間選擇憑據(jù),或在安裝之后通過服務(wù)控制管理器管理控制臺管理單元(可以通過 Windows 計算機(jī)管理進(jìn)行訪問)來調(diào)整安全標(biāo)識設(shè)置。有關(guān)開發(fā) Windows 服務(wù)的詳細(xì)信息和最佳方法,請參閱本書第 7 章、MSDN 幫助或 .NET 開發(fā)專著。
返回頁首使用 Internet 信息服務(wù)進(jìn)行承載
在 IIS 上的 Web 服務(wù)開發(fā)長期以來一直是 ASP.NET 的領(lǐng)地。ASP.NET 1.0 發(fā)布后,Web 服務(wù)框架成為它的一部分。Microsoft 利用 ASP.NET HTTP 管道使 Web 服務(wù)在 Windows 平臺上成為現(xiàn)實。遺憾的是,ASP.NET 和 Web 服務(wù)之間的這種緊密耦合在面向服務(wù)的世界中產(chǎn)生了幾個限制,對 HTTP 的依賴性是主要原因。在不同宿主上運(yùn)行 ASP.NET HTTP 管道很困難,因此很少采用這種方案。甚至在此后,ASP.NET Web 服務(wù)(也稱為 ASMX 服務(wù))在部署方案和配置依賴性方面一直是非常面向 Web 的。Microsoft 最初發(fā)布了幾個版本的 Web 服務(wù)增強(qiáng) (WSE),以彌補(bǔ) ASP.NET Web 服務(wù)的某些局限,尤其是消除在實現(xiàn) WS-* 協(xié)議方面的限制。但是,WSE 非常依賴于 ASP.NET Web 服務(wù)實現(xiàn)。
在以前幾章中介紹過,WCF 服務(wù)采用了完全不同的途徑來實現(xiàn)面向服務(wù)。WCF 的統(tǒng)一編程模型基于嚴(yán)格分層的模型,以分解面向 Web 的范例,并使服務(wù)模型和通道層與受支持的傳輸方式斷開連接。此模型允許 WCF 支持幾個不同的宿主,其中 IIS 是最重要的。
構(gòu)建 WCF 是為了支持 Windows XP、Windows Server 2003、Windows Vista 和 Windows Server 2007。自從 IIS 5.1(與 Windows XP 一起發(fā)布)以來,有了很多變化。但是,Microsoft 仍然繼續(xù)支持舊版上的 WCF。這可能是因為 Microsoft .NET Framework 和 CLR 提供的功能所導(dǎo)致的,該功能是構(gòu)建 WCF 的基礎(chǔ)。在以下幾節(jié)中,將介紹不同 IIS 版本的進(jìn)程模型之間的差異和 WCF 服務(wù)的結(jié)果。
IIS 5.1 和 IIS 6.0 核心功能
為了能夠解釋這些差異,我們首先必須解釋 IIS 的核心功能。IIS 長期以來一直支持在一個計算機(jī)上運(yùn)行多個站點和多個應(yīng)用程序。為了做到這一點,IIS 引入了公用地址模型,該模型分為三個主要區(qū)域:
?
站點(注意:與 Windows XP 一起發(fā)布的 IIS 5.1 只支持一個站點。)
?
應(yīng)用程序
?
虛擬目錄
站點綁定到特定方案、網(wǎng)絡(luò)地址和端口組合。IIS 不僅支持 HTTP,而且依據(jù)版本還支持 FTP、NNTP 和 SMTP??梢栽谙嗤军c下和在相同方案、網(wǎng)絡(luò)和端口組合下運(yùn)行多個應(yīng)用程序。應(yīng)用程序的典型 URI 是 http://localhost/MyApplication。虛擬目錄只是映射到站點網(wǎng)絡(luò)空間的文件夾,它可以是文件系統(tǒng)中的其他某處。這樣,就可以使應(yīng)用程序的實際內(nèi)容或代碼與作為相同站點組成部分的其他應(yīng)用程序分隔開來。
在 IIS 6.0 中,Microsoft 對 IIS 進(jìn)程模型做了一些重要更改。IIS 進(jìn)程模型被拆分成可以由站點和應(yīng)用程序共享的應(yīng)用程序池,在這里,每個應(yīng)用程序都運(yùn)行在它自己的應(yīng)用程序域中。“應(yīng)用程序池”是稱為 W3wp.exe 的單獨 Windows 工作進(jìn)程,并且只在它需要啟動時才會啟動。換句話說,IIS 帶有應(yīng)用程序激活模型,它允許 IIS 在它收到與應(yīng)用程序池綁定的特定應(yīng)用程序的請求時啟動該應(yīng)用程序池。這樣,IIS 就能在一個服務(wù)器上承載數(shù)千個應(yīng)用程序,而不必一直運(yùn)行數(shù)千個進(jìn)程。IIS 的激活體系結(jié)構(gòu)在服務(wù)世界中是有趣的模型,本章的“Windows 激活服務(wù)”節(jié)將對此進(jìn)行介紹。
圖 5-9 顯示在 HTTP 協(xié)議堆棧底部的 IIS 6.0 核心體系結(jié)構(gòu)以及在其頂部的至少四個不同進(jìn)程。
圖 5-9. IIS 6.0 核心體系結(jié)構(gòu)
?
Lsass.exe: 負(fù)責(zé) IIS 的安全功能:實現(xiàn) Windows 身份驗證和安全套接字層 (SSL)。
?
Inetinfo.exe: 承載非 HTTP 服務(wù)和 IIS Admin 服務(wù)(包括元數(shù)據(jù)庫)的進(jìn)程。
?
SvcHost.exe: 可以承載操作系統(tǒng)服務(wù)的進(jìn)程;在使用 IIS 的情況下,它承載 Web (HTTP) 服務(wù)。
?
W3wp.exe: 工作進(jìn)程。IIS 可以有多個 W3wp.exe 進(jìn)程,每個應(yīng)用程序池一個。若要支持在單獨進(jìn)程中拆分一個應(yīng)用程序的 Web 園方案,則有多個相同工作進(jìn)程的實例。這可以提供額外的可伸縮性和性能優(yōu)勢。
注意 我們要在這里描述 IIS 6.0 體系結(jié)構(gòu),因為它是發(fā)布 WCF 之前最廣泛使用的 IIS 版本。此外,WCF 支持 IIS 6.0,并且該模型與使用 IIS 7.0 和 Windows 激活服務(wù)時選擇的實現(xiàn)非常類似,本章后面將對此進(jìn)行介紹。IIS 5.1 和 IIS 6.0 之間的主要差異是站點和應(yīng)用程序池的數(shù)量受到限制。IIS 5.1 只支持綁定到一個應(yīng)用程序池的一個站點。
在 IIS 中承載 WCF 服務(wù)
若要在 IIS 中承載 WCF 服務(wù),需要有一個擴(kuò)展名為 .svc 的新物理文件。該文件將服務(wù)與其實現(xiàn)相關(guān)聯(lián),并且是 IIS 自動創(chuàng)建 ServiceHost 的手段。IIS 將接管服務(wù)與 ServiceHost 之間的交互,不必再由您自己實例化和啟動 ServiceHost。.svc 文件的第一行包含一條夾在 ASP.NET <% Page %> 指令內(nèi)的指令,用于告訴承載環(huán)境此文件指向哪個服務(wù)。然后,服務(wù)代碼可以駐留在內(nèi)嵌代碼行內(nèi)(如列表 5-3 所示)、在注冊于 GAC 的單獨程序集中、在駐留于應(yīng)用程序的 Bin 文件夾內(nèi)的程序集中、或者在駐留于應(yīng)用程序的 App_Code 文件夾下的 C# 文件中。最常見方案是在配置文件中定義端點。在 IIS 中,必須在 Web.config 文件中定義端點,下一節(jié)將對此進(jìn)行解釋。
列表 5-3 顯示一個基于前面的 TradeService 服務(wù)的示例 .svc 文件。它有內(nèi)嵌于代碼行內(nèi)的服務(wù)代碼。列表 5-4 顯示一個示例 .svc 文件,其中,代碼駐留于 App_Code 文件夾內(nèi)。
列表 5-3. 包含內(nèi)嵌代碼的 ExchangeServiceInline.svc 文件
<%@ServiceHost Language="C#"Service="QuickReturns.StockTrading.ExchangeService.TradeServiceInline"%>using System;using System.Collections;using System.ServiceModel;using QuickReturns.StockTrading.ExchangeService.Contracts;using QuickReturns.StockTrading.ExchangeService.DataContracts;namespace QuickReturns.StockTrading.ExchangeService{[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single,IncludeExceptionDetailInFaults=true)]public class TradeServiceInline : ITradeService{public Quote GetQuote(string ticker){...}public void PublishQuote(Quote quote){...}}}
列表 5-4. 包含外部代碼的 ExchangeService.svc 文件
<% @ServiceHost language="C#"Service=" QuickReturns.StockTrading.ExchangeService.TradeService"CodeBehind="~/App_Code/TradeService.cs" %>在 IIS 中配置 WCF 服務(wù)
在 IIS 中進(jìn)行承載意味著您必須在要承載服務(wù)的應(yīng)用程序的 Web.config 文件中設(shè)置 WCF 配置。Web.config 文件中的服務(wù)配置類似于自承載服務(wù)。列表 5-5 顯示一個 TradeService 服務(wù)的 Web.config 示例文件。
列表 5-5. 用于配置 IIS 中承載服務(wù)的 Web.config
<?xml version="1.0"?><configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"><system.serviceModel><services><servicename="QuickReturns.StockTrading.ExchangeService.TradeService"behaviorConfiguration="tradeServiceBehavior"><endpoint name="basicHttpBinding"address=""binding="basicHttpBinding"contract="QuickReturns.StockTrading.ExchangeService.?Contracts.ITradeService"/><endpoint name="mexHttpBinding"contract="IMetadataExchange"binding="mexHttpBinding"address="mex" /></service><servicename="QuickReturns.StockTrading.ExchangeService.TradeServiceInline"behaviorConfiguration="tradeServiceBehavior"><endpoint name="basicHttpBinding"address=""binding="basicHttpBinding"contract="QuickReturns.StockTrading.ExchangeService.?Contracts.ITradeService"/><endpoint name="mexHttpbinding"contract="IMetadataExchange"binding="mexHttpBinding"address="mex" /></service></services><behaviors><serviceBehaviors><behavior name="tradeServiceBehavior" ><serviceMetadata httpGetEnabled="true" /></behavior><behavior name="returnFaults"returnUnknownExceptionsAsFaults="true"/></serviceBehaviors></behaviors></system.serviceModel></configuration>
請注意,服務(wù)的 address 屬性為空。.svc 文件確定服務(wù)的 base 地址。但是,可以提供其他字符串用于設(shè)置相對于 .svc 文件的端點地址。例如,可以使用以下格式:
http://localhost:8080/QuickReturns/Exchange.svc/ExchangeService
在配置文件中指定的服務(wù) name 屬性充當(dāng)了對應(yīng)于 ExchangeService.svc 的查找鍵,它告訴承載環(huán)境此配置屬于哪個服務(wù)。端點級別的其他屬性與前面的解釋相同。
在 IIS 中,Web 配置文件可以嵌套在站點、應(yīng)用程序和虛擬目錄內(nèi)。WCF 將接受所有配置文件,并將服務(wù)及其端點合并在一起。這意味著,嵌套的 Web.config 文件將相互疊加,在層次結(jié)構(gòu)的底部讀取的最后一個文件優(yōu)先于在層次結(jié)構(gòu)中更高的文件。
在 IIS 中訪問 ServiceHost
在 IIS 中承載 WCF 服務(wù)的默認(rèn)行為是該 IIS 控制 ServiceHost 的實例化。這將使您無法在消息到達(dá)服務(wù)之前有啟動和關(guān)閉代碼。當(dāng)然,無啟動和關(guān)閉代碼的優(yōu)點是可以減少可能引起錯誤的代碼。IIS 為您提供了在代碼行方面比控制臺應(yīng)用程序更容易的承載環(huán)境。但是,有時仍然需要有避免此限制的手段。要在實例化 ServiceHost 時這樣做并影響 IIS,可以建立您自己的工廠,用于創(chuàng)建自定義宿主。這樣,就可以訪問任何事件或改寫任何方法。
為了支持自定義 ServiceHost 激活,應(yīng)當(dāng)實現(xiàn)自己的 Factory,它繼承自 ServiceHostFactory,這是可以實例化自定義宿主的工廠類。提供該類是為了關(guān)聯(lián) ServiceHost 的事件。您可以使用該類并將該類型作為 Factory 屬性放在 .svc 文件中,如列表 5-6 所示。通過改寫 ServiceHostFactory 類的 CreateServiceHost 方法,可以執(zhí)行與在自承載方案中相似的任務(wù),第 3 章對此進(jìn)行了介紹。在其他方面,這將使您能夠抽象邏輯,以便從外部配置建立說明,或為要使用的基礎(chǔ)庫、項目、部門或公司創(chuàng)建更合適的基類。
列表 5-7 顯示用于創(chuàng)建宿主的 TradeServiceCustomHost 和 TradeServiceCustomHostFactory 的代碼。
列表 5-6. 包含 CustomServiceHostFactory 的 .svc 文件
<% @ServiceHost Language="C#" Debug="true"Service="QuickReturns.StockTrading.ExchangeService.TradeService"Factory="QuickReturns.StockTrading.ExchangeService.TradeServiceCustomHostFactory" %>列表 5-7. TradeServiceCustomHostFactory 和 TradeServiceCustomHostusing System;using System.ServiceModel;using System.ServiceModel.Activation;namespace QuickReturns.StockTrading.ExchangeService{public class TradeServiceCustomHostFactory : ServiceHostFactory{protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses){TradeServiceCustomHost customServiceHost =new TradeServiceCustomHost(serviceType, baseAddresses);return customServiceHost;}}public class TradeServiceCustomHost : ServiceHost{public TradeServiceCustomHost(Type serviceType, params Uri[]baseAddresses): base(serviceType, baseAddresses){}protected override void ApplyConfiguration(){base.ApplyConfiguration();}}}回收
在 IIS 中承載 WCF 服務(wù)時,WCF 服務(wù)可以使用 ASP.NET 應(yīng)用程序的所有功能。您必須知道這些功能,因為它們會在服務(wù)世界中導(dǎo)致意外的行為。主要功能之一是應(yīng)用程序回收,包括應(yīng)用程序域回收和進(jìn)程回收。通過 IIS 管理控制臺,可以在希望發(fā)生回收時配置不同的規(guī)則??梢詾閮?nèi)存、時間和請求處理數(shù)量設(shè)置某些閾值,如圖 5-10 所示。當(dāng) IIS 回收工作進(jìn)程時,還將回收工作進(jìn)程中的所有應(yīng)用程序域。通常,當(dāng)基于 ASP.NET 的 Web 應(yīng)用程序中的關(guān)鍵文件更改時,應(yīng)用程序域也將回收。例如,在更改 Web.config 文件或 Bin 文件夾中的程序集時,將發(fā)生該操作。
圖 5-10. 應(yīng)用程序池回收設(shè)置
注意 此處描述的進(jìn)程回收包括 Windows Server 2003 中的回收。若要在 Windows XP 和 IIS 5.1 中啟用進(jìn)程回收,可以從 Microsoft 網(wǎng)站下載 IIS 5.0 進(jìn)程回收工具。進(jìn)程回收工具作為服務(wù)在運(yùn)行 IIS 5.0 或 IIS 5.1 的計算機(jī)上運(yùn)行。
修改 .svc 文件之后,還將回收應(yīng)用程序域。承載環(huán)境將嘗試按時正常關(guān)閉所有 WCF 服務(wù)的打開連接。如果由于某種原因使服務(wù)無法按時關(guān)閉,系統(tǒng)將強(qiáng)制中止它們。通過 HostingEnvironmentSettings 配置設(shè)置,可以影響回收的行為,如列表 5-8 所示。idleTimeout 設(shè)置確定應(yīng)用程序域在回收前的空閑時間長度(秒)。shutdowntimeout 設(shè)置確定正常關(guān)閉應(yīng)用程序前的時間長度(秒)。發(fā)生此超時后,它將強(qiáng)制應(yīng)用程序關(guān)閉。
列表 5-8. 包含回收設(shè)置的 hostingenvironment 節(jié)的 Web.config
<system.web><hostingEnvironment idleTimeout="20"shutdownTimeout="30"/></system.web>
使用 WCF 會話時,理解這些回收功能很重要。通常,在安全和可靠消息方案中有這種情況,本書的第 6 章和第 8 章將對此進(jìn)行介紹。默認(rèn)情況下,WCF 將會話狀態(tài)存儲在內(nèi)存中。這是與 ASP.NET 會話狀態(tài)不同的實現(xiàn),它沒有需要切換到持久會話狀態(tài)存儲的配置。但在安全和可靠消息方案中,您可以并且應(yīng)當(dāng)受益于 ASP.NET 實現(xiàn)。通過使用 WCF 的 ASP.NET 兼容性功能,可以獲得 ASP.NET 會話狀態(tài)的 SQL Server 和狀態(tài)服務(wù)器實現(xiàn),以支持企業(yè)可用的方案。在下一節(jié)中,將介紹如何受益于 WCF ASP.NET 兼容性模式。
ASP.NET 兼容性模型
如果在負(fù)載平衡或者甚至 Web 園的環(huán)境中承載 WCF 服務(wù),并且在該環(huán)境中后續(xù)的會話請求可以被此環(huán)境內(nèi)的不同宿主或進(jìn)程處理,則需要對會話狀態(tài)進(jìn)行進(jìn)程外持久存儲。最新的 WCF 不支持會話狀態(tài)的持久存儲。相反,WCF 將它的所有會話狀態(tài)存儲在內(nèi)存中。如果在 IIS 中承載 WCF 服務(wù),最后可以使用回收方案,上一節(jié)對此進(jìn)行了描述。WCF 依賴于會話狀態(tài)的 ASP.NET 實現(xiàn),而不是為會話全部再次建立持久存儲。此方式有一個嚴(yán)重的限制:使服務(wù)僅限于 HTTP。
ASP.NET 會話狀態(tài)不是受 ASP.NET 兼容性模式支持的唯一功能。它還支持諸如 HttpContext、globalization 和模擬等功能,就像用于 ASP.NET Web 服務(wù) (ASMX) 一樣。有關(guān)啟用進(jìn)程外會話狀態(tài)的特定于 ASP.NET 的功能,請參考 MSDN 幫助。
若要查看 ASP.NET 兼容性模式的限制,必須用 AspNetCompatibilityRequirements 屬性顯式標(biāo)記服務(wù),如列表 5-9 所示。
列表 5-9. AspNetCompatibilityRequirements 屬性
namespace QuickReturns.StockTrading.ExchangeService{[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single,ReturnUnknownExceptionsAsFaults=true)][AspNetCompatibilityRequirements(RequirementsMode=AspNetCompatibilityRequirementsMode.Allowed)]public class TradeService : ITradeService{...}}
AspNetCompatibilityRequirementsMode 屬性有以下允許值。
表 5-1. AspNetCompatibilityRequirementsMode 屬性的值
值 說明
NotAllowed
指示服務(wù)可能“永遠(yuǎn)不能”運(yùn)行在 ASP.NET 兼容性模式中。如果在方案中服務(wù)實現(xiàn)不能在 ASP.NET 兼容性模式中工作(例如,在服務(wù)不是為 HTTP 生成的方案中),則必須設(shè)置此項。
Allowed
指示服務(wù)“可能”運(yùn)行在 ASP.NET 兼容性模式中。只有當(dāng)您知道服務(wù)可能在此模式中工作時,才能選取此值。
Required
指示服務(wù)“必須”運(yùn)行在 ASP.NET 兼容性模式中。如果服務(wù)需要進(jìn)行持久會話存儲,請選取此值。
選擇“Required”選項時,WCF 將驗證服務(wù)的所有受支持的端點都是 HTTP 端點,并且,如果它們不是,則會在 ServiceHost 初始化期間產(chǎn)生異常。除了 AspNetCompatibilityRequirements 屬性以外,還必須設(shè)置 aspNetCompatibilityEnabled,如列表 5-10 所示。
列表 5-10. 啟用了 ASP.NET 兼容性的配置
<?xml version="1.0"?><configurationxmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"><system.serviceModel><serviceHostingEnvironment aspNetCompatibilityEnabled="true"/><services>...</services><behaviors>...</behaviors></system.serviceModel></configuration>
注意 本書附帶的示例代碼包含在 ExchangeServiceInline.svc 文件中承載的 TradeService 服務(wù),它被配置為在 ASP.NET 兼容性模式中運(yùn)行。您可以在第 5 章的解決方案文件(請參考示例代碼下載鏈接)中找到它。
Windows XP 和 IIS 5.1
Windows 2000 附帶的 IIS 5.0 拆分了 IIS 進(jìn)程模型,并引入了工作進(jìn)程。此更改的主要原因是為了隔絕應(yīng)用程序,以便 IIS 可以承載相互依賴較少的不同應(yīng)用程序。IIS 5.0 與 Windows 2000 一起發(fā)布,而 IIS 5.1 與 Windows XP 一起發(fā)布。WCF 不支持在帶 IIS 5.0 的 Windows 2000 上承載服務(wù);因此,我們將只詳細(xì)考查 IIS 5.1。IIS 5.1 受支持,但它有僅一個站點的限制,并且每個應(yīng)用程序都運(yùn)行在一個稱為 aspnet_wp.exe 的工作進(jìn)程中。IIS 5.1 對于開發(fā) ASP.NET 網(wǎng)站和 WCF 服務(wù)是很好的版本。它不是為企業(yè)使用而準(zhǔn)備的,因為它有連接限制,并且只運(yùn)行在早期的 Windows 版本或 Windows XP 的客戶端版本上。在本章中,我們將討論 IIS 5.1。
在圖 5-11 中,可以看到 IIS 5.1 的進(jìn)程模型。體系結(jié)構(gòu)被拆分成兩部分。左側(cè)的 W3svc.exe 承載 HTTP 偵聽器、啟動工作進(jìn)程并管理配置。另一側(cè)的工作進(jìn)程則使 IIS 5.1 能夠承載托管的 .NET 應(yīng)用程序,在這里,ASPNET_ISAPI.dll 負(fù)責(zé)創(chuàng)建托管 .NET 應(yīng)用程序域。請注意,在 Windows XP 上,W3svc.exe Windows 服務(wù)與 SMTP 和 FTP 服務(wù)一起承載在 SvcHost.exe 進(jìn)程中。
圖 5-11. IIS 5.1 進(jìn)程模型體系結(jié)構(gòu)
注意 不必有 IIS 即可運(yùn)行 ASP.NET 和 WCF 服務(wù)。例如,可以使用 Visual Studio 2005 附帶的 ASP.NET 開發(fā) Web 服務(wù)器。在發(fā)布 Windows XP 時,Visual Studio 還沒有此功能。必須使用 IIS 5.1 才能在 Windows XP 上開發(fā) Web 應(yīng)用程序。
Windows Server 2003 和 IIS 6.0
到 Windows Server 2003 時,Microsoft 引入了內(nèi)核模式 HTTP 堆棧,稱為 HTTP.SYS。HTTP.SYS 通過 W3svc.exe 插入 IIS 6.0 體系結(jié)構(gòu)中。W3svc.exe 是用戶模式組件,用于橋接內(nèi)核模式的 HTTP.SYS 實現(xiàn),并將它連接到在 IIS 5.1 中已有的進(jìn)程和配置管理系統(tǒng)。到 IIS 6.0 時,應(yīng)用程序池的概念更加普及。盡管在 IIS 5.1 中只有托管 (ASP.NET) 應(yīng)用程序可以承載在單獨的應(yīng)用程序池中,但在 IIS 6.0 中所有類型的應(yīng)用程序都可以承載在單獨的應(yīng)用程序池中。ASPNET_ISAPI.dll 仍然負(fù)責(zé)啟動在托管 ASP.NET 世界中的應(yīng)用程序域。圖 5-12 說明了 IIS 6.0 中的進(jìn)程模型。
圖 5-12. 在 IIS 6.0 中承載的 IIS 6.0 進(jìn)程模型體系結(jié)構(gòu)
下面的詳細(xì)步驟說明如何在 IIS 6.0 中承載 .NET 3.0 WCF 服務(wù)。我們將使用在前面描述的示例在 IIS 6.0 中進(jìn)行承載。
1.
請在示例代碼文件夾中打開包含 ExchangeServiceIISHost 文件夾的文件夾。
2.
下一步是在 IIS 中為該文件夾創(chuàng)建虛擬目錄。可以通過 IIS 管理器導(dǎo)航;但為簡單起見,只需右鍵單擊此文件夾,然后選擇“屬性”。
3.
一旦出現(xiàn)屬性對話框,請單擊“Web 共享”選項卡。只需單擊“共享此文件夾”單選按鈕,將顯示“編輯別名”。將別名從“ExchangeServiceIISHost”重命名為“ExchangeService”??梢詥⒂谩澳夸洖g覽”以使您更容易查看并單擊網(wǎng)站中的項目。通常,這是只用于開發(fā)的設(shè)置;關(guān)于 Web 共享設(shè)置,請參見圖 5-13。
警告 此設(shè)置允許用戶瀏覽站點中的所有文件,就像使用 Windows 資源管理器一樣。雖然是好功能,但請在實際運(yùn)行環(huán)境中使用時一定要小心。
圖 5-13. Web 共享“編輯別名”對話框
1.
此時,只需單擊“確定”幾次,即可退出對話框?,F(xiàn)在,應(yīng)當(dāng)可以通過以下網(wǎng)址 http://localhost/ExchangeService 訪問站點。但是,我們?nèi)匀槐仨殭z查為此站點設(shè)置的 ASP.NET 的版本。如果只安裝了 .NET 2.0(就是說從未安裝 .NET 1.1),則應(yīng)當(dāng)不用做其他操作,但檢查一下是有好處的。因此,請打開 IIS 管理器(“開始” | “控制面板” | “管理工具” | “Internet 信息服務(wù)”)。一旦看到“屬性”對話框,請單擊“ASP.NET”選項卡,然后使用下拉框?qū)?ASP.NET 的版本切換到 .NET 3.0(受支持的版本)2.0.50727(RTM 版本)。
2.
對于我們的示例,有一個額外的步驟,用于使“匿名”請求能夠訪問資源。匿名請求是指沒有與 HTTP 請求關(guān)聯(lián)的標(biāo)識或 Windows 主體的任何請求。
單擊“目錄安全”選項卡,然后在對話框的“匿名訪問和身份驗證控制”區(qū)域下單擊“編輯”。確保選項“匿名訪問”被啟用。這將允許我們的示例運(yùn)行,而不會涉及如何為請求提供身份驗證憑據(jù)。
此時,如果使用 Internet Explorer 瀏覽到 http://localhost/ExchangeService 位置,將能夠看到一個目錄列表(只要設(shè)置與上一圖中相似)。如果單擊 Service.svc,將轉(zhuǎn)到由 *.svc 擴(kuò)展的 System.ServiceModel.Activiation.HttpHandler 生成的默認(rèn)幫助屏幕。
此時,將執(zhí)行與在客戶端應(yīng)用程序中相同的步驟,要么直接通過使用 Svcutil.exe 實用程序生成代理類,要么右鍵單擊項目并通過“添加服務(wù)”加載項功能生成代理,本章后面的“使用 WCF 服務(wù)”一節(jié)將對此進(jìn)行介紹。
此示例附帶的解決方案有完整的控制臺客戶端,它可以調(diào)用我們剛創(chuàng)建的 WCF 服務(wù)。
在 IIS 7.0 上進(jìn)行承載
IIS 7.0 推動了 Web 服務(wù)器領(lǐng)域中的又一重大演進(jìn)??梢栽趫D 5-14 中看到兩個重要改變。第一,現(xiàn)在特定于協(xié)議的偵聽器適配器支持所有四種 WCF 傳輸,而不是僅限于 IIS 6.0 中的 HTTP 傳輸。此外,出現(xiàn)了稱為 Windows 激活服務(wù) (WAS) 的新操作系統(tǒng)服務(wù)。W3svc.exe 和 WAS 都運(yùn)行在稱為 SvcHost.exe 的操作系統(tǒng)宿主的內(nèi)部。為了能夠?qū)?IIS 6.0 進(jìn)程模型的強(qiáng)大功能與 WCF 結(jié)合使用,則需要進(jìn)行這些更改。您可能會問“為什么?”好的,WCF 服務(wù)也工作在 IIS 5.1 和 IIS 6.0 中,那么,通過在 IIS 中推廣進(jìn)程模型和激活功能可以獲得什么好處呢?很簡單:通過推廣激活概念使它與協(xié)議無關(guān),而不是綁定到 HTTP,可以將平臺的激活功能擴(kuò)展到幾乎所有傳輸類型。
圖 5-14. IIS 7.0 進(jìn)程模型體系結(jié)構(gòu)
在新發(fā)布的 Windows Vista 和 Windows Server 2007 中,Microsoft 轉(zhuǎn)移了 IIS 的進(jìn)程管理和配置功能,并使它在操作系統(tǒng)內(nèi)部普遍可用。這使建立于該模型上的任何應(yīng)用程序都能基于傳入的消息使用運(yùn)行時激活和生成工作進(jìn)程的功能。
HTTP、TCP/IP、命名管道和 MSMQ 的特定于協(xié)議的偵聽器適配器運(yùn)行于它們自己的進(jìn)程內(nèi)部,并將特定傳輸橋接到 WAS。偵聽器適配器要求 WAS 激活工作進(jìn)程,然后將實際通信轉(zhuǎn)交給這些工作進(jìn)程內(nèi)部的特定協(xié)議處理程序。因此,WAS 現(xiàn)在擁有 W3svc.exe 中具備的所有功能。通過將此責(zé)任拆分成多個單獨的進(jìn)程,其他三種傳輸也受益于過去內(nèi)置在 IIS 6.0 中但只用于 HTTP 的進(jìn)程模型和激活功能。總而言之,使用 IIS 7.0 可以跨越 IIS 中提供的任何傳輸類型承載任何 WCF 服務(wù)。在下一節(jié)中,將介紹 WAS 激活的工作原理,以及如果希望在 Windows Vista 或 Windows Server 2007 上的 IIS 7.0 和 WAS 內(nèi)部承載 WCF 服務(wù)時必須注意的事項。
若要在 IIS 7.0 內(nèi)部承載本書中使用的 TradeService,您要做的就是配置 IIS,并將為 IIS 6.0 創(chuàng)建的 .svc 文件放在您將創(chuàng)建的站點中。利用以下步驟您將能夠在 Windows Server 2007 上配置 IIS 7.0、WAS 和 .NET Framework 3.0,并使 TradeService 運(yùn)行在 IIS 7.0 內(nèi)部:
1.
啟動服務(wù)器管理器(位于“管理工具”中)。
2.
向服務(wù)器添加 Web 服務(wù)器 (IIS) 角色。
3.
注意,安裝 Web 服務(wù)器時將自動添加 WAS。
4.
在 IIS 的“詳細(xì)設(shè)置”屏幕上,選擇“ASP.NET”,并在“安全”下選擇“基本和 Windows 身份驗證”。讓其余選項保持默認(rèn)設(shè)置。
這將安裝 IIS 和 WAS。
5.
默認(rèn)情況下,Windows Server 2007 不附帶安裝 .NET Framework 3.0。若要安裝 .NET Framework 3.0,請打開“添加功能向?qū)А保ā翱刂泼姘濉?| “程序” | “Windows 功能”)。
6.
單擊“添加功能”,并選擇“NET Framework 3.0”(如果要用 WCF MSMQ 傳輸進(jìn)行實驗)。還應(yīng)選擇“MSMQ”。
現(xiàn)在,就可以準(zhǔn)備在 IIS 7.0 上運(yùn)行 WCF 服務(wù)了。下一步是在 IIS 中創(chuàng)建在其中運(yùn)行服務(wù)的應(yīng)用程序。這需要使用 Internet 信息服務(wù) (IIS) 管理器??梢栽凇伴_始”菜單的“管理工具”中找到 IIS 管理工具。然后,導(dǎo)航到您的服務(wù)器和您的網(wǎng)站,最后找到默認(rèn)網(wǎng)站。右鍵單擊默認(rèn)網(wǎng)站,并選擇“創(chuàng)建應(yīng)用程序”,如圖 5-15 所示。
圖 5-15. 在 IIS 管理器中新建應(yīng)用程序
現(xiàn)在,需要指定本地計算機(jī)上的一個文件夾,用于承載應(yīng)用程序的 .svc 文件。如圖 5-16 所示,可以為應(yīng)用程序指定一個用于訪問服務(wù)的名稱 (http://localhost/<chosenname>) 和駐留文件的文件夾,然后選擇應(yīng)用程序池。
圖 5-16. 在 IIS 管理器中為新應(yīng)用程序設(shè)置屬性
如果正確完成所有操作,則可以通過 IIS 7.0 訪問您的服務(wù)。通過導(dǎo)航到新創(chuàng)建的應(yīng)用程序可以測試實際效果,例如:
http://localhost:8080/QuickReturns/Exchange.svc/ExchangeService
Windows 激活服務(wù)
WAS 使您能夠承載任何 WCF 服務(wù),以便在 IIS 模型內(nèi)部支持任何傳輸。WAS 接管了最初 IIS 6.0 中 W3svc.exe Windows 服務(wù)的創(chuàng)建工作進(jìn)程和提供配置的工作(并運(yùn)行在 Inetinfo.exe 進(jìn)程的內(nèi)部)。WAS 和 IIS 現(xiàn)在共享用于定義站點、應(yīng)用程序、應(yīng)用程序池和虛擬目錄的配置存儲區(qū)。在這一節(jié)中,我們將介紹用 WAS 激活的過程,如圖 5-17 所示。
默認(rèn)情況下,如果沒有向新啟動的服務(wù)器發(fā)出請求,Windows 將運(yùn)行五個服務(wù)(如果啟用了所有協(xié)議)。下面是這些 Windows 服務(wù):
?
WAS
?
萬維網(wǎng)發(fā)布服務(wù)(承載偵聽器適配器)
?
NET.TCP 偵聽器適配器
?
NET.PIPE 偵聽器適配器
?
NET.MSMQ 偵聽器適配器
圖 5-17. 用 WAS 為 HTTP 請求激活工作進(jìn)程
偵聽器適配器啟動時,它們將向 WAS 進(jìn)行注冊,并接收對應(yīng)其特定協(xié)議的 WAS/IIS 配置。由此,偵聽器適配器可以感知它們應(yīng)當(dāng)支持的站點和應(yīng)用程序。然后,每個偵聽器適配器開始偵聽由配置提供的合適端口,這樣,它就可以將進(jìn)入的請求分派給合適的應(yīng)用程序。
一旦第一個請求進(jìn)入,偵聽器適配器就將調(diào)用 WAS 以激活工作進(jìn)程,其中包括作為請求目標(biāo)的特定應(yīng)用程序的托管 .NET 應(yīng)用程序域。
然后,請求被遞交給工作進(jìn)程內(nèi)部的所謂應(yīng)用程序域協(xié)議處理程序,以處理請求并將響應(yīng)返回給客戶端。它不關(guān)心請求是 WCF 服務(wù)請求、ASP.NET 請求還是對 IIS 7.0 的任何其他請求。創(chuàng)建激活進(jìn)程是為了使工作進(jìn)程能夠在請求到來時啟動。
為了在應(yīng)用程序域內(nèi)部啟動 WCF ServiceHost,應(yīng)用程序域協(xié)議處理程序必須調(diào)用稱為 EnsureServiceAvailable 的靜態(tài)方法。該方法與協(xié)議無關(guān),并且將激活整個服務(wù),包括所有端點和傳輸(而不僅是調(diào)用該方法的協(xié)議處理程序的傳輸)。
注意 在偵聽器適配器和協(xié)議處理程序的內(nèi)部,尤其對于 HTTP 和 TCP 協(xié)議發(fā)生了一些不可思議的事情。在單獨進(jìn)程中所承載的偵聽器適配器內(nèi)部,套接字被打開。然后,當(dāng)?shù)谝粋€請求到來時,實際上套接字將被從偵聽器適配器轉(zhuǎn)交給應(yīng)用程序域協(xié)議處理程序,以便能夠處理第一個請求和任何后續(xù)請求!
承載方案
本章前一節(jié)介紹了用于承載服務(wù)的不同方案。此外,還介紹了哪種承載方案可以滿足哪些業(yè)務(wù)要求(或非功能性要求)。通常,可以采用“為什么不是 IIS?”的方法。這是什么意思呢?IIS 在功能方面提供了最佳選擇,尤其是在服務(wù)要公開多個系統(tǒng)所依賴的關(guān)鍵業(yè)務(wù)功能的情形下。如果選擇 IIS,就必須選擇使用 IIS 6.0 還是 IIS 7.0,由于新的激活功能,顯然應(yīng)當(dāng)選擇后者。在需要進(jìn)程間通信的情形下,WinForms 和控制臺應(yīng)用程序都是可行方案。Windows 服務(wù)本質(zhì)上只是 IIS 的替代方案,并且通常在建立服務(wù)器產(chǎn)品或需要對服務(wù)的激活和壽命期進(jìn)行高級控制時使用它。
在下一節(jié)中,我們將介紹為使用服務(wù)而提供的選項,以及承載方案對使用者端意味著什么。
返回頁首使用 WCF 服務(wù)
在前一節(jié)中,我們介紹了不同的承載方案。而所選的承載方案會影響使用者端。使用 WCF 服務(wù)可以有多種方式。如果客戶端正在使用 WCF,則生產(chǎn)效率將非常高,因為 WCF 附帶的工具可以生成用于調(diào)用 WCF 服務(wù)的代理類。WCF 主要通過 SvcUtil.exe 來提供標(biāo)準(zhǔn)和工具支持,SvcUtil.exe 將作為主要的元數(shù)據(jù)解釋工具。它與 WCF Framework 利用反射詢問具有合適屬性的類型這一功能結(jié)合在一起,使生成和使用 WCF Framework 與現(xiàn)有框架相比,復(fù)雜性更低。此外,Visual Studio 2005 帶有易用的功能,可以向項目添加服務(wù)引用,并可無縫地自動生成代理類。
實際上,您可以有以下選擇:
?
從服務(wù)檢索 WSDL,并手動制作代理來調(diào)用服務(wù)。這是客戶端沒有 WCF 時的典型方案。關(guān)于此方案,請參考第 13 章。
?
使用 Visual Studio 2005 的“添加服務(wù)引用”功能,并讓它生成要在客戶端上使用的代理。
?
使用 SvcUtil.exe 工具生成代理類。
在下面幾節(jié)中,我們將介紹后面兩個選項:Visual Studio 2005 和 SvcUtil.exe。
服務(wù)代理
服務(wù)代理使您能夠以面向?qū)ο蟮姆绞绞褂梅?wù)。代理類對服務(wù)所使用的通信模型進(jìn)行抽象,這樣,客戶端開發(fā)人員不會直接意識到他正在與(遠(yuǎn)程)服務(wù)對話。這就像在調(diào)用本地代碼一樣。代理類可實現(xiàn)服務(wù)的服務(wù)接口,從而使您能夠調(diào)用服務(wù)接口上的方法,就好像它們是本地方法。代理是為服務(wù)接口中使用的任何自定義類型而生成的。列表 5-11 包含 QuickReturns Ltd. 示例中為 TradeService 服務(wù)生成的代理的片段。它演示了在客戶端有一個可用 Quote 映射到服務(wù)器端上的 Quote 對象,盡管它們是不同的類。Quote 對象按照合同進(jìn)行序列化,以便它在服務(wù)端可以序列化為服務(wù)端版本的 Quote 數(shù)據(jù)合同。此外,可以看到 GetQuote 和 PlaceQuote 方法調(diào)用一個基類,而該基類最后將以所配置的傳輸方式跨服務(wù)邊界進(jìn)行調(diào)用。
列表 5-11. 為 TradeService 服務(wù)生成的示例代理
namespace SimpleClientWithProxy.ExchangeService{[DataContract()]public partial class Quote : object, IExtensibleDataObject{// 省略了打印代碼中的 Quote 數(shù)據(jù)成員,見示例代碼}}[GeneratedCode("System.ServiceModel", "3.0.0.0")][ServiceContract()]public interface ITradeService{[OperationContract(Action ="http://tempuri.org/ITradeService/GetQuote",ReplyAction ="http://tempuri.org/ITradeService/GetQuoteResponse")]Quote GetQuote(string ticker);[OperationContract(Action ="http://tempuri.org/ITradeService/PublishQuote",ReplyAction ="http://tempuri.org/ITradeService/PublishQuoteResponse")]void PublishQuote(Quote quote);}[GeneratedCode("System.ServiceModel", "3.0.0.0")]public interface ITradeServiceChannel : ITradeService, IClientChannel{}[GeneratedCode("System.ServiceModel", "3.0.0.0")]public partial class TradeServiceClient : ClientBase<ITradeService>,ITradeService{// 省略了打印代碼中的一些構(gòu)造函數(shù),見示例代碼public SimpleClientWithProxy.ExchangeService.QuoteGetQuote(string ticker){return base.Channel.GetQuote(ticker);}public void PublishQuote(SimpleClientWithProxy.ExchangeService.Quote quote){base.Channel.PublishQuote(quote);}}使用 Visual Studio 2005
與創(chuàng)建 ASP.NET 代理相似,如果在 IDE 中右鍵單擊項目,可以看到三個用于添加引用的選項,如圖 5-18 所示。
圖 5-18. 添加對 WCF 服務(wù)的引用
您要查找的選項是“添加服務(wù)引用”。此菜單選項是 SvcUtil.exe 實用程序周圍的包裝(下一節(jié)將對此進(jìn)行介紹),它實際上將產(chǎn)生具有所需參數(shù)的進(jìn)程。一旦選擇了“添加服務(wù)引用”,就將看到在圖 5-19 中顯示的對話框。
圖 5-19. “添加服務(wù)引用”對話框
一旦在對話框中單擊“確定”,該加載項將產(chǎn)生 SvcUtil.exe,并生成需要的代理類和必需的配置文件(或修改它),并將所需引用添加到項目中?,F(xiàn)在,項目的引用將列出 WCF 程序集。
注意 要使該操作有效,必須運(yùn)行 Windows ServiceHost,或更改 URL 以指向 IIS 中承載的任何服務(wù)(使 URL 指向任何 .svc 文件)。
現(xiàn)在,即可開始在服務(wù)層中安排第一個服務(wù)調(diào)用。示例解決方案文件按以下方式進(jìn)行了修改,以幫助您查看代碼:
?
解決方案上的“設(shè)置啟動項目”已選中多個項目。
?
ExchangeServiceIISHost Web 項目的“使用動態(tài)端口”已設(shè)置為 False,并且“端口號”使用硬編碼設(shè)置。
需要將對象的簡短說明添加到項目中。在 SvcUtil.exe(“添加服務(wù)引用”)調(diào)用期間,在項目中自動添加了下面的項和引用。其中一些只是為了幫助 Visual Studio 集成;其他則是通過代理直接使用服務(wù)所必需的。
?
服務(wù)引用:在此文件夾中,我們添加了兩項。第一,“映射”文件為通過 Visual Studio 加載項生成和重新生成代理提供支持。第二,ExchangeService.cs 代表具體的代理類實現(xiàn),它利用命名空間 System.ServiceModel 提供簡單的集成類。
?
配置:第二項是 App.config 文件。App.config 文件(在 Visual Studio 構(gòu)建過程中將自動重命名為“<程序集名稱>.config”)提供運(yùn)行時 WCF 配置參數(shù)。如果看一看此文件的內(nèi)部,將發(fā)現(xiàn)大量設(shè)置,其中很多是默認(rèn)的或多余的。常見做法是,在生成該文件后使用 WCF SvcConfigEditor.exe 編輯器實用程序管理該文件。此實用程序位于 Windows SDK Bin 目錄下。還可以在“Visual Studio 2005 工具”菜單中找到它。圖 5-20 顯示了該工具的實現(xiàn)。
圖 5-20. SvcConfigEditor.exe
從圖 5-20 中的“SvcConfigEditor.exe”屏幕上可以看到,通過配置可以管理數(shù)量巨大的詳細(xì)屬性。這是 WCF 的最強(qiáng)大的優(yōu)勢之一:能夠?qū)唧w實現(xiàn)的很多方面進(jìn)行控制,而不會影響核心服務(wù)實現(xiàn)。服務(wù)實現(xiàn)不需要更改即可從基于 HTTP 的協(xié)議遷移到另一個面向消息的協(xié)議這一概念就是一個示例。若要獲得有關(guān)該工具的功能的詳細(xì)信息,請參考本書的第 3 章、第 6 章或 MSDN 幫助。
命令行實現(xiàn)
一種替代方法是直接利用 SvcUtil.exe 實用程序,而不是 Visual Studio 加載項。在從 Visual Studio 中直接執(zhí)行時,Visual Studio 加載項將再次帶參數(shù)調(diào)用 SvcUtil.exe 以生成代理。通過查看“輸出”窗口,并在下拉列表中將“顯示輸出”設(shè)置為“服務(wù)引用”,可以看到命令行和該命令的結(jié)果。
若要手動生成,可通過選擇“開始” | “所有程序” | “Microsoft Windows SDK” | “CMD”,以選擇 CMD 窗口。此命令提示符很有用,因為它的路徑被設(shè)置為 SDK 工具和實用工具所在的二進(jìn)制目錄。
您將使用 SvcUtil.exe 命令行工具生成可在 SimpleClientWithProxy 項目中使用的兩個輸出。但是,本章附帶的示例代碼使用了上一節(jié)介紹的“添加服務(wù)引用”方法。此處介紹的步驟解釋了如何生成與“添加服務(wù)引用”相同的輸出。它生成的輸出文件是客戶端代理源代碼文件和應(yīng)用程序配置文件。然后,這些文件將合并到客戶端項目中。SvcUtil.exe 可以生成這二者。在此示例中,以下命令(它只有一行,盡管此處顯示多行)將產(chǎn)生代理類和配置文件:
列表 5-12. 用于產(chǎn)生代理類和配置文件的命令
svcutil /config:app.config /out:"ExchangeService.cs" /language:csharp/n:*,SimpleClientWithProxy.ExchangeService"http://localhost/ExchangeService/?ExchangeService.svc"
警告 要讓此操作有效,需要一個正在運(yùn)行的 Windows ServiceHost 版本,或者必須更改 URL 以指向 IIS 中承載的任何服務(wù)(使 URL 指向本章討論的任何 .svc 文件)。此外,服務(wù)需要 metadataexchange 端點,第 3 章對此進(jìn)行了介紹。本章附帶的代碼配置了 metadataexchange 端點,但在本章中它不在內(nèi)嵌代碼內(nèi)!
命令有很好的自解釋功能。/n 開關(guān)表明生成的代理類應(yīng)當(dāng)屬于哪個命名空間。最后一個參數(shù)是可以在其上找到架構(gòu)信息的服務(wù)端點的 URL。注意,?wsdl 可以替換為 ?mex,因為 SvcUtil.exe 同時支持兩種發(fā)現(xiàn)方法。通過從命令提示符執(zhí)行 svcutil.exe /?,可以獲得進(jìn)一步幫助。
下一步是獲得輸出文件 ExchangeService.cs 和 App.config,并將它們合并到項目中。通過從 Visual Studio 2005 中的“項目”菜單選擇“添加現(xiàn)有項”,可以將第一個文件 ExchangeService.cs 直接添加到項目中。
第二個文件必須作為應(yīng)用程序配置 (App.config) 文件添加到項目中。如果項目還沒有 App.config 文件,則可以從“項目”菜單中再次選擇“添加現(xiàn)有項”以添加該文件。如果已有現(xiàn)成的 App.config,則必須合并 system.serviceModel 部分,以確保具備所有適當(dāng)?shù)淖釉亍?div style="height:15px;">
在了解了有關(guān)承載的可選方案的所有內(nèi)容后,您將能夠構(gòu)建 WCF 應(yīng)用程序,并在任何需要的地方承載它們。此外,您還能夠解釋在最新可用環(huán)境(Windows Vista 或 Windows Server 2007 上的 IIS 7.0 與 WAS)中進(jìn)行承載的好處。
Chris Peiris 是應(yīng)用程序集成方面的熱心作者。他在澳大利亞的 Avanade 公司擔(dān)任解決方案設(shè)計師。他經(jīng)常在有關(guān) Microsoft 技術(shù)的專業(yè)開發(fā)人員會議上發(fā)言。Chris 為包括 15Seconds、ASPToday、Wrox (Apress) 和 Developer Exchange (DevX) 在內(nèi)的各種在線刊物編寫了很多文章、評論和專欄。他還與他人共同編寫了很多有關(guān) WCF、Web 服務(wù)、UDDI、C#、IIS、Java 和安全方面的書籍。Chris 目前主要關(guān)注 WCF、WinFX、IBM Message Broker、BizTalk 和其他 EAI 實現(xiàn)。若要查看 Chris 的完整作品列表和詳細(xì)聯(lián)系信息,請訪問
Dennis Mulder 于 1997 年開始他的職業(yè)生涯,專注于 Microsoft 技術(shù)。在 2004 年 8 月,他開始服務(wù)于 Avanade,這是一家 Microsoft 和 Accenture 的合資公司。目前,他主要關(guān)注 Microsoft 平臺的幾個領(lǐng)域,具體包括面向服務(wù)的領(lǐng)域、集成和軟件工廠。作為在荷蘭的顧問,Dennis 通過利用 Microsoft 平臺的強(qiáng)大功能與企業(yè)客戶共同合作解決其問題。Dennis 經(jīng)常在荷蘭 Microsoft 會議和用戶組中發(fā)言,在 2006 年初,他就已經(jīng)成為 INETA 的發(fā)言人。可以通過 dennism@avanade.com 或他的博客
Avanade 是全球 IT 咨詢公司,致力于使用 Microsoft 平臺幫助企業(yè)取得盈利增長。通過利用拓展 Microsoft 技術(shù)的成熟解決方案,Avanade 幫助企業(yè)增加收入、降低成本并對創(chuàng)新技術(shù)進(jìn)行再投資,以獲得競爭優(yōu)勢。我們的顧問通過匯聚我們?nèi)蚬蛦T的洞察力、創(chuàng)新和才干,按照每個客戶的要求、時間線和預(yù)算提供服務(wù)。有關(guān)其他信息,可以訪問