Komponenty EJB (Enterprise Java Beans) s? programowalnymi komponentami umieszczanymi na serwerze aplikacji i zarz?dzanymi przez kontener EJB. Komponenty te odpowiadaj? za logikę aplikacji udostępniaj?c zasadnicze jej funkcjonalno?ci dla innych warstw aplikacji lub zupełnie na zewn?trz zdalnym klientom. W uproszczeniu s? to klasy JAVA, w których okre?lili?my, że pewne kluczowe ich metody mog? być wywoływane zdalnie. Ważn? cech? ze względu na bezpieczeństwo jest tu to, że możliwo?ć wywołania konkretnej metody nie oznacza, że strona wywołuj?ca zna jej implementacje. Dla strony wywołuj?cej znana jest tylko nazwa metody, argumenty metody i warto?ć zwracana. Cała implementacja znajduje sie na serwerze i jest dla strony wywołuj?cej nieznana. Komponenty EJB można uznać za pewnego rodzaju usługi rezyduj?ce na serwerze. Z punktu widzenia programisty komponenty te upraszczaj? proces tworzenia aplikacji. Dla przykładu w przypadku aplikacji bankowej takim ewentualnym komponentem EJB może być komponent zwracaj?cy informacje o kliencie. W takim przypadku możemy taki komponent napisać raz i umie?cić na serwerze aplikacji, a następnie jego funkcjonalno?ć wykorzystywać w innych aplikacjach danego banku. Dodatkowo, przy takim rozwi?zaniu, maj?c dostęp już do istniej?cego EJB, programista nie musi się martwić o logikę aplikacji i dostęp do informacji zwracanych przez konkretny komponent EJB (to wykonywane jest w kontenerze EJB), tylko o zaprezentowanie pobranych danych klientowi.<br><br> W przypadku aplikacji wykorzystuj?cej t? technologię istnieje łatwo?ć ich skalowania. Kiedy zwiększy się ilo?ć użytkowników korzystaj?cych z aplikacji i wyst?pi? problemy z wydajno?ci? istnieje możliwo?ć zainstalowania komponentów EJB na dodatkowych maszynach co spowoduje rozłożenia obci?żenia. Dodatkowo ze względu na przeniesienie implementacji na serwer aplikacje klienckie s? "odchudzone" i mog? być wywoływane z urz?dzeń o ograniczonych zasobach sprzętowych. Kontener EJB dostarcza mechanizmów transakcyjnych. Oznacza to, że w przypadku aplikacji, które wymuszaj? integracje danych mamy możliwo?ć okre?lenia poziomu izolacji danej metody EJB. Oznacza to, że w ramach jednego komponentu EJB możemy nadawać para użytkownikom do konkretnych jego metod, a nie tylko do samego komponentu. Maj?c taki przykładowy bankowy komponent EJB możemy jego metodę odpowiadaj?c? za otwarcie kredytu udostępnić zwykłemu pracownikowi, natomiast zabronić mu możliwo?ci wykonania metody odpowiadaj?cej za przyznawanie kredytu tego samego komponentu.<br><br> Ważne jest tu też to, że je?li mamy konkretny komponent EJB, nie oznacza to, że mamy zdalnie dostęp do wszystkich jego metod. To, które metody udostępniamy jako zdalne, a które nie okre?lamy na etapie projektowania, a następnie implementacji aplikacji.  Komponent do wykonania swoich zdalnych metod może potrzebować wywołać inn? pomocnicz? metodę tego komponentu, która jest potrzebna do poprawnego jego działania, ale wcale nie musi być udostępniana na zewn?trz.<br><br> Deskryptor EJB
Deskryptor EJB, to specjalny plik XML, zawieraj?cy informacje o komponentach EJB. W pliku tym zapisywane s? odwzorowania pół komponentu EJB na kolumny bazodanowe, relacje pomiędzy nimi. Zawiera on informacje o bazie danych będ?cej repozytorium dla komponentów. Dodatkowo zawiera on zapytania w języku EJB QL wyszukuj?ce komponenty EJB wg zadanego kryterium. <br><br> Rozróżniamy następuj?ce zasadnicze typy komponentów EJB:<br><br> Session
Entity
Message-Driven