Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00033 004322 14687895 na godz. na dobę w sumie
Programowanie usług WCF. Wydanie III - książka
Programowanie usług WCF. Wydanie III - książka
Autor: Liczba stron: 824
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-3617-4 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> inne - programowanie
Porównaj ceny (książka, ebook, audiobook).

Poznaj technologię WCF i wykorzystaj potencjał
Microsoft Azure AppFabric Service Bus

Udostępnianie usług sieciowych to już nie tylko widzimisię programistów lub projektantów - w dzisiejszych czasach to obowiązek! Dzięki temu ułatwiasz integrację innych aplikacji z Twoim produktem, ale też z łatwością korzystasz z funkcjonalności dostarczanych przez innych producentów. Najważniejsze jest jednak to, że najwięcej zyskuje Twój klient. A jego zadowolenie zapewni Ci sukces i byt na rynku!

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. 'Programowanie usług WCF' to doskonały, cieszący się ogromną popularnością przewodnik, poświęcony spójnej, jednolitej platformie firmy Microsoft, którą zaprojektowano z myślą o programowaniu aplikacji w oparciu o usługi dla systemu Windows. Jej autor Juval Löwy jest wybitnym specjalistą w dziedzinie platformy .NET i technologii WCF. W trakcie lektury poznasz architekturę technologii WCF, jej elementy składowe oraz zagadnienia związane z jej niezawodnością. Ponadto dowiesz się, jak zagwarantować bezpieczeństwo swoim usługom sieciowym, oraz sprawdzisz możliwości magistrali usług Azure AppFabric Service Bus. Wiedza, którą zdobędziesz, pozwoli Ci na tworzenie jeszcze lepszych i bardziej elastycznych projektów informatycznych. Sprawdź sam!

