Megosztás a következőn keresztül:

Szolgáltatás verziószámozása

  • Cikk

A kezdeti üzembe helyezést követően, és az élettartamuk során akár többször is, előfordulhat, hogy a szolgáltatásokat (és az általuk elérhető végpontokat) számos okból módosítani kell, például az üzleti igények módosítása, az informatikai követelmények módosítása vagy más problémák megoldása érdekében. Minden módosítás a szolgáltatás új verzióját mutatja be. Ez a témakör azt ismerteti, hogyan fontolja meg a verziószámozást a Windows Communication Foundationben (WCF).

A szolgáltatásmódosítások négy kategóriája

A szolgáltatások szükséges módosításai négy kategóriába sorolhatók:

  • Szerződésmódosítások: Például egy művelet hozzáadható, vagy egy üzenet adateleme hozzáadható vagy módosítható.

  • Címváltozások: Egy szolgáltatás például egy másik helyre kerül, ahol a végpontok új címmel rendelkeznek.

  • Kötési módosítások: Például egy biztonsági mechanizmus megváltozik, vagy a beállítások módosulnak.

  • Implementálási változások: Például ha egy belső metódus implementációja megváltozik.

A módosítások némelyikét "törésnek" nevezik, míg mások "nem törnek". A módosítás nem törik meg, ha az előző verzióban sikeresen feldolgozott összes üzenet sikeresen feldolgozásra kerül az új verzióban. Minden olyan módosítás, amely nem felel meg ennek a feltételnek, kompatibilitástörő változás.

Szolgáltatás tájolása és verziószámozása

A szolgáltatásorientáltság egyik alapja, hogy a szolgáltatások és az ügyfelek autonómak (vagy függetlenek). Ez többek között azt jelenti, hogy a szolgáltatásfejlesztők nem feltételezhetik, hogy ők irányítják vagy ismerik az összes szolgáltatás-ügyfelet. Ez kiküszöböli az összes ügyfél újraépítésének és újbóli üzembe helyezésének lehetőségét, amikor egy szolgáltatás verziót vált. Ez a témakör feltételezi, hogy a szolgáltatás megfelel ennek a kitartásnak, ezért az ügyfelekétől függetlenül módosítani vagy "verziószámozottnak" kell lennie.

Azokban az esetekben, amikor a kompatibilitástörő változás váratlan, és nem kerülhető el, az alkalmazás dönthet úgy, hogy figyelmen kívül hagyja ezt a műveletet, és megköveteli az ügyfelek újraépítését és újbóli üzembe helyezését a szolgáltatás új verziójával.

Szerződés verziószámozása

Az ügyfél által használt szerződéseknek nem kell megegyeznie a szolgáltatás által használt szerződéssel; csak kompatibilisnek kell lenniük.

A szolgáltatási szerződések esetében a kompatibilitás azt jelenti, hogy a szolgáltatás által közzétett új műveletek hozzáadhatók, de a meglévő műveletek nem távolíthatók el vagy nem módosíthatók szemantikailag.

Adatszerződések esetén a kompatibilitás azt jelenti, hogy új sématípus-definíciók vehetők fel, de a meglévő sématípus-definíciók nem módosíthatók kompatibilitástörő módon. A kompatibilitástörő változások közé tartozhat az adattagok eltávolítása vagy az adattípus inkompatibilis módosítása. Ez a funkció lehetővé teszi a szolgáltatás számára, hogy az ügyfelek feltörése nélkül módosítsa a szerződéseinek verzióját. A következő két szakasz ismerteti a WCF-adatok és szolgáltatásszerződések nem törhető és feltörhető módosításait.

Adatszerződés verziószámozása

Ez a szakasz az adatok verziószámozásával foglalkozik az osztályok és DataContractAttribute az DataContractSerializer osztályok használatakor.

Szigorú verziószámozás

