Wprowadzenie do platformy J2EE

Prezentacja na temat: "Wprowadzenie do platformy J2EE"— Zapis prezentacji:

1 Wprowadzenie do platformy J2EE

2 Co to jest J2EE Specyfikacja firmy Sun Microsystems, która umożliwia budowanie aplikacji wielowarstwowych (n-tier); systemów enterprise które dostarczają Wysokiej niezawodności Zapewnienie dostępu do zasobów wg reguły 24/7 Bezpieczeństwa Zapewnienie bezpieczeństwa użytkowników systemu i integracji danych Trwałych i skalowlanych Wszystkie biznes transakcje są poprawnie zakończone Czas odpowiedzi na stałym poziomie wraz z wzrostem liczby użytkowników

3 J2EE - serwisy

4 Model J2EE Model J2EE składa się z następujących elementów
J2EE Platform Specyfikacja platformy J2EE Programming Model Zbiór wskazówek tzw. design patterns wraz z propozycją konkretnego modelu aplikacji – J2EE BluePrints J2EE Compatibility Test Suite Zbiór testów umożliwiający weryfikację zgodności ze specyfikacją konkretnej implementacji J2EE J2EE Reference Implementation Dostarczona przez twórcę specyfikacji, firmę SUN wzorcowa implementacja specyfikacji

5 Model aplikacji opartej na J2EE
Architektura aplikacji dostarczająca serwisów o architekturze wielowarstwowej która posiada takie cechy jak skalowalność, przenośność, łatwa administracja Architekt systemu może się skupić na logice biznesowej, natomiast serwisy niskiego poziomu jak transakcyjność, obsługa wielu klientów są dostarczane przez platformę (wielowątkowość) W tym modelu logika biznesowa jest implementowana w poziomie middle modelu trójwarstwowego, który jest podzielony na małe kawałki a każdy z nich ma swoją określoną funkcję, każdy z tych kawałków w zależności od typu może być wykonywany w Web-Container lub EJB-Container Kontenery zarządzają cyklem życia komponentów i dostarczają mechanizmów dostępu do zasobów systemu, które są używane przez te komponenty

6 Model aplikacji opartej na J2EE – cd.

7 Serwer aplikacji Manager komponentów J2EE – serwlety, JSP EJB, ich pulowalność (resource pooling) oraz cykl życia Obsługa protokołów komunikacji – HTTP, HTTPS, RMI, IIOP Zarządzanie zasobami – połączenia i wielowątkowość Manager transakcji Usługi zapewniające bezpieczeństwo Perzystencja Obsługa dostępu do EIS Nowa jakość – kontener dla komponentu jest jak system operacyjny dla procesu

8 Deployment descriptors
Opisuje aplikację, a dokładniej wszystkie komponenty J2EE jakie się na nią składają Format plików oparty na standardzie XML deployment descriptors istnieją dla następujących komponentów - komponenty webowe (.war) – web.xml - komponenty EJB (.jar) – ejb-jar.xml - Cała aplikacja (.war + .jar = .ear) – application.xml deployment descriptors specyficzne dla serwera aplikacji

9 Deployment descriptors – cd.
Serwlety, Stony JSP Zawartość statyczna(HTML, images), biblioteki Java, TLDs Deployment Descriptor web.xml EJBs ejb-jar.xml application.xml

10 Przegląd technologii wchodzących w skład J2EE
Java Naiming Directory Interface (JNDI) Serwlety, JSP EJB Konektory JTA/JTS JMS Webservices

11 Java Naming and Directory Interface
Zasadniczy komponent Java 2 Platform Enterprise Edition Pomost pomiędzy usługami nazewnictwa i katalogowania Interfejs do lokalizacji zasobów Jednolity system dostępu do każdego rodzaju informacji usług katalogowania (referencje bezpieczeństwa, numery telefonów, elektroniczne i pocztowe adresy, preferencje aplikacji, adresy sieciowe, konfiguracje maszyn, itd.)

12 Java Naming and Directory Interface – cd.
Pojedyncze API dostępu do katalogów o różnych protokołach dostępu Izolacja aplikacji od protokołów i szczegółów implementacyjnych Rozszerzalny interfejs. Przyszli dostarczyciele usług katalogowania będą mogli dodawać nowe usługi do JNDI bez ingerowania w kod klienta Czytanie i zapisywanie całych obiektów Java do katalogów Łączenie różnych typów katalogowania

13 Architektura JNDI

14 Podobieństwa architektury JNDI i JDBC
W JDBC jest jedno ujednolicone API do wykonywania operacji na bazie danych. W JNDI, klienci usług nazewnictwa i katalogowania również korzystają z jednolitego API W JDBC dostarczyciele relacyjnych bazy danych tworzą sterowniki umożliwiające korzystanie z tychże baz. W JNDI dostarczyciele usług katalogowania tworzą SPI, umożliwiające korzystanie z ich specyficznych katalogów.

