22 lipca 2008

Enterprise JavaBeans (EJB) w skrócie

Dostałem ostatnio pytanie, które bardzo mnie zaskoczyło. Zawsze parłem do przodu z tymi wszystkimi technologicznymi wodotryskami, a tu proszę pytanie o podstawy, które mimo swej prostoty trudno było mi początkowo zebrać w strawną treść:

Studiuje sobie technologie ejb, tak jak mowiles zebym zaczal od tego. Ale gdybys mogl mi wytlumaczyc po co sa te cale ziarenka. Do czego sluza jakie maja zastosowanie gdzie ich sie uzywa i do czego ale nie teoretycznie tylko praktycznie. Wiem na czym to wszystko mniej wiecej polega ale nie rozumiem gdzie dokladnie tego uzywac i jakie to ma najczestsze zastosowanie. Pytanie banalne ale jednakze wpisywalem w google i w wiekszosci przypadkow odpowiedz byla taka ze ejb uzywa sie w aplikacjach biznesowych dzieki ejb programista moze budowac aplikacje jak z buduje sie cos z kockow lego. Ok ale do czego dokladnie. Wytlumacz mi o co to wielkie halo z ejb serwletami. Bylbym wdzieczny gdybys mi to wytlumaczyl jak przyslowiowej krowie na miedzy.

I jak tu podejść do tematu? Najlepiej wskazałbym na kilka pozycji książkowych i oczekiwałbym zapoznania się z nimi. Niektórzy preferują również praktyczne podejście do tematu i po kilku przykładach mają pewne zdanie na temat technologii. Tylko, że źle dobrane przykłady mogą całkowicie położyć technologię i można ją całkowicie zaprzepaścić. Wielokrotnie przysłuchuję się różnym rozmowom technicznym i z wielkim niepokojem wyczuwam próbę przepchnięcia tematu z własnego podwórka bez próby zrozumienia innego spojrzenia. Ilu z nas korzysta ze Springa+Hibernate, a gdyby zapytać dlaczego, zapewne padłaby odpowiedź, bo dobre (bo przecież jak inaczej wielu z nas używałoby tego zestawu?!). Pytania o szczegóły, albo alternatywne rozwiązania zazwyczaj kończą się machnięciem ramionami i końcem przyjemnej rozmowy.

Wracając do tematu Enterprise JavaBeans (w skrócie EJB). Po co nam EJB? Przede wszystkim, aby uprościć budowanie aplikacji rozproszonych z użyciem usług dostarczanych przez kontener EJB (= środowisko uruchomieniowe dla ziaren EJB), jak transakcje, utrwalanie danych, bezpieczeństwo, obsługa wyjątków, budzik, asynchroniczna obsługa komunikatów i Web Services. Wykorzystanie usług zwykle odbywa się deklaratywnie, gdzie za pomocą adnotacji lub deskryptora wdrożenia ejb-jar.xml deklarujemy nasze wymagania odnośnie wykorzystania usług w określony sposób. Właśnie możliwość wykorzystania bardzo zaawansowanych technologicznie usług deklaratywnie powoduje, że EJB znajdują swoje miejsce w architekturach aplikacji korporacyjnych. Bez tej specyfikacji wykorzystanie usług byłoby nieprzenośne i wymagające poznania mechanizmów specyficznych dla danego środowiska (= serwera aplikacyjnego), co wiązałoby się z niezwykle wysokimi kosztami rozwoju i utrzymania aplikacji. Wyobraźmy sobie sytuację, w której osoba znająca się na produkcie X dostarczającym wybrane usługi miałaby przesiąść się na produkt Y. Każdorazowe poznawanie nowych produktów jest bardzo kosztowne, a specyfikacje znacząco je obniżają.

Jakkolwiek czasy EJB 2.1 mamy za sobą, to właśnie bolączki z nią związane dały się odczuć wielu, co pchnęło Roda ze SpringSource do stworzenia Spring Framework. Wiele z rozwiązań springowych znalazły swoje miejsce w EJB 3.0 - obecnie ostatniej produkcyjnie wersji specyfikacji EJB.

Wyróżniamy cztery rodzaje ziaren EJB:
  • ziarna sesyjne (ang. session beans), w których można wyróżnić:
    • bezstanowe ziarna sesyjne (ang. stateless session beans, w skrócie SLSB) reprezentujące agentów w aplikacji korporacyjnej, bez utrzymywania stanu ostatnich użyć, np. Sklepikarz
    • stanowe ziarna sesyjne (ang. stateful session beans, w skrócie SFSB) różniące się od SLSB utrzymywaniem stanu między wywołaniami, co czyni jest idealnymi do modelowania bytów trzymających zapis operacji, np. Koszyk, do którego wkładamy towary
  • ziarna komunikacyjne (ziarna sterowane komunikatami, ang. message-driven beans, w skrócie MDB) umożliwiające obsługę komunikacji asynchronicznej, bez nakładania na klienta oczekiwania zakończenia ich pracy, np. DziennikZdarzen
  • encje (ang. entities) modelujące byty trwałe zapisywane do relacyjnej bazy danych, np. Osoba
A teraz pora na przykład wprowadzający w tematykę EJB3. Przyjrzyjmy się klasie pl.jaceklaskowski.ejb3.Sklepikarz (nazwa przypadkowa):
 package pl.jaceklaskowski.ejb3;

interface Sklepikarz {
public void otworzSklep();
}

public class SklepikarzWykwalifikowany implements Sklepikarz {

public void otworzSklep() {
// wykonaj swoją pracę
}

}
Z punktu widzenia programisty Javy nie jest to żadna nadzwyczajna klasa. Ot klasa jak wiele innych. Gdybyśmy zechcieli skorzystać z usług monitora transakcyjnego, zarządcy utrwalania, bezpieczeństwa - innymi słowy wszystkich tych usług dostępnych w kontenerze EJB musielibyśmy poznać pewien zestaw interfejsów i klas, i rozpocząć programowanie. Nie wspominam już nic o rozproszeniu aplikacji, gdzie chcielibyśmy rozlokować klasę na wielu serwerach i udostępnić je jako całość dla aplikacji klienckich. Nie ma co ukrywać - jest to wiele pracy. Z EJB3 sprawa sprowadza się do zadeklarowania klasy jako ziarno EJB odpowiednią adnotacją i temat dostępności wspomnianych usług mamy obsłużony.
 package pl.jaceklaskowski.ejb3;

import javax.ejb.Stateless;

interface Sklepikarz {
public void otworzSklep();
}

@Stateless
public class SklepikarzWykwalifikowany implements Sklepikarz {

public void otworzSklep() {
// wykonaj swoją pracę
}

}
Po udekorowaniu klasy adnotacją @Stateless staje się ona ziarnem EJB, a dokładniej SLSB. Znaczenie adnotacji rozpoznaje jedynie serwer aplikacyjny Java EE 5, więc wciąż jest to zwykła klasa, a dopiero środowisko serwera aplikacji nadaje jej specjalnego znaczenia jako ziarno EJB. Tym razem zwykła klasa jest już niezwykła, gdyż serwer aplikacji dla każdej metody publicznej przypisuje kontekst transakcyjny, bezpieczeństwo (wszystko mają domyślnie prawo wykonania metody), a pewne wyjątki wycofują transakcję automatycznie, podczas gdy inne niekoniecznie. Za wszystko odpowiada serwer aplikacyjny i stąd jego znaczenie w architekturach korporacyjnych korzystających z Korporacyjnej 5-tki (= Java EE 5). Wiele z trudności programistycznych serwer aplikacyjny zdejmuje z nas za pomocą m.in. specyfikacji EJB3. Dodając do tego inne specyfikacje budowania obiektowych aplikacji korporacyjnych mamy zestaw komponentów (= "klocki Lego"), za pomocą których możemy zbudować aplikację korporacyjną. Ot cała magia EJB3 i w ogóle Korporacyjnej 5-tki.

A gdzie znaleźć więcej informacji o EJB3? Zacząłbym od dostępnego za darmo streszczenia specyfikacji EJB3 - JSR 220: Enterprise JavaBeansTM,Version 3.0 EJB 3.0 Simplified API. Czyta się ją nadzwyczaj przyjemnie. Dodatkowo książka Billa Burke & Richarda Monsona-Haefela - Enterprise JavaBeans 3.0 z O'Reilly będzie wartościowym uzupełnieniem. Warto również rozważyć przejrzenie tematu EJB3 w Java EE Tutorial. Po tym zestawie już będzie wiadomo, czego potrzeba więcej. Aby urozmaicić lekturę, można popróbować się z EJB3 w akcji - polecam Eclipse + Geronimo lub NetBeans + GlassFish. Oba warte rozważenia dla początkujących. Część materiału przedstawiłem w swoich streszczeniach specyfikacji EJB3 w Notatniku w kategorii EJB3 oraz artykułach na moim Wiki. Miłego mielenia ziaren EJB3!

4 komentarze:

  1. Bardzo wyczerpująca odpowiedź ale i tak chyba nieco zbyt złożona w stosunku pytania Twojego czytelnika. Więc jeśli pozwolisz Jacku to też odpowiem na to pytanie:


    Drogi Czytelniku jlaskowski.blogspot.com :)

    Wyobraź sobie, że piszesz jakiś system informatyczny np: (a niech będzie!)sklep internetowy. Oprócz samej logiki działania tegoż sklepu (tzn. wkładania do koszyka, składania zamówienia czy płatności) musisz również zadbać o szereg innych aspektów takich jak:
    1. przechowywanie danych w bazie danych
    2. dbanie o spójność tych danych
    3. bezpieczeństwo Twojego portalu
    4. dostęp wielu użytkowników (toż to sklep przecież!)
    5. a jeśli sklep jest potężny i działa na wielu serwerach to i o rozproszenie
    6. sprawdzanie poprawności danych wpisywanych przez użytkowników
    7. i kilka jeszcze bardziej szczegółowych

    Zauważ, że wymienione aspekty są BARDZO potrzebne, aczkolwiek nie należą one stricte do funkcjonalności Twojego sklepu. Masz więc następujące wyjścia: albo piszesz to wszystko samemu albo skorzystasz z czegoś gotowego. Pierwsze podejście raczej odradzam...
    W przypadku drugiego znów masz dwa wyjścia: albo poszukasz bibliotek które zatroszczą się o każdy z tych aspektów albo też znajdziesz coś co zbiera to wszystko do, że się wyrażę, kupy.

    Jeśli chodzi o Javę spójne i ustandaryzowane rozwiązanie zapewnia specyfikacja JEE. Jest to specyfikacja która troszczy się o wszystkie wymienione aspekty będące "dookoła" aplikacji.

    Jak się troszczy zapytasz? Np. programujesz funkcjonalność dodawania do koszyka. Zatem powstaje klasa CartManager, która ma metody umożliwiające pracę z koszykiem. JEE definiuje coś takiego jak kontener EJB. Jest to pojemnik, w którym musisz umieścić Twoją klasę CartManager. Po umieszczeniu w kontenerze klasa staję się ziarnem EJB i od tego momentu kontener zapewnia wsparcie w w/w obszarach niezbędnych każdej aplikacji.

    Zatem po co jest EJB? Po to abyś mógł zająć się zasadniczą funkcjonalnością Twojej aplikacji a resztę miał już gotową do użycia.

    Jak jej użyć? Jak już wcześniej wspomniano dowiesz się z tego bloga:)

    Pozdrawiam,
    Michał Bartyzel

    PS. Życzę ciekawej przygody z JEE:)

    OdpowiedzUsuń
  2. Nic dodać, nic ująć. Bardzo dobrze przedstawiłeś temat EJB3. Pora na uaktualnienie Enterprise JavaBeans na polskiej Wikipedii. Piszesz się?

    OdpowiedzUsuń
  3. Wiem, że różnica jest subtelna, ale te 7 punktów, które wymienia Michał nie są wyjaśnieniem po co EJB, ani po co JEE, tylko po co infrastruktura aplikacyjna (middleware) w ogóle jest potrzebna. JEE do middleware'u dodaje zestaw uzgodnionych przez społeczność Java interfejsów programistycznych (Java EE API), tak, aby używanie tego middleware'u w Java było łatwiejsze (w tym tworzone oprogramowanie dla JEE bardziej przenośne między infrastrukturą różnych dostawców). W tym wszystkim, EJB stanowi JEDEN z WIELU modeli programistycznych dla JEE.
    Niektóre elementy EJB są udane (JPA, message-driven beans), inne (stateless/stateful beans) - mało udane i z powodu przestarzałości delikatnie mówiąc dzisiaj już zanikające pod względem istotności (co oczywiście w żaden sposób nie przekłada się na zanik istotności J2EE/JEE, czy samego middleware'u).
    W każdym razie na pewno nie należy utożsamiać pojęć infrastruktura aplikacyjna/JEE i EJB.

    Pozdrawiam,
    Waldek Kot

    PS
    Oczywiście, blog Jacka jest absolutnie godny polecenia :-)

    OdpowiedzUsuń
  4. Bardzo, ale to bardzo dobry artykuł. Ten sam problem miałem, żęby w kilku zdaniach ogół opisać. Dziekuję i Pozdrawiam

    OdpowiedzUsuń