A verziók módosításakor sok esetben a szolgáltatásfejlesztő nem tudja szabályozni az ügyfeleket, ezért nem tudja feltételezni, hogy hogyan reagálnának az üzenet XML-jében vagy sémájában bekövetkező változásokra. Ezekben az esetekben két okból kell garantálnia, hogy az új üzenetek érvényesítve lesznek a régi sémán:

  • A régi ügyfelek azzal a feltételezéssel lettek kifejlesztve, hogy a séma nem változik. Előfordulhat, hogy nem dolgozzák fel azokat az üzeneteket, amelyeket soha nem terveztek.

  • A régi ügyfelek tényleges sémaellenőrzést végezhetnek a régi sémán, mielőtt megpróbálják feldolgozni az üzeneteket.

Az ilyen helyzetekben javasolt módszer a meglévő adatszerződések nem módosíthatóként való kezelése, és újak létrehozása egyedi XML-minősített névvel. A szolgáltatásfejlesztő ezután vagy új metódusokat ad hozzá egy meglévő szolgáltatási szerződéshez, vagy új szolgáltatási szerződést hoz létre az új adatszerződést használó metódusokkal.

Gyakran előfordul, hogy a szolgáltatásfejlesztőnek olyan üzleti logikát kell írnia, amely az adatszerződés minden verzióján belül fut, valamint az adatszerződés egyes verzióihoz tartozó verzióspecifikus üzleti kódot. A témakör végén található függelék bemutatja, hogyan használhatók interfészek ennek az igénynek a kielégítésére.

Lax verziószámozás

Sok más esetben a szolgáltatásfejlesztő feltételezheti, hogy egy új, választható tag hozzáadása az adatszerződéshez nem szakítja meg a meglévő ügyfeleket. Ehhez a szolgáltatásfejlesztőnek meg kell vizsgálnia, hogy a meglévő ügyfelek nem végeznek-e sémaérvényesítést, és hogy figyelmen kívül hagyják-e az ismeretlen adattagokat. Ezekben a forgatókönyvekben az adatszerződés funkcióit kihasználva nem törhető módon adhat hozzá új tagokat. A szolgáltatásfejlesztő megbízhatóan teheti ezt a feltételezést, ha a verziószámozáshoz szükséges adatszerződési funkciók már használatban voltak a szolgáltatás első verziójához.

A WCF, a ASP.NET Web Services és számos más webszolgáltatás-verem támogatja a lax verziószámozást: azaz nem adnak kivételt az új ismeretlen adattagok számára a fogadott adatokban.

Könnyen hihető, hogy egy új tag hozzáadása nem fogja megtörni a meglévő ügyfeleket. Ha nem biztos abban, hogy minden ügyfél képes kezelni a lax verziószámozást, a javaslat a szigorú verziószámozási irányelvek használata és az adatszerződések nem módosíthatóként való kezelése.

Az adatszerződések laza és szigorú verziószámozására vonatkozó részletes irányelvekért tekintse meg az ajánlott eljárásokat: Adatszerződések verziószámozása.

Az adatszerződés és a .NET-típusok megkülönböztetése

A .NET-osztály vagy -struktúra adatszerződésként vethető előre az DataContractAttribute attribútum osztályra való alkalmazásával. A .NET-típus és az adatszerződések előrejelzései két különböző dolgot jelentenek. Több .NET-típus is lehet ugyanazzal az adatszerződés-előrejelzéssel. Ez a különbség különösen akkor hasznos, ha lehetővé teszi a .NET típusának módosítását a tervezett adatszerződés fenntartása mellett, így a szó szoros értelmében is fenntarthatja a kompatibilitást a meglévő ügyfelekkel. A .NET-típus és az adatszerződés közötti különbség fenntartása érdekében mindig két dolgot kell tennie:

  • Adjon meg egy Name és Namespace. Mindig meg kell adnia az adatszerződés nevét és névterét, hogy a .NET-típus neve és névtere ne jelenjen meg a szerződésben. Így ha később úgy dönt, hogy módosítja a .NET-névteret vagy a típusnevet, az adatszerződés változatlan marad.

  • Adja meg a következőt: Name. Mindig meg kell adnia az adattagok nevét, hogy a .NET-tag neve ne jelenjen meg a szerződésben. Így ha később úgy dönt, hogy megváltoztatja a tag .NET-nevét, az adatszerződése változatlan marad.

Tagok módosítása vagy eltávolítása