15 Kluczowe pakiety JNDI The naming package, javax.naming, używany w celu dostępu do usługi nazw. Usługi nazw kojarzą nazwy z obiektami i dostarczają udogodnień do znajdowania obiektów na podstawie ich nazw. The directory package, javax.naming.directory, używany zarówno do dostępu do usług nazw, jak i usług katalogowych. Pakiet ten dziedziczy po javax.naming, tak więc umożliwia wykonanie tych samych operacji jakie są dostępne w javax.naming. Dodatkowo dodaje możliwość manipulowania atrybutami skojarzonymi z obiektami. The service provider interface (SPI), javax.naming.spi, jest interfejsem, rozszerzanym przez doręczycieli usług.

16 Serwlety Komponenty wykonywane po stronie serwera, które odpowiadają na żądania klientów przez protokół HTTP/HTTPS W modelu MVC (Model Viewer Controler) pełnią rolę Controlera Cechy lekkie komponenty, wykonywane wewnątrz Web-Containera bezpieczeństwo, w przeciwieństwie do CGI mają ograniczony dostęp do zasobów systemowych programista dysponuje bogatym zestawem funkcji Java Servlet API np. obsługa sesji HTTP (session tracking), obiekty HttpServletResponse oraz HttpServletRequest reprezentujące odpowiednio żądanie klienta i odpowiedź serwera

17 JSP strony HTML/XML wraz z osadzonym kodem Java
strony JSP są kompilowane do serwletów, przez co także są wykonywane wewnątrz Web-Container do klienta jako wynik zapytania zwracany jest HTML/XML W modelu MVC (Model Viewer Controler) pełnią funkcję View Cechy oparte na technologii serwletów mają charakter skryptowy, mogą używać JavaBeans, Taglibs rekompilowane automatycznie po każdej zmianie

18 Engine JSP & Servlets

19 Serwlety i JSP – porównanie
obie technologie są równoważne, czyli każdy serwlet można zaprojektować jako stronę JSP i odwrotnie, ale biorąc pod uwagę model MVC odgrywają one różne role JSP zapewniają podział prac pomiędzy programistom a designerem stron HTML serwletów można używać gdy chcemy wykonać czynności inicjalizacyjne lub zapisywać dane w formacie binarnym do klienta

20 Enterprise Java Beans Zadanie to definiowanie logiki biznesowej systemu Komponenty o właściwościach modularnych, skalowalnych Wykonywane wewnątrz EJB Containera, przez co są komponentami transakcyjnymi Trzy typy EJB: session, entity i message driven beans Zgodnie z założeniami J2EE logika biznesowa implementowana jest w session EJBs, natomiast entity EJBs są obiektową reprezentacją informacji w bazie danych. Klient powinien odwoływać się do session EJB a te następnie wywołują enity EJBs, innymi słowy ich wywołania powinny zostać wewnątrz kontenera

21 Enterprise Java Beans – cd.
Stateless Session EJB – nie zachowuje informacji o stanie pomiędzy kolejnymi wywołaniami, są one obiektami pulowalnymi tzn. klient przy jego wywołaniu otrzymuje już istniejącą instancję, która po każdym wywołaniu metody biznesowej jest zwracana z powrotem do puli Statefull Session EJB - każda instancja obsługuje jednego klienta i co ważne zachowuje swój stan przy każdym kolejnym odwołaniu, dlatego mogą być one używane w przypadku gdy chcemy w nim przechowywać informacje dotyczące sesji klienta Entity EJB – odpowiedzialne za perzyztencję systemu, która może być obsługiwana bezpośrednio przez kontener (CMP-Container Managed Persistence) lub też przez programistę (BMP-Bean Managed Persistence). Każda instancja entity EJBs jest identyfikowany przez obiekt primary key. Message Driven Beans – wykorzystywane w systemach o architekturze MOM (Message Oriented Middleware), komponenty sterowane komunikatami np. JMS

22 Enterprise Java Beans – cd.

23 Transakcja - definicja
Transakcja – seria operacji, która wydają się wykonywać jak jedna duża atomowa operacja. Wszystkie operacje uczestniczące w tej jednostkowej operacji powinny zakończyć się sukcesem, niepowodzeniem, jak i wyjść z kryzysu razem.

24 Własności transakcji - ACID
Atomowość Konsystencja Izolacja Trwałość

25 Transakcje w systemach biznesowych
Domeny: finanse, bankowość, handel elektroniczny Złożoność wymagań biznesowych współczesnych aplikacji powoduje, iż przetwarzanie transakcji to jeden z najbardziej złożonych segmentów aplikacji rozproszonych

