SlideShare uma empresa Scribd logo
1 de 55
Baixar para ler offline
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 JavaEE + OSGi 6. Prezentacja platformy webowej osgi
JavaEE + OSGi Case Study
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)
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”?
JavaEE + OSGi Idea modularyzacji
JavaEE + OSGi Moduł ,[object Object]
powtarzalny wymiar,
bazowy element całości Modularyzacja ,[object Object]
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 1999. Modularyzacja ? ?
JavaEE + OSGi ,[object Object]
W informatyce modularyzacja jest raczej luźno zdefiniowanym pojęciem.
Określa się nim różne techniki programistyczne mające służyć: ,[object Object]
reużywalności kodu
generalizacji rozwiązań
izolacji szczegółów implementacji
kreowaniu interfejsów i komponentów Modularyzacja
Przykładowe obszary wykorzystania modularyzacji: ,[object Object]
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 JavaEE + OSGi Modularyzacja
Programując, dzielimy kod na użyteczne moduły: ,[object Object]
klasa / skrypt
pakiet
biblioteka
aplikacja / usługa JavaEE + OSGi Modularyzacja
Jakie są pożądane cechy dobrego modułu? ,[object Object]
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 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 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.
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
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
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
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
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
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
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
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 „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
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/ )
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
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:
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

Mais conteúdo relacionado

Semelhante a JavaEE + OSGi

Jak oszczędzać czas zespołu w środowisku mikroserwisów, czyli efektywny flow ...
Jak oszczędzać czas zespołu w środowisku mikroserwisów, czyli efektywny flow ...Jak oszczędzać czas zespołu w środowisku mikroserwisów, czyli efektywny flow ...
Jak oszczędzać czas zespołu w środowisku mikroserwisów, czyli efektywny flow ...Mateusz Paprocki, PMP
 
Produkcja aplikacji internetowych
Produkcja aplikacji internetowychProdukcja aplikacji internetowych
Produkcja aplikacji internetowychTomasz Borowski
 
Współdzielenie kodu aplikacji Windows Phone i Windows 8
Współdzielenie kodu aplikacji Windows Phone i Windows 8Współdzielenie kodu aplikacji Windows Phone i Windows 8
Współdzielenie kodu aplikacji Windows Phone i Windows 8Bartlomiej Zass
 
PHP i Microsoft - kto się lubi, ten się czubi
PHP i Microsoft - kto się lubi, ten się czubiPHP i Microsoft - kto się lubi, ten się czubi
PHP i Microsoft - kto się lubi, ten się czubiPHPCon Poland
 
Jak nadążyć za światem front-endu - WordPress Training Day
Jak nadążyć za światem front-endu - WordPress Training DayJak nadążyć za światem front-endu - WordPress Training Day
Jak nadążyć za światem front-endu - WordPress Training DayTomasz Dziuda
 
Łebski Development czyli kiedy i dlaczego tworzyć oprogramowanie pod klucz i ...
Łebski Development czyli kiedy i dlaczego tworzyć oprogramowanie pod klucz i ...Łebski Development czyli kiedy i dlaczego tworzyć oprogramowanie pod klucz i ...
Łebski Development czyli kiedy i dlaczego tworzyć oprogramowanie pod klucz i ...Wojciech Sznapka
 
Testowanie rozwiązań serverless z LocalStack
Testowanie rozwiązań serverless z LocalStackTestowanie rozwiązań serverless z LocalStack
Testowanie rozwiązań serverless z LocalStackThe Software House
 
Wprowadzenie do Kubernetesa. K8S jako nowy Linux.
Wprowadzenie do Kubernetesa. K8S jako nowy Linux.Wprowadzenie do Kubernetesa. K8S jako nowy Linux.
Wprowadzenie do Kubernetesa. K8S jako nowy Linux.Wojciech Barczyński
 
CI oraz CD w złożonym projekcie o małym budżecie
CI oraz CD w złożonym projekcie o małym budżecieCI oraz CD w złożonym projekcie o małym budżecie
CI oraz CD w złożonym projekcie o małym budżecieGrzegorz Godlewski
 