Egy tag nevének vagy adattípusának módosítása vagy az adattagok eltávolítása akkor is kompatibilitástörő változás, ha a lax verziószámozás engedélyezett. Ha ez szükséges, hozzon létre egy új adatszerződést.

Ha a szolgáltatáskompatibilitás nagy jelentőséggel bír, érdemes lehet figyelmen kívül hagyni a kódban nem használt adattagokat, és a helyén hagyni őket. Ha több tagra oszt fel egy adattagot, érdemes lehet a meglévő tagot olyan tulajdonságként hagyni, amely képes elvégezni a szükséges felosztást és újra aggregációt az alacsonyabb szintű ügyfelek (a legújabb verzióra nem frissített ügyfelek) esetében.

Hasonlóképpen az adatszerződés nevének vagy névterének módosítása is kompatibilitástörő változások.

Ismeretlen adatok ciklikus útjai

Bizonyos esetekben "oda-vissza" ismeretlen adatokra van szükség, amelyek egy új verzióban hozzáadott tagoktól származnak. Egy "versionNew" szolgáltatás például adatokat küld néhány újonnan hozzáadott taggal egy "versionOld" ügyfélnek. Az ügyfél figyelmen kívül hagyja az újonnan hozzáadott tagokat az üzenet feldolgozásakor, de ugyanazokat az adatokat , beleértve az újonnan hozzáadott tagokat is, visszaküldi a versionNew szolgáltatásnak. Ennek tipikus forgatókönyve az adatfrissítések, ahol a rendszer adatokat kér le a szolgáltatásból, módosítja és visszaadja.

Egy adott típus ciklikus lehatolásának engedélyezéséhez a típusnak implementálnia kell az interfészt IExtensibleDataObject . Az interfész egy tulajdonságot tartalmaz, ExtensionData amely a típust ExtensionDataObject adja vissza. A tulajdonság az adatszerződés jövőbeli verzióiból származó, az aktuális verzió számára ismeretlen adatok tárolására szolgál. Ezek az adatok átlátszatlanok az ügyfél számára, de a példány szerializálásakor a ExtensionData tulajdonság tartalma az adatszerződés többi tagjának adataival együtt lesz megírva.

Javasoljuk, hogy minden típus implementálja ezt a felületet, hogy új és ismeretlen jövőbeli tagokat fogadjon.

Adatszerződés-kódtárak

Lehetnek olyan adatszerződések kódtárai, amelyekben egy szerződést közzétevők egy központi adattárban, a szolgáltatás- és típus-megvalósítók pedig az adattárból származó adatszerződéseket implementálnak és tesznek közzé. Ebben az esetben, amikor adatszerződést tesz közzé az adattárban, nincs szabályozva, hogy ki hozza létre azokat megvalósító típusokat. Így nem módosíthatja a szerződést a közzététel után, így az gyakorlatilag megváltoztathatatlanná válik.

Az XmlSerializer használatakor

Az osztály használatakor ugyanazok a verziószámozási XmlSerializer alapelvek érvényesek. Ha szigorú verziószámozásra van szükség, kezelje az adatszerződéseket nem módosíthatóként, és hozzon létre új adatszerződéseket egyedi, minősített névvel az új verziókhoz. Ha biztos abban, hogy a lax verziószámozás használható, új szerializálható tagokat adhat hozzá az új verziókhoz, de nem módosíthatja vagy távolíthatja el a meglévő tagokat.

Feljegyzés

Az XmlSerializer ismeretlen adatok ciklikus lecsatolásának támogatására az és az attribútumokat használja XmlAnyElementAttributeXmlAnyAttributeAttribute .

Üzenetszerződés verziószámozása

Az üzenetszerződések verziószámozásának irányelvei nagyon hasonlóak az adatszerződések verziószámozásához. Ha szigorú verziószámozásra van szükség, ne módosítsa az üzenet törzsét, hanem hozzon létre egy új, egyedi minősített névvel rendelkező üzenetszerződést. Ha tudja, hogy használhatja a lax verziószámozást, hozzáadhat új üzenettörzsrészeket, de a meglévőket nem módosíthatja vagy távolíthatja el. Ez az útmutató a csupasz és a burkolt üzenetszerződésekre is vonatkozik.

Az üzenetfejlécek mindig hozzáadhatók, még akkor is, ha szigorú verziószámozás van használatban. A MustUnderstand jelző befolyásolhatja a verziószámozást. A WCF fejléceinek verziószámozási modelljét általában a SOAP specifikációja ismerteti.

Szolgáltatásszerződés verziószámozása

Az adatszerződések verziószámozásához hasonlóan a szolgáltatási szerződések verziószámozása is magában foglalja a műveletek hozzáadását, módosítását és eltávolítását.

Név, névtér és művelet megadása

Alapértelmezés szerint a szolgáltatási szerződés neve a felület neve. Az alapértelmezett névtér az http://tempuri.org, és minden művelet művelete .http://tempuri.org/contractname/methodname Javasoljuk, hogy explicit módon adjon meg egy nevet és névteret a szolgáltatási szerződéshez, és minden művelethez adjon meg egy műveletet annak érdekében, hogy elkerülje http://tempuri.org az interfészek és metódusok nevét a szolgáltatás szerződésében, és ne legyenek közzétéve.

Paraméterek és műveletek hozzáadása

A szolgáltatás által közzétett szolgáltatásműveletek hozzáadása nem törhető változás, mivel a meglévő ügyfeleknek nem kell aggódniuk az új műveletek miatt.

Feljegyzés

A kétoldalas visszahívási szerződés műveleteinek hozzáadása kompatibilitástörő változás.

Műveletparaméter vagy visszatérési típus módosítása

A paraméter- vagy visszatérési típusok módosítása általában kompatibilitástörő változás, kivéve, ha az új típus ugyanazt az adatszerződést valósítja meg, amelyet a régi típus implementál. Ilyen módosítás elvégzéséhez adjon hozzá egy új műveletet a szolgáltatási szerződéshez, vagy határozzon meg egy új szolgáltatási szerződést.

Műveletek eltávolítása

A műveletek eltávolítása szintén kompatibilitástörő változás. Egy ilyen módosítás elvégzéséhez definiáljon egy új szolgáltatási szerződést, és tegye közzé egy új végponton.

Tartalék szerződések

Az FaultContractAttribute attribútum lehetővé teszi a szolgáltatásszerződés-fejlesztő számára, hogy a szerződés műveleteiből visszaadható hibákra vonatkozó információkat adjon meg.

A szolgáltatásszerződésben leírt hibák listája nem tekinthető teljesnek. A művelet bármikor visszaadhatja a szerződésben nem szereplő hibákat. Ezért a szerződésben leírt hibák halmazának módosítása nem minősül kompatibilitástörőnek. Ha például új hibát ad hozzá a szerződéshez, FaultContractAttribute vagy eltávolít egy meglévő hibát a szerződésből.

Szolgáltatásszerződés-kódtárak

A szervezetek rendelkezhetnek olyan szerződések kódtárával, amelyekben a szerződéseket közzéteszik egy központi adattárban, és a szolgáltatás megvalósítói az adattárból hajtanak végre szerződéseket. Ebben az esetben, amikor szolgáltatási szerződést tesz közzé az adattárban, nincs szabályozva, hogy ki hozza létre az azt megvalósító szolgáltatásokat. Ezért nem módosíthatja a szolgáltatási szerződést a közzététel után, így az gyakorlatilag megváltoztathatatlanná válik. A WCF támogatja a szerződések öröklését, amely egy meglévő szerződéseket kiterjesztő új szerződés létrehozásához használható. A szolgáltatás használatához definiáljon egy új szolgáltatási szerződési felületet, amely a régi szolgáltatási szerződés felületétől öröklődik, majd adjon hozzá metódusokat az új felülethez. Ezután módosítania kell a régi szerződést megvalósító szolgáltatást az új szerződés implementálásához, és módosítania kell a "versionOld" végpontdefiníciót az új szerződés használatára. A "versionOld" ügyfelek esetében a végpont továbbra is a "versionOld" szerződés felfedéseként jelenik meg; a "versionNew" ügyfelek számára a végpont megjelenik a "versionNew" szerződés közzétevőjeként.

Cím- és kötésverzió-készítés

