91欧美超碰AV自拍|国产成年人性爱视频免费看|亚洲 日韩 欧美一厂二区入|人人看人人爽人人操aV|丝袜美腿视频一区二区在线看|人人操人人爽人人爱|婷婷五月天超碰|97色色欧美亚州A√|另类A√无码精品一级av|欧美特级日韩特级

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

WCF技術(shù)的實例模式的實現(xiàn)原理剖析

454398 ? 來源:博客園 ? 作者:蔣金楠 ? 2020-11-03 11:10 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

服務(wù)調(diào)用的目的體現(xiàn)在對某項服務(wù)功能的消費上,而功能的實現(xiàn)又定義在相應(yīng)的服務(wù)類型中。不論WCF服務(wù)端框架處理服務(wù)調(diào)用請求的流程有多么復(fù)雜,最終都落實在服務(wù)實例的激活和操作方法的執(zhí)行上面。WCF中的實例管理(Instance Management)旨在解決服務(wù)實例的激活和服務(wù)實例生命周期的控制。

會話(Session)的目的在于保持來自相同客戶端(服務(wù)代理)多次服務(wù)調(diào)用之間的狀態(tài)。從消息交換的角度來講,會話通過消息識別機制判斷調(diào)用某個服務(wù)的消息來源,從而將來自相同客戶端的所有消息關(guān)聯(lián)在一起。所以,會話實現(xiàn)了消息關(guān)聯(lián)(Message Correlation)。

實例與會話是WCF非常重要的兩個特性,它們既相對獨立,又互相制約。實例模式與對會話支持程度的不同組合,會讓最終的服務(wù)表現(xiàn)出截然不同的行為。對實例管理和會話的合理利用,對于改善和提高WCF服務(wù)應(yīng)用的可擴展性(Scalability)、性能(Performance)、吞吐量(Throughput)等具有決定性作用。服務(wù)實例對象并不是孤立存在的,而是被封裝到一個特殊實例上下文(InstanceContext)對象之中,本系列文章從實例上下文說起。

一、實例上下文(InstanceContext)

實例上下文是對服務(wù)實例的封裝,是WCF管理服務(wù)實例生命周期的依托。我們先撇開WCF,來簡單介紹一下在托管的環(huán)境中,公共語言運行時(CLR)是如何進行托管對象的生命周期的。在一個托管應(yīng)用程序中,我們通過不同的方式創(chuàng)建一個托管對象(比如通過new關(guān)鍵字、反射或反序列化等)時,CLR會在托管堆為該對象開辟一塊內(nèi)存空間。對象的本質(zhì)就是存儲于某塊內(nèi)存中數(shù)據(jù)的體現(xiàn),對象的生命周期終止于相應(yīng)內(nèi)存被回收之時。對于CLR來說,負(fù)責(zé)對托管堆(在這里主要指GC堆)進行回收的組件是垃圾收集器(GC),GC掌握著托管對象的生殺大權(quán),決定著托管對象的生命周期。

當(dāng)GC在進行垃圾回收的時候,會將“無用”的對象標(biāo)記為垃圾對象,然后再對垃圾對象進行清理。GC對“無用”對象的識別機制很簡單:判斷對象是否被“根(Root)”所引用。在這里,“根”是對一組當(dāng)前正被使用,或者以后可能被使用的對象的統(tǒng)稱,大體包括這樣的對象:類型的靜態(tài)字段或當(dāng)前的方法參數(shù)和局部變量、CPU寄存器等。

所以,孤立存在的對象將難逃被GC回收的厄運。反之,如果希望某個對象常駐內(nèi)存中,我們唯一的方式就是通過某個“根”引用該對象。本章所講的實例管理,就是對服務(wù)實例生命周期的管理,即讓服務(wù)實例按照我們希望的方式創(chuàng)建、存活和消亡,所以我們唯一的方式也只能是:在希望服務(wù)實例存活的時候讓它被某個“根”引用,從而阻止GC將其回收;在希望服務(wù)實例被回收的時候連“根”去除,使GC能夠?qū)⑵浠厥?。而本?jié)所講的實例上下文(InstanceContext)就扮演著“根”的角色。

