Page 1


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.

• Kup książkę • Poleć książkę • Oceń książkę

• Księgarnia internetowa • Lubię to! » Nasza społeczność


Spis treci

Przedmowa ............................................................................................................................. 15 Sowo wstpne ....................................................................................................................... 19 1. Podstawy WCF .............................................................................................................29 Czym jest WCF? Usugi Granice wykonywania usugi WCF i widoczno lokalizacji Adresy Adresy TCP Adresy HTTP Adresy IPC Adresy MSMQ Adresy magistrali usug Kontrakty Kontrakt usugi Hosting Hosting na IIS 5/6 Hosting wasny Hosting WAS Niestandardowy hosting na IIS/WAS Pakiet usug AppFabric dla systemu Windows Server Wybór hosta Wizania Podstawowe wizania Wybór wizania Dodatkowe rodzaje wiza Uywanie wizania Punkty kocowe Konfiguracja punktów kocowych — plik konfiguracyjny Konfiguracja punktów kocowych z poziomu programu Domylne punkty kocowe

29 30 31 31 32 33 34 34 34 35 35 35 39 39 40 45 46 46 48 49 50 52 53 54 55 56 60 61

5

Kup książkę

Poleć książkę


Wymiana metadanych Udostpnianie metadanych przez HTTP-GET Punkt wymiany metadanych Narzdzie Metadata Explorer Wicej o konfiguracji zachowa Programowanie po stronie klienta Generowanie obiektu porednika Konfiguracja klienta z poziomu pliku konfiguracyjnego Konfiguracja klienta z poziomu programu Klient testowy dostarczany przez WCF Konfiguracja z poziomu programu a plik konfiguracyjny Architektura WCF Architektura hosta Kanay Klasa InProcFactory Sesje warstwy transportowej Sesja transportowa i wizania Przerwanie sesji transportowej Niezawodno Wizania, niezawodno i kolejno wiadomoci Konfiguracja niezawodnoci Zachowanie kolejnoci dostarczania wiadomoci

63 64 67 72 74 76 76 81 86 87 89 89 91 92 93 96 97 97 98 99 100 101

2. Kontrakty usug ......................................................................................................... 103 Przecianie metod Dziedziczenie kontraktów Hierarchia kontraktów po stronie klienta Projektowanie oraz faktoryzacja kontraktów usug Faktoryzacja kontraktów Metryki faktoryzacji Kwerendy (przeszukiwanie metadanych) Programowe przetwarzanie metadanych Klasa MetadataHelper

103 105 106 110 110 112 114 114 116

3. Kontrakty danych .......................................................................................................121 Serializacja Serializacja w .NET Formatery WCF Serializacja kontraktów danych Atrybuty kontraktów danych Importowanie kontraktu danych Kontrakty danych i atrybut Serializable Dedukowane kontrakty danych Zoone kontrakty danych Zdarzenia zwizane z kontraktami danych Dzielone kontrakty danych 6

_

121 123 124 127 128 130 132 133 135 135 138

Spis treci

Kup książkę

Poleć książkę


Hierarchia kontraktów danych Atrybut KnownType Atrybut ServiceKnownType Wielokrotne zastosowanie atrybutu KnownType Konfiguracja akceptowanych klas pochodnych w pliku konfiguracyjnym Analizatory kontraktów danych Obiekty i interfejsy Równowano kontraktów danych Porzdek serializacji Wersjonowanie Nowe skadowe Brakujce skadowe Wersjonowanie dwukierunkowe Typy wyliczeniowe Delegaty i kontrakty danych Typy generyczne Kolekcje Konkretne kolekcje Kolekcje niestandardowe Atrybut CollectionDataContract Referencje do kolekcji Sowniki

139 139 141 143 143 144 153 155 156 158 158 159 162 164 166 166 169 170 171 172 173 174

4. Zarzdzanie instancjami ............................................................................................177 Zachowania Usugi aktywowane przez wywoania Zalety usug aktywowanych przez wywoania Konfiguracja usug aktywowanych przez wywoania Usugi aktywowane przez wywoania i sesje transportowe Projektowanie usug aktywowanych przez wywoania Wybór usug aktywowanych przez wywoania Usugi sesyjne Konfiguracja sesji prywatnych Sesje i niezawodno Identyfikator sesji Koczenie sesji Usuga singletonowa Inicjalizacja usugi singletonowej Wybór singletonu Operacje demarkacyjne Dezaktywacja instancji Konfiguracja z wartoci ReleaseInstanceMode.None Konfiguracja z wartoci ReleaseInstanceMode.BeforeCall Konfiguracja z wartoci ReleaseInstanceMode.AfterCall Konfiguracja z wartoci ReleaseInstanceMode.BeforeAndAfterCall Bezporednia dezaktywacja Stosowanie dezaktywacji instancji