Tomasz Kopacz MTS 2012 Azure - Co i kiedy użyć (IaaS vs paas vshybrid cloud v...
Tomasz Kopacz MTS 2012 Azure - Co i kiedy użyć (IaaS vs paas vshybrid cloud v...Tomasz Kopacz MTS 2012 Azure - Co i kiedy użyć (IaaS vs paas vshybrid cloud v...
Tomasz Kopacz MTS 2012 Azure - Co i kiedy użyć (IaaS vs paas vshybrid cloud v...Tomasz Kopacz
 
Tech cafe Microservices
Tech cafe MicroservicesTech cafe Microservices
Tech cafe MicroservicesKonrad Król
 

Semelhante a JavaEE + OSGi (20)

Jak oszczędzać czas zespołu w środowisku mikroserwisów, czyli efektywny flow ...
Jak oszczędzać czas zespołu w środowisku mikroserwisów, czyli efektywny flow ...Jak oszczędzać czas zespołu w środowisku mikroserwisów, czyli efektywny flow ...
Jak oszczędzać czas zespołu w środowisku mikroserwisów, czyli efektywny flow ...
 
Produkcja aplikacji internetowych
Produkcja aplikacji internetowychProdukcja aplikacji internetowych
Produkcja aplikacji internetowych
 
Budowanie sieci Grid
Budowanie sieci GridBudowanie sieci Grid
Budowanie sieci Grid
 
Środowisko PWA
Środowisko PWAŚrodowisko PWA
Środowisko PWA
 
JavaScript, Moduły
JavaScript, ModułyJavaScript, Moduły
JavaScript, Moduły
 
JavaServer Faces. Wydanie II
JavaServer Faces. Wydanie IIJavaServer Faces. Wydanie II
JavaServer Faces. Wydanie II
 
Ext js
Ext jsExt js
Ext js
 
university day 1
university day 1university day 1
university day 1
 
Współdzielenie kodu aplikacji Windows Phone i Windows 8
Współdzielenie kodu aplikacji Windows Phone i Windows 8Współdzielenie kodu aplikacji Windows Phone i Windows 8
Współdzielenie kodu aplikacji Windows Phone i Windows 8
 
Php i Microsoft
Php i MicrosoftPhp i Microsoft
Php i Microsoft
 
PHP i Microsoft - kto się lubi, ten się czubi
PHP i Microsoft - kto się lubi, ten się czubiPHP i Microsoft - kto się lubi, ten się czubi
PHP i Microsoft - kto się lubi, ten się czubi
 
PHP i microsoft
PHP i microsoftPHP i microsoft
PHP i microsoft
 
Jak nadążyć za światem front-endu - WordPress Training Day
Jak nadążyć za światem front-endu - WordPress Training DayJak nadążyć za światem front-endu - WordPress Training Day
Jak nadążyć za światem front-endu - WordPress Training Day
 
Łebski Development czyli kiedy i dlaczego tworzyć oprogramowanie pod klucz i ...
Łebski Development czyli kiedy i dlaczego tworzyć oprogramowanie pod klucz i ...Łebski Development czyli kiedy i dlaczego tworzyć oprogramowanie pod klucz i ...
Łebski Development czyli kiedy i dlaczego tworzyć oprogramowanie pod klucz i ...
 
Testowanie rozwiązań serverless z LocalStack
Testowanie rozwiązań serverless z LocalStackTestowanie rozwiązań serverless z LocalStack
Testowanie rozwiązań serverless z LocalStack
 
Wprowadzenie do Kubernetesa. K8S jako nowy Linux.
Wprowadzenie do Kubernetesa. K8S jako nowy Linux.Wprowadzenie do Kubernetesa. K8S jako nowy Linux.
Wprowadzenie do Kubernetesa. K8S jako nowy Linux.
 
CI oraz CD w złożonym projekcie o małym budżecie
CI oraz CD w złożonym projekcie o małym budżecieCI oraz CD w złożonym projekcie o małym budżecie
CI oraz CD w złożonym projekcie o małym budżecie
 
Projektowanie i programowanie aplikacji nowej generacji
Projektowanie i programowanie aplikacji nowej generacjiProjektowanie i programowanie aplikacji nowej generacji
Projektowanie i programowanie aplikacji nowej generacji
 
Tomasz Kopacz MTS 2012 Azure - Co i kiedy użyć (IaaS vs paas vshybrid cloud v...
Tomasz Kopacz MTS 2012 Azure - Co i kiedy użyć (IaaS vs paas vshybrid cloud v...Tomasz Kopacz MTS 2012 Azure - Co i kiedy użyć (IaaS vs paas vshybrid cloud v...
Tomasz Kopacz MTS 2012 Azure - Co i kiedy użyć (IaaS vs paas vshybrid cloud v...
 
Tech cafe Microservices
Tech cafe MicroservicesTech cafe Microservices
Tech cafe Microservices
 

JavaEE + OSGi

  • 1. JavaEE + OSGi wielomodułowe aplikacje webowe [email_address]
  • 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. JavaEE + OSGi Case Study
  • 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”?
  • 6. JavaEE + OSGi Idea modularyzacji
  • 7.
  • 9.
  • 10. sposób konstruowania umożliwiający łatwe zestawianie większych jednostek ze standaryzowanych modułów 1
  • 11. 1. “Słownik Encyklopedyczny - Informatyka” Wydawnictwa Europa. Autor - Zdzisław Płoski. ISBN 83-87977-16-0. Rok wydania 1999. Modularyzacja ? ?
  • 12.
  • 13. W informatyce modularyzacja jest raczej luźno zdefiniowanym pojęciem.
  • 14.
  • 18. kreowaniu interfejsów i komponentów Modularyzacja
  • 19.
  • 23. meble kuchenne, biurowe i magazynowe,
  • 24. systemy budowlane i instalacyjne,
  • 28. software JavaEE + OSGi Modularyzacja
  • 29.
  • 33. aplikacja / usługa JavaEE + OSGi Modularyzacja
  • 34.
  • 35. jawne i jak najmniejsze zależności od innych modułów
  • 37. zdolność do współpracy z innymi modułami
  • 38. standardowe punkty i metody łączenia (interfejsy)
  • 40. autokonfiguracja JavaEE + OSGi Modularyzacja
  • 41. JavaEE + OSGi Modularyzacja w JavaEE Przegląd rozwiązań modularyzacji aplikacji webowej
  • 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. 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. 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
  • 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. JavaEE + OSGi Wprowadzenie w OSGi
  • 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
  • 73. JavaEE + OSGi Prezentacja platformy webowej osgi
  • 74.
  • 77. Typy i zadania paczek
  • 83. Warstwa bazodanowa i transakcje
  • 85. JavaEE + OSGi Platforma webowa osgi
  • 86.
  • 87. kod startowy platformy eb-osgi (osgi-launcher)
  • 88. konfigurację platformy eb-osgi (felix.properties, launcher.properties)
  • 89.
  • 90.
  • 91. osgi-deployment-bundle instalacja i start paczek na podstawie konfiguracji z plików *-bundles.xml
  • 92. osgi-http-proxy-bundle integracja z serwerem http, zarządzanie kontekstami i sesjami
  • 93. osgi-web-components-bundle rejestracja zasobów webowych (servlet, filter, file)
  • 95. osgi-struts-1-2-bundle obsługa Struts, Tiles i Walidator
  • 96.
  • 103.
  • 104. Web-Context-Root katalog bazowy zasobów wewnątrz paczki
  • 105.
  • 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
  • 112. Wszystkie zadeklarowane konfiguracje z jednej paczki tworzą jeden zagregowany kontekst aplikacji
  • 113.
  • 114.
  • 115.
  • 116. Koordynacja transakcji za pomocą platformowego Menadżera Transakcji
  • 117. Komunikacja paczek za pomocą usług osgi
  • 119. Użytkownicy paczki zależą tylko i wyłącznie od klas zawartych w api. Zasady współpracy paczek
  • 120.
  • 121. Automatyczne generowanie manifestu i paczkowanie za pomocą maven-bundle-plugin
  • 122. Archetyp mavenowy ułatwiający start z projektem Jak dewelopujemy paczki?
  • 123.
  • 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