Trwałość obiektów to trudny problem. Zazwyczaj zawierają one szeroki zbiór złożonych zależności z innymi obiektami przez dziedziczenie i polimorfizmy. Obiekty mogą też zawierać właściwości innych obiektów (przez dziedziczenie) lub inne obiekty (przez agregację). Ich trwałość jest immanentną właściwością większości serwerów aplikacyjnych, ale stosowane mechanizmy są na ogół unikatowe dla konkretnego produktu, powodując trudności w przenoszeniu aplikacji między różnymi serwerami. Specyfikacja EJB wymaga, aby serwery posługiwały się tymi samymi mechanizmami.

Jako składnicę obiektów często wykorzystuje się relacyjne bazy danych, ale wymaga to trudnego w implementacji odwzorowania obiektów na tabele bazy, nie przystosowanej do przechowywania złożonych obiektów. Prosty obiekt daje się łatwo odwzorować na jedną tabelę, ale obiekty dziedziczące właś-ciwości innych będą wymagać wielu połączonych tabel.

Obiektowe bazy danych (ObjectStore, Gemstone) zapewniają lepsze mechanizmy przechowywania obiektów, ale ich właściwości - zwłaszcza w obsłudze aplikacji wysoce transakcyjnych - nie są zadowalające. Ponadto większość firm ma już zainstalowane duże bazy relacyjne i nie będzie zainteresowana inną technologią przechowywania.

Beany sesji do obsługi stanu połączenia

Beany sesji nie zapewniają trwałości, ale umożliwiają obsługę stanu sesji połączeniowej z klientem. Jeden klient może posługiwać się wieloma beanami encji, natomiast jeden bean sesji obsługuje tylko jednego klienta. Beany sesji pozwalają na przechowywanie informacji o stanie połączenia z klientem: np. jakie metody zostały wywołane w czasie jednej jednostki pracy (transakcji). Stan sesji połączeniowej nie jest trwały i znika po zamknięciu aplikacji.

Beany sesji mogą być stanowe lub bezstanowe. Stanowe beany sesji zachowują informację o stanie połączenia jednego klienta i nie mogą być użyte przez innych klientów. Beany bezstanowe zapewniają lepszą skalowalność aplikacji, ponieważ pozwalają na wspólne wykorzystywanie przez wielu klientów określonej puli połączeń z bazą danych; klient korzysta ze wszystkich metod beanu sesji bez ograniczeń. W tym przypadku za przechowywanie informacji o stanie połączenia poszczególnych klientów odpowiada programista, który może posługiwać się np. popularnym mechanizmem plików czasowych (cookie).

Normalizacja rynku

Analitycy badający wpływ określonych technologii na ofertę rynkową oceniają, że specyfikacja EJB 1.1 i kolejne jej wersje przyczynią się do konsolidacji rynku serwerów aplikacyjnych. Znacznie wyższe wymagania, jakie EJB 1.1 stawia przed producentami serwerów, spowodują, że mniejsi twórcy znikną z rynku lub zostaną wykupieni przez dużych dostawców technologii, którzy mogą pozwolić sobie na duże inwestycje w badania i rozwój.

Zalecają oni również wybieranie do nowych opracowań takich serwerów aplikacyjnych, które przejdą testy zgodności Suna. Oczekuje się, że rozpowszechnienie specyfikacji będzie miało podobny efekt, jak wprowadzenie standardów SQL; serwery aplikacyjne będzie można wymieniać bez zmiany aplikacji.

Wyróżnikami serwerów aplikacyjnych staną się natomiast: wsparcie systemów operacyjnych, wydajność transakcyjna, obsługa awarii sprzętowych i przejmowanie obsługi klientów przez inny działający serwer (failover), łatwość w integracji z systemem zarządzania siecią/aplikacjami i inne cechy drugorzędne.