Najlepszy podręcznik poświęcony WCF!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

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 treļci Przedmowa ............................................................................................................................. 15 Sĥowo wstýpne ....................................................................................................................... 19 Czym jest WCF? Usäugi Adresy Granice wykonywania usäugi WCF i widocznoĈè lokalizacji Kontrakty Kontrakt usäugi Hosting Adresy TCP Adresy HTTP Adresy IPC Adresy MSMQ Adresy magistrali usäug 1. Podstawy WCF .............................................................................................................29 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 Hosting na IIS 5/6 Hosting wäasny Hosting WAS Niestandardowy hosting na IIS/WAS Pakiet usäug AppFabric dla systemu Windows Server Wybór hosta Konfiguracja punktów koþcowych — plik konfiguracyjny Konfiguracja punktów koþcowych z poziomu programu DomyĈlne punkty koþcowe Wiñzania Podstawowe wiñzania Wybór wiñzania Dodatkowe rodzaje wiñzaþ UĔywanie wiñzania Punkty koþcowe 5 Wymiana metadanych Sesja transportowa i wiñzania Przerwanie sesji transportowej NiezawodnoĈè Architektura hosta Kanaäy Klasa InProcFactory Sesje warstwy transportowej Konfiguracja z poziomu programu a plik konfiguracyjny Architektura WCF Wiñzania, niezawodnoĈè i kolejnoĈè wiadomoĈci Konfiguracja niezawodnoĈci Zachowanie kolejnoĈci dostarczania wiadomoĈci Generowanie obiektu poĈrednika Konfiguracja klienta z poziomu pliku konfiguracyjnego Konfiguracja klienta z poziomu programu Klient testowy dostarczany przez WCF Udostöpnianie metadanych przez HTTP-GET Punkt wymiany metadanych Narzödzie Metadata Explorer Wiöcej o konfiguracji zachowaþ Programowanie po stronie klienta 63 64 67 72 74 76 76 81 86 87 89 89 91 92 93 96 97 97 98 99 100 101 2. Kontrakty usĥug ......................................................................................................... 103 103 105 106 110 110 112 114 114 116 3. Kontrakty danych .......................................................................................................121 121 123 124 127 128 130 132 133 135 135 138 Importowanie kontraktu danych Kontrakty danych i atrybut Serializable Dedukowane kontrakty danych ZäoĔone kontrakty danych Zdarzenia zwiñzane z kontraktami danych Dzielone kontrakty danych Kwerendy (przeszukiwanie metadanych) Programowe przetwarzanie metadanych Klasa MetadataHelper Serializacja w .NET Formatery WCF Serializacja kontraktów danych Atrybuty kontraktów danych PrzeciñĔanie metod Dziedziczenie kontraktów Hierarchia kontraktów po stronie klienta Projektowanie oraz faktoryzacja kontraktów usäug Faktoryzacja kontraktów Metryki faktoryzacji Serializacja 6 _ Spis treļci Hierarchia kontraktów danych RównowaĔnoĈè kontraktów danych Porzñdek serializacji Wersjonowanie Nowe skäadowe Brakujñce skäadowe Wersjonowanie dwukierunkowe Typy wyliczeniowe Delegaty i kontrakty danych Typy generyczne Kolekcje Konkretne kolekcje Kolekcje niestandardowe Atrybut CollectionDataContract Referencje do kolekcji Säowniki Atrybut KnownType Atrybut ServiceKnownType Wielokrotne zastosowanie atrybutu KnownType Konfiguracja akceptowanych klas pochodnych w pliku konfiguracyjnym Analizatory kontraktów danych Obiekty i interfejsy 139 139 141 143 143 144 153 155 156 158 158 159 162 164 166 166 169 170 171 172 173 174 4. Zarzédzanie instancjami ............................................................................................177 177 178 179 180 181 182 184 185 185 190 191 193 193 194 197 197 200 201 201 202 203 203 204 Konfiguracja z wartoĈciñ ReleaseInstanceMode.None Konfiguracja z wartoĈciñ ReleaseInstanceMode.BeforeCall Konfiguracja z wartoĈciñ ReleaseInstanceMode.AfterCall Konfiguracja z wartoĈciñ ReleaseInstanceMode.BeforeAndAfterCall BezpoĈrednia dezaktywacja Stosowanie dezaktywacji instancji Zalety usäug aktywowanych przez wywoäania Konfiguracja usäug aktywowanych przez wywoäania Usäugi aktywowane przez wywoäania i sesje transportowe Projektowanie usäug aktywowanych przez wywoäania Wybór usäug aktywowanych przez wywoäania Usäugi sesyjne Konfiguracja sesji prywatnych Sesje i niezawodnoĈè Identyfikator sesji Koþczenie sesji Usäuga singletonowa Inicjalizacja usäugi singletonowej Wybór singletonu Zachowania Usäugi aktywowane przez wywoäania Operacje demarkacyjne Dezaktywacja instancji Spis treļci _ 7 Usäugi trwaäe Usäugi trwaäe i tryby zarzñdzania instancjami Identyfikatory instancji i pamiöè trwaäa BezpoĈrednie przekazywanie identyfikatorów instancji Identyfikatory instancji w nagäówkach Powiñzania kontekstu dla identyfikatorów instancji Automatyczne zachowanie trwaäe Däawienie Konfiguracja däawienia 205 205 206 207 209 211 216 222 225 Operacje Ĕñdanie-odpowiedĒ Operacje jednokierunkowe Operacje zwrotne Konfiguracja operacji jednokierunkowych Operacje jednokierunkowe i niezawodnoĈè Operacje jednokierunkowe i usäugi sesyjne Operacje jednokierunkowe i wyjñtki 5. Operacje ..................................................................................................................... 231 231 232 232 233 233 234 236 236 238 241 244 246 249 251 252 256 256 257 258 Kontrakt wywoäaþ zwrotnych Przygotowanie obsäugi wywoäaþ zwrotnych po stronie klienta Stosowanie wywoäaþ zwrotnych po stronie usäugi Zarzñdzanie poäñczeniami dla wywoäaþ zwrotnych PoĈrednik dupleksowy i bezpieczeþstwo typów Fabryka kanaäów dupleksowych Hierarchia kontraktów wywoäaþ zwrotnych Strumienie wejĈcia-wyjĈcia Strumieniowe przesyäanie komunikatów i powiñzania Przesyäanie strumieniowe i transport Zdarzenia Strumieniowe przesyäanie danych Izolacja bäödów i eliminowanie zwiñzków Maskowanie bäödów Oznaczanie wadliwego kanaäu 6. Bĥýdy .......................................................................................................................... 261 261 262 263 267 268 272 278 281 282 285 287 290 293 Udostöpnianie bäödu Obsäuga bäödu Instalacja rozszerzeþ obsäugujñcych bäödy Host i rozszerzenia obsäugujñce bäödy Wywoäania zwrotne i rozszerzenia obsäugujñce bäödy Propagowanie bäödów Kontrakty bäödów Diagnozowanie bäödów Bäödy i wywoäania zwrotne Rozszerzenia obsäugujñce bäödy 8 _ Spis treļci Problem z przywracaniem dziaäania aplikacji Transakcje Zasoby transakcyjne WäaĈciwoĈci transakcji Zarzñdzanie transakcjami MenedĔery zasobów Propagacja transakcji Klasa Transaction Transakcje otoczenia Transakcje lokalne a transakcje rozproszone Programowanie usäug transakcyjnych Przepäyw transakcji a wiñzania Przepäyw transakcji a kontrakt operacji Wywoäania jednokierunkowe MenedĔery i protokoäy transakcji Protokoäy i wiñzania MenedĔery transakcji Awansowanie menedĔerów transakcji 7. Transakcje ..................................................................................................................297 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 Zarzñdzanie instancjami a transakcje Usäugi transakcyjne typu per-call Usäugi transakcyjne typu per-session Transakcyjne usäugi trwaäe Zachowania transakcyjne Transakcyjna usäuga singletonu Transakcje a tryby instancji Przygotowywanie otoczenia transakcji Tryby propagacji transakcji Gäosowanie a zakoþczenie transakcji Izolacja transakcji Limit czasu transakcji Tryby transakcji w wywoäaniach zwrotnych Gäosowanie w wywoäaniach zwrotnych Stosowanie transakcyjnych wywoäaþ zwrotnych Jawne programowanie transakcji Klasa TransactionScope Zarzñdzanie przepäywem transakcji Klienci nieusäugowi Zarzñdzanie stanem usäugi Granice transakcji Wywoäania zwrotne Spis treļci _ 9 Zasoby i usäugi Dostöp a zakleszczenia Unikanie zakleszczeþ Wäasne konteksty synchronizacji usäug Synchronizator puli wñtków Powinowactwo wñtków Przetwarzanie priorytetowe Kontekst synchronizacji zasobów Konteksty synchronizacji .NET Kontekst synchronizacji interfejsu uĔytkownika Kontekst synchronizacji usäug Zarzñdzanie instancjami a wspóäbieĔnoĈè Tryby wspóäbieĔnoĈci usäug ConcurrencyMode.Single ConcurrencyMode.Multiple ConcurrencyMode.Reentrant Instancje a dostöp wspóäbieĔny Usäugi typu per-call Usäugi sesyjne i usäugi typu singleton Hostowanie w wñtku interfejsu uĔytkownika Formularz jako usäuga Wñtek interfejsu uĔytkownika a zarzñdzanie wspóäbieĔnoĈciñ 8. Zarzédzanie wspóĥbieŜnoļcié ................................................................................... 377 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. Usĥugi kolejkowane ...................................................................................................445 445 446 447 447 448 Wymagania mechanizmów asynchronicznych Wywoäania asynchroniczne przy uĔyciu poĈrednika (proxy) Wywoäania asynchroniczne Zapytania a oczekiwanie na zakoþczenie Wywoäania zwrotne dopeäniajñce Asynchroniczne operacje jednokierunkowe Asynchroniczna obsäuga bäödów Wywoäania asynchroniczne a transakcje Wywoäania synchroniczne kontra asynchroniczne Wywoäania zwrotne w trybie ConcurrencyMode.Single Wywoäania zwrotne w trybie ConcurrencyMode.Multiple Wywoäania zwrotne w trybie ConcurrencyMode.Reentrant Wywoäania zwrotne i konteksty synchronizacji Wywoäania zwrotne a kontekst synchronizacji interfejsu uĔytkownika Wäasne konteksty synchronizacji a wywoäania zwrotne Usäugi i klienty odäñczone Wywoäania kolejkowane Architektura wywoäaþ kolejkowanych Kontrakty kolejkowane Konfiguracja i ustawienia 10 _ Spis treļci Wywoäania zwrotne a bezpieczeþstwo klientów Wywoäania asynchroniczne Transakcje Dostarczanie i odtwarzanie Transakcyjne ustawienia usäugi Kolejki nietransakcyjne Zarzñdzanie instancjami Usäugi kolejkowane typu per-call Kolejkowane usäugi sesyjne Usäuga singleton Zarzñdzanie wspóäbieĔnoĈciñ Kontrola przepustowoĈci Bäödy dostarczania Kolejka utraconych komunikatów Czas Ĕycia Konfiguracja kolejki odrzuconych komunikatów Przetwarzanie kolejki odrzuconych komunikatów Bäödy odtwarzania Komunikaty trujñce Obsäuga komunikatów trujñcych w MSMQ 4.0 Obsäuga komunikatów trujñcych w MSMQ 3.0 Wywoäania kolejkowane kontra poäñczone Wymaganie kolejkowania Usäuga odpowiedzi Tworzenie kontraktu usäugi odpowiedzi Programowanie po stronie klienta Programowanie kolejkowane po stronie usäugi Programowanie odpowiedzi po stronie usäugi Transakcje Mostek HTTP Projektowanie mostka Konfiguracja transakcji Konfiguracja po stronie usäugi 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. Bezpieczeħstwo ......................................................................................................... 501 501 502 503 503 505 507 508 509 509 510 Tryby bezpieczeþstwa transferu danych Konfiguracja trybu bezpieczeþstwa transferu danych Tryb Transport a poĈwiadczenia Tryb Komunikat a poĈwiadczenia Uwierzytelnianie Autoryzacja Bezpieczeþstwo transferu danych Zarzñdzanie toĔsamoĈciñ Polityka ogólna Analiza przypadków uĔycia Spis treļci _ 11 Aplikacja intranetowa Zabezpieczanie wiñzaþ intranetowych Ograniczanie ochrony komunikatów Uwierzytelnianie ToĔsamoĈci Kontekst bezpieczeþstwa wywoäaþ Personifikacja Autoryzacja Zarzñdzanie toĔsamoĈciñ Wywoäania zwrotne Aplikacja internetowa Zabezpieczanie wiñzaþ internetowych Ochrona komunikatów Uwierzytelnianie Stosowanie poĈwiadczeþ systemu Windows Stosowanie dostawców ASP.NET Zarzñdzanie toĔsamoĈciñ Aplikacja biznesowa Zabezpieczanie wiñzaþ w scenariuszu B2B Uwierzytelnianie Autoryzacja Zarzñdzanie toĔsamoĈciñ Konfiguracja bezpieczeþstwa hosta Aplikacja o dostöpie anonimowym Zabezpieczanie anonimowych wiñzaþ Uwierzytelnianie Autoryzacja Zarzñdzanie toĔsamoĈciñ Wywoäania zwrotne Aplikacja bez zabezpieczeþ Odbezpieczanie wiñzaþ Uwierzytelnianie Autoryzacja Zarzñdzanie toĔsamoĈciñ Wywoäania zwrotne Podsumowanie scenariuszy Deklaratywny framework bezpieczeþstwa Atrybut SecurityBehavior Deklaratywne bezpieczeþstwo po stronie hosta Deklaratywne bezpieczeþstwo po stronie klienta Audyt bezpieczeþstwa Konfigurowanie audytów bezpieczeþstwa Deklaratywne bezpieczeþstwo audytów 12 _ Spis treļci 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 Programowanie magistrali usäug Adres usäugi przekazywania Rejestr magistrali usäug Eksplorator magistrali usäug Powiñzania magistrali usäug Powiñzanie przekazywania TCP Powiñzanie przekazywania WS 2007 Jednokierunkowe powiñzanie przekazywania Powiñzanie przekazywania zdarzeþ Czym jest usäuga przekazywania? Magistrala Windows Azure AppFabric Service Bus Chmura jako strona przechwytujñca wywoäania Bufory magistrali usäug Bufory kontra kolejki Praca z buforami Wysyäanie i otrzymywanie komunikatów Usäugi buforowane Usäuga odpowiedzi 11. Magistrala usĥug ........................................................................................................583 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 usĥug ...................................................................................647 B Nagĥówki i konteksty .................................................................................................663 C Odkrywanie ...............................................................................................................685 D Usĥuga publikacji-subskrypcji ...................................................................................733 E Uniwersalny mechanizm przechwytywania ............................................................765 F Standard kodowania usĥug WCF ............................................................................... 779 G Katalog elementów biblioteki ServiceModelEx ....................................................... 791 Bezpieczeþstwo na poziomie transportu Bezpieczeþstwo na poziomie komunikatów Powiñzanie przekazywania TCP i bezpieczeþstwo transferu Powiñzanie przekazywania WS i bezpieczeþstwo transferu Jednokierunkowe powiñzanie przekazywania i bezpieczeþstwo transferu Powiñzania i tryby transferu Usprawnianie zabezpieczeþ transferu Konfiguracja uwierzytelniania Uwierzytelnianie z tajnym kluczem wspóädzielonym Brak uwierzytelniania Magistrala usäug jako Ēródäo metadanych Uwierzytelnianie w magistrali usäug Bezpieczeþstwo transferu Skorowidz ............................................................................................................................. 813 Spis treļci _ 13 14 _ Spis treļci ROZDZIAĤ 4. Zarzédzanie instancjami Zarzñdzanie instancjami (ang. instance management) to okreĈlenie, które stosujö w kontekĈcie zbioru technik uĔywanych przez technologiö WCF do kojarzenia Ĕñdaþ klientów z instancjami usäug — technik decydujñcych o tym, która instancja usäugi obsäuguje które Ĕñdanie klienta i kiedy to robi. Zarzñdzanie instancjami jest konieczne, poniewaĔ zasadnicze róĔnice dzielñce poszczególne aplikacje w wymiarze potrzeb skalowalnoĈci, wydajnoĈci, przepustowoĈci, trwa- äoĈci, transakcji i wywoäaþ kolejkowanych w praktyce uniemoĔliwiajñ opracowanie jednego, uniwersalnego rozwiñzania. Istnieje jednak kilka klasycznych technik zarzñdzania instancjami, które moĔna z powodzeniem stosowaè w wielu roĔnych aplikacjach i które sprawdzajñ siö w najróĔniejszych scenariuszach i modelach programistycznych. WäaĈnie o tych technikach bödzie mowa w niniejszym rozdziale. Ich dobre zrozumienie jest warunkiem tworzenia skalo- walnych i spójnych aplikacji. Technologia WCF obsäuguje trzy rodzaje aktywacji instancji: przy- dzielanie (i niszczenie) usäug przez wywoäania, gdzie kaĔde Ĕñdanie klienta powoduje utworze- nie nowej instancji; przydzielanie instancji dla kaĔdego poäñczenia z klientem (w przypadku usäug sesyjnych) oraz usäugi singletonowe, w których jedna instancja usäugi jest wspóädzielona przez wszystkie aplikacje klienckie (dla wszystkich poäñczeþ i aktywacji). W tym rozdziale zostanñ omówione zalety i wady wszystkich trzech trybów zarzñdzania instancjami. Rozdziaä zawiera teĔ wskazówki, jak i kiedy najskuteczniej uĔywaè poszczególnych trybów. Omówiö teĔ kilka pokrewnych zagadnieþ, jak zachowania, konteksty, operacje demarkacyjne, dezaktywacja instancji, usäugi trwaäe czy tzw. däawienie.1 Zachowania Tryb instancji usäug jest w istocie jednym ze szczegóäowych aspektów implementacji po stronie usäugi, który w Ĕaden sposób nie powinien wpäywaè na funkcjonowanie strony klienckiej. Na potrzeby obsäugi tego i wielu innych lokalnych aspektów strony usäugi technologia WCF defi- niuje pojöcie zachowaþ (ang. behavior). Zachowanie to pewien lokalny atrybut usäugi lub klienta, który nie wpäywa na wzorce komunikacji pomiödzy tymi stronami. Klienty nie powinny zaleĔeè od zachowaþ usäug, a same zachowania nie powinny byè ujawniane w powiñzaniach usäug ani publikowanych metadanych. We wczeĈniejszych rozdziaäach mieliĈmy juĔ do czynienia z dwoma zachowaniami usäug. W rozdziale 1. uĔyto zachowaþ metadanych usäugi do zasygnalizowania 1 Ten rozdziaä zawiera fragmenty moich artykuäów zatytuäowanych 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 hostowi koniecznoĈci publikacji metadanych usäugi za poĈrednictwem Ĕñdania HTTP-GET oraz do implementacji punktu koþcowego MEX, natomiast w rozdziale 3. wykorzystano zachowanie usäugi do ignorowania rozszerzenia obiektu danych. Na podstawie przebiegu komunikacji czy wymienianych komunikatów Ĕaden klient nie moĔe stwierdziè, czy usäuga ignoruje rozsze- rzenie obiektu danych ani jak zostaäy opublikowane jej metadane. Technologia WCF definiuje dwa typy deklaratywnych zachowaþ strony usäugi opisywane przez dwa odpowiednie atrybuty. Atrybut ServiceBehaviorAttribute säuĔy do konfigurowania zachowaþ usäugi, czyli zachowaþ wpäywajñcych na jej wszystkie punkty koþcowe (kontrakty i operacje). Atrybut ServiceBehavior naleĔy stosowaè bezpoĈrednio dla klasy implementacji usäugi. Atrybut OperationBehaviorAttribute säuĔy do konfigurowania zachowaþ operacji, czyli zacho- waþ wpäywajñcych tylko na implementacjö okreĈlonej operacji. Atrybutu OperationBehavior moĔna uĔyè tylko dla metody implementujñcej operacjö kontraktu, nigdy dla definicji tej ope- racji w samym kontrakcie. Praktyczne zastosowania atrybutu OperationBehavior zostanñ poka- zane zarówno w dalszej czöĈci tego rozdziaäu, jak i w kolejnych rozdziaäach. W tym rozdziale atrybut ServiceBehavior bödzie uĔywany do konfigurowania trybu instancji usäugi. Na listingu 4.1 pokazano przykäad uĔycia tego atrybutu do zdefiniowania wäaĈciwoĈci InstanceContextMode typu wyliczeniowego InstanceContextMode. WartoĈè wyliczenia Instance ´ContextMode steruje trybem zarzñdzania instancjami stosowanym dla tej usäugi. Listing 4.1. Przykäad uĔycia 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;} // Pozostaäe skäadowe… } Typ wyliczeniowy nieprzypadkowo nazwano InstanceContextMode zamiast InstanceMode, ponie- waĔ jego wartoĈci sterujñ trybem tworzenia instancji kontekstu zarzñdzajñcego danñ instancjñ, nie trybem dziaäania samej instancji (w rozdziale 1. wspomniano, Ĕe kontekst instancji wyznacza najbardziej wewnötrzny zasiög usäugi). Okazuje siö jednak, Ĕe instancja i jej kontekst domyĈlnie sñ traktowane jako pojedyncza jednostka, zatem wspomniane wyliczenie steruje takĔe cyklem Ĕycia instancji. W dalszej czöĈci tego rozdziaäu i w kolejnych rozdziaäach omówiö moĔliwe spo- soby (i przyczyny) oddzielania obu elementów. Usĥugi aktywowane przez wywoĥania JeĈli rodzaj usäugi skonfigurowano z myĈlñ o aktywacji przez wywoäania (ang. per-call activation), instancja tej usäugi (obiekt Ĉrodowiska CLR) istnieje tylko w trakcie obsäugi wywoäania ze strony klienta. KaĔde Ĕñdanie klienta (czyli wywoäanie metody dla kontraktu WCF) otrzymuje nowñ, dedykowanñ instancjö usäugi. Dziaäanie usäugi w trybie aktywacji przez wywoäania wyja- Ĉniono w poniĔszych punktach (wszystkie te kroki pokazano teĔ na rysunku 4.1): 178 _ Rozdziaĥ 4. Zarzédzanie instancjami Rysunek 4.1. Tryb tworzenia instancji przez wywoäania 1. Klient wywoäuje poĈrednika (ang. proxy), który kieruje to wywoäanie do odpowiedniej usäugi. 2. ćrodowisko WCF tworzy nowy kontekst z nowñ instancjñ usäugi i wywoäuje metodö tej instancji. 3. JeĈli dany obiekt implementuje interfejs IDisposable, po zwróceniu sterowania przez wywo- äanñ metodö Ĉrodowisko WCF wywoäuje metodö IDisposable.Dispose() zdefiniowanñ przez ten obiekt. ćrodowisko WCF niszczy nastöpnie kontekst usäugi. 4. Klient wywoäuje poĈrednika, który kieruje to wywoäanie do odpowiedniej usäugi. 5. ćrodowisko WCF tworzy obiekt i wywoäuje odpowiedniñ metodö nowego obiektu. Jednym z najciekawszych aspektów tego trybu jest zwalnianie (niszczenie) instancji usäugi. Jak juĔ wspomniano, jeĈli usäuga obsäuguje interfejs IDisposable, Ĉrodowisko WCF automatycznie wywoäa metodö Dispose(), umoĔliwiajñc tej usäudze zwolnienie zajmowanych zasobów. Warto pamiötaè, Ĕe metoda Dispose() jest wywoäywana w tym samym wñtku co oryginalna metoda usäugi i Ĕe dysponuje kontekstem operacji (patrz dalsza czöĈè tego rozdziaäu). Po wywoäaniu metody Dispose() Ĉrodowisko WCF odäñcza instancjö usäugi od pozostaäych elementów swojej infrastruktury, co oznacza, Ĕe instancja moĔe zostaè zniszczona przez proces odzyskiwania pamiöci. Zalety usĥug aktywowanych przez wywoĥania W klasycznym modelu programowania klient-serwer implementowanym w takich jözykach jak C++ czy C# kaĔdy klient otrzymuje wäasny, dedykowany obiekt serwera. Zasadniczñ wadñ tego modelu jest niedostateczna skalowalnoĈè. WyobraĒmy sobie aplikacjö, która musi obsäuĔyè wiele aplikacji klienckich. Typowym rozwiñzaniem jest tworzenie po stronie serwera obiektu w momencie uruchamiania kaĔdej z tych aplikacji i zwalnianie go zaraz po zakoþczeniu dzia- äania aplikacji klienckiej. SkalowalnoĈè klasycznego modelu klient-serwer jest o tyle trudna, Ĕe aplikacje klienckie mogñ utrzymywaè swoje obiekty bardzo däugo, mimo Ĕe w rzeczywisto- Ĉci uĔywajñ ich przez niewielki uäamek tego czasu. Takie obiekty mogñ zajmowaè kosztowne i deficytowe zasoby, jak poäñczenia z bazami danych, porty komunikacyjne czy pliki. JeĈli kaĔ- demu klientowi jest przydzielany osobny obiekt, te cenne i (lub) ograniczone zasoby sñ zajmo- wane przez däugi czas, co prödzej czy póĒniej musi doprowadziè do ich wyczerpania. Usĥugi aktywowane przez wywoĥania _ 179 Lepszym modelem aktywacji jest przydzielanie obiektu dla klienta tylko na czas wykonywania wywoäania usäugi. W takim przypadku naleĔy utworzyè i utrzymywaè w pamiöci tylko tyle obiektów, ile wspóäbieĔnych wywoäaþ jest obsäugiwanych przez usäugö (nie tyle obiektów, ile istnieje niezamkniötych aplikacji klienckich). Z doĈwiadczenia wiem, Ĕe w typowym systemie korporacyjnym, szczególnie takim, gdzie o dziaäaniu aplikacji klienckich decydujñ uĔytkownicy, tylko 1 klientów wykonuje wspóäbieĔne wywoäania (w przypadku mocno obciñĔonych sys- temów ten odsetek wzrasta do 3 ). Oznacza to, Ĕe jeĈli system jest w stanie obsäuĔyè sto kosz- townych instancji usäugi, w typowych okolicznoĈciach moĔe wspóäpracowaè z dziesiöcioma tysiñcami klientów. Tak duĔe moĔliwoĈci systemu wynikajñ wprost z trybu aktywacji przez wywoäania. Pomiödzy wywoäaniami klient dysponuje tylko referencjñ do poĈrednika, który nie zajmuje wäaĈciwego obiektu po stronie usäugi. Oznacza to, Ĕe moĔna zwolniè kosztowne zasoby zajmowane przez instancjö usäugi na däugo przed zamkniöciem poĈrednika przez klienta. Podob- nie uzyskiwanie dostöpu do zasobów jest odkäadane do momentu, w którym te zasoby rzeczy- wiĈcie sñ potrzebne klientowi. NaleĔy pamiötaè, Ĕe wielokrotne tworzenie i niszczenia instancji po stronie usäugi bez zamy- kania poäñczenia z klientem (a konkretnie z poĈrednikiem po stronie klienta) jest nieporów- nanie mniej kosztowne niĔ wielokrotne tworzenie zarówno instancji, jak i poäñczenia. Drugñ waĔnñ zaletñ tego rozwiñzania jest zgodnoĈè z zasobami transakcyjnymi i technikami progra- mowania transakcyjnego (patrz rozdziaä 7.), poniewaĔ przydzielanie instancji usäugi i niezböd- nych zasobów osobno dla kaĔdego wywoäania uäatwia zapewnianie spójnoĈci stanu tych instan- cji. Trzeciñ zaletñ usäug aktywowanych przez wywoäania jest moĔliwoĈè stosowania tych usäug w Ĉrodowisku z kolejkowanymi, rozäñczonymi wywoäaniami (patrz rozdziaä 9.), poniewaĔ tak dziaäajñce instancje moĔna äatwo odwzorowywaè na kolejkowane komunikaty. Konfiguracja usĥug aktywowanych przez wywoĥania Aby skonfigurowaè typ usäugi aktywowanej przez wywoäania, naleĔy uĔyè atrybutu Service ´Behavior z wartoĈciñ InstanceContextMode.PerCall ustawionñ we wäaĈciwoĈci InstanceContextMode: [ServiceContract] interface IMyContract {...} [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)] class MyService : IMyContract {...} Na listingu 4.2 pokazano przykäad prostej usäugi aktywowanej przez wywoäania i jej klienta. Jak widaè w danych wynikowych tego programu, dla kaĔdego wywoäania metody ze strony klienta jest konstruowana nowa instancja usäugi. Listing 4.2. Usäuga aktywowana przez wywoäania i jej klient ///////////////////////// Kod usäugi ///////////////////// [ServiceContract] interface IMyContract { [OperationContract] void MyMethod(); } [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)] class MyService : IMyContract,IDisposable { 180 _ Rozdziaĥ 4. Zarzédzanie instancjami 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(); // MoĔliwe dane wynikowe MyService.MyService() Licznik = 1 MyService.Dispose() MyService.MyService() Licznik = 1 MyService.Dispose() Usĥugi aktywowane przez wywoĥania i sesje transportowe Stosowanie usäug aktywowanych przez wywoäania nie zaleĔy od obecnoĈci sesji transportowej (patrz rozdziaä 1.). Sesja transportowa porzñdkuje wszystkie komunikaty kierowane przez okre- Ĉlonego klienta do konkretnego kanaäu. Nawet jeĈli sesjö skonfigurowano pod kñtem aktywacji przez wywoäania, stosowanie sesji transportowej wciñĔ jest moĔliwe, tyle Ĕe kaĔde wywoäanie usäugi WCF bödzie powodowaäo utworzenie nowego kontekstu tylko na potrzeby tego wywo- äania. JeĈli sesje poziomu transportowego nie sñ stosowane, usäuga — o czym za chwilö siö prze- konamy — zawsze, niezaleĔnie od konfiguracji zachowuje siö tak, jakby byäa aktywowana przez wywoäania. JeĈli usäuga aktywowana przez wywoäania dysponuje sesjñ transportowñ, komunikacja z klien- tem jest przerywana po pewnym czasie braku aktywnoĈci tej sesji (odpowiedni limit czasowy domyĈlnie wynosi 10 minut). Po osiñgniöciu tego limitu czasowego klient nie moĔe dalej uĔywaè poĈrednika do wywoäywania operacji udostöpnianych przez usäugö aktywowanñ przez wywoäania, poniewaĔ sesja transportowa zostaäa zamkniöta. Sesje transportowe majñ najwiökszy wpäyw na dziaäanie usäug aktywowanych przez wywo- äania w sytuacji, gdy te usäugi skonfigurowano z myĈlñ o dostöpie jednowñtkowym (zgodnie z domyĈlnymi ustawieniami Ĉrodowiska WCF — patrz rozdziaä 8.). Sesja transportowa wymu- sza wówczas wykonywanie operacji w trybie blokada-krok (ang. lock-step), gdzie wywoäania od tego samego poĈrednika sñ szeregowane. Oznacza to, Ĕe nawet jeĈli jeden klient jednoczeĈnie generuje wiele wywoäaþ, wszystkie te wywoäania sñ pojedynczo, kolejno wykonywane przez róĔne instancje. Takie dziaäanie ma istotny wpäyw na proces zwalniania instancji. ćrodowisko Usĥugi aktywowane przez wywoĥania _ 181 WCF nie blokuje dziaäania klienta w czasie zwalniania instancji usäugi. JeĈli jednak w czasie wykonywania metody Dispose() klient wygeneruje kolejne wywoäanie, dostöp do nowej instan- cji i obsäuga tego wywoäania bödñ moĔliwe dopiero po zwróceniu sterowania przez metodö Dispose(). Na przykäad dane wynikowe z koþca listingu 4.2 ilustrujñ przypadek, w którym istnieje sesja transportowa. W przedstawionym scenariuszu drugie wywoäanie moĔe byè wyko- nane dopiero po zwróceniu sterowania przez metodö Dispose(). Gdyby usäuga z listingu 4.2 nie stosowaäa sesji transportowej, dane wynikowe co prawda mogäyby byè takie same, ale teĔ mogäyby pokazywaè zmienionñ kolejnoĈè wywoäaþ (w wyniku dziaäania nieblokujñcej metody Dispose()): MyService.MyService() Licznik = 1 MyService.MyService() Licznik = 1 MyService.Dispose() MyService.Dispose() Projektowanie usĥug aktywowanych przez wywoĥania Mimo Ĕe w teorii tryb aktywacji instancji przez wywoäania moĔna stosowaè dla usäug dowol- nego typu, w rzeczywistoĈci usäugö i jej kontrakt naleĔy od poczñtku projektowaè z myĈlñ o obsäudze tego trybu. Zasadniczy problem polega na tym, Ĕe klient nie wie, Ĕe w odpowiedzi na kaĔde swoje wywoäanie otrzymuje nowñ instancjö. Usäugi aktywowane przez wywoäania muszñ utrzymywaè swój stan, tzn. muszñ tak zarzñdzaè tym stanem, aby klient miaä wraĔenie istnienia ciñgäej sesji. Usäugi stanowe z natury rzeczy róĔniñ siö od usäug bezstanowych. Gdyby usäuga aktywowana przez wywoäania byäa w peäni bezstanowa, w praktyce aktywacja dla kolej- nych wywoäaþ w ogóle nie byäaby potrzebna. WäaĈnie istnienie stanu, a konkretnie kosztownego stanu obejmujñcego zasoby, decyduje o potrzebie stosowania trybu aktywacji przez wywoäa- nia. Instancja usäugi aktywowanej przez wywoäania jest tworzona bezpoĈrednio przed kaĔdym wywoäaniem metody i niszczona bezpoĈrednio po kaĔdym wywoäaniu. Oznacza to, Ĕe na poczñtku kaĔdego wywoäania obiekt powinien inicjalizowaè swój stan na podstawie wartoĈci zapisanych w jakiejĈ pamiöci, a na koþcu wywoäania powinien zapisaè swój stan w tej pamiöci. W roli pamiöci zwykle stosuje siö albo bazö danych, albo system plików, jednak równie dobrze moĔna wykorzystaè jakñĈ pamiöè ulotnñ, na przykäad zmienne statyczne. Okazuje siö jednak, Ĕe nie wszystkie elementy stanu obiektu moĔna zapisaè. JeĈli na przykäad stan obejmuje poäñczenie z bazñ danych, obiekt musi ponownie uzyskiwaè to poäñczenie pod- czas tworzenia instancji (lub na poczñtku kaĔdego wywoäania) oraz zwalniaè je po zakoþczeniu wywoäania lub we wäasnej implementacji metody IDisposable.Dispose(). Stosowanie trybu aktywacji przez wywoäania ma zasadniczy wpäyw na projekt operacji — kaĔda operacja musi otrzymywaè parametr identyfikujñcy instancjö usäugi, której stan naleĔy odtworzyè. Instancja uĔywa tego parametru do odczytania swojego stanu z pamiöci (zamiast stanu innej instancji tego samego typu). WäaĈnie dlatego pamiöè stanów zwykle jest porzñdko- wana wedäug kluczy (moĔe mieè na przykäad postaè statycznego säownika w pamiöci lub tabeli bazy danych). Parametry stanów mogñ reprezentowaè na przykäad numer konta w przypadku usäugi bankowej, numer zamówienia w przypadku usäugi przetwarzajñcej zamówienia itp. Listing 4.3 zawiera szablon implementacji usäugi aktywowanej przez wywoäania. 182 _ Rozdziaĥ 4. Zarzédzanie instancjami Listing 4.3. Implementacja usäugi aktywowanej przez wywoäania [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 wejĈciu parametr typu Param (czyli typu danych wymyĈlonego na potrzeby tego przykäadu) identyfikujñcy odpowiedniñ instancjö: public void MyMethod(Param stateIdentifier) Instancja usäugi uĔywa tego identyfikatora do uzyskania swojego stanu i jego ponownego zapi- sania na koþcu wywoäania wspomnianej metody. Elementy skäadowe stanu, które sñ wspólne dla wszystkich klientów, moĔna przydzielaè w kodzie konstruktora i zwalniaè w kodzie metody Dispose(). Tryb aktywacji przez wywoäania sprawdza siö najlepiej w sytuacji, gdy kaĔde wywoäanie metody w peäni realizuje okreĈlone zadanie (gdy po zwróceniu sterowania przez metodö nie sñ wyko- nywane w tle Ĕadne dodatkowe czynnoĈci). PoniewaĔ obiekt jest usuwany zaraz po zakoþ- czeniu wykonywania metody, nie naleĔy uruchamiaè Ĕadnych wñtków dziaäajñcych w tle ani stosowaè wywoäaþ asynchronicznych. PoniewaĔ metoda usäugi aktywowana przez wywoäania kaĔdorazowo odczytuje stan instancji z jakiejĈ pamiöci, usäugi tego typu wprost doskonale wspóäpracujñ z mechanizmami równowa- Ĕenia obciñĔeþ (pod warunkiem Ĕe repozytorium stanów ma postaè globalnego zasobu dostöp- nego dla wszystkich komputerów). Mechanizm równowaĔenia obciñĔeþ moĔe kierowaè wywo- äania na róĔne serwery, poniewaĔ kaĔda usäuga aktywowana przez wywoäania moĔe zrealizowaè wywoäanie po uzyskaniu stanu odpowiedniej instancji. Usĥugi aktywowane przez wywoĥania _ 183 Wydajnoļë usĥug aktywowanych przez wywoĥania Usäugi aktywowane przez wywoäania sñ kompromisem polegajñcym na nieznacznym spadku wydajnoĈci (z powodu dodatkowych kosztów uzyskiwania i zapisywania stanu instancji przy okazji kaĔdego wywoäania metody) na rzecz wiökszej skalowalnoĈci (dziöki przechowywaniu stanu i zwiñzanych z nim zasobów). Nie istniejñ jasne, uniwersalne reguäy, wedäug których moĔna by oceniaè, kiedy warto poĈwiöciè czöĈè wydajnoĈci w celu znacznej poprawy skalowal- noĈci. W pewnych przypadkach najlepszym rozwiñzaniem jest profilowanie systemu i zapro- jektowanie czöĈci usäug korzystajñcych z tej formy aktywacji i czöĈci usäug pracujñcych w innych trybach. Operacje czyszczenia ļrodowiska To, czy typ usäugi obsäuguje interfejs IDisposable, naleĔy traktowaè jako szczegóä implementa- cji, który w Ĕaden sposób nie wpäywa na sposób funkcjonowania klienta. Sam klient w Ĕaden sposób nie moĔe wywoäaè metody Dispose(). Podczas projektowania kontraktu dla usäugi aktywowanej przez wywoäania naleĔy unikaè definiowania operacji, których zadaniem byäoby „czyszczenie” stanu czy zwalnianie zasobów, jak w poniĔszym przykäadzie: // Tego naleĔy 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(); } } PowyĔszy projekt ma doĈè oczywistñ wadö — jeĈli klient wywoäa metodö Cleanup(), spowo- duje utworzenie nowego obiektu tylko na potrzeby wykonania tej metody. Co wiöcej, po jej zakoþczeniu Ĉrodowisko WCF wywoäa metodö IDisposable.Dispose() (jeĈli istnieje w tej usäudze), aby ponownie zwolniè zasoby i wyczyĈciè stan usäugi. Wybór usĥug aktywowanych przez wywoĥania Mimo Ĕe model programowania usäug aktywowanych przez wywoäania moĔe wydawaè siö doĈè dziwny programistom przyzwyczajonym do architektury klient-serwer, wäaĈnie ten tryb zarzñdzania instancjami sprawdza siö najlepiej w przypadku wielu usäug WCF. Przewaga usäug aktywowanych przez wywoäania polega na wiökszej skalowalnoĈci, a przynajmniej na staäej skalowalnoĈci. Podczas projektowania usäug staram siö trzymaè pewnej reguäy skalowal- noĈci, którñ nazwaäem 10X. Zgodnie z tñ reguäñ kaĔdñ usäugö naleĔy tak zaprojektowaè, aby obsäugiwaäa obciñĔenie wiöksze o co najmniej rzñd wielkoĈci od poczñtkowo sformuäowanych wymagaþ. W Ĕadnej dziedzinie inĔynierii nie projektuje siö rozwiñzaþ czy systemów z myĈlñ 184 _ Rozdziaĥ 4. Zarzédzanie instancjami o radzeniu sobie z minimalnym zakäadanym obciñĔeniem. Nie chcielibyĈmy przecieĔ wcho- dziè do budynku, którego belki stropowe mogñ podtrzymaè tylko minimalne obciñĔenie, ani korzystaè z windy, której liny mogñ utrzymaè tylko tylu pasaĔerów, dla ilu ta winda uzyskaäa atest. Dokäadnie tak samo jest w Ĉwiecie systemów informatycznych — po co projektowaè system z myĈlñ o bieĔñcym obciñĔeniu, skoro kaĔdy dodatkowy pracownik przyjmowany do firmy w celu poprawy jej wyników biznesowych bödzie powodowaä dodatkowe obciñĔenie tego systemu? Systemy informatyczne naleĔy projektowaè raczej na lata, tak aby radziäy sobie zarówno z bieĔñcym obciñĔeniem, jak i duĔo wiökszym obciñĔeniem w przyszäoĈci. KaĔdy, kto stosuje reguäö 10X, bäyskawicznie dochodzi do punktu, w którym skalowalnoĈè usäug aktywo- wanych przez wywoäania jest bezcenna. Usĥugi sesyjne ćrodowisko WCF moĔe utrzymywaè sesjö logicznñ äñczñcñ klienta z okreĈlonñ instancjñ usäugi. Klient, który tworzy nowego poĈrednika dla usäugi skonfigurowanej jako tzw. usäuga sesyjna (ang. sessionful service), otrzymuje nowñ, dedykowanñ instancjö tej usäugi (niezaleĔnñ od jej pozo- staäych instancji). Tak utworzona instancja zwykle pozostaje aktywna do momentu, w którym klient nie bödzie jej potrzebowaä. Ten tryb aktywacji (nazywany takĔe trybem sesji prywat- nej — ang. private-session mode) pod wieloma wzglödami przypomina klasyczny model klient-serwer: kaĔda sesja prywatna jest unikatowym powiñzaniem poĈrednika i zbioru kana- äów äñczñcych strony klienta i serwera z okreĈlonñ instancjñ usäugi, a konkretnie z jej kontek- stem. Tryb tworzenia instancji dla sesji prywatnych wymaga stosowania sesji transportowej (to zagadnienie zostanie omówione w dalszej czöĈci tego podrozdziaäu). PoniewaĔ instancja usäugi pozostaje w pamiöci przez caäy czas istnienia sesji, moĔe przechowy- waè swój stan w pamiöci, zatem opisywany model programistyczny bardzo przypomina kla- sycznñ architekturö klient-serwer. Oznacza to, Ĕe usäugi sesyjne sñ naraĔone na te same problemy zwiñzane ze skalowalnoĈciñ i przetwarzaniem transakcyjnym co klasyczny model klient-serwer. Z powodu kosztów utrzymywania dedykowanych instancji usäuga skonfigurowana z myĈlñ o obsäudze sesji prywatnych zwykle nie moĔe obsäugiwaè wiöcej niĔ kilkadziesiñt (w niektórych przypadkach maksymalnie sto lub dwieĈcie) jednoczeĈnie dziaäajñcych klientów. Sesja klienta jest punktem koþcowym konkretnej sesji utworzonym dla okreĈlonego poĈrednika. JeĈli wiöc klient utworzy innego poĈrednika dla tego samego lub innego punktu koþcowego, drugi poĈrednik zostanie powiñzany z nowñ instancjñ usäugi i nowñ sesjñ. Konfiguracja sesji prywatnych Istniejñ trzy elementy wspomagajñce obsäugö sesji: zachowanie, powiñzanie i kontrakt. Zacho- wanie jest wymagane do utrzymywania przez Ĉrodowisko WCF kontekstu instancji usäugi przez caäy czas trwania sesji oraz do kierowania do tego kontekstu komunikatów przysyäanych przez klienta. Konfiguracja zachowania lokalnego wymaga przypisania wartoĈci InstanceContextMode. ´PerSession do wäaĈciwoĈci InstanceContextMode atrybutu ServiceBehavior: [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)] class MyService : IMyContract {...} Usĥugi sesyjne _ 185 PoniewaĔ InstanceContextMode.PerSession jest domyĈlnñ wartoĈciñ wäaĈciwoĈci InstanceContext ´Mode, poniĔsze definicje sñ równowaĔne: class MyService : IMyContract {...} [ServiceBehavior] class MyService : IMyContract {...} [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)] class MyService : IMyContract {...} Sesja zwykle koþczy siö w momencie, w którym klient zamyka swojego poĈrednika — poĈred- nik powiadamia wówczas usäugö o zakoþczeniu bieĔñcej sesji. JeĈli usäuga obsäuguje interfejs IDisposable, metoda Dispose() zostanie wywoäana asynchronicznie wzglödem dziaäania klienta. W takim przypadku metoda Disposed() zostanie wykonana przez wñtek roboczy pozbawiony kontekstu operacji. Aby prawidäowo skojarzyè wszystkie komunikaty od okreĈlonego klienta z konkretnñ instan- cjñ usäugi, Ĉrodowisko WCF musi mieè moĔliwoĈè identyfikacji tego klienta. Jak wyjaĈniono w rozdziale 1., wäaĈnie do tego säuĔy sesja transportowa. JeĈli usäuga ma byè projektowana z myĈlñ o dziaäaniu w roli usäugi sesyjnej, musi istnieè sposób wyraĔania tego zaäoĔenia na poziomie kontraktu. Odpowiedni element kontraktu powinien wykraczaè poza ograniczenia samej usäugi, poniewaĔ takĔe Ĉrodowisko wykonawcze WCF po stronie klienta musi wiedzieè o koniecznoĈci stosowania sesji. W tym celu atrybut ServiceContract udostöpnia wäaĈciwoĈè 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;} // Pozostaäe skäadowe… } DomyĈlnñ wartoĈciñ wyliczenia SessionMode jest SessionMode.Allowed. Skonfigurowana wartoĈè typu SessionMode jest doäñczana do metadanych usäugi i prawidäowo uwzglödniana w momencie importowania metadanych kontraktu przez klienta. WartoĈè typu wyliczeniowego SessionMode nie ma nic wspólnego z sesjñ usäugi — bardziej adekwatnñ nazwñ tego typu byäaby Transport ´SessionMode, poniewaĔ dotyczy sesji transportowej, nie sesji logicznej utrzymywanej pomiödzy klientem a instancjñ usäugi. Wartoļë SessionMode.Allowed SessionMode.Allowed jest domyĈlnñ wartoĈciñ wäaĈciwoĈci SessionMode, zatem obie poniĔsze defi- nicje sñ sobie równowaĔne: 186 _ Rozdziaĥ 4. Zarzédzanie instancjami [ServiceContract] interface IMyContract {...} [ServiceContract(SessionMode = SessionMode.Allowed)] interface IMyContract {...} MoĔliwoĈè skonfigurowania kontraktu w punkcie koþcowym z wartoĈciñ SessionMode.Allowed jest obsäugiwana przez wszystkie powiñzania. Przypisanie tej wartoĈci do wäaĈciwoĈci SessionMode oznacza, Ĕe sesje transportowe sñ dopuszczalne, ale nie sñ wymagane. Ostateczny ksztaät zacho- wania jest pochodnñ konfiguracji usäugi i stosowanego powiñzania. JeĈli usäugö skonfigurowano z myĈlñ o aktywacji przez wywoäania, zachowuje siö wäaĈnie w ten sposób (patrz przykäad z listingu 4.2). JeĈli usäugö skonfigurowano z myĈlñ o aktywacji na czas trwania sesji, bödzie zachowywaäa siö jak usäuga sesyjna, pod warunkiem Ĕe uĔyte powiñzanie utrzymuje sesjö transportowñ. Na przykäad powiñzanie BasicHttpBinding nigdy nie moĔe dysponowaè sesjñ na poziomie transportowym z racji bezpoäñczeniowego charakteru protokoäu HTTP. Utrzymywanie sesji na poziomie transportowym nie jest moĔliwe takĔe w przypadku powiñzania WSHttpBinding bez mechanizmu zabezpieczania komunikatów. W obu przypadkach mimo skonfigurowania usäugi z wartoĈciñ InstanceContextMode.PerSession i kontraktu z wartoĈciñ SessionMode.Allowed usäuga bödzie zachowywaäa siö tak jak usäugi aktywowane przez wywoäania. JeĈli jednak zostanie uĔyte powiñzanie WSHttpBinding z mechanizmem zabezpieczenia komuni- katów (czyli w domyĈlnej konfiguracji) lub z niezawodnym protokoäem przesyäania komunika- tów albo powiñzanie NetTcpBinding lub NetNamedPipeBinding, usäuga bödzie zachowywaäa siö jak usäuga sesyjna. JeĈli na przykäad uĔyjemy powiñzania NetTcpBinding, tak skonfigurowana usäuga bödzie zachowywaäa siö jak usäuga sesyjna: [ServiceContract] interface IMyContract {...} class MyService : IMyContract {...} ãatwo zauwaĔyè, Ĕe w powyĔszym fragmencie wykorzystano wartoĈci domyĈlne zarówno wäaĈciwoĈci SessionMode, jak i wäaĈciwoĈci InstanceContextMode. Wartoļë SessionMode.Required WartoĈè SessionMode.Required wymusza stosowanie sesji transportowej, ale nie wymusza uĔy- wania sesji na poziomie aplikacji. Oznacza to, Ĕe nie jest moĔliwe skonfigurowanie kontraktu z wartoĈciñ SessionMode.Required dla punktu koþcowego, którego powiñzanie nie utrzymuje sesji transportowej — to ograniczenie jest sprawdzane na etapie äadowania usäugi. Okazuje siö jed- nak, Ĕe moĔna tak skonfigurowaè tö usäugö, aby byäa aktywowana przez wywoäania, czyli aby jej instancje byäy tworzone i niszczone osobno dla kaĔdego wywoäania ze strony klienta. Tylko skonfigurowanie usäugi jako usäugi sesyjnej spowoduje, Ĕe instancja usäugi bödzie istniaäa przez caäy czas trwania sesji klienta: [ServiceContract(SessionMode = SessionMode.Required)] interface IMyContract {...} class MyService : IMyContract {...} Usĥugi sesyjne _ 187 Podczas projektowania kontraktu sesyjnego zaleca siö jawnie uĔyè wartoĈci SessionMode. ´Required, zamiast liczyè na zastosowanie domyĈlnej wartoĈci SessionMode.Allowed. W pozo- staäych przykäadach usäug sesyjnych prezentowanych w tej ksiñĔce wartoĈè SessionMode. ´Required bödzie jawnie stosowana w zapisach konfiguracyjnych. Na listingu 4.4 pokazano kod tej samej usäugi i tego samego klienta co na wczeĈniejszym lis- tingu 4.2 — z tñ róĔnicñ, Ĕe tym razem kontrakt i usäugö skonfigurowano w sposób wymuszajñcy stosowanie sesji prywatnej. Jak widaè w danych wynikowych, klient dysponuje wäasnñ, dedy- kowanñ instancjñ. Listing 4.4. Usäuga sesyjna i jej klient ///////////////////////// Kod usäugi ///////////////////// [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 uniemoĔliwia stosowanie sesji transportowej, wykluczajñc — tym samym — moĔliwoĈè korzystania z sesji na poziomie aplikacji. UĔycie tej wartoĈci powo- duje, Ĕe niezaleĔnie od swojej konfiguracji usäuga zachowuje siö jak usäuga aktywowana przez wywoäania. 188 _ Rozdziaĥ 4. Zarzédzanie instancjami PoniewaĔ zarówno protokóä TCP, jak i protokóä IPC utrzymuje sesjö na poziomie transporto- wym, nie moĔna skonfigurowaè punktu koþcowego usäugi uĔywajñcego powiñzania NetTcp ´Binding lub NetNamedPipeBinding, aby udostöpniaä kontrakt oznaczony wartoĈciñ SessionMode.Not ´Allowed (odpowiednie ograniczenie jest sprawdzane na etapie äadowania usäugi). Okazuje siö jednak, Ĕe stosowanie powiñzania WSHttpBinding äñcznie z emulowanñ sesjñ transportowñ jest dopuszczalne. Aby poprawiè czytelnoĈè pisanego kodu, zachöcam do dodatkowego konfiguro- wania usäugi jako aktywowanej przez wywoäania zawsze wtedy, gdy jest stosowana wartoĈè SessionMode.NotAllowed: [ServiceContract(SessionMode = SessionMode.NotAllowed)] interface IMyContract {...} [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)] class MyService : IMyContract {...} PoniewaĔ powiñzanie BasicHttpBinding nie moĔe dysponowaè sesjñ na poziomie transportowym, punkty koþcowe uĔywajñce tego powiñzania zawsze zachowujñ siö tak, jakby ich kontrakty skon- figurowano z wartoĈciñ SessionMode.NotAllowed. Sam traktujö wartoĈè SessionMode.NotAllowed jako ustawienie przede wszystkim poprawiajñce kompletnoĈè dostöpnych rozwiñzaþ i z reguäy nie uĔywam jej w swoim kodzie. Powiézania, kontrakty i zachowanie usĥugi W tabeli 4.1 podsumowano tryby aktywowania instancji usäugi jako pochodne stosowanego powiñzania, obsäugi sesji opisanej w kontrakcie oraz trybu obsäugi kontekstu instancji skonfi- gurowanego w zachowaniu usäugi. Tabela nie zawiera nieprawidäowych konfiguracji, na przy- käad poäñczenia wartoĈci SessionMode.Required z powiñzaniem BasicHttpBinding. Tabela 4.1. Tryb aktywowania instancji jako pochodna powiñzania, konfiguracji kontraktu i zachowania usäugi Powiézanie Podstawowe TCP, IPC TCP, IPC WS (bez zabezpieczeħ komunikatów i niezawodnoļci) WS (z zabezpieczeniami komunikatów lub niezawodnoļcié) WS (z zabezpieczeniami komunikatów lub niezawodnoļcié) Tryb sesji Allowed/NotAllowed Tryb kontekstu PerCall/PerSession Tryb instancji PerCall Allowed/Required PerCall Allowed/Required PerSession PerCall PerSession NotAllowed/Allowed PerCall/PerSession PerCall Allowed/Required PerSession PerSession NotAllowed PerCall/PerSession PerCall Spójna konfiguracja JeĈli jeden kontrakt implementowany przez usäugö jest sesyjny, wszystkie pozostaäe kontrakty takĔe powinny byè sesyjne. NaleĔy unikaè mieszania kontraktów aktywowanych wywoäaniami z kontraktami sesyjnymi dla tego samego typu usäugi sesyjnej (mimo Ĕe Ĉrodowisko WCF dopuszcza takñ moĔliwoĈè): [ServiceContract(SessionMode = SessionMode.Required)] interface IMyContract {...} [ServiceContract(SessionMode = SessionMode.NotAllowed)] Usĥugi sesyjne _ 189 interface IMyOtherContract {...} // Tego naleĔy unikaè class MyService : IMyContract,IMyOtherContract {...} Powód takiego rozwiñzania jest doĈè oczywisty — usäugi aktywowane przez wywoäania muszñ bezpoĈrednio zarzñdzaè swoim stanem, zaĈ usäugi sesyjne sñ zwolnione z tego obowiñzku. Mimo Ĕe przytoczona para kontraktów bödzie dostöpna w dwóch róĔnych punktach koþcowych i moĔe byè niezaleĔnie wykorzystywana przez dwie róĔne aplikacje klienckie, äñczne stosowanie dwóch trybów wymaga stosowania nieporöcznych zabiegów implementacyjnych w klasie usäugi. Sesje i niezawodnoļë Sesja äñczñca klienta z instancjñ usäugi moĔe byè niezawodna tylko na tyle, na ile jest niezawodna stosowana sesja transportowa. Oznacza to, Ĕe wszystkie punkty koþcowe usäugi implementu- jñcej kontrakt sesyjny powinny uĔywaè powiñzaþ umoĔliwiajñcych stosowanie niezawodnych sesji transportowych. Programista powinien siö upewniè, Ĕe uĔywane powiñzania obsäugujñ nie- zawodnoĈè i Ĕe ta niezawodnoĈè jest wprost zadeklarowana zarówno po stronie klienta, jak i po stronie uĔytkownika (programowo lub administracyjnie — patrz listing 4.5). Listing 4.5. Wäñczanie niezawodnoĈci dla usäug 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. Zarzédzanie instancjami binding name = TCPSession reliableSession enabled = true / /binding /netTcpBinding /bindings /system.serviceModel Jedynym wyjñtkiem od tej reguäy jest powiñzanie IPC. Powiñzanie IPC nie potrzebuje proto- koäu niezawodnego przesyäania komunikatów (wszystkie wywoäania i tak sñ wykonywane na tym samym komputerze) i samo w sobie jest traktowane jako niezawodny mechanizm trans- portu danych. Podobnie jak niezawodna sesja transportowa, takĔe dostarczanie komunikatów w oryginalnej kolejnoĈci jest opcjonalne, a Ĉrodowisko WCF prawidäowo utrzymuje sesjö nawet w przypadku wyäñczenia porzñdkowania komunikatów. Obsäuga sesji aplikacji powoduje jednak, Ĕe klient usäugi sesyjnej z reguäy oczekuje zgodnoĈci kolejnoĈci dostarczania komunikatów z kolejnoĈciñ ich wysyäania. Dostarczanie komunikatów w oryginalnej kolejnoĈci na szczöĈcie jest domyĈlnie wäñczone, jeĈli tylko wäñczono niezawodne sesje transportowe, zatem nie sñ potrzebne Ĕadne dodatkowe ustawienia. Identyfikator sesji KaĔda sesja ma unikatowy identyfikator dostöpny zarówno dla klienta, jak i dla usäugi. Identyfikator sesji to w duĔej czöĈci identyfikator GUID, którego moĔna z powodzeniem uĔy- waè podczas rejestrowania zdarzeþ i diagnozowania systemu. Usäuga moĔe uzyskaè dostöp do identyfikatora sesji za poĈrednictwem tzw. kontekstu wywoäania operacji (ang. operation call context), czyli zbioru wäaĈciwoĈci (w tym identyfikatora sesji) uĔywanych na potrzeby wywo- äaþ zwrotnych, tworzenia nagäówków komunikatów, zarzñdzania transakcjami, bezpieczeþ- stwa, dostöpu do hosta oraz dostöpu do obiektu reprezentujñcego sam kontekst wykonywania. KaĔda operacja wykonywana przez usäugö ma swój kontekst wywoäania dostöpny za poĈred- nictwem klasy OperationContext. Usäuga moĔe uzyskaè referencjö do kontekstu operacji wäaĈci- wego bieĔñcej metodzie za poĈrednictwem metody statycznej Current klasy OperationContext: public sealed class OperationContext : ... { public static OperationContext Current {get;set;} public string SessionId {get;} } Aby uzyskaè dostöp do identyfikatora sesji, usäuga musi odczytaè wartoĈè wäaĈciwoĈci SessionId, która zwraca (w formie äaþcucha) identyfikator niemal identyczny jak identyfikator GUID. W przypadku zawodnego powiñzania TCP po identyfikatorze GUID nastöpuje zwy- käy 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 dostöpu do wäaĈciwoĈci SessionId przez usäugö aktywowanñ przez wywoäania bez sesji transportowej spowoduje zwrócenie wartoĈè null, poniewaĔ w takim przypadku nie istnieje ani sesja, ani — co oczywiste — jej identyfikator. Usĥugi sesyjne _ 191 Klient moĔe uzyskaè dostöp do identyfikatora sesji za pomocñ poĈrednika. Jak wspomniano w rozdziale 1., klasñ bazowñ dla poĈrednika jest ClientBase T . Klasa ClientBase T definiuje wäaĈciwoĈè dostöpnñ tylko do odczytu InnerChannel typu IClientChannel. Interfejs IClientChannel dziedziczy po interfejsie IContextChannel, który z kolei zawiera wäaĈciwoĈè SessionId zwracajñcñ äaþcuch z identyfikatorem sesji: public interface IContextChannel : ... { string SessionId {get;} // Pozostaäe skäadowe… } public interface IClientChannel : IContextChannel,... {...} public abstract class ClientBase T : ... { public IClientChannel InnerChannel {get;} // Pozostaäe skäadowe… } JeĈli stosujemy definicje z listingu 4.4, klient moĔe uzyskaè identyfikator sesji w nastöpujñcy sposób: MyContractClient proxy = new MyContractClient(); proxy.MyMethod(); string sessionID = proxy.InnerChannel.SessionId; Trace.WriteLine(sessionID); Okazuje siö jednak, Ĕe stopieþ zgodnoĈci identyfikatora sesji po stronie klienta z identyfikatorem zwracanym po stronie usäugi (nawet wtedy, gdy klient ma dostöp do wäaĈciwoĈci SessionId) jest pochodnñ stosowanego powiñzania i jego konfiguracji. Za dopasowywanie identyfikatorów sesji po stronie klienta i po stronie usäugi odpowiada sesja na poziomie transportowym. JeĈli jest stosowane powiñzanie TCP i jeĈli jest wäñczona niezawodna sesja (która w takim przy- padku powinna byè wäñczona), klient moĔe uzyskaè prawidäowy identyfikator sesji dopiero po wysäaniu do usäugi pierwszego wywoäania metody i — tym samym — ustanowieniu nowej sesji lub po bezpoĈrednim otwarciu poĈrednika. W takim przypadku identyfikator sesji uzy- skany przez klienta odpowiada identyfikatorowi stosowanemu po stronie usäugi. (JeĈli klient uzyskuje dostöp do identyfikatora sesji przed pierwszym wywoäaniem, wäaĈciwoĈè SessionId ma wartoĈè null). JeĈli jest stosowane powiñzanie TCP, ale niezawodne sesje sñ wyäñczone, klient moĔe uzyskaè dostöp do identyfikatora sesji przed pierwszym wywoäaniem, jednak otrzy- many identyfikator bödzie inny od tego dostöpnego po stronie usäugi. W przypadku powiñza- nia WS (przy wäñczonym mechanizmie niezawodnego przesyäania komunikatów) identyfikator sesji bödzie miaä wartoĈè null do czasu zakoþczenia pierwszego wywoäania (lub otwarcia poĈred- nika przez klienta). Po tym wywoäaniu klient i usäuga zawsze bödñ miaäy dostöp do tego samego identyfikatora sesji. W razie braku niezawodnego przesyäania komunikatów przed uzyskaniem dostöpu do identyfikatora sesji klient musi uĔyè poĈrednika (lub tylko go otworzyè); w prze- ciwnym razie istnieje ryzyko wystñpienia wyjñtku InvalidOperationException. Po otwarciu poĈred- nika klient i usäuga majñ dostöp do tego samego, skorelowanego identyfikatora sesji. W przy- padku powiñzania IPC klient moĔe uzyskaè dostöp do wäaĈciwoĈci SessionId przed pierwszym wywoäaniem, jednak otrzymany w ten sposób identyfikator sesji bödzie inny od tego dostöp- nego po stronie usäugi. Podczas stosowania tego powiñzania najlepszym rozwiñzaniem jest caä- kowite ignorowanie identyfikatora sesji. 192 _ Rozdziaĥ 4. Zarzédzanie instancjami Koħczenie sesji Sesja zwykle koþczy siö w momencie, w którym klient zamyka swojego poĈrednika. JeĈli jednak klient sam nie zamyka poĈrednika, jeĈli dziaäanie klienta koþczy siö w jakiĈ nieoczekiwany sposób lub jeĈli wystñpiä jakiĈ problem komunikacyjny, sesja zostanie zakoþczona po okreĈlo- nym czasie nieaktywnoĈci sesji transportowej. Usĥuga singletonowa Usäuga singletonowa (ang. singleton service) to w istocie usäuga wspóädzielona. Skonfiguro- wanie usäugi jako singletonu powoduje, Ĕe wszystkie aplikacje klienckie niezaleĔnie od siebie äñczñ siö z jednym, dobrze znanym kontekstem instancji i poĈrednio z jednñ instancjñ usäugi (niezaleĔnie od uĔywanego punktu koþcowego usäugi). Singleton jest tworzony tylko raz (pod- czas tworzenia hosta) i nigdy nie jest niszczony. Zwolnienie singletonu nastöpuje dopiero w momencie wyäñczenia hosta. Singleton udostöpniany na serwerze IIS lub WAS jest tworzony z chwilñ uruchamiania procesu hosta, czyli w odpowiedzi na pierwsze Ĕñdanie dotyczñce dowolnej usäugi w tym procesie. Okazuje siö jednak, Ĕe w przypadku stosowania mechanizmu auto- matycznego uruchamiania pakietu Windows Server AppFabric singleton jest tworzony zaraz po uruchomieniu komputera. Zachowanie semantyki singletonu wymaga uĔycia albo mechanizmu samohostingu (ang. self-hosting), albo pakietu Windows Server AppFabric z funkcjñ automatycznego uruchamiania. Stosowanie usäugi singletonowej nie wymaga od klientów utrzymywania sesji logicznej z instan- cjñ tej usäugi ani uĔywania powiñzaþ obsäugujñcych sesje transportowe. JeĈli kontrakt pobrany przez klienta obejmuje sesjö, do wywoäania usäugi singletonowej zostanie przypisany ten sam identyfikator sesji, którym dysponuje klient (jeĈli stosowane powiñzanie dopuszcza takñ moĔ- liwoĈè), ale zamkniöcie poĈrednika tego klienta spowoduje zakoþczenie tylko sesji transporto- wej — kontekst singletonu ani sama instancja usäugi nie zostanñ zamkniöte. JeĈli usäuga single- tonowa obsäuguje kontrakty bez sesji, takĔe te kontrakty nie bödñ aktywowane przez wywoäania, tylko trwale powiñzane z tñ samñ instancjñ. Usäuga singletonowa z natury rzeczy ma cha- rakter wspóädzielony, a kaĔdy klient powinien utworzyè wäasnego poĈrednika lub wäasnych poĈredników w dostöpie do jedynej instancji tej usäugi. Konfiguracja usäugi singletonowej wymaga ustawienia wartoĈci InstanceContextMode.Single we wäaĈciwoĈci InstanceContextMode: [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)] class MySingleton : ... {...} Listing 4.6 demonstruje usäugö singletonowñ z dwoma kontraktami, z których jeden wymaga sesji, drugi — nie. Przykäad wywoäania ze strony klienta pokazuje, Ĕe dwa wywoäania doty- czñce dwóch róĔnych punktów koþcowych sñ kierowane do tej samej instancji, a zamkniöcie poĈredników nie powoduje zakoþczenia dz
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Programowanie usług WCF. Wydanie III
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: