1 / 44

Wprowadzenie do platformy J2EE

Wprowadzenie do platformy J2EE. Co to jest J2EE. Specyfikacja firmy Sun Microsystems, która umożliwia budowanie aplikacji wielowarstwowych ( n-tier ); systemów enterprise które dostarczają W ysokiej niezawodności Zapewnienie dostępu do zasobów wg reguły 24/7

vanna-rodgers
Télécharger la présentation

Wprowadzenie do platformy J2EE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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ściZapewnienie dostępu do zasobów wg reguły 24/7 • BezpieczeństwaZapewnienie 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 PlatformSpecyfikacja platformy • J2EE Programming ModelZbiór wskazówek tzw. design patterns wraz z propozycją konkretnego modelu aplikacji – J2EE BluePrints • J2EE Compatibility Test SuiteZbiór testów umożliwiający weryfikację zgodności ze specyfikacją konkretnej implementacji J2EE • J2EE Reference ImplementationDostarczona 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ść) • Wtym modelu logika biznesowa jest implementowana w poziomiemiddle 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, JSPEJB, 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- komponentywebowe (.war) – web.xml - komponenty EJB(.jar) – ejb-jar.xml - Cała aplikacja (.war + .jar = .ear) – application.xml • deployment descriptors specyficzne dla serwera aplikacji

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

  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 APInp. 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. Wszystkieoperacje uczestniczące w tej jednostkowej operacji powinnyzakończyć się sukcesem, niepowodzeniem, jak i wyjść zkryzysu 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. Komponenty tej architektury Komponenty aplikacji Menedżer zasobów Menedżer transakcji Architektura przetwarzania transakcji

  27. Menadżer transakcji i zasobów

  28. Sprzężenie JTS i JTA

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

  30. Adaptery Enterprise Application Integrator - EAIArchitektura 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 poprzezAPI 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 programowaniaOddzielenie specyfikacji oraz implementacji • Luźno połączoneOparte na wymianie komunikatów – komunikacja synchroniczna lub asynchroniczna • Komunikacja (ang. interoperability)Oparta na protokołach • Poprzez internetBrak centralnego punktu przetwarzania, wykorzystanie odpowiednich protokołów transportowych (np. HTTP)

  41. Komunikacja App2App - WebServices • Protokół transportowy HTTP/HTTPS, SMTP • Kodowanie (format) danychSOAP (Simple Object Access Protocol) • Opis interfejsówWSDL (Web Services Description Language) • Opis serwisu oraz lokalizacjaUDDI (Universal Description, Discovery and Integration) • BezpieczeństwoWS-Security, XML-Signature

  42. 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 SOAP1.1 Message Structure SOAP Envelope Header Entries [Header Element] Body Element [Fault Element]

  43. 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 WSDL

  44. Dziękuję za Uwagę

More Related