Wprowadzenie do JavaEE

Dzisiaj porozmawiamy o tym, czym jest - Java EE: z czego się składa, jakie są cechy architektury aplikacji Java EE, a także przedstawimy opisy różnych technologii tej platformy. Sam temat jest obszerny, ale nie poprzestaniemy na podstawach. Na koniec dokonamy małego porównania Java EE z Spring Framework i odpowiemy na pytanie: „czego lepiej się uczyć” (spoiler: oczywiście wszystkiego trzeba się nauczyć =) ) Zacznijmy od podstaw.

Java EE – co to jest?

Java EE to platforma zbudowana na bazie Java SE, która zapewnia interfejs API i środowisko wykonawcze do tworzenia i uruchamiania wielkoskalowych, wielowarstwowych, skalowalnych, niezawodnych i bezpiecznych aplikacji sieciowych. Takie aplikacje nazywane są aplikacjami korporacyjnymi, ponieważ rozwiązują problemy, z którymi borykają się duże firmy. Jednakże duże korporacje i agencje rządowe nie są jedynymi, które mogą czerpać korzyści z takich aplikacji i korzyści, jakie zapewnia Java EE. Rozwiązania oferowane przez platformę Java EE są przydatne, a czasem po prostu niezbędne, zarówno dla indywidualnych programistów, jak i małych organizacji.

Rozwój Java EE

Java EE jest rozwijany w ramach procesu Java Community Process (JCP), utworzonego w 1998 roku. Umożliwia zainteresowanym uczestniczenie w kształtowaniu przyszłych wersji specyfikacji platformy językowej Java. Podstawą tego procesu jest JSR (JavaSpecification Request), formalne dokumenty opisujące specyfikacje i technologie, które mają zostać dodane do platformy Java. Takie prośby składają członkowie społeczności - zwykli programiści i firmy. Do tych ostatnich zaliczają się Oracle, Red Hat, IBM, Apache i wiele innych. Te. chłopaki proponują do rozważenia nowe funkcje i gadżety, które chcieliby uwzględnić w Javie. A następnie przeprowadzają głosowanie, na podstawie którego zapada decyzja, co uwzględnić w kolejnej wersji. Historia wersji Java EE wygląda następująco:

• J2EE 1.2 (grudzień 1999)
• J2EE 1.3 (wrzesień 2001)
• J2EE 1.4 (listopad 2003)
• Java EE 5 (maj 2006)
• Java EE 6 (grudzień 2009)
• Java EE 7 (maj)
• Java EE 8 (sierpień 2017 r.)
• Dżakarta EE 8 (wrzesień 2019)

W 2017 roku nastąpił nowy kamień milowy w rozwoju platformy: Oracle przekazało kontrolę nad rozwojem Java EE Fundacji Eclipse. W kwietniu 2018 roku nazwę Java EE zmieniono na Jakarta EE, która jest w pełni kompatybilna z Java EE 8.

Architektura aplikacji Java EE

Krótkie wprowadzenie. Aby ułatwić zrozumienie, porozmawiajmy o strukturze aplikacji Java EE i niektórych terminach, których będziemy używać dalej. Aplikacje Java EE mają strukturę, która ma dwie kluczowe cechy:

• Po pierwsze, wielopoziomowe. Aplikacje Java EE są wielowarstwowe i omówimy to bardziej szczegółowo później;
• po drugie, zagnieżdżanie. Istnieje serwer Java EE (lub serwer aplikacji) z umieszczonymi w nim kontenerami komponentów. W tych pojemnikach mieszczą się komponenty (bingo!).

Aby wyjaśnić architekturę aplikacji Java EE, porozmawiajmy najpierw o warstwach. Jakie są poziomy? Jakie technologie Java EE są wykorzystywane na różnych poziomach? Następnie omówimy, w jaki sposób serwery aplikacji, kontenery komponentów i same komponenty są ze sobą połączone. Należy jednak pamiętać, że wszystkie te obrazy przedstawiają spojrzenie na tę samą rzecz z różnych punktów widzenia i kolejność nie jest tutaj tak istotna.

