A szolgáltatás konfigurálása

A fordítható programot fordítsuk le, generáljuk le a diszken a SmsSzerver.exe programot!

11.4. A szolgáltatás konfigurálása

Amennyiben sikeresen generáltuk a szerver bináris formáját (pl. exe vagy dll kiterjesztéssel), mely tartalmazza a szerződést (contract), bátran indítsuk el a SvcConfigEditor.exe-t, a menüben nyissuk meg az App.config állományt! A konfigurációs fájl kitöltetlensége miatt egy eléggé üres állapotot látunk a szerkesztőben.

Kattintsunk a Services faelemhez tartozó Create a New Service... linkre! Egy párbeszédablak bukkan fel, mely a szolgáltatásunk nevére kíváncsi, de egy Browse gombot tartalmaz (11.21. ábra).

11.21. ábra. „Create a New Service ...”

A Browse segítségével keressük meg a lefordított szerver alkalmazás kódját a lemezen, és töltsük be! Jó tanács:

győződjünk meg róla, hogy az SvcConfigEditor verziója 4.0 vagy annál magasabb, mivel a korábbi verziók nem képesek kezelni a 4.0-s WCF-kódokat! Valamint ha 64 bites környezetben fejlesztünk, a Platform target-et fordítás előtt állítsuk Any CPU-ra, különben az SvcConfigEditor hajlamos hibát jelezni a megnyitáskor!

Ha mindent jól csináltunk, a Browse során nem csak az .exe állományunk nevéig jutunk el, hanem a ConfigEditor ki is bontja az exe tartalmát, és kilistázza a benne található ServiceContractot tartalmazó osztályok neveit. Válasszuk ki a megfelelő osztályt (11.22. ábra)!

11.22. ábra. A szolgáltatás tallózása az .exe-ből

