Wydawnictwo Helionul. Chopina 644-100 Gliwicetel. (32)230-98-63e-mail: helion@helion.pl

PRZYK£ADOWY ROZDZIA£PRZYK£ADOWY ROZDZIA£

IDZ DOIDZ DO

ZAMÓW DRUKOWANY KATALOGZAMÓW DRUKOWANY KATALOG

KATALOG KSI¥¯EKKATALOG KSI¥¯EK

TWÓJ KOSZYKTWÓJ KOSZYK

CENNIK I INFORMACJECENNIK I INFORMACJE

ZAMÓW INFORMACJEO NOWOŒCIACH

ZAMÓW INFORMACJEO NOWOŒCIACH

ZAMÓW CENNIKZAMÓW CENNIK

CZYTELNIACZYTELNIAFRAGMENTY KSI¥¯EK ONLINEFRAGMENTY KSI¥¯EK ONLINE

SPIS TREŒCISPIS TREŒCI

DODAJ DO KOSZYKADODAJ DO KOSZYKA

KATALOG ONLINEKATALOG ONLINE

Zarz¹dzanie zasobami.Wzorce projektowe

Techniki implementacji wydajnych mechanizmów zarz¹dzania zasobami

• Pozyskiwanie zasobów• Wykorzystywanie zasobów• Zwalnianie zasobów

Efektywne zarz¹dzanie zasobami ma kluczowe znaczenie dla funkcjonowania oprogramowania. Niezale¿nie od tego, czy s¹ to ma³e systemy instalowanew urz¹dzeniach przenoœnych, czy rozbudowane aplikacje korporacyjne, musimy mieæ pewnoœæ, ¿e pamiêæ, w¹tki, pliki i po³¹czenia sieciowe s¹ zarz¹dzane w sposób, który zapewnia w³aœciwe i wydajne dzia³anie systemu. Koniecznoœæ stosowania efektywnych metod zarz¹dzania zasobami zbyt czêsto jest odkrywana w póŸnych fazach projektów informatycznych. Wprowadzanie zmian jest wtedy trudne i kosztowne.

Ksi¹¿ka „Zarz¹dzanie zasobami. Wzorce projektowe” przedstawia metody implementacji efektywnych mechanizmów zarz¹dzania zasobami w systemach informatycznych. Wzorce przydzielono do trzech grup odpowiadaj¹cych naturalnemu cyklowi ¿ycia zasobów. Ka¿dy wzorzec zosta³ zilustrowany przyk³adem.Ksi¹¿ka zawiera równie¿ dwa studia przypadków, które opisuj¹ mo¿liwoœci stosowania przedstawionych wzorców w sieciach komputerowych.

• Przegl¹d technik zarz¹dzania zasobami• Stosowanie wzorców projektowych• Wzorce pozyskiwania zasobów• Wzorce zarz¹dzania zasobami• Wzorce zwalniania zasobów

Dziêki zawartym w tej ksi¹¿ce wiadomoœciom stworzysz wydajniejsze oprogramowanie.

Autorzy: Michael Kircher, Prashant JainT³umaczenie: Miko³aj SzczepaniakISBN: 83-246-0102-3Tytu³ orygina³u: Pattern-Oriented SoftwareArchitecture, Patterns for Resource ManagementFormat: B5, stron: 352

Spis treści 5

!spis-03 5

Słowo wstępne Franka Buschmanna ...............................7

Słowo wstępne Steve’a Vinoskiego ................................11

O książce .....................................................................15

O autorach ...................................................................23

1. Wprowadzenie .....................................................251.1. Przegląd technik zarządzania zasobami ............................281.2. Zakres zarządzania zasobami ...........................................311.3. Stosowanie wzorców .........................................................341.4. Wzorce w zarządzaniu zasobami .......................................351.5. Materiały dodatkowe ........................................................391.6. Format prezentacji wzorca ................................................44

2. Pozyskiwanie zasobów .........................................47Lookup .............................................................................50Lazy Acquisition ...............................................................70Eager Acquisition .............................................................88Partial Acquisition ..........................................................103

3. Cykl życia zasobów ...........................................119Caching .........................................................................121Pooling ...........................................................................138Coordinator ....................................................................155Resource Lifecycle Manager ............................................175

4. Zwalnianie zasobów ...........................................197Leasing ..........................................................................199Evictor ...........................................................................221

6 Spis treści

6 !spis-03

5. Zarządzanie zasobami — praktyczne wskazówki ..235

6. Studium przypadku: sieć ad hoc ........................2396.1. Pojęcia ogólne ................................................................2406.2. Motywacja ......................................................................2426.3. Rozwiązanie ...................................................................244

7. Studium przypadku: sieć mobilna ......................2517.1. Pojęcia ogólne ................................................................2527.2. Motywacja ......................................................................2577.3. Rozwiązanie ...................................................................259

8. Przeszłość, teraźniejszość i przyszłośćwzorców projektowych ......................................281

8.1. Cztery ostatnie lata w pigułce .........................................2828.2. Obecny stan rozwoju wzorców projektowych ...................2898.3. Jaka przyszłość czeka wzorce projektowe? ......................2908.4. Drobna uwaga odnośnie do przyszłości wzorców .............298

9. Uwagi końcowe ..................................................299

Wykaz wzorców .................................................303

Notacja .............................................................309

Bibliografia .......................................................317

Źródła cytatów ..................................................329

Skorowidz wzorców ...........................................331

Skorowidz .........................................................333

r03-03 119

Nie szukaj duszo nieśmiertelności,ciesz się raczej tymi zasobami,

które są w twoim zasięgu.

Pindar

Kiedy już pozyskamy niezbędny zasób, musimy znaleźć sposóbna efektywne zarządzanie jego cyklem życia. Zarządzanie za-sobami wiąże się oczywiście z ich udostępnianiem użytkowni-kom, obsługą zależności międzyzasobowych, pozyskiwaniem —w razie konieczności — wszelkich zasobów zależnych oraz zwal-nianiem zasobów, kiedy okaże się, że nie są one już potrzebne.

