WCF egyszerűsítési funkciók

Ez a témakör azokat az új funkciókat ismerteti, amelyek egyszerűbbé teszik a WCF-alkalmazások írását.

gRPC a WCF alternatívaként

A gRPC egy modern RPC-keretrendszer, amely a WCF népszerű alternatíva. A gRPC a HTTP/2-n alapul, amely számos előnyt biztosít a WCF-sel szemben, beleértve a következőket:

• Teljesítmény: a gRPC sokkal hatékonyabb, mint a WCF, különösen a hosszú ideig futó kapcsolatok esetében.
• Méretezhetőség: a gRPC nagy számú ügyfélre és kiszolgálóra skálázható.
• Biztonság: a gRPC számos biztonsági mechanizmust támogat, beleértve a TLS-t és a hitelesítést.
• Platformfüggetlen: a gRPC platformsemleges, és számos programozási nyelvvel használható.

A WCF-alkalmazások gRPC-be való fejlesztésével vagy migrálásával kapcsolatos további információkért lásd:

• Miért ajánljuk a gRPC-t WCF-fejlesztőknek?
• WCF és gRPC összehasonlítása
• A gRPC bemutatása WCF-fejlesztőknek

Egyszerűsített generált konfigurációs fájlok

Amikor hozzáad egy szolgáltatáshivatkozást a Visual Studióban, vagy használja a SvcUtil.exe eszközt, létrejön egy ügyfélkonfigurációs fájl. A WCF korábbi verzióiban ezek a konfigurációs fájlok minden kötéstulajdonság értékét tartalmazzák, még akkor is, ha az értéke az alapértelmezett érték. A WCF 4.5-ben a létrehozott konfigurációs fájlok csak azokat a kötési tulajdonságokat tartalmazzák, amelyek nem alapértelmezett értékre vannak beállítva.

Az alábbiakban egy példa látható a WCF 3.0 által létrehozott konfigurációs fájlra.

XML

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IService1" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                    allowCookies="false" bypassProxyOnLocal="false"
                    hostNameComparisonMode="StrongWildcard" maxBufferSize="65536"
                    maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
                    useDefaultWebProxy="true">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192"
                        maxArrayLength="16384" maxBytesPerRead="4096"
                        maxNameTableCharCount="16384" />
                    <security mode="None">
                        <transport clientCredentialType="None" proxyCredentialType="None"
                            realm="" />
                        <message clientCredentialType="UserName" algorithmSuite="Default" />
                    </security>
                </binding>
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:36906/Service1.svc" binding="basicHttpBinding"
                bindingConfiguration="BasicHttpBinding_IService1" contract="IService1"
                name="BasicHttpBinding_IService1" />
        </client>
    </system.serviceModel>
</configuration>

Az alábbiakban egy példa látható a WCF 4.5 által létrehozott konfigurációs fájlra.

XML

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IService1" />
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:36906/Service1.svc" binding="basicHttpBinding"
                bindingConfiguration="BasicHttpBinding_IService1" contract="IService1"
                name="BasicHttpBinding_IService1" />
        </client>
    </system.serviceModel>
</configuration>

Szerződés-első fejlesztés

A WCF mostantól támogatja a szerződés-első fejlesztést. A svcutil.exe eszköz /serviceContract kapcsolóval rendelkezik, amellyel szolgáltatási és adatszerződéseket hozhat létre egy WSDL-dokumentumból.

Szolgáltatáshivatkozás hozzáadása hordozható részhalmazprojektből

A hordozható részhalmazprojektek lehetővé teszik, hogy a .NET-szerelvényprogramozók egyetlen forrásfát tartsanak fenn, és rendszert építsenek, miközben több .NET-implementációt is támogatnak (asztali, Silverlight, Windows Phone-telefon és Xbox). A hordozható részhalmazprojektek csak .NET-alapú hordozható kódtárakra hivatkoznak, amelyek bármely .NET-implementációban használható szerelvények. A fejlesztői élmény ugyanaz, mint egy szolgáltatáshivatkozás hozzáadása bármely más WCF-ügyfélalkalmazásban. További információ: Szolgáltatáshivatkozás hozzáadása hordozható részhalmazprojektekben.

ASP.NET kompatibilitási mód alapértelmezett módosítása

A WCF ASP.NET kompatibilitási módot biztosít a fejlesztőknek, hogy teljes hozzáférést biztosítsanak a ASP.NET HTTP-folyamat funkcióihoz a WCF-szolgáltatások írásakor. A mód használatához az aspNetCompatibilityEnabled attribútumot true értékre kell állítania a <web.config serviceHostingEnvironment> szakaszában. Ezenkívül az appDomain bármely szolgáltatásának rendelkeznie kell a RequirementsMode tulajdonság beállításával Allowed vagy RequiredbeállításávalAspNetCompatibilityRequirementsAttribute. Alapértelmezés szerint AspNetCompatibilityRequirementsAttribute most már be van állítva, Allowed és az alapértelmezett WCF szolgáltatásalkalmazás-sablon az attribútumot a aspNetCompatibilityEnabled következőre trueállítja be: . További információ: A Windows Communication Foundation 4.5 újdonságai, a WCF-szolgáltatások és ASP.NET.

Streamelési fejlesztések

• Az aszinkron streamelés új támogatása lett hozzáadva a WCF-hez. Az aszinkron streamelés engedélyezéséhez adja hozzá a DispatcherSynchronizationBehavior végpont viselkedését a szolgáltatás gazdagépéhez, és állítsa a tulajdonságát AsynchronousSendEnabled a következőre true: . Ez akkor lehet hasznos, ha egy szolgáltatás streamelt üzeneteket küld több olyan ügyfélnek, amelyek lassan olvasnak. A WCF már nem blokkolja az ügyfélenként egy szálat, és felszabadítja a szálat egy másik ügyfél kiszolgálásához.

• Az üzenetek pufferelésével kapcsolatos korlátozások el lettek távolítva, amikor egy szolgáltatás IIS-t üzemeltet. A WCF korábbi verzióiban, amikor egy streamelt üzenetátvitelt használó IIS-szolgáltatáshoz kapott üzenetet, ASP.NET pufferelné a teljes üzenetet, mielőtt elküldené azt a WCF-nek. Ez nagy memóriahasználatot okozna. Ez a pufferelés el lett távolítva a .NET-keretrendszer 4.5-ben, és az IIS által üzemeltetett WCF-szolgáltatások megkezdhetik a bejövő stream feldolgozását a teljes üzenet fogadása előtt, ezáltal lehetővé téve a valódi streamelést. Ez lehetővé teszi, hogy a WCF azonnal válaszoljon az üzenetekre, és jobb teljesítményt biztosít. Emellett már nem kell megadnia a bejövő kérelmek méretkorlátjának ASP.NET értékét maxRequestLength. Ha ez a tulajdonság be van állítva, a rendszer figyelmen kívül hagyja. További információ a httpRuntime konfigurációs elemrőlmaxRequestLength<.> Továbbra is konfigurálnia kell a maxAllowedContentLength elemet. További információ: IIS-kérelmek korlátai.

Új átviteli alapértelmezett értékek

Az alábbi táblázat a módosított beállításokat és a további információk megkeresésének helyét ismerteti.