Poziomy aplikacji

Aplikacje wielowarstwowe to aplikacje podzielone według zasad funkcjonalnych na izolowane moduły (poziomy, warstwy). Zazwyczaj (także w kontekście rozwoju Java EE) aplikacje korporacyjne dzieli się na trzy poziomy:

• klient;
• średni poziom;
• poziom dostępu do danych.

1. Warstwa klienta to aplikacja żądająca danych z serwera Java EE (warstwa środkowa). Serwer z kolei przetwarza żądanie klienta i zwraca na nie odpowiedź. Aplikacją kliencką może być przeglądarka, samodzielna aplikacja (mobilna lub stacjonarna) lub inna aplikacja serwerowa bez interfejsu graficznego.

2. Poziom środkowy dzieli się z kolei na poziom sieciowy i poziom logiki biznesowej.

   1. Warstwa sieciowa składa się z komponentów zapewniających interakcję pomiędzy klientami a warstwą logiki biznesowej.

      Na poziomie sieci wykorzystywane są następujące technologie Java EE:

      • Technologia JavaServer Faces (JSF);
      • Strony serwera Java (JSP);
      • Język wyrażeń (EL);
      • serwlety;
      • Konteksty i wstrzykiwanie zależności dla Java EE (CDI).

   2. Warstwa logiki biznesowej składa się z komponentów implementujących całą logikę biznesową aplikacji. Logika biznesowa to kod zapewniający funkcjonalność pokrywającą potrzeby określonego obszaru biznesowego (branża finansowa, bankowość, e-commerce). Poziom ten można uznać za rdzeń całego systemu.

      Technologie stosowane na tym poziomie:

      • Korporacyjne komponenty JavaBeans (EJB);
      • Usługi sieciowe JAX-RS RESTful;
      • Jednostki API trwałości Java;
      • Usługa wiadomości Java.

3. Poziom dostępu do danych. Poziom ten nazywany jest czasem poziomem systemów informatycznych przedsiębiorstwa (EIS). EIS składa się z różnych serwerów baz danych, systemów planowania zasobów przedsiębiorstwa ERP (Enterprise Resource Planning) i innych źródeł danych. Warstwa logiki biznesowej uzyskuje dostęp do tej warstwy w celu uzyskania danych.

   Na tym poziomie można znaleźć technologie takie jak:

   • Interfejs API łączności z bazą danych Java (JDBC);
   • API trwałości Java;
   • Architektura złącza Java EE;
   • Interfejs API transakcji Java (JTA).

Serwery aplikacji, kontenery, komponenty

Przyjrzyjmy się definicji Java EE z Wikipedii. Java EE to zbiór specyfikacji i dokumentacji z nią związanej dla języka Java, opisującej architekturę platformy serwerowej dla zadań średnich i dużych przedsiębiorstw. Aby lepiej zrozumieć, co w tym kontekście oznacza „zestaw specyfikacji”, przeprowadźmy analogię z interfejsem Java. Sam interfejs Java jest pozbawiony funkcjonalności. Po prostu definiuje jakąś umowę, zgodnie z którą jakaś funkcjonalność jest realizowana. Ale inne klasy implementują interfejs. Co więcej, jeden interfejs może mieć kilka implementacji, z których każda może różnić się od siebie pewnymi szczegółami. Specyfikacja jest dokładnie taka sama. Naked Java EE to tylko zestaw specyfikacji. Specyfikacje te są wdrażane przez różne serwery Java EE. Serwer Java EE to aplikacja serwerowa, która implementuje interfejsy API platformy Java EE i udostępnia standardowe usługi Java EE. Serwery Java EE są czasami nazywane serwerami aplikacji. Dane serwera mogą zawierać komponenty aplikacji, z których każdy odpowiada swojemu poziomowi w wielopoziomowej hierarchii. Serwer Java EE udostępnia tym komponentom różne usługi w formie kontenera. Kontenery stanowią interfejs pomiędzy hostowanymi przez nie komponentami a niskopoziomową, niezależną od platformy funkcjonalnością obsługującą dany komponent. Kontenery zapewniają określone usługi komponentom, które hostują. Na przykład zarządzanie cyklem życia oprogramowania, wstrzykiwanie zależności, współbieżność itp. Kontenery ukrywają złożoność techniczną i zwiększają przenośność. W Java EE istnieją cztery różne typy kontenerów :

1. Kontenery apletów są implementowane przez większość przeglądarek. Tworząc aplety, możesz skoncentrować się na wizualnej stronie aplikacji, podczas gdy kontener zapewnia bezpieczne środowisko.

2. Kontener klienta aplikacji (ACC) zawiera zestaw klas Java, bibliotek i innych plików potrzebnych do implementowania takich funkcji, jak wstrzykiwanie, zarządzanie bezpieczeństwem i usługi nazewnictwa w aplikacjach Java SE.

3. Kontener sieciowy zapewnia podstawowe usługi zarządzania i wykonywania komponentów sieciowych (serwlety, komponenty EJB Lite, strony JSP, filtry, odbiorniki, strony JSF i usługi sieciowe). Odpowiada za tworzenie instancji, inicjowanie i wywoływanie serwletów oraz obsługę protokołów HTTP i HTTPS. Kontener ten służy do udostępniania stron internetowych przeglądarkom klienckim.

4. Kontener EJB (Enterprise Java Bean) odpowiada za zarządzanie i wykonywanie komponentów modelu EJB, które zawierają warstwę logiki biznesowej aplikacji. Tworzy nowe jednostki komponentu EJB, zarządza ich cyklem życia i zapewnia usługi, takie jak transakcje, bezpieczeństwo, współbieżność, dystrybucja, nazewnictwo lub możliwości wywoływania asynchronicznego.

Również w Java EE istnieją cztery typy komponentów , które musi obsługiwać implementacja specyfikacji Java EE:

1. Aplety to aplikacje z graficznym interfejsem użytkownika (GUI), które działają w przeglądarce. Wykorzystują bogate API Swing do tworzenia potężnych interfejsów użytkownika.

2. Aplikacje to programy działające po stronie klienta. Zazwyczaj są to graficzne interfejsy użytkownika (GUI) i służą do przetwarzania wsadowego.

3. Aplikacje internetowe (składające się z serwletów i ich filtrów, detektorów zdarzeń sieciowych, stron JSP i JSF) - działają w kontenerze sieciowym i odpowiadają na żądania HTTP od klientów sieciowych. Serwlety obsługują także punkty końcowe usług internetowych SOAP i RESTful.

4. Aplikacje korporacyjne (zbudowane w oparciu o Enterprise Java Beans, Java Message Service, Java Transaction API, wywołania asynchroniczne, usługi czasowe) działają w kontenerze EJB. EJB zarządzane przez kontener obsługują transakcyjną logikę biznesową. Można uzyskać do nich dostęp lokalnie lub zdalnie poprzez RMI (lub HTTP w przypadku usług sieciowych SOAP i RESTful).

Poniższy diagram przedstawia typową architekturę aplikacji Java EE:

Technologie

Więc uporządkowaliśmy architekturę. Ogólna struktura powinna być jasna. W procesie opisywania komponentów architektonicznych poruszyliśmy niektóre technologie Java EE takie jak EJB, JSP itp. Przyjrzyjmy się im bliżej. Poniższa tabela przedstawia technologie stosowane głównie na poziomie klienta: Poniższa tabela przedstawia technologie zastosowane na poziomie logiki biznesowej: Poniższa tabela przedstawia technologie stosowane w warstwie dostępu do danych:

Java EE kontra wiosna

