Transakcje zarządzane przez kontener (Container-Managed Transaction)

EJB3 dostarcza wbudowane usługi do zarządzania transakcjami, które są domyślnie dostępne w bean-ach sesyjnych oraz bean-ach typu MDB (Message Driven Bean). Kontener wytycza granice transakcji oraz automatycznie rozpoczyna i zatwierdza (commit) transakcje w oparciu o deklaratywne metadane dostarczone przez twórcę bean-a.

W przypadku, gdy jakiś EJB deklaruje w metadanych swoje zachowanie jako transakcyjne, kontener ingeruje w wywołania metod bean-a i wprowadza zachowanie transakcyjne w obrębie metod bean-a sesyjnego. Może zostać wyspecyfikowany dla każdej metody jeden stały zestaw opcji. Domyślnym zachowaniem dostarczanym przez kontener jest weryfikacja, bezpośrednio przed wywołaniem metody, czy kontekst transakcyjny jest skojarzony z bieżącym wątkiem. Jeżeli wyżej wymieniony kontekst nie jest dostępny, kontener rozpoczyna nową transakcję bezpośrednio przed wywołaniem metody. Jeżeli natomiast, kontekst transakcyjny jest dostępny, kontener propaguje bieżącą transakcję w wywołaniu metody a także dopuszcza jej dostępność w kodzie metody. Następnie, po powrocie z wywołania metody, kontener wykonuje następną weryfikację. W wyniku ponownej weryfikacji, jeżeli kontener był odpowiedzialny za utworzenie nowego kontekstu transakcyjnego, automatycznie zatwierdza transakcję po wyjściu z metody (lub gdy wyrzucony został wyjątek przez metodę, odwraca (rollbak) transakcję którą rozpoczął). W przypadku, gdy kontener nie był twórcą transakcji, pozwala na kontynuowanie transakcji bez jej naruszania. Poprzez ingerencję w wywołania metod bean-a, kontener EJB ma możliwość wprowadzenia zachowania transakcyjnego w runtime-mie, na bazie tego co zostało wyspecyfikowane deklaratywnie w trakcie tworzenia (developmentu).

Domyślne zachowanie opisane wyżej jest określane poprzez specyfikację atrybutu transakcji na REQUIRED. Developer ma możliwość określenia atrybutu transakcji oprócz wyżej wymienionego, na sześć różnych sposobów:

• MANDATORY – transakcja jest konieczna; błąd, gdy nie ma bieżącej transakcji podczas wywołania metody


• REQUIRED – transakcja jest wymagana; gdy nie ma bieżącej transakcji tworzona jest automatycznie nowa


• REQUIRES_NEW – wymagana nowa transakcja; nawet gdy podczas wywołania jest bieżąca transakcja jest ona usypiana i tworzona jest zupełnie nowa na rzecz wywołania metody


• SUPPORTS – transakcja może być ale nie musi


• NOT_SUPPORTED – transakcja nie jest wspierana; gdy istnieje bieżąca transakcja jest usypiana, a wywołanie odbywa się bez kontekstu transakcyjnego


• NEVER – transakcja jest niedopuszczalna; gdy istnieje bieżąca transakcja zostaje zwrócony błąd

Wszystkie sześć atrybutów jest typowo dostępne dla metod bean-a sesyjnego, tym niemniej pewne atrybuty nie są dostępne w metodzie będącej timeout callback-iem, lub gdy bean sesyjny implementuje interfejs javax.ejb.SessionSynchronization. W bean-ach typu MDB dostępne są jedynie atrybuty REQUIRED oraz NOT_SUPPORTED.

Kluczowe terminy z dziedziny SOA

Usługa (service) reprezentuje powtarzalne zadanie biznesowe. Usługi używane są w celu enkapsulacji jednostek funkcjonalnych aplikacji poprzez dostarczenie interfejsu, który jest dobrze zdefiniowany i niezależny od implementacji. Usługi mogą być wywoływane (consumed) przez inne usługi lub aplikacje klienckie.

Orientacja na usługi (service orientation) definiuje metodę integracji aplikacji i procesów biznesowych jako połączonych usług.

SOA (Service-oriented architecture) ma różne znaczenie dla różnych osób w zależności od roli osoby oraz kontekstu (biznesowy, architekturalny, implementacyjny, operacyjny). Z biznesowego punktu widzenia, SOA definiuje zestaw usług biznesowych skomponowanych, by zapewnić projekt biznesowy, który korporacja chce wyeksponować wewnętrznie jak również dla swoich klientów i partnerów. Z punktu widzenia architektury SOA jest stylem architektonicznym, który wspiera orientację na usługi. Na poziomie implementacji, SOA jest realizowane przy użyciu infrastruktury, modelu programistycznrgo oraz technologii opartych na standardach takich jak Webservices. Z punktu widzenia operacyjnego SOA zawiera zestaw uzgodnień pomiędzy konsumentami usług oraz dostawcami, które określają jakość usług jak również specyfikację metryk IT oraz kluczowych elementów biznesu.

Aplikacja kompozytowa (composite application) jest zestawem skojarzonych oraz zintegrowanych usług, które wspierają procesy biznesowe zrealizowane w oparciu o SOA.

SOA może być zdefiniowane jako sterowane przez biznes podejście architektoniczne IT, które wspiera integrację określonego biznesu jako połączonych, powtarzalnych zadań biznesowych lub usług.


SOA governance jest pojęciem odnoszącym się do ustanawiania polityk, procedur i procesów, które są wymagane by zapewnić efektywne i wydajne podejmowanie decyzji w ramach organizacji.

SOA governance jest rozszerzeniem IT governance, które skupia się na cyklu życia usług oraz aplikacji kompozytowych w organizacyjnym SOA. Funkcje SOA governance to:
- określenie praw decyzyjnych dla developmentu, wdrożenia oraz zarządzania nowymi usługami,
- monitorowanie oraz raportowanie decyzji w celu przedstawienia rezultatu zarządzania
SOA governance dostarcza prawa decyzyjne, procesy oraz zasady w odniesieniu do tych aktywności.