Aplikacje J2EE składają się z dobrze zdefiniowanych komponentów, z których część może występować po stronie serwera (komponenty EJB¹, JSP, Servlety) a cześć po stronie klienta (klienckie części aplikacji, aplety, Jave Beans) oraz zasobów.

Istnieją trzy rodzaje komponentów EJB: ziarenka encji (ang. entity beans), ziarenka sesji (ang. session beans), ziarenka komunikatów (ang. message driven beans). Komponent EJB egzystuje w pojemniku, który dostarcza różnych usług, takich jak np. trwałość. Istnieją cztery rodzaje pojemników:

Trwałość może być obsługiwana zarówno przez pojemnik (CMP), jak i przez ziarenko (BMP). Pierwszy rodzaj trwałości nie wymaga pisania zapytań w SQL'u przez programistów komponentów.

Platforma J2EE dobrze integruje się z innymi systemami, co jest bardzo istotne w procesie informatyzacji firm, szczególnie dużych. Umożliwia ono "dobudowanie" internetowej części do już istniejących systemów informatycznych. Taka otwartość jest bardzo ważna, gdyż rzadko informatyzuje się cały biznes od początku.

W hipotetycznej aplikacji można wyróżnić następujące warstwy:

-warstwa klienta (ang. Client tier)

-serwera aplikacji

-logika prezentacji (JSP i Servletey)

-logika biznesowa (EJB)

-warstwa tylna, którą stanowią źródła danych, istniejące aplikacje itp.

Aplikacja kliencka może komunikować z sesyjnym EJB lub przy pomocy protokołu HTTP z serwletem.

Rozwiązanie biznesowe może się składać się z wielu aplikacji. Każda nich składa się z modułów. Ważną częścią każdego z nich jest opis rozmieszczenia (ang. Deployment descriptor). W skład modułu wchodzą komponenty, klasy pomocnicze i zasoby.

Poniżej podano zbiór API występujący w wersji 1.3 J2EE (za [J2EE1.3Spec]):

Warto pamiętać, iż [J2ee1.3Spec] specyfikacja J2EE zapewnia minimalny zestaw udogodnień; konkretne produkty oferują zazwyczaj większy ich repertuar.

Poniżej w telegraficznym skrócie podano pewne informacje na temat technologii J2EE. Jest ona sama w sobie dość rozbudowana; podręcznik do platformy w wersji 1.3 ma około 500 stron a do wersji 1.4 trzy razy więcej. Oczywiście na innym poziomie technologię tą znać musi firma, która implementuje platformę a na innym firma, która jej "tylko" używa tworząc aplikacje dla klientów. Choć J2EE składa się z wielu API to wydaje się, że podstawowe znaczenie ma technologia EJB, która zostanie poniżej pokrótce omówiona (potwierdza to [ACM2003]).

W obrębie technologii EJB wyróżnia się trzy rodzaje beanów:

-ziarenka sesji (ang. Session beans)

-ziarenka encji (ang. Entity beans)

-ziarenka komunikatów (ang. Message beans)

Można powiedzieć, iż EJB sesji wykonuje zadania na rzecz klienta i reprezentuje go w obrębie serwera aplikacji. Warto dodać, iż sesyjne EJB mogą być stanowe jak i bezstanowe. Komponenty stanowe zachowują informacje o swym stanie pomiędzy wywołaniami metod. Aplikacja klienta może być zarówno typu gruby klient (ang. Thick client) jak i cienki klient (ang. Thin client).

Gdyby dokonać analizy ilościowej wielu różnych nie trywialnych aplikacji stworzonych przez programistów “od podstaw” to można dojść do wniosku, iż bardzo znaczną część ich kodu źródłowego realizuje niespecyficzną dla danego systemu funkcjonalność. Jest to np. zapewnienie trwałości, komunikacja z użytkownikiem, zarządzanie zasobami itp. Zastosowanie serwerów aplikacji ma z założenia odciążyć programistów i projektantów tak, aby w swojej pracy mogli się oni skupić na tym co charakterystyczne dla ich rozwiązania. Z użyciem technologii takiej, jak J2EE nie pisze się aplikacji od podstaw, gdyż znaczną część funkcji realizuje lub może realizować serwer aplikacji. Powoduje to jednak, iż wytwarzanie aplikacji odbywa się inaczej. Ważne jest zastosowanie odpowiednich wzorców projektowych. Mniej jest miejsca na dowolność. Bardzo ważną rolę w procesie wytwarzania aplikacji J2EE odgrywa umieszczenie komponentów aplikacji w pojemnikach czyli deployement. Sposób obsługi komponentu lub modułu przez serwer jest określany deklaratywnie przy pomocy deskryptora rozmieszczenia (ang. Deployment descriptor).

Patrząc od strony programistycznej Klasa będąca EJB musi implantować pewne interfejsy, których używa klient. Interfejs Remote zawiera metody wywoływane przez klienta. Interfejs Home służy do stworzenia komponentu. Alternatywnie komponenty implementują interfejsy Local i LocalHome służą one odpowiednio to komunikacji lokalnej (tzn. z innymi bytami wykonywanymi w obrębie tej samej maszyny wirtualnej co dany komponent) i stworzenia komponentu.