Programowanie uslug WCF Wydanie III prowcf

Tytuł oryginału: Programming WCF Services:
Mastering WCF and the Azure AppFabric Service Bus, 3rd edition

Tłumaczenie: Mikołaj Szczepaniak (wstęp, rozdz. 4 – 6, 11, dodatki),
Weronika Łabaj (rozdz. 1 – 3),
Krzysztof Rychlicki-Kicior (rozdz. 7 – 10)

ISBN: 978-83-246-3617-4

© HELION 2012.
Authorized Polish translation of the English edition of Programming WCF Services, 3rd Edition ISBN
9780596805487 © 2010, Juval Löwy.

This translation is published and sold by permission of O’Reilly Media, Inc., the owner of all rights to
publish and sell the same.

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording or by any information storage retrieval system,
without permission from the Publisher.

Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej
publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną,
fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje
naruszenie praw autorskich niniejszej publikacji.

Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich
właścicieli.

Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były
kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane
z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie
ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji
zawartych w książce.

Wydawnictwo HELION
ul. Kościuszki 1c, 44-100 GLIWICE
tel. 32 231 22 19, 32 230 98 63
e-mail: helion@helion.pl
WWW: http://helion.pl (księgarnia internetowa, katalog książek)

Drogi Czytelniku!
Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres
http://helion.pl/user/opinie/prowcf
Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.

Printed in Poland.

Księgarnia internetowa

•

Lubię to! » Nasza społeczność

Spis treci

Przedmowa ............................................................................................................................. 15

Sowo wstpne ....................................................................................................................... 19

1. Podstawy WCF .............................................................................................................29

Czym jest WCF?

Usugi

Granice wykonywania usugi

WCF i widoczno lokalizacji

Adresy

Adresy TCP

Adresy HTTP

Adresy IPC

Adresy MSMQ

Adresy magistrali usug

Kontrakty

Kontrakt usugi

Hosting

Hosting na IIS 5/6

Hosting wasny

Hosting WAS

Niestandardowy hosting na IIS/WAS

Pakiet usug AppFabric dla systemu Windows Server

Wybór hosta

Wizania

Podstawowe wizania

Wybór wizania

Dodatkowe rodzaje wiza

Uywanie wizania

Punkty kocowe

Konfiguracja punktów kocowych — plik konfiguracyjny

Konfiguracja punktów kocowych z poziomu programu

Domylne punkty kocowe

Kup książkę

Poleć książkę

Spis treci

Wymiana metadanych

Udostpnianie metadanych przez HTTP-GET

Punkt wymiany metadanych

Narzdzie Metadata Explorer

Wicej o konfiguracji zachowa

Programowanie po stronie klienta

Generowanie obiektu porednika

Konfiguracja klienta z poziomu pliku konfiguracyjnego

Konfiguracja klienta z poziomu programu

Klient testowy dostarczany przez WCF

Konfiguracja z poziomu programu a plik konfiguracyjny

Architektura WCF

Architektura hosta

Kanay

Klasa InProcFactory

Sesje warstwy transportowej

Sesja transportowa i wizania

Przerwanie sesji transportowej

Niezawodno 98

Wizania, niezawodno i kolejno wiadomoci

Konfiguracja niezawodnoci

100

Zachowanie kolejnoci dostarczania wiadomoci

101

2. Kontrakty usug ......................................................................................................... 103

Przecianie metod

103

Dziedziczenie kontraktów

105

Hierarchia kontraktów po stronie klienta

106

Projektowanie oraz faktoryzacja kontraktów usug

110

Faktoryzacja kontraktów

110

Metryki faktoryzacji

112

Kwerendy (przeszukiwanie metadanych)

114

Programowe przetwarzanie metadanych

114

Klasa MetadataHelper

116

3. Kontrakty danych .......................................................................................................121

Serializacja

121

Serializacja w .NET

123

Formatery WCF

124

Serializacja kontraktów danych

127

Atrybuty kontraktów danych

128

Importowanie kontraktu danych

130

Kontrakty danych i atrybut Serializable

132

Dedukowane kontrakty danych

133

Zoone kontrakty danych

135

Zdarzenia zwizane z kontraktami danych

135

Dzielone kontrakty danych

138

Poleć książkę

Kup książkę

Spis treci

Hierarchia kontraktów danych

139

Atrybut KnownType

139

Atrybut ServiceKnownType

141

Wielokrotne zastosowanie atrybutu KnownType

143

Konfiguracja akceptowanych klas pochodnych w pliku konfiguracyjnym

143

Analizatory kontraktów danych

144

Obiekty i interfejsy

153

Równowano kontraktów danych

155

Porzdek serializacji

156

Wersjonowanie 158

Nowe skadowe

158

Brakujce skadowe

159

Wersjonowanie dwukierunkowe

162

Typy wyliczeniowe

164

Delegaty i kontrakty danych

166

Typy generyczne

166

Kolekcje

169

Konkretne kolekcje

170

Kolekcje niestandardowe

171

Atrybut CollectionDataContract

172

Referencje do kolekcji

173

Sowniki 174

4. Zarzdzanie instancjami ............................................................................................177

Zachowania 177
Usugi aktywowane przez wywoania

178

Zalety usug aktywowanych przez wywoania

179

Konfiguracja usug aktywowanych przez wywoania

180

Usugi aktywowane przez wywoania i sesje transportowe

181

Projektowanie usug aktywowanych przez wywoania

182

Wybór usug aktywowanych przez wywoania

184

Usugi sesyjne

185

Konfiguracja sesji prywatnych

185

Sesje i niezawodno

190

Identyfikator sesji

191

Koczenie sesji

193

Usuga singletonowa

193

Inicjalizacja usugi singletonowej

194

Wybór singletonu

197

Operacje demarkacyjne

197

Dezaktywacja instancji

200

Konfiguracja z wartoci ReleaseInstanceMode.None

201

Konfiguracja z wartoci ReleaseInstanceMode.BeforeCall

201

Konfiguracja z wartoci ReleaseInstanceMode.AfterCall

202

Konfiguracja z wartoci ReleaseInstanceMode.BeforeAndAfterCall

203

Bezporednia dezaktywacja

203

Stosowanie dezaktywacji instancji

204

Poleć książkę

Kup książkę

Spis treci

Usugi trwae

205

Usugi trwae i tryby zarzdzania instancjami

205

Identyfikatory instancji i pami trwaa

206

Bezporednie przekazywanie identyfikatorów instancji

207

Identyfikatory instancji w nagówkach

209

Powizania kontekstu dla identyfikatorów instancji

211

Automatyczne zachowanie trwae

216

Dawienie

222

Konfiguracja dawienia

225

5. Operacje ..................................................................................................................... 231

Operacje danie-odpowied

231

Operacje jednokierunkowe

232

Konfiguracja operacji jednokierunkowych

232

Operacje jednokierunkowe i niezawodno

233

Operacje jednokierunkowe i usugi sesyjne

233

Operacje jednokierunkowe i wyjtki

234

Operacje zwrotne

236

Kontrakt wywoa zwrotnych

236

Przygotowanie obsugi wywoa zwrotnych po stronie klienta

238

Stosowanie wywoa zwrotnych po stronie usugi

241

Zarzdzanie poczeniami dla wywoa zwrotnych

244

Porednik dupleksowy i bezpieczestwo typów

246

Fabryka kanaów dupleksowych

249

Hierarchia kontraktów wywoa zwrotnych

251

Zdarzenia

252

Strumieniowe przesyanie danych

256

Strumienie wejcia-wyjcia

256

Strumieniowe przesyanie komunikatów i powizania

257

Przesyanie strumieniowe i transport

258

6. Bdy .......................................................................................................................... 261

Izolacja bdów i eliminowanie zwizków

261

Maskowanie bdów

262

Oznaczanie wadliwego kanau

263

Propagowanie bdów

267

Kontrakty bdów

268

Diagnozowanie bdów

272

Bdy i wywoania zwrotne

278

Rozszerzenia obsugujce bdy

281

Udostpnianie bdu

282

Obsuga bdu

285

Instalacja rozszerze obsugujcych bdy

287

Host i rozszerzenia obsugujce bdy

290

Wywoania zwrotne i rozszerzenia obsugujce bdy

293

Poleć książkę

Kup książkę

Spis treci

7. Transakcje .................................................................................................................. 297

Problem z przywracaniem dziaania aplikacji

297

Transakcje

298

Zasoby transakcyjne

299

Waciwoci transakcji

299

Zarzdzanie transakcjami

301

Menedery zasobów

304

Propagacja transakcji

304

Przepyw transakcji a wizania

305

Przepyw transakcji a kontrakt operacji

306

Wywoania jednokierunkowe

308

Menedery i protokoy transakcji

308

Protokoy i wizania

309

Menedery transakcji

310

Awansowanie menederów transakcji

313

Klasa Transaction

314

Transakcje otoczenia

314

Transakcje lokalne a transakcje rozproszone

315

Programowanie usug transakcyjnych

316

Przygotowywanie otoczenia transakcji

316

Tryby propagacji transakcji

318

Gosowanie a zakoczenie transakcji

325

Izolacja transakcji

328

Limit czasu transakcji

330

Jawne programowanie transakcji

332

Klasa TransactionScope

332

Zarzdzanie przepywem transakcji

334

Klienci nieusugowi

340

Zarzdzanie stanem usugi

341

Granice transakcji

342

Zarzdzanie instancjami a transakcje

343

Usugi transakcyjne typu per-call

344

Usugi transakcyjne typu per-session

347

Transakcyjne usugi trwae

359

Zachowania transakcyjne

361

Transakcyjna usuga singletonu

366

Transakcje a tryby instancji

369

Wywoania zwrotne

371

Tryby transakcji w wywoaniach zwrotnych

371

Gosowanie w wywoaniach zwrotnych

373

Stosowanie transakcyjnych wywoa zwrotnych

373

Poleć książkę

Kup książkę

Spis treci

8. Zarzdzanie wspóbienoci ................................................................................... 377

Zarzdzanie instancjami a wspóbieno

377

Tryby wspóbienoci usug

378

ConcurrencyMode.Single 379
ConcurrencyMode.Multiple 379
ConcurrencyMode.Reentrant 382

Instancje a dostp wspóbieny

385

Usugi typu per-call

385

Usugi sesyjne i usugi typu singleton

386

Zasoby i usugi

386

Dostp a zakleszczenia

387

Unikanie zakleszcze

388

Kontekst synchronizacji zasobów

389

Konteksty synchronizacji .NET

390

Kontekst synchronizacji interfejsu uytkownika

392

Kontekst synchronizacji usug

397

Hostowanie w wtku interfejsu uytkownika

398

Formularz jako usuga

403

Wtek interfejsu uytkownika a zarzdzanie wspóbienoci

406

Wasne konteksty synchronizacji usug

408

Synchronizator puli wtków

408

Powinowactwo wtków

413

Przetwarzanie priorytetowe

415

Wywoania zwrotne a bezpieczestwo klientów

418

Wywoania zwrotne w trybie ConcurrencyMode.Single

419

Wywoania zwrotne w trybie ConcurrencyMode.Multiple

419

Wywoania zwrotne w trybie ConcurrencyMode.Reentrant

420

Wywoania zwrotne i konteksty synchronizacji

420

Wywoania zwrotne a kontekst synchronizacji interfejsu uytkownika

421

Wasne konteksty synchronizacji a wywoania zwrotne

424

Wywoania asynchroniczne

427

Wymagania mechanizmów asynchronicznych

427

Wywoania asynchroniczne przy uyciu porednika (proxy)

429

Wywoania asynchroniczne

430

Zapytania a oczekiwanie na zakoczenie

432

Wywoania zwrotne dopeniajce

434

Asynchroniczne operacje jednokierunkowe

439

Asynchroniczna obsuga bdów

442

Wywoania asynchroniczne a transakcje

443

Wywoania synchroniczne kontra asynchroniczne

443

9. Usugi kolejkowane ...................................................................................................445

Usugi i klienty odczone

445

Wywoania kolejkowane

446

Architektura wywoa kolejkowanych

447

Kontrakty kolejkowane

447

Konfiguracja i ustawienia

448

Poleć książkę

Kup książkę

Spis treci

Transakcje

454

Dostarczanie i odtwarzanie

455

Transakcyjne ustawienia usugi

456

Kolejki nietransakcyjne

459

Zarzdzanie instancjami

460

Usugi kolejkowane typu per-call

460

Kolejkowane usugi sesyjne

462

Usuga singleton

465

Zarzdzanie wspóbienoci

466

Kontrola przepustowoci

467

Bdy dostarczania

467

Kolejka utraconych komunikatów

469

Czas ycia

469

Konfiguracja kolejki odrzuconych komunikatów

470

Przetwarzanie kolejki odrzuconych komunikatów

471

Bdy odtwarzania

475

Komunikaty trujce

476

Obsuga komunikatów trujcych w MSMQ 4.0

477

Obsuga komunikatów trujcych w MSMQ 3.0

480

Wywoania kolejkowane kontra poczone

481

Wymaganie kolejkowania

483

Usuga odpowiedzi

484

Tworzenie kontraktu usugi odpowiedzi

485

Programowanie po stronie klienta

488

Programowanie kolejkowane po stronie usugi

491

Programowanie odpowiedzi po stronie usugi

492

Transakcje 493

Mostek HTTP

496

Projektowanie mostka

496

Konfiguracja transakcji

497

Konfiguracja po stronie usugi

498

Konfiguracja po stronie klienta

499

10. Bezpieczestwo ......................................................................................................... 501

Uwierzytelnianie 501
Autoryzacja 502
Bezpieczestwo transferu danych

503

Tryby bezpieczestwa transferu danych

503

Konfiguracja trybu bezpieczestwa transferu danych

505

Tryb Transport a powiadczenia

507

Tryb Komunikat a powiadczenia

508

Zarzdzanie tosamoci

509

Polityka ogólna

509

Analiza przypadków uycia

510

Poleć książkę

Kup książkę

Spis treci

Aplikacja intranetowa

510

Zabezpieczanie wiza intranetowych

511

Ograniczanie ochrony komunikatów

517

Uwierzytelnianie 518
Tosamoci 520
Kontekst bezpieczestwa wywoa

521

Personifikacja 523
Autoryzacja 530
Zarzdzanie tosamoci

535

Wywoania zwrotne

536

Aplikacja internetowa

537

Zabezpieczanie wiza internetowych

537

Ochrona komunikatów

539

Uwierzytelnianie 543
Stosowanie powiadcze systemu Windows

545

Stosowanie dostawców ASP.NET

546

Zarzdzanie tosamoci

554

Aplikacja biznesowa

554

Zabezpieczanie wiza w scenariuszu B2B

554

Uwierzytelnianie 555
Autoryzacja 557
Zarzdzanie tosamoci

559

Konfiguracja bezpieczestwa hosta

559

Aplikacja o dostpie anonimowym

559

Zabezpieczanie anonimowych wiza

560

Uwierzytelnianie 561
Autoryzacja 561
Zarzdzanie tosamoci

561

Wywoania zwrotne

561

Aplikacja bez zabezpiecze

562

Odbezpieczanie wiza

562

Uwierzytelnianie 562
Autoryzacja 562
Zarzdzanie tosamoci 562
Wywoania zwrotne

563

Podsumowanie scenariuszy

563

Deklaratywny framework bezpieczestwa

563

Atrybut SecurityBehavior

564

Deklaratywne bezpieczestwo po stronie hosta

571

Deklaratywne bezpieczestwo po stronie klienta

572

Audyt bezpieczestwa

578

Konfigurowanie audytów bezpieczestwa

579

Deklaratywne bezpieczestwo audytów

581

Poleć książkę

Kup książkę

Spis treci

11. Magistrala usug ........................................................................................................583

Czym jest usuga przekazywania?

584

Magistrala Windows Azure AppFabric Service Bus

585

Programowanie magistrali usug

586

Adres usugi przekazywania

586

Rejestr magistrali usug

589

Eksplorator magistrali usug

590

Powizania magistrali usug

591

Powizanie przekazywania TCP

591

Powizanie przekazywania WS 2007

595

Jednokierunkowe powizanie przekazywania

596

Powizanie przekazywania zdarze

597

Chmura jako strona przechwytujca wywoania

599

Bufory magistrali usug

600

Bufory kontra kolejki

600

Praca z buforami

601

Wysyanie i otrzymywanie komunikatów

607

Usugi buforowane

608

Usuga odpowiedzi

617

Uwierzytelnianie w magistrali usug

621

Konfiguracja uwierzytelniania

622

Uwierzytelnianie z tajnym kluczem wspódzielonym

623

Brak uwierzytelniania

627

Magistrala usug jako ródo metadanych

628

Bezpieczestwo transferu

630

Bezpieczestwo na poziomie transportu

631

Bezpieczestwo na poziomie komunikatów

632

Powizanie przekazywania TCP i bezpieczestwo transferu

633

Powizanie przekazywania WS i bezpieczestwo transferu

639

Jednokierunkowe powizanie przekazywania i bezpieczestwo transferu

640

Powizania i tryby transferu

641

Usprawnianie zabezpiecze transferu

641

A Wprowadzenie modelu usug ...................................................................................647

B Nagówki i konteksty .................................................................................................663

C Odkrywanie ...............................................................................................................685

D Usuga publikacji-subskrypcji ................................................................................... 733

E Uniwersalny mechanizm przechwytywania ............................................................ 765

F Standard kodowania usug WCF ............................................................................... 779

G Katalog elementów biblioteki ServiceModelEx ....................................................... 791

Skorowidz ............................................................................................................................. 813

Poleć książkę

Kup książkę

Spis treci

Poleć książkę

Kup książkę

177

ROZDZIA 4.

Zarzdzanie instancjami

(ang. instance management) to okrelenie, które stosuj w kontekcie

zbioru technik uywanych przez technologi WCF do kojarzenia da klientów z instancjami
usug — technik decydujcych o tym, która instancja usugi obsuguje które danie klienta
i kiedy to robi. Zarzdzanie instancjami jest konieczne, poniewa zasadnicze rónice dzielce
poszczególne aplikacje w wymiarze potrzeb skalowalnoci, wydajnoci, przepustowoci, trwa-
oci, transakcji i wywoa kolejkowanych w praktyce uniemoliwiaj opracowanie jednego,
uniwersalnego rozwizania. Istnieje jednak kilka klasycznych technik zarzdzania instancjami,
które mona z powodzeniem stosowa w wielu ronych aplikacjach i które sprawdzaj si
w najróniejszych scenariuszach i modelach programistycznych. Wanie o tych technikach
bdzie mowa w niniejszym rozdziale. Ich dobre zrozumienie jest warunkiem tworzenia skalo-
walnych i spójnych aplikacji. Technologia WCF obsuguje trzy rodzaje aktywacji instancji: przy-
dzielanie (i niszczenie) usug przez wywoania, gdzie kade danie klienta powoduje utworze-
nie nowej instancji; przydzielanie instancji dla kadego poczenia z klientem (w przypadku
usug sesyjnych

) oraz usugi singletonowe, w których jedna instancja usugi jest wspódzielona

przez wszystkie aplikacje klienckie (dla wszystkich pocze i aktywacji). W tym rozdziale
zostan omówione zalety i wady wszystkich trzech trybów zarzdzania instancjami. Rozdzia
zawiera te wskazówki, jak i kiedy najskuteczniej uywa poszczególnych trybów. Omówi te
kilka pokrewnych zagadnie, jak zachowania, konteksty, operacje demarkacyjne, dezaktywacja
instancji, usugi trwae czy tzw. dawienie.

Zachowania

Tryb instancji usug jest w istocie jednym ze szczegóowych aspektów implementacji po stronie
usugi, który w aden sposób nie powinien wpywa na funkcjonowanie strony klienckiej. Na
potrzeby obsugi tego i wielu innych lokalnych aspektów strony usugi technologia WCF defi-
niuje pojcie zachowa (ang. behavior). Zachowanie to pewien lokalny atrybut usugi lub klienta,
który nie wpywa na wzorce komunikacji pomidzy tymi stronami. Klienty nie powinny zalee
od zachowa usug, a same zachowania nie powinny by ujawniane w powizaniach usug ani
publikowanych metadanych. We wczeniejszych rozdziaach mielimy ju do czynienia z dwoma
zachowaniami usug. W rozdziale 1. uyto zachowa metadanych usugi do zasygnalizowania

Ten rozdzia zawiera fragmenty moich artykuów zatytuowanych WCF Essentials: Discover Mighty Instance
Management Techniques for Developing WCF Apps („MSDN Magazine”, czerwiec 2006) oraz Managing State with
Durable Services („MSDN Magazine”, padziernik 2008).

Poleć książkę

Kup książkę

178

Rozdzia 4. Zarzdzanie instancjami

hostowi koniecznoci publikacji metadanych usugi za porednictwem dania HTTP-GET oraz
do implementacji punktu kocowego MEX, natomiast w rozdziale 3. wykorzystano zachowanie
usugi do ignorowania rozszerzenia obiektu danych. Na podstawie przebiegu komunikacji czy
wymienianych komunikatów aden klient nie moe stwierdzi, czy usuga ignoruje rozsze-
rzenie obiektu danych ani jak zostay opublikowane jej metadane.

Technologia WCF definiuje dwa typy deklaratywnych zachowa strony usugi opisywane
przez dwa odpowiednie atrybuty. Atrybut

ServiceBehaviorAttribute

suy do konfigurowania

zachowa usugi, czyli zachowa wpywajcych na jej wszystkie punkty kocowe (kontrakty
i operacje). Atrybut

ServiceBehavior

naley stosowa bezporednio dla klasy implementacji usugi.

Atrybut

OperationBehaviorAttribute

suy do konfigurowania zachowa operacji, czyli zacho-

wa wpywajcych tylko na implementacj okrelonej operacji. Atrybutu

OperationBehavior

mona uy tylko dla metody implementujcej operacj kontraktu, nigdy dla definicji tej ope-
racji w samym kontrakcie. Praktyczne zastosowania atrybutu

OperationBehavior

zostan poka-

zane zarówno w dalszej czci tego rozdziau, jak i w kolejnych rozdziaach.

W tym rozdziale atrybut

ServiceBehavior

bdzie uywany do konfigurowania trybu instancji

usugi. Na listingu 4.1 pokazano przykad uycia tego atrybutu do zdefiniowania waciwoci

InstanceContextMode

typu wyliczeniowego

InstanceContextMode

. Warto wyliczenia

Instance

ContextMode

steruje trybem zarzdzania instancjami stosowanym dla tej usugi.

Listing 4.1. Przykad uycia atrybutu ServiceBehaviorAttribute do skonfigurowania trybu kontekstu instancji

public enum InstanceContextMode
{
PerCall,
PerSession,
Single
}
[AttributeUsage(AttributeTargets.Class)]
public sealed class ServiceBehaviorAttribute : Attribute,...
{
public InstanceContextMode InstanceContextMode
{get;set;}

// Pozostae skadowe…

}

Typ wyliczeniowy nieprzypadkowo nazwano

InstanceContextMode

zamiast

InstanceMode

, ponie-

wa jego wartoci steruj trybem tworzenia instancji kontekstu zarzdzajcego dan instancj,
nie trybem dziaania samej instancji (w rozdziale 1. wspomniano, e kontekst instancji wyznacza
najbardziej wewntrzny zasig usugi). Okazuje si jednak, e instancja i jej kontekst domylnie
s traktowane jako pojedyncza jednostka, zatem wspomniane wyliczenie steruje take cyklem
ycia instancji. W dalszej czci tego rozdziau i w kolejnych rozdziaach omówi moliwe spo-
soby (i przyczyny) oddzielania obu elementów.

