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.
5
Spis treci
Przedmowa ............................................................................................................................. 15
Sowo wstpne ....................................................................................................................... 19
1. Podstawy WCF .............................................................................................................29
Czym jest WCF?
29
Usugi
30
Granice wykonywania usugi
31
WCF i widoczno lokalizacji
31
Adresy
32
Adresy TCP
33
Adresy HTTP
34
Adresy IPC
34
Adresy MSMQ
34
Adresy magistrali usug
35
Kontrakty
35
Kontrakt usugi
35
Hosting
39
Hosting na IIS 5/6
39
Hosting wasny
40
Hosting WAS
45
Niestandardowy hosting na IIS/WAS
46
Pakiet usug AppFabric dla systemu Windows Server
46
Wybór hosta
48
Wizania
49
Podstawowe wizania
50
Wybór wizania
52
Dodatkowe rodzaje wiza
53
Uywanie wizania
54
Punkty kocowe
55
Konfiguracja punktów kocowych — plik konfiguracyjny
56
Konfiguracja punktów kocowych z poziomu programu
60
Domylne punkty kocowe
61
Kup książkę
Poleć książkę
6
_
Spis treci
Wymiana metadanych
63
Udostpnianie metadanych przez HTTP-GET
64
Punkt wymiany metadanych
67
Narzdzie Metadata Explorer
72
Wicej o konfiguracji zachowa
74
Programowanie po stronie klienta
76
Generowanie obiektu porednika
76
Konfiguracja klienta z poziomu pliku konfiguracyjnego
81
Konfiguracja klienta z poziomu programu
86
Klient testowy dostarczany przez WCF
87
Konfiguracja z poziomu programu a plik konfiguracyjny
89
Architektura WCF
89
Architektura hosta
91
Kanay
92
Klasa InProcFactory
93
Sesje warstwy transportowej
96
Sesja transportowa i wizania
97
Przerwanie sesji transportowej
97
Niezawodno 98
Wizania, niezawodno i kolejno wiadomoci
99
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
_
7
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ę
8
_
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
_
9
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ę
10
_
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
_
11
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ę
12
_
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
_
13
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ę
14
_
Spis treci
Poleć książkę
Kup książkę
177
ROZDZIA 4.
Zarzdzanie instancjami
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.
1
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
1
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
1.
Klient wywouje porednika (ang. proxy), który kieruje to wywoanie do odpowiedniej usugi.
2.
rodowisko WCF tworzy nowy kontekst z now instancj usugi i wywouje metod tej
instancji.
3.
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.
4.
Klient wywouje porednika, który kieruje to wywoanie do odpowiedniej usugi.
5.
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;
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();
// 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
PerCall
TCP, IPC
Allowed/Required
PerSession
PerSession
WS (bez zabezpiecze komunikatów i niezawodnoci)
NotAllowed/Allowed
PerCall/PerSession
PerCall
WS (z zabezpieczeniami komunikatów lub niezawodnoci)
Allowed/Required
PerSession
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
<binding name = "TCPSession">
<reliableSession enabled = "true"/>
</binding>
</netTcpBinding>
</bindings>
</system.serviceModel>
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
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
we
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
i
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
i
IsTerminating
s odpowiednio
true
i
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
ma
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
i
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
ID
musi reprezento-
wa typ porównywalny, za parametr typu
T
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;
}
}
}
[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)
{
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()
i
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()
i
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:
x
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.
x
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.
x
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).
x
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 ..."
<!-- Parametry dostawcy -->
/>
</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:
<behaviors>
<serviceBehaviors>
<behavior name = "Durable">
<persistenceProvider
type = "FilePersistenceProviderFactory,ServiceModelEx"
fileName = "MyService.bin"
/>
</behavior>
</serviceBehaviors>
</behaviors>
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
i
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
<connectionStrings>
<add name = "DurableServices"
connectionString = "..."
providerName = "System.Data.SqlClient"
/>
</connectionStrings>
<behaviors>
<serviceBehaviors>
<behavior name = "Durable">
<persistenceProvider
type = "System.ServiceModel.Persistence.SqlPersistenceProviderFactory,
System.WorkflowServices,Version=4.0.0.0,Culture=neutral,
PublicKeyToken=31bf3856ad364e35"
connectionStringName = "DurableServices"
/>
</behavior>
</serviceBehaviors>
</behaviors>
Istnieje te moliwo wymuszenia na rodowisku WCF serializacji instancji w formie tekstowej
(zamiast domylnej serializacji binarnej) na przykad na potrzeby diagnostyczne czy analityczne:
<persistenceProvider
type = "System.ServiceModel.Persistence.SqlPersistenceProviderFactory,
System.WorkflowServices,Version=4.0.0.0,Culture=neutral,
PublicKeyToken=31bf3856ad364e35"
connectionStringName = "DurableServices"
serializeAsText = "true"
/>
Dawienie
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
A
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
B
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
C
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
D
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
E
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
F
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
G
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
H
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
I
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
K
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
L
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
M
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,
64
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
N
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
O
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
P
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
R
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
S
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
T
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
U
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
V
versioning round-trip, Patrz wersjonowanie
dwukierunkowe
W
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
w wtku interfejsu uytkownika, 422, 423
wielobieno, 242
zarzdzanie poczeniami, 244
zdarzenia, 252
wzorzec projektowy
mostu, 220
publikacji-subskrypcji, 734, 749, 750, 758
X
X509Identity, 521
XMLSerializerFormatAttribute, 133
Z
zachowania, 64, 177
domylne, 75
konfiguracja, 74
operacji, 178
transakcyjne, 361
trwae, 216
zakleszczenia, 387, 388
unikanie, 388
zapytanie-odpowied, 49
zarzdzanie instancjami, 177
zasigi, 692
stosowanie, 694
zasoby
synchronizacja, 389
transakcyjne, 299
wspóbieno, 386, 387
zdarzenia, 252, 253
deserializacja, 135, 137, 138, 160
kontrakty danych, 135
publikowanie, 598, 742
serializacja, 135, 136
zgaszanie nieznanego bdu, 272
zorientowanie na usugi, 30
zwizki transakcyjne, 357
Poleć książkę
Kup książkę