177 178 179 180 181 182 184 185 185 190 191 193 193 194 197 197 200 201 201 202 203 203 204 Spis treci

Kup książkę

_

7

Poleć książkę


Usugi trwae Usugi trwae i tryby zarzdzania instancjami Identyfikatory instancji i pami trwaa Bezporednie przekazywanie identyfikatorów instancji Identyfikatory instancji w nagówkach Powizania kontekstu dla identyfikatorów instancji Automatyczne zachowanie trwae Dawienie Konfiguracja dawienia

205 205 206 207 209 211 216 222 225

5. Operacje ..................................................................................................................... 231 Operacje danie-odpowied Operacje jednokierunkowe Konfiguracja operacji jednokierunkowych Operacje jednokierunkowe i niezawodno Operacje jednokierunkowe i usugi sesyjne Operacje jednokierunkowe i wyjtki Operacje zwrotne Kontrakt wywoa zwrotnych Przygotowanie obsugi wywoa zwrotnych po stronie klienta Stosowanie wywoa zwrotnych po stronie usugi Zarzdzanie poczeniami dla wywoa zwrotnych Porednik dupleksowy i bezpieczestwo typów Fabryka kanaów dupleksowych Hierarchia kontraktów wywoa zwrotnych Zdarzenia Strumieniowe przesyanie danych Strumienie wejcia-wyjcia Strumieniowe przesyanie komunikatów i powizania Przesyanie strumieniowe i transport

231 232 232 233 233 234 236 236 238 241 244 246 249 251 252 256 256 257 258

6. Bdy .......................................................................................................................... 261 Izolacja bdów i eliminowanie zwizków Maskowanie bdów Oznaczanie wadliwego kanau Propagowanie bdów Kontrakty bdów Diagnozowanie bdów Bdy i wywoania zwrotne Rozszerzenia obsugujce bdy Udostpnianie bdu Obsuga bdu Instalacja rozszerze obsugujcych bdy Host i rozszerzenia obsugujce bdy Wywoania zwrotne i rozszerzenia obsugujce bdy

8

_

261 262 263 267 268 272 278 281 282 285 287 290 293

Spis treci

Kup książkę

Poleć książkę


7. Transakcje .................................................................................................................. 297 Problem z przywracaniem dziaania aplikacji Transakcje Zasoby transakcyjne Waciwoci transakcji Zarzdzanie transakcjami Menedery zasobów Propagacja transakcji Przepyw transakcji a wizania Przepyw transakcji a kontrakt operacji Wywoania jednokierunkowe Menedery i protokoy transakcji Protokoy i wizania Menedery transakcji Awansowanie menederów transakcji Klasa Transaction Transakcje otoczenia Transakcje lokalne a transakcje rozproszone Programowanie usug transakcyjnych Przygotowywanie otoczenia transakcji Tryby propagacji transakcji Gosowanie a zakoczenie transakcji Izolacja transakcji Limit czasu transakcji Jawne programowanie transakcji Klasa TransactionScope Zarzdzanie przepywem transakcji Klienci nieusugowi Zarzdzanie stanem usugi Granice transakcji Zarzdzanie instancjami a transakcje Usugi transakcyjne typu per-call Usugi transakcyjne typu per-session Transakcyjne usugi trwae Zachowania transakcyjne Transakcyjna usuga singletonu Transakcje a tryby instancji Wywoania zwrotne Tryby transakcji w wywoaniach zwrotnych Gosowanie w wywoaniach zwrotnych Stosowanie transakcyjnych wywoa zwrotnych

297 298 299 299 301 304 304 305 306 308 308 309 310 313 314 314 315 316 316 318 325 328 330 332 332 334 340 341 342 343 344 347 359 361 366 369 371 371 373 373

Spis treci

Kup książkę

_

9

Poleć książkę