Usugi aktywowane przez wywoania

Jeli rodzaj usugi skonfigurowano z myl o aktywacji przez wywoania (ang. per-call activation),
instancja tej usugi (obiekt rodowiska CLR) istnieje tylko w trakcie obsugi wywoania ze
strony klienta. Kade danie klienta (czyli wywoanie metody dla kontraktu WCF) otrzymuje
now, dedykowan instancj usugi. Dziaanie usugi w trybie aktywacji przez wywoania wyja-
niono w poniszych punktach (wszystkie te kroki pokazano te na rysunku 4.1):

Poleć książkę

Kup książkę

Usugi aktywowane przez wywoania

_ 179

Rysunek 4.1. Tryb tworzenia instancji przez wywoania

Klient wywouje porednika (ang. proxy), który kieruje to wywoanie do odpowiedniej usugi.

rodowisko WCF tworzy nowy kontekst z now instancj usugi i wywouje metod tej
instancji.

Jeli dany obiekt implementuje interfejs

IDisposable

, po zwróceniu sterowania przez wywo-

an metod rodowisko WCF wywouje metod

IDisposable.Dispose()

zdefiniowan przez

ten obiekt. rodowisko WCF niszczy nastpnie kontekst usugi.

Klient wywouje porednika, który kieruje to wywoanie do odpowiedniej usugi.

rodowisko WCF tworzy obiekt i wywouje odpowiedni metod nowego obiektu.

Jednym z najciekawszych aspektów tego trybu jest zwalnianie (niszczenie) instancji usugi. Jak
ju wspomniano, jeli usuga obsuguje interfejs

IDisposable

, rodowisko WCF automatycznie

wywoa metod

Dispose()

, umoliwiajc tej usudze zwolnienie zajmowanych zasobów. Warto

pamita, e metoda

Dispose()

jest wywoywana w tym samym wtku co oryginalna metoda

usugi i e dysponuje kontekstem operacji (patrz dalsza cz tego rozdziau). Po wywoaniu
metody

Dispose()

rodowisko WCF odcza instancj usugi od pozostaych elementów swojej

infrastruktury, co oznacza, e instancja moe zosta zniszczona przez proces odzyskiwania
pamici.

Zalety usug aktywowanych przez wywoania

W klasycznym modelu programowania klient-serwer implementowanym w takich jzykach
jak C++ czy C# kady klient otrzymuje wasny, dedykowany obiekt serwera. Zasadnicz wad
tego modelu jest niedostateczna skalowalno. Wyobramy sobie aplikacj, która musi obsuy
wiele aplikacji klienckich. Typowym rozwizaniem jest tworzenie po stronie serwera obiektu
w momencie uruchamiania kadej z tych aplikacji i zwalnianie go zaraz po zakoczeniu dzia-
ania aplikacji klienckiej. Skalowalno klasycznego modelu klient-serwer jest o tyle trudna,
e aplikacje klienckie mog utrzymywa swoje obiekty bardzo dugo, mimo e w rzeczywisto-
ci uywaj ich przez niewielki uamek tego czasu. Takie obiekty mog zajmowa kosztowne
i deficytowe zasoby, jak poczenia z bazami danych, porty komunikacyjne czy pliki. Jeli ka-
demu klientowi jest przydzielany osobny obiekt, te cenne i (lub) ograniczone zasoby s zajmo-
wane przez dugi czas, co prdzej czy póniej musi doprowadzi do ich wyczerpania.

Poleć książkę

Kup książkę

180

Rozdzia 4. Zarzdzanie instancjami

Lepszym modelem aktywacji jest przydzielanie obiektu dla klienta tylko na czas wykonywania
wywoania usugi. W takim przypadku naley utworzy i utrzymywa w pamici tylko tyle
obiektów, ile wspóbienych wywoa jest obsugiwanych przez usug (nie tyle obiektów, ile
istnieje niezamknitych aplikacji klienckich). Z dowiadczenia wiem, e w typowym systemie
korporacyjnym, szczególnie takim, gdzie o dziaaniu aplikacji klienckich decyduj uytkownicy,
tylko 1% klientów wykonuje wspóbiene wywoania (w przypadku mocno obcionych sys-
temów ten odsetek wzrasta do 3%). Oznacza to, e jeli system jest w stanie obsuy sto kosz-
townych instancji usugi, w typowych okolicznociach moe wspópracowa z dziesicioma
tysicami klientów. Tak due moliwoci systemu wynikaj wprost z trybu aktywacji przez
wywoania. Pomidzy wywoaniami klient dysponuje tylko referencj do porednika, który nie
zajmuje waciwego obiektu po stronie usugi. Oznacza to, e mona zwolni kosztowne zasoby
zajmowane przez instancj usugi na dugo przed zamkniciem porednika przez klienta. Podob-
nie uzyskiwanie dostpu do zasobów jest odkadane do momentu, w którym te zasoby rzeczy-
wicie s potrzebne klientowi.

Naley pamita, e wielokrotne tworzenie i niszczenia instancji po stronie usugi bez zamy-
kania poczenia z klientem (a konkretnie z porednikiem po stronie klienta) jest nieporów-
nanie mniej kosztowne ni wielokrotne tworzenie zarówno instancji, jak i poczenia. Drug
wan zalet tego rozwizania jest zgodno z zasobami transakcyjnymi i technikami progra-
mowania transakcyjnego (patrz rozdzia 7.), poniewa przydzielanie instancji usugi i niezbd-
nych zasobów osobno dla kadego wywoania uatwia zapewnianie spójnoci stanu tych instan-
cji. Trzeci zalet usug aktywowanych przez wywoania jest moliwo stosowania tych usug
w rodowisku z kolejkowanymi, rozczonymi wywoaniami (patrz rozdzia 9.), poniewa tak
dziaajce instancje mona atwo odwzorowywa na kolejkowane komunikaty.

Konfiguracja usug aktywowanych przez wywoania

Aby skonfigurowa typ usugi aktywowanej przez wywoania, naley uy atrybutu

Service

Behavior

z wartoci

InstanceContextMode.PerCall

ustawion we waciwoci

InstanceContextMode

[ServiceContract]
interface IMyContract
{...}

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
class MyService : IMyContract
{...}

Na listingu 4.2 pokazano przykad prostej usugi aktywowanej przez wywoania i jej klienta.
Jak wida w danych wynikowych tego programu, dla kadego wywoania metody ze strony
klienta jest konstruowana nowa instancja usugi.

Listing 4.2. Usuga aktywowana przez wywoania i jej klient

///////////////////////// Kod usugi /////////////////////
[ServiceContract]
interface IMyContract
{
[OperationContract]
void MyMethod();
}
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
class MyService : IMyContract,IDisposable
{

Poleć książkę

Kup książkę

Usugi aktywowane przez wywoania

_ 181

int m_Counter = 0;

MyService()
{
Trace.WriteLine("MyService.MyService()");
}
public void MyMethod()
{
m_Counter++;
Trace.WriteLine("Licznik = " + m_Counter);
}
public void Dispose()
{
Trace.WriteLine("MyService.Dispose()");
}
}
///////////////////////// Kod klienta /////////////////////
MyContractClient proxy = new MyContractClient();

proxy.MyMethod();
proxy.MyMethod();

proxy.Close();

// Moliwe dane wynikowe
MyService.MyService()
Licznik = 1
MyService.Dispose()
MyService.MyService()
Licznik = 1
MyService.Dispose()

Usugi aktywowane przez wywoania i sesje transportowe

Stosowanie usug aktywowanych przez wywoania nie zaley od obecnoci sesji transportowej
(patrz rozdzia 1.). Sesja transportowa porzdkuje wszystkie komunikaty kierowane przez okre-
lonego klienta do konkretnego kanau. Nawet jeli sesj skonfigurowano pod ktem aktywacji
przez wywoania, stosowanie sesji transportowej wci jest moliwe, tyle e kade wywoanie
usugi WCF bdzie powodowao utworzenie nowego kontekstu tylko na potrzeby tego wywo-
ania. Jeli sesje poziomu transportowego nie s stosowane, usuga — o czym za chwil si prze-
konamy — zawsze, niezalenie od konfiguracji zachowuje si tak, jakby bya aktywowana przez
wywoania.

Jeli usuga aktywowana przez wywoania dysponuje sesj transportow, komunikacja z klien-
tem jest przerywana po pewnym czasie braku aktywnoci tej sesji (odpowiedni limit czasowy
domylnie wynosi 10 minut). Po osigniciu tego limitu czasowego klient nie moe dalej
uywa porednika do wywoywania operacji udostpnianych przez usug aktywowan przez
wywoania, poniewa sesja transportowa zostaa zamknita.

Sesje transportowe maj najwikszy wpyw na dziaanie usug aktywowanych przez wywo-
ania w sytuacji, gdy te usugi skonfigurowano z myl o dostpie jednowtkowym (zgodnie
z domylnymi ustawieniami rodowiska WCF — patrz rozdzia 8.). Sesja transportowa wymu-
sza wówczas wykonywanie operacji w trybie blokada-krok (ang. lock-step), gdzie wywoania
od tego samego porednika s szeregowane. Oznacza to, e nawet jeli jeden klient jednoczenie
generuje wiele wywoa, wszystkie te wywoania s pojedynczo, kolejno wykonywane przez
róne instancje. Takie dziaanie ma istotny wpyw na proces zwalniania instancji. rodowisko

Poleć książkę

Kup książkę

182

Rozdzia 4. Zarzdzanie instancjami

WCF nie blokuje dziaania klienta w czasie zwalniania instancji usugi. Jeli jednak w czasie
wykonywania metody

Dispose()

klient wygeneruje kolejne wywoanie, dostp do nowej instan-

cji i obsuga tego wywoania bd moliwe dopiero po zwróceniu sterowania przez metod

Dispose()

. Na przykad dane wynikowe z koca listingu 4.2 ilustruj przypadek, w którym

istnieje sesja transportowa. W przedstawionym scenariuszu drugie wywoanie moe by wyko-
nane dopiero po zwróceniu sterowania przez metod

Dispose()

. Gdyby usuga z listingu 4.2

nie stosowaa sesji transportowej, dane wynikowe co prawda mogyby by takie same, ale te
mogyby pokazywa zmienion kolejno wywoa (w wyniku dziaania nieblokujcej metody

Dispose()

MyService.MyService()
Licznik = 1
MyService.MyService()
Licznik = 1
MyService.Dispose()
MyService.Dispose()

Projektowanie usug aktywowanych przez wywoania

Mimo e w teorii tryb aktywacji instancji przez wywoania mona stosowa dla usug dowol-
nego typu, w rzeczywistoci usug i jej kontrakt naley od pocztku projektowa z myl
o obsudze tego trybu. Zasadniczy problem polega na tym, e klient nie wie, e w odpowiedzi
na kade swoje wywoanie otrzymuje now instancj. Usugi aktywowane przez wywoania
musz utrzymywa swój stan, tzn. musz tak zarzdza tym stanem, aby klient mia wraenie
istnienia cigej sesji. Usugi stanowe z natury rzeczy róni si od usug bezstanowych. Gdyby
usuga aktywowana przez wywoania bya w peni bezstanowa, w praktyce aktywacja dla kolej-
nych wywoa w ogóle nie byaby potrzebna. Wanie istnienie stanu, a konkretnie kosztownego
stanu obejmujcego zasoby, decyduje o potrzebie stosowania trybu aktywacji przez wywoa-
nia. Instancja usugi aktywowanej przez wywoania jest tworzona bezporednio przed kadym
wywoaniem metody i niszczona bezporednio po kadym wywoaniu. Oznacza to, e na
pocztku kadego wywoania obiekt powinien inicjalizowa swój stan na podstawie wartoci
zapisanych w jakiej pamici, a na kocu wywoania powinien zapisa swój stan w tej pamici.
W roli pamici zwykle stosuje si albo baz danych, albo system plików, jednak równie dobrze
mona wykorzysta jak pami ulotn, na przykad zmienne statyczne.

Okazuje si jednak, e nie wszystkie elementy stanu obiektu mona zapisa. Jeli na przykad
stan obejmuje poczenie z baz danych, obiekt musi ponownie uzyskiwa to poczenie pod-
czas tworzenia instancji (lub na pocztku kadego wywoania) oraz zwalnia je po zakoczeniu
wywoania lub we wasnej implementacji metody

IDisposable.Dispose()

Stosowanie trybu aktywacji przez wywoania ma zasadniczy wpyw na projekt operacji —
kada operacja musi otrzymywa parametr identyfikujcy instancj usugi, której stan naley
odtworzy. Instancja uywa tego parametru do odczytania swojego stanu z pamici (zamiast
stanu innej instancji tego samego typu). Wanie dlatego pami stanów zwykle jest porzdko-
wana wedug kluczy (moe mie na przykad posta statycznego sownika w pamici lub tabeli
bazy danych). Parametry stanów mog reprezentowa na przykad numer konta w przypadku
usugi bankowej, numer zamówienia w przypadku usugi przetwarzajcej zamówienia itp.

Listing 4.3 zawiera szablon implementacji usugi aktywowanej przez wywoania.

Poleć książkę

Kup książkę

Usugi aktywowane przez wywoania

_ 183

Listing 4.3. Implementacja usugi aktywowanej przez wywoania

[DataContract]
class Param
{...}

[ServiceContract]
interface IMyContract
{
[OperationContract]
void MyMethod(Param stateIdentifier);
}

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
class MyPerCallService : IMyContract,IDisposable
{
public void MyMethod(Param stateIdentifier)
{
GetState(stateIdentifier);
DoWork();
SaveState(stateIdentifier);
}
void GetState(Param stateIdentifier)
{...}
void DoWork()
{...}
void SaveState(Param stateIdentifier)
{...}
public void Dispose()
{...}
}

Klasa implementuje operacj

MyMethod()

, która otrzymuje na wejciu parametr typu

Param

(czyli typu danych wymylonego na potrzeby tego przykadu) identyfikujcy odpowiedni
instancj:

public void MyMethod(Param stateIdentifier)

Instancja usugi uywa tego identyfikatora do uzyskania swojego stanu i jego ponownego zapi-
sania na kocu wywoania wspomnianej metody. Elementy skadowe stanu, które s wspólne
dla wszystkich klientów, mona przydziela w kodzie konstruktora i zwalnia w kodzie metody

Dispose()

Tryb aktywacji przez wywoania sprawdza si najlepiej w sytuacji, gdy kade wywoanie metody
w peni realizuje okrelone zadanie (gdy po zwróceniu sterowania przez metod nie s wyko-
nywane w tle adne dodatkowe czynnoci). Poniewa obiekt jest usuwany zaraz po zako-
czeniu wykonywania metody, nie naley uruchamia adnych wtków dziaajcych w tle ani
stosowa wywoa asynchronicznych.

Poniewa metoda usugi aktywowana przez wywoania kadorazowo odczytuje stan instancji
z jakiej pamici, usugi tego typu wprost doskonale wspópracuj z mechanizmami równowa-
enia obcie (pod warunkiem e repozytorium stanów ma posta globalnego zasobu dostp-
nego dla wszystkich komputerów). Mechanizm równowaenia obcie moe kierowa wywo-
ania na róne serwery, poniewa kada usuga aktywowana przez wywoania moe zrealizowa
wywoanie po uzyskaniu stanu odpowiedniej instancji.

Poleć książkę

Kup książkę

184

Rozdzia 4. Zarzdzanie instancjami

Wydajno usug aktywowanych przez wywoania

Usugi aktywowane przez wywoania s kompromisem polegajcym na nieznacznym spadku
wydajnoci (z powodu dodatkowych kosztów uzyskiwania i zapisywania stanu instancji przy
okazji kadego wywoania metody) na rzecz wikszej skalowalnoci (dziki przechowywaniu
stanu i zwizanych z nim zasobów). Nie istniej jasne, uniwersalne reguy, wedug których
mona by ocenia, kiedy warto powici cz wydajnoci w celu znacznej poprawy skalowal-
noci. W pewnych przypadkach najlepszym rozwizaniem jest profilowanie systemu i zapro-
jektowanie czci usug korzystajcych z tej formy aktywacji i czci usug pracujcych w innych
trybach.

Operacje czyszczenia rodowiska

To, czy typ usugi obsuguje interfejs

IDisposable

, naley traktowa jako szczegó implementa-

cji, który w aden sposób nie wpywa na sposób funkcjonowania klienta. Sam klient w aden
sposób nie moe wywoa metody

Dispose()

. Podczas projektowania kontraktu dla usugi

aktywowanej przez wywoania naley unika definiowania operacji, których zadaniem byoby
„czyszczenie” stanu czy zwalnianie zasobów, jak w poniszym przykadzie:

// Tego naley unika
[ServiceContract]
interface IMyContract
{
void DoSomething();
void Cleanup();
}
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
class MyPerCallService : IMyContract,IDisposable
{
public void DoSomething()
{...}
public void Cleanup()
{...}
public void Dispose()
{
Cleanup();
}
}

Powyszy projekt ma do oczywist wad — jeli klient wywoa metod

Cleanup()

, spowo-

duje utworzenie nowego obiektu tylko na potrzeby wykonania tej metody. Co wicej, po jej
zakoczeniu rodowisko WCF wywoa metod

IDisposable.Dispose()

(jeli istnieje w tej usudze),

aby ponownie zwolni zasoby i wyczyci stan usugi.

Wybór usug aktywowanych przez wywoania

Mimo e model programowania usug aktywowanych przez wywoania moe wydawa si
do dziwny programistom przyzwyczajonym do architektury klient-serwer, wanie ten tryb
zarzdzania instancjami sprawdza si najlepiej w przypadku wielu usug WCF. Przewaga
usug aktywowanych przez wywoania polega na wikszej skalowalnoci, a przynajmniej na
staej skalowalnoci. Podczas projektowania usug staram si trzyma pewnej reguy skalowal-
noci, któr nazwaem 10X. Zgodnie z t regu kad usug naley tak zaprojektowa, aby
obsugiwaa obcienie wiksze o co najmniej rzd wielkoci od pocztkowo sformuowanych
wymaga. W adnej dziedzinie inynierii nie projektuje si rozwiza czy systemów z myl

Poleć książkę

Kup książkę

Usugi sesyjne

_ 185

o radzeniu sobie z minimalnym zakadanym obcieniem. Nie chcielibymy przecie wcho-
dzi do budynku, którego belki stropowe mog podtrzyma tylko minimalne obcienie, ani
korzysta z windy, której liny mog utrzyma tylko tylu pasaerów, dla ilu ta winda uzyskaa
atest. Dokadnie tak samo jest w wiecie systemów informatycznych — po co projektowa
system z myl o biecym obcieniu, skoro kady dodatkowy pracownik przyjmowany do
firmy w celu poprawy jej wyników biznesowych bdzie powodowa dodatkowe obcienie
tego systemu? Systemy informatyczne naley projektowa raczej na lata, tak aby radziy sobie
zarówno z biecym obcieniem, jak i duo wikszym obcieniem w przyszoci. Kady, kto
stosuje regu 10X, byskawicznie dochodzi do punktu, w którym skalowalno usug aktywo-
wanych przez wywoania jest bezcenna.

Usugi sesyjne

rodowisko WCF moe utrzymywa sesj logiczn czc klienta z okrelon instancj usugi.
Klient, który tworzy nowego porednika dla usugi skonfigurowanej jako tzw. usuga sesyjna
(ang. sessionful service), otrzymuje now, dedykowan instancj tej usugi (niezalen od jej pozo-
staych instancji). Tak utworzona instancja zwykle pozostaje aktywna do momentu, w którym
klient nie bdzie jej potrzebowa. Ten tryb aktywacji (nazywany take trybem sesji prywat-
nej

— ang. private-session mode) pod wieloma wzgldami przypomina klasyczny model

klient-serwer: kada sesja prywatna jest unikatowym powizaniem porednika i zbioru kana-
ów czcych strony klienta i serwera z okrelon instancj usugi, a konkretnie z jej kontek-
stem. Tryb tworzenia instancji dla sesji prywatnych wymaga stosowania sesji transportowej
(to zagadnienie zostanie omówione w dalszej czci tego podrozdziau).

Poniewa instancja usugi pozostaje w pamici przez cay czas istnienia sesji, moe przechowy-
wa swój stan w pamici, zatem opisywany model programistyczny bardzo przypomina kla-
syczn architektur klient-serwer. Oznacza to, e usugi sesyjne s naraone na te same problemy
zwizane ze skalowalnoci i przetwarzaniem transakcyjnym co klasyczny model klient-serwer.
Z powodu kosztów utrzymywania dedykowanych instancji usuga skonfigurowana z myl
o obsudze sesji prywatnych zwykle nie moe obsugiwa wicej ni kilkadziesit (w niektórych
przypadkach maksymalnie sto lub dwiecie) jednoczenie dziaajcych klientów.

Sesja klienta jest punktem kocowym konkretnej sesji utworzonym dla okrelonego
porednika. Jeli wic klient utworzy innego porednika dla tego samego lub innego
punktu kocowego, drugi porednik zostanie powizany z now instancj usugi i now
sesj.

Konfiguracja sesji prywatnych

Istniej trzy elementy wspomagajce obsug sesji: zachowanie, powizanie i kontrakt. Zacho-
wanie jest wymagane do utrzymywania przez rodowisko WCF kontekstu instancji usugi przez
cay czas trwania sesji oraz do kierowania do tego kontekstu komunikatów przysyanych przez
klienta. Konfiguracja zachowania lokalnego wymaga przypisania wartoci

InstanceContextMode.

PerSession

do waciwoci

InstanceContextMode

atrybutu

ServiceBehavior

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
class MyService : IMyContract
{...}

Poleć książkę

Kup książkę

186

Rozdzia 4. Zarzdzanie instancjami

Poniewa

InstanceContextMode.PerSession

jest domyln wartoci waciwoci

InstanceContext

Mode

, ponisze definicje s równowane:

class MyService : IMyContract
{...}

[ServiceBehavior]
class MyService : IMyContract
{...}

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
class MyService : IMyContract
{...}

Sesja zwykle koczy si w momencie, w którym klient zamyka swojego porednika — pored-
nik powiadamia wówczas usug o zakoczeniu biecej sesji. Jeli usuga obsuguje interfejs

IDisposable

, metoda

Dispose()

zostanie wywoana asynchronicznie wzgldem dziaania klienta.

W takim przypadku metoda

Disposed()

zostanie wykonana przez wtek roboczy pozbawiony

kontekstu operacji.

Aby prawidowo skojarzy wszystkie komunikaty od okrelonego klienta z konkretn instan-
cj usugi, rodowisko WCF musi mie moliwo identyfikacji tego klienta. Jak wyjaniono
w rozdziale 1., wanie do tego suy sesja transportowa. Jeli usuga ma by projektowana
z myl o dziaaniu w roli usugi sesyjnej, musi istnie sposób wyraania tego zaoenia na
poziomie kontraktu. Odpowiedni element kontraktu powinien wykracza poza ograniczenia
samej usugi, poniewa take rodowisko wykonawcze WCF po stronie klienta musi wiedzie
o koniecznoci stosowania sesji. W tym celu atrybut

ServiceContract

udostpnia waciwo

SessionMode

typu wyliczeniowego

SessionMode

public enum SessionMode
{
Allowed,
Required,
NotAllowed
}
[AttributeUsage(AttributeTargets.Interface|AttributeTargets.Class,
Inherited=false)]
public sealed class ServiceContractAttribute : Attribute
{
public SessionMode SessionMode
{get;set;}

// Pozostae skadowe…

}

Domyln wartoci wyliczenia

SessionMode

jest

SessionMode.Allowed

. Skonfigurowana warto

typu

SessionMode

jest doczana do metadanych usugi i prawidowo uwzgldniana w momencie

importowania metadanych kontraktu przez klienta. Warto typu wyliczeniowego

SessionMode

nie ma nic wspólnego z sesj usugi — bardziej adekwatn nazw tego typu byaby

Transport

SessionMode

, poniewa dotyczy sesji transportowej, nie sesji logicznej utrzymywanej pomidzy

klientem a instancj usugi.

Warto SessionMode.Allowed

SessionMode.Allowed

jest domyln wartoci waciwoci

SessionMode

, zatem obie ponisze defi-

nicje s sobie równowane:

Poleć książkę

Kup książkę

Usugi sesyjne

_ 187

[ServiceContract]
interface IMyContract
{...}

[ServiceContract(SessionMode = SessionMode.Allowed)]
interface IMyContract
{...}

Moliwo skonfigurowania kontraktu w punkcie kocowym z wartoci

SessionMode.Allowed

jest obsugiwana przez wszystkie powizania. Przypisanie tej wartoci do waciwoci

SessionMode

oznacza, e sesje transportowe s dopuszczalne, ale nie s wymagane. Ostateczny ksztat zacho-
wania jest pochodn konfiguracji usugi i stosowanego powizania. Jeli usug skonfigurowano
z myl o aktywacji przez wywoania, zachowuje si wanie w ten sposób (patrz przykad
z listingu 4.2). Jeli usug skonfigurowano z myl o aktywacji na czas trwania sesji, bdzie
zachowywaa si jak usuga sesyjna, pod warunkiem e uyte powizanie utrzymuje sesj
transportow. Na przykad powizanie

BasicHttpBinding

nigdy nie moe dysponowa sesj na

poziomie transportowym z racji bezpoczeniowego charakteru protokou HTTP. Utrzymywanie
sesji na poziomie transportowym nie jest moliwe take w przypadku powizania

WSHttpBinding

bez mechanizmu zabezpieczania komunikatów. W obu przypadkach mimo skonfigurowania
usugi z wartoci

InstanceContextMode.PerSession

i kontraktu z wartoci

SessionMode.Allowed

usuga bdzie zachowywaa si tak jak usugi aktywowane przez wywoania.

Jeli jednak zostanie uyte powizanie

WSHttpBinding

z mechanizmem zabezpieczenia komuni-

katów (czyli w domylnej konfiguracji) lub z niezawodnym protokoem przesyania komunika-
tów albo powizanie

NetTcpBinding

lub

NetNamedPipeBinding

, usuga bdzie zachowywaa si jak

usuga sesyjna. Jeli na przykad uyjemy powizania

NetTcpBinding

, tak skonfigurowana usuga

bdzie zachowywaa si jak usuga sesyjna:

[ServiceContract]
interface IMyContract
{...}

class MyService : IMyContract
{...}

atwo zauway, e w powyszym fragmencie wykorzystano wartoci domylne zarówno
waciwoci

SessionMode

, jak i waciwoci

InstanceContextMode

Warto SessionMode.Required

Warto

SessionMode.Required

wymusza stosowanie sesji transportowej, ale nie wymusza uy-

wania sesji na poziomie aplikacji. Oznacza to, e nie jest moliwe skonfigurowanie kontraktu
z wartoci

SessionMode.Required

dla punktu kocowego, którego powizanie nie utrzymuje sesji

transportowej — to ograniczenie jest sprawdzane na etapie adowania usugi. Okazuje si jed-
nak, e mona tak skonfigurowa t usug, aby bya aktywowana przez wywoania, czyli aby
jej instancje byy tworzone i niszczone osobno dla kadego wywoania ze strony klienta. Tylko
skonfigurowanie usugi jako usugi sesyjnej spowoduje, e instancja usugi bdzie istniaa przez
cay czas trwania sesji klienta:

[ServiceContract(SessionMode = SessionMode.Required)]
interface IMyContract
{...}

class MyService : IMyContract
{...}

Poleć książkę

Kup książkę

188

Rozdzia 4. Zarzdzanie instancjami

Podczas projektowania kontraktu sesyjnego zaleca si jawnie uy wartoci

SessionMode.

Required

, zamiast liczy na zastosowanie domylnej wartoci

SessionMode.Allowed

. W pozo-

staych przykadach usug sesyjnych prezentowanych w tej ksice warto

SessionMode.

Required

bdzie jawnie stosowana w zapisach konfiguracyjnych.

Na listingu 4.4 pokazano kod tej samej usugi i tego samego klienta co na wczeniejszym lis-
tingu 4.2 — z t rónic, e tym razem kontrakt i usug skonfigurowano w sposób wymuszajcy
stosowanie sesji prywatnej. Jak wida w danych wynikowych, klient dysponuje wasn, dedy-
kowan instancj.

Listing 4.4. Usuga sesyjna i jej klient

///////////////////////// Kod usugi /////////////////////
[ServiceContract(SessionMode = SessionMode.Required)]
interface IMyContract
{
[OperationContract]
void MyMethod();
}
class MyService : IMyContract,IDisposable
{
int m_Counter = 0;

proxy.MyMethod();
proxy.MyMethod();

proxy.Close();

// Dane wynikowe
MyService.MyService()
Licznik = 1
Licznik = 2
MyService.Dispose()

Warto SessionMode.NotAllowed

Warto

SessionMode.NotAllowed

uniemoliwia stosowanie sesji transportowej, wykluczajc —

tym samym — moliwo korzystania z sesji na poziomie aplikacji. Uycie tej wartoci powo-
duje, e niezalenie od swojej konfiguracji usuga zachowuje si jak usuga aktywowana przez
wywoania.

Poleć książkę

Kup książkę

Usugi sesyjne

_ 189

Poniewa zarówno protokó TCP, jak i protokó IPC utrzymuje sesj na poziomie transporto-
wym, nie mona skonfigurowa punktu kocowego usugi uywajcego powizania

NetTcp

Binding

lub

NetNamedPipeBinding

, aby udostpnia kontrakt oznaczony wartoci

SessionMode.Not

Allowed

(odpowiednie ograniczenie jest sprawdzane na etapie adowania usugi). Okazuje si

jednak, e stosowanie powizania

WSHttpBinding

cznie z emulowan sesj transportow jest

dopuszczalne. Aby poprawi czytelno pisanego kodu, zachcam do dodatkowego konfiguro-
wania usugi jako aktywowanej przez wywoania zawsze wtedy, gdy jest stosowana warto

SessionMode.NotAllowed

[ServiceContract(SessionMode = SessionMode.NotAllowed)]
interface IMyContract
{...}

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
class MyService : IMyContract
{...}

Poniewa powizanie

BasicHttpBinding

nie moe dysponowa sesj na poziomie transportowym,

punkty kocowe uywajce tego powizania zawsze zachowuj si tak, jakby ich kontrakty skon-
figurowano z wartoci

SessionMode.NotAllowed

. Sam traktuj warto

SessionMode.NotAllowed

jako ustawienie przede wszystkim poprawiajce kompletno dostpnych rozwiza i z reguy
nie uywam jej w swoim kodzie.

Powizania, kontrakty i zachowanie usugi

W tabeli 4.1 podsumowano tryby aktywowania instancji usugi jako pochodne stosowanego
powizania, obsugi sesji opisanej w kontrakcie oraz trybu obsugi kontekstu instancji skonfi-
gurowanego w zachowaniu usugi. Tabela nie zawiera nieprawidowych konfiguracji, na przy-
kad poczenia wartoci

SessionMode.Required

z powizaniem

BasicHttpBinding

Tabela 4.1. Tryb aktywowania instancji jako pochodna powizania, konfiguracji kontraktu i zachowania usugi

Powizanie

Tryb sesji

Tryb kontekstu

Tryb instancji

Podstawowe

Allowed/NotAllowed

PerCall/PerSession

PerCall

TCP, IPC

Allowed/Required

PerCall

TCP, IPC

Allowed/Required

PerSession

WS (bez zabezpiecze komunikatów i niezawodnoci)

NotAllowed/Allowed

PerCall/PerSession

PerCall

WS (z zabezpieczeniami komunikatów lub niezawodnoci)

Allowed/Required

PerSession

WS (z zabezpieczeniami komunikatów lub niezawodnoci)

NotAllowed

PerCall/PerSession

PerCall

Spójna konfiguracja

Jeli jeden kontrakt implementowany przez usug jest sesyjny, wszystkie pozostae kontrakty
take powinny by sesyjne. Naley unika mieszania kontraktów aktywowanych wywoaniami
z kontraktami sesyjnymi dla tego samego typu usugi sesyjnej (mimo e rodowisko WCF
dopuszcza tak moliwo):

[ServiceContract(SessionMode = SessionMode.Required)]
interface IMyContract
{...}

[ServiceContract(SessionMode = SessionMode.NotAllowed)]

Poleć książkę

Kup książkę

190

Rozdzia 4. Zarzdzanie instancjami

interface IMyOtherContract
{...}

// Tego naley unika
class MyService : IMyContract,IMyOtherContract
{...}

Powód takiego rozwizania jest do oczywisty — usugi aktywowane przez wywoania musz
bezporednio zarzdza swoim stanem, za usugi sesyjne s zwolnione z tego obowizku. Mimo
e przytoczona para kontraktów bdzie dostpna w dwóch rónych punktach kocowych i moe
by niezalenie wykorzystywana przez dwie róne aplikacje klienckie, czne stosowanie dwóch
trybów wymaga stosowania nieporcznych zabiegów implementacyjnych w klasie usugi.

Sesje i niezawodno

Sesja czca klienta z instancj usugi moe by niezawodna tylko na tyle, na ile jest niezawodna
stosowana sesja transportowa. Oznacza to, e wszystkie punkty kocowe usugi implementu-
jcej kontrakt sesyjny powinny uywa powiza umoliwiajcych stosowanie niezawodnych
sesji transportowych. Programista powinien si upewni, e uywane powizania obsuguj nie-
zawodno i e ta niezawodno jest wprost zadeklarowana zarówno po stronie klienta, jak i po
stronie uytkownika (programowo lub administracyjnie — patrz listing 4.5).

Listing 4.5. Wczanie niezawodnoci dla usug sesyjnych

<!—Konfiguracja hosta:—>
<system.serviceModel>
<services>
<service name = "MyPerSessionService">
<endpoint
address = "net.tcp://localhost:8000/MyPerSessionService"
binding = "netTcpBinding"
bindingConfiguration = "TCPSession"
contract = "IMyContract"
/>
</service>
</services>
<bindings>
<netTcpBinding>
<binding name = "TCPSession">
<reliableSession enabled = "true"/>
</binding>
</netTcpBinding>
</bindings>
</system.serviceModel>

<!—Konfiguracja klienta:—>
<system.serviceModel>
<client>
<endpoint
address = "net.tcp://localhost:8000/MyPerSessionService/"
binding = "netTcpBinding"
bindingConfiguration = "TCPSession"
contract = "IMyContract"
/>
</client>
<bindings>
<netTcpBinding>

Poleć książkę

Kup książkę

Usugi sesyjne

_ 191

Jedynym wyjtkiem od tej reguy jest powizanie IPC. Powizanie IPC nie potrzebuje proto-
kou niezawodnego przesyania komunikatów (wszystkie wywoania i tak s wykonywane na
tym samym komputerze) i samo w sobie jest traktowane jako niezawodny mechanizm trans-
portu danych.

Podobnie jak niezawodna sesja transportowa, take dostarczanie komunikatów w oryginalnej
kolejnoci jest opcjonalne, a rodowisko WCF prawidowo utrzymuje sesj nawet w przypadku
wyczenia porzdkowania komunikatów. Obsuga sesji aplikacji powoduje jednak, e klient
usugi sesyjnej z reguy oczekuje zgodnoci kolejnoci dostarczania komunikatów z kolejnoci
ich wysyania. Dostarczanie komunikatów w oryginalnej kolejnoci na szczcie jest domylnie
wczone, jeli tylko wczono niezawodne sesje transportowe, zatem nie s potrzebne adne
dodatkowe ustawienia.

Identyfikator sesji

Kada sesja ma unikatowy identyfikator dostpny zarówno dla klienta, jak i dla usugi.
Identyfikator sesji to w duej czci identyfikator GUID, którego mona z powodzeniem uy-
wa podczas rejestrowania zdarze i diagnozowania systemu. Usuga moe uzyska dostp do
identyfikatora sesji za porednictwem tzw. kontekstu wywoania operacji (ang. operation call
context), czyli zbioru waciwoci (w tym identyfikatora sesji) uywanych na potrzeby wywo-
a zwrotnych, tworzenia nagówków komunikatów, zarzdzania transakcjami, bezpiecze-
stwa, dostpu do hosta oraz dostpu do obiektu reprezentujcego sam kontekst wykonywania.
Kada operacja wykonywana przez usug ma swój kontekst wywoania dostpny za pored-
nictwem klasy

OperationContext

. Usuga moe uzyska referencj do kontekstu operacji waci-

wego biecej metodzie za porednictwem metody statycznej

Current

klasy

OperationContext

public sealed class OperationContext : ...
{
public static OperationContext Current
{get;set;}
public string SessionId
{get;}
}

Aby uzyska dostp do identyfikatora sesji, usuga musi odczyta warto waciwoci

SessionId

, która zwraca (w formie acucha) identyfikator niemal identyczny jak identyfikator

GUID. W przypadku zawodnego powizania TCP po identyfikatorze GUID nastpuje zwy-
ky numer sesji z danym hostem:

string sessionID = OperationContext.Current.SessionId;
Trace.WriteLine(sessionID);
// Zapisuje identyfikator:
// uuid:8a0480da-7ac0-423e-9f3e-b2131bcbad8d;id=1

Próba uzyskania dostpu do waciwoci

SessionId

przez usug aktywowan przez wywoania

bez sesji transportowej spowoduje zwrócenie warto

null

, poniewa w takim przypadku nie

istnieje ani sesja, ani — co oczywiste — jej identyfikator.

Poleć książkę

Kup książkę

192

Rozdzia 4. Zarzdzanie instancjami

Klient moe uzyska dostp do identyfikatora sesji za pomoc porednika. Jak wspomniano
w rozdziale 1., klas bazow dla porednika jest

ClientBase<T>

. Klasa

ClientBase<T>

definiuje

waciwo dostpn tylko do odczytu

InnerChannel

typu

IClientChannel

. Interfejs

IClientChannel

dziedziczy po interfejsie

IContextChannel

, który z kolei zawiera waciwo

SessionId

zwracajc

acuch z identyfikatorem sesji:

public interface IContextChannel : ...
{
string SessionId
{get;}

// Pozostae skadowe…

}
public interface IClientChannel : IContextChannel,...
{...}
public abstract class ClientBase<T> : ...
{
public IClientChannel InnerChannel
{get;}

// Pozostae skadowe…

}

Jeli stosujemy definicje z listingu 4.4, klient moe uzyska identyfikator sesji w nastpujcy
sposób:

MyContractClient proxy = new MyContractClient();
proxy.MyMethod();

string sessionID = proxy.InnerChannel.SessionId;
Trace.WriteLine(sessionID);

Okazuje si jednak, e stopie zgodnoci identyfikatora sesji po stronie klienta z identyfikatorem
zwracanym po stronie usugi (nawet wtedy, gdy klient ma dostp do waciwoci

SessionId

) jest

pochodn stosowanego powizania i jego konfiguracji. Za dopasowywanie identyfikatorów
sesji po stronie klienta i po stronie usugi odpowiada sesja na poziomie transportowym. Jeli
jest stosowane powizanie TCP i jeli jest wczona niezawodna sesja (która w takim przy-
padku powinna by wczona), klient moe uzyska prawidowy identyfikator sesji dopiero
po wysaniu do usugi pierwszego wywoania metody i — tym samym — ustanowieniu nowej
sesji lub po bezporednim otwarciu porednika. W takim przypadku identyfikator sesji uzy-
skany przez klienta odpowiada identyfikatorowi stosowanemu po stronie usugi. (Jeli klient
uzyskuje dostp do identyfikatora sesji przed pierwszym wywoaniem, waciwo

SessionId

ma warto

null

). Jeli jest stosowane powizanie TCP, ale niezawodne sesje s wyczone,

klient moe uzyska dostp do identyfikatora sesji przed pierwszym wywoaniem, jednak otrzy-
many identyfikator bdzie inny od tego dostpnego po stronie usugi. W przypadku powiza-
nia WS (przy wczonym mechanizmie niezawodnego przesyania komunikatów) identyfikator
sesji bdzie mia warto

null

do czasu zakoczenia pierwszego wywoania (lub otwarcia pored-

nika przez klienta). Po tym wywoaniu klient i usuga zawsze bd miay dostp do tego samego
identyfikatora sesji. W razie braku niezawodnego przesyania komunikatów przed uzyskaniem
dostpu do identyfikatora sesji klient musi uy porednika (lub tylko go otworzy); w prze-
ciwnym razie istnieje ryzyko wystpienia wyjtku

InvalidOperationException

. Po otwarciu pored-

nika klient i usuga maj dostp do tego samego, skorelowanego identyfikatora sesji. W przy-
padku powizania IPC klient moe uzyska dostp do waciwoci

SessionId

przed pierwszym

wywoaniem, jednak otrzymany w ten sposób identyfikator sesji bdzie inny od tego dostp-
nego po stronie usugi. Podczas stosowania tego powizania najlepszym rozwizaniem jest ca-
kowite ignorowanie identyfikatora sesji.

Poleć książkę

Kup książkę

Usuga singletonowa

_ 193

Koczenie sesji

Sesja zwykle koczy si w momencie, w którym klient zamyka swojego porednika. Jeli jednak
klient sam nie zamyka porednika, jeli dziaanie klienta koczy si w jaki nieoczekiwany
sposób lub jeli wystpi jaki problem komunikacyjny, sesja zostanie zakoczona po okrelo-
nym czasie nieaktywnoci sesji transportowej.

Usuga singletonowa

(ang. singleton service) to w istocie usuga wspódzielona. Skonfiguro-

wanie usugi jako singletonu powoduje, e wszystkie aplikacje klienckie niezalenie od siebie
cz si z jednym, dobrze znanym kontekstem instancji i porednio z jedn instancj usugi
(niezalenie od uywanego punktu kocowego usugi). Singleton jest tworzony tylko raz (pod-
czas tworzenia hosta) i nigdy nie jest niszczony. Zwolnienie singletonu nastpuje dopiero
w momencie wyczenia hosta.

Singleton udostpniany na serwerze IIS lub WAS jest tworzony z chwil uruchamiania
procesu hosta, czyli w odpowiedzi na pierwsze danie dotyczce dowolnej usugi
w tym procesie. Okazuje si jednak, e w przypadku stosowania mechanizmu auto-
matycznego uruchamiania pakietu Windows Server AppFabric singleton jest tworzony
zaraz po uruchomieniu komputera. Zachowanie semantyki singletonu wymaga uycia
albo mechanizmu samohostingu (ang. self-hosting), albo pakietu Windows Server
AppFabric z funkcj automatycznego uruchamiania.

Stosowanie usugi singletonowej nie wymaga od klientów utrzymywania sesji logicznej z instan-
cj tej usugi ani uywania powiza obsugujcych sesje transportowe. Jeli kontrakt pobrany
przez klienta obejmuje sesj, do wywoania usugi singletonowej zostanie przypisany ten sam
identyfikator sesji, którym dysponuje klient (jeli stosowane powizanie dopuszcza tak mo-
liwo), ale zamknicie porednika tego klienta spowoduje zakoczenie tylko sesji transporto-
wej — kontekst singletonu ani sama instancja usugi nie zostan zamknite. Jeli usuga single-
tonowa obsuguje kontrakty bez sesji, take te kontrakty nie bd aktywowane przez wywoania,
tylko trwale powizane z t sam instancj. Usuga singletonowa z natury rzeczy ma cha-
rakter wspódzielony, a kady klient powinien utworzy wasnego porednika lub wasnych
poredników w dostpie do jedynej instancji tej usugi.

Konfiguracja usugi singletonowej wymaga ustawienia wartoci

InstanceContextMode.Single

waciwoci

InstanceContextMode

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
class MySingleton : ...
{...}

Listing 4.6 demonstruje usug singletonow z dwoma kontraktami, z których jeden wymaga
sesji, drugi — nie. Przykad wywoania ze strony klienta pokazuje, e dwa wywoania doty-
czce dwóch rónych punktów kocowych s kierowane do tej samej instancji, a zamknicie
poredników nie powoduje zakoczenia dziaania instancji usugi singletonowej.

Listing 4.6. Usuga singletonowa i jej klient

///////////////////////// Kod usugi /////////////////////
[ServiceContract(SessionMode = SessionMode.Required)]
interface IMyContract

Poleć książkę

Kup książkę

194

Rozdzia 4. Zarzdzanie instancjami

{
[OperationContract]
void MyMethod();
}
[ServiceContract(SessionMode = SessionMode.NotAllowed)]
interface IMyOtherContract
{
[OperationContract]
void MyOtherMethod();
}
[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single)]
class MySingleton : IMyContract,IMyOtherContract,IDisposable
{
int m_Counter = 0;

public MySingleton()
{
Trace.WriteLine("MySingleton.MySingleton()");
}
public void MyMethod()
{
m_Counter++;
Trace.WriteLine("Licznik = " + m_Counter);
}
public void MyOtherMethod()
{
m_Counter++;
Trace.WriteLine("Licznik = " + m_Counter);
}
public void Dispose()
{
Trace.WriteLine("Singleton.Dispose()");
}
}
///////////////////////// Kod klienta /////////////////////
MyContractClient proxy1 = new MyContractClient();
proxy1.MyMethod();
proxy1.Close();

MyOtherContractClient proxy2 = new MyOtherContractClient();
proxy2.MyOtherMethod();
proxy2.Close();

// Dane wynikowe
MySingleton.MySingleton()
Licznik = 1
Licznik = 2

Inicjalizacja usugi singletonowej

W pewnych przypadkach tworzenie i inicjalizacja singletonu za pomoc konstruktora domyl-
nego nie jest najlepszym rozwizaniem. Na przykad inicjalizacja stanu moe wymaga wyko-
nania jakich niestandardowych kroków lub specjalistycznej wiedzy, która albo nie powinna
obcia klientów, albo w ogóle nie jest dla nich dostpna. Niezalenie od powodów progra-
mista moe zdecydowa o utworzeniu singletonu przy uyciu mechanizmu spoza hosta usug
rodowiska WCF. Z myl o podobnych scenariuszach rodowisko WCF umoliwia bezpo-
rednie utworzenie instancji usugi singletonowej za pomoc standardowego mechanizmu

Poleć książkę

Kup książkę

Usuga singletonowa

_ 195

tworzenia instancji klas w rodowisku CLR. Tak utworzon instancj mona nastpnie zaini-
cjalizowa, po czym otworzy host z t instancj w roli usugi singletonowej. Klasa

ServiceHost

oferuje odpowiedni konstruktor, który otrzymuje na wejciu parametr typu

object

public class ServiceHost : ServiceHostBase,...
{
public ServiceHost(object singletonInstance,params Uri[] baseAddresses);
public object SingletonInstance
{get;}

// Pozostae skadowe…

}

Warto pamita, e przekazany parametr typu

object

musi by skonfigurowany jako singleton.

Przeanalizujmy na przykad kod z listingu 4.7. Klasa

MySingleton

jest najpierw inicjalizowana,

po czym umieszczana na hocie w formie usugi singletonowej.

Listing 4.7. Inicjalizacja usugi singletonowej i jej umieszczanie na hocie

// Kod usugi
[ServiceContract]
interface IMyContract
{
[OperationContract]
void MyMethod();
}
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
class MySingleton : IMyContract
{
public int Counter
{get;set;}

public void MyMethod()
{
Counter++;
Trace.WriteLine("Licznik = " + Counter);
}
}
// Kod hosta
MySingleton singleton = new MySingleton();
singleton.Counter = 287;

ServiceHost host = new ServiceHost(singleton);
host.Open();

// Kod klienta
MyContractClient proxy = new MyContractClient();
proxy.MyMethod();
proxy.Close();

// Dane wynikowe:
Licznik = 288

Jeli programista decyduje si na inicjalizacj singletonu i umieszczenie go na hocie w ten
sposób, moe by zainteresowany take bezporednim dostpem do tego singletonu z poziomu
hosta. rodowisko WCF umoliwia obiektom uczestniczcym w acuchu wywoa bezporedni
dostp do singletonu za pomoc waciwoci

SingletonInstance

klasy

ServiceHost

. Kady element

acucha wywoa czcego kolejne elementy, poczwszy od oryginalnego wywoania ope-
racji singletonu, ma dostp do hosta za porednictwem waciwoci

Host

(dostpnej tylko do

odczytu) kontekstu operacji:

Poleć książkę

Kup książkę

196

Rozdzia 4. Zarzdzanie instancjami

public sealed class OperationContext : ...
{
public ServiceHostBase Host
{get;}

// Pozostae skadowe…

}

Po uzyskaniu referencji do singletonu dalsze dziaania mona podejmowa bezporednio na
tym obiekcie:

ServiceHost host = OperationContext.Current.Host as ServiceHost;
Debug.Assert(host != null);
MySingleton singleton = host.SingletonInstance as MySingleton;
Debug.Assert(singleton != null);
singleton.Counter = 388;

Jeli host nie dysponuje adn instancj usugi singletonowej, waciwo

SingletonInstance

zwraca warto

null

Usprawnienie przy uyciu klasy ServiceHost<T>

Klas

ServiceHost<T>

, któr przedstawiono w rozdziale 1., mona uzupeni o kod zapewniajcy

inicjalizacj singletonu i dostp do jego instancji (z zachowaniem bezpieczestwa typów):

public class ServiceHost<T> : ServiceHost
{
public ServiceHost(T singleton,params Uri[] baseAddresses) :
base(singleton,baseAddresses)
{}
public virtual T Singleton
{
get
{
if(SingletonInstance == null)
{
return default(T);
}
return (T)SingletonInstance;
}
}

// Pozostae skadowe…

}

Parametr typu zapewnia powizanie gwarantujce bezpieczestwo typów dla obiektu prze-
kazanego na wejciu konstruktora:

MySingleton singleton = new MySingleton();
singleton.Counter = 287;

ServiceHost<MySingleton> host = new ServiceHost<MySingleton>(singleton);
host.Open();

i obiektu zwróconego przez waciwo

Singleton

ServiceHost<MySingleton> host = OperationContext.Current.Host
as ServiceHost<MySingleton>;

Debug.Assert(host != null);
host.Singleton.Counter = 388;

Poleć książkę

Kup książkę

Operacje demarkacyjne

_ 197

Take klas

InProcFactory<T>

(wprowadzon w rozdziale 1.) mona w podobny sposób

uzupeni o kod inicjalizujcy instancj singletonu.

Wybór singletonu

Usuga singletonowa jest zadeklarowanym wrogiem skalowalnoci. Powodem tej „wrogoci”
jest synchronizacja stanu usugi singletonowej, nie koszt utrzymania jej jedynej instancji. Stoso-
wanie singletonu wynika z potrzeby uycia pojedynczej instancji reprezentujcej pewien cenny
stan, który ma by wspódzielony przez wszystkie aplikacje klienckie. Problem w tym, e jeli
stan singletonu jest zmienny i jeli wiele klientów czy si z jedyn instancj tej usugi, wszyst-
kie aplikacje klienckie mog to robi jednoczenie, a generowane przez nie wywoania s obsu-
giwane przez wiele wtków roboczych. Oznacza to, e singleton musi synchronizowa dostp
do swojego stanu, aby unikn jego uszkodzenia. To z kolei powoduje, e w danym momencie
dostp do singletonu moe mie tylko jeden klient. Wspomniane ograniczenie moe znacznie
obniy przepustowo, wyduy czas odpowiedzi i zmniejszy dostpno singletonu. W tej
sytuacji ju w systemach redniej wielkoci singleton moe sta si po prostu bezuyteczny.
Jeli na przykad pojedyncza operacja wykonywana przez usug singletonow zajmuje jedn
dziesit sekundy, singleton moe obsuy zaledwie dziesi klientów w cigu sekundy.
W przypadku wikszej liczby klientów (na przykad dwudziestu czy stu) wydajno caego
systemu drastycznie spadnie.

Ogólnie usugi singletonowe naley stosowa tylko wtedy, gdy odwzorowuj naturalne single-
tony wystpujce w dziedzinie aplikacji. Naturalny singleton to zasób, który z natury rzeczy
wystpuje pojedynczo i jest niepowtarzalny. Przykadami naturalnych singletonów s globalne
dzienniki zdarze, w których wszystkie usugi rejestruj swoje dziaania, pojedyncze porty
komunikacyjne czy pojedyncze silniki mechaniczne. Stosowania singletonów naley unika,
jeli istnieje choby cie szansy na obsug wikszej liczby instancji danej usugi w przyszoci
(na przykad poprzez dodanie kolejnego silnika lub drugiego portu komunikacyjnego). Powód
jest jasny — skoro wszystkie aplikacje klienckie bd pocztkowo zaleay od poczenia z jedn
instancj i skoro z czasem bdzie dostpna druga instancja danej usugi, aplikacje bd potrze-
boway moliwoci nawizania poczenia z waciw instancj. Konieczno obsugi wikszej
liczby instancji ma zasadniczy wpyw na stosowany model programowania aplikacji. Z powodu
tych ogranicze radz unika singletonów w ogólnych przypadkach i poszukiwa sposobów
wspódzielenia raczej stanu singletonu, a nie jego instancji. Jak ju wspomniano, w pewnych
przypadkach stosowanie jest w peni uzasadnione.

Operacje demarkacyjne

W pewnych przypadkach kontrakty stanowe niejawnie zakadaj, e wywoania operacji bd
nastpoway w okrelonej kolejnoci. Niektóre operacje nie mog by wywoywane jako pierw-
sze, inne musz by wywoywane jako ostatnie. Przeanalizujmy na przykad kontrakt uywany
do zarzdzania zamówieniami klientów:

[ServiceContract(SessionMode = SessionMode.Required)]
interface IOrderManager
{
[OperationContract]

Poleć książkę

Kup książkę

198

Rozdzia 4. Zarzdzanie instancjami

void SetCustomerId(int customerId);

[OperationContract]
void AddItem(int itemId);

[OperationContract]
decimal GetTotal();

[OperationContract]
bool ProcessOrders();
}

Kontrakt przewiduje nastpujce ograniczenia: w pierwszej operacji w ramach sesji aplikacja
kliencka musi przekaza identyfikator nabywcy (w przeciwnym razie nie mona wykona
pozostaych operacji); w kolejnych operacjach mona doda do zamówienia produkty; usuga
oblicza czn warto zamówienia na kade danie klienta; ostateczne przetworzenie zamó-
wienia koczy sesj, zatem musi by wykonane jako ostatnie. W klasycznym frameworku .NET
wymagania tego typu czsto wymuszaj na programistach stosowanie maszyny stanów lub flag
stanów oraz weryfikacji biecego stanu przy okazji kadej operacji.

Okazuje si jednak, e w rodowisku WCF projektanci kontraktów maj moliwo wyznacza-
nia operacji, które mog rozpoczyna bd koczy sesje (lub nie mog tego robi). Odpowied-
nie ustawienia mona definiowa za pomoc waciwoci

IsInitiating

IsTerminating

atrybutu

OperationContract

[AttributeUsage(AttributeTargets.Method)]
public sealed class OperationContractAttribute : Attribute,...
{
public bool IsInitiating
{get;set;}
public bool IsTerminating
{get;set;}

// Pozostae skadowe…

}

Wymienione waciwoci mog by uywane do izolowania granic sesji; sam okrelam t tech-
nik mianem operacji demarkacyjnych (ang. demarcating operations). Jeli w czasie adowania
usugi (lub w czasie stosowania porednika po stronie klienta) te dwie waciwoci maj przy-
pisane wartoci inne ni domylne, rodowisko WCF sprawdza, czy operacje demarkacyjne
wchodz w skad kontraktu wymuszajcego stosowanie sesji (tj. czy waciwo

SessionMode

ma warto

SessionMode.Required

); jeli nie, rodowisko zgasza wyjtek

InvalidOperationException

Zarówno usugi sesyjne, jak i usugi singletonowe mog implementowa kontrakty uywajce
operacji demarkacyjnych do zarzdzania sesjami klientów.

Wartociami domylnymi waciwoci

IsInitiating

IsTerminating

s odpowiednio

true

false

Oznacza to, e nastpujce dwie definicje s sobie równowane:

[OperationContract]
void MyMethod();

[OperationContract(IsInitiating = true,IsTerminating = false)]
void MyMethod();

Jak wida, obie te waciwoci mona ustawi dla tej samej metody. Operacje domylnie nie
izoluj granic sesji — mog by wywoywane jako pierwsze, ostatnie lub pomidzy dowolnymi
innymi operacjami w ramach swojej sesji. Uycie wartoci innych ni domylne pozwala okre-
li, e dana metoda nie moe by wywoywana jako pierwsza, musi by wywoywana jako
ostatnia lub powinna spenia oba te warunki jednoczenie:

Poleć książkę

Kup książkę

Operacje demarkacyjne

_ 199

[ServiceContract(SessionMode = SessionMode.Required)]
interface IMyContract
{
[OperationContract]
void StartSession();

[OperationContract(IsInitiating = false)]
void CannotStart();

[OperationContract(IsTerminating = true)]
void EndSession();

[OperationContract(IsInitiating = false,IsTerminating = true)]
void CannotStartCanEndSession();
}

Wrómy teraz do przykadu kontraktu na potrzeby zarzdzania zamówieniami — operacji
demarkacyjnych mona uy do wymuszania pewnych ogranicze interakcji:

[ServiceContract(SessionMode = SessionMode.Required)]
interface IOrderManager
{
[OperationContract]
void SetCustomerId(int customerId);

[OperationContract(IsInitiating = false)]
void AddItem(int itemId);

[OperationContract(IsInitiating = false)]
decimal GetTotal();

[OperationContract(IsInitiating = false,IsTerminating = true)]
bool ProcessOrders();
}
// Kod klienta
OrderManagerClient proxy = new OrderManagerClient();

proxy.SetCustomerId(123);
proxy.AddItem(4);
proxy.AddItem(5);
proxy.AddItem(6);
proxy.ProcessOrders();

proxy.Close();

Jeli waciwo

IsInitiating

ma warto

true

(czyli swoj warto domyln), odpowiednia

operacja albo rozpocznie now sesj, jeli bdzie pierwsz metod wywoan przez klienta,
albo bdzie czci trwajcej sesji, jeli wczeniej wywoano inn operacj. Jeli waciwo

IsInitiating

ma warto

false

, klient nigdy nie moe wywoa danej metody jako pierwszej

operacji nowej sesji, zatem metoda ta moe by wywoana tylko w ramach trwajcej sesji.

Jeli waciwo

IsTerminating

ma warto

false

(czyli swoj warto domyln), sesja nie

koczy si po zwróceniu sterowania przez dan operacj. Jeli waciwo

IsTerminating

warto

true

, sesja koczy si wraz ze zwróceniem sterowania przez odpowiedni metod,

a rodowisko WCF asynchronicznie zwalnia instancj danej usugi. Klient nie bdzie móg prze-
kaza adnych dodatkowych wywoa do odpowiedniego porednika. Warto przy tym pami-
ta, e klient wci ma obowizek zamknicia tego porednika.

Poleć książkę

Kup książkę

200

Rozdzia 4. Zarzdzanie instancjami

Po wygenerowaniu porednika dla usugi korzystajcej z operacji demarkacyjnych
zaimportowana definicja kontraktu obejmuje ustawienia waciwoci. rodowisko WCF
wymusza izolowanie granic sesji osobno po stronie klienta i osobno po stronie usugi,
zatem w praktyce oba zadania mog by realizowane niezalenie od siebie.

Dezaktywacja instancji

Na poziomie koncepcyjnym technika zarzdzania instancjami usugi sesyjnej (przynajmniej
w dotychczas opisanej formie) czy klienta (lub wiele aplikacji klienckich) z instancj usugi.
Okazuje si jednak, e dziaanie tego mechanizmu jest bardziej zoone. W rozdziale 1. wspo-
mniano, e kada instancja usugi naley do pewnego kontekstu (patrz rysunek 4.2).

Rysunek 4.2. Konteksty i instancje

W praktyce zadaniem sesji jest kojarzenie komunikatów wysyanych przez aplikacje klienckie
nie tyle z instancjami, co z hostami zawierajcymi t instancj. W momencie rozpoczcia sesji
host tworzy nowy kontekst. Z chwil zakoczenia sesji koczy si take ten kontekst. Czas
ycia kontekstu jest wic taki sam jak czas ycia nalecej do niego instancji. Okazuje si jednak,
e aby poprawi optymalizacj i rozszerzalno, technologia WCF umoliwia projektantom
usug rozdzielanie tych dwóch cykli ycia i dezaktywacj instancji niezalenie od jej kontekstu.
W rzeczywistoci technologia WCF dopuszcza nawet istnienie kontekstu bez jakiejkolwiek
powizanej instancji usugi (patrz rysunek 4.2). Opisan technik zarzdzania instancjami okre-
lam mianem dezaktywacji kontekstu (ang. context deactivation). Typowym sposobem stero-
wania procesem dezaktywacji kontekstu jest korzystanie z porednictwa waciwoci

Release

InstanceMode

atrybutu

OperationBehavior

public enum ReleaseInstanceMode
{
None,
BeforeCall,
AfterCall,
BeforeAndAfterCall
}
[AttributeUsage(AttributeTargets.Method)]
public sealed class OperationBehaviorAttribute : Attribute,...
{
public ReleaseInstanceMode ReleaseInstanceMode
{get;set;}

// Pozostae skadowe…

}

Waciwo

ReleaseInstanceMode

jest egzemplarzem typu wyliczeniowego

ReleaseInstanceMode

Poszczególne wartoci typu

ReleaseInstanceMode

steruj czasem zwalniania instancji wzgldem

Poleć książkę

Kup książkę

Dezaktywacja instancji

_ 201

wywoania metody: przed, po, przed i po lub wcale. Jeli dana usuga obsuguje interfejs

IDispo

sable

, podczas zwalniania instancji tej usugi jest wywoywana metoda

Dispose()

, która

dysponuje kontekstem operacji.

Dezaktywacj instancji zwykle stosuje si tylko dla wybranych metod usugi lub dla wielu ró-
nych metod z odmiennymi ustawieniami waciwoci

ReleaseInstanceMode

[ServiceContract(SessionMode = SessionMode.Required)]
interface IMyContract
{
[OperationContract]
void MyMethod();

[OperationContract]
void MyOtherMethod();
}
class MyService : IMyContract,IDisposable
{
[OperationBehavior(ReleaseInstanceMode = ReleaseInstanceMode.AfterCall)]
public void MyMethod()
{...}
public void MyOtherMethod()
{...}
public void Dispose()
{...}
}

Opisane rozwizanie jest stosowane sporadycznie, poniewa jego spójne wykorzystywanie
wymagaoby tworzenia usug zblionych do tych aktywowanych przez wywoania — w takim
przypadku równie dobrze mona po prostu posuy si tym trybem aktywacji.

Jeli mechanizm dezaktywacji instancji wymaga okrelonego porzdku wywoa, warto spró-
bowa wymusi stosowanie tej kolejnoci przy uyciu operacji demarkacyjnych.

Konfiguracja z wartoci ReleaseInstanceMode.None

Wartoci domyln waciwoci

ReleaseInstanceMode

jest

ReleaseInstanceMode.None

, zatem ponisze

definicje s sobie równowane:

[OperationBehavior(ReleaseInstanceMode = ReleaseInstanceMode.None)]
public void MyMethod()
{...}

public void MyMethod()
{...}

Warto

ReleaseInstanceMode.None

oznacza, e wywoanie nie wpywa na czas ycia instancji

(patrz rysunek 4.3).

Konfiguracja z wartoci ReleaseInstanceMode.BeforeCall

Jeli skonfigurowano metod z wartoci

ReleaseInstanceMode.BeforeCall

i jeli istnieje jaka

instancja w ramach sesji, przed przekazaniem wywoania rodowisko dezaktywuje t instancj
i tworzy w jej miejsce now, która obsuguje to wywoanie (patrz rysunek 4.4).

rodowisko WCF dezaktywuje instancje i wywouje metod

Dispose()

przed zakoczeniem

wywoania w wtku obsugujcym wywoanie przychodzce (w tym czasie wykonywanie kodu

Poleć książkę

Kup książkę

202

Rozdzia 4. Zarzdzanie instancjami

Rysunek 4.3. Czas ycia instancji w przypadku metod skonfigurowanych z wartoci ReleaseInstanceMode.None

Rysunek 4.4. Czas ycia instancji w przypadku metod skonfigurowanych z wartoci
ReleaseInstanceMode.BeforeCall

klienta jest zablokowane). Takie rozwizanie gwarantuje, e dezaktywacja instancji rzeczywi-
cie zakoczy si przed rozpoczciem wywoania, nie równolegle do jego realizacji. Warto

ReleaseInstanceMode.BeforeCall

zaprojektowano z myl o optymalizacji takich metod jak

Create()

które uzyskuj cenne zasoby, ale te powinny kadorazowo zwalnia wczeniej zajte zasoby.
Zamiast uzyskiwa zasoby w momencie rozpoczcia sesji, usuga czeka na wywoanie metody

Create()

, która nie tylko uzyskuje nowe zasoby, ale te zwalnia te przydzielone wczeniej. Po

wywoaniu metody

Create()

usuga jest gotowa do obsugi pozostaych metod danej instancji,

które zwykle konfiguruje si przy uyciu wartoci

ReleaseInstanceMode.None

Konfiguracja z wartoci ReleaseInstanceMode.AfterCall

Jeli skonfigurowano metod z wartoci

ReleaseInstanceMode.AfterCall

, rodowisko WCF dez-

aktywuje instancj po wywoaniu tej metody (patrz rysunek 4.5).

Rysunek 4.5. Czas ycia instancji w przypadku metod skonfigurowanych z wartoci
ReleaseInstanceMode.AfterCall

Poleć książkę

Kup książkę

Dezaktywacja instancji

_ 203

T warto zaprojektowano z myl o optymalizacji takich metod jak

Cleanup()

, które zwalniaj

cenne zasoby zajmowane przez instancj, nie czekajc na zakoczenie odpowiedniej sesji. War-
to

ReleaseInstanceMode.AfterCall

zwykle stosuje si dla metod wywoywanych po metodach

skonfigurowanych z wartoci

ReleaseInstanceMode.None

Konfiguracja z wartoci
ReleaseInstanceMode.BeforeAndAfterCall

Jak nietrudno si domyli, skonfigurowanie metody z wartoci

ReleaseInstanceMode.BeforeAnd

AfterCall

umoliwia poczenie skutków uycia wartoci

ReleaseInstanceMode.BeforeCall

ReleaseInstanceMode.AfterCall

. Jeli przed wywoaniem tak skonfigurowanej metody kontekst

zawiera instancj usugi, bezporednio przed przekazaniem tego wywoania rodowisko WCF
dezaktywuje t instancj i tworzy now na potrzeby tego wywoania. Nowa instancja jest dez-
aktywowana zaraz po zakoczeniu wywoania (patrz rysunek 4.6).

Rysunek 4.6. Czas ycia instancji w przypadku metod skonfigurowanych z wartoci
ReleaseInstanceMode.BeforeAndAfterCall

Na pierwszy rzut oka metoda

ReleaseInstanceMode.BeforeAndAfterCall

moe sprawia wraenie

nadmiarowej, ale w rzeczywistoci stanowi cenne uzupenienie pozostaych wartoci. Warto

ReleaseInstanceMode.BeforeAndAfterCall

stosuje si dla metod wywoywanych po metodach ozna-

czonych wartoci

ReleaseInstanceMode.BeforeCall

lub

None

bd przed metodami oznaczonymi

wartoci

ReleaseInstanceMode.AfterCall

lub

None

. Wyobramy sobie sytuacj, w której usuga

sesyjna ma korzysta z zachowania stanowego (podobnie jak usuga aktywowana przez wywo-
ania) i jednoczenie zajmowa zasoby tylko w czasie, gdy s rzeczywicie potrzebne (aby
zoptymalizowa zarzdzanie zasobami i zapewni bezpieczestwo). Gdyby jedyn dostpn
opcj bya warto

ReleaseInstanceMode.BeforeCall

, zasoby byyby niepotrzebnie zajmowane

przez ten obiekt przez pewien czas po zakoczeniu wywoania. Podobna sytuacja miaaby
miejsce, gdyby jedyn dostpn opcj bya warto

ReleaseInstanceMode.AfterCall

— wówczas

zasoby byyby niepotrzebnie zajmowane przez pewien czas przed wywoaniem tak skonfigu-
rowanej metody.

Bezporednia dezaktywacja

Decyzji o tym, które metody maj dezaktywowa instancj usugi, nie trzeba podejmowa na
etapie projektowania systemu — równie dobrze mona j podj w czasie wykonywania, po
zwróceniu sterowania przez odpowiedni metod. Wystarczy wywoa metod

ReleaseService

Instance()

dla obiektu kontekstu instancji. Obiekt kontekstu instancji mona uzyska za

porednictwem waciwoci

InstanceContext

kontekstu operacji:

Poleć książkę

Kup książkę

204

Rozdzia 4. Zarzdzanie instancjami

public sealed class InstanceContext : ...
{
public void ReleaseServiceInstance();

// Pozostae skadowe…

}
public sealed class OperationContext : ...
{
public InstanceContext InstanceContext
{get;}

// Pozostae skadowe…

}

Listing 4.8 zawiera przykad uycia techniki bezporedniej (jawnej) dezaktywacji w implemen-
tacji niestandardowej techniki zarzdzania instancjami zalenie od wartoci licznika.

Listing 4.8. Przykad uycia metody ReleaseServiceInstance()

[ServiceContract(SessionMode = SessionMode.Required)]
interface IMyContract
{
[OperationContract]
void MyMethod();
}
class MyService : IMyContract,IDisposable
{
int m_Counter = 0;

public void MyMethod()
{
m_Counter++;
if(m_Counter > 4)
{
OperationContext.Current.InstanceContext.ReleaseServiceInstance();
}
}
public void Dispose()
{...}
}

Wywoanie metody

ReleaseServiceInstance()

daje podobny efekt do uycia wartoci

Release

InstanceMode.AfterCall

. Wywoanie tej metody wewntrz metody oznaczonej wartoci

Release

InstanceMode.BeforeCall

spowoduje dziaanie podobne do uycia samej wartoci

ReleaseInstance

Mode.BeforeAndAfterCall

Dezaktywacja usugi wpywa take na sposób dziaania singletonu, jednak czenie obu
rozwiza nie ma wikszego sensu — instancja usugi singletonowej z natury rzeczy nie
musi i nie powinna by dezaktywowana.

Stosowanie dezaktywacji instancji

Dezaktywacja instancji to jedna z technik optymalizacji, której — jak wszystkich technik opty-
malizacji — nie naley stosowa we wszystkich przypadkach. Dezaktywacja instancji wpro-
wadza dodatkow zoono do aplikacji i utrudnia konserwacj kodu programistom, którzy
nie s ekspertami w dziedzinie technologii WCF. Stosowanie tej techniki naley rozwaa tylko
wtedy, gdy inne sposoby nie wystarcz do osignicia zakadanej wydajnoci i skalowalnoci
oraz gdy uwana analiza i profilowanie kodu ostatecznie dowiody, e dezaktywacja instancji

Poleć książkę

Kup książkę

Usugi trwae

_ 205

rzeczywicie poprawi sytuacj. W razie problemów z niedostateczn skalowalnoci i przepu-
stowoci warto skorzysta raczej z prostoty trybu aktywowania usugi przez wywoania,
unikajc dezaktywacji instancji. Opisuj t technik przede wszystkim dlatego, e samo ro-
dowisko WCF czsto stosuje mechanizm dezaktywacji instancji; znajomo tej techniki jest
wic niezbdna do zrozumienia wielu innych aspektów tej technologii, w tym usug trwaych
i transakcji.

Usugi trwae

Warto przeanalizowa przypadek, w którym jaki proces biznesowy lub system przepywu
pracy (skadajcy si z wielu sekwencji wykonywania) trwa wiele dni lub nawet tygodni.

Uywam terminu przepyw pracy (ang. workflow) w kontekcie ogólnego, biznesowego
przepywu pracy, niekoniecznie przepywu obsugiwanego przez produkt Windows
Workflow czy powizanego z tym produktem.

Takie dugotrwae procesy mog wspópracowa z klientami (lub wrcz uytkownikami ko-
cowymi) czcymi si z aplikacj, wykonujcymi okrelone, skoczone zadania, zmieniajcymi
stan przepywu pracy i rozczajcymi si na nieznany okres przed nawizaniem kolejnego
poczenia (i dalszym wpywaniem na stan przepywu pracy). Aplikacje klienckie mog w pew-
nym momencie zdecydowa o zakoczeniu biecego przepywu pracy i rozpoczciu nowego.
Przepyw pracy moe zosta zakoczony take przez usug, która go obsuguje. Utrzymywanie
poredników i usug w pamici w oczekiwaniu na wywoania ze strony klientów nie miaoby
oczywicie wikszego sensu. Taki model z pewnoci nie przetrwaby próby czasu; poczenia
byyby zrywane choby z powodu upywajcych limitów czasowych, a ponowne uruchamianie
lub wylogowywanie komputerów po obu stronach poczenia z pewnoci nie byoby atwe.
Konieczno stosowania niezalenych cyklów ycia klientów i usug jest szczególnie wana
w przypadku dugotrwaych procesów biznesowych, poniewa bez tej niezalenoci nie sposób
umoliwi klientom nawizywanie poczenia, wykonywanie pewnych zada zwizanych
z przepywem pracy i rozczanie si. Po stronie hosta z czasem moe zaistnie potrzeba kiero-
wania wywoa do rónych komputerów.

W przypadku dugotrwaych usug waciwym rozwizaniem jest unikanie utrzymywania stanu
usugi w pamici. Kade wywoanie powinno by obsugiwane przez now instancj dyspo-
nujc wasnym stanem (przechowywanym w pamici). Na potrzeby kadej operacji usuga
powinna uzyskiwa swój stan z jakiej pamici trwaej (na przykad pliku lub bazy danych),
wykonywa dan jednostk pracy, po czym (na zakoczenie obsugi wywoania) zapisywa
stan w odpowiedniej pamici trwaej. Usugi dziaajce wedug tego modelu okrela si mianem
usug trwaych

. Poniewa uywana pami trwaa moe by wspódzielona przez wiele kompu-

terów, stosowanie usug trwaych dodatkowo stwarza moliwo rozdzielania wywoa pomi-
dzy róne komputery z myl o skalowalnoci, nadmiarowoci lub na potrzeby konserwacji.

Usugi trwae i tryby zarzdzania instancjami

Model zarzdzania stanem obowizujcy w usugach trwaych pod wieloma wzgldami przy-
pomina zaproponowane wczeniej rozwizania dla usug aktywowanych przez wywoania, które
take aktywnie zarzdzaj swoim stanem. Stosowanie usug aktywowanych przez wywoania ma

Poleć książkę

Kup książkę

206

Rozdzia 4. Zarzdzanie instancjami

jeszcze t zalet, e eliminuje konieczno utrzymywania instancji pomidzy wywoaniami (nie
ma takiej potrzeby, skoro stan jest odczytywany z pamici trwaej). Jedynym aspektem, który
odrónia usugi trwae od klasycznych usug aktywowanych przez wywoania, jest konieczno
stosowania trwaego repozytorium stanów.

O ile w teorii nic nie stoi na przeszkodzie, aby usugi trwae zaimplementowa na bazie usug
sesyjnych czy wrcz usug singletonowych, które przechowywayby swój stan w jakiej pamici,
praktyka pokazuje, e takie rozwizanie jest zupenie nieefektywne. W przypadku usugi sesyjnej
naleaoby utrzymywa przez dugi czas otwarty obiekt porednika po stronie klienta, zatem
nie byaby moliwa ciga wspópraca z klientami koczcymi i ponownie nawizujcymi po-
czenia. W przypadku usugi singletonowej, której czas ycia w zaoeniu jest nieskoczony
i która obsuguje aplikacje klienckie wielokrotnie nawizujce kolejne poczenia, stosowanie
pamici trwaej nie ma wikszego sensu. W tej sytuacji tryb aktywowania przez wywoania
wydaje si zdecydowanie najlepszym rozwizaniem. Warto pamita, e w przypadku usug
trwaych aktywowanych przez wywoania, gdzie zasadniczym celem jest obsuga dugotrwa-
ych przepywów pracy (nie zapewnianie skalowalnoci czy efektywne zarzdzanie zasobami),
obsuga interfejsu

IDisposable

jest opcjonalna. W przypadku usug trwaych take obecno

sesji transportowej jest opcjonalna, poniewa nie ma potrzeby utrzymywania sesji logicznych
pomidzy klientem a usug. Sesja transportowa bdzie penia funkcj elementu uywanego
kanau transportowego i jako taka nie bdzie decydowaa o czasie ycia instancji usugi.

Tworzenie i niszczenie instancji usugi

W momencie rozpoczcia dugoterminowego procesu przepywu pracy odpowiednia usuga
musi najpierw zapisa swój stan w pamici trwaej, tak aby kolejne operacje miay dostp do
stanu w tej pamici. Po zakoczeniu pracy usuga musi usun swój stan z pamici trwaej;
w przeciwnym razie pami byaby stopniowo zamiecana starymi, niepotrzebnymi stanami
instancji.

Identyfikatory instancji i pami trwaa

Poniewa nowa instancja usugi jest tworzona dla kadej operacji, instancja musi mie mo-
liwo odnalezienia i zaadowania stanu przechowywanego w pamici trwaej. Oznacza to, e
klient musi dostarczy instancji usugi jaki identyfikator stanu. Taki identyfikator okrela si
mianem identyfikatora instancji. Obsuga klientów sporadycznie nawizujcych poczenie
z usug oraz aplikacji klienckich czy nawet komputerów, które mog ulega zasadniczym
zmianom pomidzy wywoaniami (wszystko w czasie trwania jednego przepywu pracy),
wymaga zapisywania identyfikatora instancji w jakiej pamici trwaej po stronie klienta (na
przykad w pliku) i przekazywania go w kadym wywoaniu. Klient moe usun identyfika-
tor instancji dopiero po zakoczeniu odpowiedniego przepywu pracy. Typ danych uywany
do reprezentowania identyfikatora instancji powinien zapewnia moliwo szeregowania
(serializacji) i porównywania. Warunek szeregowalnoci jest o tyle wany, e usuga bdzie
musiaa zapisa identyfikator w pamici trwaej (wraz ze swoim stanem). Moliwo porówny-
wania identyfikatora jest niezbdna, jeli usuga ma odczytywa odpowiedni stan z pamici
trwaej. Wszystkie typy proste frameworku .NET (jak

int

string

czy

Guid

) speniaj wymagania

stawiane identyfikatorom instancji.

Pami trwaa zwykle ma posta sownika, który obejmuje pary zoone z identyfikatora i stanu
instancji. Usuga z reguy uywa pojedynczego identyfikatora w roli reprezentacji caego swo-

Poleć książkę

Kup książkę

Usugi trwae

_ 207

jego stanu, jednak istnieje moliwo stosowania bardziej zoonych relacji, w tym wielu kluczy
czy wrcz hierarchii kluczy. Dla uproszczenia w tym materiale bd omawiane tylko poje-
dyncze identyfikatory. Wiele usug dodatkowo uywa klas lub struktur pomocniczych cz-
cych wszystkie zmienne skadowe i zapisujcych dane zagregowane w tym typie w pamici
trwaej (oraz odczytujcych te dane z pamici trwaej). I wreszcie sam dostp do pamici trwa-
ej musi by synchronizowany i gwarantowa bezpieczestwo przetwarzania wielowtkowego.
Spenienie tych warunków jest konieczne, poniewa zawarto pamici trwaej moe by jed-
noczenie odczytywana i modyfikowana przez wiele instancji.

Aby uatwi Ci implementacj i obsug prostych usug trwaych, napisaem nastpujc klas

FileInstanceStore<ID,T>

public interface IInstanceStore<ID,T> where ID : IEquatable<ID>
{
void RemoveInstance(ID instanceId);
bool ContainsInstance(ID instanceId);
T this[ID instanceId]
{get;set;}
}

public class FileInstanceStore<ID,T> : IInstanceStore<ID,T> where ID :
IEquatable<ID>
{
protected readonly string Filename;
public FileInstanceStore(string fileName);

// Dalsza cz implementacji…

}

Klasa

FileInstanceStore<ID,T>

reprezentuje uniwersaln, plikow pami instancji. Klasa

File

InstanceStore<ID,T>

otrzymuje dwa parametry typów: parametr typu

musi reprezento-

wa typ porównywalny, za parametr typu

reprezentuje stan instancji. W czasie wykony-

wania statyczny konstruktor klasy

FileInstanceStore<ID,T>

sprawdza, czy oba te typy s szere-

gowalne (mog podlega serializacji).

Klasa

FileInstanceStore<ID,T>

udostpnia prosty mechanizm indeksujcy, który umoliwia

zapisywanie stanu instancji w pliku i odczytywanie go z tego pliku. Stan instancji mona te
usun z pliku. Istnieje take moliwo sprawdzenia, czy dany plik zawiera stan instancji.
Wszystkie te operacje zdefiniowano w interfejsie

IInstanceStore<ID,T>

. Implementacja tego

interfejsu w formie klasy

FileInstanceStore<ID,T>

reprezentuje sownik, a kada próba dostpu

powoduje serializacj i deserializacj tego sownika w i z pliku. Klasa

FileInstanceStore<ID,T>

uyta po raz pierwszy tworzy i inicjalizuje plik, umieszczajc w nim pusty sownik (po spraw-
dzeniu, czy rzeczywicie ten plik nie zawiera adnych danych).

Bezporednie przekazywanie identyfikatorów instancji

Najprostszym sposobem udostpniania identyfikatora instancji przez klienta jest bezporednie
(jawne) przekazywanie tego identyfikatora w formie parametru kadej operacji, która wymaga
dostpu do stanu instancji. Odpowiedni przykad klienta i usugi wraz z definicjami typów
pomocniczych pokazano na listingu 4.9.

Listing 4.9. Bezporednie przekazywanie identyfikatorów instancji

[DataContract]
class SomeKey : IEquatable<SomeKey>
{...}

Poleć książkę

Kup książkę

208

Rozdzia 4. Zarzdzanie instancjami

[ServiceContract]
interface IMyContract
{
[OperationContract]
void MyMethod(SomeKey instanceId);
}

// Typ pomocniczy uywany przez usug do uzyskiwania swojego stanu
[Serializable]
struct MyState
{...}

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
class MyService : IMyContract
{
public void MyMethod(SomeKey instanceId)
{
GetState(instanceId);
DoWork();
SaveState(instanceId);
}
void DoWork()
{...}

// Uzyskuje i ustawia MyState na podstawie pamici trwaej

void GetState(SomeKey instanceId)
{...}

void SaveState(SomeKey instanceId)
{...}
}

Aby lepiej zrozumie kod z listingu 4.9, warto przyjrze si listingowi 4.10 obsugujcemu
kieszonkowy kalkulator z pamici trwa w formie pliku dyskowego.

Listing 4.10. Kalkulator z jawnie przekazywanym identyfikatorem instancji

[ServiceContract]
interface ICalculator
{
[OperationContract]
double Add(double number1,double number2);

/* Pozostae dziaania arytmetyczne */

// Operacje zwizane z zarzdzaniem pamici

[OperationContract]
void MemoryStore(string instanceId,double number);

[OperationContract]
void MemoryClear(string instanceId);
}

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
class MyCalculator : ICalculator
{
static IInstanceStore<string,double> Memory =
new FileInstanceStore<string,double>(Settings.Default.MemoryFileName);

public double Add(double number1,double number2)
{

Poleć książkę

Kup książkę

Usugi trwae

_ 209

return number1 + number2;
}
public void MemoryStore(string instanceId,double number)
{
lock(typeof(MyCalculator))
{
Memory[instanceId] = number;
}
}
public void MemoryClear(string instanceId)
{
lock(typeof(MyCalculator))
{
Memory.RemoveInstance(instanceId);
}
}

// Dalsza cz implementacji…

}

W kodzie z listingu 4.10 nazwa pliku jest dostpna we wszystkich waciwociach projektu
w klasie

Settings

. Wszystkie instancje usugi kalkulatora uywaj tej samej pamici statycznej

reprezentowanej przez klas

FileInstanceStore<string,double>

. Kalkulator synchronizuje dostp

do tej pamici w kadej operacji i we wszystkich instancjach, blokujc typ usugi. Usunicie
zawartoci pamici jest traktowane przez kalkulator jako sygna koca przepywu pracy, po
którym usuga czyci swój stan w pamici trwaej.

Identyfikatory instancji w nagówkach

Zamiast bezporednio przekazywa identyfikator instancji, klient moe umieci ten identyfi-
kator w nagówkach komunikatów. Stosowanie nagówków komunikatów jako techniki prze-
kazywania dodatkowych parametrów na potrzeby niestandardowych kontekstów zostanie
szczegóowo omówione w dodatku B. W tym przypadku klient uywa klasy porednika

HeaderClientBase<T,H>

, a usuga moe odczyta identyfikator instancji za pomoc odpowied-

nich operacji opracowanej przeze mnie klasy pomocniczej

GenericContext<H>

. Usuga moe albo

uywa klasy

GenericContext<H>

w jej oryginalnej formie, albo opakowa j w ramach dedyko-

wanego kontekstu.

Ogólny wzorzec stosowania tej techniki pokazano na listingu 4.11.

Listing 4.11. Przekazywanie identyfikatorów instancji w nagówkach komunikatów

[ServiceContract]
interface IMyContract
{
[OperationContract]
void MyMethod();
}
// Strona klienta
class MyContractClient : HeaderClientBase<IMyContract,SomeKey>,IMyContract
{
public MyContractClient(SomeKey instanceId)
{}
public MyContractClient(SomeKey instanceId,string endpointName) :
base(instanceId,endpointName)
{}

Poleć książkę

Kup książkę

210

Rozdzia 4. Zarzdzanie instancjami

// Pozostae konstruktory…

public void MyMethod()
{
Channel.MyMethod();
}
}
// Strona usugi
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
class MyService : IMyContract
{
public void MyMethod()
{
SomeKey instanceId = GenericContext<SomeKey>.Current.Value;
...
}

// Dalsza cz taka sama jak na listingu 4.9

}

Take tym razem, aby schemat z listingu 4.11 nie by zbyt abstrakcyjny, warto przeanalizo-
wa listing 4.12 z kodem kalkulatora stosujcego technik przekazywania identyfikatorów
w formie nagówków komunikatów.

Listing 4.12. Kalkulator z identyfikatorem instancji w nagówkach komunikatów

[ServiceContract]
interface ICalculator
{
[OperationContract]
double Add(double number1,double number2);

/* Pozostae dziaania arytmetyczne */

// Operacje zwizane z zarzdzaniem pamici

[OperationContract]
void MemoryStore(double number);

[OperationContract]
void MemoryClear();
}
// Strona klienta
class MyCalculatorClient : HeaderClientBase<ICalculator,string>,ICalculator
{
public MyCalculatorClient(string instanceId)
{}

public MyCalculatorClient(string instanceId,string endpointName) :
base(instanceId,endpointName)
{}

// Pozostae konstruktory…

public double Add(double number1,double number2)
{
return Channel.Add(number1,number2);
}

public void MemoryStore(double number)
{
Channel.MemoryStore(number);
}

Poleć książkę

Kup książkę

Usugi trwae

_ 211

// Dalsza cz implementacji…

}
// Strona usugi
// Jeli stosowanie klasy GenericContext<T> jest niewygodne, mona j opakowa:
static class CalculatorContext
{
public static string Id
{
get
{
return GenericContext<string>.Current.Value ?? String.Empty;
}
}
}

public double Add(double number1,double number2)
{
return number1 + number2;
}
public void MemoryStore(double number)
{
lock(typeof(MyCalculator))
{
Memory[CalculatorContext.Id] = number;
}
}
public void MemoryClear()
{
lock(typeof(MyCalculator))
{
Memory.RemoveInstance(CalculatorContext.Id);
}
}

// Dalsza cz implementacji…

}

