Specykacja techniczna Platformy Informatycznej PCM - PDF\nSpecykacja techniczna Platformy Informatycznej PCM\nDownload "Specykacja techniczna Platformy Informatycznej PCM"\n1 Specykacja techniczna Platformy Informatycznej PCM 30 Maj 2011\n2 Spis tre±ci I Wst p 5 1 Cel dokumentu 6 2 Konwencja pi±miennicza 7 3 Adresat opracowania 8 II Architektura Platformy 9 4 Standard opisu architektury Cele i zaªo»enia architektoniczne Scenariusze bazowe Start systemu Wy±wietlenie komunikatu o bª dzie Sprawdzenie poziomu bezpiecze«stwa kanaªu komunikacyjnego Autoryzacja u»ytkownika Obsªuga» da«obserwatora Obsªuga» da«u»ytkownika, ze zmian widoku Obsªuga» da«u»ytkownika, bez zmiany widoku Obsªuga» da«systemów informatycznych Obsªuga wydarze«systemowych Widok logiki biznesowej (Logic View) Widok procesów (Process View) Widok przynale»no±ci sprz towej (Physical View) III Opis Rozwi zania 30 5 Platforma aplikacyjna Wymagania Porównanie wybranych rozwi za« PHP Symfony Ocena rozwi zania\n3 SPIS TRE CI ucommon C Ocena rozwi zania CrissCross framework Ocena rozwi zania PureMVC Ocena rozwi zania GlassFish Ocena rozwi zania JBoss Ocena rozwi zania Geronimo Ocena rozwi zania Ruby on Rails (RoR) Ocena rozwi zania Wybrane rozwi zanie Aplikacja kliencka Wymagania Porównanie wybranych rozwi za« Dynamicznie strony Ocena rozwi zania Adobe Flex/Flash Ocena rozwi zania Aplet Java/JavaFX Ocena rozwi zania Wybrane rozwi zanie Aplikacja administratora Wymagania Porównanie wybranych rozwi za« Dynamicznie strony Ocena rozwi zania Aplikacja Adobe Flex/Flash Ocena rozwi zania Aplet Java/JavaFX Ocena rozwi zania Wybrane rozwi zanie Platforma bazodanowa Wymagania Porównanie dost pnych rozwi za« Klaster MySQL Ocena rozwi zania\n4 SPIS TRE CI Oracle RAC Ocena rozwi zania PostgreSQL Bucardo Ocena rozwi zania Postgres-XC Ocena rozwi zania Wybrane rozwi zanie IV Rozwi zanie sprz towe 63 9 Serwery aplikacyjne Wymagania Ilo± Serwery bazodanowe Wymagania Ilo± Firewall Wymagania Ilo± Przeª cznik KVM Wymagania Ilo± Aktywne elementy sieci teleinformatycznej (switch) Wymagania Ilo± Zabezpieczenie ª cza energetycznego Wymagania Ilo± Bibliograa 74\n5 Spis rysunków 4.1 Widok logiki biznesowej Widok przepªywu informacji Widok procesów - przetwarzanie akcji zainicjowanej przez zewn trzny system Widok przynale»no±ci sprz towej Architektura klastra MySQL Architektura Oracle RAC Funkcjonalno± RAC\n6 Cz ± I Wst p 5\n7 Rozdziaª 1 Cel dokumentu Celem niniejszego dokumentu jest zaprezentowanie opisu rozwi zania technicznego, pozwalaj cego urzeczywistni ide Platformy PCM, której wymagania funkcjonalne i niefunkcjonalne zostaªy opisane w . W dokumencie mo»na wyró»ni dwie podstawowe cz ±ci: ˆ opis architektury - zawieraj cy opis zale»no±ci pomi dzy poszczególnymi elementami systemu ˆ opis rozwi zania technicznego - zawieraj cy szczegóªowy opis techniczny pozwalaj cy na zbudowanie dziaªaj cego systemu o zadanych parametrach wydajno±ciowych oraz speªniaj cego wyspecykowane wymagania niefunkcjonalne Opis architektury zostaª dodany po rozmowach z reprezentatem Instytutu Immunologii i Terapii Do±wiadczalnej PAN we Wrocªawiu, jako uzupeªnienie opisu systemu PCM o zale»no±ci wynikaj ce z wymaga«postawionych przed nim. Dlatego te» niniejszy dokument nale»y traktowa jako kompilacj specykacji technicznej z opisem architektury softwarowej Platformy. Dzi ki takiemu poª czeniu funkcji, niniejszy dokument nie tylko opisuje proponowane rozwi zania, ale pozwala zrozume kryteria jakimi kierownano si przy ich wyborze. Architekura systemu zostaªa oparta o tzw. wzorzec N+1 widoków, który zostaª wyprowadzony jako rozszerzenie idei opisanych w . 6\n8 Rozdziaª 2 Konwencja pi±miennicza W dokumencie przyj to jednolit konwencj pi±miennicz pozwalaj c wyró»ni szczególne istotne elementy opisu. ˆ Symbole i nazwy wªasne podjednostek systemu (domen, podsystemów) oraz jego charakterystycznycznych elementów zostaªy zapisane za pomoc pogubionej czcionki, np. Platforma. ˆ Symbole rozpoczynaj si zawsze wielk liter. ˆ Symbole mog by opisywane za pomoc pojedynczego rzeczownika, lub grupy rzeczownikowej. W pierwszym przypadku caªy rzeczownik wykorzystywany jest jako symbol, np. Platforma, w przypadku grupy rzeczownikowej wykorzystywany jest skrót skªadaj cy si z tylko z pierwszych liter poszczególnych wyrazów lub ich okre±lonych fragmentów, np. MBiol. ˆ Symbole wykorzystuj ce skróty wyrazowe lub ich fragmenty zako«czone s kropk, np. MBiol. ˆ Symbole opisywane za pomoc pojedynczego rzeczownika s odmieniane wg. reguª obowi zuj cych w j zyku Polskim, np. [...] w przypadku Platformy [...] ˆ Symbole opisywane za pomoc skrótów literowych lub fragmentów wyrazów nie s odmieniane, np. odbieraj c MBiol. [...] ˆ Lista i opis wszystkich symboli jest umieszczony na ko«cu dokumentu ˆ Wyrazy pisany czcionk zwykª (niepogrubion ) nie posiadaj znaczenia symbolu, a jedynie zwykªe, sªownikowe znaczenie wyrazu ˆ Wyra»enia pisane za pomoc czcionki pochylonej, obrazuj obiekty klas. S to albo tzw. klasy dziedziny - rzeczywistych obiektów obrazuj cych zachowanie systemu, albo klas obiektów programistycznych, które s wykorzystane w przypadku opisu przypadków u»ycia (ang. use case), np. Kontroler. 7\n9 Rozdziaª 3 Adresat opracowania Niniejsze opracowanie jest adresowane gªównie do przyszªego menad»era projektu jako tzw. blueprint (wzór) systemu. Dodatkowo powinien on zosta przestudiowany przez przyszªych in»ynierów systemu, zajmuj cych si przygotowaniem i utrzymaniem infrastruktury sprz towej. Powinien on, wraz ze list wymaga«funkcjonalnych i niefunkcjonalnych () pozwoli na oszacowanie kosztów systemu na podstawie oceny jego zªo»ono±ci oraz stanowi podstaw do wyznaczenia terminów zako«czenia poszczególnych etapów jego budowy oraz opracowania terminarza udost pnienia ich potencjalnych u»ytkownikom, w tym pracownikom kolekcji PCM zorganizowanej wokóª Intytutu Immunologii i Intensywnej Terapii PAN we Wrocªawiu. Do peªnego zrozumienia informacji zawartych w niniejszym dokumencie niezb dna jest specjalistyczna wiedza informatyczna, dlatego te» mo»e on mie mniejsze znaczenie poznawcze dla pracowników PCM lub innych u»ytkowników systemu, jakkolwiek równie» taki typ u»ytkownika mo»e znale± tutaj opis pozwalaj cy na werykacj poprawno±ci budowy i dziaªania Platformy. Ninejszy dokument powinien tak»e by u»yteczny dla programistów pracuj cych nad rozwojem systemu, szczególnie opis architektury Platformy wydaje si by istotny do peªnego zrozumienia interakcji pomi dzy jego podzespoªami, jego umiejscowienia na poszczególnych urz dzeniach oraz przypisania poszczególnych komponentów do konkretnych procesów/tasków systemu operacyjnego. 8\n10 Cz ± II Architektura Platformy 9\n11 Rozdziaª 4 Standard opisu architektury W niniejszym opracowaniu przyj to opis architektury software'owej wedªug standardu: N+1 Views. Idea tego standardu opisu architektury oprogramowania wywodzi si z pracy Kuchten  Views. W wersji oryginalnej opieraªa si on na opisie czterech widoków systemu, ka»dy z nich skupiaj cym si na jednym aspekcie systemu. Wyró»nia si nast puj ce typu widoków systemu: ˆ widok logiki biznesowej (ang. logic view) ˆ widok procesów (ang. process view) ˆ widok zale»no±ci komponentowej (ang. development view) ˆ widok przyporz dkowania sprz towego (ang. physical view) Dodatkowo, widokiem +1 jest widok scenariuszy, który zawiera scenariusze wysokopoziomowe systemu, pozwalaj ce na werykacj poprawno±ci w/w widoków, oraz pozwalaj cych zrozumie relacje pomi dzy ró»nymi widokami. W niniejszym dokumencie przyj to swobodniejszy model opisu architektury, gdzie nie podaje si ilo±ci ani typów widoków architektonicznych, a jedynie zakªada si podobn iteracyjn formuª : 1. wybór scenariuszy 2. przedstawienie scenariuszy za pomoc kilku wybranych widoków 3. uzupeªnienie widoków o logicznie wymagane detale dziaªania systemu 4. dobór lub rozszerzenie scenariuszy bazowych. Tak jak w oryginalnej pracy, scenariusze opisane w niniejszym dokumencie s tzw. scenariuszami wysokopoziomowymi, tj. opisuj cymi istotne aspekty systemu, ale tylko na du»ym poziomie abstrakcji, bez wnikania w detale rozwi za«opisanych ju» w zebranych wymaganiach systemu (). Scenariusze s opisane w sposób zbli»ony do sposobu w jaki zostaªy opisane w , tj. za pomoc przypadków u»ycia (ang. use cases). Ich ilo± 10\n12 ROZDZIAŠ 4. STANDARD OPISU ARCHITEKTURY 11 zostaªa dobrana tak by przedstawi wszystkie istotne wªa±ciwo±ci Platformy, zgodnie z zebran list wymaga«. Wszystkie typy widoków wraz z opisanymi scenariuszami maj na celu uwidocznienie struktury Platformy, pomijaj c szczegóªy przyszªej implementacji. Proces tworzenia architektury Platformy byª procesem iteracyjnym - na podstawie wybranych scenariuszy wygenerowano pozostaªe cztery widoki systemu, które nast pnie uzupeªniono o szczegóªy wynikaj ce z zale»no±ci pomi dzy poszczególnymi widokami. Na podstawie uzupeªnionych widoków oraz listy wymaga«dobrano kolejne scenariusze, które ponownie wykorzystano do poprawienia widoków architektury systemu. Zgodnie z ogólnymi zasadami postawionymi przed opisem architektury aplikacji, tak»e i w tym opracowaniu stosowano nast puj ce zasada opisu: ˆ Ekspozycja struktury systemu, ale ukrycie szczegóªów implementacji. ˆ Realizacja wszystkich przypadków u»ycia oraz scenariuszy. ˆ Uwzgl dnienie wymaga«wysuni tych przez ró»nych u»ytkowników Platformy. ˆ Speªnienie zarówno wymaga«funkcjonalnych jak i niefunkcjonalnych. 4.1 Cele i zaªo»enia architektoniczne ˆ Platforma ma by przygotowana na przyszªe zmiany (rozszerzenia), a nie traktowana jako rozwi zanie ostateczne. Proponowana architektura Platformy musi uwzgl dnia potrzeb zmian w jej funkcjonalno±ci poprzez dodanie lub mody- kacj wymaga«funkcjonalnych oraz niefunkcjonalnych. Platforma musi by zaprojektowana elastycznie, aby móc pod»a za zmianami wymaga«wªa±ciciela i u»ytkowników. ˆ Projektowana Platforma nie mo»e dopuszcza, aby awaria pojedynczego element Platformy mogªa skutkowa awari caªego systemu (ang. single point of failure) - zaªo»enie to dotyczy zarówno warstwy aplikacyjnej jak i sprz towej. ˆ Architektura nie mo»e zwi zywa projektowanego rozwi zania z konkretnym producentem lub rozwi zaniem. Oczywi±cie proponowane rozwi zanie b dzie wykorzystywaªo rozwi zania konkretnego producenta (producentów), ale w zaªo»eniu musi pozwala na zmian producenta sprz tu lub oprogramowania na inne, speªniaj ce te same wymagania (posiadaj ce podobne wªa±ciwo±ci), lub na uzupeªnienie istniej cej infrastruktury o rozwi zanie innego producenta. ˆ Platforma ma by wysoce wydajna i prawie liniowo skalowalna. Projekt Platformy zakªada jej dynamiczny rozwój w okresie najbli»szych 2-5 lat. Rozwój ten zakªada kilkukrotne zwi kszenie ilo±ci gromadzonych i przetwarzanych danych, dlatego jest istotne nawet cz ±ciowe przeskalowanie wydajno±ci Platformy, tj.\n13 ROZDZIAŠ 4. STANDARD OPISU ARCHITEKTURY 12 przygotowanie architektury na znacznie wi ksz ilo± danych ni» obecnie zawiera kolekcja PCM. ˆ Platforma musi uwzgl dnia mo»liwo± niezale»nego skalowania jej pojemno±ci (ilo±ci zgromadzonych danych) od skalowania mocy obliczeniowej potrzebnej do przetwarzania danych i obsªugi poª cze«zewn trznych. ˆ Architektura musi uwzgl dnia potrzeb minimalizowania wyª czenia Platformy do celów serwisowych lub w przypadku wymaganego upgrade'u. Istotna w speªnieniu tego zaªo»enia jest tu nie tylko ilo± potencjalnych wyª cze«systemu potrzebnych do dokonania danej operacji ale tak»e sumaryczny czas niedost pno±ci systemu dla u»ytkowników. 4.2 Scenariusze bazowe Ni»ej opisane scenariusze dziaªania systemu zostaly wyselekcjonowane w celu przedstawienia najbardziej kluczowych funkcjonalno±ci systemu Platformy. W opisie tzw. przypadków u»ycia wykorzystano pewne wyra»enia, opisuj ce logiczne moduªy systemu. Wprowadzono je w celu przedstawienia pewnych podstawownych funkcjonalno±ci systemu. Ich wzajemne relacje mo»na zaobserwowa na widokach architektonicznych zawartych w poni»szych rozdziaªach. Komponenty systemowe wykorzystane do opisu systemu to: ˆ Kontroler - obrazuje obiekt odpieraj cy i przekierowuj cy» dania przychodz ce od u»ytkowników lub od innych obiektów systemu Platformy ˆ Obserwator - obrazuje obiekt ±ledz cy zmiany zachodz ce w systemie Platformy, i wysyªajacy» dania obsªugi tych wydarze«do Kontrolera ˆ Procesor - obrazuje obiekt zajmuj cy sie przetwarzaniem okre±lonego zapytania ˆ Widok - obrazuje kontener zawieraj cy szczegóªy pozwalaj ce na wygenrowanie peªnego widoku (ekranu) aplikacji ˆ obiekt» dania (» danie) - obrazuje kontener zawieraj cy szczegóªy» dania ˆ obiekt danych (dane) - obrazuj pewien kontener zawieraj cy okre±lone dane\n14 ROZDZIAŠ 4. STANDARD OPISU ARCHITEKTURY Start systemu Id : UC-SS Nazwa : start systemu Aktorzy : - Rozszerza : - Wywoªany przez : uruchomienie serwerów aplikacyjnych Warunki wst pne : ˆ skongurowane i uruchomiony system bazy danych Opis : ˆ skongurowane serwery aplikacyjne 1. system operacyjny uruchamia platform (framework) aplikacyjn 2. framework synchronizuje dane Platformy PCM pomi dzy poszczególnymi w zªami 3. framework uruchamia system Platformy PCM 4. Platforma PCM inicjalizuje swoje gªównie komponenty: (a) Obserwator (b) Kontroler 5. Obserwator zapisuje do bazy danych stan systemu, dat uruchomienia, itp. 6. framework inicjalizuje funkcj serwera WWW, serwera obiektów binarnych (ROS - Remote Object Server) Stan ko«cowy : Wyj tki : 7. Platforma PCM jest gotowa do obsªugi» da«system jest przygotowany do obsªugi» da«ˆ brak poª czenia pomi dzy serwerami bazy danych a serwerami aplikacyjnymi ˆ niepoprawnie uruchomiony lub nieuruchomiony system bazy danych\n15 ROZDZIAŠ 4. STANDARD OPISU ARCHITEKTURY Wy±wietlenie komunikatu o bª dzie Id : UC-WKOB Nazwa : Wy±wietlenie komunikatu o bª dzie Aktorzy : u»ytkownik Rozszerza : - Wywoªany przez : inne obiekty systemu Warunki wst pne : ˆ skongurowane i uruchomiony system bazy danych Opis : ˆ skongurowane serwery aplikacyjne ˆ znany jest rodzaj Widoku odpowiedzialnego za pokazanie komunikatu o bª dzie ˆ znany jest kod bª du ˆ znany jest komunikat o bª dzie 1. Procesor tworzy Widok 2. Procesor uzupeªnia Widok o opis bª du 3. Procesor przekazuje gotowy Widok Kontrolerowi 4. Kontroler odsyªa Widok u»ytkownikowi Stan ko«cowy : Wyj tki : 5. Widok zostaje wy±wietlony u»ytkownikowi informacja o bª dzie zostaªa pokazana u»ytkownikowi ˆ brak poª czenia pomi dzy serwerami bazy danych a serwerami aplikacyjnymi ˆ niepoprawnie uruchomiony lub nieuruchomiony system bazy danych ˆ utrata poª czenia z u»ytkownikiem\n16 ROZDZIAŠ 4. STANDARD OPISU ARCHITEKTURY Sprawdzenie poziomu bezpiecze«stwa kanaªu komunikacyjnego Id : UC-SPBKK Nazwa : Sprawdzenie poziomu bezpiecze«stwa obiektu» dania Rozszerza : - Aktorzy : system Wywoªany przez : inny przypadek u»ycia, który musi rozró»nia czy typ» dania pozwala na odesªanie okre±lonych danych (ogólnodost pnych lub danych chronionych) Warunki wst pne : system Platformy PCM jest uruchomiony Opis : 1. Procesor otrzymaªa» danie sprawdzenia poziomu bezpiecze«stwa kanaªu komunikacyjnego dla danego obiektu» - dania. 2. Procesor sprawdza czy dostarczono obiekt» dania. 3. je»eli obiekt» dania nie zostaª dostarczony lub jest niepoprawny (przeterminowany) - Procesor odsyªa ogólnodost pny typ» dania 4. Procesor sprawdza czy» danie zostaªo przesªane poprzez jeden z kanaªów oznaczonych jako bezpieczny (np. https). 5. je»eli» danie zostaªo wysªane poprzez kanaª niewyst puj cy na li±cie kanaªów bezpiecznych, Procesor zwraca ogólnodost pny typ» dania. 6. je»eli» danie zostaªo wysªane przez kanaª wyst puj cy na li±cie kanaªów bezpiecznych, Procesor sprawdza czy wszystkie niezb dne wªasno±ci wymagane dla danego kanaªu zostaªy speªnione, np. dla https, werykuje certykat serwera, i/lub certykat u»ytkownika. 7. je»eli werykacja wªasno±ci kanaªu, poprzez który zostaªo wysªane» danie nie powiodªo si, Procesor zwraca ogólnodost pny typ» dania Stan ko«cowy : Wyj tki : 8. je»eli werykacja wªasno±ci kanaªu, przez który zostaªo wysªane» danie powiodªa si, Procesor zwraca bezpieczny typ» dania. obiekt» dania uzyskaª certykat typu kanaªu komunikacyjnego ˆ brak poª czenia pomi dzy serwerami bazy danych a serwerami aplikacyjnymi ˆ niepoprawnie uruchomiony lub nieuruchomiony system bazy danych\n17 ROZDZIAŠ 4. STANDARD OPISU ARCHITEKTURY Autoryzacja u»ytkownika Id : UC-AU Nazwa : Autoryzacja u»ytkownika Rozszerza : - Aktorzy : u»ytkownik Wywoªany przez :» danie autoryzacji - poprzez GUI Warunki wst pne : system Platformy PCM jest uruchomiony\n18 ROZDZIAŠ 4. STANDARD OPISU ARCHITEKTURY 17 Opis : 1. Kontroler otrzymaª» danie autoryzacji 2. Kontroler wywoªuje UC-SPBKK 3. Kontroler tworzy obiekt Procesora i przekazuje mu obiekt» dania 4. Procesor sprawdza czy wraz z» daniem autoryzacji dostarczono dane u»ytkownika: (a) nazw u»ytkownika (b) hasªo u»ytkownika 5. je»eli której± z informacji brakuje - Procesor odsyªa informacj o odmowie dost pu do Kontrolera 6. Kontroler wykonuje UC-WKOB 7. je»eli oba pola s dost pne - Procesor wyszukuje w bazie danych informacji nt. danego u»ytkownika. 8. je»eli u»ytkownik o podanej nazwie nie wyst puje w bazie danych - Procesor odsyªa informacj o odmowie dost pu do Kontrolera 9. Kontroler wykonuje UC-WKOB 10. je»eli konto u»ytkownika o podanej nazwie zostaªo zawieszone (jest nieaktywne) - Kontroler wykonuje UC-WKOB 11. je»eli u»ytkownik o podanej nazwie istnieje i jego konto jest aktywne Procesor wywoªuje UC-SPBKK 12. je»eli UC-SPBKK zwraca informacj,»e» danie autoryzacji przeprowadzono przez ogólnodost pny kanaª autoryzacji (a) Procesor odsyªa informacj o odmowie dost pu do Kontrolera (b) Kontroler wykonuje UC-WKOB 13. je»eli UC-SPBKK zwraca informacj,»e» danie autoryzacji przeprowadzono przez kanaª bezpieczny - Procesor wyznacza podpis hasªa za pomoc funkcji haszuj cej, a nast puje porównuje warto± wyliczon i otrzyman w» - daniu 14. je»eli warto±ci nie s identyczne - Kontroler wykonuje UC- WKOB 15. je»eli warto±ci s identyczne - Kontroler odsyªa informacj o uzyskaniu dost pu oraz tworzy obiekt sesji dla danego poª czenia gdzie zapisuje m.in nazw zalogowanego u»ytkownika\n19 ROZDZIAŠ 4. STANDARD OPISU ARCHITEKTURY 18 Stan ko«cowy : Wyj tki : przygotowane s dane sesji po stronie serwera, u»ytkownik uzyskaª dost p do danych systemu ˆ brak poª czenia pomi dzy serwerami bazy danych a serwerami aplikacyjnymi Obsªuga» da«obserwatora ˆ niepoprawnie uruchomiony lub nieuruchomiony system bazy danych Id : UC-O O Nazwa : Obsªuga» da«obserwatora Rozszerza : - Aktorzy : u»ytkownik Wywoªany przez :» danie obsªugi - poprzez GUI Warunki wst pne : ˆ system Platformy PCM jest uruchomiony\n20 ROZDZIAŠ 4. STANDARD OPISU ARCHITEKTURY 19 Opis : 1. Kontroler otrzymuje» danie od Obserwatora 2. Na podstawie typu» dania Kontroler tworzy odpowiedni obiekt Procesora 3. Procesor pobiera dane wymagane do wykonania» dania 4. Procesor sprawdza czy obsªuga» dania wymaga powiadomienia odpowiednich u»ytkowników 5. je»eli nie - Procesor przetwarza» dania (a) je»eli» danie polegaªo na przetworzeniu danych - Procesor wylicza odpowiednio warto± ko«cow i skªaduje j w bazie danych (b) je»eli» danie wymaga zmiany stanu systemu Platformy PCM, Procesor powiadamia Kontroler o zaprzestaniu przyjmowania» da«, oraz wysyªa informacj do innych obiektów o zmianie stanu sytemu. (c) je»eli» danie przywraca stan dziaªania Platformy PCM, Procesor przywraca resetuje stan wszystkich obiektów systemu, a nast pnie wysyªa» danie do Kontrolera o przywrócenie przyjmowania» da«6. je»eli tak, Procesor tworzy odpowiedni obiekt Widoku a nast pnie uzupeªnia go o przetworzone dane pobrane wcze±niej 7. Procesor przekazuje Kontrolerowi utworzony obiekt Widoku uzupeªniony o dane wraz z informacj nt. typu u»ytkowników, którzy maj by powiadomieni. 8. Kontroler przegl da list aktywnych obiektów sesji, wyszukuj c te, których u»ytkownicy powinni zosta powiadomieni o zaistniaªym wydarzeniu. 9. Kontroler wysyªa do wybranych u»ytkowników wiadomo± o potrzebie pobrania informacji o stanie systemu, wraz z identykatorem pobrania (kluczem). 10. Kontroler otrzymuje» danie pobrania informacji o systemie od ka»dego z powiadomionych u»ytkowników 11. Kontroler sprawdza czy identykator pobrania zgadza si z wysªanym wcze±niej kluczem 12. je»eli identykator wysªany i odebrany jest taki sam, Kontroler odsyªa przygotowany wcze±niej obiekt Widoku wypeªniony odpowiednimi danymi. 13. je»eli nie - Kontroler wykonuje UC-WKOB\n21 ROZDZIAŠ 4. STANDARD OPISU ARCHITEKTURY 20 Stan ko«cowy : Wyj tki : dane, b d ce efektem wykonania» dania u»ytkownika zostaªy przesªane u»ytkownikowi ˆ brak poª czenia pomi dzy serwerami bazy danych a serwerami aplikacyjnymi ˆ niepoprawnie uruchomiony lub nieuruchomiony system bazy danych ˆ zerwanie poª czenia z systemem komputerowym u»ytkownika przed wysªaniem danych Obsªuga» da«u»ytkownika, ze zmian widoku Id : UC-O U-ZZW Nazwa : Obsªuga» da«u»ytkownika Rozszerza : - Aktorzy : u»ytkownik Wywoªany przez :» danie obsªugi - poprzez GUI Warunki wst pne : ˆ system Platformy PCM jest uruchomiony\n22 ROZDZIAŠ 4. STANDARD OPISU ARCHITEKTURY 21 Opis : 1.» danie traa do obiektu Kontrolera, który sprawdza czy» danie mo»e zosta wykonane bez autoryzacji u»ytkownika 2. je»eli tak - na podstawie typu» dania tworzony jest obiekt Procesora, który rozpoczyna analiz danych. 3. je»eli nie - Procesor sprawdza czy» danie pochodzi z sesji, dla której istnieje ju» obiekt sesji, t.j. u»ytkownik zostaª poprawnie zautoryzowany (a) je»eli nie - Kontroler w odpowiedzi przesyªa przekierowanie na stron autoryzacyjn (b) je»eli tak - Kontroler sprawdza czy sesja jest prawidªowa i czy» danie zostaªo wysªane za pomoc bezpiecznego kanaªu komunikacyjnego (UC-SPBKK) i tworzy obiekt Procesora, który rozpoczyna analiz danych i. je»eli Kontroler wykryje nieprawidªowo±ci w obiekcie danych, np. sesja jest przeterminowana, niszczy obiekt sesji i w odpowiedzi przesyªa przekierowanie na stron autoryzacyjn. ii. je»eli Kontroler wykryje nieprawidªowy typ kanaªu komunikacyjnego, niszczy obiekt sesji i przesyªa w odpowiedzi przekierowanie na stron autoryzacyjn 4. Procesor sprawdza czy wszystkie potrzebne dane s dost pne 5. je»eli tak - Procesor przyst puje do przetwarzania danych 6. je»eli nie - Procesor tworzy obiekt odpowiedniego Widoku, i wraz z komunikatem bª du odsyªa go do u»ytkownika 7. w ramach przetwarzania» dania, Procesor pobiera niezb dne dane z bazy danych oraz tworzy odpowiedni obiekt Widoku. 8. Procesor uzupeªnia obiekt Widoku o odpowiednie dane, dokonuj c stosownych przeksztaªce«lub wylicze«. 9. Procesor odsyªa ko«cowy rezultat, czyli obiekt Widoku uzupeªnionego o pobrane i przetworzone dane do Kontrolera 10. Kontroler przysyªa otrzymany obiekt Widoku u»ytkownikowi\n23 ROZDZIAŠ 4. STANDARD OPISU ARCHITEKTURY 22 Stan ko«cowy : Wyj tki : efekt wykonania» dania zostaª przesªany u»ytkownikowi ˆ brak poª czenia pomi dzy serwerami bazy danych a serwerami aplikacyjnymi ˆ niepoprawnie uruchomiony lub nieuruchomiony system bazy danych ˆ zerwanie poª czenia z systemem komputerowym u»ytkownika przed wysªaniem danych i widoku Obsªuga» da«u»ytkownika, bez zmiany widoku Id : Nazwa : Rozszerza : Aktorzy : Wywoªany przez : Warunki wst pne : Opis : UC-O U-BZW Obsªuga» da«u»ytkownika UC-O U-ZZW u»ytkownik» danie obsªugi - poprzez GUI ˆ system Platformy PCM jest uruchomiony 1. punkty 1-6 wykonane s identycznie 2. w ramach przetwarzania» dania, Procesor pobiera niezb dne dane z bazy danych 3. Procesor dokonuje stosownych przeksztaªce«lub wylicze«na pobranych danych 4. Procesor tworzy obiekt Danych, który uzupeªnia o ko«cowy rezultat(y), a nast pnie przesyªa go do Kontrolera Stan ko«cowy : Wyj tki : 5. Kontroler odsyªa obiekt Danych do u»ytkownika dane, b d ce efektem wykonania» dania u»ytkownika zostaªy przesªane u»ytkownikowi ˆ brak poª czenia pomi dzy serwerami bazy danych a serwerami aplikacyjnymi ˆ niepoprawnie uruchomiony lub nieuruchomiony system bazy danych ˆ zerwanie poª czenia z systemem komputerowym u»ytkownika przed wysªaniem danych Obsªuga» da«systemów informatycznych Id : Nazwa : UC-O SI Obsªuga» da«systemów informatycznych\n24 ROZDZIAŠ 4. STANDARD OPISU ARCHITEKTURY 23 Rozszerza : - Aktorzy : zewn trzny system informatyczny Wywoªany przez :» danie obsªugi - wysªane przez zewn trzny system Warunki wst pne : system Platformy PCM jest uruchomiony Opis : 1. autoryzacja u»ytkownika - UC-AU (autoryzowanym u»ytkownikiem jest tzw. u»ytkownik systemowy, posiadaj cy tak»e swoje dane autoryzacyjne) 2. je»eli autoryzacja u»ytkownika systemowego nie powiodªa si - Kontroler tworzy obiekt Procesora, który generuje odpowiednio sformatowany obiekt bª du. (a) Procesor odsyªa obiekt bª du do Kontrolera, który przesyªa go do zewn trznego systemu - nadawcy (b) Kontroler zamyka kanaª komunikacyjny i niszczy obiekt sesji 3. je»eli autoryzacja u»ytkownika systemowego powiodªa si - Kontroler tworzy obiekt Procesora i przekazuje mu obiekt» dania 4. Procesor sprawdza uprawnienia danego systemu do wykonania danego typu» da«5. je»eli dany system nie ma wystarczaj cych uprawnie«do wykonania danego» dania, Procesor tworzy obiekt bª du i odsyªa go do Kontrolera (a) Kontroler wywoªuje UC-WKOB 6. je»eli dany system ma uprawnienia pozwalaj ce na wykonanie danego» dania Procesor tworzy obiekt Danych Stan ko«cowy : (a) Procesor pobiera dodatkowo niezb dne dane z bazy danych i uzupeªnia nimi obiekt Danych (b) Procesor przekazuje gotowy obiekt Danych Kontrolerowi (c) Kontroler odsyªa obiekt Danych do systemu nadawczego. dane, b d ce efektem wykonania» dania zostaªy przesªane do zewn trznego systemu informatycznego\n25 ROZDZIAŠ 4. STANDARD OPISU ARCHITEKTURY 24 Wyj tki : ˆ brak poª czenia pomi dzy serwerami bazy danych a serwerami aplikacyjnymi Obsªuga wydarze«systemowych ˆ niepoprawnie uruchomiony lub nieuruchomiony system bazy danych ˆ zerwanie poª czenia z zewn trznym systemem informatycznym przed wysªaniem danych Id : UC-OWS Nazwa : Obsªuga wydarze«systemowych Rozszerza : - Aktorzy : system Platformy PCM Wywoªany przez : wydarzenie systemowe Warunki wst pne : system Platformy PCM jest uruchomiony Opis : 1. Obserwator budzi si ze stanu u±pienia 2. Obserwator sprawdza list natychmiastowych zada«systemowych 3. Obserwator sprawdza list zaplanowanych zada«systemowych 4. je»eli którakolwiek lista zawiera zadania do wykonania 5. LOOP [dla ka»dego zadania]: (a) Obserwator przygotowuje obiekt» dania (b) Obserwator wysyªa obiekt» dania do Kontrolera Stan ko«cowy : Wyj tki : 6. Obserwator przechodzi w stan u±pienia na okre±lony czas (sugerowany czas: 30 sec) system jest przygotowany do obsªugi wydarze«ˆ brak poª czenia pomi dzy serwerami bazy danych a serwerami aplikacyjnymi ˆ niepoprawnie uruchomiony lub nieuruchomiony system bazy danych 4.3 Widok logiki biznesowej (Logic View) Widok logiki biznesowej przedstawia zale»no±ci mi dzy moduªami systemu, obrazuj - cymi pewne koncepcje domenowe. Jest to tzw. model statyczny, który ma za zadanie\n26 ROZDZIAŠ 4. STANDARD OPISU ARCHITEKTURY 25 przedstawi relacje pomi dzy posczególnymi komponentami. Relacje przedstawione w tym widoku to relacje typu: argregacja lub kompozycja, oraz relacje wykorzystania (ang. uses) danego pakietu przez inny. W diagramie, jak i w caªym dokumencie u»yto notacji zgodnej z UML 2.0. Na rysunku, centralnym elementem systemu jest Kontroler, który odbiera wiadomo±ci o wydarzeniach wewn trz systemu, jak i wydarzeniach przychodz cych z zewn trz (nie przedstawionych). Jego funkcj jest znalezienie odpowiedniego wykonawcy dla danego» dania. W tym celu posiada list Procesorów, obiektów, które zajmuj si przetworzeniem» dania. Ka»dy z nich, oprócz wbudowanej wiedzy nt. przetwarzanego» dania posiada list Widoków, obiektów, które posiadaj caªo± informacji pozwalaj - cych wygenerowa po stronie u»ytkownika peªny widok (ukªad ekranowy). Procesor, dodatkowo posiada list obiektów Danych, które zostaªy pobrane z systemu bazodanowego (nie pokazanego na rysunku). Dzi ki posiadaniu obiektu z opisem Widoku, obiektu z wymaganymi Danymi, oraz samego» dania, obiekt Procesora jest w stanie nie tylko przetworzy dane, ale równie» przygotowa informacj zwrotn dla u»ytkownika. Jedynym ¹ródªem wiadomo±ci pochodz cym z wewn trz systemu jest Obserwator, obiekt który przez wi kszo± czasu jest u±piony, ale potra si zreaktywowa aby obsªu»y wydarzenie systemowe. Obserwator potra tak»e pracowa jak tzw. scheduler, tj. uruchamia okre±lone zadania wg. przekazanej listy zada«oraz wymaganego czasu uruchomienia. W obu przypadkach Obserwator wykonuje dwie czynno±ci: odczytuje lub zapisuje obiekt Stanu Systemu, b d cym swego rodzaju dziennikiem systemowym oraz inicjatorem zmian zachodz cych w systemie, oraz przekazuje» danie wykonania zadania Kontrolerowi. <<komponent>> Obiekt Stanu Systemu 0..* <<komponent>> Obserwator Systemu 1 <<komponent>> Widok inicjuj akcje 1..* <<komponent>> Procesor <<komponent>> Kontroler 1 1 <<komponent>> Obiekt Danych Widoku 1 1..* 0..* Rysunek 4.1: Widok logiki biznesowej\n27 ROZDZIAŠ 4. STANDARD OPISU ARCHITEKTURY Widok procesów (Process View) Widok procesów zostaª przedstawiony za pomoc tzw. diagramu przepªywów (ow diagram). Przedstawia on dwie sytuacje wywnioskowane na podstawie przypadków u»ycia opisanych wcze±niej. Pierwsza z nich to obsªuga dowolnego» dania wysªanego przez u»ytkownika zewn trznego, druga to» danie wysªane przez zewn trzny system komputerowy. Na diagramie przedstawiono wszystkie elementy systemu, wraz z zaznaczeniem tzw. stereotypu, czyli rodzaju danego elementu. Na poni»szych rysunkach mo»na rozpozna procesy dziaªaj ce non-stop, okre±lone jako: <<process>>, oraz obiekty pojawiaj ce si jedynie w na pewien czas dziaªania, opisane jako: <<obiekt>>. Dodatkowo, na rysunkach, w sposób bardziej szczegóªowy przedstawiono jak przebiego pobranie danych z serwera bazy danych (Datastore) i przekazanie ich do obiektu procesora. Diagram tak»e posªuguje si notacj UML 2.0, i zgodnie z ni wykorzystywane s pewn funkcjonalne wiadomo±ci maj ce na celu akcj caªego obiektu, a nie przekazanie danych. Na rysunku mo»na znale¹ np. wiadomo±ci <<create>> lub <<destroy>>, maj ce na celu utworzenie lub zniszczenie obiektów. Polecenie wykonaj wysyªane pomi dzy wieloma obiektami lub procesami obrazuje wysªanie i przetwarzanie dowolnej, akceptowanej przez system, wiadomo±ci. Na diagramie nie przedstawiono obsªugi sytuacji wyj tkowych, które nie powinny by trudne do zdiagnozowania przez programist, a których obecno± utrudniªaby zrozumienie rysunków. Na rysunkach diagramów przepªywu przyj to konw cj przekazywania nazwy obiektu, je»eli efektem odebrania wiadomo±ci ma by odesªania wygenerowanego obiektu. I tak np. <<obiekt>> dane1:rekord zostaje przesªany do <<proces>> :Datastore za pomoc zwrotnej wiadomo±ci zawieraj cej warto± dane1.\n28 ROZDZIAŠ 4. STANDARD OPISU ARCHITEKTURY 27 user <<obiekt>> :Aplikacja <<proces>> :Obserwator <<proces>> :Kontoler <<obiekt>> :Processor1 <<proces>> :Datastore <<obiekt>> dane1:rekord <<obiekt>> widok1:view1 <<create>> wykonaj wykonaj wykonaj <<create>> wykonaj getdata <<create>> dane1 dane1 <<create>> widok1 widok1+dane1 show() <<destroy>> <<destroy>> Rysunek 4.2: Widok przepªywu informacji zewnetrzny system admin <<obiekt>> :Aplikacja <<proces>> :Kontoler <<obiekt>> :Processor1 <<proces>> :Datastore <<obiekt>> dane1:rekord <<obiekt>> dane2:rekord <<obiekt>> widok2:view2 <<create>> wykonaj <<create>> wykonaj getdata <<create>> dane1 dane1 dane1 <<create>> dane1 widok2 getdata <<create>> dane2 dane2 widok2+dane2 show() <<destroy>> <<destroy>> Rysunek 4.3: Widok procesów - przetwarzanie akcji zainicjowanej przez zewn trzny system\n29 ROZDZIAŠ 4. STANDARD OPISU ARCHITEKTURY Widok przynale»no±ci sprz towej (Physical View) Widok przynale»no±ci sprz towej ma za zadanie przedstawienie zycznej lokalizacji danego komponentu, i ewentualnie ich przynale»no±ci do danego pliku wykonywalnego. Na diagramie poni»ej przyj to konwencj umieszczania nazw klas, wraz z ich stereotypem w mniejszych prostok tach, podczas gdy zewn trzne, prostok ty reprezentuj poszczególne maszyny lub grupy maszyn. W przypadku, gdy dana maszyna (b d¹ grupa maszyn) komunikuje si ze sob, przedstawiono ich komunikacj za pomoc dwu- (komunikacja dwustronna) lub jednostronnej strzaªki (komunikacja jednostronna). Ka»da strzaªka dodatkowo zostaªa opisana typem protokoªu u»ywanego do przekazywania danych pomi dzy wybranymi dwoma komputerami. Typ lini (kropkowany, ci gªy, itp.), nie ma specjalnego znaczenia. U»yto go by poprawi czytelno± rysunku, tj. uªatwi lokalizacj komponentów bior cych udziaª w komunikacji. Diagram przynale»no±ci sprz towej nie przedstawia komunikacji wewn trz ka»dego z komputerów, nale»y za- ªo»y»e taka komunikacja jest mo»liwa i zachodz ca je»eli inne widoki j opisuj. Dodanie dodatkowej komunikacji wewn trznej, w widoku przynale»no±ci sprz towej, spowodowaªoby nieczytelno± rysunku. Warto zauwa»y,»e wi kszo± strzaªek dotyka tylko brzegu zewn trznego prostok ta obrazuj cego komputer. Oznacza to,»e ka»dy z komponentów wykonywanych na danej maszynie mo»e mie dost p do tych danych. Inny charakter ma komunikacja, gdy strzaªka ª czy si z jednym z wewn trznych prostok tów. W takim przypadku komunikacja mo»e odbywa si jedynie z tym komponentem. Niereguralny ksztaªt w ±rodku diagramu przedstawia sie Internet, i w du»ym uproszczeniu oznacza,»e komputery stoj ce po prawej i po lewej stronie diagramu mo»e rozdziela du»a odlegªo± geograczna i czasowa. Na rysunku wprowadzono notacj wykorzystywan w diagramach stanu, a mianowicie podziaª na równolegªe domeny (procesy). Na rysunku poni»ej oznacza ona podziaª danej maszyny na dwa wirtualne byty: jeden komunikuj cy si ze ±wiatem zewn trznym, a drugi komunikuj cy si ze ±wiatem zewn trznym. Nale»y tak»e zauwa»y,»e strzaªki ª cz ce pojedy«czy punkt z jednej strony z grup (np. dwoma punktami) z drugiej strony oznacza,»e ka»dy pakiet danych przesyªany jest jednocze±nie do obu punktów docelowych, jakkolwiek komunikacja powrotna (ze strony podwójnych punktów) jest niezale»na od siebie nawzajem.\n30 ROZDZIAŠ 4. STANDARD OPISU ARCHITEKTURY 29 Rysunek 4.4: Widok przynale»no±ci sprz towej\n31 Cz ± III Opis Rozwi zania 30\n32 Rozdziaª 5 Platforma aplikacyjna 5.1 Wymagania Poni»ej zgromadzono wymagania werykuj ce stopie«przydatno±ci danego rozwi zania jako platformy aplikacyjnej, na której ma by oparta warstwa aplikacyjna Platformy PCM. W nawiasach kwadratowych uwidoczniono istotno± ka»dego z wymaga«za pomoc ilo±ci gwiazdek. Najwy»sz istotno± reprezentuj wymagania oznaczone za pomoc trzech gwiazdek, ni»sz za pomoc dwóch, a najni»sz te oznaczone za pomoc jednej gwiazdki. Kolejno± wymaga«nie ma znaczenia. ˆ praca w systemie klastra - wiele serwerów widzianych z zewn trz tak, jakby tworzyªy jedn wirtualn maszyn [***] ˆ ªatwo± tworzenia aplikacji [***] ˆ ªatwo± wprowadzania poprawek [***] ˆ ªatwo± testowalno±ci [***] ˆ automatyzacja tworzenia obiektów na podstawie rekordu bazy danych (ang. Object- Relation Mapping - ORM) ˆ szybko± tworzenia aplikacji [***] ˆ ilo± obsªugiwanych poª cze«przypadaj cych na jeden serwer [***] ˆ skalowalno± - wzrost wydajno±ci wraz ze wzrostem ilo±ci serwerów [***] ˆ ªatwo± instalacji (deployment) - zarówno rozszerze«udoskonale«systemu, jak i jego peªna reinstalacja [***] ˆ synchronizacja instalacji nowej wersji aplikacji wewn trz klastra [***] ˆ oparcie o kod ogólnodost pny (open source) [**] 31\n33 ROZDZIAŠ 5. PLATFORMA APLIKACYJNA 32 ˆ ªatwo± integrowania z WEB2.0 (np. AJAX) [***] ˆ generacja widoków stron na podstawie statycznej zawarto±ci i dynamicznych parametrów [***] 5.2 Porównanie wybranych rozwi za«5.2.1 PHP Symfony PHP Symfony jest framework-iem dla aplikacji internetowych napisanym w j zyku PHP. Framework ten bazuje na wzorcu projektowym MVC. Symfony cechuje si nast puj - cymi wªa±ciwo±ciami: ˆ bazuje na wzorcu projektowym MVC (ang. Model-View-Controler) ˆ programowanie zorientowane obiektowo ˆ ªatwo± w instalacji oraz konguracji na wi kszo±ci platform ˆ niezale»no± od systemu bazodanowego ˆ zgodno± z najlepszymi standardami oraz wzorcami budowy aplikacji internetowych ˆ walidacja formularzy i tre±ci ˆ zarz dzanie sesjami ˆ ªatwo± rozbudowy oraz mo»liwo± integracji z innymi bibliotekami ˆ wykorzystanie technologii scaoldingu. ˆ wbudowana internacjonalizacja (i18n) ˆ wbudowana ochrona przed atakami typu CSRF oraz XSS Dodatkowo PHP Symfony posiada bardzo dobrze zaprojektowany, wbudowany mechanizm do tworzenia testów jednostkowych oraz testów funkcjonalnych. Posiada on te» pewne rozwi zania uªatwiaj ce synchronizacj danych pomi dzy w zªami klastra Ocena rozwi zania PHP Symphony to bardzo interesuj cy framework, zawieraj cy rozwi zania i metodologie znane z najlepszych i wypróbowanych rozwi za«komercyjnych. Niestety jego u»yteczno± dla du»ych i skomplikowanych projektów informatycznych, gdzie oprócz wygody, pr dko±ci kodowania i testowania liczy si wydajno± i skalowalno±, nie jest wpeªni dopracowana. Projektu Symfony jest projektem stosunkowo ±wie»ym, a wi c\n34 ROZDZIAŠ 5. PLATFORMA APLIKACYJNA 33 ci gle nara»onym na liczne zmiany, co dodatkowo mo»e powodowa problemy w przypadku aplikacji rozwijanych przez dªu»szy okres czasu, takich jak omawiana Platforma PCM. PHP Symfony posiada jedynie bardzo podstawow funkcjonalno± dotycz c synchronizacji danych w ±rodowisku klastra, co ostatecznie wyklucza jego wykorzystanie jako platformy aplikacyjnej dla systemu informatycznego PCM ucommon C++ ucommon C++ to lekka, niewielka, wielow tkowa biblioteka napisane w C++, której celem jest oddzielenie warstwy aplikacyjnej od zale»no±ci zwi zanych z wykorzystaniem konkretnego systemu operacyjnego. Biblioteka ta napisana zostaªa z wykorzystaniem tzw. wzorców projektowych, co powoduje,»e biblioteka jest bardzo ªatwo zrozumiaªa i po krótkim zapoznaniu si z nazwami konkretnych klas mo»e zosta wykorzystana w planowanym projekcie. Biblioteka byªa pisana pod urz dzenia typu embedded, i z tego powodu w jej budowie i architekturze mo»na zauwa»y wiele elementów, które kªad istotny nacisk na maªe wymagania pami ciowe oraz umiarkowane wymagania dotycz ce uruchomienia (upraszczanie algorytmów). Dlatego te» nie posiada ona bardziej zaawansowanych rozwi za«takich jak: rtti czy obsªuga wyj tków, oraz zakªada»e b dzie wykorzystana w wi kszo±ci przypadków w aplikacjach, w których pozostaªe biblioteki b d napisane w czystym j zyku C (ANSI C), a nie z wykorzystaniem rozwi za«opartych o mechanizmy wprowadzone w j zyku C++, wymagaj cych zwi kszonych zasobów systemowych. ucommon jest przygotowana do kompilacji z ka»dym kompilatorem C++ zgodnym ze standardem ANSI C++, jakkolwiek wymaga wyª czenia lub zmiany domy±lnych ustawie«kompilatora, je»eli s one niezgodne z zaªo»eniami biblioteki (np. brak obsªugi wyj tków). ucommon wprowadza równie» niektóre rozwi zania znane z j zyka Objective-C, na przykªad 1 : ˆ reference counted objects ˆ memory pools, smart pointers ˆ dynamic typing - wykorzystuj ce tzw. inline templates Dodatkowo, ucommon posiada automatyzacj zarz dzania zmiennymi, np. umo»liwia uruchomienie automatycznej funkcji usuwania obiektów i zablokowanych w tków w przypadku powrotu z metody, która je wykorzystywaªa, oraz dostarcza funkcjonalno±ci timerów (w tym timerów czasu rzeczywistego) - o ile s one dost pne na poziomie systemu operacyjnego. ucommon posiada dobrze zaprojektowany framework potrzebny aplikacjom wielow tkowym, np. w wi kszo±ci przypadków potra ona emulowa podobne zachowania dotycz ce synchronizacji mi dzyw tkowej nawet w przypadku systemów operacyjnych, które posiadaj albo dalece ró»n mechanik zarz dzania w tkami, albo wr cz bardzo ubog 1 Pozostawiono oryginaln wersj j zykow z uwagi na wysoko techniczny aspekt poni»szych wyra»e«, których znaczenie mo»e sta si trudne do zrozumienia po przetªumaczeniu.\n35 ROZDZIAŠ 5. PLATFORMA APLIKACYJNA 34 (szcz tkow ) funkcjonalno±. Uniwersalna i dobrze zaprojektowana architektura biblioteki oraz konsekwentnie wykorzystywane nazewnictwo s niew tpliwymi zaletami biblioteki ucommon Ocena rozwi zania Mimo szeregu zalet i niezwykªej wydajno±ci biblioteka ucommon nie dostarcza wymaganych funkcjonalno±ci, a jedynie dobry framework pozwalaj cy na zbudowanie docelowego rozwi zania. Z uwagi na to,»e nakªad pracy zwi zanej z dopracowaniem wªa±ciwego frameworku jest za du»y, rozwi zanie to zostaje odrzucone CrissCross framework CrissCross jest platform aplikacyjn napisan w C++ pozwalaj c na zunikowan obsªug szczegóªów implementacji zwi zanych z systemem operacyjnym. CrissCross dziaªa pod kontrol nast puj cych systemów operacyjnych: ˆ Mac OS X ˆ Linux ˆ NetBSD ˆ FreeBSD ˆ OpenBSD ˆ Windows Skªada si on z przygotowanej grupy klas, gotowych do kompilacji na ró»nych systemach operacyjnych, pozwalaj cych na uruchomienie tego samego kodu aplikacji na wielu systemów operacyjnych, wykorzystuj c do tego celu to samo drzewo kodu ¹ródªowego. CrissCross jest bardzo lekkim rozwi zaniem dostarczanym jako biblioteka C++, zawieraj cym podstawowe funkcjonalno±ci wymagane przez aplikacje. Zawiera on m.in. klasy do obsªugi konsoli oraz funkcjonalno± wej/wyj dla plików, struktury danych charakteryzuj ce si szybkim dost pem, funkcje dostarczaj ce mo»liwo±ci identykacji CPU (CPUID) i obsªugi socket-ów (TCP and UDP) Ocena rozwi zania Podobnie jak poprzednio opisywana biblioteka ucommon, CrissCross framework mógªby by baz pozwalaj c na stworzenie wªa±ciwej platformy wymaganej do implementacji systemu, a z uwagi na brak wymaganych funkcjonalno±ci, zwi ksza znacz co nakªad prac zwi zanych z dopisaniem brakuj cych funkcjonalno±ci, co automatycznie powoduje odrzucenie tego rozwi zania.\n36 ROZDZIAŠ 5. PLATFORMA APLIKACYJNA PureMVC PureMVC jest generycznym frameworkiem napisanym (lub przepisanym) na wiele j zyków m.in. Perl, Java, C#, C++, ActionScript i inne. Udost pnia on spójny i do± prosty mechanizm pisania aplikacji z obligatoryjnym wykorzystaniem wzorca MVC. Architektura PureMVC zakªada tzw. kod ortogonalny, tj. brak (lub minimalne) zale»no±ci pomi dzy poszczególnymi fragmentami frameworku jak i kodem aplikacji, ale tak»e pisanie kodu samej aplikacji w sposób umo»liwiaj cy wprowadzanie zmian do jednego fragmentu bez potrzeby modykacji komponentów z niego korzystaj cych, lub wykorzystywanych przez fragment zmieniany. PureMVC charakteryzuje si dobr skalowalno±ci (posiada np. wersj jednordzeniow lub wielordzeniow w zale»no±ci od wykorzystywanego CPU), oraz pozwala na szybkie budowanie i testowanie aplikacji. Mimo,»e nie posiada wbudowanych mechanizmów wymaganych przez framework pracuj cy w konguracji klastra, jego dobra architektura pozwala w prosty sposób tak funkcjonalno± doda. Najwi kszym atutem frameworku PureMVC jest jego ortogonalno± w stosunku do konkretnego j zyka programowania. Dzi ki temu mo»na przygotowa praktycznie caªy projekt, a» do detalicznego podziaªu na poszczególne zadania, bez wnikania w specyk danego j zyka programowania. Pozwala to te» we wzgl dnie prosty sposób na przeniesienie istniej cego rozwi zania zaimplementowanego w jednym j zyku do innego, który okazaª si wydajniejszy lub wygodniejszy w rzeczywistym zastosowaniu. Ze wzgl du na przyj ty model i architektur tego rozwi zania - PureMVC idealnie nadaje si do generowania zawarto±ci widoków (ang. views) zawieraj cych opis w postaci kodu HTML, jednak»e sama translacja danych do postaci HTML nie jest cz ±ci frameworku, wi c wymagany jest nakªad pracy przy jej implementacji. Bardziej powa»nym problemem jest brak serwera WWW zintegrowanego z PureMVC - mo»na oczywi±cie zaªo»y wykorzystanie jednego z istniej cych serwerów np. Apache czy Nginx, ale nawet w tym przypadku potrzebny byªby moduª (Apache'a lub Nginx'a) pozwalaj cy na translacj otrzymanego zapytania HTTP na odpowiedni wiadomo± przetwarzan przez framework Ocena rozwi zania Mimo zach caj cej nazwy oraz bardzo ciekawego podej±cia do wzorca MVC i jego bardzo praktycznego wykorzystania, framework ten nie nadaje si do celów platformy aplikacyjnej dla systemu projektowanego dla kolekcji PCM. Decyzja o odrzuceniu PureMVC jest podyktowana znacznie wi kszym nakªadem pracy zwi zanym z konieczno±ci uzupeªnienia funkcjonalno±ci frameworku o wymagane z punktu widzenia Platformy PCM. Taka praca jakkolwiek przydatna byªaby strat czasu w stosunku do innych frameworków posiadaj cych np. tworzenie dynamicznych stron WWW out-of-the-box. Podobnie wygl da ocena funkcjonalno±ci klastrowej PureMVC, kosztem pewnego nakªadu pracu mo»na j dopisa - jednak warto± takiego rozwi zania, szczególnie w przypadku gdy istnieje wiele innych frameworków, posiadaj cych tak funkcjonalno± wbudowan\n37 ROZDZIAŠ 5. PLATFORMA APLIKACYJNA 36 (ang. build-in), nie jest warte wysiªku. Z tego powodu, PureMVC zostaje odrzucony jako rozwi zanie bardziej pracochªonne GlassFish GlassFish jest serwerem aplikacyjnym przygotowanym jako platforma programistyczna dla projektów typu Enterprise napisanych w j zyku Java. Powstaª on jako projekt typu open source nadzorowany przez rm Sun Microsystems. Obecnie zostaª on przekazany wraz z prawami do j zyka Java rmie Oracle, która ogªosiªa ch zachowania projektu w istniej cej formie, tj. jako projekt oparty o licencj GPL. Projekt GlassFish ze wzgl du na swój agowy charakter 2, byª projektem wzorcowym, który zwykle jako pierwszy wprowadzaª nowe, ustalone standardy specykacji zwi zanej z J2EE API, oraz który sªu»yª jako punkt referencyjny dla innych projektów, tj. wykorzystywano go do sprawdzenia jak dana funkcjonalno± powinna dziaªa w ±rodowisku naturalnym, i na tej podstawie poprawiano kod innych serwerów aplikacyjnych. Z tego wzgl du mo»na ±miaªo nazwa GlassFish wzorcowym serwerem aplikacyjnym dla projektów J2EE, który najwcze±niej i najpeªniej speªniaª wymagania dotycz ce funkcjonalno±ci wyspecykowanych w ocjalnych dokumentach rmy Sun Microsystems. GlassFish speªnia wszystkie wymagania opisane w specykacji dla J2EE API, m.in. JDBC, RMI, , JMS, web services, XML, etc., i okre±la ich wzajemne relacje wewn trz przestrzeni serwera Java EE. GlassFish posiada równie» wiele funkcjonalno±ci specycznych dla komponentów Java, takich jak: ˆ Enterprise JavaBeans ˆ Connectors ˆ Servlets ˆ Portlets ˆ Java Server Pages ˆ Web Services Takie cechy, pozwalaj programistom tworzy aplikacje typu enterprise, które nie tylko s skalowalne i przenaszalne na inne serwery aplikacyjne J2EE, ale równie» mog by w prosty sposób zintegrowane z tzw. kodem typ legacy. GlassFish posiada kilka wybieralnych komponentów kontroluj cych sposób dziaªana warstwy danych niezb dnej w ka»dej wi kszej aplikacji Enterprise. Jednym z nich jest 2 Byª projektem nadzorowanym przez rm Sun, a wi c wªa±ciciela i twórc j zyka oraz wszystkich standardów zwi zanych z Java i J2EE, dlatego te» projekt serwera aplikacyjnego nadzorowanego przez Sun musiaª by najbardziej zgodny ze standardami proponowanymi przez t sam rm.\n38 ROZDZIAŠ 5. PLATFORMA APLIKACYJNA 37 adapter oparty o kod ogólnodost pny udost pniony przez rmy Sun i Oracle Corporation's - tzw. TopLink. Pozwala on na bardzo precyzyjn kontrol zachowania obiektów mapuj cych funkcjonalno±ci i relacji danych przechowywanych w bazach danych (tzw. Object Relation Mapping) i to niezale»nie od typu wykorzystywanej bazy danych. TopLink pozwala m.in. na zdeniowania zachowania w przypadku wielodost pno±ci do tych samych danych, tj. gdy pewna liczba serwerów jednocze±nie modykuje dane podczas gdy, inna grupa odczytuje ich warto±ci. W takim przypadku nie unikniony jest tu pewien kompromis wynikaj cy z wielodost pu, dla którego TopLink pozwala np. zdeniowa czy serwer ma blokowa dost p do danych dopóki transakcje modykuj ce nie zostan zako«czone, czy chwilowe niewielkie ró»nice w zawarto±ci niektórych tabel nie maj znaczenia dla poprawnej pracy aplikacji i dlatego dopuszczalne jest dopuszczenie czytanie danych, które mog by cz ±ciowo przestarzaªe, poniewa» w czasie ich przetwarzania nowsza wersja zostaªa zapisana do bazy danych. GlassFish wykorzystuje jako serwer WWW oferuj cy zarówno statyczne strony WWW jak i te generowane dynamicznie, serwlet oparty o kod Apache Tomcat. Serwlet ten od pewnego czasu rozwijany oddzielnie rozszerzaj c go m.in. o bardzo wydajny komponent Grizzly, którego zwi kszona wydajno± bierze si z wykorzystywania nowego I/O API oferowanego przez nowsze wersje j zyka Java i JVM, tzw. NIO - Java New I/O. Z uwagi na lepsz zgodno± niskopoziomow z funkcjonalno±ci i architektur wspóªczesnych systemów operacyjnych NIO pozwala na uzyskanie nawet 40% zwi kszenia wydajno±ci ko«cowej aplikacji. GlassFish, ze wzgl du na implementacj wszystkich standardów zdeniowanych przez J2EE API, posiada wbudowane mechanizmy mapowania obiektów bazodanowych na obiekty Javy (tzw. POJO), np. z wykorzystaniem ocjalnego standardu JPA Ocena rozwi zania Platforma aplikacyjna GlassFish speªnia wszystkie wymagania, i jakkolwiek pod wzgl dem wydajno±ci przegrywa ona z rozwi zaniami opartymi o natywnie kompilowane moduªy, to zachowuje ona skalowalno± bardzo blisk zaªo»onej skalowalno±ci liniowej, osi gaj c przy tym bardzo przyzwoit sprawno± mierzon za pomoc ilo±ci jednocze±nie obsªugiwanych poª cze«. GlassFish posiada bardzo zaawansowane mechanizmy synchronizacji pracy poszczególnych serwerów w ramach jednego klastra, oraz wbudowane mechanizmy loadbalance-ingu oraz przejmowania zada«od uszkodzonych w zªów (ang. fail over). Dodatkowo jest platform sprawdzon w wielu aplikacjach typu Enterprise, stabiln, wci» rozwijan i usprawnian oraz umo»liwiaj c ªatw konguracj i rozszerzanie funkcjonalno±ci. Z tego wzgl du serwer aplikacji GlassFish jest jak najbardziej polecanym rozwi zaniem JBoss JBoss to serwer aplikacji w Javie na licencji LGPL, na bazie technologii Enterprise JavaBeans (EJB). JBoss implementuje peªen zestaw usªug Java EE (J2EE).\n39 ROZDZIAŠ 5. PLATFORMA APLIKACYJNA 38 Serwer zostaª napisany w caªo±ci w j zyku Java, dzi ki czemu JBoss jest dost pny na niemal wszystkie platformy. Jest równie» zintegrowany z darmowym ±rodowiskiem programistycznym Eclipse, które umo»liwia wytwarzanie komponentów dla tego serwera. Osadzenie komponentów na JBossie równie» nie stanowi problemu. Ka»dy komponent (zarówno serwlet, strona JSP, strona HTML, komponent EJB lub jakikolwiek inny zasób) jest umieszczany w pliku JAR (pliki te posiadaj ró»ne rozszerzenia zale»nie od typu komponentu). Opis plików w postaci dokumentów XML znajduje si równie» w tym samym pliku (jar). Skopiowanie pliku do katalogu o nazwie 'deploy' powoduje automatyczne zaªadowanie komponentu. Serwer JBoss od wersji 3.x posiada ju» zaawansowane mechanizmy dost pne w komercyjnych serwerach aplikacji (jak np. tworzenie klastra w oparciu o wiele serwerów). JBossa otacza wiele otwartych projektów. Do wersji 3.2.x stworzony zostaª komponent udost pniaj cy jednostki EJB w postaci usªug sieciowych (web service-ów). Pocz tkowo ich serwer opieraª si o projekt AXIS, potem AXIS zostaª obudowany komponentem jboss.net, a w wersji 4.0 JBoss dostarcza ju» wªasny serwer web service. Tak jak w przypadku innych serwerów aplikacyjnych JBoss udost pnia poprzez J2EE API mo»liwo± ªatwego mapowania obiektów bazodanowych na obiekty Javy (tzw. POJO). JBoss to tak»e nazwa rmy zajmuj cej si rozwojem tego oprogramowania, a zarabiaj cej na komercyjnym wsparciu produktu. Serwer JBoss oferuje nast puj ce funkcjonalno±ci/standardy: ˆ Aspect-Oriented Programming (AOP) ˆ Clustering ˆ Deployment API ˆ Funkcja rozproszonego caching ˆ Distributed deployment (farming) ˆ EJB v. 3.0 i 2.1 ˆ Failover (równie» dla danych sesji) ˆ integracja z frameworkiem Hibernate ˆ JAAS (Java Authentication and Authorization Service) ˆ JCA (Java Connector Architecture) ˆ Java Management Extensions JMS (Java Message Service) ˆ JNDI (Java Naming and Directory Interface) ˆ JTA (Java Transaction API)\n40 ROZDZIAŠ 5. PLATFORMA APLIKACYJNA 39 ˆ JACC (Java Authorization Contract for Containers) ˆ JavaMail ˆ JavaServer Faces 1.2 (Mojarra) JSP/Servlet 2.1/2.5 (Tomcat) ˆ JBossWS (JBoss Web Services) for Java EE-Web Services like JAX-WS JDBC ˆ Load balancing Management API ˆ OSGi framework ˆ RMI-IIOP (JacORB, contraction of Java and CORBA) ˆ SAAJ (SOAP with Attachments API for Java) Ocena rozwi zania JBoss jest rozwi zaniem speªniaj cym, je»eli nie wszystkie to wi kszo±, postawionych wymaga«. Jest bardzo stabilnym, rozwijanym projektem, który cz sto wprowadzaª pewne rozszerzenia do ustanowionych standardów, staj cych si z czasem cz ±ci owego standardu. Taka ewolucja funkcjonalno±ci zainicjowana przez projektantów i deweloperów tego projektu najlepiej pokazuje jego przydatno± i elastyczno±. JBoss jako jedyny serwer aplikacyjny, oprócz serwera GlassFish, ma doskonaªy mechanizm pracy w konguracji klastra co stawia go jako potencjaln alternatyw dla rozwi zania oferowanego przez serwer GlassFish Geronimo Geronimo jest kolejnym serwerem aplikacyjnym zgodnym z J2EE. Tak jak wi kszo± systemów operacyjnych, Geronimo posiada swoje wªasne j dro systemowe, tzn. mikrokernel, który jest warstw bazow dla warstw aplikacji, znajduj cych si powy»ej. Rol j dra jest zarz dzanie moduªami Geronimo, tj. fragmentami speªniaj cymi okre±lon funkcjonalno±. Geronimo zostaª stworzony, wykorzystuj c w swojej architekturze tzw. koncepcj wstrzykiwania zale»no±ci (ang. Dependency Injection- DI), co oznacza tyle,»e j dro kernel (j dro systemu) nie ma»adnych wbudowanych zale»no±ci do jakiegokolwiek komponentu. Kernel jest baz dla serwisów kontroluj cym cykl powstawania serwisu, jego rejestracji i wyrejestrowania. Wi kszo± serwisów Geronimo s dodawane i kongurowane poprzez tzw. GBeansy, które staj si cz ±ci serwera. GBean jest typem interfejsu, który ª czy dodatkowe komponenty z kernelem systemu. Ka»dy GBean utrzymuje swój stan, polega na i komunikuje si z innymi GBean-ami. GBean-y reaguj na wiadomo±ci (events) wysyªane przez inne GBean-y lub kernel. Interfejs GBean umo»liwia m.in. przeª czanie serwera aplikacyjnego pomi dzy dwoma typami serwerów serwletów, np. Jetty lub Tomcat. Taka architektura pozwala na ªatw integracj Geronimo z wieloma istniej cymi rozwi zaniami, szczególnie z zakresu oprogramowania ogólnodost pnego (open source).\n41 ROZDZIAŠ 5. PLATFORMA APLIKACYJNA 40 Geronimo posiada wbudowan peªn obsªug serwisów zgodnych ze specykacj J2EE, jednak»e jego implementacja bazuje na OpenEJB, które w niektórych aspektach ró»ni si od wersji wypromowanej przez rm Sun a obecnie Oracle. Tak jak i pozostaªe omawiane serwery aplikacyjne zgodne z J2EE, Geronimo posiada mo»liwo±ci ORM za pomoc protokoªu JPA lub dodatkowych dodawanych moduªów - np. Hibernate Ocena rozwi zania Mimo bardzo ciekawej architektury i dynamicznego rozwoju, Geronimo ci gle nie udost pnia wbudowanego, wiarygodnego rozwi zania pozwalaj cego na jego prac w systemie klastra. Ta wada obni»a ko«cow ocen serwera. Dodatkowo nale»y podkre±li,»e Geronimo jest projektem stosunkowo mªodym, wi c nara»onym na gwaªtowne zmiany API i zmiany zachowania w stosunku do obecnie dost pnych wersji. Nie posiada on równie» specjalnie wydajnego serwera WWW (zawieraj cego szybki silnik generacji dynamicznych stron WWW), co w ostatecznym rozrachunku powoduje odrzucenie serwera Geronimo jako platformy aplikacyjnej, która miaªaby by podstaw aplikacji Platfromy PCM Ruby on Rails (RoR) RoR jest platform typu open source, sªu» c do szybkiego tworzenia aplikacji webowych. Zostaª napisany w j zyku Ruby z u»yciem architektury MVC (ang. Model- View-Controller). Na framework Rails skªadaj si cztery gªówne elementy: ˆ ActiveRecord mechanizm ORM (Object-Relational mapping) dla Ruby, odpowiada za tworzenie modeli w architekturze MVC ˆ ActionPack biblioteka zawieraj ca klasy ActionController ˆ ActionView, które odpowiadaj za tworzenie odpowiednio kontrolerów i widoków ˆ ActiveSupport zbiór u»ytecznych dodatków do standardowej biblioteki Ruby, zawiera m.in. rozszerzenia klas String czy Time ˆ ActionMailer biblioteka sªu» ca do wysyªania wiadomo±ci (najcz ±ciej przez aplikacj Rails) Ka»da z tych cz ±ci mo»e zosta zainstalowana oddzielnie, np. za pomoc menad»era pakietów RubyGems. W skªad dystrybucji Rails wchodzi te» konsolowy program rails, który generuje drzewo katalogów nowego projektu. Rails oparte jest o architektur MVC, tzn. klient po wy±wietleniu widoku (w tym przypadku wygenerowanej strony HTML), wysyªa do aplikacji» danie (klikaj c w odpowiedni link na stronie lub wypeªniaj c formularz). danie jest przyjmowane przez kontroler, który generuje odpowied¹ w formie widoku wysyªanego do klienta (najcz ±ciej kontroler w celu wygenerowania odpowiedzi pobiera dane z modelu, który w RoR implementowany jest jako relacyjna baza danych).\n42 ROZDZIAŠ 5. PLATFORMA APLIKACYJNA 41 Standardowy serwer, na którym mo»na uruchomi RoR oparty jest na bibliotece WEBrick. Takie rozwi zanie jest zwykle stosowane podczas tworzenia lub testowania aplikacji z uwagi na brak wydajnej obsªugi wielu zapyta«. Innym dost pnym serwerem jest Mongrel. Raz uruchomiony serwer przypisuje nadchodz ce» dania (requests) odpowiednim kontrolerom i na podstawie ich dziaªania zwraca do klienta odpowied¹ (response). Serwer Rails mo»e dziaªa samodzielnie lub by ukrytym za innym serwerem HTTP (np. Apache, Lighttpd czy Nginx). W tym drugim rozwi zaniu zewn trzny serwer równowa»y obci»enie wszystkich serwerów aplikacji. Innym, zdobywaj cym coraz wi ksz rzesz zwolenników rozwi zaniem, jest Phusion Passenger, zwany tak»e mod_rails lub mod_rack. Dost pny jest on dla Apache'a (jako moduª) i Nginxa (wymaga wkompilowania w serwer). Zalet rozwi zania jest jego automatyzacja po odpowiednim ustawieniu ±cie»ek w pliku konguracyjnym, Passenger odpowiednio wywoªuje kolejne w tki aplikacji w ramach potrzeb. RoR nie tylko posiada, ale wr cz bazuje na funkcjonalno±ci typu ORM, dodatkowo uzupeªniaj c j o mo»liwo± automatycznej generacji klas mapuj cych obiekty bazy danych bez jakiejkolwiek pomocy ze strony u»ytkownika. Framework co prawda zakªada pewne wªa±ciwo±ci tabel bazy danych aby móc w peªni wykorzysta opisywany mechanizm, ale nawet w takim przypadku nale»y podkre±li nowatorsko± tego rozwi zania oraz bardzo istotny wpªyw na popularno± wykorzystania RoR jako platformy aplikacji webowych Ocena rozwi zania Bardzo obiecuj ce rozwi zanie pozwalaj ce na bardzo szybkie tworzenie aplikacji webowych. RoR wykorzystuje nowy, bez typowy j zyk programowania - Ruby, który jest doskonaª kompilacj najlepszych dokona«takich poprzedników jak Smalltalk, Perl i Python. J zyk Ruby wraz z wymuszonym przez RoR wzorcem MVC powoduje bardzo du» automatyzacj w pracy nad pisaniem i testowaniem nowotworzonych aplikacji. Nie jest to jednak rozwi zanie pozbawione wad - nie tylko RoR jest nowym rozwi zaniem, ale tak»e sam j zyk Ruby jest ci gle dopracowywany co skutkuje cz stymi zmianami API. Wraz z j zykiem zmienia si tak»e specyka narz dzi dostarczanych wraz z wybran wersj Ruby. To powoduje,»e rzeczywista pr dko± pisania aplikacji mo»e by du»o mniejsza od teoretycznych mo»liwo±ci j zyka. Dodatkowo - RoR nie posiada w peªni dojrzaªego serwera generuj cego strony WWW. Wbudowany serwer jak i serwery dost pne poza RoR s tak»e w stadium rozwoju i jakkolwiek bardzo obiecuj ce w chwili obecnej, nie s zalecane jako serwery produkcyjne dla aplikacji typu Enterprise. Kolejn kwesti jest brak wbudowanych mechanizmów pracy w klastrze, a oferowane rozszerzenia mog co najwy»ej udost pnia bardzo podstawow funkcjonalno± i to przy zaªo»eniu,»e ani j zyk Ruby ani struktura RoR si nie zmieni co przy tak mªodym projekcie jest prawie niemo»liwe. Z powy»szych wzgl dów, mimo»e sam j zyk Ruby i platforma RoR s jak najbardziej przystaj ce do wymaga«projektu - idea wykorzystania RoR jako serwer aplikacji dla Platformy zostaje porzucona.\n43 ROZDZIAŠ 5. PLATFORMA APLIKACYJNA Wybrane rozwi zanie Z spo±ród zaakceptowanych rozwi za«postanowiono wybra rozwi zanie przoduj ce pod wzgl dem dost pnej funkcjonalno±ci a jednocze±nie charakteryzuj ce si stabilnym rozwojem, kontrolowanym przez pojedyncz organizacj. Wpªyw na ko«cow decyzj miaª tak»e wpªyw fakt,»e wybrane rozwi zanie jest sponsorowane i kontrolowane przez rm Oracle, obecnego wªa±ciciela i opiekuna rozwoju oprogramowania opartego o j zyk Java, w tym tak»e deniuj cej i dbaj cej standardy obsªugiwane przez certykowane serwery aplikacyjne obsªuguj ce aplikacje napisane w j zyku Java. Z powy»szych wzgl dów proponowanym rozwi zaniem jest rozwi zanie oparte o serwer aplikacyjny GlassFish. Serwer ten w obecnej wersji 3.1 jest projektem bardzo dojrzaªym, stabilnym, posiadaj c nie tylko szerok gam funkcjonalno±ci, ale równie» ogromn bibliotek dokumentów dost pnych zarówno w formie elektronicznej jak i papierowej, która pozwala znale¹ rozwi zanie wielu wyst puj cych problemów, zarówno w doskonaªej dokumentacji jak i w licznych przykªadach opisanych przez ró»nych u»ytkowników. Produkt ten posiada równie» dobrze zdeniowanego wªa±ciciela - rm Oracle - która oferuje pªatn pomoc w instalacji, konguracji i rozwi zywaniu problemów, a jednocze±nie platforma GlassFish jest caªy czas (i b dzie jak zapowiedziaªa rma Oracle) dost pna na zasadach licencji GPL, co powoduje»e koszt uzyskania dziaªaj cej platformy aplikacyjnej mo»e by niewielki. Nale»y tutaj podkre±li,»e generalnie rozwi zania oparte o standardy wyspecy- kowane dla aplikacji napisanych w Java, wydaj si najlepszym rozwi zaniem ze wzgl du na dojrzaªo± tego typu rozwi za«, ich wytestowaniu w warunkach produkcyjnych oraz wzgl dnej ªatwo±ci dobierania rozszerze«do istniej cych standardów w sposób zachowuj cy ich oryginaln funkcjonalno±. Z tego powodu dodatkowym atutem wyboru rozwi zania opartego o platform GlassFish jest mo»liwo± ªatwej migracji na inn platform opart o te same standardy, np. JBoss czy Geronimo, przy praktycznie zerowym nakªadzie zwi zanym ze zmian platformy aplikacyjnej.\n44 Rozdziaª 6 Aplikacja kliencka 6.1 Wymagania ˆ ªatwo± i prostota instalacji i u»ytkowania [***] ˆ dobra wspóªpraca z wybran platform aplikacyjn [***] ˆ ªatwo± wymiany informacji z wybran platform aplikacyjn [***] ˆ ªatwo± generowania widoków wy±wietlanych przez wybrane przegl darki WWW [***] ˆ oparcie o kod ogólnodost pny (open source) [**] ˆ ªatwo± integrowania z WEB2.0 (np. AJAX) [***] ˆ ªatwo± pobierania danych ogólnodost pnych przez wyszukiwarki internetowe [***] - aplikacja kliencka powinna udost pnia zawarte informacje w taki sposób,»e tzw. webcrawlery - czyli automaty przeszukuj ce internet mogªy w prosty sposób przeszuka i przeanalizowa dost pn tre±. Dzi ki temu informacje zawarte w serwisie mog zosta prawidªowo zakwalikowane i pozwoli w przyszªo±ci na znalezienie kolekcji PCM, poprzez wpisanie w wyszukiwark internetow okre±lonej frazy lub wyra»enia. 6.2 Porównanie wybranych rozwi za«6.2.1 Dynamicznie strony WWW Termin dynamicznie generowane strony WWW jest prawdopodobnie zbyt ogólny, ale z uwagi na konieczno± wspóªpracy mechanizmu generacji z wybran platform aplikacyjn, nie ma potrzeby ani sensu rozstrzygania w niniejszym rozdziale wªa±ciwo±ci samego procesu generacji, tj. czy np. JSF jest lepszym czy gorszym rozwi zaniem ni» 43\n47 ROZDZIAŠ 6. APLIKACJA KLIENCKA Ocena rozwi zania Z porówniania opisu wªa±ciwo±ci dynamicznie generowancych stron WWW z list wymaga«wynika niezbicie,»e aplikacjia kliencka Platformy PCM, mo»e by oparta o t technologi. Co prawda jak to zostaªo wspomniane w opisie, strony WWW wymagaj osobnego traktowania dla ka»dej przegl darki, dla której serwis ma dziaªa poprawnie. Taka cecha powoduje wi ksze nakªady zwi zane z kodowaniem/tworzeniem stony WWW, co jest zdecydowanie negatywn cech, jednak»e w przypadku aplikacji klienckiej, która ma by niejako wizytówk kolekcji PCM, wizytówk która zostanie zauwa»ona, przanalizowana i udost pniona innym poprzez serwisy wyszukiwarek internetowych, nale»y uzna»e zyski wynikaj ce z przetworzenia prostego formatu WWW przewa»aj nad jego wadami, dlatego te» nale»y zaproponowa to rozwi zanie jako potencjalnie mo»liwe do wykorzystania w aplikacji klienckiej serwisu Platformy Adobe Flex/Flash Rozwi zanie opisywane w niniejszym rozdziale opiera si o zupeªnie inne zaªo»enia ni» standard WWW. Jedyn cz ±ci wspóln jest wykorzystywanie przegl darki WWW jako narz dzia do komunikacji z u»ytkownikiem. W tym przypadku przegl darka renderuje niewielk cz ± strony WWW, zawieraj cej zwykle tªo dla gªównej aplikacji, podczas gdy wi kszo± pracy zwi zanej z wy±wietleniem informacji dla u»ytkownika zostaje przekazana do wtyczki (ang. plug-in), która samodzielnie renderuje obraz i wy±wietla w fragmencie strony. Wbrew pozorom istnienie plugina nie komplikuje procesu interakcji z u»ytkownikiem, a wr cz go usprawnia. Adobe Flash, a wcze±niej Macromedia Flash - byªy jednymi z pierwszych pluginów, które wykorzystywaªy funkcj automatycznej instalacji na» danie wysªane z renderowanej strony. Process pobierania i instalacji plugina potra cego wy±wietla obiekty Flex/Flash przebiegaª niewidocznie z punktu widzenia u»ytkownika i w ko«cowym efekcie spowodowaª lawinowy wzrost wykorzystania elementów Flash w stronach WWW, nawet tych w których wi kszo± informacji zostaªa przekazana w standardzie WWW. Obiekty Flex/Flash maj bardzo wa»n zalet z punktu widzenia programisty i projektanta - dziaªaj tak samo niezale»nie od przegl darki i systemu operacyjnego. Co wi cej w opisie obiektu Flash/Flex podawana jest minimalna wersja plugina wymagana do wy±wietlenia danego obiektu, tak wi c programista nie musi analizowa problemu popularno±ci danej wersji przegl darki - mo»e korzysta z najnowszych funkcjonalno±ci dost pnych przez pluginy Flash, a w przypadku gdy dany u»ytkownik takiej wersji nie posiada - zostanie ona dla niego pobrana i zainstalowana. Dodatkowo nale»y podkre±li wysiªek rmy Macromedia, a obecnie Adobe, by utrzymywa i udost pnia jednocze±nie nowy plugin Flash dla wszystkich wa»niejszych przegl darek i systemów operacyjnych. Ta metodologia znakomicie upraszcza budowanie i testowanie aplikacji wykorzystuj - cych Flash. Wystarczy wybra poziom funkcjonalno±ci oferowany przez ró»ne wersje plaginów Flash, a nast pnie pisa i testowa aplikacj w caªkowitym oderwaniu od typu i wersji przegl darki, na której b dzie ona ostatecznie wy±wietlona.\n48 ROZDZIAŠ 6. APLIKACJA KLIENCKA 47 Ze wzgl du na wzrastaj c popularno± pluginów i aplikacji pisanych w technologii Flash, rma Adobe wprowadziªa pewne rozszerzenia do orginalnej koncepcji Flash, pozwalaj ce na szybsze i sprawniejsze pisanie typowych aplikacji biznesowych, w których efekty wizualne, b d ce mocn stron obiektów Flash, ust puj miejsca wa»no±ci funkcjonalno±ci i wygodzie u»ytkowania. Ten nowy standard oparto o pliki XML, zwane MXML, które pozwalaj na generacj kodu Flash bez jego pisania (lub przy niewielkim wysiªku, w postaci wstawek (ang. snipet) w pliku MXML. Ten nowy format wraz z generatorem kodu opartego o MXML zostaª nazwany Flex. Bardzo istotn cech tego rozwi zania jest to,»e co prawda proces tworzenia aplikacji jest nieco inny, ale sposób wykorzystania ko«cowego produktu przez u»ytkownika jest praktycznie identyczny, tj. poprzez t sam przegl dark internetow. Z uwagi na to,»e nalnie aplikacje napisane we Flex-ie s kompilowane do takiego samego byte-codu jak aplikacje napisane we Flash-u, wi c do ich wy±wietlenia wystarczy ten sam plugin wbudowany w wybran przez u»ytkownika przegl dark. Taka funkcjonalno± spowodowaªa ponowne zwi kszenie popularno±ci aplikacji opartych o technologie rmy Adobe. Niestety aplikacje Flash s napisane w j zyku Actionscript 3.0 (AS3.0), który musi by skompilowany do postaci byte-code, a nast pnie spakowany w format SWF, który plugin Flash potra wy±wietli. Do tego celu wymagane jest specjalistyczne pªatnie oprogramowania sprzedawane przez rm Adobe. Dodatkowym mankamentem aplikacji napisanych w j zyku AS3.0 jest to,»e tre± w nim zawarta, nie jest ªatwo dost pna z uwagi na binarny format pliku SWF, oraz na jego struktur wewn trzn. Plik SWF ma struktur podobn do struktury plików lmowych np. AVI, gdzie na pocz tku pliku zgromadzone s dane w postaci sªownika, które nast pnie s wykorzystywane w procesie renderowania poszczególnych klatek lmu. Taki format powoduje,»e niezwykle trudno jest poª czy znalezione informacje w logiczne i spójne grupy, bez przeprowadzenie praktycznie peªnego procesu renderowania, takiego samego jaki przeprowadza plugin. To powoduje,»e w zasadzie»adna wyszukiwarka internetowa nie przeprowadza obecnie analizy zawaro±ci tre±ci plików SWF, nie potra zanalizowa ich zawarto±ci. To oznacza,»e technologia ta nie nadaje si w przypadku gdy zale»y nam na szybkim rozpropagowaniu informacji nt. nowootwartego serwisu w sieci Internet Ocena rozwi zania Mimo licznych zalet, takich jak uniwersalno± rozwi zania ªatwo± testowania wynikaj ca nie tylko z niezale»no±ci aplikacji typu Flash od konkretnej przegl darki, ale tak»e od mo»liwo±ci debugowania aplikacji Flash za pomoc wbudowanege debugera, sprawdzanie kodu za pomoc parsera, który tak»e jest dost pny z poziomu programu IDE, wygenerowany plik SWF skutecznie chroni posiadan informacj przed dost pem ze strony wyszukiwarek internetowch, tak»e jedyn szans na znalezienie nowootwartego serwisu jest otrzymanie informacji zawieraj cej peªny adres serwisu. Z tego powodu, który jest sprzeczny z wymaganiem umo»liwienia przetwarzania informacji zawartych w oferowanym serwisie przez wyszukiwarki internetowe, technologia\n49 ROZDZIAŠ 6. APLIKACJA KLIENCKA 48 Flex/Flash zostaje odrzucona Aplet Java/JavaFX Rozwi zanie oparte jest o obiekty Java procesowane i wy±wietlane wewn trz przegl - darki internetowej. Tak jak w przypadku obiektów Flash, tak»e w przypadku apletów Java wymagany jest plugin mog cy wykona jego specyczny kod - byte-code. Niestety rma Sun w czasie wprowadzenie tego rozwi zania zaªo»yªa,»e plugin nie b dzie posiadaª peªnej funkcjonalno±ci JVM, a jedynie wywoªywaª JVM uprzednio zainstalowan na danym komputerze. Dodatkowo wyª czono automatyczn instalacj obu potrzebnych komponentów ze wzgl dów bezpiecze«stwa. Problem u»yteczno±ci apletów pogª biª si w sytuacji, gdy rma Microsoft zrezygnowaªa z promocji idei wspólnej maszyny wirtualnej Java (JVM ), a zacz ªa wprowadza wªasn jej odmian, a pó¹niej przeszªa na promocj swojego rozwi zania opartego o C#. Suma tych wypadków, oraz maªo uniwersalny i niewygodny silnik renderowania graki, niepozwalaj cy w sposób efektywny na tworzenie nawet prostych animacji spowodowaª,»e ilo± wykorzystywanych apletów na stronach WWW z roku na rok, mimo wysiªków rmy Sun malaª. Oczywi±cie dzisiejsze aplety mogªyby by u»ywane w sposób du»o wygodniejszy ni» w momencie ich wprowadzenia, ale mimo to s one ci gle mniej wygodne, nieprze¹roczyste dla u»ytkowników. Dodatkowo nowy opiekun j zyka Java i wszystkich okoªo-javowych narz dzi i idei - rma Oracle - wyra¹nie idzie w stron wykorzystania dojrzaªej idei serwerów WWW opartych o ró»ne technologie javowe, ale raczej nie inwestuje czasu i pieni dzy w rozwój rozwi za«klienckich (pod przegl dark WWW ). Oczywi±cie rozwi zanie oparte o aplety Java czy j zyk skryptowy JavaFX (kompilowany do formatu zbli»onego do apletów Java), ma olbrzymie zalety z powodu wykorzystania doskonale znanego, szybkiego, a przy tym do± prostego j zyka oraz mnóstwa gotowych narz dzi przygotowanych do pisania, testowania, debagowania i integracji aplikacji Java, ale ci gle niedopracowany i niewygodny sposób korzystania z gotowego apletu przez u»ytkownika ko«cowego znacz co obni»a walory tego rozwi zania. Aplety Java nie s specjalnie ró»ne od innych aplikacji napisanych w j zyku Java. Ich wewn trzny format to format binarny klas (fragmentów kodu) pogrupowanych odpowiednio w katalogi ze wzgl du na ich funkcjonalno±, a nast pnie spakowane do postaci archiwum, które w zasadzie jest identyczne ze standardem formatem ZIP. Z tego wzgl du, tak jak w przypadku informacji zawartych w binarnych plikach formatu SWF, tak jak w przypadku plików JAR (spakowanych klass), jak i poszczególnych plików w formacie CLASS, ich dane wewn trzne nie s w prosty sposób dost pne bez przeprowadzenia peªnej analizy, podobnej do tej jak wykonuje w przypadku JVM tzw. class loader. To powoduje,»e i w przypadku apletów ich dane b d niedost pne dla wyszukiwarek internetowych.\n50 ROZDZIAŠ 6. APLIKACJA KLIENCKA Ocena rozwi zania Z powodu postawionego zaªo»enia o ªatwo±ci korzystania z wybranego rozwi zania, tj. rozwi zanie musi wymaga jak najmniejszej ilo±ci dodatkowych operacji, poza wpisaniem odpowiedniego adresu do wybranej przegl darki WWW, oraz z powodu braku mo»liwo±ci ªatwego parsowania zawarto±ci binarnych appletów przez wyszukiwarki internetowe - rozwi zanie to zostaje odrzucone jako nie speªniaj ce wymogów stawianych przed aplikacj klienck. 6.3 Wybrane rozwi zanie Spo±ród przedstawionych rozwi za«wybranym i proponowanym rozwi zaniem jest rozwi zanie oparte o dynamicznie generowny kod HTML (stron WWW). Pomimo nieco wi kszego nakªadu pracy jest to jedyne rozwi zanie speªniaj ce wszystkie postulowane wymagania, a dodatkowy nakªad pracy by mo»e zostanie zminimalizowany, poprzez wykorzystanie specjalizowanych narz dzi do tworzenia stron WWW, oraz pewnych mechanizmów wbudowanych w serwery aplikacyjne zgodne ze standardem J2EE, które potra tak»e sprawia by generowany kod byª poprawnie renderowany przez wi kszo± przegl darek. Nale»y tu podkre±li,»e w zaªo»eniu aplikacji klienckich, ilo± danych które s wbudowywane w wy±wietlane strony WWW wielokrotnie przewy»sza ilo± danych wymienianych pomi dzy przegl dark a serwerem aplikacyjnym poprzez protokóª AJAX. Oznacza to mniejsz ilo± specjalizowanego kodu napisanego w j zyki Javascipt, który jest du»o bardziej zale»ny od typu i wersji przegl darki ni» struktura strony WWW opisanej za pomoc znaczników HTML. Dodatkowo w celu u±ci±lenia nale»y podkresli,»e ze wzgl du na wybrany serwer oraz potrzeby aplikacji klienckiej proponowane jest, by generacja stron WWW odbywaªa si z wykorzystaniem technologii JSF (Java Server Faces) uzupeªnionej o Java Portlets.\n51 Rozdziaª 7 Aplikacja administratora 7.1 Wymagania ˆ ªatwo± i prostota instalacji i u»ytkowania [**] ˆ dobrze wspóªpracuj ca z wybran platform aplikacyjn [***] ˆ ªatwo± wymiany informacji z wybran platform aplikacyjn [***] ˆ ªatwo± generowania widoków wy±wietlanych przez wybrane przegl darki WWW [***] ˆ oparcie o kod ogólnodost pny (open source) [**] ˆ obªuga metodologii: server push, tj. serwer inicjuje wysªanie danych do klienta - niezb dne do natychmiastowego wy±wietlania notykacji systemowych [***] ˆ zapewnienie wysokiego poziomu bezpiecze«stwa, zarówno od strony autoryzacji u»ytkownika jak i od strony dost pu do danych ˆ aplikacja b dzie typem aplikacji dummy czyli takiej, która praktycznie nie posiada wbudowanych»adnych danych, a dane dost pne dopiero po procesie autoryzacji zostaj przekazana na czas wy±wietlenia [***] ˆ aplikacja nie powinna zostawia danych w przegl darce w postaci historii wykorzystywanych adresów URL, oraz obiektów przechowywanych w cache-u przegl - darki [***] 7.2 Porównanie wybranych rozwi za«7.2.1 Dynamicznie strony WWW Opis dynamicznie generowanych stron mo»na znale± w rozdziale na stronie 43, dlatego te» zostanie on pomini ty w tym rozdziale. Jedynie ocena celowo±ci wykorzys- 50\n52 ROZDZIAŠ 7. APLIKACJA ADMINISTRATORA 51 tania dynamicznie generowanych stron WWW dla aplikacji administratora zostanie oceniona w nast pnym paragrae Ocena rozwi zania Rozwi zanie oparte o dynamicznie generowane strony WWW posiada te same wady i zalety, jak to zostaªo opisane w poprzednich rozdziaªach, jednak z powodu nieco innych wymaga«aplikacji administratora, ich ocena przydatno±ci do tego typu aplikacji jest nieco inna. Wydaje si,»e ze wzgl dów bezpiecze«stwa, oraz z powodu wymagania dotycz cego ochrony danych, tj. nie udost pnianiu ich poza kr g uprawnionych u»ytkowników, rozwi zanie bazuj ce na dynamicznie generowanych stronach jest mniej atrakcyjne. Problemem jest tu tzw. cache-owanie informacji, które jest zale»ne od wªa±ciwo±ci przegl darki, i cz sto nawet w przypadku korzystania z mechanizmów wymuszenia wyª czenia wªa±ciwo±ci cache-owania danych (np. dyrektywa HTTP: pragma: nocache), nie jest w peªni respektowana przez wszystkie przegl darki. Dodatkowo dynamicznie generowane strony WWW nie pozwalaj na proste stworzenie rozdzielnych kanaªów komunikacyjnych dla danych oraz widoków. To z kolei powoduje konieczno± szyfrowania wszystkich danych poª czenia, co niepotrzebnie zwi ksza obci»enia serwera. Dodatkowym zagro»eniem s ataki typu XSS (ang. cross site scripting) oraz cz sto pojawiaj ce si bªedy w samym protokole HTTP czy j zyku HTML. Przykªadem takich bª dów mog by np. bª dy wykryte w nowoprojektowanym j zyku HTML 5.0 (np. ). Mimo,»e jako± i mechnizmy zabezpieczaj ce dane udost pniane przez przegl - darki internetowe zostaªy w dramatyczny sposób ulepszone, ci gle udaje si znale± do± proste metody przechwycenia informacji wysyªanych do i przez przegl dark. Dodatkowo rozwi zanie oparte o dynamicznie generowane strony WWW, nie posiada zintegrowanego mechanizmu typu server push, tj. wymiany danych inicjowanych ze strony serwera. Jedynym dost pnym mechanizmem mimikuj cym to zachowanie mogªby by mechanizm typu data pull, tj. cykliczne pobieranie danych w tle, oparte np. o protokóª AJAX. Ze wzgl du na mniejsz wygod i wydajno± tego rozwi zania, oraz z powodu problemów zwi zanych z bezpiecze«stwem danych, rozwi zanie to jest mniej preferowane, szczególnie w sytuacji, gdy isniej rozwi zania alternatywne Aplikacja Adobe Flex/Flash Opis dynamicznie generowanych stron mo»na znale± w rozdziale na stronie 46, dlatego te» zostanie on pomini ty w tym rozdziale. Jedynie ocena celowo±ci wykorzystania obiektów Flash dla aplikacji administratora zostanie oceniona w nast pnym paragrae Ocena rozwi zania W przypadku aplikacji administratora, rozwi zanie oparte o obiekty Flash wydaje si rozwi zaniem bardziej przystaj cym do listy wymaga«przedstawionych w rozdziale 7.1.\n53 ROZDZIAŠ 7. APLIKACJA ADMINISTRATORA 52 Szczególnie cecha objektów Flash, która zani»aªa ich warto± w przypadku aplikacji klijenckiej, tj. binarny charakter, z utrudnionym dost pem do danych - w przypadku aplikacji administratora, staje si jej zalet. Taka budowa obiektów Flex, chroni ich zawarto± przed przypadkow propagacj danych przechwyconych przez wyszukiwarki internetowe. Dodatkowo, poniewa» Flex/Flash oferuje bardzo rozbudowany wachlarz mo»liwo±ci pobierania danych, a nast pnie wykorzystywania ich do uzupeªniania danego widoku, mechanizmy te s w stanie w znacznie lepszy sposób wypeªni wymagania aplikacji typu dummy, ni» mo»e to mie miejsce w przypadku aplikacji opartych o czysty protokóª AJAX. Co wi cej, dane przekazane np. za pomoc technologii RemoteObject nie s cache-wane przez przegl dark - co dadatkowo zwi ksza ich bezpiecze«stwo. Rozdzielenie kanaªów komunikacyjnych do przesyªania danych oraz widoków aplikacji mo»e tak»e skutkowa zwi kszeniem wydajno±ci systemu. Stanie si tak, gdy mechanizmy szyfrowania zostan wª czone jedynie do celów autoryzacji oraz do przekazywania danych, natomiast sama aplikacja zawieraj ca widoki mo»e zosta przesªana w sposób niewymagaj cy szyfrowania. Z uwagi na to,»e w ostatnim okresie rma Adobe promuje rozwi zanie skªadaj ce si z aplikacji webowych napisanych w technologii Flash/Flex oraz serwera danych opartego o technologi J2EE, dost pnych jest wiele rozwi za«pozwalaj cych ª czy te dwie technologie, nawet na najni»szym binarnym poziomie, tj. istniej translatory tªumacz ce posta binarn obiektów Java na binarne obiekty AS3.0 i vice versa. Jedym z takich rozwi za«jest np. GraniteDS - pozwalaj cy na bardzo ªatw wymian danych pomi dzy aplikacj napisan we Flex-ie, a obiektami EJB znajduj cymi si wewn trz ±rodowiska dowolnego serwera J2EE, np. GlassFish. Wykorzystanie technologii Flex/Flash do tworzenia aplikacji pozwoli tak»e na uproszczenie procesu tworzenia aplikacji, gªównie ze wzgl du na jednolit warstw API, niezale»n od wykorzystywanej przegl darki oraz systemu operacyjnego Aplet Java/JavaFX Opis dynamicznie generowanych stron mo»na znale± w rozdziale na stronie 48, dlatego te» zostanie on pomini ty w tym rozdziale. Jedynie ocena celowo±ci wykorzystania apletów Java dla aplikacji administratora zostanie oceniona w nast pnym paragrae Ocena rozwi zania Pomimo pewnych podobie«stw rozwi zania opartego o aplet Java i rozwi zania opartego o technologi Flash/Flex, rozwi zanie oparte o aplet Javy posiada ci gle te same wady, czyli wymagania dodatkowego i manualnego wykonania instalacji JRE w przypadku ka»dej maszyny klienckiej (korzystaj cej z apilkacji administratora). Taka procedura wymagana do rozpocz cia korzystania z Platformy PCM jest sprzeczna z wymaganiem ªatwo±ci u»ytkowania i instalacji aplikacji administratora. Zatem, pomimo podobnych zalet jak w przypadku aplikacji napisanych w technologii Flex, a nawet\n54 ROZDZIAŠ 7. APLIKACJA ADMINISTRATORA 53 dodatkowej zalety w postaci jednakowego j zyka programowania - co zwykle skutkuje bardziej elastycznym rozwojem aplikacj (np. mo»liwe jest ªatwiejsze u»ytkowania zasobami ludzkimi), nale»y tak»e w przypadku aplikacji administratora odrzuci to rozwi zanie jako zbyt niewygodne dla ko«cowego u»ytkownika. 7.3 Wybrane rozwi zanie Z uwagi na postawione wymagania, proponowanym rozwi zaniem do tworzenia aplikacji administratora, jest rozwi zanie oparte o technologi Flash/Flex. Zakªada si stworzenie intefejsu u»ytkownika w technologii Flex, korzystaj c z generowania widoków u»ytkownika z przygotowanych formatek MXML, które do komunikacji z serwerem aplikacyjnym GlassFish wykorzystaj, wbudowany w technologi Flex, mechanizm oparty o protokóª RO (remote object), komunikuj cy si z moduªem konwertuj cym obiekty AS3.0 do postaci obiektów Java, które mog by bezpo±rednio wykorzystane wewn trz serwera J2EE. Komunikacja w odwrotnym kierunku nast puje w podobny sposób, tj. obiekty Java stworzone poprzez server J2EE, s konwertowane za pomoc tego samego konwertera (GraniteDS) do postaci obiektów AS3.0, które s dostarczane do aplikacji Flex za pomoc protokoªu RO. Caªa ta ±cie»ka nie wymaga wysiªku od twórców systemu Platformy, gdy» wszystkie wymienione mechanizmy s ju» gotowe i przetestowane - jedynie wymagana jest ich konguracja wewn trz servera J2EE.\n55 Rozdziaª 8 Platforma bazodanowa Jednym z gªównych wymaga«platformy PCM jest przechowywanie i wyszukiwanie danych MBiol. W tym celu Platforma zawiera jako jeden z komponentów podsystem bazy danych. System bazy danych wymagany przez Platform, musi - obok speªniania wymaga«wymaganych w nast pnym rozdziale, stanowi bardzo wydajn platform przetwarzaj c, z uwagi na kluczow funkcjonalno± Platformy, tj. zarz dzanie danymi. 8.1 Wymagania 1. rozwi zanie typu klaster, tj. z wieloma serwerami bazodanowymi, z których ka»dy mo»e by niezale»nie wykorzystywany do przetwarzania zapyta«aplikacji klienckiej [***] 2. klaster typu master only - tzn. wszystkie w zªy klastra (serwery) s równorz dne, speªniaj c tak sam rol w systemie, brak serwerów typu slave, u»ywanych jedynie w przypadku awarii lub do tzw. zapyta«niemodykuj cych [***] 3. synchroniczna replikacja master-master - brak mo»liwo±ci utraty danych (lub ich desynchronizacji) w przypadku awarii sprz tu [***] 4. odporno± na zerwanie poª czenia sieciowego [***] 5. mo»liwo± rozszerzenia klastra o nowe w zªy bez konieczno±ci jego restartu [**] 6. architektura wspieraj ca brak wspóªdzielenia jakkichkolwiek zasobów sprz towych (ang. shared nothing architecture) [***] 7. brak pojedynczego elementu skutkuj cego awari systemu bazy danych (ang. single point of failure) [***] 8. wzrost wydajno±ci klastra w zale»no±ci od ilo±ci w zªów powinien by liniowy (lub jej jak najbli»szy) [***] 54\n56 ROZDZIAŠ 8. PLATFORMA BAZODANOWA Porównanie dost pnych rozwi za«w poni»szych podrozdziaªach zgromadzono opis najpopularniejszych rozwi za«klastrów bazodanowych Klaster MySQL Klaster MySQL jest technologi umo»liwiaj c tworznie baz danych w architekturze SN (Shared Nothing). Umo»liwia ona prawie liniow skalowalno±. Implementowana jest przez dodatkowy silnik bazy danych, nazywany NDB lub NDBCLUSTER (NDB jest skrótem od Network Database). Klaster MySQL u»ywa replikacji synchronicznej, wykorzystuj c dwufazowy mechanizm zatwierdzania transakcji gwarantuj cy zapis danych do wielu w zªów. Dwie kopie nazywane replikami s konieczne do zagwarantowania dost pno±ci. Klaster mo»e zapisywa dane od 2 do 4 w zªów. Dane tabel klatra NDB s automatycznie rozdysponowywane na w zªy systemu (tzw. horyzontalne partycjonowanie danych). Dyspozycje realizuje algorytm haszuj cy oparty na unikalnym kluczu danej tabeli. Partycjonowanie jest przezroczyste dla aplikacji. Klaster pozwala u»ytkownikowi zdeniowa swoje schematy partycjonowania. Klaster MySQL pozwala bazom danych, przekraczaj cym pojemno± pojedynczych maszyn na alokacj danych pomi dzy ró»nymi zycznymi serwerami, tworz c tzw. chmur. Wszystkie indeksowane kolumny tabel klaster przetrzymuje w pami ci dzielonej. Nieindeksowane kolumny mog by przetrzymywane na dysku lub w pami ci cache. Zapisywanie nieindeksowanych kolumn na dysku, pozwala klastrowi MySQL przechowywa zbiory danych wi ksze ni» zagregowana pami w zªów klastra. NDB zapisuje na dysku logi Redo dla wszystkich zmian danych. Umo»liwia to przywrócenie spójno±ci danych w przypadku awarii klastra. Logi Redo zapisywane s na dysk asynchronicznie z uwzgl dnieniem kolejno±ci transakcji. Mo»e to skutkowa utrat pewnej liczby transakcji w momencie awarii klastra. Gªówna tabela klastra NDB przetrzymywana jest w pami ci. Operacje zapisu na dysk dotycz tylko logów Redo, dzi ki czemu ª czna przepustowo± klastra jest wi ksza od tradycyjnych systemów bazodanowych.\n57 ROZDZIAŠ 8. PLATFORMA BAZODANOWA 56 Rysunek 8.1: Architektura klastra MySQL Klaster MySQL jest zaprojektowany tak, by nie posiada pojedynczego punktu awarii. Nie jest przy tym wymagany wspóªdzielony udziaª dyskowy (SAN). Poª czenia miedzy w zªami mog by oparte o standardowy Ethernet. Wspierane s tak»e SCI i Ethernet gigabitowy. Klaster MySQL u»ywa trzech ró»nych typów w zªów implementowanych jako procesy: ˆ W zeª danych (procesy ndbd/ndbmtd): w zªy tego typu odpowiedzialne s za zapis danych. ˆ W zeª zarz dzaj cy (proces ndb_mgmd): w zeª u»ywany do konguracji oraz monitorowania klastra. ˆ W zeª SQL (proces mysqld): Standardowy serwer MySQL, poª czony ze wszystkimi w zªami danych w celu wykonywania operacji zapisu i odczytu danych Ocena rozwi zania Zalety rozwi zania: Wady: ˆ Releatywnie nieskomplikowana architektura ˆ Polityka licencjonowania uwzgl dniaj ca dost pno± kodu ¹ródªowego ˆ Mo»liwo± uzyskania komercyjnego wsparcia ˆ Bogata dokumentacja ˆ Rozwi zanie darmowe ˆ Dwufazowy mechanizm zatwierdzania transakcji