8. Zarzdzanie wspóbienoci ................................................................................... 377 Zarzdzanie instancjami a wspóbieno Tryby wspóbienoci usug ConcurrencyMode.Single ConcurrencyMode.Multiple ConcurrencyMode.Reentrant Instancje a dostp wspóbieny Usugi typu per-call Usugi sesyjne i usugi typu singleton Zasoby i usugi Dostp a zakleszczenia Unikanie zakleszcze Kontekst synchronizacji zasobów Konteksty synchronizacji .NET Kontekst synchronizacji interfejsu uytkownika Kontekst synchronizacji usug Hostowanie w wtku interfejsu uytkownika Formularz jako usuga Wtek interfejsu uytkownika a zarzdzanie wspóbienoci Wasne konteksty synchronizacji usug Synchronizator puli wtków Powinowactwo wtków Przetwarzanie priorytetowe Wywoania zwrotne a bezpieczestwo klientów Wywoania zwrotne w trybie ConcurrencyMode.Single Wywoania zwrotne w trybie ConcurrencyMode.Multiple Wywoania zwrotne w trybie ConcurrencyMode.Reentrant Wywoania zwrotne i konteksty synchronizacji Wywoania zwrotne a kontekst synchronizacji interfejsu uytkownika Wasne konteksty synchronizacji a wywoania zwrotne Wywoania asynchroniczne Wymagania mechanizmów asynchronicznych Wywoania asynchroniczne przy uyciu porednika (proxy) Wywoania asynchroniczne Zapytania a oczekiwanie na zakoczenie Wywoania zwrotne dopeniajce Asynchroniczne operacje jednokierunkowe Asynchroniczna obsuga bdów Wywoania asynchroniczne a transakcje Wywoania synchroniczne kontra asynchroniczne

377 378 379 379 382 385 385 386 386 387 388 389 390 392 397 398 403 406 408 408 413 415 418 419 419 420 420 421 424 427 427 429 430 432 434 439 442 443 443

9. Usugi kolejkowane ...................................................................................................445 Usugi i klienty odczone Wywoania kolejkowane Architektura wywoa kolejkowanych Kontrakty kolejkowane Konfiguracja i ustawienia 10

_

445 446 447 447 448

Spis treci

Kup książkę

Poleć książkę


Transakcje Dostarczanie i odtwarzanie Transakcyjne ustawienia usugi Kolejki nietransakcyjne Zarzdzanie instancjami Usugi kolejkowane typu per-call Kolejkowane usugi sesyjne Usuga singleton Zarzdzanie wspóbienoci Kontrola przepustowoci Bdy dostarczania Kolejka utraconych komunikatów Czas ycia Konfiguracja kolejki odrzuconych komunikatów Przetwarzanie kolejki odrzuconych komunikatów Bdy odtwarzania Komunikaty trujce Obsuga komunikatów trujcych w MSMQ 4.0 Obsuga komunikatów trujcych w MSMQ 3.0 Wywoania kolejkowane kontra poczone Wymaganie kolejkowania Usuga odpowiedzi Tworzenie kontraktu usugi odpowiedzi Programowanie po stronie klienta Programowanie kolejkowane po stronie usugi Programowanie odpowiedzi po stronie usugi Transakcje Mostek HTTP Projektowanie mostka Konfiguracja transakcji Konfiguracja po stronie usugi Konfiguracja po stronie klienta

454 455 456 459 460 460 462 465 466 467 467 469 469 470 471 475 476 477 480 481 483 484 485 488 491 492 493 496 496 497 498 499

10. Bezpieczestwo ......................................................................................................... 501 Uwierzytelnianie Autoryzacja Bezpieczestwo transferu danych Tryby bezpieczestwa transferu danych Konfiguracja trybu bezpieczestwa transferu danych Tryb Transport a powiadczenia Tryb Komunikat a powiadczenia Zarzdzanie tosamoci Polityka ogólna Analiza przypadków uycia

501 502 503 503 505 507 508 509 509 510

Spis treci

Kup książkę

_

11

Poleć książkę


Aplikacja intranetowa Zabezpieczanie wiza intranetowych Ograniczanie ochrony komunikatów Uwierzytelnianie Tosamoci Kontekst bezpieczestwa wywoa Personifikacja Autoryzacja Zarzdzanie tosamoci Wywoania zwrotne Aplikacja internetowa Zabezpieczanie wiza internetowych Ochrona komunikatów Uwierzytelnianie Stosowanie powiadcze systemu Windows Stosowanie dostawców ASP.NET Zarzdzanie tosamoci Aplikacja biznesowa Zabezpieczanie wiza w scenariuszu B2B Uwierzytelnianie Autoryzacja Zarzdzanie tosamoci Konfiguracja bezpieczestwa hosta Aplikacja o dostpie anonimowym Zabezpieczanie anonimowych wiza Uwierzytelnianie Autoryzacja Zarzdzanie tosamoci Wywoania zwrotne Aplikacja bez zabezpiecze Odbezpieczanie wiza Uwierzytelnianie Autoryzacja Zarzdzanie tosamoci Wywoania zwrotne Podsumowanie scenariuszy Deklaratywny framework bezpieczestwa Atrybut SecurityBehavior Deklaratywne bezpieczestwo po stronie hosta Deklaratywne bezpieczestwo po stronie klienta Audyt bezpieczestwa Konfigurowanie audytów bezpieczestwa Deklaratywne bezpieczestwo audytów