Wzorzec projektowy Caching (zob. strona 121) opisuje sposób za-rządzania cyklem życia często wykorzystywanych zasobów, którypozwala znacznie ograniczyć koszty ich ponownego pozyskiwa-nia i zwalniania, zachowując jednocześnie podstawowe właści-wości (identyfikator) tych zasobów. Wzorzec Caching jest nie-zwykle popularny — powszechnie stosuje się go między innymiw wysoce skalowalnych rozwiązaniach korporacyjnych. Wzorzec

120 Cykl życia zasobów

120 r03-03

projektowy Pooling (zob. strona 138) — podobnie jak wzorzecCaching — optymalizuje procesy pozyskiwania i zwalniania zaso-bów, ale — w przeciwieństwie do tamtego wzorca — nie zachowujeunikatowych identyfikatorów tych zasobów. Wzorzec Pooling jestwięc dobrym rozwiązaniem w przypadku zasobów bezstanowych,które wymagają stosunkowo niewielu działań w fazie inicjaliza-cji lub nie wymagają ich wcale. Podobnie jak Caching, wzorzecprojektowy Pooling jest bardzo popularny — można bez truduwskazać przykłady puli komponentów w architekturach kompo-nentowych lub puli wątków w aplikacjach rozproszonych. WzorceCaching i Pooling mogą być stosowane wyłącznie dla zasobówwielokrotnego użytku. Oba wzorce stosuje się dla zasobów wie-lokrotnego użytku z wyłącznym dostępem, które są kolejno wy-korzystywane przez wielu użytkowników. Warto jednak pamię-tać, że w niektórych przypadkach zastosowanie wzorca Cachinglub Pooling także dla współbieżnie wykorzystywanych zasobówwielokrotnego użytku znajduje uzasadnienie. W takim przypadkuani wzorzec Caching, ani wzorzec Pooling w ogóle nie musi „wie-dzieć”, że pojedyncze zasoby są udostępniane wielu użytkowni-kom jednocześnie (uczestniczą w przetwarzaniu współbieżnym),ponieważ wszelkie operacje i tak dotyczą tylko zasobów „po-branych” z pamięci podręcznej lub puli.

Dwa lub wiele składników programu, czyli np. pozyskanych za-sobów, użytkowników zasobów lub dostawców zasobów, może zesobą współpracować i wprowadzać odpowiednie zmiany do dane-go systemu informatycznego. W tego typu sytuacjach mówi się,że wspomniane składniki są aktywne i zdolne do uczestnictwaw działaniach skutkujących zmianami. W takim przypadku bar-dzo ważne jest utrzymywanie spójnego stanu systemu mimo zmiangenerowanych przez aktywnych uczestników przetwarzania. Wzo-rzec projektowy Coordinator (zob. strona 155) daje nam pewność,że realizacja zadań wymagających udziału wielu uczestników niespowoduje utraty spójności i jako takie nie obniżą one ogólnej sta-bilności systemu.

Wzorzec Resource Lifecycle Manager (zob. strona 175) zarządzawszystkimi zasobami danego systemu informatycznego, co ozna-cza, że zwalnia z obowiązku właściwego zarządzania cyklem życiazasobów zarówno same zasoby, jak i ich użytkowników. Wzorzecprojektowy Resource Lifecycle Manager odpowiada za zarządzaniacyklem życia wszystkich typów zasobów, włącznie z zasobami wie-lokrotnego użytku i jednorazowego użytku.

Caching 121

r03-03 121

Wzorzec Caching opisuje sposób unikania kosztownych operacjiponownego pozyskiwania zasobów, ponieważ nie zwalnia zasobówzaraz po ich użyciu. Zasoby zachowują swoją identyfikatory i sąskładowane w pamięci zapewniającej możliwie szybki dostęp. Abyuniknąć konieczności ponownego pozyskiwania zasobów, wzorzecprojektowy Caching przewiduje możliwość ich ponownego wyko-rzystywania.

Przykład Wyobraź sobie system zarządzający siecią, który musi monitoro-wać stan wielu elementów sieciowych. Tego rodzaju systemy zwy-kle implementuje się w architekturze trójwarstwowej. Użytkow-nicy końcowi mogą korzystać z takiego systemu za pośrednictwemwarstwy prezentacji, która zwykle ma postać graficznego inter-fejsu użytkownika (GUI). Warstwa środkowa (pośrednicząca), którapowinna zawierać całą logikę biznesową, współpracuje zarównoz warstwą utrwalania, jak i z fizycznymi elementami sieciowymi.Ponieważ typowa sieć może się składać z tysięcy takich elemen-tów, ustanawianie trwałych połączeń pomiędzy warstwą środko-wą, serwerem aplikacji i wszystkimi tymi elementami byłoby bar-dzo kosztowne. Z drugiej strony, użytkownik końcowy może (zapośrednictwem odpowiednich funkcji interfejsu GUI) wskazać do-wolne elementy sieciowe, aby uzyskać szczegółowe informacje natemat tych elementów. System zarządzania siecią musi odpowia-dać na żądania użytkowników w skończonym czasie, zatem po-winien gwarantować krótkie czasy oczekiwania pomiędzy żąda-niem użytkownika (wskazaniem konkretnego elementu sieciowego)a odpowiedzią systemu (wizualizacją właściwości tego elementu).

Z ustanawianiem nowych połączeń sieciowych dla wszystkich wy-bieranych przez użytkownika elementów sieciowych oraz niszcze-nie tych połączeń już po wykorzystaniu wiązałoby się z ogrom-nym obciążeniem procesora w ramach serwera aplikacji. Cowięcej, średni czas dostępu do elementu sieciowego byłby bar-dzo długi.

122 Cykl życia zasobów

122 r03-03

Kontekst Systemy, które wielokrotnie uzyskują dostęp do tego samego zbio-ru zasobów i które wymagają odpowiedniej optymalizacji w ob-szarze wydajności.

Problem Wielokrotne powtarzanie operacji pozyskiwania, inicjalizacji i zwal-niania tego samego zasobu powoduje zupełnie niepotrzebne opóź-nienia. Jeśli jeden lub wiele komponentów systemu uzyskujedostęp do tego samego zasobu i — tym samym — wielokrotniepowtarza operacje pozyskiwania i inicjalizacji, koszt wyrażanyw cyklach procesora i ogólnej wydajności systemu może być bar-dzo wysoki. Poprawa wydajności wymaga więc znacznego obniże-nia kosztów pozyskiwania, dostępu i zwalniania najczęściej wyko-rzystywanych zasobów.

