JAVA EE MODEL APLIKACJI. Waldemar Korłub. Narzędzia i aplikacje Java EE KASK ETI Politechnika Gdańska

Transkrypt

1 JAVA EE MODEL APLIKACJI Waldemar Korłub Narzędzia i aplikacje Java EE KASK ETI Politechnika Gdańska

2 Architektura aplikacji 2 Java EE od początku była projektowana z myślą o aplikacjach klasy enterprise Podział na wiele modułów i komponentów n Dystrybuowanych jako osobne archiwa JAR/WAR n Kontrakty w postaci statycznie typowanych interfejsów n Wysoka separacja modułów, luźne powiązania Nacisk na separację odpowiedzialności n Oddzielenie logiki biznesowej od interfejsu aplikacji i warstwy danych Wczesne wersje Javy EE (do J2EE 1.4) wymuszały rozbudowaną architekturę aplikacji Korzystne w dużych projektach platforma wymusza na deweloperach określoną kulturę pracy Uciążliwe w małych projektach i w czasie prototypowania n Świadomy wybór architektów platformy J2EE

3 Wielowarstwowa aplikacja Java EE 3

4 EAR: Enterprise ARchive 4 JAR RAR WAR JAR

5 Architektura aplikacji 5 Od Javy EE 5 (2006 r.) większość elementów architektonicznych staje się opcjonalna Ten kierunek rozwoju jest kontynuowany w wersjach Java EE 6 (2009), 7 (2013), 8 (2017) Współcześnie możemy zacząć pracę z Javą EE niczym z mikroframeworkiem Idea convention over configuration Deskryptory typu web.xml nie są konieczne i dodawać kolejne elementy w miarę potrzeb Model aplikacji skaluje się wraz z rozwojem projektu

6 Profile platformy Java EE 6 Określają jakie funkcje musi posiadać serwer, aby uzyskać certyfikat zgodności z Javą EE Full Profile n Wszystkie specyfikacje wchodzące w skład Javy EE n Obsługa archiwów EAR (Enterprise Archive) oraz WAR Web Profile (od Javy EE 6) n Profil przeznaczony dla aplikacji WWW (stron internetowych) n Nie obejmuje m.in.: EJB remoting, async, timer, JMS, Batch n Tylko archiwa WAR (Web ARchive) MicroProfile (EE4J 9?) n Profil przeznaczony dla mikroserwisów

7 Web vs Full vs MicroProfile 7 Web Profile (Java EE 8) Full Profile (Java EE 8) Servlet 4.0 JavaServer Pages (JSP) 2.3 Expression Language (EL) 3.0 Debugging Support for Other Languages 1.0 STL for JavaServer Pages (JSTL) 1.2 JavaServer Faces (JSF) 2.3 Java API for RESTful Web Services (JAX-RS) 2.1 Java API for WebSocket (WebSocket) 1.1 Java API for JSON Processing (JSON-P) 1.1 Java API for JSON Binding (JSON-B) 1.0 Common Annotations (JSR-250) 1.3 Enterprise JavaBeans (EJB) 3.2 Lite Java Transaction API (JTA) 1.2 Java Persistence API (JPA) 2.2 Bean Validation 2.0 Managed Beans 1.0 Interceptors 1.2 CDI 2.0 Dependency Injection for Java 1.0 Java EE Security API 1.0 JASPIC 1.1 Wszystkie specyfikacje z Web Profile EJB 3.2 JMS 2.0 JavaMail 1.6 Connector 1.7 Web Services 1.4 Concurrency Utilities 1.0 Batch 1.0 Java EE Management 1.1 JACC 1.5 JSP Debugging 1.0 Web Services Metadata 2.1 MicroProfile JAX-RS CDI JSON-P

8 Wildfly Swarm 8 Czasami żaden profil nie pasuje do potrzeb aplikacji Wildfly Swarm umożliwia skomponowanie serwera, który zawiera tylko biblioteki wymagane w projekcie Wymagane komponenty określone w pom.xml lub automatycznie wykrywane na podstawie kodu projektu przez wildfly-swarm-plugin W czasie budowania projektu (mvn package) powstaje archiwum JAR obejmujące: Komponenty aplikacji Zależności aplikacji (biblioteki 3rd party) Serwer aplikacji Łatwa dystrybucja pojedynczy plik JAR Łatwe uruchamianie aplikacji: $ java -jar app.jar Nie ma potrzeby wdrażania na osobny serwer

9 Próg wejścia 9 Java EE jest postrzegana jako platforma o wysokim progu wejścia Ciekawe dlaczego Inne frameworki oferują najczęściej jeden model wytwarzania aplikacji Dostosowany dla jednej klasy projektów W Javie EE wybieramy model aplikacji w zależności od skali projektu Następnie wybieramy poszczególne rozwiązania n np. transakcje: w warstwie EJB lub JTA lub JPA (resource local) lub zarządzane przez CDI (@Transactional) Architekt aplikacji musi znać specyfikę dostępnych rozwiązań, aby prawidłowo je dobrać do wymagań projektu

10 10 Pytania?