Wydaje się, że programiści tworzący duże aplikacje nie powinni zastanawiać się, czy już zacząć korzystać z technologii Java 2 Enterprise Edition, ale kiedy i w jaki sposób tego dokonać.

Specyfikację Enterprise Java Beans (EJB) można ocenić jako wstępną przymiarkę Suna do ustanowienia standardu tworzenia aplikacji korporacyjnych. Specyfikacja Java 2 Enterprise Edition (J2EE) już znacznie rozszerza i pogłębia możliwości modelu EJB, określając model architektoniczny dużych aplikacji pisanych w Javie. Architektura zdefiniowana przez J2EE jest bardziej realistyczna, elastyczniejsza i potężniejsza niż propozycja ograniczona wyłącznie do EJB. J2EE uznaje wielowarstwową naturę współczesnych programów i oferuje oddzielne modele programowe dla interfejsu użytkowego, logiki biznesowej i dostępu do baz danych.

Typowa aplikacja J2EE

Aplikacja J2EE składa się z części klienckiej w formie apletu lub programu HTML, wykonywanego przez przeglądarkę, części pośredniej zawierającej servlety lub Java Server Pages (JSP), współpracujące z beanami sesji (komponentami komunikacyjnymi EJB) oraz za ich pośrednictwem z beanami encji (komponentami EJB do zapamiętywania danych), korzystającymi z bazy danych.

Przebieg transakcji w aplikacji J2EE zaczyna się od apletu lub programu HTML. Większość logiki aplikacji jest wykonywana na serwerze; dotyczy to również interfejsu użytkowego klienckiej części aplikacji - zarządzania i formatowania stron HTML, odbieranych i wysyłanych do klienta. Logicznie jest to kliencka część aplikacji, chociaż fizycznie jest wykonywana przez serwer.

Istnieją dwa modele programistyczne wykonywania klienckiej części aplikacji w serwerze: z wykorzystaniem servletów lub JSP. Servlety to kompletne programy w Javie (zawierają funkcję main), pobierające adres URL i emitujące strony HTML lub XML. Jeżeli servlet dostarcza wynik działania w postaci XML, to może również działać niezależnie od klienta, pobierając komunikaty z innych programów i przesyłając im z powrotem wyniki. Wynik w formie HTML jest zawsze przesyłany bezpośrednio do klienta.

Server Pages to odpowiedź Suna na Active Server Pages Microsoftu. Są to niekompletnie zdefiniowane stronice HTML, zawierające polecenia (skrypty) Java, służące do skompletowania strony w czasie wykonywania programu. JSP są łatwiejsze do opracowania niż servlety; można je skompilować do postaci servletu. Obiektowy model programistyczny Java jest trudny pojęciowo i wymaga wiele pracy do pełnego opanowania jego możliwości. Servlety i JSP służą do przybliżenia Javy osobom, które nie mają dużego doświadczenia w programowaniu.

Sun stale rozszerza właściwości funkcjonalne servletów. Przewiduje się nawet, że firma wyposaży je w możliwość definiowania transakcji. Biorąc pod uwagę, że servlety pozwalają na dostęp do bazy danych (są kompletnymi programami, można więc w nie wbudować wszystko, co wymyśli programista), istnieje możliwość stworzenia aplikacji zawierającej całą logikę aplikacji w servletach. Trzeba jednak pamiętać, że jest to model aplikacji monolitycznej, mało elastycznej, trudnej w modyfikowaniu i dystrybucji.

Obsługa logiki aplikacji

Aplikacja wielowarstwowa zgodna z modelem J2EE wymaga posługiwania się komponentami EJB do opracowywania logiki aplikacji i dostępu do baz danych. EJB to rozbudowany model komponentowy, dopasowany do tworzenia rozwiązań architektonicznych opartych na wykorzystaniu m.in. usług systemowych, kontenera komponentów, serwera aplikacyjnego. Komponenty EJB są niezależne od klienta i nie mogą być używane do tworzenia interfejsu użytkowego. Usługi komponentu EJB wywołuje się więc z programu obsługującego interfejs użytkowy, innego komponentu EJB lub z Internetu za pośrednictwem protokołów IIOP (Internet Inter-ORB Protocol) lub RMI (Remote Method Invocation).