12

_

510 511 517 518 520 521 523 530 535 536 537 537 539 543 545 546 554 554 554 555 557 559 559 559 560 561 561 561 561 562 562 562 562 562 563 563 563 564 571 572 578 579 581

Spis treci

Kup książkę

Poleć książkę


11. Magistrala usug ........................................................................................................583 Czym jest usuga przekazywania? Magistrala Windows Azure AppFabric Service Bus Programowanie magistrali usug Adres usugi przekazywania Rejestr magistrali usug Eksplorator magistrali usug Powizania magistrali usug Powizanie przekazywania TCP Powizanie przekazywania WS 2007 Jednokierunkowe powizanie przekazywania Powizanie przekazywania zdarze Chmura jako strona przechwytujca wywoania Bufory magistrali usug Bufory kontra kolejki Praca z buforami Wysyanie i otrzymywanie komunikatów Usugi buforowane Usuga odpowiedzi Uwierzytelnianie w magistrali usug Konfiguracja uwierzytelniania Uwierzytelnianie z tajnym kluczem wspódzielonym Brak uwierzytelniania Magistrala usug jako ródo metadanych Bezpieczestwo transferu Bezpieczestwo na poziomie transportu Bezpieczestwo na poziomie komunikatów Powizanie przekazywania TCP i bezpieczestwo transferu Powizanie przekazywania WS i bezpieczestwo transferu Jednokierunkowe powizanie przekazywania i bezpieczestwo transferu Powizania i tryby transferu Usprawnianie zabezpiecze transferu

584 585 586 586 589 590 591 591 595 596 597 599 600 600 601 607 608 617 621 622 623 627 628 630 631 632 633 639 640 641 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 Spis treci

Kup książkę

_

13

Poleć książkę


14

_

Spis treci

Kup książkę

Poleć książkę


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, trwaoci, 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 skalowalnych i spójnych aplikacji. Technologia WCF obsuguje trzy rodzaje aktywacji instancji: przydzielanie (i niszczenie) usug przez wywoania, gdzie kade danie klienta powoduje utworzenie 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 definiuje 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”, pa dziernik 2008).

177

Kup książkę

Poleć książkę


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 rozszerzenie 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 zachowa wpywajcych tylko na implementacj okrelonej operacji. Atrybutu OperationBehavior mona uy tylko dla metody implementujcej operacj kontraktu, nigdy dla definicji tej operacji w samym kontrakcie. Praktyczne zastosowania atrybutu OperationBehavior zostan pokazane 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, poniewa 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 sposoby (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 wyjaniono w poniszych punktach (wszystkie te kroki pokazano te na rysunku 4.1): 178

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


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 wywoan 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. Wyobra my 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 dziaania aplikacji klienckiej. Skalowalno klasycznego modelu klient-serwer jest o tyle trudna, e aplikacje klienckie mog utrzymywa swoje obiekty bardzo dugo, mimo e w rzeczywistoci 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 kademu klientowi jest przydzielany osobny obiekt, te cenne i (lub) ograniczone zasoby s zajmowane przez dugi czas, co prdzej czy pó niej musi doprowadzi do ich wyczerpania.

Usugi aktywowane przez wywoania

Kup książkę

_

179

Poleć książkę


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 systemów ten odsetek wzrasta do 3%). Oznacza to, e jeli system jest w stanie obsuy sto kosztownych 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. Podobnie uzyskiwanie dostpu do zasobów jest odkadane do momentu, w którym te zasoby rzeczywicie s potrzebne klientowi. Naley pamita, e wielokrotne tworzenie i niszczenia instancji po stronie usugi bez zamykania poczenia z klientem (a konkretnie z porednikiem po stronie klienta) jest nieporównanie mniej kosztowne ni wielokrotne tworzenie zarówno instancji, jak i poczenia. Drug wan zalet tego rozwizania jest zgodno z zasobami transakcyjnymi i technikami programowania transakcyjnego (patrz rozdzia 7.), poniewa przydzielanie instancji usugi i niezbdnych zasobów osobno dla kadego wywoania uatwia zapewnianie spójnoci stanu tych instancji. 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 {

180

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


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 okrelonego 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 wywoania. Jeli sesje poziomu transportowego nie s stosowane, usuga — o czym za chwil si przekonamy — zawsze, niezalenie od konfiguracji zachowuje si tak, jakby bya aktywowana przez wywoania. Jeli usuga aktywowana przez wywoania dysponuje sesj transportow, komunikacja z klientem 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 wywoania w sytuacji, gdy te usugi skonfigurowano z myl o dostpie jednowtkowym (zgodnie z domylnymi ustawieniami rodowiska WCF — patrz rozdzia 8.). Sesja transportowa wymusza 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 Usugi aktywowane przez wywoania

Kup książkę

_

181

Poleć książkę


WCF nie blokuje dziaania klienta w czasie zwalniania instancji usugi. Jeli jednak w czasie wykonywania metody Dispose() klient wygeneruje kolejne wywoanie, dostp do nowej instancji 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 wykonane 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 dowolnego 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 kolejnych wywoa w ogóle nie byaby potrzebna. Wanie istnienie stanu, a konkretnie kosztownego stanu obejmujcego zasoby, decyduje o potrzebie stosowania trybu aktywacji przez wywoania. 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 podczas 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 porzdkowana 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.

182

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


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 zapisania 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 wykonywane w tle adne dodatkowe czynnoci). Poniewa obiekt jest usuwany zaraz po zakoczeniu 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ównowaenia obcie (pod warunkiem e repozytorium stanów ma posta globalnego zasobu dostpnego dla wszystkich komputerów). Mechanizm równowaenia obcie moe kierowa wywoania na róne serwery, poniewa kada usuga aktywowana przez wywoania moe zrealizowa wywoanie po uzyskaniu stanu odpowiedniej instancji.

