Wirtualizacja wirtualnej maszyny Java - czyli jak uruchamiać aplikacje Java bez systemu operacyjnego
Waldek Kot
Dosyć powszechnie uważa się, że największą zaletą technologii Java jest JVM - Java Virtual Machine. Dzięki JVM programy tworzone w językach Java, Scala, Groovy, Ruby czy wielu innych, są nie tylko przenośne między różnymi środowiskami, ale także działają bezpiecznie, są zarządzalne, a do tego jeszcze wydajne. Widać to szczególnie w serwerowych zastosowaniach JVM. Od pewnego czasu upowszechnia się i znajduje coraz nowe zastosowania technologia wirtualizacji sprzętu, w której za pomocą hypervisora możliwe jest udostępnienie w ramach pojedynczego fizycznego komputera, wielu komputerów logicznych (wirtualnych maszyn). W tutaj przyjętej definicji wirtualizacji - hypervisor to specjalizowane oprogramowanie, "zastępujące" system operacyjny fizycznej maszyny. Jest to stosunkowo cienka warstwa zajmująca się zarządzaniem zasobami fizycznego komputera i koordynowaniem dostępu do nich przez maszyny wirtualne, tak, aby oprogramowanie działające w ramach wirtualnego komputera "myślało", że działa w ramach prawdziwego (=fizycznego) sprzętu. Hypervisor pozwala na równoczesne działanie w ramach fizycznej maszyny wielu maszyn wirtualnych (dzisiaj, z racji powszechności wydajnych wieloprocesorowych/wielordzeniowych serwerów, często w ramach jednej fizycznej maszyny działają dziesiątki i setki maszyn wirtualnych). Zarówno z wewnątrz (czyli dla oprogramowania działającego w ramach maszyny wirtualnej - np. systemu operacyjnego, czy aplikacji, w tym JVM, serwerów aplikacyjnych, czy aplikacji Java EE), jak i z zewnątrz (czyli dla użytkowników) taki wirtualny komputer niczym się nie różni od fizycznego (od wewnątrz udostępnia 'wirtualne wersje' BIOS, CPU, RAM czy urządzeń takich jak karta sieciowa, czy dyski; z zewnątrz jest dostępny poprzez sieć, itd). Zaletą takiej wirtualizacji jest znacznie większa elastyczność - udostępnienie nowego komputera trwa bardzo krótko. W dodatku takie maszyny można bardzo łatwo klonować, zapewniając niemal ich identyczną konfigurację (nie tylko identyczny sprzęt, ale także choćby identyczne ustawienia security, czy identyczny zestaw aplikacji/usług mających działać w takim komputerze). Wirtualny komputer istnieje w zasadzie w postaci zbioru danych, np. pliku. Takie podejście otwiera także ciekawe (mimo, iż dostępne już od dosyć dawna) możliwości, jak np. możliwość migracji wirtualnych komputerów pomiędzy różnymi fizycznymi komputerami (w migracji "na żywo", tj. bez przerwy w pracy oprogramowania działającego wewnątrz maszyny wirtualnej i w sposób niezauważalny dla użytkowników tego oprogramowania). Niemal nieustannie odkrywane są coraz to nowe zastosowania wirtualizacji - choćby związane z podniesieniem poziomu bezpieczeństwa i niezawodności systemów, a nawet przyjazności dla środowiska naturalnego (w ramach "green computing"). Wirtualizacja leży u podstaw takich innowacji jak cloud computing. Wirtualizacja nie pozostaje bez wpływu na technologię JVM. W dążeniu do coraz większej efektywności i elastyczności aplikacji Java (szczególnie serwerowych), wirtualizacja "poprzez hypervisor" może odegrać tu istotną rolę. Hypervisor znacznie ułatwia budowę specjalizowanych (=dedykowanych) "systemów operacyjnych", dzięki którym JVM może działać bardziej optymalnie. Maszyna wirtualna Javy bowiem, szczególnie w zastosowaniach serwerowych, niemal nie potrzebuje systemu operacyjnego (niektórzy twierdzą, że jest to maksymalnie 0.5% kodu OS, głównie związanego z niskopoziomowym zarządzaniem pamięcią i wątkami, I/O w zakresie sieci i storage'u oraz narzędziami do monitorowania i administracji - resztę zadań i tak implementuje JVM - a w środowisku zwirtualizowanym także hypervisor). Co więcej, klasyczny system operacyjny nie rozumie tego co dzieje się wewnątrz JVM i dosyć nagminnie przeszkadza JVM w efektywnym wykonywaniu aplikacji (tzw. efekt podwójnej - a w środowisku wirtualnym - nawet potrójnej wirtualizacji). Wiele zadań jest wykonywanych nadmiarowo, w nieskoordynowany sposób przez JVM, hypervisor i OS. Może zatem warto pozbyć się takiego "rozdmuchanego" systemu operacyjnego, skoro JVM i tak go w zasadzie nie używa ? Tym właśnie jest wirtualizacja JVM - możliwość uruchamiania JVM bezpośrednio w ramach wirtualnych maszyn udostępnianych przez hypervisor, bez systemu operacyjnego. A dokładniej: zamiast zwykłego OS, JVM działa na specjalizowanej, bardzo cienkiej (rzędu 1-2 MB) warstwie pełniącej rolę systemu operacyjnego, która udostępnia JVM tylko te usługi, których ta rzeczywiście od OS potrzebuje. Korzyści z oddania sporej ilości zasobów (pamięć, CPU) zajmowanych (marnotrawionych ?) wcześniej przez OS i lepszej koordynacji zadań widać szczególnie wtedy, gdy w ramach jednej fizycznej maszyny działa wiele (dziesiątki/setki) maszyn wirtualnych. W takiej kombinacji pojawia się możliwość praktycznej realizacji wielu dodatkowych optymalizacji w wykonywaniu kodu Java. Niektóre z tych optymalizacji udostępnia technologia JRockit Virtual Edition - maszyny wirtualnej Java (JRockit JVM) działającej bez systemu operacyjnego w środowisku opartego o Xen hypervisora Oracle VM. Podczas tej sesji chciałbym zaprezentować wybrane aspekty technologii wirtualizacji, szczególnie w kontekście jej wpływu na Java i JVM. Będzie sporo praktycznych demonstracji z wykorzystaniem aktualnych wersji JRockit VE, WebLogic Server VE i Oracle VM (zapraszam także tych, którzy chcą zobaczyć zwirtualizowane aplikacje napisane w Ruby i Groovy ;-)). W pewnym zakresie sesja będzie podobna do tej, którą mogli zobaczyć uczestnicy konferencji GeeCon 2009 w Krakowie. Postaram się jednak pokazać także nowe rzeczy. Najbardziej liczę jednak na to, że ta innowacja w świecie Java pt. wirtualizacja wirtualnej maszyny Java przede wszystkim zaciekawi społeczność Java (a pewnie i nie obędzie się bez kontrowersji i emocji, których przykłady mogli zaobserwować uważni czytelnicy grupy dyskusyjnej pl.comp.lang.java). A niektórych może nawet zachęci do dalszych poszukiwań usprawnień w JVM. Serdecznie zapraszam ! Testy wspaniałe zdobywają Warszawę Szczepan Faber
Po mojej sesji Warszawa będzie inna. Programiści zaczną pisać testy, które inni programiści będą rozumieć od razu. Debugger stanie się ekscentrycznym urządzeniem, o którym większość programistów zapomni. Rzadziej będziemy słyszeć: „nie napisaliśmy testów, bo one zawsze utrudniają refaktoring i dodawanie nowych funkcjonalności”. Częściej będziemy słyszeć: „pewnie, że mamy testy”. Szczepan, czy ty czasem nie opowiadałeś o wspaniałych testach na ostatnim GeeCON’ie? Owszem, ale tamta sesja to był tylko wstęp do tematu. Kraków nie był jeszcze gotowy, żeby poznać wyższe voodoo wspaniałych testów (no i bilet na prezentację dostałem od organizatorów 2 dni wcześniej...). Co będzie na sesji? Slajdy, java na slajdach, kodowanie na żywo (jeśli mój jedyny słuszny OS pozwoli), nieco dogmatycznej ewangelizacji i dużo wzorców do wykorzystania w codziennym kodowaniu. Warsztaty 'coding by example' Bartosz Bańkowski, Igor Czechowski, Szczepan Faber W skrócie: nie pisz testów, pisz przykłady. Wierzymy, że 'poprawne' TDD to nie testowanie kodu, tylko dokumentowanie zachowań obiektów i pokazywanie tych zachowań na przykładach.
Jeżeli jeszcze nie stosujesz TDD, zapraszamy na warsztat - spróbujemy nauczyć Cię 'poprawnego' TDD. Jeżeli już stosujesz TDD, zapraszamy na warsztat - spróbujemy podszkolić twój styl TDD, a twoja wiedza bardzo się przyda w dyskusjach i w pomocy innym uczestnikom.
Zamiast 'coding by example', moglibyśmy nazwać warsztaty: 'BDD, czyli jak połączyć TDD z DDD', ale mamy już dość trzyliterowych skrótów.
Warsztat trwa 3 godziny. Jeżeli trafisz w połowie sesji, nie powinieneś mieć problemu z dogonieniem reszty grupy, ponieważ dołączymy Cię do odpowiedniej pary. Prawie zapomniałem: podczas warsztatu programujemy w parach, więc albo swój laptop (zalecane), albo poszukamy dla Ciebie pary z laptopem. Google Web Toolkit i Seam, czyli piękny wygląd z bogatym wnętrzem
Celem wystąpienia jest prezentacja najnowszych możliwości Google Web Toolkit - narzędzia do tworzenia bogatych interfejsów webowych przy użyciu języka Java - oraz wskazanie zalet i problemów występujących przy integracji oprogramowania wykorzystującego GWT z biblioteką Seam. Zarówno GWT, rozwijane przez Google, jak i Seam, mające wsparcie JBoss, są projektami open source o solidnych podstawach i szerokim wsparciu środowiska. Mając na celu przyspieszenie i ułatwienie tworzenia aplikacji webowych i enterprise, stanowią świetne uzupełnienie, którego warto być świadomym rozpatrując technologie odpowiednie do realizacji projektów informatycznych.
W czasie prezentacji dokonane zostanie porównanie Google Web Toolkit z alternatywnymi rozwiązaniami, omówiona zostanie specyfika tego narzędzia, jego wady i zalety, istniejące aplikacje wykorzystujące GWT oraz perspektywy na przyszłość. W drugiej części wystąpienia biblioteka Seam zaprezentowana zostanie jako dopełnienie GWT dla warstw aplikacji realizowanych po stronie serwera. Zaproponowane zostanie tym samym kompletne rozwiązanie, potencjalnie przewyższające w łatwości i szybkości realizacji projektu inne możliwości, najczęściej stosowane. Ewolucja Architektury Paweł Lipiński
Architektura oprogramowania to ten jego składnik, co do którego
decyzje podejmowane są zwykle na samym początku projektu. Na czym
bardziej zaawansowanym etapie jest projekt, tym bardziej ryzykowne i
kosztowne są jej zmiany. Czasem jednak takie zmiany są niezbędne.
Czasem architektura ma oczywiste błędy. Czasem wymagania co do
funkcjonowania systemu zmieniają się do tego stopnia, że oryginalna
jego architektura nie może im sprostać. Paweł omówi sposoby radzenia
sobie w takich sytuacjach. Opisze jak kwestie ewolucji architektury
podejmowane są w projektach prowadzonych przy pomocy zwinnych
metodyk. Wskaże sposoby tworzenia aplikacji w taki sposób by jak
najmniej wiązać logikę aplikacji z jej architekturą, tak by umożliwić,
a czasem nawet promować jej ewolucję. |