Aby skutecznie rozwiązać ten problemu, należy uwzględnić nastę-pujące czynniki:

� Wydajność. Należy zminimalizować koszty wielokrotnie po-wtarzanych operacji pozyskiwania, inicjalizacji i zwalnianiazasobów.

Caching 123

r03-03 123

� Złożoność. Nasze rozwiązanie z pewnością nie powinno niepo-trzebnie komplikować operacji pozyskiwania i zwalniania zaso-bów. Co więcej, stosowane rozwiązanie nie powinno dodawaćniepotrzebnego poziomu pośredniczenia w dostępie do zasobów.

� Dostępność. Rozwiązanie problemu powinno zapewniać do-stępność zasobów także wtedy, gdy dostawcy zasobów są tym-czasowo niedostępni.

� Skalowalność. Stosowane rozwiązanie powinno być skalowalneprzede wszystkim w wymiarze liczby zasobów.

Rozwiązanie Należy w sposób przezroczysty składować zasoby w buforze zape-wniającym szybki dostęp, nazywanym pamięcią podręczną. Ozna-cza to, że kiedy użytkownik zażąda ponownego dostępu, pobie-ramy dany zasób z pamięci podręcznej, zamiast ponownie pozy-skiwać ten zasób za pośrednictwem dostawcy (np. zarządzającegozasobami systemu operacyjnego). Zasoby w pamięci podręcznejsą identyfikowane według unikatowych właściwości (jakichś cechcharakterystycznych), a więc wskaźnika, referencji lub kluczagłównego.

Zachowując często wykorzystywane zasoby i nie zwalniając ichpo każdym użyciu, możemy w prosty sposób uniknąć kosztówzwiązanych z ponownymi pozyskiwaniem i wielokrotnym zwalnia-niem. Stosowanie pamięci podręcznej ułatwia też zarządzaniekomponentami, które uzyskują dostęp do takich zasobów.

Kiedy zasoby w pamięci podręcznej nie będą już potrzebne, na-leży je zwolnić. Od implementacji samej pamięci podręcznej za-leży, jak i kiedy usuwać niepotrzebne zasoby. Odpowiednie za-chowania można kontrolować za pomocą starannie dobieranychstrategii.

Struktura Na poniższej liście wymieniono i krótko opisano uczestników wzor-ca projektowego Caching:

� Użytkownik zasobów wykorzystuje dany zasób.

� Zasób jest jakimś bytem, np. połączeniem.

� Pamięć podręczna zasobów buforuje zasoby zwalniane przezich użytkowników.

� Dostawca zasobów posiada i zarządza wieloma zasobami.

124 Cykl życia zasobów

124 r03-03

Przedstawione poniżej karty CRC ilustrują sposób, w jaki współ-pracują ze sobą uczestnicy tego wzorca.

Strukturę wzorca projektowego Caching przedstawiono na poniż-szym diagramie klas.

Rola dostawcy zasobów, np. systemu operacyjnego, sprowadza sięw takim przypadku do zarządzania zasobami do momentu ichpierwszego pozyskania przez użytkownika. Użytkownik uzyskujenastępnie dostęp do pozyskanych w ten sposób zasobów. Kiedyzasoby nie będą już potrzebne, użytkownik zwraca je do pamięcipodręcznej (bufora). Użytkownik wykorzystuje tę pamięć do pozy-skiwania tych zasobów, których ponownie potrzebuje. Pozyski-wanie zasobów z pamięci podręcznej jest tańsze (przynajmniej od

Caching 125

r03-03 125

pozyskiwania bezpośrednio od dostawców) zarówno w wymiarzeobciążenia procesora, jak i opóźnień czasowych.

Dynamika Na poniższym rysunku przedstawiono sposób pozyskiwania za-sobu przez użytkownika bezpośrednio od jego dostawcy. Użytkow-nik uzyskuje następnie dostęp do tego zasobu. Użyty w ten sposóbzasób jest zwracany do pamięci (zamiast do swojego dostawcy).

Kiedy okaże się, że użytkownik ponownie musi uzyskać dostęp dotego samego zasobu, nie korzysta już z dostawcy, tylko od razupobiera ten zasób z pamięci podręcznej.

Implementacja Aby zaimplementować wzorzec projektowy Caching, należy wyko-nać następujące kroki:

1. Dobór zasobów. Należy wybrać zasoby, które rzeczywiście sko-rzystają na stosowaniu techniki wykorzystującej pamięć pod-ręczną. W większości przypadków będą to zasoby, których pozy-skiwanie jest kosztowne i które są wykorzystywane stosunkowoczęsto. Wzorzec projektowy Caching jest bardzo często wprowa-dzany jako technika optymalizacji oprogramowania po zidenty-fikowaniu wąskich gardeł obniżających jego łączną wydajność.

W systemach rozproszonych pamięć podręczna może występowaćw dwóch postaciach: pamięci klienta i pamięci serwera. Pamięćpodręczna po stronie klienta daje pewne oszczędności w wymiarze

126 Cykl życia zasobów

126 r03-03

obciążenia połączeń sieciowych i — tym samym — czasu potrzeb-nego do wielokrotnego przesyłania danych pomiędzy serwerema klientem. Z drugiej strony, pamięć podręczna po stronie serwerajest skutecznym rozwiązaniem w sytuacji, gdy liczne żądania wieluklientów dotyczą pozyskiwania i zwalniania tego samego zasobu.

2. Określenie interfejsu pamięci podręcznej. Skoro użytkownikma zwalniać i ponownie pozyskiwać zasoby bezpośrednio z pa-mięci podręcznej, należy zaprojektować odpowiedni interfejs dlatej pamięci. Taki interfejs powinien oczywiście udostępniać me-tody release() i acquire() (reprezentujące odpowiednio opera-cje zwalniania i pozyskiwania zasobów).

public interface Cache { public void release (Resource resource); public Resource acquire (Identity id) throws ResourceNotFound;}