Usugi aktywowane przez wywoania

Kup książkę

_

183

Poleć książkę


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 skalowalnoci. W pewnych przypadkach najlepszym rozwizaniem jest profilowanie systemu i zaprojektowanie 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ó implementacji, 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(), spowoduje 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 skalowalnoci, 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 184

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


o radzeniu sobie z minimalnym zakadanym obcieniem. Nie chcielibymy przecie wchodzi 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 aktywowanych 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 pozostaych instancji). Tak utworzona instancja zwykle pozostaje aktywna do momentu, w którym klient nie bdzie jej potrzebowa. Ten tryb aktywacji (nazywany take trybem sesji prywatnej — 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 kontekstem. 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 przechowywa swój stan w pamici, zatem opisywany model programistyczny bardzo przypomina klasyczn 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. Zachowanie 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 {...}

Usugi sesyjne

Kup książkę

_

185

Poleć książkę


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 — porednik 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 instancj 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:

186

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


[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 zachowania 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 komunikatów (czyli w domylnej konfiguracji) lub z niezawodnym protokoem przesyania komunikató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 uywania 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 jednak, 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 {...}

Usugi sesyjne

Kup książkę

_

187

Poleć książkę


Podczas projektowania kontraktu sesyjnego zaleca si jawnie uy wartoci SessionMode. ´Required, zamiast liczy na zastosowanie domylnej wartoci SessionMode.Allowed. W pozostaych 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 listingu 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, dedykowan 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 powoduje, e niezalenie od swojej konfiguracji usuga zachowuje si jak usuga aktywowana przez wywoania.

188

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


Poniewa zarówno protokó TCP, jak i protokó IPC utrzymuje sesj na poziomie transportowym, 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 konfigurowania 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 skonfigurowano 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 skonfigurowanego w zachowaniu usugi. Tabela nie zawiera nieprawidowych konfiguracji, na przykad 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)]

Usugi sesyjne

Kup książkę

_

189

Poleć książkę


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 implementujcej kontrakt sesyjny powinny uywa powiza umoliwiajcych stosowanie niezawodnych sesji transportowych. Programista powinien si upewni, e uywane powizania obsuguj niezawodno 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>

190

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


<binding name = "TCPSession"> <reliableSession enabled = "true"/> </binding> </netTcpBinding> </bindings> </system.serviceModel>

Jedynym wyjtkiem od tej reguy jest powizanie IPC. Powizanie IPC nie potrzebuje protokou niezawodnego przesyania komunikatów (wszystkie wywoania i tak s wykonywane na tym samym komputerze) i samo w sobie jest traktowane jako niezawodny mechanizm transportu 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 uywa 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 wywoa zwrotnych, tworzenia nagówków komunikatów, zarzdzania transakcjami, bezpieczestwa, dostpu do hosta oraz dostpu do obiektu reprezentujcego sam kontekst wykonywania. Kada operacja wykonywana przez usug ma swój kontekst wywoania dostpny za porednictwem klasy OperationContext. Usuga moe uzyska referencj do kontekstu operacji waciwego 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 zwyky 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.

Usugi sesyjne

Kup książkę

_

191

Poleć książkę


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 przypadku 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 uzyskany 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 otrzymany identyfikator bdzie inny od tego dostpnego po stronie usugi. W przypadku powizania WS (przy wczonym mechanizmie niezawodnego przesyania komunikatów) identyfikator sesji bdzie mia warto null do czasu zakoczenia pierwszego wywoania (lub otwarcia porednika 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 przeciwnym razie istnieje ryzyko wystpienia wyjtku InvalidOperationException. Po otwarciu porednika klient i usuga maj dostp do tego samego, skorelowanego identyfikatora sesji. W przypadku powizania IPC klient moe uzyska dostp do waciwoci SessionId przed pierwszym wywoaniem, jednak otrzymany w ten sposób identyfikator sesji bdzie inny od tego dostpnego po stronie usugi. Podczas stosowania tego powizania najlepszym rozwizaniem jest cakowite ignorowanie identyfikatora sesji.

192

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


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 okrelonym czasie nieaktywnoci sesji transportowej.

Usuga singletonowa Usuga singletonowa (ang. singleton service) to w istocie usuga wspódzielona. Skonfigurowanie 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 (podczas 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 automatycznego 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 instancj 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 moliwo), ale zamknicie porednika tego klienta spowoduje zakoczenie tylko sesji transportowej — kontekst singletonu ani sama instancja usugi nie zostan zamknite. Jeli usuga singletonowa 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 charakter 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 dotyczce 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

Usuga singletonowa

Kup książkę

_

193

Poleć książkę


{ [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 domylnego nie jest najlepszym rozwizaniem. Na przykad inicjalizacja stanu moe wymaga wykonania 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 programista moe zdecydowa o utworzeniu singletonu przy uyciu mechanizmu spoza hosta usug rodowiska WCF. Z myl o podobnych scenariuszach rodowisko WCF umoliwia bezporednie utworzenie instancji usugi singletonowej za pomoc standardowego mechanizmu

194

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


tworzenia instancji klas w rodowisku CLR. Tak utworzon instancj mona nastpnie zainicjalizowa, 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 operacji singletonu, ma dostp do hosta za porednictwem waciwoci Host (dostpnej tylko do odczytu) kontekstu operacji:

Usuga singletonowa

Kup książkę

_

195

Poleć książkę


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 przekazanego 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;

196

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


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. Stosowanie 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, wszystkie aplikacje klienckie mog to robi jednoczenie, a generowane przez nie wywoania s obsugiwane 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 singletony 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 potrzeboway 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 pierwsze, inne musz by wywoywane jako ostatnie. Przeanalizujmy na przykad kontrakt uywany do zarzdzania zamówieniami klientów: [ServiceContract(SessionMode = SessionMode.Required)] interface IOrderManager { [OperationContract]

Operacje demarkacyjne

Kup książkę

_

197

Poleć książkę


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 wyznaczania operacji, które mog rozpoczyna bd koczy sesje (lub nie mog tego robi). Odpowiednie 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 technik mianem operacji demarkacyjnych (ang. demarcating operations). Jeli w czasie adowania usugi (lub w czasie stosowania porednika po stronie klienta) te dwie waciwoci maj przypisane 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 okreli, e dana metoda nie moe by wywoywana jako pierwsza, musi by wywoywana jako ostatnia lub powinna spenia oba te warunki jednoczenie: 198

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


[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 przekaza adnych dodatkowych wywoa do odpowiedniego porednika. Warto przy tym pamita, e klient wci ma obowizek zamknicia tego porednika.

Operacje demarkacyjne

Kup książkę

_

199

Poleć książkę


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. wspomniano, 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 okrelam mianem dezaktywacji kontekstu (ang. context deactivation). Typowym sposobem sterowania 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

200

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


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 Dezaktywacja instancji

Kup książkę

_

201

Poleć książkę


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 rzeczywicie 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 dezaktywuje instancj po wywoaniu tej metody (patrz rysunek 4.5).

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

202

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


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. Warto 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 dezaktywowana 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 oznaczonych wartoci ReleaseInstanceMode.BeforeCall lub None bd przed metodami oznaczonymi wartoci ReleaseInstanceMode.AfterCall lub None. Wyobra my sobie sytuacj, w której usuga sesyjna ma korzysta z zachowania stanowego (podobnie jak usuga aktywowana przez wywoania) 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 skonfigurowanej 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: Dezaktywacja instancji

Kup książkę

_

203

Poleć książkę


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 implementacji 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 optymalizacji — nie naley stosowa we wszystkich przypadkach. Dezaktywacja instancji wprowadza 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

204 _

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


rzeczywicie poprawi sytuacj. W razie problemów z niedostateczn skalowalnoci i przepustowoci warto skorzysta raczej z prostoty trybu aktywowania usugi przez wywoania, unikajc dezaktywacji instancji. Opisuj t technik przede wszystkim dlatego, e samo rodowisko 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 kocowymi) 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 pewnym 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 kierowania 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 dysponujc 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 komputerów, stosowanie usug trwaych dodatkowo stwarza moliwo rozdzielania wywoa pomidzy 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 przypomina zaproponowane wczeniej rozwizania dla usug aktywowanych przez wywoania, które take aktywnie zarzdzaj swoim stanem. Stosowanie usug aktywowanych przez wywoania ma

Usugi trwae

Kup książkę

_

205

Poleć książkę


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 poczenia. 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 dugotrwaych 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 moliwo 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 identyfikator 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ównywania 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-

206

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


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 pojedyncze identyfikatory. Wiele usug dodatkowo uywa klas lub struktur pomocniczych czcych 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 trwaej musi by synchronizowany i gwarantowa bezpieczestwo przetwarzania wielowtkowego. Spenienie tych warunków jest konieczne, poniewa zawarto pamici trwaej moe by jednoczenie 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 reprezentowa typ porównywalny, za parametr typu T reprezentuje stan instancji. W czasie wykonywania statyczny konstruktor klasy FileInstanceStore<ID,T> sprawdza, czy oba te typy s szeregowalne (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 sprawdzeniu, 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> {...}

Usugi trwae

Kup książkę

_

207

Poleć książkę


[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) {

208 _

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


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 identyfikator w nagówkach komunikatów. Stosowanie nagówków komunikatów jako techniki przekazywania 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 odpowiednich operacji opracowanej przeze mnie klasy pomocniczej GenericContext<H>. Usuga moe albo uywa klasy GenericContext<H> w jej oryginalnej formie, albo opakowa j w ramach dedykowanego 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) {}

Usugi trwae

Kup książkę

_ 209

Poleć książkę


// 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 przeanalizowa 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); }

210

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


// 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 niestandardowych 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 przekazywa oba te elementy do swoich poredników. W przypadku zastosowania tego samego interfejsu 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)

Usugi trwae

Kup książkę

_

211

Poleć książkę


{} // 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 identyfikator 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 porednictwem powiza kontekstu. Warto zwróci szczególn uwag na klucz identyfikatora instancji 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) {...}

212

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


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 identyfikatora 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 kontekstu, tak i warto identyfikatora instancji jest niezmienna przez cay czas ycia porednika.

Usugi trwae

Kup książkę

_

213

Poleć książkę


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; }

214

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


} // Pozostae skadowe… }

Klasa ContextManager definiuje metody GetInstanceId() i SetInstanceId(), które umoliwiaj klientowi odpowiednio odczytanie identyfikatora instancji z kontekstu i zapisanie tego identyfikatora w kontekcie. Do uzyskiwania identyfikatora usuga uywa waciwoci InstanceId (dostpnej tylko do odczytu). Klasa ContextManager w tej formie dodatkowo zapewnia bezpieczestwo 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 identyfikator pomidzy kolejnymi sesjami wspópracy aplikacji klienckiej z usug. Klient moe co prawda uy klasy ContextClientBase<T> do przekazania standardowego identyfikatora instancji (jak na listingu 4.13), jednak lepszym rozwizaniem jest wykorzystanie wbudowanej 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) {}

Usugi trwae

Kup książkę

_

215

Poleć książkę


// 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. Powtarzalno tych dziaa oznacza, e rodowisko WCF moe je zautomatyzowa, serializujc i deserializujc 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 deserializacji) 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.

216

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


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 wymagajcych 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 dezaktywuje kontekst po kadym wywoaniu). Co wicej, usuga musi stosowa jeden ze zwizków kontekstu dla kadego punktu kocowego, aby byo moliwe stosowanie standardowego identyfikatora instancji. Sam kontrakt musi dopuszcza lub wymusza stosowanie sesji transportowej (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 rodowisku 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 usunie 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 — wystarczy przypisa warto false waciwoci CanCreateInstance. Kod z listingu 4.18 demonstruje uycie waciwoci CompletesInstance dla operacji MemoryClear() usugi kalkulatora. Usugi trwae

Kup książkę

_

217

Poleć książkę


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 kontekstu 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 tworzenie 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);

218

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


} 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 wyczyszczeniu 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 skonstruowany 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 przypadku 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.

