Przewodnik dla początkujących do Enterprise JavaBeans

Enterprise JavaBeans (EJB) wzbudziło wiele emocji od czasu ogłoszenia w marcu 1998 r. Specyfikacji Enterprise JavaBeans w wersji 1.0. Firmy takie jak Oracle, Borland, Tandem, Symantec, Sybase i Visigenic, między innymi, ogłosiły i / lub dostarczyły produkty zgodne ze specyfikacją EJB. W tym miesiącu przyjrzymy się wysokopoziomowo, czym dokładnie są Enterprise JavaBeans. Omówimy, czym różni się EJB od oryginalnego modelu komponentów JavaBeans i omówimy, dlaczego EJB wzbudził tak ogromne zainteresowanie.

Ale najpierw porada: w tym miesiącu nie będziemy zajmować się kodem źródłowym ani tematami instruktażowymi. Ten artykuł nie jest samouczkiem; jest to raczej przegląd architektury. EJB obejmuje wiele obszarów i bez uprzedniego zrozumienia podstawowych pojęć, fragmenty kodu i sztuczki programistyczne są bez znaczenia. Jeśli czytelnicy JavaWorld będą zainteresowani , w przyszłych artykułach mogą zostać omówione szczegóły wykorzystania Enterprise JavaBeans API do tworzenia własnych Enterprise JavaBeans.

Aby zrozumieć, dlaczego EJB jest tak atrakcyjny dla programistów, potrzebujemy trochę tła historycznego. Najpierw przyjrzymy się historii systemów klient / serwer oraz aktualnemu stanowi rzeczy. Następnie omówimy różne części systemu EJB: komponenty EJB - które znajdują się w kontenerze EJB działającym wewnątrz serwera EJB - oraz obiekty EJB, których klient używa jako swego rodzaju „zdalne sterowanie” komponentami EJB . Pójdziemy nad dwoma rodzajami EJB: sesyjne i podmiot obiektów. Przeczytasz także o domu i zdalnyminterfejsy, które odpowiednio tworzą instancje EJB i zapewniają dostęp do metod biznesowych EJB. Pod koniec artykułu dowiesz się, jak można zbudować rozszerzalne serwery za pomocą Enterprise JavaBeans. Ale najpierw spójrz w przeszłość.

Historia klienta / serwera

Historia starożytna

Na początku był to komputer typu mainframe. I było dobrze. (A przynajmniej tak dobre, jak się udało). Stan techniki w przetwarzaniu informacji w latach 60. składał się głównie z dużych, drogich maszyn używanych przez duże organizacje do wspierania ich codziennych operacji biznesowych. Minikomputery i współdzielenie czasu w latach 70. zwiększyły dostępność mocy obliczeniowej, ale informacje i przetwarzanie były nadal scentralizowane na poszczególnych maszynach. Pierwsze komputery osobiste w latach 80. szybko zaśmiecały korporacyjny krajobraz tysiącami małych wysepek informacji, z których wszystkie niestrudzenie generowały raporty o różnej jakości, tracąc krytyczne dane w przypadku awarii i szybko stawały się niezgodne ze sobą.

Klient / serwer na ratunek

Architektura klient / serwer jest jednym z najczęstszych rozwiązań problemu, w jaki sposób radzić sobie z potrzebą zarówno scentralizowanej kontroli danych, jak i powszechnej dostępności danych. W systemach klient / serwer informacje są utrzymywane w sposób względnie scentralizowany (lub podzielone na partycje i / lub replikowane między serwerami rozproszonymi), co ułatwia kontrolę i spójność danych, jednocześnie zapewniając dostęp do danych potrzebnych użytkownikom.