Konstruując powyższy interfejs zakładaliśmy, że istnieje i jest do-stępny zasób z unikatowym identyfikatorem, co nie we wszyst-kich przypadkach musi mieć miejsce. Może się zdarzyć, że identy-fikator zasobu będzie wymagał wyznaczenia takiego identyfikatorana podstawie swoich właściwości (tożsamości)1.

Metoda release() jest wywoływana przez użytkownika zasobuw momencie, w którym zdecyduje o zwolnieniu zasobu — zasóbjest wówczas zwracany do pamięci podręcznej zamiast do swojegooryginalnego dostawcy.

3. Implementacja pamięci podręcznej. Właściwa implementacjametod acquire() i release() interfejsu wzorca projektowego Ca-ching jest kluczem do funkcjonalności pamięci podręcznej.

Poniższy fragment kodu zawiera implementację metody re-lease(), która jest wywoływana w chwili zwalniania danego za-sobu przez jego użytkownika:

public class CacheImpl implements Cache { public void release (Resource resource) { String id = resource.getId (); map.put (id, resource); } // ...

private HashMap map = new HashMap ();}

1 Nie będziemy tutaj szczegółowo omawiali tego zagadnieniem, ponieważ wykracza onopoza zakres tematyczny niniejszej książki.

Caching 127

r03-03 127

Metoda release() dodaje zasób do odpowiedniej struktury danych(w tym przypadku typu HashMap), dzięki czemu będzie można póź-niej ten zasób pozyskać, przekazując jego identyfikator. Zasto-sowano strukturę HashMap ze względów optymalizacyjnych, ponie-waż czas wyszukiwania w tablicy (mapie) asocjacyjnej jest stały.Wzorzec projektowy Comparand [Costanza, 2001] wprowadza pe-wne koncepcje w zakresie porównywania identyfikatorów. W za-leżności od rodzaju zasobu, może się okazać, że w pierwszej ko-lejności należy wyznaczyć jego identyfikator. W tym przypadkuzasób zawiera już odpowiedni identyfikator.

Metoda acquire() naszej implementacji pamięci podręcznej po-winna odpowiadać za odnajdywanie zasobu w strukturze tablicyasocjacyjnej według przekazanego na wejściu identyfikatora. Jeślioperacja pozyskania zasobu z pamięci podręcznej zakończy sięniepowodzeniem, co oznacza, że nie udało się znaleźć zasobuz danym identyfikatorem, pamięć podręczna teoretycznie możepodjąć próbę pozyskania tego zasobu bezpośrednio od jego do-stawcy. Więcej informacji na ten temat znajdziesz w omówieniuwersji „Przezroczysta pamięć podręczna” w punkcie „Wersje”.

Poniższy fragment kodu zawiera przykładową implementację me-tody acquire().

public class CacheImpl implements Cache { public Resource acquire (Identity id) throws ResourceNotFound{ Resource resource = (Resource)map.get (id); if (resource == null) throw new ResourceNotFound ("Zasób z id" + id.toString ()+ " nie znaleziony!"); return resource; }}

4. Określenie sposobu integracji z pamięcią podręczną (krokopcjonalny). Jeśli chcemy zintegrować pamięć podręczną z na-szym systemem w sposób przezroczysty, powinniśmy rozważyćużycie wzorca projektowego Interceptor [Schmidt, 2000] lub CacheProxy [Buschmann, 1996]. Wprowadzenie któregoś z tych wzor-ców pozwoli ograniczyć złożoność operacji jawnego zwalnianiai ponownego pozyskiwania zasobów z pamięci podręcznej, ponie-waż zapewni przezroczystość odpowiednich działań. Więcej in-formacji temat sposobów zapewniania przezroczystości operacjina zasobach składowanych w pamięci podręcznej znajdziesz

128 Cykl życia zasobów

128 r03-03

w omówieniu wersji „Przezroczysta pamięć podręczna” w punkcie„Wersje”. Warto jednak pamiętać, że opisane sposoby nie elimi-nują dodatkowego poziomu pośrednictwa związanego z ko-niecznością przeszukiwania pamięci podręcznej.

5. Wybór strategii usuwania zasobów z pamięci podręcznej.Zasoby składowane w pamięci podręcznej wymagają dodatkowejprzestrzeni pamięciowej. Jeśli tego rodzaju zasoby nie są wyko-rzystywane przez długi czas, ich dalsze składowanie staje się bez-celowe i obniża łączną efektywność systemu. Należy wówczas użyćwzorca projektowego Evictor (zob. strona 221), który będzie stop-niowo usuwał z bufora niepotrzebne zasoby. Istnieje wiele spo-sobów integrowania wzorca Evictor ze wzorcem Caching. Przy-kładowo mechanizmy wzorca Evictor można wywoływać albow ciele metody release(), albo automatycznie, w regularnychodstępach czasu. Tego rodzaju działania mają oczywiście wpływna łączną przewidywalność systemu. Co więcej, istnieje wiele róż-nych sposobów konfiguracji wzorca projektowego Evictor, którymoże stosować rozmaite strategie wyboru zasobów przeznaczonychdo usunięcia, np. począwszy od najdłużej nieużywanych (ang. Le-ast Recently Used — LRU), począwszy od najrzadziej używanych(ang. Least Frequently Used — LFU) lub innych strategii właści-wych dla danej dziedziny. Można się oczywiście posłużyć wzorcemStrategii [Gamma, 1995].

6. Zapewnianie spójności. Wiele zasobów ma przypisane stany, któ-re należy odpowiednio inicjalizować podczas tworzenia zasobów.Co więcej, kiedy na którymś z tego rodzaju zasobów wykonujemyoperację zapisu, musimy zapewnić spójność pomiędzy oryginal-nym zasobem zarządzanym przez swojego dostawcę a jego kopiąskładowaną w pamięci podręcznej. Ewentualna zmiana oryginal-nego zasobu wymaga wykonania wywołań zwrotnych, które zak-tualizują jej kopię w pamięci podręcznej. Jeśli natomiast zmienisię sama kopia, większość implementacji pamięci podręcznej sto-suje strategię propagowania operacji zapisu, zgodnie z którą zmia-ny zastosowane na kopii zasobu są automatycznie wprowadzanezarówno w tej kopii, jak i w oryginalnym zasobie. Do implemen-tacji tego typu funkcjonalności zwykle wykorzystuje się mecha-nizm Synchronizer (obiektu synchronizującego). Oznacza to, żew analizowanym scenariuszu Synchronizer jest istotnym składni-kiem wzorca projektowego Caching. Niektóre implementacje pa-mięci podręcznej dodatkowo optymalizują swoją funkcjonalność,

Caching 129

r03-03 129

wprowadzając złożoną logikę utrzymywania spójności pomiędzyoryginalnymi zasobami a ich kopiami.

Do podejmowania decyzji, kiedy należy synchronizować oryginalnyzasób z jego kopią, można użyć wzorca projektowego Strategy[Gamma, 1995]. W niektórych przypadkach tylko specjalne dzia-łania, np. operacje zapisu, będą wymagały natychmiastowej syn-chronizacji; w pozostałych przypadkach wystarczy synchronizo-wać zasoby w regularnych odstępach czasu. Synchronizacja możeteż być wywoływana przez takie zdarzenia zewnętrzne jak aktu-alizacje oryginalnych zasobów przez innych użytkowników.

Jeśli w analizowanym przykładzie systemu zarządzania sieciąfizyczne dane o elemencie sieciowym ulegną zmianie, także repre-zentacja tego elementu przechowywana w pamięci podręcznej musizostać odpowiednio zmodyfikowana. Podobnie jeśli użytkownikzmieni ustawienia jakiegoś elementu sieciowego, wprowadzoneprzez niego zmiany należy uwzględnić na poziomie odpowiedniegourządzenia.

Przykładowerozwiązanie

Wyobraźmy sobie system zarządzania siecią, którego zadaniemjest monitorowanie stanu wielu elementów sieciowych. Warstwaśrodkowa tego systemu wykorzystuje wzorzec projektowy Caching,za pomocą którego zaimplementowano pamięć podręczną połą-czeń z tymi elementami sieciowymi. W odpowiedzi na podjętąprzez użytkownika próbę uzyskania dostępu do konkretnego ele-mentu sieciowego system pozyskuje połączenie z tym elemen-tem. Kiedy okaże się, że takie połączenie nie jest już potrzebne,następuje jego dodanie do pamięci podręcznej. Jeśli w przyszło-ści pojawi się kolejne żądanie takiego połączenia, zostanie ono po-zyskane z tej pamięci, dzięki czemu unikniemy dużo większychkosztów jego pozyskiwania od oryginalnego dostawcy.

Kolejne połączenia z pozostałymi elementami sieciowymi będąustanawiane w odpowiedzi na generowane przez użytkownikówpróby pierwszego dostępu. Kiedy kontekst użytkownika przełą-czy się na inny element sieciowy, połączenie zostanie zwróconedo pamięci (bufora) połączeń. Jeśli jakiś użytkownik zażąda do-stępu do tego samego elementu sieciowego, istniejące połączeniezostanie wykorzystane ponownie. Z dostępem do pozyskanegowcześniej połączenia (występującego w roli zasobu wielokrotnegoużytku) nie będą się wiązały żadne dodatkowe opóźnienia.

130 Cykl życia zasobów

130 r03-03

Wersje Transparent Cache (przezroczysta pamięć podręczna). Jeśli pa-mięć podręczna musi zostać zintegrowana z systemem w sposóbprzezroczysty, do pozyskiwania zasobów żądanych przez klientapowinniśmy użyć wzorca projektowego Lazy Acquisition (zob.strona 70). Takie rozwiązanie jest możliwe tylko wtedy, gdy pamięćpodręczna „wie”, jak pozyskiwać i inicjalizować takie zasoby. Le-niwe pozyskiwanie zasobów pozwala na całkowite uniezależnie-nie użytkownika zasobów od funkcjonowania pamięci podręcznej.

Read-Ahead Cache (pamięć podręczna wypełnianą z wyprzedze-niem). W sytuacji gdy zasoby są pozyskiwane przez wielokrotnestosowanie wzorca projektowego Partial Acquisition (zob. strona103), efektywność systemu można znacznie podnieść stosującpamięć podręczną wypełnianą z wyprzedzeniem. Taka pamięć mo-że pozyskiwać zasoby, zanim dotrą one do systemu właściwe żą-dania użycia i — tym samym — zapewnić niemal natychmia-stową dostępność tych zasobów.

Cached Pool (pula pamięci podręcznej). Stosowanie kombinacjipamięci podręcznej i puli może być skutecznym sposobem bu-dowy wyrafinowanych rozwiązań zarządzających zasobami. Kiedyzaistnieje konieczność usunięcia zasobu z pamięci podręcznej, za-miast zwracać ten zasób do jego dostawcy, można go umieścićw specjalnej puli. Pamięć podręczna pełni więc funkcję swoistegopośrednika w dostępie do zasobów. Zwykle definiuje się dla takiejpamięci podręcznej limit czasowy — jeśli założony czas się wy-czerpie, zasób traci swój identyfikator i wraca do puli. Zaletą tegorozwiązania jest niewielka optymalizacja: jeśli zasób, który niezostał jeszcze zwrócony do puli, jest przedmiotem żądania, uni-kamy kosztów dodatkowej inicjalizacji (co jest podstawową zaletąkoncepcji pamięci podręcznej).

Layered Cache (wielowarstwowa pamięć podręczna). W skompli-kowanych systemach wzorzec projektowy Caching często jest sto-sowany na wielu poziomach jednocześnie. Przykładowo serwerWebSphere Application Server (WAS) [IBM (a), 2004] stosuje pa-mięć podręczną w wielu aspektach swojego funkcjonowania. SerwerWAS oferuje możliwość aktywnego przechowywania w pamięcipodręcznej wyników metod komponentów EJB. Składowanie pole-ceń w pamięci podręcznej z myślą o ich ponownym wykorzysty-waniu przez kolejne obiekty wywołujące umożliwia obsługę żądańw warstwie logiki biznesowej zamiast w warstwie danych, gdzie

Caching 131

r03-03 131