Usugi trwae

Kup książkę

_

219

Poleć książkę


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 projektowy mostu (ang. bridge) w postaci modelu dostawcy — dziki temu programista moe przekazywa informacje o pamici stanów niezalenie od wspomnianego atrybutu. Oznacza to, e atrybut DurableService jest oddzielony od pamici stanów, dziki czemu istnieje moliwo stosowania mechanizmu automatycznego zachowania trwaego w przypadku pamici zapewniajcych 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 abstrakcyjnej 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 public public public

abstract abstract abstract abstract

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

// Pozostae skadowe… }

Najbardziej popularnym sposobem wskazywania fabryki dostawców trwaoci jest umieszczanie odpowiednich zapisów w formie zachowania usugi w pliku konfiguracyjnym hosta i odwoywanie 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.

220

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


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>. Konstruktor 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 konfiguracyjnym 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 przykad 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 ustawieniami domylnymi odpowiednie skrypty instalacyjne tej bazy danych mona znale  w katalogu 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 zdefiniowania acucha poczenia:

Usugi trwae

Kup książkę

_

221

Poleć książkę


<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,

222

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


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 przyczyn tego zachowania wykraczaaby poza zakres tematyczny tej ksiki (wymagaaby analizy teorii kolejkowania i kosztów zwizanych z zarzdzaniem zasobami). To niepodane, nieelastyczne 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 wywoujce, które powoduj skokowy wzrost obcienia, zostay obsuone, system co prawda dziaaby 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 dwukrotnego 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 obcienia), ale system jako cao bdzie dziaa prawidowo. Dawienie nie sprawdza si w sytuacjach, 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 problemu na pó niej, prowadzc ostatecznie do wyczerpania limitów czasowych po stronie klientów. Taki system naley od podstaw zaprojektowa z myl o obsudze wikszego obcienia.