Systemy klient-serwer są obecnie zwykle złożone z różnych poziomów. Standardowy stary system mainframe lub system współdzielenia czasu, w którym interfejs użytkownika działa na tym samym komputerze, co baza danych i aplikacje biznesowe, jest nazywany pojedynczą warstwą. Takie systemy są stosunkowo łatwe w zarządzaniu, a spójność danych jest prosta, ponieważ dane są przechowywane tylko w jednym miejscu. Niestety, systemy jednopoziomowe mają ograniczoną skalowalność i są podatne na zagrożenia związane z dostępnością (awaria jednego komputera powoduje awarię całej firmy), szczególnie w przypadku komunikacji.

Pierwsze systemy klient / serwer były dwuwarstwowe, w których interfejs użytkownika działał na kliencie, a baza danych znajdowała się na serwerze. Takie systemy są nadal powszechne. Jeden serwer dwuwarstwowy typu ogrodowego wykonuje większość logiki biznesowej na kliencie, aktualizując udostępnione dane przez wysyłanie strumieni SQL do serwera. Jest to elastyczne rozwiązanie, ponieważ konwersacja klient / serwer odbywa się na poziomie języka bazy danych serwera. W takim systemie odpowiednio zaprojektowanego klienta można modyfikować tak, aby odzwierciedlał nowe reguły i warunki biznesowe bez modyfikowania serwera, o ile serwer ma dostęp do schematu bazy danych (tabele, widoki itp.) Potrzebnego do wykonywania transakcji. Serwer w takim systemie dwupoziomowym nazywany jest serwerem bazy danych, jak pokazano poniżej.

Serwery baz danych mają jednak pewne zobowiązania. Często SQL dla określonej funkcji biznesowej (na przykład dodawania pozycji do zamówienia) jest identyczny, z wyjątkiem aktualizowanych lub wstawianych danych, od wywołania do wywołania. W końcu serwer bazy danych analizuje i ponownie analizuje prawie identyczny kod SQL dla każdej funkcji biznesowej. Na przykład wszystkie instrukcje SQL dotyczące dodawania towaru do zamówienia będą prawdopodobnie bardzo podobne, podobnie jak instrukcje SQL służące do wyszukiwania klienta w bazie danych. Czas potrzebny na to analizowanie byłby lepiej spędzony na faktycznym przetwarzaniu danych. (Istnieją rozwiązania tego problemu, w tym pamięci podręczne analizy składniowej SQL i procedury składowane). Innym problemem, który się pojawia, jest jednoczesne przechowywanie wersji klientów i bazy danych: wszystkie maszyny muszą zostać wyłączone w celu aktualizacji,a klienci lub serwery opóźnione w wersji oprogramowania zazwyczaj nie nadają się do użytku, dopóki nie zostaną uaktualnione.

Serwery aplikacji

Serwer aplikacji architektura (patrz następne zdjęcie) jest popularną alternatywą dla architektury serwera bazy danych, ponieważ rozwiązuje niektóre problemy z serwerami baz danych mają.

Środowisko serwera bazy danych zwykle wykonuje metody biznesowe na kliencie i używa serwera głównie do utrwalania i wymuszania integralności danych. Na serwerze aplikacji metody biznesowe działają na serwerze, a klient żąda, aby serwer wykonał te metody. W tym scenariuszu klient i serwer zazwyczaj będą używać protokołu, który reprezentuje konwersację na poziomie transakcji biznesowych, a nie na poziomie tabel i wierszy. Takie serwery aplikacji często działają lepiej niż ich odpowiedniki w bazach danych, ale nadal mają problemy z wersjonowaniem.

Zarówno bazy danych, jak i systemy aplikacji można ulepszyć, dodając dodatkowe warstwy do architektury. Tak zwane systemy trójwarstwowe umieszczają komponent pośredni między klientem a serwerem. Cała branża - oprogramowanie pośredniczące - pojawiła się, aby sprostać zobowiązaniom systemów dwupoziomowych. Monitora przetwarzania transakcji,jeden typ oprogramowania pośredniego, odbiera strumienie żądań od wielu klientów i może równoważyć obciążenie między wieloma serwerami, zapewniać przełączanie awaryjne w przypadku awarii serwera i zarządzać transakcjami w imieniu klienta. Inne rodzaje oprogramowania pośredniego zapewniają translację protokołów komunikacyjnych, konsolidują żądania i odpowiedzi między klientami i wieloma heterogenicznymi serwerami (jest to szczególnie popularne w przypadku obsługi starszych systemów w reengineeringu procesów biznesowych) i / lub zapewniają pomiary usług i informacje o ruchu w sieci.