26 Architektura przetwarzania transakcji
Komponenty tej architektury Komponenty aplikacji Menedżer zasobów Menedżer transakcji

27 Menadżer transakcji i zasobów

28 Sprzężenie JTS i JTA

29 Integracja J2EE z systemami EIS
Purchased Apps Internet Java Różne systemy operacyjne Różne języki programowania Wiele baz danych Rozbudowana infrastruktura LAN Trudny dostęp poprzez protokół HTTP

30 Adaptery Enterprise Application Integrator - EAI Architektura konektorów
Jak komunikować się z poziomu serwera aplikacji ze systemami heterogenicznymi Określa standard dzięki któremu nasza aplikacja w razie potrzeby może być przeniesiona na serwer aplikacji innego producenta Umożliwia napisanie adaptera do odpowiedniego systemu w charakterze wtyczki

31 Architektura konektorów – cd.
Resource adapter – komunikacja na poziomie serwer aplikacji – EIS, odpowiedzialny za pulę połączeń, transakcyjność, bezpieczeństwo Interfejs CCI (Common Client Interface) umożliwia wykorzystanie zasobów poprzez API wykorzystywane po stronie klienta

32 Java Messaging Service
Java Messaging Service to usługa niezawodnej, asynchronicznej wymiany komunikatów. Architektura JMS opiera się na scentralizowanym zarządzaniu rozsyłaniem informacji w systemie.

33 Architektura JMS

34 Architektura JMS – cd. JMS provider: system komunikatów implementujący interfejs JMS i dostarczający cech administracyjnych. · JMS clients: programy lub komponenty napisane w języku Java, które produkują i konsumują komunikaty · Messages: obiekty, w których przesyłana jest informacja pomiędzy klientami JMS · Administered objects: prekonfigurowane obiekty JMS stworzone przez administratora do użytku klientów. Dwa rodzaje: destinations i connection factories. · Native clients: programy, które używają natywne API kliencie produktu kolejkowego zamiast JMS API.

35 Model point-to-point

36 Model point-to-point – cd.
Każdy komunikat ma tylko jednego konsumenta Nie ma żadnych zależności czasowych pomiędzy nadawcą, a odbiorcą komunikatu. Odbiorca może pobrać komunikat niezależnie od tego, czy był uruchomiony, gdy klient wysłał ten komunikat, czy też nie Odbiorca potwierdza udane przetworzenie komunikatu Stosuj, gdy chcesz, aby każdy komunikat wysłany został przetworzony z sukcesem przez konsumenta.

37 Model publish/subscribe

38 Model publish/subscribe – cd.
Każdy komunikat może mieć wielu konsumentów Jest zależność czasowa pomiędzy nadawcami i odbiorcami, ponieważ klient, który subskrybował się do forum może konsumować tylko komunikaty publikowane po jego subskrypcji, i musi pozostawać aktywnym, aby konsumować komunikaty Stosuj, gdy chcesz, aby każdy komunikat był przetwarzany przez zero, jednego lub wielu konsumentów.

39 WebServices Infrastruktura niezależna od języka programowania i platformy dla luźno połączonych (ang. loosely-coupled), wspólnie komunikujących się aplikacji poprzez mechanizmy Internet.

40 WebServices – cd. Niezależność od platformy i języka programowania Oddzielenie specyfikacji oraz implementacji Luźno połączone Oparte na wymianie komunikatów – komunikacja synchroniczna lub asynchroniczna Komunikacja (ang. interoperability) Oparta na protokołach Poprzez internet Brak centralnego punktu przetwarzania, wykorzystanie odpowiednich protokołów transportowych (np. HTTP)

41 Komunikacja App2App - WebServices
Protokół transportowy HTTP/HTTPS, SMTP Kodowanie (format) danych SOAP (Simple Object Access Protocol) Opis interfejsów WSDL (Web Services Description Language) Opis serwisu oraz lokalizacja UDDI (Universal Description, Discovery and Integration) Bezpieczeństwo WS-Security, XML-Signature

42 SOAP Protokół oparty na XML Loosely coupled
SOAP1.1 Message Structure Protokół oparty na XML Określa sposób kodowania danych Reprezentuje składnie zdalnych wywołań (RPC) Loosely coupled Brak zdalnych referencji Niezależny od warstwy transportowej „SOAP with Attachments” - pozwala na przesyłanie specyficznych danych SOAP Envelope Header Entries [Header Element] Body Element [Fault Element]

43 WSDL Dokument WSDL opisuje Funkcjonalność Lokalizacje Sposób wywołania
Podobny do IDL, ale bardziej rozszerzalny Definiuje mapowania dla SOAP1.1, HTTP, GET/POST and MIME Dokumenty WSDL mogą być udostępniane w serwisach UDDI

44 Dziękuję za Uwagę