Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00439 007331 10472200 na godz. na dobę w sumie
Zarządzanie zasobami. Wzorce projektowe - książka
Zarządzanie zasobami. Wzorce projektowe - książka
Autor: , Liczba stron: 352
Wydawca: Helion Język publikacji: polski
ISBN: 83-246-0102-3 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> wzorce projektowe
Porównaj ceny (książka, ebook, audiobook).

Techniki implementacji wydajnych mechanizmów zarządzania zasobami

Efektywne zarządzanie zasobami ma kluczowe znaczenie dla funkcjonowania oprogramowania. Niezależnie od tego, czy są to małe systemy instalowane w 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.

Dzięki zawartym w tej książce wiadomościom stworzysz wydajniejsze oprogramowanie.

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

Darmowy fragment publikacji:

IDZ DO IDZ DO PRZYK£ADOWY ROZDZIA£ PRZYK£ADOWY ROZDZIA£ SPIS TREŒCI SPIS TREŒCI KATALOG KSI¥¯EK KATALOG KSI¥¯EK KATALOG ONLINE KATALOG ONLINE ZAMÓW DRUKOWANY KATALOG ZAMÓW DRUKOWANY KATALOG TWÓJ KOSZYK TWÓJ KOSZYK Zarz¹dzanie zasobami. Wzorce projektowe Autorzy: Michael Kircher, Prashant Jain T³umaczenie: Miko³aj Szczepaniak ISBN: 83-246-0102-3 Tytu³ orygina³u: Pattern-Oriented Software Architecture, Patterns for Resource Management Format: B5, stron: 352 DODAJ DO KOSZYKA DODAJ DO KOSZYKA Techniki implementacji wydajnych mechanizmów zarz¹dzania zasobami CENNIK I INFORMACJE CENNIK I INFORMACJE ZAMÓW INFORMACJE ZAMÓW INFORMACJE O NOWOŒCIACH O NOWOŒCIACH ZAMÓW CENNIK ZAMÓW CENNIK CZYTELNIA CZYTELNIA FRAGMENTY KSI¥¯EK ONLINE FRAGMENTY KSI¥¯EK ONLINE (cid:129) Pozyskiwanie zasobów (cid:129) Wykorzystywanie zasobów (cid:129) Zwalnianie zasobów Efektywne zarz¹dzanie zasobami ma kluczowe znaczenie dla funkcjonowania oprogramowania. Niezale¿nie od tego, czy s¹ to ma³e systemy instalowane w 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. (cid:129) Przegl¹d technik zarz¹dzania zasobami (cid:129) Stosowanie wzorców projektowych (cid:129) Wzorce pozyskiwania zasobów (cid:129) Wzorce zarz¹dzania zasobami (cid:129) Wzorce zwalniania zasobów Dziêki zawartym w tej ksi¹¿ce wiadomoœciom stworzysz wydajniejsze oprogramowanie. Wydawnictwo Helion ul. Chopina 6 44-100 Gliwice tel. (32)230-98-63 e-mail: helion@helion.pl Spis treści 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 .....................................................25 1.1. Przegląd technik zarządzania zasobami ............................ 28 1.2. Zakres zarządzania zasobami ........................................... 31 1.3. Stosowanie wzorców ......................................................... 34 1.4. Wzorce w zarządzaniu zasobami ....................................... 35 1.5. Materiały dodatkowe ........................................................ 39 1.6. Format prezentacji wzorca ................................................ 44 2. 3. 4. Pozyskiwanie zasobów .........................................47 Lookup ............................................................................. 50 Lazy Acquisition ............................................................... 70 Eager Acquisition ............................................................. 88 Partial Acquisition .......................................................... 103 Cykl życia zasobów ........................................... 119 Caching ......................................................................... 121 Pooling ........................................................................... 138 Coordinator .................................................................... 155 Resource Lifecycle Manager ............................................ 175 Zwalnianie zasobów ........................................... 197 Leasing .......................................................................... 199 Evictor ........................................................................... 221 !spis-03 5 6 Spis treści 5. Zarządzanie zasobami — praktyczne wskazówki .. 235 6. Studium przypadku: sieć ad hoc ........................ 239 6.1. Pojęcia ogólne ................................................................ 240 6.2. Motywacja ...................................................................... 242 6.3. Rozwiązanie ................................................................... 244 7. Studium przypadku: sieć mobilna ...................... 251 7.1. Pojęcia ogólne ................................................................ 252 7.2. Motywacja ...................................................................... 257 7.3. Rozwiązanie ................................................................... 259 8. Przeszłość, teraźniejszość i przyszłość wzorców projektowych ...................................... 281 8.1. Cztery ostatnie lata w pigułce ......................................... 282 8.2. Obecny stan rozwoju wzorców projektowych ................... 289 8.3. Jaka przyszłość czeka wzorce projektowe? ...................... 290 8.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 6 !spis-03 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ób na 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óry pozwala 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 innymi w wysoce skalowalnych rozwiązaniach korporacyjnych. Wzorzec r03-03 119 120 Cykl życia zasobów projektowy Pooling (zob. strona 138) — podobnie jak wzorzec Caching — optymalizuje procesy pozyskiwania i zwalniania zaso- bów, ale — w przeciwieństwie do tamtego wzorca — nie zachowuje unikatowych identyfikatorów tych zasobów. Wzorzec Pooling jest wię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, wzorzec projektowy Pooling jest bardzo popularny — można bez trudu wskazać przykłady puli komponentów w architekturach kompo- nentowych lub puli wątków w aplikacjach rozproszonych. Wzorce Caching i Pooling mogą być stosowane wyłącznie dla zasobów wielokrotnego 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 Caching lub Pooling także dla współbieżnie wykorzystywanych zasobów wielokrotnego użytku znajduje uzasadnienie. W takim przypadku ani 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 ze sobą 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 uczestnictwa w działaniach skutkujących zmianami. W takim przypadku bar- dzo ważne jest utrzymywanie spójnego stanu systemu mimo zmian generowanych 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 nie spowoduje utraty spójności i jako takie nie obniżą one ogólnej sta- bilności systemu. Wzorzec Resource Lifecycle Manager (zob. strona 175) zarządza wszystkimi zasobami danego systemu informatycznego, co ozna- cza, że zwalnia z obowiązku właściwego zarządzania cyklem życia zasobów zarówno same zasoby, jak i ich użytkowników. Wzorzec projektowy Resource Lifecycle Manager odpowiada za zarządzania cyklem życia wszystkich typów zasobów, włącznie z zasobami wie- lokrotnego użytku i jednorazowego użytku. 120 r03-03 Caching 121 Wzorzec Caching opisuje sposób unikania kosztownych operacji ponownego pozyskiwania zasobów, ponieważ nie zwalnia zasobów zaraz po ich użyciu. Zasoby zachowują swoją identyfikatory i są składowane w pamięci zapewniającej możliwie szybki dostęp. Aby uniknąć konieczności ponownego pozyskiwania zasobów, wzorzec projektowy 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średnictwem warstwy prezentacji, która zwykle ma postać graficznego inter- fejsu użytkownika (GUI). Warstwa środkowa (pośrednicząca), która powinna zawierać całą logikę biznesową, współpracuje zarówno z 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 (za pośrednictwem odpowiednich funkcji interfejsu GUI) wskazać do- wolne elementy sieciowe, aby uzyskać szczegółowe informacje na temat 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. Co więcej, średni czas dostępu do elementu sieciowego byłby bar- dzo długi. r03-03 121 122 Cykl życia zasobów 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 uzyskuje dostęp do tego samego zasobu i — tym samym — wielokrotnie powtarza operacje pozyskiwania i inicjalizacji, koszt wyrażany w 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 zwalniania zasobów. 122 r03-03 Caching 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ć skalowalne · przede 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ącego zasobami systemu operacyjnego). Zasoby w pamięci podręcznej są identyfikowane według unikatowych właściwości (jakichś cech charakterystycznych), a więc wskaźnika, referencji lub klucza głównego. Zachowując często wykorzystywane zasoby i nie zwalniając ich po każdym użyciu, możemy w prosty sposób uniknąć kosztów związanych z ponownymi pozyskiwaniem i wielokrotnym zwalnia- niem. Stosowanie pamięci podręcznej ułatwia też zarządzanie komponentami, 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 dobieranych strategii. 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 przez · ich użytkowników. Dostawca zasobów posiada i zarządza wieloma zasobami. · r03-03 123 124 Cykl życia zasobów 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 ich pierwszego pozyskania przez użytkownika. Użytkownik uzyskuje następnie dostęp do pozyskanych w ten sposób zasobów. Kiedy zasoby nie będą już potrzebne, użytkownik zwraca je do pamięci podrę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 124 r03-03 Caching 125 pozyskiwania bezpośrednio od dostawców) zarówno w wymiarze obciąż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ób zasób jest zwracany do pamięci (zamiast do swojego dostawcy). Kiedy okaże się, że użytkownik ponownie musi uzyskać dostęp do tego samego zasobu, nie korzysta już z dostawcy, tylko od razu pobiera 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 stosunkowo czę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 r03-03 125 126 Cykl życia zasobów obciążenia połączeń sieciowych i — tym samym — czasu potrzeb- nego do wielokrotnego przesyłania danych pomiędzy serwerem a klientem. Z drugiej strony, pamięć podręczna po stronie serwera jest skutecznym rozwiązaniem w sytuacji, gdy liczne żądania wielu klientów dotyczą pozyskiwania i zwalniania tego samego zasobu. 2. Określenie interfejsu pamięci podręcznej. Skoro użytkownik ma zwalniać i ponownie pozyskiwać zasoby bezpośrednio z pa- mięci podręcznej, należy zaprojektować odpowiedni interfejs dla tej 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 identyfikatora na podstawie swoich właściwości (tożsamości)1. Metoda release() jest wywoływana przez użytkownika zasobu w momencie, w którym zdecyduje o zwolnieniu zasobu — zasób jest wówczas zwracany do pamięci podręcznej zamiast do swojego oryginalnego dostawcy. 3. Implementacja pamięci podręcznej. Właściwa implementacja metod 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 ono poza zakres tematyczny niniejszej książki. 126 r03-03 Caching 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 przypadku zasób zawiera już odpowiedni identyfikator. Metoda acquire() naszej implementacji pamięci podręcznej po- winna odpowiadać za odnajdywanie zasobu w strukturze tablicy asocjacyjnej według przekazanego na wejściu identyfikatora. Jeśli operacja pozyskania zasobu z pamięci podręcznej zakończy się niepowodzeniem, co oznacza, że nie udało się znaleźć zasobu z danym identyfikatorem, pamięć podręczna teoretycznie może podjąć próbę pozyskania tego zasobu bezpośrednio od jego do- stawcy. Więcej informacji na ten temat znajdziesz w omówieniu wersji „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ą (krok opcjonalny). 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 Cache Proxy [Buschmann, 1996]. Wprowadzenie któregoś z tych wzor- ców pozwoli ograniczyć złożoność operacji jawnego zwalniania i 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 operacji na zasobach składowanych w pamięci podręcznej znajdziesz r03-03 127 128 Cykl życia zasobów 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ą dodatkowej przestrzeni 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ć albo w ciele metody release(), albo automatycznie, w regularnych odstępach czasu. Tego rodzaju działania mają oczywiście wpływ na łączną przewidywalność systemu. Co więcej, istnieje wiele róż- nych sposobów konfiguracji wzorca projektowego Evictor, który może stosować rozmaite strategie wyboru zasobów przeznaczonych do 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ć wzorcem Strategii [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 wykonujemy operację 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 zmieni się 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 wprowadzane zaró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, że w analizowanym scenariuszu Synchronizer jest istotnym składni- kiem wzorca projektowego Caching. Niektóre implementacje pa- mięci podręcznej dodatkowo optymalizują swoją funkcjonalność, 128 r03-03 Caching 129 Przykładowe rozwiązanie wprowadzając złożoną logikę utrzymywania spójności pomiędzy oryginalnymi zasobami a ich kopiami. Do podejmowania decyzji, kiedy należy synchronizować oryginalny zasó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że też 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 musi zostać odpowiednio zmodyfikowana. Podobnie jeśli użytkownik zmieni ustawienia jakiegoś elementu sieciowego, wprowadzone przez niego zmiany należy uwzględnić na poziomie odpowiedniego urządzenia. Wyobraźmy sobie system zarządzania siecią, którego zadaniem jest 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ększych kosztów jego pozyskiwania od oryginalnego dostawcy. Kolejne połączenia z pozostałymi elementami sieciowymi będą ustanawiane w odpowiedzi na generowane przez użytkowników próby pierwszego dostępu. Kiedy kontekst użytkownika przełą- czy się na inny element sieciowy, połączenie zostanie zwrócone do pamięci (bufora) połączeń. Jeśli jakiś użytkownik zażąda do- stępu do tego samego elementu sieciowego, istniejące połączenie zostanie wykorzystane ponownie. Z dostępem do pozyskanego wcześniej połączenia (występującego w roli zasobu wielokrotnego użytku) nie będą się wiązały żadne dodatkowe opóźnienia. r03-03 129 130 Cykl życia zasobów Wersje Transparent Cache (przezroczysta pamięć podręczna). Jeśli pa- mięć podręczna musi zostać zintegrowana z systemem w sposób przezroczysty, do pozyskiwania zasobów żądanych przez klienta powinniś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 wielokrotne stosowanie wzorca projektowego Partial Acquisition (zob. strona 103), efektywność systemu można znacznie podnieść stosując pamięć 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 kombinacji pamięci podręcznej i puli może być skutecznym sposobem bu- dowy wyrafinowanych rozwiązań zarządzających zasobami. Kiedy zaistnieje 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ę swoistego pośrednika w dostępie do zasobów. Zwykle definiuje się dla takiej pamię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ą tego rozwiązania jest niewielka optymalizacja: jeśli zasób, który nie został 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 serwer WebSphere Application Server (WAS) [IBM (a), 2004] stosuje pa- mięć podręczną w wielu aspektach swojego funkcjonowania. Serwer WAS oferuje możliwość aktywnego przechowywania w pamięci podrę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 130 r03-03 Caching 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 mechanizmu przetwarzania 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ć do znacznej 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 komponenty dostępu do danych, które składują w swojej pamięci podręcznej wyniki zapytań wykonanych na bazie danych. Skutki stosowania 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ęci podręcznej. W przeciwieństwie do wzorca projektowego Pooling (zob. strona 138), pamięć podręczna gwarantuje zachowanie przez 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ć poza pamięcią podręczną — wystarczy odnaleźć odpowiednią pozy- cję w strukturze pamięci podręcznej. · Skalowalność. Jedną z zalet stosowania wzorca projektowego Caching jest brak konieczności każdorazowego pozyskiwania i 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 koszty zwią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 Caching w istotny sposób poprawia skalowalność systemu. r03-03 131 132 Cykl życia zasobów · Złożoność korzystania z zasobów. Stosując pamięć podręczną możemy mieć pewność, że z perspektywy użytkownika zasobów zł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, zasoby w pamięci podręcznej pozostają dostępne dla swoich użytkow- ników. · Stabilność. Ponieważ wzorzec projektowy Caching ogranicza liczbę 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 na konieczność 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 trudniejsze w ś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ększa potrzeby systemu w zakresie zajmowanego obszaru pamięci, ponieważ istnieje ryzyko składowania w pamięci podręcznej niewykorzystanych 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. 132 r03-03 Caching 133 Mechanizm pamięci podręcznej nie jest najlepszym rozwiązaniem w przypadku aplikacji wymagających stałej dostępności danych dla 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 inne próby udoskonalenia, np. optymalizacja operacji pozyskiwania samego zasobu, okażą się nieskuteczne. Pamięć podręczna często jest ź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 po użyciu. Oznacza to, że przed podjęciem decyzji o zastosowaniu tego wzorca należy dokładnie rozważyć wady i zalety w takich aspektach jak wydajność, wykorzystanie zasobów i złożoność systemu. Sprzętowa pamięć podręczna [Smith, 1982]. Niemal wszystkie procesory (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, ale też pomaga ograniczyć obciążenie magistrali. Z tych dwóch powo- dów pamięć podręczna procesora zwykle jest szybsza od pamięci operacyjnej (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 stronie serwera, 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óźnienia związane z pobieraniem danych z serwera. Znane zastosowania r03-03 133 134 Cykl życia zasobów 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ępnianych przez zdalne obiekty). Zdalny obiekt jest przesyłany w całości (przez wartość) pomiędzy klientem a serwerem, dzięki czemu możliwe jest 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ż opisane rozwiązanie w wielu przypadkach poprawia wydajność, należy pamiętać o konieczności zaimplementowania przez użytkownika odpowiednich mechanizmów synchronizacji lokalnej kopii i ory- ginalnego obiektu zdalnego. Serwer proxy dla WWW [Squid Web Proxy Cache, 2004]. Serwer proxy dla WWW (ang. Web proxy) jest po prostu serwerem proxy pracującym pomiędzy przeglądarką internetową a serwerami WWW. Żą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ęcznej i zwraca ją w odpowiedzi na wszystkie kolejne żądania tej samej strony. 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 lokalnej pamię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ęcznej najczęściej otwierane strony WWW. Jeśli użytkownik ponownie zażą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 witryny internetowej. Do określania optymalnego czasu przechowywania stron w pamięci podręcznej (i właściwego momentu ich usuwa- nia) wykorzystuje się mechanizm znaczników czasowych. 134 r03-03 Caching 135 Stronicowanie [Tanenbaum, 2001] [Noble, 2000]. Współczesne systemy operacyjne utrzymują w pamięci tzw. strony, które w wielu sytuacjach pozwalają unikać kosztownych operacji odczytu z dys- kowego pliku wymiany. Można przyjąć, że strony przechowywane w pamięci znajdują się swoistej pamięci podręcznej. Dopiero kiedy nie 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ś powodu połączenie z tymi napędami nie będzie możliwe). Pliki i katalogi są kopiowane do pamięci podręcznej i synchronizowane z zawar- tością oryginalnych dysków sieciowych w momencie nawiązania połączenia z siecią. Najnowsze wersje systemów operacyjnych firmy Microsoft obsługują plikową pamięć podręczną w oparciu o technologię nazwaną Plikami offline. .NET [Richter]. Zbiory danych technologii .NET można traktować jak składowane w pamięci bazy danych. Egzemplarze tych zbiorów są tworzone lokalnie, a za ich wypełnianie danymi odpowiadają zapytania języka SQL przetwarzającej jedną lub wiele tabel bazy danych (za pomocą klasy SqlDataAdapter). Od tego momentu aplikacje 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żyjemy wprost klasy SqlDataAdapter do zaktualizowania odpowiednich tabel. 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) informacje skł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 Object Cache, 2004]. Obiektowa pamięć podręczna jest próbą stosowa- nia wzorca projektowego Caching w warunkach przetwarzania r03-03 135 136 Cykl życia zasobów 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ć przynajmniej część 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 projektowego Caching stosowaną dla danych. Dane są traktowane jak zasób, który w pewnych sytuacjach jest trudny do pozyskania. Takie dane mogą na przykład zawierać skomplikowane i kosztowne obliczenia lub odwołania do innego, zewnętrznego źródła danych. Wzorzec Caching w tej wersji umożliwia wielokrotne wykorzystywanie raz wczytanych danych i — tym samym — eliminuje konieczność ko- sztownego pozyskiwania danych, kiedy okaże się, że są ponownie potrzebne. 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 EMS wykorzystuje 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 nimi istnieje 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ą przypisanych unikatowych 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 samego typu. W przeciwieństwie do wzorca Pooling, we wzorcu Caching każdy zasób składowany w pamięci podręcznej ma przypisany unikatowy identyfikator. Oznacza to, że wzorzec Pooling umożli- wia przezroczyste pozyskiwanie zasobów, natomiast we wzorcu Caching 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. 136 r03-03 Caching 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 Computing Interactive, 2004], które przechwytują zdalne wywołania. Wzorzec projektowy Cache Management (zarządzania pamięcią podręczną) [Grand, 1998] koncentruje się na sposobie łączenia pamię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łączeniach z 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 żądania dostępu do dynamicznie generowanych stron internetowych. Pa- mięć podręczną stron internetowych wykorzystuje się po stronie serwera WWW — serwer umieszcza w niej strony indeksowane według adresów URL. Kiedy serwer WWW ponownie otrzyma żą- danie dostępu do strony znajdującej się pod tym samym adresem URL, wykona odpowiednie zapytanie na swojej pamięci podręcznej i 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ład praktycznego stosowania tego wzorca, system iMerge. Chcieliby- śmy także podziękować Pascalowi Costanza, naszemu opiekunowi podczas konferencji EuroPLoP 2003, za jego bezcenne komenta- rze na temat naszej pracy. Jesteśmy także wdzięczni uczestnikom warsztatów pisarskich: Frankowi Buschmannowi, Kevlinowi Hen- neyowi, Wolfgangowi Herznerowi, Klausowi Marquartowi, Allano- wi O’Callaghanowi oraz Markusowi Völterowi. r03-03 137
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Zarządzanie zasobami. Wzorce projektowe
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ą: