2. JavaEE + OSGi AGENDA 1. Case study 2. Idea modularyzacji 3. Modularyzacja w JavaEE 4. Wprowadzenie w OSGi 5. Współpraca JavaEE + OSGi 6. Prezentacja platformy webowej osgi
4. JavaEE + OSGi Case study Jak szybko zbudować system wsparcia sprzedaży dla nowego banku? Nic trudnego, napiszemy aplikację webową Java EE ! Zalety: standardowa architektura, pełna współpraca kodu, dewelopowanie in-place, łatwe testowanie, spójny interfejs użytkownika, klarowne zarządzanie sesją duże wsparcie ze strony IDE Zrobione ! w naszym przypadku: > 1 mln linii kodu > 10 tys. klas > 1500 klas akcji struts > 2300 ścieżek do akcji > 1000 stron JSP > 8 zespołów > 60 osób JVM JEE Server Aplikacja Webowa ale po pewnym czasie ... 100 tys. linii kodu 2 zespoły programistów po dłuższym czasie 500 tys. linii kodu 4 zespoły programistów jar-hell długie kompilacje, przeciążenie zasobów IDE problemy przy dewelopowaniu wielozespołowym (merge) ograniczona skalowalność (do ~100 tys. linii kodu) trudności przy wariantowaniu aplikacji kłopoty z izolacją zagadnień (SoC)
5. JavaEE + OSGi Co z tym teraz zrobić ? Case study JVM JEE Server Podzielmy aplikację na moduły ! Co to jednak znaczy „ podzielić aplikację na moduły”?
42. JavaEE + OSGi Przegląd technik Rozważmy 5 propozycji modularyzacji: 1. Statyczna kompozycja standardowej aplikacji webowej z modułów na etapie budowania (maven overlays, ant build). 2. Dynamiczna k ompozycja aplikacji webowej z modułów (fragmentów) w trakcie inicjalizacji (od JEE6, Servlet 3.0). 3. M oduły jako odrębne aplikacje webowe na wspólnym serwerze. 4. M oduły jako odrębne aplikacje webowe rozproszone na wielu serwerach. 5. Aplikacja webowa ze zintegrowaną platformą OSGi, moduły aplikacyjne jako paczki osgi.
44. JavaEE + OSGi Przegląd technik 1. Statyczna kompozycja standardowej aplikacji webowej z modułów na etapie budowania (maven overlays, ant build). Zalety: możliwość osobnego dewelopowania i wersjonowania modułów przez rożne zespoły programistów ułatwione tworzenie wariantów aplikacji dla różnych celów i środowisk znaczna redukcja rozmiaru projektów w IDE Wady: uciążliwa dodatkowa faza łączenia modułów brak możliwości dewelopowania in-place nadal problemy z jar-hell brak mechanizmów autokonfiguracji JVM JEE Server 1 2 3 4 5 7 6
45. JavaEE + OSGi Przegląd technik 2. Dynamiczna k ompozycja aplikacji webowej z modułów (fragmentów) w trakcie inicjalizacji (tylko JEE6, Servlet 3.0). Zalety: rozwiązanie standardowe wsparcie ze strony IDE częściowa autokonfiguracja aplikacji wydajna komunikacja wewnątrz pojedynczej JVM spójny interfejs użytkownika Wady: autokonfiguracja tylko dla standardowych zasobów brak separacji modułów nadal jar-hell wymagany serwer certyfikowany dla JEE6 brak dewelopowania w trybie in-place JVM JEE Server 1 2 3 4 5 7 6
46. JavaEE + OSGi Przegląd technik 3. M oduły jako odrębne aplikacje webowe na wspólnym serwerze. Integracja przez bazę danych, rmi/corba lub http/soap. Zalety: wysoka samodzielność funkcjonalna modułów, wysoka wydajność komunikacji wewnątrz pojedynczej JVM, likwidacja jar-hell dewelopowanie in-place Wady: utrudnione testowanie całkowita separacja przestrzeni klas, zasobów i konfiguracji duża duplikacja kodu wspólnego (bibliotek) b. grube ziarno separacji problemy z utrzymaniem spójności stanu UI JVM JEE Server 1 2 3 4 5
47. JavaEE + OSGi Przegląd technik 4. M oduły jako odrębne aplikacje webowe rozproszone na wielu serwerach. Integracja przez bazę danych, rmi/corba lub http/soap. Zalety: wysoka samodzielność funkcjonalna modułów, dewelopowanie in-place duże możliwości tuningu architektonicznego i wydajnościowego Możliwość balansowania komunikacji i wykorzystania narzędzi typu ESB Wady: wysoki koszt komunikacji zdalnej skomplikowane testowanie całkowita izolacja klas i zasobów modułów duża duplikacja kodu wspólnego problemy z utrzymaniem spójności stanu UI JVM JEE Server 1 JVM JEE Server JVM JEE Server 1 JVM JEE Server JVM JEE Server 1 JVM JEE Server JVM JEE Server 1 JVM JEE Server JVM JEE Server 1 JVM JEE Server JVM JEE Server 1 JVM JEE Server JVM JEE Server 1 JVM JEE Server JVM JEE Server 1 JVM JEE Server JVM JEE Server 1 JVM JEE Server JVM JEE Server 1 JVM JEE Server
48. JavaEE + OSGi Przegląd technik 5. Aplikacja webowa ze zintegrowaną platformą OSGi, moduły aplikacyjne jako paczki osgi. Zalety: integracja/izolacja kodu/zasobów/usług wg potrzeb, dynamiczna konfiguracja, likwidacja jar-hell, dewelopowanie in-place, lazy-loading modułów Wady: problemy z działaniem platformy OSGi w środowisku serwera JavaEE, stroma krzywa uczenia OSGi, słaba standaryzacja dla takich rozwiązań w przemyśle IT Platforma OSGi JVM JEE Server 2 4 5 8 6 7 3
51. (wcześniej O pen S ervices G ateway I nitiative) Konsorcjum wielu firm rozwijające zbiór standardów, zwanych „Specyfikacjami OSGi” Pierwsze specyfikacje powstały w 1998 dla potrzeb oprogramowania „inteligentnych budynków”. Misja: Rozwój standardu uniwersalnego „middleware” silnie zorientowanego na wymianę usług przez dynamicznie zarządzane komponenty (SOA-in-VM) . JavaEE + OSGi Wprowadzenie w OSGi OSGi™ - The Dynamic Module System for Java™ http://www.osgi.org
52. JavaEE + OSGi Wprowadzenie w OSGi OSGi™ - The Dynamic Module System for Java™ Obszary zastosowań Systemy informatyczne dla przedsiębiorstw Telekomunikacja Urządzenia mobilne Inteligentne budynki Sprzęt AGD i RTV Certfikowane implementacje platformy OSGi: Specyfikacja Core R4 V4.2 : 1. Makewave Knopflerfish Pro 3 ( www.makewave.com ) 2. ProSyst Software mBedded Server 7 ( www.prosyst.com ) 3. Hitachi Solutions SuperJ Engine Framework V4 ( www.hitachisoft.jp ) 4. Apache Felix Framework 3.0.0 ( http://felix.apache.org ) Specyfikacja Core R4: 5. Eclipse Equinox 3.2 ( www.eclipse.org/equinox/ ) 6. Samsung OSGi R4 Solution ( www.samsung.com ) 7. KT OSGi Service Platform (KOSP) 1.0 ( http://www.kt.co.kr/ )
53. JavaEE + OSGi Wprowadzenie w OSGi Przykładowe aplikacje wykorzystujące OSGi Eclipse IDE NetBeans IDE GlassFish Server Oracle Weblogic Server IBM WebSphere JOnAS JBoss Webserver SpringSource dm Server IBM Tivoli Atlassian Confluence Apache Synapse Apache Tuscany Kluczowe cechy platformy OSGi - przeznaczona dla środowiska Java (różne profile) - wykorzystuje tylko standardowe mechanizmy JDK (1.4) - minimalistyczna specyfikacja i api (~30 klas i interfesjów) - elastyczna: moduły mogą się zarówno w pełni angażować w życie platformy lub też zupełnie nic o niej nie wiedzieć OSGi™ - The Dynamic Module System for Java™ COMPENDIUM Specification ENTERPRISE Specification CORE Specification
54. JavaEE + OSGi Wprowadzenie w OSGi Framework - platforma, zgodna ze specyfikacją OSGi Core, łączy moduły, zarządza modułami, udostępnia globalne repozytorium i api wymiany usług, egzekwuje reguły bezpieczeństwa. Bundle - elementarny moduł, paczka kodu i zasobów z dokumentem konfiguracyjnym opisującym zasady wymiany kodu z innymi modułami (MANIFEST.MF), posiada dostęp do API platformy, może wpływać na cykl życia i zachowanie innych modułów, podlega regułom bezpieczeństwa, wymienia usługi z innymi modułami za pośrednictwem API platformy lub dedykowanych mechanizmów (DS, Spring DM, iPOJO). Service - usługa, obiekt języka Java wymieniany między modułami poprzez globalne repozytorium na podstawie nazwy interfejsu/klasy i dodatkowych atrybutów, usługi rozgłaszane są i dostarczane w sposób dynamiczny. META-INF/MANIFEST.MF - plik modułu zawierający istotne nagłówki konfiguracyjne odczytywane przez platformę oraz dostępne do wiadomości innych modułów. Wiring - proces przyswajania modułu do platformy polegający na analizie dostępności wymaganych i oferowanych przez moduł zależności (pakietów kodu) BundleContext - podstawowy interfejs platformy OSGi przekazywany modułom w celu współpracy, umożliwia: pozyskiwanie danych o modułach i usługach, pobieranie usług, zarządzanie platformą i modułami, dostęp do kodu i zasobów innych modułów w ramach reguł bezpieczeństwa. Tracker - obserwator modułów (BundleTracker) lub usług (ServiceTracker), przydatne klasy API platformy ułatwiające współpracę modułów z platformą, umożliwiają łatwą implementację zaawansowanych mechanizmów integracyjnych. Użyteczny słowniczek OSGi:
55. Architektura platformy OSGi JavaEE + OSGi Wprowadzenie w OSGi OSGi™ - The Dynamic Module System for Java™ Wsparcie dla różnych środowisk i profili JDK Moduły (bundles) współpracują ze sobą wymieniając kod i usługi Zarządzanie dynamicznym cyklem życia modułów (instalowanie, startowanie, zatrzymywanie, usuwanie) Globalne repozytorium i API do wymiany usług między modułami Zarządzanie wymianą kodu i zasobów między modułami Wymaga jedynie standardowego środowiska Java Zintegrowana architektura uprawnień i zabezpieczeń bazująca na Java Security
56. JavaEE + OSGi Wprowadzenie w OSGi OSGi™ - The Dynamic Module System for Java™ 3 główne funkcje platformy OSGi Nadzorowanie wymiany kodu Zarządzanie cyklem życia modułów Repozytorium usług
57. JavaEE + OSGi Wprowadzenie w OSGi 1. Wymiana kodu przez moduły Każdy moduł posiada własną wewnętrzną ścieżkę klas , na której mogą znajdować się zarówno katalogi, jak i archiwa JAR. Framework konstruuje dla każdego modułu osobny ClassLoader. Każdy moduł posiada własną przestrzeń klas , w której mogą znajdować się klasy z tego modułu oraz z innych modułów. Framework kieruje się deklaracjami zawartymi w nagłówkach Import-Package i Export-Package w pliku MANIFEST.MF Elementarną jednostką wymiany kodu jest pakiet. Importy i eksporty pakietów są wersjonowane. Framework dba o to, aby przestrzeń klas każdego z modułów była możliwie spójna, tj. zawierała tylko jedną wersję danej klasy. Przestrzenie różnych modułów mogą zawierać różne wersje tych samych klas, nie mogą jednak wtedy wymieniać obiektów tych klas, bezpośrednio lub pośrednio (przez inne klasy). private public private public
58. JavaEE + OSGi Wprowadzenie w OSGi 1. Wymiana kodu przez moduły, c.d.
59. JavaEE + OSGi Wprowadzenie w OSGi 2. Zarządzanie cyklem życia modułów Installed Resolved Active Stopping Starting
60. JavaEE + OSGi Wprowadzenie w OSGi 3. Repozytorium usług Bundles Framework OSGi Repozytorium usług API Declarative Services Spring DM (Dynamic Modules) Apache iPOJO
61. JavaEE + OSGi Wprowadzenie w OSGi Standardowe dodatkowe usługi platformy OSGi (opcjonalne) FRAMEWORK SERVICES Permission Admin Package Admin Start Level URL Handler SYSTEM SERVICES Log Service Configuration Admin Service Device Access Service User Admin Service IO Connector Service Preferences Service Component Runtime Deployment Admin Event Admin Application Admin PROTOCOL SERVICES Http Service UPnP Service DMT Admin MISCELLANEOUS SERVICES Wire Admin Service XML Parser Service Initial Provisioning Foreign Application Access
62. JavaEE + OSGi Wprowadzenie w OSGi Jak zbudować moduł OSGi? - paczka modułu OSGi jest standardowo archiwum JAR - różne platformy dopuszczają również inne formy pakowania lub instalowanie bezpośrednio z katalogu plików - wystarczy dodać plik META-INF/MANIFEST.MF do archiwum JAR, jedyny wymagany przez platformę nagłówek to Bundle-SymbolicName , pozostałe są opcjonalne - ręczne deklarowanie nagłówków Import-Package i Export-Package jest polecane tylko w prostych przypadkach - dostępnych jest kilka dobrych narzędzi wspomagających generowanie nagłówków osgi na bazie analizy statycznej kodu i deklaracji zależności: aQute BND – biblioteka Petera Kriensa z pluginami do ANT-a i MAVEN-a ( maven-bundle-plugin ) SpringSource Bundlor - nagłówek Bundle-ClassPath deklaruje wewnętrzną scieżkę klas i zasobów paczki modułu, mogą się na niej znajdować zarówno katalogi jak i archiwa JAR zagnieżdżone w głównym archiwum
63. JavaEE + OSGi Wprowadzenie w OSGi Jak użyć platformy OSGi w swoim projecie? Każda z implementacji platformy OSGi posiada własny sposób użycia oraz własny model dostarczania modułów Większość implementacji (w tym equinox i felix) dopuszcza zarówno uruchomienie samodzielne (standalone) jak i zagnieżdżenie w innej aplikacji (embeded) Implementacje różnią się między sobą zakresem dostępnych usług dodatkowych (specyfikacja COMPANION lub ENTERPRISE) Uniwersalny charakter osgi umożliwia przenoszenie gotowych implementacji usług (dostępnych zazwyczaj jako osobne moduły) pomiędzy różnymi platformami Wybór implementacji platformy powinien być obojętny dla działania zainstalowanych na niej modułów (założenie) Popularnym modelem dostarczania modułów do uruchomionej platformy jest automatyczne zaczytywanie archiwów JAR z określonego katalogu API platformy OSGi umożliwia łatwe tworzenie własnych mechanizmów ładowania modułów
64. JavaEE + OSGi Wprowadzenie w OSGi 2 pożyteczne wzorce współdziałania modułów Wzorzec 1: Extender Jeśli chcemy uwolnić obce moduły od konieczności samodzielnej integracji z dowolnym udostępnianym przez nas mechanizmem (api), możemy je w tym wyręczyć stosując wzorzec Extender . Wzorzec Extender działa następująco: -obserwujemy z użyciem BundleTracker inne moduły -podczas instalacji lub startu obcego modułu sprawdzamy, czy nie posiada on informacji przeznaczonych dla naszego modułu (w formie nagłówka lub pliku konfiguracyjnego) -jeśli obcy moduł posiada odpowiednie informacje, to wykorzystujemy je dla uzupełnienia lub skonfigurowania naszego mechanizmu Cechy wzorca Extender : -uwolnienie obcych modułów od znajomości szczegółów interakcji z naszym mechanizmem poprzez api (SoC), dostęp do zasobów obcego modułu przed jego startem Przykłady: Spring DM, Declarative Services (DS)
65. JavaEE + OSGi Wprowadzenie w OSGi 2 pożyteczne wzorce współdziałania modułów Wzorzec 2 : Whiteboard Jeśli chcemy uwolnić obce moduły od konieczności samodzielnej integracji z dowolnym udostępnianym przez nas mechanizmem (poprzez api), możemy je w tym również wyręczyć stosując wzorzec Whiteboard . Wzorzec Whiteboard działa następująco: -obserwujemy z użyciem ServiceTracker usługi wystawiane przez inne moduły -jeśli zostanie wystawiona interesująca nas usługa, pobieramy ją i wykorzystujemy dla uzupełnienia lub skonfigurowania naszego mechanizmu Cechy wzorca Whiteboard : -uwolnienie obcych modułów od znajomości szczegółów interakcji z naszym mechanizmem poprzez api (SoC) -dynamiczna reakcja na usługi wystawiane lub wycofywane przez obce moduły Przykład: Http Service
66. JavaEE + OSGi Wprowadzenie w OSGi Konkluzja: Dlaczego OSGi? - możliwość uzyskania dowolnej pożądanej separacji i/lub współdziałania modułów - czytelna, deklaratywna konfiguracja właściwości i zależności modułów - silne zorientowanie na współpracę poprzez wymianę usług (SOA-in-VM) - pełna obsługa cyklu życia modułów - otwarta i stabilna specyfikacja zarządzana przez dedykowane konsorcjum - minimalne api - małe wymagania środowiskowe (tylko JDK) - dojrzałe i sprawdzone implementacje dostępne dla różnych profili i zastosowań
67. JavaEE + OSGi Współpraca JavaEE z OSGi Razem czy osobno?
68. JavaEE + OSGi Współpraca JavaEE z OSGi JavaEE i OSGi różnią się znacznie proponowanymi rozwiązaniami : Java EE OSGi Elementarny instalowany element aplikacja(ear,war) moduł (bundle) Wymiana kodu i usług między modułami nie tak Komunikacja z platformą (serwerem) jednostronna dwustronna Preferowany cykl życia statyczny dynamiczny Zestaw usług serwera / platformy zamknięty otwarty Układ zasobów aplikacji / modułu sztywny dowolny
69. JavaEE + OSGi Współpraca JavaEE z OSGi Java EE OSGi Zaawansowana modularyzacja kodu - + Repozytorium usług lokalnych - + Obsługa zdalnych wywołań usług (WS) + - Komunikacja poprzez zdarzenia - + Przesyłanie komunikatów (JMS) + - Współpraca z bazami danych (JPA) + - Zarządzaniem kontekstem aplikacji (DI) + + Zdalne zarządzanie stanem aplikacji + + Monitorowanie stanu komponentów (JMX) + - Auto-konfiguracja modułów i usług - + Obsługa protokołów sieciowych (http,rmi) + +/- JavaEE i OSGi uzupełniają się jednak dobrze we wielu obszarach:
70. JavaEE + OSGi Współpraca JavaEE z OSGi OSGi w świecie aplikacji klasy „Enterprise” - najmłodsza ze specyfikacji osgi (Marzec 2010) - otwarcie na technologie wypracowane i używane od dawna w JavaEE - dobry przykład: zaawansowana implementacja usługi zarządzania kontekstami aplikacji w modułach: Spring DM - powstają powoli pierwsze implementacje platform osgi dedykowanych dla systemów enterprise (Apache Aries, Eclipse Virgo) Wsparcie dla wszystkich komponentów webowych (servlet, filter, listener, ...) Blueprint Container (DI) JDBC, JPA, JTA jako usługi OSGi Integracja z JNDI Instalowanie WAR jako modułu
71. JavaEE + OSGi Współpraca JavaEE z OSGi 2 drogi integracji JavaEE z OSGi JVM JEE Server Platforma OSGi 1 2 4 5 8 6 7 3 Platforma OSGi wewnętrz aplikacji JEE Platforma OSGi JVM 1 2 4 5 8 6 7 3 Komponenty JEE Server Serwer JEE jako usługa wewnątrz OSGi
72. JavaEE + OSGi Współpraca JavaEE z OSGi Platforma OSGi wewnętrz aplikacji JEE 2 drogi integracji JavaEE z OSGi Serwer JEE jako usługa wewnątrz OSGi Zalety: Wykorzystanie potencjału i inwestycji w istniejące instalacje serwerów JEE wysoka jakość usług Java EE Wady: dualna architektura rozproszone zarządzanie i konfigurowanie duże problemy z pełną integracją i współpracą platformy osgi z serwerem Zalety: homogeniczna architektura pełne wykorzystanie potencjału OSGi otwarty katalog usług serwera Wady: rozwiązanie niestandardowe brak sprawdzonych implementacji
106. Tiles-Config lista plików konfiguracji tiles lub lokalizacja META-INF/tiles
107.
108. W eb-osgi ‘moduły struts’ tworzą strukturę hierarchiczną, moduły niższe mogą bez dodatkowych atrybutów korzystać z elementów zadeklarowanych u rodziców
109. Pozycja modułu w hierarchi ustalana jest poprzez separację elementów ścieżki modułu. Np. ścieżka „/a/b/c” oznacza hierarchię „/”,”/a”,”/a/b”,”/a/b/c” Organizacja warstwy prezentacji, obsługa żądań HTTP i stron JSP
110.
111. Konteksty podnoszą się automatycznie przy starcie paczki z lokalizacji zadeklarowanych nagłówkiem ‘ Spring-Context ’ w pliku MANIFEST.MF lub z lokalizacji domyślnej META-INF/spring
124. Informacja o paczce zawiera element maven z danymi artefaktu mavenowego budowanego z projektu naszej paczki biznesowej
125. Po edycji listy paczek projekt kontenera wymaga zbudowania lokalnie mavenem (mvn package)
126.
127. Dla poprawnego działania paczki inplace wymagane jest również wygenerowanie rozpakowanej paczki poleceniem mvn package
128. Jest to konieczne po zmianach mających wpływ na postać pliku MANIFEST.MF oraz po modyfikacji zależności projektu w pom.xml
129. Deklaracja paczki inplace polega na dopisaniu jej do pliku local-dev-bundles.xml z takim samym id jak wpisaliśmy ją do pliku application-bundles.xml Dewelopowanie paczek w trybie in-place