przetwarzanie jest z reguły bardziej kosztowne. WebSphere Ap-plication Server oferuje też pamięć podręczną dla tzw. przygoto-wanych, gotowych wyrażeń, które można konfigurować za pomocąobsługiwanego przez wykorzystywaną bazę danych mechanizmuprzetwarzania dynamicznych lub statycznych wyrażeń języka SQL.W zależności od stosowanych wzorców dostępu do danych apli-kacji, gotowe wyrażenia serwera WAS mogą się przyczynić doznacznej poprawy wydajności aplikacji. Aby poprawić wydajnośćoperacji JNDI, serwer aplikacji WebSphere stosuje pamięć pod-ręczną redukującą liczbę odwołań do serwera nazw podczas ope-racji wyszukiwania. I wreszcie serwer WAS oferuje komponentydostępu do danych, które składują w swojej pamięci podręcznejwyniki zapytań wykonanych na bazie danych.

Skutkistosowania

Z uwagi na dodatkowy poziom pośredniczenia, techniki wykorzy-stujące pamięć podręczną mogą być źródłem pewnych opóźnieńw przetwarzaniu, jednak ogólny bilans wydajności jest pozytywny,ponieważ zasoby są pozyskiwane dużo szybciej.

Stosowanie wzorca projektowego Caching niesie ze sobą wiele ko-rzyści:

� Wydajność. Szybki dostęp do często wykorzystywanych zaso-bów jest niewątpliwie największą zaletą stosowania pamięcipodręcznej. W przeciwieństwie do wzorca projektowego Pooling(zob. strona 138), pamięć podręczna gwarantuje zachowanieprzez zasoby ich tożsamości (unikatowych identyfikatorów). Oz-nacza to, że w razie konieczności uzyskania ponownego dostę-pu do tego samego zasobu, nie musimy go poszukiwać pozapamięcią podręczną — wystarczy odnaleźć odpowiednią pozy-cję w strukturze pamięci podręcznej.

� Skalowalność. Jedną z zalet stosowania wzorca projektowegoCaching jest brak konieczności każdorazowego pozyskiwaniai zwalniania zasobów. Pamięć podręczna z natury rzeczy jest im-plementowana w taki sposób, pozwalający zachowywać najczę-ściej wykorzystywane zasoby. Oznacza to, że podobnie jak wzo-rzec Pooling, także wzorzec Caching redukuje eliminuje kosztyzwiązane z pozyskiwaniem i zwalnianiem zasobów. Korzyści wy-nikające z takiego podejścia są tym większe, im częściej wy-korzystujemy dany zasób, zatem wzorzec projektowy Cachingw istotny sposób poprawia skalowalność systemu.

132 Cykl życia zasobów

132 r03-03

� Złożoność korzystania z zasobów. Stosując pamięć podręcznąmożemy mieć pewność, że z perspektywy użytkownika zasobówzłożoność operacji ich pozyskiwania i zwalniania nie wzrośnie(mimo dodatkowego kroku mającego na celu sprawdzenie do-stępności odpowiednich zasobów w pamięci podręcznej).

� Dostępność. Składowanie zasobów w pamięci podręcznej zwięk-sza ich dostępność w sytuacji, gdy oryginalni dostawcy są cza-sowo niedostępni — niezależnie od stanu dostawców, zasobyw pamięci podręcznej pozostają dostępne dla swoich użytkow-ników.

� Stabilność. Ponieważ wzorzec projektowy Caching ograniczaliczbę operacji zwalniania i ponownego pozyskiwania zasobów,minimalizuje ryzyko fragmentacji pamięci i — tym samym —prowadzi do większej stabilności systemu. Podobny efekt moż-na osiągnąć stosując wzorzec projektowy Pooling.

Ze stosowaniem wzorca Caching wiążą się także pewne utrud-nienia:

� Złożoność synchronizacji. W zależności od rodzaju zasobu,złożoność stosowanej implementacji może rosnąć z uwagi nakonieczność zachowania spójności stanu zasobu w pamięci pod-ręcznej i oryginalnych danych, które są przez ten zasób repre-zentowane. Zapewnienie takiej zgodności jest jeszcze trudniejszew środowiskach podzielonych na klastry (w skrajnych przypad-kach tego typu komplikacje mogą w ogóle przekreślić sens sto-sowania wzorca projektowego Caching).

� Trwałość. W razie awarii ewentualne zmiany dokonane na za-sobach składowanych w pamięci podręcznej mogą zostać utra-cone. Można tego problemu uniknąć stosując tzw. synchroni-zowaną pamięć podręczną.

� Zajętość pamięci. Stosowanie pamięci podręcznej zwiększapotrzeby systemu w zakresie zajmowanego obszaru pamięci,ponieważ istnieje ryzyko składowania w pamięci podręcznejniewykorzystanych zasobów. Jeśli jednak zdecydujemy się użyćwzorca projektowego Evictor (zob. strona 221), najprawdopo-dobniej uda nam się zminimalizować liczbę zasobów niepo-trzebnie przechowywanych w pamięci podręcznej.

Caching 133

r03-03 133

Mechanizm pamięci podręcznej nie jest najlepszym rozwiązaniemw przypadku aplikacji wymagających stałej dostępności danychdla zasobów, których przetwarzanie obejmuje szczególnie kosz-towne operacje. Przykładowo aplikacje sterowane przerwaniami,które na każdym kroku wykorzystują operacje wejścia-wyjścia,oraz tzw. systemy wbudowane (osadzone) bardzo rzadko korzy-stają ze sprzętowych implementacji pamięci podręcznej.

Ogólna uwaga odnośnie do optymalizacji: Wzorzec projektowy Ca-ching powinien być stosowany szczególnie ostrożnie, jeśli innepróby udoskonalenia, np. optymalizacja operacji pozyskiwaniasamego zasobu, okażą się nieskuteczne. Pamięć podręczna częstojest źródłem dodatkowej złożoności na poziomie implementacji —komplikuje konserwację całego rozwiązania i zwiększa łączny po-ziom wykorzystania zasobów (np. pamięci), ponieważ zasoby skła-dowane w pamięci podręcznej nie są zwalniane natychmiast poużyciu. Oznacza to, że przed podjęciem decyzji o zastosowaniutego wzorca należy dokładnie rozważyć wady i zalety w takichaspektach jak wydajność, wykorzystanie zasobów i złożonośćsystemu.