A következő lépésekben a varázsló megkérdezi, milyen kommunikációs módot kívánunk használni. Válasszuk a HTTP-alapú kommunikációt (11.23. ábra)! A következő lépésben válasszuk az advanced (fejlett) webszolgáltatási protokollt (11.24. ábra), a simplex (csak a kliens kezdeményez függvényhívást a szerver oldalon) kommunikációs módot! Adjuk meg a címet (11.25. ábra, pl. „http://localhost:8082/SmsSzerver”), majd kattintsunk a Finish gombra! Egyszerűnek tűnik?

11.23. ábra. A kommunikációs protokoll választása

11.24. ábra. A protokoll finomítása

11.25. ábra. A szolgáltatás címe (address)

Mivel az így elkészült konfiguráció még nem exportálja a WSDL leírást, így tovább kell kattingatnunk a felületen. Az Advanced fában az Service Behaviors részen alakítsunk ki új viselkedési szabályt (New Service Behavior Configuration, 11.26. ábra)! Nem szükséges módosítani az alapértelmezett nevet (NewBehavior0), de talán érdemes, írjuk át pl. „WSDL-Publikalas”-ra, majd kattintsunk az Add gombra (11.26. ábra)! A felbukkanó listából válasszuk ki a serviceMetaData elemet (11.27. ábra)! A hozzáadott elemre kattintsunk kettőt (duplán), hogy a részleteit tudjuk szerkeszteni (a beállítóablakot korábban már bemutattuk a 11.14. ábra alapján)!

11.26. ábra. „New Service Behavior Configuration” ablak

11.27. ábra. A viselkedés neve és az Add gomb

11.28. ábra. A viselkedési beállítás kiválasztása

Ezek után térjünk vissza a Services faelemhez, és válasszuk ki a szolgáltatásunkat! A BehaviorConfiguration részben a legördülő listából válasszuk ki a WSDL-publikálási beállítást (11.29. ábra), és mentsünk (File/Save menüpont)!

11.29. ábra. A szolgáltatás és a viselkedés összekapcsolása

Tekintsük meg a kiegészített App.config fájl tartalmát! Mint látjuk, a szolgáltatás máris beállításra került. Ha ezen lépések előtt próbáltuk meg a szervert indítani, akkor kivételt dobott a végpontok konfigurálatlan volta miatt. Anélkül, hogy a szerver bináris formáját újrafordítottuk volna, az App.config beállítások miatt a szerver máris elindul, a szolgáltatás fut.

Térjünk vissza a titkosítás beállításaihoz! Keressük meg a fában az egyetlen (név nélküli) EndPointot, annak is a BindingConfiguration részét, és kattintsunk duplán az egyelőre üres mezőben! Ez létrehoz a Bindings fában egy új bejegyzést (és automatikusan ide csatolja az ottani beállításokat), lásd a 11.30. ábra. Ha ez mégsem működne (időnként rapszodikusan viselkedik ez a lépés), akkor a Bindings fában manuálisan kell megnyitni egy új bejegyzést (ennek során biztosan meg kell adni, hogy egy wsHttpBinding-hoz kell konfigurációs beállításokat létrehozni). A beállítási panelon felül válasszuk a Security fület, ahol rendelkezhetünk a titkosításokról (11.31.

ábra)!

11.30. ábra. Dupla kattintás a BindingConfigurationön

11.31. ábra. A Security fül beállítása

A „Mode” részen választhatunk, milyen szinten kívánjuk alkalmazni a titkosítást. Az alapértelmezett beállítás a

„Message” szint, vagyis maga az átvitel nem titkosított (a HTTP fejléc), de a beágyazott SOAP-üzenet már kódolásra kerül. Ez nekünk meg is felel. Széles skáláról választhatunk titkosítási algoritmusokat, melyekből a Basic256 az alapértelmezett. A különböző titkosítási algoritmusok ismertetése túlmutat ezen jegyzet keretein, de tudnunk kell, hogy az egyes módszerek több-kevesebb processzoridőt kötnek le, ami lassítja a működést, de esetleg nehezebben törhetőek fel. A választás tehát fontos, de a szükségtelenül erős kódolás esetleg felesleges erőforrás-lekötéseket és lassulást eredményez.

Az EstablishSecurityContext értékét érdemes true-ra állítani. Ez azt jelenti, hogy a szerver és a kliens a kapcsolat kiépülésekor cserél titkos kulcsot, és ugyanezen kulcsot használja végig a kommunikáció során.

Ellentétes értéke esetén hívásonként teszi ezt meg – ami további lassulást eredményezhet (de növeli a biztonságot).

A titkosítási beállítások áttekintése és definiálása után győződjünk meg, hogy az Endpoint beállításoknál a megfelelő Binding kiválasztásra kerüljön! A generált App.config fájl tartalmának az alábbiak szerint kell alakuljnia:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

<system.serviceModel>

<bindings>

<wsHttpBinding>

<binding name="WsdlTitkositas">

<security mode="Message">

<message clientCredentialType="Windows"

establishSecurityContext="true" />

</security>

</binding>

</wsHttpBinding>

</bindings>

<behaviors>

<serviceBehaviors>

<behavior name="WSDL-Publikalas">

<serviceMetadata httpGetEnabled="true"

httpGetUrl="http://localhost:8082/SmsSzerver" />

</behavior>

</serviceBehaviors>

</behaviors>

<services>

<service behaviorConfiguration="WSDL-Publikalas"

name="SmsService.SmsSzerver">

<endpoint address="http://localhost:8082/SmsSzerver"

binding="wsHttpBinding"

A belépéssel kapcsolatos (legegyszerűbb) megvalósítás azon alapszik, hogy a „felhasznalok” lista már fel van töltve adatokkal (pl. fájlból korábban beolvasásra került). A foreach ciklus időtartamára a lista zárolásra kerül, nehogy egy párhuzamos folyamat (szál) új felhasználóval bővítse, vagy töröljön belőle elemet. Ha sikeresen megtaláljuk a név + jelszó párossal azonosított rekordot, akkor a példányszintű belepett mezőben elmentjük a referenciáját.

public class SmsSzerver : ISmsSzerver {

static List<user> felhasznalok = new List<user>();

protected user belepett = null;

public bool bejelentkezes(string nev, string jelszo) {

Abból indulunk ki, hogy az uzenet lista nemcsak egyetlen, de minden egyes felhasználó üzenetét tartalmazza.

Ezért az adott felhasználó üzeneteinek megszámolásához minden egyes üzenetet sorra kell venni.