Powizania kontekstu dla identyfikatorów instancji

Technologia WCF udostpnia powizania dedykowane, które umoliwiaj przekazywanie nie-
standardowych parametrów kontekstu. Powizania tego typu, okrelane mianem powiza
kontekstu

(ang. context bindings), zostan szczegóowo omówione w dodatku B. Aplikacje

klienckie mog uywa klasy

ContextClientBase<T>

do przekazywania identyfikatorów instancji

za porednictwem protokou powiza kontekstu. Poniewa powizania kontekstu wymagaj
klucza i wartoci dla kadego parametru kontekstu, aplikacje klienckie bd musiay przeka-
zywa oba te elementy do swoich poredników. W przypadku zastosowania tego samego inter-
fejsu

IMyContract

co na listingu 4.11 odpowiedni porednik mógby mie nastpujc posta:

class MyContractClient : ContextClientBase<IMyContract>,IMyContract
{
public MyContractClient(string key,string instanceId) : base(key,instanceId)
{}
public MyContractClient(string key,string instanceId,string endpointName) :
base(key,instanceId,endpointName)

Poleć książkę

Kup książkę

212

Rozdzia 4. Zarzdzanie instancjami

{}

// Pozostae konstruktory…

public void MyMethod()
{
Channel.MyMethod();
}
}