Wiele warstw zapewnia elastyczność i współdziałanie, które zaowocowały systemami oferującymi więcej niż te trzy warstwy usług. Na przykład systemy n-warstwowe są uogólnieniem systemów trójwarstwowych, przy czym każda warstwa oprogramowania zapewnia inny poziom usług niż warstwy powyżej i poniżej. Perspektywa n-warstw traktuje sieć jako pulę usług rozproszonych, a nie tylko sposób na dostęp klienta do pojedynczego serwera.

W miarę jak języki i techniki zorientowane obiektowo stały się modne, systemy klient / serwer coraz częściej przechodzą w kierunku zorientowania obiektowego. CORBA (Common Object Request Broker Architecture) to architektura, która umożliwia obiektom w aplikacjach - nawet obiektom napisanym w różnych językach - uruchamianie na oddzielnych maszynach, w zależności od potrzeb danej aplikacji. Aplikacje napisane lata temu można spakować jako usługi CORBA i współdziałać z nowymi systemami. Enterprise JavaBeans, który został zaprojektowany tak, aby był kompatybilny z CORBA, to kolejny wpis w zorientowany obiektowo pierścień aplikacja-serwer.

Celem tego artykułu nie jest dostarczenie samouczka dotyczącego systemów klient / serwer, ale konieczne było przedstawienie pewnych informacji w celu zdefiniowania kontekstu. Przyjrzyjmy się teraz, co ma do zaoferowania EJB.

Enterprise JavaBeans i rozszerzalne serwery aplikacji

Teraz, gdy przyjrzeliśmy się nieco historii i zrozumieliśmy, czym są serwery aplikacji, spójrzmy na Enterprise JavaBeans i zobaczmy, co oferuje w tym kontekście.

Podstawową ideą Enterprise JavaBeans jest zapewnienie struktury dla komponentów, które mogą być „podłączone” do serwera, rozszerzając tym samym jego funkcjonalność. Enterprise JavaBeans jest podobny do oryginalnego JavaBeans tylko w tym, że wykorzystuje kilka podobnych koncepcji. Technologia EJB nie jest regulowana przez specyfikację komponentów JavaBeans, ale przez zupełnie inną (i ogromną) specyfikację Enterprise JavaBeans. (Zobacz Zasoby, aby uzyskać szczegółowe informacje na temat tej specyfikacji.) Specyfikacja EJB odwołuje się do różnych graczy w systemie klient / serwer EJB, opisuje, w jaki sposób EJB współpracuje z klientem i istniejącymi systemami, precyzuje zgodność EJB z CORBA i definiuje odpowiedzialność za różne komponenty systemu.

Cele Enterprise JavaBeans