說到實例上下文,相信讀者不會感到陌生,因為在進行WCF雙向(Duplex)通信的時候,我們通過實例上下文來封裝回調(diào)對象。在WCF中,實例上下文不僅僅用于對回調(diào)對象的封裝,也用于對真正服務(wù)實例的封裝。實際上可以將WCF的雙向通信理解成一種對等通信,通信的雙方是對等的參與者,并沒有嚴(yán)格的服務(wù)端和客戶端之分,或者說通信的雙方交替地扮演著服務(wù)與客戶的角色。客戶端正常調(diào)用服務(wù)端操作是一種服務(wù)調(diào)用;服務(wù)端回調(diào)客戶端操作也可以看成是一種服務(wù)調(diào)用。因此,通過實例上下文對回調(diào)對象和服務(wù)實例進行封裝本質(zhì)上是一致的。

實例上下文對服務(wù)實例的封裝大體可以通過圖1表示。一個WCF服務(wù)通過一個ServiceHost進行寄宿,并添加一到多個終結(jié)點。對于接收到的服務(wù)調(diào)用請求,如果相應(yīng)的實例上下文存在,則通過它得到服務(wù)實例來處理服務(wù)請求,否則創(chuàng)建服務(wù)實例并通過實例上下文對其進行封裝,然后再通過實例上下文得到具體的服務(wù)實例進行服務(wù)請求處理。

圖1 實例上下文對服務(wù)實例的封裝

實例上下文通過類型System.ServiceModel.InstanceContext表示。InstanceContext繼承自CommunicationObject,實現(xiàn)了IExtensibleObject接口。InstanceContext的定義如下面的代碼所示:

   1: public sealed class InstanceContext : CommunicationObject, IExtensibleObject
   2: {   
   3:     //其他成員
   4:     public InstanceContext(object implementation);
   5:     public InstanceContext(ServiceHostBase host);
   6:     public InstanceContext(ServiceHostBase host, object implementation);
   7: 
   8:     public object GetServiceInstance();
   9:     public object GetServiceInstance(Message message);
  10:     public void ReleaseServiceInstance();
  11: 
  12:     public IExtensionCollection Extensions { get; }
  13:     public ServiceHostBase Host { get; }
  14:     public ICollection IncomingChannels { get; }
  15:     public ICollection OutgoingChannels { get; }
  16:     public SynchronizationContext SynchronizationContext { get; set; }
  17: }

InstanceContext具有三個構(gòu)造函數(shù),接受ServiceHostBase對象和具體的實例對象作為其輸入?yún)?shù)。GetServiceInstance和ReleaseServiceInstance用戶服務(wù)實例的獲取和釋放。IncomingChannels和OutgoingChannels則表示入棧和出棧信道集合。而通過SynchronizationContext屬性則可以設(shè)置或獲取用于異步操作的同步上下文,比如服務(wù)操作須要在非UI線程下操作一個Windows Form的控件,你就需要基于UI線程的同步上下文(SynchronizationContext)。

二、實例上下文模式(InstanceContext Mode)

實例上下文模式(IntanceContext Mode)表示服務(wù)端的服務(wù)實例與客戶端的服務(wù)代理的綁定方式。如果讀者熟悉.NET Remoting,肯定會很清楚.NET Remoting具有兩種不同的遠程對象激活方式:服務(wù)端激活對象(SAO:Server Activated Object)和客戶端激活對象(CAO:Client Activated Object),而前者又具有兩種不同的變體:單調(diào)(SingleCall)和單例(Singleton)。單調(diào)模式意味著服務(wù)端對于接收到的調(diào)用,都會創(chuàng)建新的遠程對象,而單例模式則表示服務(wù)端使用相同的遠程對象處理來自不同客戶端的所有遠程調(diào)用。單調(diào)和單例模式體現(xiàn)了兩種極端的遠程對象激活方式,而CAO則是一種相對折中的方式:一個客戶端代理對象與一個遠程對象一一匹配。WCF實例上下文模式與.NET Remoting的遠程對象激活方式類似,同樣具有三種不同的實例上下文模式,分別與上述三種激活方式匹配。這三種實例上下文模式分別是:單調(diào)(Per-Call)模式、會話(Per-Session)模式和單例(Single)模式。