Znanezastosowania

Sprzętowa pamięć podręczna [Smith, 1982]. Niemal wszystkieprocesory (ang. Central Processing Unit — CPU) wykorzystują wła-sną, sprzętową pamięć podręczną. Taka pamięć nie tylko skracaśredni czas dostępu do danych niezbędnych do przetwarzania, aleteż pomaga ograniczyć obciążenie magistrali. Z tych dwóch powo-dów pamięć podręczna procesora zwykle jest szybsza od pamięcioperacyjnej (RAM).

Pamięć podręczna w systemach plików i rozproszonych sys-temach plików [Nelson, 1988] [Smith, 1985]. Rozproszone sys-temy plików wykorzystują wzorzec projektowy Caching po stronieserwera, aby ograniczyć liczbę stale powtarzanych operacji od-czytu bloków dyskowych. Najczęściej wykorzystywane pliki sąprzechowywane w pamięci serwera, co znacznie skraca czas dostę-pu. Systemy plików wykorzystują także pamięć podręczną z blo-kami plików po stronie klienta — w ten sposób można zredu-kować obciążenie połączeń sieciowych i ewentualne opóźnieniazwiązane z pobieraniem danych z serwera.

134 Cykl życia zasobów

134 r03-03

Data Transfer Object [Fowler, 2002]. Technologie oprogramo-wania pośredniczącego, np. CORBA [Object Management Group(a), 2004] oraz Java RMI [Sun Microsystems (g), 2004], oferująmożliwość zdalnego przesyłania całych obiektów (zamiast trady-cyjnych technik zdalnego wywoływania metod udostępnianychprzez zdalne obiekty). Zdalny obiekt jest przesyłany w całości (przezwartość) pomiędzy klientem a serwerem, dzięki czemu możliwejest lokalne wywoływane jego metod. W ten sposób da się zmini-malizować liczbę zdalnych wywołań metod, które zwykle są dośćkosztowne. Obiekt jest lokalnie przechowywany w pamięci pod-ręcznej i reprezentuje właściwy obiekt zdalny. Chociaż opisanerozwiązanie w wielu przypadkach poprawia wydajność, należypamiętać o konieczności zaimplementowania przez użytkownikaodpowiednich mechanizmów synchronizacji lokalnej kopii i ory-ginalnego obiektu zdalnego.

Serwer proxy dla WWW [Squid Web Proxy Cache, 2004]. Serwerproxy dla WWW (ang. Web proxy) jest po prostu serwerem proxypracującym pomiędzy przeglądarką internetową a serweramiWWW. Żądanie dostępu dociera do tego serwera proxy od prze-glądarki internetowej za każdym razem, gdy z któregoś z niezli-czonych serwerów WWW należy pobrać i otworzyć jakąś stronęinternetową. Serwer proxy zapisuje pobraną przez przeglądarkęz serwera WWW stronę internetową w swojej pamięci podręczneji zwraca ją w odpowiedzi na wszystkie kolejne żądania tej samejstrony. Oznacza to, że serwer proxy dla WWW ogranicza liczbężądań dostępu do stron internetowych przesyłanych przez inter-net, ponieważ przechowuje najczęściej żądane strony w lokalnejpamięci podręcznej.

Przeglądarki internetowe. Większość popularnych przegląda-rek internetowych, włącznie z takimi produktami jak Netscape[Netscape Browser, 2004] czy Internet Explorer [Microsoft In-ternet Explorer, 2004], składuje we własnej pamięci podręcznejnajczęściej otwierane strony WWW. Jeśli użytkownik ponowniezażąda dostępu do tej samej strony, przeglądarka wczyta jej za-wartość z pamięci podręcznej i — tym samym — uniknie kosz-townego i czasochłonnego pobierania odpowie strony z witrynyinternetowej. Do określania optymalnego czasu przechowywaniastron w pamięci podręcznej (i właściwego momentu ich usuwa-nia) wykorzystuje się mechanizm znaczników czasowych.

Caching 135

r03-03 135

Stronicowanie [Tanenbaum, 2001] [Noble, 2000]. Współczesnesystemy operacyjne utrzymują w pamięci tzw. strony, które w wielusytuacjach pozwalają unikać kosztownych operacji odczytu z dys-kowego pliku wymiany. Można przyjąć, że strony przechowywanew pamięci znajdują się swoistej pamięci podręcznej. Dopiero kiedynie uda się znaleźć jakiejś strony w pamięci tej podręcznej, sys-tem operacyjny odwołuje się do dużo wolniejszego, dyskowego pli-ku wymiany.

Plikowa pamięć podręczna [Kistler, 1992]. Plikowe pamięci pod-ręczne poprawiają wydajność i dostępność, ponieważ umożliwiająlokalną pracę na plikach i katalogach pochodzących z zamonto-wanych napędów sieciowych (także wtedy, gdy z jakiegoś powodupołączenie z tymi napędami nie będzie możliwe). Pliki i katalogisą kopiowane do pamięci podręcznej i synchronizowane z zawar-tością oryginalnych dysków sieciowych w momencie nawiązaniapołączenia z siecią. Najnowsze wersje systemów operacyjnychfirmy Microsoft obsługują plikową pamięć podręczną w oparciuo technologię nazwaną Plikami offline.

.NET [Richter]. Zbiory danych technologii .NET można traktowaćjak składowane w pamięci bazy danych. Egzemplarze tych zbiorówsą tworzone lokalnie, a za ich wypełnianie danymi odpowiadajązapytania języka SQL przetwarzającej jedną lub wiele tabel bazydanych (za pomocą klasy SqlDataAdapter). Od tego momentuaplikacje klienckie mogą uzyskiwać dostęp do tych danych za po-mocą technik obiektowych. Ewentualne zmiany zostaną uwzględ-nione w oryginalnej bazie danych dopiero wtedy, gdy użyjemywprost klasy SqlDataAdapter do zaktualizowania odpowiednichtabel. Spójność reprezentacji obiektowej i oryginalnego źródła da-nych nie jest zapewniana za pomocą żadnych automatycznych me-chanizmów.

Enterprise JavaBeans (EJB) [Sun Microsystems (b), 2004]. Kom-ponenty encyjne (ang. Entity Beans) technologii EJB reprezentująw warstwie środkowej (na poziomie serwera aplikacji) informacjeskładowane w bazie danych. W ten sposób można uniknąć ko-sztownego wyszukiwania danych (pozyskiwania zasobów) w ba-zie danych.

Obiektowa pamięć podręczna [Oracle, 2003] [ShiftOne ObjectCache, 2004]. Obiektowa pamięć podręczna jest próbą stosowa-nia wzorca projektowego Caching w warunkach przetwarzania

136 Cykl życia zasobów

136 r03-03

obiektowego. W takim przypadku w roli zasobów występują obiekty,które mają przypisane określone koszty tworzenia i inicjalizacji.Obiektowa pamięć podręczna może wyeliminować przynajmniejczęść tych kosztownych operacji (pod warunkiem, że sposób ko-rzystania z tych zasobów umożliwia ich składowanie w takim do-datkowym buforze).

Pamięć podręczna danych [Robinson, 1990] [Newport, 2004].Pamięć podręczna danych jest implementacją wzorca projektowegoCaching stosowaną dla danych. Dane są traktowane jak zasób,który w pewnych sytuacjach jest trudny do pozyskania. Takie danemogą na przykład zawierać skomplikowane i kosztowne obliczenialub odwołania do innego, zewnętrznego źródła danych. WzorzecCaching w tej wersji umożliwia wielokrotne wykorzystywanie razwczytanych danych i — tym samym — eliminuje konieczność ko-sztownego pozyskiwania danych, kiedy okaże się, że są ponowniepotrzebne.

iMerge [iMerge, 2003]. iMerge EMS jest systemem zarządzania ele-mentami wchodzącymi w skład systemu sprzętowego iMerge VoIP(Voice over Internet Protocol), który w roli swojego interfejsu ko-munikacyjnego wykorzystuje protokół SNMP. System iMerge EMSwykorzystuje wzorzec projektowy Caching do optymalizacji komu-nikacji pomiędzy elementami sieciowymi.

Zobacz także Chociaż wzorzec projektowy Pooling (zob. strona 138) pod wie-loma względami przypomina wzorzec Caching, pomiędzy nimiistnieje też jedna bardzo istotna różnica. Podstawowym założe-niem wzorca Pooling jest wielokrotne wykorzystywanie „anoni-mowych” zasobów, czyli takich, które nie mają przypisanychunikatowych identyfikatorów. Takie rozwiązanie pomaga uniknąćkosztów ponownego pozyskiwania i zwalniania zasobów. Więk-szość zasobów jest pozbawiona jakichkolwiek cech wyróżniają-cych (identyfikujących) spośród pozostałych zasobów tego samegotypu. W przeciwieństwie do wzorca Pooling, we wzorcu Cachingkażdy zasób składowany w pamięci podręcznej ma przypisanyunikatowy identyfikator. Oznacza to, że wzorzec Pooling umożli-wia przezroczyste pozyskiwanie zasobów, natomiast we wzorcuCaching za pozyskiwanie zasobów odpowiada ich użytkownik.

Wzorzec projektowy Eager Acquisition (zob. strona 88) zwykle wy-korzystuje wzorzec Caching do zarządzania chciwie pozyskiwany-mi zasobami.

Caching 137

r03-03 137

Możemy użyć wzorca Evictor (zob. strona 221) do usuwania nie-potrzebnych danych z pamięci podręcznej.

Wzorzec Resource Lifecycle Manager (zob. strona 175) może we-wnętrznie wykorzystywać wzorzec projektowy Caching do zapew-niania jak najszybszego dostępu do stanowych zasobów.

Wzorzec Cache Proxy [Buschmann, 1996] może posłużyć do ukry-cia efektów ubocznych stosowania pamięci podręcznej. Takie roz-wiązanie szczególnie dobrze sprawdza się w implementacjach wzor-ca Smart Proxy [Hohpe, 2003] [Schmidt, 1998] [Object ComputingInteractive, 2004], które przechwytują zdalne wywołania.

Wzorzec projektowy Cache Management (zarządzania pamięciąpodręczną) [Grand, 1998] koncentruje się na sposobie łączeniapamięci podręcznej ze wzorcem Manager (menadżera) [Sommer-lad, 1998], który centralizuje operacje dostępu, tworzenia i nisz-czenia obiektów. Definicja wymienionych wzorców została opra-cowana przede wszystkim z myślą o obiektach i połączeniachz bazami danych w kontekście aplikacji Javy.

Wzorzec Page Cache (pamięć podręczna stron internetowych)[Trowbridge, 2003] jest wyspecjalizowaną wersją wzorca uniwer-salnego Caching, w której skrócono czas odpowiedzi na żądaniadostępu do dynamicznie generowanych stron internetowych. Pa-mięć podręczną stron internetowych wykorzystuje się po stronieserwera WWW — serwer umieszcza w niej strony indeksowanewedług adresów URL. Kiedy serwer WWW ponownie otrzyma żą-danie dostępu do strony znajdującej się pod tym samym adresemURL, wykona odpowiednie zapytanie na swojej pamięci podręczneji zwróci zapisaną tam stronę (zamiast ponownie generować jej dy-namiczną zawartość).

Podziękowania Dziękujemy Ralphowi Cabrera za to, że zechciał się z nami po-dzielić swoim doświadczeniem w zakresie stosowania wzorca pro-jektowego Caching, oraz za to, że wskazał nam konkretny przykładpraktycznego stosowania tego wzorca, system iMerge. Chcieliby-śmy także podziękować Pascalowi Costanza, naszemu opiekunowipodczas konferencji EuroPLoP 2003, za jego bezcenne komenta-rze na temat naszej pracy. Jesteśmy także wdzięczni uczestnikomwarsztatów pisarskich: Frankowi Buschmannowi, Kevlinowi Hen-neyowi, Wolfgangowi Herznerowi, Klausowi Marquartowi, Allano-wi O’Callaghanowi oraz Markusowi Völterowi.