Warto pamita, e protokó kontekstu obsuguje tylko acuchy w roli kluczy i wartoci. Skoro
warto klucza musi by znana usudze z wyprzedzeniem, klient moe równie dobrze trwale
zakodowa ten sam klucz w klasie samego porednika. Usuga moe nastpnie uzyska identy-
fikator instancji przy uyciu mojej klasy pomocniczej

ContextManager

(opisanej w dodatku B).

Podobnie jak w przypadku nagówków komunikatów usuga moe te opakowa interakcj
z klas

ContextManager

w ramach dedykowanej klasy kontekstu.

Na listingu 4.13 pokazano ogólny wzorzec przekazywania identyfikatora instancji za pored-
nictwem powiza kontekstu. Warto zwróci szczególn uwag na klucz identyfikatora instan-
cji trwale zapisany w kodzie porednika i na to, e jest to identyfikator znany usudze.

Listing 4.13. Przekazywanie identyfikatora instancji za porednictwem powizania kontekstu

// Strona klienta
class MyContractClient : ContextClientBase<IMyContract>,IMyContract
{
public MyContractClient(string instanceId) : base("MyKey",instanceId)
{}

public MyContractClient(string instanceId,string endpointName) :
base("MyKey",instanceId,endpointName)
{}

// Pozostae konstruktory…

public void MyMethod()
{
Channel.MyMethod();
}
}
// Strona usugi
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
class MyService : IMyContract
{
public void MyMethod()
{
string instanceId = ContextManager.GetContext("MyKey");

GetState(instanceId);
DoWork();
SaveState(instanceId);
}
void DoWork()
{...}

// Uzyskuje i ustawia stan na podstawie pamici trwaej

void GetState(string instanceId)
{...}

Poleć książkę

Kup książkę

Usugi trwae

_ 213

void SaveState(string instanceId)
{...}
}

Na listingu 4.14 pokazano przykad konkretnego uycia tego schematu na potrzeby usugi
kalkulatora.

Listing 4.14. Kalkulator z identyfikatorem instancji przekazywanym za porednictwem powizania kontekstu

// Strona klienta
class MyCalculatorClient : ContextClientBase<ICalculator>,ICalculator
{
public MyCalculatorClient(string instanceId) : base("CalculatorId",instanceId)
{}
public MyCalculatorClient(string instanceId,string endpointName) :
base("CalculatorId",instanceId,endpointName)
{}

// Pozostae konstruktory…

public double Add(double number1,double number2)
{
return Channel.Add(number1,number2);
}
public void MemoryStore(double number)
{
Channel.MemoryStore(number);
}

// Dalsza cz implementacji…

}
// Strona usugi
static class CalculatorContext
{
public static string Id
{
get
{
return ContextManager.GetContext("CalculatorId") ?? String.Empty;
}
}
}
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
class MyCalculator : ICalculator
{

// To samo co na listingu 4.12

}

Stosowanie standardowego identyfikatora dla powizania kontekstu

Konieczno trwaego kodowania i znajomoci z wyprzedzeniem klucza uywanego dla iden-
tyfikatora instancji jest pewnym utrudnieniem. Powizania kontekstu zaprojektowano z myl
o usugach trwaych, zatem kade takie powizanie zawiera automatycznie wygenerowany
identyfikator instancji w postaci obiektu klasy

Guid

(w formacie acuchowym), który jest

dostpny za porednictwem zastrzeonego klucza

instanceId

. Klient i usuga maj dostp do tej

samej wartoci identyfikatora klucza. Warto tego klucza jest inicjalizowana zaraz po zwróceniu
sterowania przez pierwsze wywoanie porednika — po tym, jak powizanie zyska moliwo
skojarzenia klienta i usugi. Jak kady parametr przekazywany za porednictwem powizania kon-
tekstu, tak i warto identyfikatora instancji jest niezmienna przez cay czas ycia porednika.

