Wykład 1

Platforma J2EE

Java 2 Enterprise Edition


"Unfortunately, no one can be...told what the J2EE is.
You have to see it for yourself."


Streszczenie

W tym wykładzie przedstawię platformę J2EE (Java 2 Enterprise Edition). Jest to zbiór powiązanych ze sobą technologii, które umożliwiają (lub też ułatwiają) pracę programisty budującego aplikacje gospodarcze. Wybór Javy nie jest przypadkowy. J2EE jest kompletnym zbiorem specyfikacji wszystkiego, co może się przydać programiście aplikacyjnemu: język redagowania dynamicznych stron, obsługa trwałości, transakcji i autoryzacji oraz odwzorowanie obiektowo-relacyjne i wiele innych. Istnieją oczywiście inne podobne rozwiązania (jak .NET), jednak uznałem, że wybór J2EE jako wiodącej tematyki będzie najlepiej służył celom tego wykładu. Tę tezę postaram się udowodnić przy końcu wykładu.


Wstęp

Współczesne przedsiębiorstwa, aby się rozwijać, muszą poszerzać zakres swych usług, obniżać ich koszty i zapewniać wygodny dostęp do nich dla klientów, pracowników i dostawców. W typowej systuacji aplikacje realizujące te usługi muszą łączyć istniejące systemy informacyjne przedsiębiorstwa z nową funkcjonalnością biznesową, której odbiorcą jest liczna rzesza klientów. Wspomniane usługi muszą charakeryzować się:

Dla programisty stającego przed zadaniem stworzenia takiej aplikacji powyższe wymagania mogą stanowić nie lada wyzwanie. Uwierzytelnianie i kontrola uprawnień użytkowników systemu, transakcyjność wykonywanych operacji, komunikacja między różnymi modułami systemu (często rozproszonymi), zarządzanie dostępem do trwałych archiwów danych - to tylko niektóre z mechanizmów, które należy zaimplementować. Ponieważ są to skomplikowane zadania programistyczne, a wraz rozwojem elektronicznego biznesu pojawiało się coraz większe zapotrzebowanie na aplikacje spełniające te wszystkie wymogi, powstała idea stworzenia czegoś, co teraz określa się terminem śródprogramu (ang. middleware).

Podejście to bazuje na pomyśle, żeby stworzyć warstwę oprogramowania rezydującą ponad systemem operacyjnym, odpowiedzialną za implementację zestawu mechanizmów, protokołów i interfejsów programistycznych, które są nieodzowne dla stworzenia zaawansowanego systemu informatycznego dla współczesnego przedsiębiorstwa prowadzącego działalność w Sieci.

Istnienie takiej warstwy umożliwiłoby twórcy systemu pracę na wyższym poziomie abstrakcji i skupienie się na oprogramowaniu logiki aplikacji, bez angażowania się w skomplikowane mechanizmy niskopoziomowe. Już na pierwszy rzut oka widać wynikające z tego korzyści:

Platforma J2EE firmy Sun Microsystems pozwala na zrealizowanie tych wszystkich założeń.

Ponieważ rozwinięcie akronimu (Java 2 Enterprise Edition) nieuchronnie nasuwa na myśl pytanie o związek J2EE z językiem Java, jeszcze przed opisem tej platformy zobaczmy, jak przebiegała ewolucja od Javy do J2EE.

  1. Pojawia się JDK; firma Sun jeszcze nie myśli o technologiach śródprogramowych.
  2. Java okazuje się dobrym jezykiem oprogramowania strony serwera systemów działających w architekturze klient-serwer; powstają usługi nazw, katalogowe, zapewniania transakcyjności, pojawia się pierwsza specyfikacja EJB; problem - specyfikacje są słabo skorelowane, jest wiele niespójności i dwuznacznosci; różne wersje interfejsów pojawiają się niezależnie, brak między nimi zgodności; brak referencyjnej implementacji interfejsów programistycznych (API).
  3. Nowa koncepcja Suna - podział na 3 platformy (uporządkowane od najmniejszej):

Co to jest platforma?