Historia Parafii – PARAFIA LASZKI\nLaszki znów samodzielną parafią…\nW roku 1895 nastąpiło jedno z największych wydarzeń w dziejach parafii Laszki – ponowna jej i uwolnienie od wszelkich zależności parafii jarosławskiej. Siedzibą parafii stał się drewniany kościół pod wezwaniem św. Łukasza z 1793 roku, a prawo patronatu przypadło Zamoyskim. Pierwszym proboszczem został ksiądz Ludwik Bikowski (ur. w 1849 r.), dziekan jarosławski. Na terenie parafii powstały liczne kaplice filialne, w których odprawiano Msze Święte w: Wysocku, Moszczanach, Hruszowicach, Miękiszu Nowym, Miękiszu Starym i Korzenicy.\nNa początku XX wieku wzniesiono neogotycki kościół, ufundowany przez Zamoyskich. Równocześnie rozebrano wówczas stary drewniany kościółek, będący w złym stanie, który nie nadawał sie już do remontu. Budowę kościoła rozpoczęto w 1902 roku, a ukończono pięć lat później. Kościół po dziś dzień służy parafianom z Laszek. Kościół, któremu patronują św. Zofia i św. Szczepan, został konsekrowany w 28 października 1928 roku przez biskupa Anatola Nowaka. Gospodarzem nowego kościoła był już ksiądz Franciszek Zawisza (ur. w 1897 r.). Więcej o historii i wystroju kościoła można przeczytać w zakładce „Kościół parafialny w Laszkach”.\nOkres I wojny światowej i 20-lecnia międzywojennego…\nKościół staraniem parafian został odremontowany tuż po wojnie. Kościół zelektryfikowano, także odmalowano i położono nowy dach. W październiku 1947 roku z parafii Laszki wydzielono Wietlin i Wysock w celu utworzenia osobnej parafii, która miała obejmować ponadto Makowisko i Surochów.