Poleć książkę

Kup książkę

214

Rozdzia 4. Zarzdzanie instancjami

Aby uproci interakcj ze standardowym identyfikatorem instancji, uzupeniem klas

Context

Manager

o metody, waciwoci i metody porednika zarzdzajce tym identyfikatorem (patrz

listing 4.15).

Listing 4.15. Zarzdzanie standardowym identyfikatorem instancji w klasie ContextManager

public static class ContextManager
{
public const string InstanceIdKey = "instanceId";

public static Guid InstanceId
{
get
{
string id = GetContext(InstanceIdKey) ?? Guid.Empty.ToString();
return new Guid(id);
}
}
public static Guid GetInstanceId(IClientChannel innerChannel)
{
try
{
string instanceId =
innerChannel.GetProperty<IContextManager>().GetContext()[InstanceIdKey];
return new Guid(instanceId);
}
catch(KeyNotFoundException)
{
return Guid.Empty;
}
}
public static void SetInstanceId(IClientChannel innerChannel,Guid instanceId)
{
SetContext(innerChannel,InstanceIdKey,instanceId.ToString());
}
public static void SaveInstanceId(Guid instanceId,string fileName)
{
using(Stream stream =
new FileStream(fileName,FileMode.OpenOrCreate,FileAccess.Write))
{
IFormatter formatter = new BinaryFormatter();
formatter.Serialize(stream,instanceId);
}
}

public static Guid LoadInstanceId(string fileName)
{
try
{
using(Stream stream = new FileStream(fileName,FileMode.Open,
FileAccess.Read))
{
IFormatter formatter = new BinaryFormatter();
return (Guid)formatter.Deserialize(stream);
}
}
catch
{
return Guid.Empty;
}

Poleć książkę

Kup książkę

Usugi trwae

_ 215

}

// Pozostae skadowe…

}

Klasa

ContextManager

definiuje metody

GetInstanceId()

SetInstanceId()

, które umoliwiaj

klientowi odpowiednio odczytanie identyfikatora instancji z kontekstu i zapisanie tego identy-
fikatora w kontekcie. Do uzyskiwania identyfikatora usuga uywa waciwoci

InstanceId

(dostpnej tylko do odczytu). Klasa

ContextManager

w tej formie dodatkowo zapewnia bezpiecze-

stwo typów, poniewa traktuje identyfikator instancji jako warto typu

Guid

(nie acuch).

Klasa wprowadza te mechanizmy obsugi bdów.

I wreszcie klasa

ContextManager

udostpnia metody

LoadInstanceId()

SaveInstanceId()

, które

odpowiednio odczytuj identyfikator instancji z pliku i zapisuj ten identyfikator w pliku.
Wymienione metody s szczególnie wygodne po stronie klienta, który moe zapisywa identy-
fikator pomidzy kolejnymi sesjami wspópracy aplikacji klienckiej z usug.

Klient moe co prawda uy klasy

ContextClientBase<T>

do przekazania standardowego identyfi-

katora instancji (jak na listingu 4.13), jednak lepszym rozwizaniem jest wykorzystanie wbu-
dowanej obsugi tego identyfikatora (patrz listing 4.16).

Listing 4.16. Klasa ContextClientBase<T> uzupeniona o obsug standardowych identyfikatorów instancji

public abstract class ContextClientBase<T> : ClientBase<T> where T : class
{
public Guid InstanceId
{
get
{
return ContextManager.GetInstanceId(InnerChannel);
}
}
public ContextClientBase(Guid instanceId) :
this(ContextManager.InstanceIdKey,instanceId.ToString())
{}

public ContextClientBase(Guid instanceId,string endpointName) :
this(ContextManager.InstanceIdKey,instanceId.ToString(),endpointName)
{}

// Pozostae konstruktory…

}

Na listingu 4.17 pokazano przykad uycia standardowego identyfikatora instancji przez
klienta i usug kalkulatora.

Listing 4.17. Usuga kalkulatora korzystajca ze standardowego identyfikatora

// Strona klienta
class MyCalculatorClient : ContextClientBase<ICalculator>,ICalculator
{
public MyCalculatorClient()
{}
public MyCalculatorClient(Guid instanceId) : base(instanceId)
{}
public MyCalculatorClient(Guid instanceId,string endpointName) :
base(instanceId,endpointName)
{}

Poleć książkę

Kup książkę

216

Rozdzia 4. Zarzdzanie instancjami

// Dalsza cz taka sama jak na listingu 4.14

}
// Strona usugi
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
class MyCalculator : ICalculator
{
static IInstanceStore<Guid,double> Memory =
new FileInstanceStore<Guid,double>(Settings.Default.MemoryFileName);

public double Add(double number1,double number2)
{
return number1 + number2;
}
public void MemoryStore(double number)
{
lock(typeof(MyCalculator))
{
Memory[ContextManager.InstanceId] = number;
}
}
public void MemoryClear()
{
lock(typeof(MyCalculator))
{
Memory.RemoveInstance(ContextManager.InstanceId);
}
}

// Dalsza cz implementacji…

}

Automatyczne zachowanie trwae

Wszystkie opisane do tej pory techniki obsugi usug trwaych wymagay wykonywania do
zoonych czynnoci po stronie samych usug — w szczególnoci operowania na trwaej pamici
stanów i bezporedniego zarzdzania stanem instancji przy okazji kadej operacji. Powtarzal-
no tych dziaa oznacza, e rodowisko WCF moe je zautomatyzowa, serializujc i dese-
rializujc stan usugi dla kadej operacji na podstawie wskazanej pamici stanów (przy uyciu
standardowego identyfikatora instancji).

Jeli programista zdecyduje si przekaza rodowisku WCF odpowiedzialno za zarzdzanie
stanem instancji, zarzdzanie bdzie przebiegao wedug nastpujcych regu:

Jeli klient nie przekaza identyfikatora, rodowisko WCF utworzy now instancj usugi,
korzystajc z jej konstruktora. Po zakoczeniu wywoania rodowisko WCF serializuje
instancj w pamici stanów.

Jeli klient przekazuje identyfikator do porednika i jeli pami stanów zawiera ju stan
pasujcy do tego identyfikatora, rodowisko WCF nie wywouje konstruktora instancji.
W takim przypadku wywoanie jest obsugiwane przez instancj odczytan (w procesie dese-
rializacji) z pamici stanów.

Jeli klient przekazuje prawidowy identyfikator, rodowisko WCF kadorazowo deseria-
lizuje instancj z pamici stanów, wywouje odpowiedni operacj i ponownie serializuje
w pamici nowy stan (zmodyfikowany przez t operacj).

Jeli klient przekazuje identyfikator, który nie wystpuje w pamici stanów, rodowisko
WCF zgasza stosowny wyjtek.

Poleć książkę

Kup książkę

Usugi trwae

_ 217

Atrybut zachowania usugi trwaej

Do wczania automatycznego zachowania trwaego suy atrybut zachowania

DurableService

który zdefiniowano w nastpujcy sposób:

public sealed class DurableServiceAttribute : Attribute,IServiceBehavior,...
{...}

Atrybut

DurableService

naley zastosowa bezporednio dla klasy usugi. Co wane, klasa

usugi musi by dodatkowo oznaczona albo jako szeregowalna (przystosowana do serializacji),
albo jako kontrakt danych (z atrybutem

DataMember

uytym dla wszystkich skadowych wyma-

gajcych zarzdzania trwaym stanem):

[Serializable]
[DurableService]
class MyService : IMyContract
{

/* Tylko szeregowalne zmienne skadowe */

public void MyMethod()
{

// Waciwe dziaania

}
}

Instancja usugi trwaej moe teraz zarzdza swoim stanem w zmiennych skadowych, tak
jakby bya zwyk instancj — tym razem to rodowisko WCF odpowiada za trwao tych
skadowych. Gdyby usuga nie zostaa oznaczona jako szeregowalna (lub jako kontrakt danych),
pierwsze wywoanie zakoczyoby si niepowodzeniem z powodu podjtej przez rodowisko
WCF próby serializacji instancji w pamici stanów. Kada usuga korzystajca z mechanizmu
automatycznego zarzdzania trwaym stanem musi zosta skonfigurowana jako usuga sesyjna,
a mimo to zachowuje si jak usuga aktywowana przez wywoania (rodowisko WCF dezak-
tywuje kontekst po kadym wywoaniu). Co wicej, usuga musi stosowa jeden ze zwizków
kontekstu dla kadego punktu kocowego, aby byo moliwe stosowanie standardowego iden-
tyfikatora instancji. Sam kontrakt musi dopuszcza lub wymusza stosowanie sesji transporto-
wej (nie moe jej wycza). Oba te ograniczenia s sprawdzane na etapie adowania usugi.

Atrybut zachowania operacji trwaej

Usuga moe opcjonalnie uy atrybutu zachowania

DurableOperation

do zasygnalizowania ro-

dowisku WCF koniecznoci wyczyszczenia stanu w pamici trwaej na kocu przepywu pracy:

[AttributeUsage(AttributeTargets.Method)]
public sealed class DurableOperationAttribute : Attribute,...
{
public bool CanCreateInstance
{get;set;}
public bool CompletesInstance
{get;set;}
}

Przypisanie waciwoci

CompletesInstance

wartoci

true

powoduje, e rodowisko WCF usu-

nie identyfikator instancji z pamici trwaej zaraz po zwróceniu sterowania przez wywoanie
operacji. Wartoci domyln waciwoci

CompletesInstance

jest

false

. Jeli klient nie przekaza

identyfikatora instancji, mona zapobiec utworzeniu nowej instancji przez operacj — wystar-
czy przypisa warto

false

waciwoci

CanCreateInstance

. Kod z listingu 4.18 demonstruje

uycie waciwoci

CompletesInstance

dla operacji

MemoryClear()

usugi kalkulatora.

Poleć książkę

Kup książkę

218

Rozdzia 4. Zarzdzanie instancjami

Listing 4.18. Przykad uycia waciwoci CompletesInstance do usunicia stanu

[Serializable]
[DurableService]
class MyCalculator : ICalculator
{
double Memory
{get;set;}
public double Add(double number1,double number2)
{
return number1 + number2;
}
public void MemoryStore(double number)
{
Memory = number;
}
[DurableOperation(CompletesInstance = true)]
public void MemoryClear()
{
Memory = 0;
}

// Dalsza cz implementacji…

}

Stosowanie waciwoci

CompletesInstance

jest o tyle problematyczne, e identyfikator kontek-

stu jest niezmienny. Oznacza to, e jeli klient próbuje wykona kolejne wywoania poprzez
obiekt porednika (ju po wykonaniu operacji z wartoci

true

we waciwoci

CompletesInstance

wszystkie te wywoania zakocz si niepowodzeniem, poniewa pami trwaa nie zawiera
ju identyfikatora instancji. Oznacza to, e klient musi wiedzie o braku moliwoci dalszego
korzystania z tego samego porednika — jeli ma kierowa dalsze wywoania do danej usugi,
musi uy nowego porednika, który nie ma jeszcze identyfikatora instancji (w ten sposób
klient rozpocznie nowy przepyw pracy). Jednym ze sposobów wymuszania odpowiedniego
zastosowania jest zamykanie programu klienta po zakoczeniu przepywu pracy (lub tworze-
nie nowej referencji do obiektu porednika). Na listingu 4.19 pokazano kod demonstrujcy, jak
zarzdza tym samym porednikiem usugi kalkulatora po wyczyszczeniu pamici (w kodzie
wykorzystano definicj porednika z listingu 4.17).

Listing 4.19. Resetowanie porednika po zakoczeniu przepywu pracy

class CalculatorProgram
{
MyCalculatorClient m_Proxy;

public CalculatorProgram()
{
Guid calculatorId =
ContextManager.LoadInstanceId(Settings.Default.CalculatorIdFileName);

m_Proxy = new MyCalculatorClient(calculatorId);
}
public void Add()
{
m_Proxy.Add(2,3);
}
public void MemoryClear()
{
m_Proxy.MemoryClear();

ResetDurableSession(ref m_Proxy);

Poleć książkę

Kup książkę

Usugi trwae

_ 219

}
public void Close()
{
ContextManager.SaveInstanceId(m_Proxy.InstanceId,
Settings.Default.CalculatorIdFileName);
m_Proxy.Close();
}
void ResetDurableSession(ref MyCalculatorClient proxy)
{
ContextManager.SaveInstanceId(Guid.Empty,
Settings.Default.CalculatorIdFileName);
Binding binding = proxy.Endpoint.Binding;
EndpointAddress address = proxy.Endpoint.Address;

proxy.Close();

proxy = new MyCalculatorClient(binding,address);
}
}

W kodzie z listingu 4.19 wykorzystano klas pomocnicz

ContextManager

do zaadowania

identyfikatora instancji z pliku i zapisania jej w tym pliku. Konstruktor programu klienta
tworzy nowy obiekt porednika na podstawie identyfikatora odczytanego z tego pliku. Jak
wida na wczeniejszym listingu 4.15, jeli plik nie zawiera identyfikatora instancji, metoda

LoadInstanceId()

zwraca warto

Guid.Empty

. Klas

ContextClientBase<T>

zaprojektowaem w taki

sposób, aby obsugiwaa pusty identyfikator GUID w roli identyfikatora kontekstu — w razie
przekazania pustego identyfikatora GUID klasa

ContextClient Base<T>

konstruuje swój obiekt

bez identyfikatora instancji, rozpoczynajc tym samym nowy przepyw pracy. Po wyczysz-
czeniu pamici usugi kalkulatora klient wywouje metod pomocnicz

ResetDurableSession()

Metoda

ResetDurableSession()

zapisuje najpierw pusty identyfikator GUID w pliku, po czym

tworzy kopi istniejcego porednika. Metoda kopiuje adres i powizanie dotychczasowego
porednika, zamyka go i tak ustawia referencj do porednika, aby wskazywaa nowo skon-
struowany obiekt z tym samym adresem i powizaniem oraz pustym identyfikatorem GUID
w roli identyfikatora instancji.

Programowe zarzdzanie instancj

Technologia WCF oferuje prost klas pomocnicz dla usug trwaych, nazwan

DurableOpera

tionContext

public static class DurableOperationContext
{
public static void AbortInstance();
public static void CompleteInstance();
public static Guid InstanceId
{get;}
}

Metoda

CompleteInstance()

umoliwia usudze programowe (nie deklaratywnie, jak w przy-

padku atrybutu

DurableOperation

) zakoczenie dziaania instancji i usunicie jej stanu z pamici

zaraz po zwróceniu sterowania przez wywoanie. Metoda

AbortInstance()

anuluje wszystkie

zmiany wprowadzone w pamici trwaej w czasie danego wywoania, przywracajc stan sprzed
tego wywoania. Waciwo

InstanceId

przypomina wspomnian wczeniej waciwo

Context

Manager.InstanceId

Poleć książkę

Kup książkę

220

Rozdzia 4. Zarzdzanie instancjami

Dostawcy trwaoci

Atrybut

DurableService

instruuje rodowisko WCF, kiedy serializowa i deserializowa dan

instancj usugi, ale w aden sposób nie wskazuje miejsca tej serializacji i deserializacji (nie
zawiera adnych informacji na temat pamici stanów). rodowisko WCF stosuje wzorzec pro-
jektowy mostu (ang. bridge) w postaci modelu dostawcy — dziki temu programista moe prze-
kazywa informacje o pamici stanów niezalenie od wspomnianego atrybutu. Oznacza to, e
atrybut

DurableService

jest oddzielony od pamici stanów, dziki czemu istnieje moliwo sto-

sowania mechanizmu automatycznego zachowania trwaego w przypadku pamici zapewnia-
jcych zgodno z tym mechanizmem.

Jeli usug skonfigurowano z atrybutem

DurableService

, naley jeszcze skonfigurowa hosta

z odpowiedni fabryk dostawców trwaoci. Klasa tej fabryki dziedziczy po klasie abstrakcyj-
nej

PersistenceProviderFactory

i tworzy podklas klasy abstrakcyjnej

PersistenceProvider

public abstract class PersistenceProviderFactory : CommunicationObject
{
protected PersistenceProviderFactory();
public abstract PersistenceProvider CreateProvider(Guid id);
}

public abstract class PersistenceProvider : CommunicationObject
{
protected PersistenceProvider(Guid id);

public Guid Id
{get;}

public abstract object Create(object instance,TimeSpan timeout);
public abstract void Delete(object instance,TimeSpan timeout);
public abstract object Load(TimeSpan timeout);
public abstract object Update(object instance,TimeSpan timeout);

// Pozostae skadowe…

}

Najbardziej popularnym sposobem wskazywania fabryki dostawców trwaoci jest umieszcza-
nie odpowiednich zapisów w formie zachowania usugi w pliku konfiguracyjnym hosta i odwo-
ywanie si do tego zachowania w definicji usugi:

<behaviors>
<serviceBehaviors>
<behavior name = "DurableService">
<persistenceProvider
type = "...type...,...assembly ..."

/>
</behavior>
</serviceBehaviors>
</behaviors>

Po skonfigurowaniu hosta z uwzgldnieniem fabryki dostawców trwaoci rodowisko uywa
klasy

PersistenceProvider

dla kadego wywoania do serializacji i deserializacji instancji. Gdyby

nie okrelono adnej fabryki dostawców trwaoci, rodowisko WCF przerwaoby tworzenie
hosta usugi.

Poleć książkę

Kup książkę

Usugi trwae

_ 221

Niestandardowi dostawcy trwaoci

Dobr ilustracj sposobu pisania prostego, niestandardowego dostawcy trwaoci jest moja klasa

FilePersistenceProviderFactory

, której definicja jest nastpujca:

public class FilePersistenceProviderFactory : PersistenceProviderFactory
{
public FilePersistenceProviderFactory();
public FilePersistenceProviderFactory(string fileName);
public FilePersistenceProviderFactory(NameValueCollection parameters);
}
public class FilePersistenceProvider : PersistenceProvider
{
public FilePersistenceProvider(Guid id,string fileName);
}

Klasa

FilePersistenceProvider

jest opakowaniem mojej klasy

FileInstanceStore<ID,T>

. Konstruk-

tor klasy

FilePersistenceProviderFactory

wymaga wskazania nazwy odpowiedniego pliku. Jeli

na wejciu konstruktora nie zostanie przekazana adna nazwa, klasa

FilePersistenceProvider

Factory

uyje domylnego pliku Instances.bin.

Warunkiem stosowania fabryki niestandardowych dostawców trwaoci w pliku konfigura-
cyjnym jest zdefiniowanie konstruktora, który otrzyma na wejciu kolekcj typu

NameValue

Collection

(reprezentujc parametry). Parametry w tej kolekcji maj posta zwykych par

kluczy i wartoci acuchowych wskazanych w sekcji zachowania fabryki dostawców w pliku
konfiguracyjnym. W tej roli mona stosowa niemal dowolne klucze i wartoci. Poniszy przy-
kad pokazuje, jak mona w ten sposób okreli nazw pliku:

Konstruktor moe teraz uy kolekcji

parameters

do uzyskania dostpu do tych parametrów:

string fileName = parameters["fileName"];

Dostawca trwaoci na bazie systemu SQL Server

rodowisko WCF jest dostarczane wraz z dostawc trwaoci, który zapisuje stan instancji
w dedykowanej tabeli bazy danych systemu SQL Server. Po przeprowadzeniu instalacji z usta-
wieniami domylnymi odpowiednie skrypty instalacyjne tej bazy danych mona znale w kata-
logu C:\Windows\Microsoft.NET\Framework\v4.0.30316\SQL\EN. Warto pamita, e doczony
do rodowiska WCF dostawca trwaoci moe wspópracowa tylko z bazami danych SQL
Server 2005, SQL Server 2008 lub nowszymi. Wspomniany dostawca trwaoci ma posta klas

SqlPersistenceProviderFactory

SqlPersistenceProvider

nalecych do podzespou

System.Workflow

Services

w przestrzeni nazw

System.ServiceModel.Persistence

Uycie tego dostawcy wymaga tylko wskazania odpowiedniej fabryki dostawców i zdefinio-
wania acucha poczenia:

Poleć książkę

Kup książkę

222

Rozdzia 4. Zarzdzanie instancjami

Istnieje te moliwo wymuszenia na rodowisku WCF serializacji instancji w formie tekstowej
(zamiast domylnej serializacji binarnej) na przykad na potrzeby diagnostyczne czy analityczne:

Dawienie

(ang. throttling) nie jest co prawda technik bezporedniego zarzdzania instancjami,

ale pozwala opanowa poczenia nawizywane przez aplikacje klienckie i obcienie usugi
powodowane przez te poczenia. Dawienie jest niezbdne, poniewa systemy informatyczne
nie s elastyczne (patrz rysunek 4.7).

Rysunek 4.7. Nieelastyczny charakter wszystkich systemów informatycznych

Oznacza to, e nie jest moliwe zwikszanie w nieskoczono obcienia systemu w nadziei na
stopniowy, proporcjonalny spadek wydajnoci — system informatyczny to nie guma do ucia,

Poleć książkę

Kup książkę

Dawienie

_ 223

któr mona rozciga niemal bez koca. Wikszo systemów pocztkowo dobrze radzi sobie
ze wzrostem obcienia, jednak po pewnym czasie niespodziewanie odmawiaj wspópracy.
W ten sposób zachowuj si wszystkie systemy informatyczne — szczegóowa analiza przy-
czyn tego zachowania wykraczaaby poza zakres tematyczny tej ksiki (wymagaaby analizy
teorii kolejkowania i kosztów zwizanych z zarzdzaniem zasobami). To niepodane, nieela-
styczne zachowanie jest szczególnie kopotliwe w przypadku nagych wzrostów obcienia
(patrz rysunek 4.8).

Rysunek 4.8. Chwilowy wzrost obcienia moe spowodowa, e stan systemu wyjdzie poza ograniczenia
przyjte przez projektantów

Nawet jeli system doskonale radzi sobie z nominalnym obcieniem (pozioma linia na
rysunku 4.8), nagy wzrost obcienia moe spowodowa przekroczenie zaoe projektowych
i doprowadzi do istotnego spadku poziomu obsugi (w stopniu odczuwalnym przez klientów).
Takie czasowe skoki mog te rodzi problemy w kontekcie oceny ogólnego wzrostu obcienia,
nawet jeli redni poziom nie powinien mie negatywnego wpywu na funkcjonowanie systemu.

Dawienie umoliwia zapobieganie przekraczaniu limitów obowizujcych dla danej usugi
i uywanych przez ni zasobów. Jeli dawienie jest wczone, przekroczenie skonfigurowanych
ustawie spowoduje, e rodowisko WCF automatycznie umieci oczekujce aplikacje klienckie
w kolejce i obsuy ich dania w kolejnoci przesania do usugi. Jeli w czasie, w którym
wywoanie oczekuje w kolejce, upynie limit czasowy, klient otrzyma wyjtek

TimeoutException

Dawienie jest przykadem niesprawiedliwej techniki, poniewa aplikacje klienckie, których
dania znalazy si w kolejce, dowiadczaj istotnego spadku poziomu obsugi. W tym
przypadku ta niesprawiedliwo jest jednak uzasadniona — gdyby wszystkie aplikacje wywo-
ujce, które powoduj skokowy wzrost obcienia, zostay obsuone, system co prawda dzia-
aby sprawiedliwie, ale spadek poziomu obsugi byby dostrzegalny dla wszystkich klientów.
Dawienie jest wic uzasadnione w sytuacji, gdy czas skoków obcienia jest stosunkowo krótki
w porównaniu z caym czasem funkcjonowania usug, tzn. gdy prawdopodobiestwo dwukrot-
nego umieszczenia tego samego klienta w kolejce jest bardzo niewielkie. Od czasu do czasu
dania czci klientów zostan umieszczone w kolejce (w odpowiedzi na nagy wzrost obci-
enia), ale system jako cao bdzie dziaa prawidowo. Dawienie nie sprawdza si w sytu-
acjach, gdy obcienie osiga nowy, wysoki poziom i utrzymuje si na tym poziomie przez
duszy czas (patrz rysunek 4.9). W takim przypadku dawienie powoduje tylko odoenie pro-
blemu na póniej, prowadzc ostatecznie do wyczerpania limitów czasowych po stronie klien-
tów. Taki system naley od podstaw zaprojektowa z myl o obsudze wikszego obcienia.

Poleć książkę

Kup książkę

224

Rozdzia 4. Zarzdzanie instancjami

Rysunek 4.9. Nieprawidowe zastosowanie dawienia

Dawienie stosuje si na poziomie typu usugi, zatem ma wpyw na wszystkie instancje tej usugi
i wszystkie jej punkty kocowe. Mechanizm dawienia jest kojarzony z elementami rozdziela-
jcymi dla wszystkich kanaów uywanych przez dan usug.

Technologia WCF umoliwia programicie sterowanie wybranymi lub wszystkimi poniszymi
parametrami obcienia usugi:

Maksymalna liczba równoczesnych sesji

Okrela czn liczb klientów, którzy mog jednoczenie dysponowa sesj transportow
dla danej usugi. W najwikszym skrócie ten parametr reprezentuje maksymaln liczb
klientów jednoczenie korzystajcych z powiza WS na bazie protokou TCP i (lub) IPC
(z niezawodnoci, bezpieczestwem lub oboma mechanizmami jednoczenie). Poniewa
bezpoczeniowy charakter podstawowych pocze na bazie protokou HTTP oznacza, e
sesje transportowe s bardzo krótkie (istniej tylko w czasie wykonywania wywoania),
opisywany parametr nie wpywa na aplikacje klienckie uywajce podstawowych powiza
lub powiza WS bez sesji transportowych. Obcienie generowane przez te aplikacje klienc-
kie mona ograniczy, okrelajc maksymaln dopuszczaln liczb równoczesnych wywo-
a. Parametr domylnie ma warto równ stokrotnej liczbie procesorów (lub rdzeni).

Maksymalna liczba równoczesnych wywoa

Ogranicza czn liczb wywoa, które mog by jednoczenie przetwarzane przez wszyst-
kie instancje usugi. Warto tego parametru powinna mieci si w przedziale od 1 do 3%
maksymalnej liczby wspóbienych sesji. Parametr domylnie ma warto równ szesna-
stokrotnoci liczby procesorów (lub rdzeni).

Maksymalna liczba jednoczenie istniejcych instancji

Decyduje o liczbie jednoczenie utrzymywanych kontekstów. Jeli warto tego parametru
nie zostanie ustawiona przez programist, domylnie zostanie uyta suma maksymalnej
liczby jednoczesnych wywoa i maksymalnej liczby jednoczesnych sesji (116-krotno
liczby procesorów lub rdzeni). Ustawienie wartoci tego parametru powoduje jej unieza-
lenienie od dwóch pozostaych waciwoci. Sposób odwzorowywania instancji na kon-
teksty zaley zarówno od stosowanego trybu zarzdzania kontekstem instancji, jak i od
obowizujcego modelu dezaktywacji kontekstu i instancji. W przypadku usugi sesyjnej
maksymalna liczba instancji jest jednoczenie czn liczb istniejcych jednoczenie aktyw-
nych instancji i czn liczb wspóbienych sesji. W przypadku stosowania mechanizmu
dezaktywacji instancji liczba instancji moe by duo mniejsza ni liczba kontekstów,

Poleć książkę

Kup książkę

Dawienie

_ 225

a mimo to aplikacje klienckie bd blokowane w razie osignicia przez liczb kontekstów
maksymalnej liczby jednoczenie istniejcych instancji. W przypadku usugi aktywowa-
nej przez wywoania liczba instancji jest równa liczbie wspóbienych wywoa. Oznacza
to, e dla usug aktywowanych przez wywoania maksymalna liczba instancji w praktyce
jest równa mniejszej sporód dwóch innych wartoci: maksymalnej liczby jednoczenie
istniejcych instancji i maksymalnej liczby wspóbienych wywoa. W przypadku usug
singletonowych warto tego parametru jest ignorowana, poniewa takie usugi i tak mog
mie tylko po jednej instancji.

Dawienie to jeden z aspektów hostingu i wdraania. Podczas projektowania usugi nie
naley przyjmowa adnych zaoe dotyczcych konfiguracji dawienia — programista
powinien raczej zakada, e jego usuga bdzie musiaa radzi sobie ze wszystkimi
daniami klientów. Wanie dlatego technologia WCF nie oferuje adnych atrybutów
sterujcych mechanizmem dawienia, chocia ich opracowanie nie stanowioby adnego
problemu.

Konfiguracja dawienia

Administratorzy zwykle konfiguruj dawienie w pliku konfiguracyjnym. Takie rozwizanie
umoliwia stosowanie rónych parametrów dawienia dla tego samego kodu usugi zalenie
od biecych warunków i wdroenia. Host moe te programowo konfigurowa dawienie na
podstawie decyzji podejmowanych w czasie wykonywania.

Administracyjne konfigurowanie dawienia

Na listingu 4.20 pokazano, jak skonfigurowa dawienie w pliku konfiguracyjnym hosta. Za
pomoc znacznika

behaviorConfiguration

mona doda do usugi niestandardowe zachowanie

ustawiajce parametry dawienia.

Listing 4.20. Administracyjne konfigurowanie dawienia

<system.serviceModel>
<services>
<service name = "MyService" behaviorConfiguration = "ThrottledBehavior">
...
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name = "ThrottledBehavior">
<serviceThrottling
maxConcurrentCalls = "500"
maxConcurrentSessions = "10000"
maxConcurrentInstances = "100"
/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>

Poleć książkę

Kup książkę

226

Rozdzia 4. Zarzdzanie instancjami

Programowe konfigurowanie dawienia

Proces hosta moe te programowo sterowa mechanizmem dawienia na podstawie biecych
parametrów wykonawczych. Dawienie mona skonfigurowa programowo wycznie przed
otwarciem hosta. Mimo e host moe przykry zachowanie mechanizmu dawienia znalezione
w pliku konfiguracyjnym (usuwajc je i dodajc wasne), w wikszoci przypadków programowe
sterowanie dawieniem naley stosowa tylko wtedy, gdy nie zdefiniowano odpowiednich usta-
wie w pliku konfiguracyjnym.

Klasa

ServiceHostBase

oferuje waciwo

Description

typu

ServiceDescription

public abstract class ServiceHostBase : ...
{
public ServiceDescription Description
{get;}

// Pozostae skadowe…

}

Typ

ServiceDescription

, jak nietrudno si domyli, reprezentuje opis usugi obejmujcy wszyst-

kie jej aspekty i zachowania. Klasa

ServiceDescription

zawiera waciwo nazwan

Behaviors

(typu

KeyedByTypeCollection<T>

) z interfejsem

IServiceBehavior

w roli parametru uogólnionego.

Sposób programowego ustawiania parametrów zachowania z dawieniem pokazano na
listingu 4.21.

Listing 4.21. Programowe konfigurowanie dawienia

ServiceHost host = new ServiceHost(typeof(MyService));

ServiceThrottlingBehavior throttle;
throttle = host.Description.Behaviors.Find<ServiceThrottlingBehavior>();
if(throttle == null)
{
throttle = new ServiceThrottlingBehavior();
throttle.MaxConcurrentCalls = 500;
throttle.MaxConcurrentSessions = 10000;
throttle.MaxConcurrentInstances = 100;
host.Description.Behaviors.Add(throttle);
}
host.Open();

Kod hosta sprawdza najpierw, czy parametry zachowania dawicego nie zostay ustawione
w pliku konfiguracyjnym. W tym celu kod wywouje metod

Find<T>()

klasy

KeyedByTypeCollec

tion<T>

, przekazujc klas

ServiceThrottlingBehavior

w roli parametru typu:

public class ServiceThrottlingBehavior : IServiceBehavior
{
public int MaxConcurrentCalls
{get;set;}
public int MaxConcurrentSessions
{get;set;}
public int MaxConcurrentInstances
{get;set;}

// Pozostae skadowe…

}

Jeli zwrócona zmienna

throttle

ma warto

null

, kod hosta tworzy nowy obiekt klasy

Service

ThrottlingBehavior

, ustawia jego parametry i dodaje go do zachowa reprezentowanych

w opisie usugi.

Poleć książkę

Kup książkę

Dawienie

_ 227

Usprawnienie przy uyciu klasy ServiceHost<T>

W przypadku stosowania rozszerze frameworku C# 3.0 istnieje moliwo uzupenienia klasy

ServiceHost

(lub dowolnej sporód jej podklas, na przykad

ServiceHost<T>

) o mechanizm auto-

matyzujcy kod z listingu 4.21 — przykad takiego rozwizania pokazano na listingu 4.22.

Listing 4.22. Rozszerzenie klasy ServiceHost o obsug dawienia

public static class ServiceThrottleHelper
{
public static void SetThrottle(this ServiceHost host,
int maxCalls,int maxSessions,int maxInstances)
{
ServiceThrottlingBehavior throttle = new ServiceThrottlingBehavior();
throttle.MaxConcurrentCalls = maxCalls;
throttle.MaxConcurrentSessions = maxSessions;
throttle.MaxConcurrentInstances = maxInstances;
host.SetThrottle(throttle);
}

public static void SetThrottle(this ServiceHost host,
ServiceThrottlingBehavior serviceThrottle,
bool overrideConfig)
{
if(host.State == CommunicationState.Opened)
{
throw new InvalidOperationException("Host jest ju otwarty");
}
ServiceThrottlingBehavior throttle =
host.Description.Behaviors.Find<ServiceThrottlingBehavior>();
if(throttle == null)
{
host.Description.Behaviors.Add(serviceThrottle);
return;
}
if(overrideConfig == false)
{
return;
}
host.Description.Behaviors.Remove(throttle);
host.Description.Behaviors.Add(serviceThrottle);
}
public static void SetThrottle(this ServiceHost host,
ServiceThrottlingBehavior serviceThrottle)
{
host.SetThrottle(serviceThrottle,false);
}
}

Klasa

ServiceThrottleHelper

udostpnia metod

SetThrottle()

, która otrzymuje na wejciu zacho-

wanie dawienia, i flag typu

Boolean

okrelajc, czy naley przykry ewentualne wartoci

odczytane z pliku konfiguracyjnego. Drugi parametr przecionej wersji metody

SetThrottle()

domylnie ma warto

false

. Metoda

SetThrottle()

uywa waciwoci

State

klasy bazowej

CommunicationObject

do sprawdzenia, czy host nie zosta jeszcze otwarty. Jeli skonfigurowane

parametry dawienia maj zosta przykryte, metoda

SetThrottle()

usuwa zachowanie dawie-

nia z opisu usugi. Pozostay kod z listingu 4.22 bardzo przypomina rozwizania zastosowane
na listingu 4.21. Oto przykad uycia klasy

ServiceHost<T>

do programowego ustawienia para-

metrów dawienia:

Poleć książkę

Kup książkę

228

Rozdzia 4. Zarzdzanie instancjami

ServiceHost<MyService> host = new ServiceHost<MyService>();
host.SetThrottle(12,34,56);
host.Open();

Take klas

InProcFactory<T>

(wprowadzon w rozdziale 1.) mona w podobny sposób

uzupeni o kod upraszczajcy zarzdzanie dawieniem.

Odczytywanie wartoci parametrów dawienia

Programici usug mog odczytywa wartoci parametrów dawienia w czasie wykonywania
kodu (na przykad na potrzeby diagnostyczne lub analityczne). Warunkiem uzyskania dostpu
do waciwoci dawienia przez instancj usugi (za porednictwem obiektu rozdzielajcego
zadania) jest uzyskanie referencji do hosta z kontekstu operacji.

Klasa bazowa hosta, czyli

ServiceHostBase

, definiuje waciwo

ChannelDispatchers

dostpn tylko

do odczytu:

public abstract class ServiceHostBase : CommunicationObject,...
{
public ChannelDispatcherCollection ChannelDispatchers
{get;}

// Pozostae skadowe…

}

ChannelDispatchers

to kolekcja obiektów klasy

ChannelDispatcherBase

ze cis kontrol typów:

public class ChannelDispatcherCollection :
SynchronizedCollection<ChannelDispatcherBase>
{...}

Kady element tej kolekcji jest obiektem klasy

ChannelDispatcher

. Klasa

ChannelDispatcher

udo-

stpnia waciwo

ServiceThrottle

public class ChannelDispatcher : ChannelDispatcherBase
{
public ServiceThrottle ServiceThrottle
{get;set;}

// Pozostae skadowe…

}
public sealed class ServiceThrottle
{
public int MaxConcurrentCalls
{get;set;}
public int MaxConcurrentSessions
{get;set;}
public int MaxConcurrentInstances
{get;set;}
}

Waciwo

ServiceThrottle

zawiera skonfigurowane wartoci parametrów dawienia:

class MyService : ...
{
public void MyMethod()

// Operacja kontraktu

{
ChannelDispatcher dispatcher = OperationContext.Current.
Host.ChannelDispatchers[0] as ChannelDispatcher;

ServiceThrottle serviceThrottle = dispatcher.ServiceThrottle;

Poleć książkę

Kup książkę

Dawienie

_ 229

Trace.WriteLine("Maksymalna liczba wywoa: " + serviceThrottle.MaxConcurrentCalls);
Trace.WriteLine("Maksymalna liczba sesji: " + serviceThrottle.MaxConcurrentSessions);
Trace.WriteLine("Maksymalna liczba instancji: " + serviceThrottle.MaxConcurrentInstances);
}
}

Warto pamita, e usuga moe tylko odczyta wartoci parametrów dawienia i w aden
sposób nie moe na nie wpywa. Kada próba ustawienia tych wartoci spowoduje zgoszenie
wyjtku

InvalidOperationException

Take w tym przypadku proces odczytywania wartoci parametrów mona usprawni za
pomoc klasy

ServiceHost<T>

. Naley najpierw doda waciwo

ServiceThrottle

public class ServiceHost<T> : ServiceHost
{
public ServiceThrottle Throttle
{
get
{
if(State == CommunicationState.Created)
{
throw new InvalidOperationException("Host nie jest otwarty");
}
ChannelDispatcher dispatcher = OperationContext.Current.
Host.ChannelDispatchers[0] as ChannelDispatcher;
return dispatcher.ServiceThrottle;
}
}

// Pozostae skadowe…

}

Od tej pory mona uy klasy

ServiceHost<T>

w roli hosta usugi, a za porednictwem waci-

woci

ServiceThrottle

mona uzyska dostp do skonfigurowanego zachowania dawienia:

// Kod hosta
ServiceHost<MyService> host = new ServiceHost<MyService>();
host.Open();

class MyService : ...
{
public void MyMethod()
{
ServiceHost<MyService> host = OperationContext.Current.
Host as ServiceHost<MyService>;
ServiceThrottle serviceThrottle = host.Throttle;
...
}
}

Dostp do waciwoci

Throttle

klasy

ServiceHost<T>

mona uzyska dopiero po otwarciu

hosta, poniewa kolekcja

dispatcher

jest inicjalizowana dopiero w momencie otwarcia.

Poleć książkę

Kup książkę

230

Rozdzia 4. Zarzdzanie instancjami

Poleć książkę

Kup książkę

813

Skorowidz

ACID, 299
AddServiceEndpoint(), 60
adresy, 32, 33

dynamiczne, 687
HTTP, 34
IPC, 34
magistrala usug, 35
MSMQ, 34
statyczne, 687
TCP, 33

akcesory, 113
aktywacja przez wywoania, 178, 179, 181, 182, 183

konfiguracja, 180
wybór usug, 184
wydajno, 184

analizatory kontraktów danych, 144

instalacja, 146

aplikacja

na bazie usug, 656
przywracanie dziaania, 297, 298

aplikacja biznesowa, bezpieczestwo, 554, 567
aplikacja internetowa, 537, 539

bezpieczestwo, 566

aplikacja intranetowa, 510

bezpieczestwo, 565

app.config, 41
AppFabric, 46, 47
architektura, 89, 90

hosta, 91
oparta na przechwyceniach, 90

ASP.NET Providers, Patrz dostawcy ASP.NET
AsyncPattern, 429
AsyncWaitHandle, 433, 434
ataki DoS, 503
ataki powtórzenia, 503
authentication, Patrz uwierzytelnianie
AuthorizationPolicy, 603

autorejestracja, 299
autoryzacja, 502, 530, 545, 552, 557, 558, 561, 562

wybór trybu, 531

BasicHttpBinding, 50, 51, 54, 99, 187, 505, 506, 508
BasicHttpContextBinding, 53
BasicHttpSecurityMode, 506
BeginTransaction(), 301
behaviours, Patrz zachowania
bezpieczestwo, 501, 510, 788

anonimowych komunikatów, 634
aplikacja bez zabezpiecze, 562
aplikacja biznesowa, 554, 567
aplikacja internetowa, 537, 539, 566
aplikacja intranetowa, 510, 565
aplikacja o dostpie anonimowym, 559, 560
audyt, 578, 579, 580, 581
autoryzacja, 502
framework, 563, 564
na poziomie komunikatów, 632, 636, 639
na poziomie transportu, 631, 632
oparte na rolach, 532, 533, 534, 535, 546, 553
po stronie hosta, 571, 572
po stronie klienta, 572
punkt-punkt, 630
scenariusze, 563
transferu danych, 503, 630, 639, 640

tryby, 503, 504, 505

typów, 246
uwierzytelnianie, 501

biblioteka zada równolegych, 396
BinaryFormatter, 124
binding discovery, Patrz odkrywanie powiza
bindingConfiguration, 100
bdy, 261, 784

diagnozowanie, 272
dostarczania, 467

Poleć książkę

Kup książkę

814

Skorowidz

bdy

instalacja rozszerze, 287
izolacja, 261
kanay, 271
kontrakty, 268
maskowanie, 262, 267
obsuga, 270, 285
obsuga asynchroniczna, 442
odtwarzania, 475
propagowanie, 267
protokou SOAP, 267
rozszerzenia, 281
typy, 262
udostpnianie, 282
wywoania zwrotne, 278

boundary problem, Patrz problem ogranicze
bounded-generic types, Patrz parametry typu
bufory, 600, 601

a kolejki, 600, 601
administrowanie, 603
komunikaty, 607, 608
strategia dziaania, 602
tworzenie za pomoc Service Bus Explorer, 605

CallbackBehaviour, 280
CallbackErrorHandlerBehaviour, 294, 295
certyfikat X509, 540
ChannelDispatchers, 228, 287, 288
ChannelFactory<T>, 92, 93, 249
channels, Patrz kanay
chmura, przechwytywanie wywoa, 599, 600
ClientBase<T>, 84, 192
CLR, 29
CollectionDataContract, 172, 173
COM, 650, 652
Common Language Runtime, Patrz CLR
CommunicationObjectFaultedException, 97, 265
CommunicationState.Faulted, 263
ConcurrencyMode, 378
ConcurrencyMode.Multiple, 379, 381, 382, 383,

386, 387, 419

ConcurrencyMode.Reentrant, 382, 383, 386, 420
ConcurrencyMode.Single, 379, 386, 419
Conditional, 453
context bindings, Patrz powizania kontekstu
context deactivation, Patrz dezaktywacja kontekstu
ContextClientBase<T>, 211
Credentials, 540
Credentials Manager, Patrz Meneder powiadcze
czas wywoania, 85
czyszczenie rodowiska, 184

data member, Patrz skadowa danych
data-contract resolvers, Patrz analizatory

kontraktów danych

DataContractAttribute, 128, 133
DataContractResolver, 144
DataContractSerializer, 124, 125
DataContractSerializer<T>, 126
DataMemberAttribute, 128, 132
Dead-Letter Queue, Patrz kolejki utraconych

komunikatów

DeadLetterQueue, 470
dedukowane kontrakty danych, 133
delegaty, 166
DeliveryRequirementAttribute, 101, 102
demarcating operations, Patrz operacje

demarkacyjne

deserializacja, 122, 123

zdarzenia, 135, 137, 138, 160

deserialized, 135, 137, 138
deserializing, 135, 137
designated account, Patrz konto wyznaczone
dezaktywacja kontekstu, 200
Discoverability, 602
discovery cardinality, Patrz liczno odkrywania
Dispose(), 179
distributed transaction, Patrz transakcje

rozproszone

Distributed Transaction Coordinator,

Patrz rozproszony koordynator transakcji

DistributedIdentifier, 316
DLQ, Patrz kolejki utraconych komunikatów
dawienie, 222, 223, 224, 225

konfiguracja, 225, 226
odczytywanie wartoci parametrów, 228

dostawcy ASP.NET, 546, 547
DTC, Patrz rozproszony koordynator transakcji
DuplexChannelFactory<T>, 249
DuplexClientBase<T>, 238, 239, 240, 246
DurableOperation, 217
DurableOperationContext, 219
DurableService, 217, 220, 266, 361
dziedziczenie kontraktów, 105

endpoint, Patrz punkty kocowe
EndpointNotFoundException, 262
enlistment, Patrz rejestrowanie
EnumMember, 165, 166
ErrorHandleBehaviour, 289, 290
ErrorHandlerHelper.PromoteException(), 284
ExpiresAfter, 602

Poleć książkę

Kup książkę

Skorowidz

_ 815

fabryka

dwustronna, 578
hostów, 46
kanaów, 576
kanaów dupleksowych, 249, 250
odkrywania, 699

Factory, 46
faktoryzacja, 110, 111

kontraktów usugi, 110, 112, 113
metryki, 112, 113

FaultContract, 269, 270
FaultException, 263, 268, 271
FaultException<T>, 267, 268, 272
fire-and-forget pattern, Patrz odpal-i-zapomnij
formatery

.NET, 124
WCF, 124

FormHost<F>, 404, 405
formularze, 400, 405

jako usuga, 403

framework .NET, 651, 652
funkcja, 649

GenericIdentity, 521
GenericResolver, 148, 150, 152, 153
generyczny analizator, 148

instalacja, 150

GetCallbackChannel<T>(), 241
Globally Unique IDentifier, Patrz GUID
gosowanie

deklaratywne, 325, 327
jawne, 327, 328
w wywoaniach zwrotnych, 373
wewntrz zasigu zagniedonego, 336

GRID, 53
GUID, 33, 315

HandleError(), 285
host, 91

architektura, 91
rozszerzenia obsugujce bdy, 290

host process, Patrz proces hostujcy
hosting, 39

IIS 5//6, 39
in-proc, 39
niestandardowy na IIS/WAS, 46

WAS, 45
wasny, 40
wybór, 48, 49

HTTP, 34
hybrydowe zarzdzanie stanem, 357, 358

IAsyncResult, 431, 432, 433
IClientMessageInspector, 770
ICommunicationObject, 44
identyfikator instancji, 206

bezporednie przekazywanie, 207
powizania kontekstu, 211, 212, 213
w nagówkach, 209

identyfikator sesji, 191
identyfikator transakcji rozproszonej, 316
IDictionary, 174
IDisposable, 179, 184
IEndpointBehaviour, 293
IEnumerable, 169
IEnumerable<T>, 169
IErrorHandler, 281, 287, 288
IExtensibleDataObject, 163, 164
IIdentity, 520, 521
IMetadataExchange, 68
Impersonate(), 523
ImpersonationOption.Allowed, 524
ImpersonationOption.NotAllowed, 524
ImpersonationOption.Required, 524
IncludeExceptionDetailInFaults, 275, 280
inferred data contracts, Patrz dedukowane

kontrakty danych

infoset, 121
InProcFactory, 93, 95

CreateInstance(), 93, 95
GetAddress(), 95

InProcFactory<T>, implementacja, 94
instance management, Patrz zarzdzanie

instancjami

InstanceContext, 238, 246
instancje, 200

a dostp wspóbieny, 385
dezaktywacja, 200, 203, 204
programowe zarzdzanie, 219
zarzdzanie, 266, 343, 460, 782
zarzdzanie identyfikatorami, 360

Inter Process Communication, Patrz IPC
interception-based architecture, Patrz architektura

oparta na przechwyceniach

interfejs uytkownika, 392

dostp i aktualizacja, 393
kontrolki, 395, 397

Poleć książkę

Kup książkę

816

Skorowidz

interfejs uytkownika

obsuga wielu wtków, 402
responsywno, 406

InvalidContractException, 132
InvalidOperationException, 102, 103, 242, 262
inynieria oprogramowania, historia, 647
IPC, 34
IPrincipal, 530, 531, 534
IServiceBehaviour, 287

ApplyDispatchBehaviour(), 287

IsInRole(), 534
IsolationLevel, 328

kanay, 90, 91, 92
Kernel Transaction Manager, Patrz menedery

transakcji jdra

klasy czciowe, 137
klient, 76

konfiguracja z poziomu programu, 86
nieusugowy, 340
odczony, 445
plik konfiguracyjny, 81, 82, 83
testowy, 87, 88
usugi, 31

KnownTypeAttribute, 139, 141, 143

wielokrotne zastosowanie, 143

kodowanie

binarne, 52
tekstowe, 52

kolejki

a bufory, 600
czyszczenie, 452
nietransakcyjne, 459, 460
prywatne, 448, 449
publiczne, 448
tworzenie, 449
utraconych komunikatów, 469

implementacja usugi, 474
konfiguracja, 470
przetwarzanie, 471
sprawdzanie wasnej, 471
tworzenie usugi, 472

kolejkowanie

wydawców i subskrybentów, 749
wymaganie, 483

kolekcje, 169, 170, 171

niestandardowe, 171
referencje, 173

kompilator, 648
komunikaty, 503

nagówki, 663
ochrona, 539

ograniczanie ochrony, 517
trujce, 476

obsuga w MSMQ 3.0, 480
obsuga w MSMQ 4.0, 477
usuga, 479

konfiguracja, 89
kontekst synchronizacji, 390, 391, 392, 396, 420, 421

instalowany na hocie, 414
interfejs uytkownika, 392
usugi, 397
wasny, 408, 409, 410
wywoania zwrotnego dopeniajcego, 437

konteksty, 91, 92, 200

powizania, 672, 678
wywoania operacji, 191

konto wyznaczone, 520
kontrakty, 35, 103, 113

bdów, 35, 268
danych, 35, 121, 127, 132, 133, 781

analizatory, 144, 146
atrybuty, 128
dedukowane, 133
delegaty, 166
dzielone, 138
hierarchia, 139
importowanie, 130
równowano, 155
zdarzenia, 135
zoone, 135

dziedziczenie, 105
faktoryzacja, 110, 111, 112, 113
hierarchia po stronie klienta, 106, 107, 108
kolejkowane, 447
projektowanie, 110
usug, 35, 781
wiadomoci, 35

KTM, Patrz menedery transakcji jdra
kwerendy, 114

lekki meneder transakcji, 310, 311, 313
liczno odkrywania, 696
lightweight protocol, Patrz protokó lekki
Lightweight Transaction Manager, Patrz lekki

meneder transakcji

lista inwokacji, 166
LocalIdentifier, 315
LogbookManager, 285, 286
lokalna pami wtku, 389
lokalny identyfikator transakcji, 315
LTM, Patrz lekki meneder transakcji

Poleć książkę

Kup książkę

Skorowidz

_ 817

magistrala usug, 35, 583, 584, 585, 789

bufory, 600, 601, 602, 603, 607, 608
eksplorator, 590, 591
jako centrum zdarze, 598
jako ródo metadanych, 628
powizania, 591
programowanie, 586
rejestr, 589
uwierzytelnianie, 621, 622, 623, 627
z buforowan usug odpowiedzi, 617

mapowanie protokou, 63
marshaling, 29
marshaling by value, Patrz przekazywanie

przez warto

MaxMessageCount, 602
mechanizm transportu, 32
MembershipProvider, 547, 548
Meneder powiadcze, 550, 551
meneder zasobu, 304
menedery transakcji, 308, 310

awansowanie, 313
jdra, 310, 311, 313
lekki meneder transakcji, 310
rozproszony koordynator transakcji, 310

menedery ulotnych zasobów, 343
message reliability, Patrz niezawodno

dostarczania wiadomoci

MessageBufferClient, 603, 604, 607
MessageBufferPolicy, 602
MessageHeaders, 664
MessageQueue, 449
metadane, 31, 63

programowe przetwarzanie, 114
przeszukiwanie, 114
punkt wymiany, 67, 68, 69, 72
udostpnianie, 454
udostpnianie przez HTTP-GET, 64, 65
wczanie wymiany w pliku konfiguracyjnym,

wczanie wymiany z poziomu programu, 65

Metadata Explorer, 72, 116, 630, 703, 731
MetadataHelper, 116, 117
MetadataResolver, 116
metody, przecianie, 103, 104
metryki faktoryzacji, 112, 113
MEX Explorer, 709
Microsoft Message Queuing, Patrz MSMQ
Microsoft.ServiceBus.dll, 586
mieszany tryb zabezpiecze, 637, 638
model komponentowy, 650
model obiektowy, 649
model odczony, 445

model usug, 653, 655
mostek HTTP, 496, 497

projektowanie, 496

MSMQ, 33, 34, 446, 448, 449, 454, 459, 460, 467,

468, 469

czas ycia, 469

MsmqBindingBase, 469, 470
MsmqIntegrationBinding, 54
MsmqMessageProperty, 473, 474

nagówki, 663

hermetyzacja, 666
po stronie klienta, 664
po stronie usugi, 666

nazwy, 38
NetDataContractSerializer, 126
NetMsmqBinding, 51, 99, 446, 505, 507, 508, 515

bezpieczestwo, 517

NetMsmqSecurityMode, 507
NetNamedBinding, 505
NetNamedPipeBinding, 51, 99, 100, 187, 507, 508, 514

bezpieczestwo, 515

NetNamedPipeSecurityMode, 507
NetPeerTcpBinding, 53
NetTcpBinding, 51, 99, 100, 187, 505, 507, 508, 513

bezpieczestwo, 513, 514

NetTcpContextBinding, 53, 513
NetTcpRelayBinding, 237
NetTcpSecurity, 513
niezawodno, 98, 99, 100

dostarczania wiadomoci, 98, 99
konfiguracja, 100
operacje jednokierunkowe, 233
sesje, 190
transakcje, 305
transportu, 98
wiadomoci, 100

NonSerialized, 123, 124

obcienie usugi, 224
obiekt porednika, 31
ObjectDisposedException, 244, 262
obsuga bdów, 270

asynchroniczna, 442

odkrywanie, 685

adresu, 685, 686
cige, 704
magistrali usug, 712, 714
powiza, 698

Poleć książkę

Kup książkę

818

Skorowidz

odpal-i-zapomnij, 49
ogoszenia, 706, 724, 727

architektura, 706
automatyczne, 708
kompletna implementacja, 709
otrzymywanie, 708
upraszczanie, 709

OnDeserialized, 136
OnDeserializing, 136, 160
one-way operation, Patrz operacje

jednokierunkowe

OnSerialized, 136
OnSerializing, 136
operacje, 231, 782

asynchroniczne jednokierunkowe, 439
demarkacyjne, 197, 198, 199, 200
dupleksowe, 236
jednokierunkowe, 232

konfiguracja, 232
niezawodno, 233
usugi sesyjne, 233
wyjtki, 234

zwrotne, 236
danie-odpowied, 231

operation call context, Patrz konteksty wywoania

operacji

OperationBehaviourAttribute, 178
OperationContextScope, 665
OperationContract, 36, 37, 38, 232
osobowo, 530
otoczenie transakcji, 314
OverflowPolicy, 603

pami trwaa, 206, 207
parametry typu, 148
partial classes, Patrz klasy czciowe
per-call activation, Patrz aktywacja przez wywoania
Persistent Subscription Manager, 748
personifikacja, 523

deklaratywna, 524
mikka, 535
ograniczenie, 527
rczna, 523
unikanie, 529
wszystkich operacji, 525

plik konfiguracyjny, 89
polityka bezpieczestwa, 509
porednik, 76, 80

dupleksowy, 238, 246
generowanie, 76, 77, 78, 80
korzystanie, 84

wywoania asynchroniczne, 429
zamykanie, 85, 265

powiadczenia systemu Windows, 545
powizania

kontekstu, 211, 213
NetTcpRelayBinding, 237
tryby transferu, 641
WSDualHttpBinding, 237

powinowactwo wtków, 389, 413, 414

a wywoania zwrotne, 426

PrincipalPermissionAttribute, 532
PrincipalPermissionMode.None, 531
PrincipalPermissionMode.UseWindowsGroups,

531, 532, 545, 546

private-session mode, Patrz tryb sesji prywatnej
problem ogranicze, 653
proces hostujcy, 39, 41, 56
property-like methods, Patrz akcesory
ProtectionLevel, 517, 518
protocolMapping, 63
protokoy transakcji, 308
protokó lekki, 308, 309
protokó OleTx, 309
protokó WS-Atomic Transaction, 309
ProvideFault(), 282, 283
proxy, Patrz obiekt porednika
przecianie metod, 103, 104
przekazywanie przez warto, 122
przepyw pracy, 205
przepustowo, kontrola, 467
przestrzenie nazw, 38

definiowanie, 38

przesyanie danych strumieniowe, 256
przetwarzanie priorytetowe, 415
publisher, Patrz wydawca
punkt wymiany metadanych, 67, 68, 72

z poziomu programu, 69

punkty kocowe, 55

adres bazowy, 57
domylne, 61, 62
konfiguracja, 56, 60
MEX, 67
standardowe, 68

ReceiveErrorHandling, 477
ReceiveErrorHandling.Drop, 478, 480
ReceiveErrorHandling.Fault, 477, 478, 480
ReceiveErrorHandling.Move, 478
ReceiveErrorHandling.Reject, 478
ReceiveRetryCount, 477
refleksje, 123

Poleć książkę

Kup książkę

Skorowidz

_ 819

rejestrowanie, 299
ReleaseInstanceMode.AfterCall, 202
ReleaseInstanceMode.BeforeAndAfterCall, 203
ReleaseInstanceMode.BeforeCall, 201, 202
ReleaseInstanceMode.None, 201, 202
reply-request, Patrz operacje danie-odpowied
request-reply pattern, Patrz zapytanie-odpowied
Resource Manager, Patrz meneder zasobu
rozproszony koordynator transakcji, 310, 311, 312
równowaenie obcienia, 481

scopes, Patrz zasigi
security principal, Patrz osobowo
SecurityAccessDeniedException, 262
SecurityBehaviour, 564, 565, 568, 569, 571
SecurityClientBase<T>, 574, 575
SecurityHelper, 572, 573, 574
SecurityMode, 507
SecurityNegotiationException, 262
Serializable, 123, 128
serializacja, 121, 122, 123, 124

formatery .NET, 124
formatery WCF, 124
kontraktów danych, 127, 133
porzdek, 156
XML, 133
zdarzenia, 135, 136

serialized, 135
serializing, 135
Service Bus Explorer, 590
service orientation, Patrz zorientowanie na usugi
ServiceBehaviourAttribute, 178, 274
ServiceContractAttribute, 35, 36, 37, 38, 103, 105, 781
ServiceDescription, 226
ServiceEndpoint, 146

Contract, 115

ServiceHost, 41

AddServiceEndpoint(), 60

ServiceHost<T>, 44, 45, 152, 196, 227

AddAllMexEndPoints(), 71
AddAllMexPoints(), 72
EnableMetadataExchange(), 71, 72
HasMexEndpoint, 71, 72
poprawa efektywnoci, 71

ServiceHostBase, 42, 531

Description, 65

ServiceKnownType, 141, 142, 143
serviceMetadata, 64, 68
ServiceMetadataEndpoint, 70
ServiceModelEx, 735, 791
ServiceSecurityContext, 521, 522
serwer MTS, 652

sesja transportowa, 97, 181

przerwania, 97
wizania, 97

sesje prywatne, 185
sesjogram, 460
sessiongram, Patrz sesjogram
SessionMode.Allowed, 186
SessionMode.NotAllowed, 188, 189
SessionMode.Required, 187, 259
SetCertificate(), 541
SetTransactionComplete(), 327
singleton, 193, 197

naturalny, 197
transakcyjny, 366
transakcyjny stanowy, 368, 369
wybór, 197

skadowa danych, 133
sowniki, 174
SO, Patrz zorientowanie na usugi
SOAP, 31
SoapFormatter, 124
sposoby komunikacji, 49
stan, przekazywanie informacji, 436
standardowe punkty kocowe, 68
state-aware service, Patrz usugi wiadome stanu
Stream, 256, 257
streaming transfer mode, Patrz tryb przesyania

strumieniowego

strumienie wejcia-wyjcia, 256
strumieniowe przesyanie danych, 256, 258, 259

powizania, 257
transport, 258

strumieniowe przesyanie komunikatów, 256
subscriber, Patrz subskrybent
subskrybent, 252, 253, 734, 762

kolejkowany, 750
rodzaje, 735
singletonowy, 748
trway, 735, 739, 747
ulotny, 735

SvcConfigEditor, narzdzie, 83, 84
SvcUtil, narzdzie, 78, 80
SynchronizationContext, 390
synchronizator puli wtków, 408
Syndication Service Library, projekt, 89
syndykacja, 54
System.Transactions, 332

TCP, 33
thread affinity, Patrz powinowactwo wtków
Thread Local Storage, Patrz lokalna pami wtku

Poleć książkę

Kup książkę

820

Skorowidz

ThreadAbortException, 261
ThreadPoolSynchronizer, 408, 409
throttling, Patrz dawienie
TimeoutException, 85, 231, 262
TimeToLive, 469
TokenImpersonationLevel.Anonymous, 528
TokenImpersonationLevel.Delegation, 528
TokenImpersonationLevel.Identification, 528, 529
TokenImpersonationLevel.Impersonation, 528
TokenImpersonationLevel.None, 528
topologia siatki, 53
tosamo, zarzdzanie, 509, 520, 546

w aplikacji biznesowej, 559, 561
w scenariuszu bez zabezpiecze, 562, 563
w scenariuszu internetowym, 554
w scenariuszu intranetowym, 535

Transaction, 314, 315
TransactionalBehaviour, 363, 364, 365
TransactionalMemoryProviderFactory, 362
TransactionAutoComplete, 325, 326, 328
TransactionFlow, 305
TransactionFlowAttribute, 306
TransactionFlowOption.Allowed, 307
TransactionFlowOption.Mandatory, 307
TransactionFlowOption.NotAllowed, 307
TransactionInformation, 315
TransactionIsolationLevel, 329, 330
TransactionScope, 332, 333, 335, 339, 340
TransactionScopeOption.Required, 336, 337
TransactionScopeOption.RequiresNew, 337, 338
TransactionScopeOption.Suppress, 338
TransactionScopeRequired, 326
TransactonInstanceProviderFactory, 362
transakcje, 297, 298, 454, 493, 785

a dostp niesynchroniczny, 382
a tryby instancji, 369
a wielobieno metod, 384
ACID, 299
atomowo, 299, 300
cykl ycia, 346, 353
dostarczane, 455
gosowanie, 325
granice, 342
izolacja, 300, 328, 329
jawne programowanie, 332
limit czasu, 330, 331
lokalne, 315
niezawodno, 305
oddzielone, 458
odtwarzane, 456, 457, 458
otoczenia, 314
propagacja, 304, 318
protokoy, 308
protokó dwufazowego zatwierdzania, 303,

304, 308

przepyw a kontrakt operacji, 306
przepyw a wizania, 305
przerwane, 298
przerywanie, 328
rozproszone, 303, 315, 316
spójno, 300
trwao, 300
tryby, 318, 319, 320, 321, 322, 323, 324, 325
wtpliwe, 298
wewntrzprocesowe, 365
waciwoci, 299
wspóbiene, 353, 354
wywoania asynchroniczne, 443
zakoczenie, 325
zamykanie na zakoczenie sesji, 354
zarzdzanie, 301, 302
zarzdzanie przepywem, 334
zasoby transakcyjne, 299
zatwierdzone, 298

TransferMode.Streamed, 257
TransferMode.StreamedResponse, 257
transport reliability, Patrz niezawodno

transportu

transport scheme, Patrz mechanizm transportu
TransportClientCredentialType, 622
TransportProtection, 603
tryb hybrydowy, 593, 594, 595
tryb przekazywania, 593, 594
tryb przesyania strumieniowego, 256
tryb sesji prywatnej, 185
typy

bezpieczestwo, 246
generyczne, 166
wyliczeniowe, 164

UDP, 685
Universal Resource Identifier, Patrz URI
uniwersalny mechanizm przechwytywania, 765,

775

UnknownExceptionAction, 266
URI, 33
UseSynchronizationContext, 398
using, 265
usugi, 30, 31, 656

ACS, 585
adresy, 32, 33
aktywowane przez wywoania, 178, 179, 180,

181, 182, 183, 184, 245

bezstanowe, 182
buforowane, 608
dziennika, 285

Poleć książkę

Kup książkę

Skorowidz

_ 821

granice wykonywania, 31
in-proc, 40
klient, 31
kolejkowane, 445, 787

sesyjne, 462, 464
typu per-call, 460, 462

kontrakty, 35, 103, 110, 113
lokalne, 30
metadane, 31, 63
obcienie, 224
przekazywania, 584
sesyjne, 177, 185, 233, 246, 386

typu per-session, 353

singletonowe, 177, 193, 197, 246, 386, 465

inicjalizacja, 194

stanowe, 182
wiadome stanu, 341, 342

typu per-session, 352

transakcyjne, 316

typu per-call, 344, 345, 346
typu per-session, 347

trwae, 205, 206, 216, 359

tryby zarzdzania instancjami, 205

tryby wspóbienoci, 378
typu per-call, 385
zarzdzanie stanem, 341
zdalne, 30
zorientowanie na usugi, 30

uwierzytelnianie, 501, 543, 551, 555, 561, 562

brak, 501
certyfikat X509, 502
nazwa uytkownika i haso, 502
token, 502
w magistrali usug, 621, 622, 623, 627
Windows, 502
wasny mechanizm, 502

versioning round-trip, Patrz wersjonowanie

dwukierunkowe

WaitAll(), 434
WaitOne(), 433
warstwa transportowa, 96
WAS, 45
wtki

powinowactwo, 413
robocze, 42

WCF, 29, 30

architektura, 89, 90
biblioteki usug, 89

host testowy, 73
klient testowy, 87, 88
komunikacja pomidzy rónymi

komputerami, 32

komunikacja w obrbie jednego komputera, 32
mechanizmy komunikacji, 33
standard kodowania usug, 779
wskazówki projektowe, 779, 780

WCF Service Application, projekt, 89
WCF Service Library, projekt, 89
WcfSvcHost, 73, 74, 88
WcfTestClient, 87, 88, 89
WcfWrapper, 95
Web Services Description Language, Patrz WSDL
Web.Config, 40
WebHttpBinding, 54
wersjonowanie, 158, 161

brakujce skadowe, 159
dwukierunkowe, 162, 163
nowe skadowe, 158
scenariusze, 158

wiadomoci, kolejno dostarczania, 101
wizania, 49, 50, 99

dodatkowe, 53
domylne, 58
format, 51
integracyjne MSMQ, 54
IPC, 51, 102
kodowanie, 51
konfiguracja, 57, 61
kontekstowe, 53
MSMQ, 51
podstawowe, 50
podwójne WS, 53
równorzdnej sieci, 53
wiadome transakcji, 304
TCP, 51
uywanie, 54
WS, 51
WS 2007, 54
wybór, 52
zarzdzane WS, 54
zarzdzane WS 2007, 54

wielobieno, 383

zastosowanie, 383

Windows Activation Service, Patrz WAS
Windows Azure AppFabric Service Bus, 585, 586
Windows Communication Foundation, Patrz WCF
Windows Server AppFabric, 46, 47
WindowsIdentity, 521, 523
worker threads, Patrz wtki robocze
workflow, Patrz przepyw pracy
Workflow Service Application, projekt, 89
WS2007FederationHttpBinding, 54

Poleć książkę

Kup książkę

822

Skorowidz

WS2007HttpBinding, 54
WSAT, Patrz protokó WS-Atomic Transaction
WSDL, 31
WSDualHttpBinding, 53, 237
WSFederationBinding, 54
WSHttpBinding, 51, 99, 100, 496, 505, 507, 508, 538

bezpieczestwo, 539

WSHttpContextBinding, 53, 513
wspóbieno, 386

a instancje, 377
wtek interfejsu uytkownika, 406, 408
zarzdzanie, 377, 406, 423, 466, 786
zasoby, 387

wydawca, 252, 253, 734, 761

kolejkowany, 750

wyjtki, 261, 266

diagnozowanie, 275
operacje jednokierunkowe, 234
promocja, 283
wyodrbnianie, 276

wywoania, 782
wywoania asynchroniczne, 427, 429, 430

a sesje transportowe, 432
kontra synchroniczne, 443, 444
przy uycie porednika, 429
transakcje, 443
wymagania, 427

wywoania jednokierunkowe, 308
wywoania kolejkowane, 446

a transakcje, 457
architektura, 447
kontra poczone, 481

wywoania synchroniczne, limity czasu, 442
wywoania zwrotne, 236, 371

a bezpieczestwo klientów, 418
a metody wielobiene, 384
bezpieczestwo w intranecie, 536
bdy, 278
diagnozowanie, 280
dopeniajce, 434, 435, 436, 437
dupleksowe, 595, 596, 733
gosowanie, 373
hierarchia kontraktów, 251
kontekst synchronizacji, 420, 421, 424
obsuga po stronie klienta, 238
po stronie usugi, 241
powinowactwo wtków, 426
rozszerzenia obsugujce bdy, 293
transakcyjne, 373
tryby transakcji, 371
w trybie ConcurrencyMode.Multiple, 419
w trybie ConcurrencyMode.Reentrant, 420
w trybie ConcurrencyMode.Single, 419