1、單調(diào)(Per-Call)模式

單調(diào)模式相當(dāng)于.NET Remoting的SingleCall遠程對象激活方式。如果采用單調(diào)實例上下文模式,對于每一個服務(wù)調(diào)用,不論是來自相同的客戶端(服務(wù)代理)還是不同的客戶端,WCF總是創(chuàng)建一個全新的服務(wù)實例和實例上下文對象來處理服務(wù)調(diào)用請求。在服務(wù)操作執(zhí)行完畢,實例上下文對象和被封裝的服務(wù)實例被回收調(diào)。圖2揭示了在單調(diào)模式下實例上下文、服務(wù)實例和服務(wù)代理之間的關(guān)聯(lián)。

圖2 單調(diào)模式下服務(wù)代理與服務(wù)實例上下文之間的關(guān)聯(lián)

2、會話(Per-Session)模式

會話(Session)的目的在于保持來自相同客戶端(即同一個服務(wù)代理)多次服務(wù)調(diào)用之間的狀態(tài)。如果從消息交互的角度來講,通過會話可以將來自相同客戶端的多個消息關(guān)聯(lián)在一起。在會話實例上下文模式下,WCF為每一個服務(wù)代理對象分配一個單獨的服務(wù)實例上下文對象,對于來自相同服務(wù)代理的所有服務(wù)調(diào)用請求,都將分發(fā)給相同的服務(wù)實例上下文處理。會話模式與.NET Remoting下的CAO遠程對象激活模式類似,圖3揭示了會話模式下實例上下文、服務(wù)實例和服務(wù)代理之間的關(guān)系。

圖3 會話模式下服務(wù)代理與服務(wù)實例上下文之間的關(guān)聯(lián)

3、單例(Single)模式

單例模式意味著WCF為每個服務(wù)維護一個并且僅維護一個服務(wù)實例上下文。不論請求來自相同的服務(wù)代理還是不同的服務(wù)代理,處理服務(wù)調(diào)用請求都是同一個服務(wù)實例上下文對象。單例模式相當(dāng)于.NET Remoting下的Singleton遠程對象激活方式,圖4揭示了單例模式下實例上下文、服務(wù)實例和服務(wù)代理之間的關(guān)系。

圖4 會話模式下服務(wù)代理與服務(wù)實例上下文之間的關(guān)聯(lián)

三、 實例服務(wù)行為

在介紹服務(wù)寄宿的時候,我們談到過WCF下“契約(Contract)”和“行為(Behavior)”的區(qū)別:契約是涉及雙邊的描述(契約是服務(wù)的提供者和服務(wù)消費者進行交互的手段),那么行為就是基于單邊的描述??蛻舳诵袨轶w現(xiàn)的是WCF如何進行服務(wù)調(diào)用的方式,而服務(wù)端行為則體現(xiàn)了WCF的請求分發(fā)方式。所以服務(wù)契約會通過元數(shù)據(jù)對外發(fā)布,而服務(wù)行為則對于客戶端是透明的。

對于客戶端來講,它所關(guān)心的是通過服務(wù)調(diào)用能夠獲得正確的結(jié)果,而不會關(guān)心服務(wù)端采用怎樣的模式來激活服務(wù)實例。所以,WCF實例管理通過服務(wù)行為體現(xiàn),不同的實例上下文模式通過ServiceBehaviorAttribute特性指定。在ServiceBehaviorAttribute中,通過設(shè)置InstanceContextMode屬性來指定不同的服務(wù)實例上下文模式。

   1: [AttributeUsage(AttributeTargets.Class)]
   2: public sealed class ServiceBehaviorAttribute : Attribute, IServiceBehavior
   3: { 
   4:     //其他成員
   5:     public InstanceContextMode InstanceContextMode { get; set; }
   6: }