Pulpeciki ze szczupaka w galarecie - NaTropieSmakówNaTropieSmaków\nOstatnio u mnie nadzwyczaj słodko, dlatego postanowiłam przygotować dla równowagi kilka przepisów bardziej wytrawnych, a w związku ze zbliżającymi się Świętami pojawią się też propozycje, które z powodzeniem będziecie mogli przygotować na #zdrowąWielkanoc.\nPulpeciki ze szczupaka (lub innej Waszej ulubionej ryby) w galarecie to idealny pomysł na Wielkanocny stół. Przygotowanie może niekoniecznie ekspresowe, chyba że do przygotowania pulpecików użyjecie gotowych filetów, a nie tak jak ja będziecie „rozbierać” rybkę od początku, ale na pewno warte zachodu związanego z przygotowaniem tego dania! Moi domownicy byli wprost zachwyceni! Zaskoczcie i Wy swoich bliskich i przygotujcie coś zaskakującego, a zarazem zdrowego i pysznego. Gorąco polecam 🙂\nSkładniki: (na 2 półmiski)\n800 g filetów ze szczupaka (lub innej wybranej ryby i płatków ryżowych)\nmleko (do namoczenia ryby)\n1,5 l bulionu warzywnego lub rybnego\n1. Oczyszczone z ości i skóry filety rybne moczymy 3-4 godziny w mleku, a następnie dokładnie osuszamy na ręczniku papierowym. Płatki ryżowe zalewamy 4 łyżkami mleka i odstawiamy do napęcznienia. Cebule obieramy i szklimy na łyżce masła klarowanego. Pietruszkę myjemy i siekamy jak najdrobniej.\n2. Osuszoną rybę, napęczniałe płatki ryżowe (jeżeli pozostało z nich odrobina mleka to odlewamy ją), zeszkloną cebulkę oraz siemię lniane mielimy w młynku do mielenia mięsa.\n3. Do zmielonej masy dodajemy sól, pieprz biały i posiekaną pietruszkę, dokładnie mieszamy, odstawiamy na 10 minut do lodówki. W tym czasie bulion umieszczamy w dużym garnku i doprowadzamy do wrzenia. Z masy rybnej lepimy małe pulpeciki i wrzucamy do wrzącego bulionu (możemy gotować je partiami). Gotujemy około 15 minut.\n4. Łyżką cedzakową wyjmujemy pulpeciki i układamy w półmiskach. Żelatynę/agar rozpuszczamy w naszym bulionie zgodnie z instrukcją na opakowaniu. Pulpety zalewamy bulionem i pozostawiamy do stężenia.\n« Czekoladowe babeczki z kremem jaglanym i owocami (bez pieczenia) | Strona główna | Majonez konopny »


