Uniwersytet Łódzki Wydział Matematyki i Informatyki, Katedra Analizy Nieliniowej Enterprise Java Beans wykład 7 i 8 Programowanie w Javie 2 mgr inż. Michał Misiak
Agenda Co to jest EJB Architektura EJB Komponenty Kontenery Typy Fasolek Role Wołanie metod EJB Deskryptor i rozmieszczanie
Co to jest EJB? EJB Enterprise JavaBeans EJB opisane w specyfikacji J2EE Jest to architektura komponentowa ułatwiające rozwój i rozmieszanie aplikacji biznesowych rozproszonych Aplikacje napisane z wykorzystaniem EJB są skalowalne, rozproszone, wspierają transakcje oraz zapewniają bezpieczeństwo w środowisku wielu użytkowników Koncepcja: wirte once, run anywhere
Podstawowe zasady projektowania aplikacji używających EJB Aplikacje są luźno powiązane Zachowanie specyfikowane jest po przez interfejsy Aplikacje nie zarządzają zasobami Kontener dostarcza pomocnicze mechanizmy dla programisty Aplikacje są wielowarstwowe Warstwa Session: API do aplikacji Warstwa Entity: API do danych
EJB loosely coupled Z założeń specyfikacji: możliwość integracji EJB od rożnych dostawców Nie trzeba ingerować w kod EJB. Dostęp do usług i innych komponentów za pomocą nazw. Zalety swobodnego powiązania: system łatwiej utrzymywać, testować i rozbudowywać (ponowne wykorzystanie komponentów) Dwie zasadnicze role: Application assembler: osoba składająca aplikację z komponentów. Zadaniem jest rozwiązanie problemu nazw, prawidłowej propagacji transakcji, etc Brak konieczności ingerencji w kod aplikacji, jedynie XML Component provider
Specyfikacja zachowania EJB Zachowanie widoczne dla klienta EJB określone za pomocą interfejsu Interfejs to: zestaw metod, które może wykonać klient Zamknięcie implementacji z punktu widzenia klienta Wsparcie dla przenośności i skalowalności oraz możliwości integracji z innymi aplikacjami niż Java (specyfikacja za pomocą IDL CORBA)
EJB i źródła danych EJB nie zajmuje się zarządzaniem źródłem danych. Realizowane to jest przez warstwę pośredniczącą. Dostęp do danych zapewnia kontener. Kontener może implementować różnego rodzaju mechanizmy w celu optymalizacji (pooling)
Mechanizmy kontenera Kontener oferuje szereg mechanizmów wspierających programistę m.in: Bezpieczeństwo Transakcje Zarządzanie połączeniami (connecting pool) Zarządzanie cyklem życia komponentu Wielowątkowość Persistence Programista opisuje swojego wymagania w sposób deklaratywny nie w kodzie
Umieszczenie EJB w architekturze J2EE
EJB w architekturze J2EE web-tier EJB Client Standalone EJB Client Źródło: http://java.sun.com
Dlaczego EJB? Zalety modelu komponentowego po stronie serwera (ponowne wykorzystanie, dostępność komponentów innych dostawców, dostępność narzędzie, etc ) Oddzielenie logiki biznesowej od systemu (kontener) Dostarczenie gotowych mechanizmów: persistence, transakcyjność, zarządzanie zasobami Środowisko dla przenośnych komponentów (standard przemysłowy oraz zastosowanie języka Java) Konfiguracja w momencie rozmieszczania aplikacji za pomocą deskryptora bez ingerencji w kodzie
EJB Wykorzystywany wyłączenie do implementacji logiki biznesowej Brak konieczności troszczenia się o zagadnienia niskopoziomowe Możliwość wielokrotnego wykorzystania na różnych platformach Implementuje interfejsy, za pomocą których kontener może zarządzać EJB Konieczność specyfikacji dwóch rodzajów interfejsów: Lokalny Zdalny
Kiedy EJB, kiedy wyłącznie strona Warstwa EJB pozwala wykorzystać funkcjonalność oferowaną przez kontener: zarządzanie zasobami, zarządzanie cyklem życia, sterowanie wielowątkowością, wielowątkowość presistence, transakcje i bezpieczeństwo komunikacja asynchroniczna wiadomości Skalowalność, niezawodność Problemy, które mogą pojawić się w przypadku rozbudowy aplikacji niekorzystającej z EJB Jeśli korzystamy włącznie z prostych operacji na tabelach, wówczas warto się zastanowić na aplikacją napisaną bez EJB Jeśli wiemy, że komponenty biznesowe będą nam potrzebne wówczas warto wykorzystać EJB
Źródło: http://www.javaworld.com/javaworld/jw-12-2001/images/jw-1207-yesnoejbf2.jpg
Pytania contra EJB Zbyt ciężka technologia Złożony model programistyczny Problematyczne testowanie aplikacji Przydatne wyłącznie przy dużych rozproszonych architekturach EJB3.0 uwzględnia powyższe aspekty
Komponent EJB Baza danych lub komponent Architektura EJB EJB Home Klient EJB Object Kontener Serwer EJB
Tworzenie EJB Implementacja: Interfejsu lokalnego do zarządzania cyklem życia aplikacji, tworzenie i lokalizacja EJB Interfejsu zdalnego metody biznesowe dostępne dla innych komponentów Stworzenie EJB Kontener stworzy 2 obiekty: Lokalny Zdalny Klient komunikuje się za pomocą pośrednich obiektów, w celu przechwytywania wszelkich wywołań
Architektura kontraktów w EJB Kontrakty są określone w specyfikacji EJB Klient EJB oczekuje ściśle określonego zbioru zachowań od EJB Dwa rodzaje kontraktów: Client view contract: kontrakt pomiędzy klientem i kontnerem Component contract: kontrakt pomiędzy EJB i jego kontenerem
Client view Contract Klientem EJB może być dowolny obiekt, który woła metody EJB np.: Komponenty warstwy WEB: Serwlet i JSP Aplikacje stand alone Aplety Inny EJB lub inny kontener np. session bean odbiera żądania i przekazuje je do entity beans, który sięga po dane Klient WS Specyfikacja EJB 2.1 określa również sposób prezentacji WS
Client view contract (2) Budowa CVC Interfejs lokalny (home interface) zawiera zestaw metod do tworzenia i lokalizacji fasolki Interfejs zdalny (logic/remote interface) zawiera metody biznesowe Identyfikacja obiektu identyfikuje konkretną instancję fasolki Interfejs dla metadanych Handler
Kontrakt komponentu Określa co powinien kontener robić dla komponentu np. Umożliwia wołanie metod EJB przez klienta (kontener przechwytuje połączenie i przekazuje do konkretnego bean a) Zarządza cyklem życia EJB. Programista nie zajmuje się tworzeniem fasolki, zarządza pulą i zgodnie z potrzebami zasobów może zniszczyć instancję Interfejs lokalny i zdalny implementowane są przez obiekty zdalny i lokalny Zapewnienie trwałości dla CMP entity beans
Kontrakty EJB klient Kontrakt dla klienta Client view contract Instancja EJB Kontrakt Komponentu Kontener EJB Serwer EJB
Architektura EJB EJB jest to komponent programistyczny na którym mogą być wołane metody i który może wołać metody na innych obiektach Wołanie metod może być realizowane lokalnie lub zdalnie w sieci (podobieństwo do RMI, CORBA)
Podstawy EJB Zachowanie/metody widziane przez klienta są zdefiniowane w interfejsach EJB znajdują się i są wspierane przez kontener Kontener EJB tworzy wirtualne środowisko dla wykonywania pojedynczego wątku Kontener EJB zarządza transakcjami bazodanowymi Kontener EJB zarządza dostępem i bezpieczeństwem Zestandaryzowany sposób kreacji i lokalizacji EJB Możliwość tworzenia pul instancji w celu optymalizacji Kontener zarządza zasobami Zestandaryzowany sposób rozmieszczenia aplikacji
Zachowanie EJB widziane przez klienta Klient może wołać jedynie metody eksponowane w postaci interfejsów przez EJB Interfejs zdalny funkcje biznesowe wołane po zlokalizowanie EJB. Interfejs lokalny fabryka EJB. Usuwanie, tworzenie i lokalizowanie EJB. Obiekty które korzystają z interfejsów EJB są klientami względem EJB Interfejsy są jedynie specyfikacją metod. Nie ma mowy o ich implmentacji.
Izolowanie i środowisko kontenera Przechwytywanie wywołań przez kontener. Klient nie woła metod EJB bezpośrednio (nawet jeśli ten sam serwer lub JVM). Przechwytywanie wywołań pozwala na obsługę transakcji rozproszonych oraz tworzenie puli EJB Dostęp do kontenera i do EJB odbywa się przez obiekty pośredniczące (obiekty home & EJB). Kontener izoluje (enkapsuluje EJB) i zarządza bezpieczeństwem Generowanie obiektów pośredniczących na żądanie, automatycznie
Kontener zapewnia wirtualne środowisko jednowątkowe Programista nie musi troszczyć się o zarządzanie problemami wielowątkowości oraz samym programowaniem wielowątkowym Kontener zapewnia, że EJB nie będzie wołane wielokrotnie
Kontener zarządza transakcjami bazodanowymi Kontener obsługuje zarówno lokalne jak i zdalne transakcje Kontener wspiera deklaratywne transkacje
Kontener zarządza bezpieczeństwem i dostępem Kontener obsługuje reguły dostępu: Które metody są dostępne dla jakich ról Sterowanie dostępem jest w sposób deklaratywny zawarte w deskryptorze Dozwolone jest programistyczne zarządzanie dostępem Kontener dostarcza mechanizmy autentykacji programista EJB nie powinien tych mechanizmów implementować samodzielnie
Tworzenie i lokalizacja EJB Specyfikacja EJB precyzyjnie określa w jaki sposób są tworzenie EJB i w jaki sposób usuwane Pobranie obiektu pośredniczącego (proxy) referencja na obiekt EJB Klient woła metody Create() lub find() w celu pobrania nowego obiektu Klient współpracuje z proxy nigdy bezpośrednio z EJB
Zarządzanie instancjami przez kontener w celu zwiększenia efektywności Kontener może umieszczać instancje obiekty w pulach Kontener zwiększa efektywność zarządzania instancjami W momencie, gdy klient pyta kontener o EJB wówczas kontener zwraca referencje na instancję EJB znajdującego się w puli. Cała operacja jest przeźroczysta dla klienta.
Kontener zarządza zewnętrznymi zasobami Przykłady zasobów którymi zarządza kontener: Bazy danych Systemy informacyjne Systemy wiadomości Zewnętrzne zasoby mogą być współdzielone z wykorzystaniem EJB Kontener zarządza połączeniami/dostępem do tych zasobów
Standaryzacja rozmieszczania EJB EJB specyfikuje standard według którego rozmieszczane są EJB Pakowanie EJB Postać deskryptora Standard pozwala na uruchamianie aplikacji na dowolnym serwerze zgodnym ze specyfikacją EJB
Kontener & Komponent Kontener obsługuje: Aspekty wielowątkowości dostępność w tym samym czasie dla wielu klientów Bezpieczeństwo konfiguracja funkcji bezpieczeństwa i dostępu w trakcie rozmieszania aplikacji Dostępność przechowywanie sesji w pamięci zewnętrznej Skalowalność Trwałość danych Transakcje Cykl życia Zarządzanie Komponent realizuje: Logikę biznesową
Funkcje kontenera EJB Generuje klasy dla interfejsów Wiąże nazwę z EJB za pomocą usługi JNDI. Klient wyszukuje obiekt po nazwie Tworzy zbiór obiektów do wykorzystania Zarządza pamięcią podręczną z EJB Zarządza zbiorem połączeń dla JDBC
Terminy wykorzystywane przy EJB Klasa EJB (bean class) klasa napisana w Javie reprezentująca fasolkę Instancja EJB konkretna fasolka obiekt Moduł EJB (EJB module) jar z ejb lub zbiór klas EJB Aplikacja EJB plik ear
Terminy wykorzystywane przy EJB Interfejs lokalny (home interface) interfejs javy zawierający metody do tworzenia, lokalizacji i niszczenia obiektu Lokalny obiekt EJB (EJB Home Object) implementuje interfejs lokalny. Obiekt nazywany fabryką Interfejs zdalny (logic interface) określa zachowanie EJB. Specyfikuje metody do logiki biznesowej Obiekt EJB (EJB Object) implementuje interfejs zdalny. Implementowany jest automatycznie przez kontener.
Typy EJB Session Beans EJB stanowe EJB bezstanowe Entity Beans Bean Managed Persistence Container Managed Persistence Message Driven Beans JMS JAXM
Session Beans Jest to obiekt tymczasowy, którego czas istnienia jest uwarunkowany czasem komunikacji z klientem Klient tworzy EJB, wykonuje metody i później usuwa EJB. W przypadku, gdy klient nie usunie EJB kontener wykona to w operacji cyklicznej Session Beans bezstanowe (stateless) wykorzystywane są przez wielu klientów Session Beans stanowe (statefull) tworzony dla konkretnego klienta i nie jest wykorzystywany przez żadnego innego Wykorzystanie: modelowanie procesu, zestawu zadań np. proces rezerwacji
Stanowe i bezstanowe Session Beans Bezstanowe Session Beans wykonuje żądanie i zwraca wynik bez zachowywania specyficznych dla klient informacji o stanie. Wykorzystywany w przypadku, gdy dany proces zamyka się w wywołaniu jednej metody Np.. Zestawienie katalogowe, pobranie informacji o walutach Stanowe Session Beans utrzymuje informacje o stanie dla konkretnego klienta
Entity Beans Udostępnia widok danych Jest nieśmiertelny niezależny od czasu poświęcanego na interakcję z klientem Żyje tak długo jak długo istnieją dane w bazie W większości przypadków synchronizowany z relacyjnymi bazami danych (stan przechowywany w bazie danych) Współdzielony przez wielu klientów Musi implementować interfejs: javax.ejb.entitybean
Entity Beans (scenariusz) Klient wyszukuje istniejący EJB Utworzenie wiąże się z dodaniem nowych danych do aplikacji - utworzeniem wiersza w tabeli Każdy Entity Beans posiada swój identyfikator, uzyskiwany poprzez przypisanie klucza do każdej instancji Przykłady EJB: EJB klient dane klienta współdzielone przez inne obiekty, musi przetrwać awarię serwera, etc
Typy Entity Beans CMP (Container Managed Persistence) Zarządzanie trwałością przez kontener Wymaganie dot. trwałości specyfikowane są w deskryptorze Programista nie musi troszczyć się o mechanizmy zapewniające trwałość danych Zastosowanie: niezależność od bazy danych, wydajność, łatwy w tworzeniu BMP (Bean Managed Persistence) Programista dostarcza logikę zapewniającą trwałość
JavaBeans vs EJB JavaBeans Przenośność w IDE Dostosowanie komponentów bazuje na introspekcji i IDE Zestaw interfejsów i zachowań komponentów do wizualnej manipulacji własnościami Zdarzenia (publish-and-subscribe) typowo używane dla komunikacji między komponentami Komponenty są niezależne a ich kod wykonywany w ramach JVM Enterprise JavaBeans Środowisko uruchomieniowe w ramach serwera aplikacyjnego Środowisko uruchomieniowe jest modyfikowane metodą programowania deklaratywnego Zestaw interfejsów i zachowań komponentów dla wykonania kodu w ramach serwera aplikacyjnego Zdalne interfejsy i zdalne wywoływanie metod typowym przykładem komunikacji między komponentami Komponenty nie mogą istnieć poza odpowiednimi kontenerami dostarczanymi przez serwer aplikacyjny Źródło: OPA, Krystian Ignasiak
Session vs. Entity Beans Komponent session Prywatne zasoby klienta Klient wpływa na stan komponentu Komponent nie jest trwały Cyklem życia zarządza komponent Zwykle tworzony w momencie żądania użycia Zwykle jednowątkowy Komponent entity Wielu klientów realizuje współbieżny dostęp Komponent reprezentuje stan danych Komponent jest trwały Cykl życia odpowiada stanowi trwałemu (persistent) Zwykle odnajdywany w momencie żądania użycia Jednowątkowy z definicji Źródło: OPA, Krystian Ignasiak