J2EE jest platformą dla złożonych, wielowarstowych, rozproszonych, wydajnych i skalowalnych aplikacji. Co to jednak znaczy platforma? J2EE to nie sprzęt komputerowy, ani żadne konkretne oprogramowanie. Jest to zbiór specyfikacji dotyczących powiązanych ze sobą technologii, które razem mają zapewnić dobrą realizację zadań wymienionych we wstępie. W szczególności wiele z nich określa wymagania odnośnie implementowanych interfejsów programistycznych. Rolę systemu zgodnego z J2EE można przedstawić w analogii do zadań systemu operacyjnego, który ma umożliwić procesom korzystanie z zasobów komputerowych i zarządzać ich działaniem w sposób wydajny i bezpieczny. System operacyjny odpowiada za stworzenie procesom abstrakcji sprzętu, natomiast oprogramowanie spełniające standardy J2EE pozwala programiście abstrahować od implementacji podstawowych usług, np. uwierzytelniania, komunikacji w rozproszonym środowisku, czy transakcyjności. Dzięki temu programista może skupić się wyłącznie na logice biznesowej tworzonego oprogramowania.

Fakt, że J2EE jest tylko zbiorem specyfikacji i nie narzuca żadnej konkretnej implementacji, prowadzi do otwartości systemów opartych na tej platformie i pozwala wybierać między różnymi dostawcami oprogramowania zgodnego z J2EE.


J2EE od wewnątrz

Za skrótem J2EE kryje się wielka liczba pojęć, technologii, wymagań, ograniczeń i narzędzi. W listopadzie 2003 ukazała się kocowa wersja Java 2 Platform Enterprise Edition Specification w wersji 1.4. Jednak J2EE to nie tylko specyfikacja komponentowego modelu aplikacji rozproszonej. Na J2EE składają się cztery elementy:

J2EE Platform Specyfikacja platformy
J2EE Compatibility Test Suite Zbiór testów umożliwiających weryfikację zgodności ze specyfikacją konkretnej implementacji J2EE
J2EE Reference Implementation Dostarczona przez twórcę specyfikacji, firmę Sun Microsystems, wzorcowa implementacja specyfikacji
J2EE Blueprints Zbiór wskazówek, preferowanych rozwiązań, wzorców projektowych wraz z propozycją konkretnego modelu rozproszonej, skalowalnej aplikacji

W dalszej części skupimy się na pierwszym z tych elementów.

Wielowarstwowość aplikacji

Aplikacje J2EE są logicznie podzielone na warstwy. Każda warstwa odpowiada za inny zakres funkcjonalności systemu i może zawierać wiele komponentów. Najczęściej pod terminem "wielowarstwowy" (ang. multi-tiered) rozumie się 3 warstwy. Granice między warstwami są oczywiście logiczne i mogą być ustanowione przez różne maszyny, procesy, bądź przedsiębiorstwa. Wspomniany model 3-warstwowy pasuje do wzorca MVC (Model, View, Controller), gdzie w kolejnych warstwach rezydują:

Warstwa prezentacji (View) Aplikacje w Javie, aplety, serwlety, strony JSP
Warstwa logiki biznesowej (Controller) Komponenty EJB
Warstwa danych (Model) Bazy danych, Enterprise Information Systems

Zaletą takiego podejścia jest możliwość podzielenia aplikacji na niezależne części, z których każda obejmuje oprogramowanie odpowiadające za konkretny fragment funkcjonalności całego systemu i może być rozwijana równolegle z pozostałymi. Żeby tworzone niezależnie komponenty oprogramowania chciały ze sobą współgrać, muszą między nimi istnieć dobrze zdefiniowane interfejsy, a to właśnie daje platforma J2EE.

wielowarstowa aplikacja

Komponentowy model programownia

Programowanie z wykorzystaniem komponentów realizuje dobrze znany sposób atakowania większych problemów określany jako dziel i rządź (łac. divide et impera). Komponent to kawałek kodu implementujący pewien zbiór interfejsów. Jest to fragment logiki programu, który sam nie stanowi aplikacji - nie może działać samodzielnie, a jest raczej 'klockiem', który można złożyć z innymi, aby powstała pełna aplikacja. Ideą stojącą za programowaniem komponentowym jest powtórne wykorzystanie kodu. Korzyści płynące z tworzenia aplikacji za pomocą komponentów to z pewnością:

Aby można było tworzyć oprogramowanie bazujące na komponentach potrzebne są:

Menedżer zasobów

Dostęp do zewnętrznych zasobów danych organizowany jest wokół koncepcji tzw. menedżerów zasobów (ang. resource manager), która jest uogólnieniem idei stojącej za JDBC, czy JNDI. Serwer aplikacyjny korzysta z usług odpowiedniego sterownika, który implementując odpowiedni protokół komunikacyjny, umożliwia dostęp do zasobów konkretnego systemu przechowywania i archiwizacji danych (EIS). Specyfikacja J2EE Connector Architecture 1.0 opisuje ten standard.

Podział na role

Specyfikacja J2EE zakłada ścisły podział ról w obrębie procesu tworzenia aplikacji, co jest naturalną konsekwencją przyjęcia wielowarstwowego modelu opartego na komponentach.

J2EE Product Provider Dostawca platformy programowej zgodnej ze specyfikacją J2EE
Application Component Provider Programista tworzący komponenty
Application Assembler Osoba odpowiedzialna za przygotowanie pliku EAR z dostarczonych komponentów
Deployer Osoba wdrażająca aplikację
Administrator Administrator aplikacji J2EE

Dlaczego w Javie?

Dlaczego to właśnie Java została wybrana jako język programowania aplikacji na platformę J2EE?

Najważniejsze technologie

W tym punkcie przedstawione będą technologie wykorzystywane w systemach zgodnych z J2EE, które realizują założenia opisane w punkcie J2EE od wewnątrz/Najważniejsze koncepcje.

Podział ogólny

Architektura J2EE opiera się na wielu technologiach, które można podzielić na 3 podstawowe kategorie:

  1. Technologie komponentowe
    Platforma J2EE wspiera następujące komponenty: aplikacje kliencke, applety, komponenty WWW (serwlety i strony JSP) oraz komponenty EJB.
    Ze względu na miejsce wykonania kodu komponentów można je podzielić na: Ze względu na charakter wykonywanych zadań można dokonać podziału na: Dla appletów oraz normalnych programów w Javie do wykonania potrzebna jest wirtualna maszyna Javy. W odróżnieniu od nich komponenty WWW i komponenty EJB potrzebują czegoś więcej. Środowiskiem pracy dla tych komponentów są kontenery, które oddzielają je od klientów, jak również od zewnętrznych zasobów. Tego rodzaju pośrednictwo jest niezbędne do umożliwienia wykonywania kontenerowi jego zadań, a więc zarządzania transakcjami, zewnętrznymi zasobami, cyklem życia poszczególnych komponentów, dostępem do systemu oraz autoryzacją jego użytkowników. Kontenery implementowane są jako niezależne podsystemy w serwerze aplikacji, który stanowi jądro systemu zgodnego z J2EE. Serwer aplikacji wykonuje ogromną liczbę różnych zadań, których celem jest realizacja wszystkich wymagań stawianych zaawansowanym aplikacjom sieciowym (niezawodność, odporność na błędy, transakcyjność, bezpieczeństwo, wielodostępność, wydajność, równoważenie obciążenia., itp.).
  2. Komunikacja
    Ponieważ aplikacje tworzone na platformę J2EE są zwykle rozproszone, muszą być dostarczone odpowiednie protokoły zapewniające komunikację między poszczególnymi elementami systemu:
  3. Usługi
    Ze względu na to, że aplikacje J2EE często muszą integrować wiele źródeł informacji (bazy danych, systemy typu ERP, CRM, inne aplikacje istniejące w firmie), serwer aplikacyjny musi oferować jednolity sposób dostępu do tych zasobów. Tego typu usługi definiuje specyfikacja J2EE Connector Architecture 1.0.

Interfejsy programowe

Aby aplikacje zbudowane w modelu J2EE mogły działać zgodnie z podanymi wytycznymi, potrzebnych jest wiele interfejsów programowych (API). Dostawca systemu zgodnego z J2EE zapewnia ich implementację, a twórca komponentów musi ich przestrzegać, co wiąże się także z pewnymi ograniczeniami, np. pisząc komponenty EJB nie można korzystać z bibliotek natywnych, tworzyć i synchronizować wątków, korzystać z dostępu do plików poprzez bibliotekę java.io, ani korzystać z obiektów klasy ServerSocket. Kilka z tych interfejsów występuje już w J2SE (Java 2 Platform Standard Edition).

Poniżej znajdują się krótkie opisy interfejsów, o których jest mowa w specyfikacjie J2EE 1.4.

Java IDL API Java IDL pozwala na tworzenie aplikacji obiektowych komunikujących się przez CORBA.
JDBC Core API JDBC jest protokołem dostępu do relacyjnych baz danych.
RMI-IIOP API Protokół RMI pozwala na komunikację międzyprocesową. RMI-IIOP jest jego przenośnym rozszerzeniem bazującym na protokole IIOP (Internet Inter-ORB Protocol), używanym przez aplikacje wykorzystujące standard CORBA.
JNDI API JNDI pozwala na zlokalizowanie komponentu lub innego zasobu w sieci.
JDBC 2.0 Extension Ten interfejs programistyczny zawiera wsparcie dla operacji na zbiorach krotek, nazywania połączeń z wykorzystaniem JNDI, zarządzania pulą połączeń i obsługi rozproszonych transakcji.
EJB Standard EJB definiuje sposób pisania komponentów strony serwera i ustanawia standardowy interfejs między komponentami i serwerem aplikacyjnym.
Servlets Specyfikacja Servlets 2.3 definiuje zasady programowania serwletów.
JSP Specyfikacja Java Server Pages określa zasady budowania komponentów WWW bazujących na osadzaniu kodu języka Java w dokumentach HTML.
JMS Java Messaging Service pozwala na asynchroniczną komunikację między rozproszonymi obiektami.
JTA Specyfikacje Java Transaction API i Java Transaction Service oferują komponentom niezawodne usługi transakcyjne.
JavaMail JavaMail pozwala na wysyłanie poczty elektronicznej z poziomu aplikacji napisanej w Javie w sposób niezależny od platformy oraz używanych protokołów dostarczania poczty. JavaMail jest interfejsem zależnym od JAF.
JAF Specyfikacja Java Beans Activation Framework określa zadania tego interfejsu jako: określanie typu dowolnych danych, hermetyzacja dostępu do danych, pobieranie zestawu operacji możliwych do wykonania na określonym typie danych.
JAXP Java API for XML Parsing obsługuje interfejsy SAX i DOM parserów XML, jak również wspiera obsługę procesorów transformacji XSLT.
Connector Ten interfejs pozwala na integrację aplikacji J2EE z różnymi systemami EIS.
JAAS Za pomocą Java Authentication and Authorization Service można przeprowadzić uwierzytelnianie użytkowników i kontrolować ich prawa dostępu do aplikacji. Wykorzystywany jest do tego mechanizm podobny do PAM (Pluggable Authentication Modules).

Intuicje odnośnie opisanych mechanizmów w architekturze J2EE dobrze wspomaga poniższy obrazek

mechanizmy

Schemat procesu tworzenia aplikacji na platformę J2EE

Aplikacje zgodne ze specyfikacją J2EE są odpowiednio pakowane do pliku typu EAR (Enterprise Archive). Plik taki ma dobrze określoną strukturę, a jego zawartość opisywana jest przez deskryptor pliku EAR. Pojedynczy plik EAR jest samodzielnym, zamkniętym pakietem, który stanowi kompletną aplikację gotową do uruchomienia na dowolnym systemie zgodnym z J2EE.
Plik EAR zwykle składa się z kilku modułów, które zawierają komponenty. Podobnie jak plik EAR jest opisany przez własny deskryptor (zwany deskryptorem aplikacji), tak zawartość każdego modułu jest opisana jego deskryptorem. Każdy moduł może dać się samodzielnie uruchomić, nie jest do tego potrzebny kontekst ani deskryptor aplikacji.

W typowym przypadku aplikacja J2EE składa się z następujących modułów:
Rozwój typowej aplikacji J2EE odbywa się według następującego schematu postępowania:
  1. Implementacja poszczególnych komponentów: serwletów, stron JSP, komponentów EJB.
  2. Spakowanie komponentów w odpowiednie moduły i utworzenie dla nich deskryptorów.
  3. Spakowanie modułów komponentowych do jednego pliku EAR i utworzenie dla niego deskryptora aplikacji, co razem daje kompletny program na platformę J2EE.
  4. Instalacja aplikacji w postaci pliku EAR w serwerze aplikacji.
  5. Uruchomienie aplikacji za pomocą narzędzia (deployment tool) dostarczonego przez producenta serwera aplikacji, na co składa się:
  6. Dopasowanie przez administratora systemu wszystkich parametrów aplikacji (polityka bezpieczeństwa, zachowanie transakcyjne systemu) do istniejącego środowiska IT.

Wszystkie wspomniane deskryptory zapisane są w odpowiednim dialekcie języka XML.

Oto przykładowy deskryptor aplikacji.

Widać na nim, że aplikacja składa się z jednego modułu WWW (petstoreadmin.war) oraz jednego modułu EJB (petstoreadminEjb.jar).


Istniejące implementacje


Aktualna wersja specyfikacji

Aktualna specyfikacja J2EE ma numer 1.5. Prace zaliczeniowe będziemy jednak budować w oparciu o starszą wersję J2EE 1.4 - większość obecnie prowadzonych projektów opartych jest o J2EE 1.4 lub 1.3.X. 


Kierunki rozwoju

Biorąc pod uwagę, że celem sformułowania specyfikacji J2EE jest stworzenie pełnego środowiska dla wykonywania rozproszonych aplikacji, widać, że jest jeszcze wiele do zrobienia. Autorzy specyfikacji wskazują aktualnie na następujące kierunki rozwoju:

Konkurencyjne rozwiązania

Rozwiązania konkurencyjne dla J2EE opracowywane są także przez firmę Microsoft. Na samym początku trzeba już jednak wskazać podstawową różnicę w podejściu Suna i Microsoftu do tego problemu. J2EE jest specyfikacją, czyli sformułowaniem zestawu warunków, które muszą być spełnione przez każdą implementację, podczas gdy Microsoft oferuje gotowe rozwiązania w postaci własnych aplikacji.

Propozycje Microsoftu to:

Oczywistą konsekwencją zdecydowania się na rozwiązanie Microsoftu jest automatyczna rezygnacja z możliwości wyboru między dostawcami elementów platformy.

Ze względu na brak praktycznego doświadczenia pozwalającego na dokonane porównania J2EE z Microsoft.Net pozwolę sobie zacytować kilka fragmentów z artykułu "J2EE vs. Microsoft .NET A comparison of building XML-based web services", Chad Vawter and Ed Roman June 2001.

"The shared vision between both J2EE and .NET is that there is an incredible amount of 'plumbing' that goes into building web services, such as XML interoperability, load-balancing, and transactions. Rather than writing all that plumbing yourself, you can write an application that runs within a container that provides those tricky services for you."

"Microsoft.NET offers language-independence and language-interoperability. This is one of the most intriguing and fundamental aspects of the .NET platform. A single .NET component can be written, for example, partially in VB.NET, the .NET version of Visual Basic, and C#, Microsoft's new object-oriented programming language."

"J2EE offers several features that accelerate time-to-market which are not found in .NET. For example, state management services enable developers to write less code and not worry about managing state, resulting in a higher degree of rapid application development."

"Microsoft.NET offers a variety of time-to-market features not found in J2EE as well. Most notably, ASP.NET is independent of client device, and allows for user interfaces to be rendered to alternative user interfaces without rewriting code. Microsoft also offers Queued Components which are superior to MessageDriven Beans. It should be noted here that Microsoft has tried to simplify server-side programming greatly by removing support for features found in traditional enterprise applications, such as stateful servers and simple transactions. If developers need to go outside this box, their code must be made to be non-managed and reside outside the .NET Framework rather than take advantage of it. Microsoft also provides business process management and E-Commerce capabilities, which are available in some J2EE implementations but not all."

"In conclusion, we feel the ability to achieve rapid application development offered by both J2EE and .NET is definitely not equal. It is, however, comparable."

".NET provides a fairly complete solution from a single vendor--Microsoft. This solution may lack some of the higher end features that J2EE solutions offer, but in general, the complete web services vision that Microsoft will be providing is equal in scope to that of a larger J2EE vendor."

"Arguments supporting both platforms:

Arguments for .NET and against J2EE:

Arguments for J2EE and against .NET

In conclusion, while both platforms will have their own market-share, we feel most customers will reap greater wins with J2EE. We feel the advantages outweigh those offered by Microsoft.NET. That is our preferred architecture, and we stand behind it."


Podsumowanie

Na pierwszym wykładzie przedstawiłem ogólny przegląd platformy J2EE, jej filozofię i składające się na nią technologie. Omówiłem też specyficzny sposób wytwarzania aplikacji WWW a w szczególności jego przebieg w wypadku oprogramowania na platformę J2EE. Porównałem ją też do konkurencyjnego rozwiązania zwanego .NET.

Referencyjna implementacja J2EE będzie używana przy opracowywaniu prac zaliczeniowych z tego przedmiotu.


Słownik

EAR (Enterprise ARchive)
Plik, który jest samodzielnym, zamkniętym pakietem stanowiącym kompletną aplikację gotową do uruchomienia na dowolnym systemie zgodnym z J2EE.
J2EE (Java 2 Enterprise Edition)
Pełna platforma do tworzenia zaawansowanych aplikacji działających na serwerze.
komponent
Kawałek kodu implementujący pewien zbiór interfejsów; fragment logiki programu, który sam nie stanowi aplikacji - nie może działać samodzielnie, a jest raczej 'klockiem', który można złożyć z innymi, aby powstała pełna aplikacja.
platforma
Zbiór specyfikacji dotyczących powiązanych ze sobą technologii, który pozwala programiście abstrahować od implementacji podstawowych usług, np. uwierzytelniania, komunikacji w rozproszonym środowisku, czy transakcyjności.
rola (wytwarzanie)
Zbiór przypisanych do osoby lub zespołu zadań wykonywanych w trakcie projektowania, wytwarzania i wdrażania aplikacji J2EE.
śródprogram (ang. middleware)
Warstwa oprogramowania rezydującą ponad systemem operacyjnym, odpowiedzialna za implementację zestawu mechanizmów, protokołów i interfejsów programistycznych, które są nieodzowne dla stworzenia zaawansowanego systemu informatycznego dla współczesnego przedsiębiorstwa prowadzącego działalność w Sieci.
wielowarstwowość aplikacji
Cecha aplikacji podzielonej na warstwy, z których każda odpowiada za inny zakres funkcjonalności systemu i może zawierać wiele komponentów.

Adresy w sieci

  1. J2EE Blueprints
  2. J2EE Frequently Asked Questions
  3. J2EE Glossary
  4. J2EE Tutorial
  5. Web Services and Java(TM) technology
  6. J2EE vs. Microsoft.Net

Zadanie

W trakcie tego przedmiotu będziemy pisać programy użytkowe na platformę J2EE. Na stronach Suna jest dostępna tzw. implementacja referencyjna J2EE (J2EE Reference Implementation). Można jej za darmo używać do celów niekomercyjnych. Będziemy korzystać z tej referencyjnej implementacji do pisania programów zaliczeniowych.

Pierwsze zadanie domowe polega na ściągnieciu pakietu J2SE SDK 1.5 (J2SE Software Development Kit) oraz jBoss, zainstalowaniu i uruchomieniu ich na jakimś komputerze, np. w domu.

To zadanie nie jest oceniane przez wykładowcę. Jego wykonanie jest ze swej natury warunkiem koniecznym zaliczenia.

Powodzenia!


Strona przygotowana przez Tomasza Pieciukiewicza.