VESBO® POLAND - Instalacje Sanitarne - Szkolenia\nVESBO ACADEMY - nowe szkolenia.\nKoniecznie obejrzyj fotorelację z kolejnych szkoleń jakie odbyły się w Oświęcimiu, Busku-Zdroju, Krośnie, Płońsku i Józefowie.\nZobacz również bramki z polipropylenowych rur VESBO, które powstały podczas zawodów zorganizowanych dla naszego Klienta z Wejherowa.\nSzkolenia dla Klientów VESBO to nie tylko przyswajanie wiedzy, ale również przyjemne spędzanie czasu.\nZobacz fotorelację z ostatnich wspólnych spotkań.\nSzkolenie w Rzeszowie, miejscowości koło Pruchnika oraz Makowie Mazowieckim\nW ostatnich dniach mieliśmy przyjemność zorganizowania szkolenia dla naszych Klientów z Kowna i Wilna.\nNa spotkaniu przedstawiliśmy możliwości systemów instalacyjnych VESBO. Nauka odbywała się w przyjemnej atmosferze, połączonej z zabawą. Można było również wygrać atrakcyjne nagrody.\nSzkolenie Kowno i Wilno - zobacz galerię\nVESBO kładzie nacisk na propagowanie fachowej wiedzy specjalistycznej z zakresu instalacji sanitarnych. W tym celu systematycznie od lat organizuje szkolenia dla wszystkich chcących poszerzyć wiedzę z technik instalacyjnych.\nW warsztatach uczestniczy młodzież kształcąca się w szkołach o profilu technicznym, instalatorzy i projektanci specjalizujący się w branży instalacyjnej jak również hurtownie oferujące produkty z artykułami sanitarnymi.\nZadzwoń lub napisz - umów się na szkolenie\nSzkolenia - zobacz galerię