屬性InstanceContextMode的類型為System.ServiceModel.InstanceContextMode枚舉,三個枚舉值PerCall、PerSession和Single分別表示上述的三種實例上下文模式。默認(rèn)選項為PerSession。

   1: public enum InstanceContextMode
   2: {
   3:     PerCall,
   4:     PerSession,
   5:     Single
   6: }

在本系列后續(xù)部分,我將對每一種實例模式的實現(xiàn)原理進行逐個剖析,相信極大的加深讀者對WCF下的服務(wù)對象生命周期管理機制的理解。
編輯:hfy

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 寄存器
    +關(guān)注

    關(guān)注

    31

    文章

    5608

    瀏覽量

    129968
  • WCF
    WCF
    +關(guān)注

    關(guān)注

    0

    文章

    4

    瀏覽量

    7109
收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點推薦

    LMK04828 - EP:超低噪聲時鐘抖動清理器的技術(shù)剖析與應(yīng)用指南

    LMK04828 - EP:超低噪聲時鐘抖動清理器的技術(shù)剖析與應(yīng)用指南 在電子設(shè)計領(lǐng)域,時鐘信號的穩(wěn)定性和低抖動特性對于系統(tǒng)的性能至關(guān)重要。LMK04828 - EP作為一款超低噪聲、符合
    的頭像 發(fā)表于 02-08 11:45 ?443次閱讀

    深入剖析MAX16812:集成高壓LED驅(qū)動的技術(shù)先鋒

    深入剖析MAX16812:集成高壓LED驅(qū)動的技術(shù)先鋒 在當(dāng)今的電子世界中,LED照明技術(shù)的發(fā)展日新月異,而與之配套的LED驅(qū)動芯片也在不斷創(chuàng)新。MAX16812作為一款集成高壓LED驅(qū)動芯片,憑借
    的頭像 發(fā)表于 02-02 16:25 ?166次閱讀

    MCP2510:獨立CAN控制器的技術(shù)剖析與應(yīng)用指南

    MCP2510:獨立CAN控制器的技術(shù)剖析與應(yīng)用指南 在電子工程師的設(shè)計工具箱中,CAN(Controller Area Network)控制器是實現(xiàn)可靠通信的關(guān)鍵組件。Microchip
    的頭像 發(fā)表于 01-28 16:15 ?170次閱讀

    深度剖析L6566B:多模式SMPS控制器的卓越之選

    深度剖析L6566B:多模式SMPS控制器的卓越之選 在電源管理領(lǐng)域,一款優(yōu)秀的控制器對于開關(guān)電源(SMPS)的性能起著決定性作用。今天,我們將深入探討STMicroelectronics推出
    的頭像 發(fā)表于 01-27 10:55 ?288次閱讀

    深入解析L6562:高性能過渡模式PFC控制器

    ,工作在過渡模式(TM),與前代L6561引腳兼容且性能更優(yōu)。接下來,我們將詳細剖析L6562的特性、功能、應(yīng)用及相關(guān)設(shè)計要點。 文件下載: l6562.pdf 特性亮點 先進工藝與模式 BCD
    的頭像 發(fā)表于 01-27 10:55 ?322次閱讀

    L6564T:高性能過渡模式PFC控制器的深度剖析

    L6564T:高性能過渡模式PFC控制器的深度剖析 在開關(guān)電源(SMPS)設(shè)計領(lǐng)域,功率因數(shù)校正(PFC)技術(shù)至關(guān)重要,它能夠提高電源效率、減少諧波污染。今天,我們要深入探討一款優(yōu)秀的PFC控制器
    的頭像 發(fā)表于 01-27 10:35 ?770次閱讀

    深入剖析L6563/L6563A:高級過渡模式PFC控制器的卓越性能

    深入剖析L6563/L6563A:高級過渡模式PFC控制器的卓越性能 在開關(guān)電源(SMPS)設(shè)計中,功率因數(shù)校正(PFC)技術(shù)起著至關(guān)重要的作用,它能提高電源效率,降低諧波污染。L6563
    的頭像 發(fā)表于 01-27 10:30 ?318次閱讀

    剖析AD8451:電池測試與成型系統(tǒng)的高精度模擬前端控制器

    和豐富的功能。今天,我們就來深入剖析AD8451,探討它在電池測試與成型系統(tǒng)中的應(yīng)用。 文件下載: AD8451.pdf 一、AD8451關(guān)鍵特性 (一)集成模式與自動切換 AD8451集成了恒流(CC)和恒壓(CV)模式,并能
    的頭像 發(fā)表于 01-14 11:15 ?208次閱讀

    AMD UltraScale架構(gòu):高性能FPGA與SoC的技術(shù)剖析

    AMD UltraScale架構(gòu):高性能FPGA與SoC的技術(shù)剖析 在當(dāng)今的電子設(shè)計領(lǐng)域,高性能FPGA和MPSoC/RFSoC的需求日益增長。AMD的UltraScale架構(gòu)憑借其創(chuàng)新的技術(shù)和卓越
    的頭像 發(fā)表于 12-15 14:35 ?554次閱讀

    ProfiNet嵌入式板卡,主流替代可實現(xiàn)ProfiNet工業(yè)以太網(wǎng)的應(yīng)用實例

    ProfiNet嵌入式板卡,主流替代可實現(xiàn)ProfiNet工業(yè)以太網(wǎng)的應(yīng)用實例
    的頭像 發(fā)表于 12-01 17:11 ?1112次閱讀
    ProfiNet嵌入式板卡,主流替代可<b class='flag-5'>實現(xiàn)</b>ProfiNet工業(yè)以太網(wǎng)的應(yīng)用<b class='flag-5'>實例</b>

    Modbus協(xié)議的深度剖析

    Modbus協(xié)議作為工業(yè)自動化領(lǐng)域最廣泛應(yīng)用的通信協(xié)議之一,其簡潔高效的特性使其在工業(yè)控制系統(tǒng)中占據(jù)重要地位。本文將從協(xié)議的發(fā)展歷程、技術(shù)架構(gòu)、通信模式、安全機制以及未來演進等多個維度進行全面剖析
    的頭像 發(fā)表于 11-07 07:43 ?851次閱讀
    Modbus協(xié)議的深度<b class='flag-5'>剖析</b>

    【「DeepSeek 核心技術(shù)揭秘」閱讀體驗】--全書概覽

    講解Deepseek的使用方法 第三章 深入剖析Deepseek-V3的模型架構(gòu)、訓(xùn)練框架、推理階段優(yōu)化、后訓(xùn)練優(yōu)化等關(guān)鍵技術(shù) 第四章關(guān)于DeepSeek-R1的技術(shù)剖析 第五章 從
    發(fā)表于 07-21 00:04

    實例解讀模擬電子技術(shù)

    資料介紹:本文通過豐富多彩的應(yīng)用實例,由淺入深地剖析模擬電子電路各方面的知識。例如,通過電子地動儀的介紹帶領(lǐng)讀者進入電子學(xué)的殿堂,通過USB充電器和電池保護器介紹有關(guān)直流電源的知識,通過電子聽診器
    發(fā)表于 05-16 13:29

    UIAbility組件啟動模式實例在啟動時的不同呈現(xiàn)狀態(tài)

    UIAbility組件啟動模式 UIAbility的啟動模式是指UIAbility實例在啟動時的不同呈現(xiàn)狀態(tài)。針對不同的業(yè)務(wù)場景,系統(tǒng)提供了三種啟動模式: singleton(單
    發(fā)表于 05-16 06:10

    電機故障診斷常見誤區(qū)的剖析

    純分享帖,需要者可點擊附件獲取完整資料~~~*附件:電機故障診斷常見誤區(qū)的剖析.pdf (免責(zé)聲明:本文系網(wǎng)絡(luò)轉(zhuǎn)載,版權(quán)歸原作者所有。本文所用視頻、圖片、文字如涉及作品版權(quán)問題,請第一時間告知,刪除內(nèi)容!)
    發(fā)表于 04-07 17:35