Tulajdonság	Be	Új alapértelmezett	További információ
channelInitializationTimeout	NetTcpBinding	30 másodperc	Ez a tulajdonság határozza meg, hogy egy TCP-kapcsolat mennyi ideig tarthat a .NET Framing protokoll használatával történő hitelesítéshez. Az ügyfélnek el kell küldenie néhány kezdeti adatot, mielőtt a kiszolgáló elegendő információval rendelkezik a hitelesítés végrehajtásához. Ez az időtúllépés szándékosan kisebb, mint a ReceiveTimeout (10 perc), így a rosszindulatú, hitelesítés nélküli ügyfelek nem tartják sokáig a kiszolgálóhoz kötött kapcsolatokat. Az alapértelmezett érték 30 másodperc. További információ: ChannelInitializationTimeout
listenBacklog	NetTcpBinding	16 * processzorok száma	Ez a szoftvercsatornaszintű tulajdonság a várólistára küldendő "függőben lévő elfogadás" kérések számát írja le. Ha a figyelés hátralék-üzenetsora megtelik, a rendszer elutasítja az új szoftvercsatorna-kérelmeket. További információ: ListenBacklog
maxPendingAccepts	Csatlakozás ionOrientedTransportBindingElement SMSvcHost.exe	2 * szállítási processzorok száma 4 * processzorok száma SMSvcHost.exe	Ez a tulajdonság korlátozza a kiszolgáló által a figyelőre várakozó csatornák számát. Ha a MaxPendingAccepts túl alacsony, lesz egy kis idő, amikor az összes várakozási csatorna megkezdte a kapcsolatok karbantartását, de új csatornák nem kezdték el a figyelést. A kapcsolat ebben az időszakban meg tud érkezni, és sikertelen lesz, mert semmi sem vár rá a kiszolgálón. Ezt a tulajdonságot úgy lehet konfigurálni, hogy a MaxPendingConnections tulajdonságot nagyobb számra állítja. További információkért lásd MaxPendingAccepts és konfigurálja a Net.TCP portmegosztási szolgáltatást
maxPending Csatlakozás ions	Csatlakozás ionOrientedTransportBindingElement	12 * processzorok száma	Ez a tulajdonság azt szabályozza, hogy egy átvitel hány kapcsolatot fogadott el, de a ServiceModel Dispatcher nem vette fel őket. Az érték beállításához használja MaxConnections a kötést vagy maxOutboundConnectionsPerEndpoint a kötési elemet. További információ: MaxPendingConnections
receiveTimeout	SMSvcHost.exe	30 másodperc	Ez a tulajdonság azt az időtúllépést adja meg, amely a TCP-keretezési adatok beolvasására és a mögöttes kapcsolatokból való kapcsolatküldés végrehajtására használható. Ez azt a korlátot határozza meg, hogy a szolgáltatás mennyi időt vesz igénybe, SMSvcHost.exe a szolgáltatás folyamatosan beolvassa a bejövő kapcsolatból származó preambulumadatokat. További információ: A Net.TCP portmegosztási szolgáltatás konfigurálása.

Megjegyzés

Ezeket az új alapértelmezett értékeket csak akkor használja a rendszer, ha a WCF szolgáltatást a .NET-keretrendszer 4.5-ös verziójú gépen helyezi üzembe. Ha ugyanazt a szolgáltatást .NET-keretrendszer 4.0-s gépre telepíti, akkor a .NET-keretrendszer 4.0-s alapértelmezett értékeket használja. Ilyen esetekben javasoljuk, hogy ezeket a beállításokat explicit módon konfigurálja.

XmlDictionaryReaderQuotas

XmlDictionaryReaderQuotas Olyan konfigurálható kvótaértékeket tartalmaz az XML-szótárolvasók számára, amelyek korlátozzák a kódoló által az üzenet létrehozásakor felhasznált memória mennyiségét. Bár ezek a kvóták konfigurálhatók, az alapértelmezett értékek módosultak, így csökkentve annak lehetőségét, hogy a fejlesztőnek explicit módon kell beállítania őket. MaxReceivedMessageSize a kvóta nem módosult, így továbbra is korlátozhatja a memóriahasználatot, így nem kell foglalkoznia a kvóta összetettségével XmlDictionaryReaderQuotas. Az alábbi táblázat a kvótákat, az új alapértelmezett értékeket és az egyes kvóták felhasználásának rövid ismertetését mutatja be.

Kvóta neve	Alapértelmezett érték	Leírás
MaxArrayLength	Int32.MaxValue	Lekéri és beállítja a maximálisan megengedett tömbhosszt. Ez a kvóta korlátozza az XML-olvasó által visszaadott primitív tömbök maximális méretét, beleértve a bájttömböket is. Ez a kvóta nem korlátozza a memóriahasználatot az XML-olvasóban, hanem bármilyen összetevőben, amely az olvasót használja. Hapéldáult használ például DataContractSerializer , MaxArrayLengthakkor nem deszerializálja a kvótánál nagyobb bájttömböket.
MaxBytesPerRead	Int32.MaxValue	Lekéri és beállítja az egyes olvasásokhoz visszaadott maximális bájtokat. Ez a kvóta korlátozza az egyetlen olvasási műveletben beolvasott bájtok számát az elem kezdőcímkéjének és attribútumainak olvasásakor. (Nem streamelt esetekben maga az elem neve nem számít bele a kvótába). Ha túl sok XML-attribútumot használ, az aránytalan feldolgozási időt is igénybe vehet, mivel az attribútumnevek egyediségét ellenőrizni kell. MaxBytesPerRead elhárítja ezt a fenyegetést.
MaxDepth	128 csomópont mély	Ez a kvóta korlátozza az XML-elemek maximális beágyazási mélységét. MaxDepth a következővel MaxBytesPerReadkommunikál: az olvasó mindig a memóriában tartja az adatokat az aktuális elem és az összes elődje számára, így az olvasó maximális memóriahasználata arányos a két beállítás szorzatával. Mélyen beágyazott objektumdiagramok deszerializálásakor a deszerializálónak a teljes veremhez kell hozzáférnie, és vissza nem térítendőt StackOverflowExceptionkell dobnia. Közvetlen korreláció áll fenn az XML-beágyazás és az objektumok beágyazása között mind a DataContractSerializerXmlSerializer. MaxDepth a fenyegetés mérséklésére szolgál.
MaxNameTableCharCount	Int32.MaxValue	Ez a kvóta korlátozza a névtáblában megengedett karakterek maximális számát. A névtábla bizonyos sztringeket (például névtereket és előtagokat) tartalmaz, amelyek egy XML-dokumentum feldolgozásakor lépnek fel. Mivel ezek a sztringek pufferelve vannak a memóriában, ez a kvóta megakadályozza a túlzott pufferelést, amikor a streamelés várható.
MaxStringContentLength	Int32.MaxValue	Ez a kvóta korlátozza az XML-olvasó által visszaadott maximális sztringméretet. Ez a kvóta nem korlátozza a memóriahasználatot az XML-olvasóban, hanem az olvasót használó összetevőben. Ha például egy DataContractSerializer olvasót MaxStringContentLengthhasznál, azzal nem deszerializálja az ennél a kvótánál nagyobb sztringeket.

Fontos

Az adatok biztonságával kapcsolatos további információkért tekintse meg az "XML Széf ly használata" című témakört az Adatok biztonsági szempontjai között.

Megjegyzés

Ezeket az új alapértelmezett értékeket csak akkor használja a rendszer, ha a WCF szolgáltatást a .NET-keretrendszer 4.5-ös verziójú gépen helyezi üzembe. Ha ugyanazt a szolgáltatást .NET-keretrendszer 4.0-s gépre telepíti, akkor a .NET-keretrendszer 4.0-s alapértelmezett értékeket használja. Ilyen esetekben javasoljuk, hogy ezeket a beállításokat explicit módon konfigurálja.

WCF-konfiguráció ellenőrzése

A Visual Studióban a buildelési folyamat részeként a WCF-konfigurációs fájlok érvényesítve lesznek. Ha az ellenőrzés sikertelen, megjelenik az érvényesítési hibák vagy figyelmeztetések listája a Visual Studióban.

XML-szerkesztő elemleírásai

Annak érdekében, hogy az új és meglévő WCF-szolgáltatásfejlesztők konfigurálhassák szolgáltatásaikat, a Visual Studio XML-szerkesztő mostantól elemleírásokat biztosít a szolgáltatáskonfigurációs fájl részét képező összes konfigurációelemhez és tulajdonságaihoz.

AlapszintűhttpBinding-fejlesztések

1. Lehetővé teszi, hogy egyetlen WCF-végpont válaszoljon a különböző hitelesítési módokra.

2. Lehetővé teszi, hogy a WCF-szolgáltatás biztonsági beállításait az IIS vezérelje