Istnieją dwa typy komponentów EJB: beany sesji i beany encji. Beany sesji są przeznaczone do zarządzania stanem sesji połączeniowej z klientem lub transakcji. Gdy sesja się kończy, bean sesji zwalania wszystkie zasoby związane z jej stanem i może być usunięty z pamięci komputera. Większość logiki zaimplementowanej w beanie sesji dotyczy przebiegu sesji połączeniowej oraz interpretacji i formatowania danych. Bean sesji może zachowywać stan między kolejnymi wywołaniami od klienta (stanowy bean sesji) lub nie - odrzuca stan po zakończeniu wywołania (bezstanowy bean sesji). Bean bezstanowy jest bardziej efektywny w wykorzystaniu zasobów komputera, gdyż może być używany przez wielu klientów, ale za obsługę stanu sesji klienta odpowiada programista.

Beany encji reprezentują encję - dane lub obiekt. Typowy stan beanu encji odpowiada zawartości jednego lub kilku rekordów w bazie danych. Bean encji zachowuje stan trwale, zajmując przez dłuższy czas zasoby komputera. W beany encji zwykle wbudowuje się logikę współpracy z bazą danych.

Istnieją dwa sposoby przechowywania (zapewnienia trwałości) informacji w beanie encji. Trwałość informacji (persistence) może być zapewniana bezpośrednio przez bean encji. Programista musi do takiego beanu explicite wstawić polecenia SQL do współpracy z bazą danych. Gdy trwałość informacji jest zarządzana przez kontener, w którym bean działa, nie są potrzebne bezpośrednie odwołania do bazy. Tu trwały stan beanu jest automatycznie pobierany i zachowywany w bazie danych przez logikę kontenera komponentów (zwykle jest to serwer aplikacyjny).

Beany encji z trwałością zarządzaną przez kontener występują w dwóch odmianach. W pierwszej każda zmiana stanu beanu encji wywołuje odpowiednią operację w bazie danych, przechowującej dane na dysku. W drugiej uaktualnia się zawartość beanów rezydujących cały czas w pamięci. Takie beany to ścisły odpowiednik klasycznych obiektów z kompletną enkapsulacją danych. Żadna aplikacja nie wpływa bezpośrednio na rekordy w bazie danych.

Realizacja takiej obsługi beanów to trudny problem dla twórcy serwera aplikacyjnego. Musi on zajmować się tym, czym zazwyczaj zajmuje się system zarządzania bazami danych: jednoczesnym dostępem do danych, integralnością, efektywnością realizowania zapytań itp. W efekcie wymaga to korzystania z pewnej formy bazy danych, rezydującej w całości w pamięci, stanowiącej swoisty bufor między bazą dyskową a beanami encji. Obecnie nie jest dostępny żaden serwer aplikacyjny realizujący w taki sposób trwałość danych.

Jaka aplikacja Java?

Java 2 Enterprise Edition i EJB będą odgrywać coraz większą rolę przy tworzeniu aplikacji skalowalnych, elastycznych, łatwych w utrzymaniu i modyfikowaniu. Z powodu trudności w progra- mowaniu lub ograniczonych możliwości zakupu odpowiednich komponentów obecnie wiele aplikacji Java jest opracowywanych w formie monolitycznej lub quasi-monolitycznej, przy wykorzystaniu jedynie JSP lub servletów, z wbudowaną w nie mało elastyczną logiką dostępu do bazy danych.

Jeżeli jednak zamierzamy opracować sensowne ramy architektoniczne tworzonych w firmie aplikacji oraz wielokrotnie wykorzystać raz stworzone komponenty, powinniśmy projektować nowoczesne aplikacje zgodnie z wymaganiami J2EE, posługując się beanami EJB, zarządzanymi przez komercyjne serwery aplikacyjne.