A végpontcím és a kötés módosítása törést hoz, hacsak az ügyfelek nem képesek dinamikusan felderíteni az új végpontcímet vagy kötést. A képesség megvalósításának egyik mechanizmusa egy univerzális felderítési leírás és integrációs (UDDI) beállításjegyzék és az UDDI-hívási minta használata, ahol az ügyfél megpróbál kommunikálni egy végponttal, és hiba esetén lekérdez egy jól ismert UDDI-regisztrációs adatbázist az aktuális végpont metaadataihoz. Az ügyfél ezután a metaadatok címével és kötésével kommunikál a végponttal. Ha ez a kommunikáció sikeres, az ügyfél gyorsítótárazza a címet és a kötési információkat a jövőbeli használathoz.

Útválasztási szolgáltatás és verziószámozás

Ha a szolgáltatásban végrehajtott módosítások megszegik a módosításokat, és egy szolgáltatás két vagy több különböző verziójára van szüksége egyszerre, a WCF útválasztási szolgáltatással átirányíthatja az üzeneteket a megfelelő szolgáltatáspéldányra. A WCF útválasztási szolgáltatás tartalomalapú útválasztást használ, más szóval az üzeneten belüli információk alapján határozza meg, hogy hová kell irányítani az üzenetet. A WCF útválasztási szolgáltatással kapcsolatos további információkért lásd: Útválasztási szolgáltatás. A WCF útválasztási szolgáltatás szolgáltatásverzióhoz való használatára vonatkozó példa: Útmutató: Szolgáltatás verziószámozása.

Függelék

Az adatszerződések általános verziószámozási útmutatója, ha szigorú verziószámozásra van szükség, az adatszerződések nem módosíthatóként való kezelése és újak létrehozása, amikor módosításokra van szükség. Minden új adatszerződéshez létre kell hozni egy új osztályt, ezért olyan mechanizmusra van szükség, amely megakadályozza, hogy a régi adatszerződési osztályban megírt meglévő kódot át kell írni az új adatszerződési osztályra vonatkozóan.

Az egyik ilyen mechanizmus az interfészek használata az egyes adatszerződések tagjainak meghatározására, és belső implementációs kód írása az interfészek szempontjából, nem pedig az interfészeket megvalósító adatszerződési osztályok szerint. A szolgáltatás 1. verziójához tartozó alábbi kód egy felületet és egy IPurchaseOrderV1PurchaseOrderV1:

public interface IPurchaseOrderV1  
{  
    string OrderId { get; set; }  
    string CustomerId { get; set; }  
}  
  
[DataContract(  
Name = "PurchaseOrder",  
Namespace = "http://examples.microsoft.com/WCF/2005/10/PurchaseOrder")]  
public class PurchaseOrderV1 : IPurchaseOrderV1  
{  
    [DataMember(...)]  
    public string OrderId {...}  
    [DataMember(...)]  
    public string CustomerId {...}  
}

Bár a szolgáltatási szerződés műveleteit a rendszer a következő módon PurchaseOrderV1írná IPurchaseOrderV1le, a tényleges üzleti logika a következő lenne: . Ezután a 2. verzióban egy új IPurchaseOrderV2 felület és egy új PurchaseOrderV2 osztály jelenik meg az alábbi kódban látható módon:

public interface IPurchaseOrderV2  
{  
    DateTime OrderDate { get; set; }  
}

[DataContract(
Name = "PurchaseOrder",  
Namespace = "http://examples.microsoft.com/WCF/2006/02/PurchaseOrder")]  
public class PurchaseOrderV2 : IPurchaseOrderV1, IPurchaseOrderV2  
{  
    [DataMember(...)]  
    public string OrderId {...}  
    [DataMember(...)]  
    public string CustomerId {...}  
    [DataMember(...)]  
    public DateTime OrderDate { ... }  
}

A szolgáltatási szerződés úgy frissülne, hogy az tartalmazza azokat az új műveleteket, amelyek a következő módon PurchaseOrderV2vannak megírva: . A meglévő üzleti logika, amely meg van írva, IPurchaseOrderV1 továbbra is működni PurchaseOrderV2 fog, és az új üzleti logika, amely a tulajdonságot igényli, a OrderDate következő módon IPurchaseOrderV2lesz megírva: .

Lásd még