EJB Spec stara się spełniać kilka celów naraz:

  • EJB został zaprojektowany, aby ułatwić programistom tworzenie aplikacji, uwalniając ich od niskopoziomowych szczegółów systemowych związanych z zarządzaniem transakcjami, wątkami, równoważeniem obciążenia i tak dalej. Twórcy aplikacji mogą skoncentrować się na logice biznesowej i pozostawić szczegóły zarządzania przetwarzaniem danych szkieletowi. Jednak w przypadku wyspecjalizowanych aplikacji zawsze można wejść „pod maskę” i dostosować te usługi niższego poziomu.

  • EJB Spec określa główne struktury ramach EJB, a następnie szczegółowo określa umowy pomiędzy nimi. Obowiązki klienta, serwera i poszczególnych komponentów są jasno określone. (Za chwilę przejdziemy do tego, czym są te struktury). Programista tworzący komponent Enterprise JavaBean ma zupełnie inną rolę niż ktoś, kto tworzy serwer zgodny z EJB, a specyfikacja opisuje obowiązki każdego z nich.

  • EJB ma być standardowym sposobem budowania aplikacji klient / serwer w języku Java. Tak jak można łączyć oryginalne komponenty JavaBeans (lub komponenty Delphi lub cokolwiek innego) od różnych dostawców w celu utworzenia niestandardowego klienta, tak komponenty serwera EJB od różnych dostawców można łączyć w celu utworzenia niestandardowego serwera. Komponenty EJB, będące klasami Java, będą oczywiście działać na każdym serwerze zgodnym z EJB bez ponownej kompilacji. Jest to korzyść, której nie mogą zaoferować rozwiązania specyficzne dla platformy.

  • Wreszcie, EJB jest kompatybilny z innymi interfejsami API języka Java i korzysta z nich, może współpracować z aplikacjami innymi niż Java i jest zgodny z CORBA.

Jak działa system klient / serwer EJB

Aby zrozumieć, jak działa system klient / serwer EJB, musimy zrozumieć podstawowe części systemu EJB: komponent EJB, kontener EJB i obiekt EJB.

Komponent Enterprise JavaBeans

Komponent Enterprise JavaBean jest komponentem, podobnie jak tradycyjna JavaBean. Elementy Enterprise JavaBeans są wykonywane w kontenerze EJB, który z kolei jest wykonywany na serwerze EJB. Dowolny serwer, który może obsługiwać kontener EJB i zapewniać mu niezbędne usługi, może być serwerem EJB. (Oznacza to, że wiele istniejących serwerów można rozszerzyć tak, aby były serwerami EJB, aw rzeczywistości wielu dostawców to osiągnęło lub ogłosiło taki zamiar).

Komponent EJB to typ klasy EJB, który najprawdopodobniej będzie uznawany za „Enterprise JavaBean”. Jest to klasa Java napisana przez programistę EJB, która implementuje logikę biznesową. Wszystkie inne klasy w systemie EJB obsługują dostęp klientów do klas komponentów EJB lub świadczą usługi (takie jak utrwalanie itd.).

Kontener Enterprise JavaBeans

Kontener EJB to miejsce, w którym „żyje” komponent EJB. Kontener EJB zapewnia usługi, takie jak zarządzanie transakcjami i zasobami, wersjonowanie, skalowalność, mobilność, trwałość i bezpieczeństwo dla zawartych w nim komponentów EJB. Ponieważ kontener EJB obsługuje wszystkie te funkcje, twórca komponentu EJB może skoncentrować się na regułach biznesowych i pozostawić obsługę bazy danych i inne drobne szczegóły kontenerowi. Na przykład, jeśli pojedynczy komponent EJB zdecyduje, że bieżąca transakcja powinna zostać przerwana, po prostu informuje swój kontener (w sposób zdefiniowany w specyfikacji EJB, a kontener jest odpowiedzialny za wykonanie wszystkich wycofań lub zrobienie wszystkiego, co konieczne, aby anulować transakcja w toku. W jednym kontenerze EJB zazwyczaj istnieje wiele instancji komponentu EJB.

Obiekt EJB i zdalny interfejs

Programy klienckie wykonują metody na zdalnych komponentach EJB za pośrednictwem obiektu EJB. Obiekt EJB implementuje „zdalny interfejs” komponentu EJB na serwerze. Interfejs zdalny reprezentuje metody „biznesowe” komponentu EJB. Zdalny interfejs wykonuje rzeczywistą, użyteczną pracę obiektu EJB, taką jak tworzenie formularza zamówienia lub kierowanie pacjenta do specjalisty. Poniżej omówimy bardziej szczegółowo interfejs zdalny.