Spring Framework jest uważany za konkurenta Java EE. Jeśli przyjrzeć się rozwojowi tych dwóch platform, wyłania się ciekawy obraz. Pierwsze wersje Java EE powstały przy udziale IBM. Okazały się fajne, ale nieporadne, ciężkie i niewygodne w użyciu. Programiści mieli problemy z powodu konieczności utrzymywania dużej liczby plików konfiguracyjnych i innych powodów, które komplikują rozwój. W tym samym czasie narodził się Spring IoC. Była to mała, piękna i łatwa w obsłudze biblioteka. Używał również pliku konfiguracyjnego, ale w przeciwieństwie do Java EE był tylko jeden. Prostota Springa doprowadziła do tego, że prawie każdy zaczął wykorzystywać ten framework w swoich projektach. A potem Spring i Java EE rozpoczęły swoją drogę do tego samego, ale z różnych stron. Pivotal Software, twórca Springa, zaczął wydawać projekt za projektem, aby zaspokoić wszystkie możliwe i niemożliwe potrzeby programistów Java. Stopniowo to, co wcześniej nazywało się Spring, najpierw stało się jednym z projektów, a następnie całkowicie połączyło się z kilkoma innymi projektami w Spring Core. Wszystko to doprowadziło do nieuniknionych komplikacji wiosny w porównaniu z tym, czym była pierwotnie. Z biegiem czasu bardzo trudno było śledzić całą plątaninę zależności Springa i pojawiła się potrzeba osobnej biblioteki, która sama by wszystko ładowała i uruchamiała (teraz ukochany Spring Boot gdzieś się zawiesił). Przez cały ten czas JCP pracowało nad jedną rzeczą – aby osiągnąć maksymalne uproszczenie wszystkiego, co jest możliwe w Java EE. Dzięki temu w nowoczesnym EJB do opisania komponentu bean wystarczy podać jedną adnotację nad klasą, co daje programiście dostęp do pełnych możliwości technologii Enterprise Java Beans. Podobne uproszczenia wpłynęły na każdą specyfikację Java EE. W rezultacie Spring i Java EE są mniej więcej równe pod względem funkcjonalności. Niektóre rzeczy są lepsze, inne gorsze, ale jeśli spojrzeć globalnie, nie ma dużych różnic. To samo tyczy się złożoności zadania. Zarówno Spring, jak i Java EE są doskonałymi narzędziami. Być może najlepsze, jakie obecnie istnieje do tworzenia aplikacji sieciowych dla przedsiębiorstw w języku Java. Jednak Java EE może ogólnie działać tylko w ramach Enterprise Application Server (Tomcat nie jest jednym z nich), a aplikacja na stosie Spring może działać na czymkolwiek (na tym samym Tomcacie), a nawet w ogóle bez serwera (ponieważ będzie działać w sobie niezależnie). To sprawia, że ​​Spring jest idealnym narzędziem do tworzenia małych aplikacji typu front-end GUI lub architektur mikrousług. Jednak wyeliminowanie zależności od serwerów aplikacji miało negatywny wpływ na skalowalność aplikacji Spring. Java EE doskonale nadaje się do wdrażania skalowalnych, monolitycznych aplikacji klastrowych. Programiści znający Spring Framework są obecnie bardziej poszukiwani na rynku pracy. Historycznie rzecz biorąc, działo się tak: w czasie, gdy Java EE była zbyt skomplikowana, Spring „zyskał bazę klientów”. A mimo to nie ma jednoznacznej odpowiedzi na pytanie, czego uczyć się Springa czy Java EE. Początkującemu można udzielić następujących rad. Zapoznaj się (przynajmniej powierzchownie) z obiema platformami. Napisz mały projekt domowy w Java EE i Spring. A następnie zagłębij się w ramy, które będą potrzebne w pracy. Dzięki temu przełączanie pomiędzy Springiem a Java EE nie będzie trudne.

Wyniki

Tematu o dużej skali nie da się oczywiście omówić w jednym artykule! Po mnóstwie nowych terminów prawdopodobnie chcesz „zastosować” tę wiedzę na przykładzie z życia wziętym. Dlatego będziemy kontynuować naukę Java EE: w następnym artykule znajdziesz praktyczne lekcje dotyczące konfigurowania lokalnego środowiska do programowania Java EE.