JavaEE + OSGi wielomodułowe aplikacje webowe [email_address]
JavaEE + OSGi AGENDA 1. Case study 2. Idea modularyzacji 3. Modularyzacja w JavaEE 4. Wprowadzenie w OSGi 5. Współpraca Ja...
JavaEE + OSGi Case Study
JavaEE + OSGi Case study Jak szybko zbudować system wsparcia sprzedaży dla nowego banku? Nic trudnego, napiszemy aplikację...
JavaEE + OSGi Co z tym teraz zrobić ? Case study JVM JEE Server  Podzielmy  aplikację  na moduły ! Co to jednak znaczy  „ ...
JavaEE + OSGi Idea modularyzacji
JavaEE + OSGi Moduł <ul><ul><li>miara,
powtarzalny wymiar,
bazowy element całości </li></ul></ul>Modularyzacja <ul><ul><li>koncepcja budowania złożonych systemów przez dzielenie ich...
sposób konstruowania umożliwiający łatwe zestawianie większych jednostek ze standaryzowanych modułów 1
1. “Słownik Encyklopedyczny - Informatyka” Wydawnictwa Europa. Autor - Zdzisław Płoski. ISBN 83-87977-16-0. Rok wydania 19...
JavaEE + OSGi <ul><ul><li>Koncepcja modularyzacji rozwinęła się w połowie XIX wieku w manufakturach zbrojeniowych, kładąc ...
W informatyce modularyzacja jest raczej luźno zdefiniowanym pojęciem.
Określa się nim różne techniki programistyczne mające służyć: </li><ul><ul><ul><ul><ul><ul><ul><ul><li>separacji zagadnień...
reużywalności kodu
generalizacji rozwiązań
izolacji szczegółów implementacji
kreowaniu interfejsów i komponentów </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>Modularyzacja
Przykładowe obszary wykorzystania modularyzacji: <ul><ul><ul><ul><ul><ul><li>konstrukcja maszyn,
linie produkcyjne,
urządzenia sieciowe,
podzespoły elektroniczne,
meble kuchenne, biurowe i magazynowe,
systemy budowlane i instalacyjne,
opakowania i kontenery
kreatywne zabawki (lego),
projektowanie architektoniczne i przestrzenne,
software </li></ul></ul></ul></ul></ul></ul>JavaEE + OSGi Modularyzacja
Programując, dzielimy kod na użyteczne moduły: <ul><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>metoda / funkcja
klasa / skrypt
pakiet
biblioteka
aplikacja / usługa </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>JavaEE + OSGi Modularyzacja
Jakie są pożądane cechy dobrego modułu? <ul><ul><li>czytelnie określona funkcja/zagadnienie/odpowiedzialność
jawne i jak najmniejsze zależności od innych modułów
samodzielność/enkapsulacja/izolacja implementacji
zdolność do współpracy z innymi modułami
standardowe punkty i metody łączenia (interfejsy)
wymienność
autokonfiguracja </li></ul></ul>JavaEE + OSGi Modularyzacja
JavaEE + OSGi Modularyzacja w JavaEE Przegląd rozwiązań modularyzacji aplikacji webowej
JavaEE + OSGi Przegląd technik Rozważmy 5 propozycji modularyzacji: 1. Statyczna kompozycja standardowej aplikacji webowej...
JavaEE + OSGi Przegląd technik Kryteria oceny rozwiązań 1. modularność  (stopień separacji / współpracy) 2. skalowalność  ...
JavaEE + OSGi Przegląd technik 1. Statyczna kompozycja standardowej aplikacji webowej z modułów na etapie budowania (maven...
JavaEE + OSGi Przegląd technik 2. Dynamiczna k ompozycja aplikacji webowej z modułów (fragmentów) w trakcie inicjalizacji ...
JavaEE + OSGi Przegląd technik 3. M oduły jako odrębne aplikacje webowe na wspólnym serwerze. Integracja przez bazę danych...
JavaEE + OSGi Przegląd technik 4. M oduły jako odrębne aplikacje webowe rozproszone na wielu serwerach. Integracja przez b...
JavaEE + OSGi Przegląd technik 5.  Aplikacja webowa ze zintegrowaną platformą OSGi, moduły aplikacyjne jako paczki osgi. Z...
Wariant modularyzacji 1 2 3 4 5 6 7 8 9 10 11 0 ( monolit ) - + - + + + + + - + - 2 ( kompozycja statyczna ) + + +/- + + -...
JavaEE + OSGi Wprowadzenie w OSGi
(wcześniej  O pen  S ervices  G ateway  I nitiative) Konsorcjum wielu firm rozwijające zbiór standardów, zwanych „Specyfik...
JavaEE + OSGi Wprowadzenie w OSGi OSGi™ -   The Dynamic Module System for Java™ Obszary zastosowań Systemy informatyczne d...
JavaEE + OSGi Wprowadzenie w OSGi Przykładowe aplikacje wykorzystujące OSGi Eclipse IDE NetBeans IDE GlassFish Server Orac...
JavaEE + OSGi Wprowadzenie w OSGi Framework  -  platforma, zgodna ze specyfikacją OSGi Core, łączy moduły, zarządza moduła...
Architektura platformy OSGi JavaEE + OSGi Wprowadzenie w OSGi OSGi™ -   The Dynamic Module System for Java™ Wsparcie dla r...
Upcoming SlideShare
Loading in...5
×

JavaEE + OSGi

1,266

Published on

How to get JavaEE and OSGi working together? How to design modular web application using OSGi?

Published in: Technology
1 Comment
1 Like
Statistics
Notes
  • Thanks, Really great presentation!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
1,266
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide

JavaEE + OSGi

  1. 1. JavaEE + OSGi wielomodułowe aplikacje webowe [email_address]
  2. 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
  3. 3. JavaEE + OSGi Case Study
  4. 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. 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”?
  6. 6. JavaEE + OSGi Idea modularyzacji
  7. 7. JavaEE + OSGi Moduł <ul><ul><li>miara,
  8. 8. powtarzalny wymiar,
  9. 9. bazowy element całości </li></ul></ul>Modularyzacja <ul><ul><li>koncepcja budowania złożonych systemów przez dzielenie ich na wewnętrznie spójne moduły, między którymi wymiana informacji jest znacznie rzadsza niż wewnątrz nich 1
  10. 10. sposób konstruowania umożliwiający łatwe zestawianie większych jednostek ze standaryzowanych modułów 1
  11. 11. 1. “Słownik Encyklopedyczny - Informatyka” Wydawnictwa Europa. Autor - Zdzisław Płoski. ISBN 83-87977-16-0. Rok wydania 1999. </li></ul></ul>Modularyzacja ? ?
  12. 12. JavaEE + OSGi <ul><ul><li>Koncepcja modularyzacji rozwinęła się w połowie XIX wieku w manufakturach zbrojeniowych, kładąc podwaliny rozwojowi masowej produkcji przemysłowej opartej na zunifikowanych i wymiennych podzespołach, produkowanych i zespalanych oddzielnie.
  13. 13. W informatyce modularyzacja jest raczej luźno zdefiniowanym pojęciem.
  14. 14. Określa się nim różne techniki programistyczne mające służyć: </li><ul><ul><ul><ul><ul><ul><ul><ul><li>separacji zagadnień (SoC)
  15. 15. reużywalności kodu
  16. 16. generalizacji rozwiązań
  17. 17. izolacji szczegółów implementacji
  18. 18. kreowaniu interfejsów i komponentów </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>Modularyzacja
  19. 19. Przykładowe obszary wykorzystania modularyzacji: <ul><ul><ul><ul><ul><ul><li>konstrukcja maszyn,
  20. 20. linie produkcyjne,
  21. 21. urządzenia sieciowe,
  22. 22. podzespoły elektroniczne,
  23. 23. meble kuchenne, biurowe i magazynowe,
  24. 24. systemy budowlane i instalacyjne,
  25. 25. opakowania i kontenery
  26. 26. kreatywne zabawki (lego),
  27. 27. projektowanie architektoniczne i przestrzenne,
  28. 28. software </li></ul></ul></ul></ul></ul></ul>JavaEE + OSGi Modularyzacja
  29. 29. Programując, dzielimy kod na użyteczne moduły: <ul><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>metoda / funkcja
  30. 30. klasa / skrypt
  31. 31. pakiet
  32. 32. biblioteka
  33. 33. aplikacja / usługa </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>JavaEE + OSGi Modularyzacja
  34. 34. Jakie są pożądane cechy dobrego modułu? <ul><ul><li>czytelnie określona funkcja/zagadnienie/odpowiedzialność
  35. 35. jawne i jak najmniejsze zależności od innych modułów
  36. 36. samodzielność/enkapsulacja/izolacja implementacji
  37. 37. zdolność do współpracy z innymi modułami
  38. 38. standardowe punkty i metody łączenia (interfejsy)
  39. 39. wymienność
  40. 40. autokonfiguracja </li></ul></ul>JavaEE + OSGi Modularyzacja
  41. 41. JavaEE + OSGi Modularyzacja w JavaEE Przegląd rozwiązań modularyzacji aplikacji webowej
  42. 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.
  43. 43. JavaEE + OSGi Przegląd technik Kryteria oceny rozwiązań 1. modularność (stopień separacji / współpracy) 2. skalowalność (dewelopowanie wielozespołowe, wersjonowanie) 3. czytelność rozwiązania, standaryzacja 4. brak duplikacji kodu / zasobów / konfiguracji 5. spójność interfejsu użytkownika 6. klarowne zarządzanie sesją użytkownika 7. likwidacja problemów z jar-hell 8. wydajna komunikacja modułów 9. łatwość wariantowania aplikacji 10. szybkie dewelopowanie in-place 11. wygodne środowisko testowe
  44. 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. 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. 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. 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. 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
  49. 49. Wariant modularyzacji 1 2 3 4 5 6 7 8 9 10 11 0 ( monolit ) - + - + + + + + - + - 2 ( kompozycja statyczna ) + + +/- + + - + + - + + 2 ( kompozycja dynamiczna ) + +/- +/- + + - + + - + + 3 ( aplikacje na wspólnym serwerze ) + +/- +/- - - +/- - +/- +/- + + 4 ( aplikacje rozproszone na wielu serwerach ) + - + - - +/- - - +/- - + 5 ( Platforma OSGi ) + +/- + + + + + + + + + JavaEE + OSGi Przegląd technik modularność czytelność skalowalność brak duplikacji spójność stanu UI in-place łatwe testowanie wspólna sesja http likwidacja jar-hell wydajna komunik. wariantowanie
  50. 50. JavaEE + OSGi Wprowadzenie w OSGi
  51. 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. 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. 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. 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. 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. 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. 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. 58. JavaEE + OSGi Wprowadzenie w OSGi 1. Wymiana kodu przez moduły, c.d.
  59. 59. JavaEE + OSGi Wprowadzenie w OSGi 2. Zarządzanie cyklem życia modułów Installed Resolved Active Stopping Starting
  60. 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. 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. 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. 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. 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. 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. 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. 67. JavaEE + OSGi Współpraca JavaEE z OSGi Razem czy osobno?
  68. 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. 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. 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. 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. 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
  73. 73. JavaEE + OSGi Prezentacja platformy webowej osgi
  74. 74. JavaEE + OSGi Platforma webowa osgi <ul><li>Architektura – Big Picture
  75. 75. Kontener
  76. 76. Platforma eb-osgi
  77. 77. Typy i zadania paczek
  78. 78. Konfiguracja warstwy prezentacji
  79. 79. Menu deklaratywne
  80. 80. Autoryzacja dostępów
  81. 81. Konteksty springowe, wymiana usług
  82. 82. Komunikacja w ramach SOA
  83. 83. Warstwa bazodanowa i transakcje
  84. 84. Komunikacja między paczkami, API </li></ul>
  85. 85. JavaEE + OSGi Platforma webowa osgi
  86. 86. JavaEE + OSGi Platforma webowa osgi <ul><li>Kontener – samodzielna aplikacja webowa J2EE zawierająca: </li></ul><ul><ul><li>konfigurację J2EE (web.xml, weblogic.xml)
  87. 87. kod startowy platformy eb-osgi (osgi-launcher)
  88. 88. konfigurację platformy eb-osgi (felix.properties, launcher.properties)
  89. 89. listy paczek przeznaczonych do zainstalowania na platformie przy starcie (*-bundles.xml) </li></ul></ul><ul><ul><li>konfigurację statyczną aplikacji </li></ul></ul><ul><ul><li>konfigurację dla uruchomień standalone </li></ul></ul>
  90. 90. JavaEE + OSGi Platforma webowa osgi <ul><li>Platforma eb-osgi – zestaw bibliotek i modułów osgi tworzących uniwersalną bazę dla wielomodułowych aplikacji webowych: </li></ul><ul><ul><li>osgi-launcher start Apache Felix, integracja z kontenerem WAR, serwlet integracyjny
  91. 91. osgi-deployment-bundle instalacja i start paczek na podstawie konfiguracji z plików *-bundles.xml
  92. 92. osgi-http-proxy-bundle integracja z serwerem http, zarządzanie kontekstami i sesjami
  93. 93. osgi-web-components-bundle rejestracja zasobów webowych (servlet, filter, file)
  94. 94. osgi-jsp-bundle obsługa stron JSP
  95. 95. osgi-struts-1-2-bundle obsługa Struts, Tiles i Walidator </li></ul></ul>
  96. 96. JavaEE + OSGi Platforma webowa osgi <ul><li>Paczka – archiwum JAR zawierające skompilowany kod i inne zasoby, posiadające plik META-INF/MANIFEST.MF z nagłówkami wymaganymi przez osgi i z nagłówkami wymaganymi przez platformę webową. </li></ul><ul><ul><li>Paczki rdzeniowe platformy webowej osgi
  97. 97. Zewnętrzne paczki systemowe
  98. 98. Paczki biblioteczne
  99. 99. Paczki pomocnicze
  100. 100. Paczki klientów serwisów SOA
  101. 101. Paczki bazowe aplikacji
  102. 102. Paczki biznesowe aplikacji </li></ul></ul>
  103. 103. JavaEE + OSGi Platforma webowa osgi <ul><li>Paczka osgi-launcher-bundle rejestruje zasoby www zadeklarowane przez paczki biznesowe za pomocą nagłówków w pliku MANIFEST.MF : </li><ul><li>Web-Context-Path kontekst wewnętrzny zasobów paczki
  104. 104. Web-Context-Root katalog bazowy zasobów wewnątrz paczki
  105. 105. Web-Exclude-Patterns lista wzorców wykluczeń </li></ul><li>Paczka osgi-struts-1-2-bundle agreguje konfiguracje struts, tiles i walidator zadeklarowane przez paczki biznesowe za pomocą nagłówków w pliku MANIFEST.MF lub umieszczone w domyślnej lokalizacji: </li><ul><li>Struts-Config lista plików konfiguracji struts lub lokalizacja META-INF/struts
  106. 106. Tiles-Config lista plików konfiguracji tiles lub lokalizacja META-INF/tiles
  107. 107. Validator-Config lista plików konfiguracji lub lokalizacja META-INF/validator </li></ul><li>Elementy struts i tiles dodawane są do ‘modułu struts’ o ścieżce zadeklarowanej w ‘Web-Context-Path’
  108. 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. 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” </li></ul>Organizacja warstwy prezentacji, obsługa żądań HTTP i stron JSP
  110. 110. JavaEE + OSGi Platforma webowa osgi <ul><li>eb-osgi wykorzystuje Spring Dynamic Modules (Spring DM) do zarządzania kontekstami springowymi
  111. 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
  112. 112. Wszystkie zadeklarowane konfiguracje z jednej paczki tworzą jeden zagregowany kontekst aplikacji
  113. 113. Spring DM udostępnia możliwość: </li><ul><li>rejestracji z poziomu konfiguracji beanów springowych jako usług w repozytorium osgi ( <osgi-service …),
  114. 114. oraz pobierania z tegoż repozytorium usług w postaci beanów (<osgi-reference …). </li></ul><li>Za pomocą tej techniki wymieniamy beany pomiędzy kontekstami różnych paczek. </li></ul><ul>http:// static.springsource.org / osgi / docs /2.0.0.M1/ reference / html / </ul>Zarządzaniem kontekstem aplikacji
  115. 115. JavaEE + OSGi Platforma webowa osgi <ul><li>Każda paczka biznesowa pracuje z własnym mapowaniem i konfiguracją toplinka
  116. 116. Koordynacja transakcji za pomocą platformowego Menadżera Transakcji
  117. 117. Komunikacja paczek za pomocą usług osgi
  118. 118. Wydzielone paczki z API
  119. 119. Użytkownicy paczki zależą tylko i wyłącznie od klas zawartych w api. </li></ul>Zasady współpracy paczek
  120. 120. JavaEE + OSGi Platforma webowa osgi <ul><li>Projekt mavenowy typu ‘ bundle ’ w Eclipse
  121. 121. Automatyczne generowanie manifestu i paczkowanie za pomocą maven-bundle-plugin
  122. 122. Archetyp mavenowy ułatwiający start z projektem </li></ul>Jak dewelopujemy paczki?
  123. 123. JavaEE + OSGi Platforma webowa osgi Konfiguracja aplikacji, instalowanie modułów <ul><li>W projekcie kontenera edytujemy plik application-bundles.xml , dodajemy do niego informację o nowej paczce biznesowej, pamiętamy o unikalnym wartości atrybutu id
  124. 124. Informacja o paczce zawiera element maven z danymi artefaktu mavenowego budowanego z projektu naszej paczki biznesowej
  125. 125. Po edycji listy paczek projekt kontenera wymaga zbudowania lokalnie mavenem (mvn package) </li></ul>
  126. 126. JavaEE + OSGi Platforma webowa osgi Dewelopowanie paczek w trybie in-place <ul><li>Dewelopowanie in-place oznacza podłączenie katalogu, do którego Eclipse buduje projekt jako paczki do kontenera
  127. 127. Dla poprawnego działania paczki inplace wymagane jest również wygenerowanie rozpakowanej paczki poleceniem mvn package
  128. 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. 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 </li></ul>Dewelopowanie paczek w trybie in-place
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×