Dawienie

Kup książkę

_

223

Poleć książkę


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 rozdzielajcymi 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 klienckie mona ograniczy, okrelajc maksymaln dopuszczaln liczb równoczesnych wywoa. 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 wszystkie 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 szesnastokrotnoci 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 uniezalenienie od dwóch pozostaych waciwoci. Sposób odwzorowywania instancji na konteksty 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 aktywnych instancji i czn liczb wspóbienych sesji. W przypadku stosowania mechanizmu dezaktywacji instancji liczba instancji moe by duo mniejsza ni liczba kontekstów, 224 _

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


a mimo to aplikacje klienckie bd blokowane w razie osignicia przez liczb kontekstów maksymalnej liczby jednoczenie istniejcych instancji. W przypadku usugi aktywowanej 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>

Dawienie

Kup książkę

_

225

Poleć książkę


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 ustawie 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 wszystkie 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.

226

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


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 automatyzujcy 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 zachowanie 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 dawienia 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 parametrów dawienia:

Dawienie

Kup książkę

_

227

Poleć książkę


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 udostpnia 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;

228

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


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 waciwoci 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.

Dawienie

Kup książkę

_

229

Poleć książkę


230

_

Rozdzia 4. Zarzdzanie instancjami

Kup książkę

Poleć książkę


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

813

Kup książkę

Poleć książkę


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

814

_

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

Skorowidz

Kup książkę

Poleć książkę


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

Skorowidz

Kup książkę

_

815

Poleć książkę


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 816

_

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

Skorowidz

Kup książkę

Poleć książkę


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

Skorowidz

Kup książkę

_

817

Poleć książkę


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

818

_

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

Skorowidz

Kup książkę

Poleć książkę


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

Skorowidz

Kup książkę

_

819

Poleć książkę


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 820 _

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

Skorowidz

Kup książkę

Poleć książkę


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

Skorowidz

Kup książkę

_

821

Poleć książkę


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

822

_

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

Skorowidz

Kup książkę

Poleć książkę


Programowanie us ug WCF  

Jeżeli podjąłeś decyzję, że Twoja kolejna aplikacja będzie wspierała WCF, to wybierając tę książkę, nie mogłeś trafić lepiej. &#8222;Program...

Advertisement