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.

Transakcje zarządzane przez Bean-a (Bean-Managed Transaction)

Dla niektórych bean-ów typu enterprise, deklaratywne usługi typu CMT (Container Managed Transaction) mogą nie dostarczać wymaganej granulacji. Przykładowo, klient może chcieć wywołać kilka metod na bean-ie sesyjnym bez commit-owania wykonanych przez nie działań po ich zakończeniu. W tym przypadku klient ma do wyboru dwie opcje: może albo utworzyć instancję własnej transakcji JTA (lub resource-local), albo może zwrócić się do bean-a sesyjnego w celu wyeksponowania metod do obsługi transakcji, które klient może sam wywołać by kontrolować zakres transakcji.

W celu obsługi postawionych wyżej wymagań, EJB oferuje bean-om sesyjnym wygodny sposób obsługi ich zdarzeń związanych z zakresem transakcji. By wyłączyć usługi CMT, w bean-ach sesyjnych należy użyć adnotacji @TransactionManagement(TransactionManagementType.BEAN) lub umieścić odpowiadające temu metadane dla bean-a sesyjnego w pliku ejb-jar.xml.
Dla transakcji typu BMT, kontener EJB w dalszym ciągu dostarcza wsparcia transakcyjnego dla bean-a. Główną różnicą jest to, że bean wykonuje konkretne wywołania w celu rozpoczęcia, commit-owania i rollback-owania transakcji w miejsce użycia atrybutów CMT do deklaratywnego przypisania zachowania transakcyjnego swoim metodom. Także, kontener nie propaguje transakcji rozpoczętych przez klienta do bean-ów, które wybrały własną kontrolę zakresu transakcji. Pomimo, że każdy bean enterprise musi mieć określony taki czy inny plan (CMT czy BMT) dla swoich metod, obydwa typy bean-ów mogą współdziałać ze sobą wewnątrz pojedynczego kontekstu transakcji.

Zarządzanie ryzykiem

STRATEGIE

Główne strategie zarządzania ryzykiem to:
1. Transfer ryzyka na innych
2. Zapobieganie ryzyku
3. Redukcja negatywnych skutków ryzyka
4. Akceptacja wybranych lub wszystkich konsekwencji szczególnego ryzyka

Każde prawdopodobne ryzyko powinno mieć sformułowany plan działania z jego możliwymi konsekwencjami.

PROCES

Określenie kontekstu:
w skład tego wchodzi zrozumienie aktualnych uwarunkowań, w których działa organizacja z punktu widzenia wewnętrznego, zewnętrznego oraz w kontekście zarządzania ryzykiem.

Identyfikacja ryzyk:
w skład tego wchodzi udokumentowanie z materialnego punktu widzenia osiągnięć organizacji, jej celów oraz reprezentacji obszarów, które organizacja może wykorzystać do uzyskania konkurencyjnej przewagi.

Analiza/Szacowanie ryzyk:
w skład tego wchodzi skalowanie oraz jeżeli to możliwe utworzenie prawdopodobieństwa dystrybucji przychodów ze względu na każde ryzyko materialne.

Integracja ryzyk:
w skład tego wchodzi agregacja wszystkich dystrybucji ryzyk, odzwierciedlenie korelacji oraz efektów związanych z portfelem, sformułowanie rezultatów w terminach mających wpływ na kluczowe metryki z punktu widzenia wydajności organizacji.

Pobranie/Priorytetyzacja ryzyk:
w skład tego wchodzi określenie wkładu każdego z ryzyk na zagregowany profil ryzyka oraz odpowiednia priorytetyzacja.

Testowanie/Eksploatacja ryzyk:
wypracowanie strategii kontroli i wykorzystania różnych ryzyk.

Monitorowanie i przegląd:
ciągłe pomiary oraz monitorowanie środowiska ryzyka oraz wydajności strategii zarządzania ryzykiem.

Transakcyjny i rozszerzony kontekst persystencji

JPA (Java Persistence Architecture), która jest częścią specyfikacji EJB 3.0, służy uproszczeniu tworzenia aplikacji EJB wykorzystujących persystencję danych. Podstawowym uproszczeniem wprowadzonym przez EJB 3.0 było wprowadzenie interfejsu EntityManager w celu dostępu do elementów bazy danych oraz tworzenia, usuwania lub aktualizacji encji w transakcji. Encje są obiektami, które reprezentują dane w bazie. Są one persystentne w takim sensie, że pozostają nawet po zakończeniu działania aplikacji, która je utworzyła. W celu wsparcia persystencji encji zarządca encji (entity manager) współdziała z kontekstem persystencji (persistence context), który definiowany jest przez Java Persistence Architecture jako:

Zestaw instancji encji zarządzanych (managed), w którym dla jakiegokolwiek identyfikatora encji występuje unikalna instancja encji. Wewnątrz kontekstu persystencji, instancje encji oraz ich cykl życia są zarządzane przez zarządce encji (entity manager).

Java Persistence Architecture określa również, że container-managed persistence context, który jest kontekstem persystencji, którego cykl życia jest zarządzany automatycznie przez kontener, może być zdefiniowany tak by miał albo cykl życia który jest ograniczony to pojedynczej transakcji albo rozszerzony cykl życia który rozpięty jest na wiele transakcji. Zakres cyklu życia zależy od typu określonego w klasie PersistenceContextType w trakcie tworzenia zarządcy encji (entity manager).

W przypadku, gdy container-managed persistence context jest ograniczony do pojedynczej transakcji, kontekst persystencji kończy się wraz z zatwierdzeniem lub wycofywaniem (commit & rollback) skojarzonej transakcji przez Java Transaction API. Dla porównania container-managed persistence context, który ma rozszerzony cykl życia zaczyna się, gdy jest tworzony stanowy bean sesyjny i kończy się wyłącznie, gdy w/w bean jest usuwany z kontenera. Przyjmuje się, że rozszerzony kontekst persystencji (extended persistence context) skojarzony jest ze stanowym beanem sesyjnym. Należy zwrócić uwagę, że jedynie stanowe beany sesyjne mogą posiadać rozszerzonego zarządcę persystencji zarządzanego przez kontener (container-managed, extended entity manager).

Jedną z istotnych różnic pomiędzy kontekstem persystencji ograniczonym do transakcji (transaction-scoped) i rozszerzonym kontekstem persystencji jest stan encji po zakończeniu transakcji. W przypadku transakcyjnego kontekstu persystencji encje zostają odłączone (detached), to jest, nie są dłużej zarządzane, natomiast w przypadku rozszerzonego kontekstu persystencji encje pozostają zarządzane (mamaged). Innymi słowy część operacji związanych z modyfikacją (persist(), merge(), remove()) może być wykonanych poza transakcją i są one kolejkowane i zatwierdzane (komitowane) gdy kontekst persystencji jest kojarzony (attached) z transakcją (i kiedy są zatwierdzane przez commit). Część operacji nie może być wykonana poza transakcją i są to operacje flush(), lock() oraz zapytania typu update/delete.

Wyżej wymienione zagadnienia powodują, że rozszerzony kontekst persystencji jest idealnym rozwiązaniem dla modelowania konwersacji z użytkownikiem, który rozciąga się na wiele interakcji. Podobne zachowanie można osiągnąć używając transakcji zarządzanej przez bean-a (bean-managed transaction), która rozciąga się na całą konwersację użytkownika. W tym przypadku transakcja rozpoczynana jest poprzez użycie metody UserTransaction.begin(). Jednakże to alternatywne podejście jest bardziej skomplikowane niż wykorzystanie rozszerzonego kontekstu persystencji.

Domyślnym typem kontekstu persystencji jest kontekst transakcyjny. W celu wstrzyknięcia EntityManager'a z wyspecyfikowanym rozszerzonym kontekstem persystencji, należy wyspecyfikować dyrektywę wstrzyknięcia w następujący sposób (lub zdefiniować element persistence-context-ref w deskryptorze XML):

@PersistenceContext(type = PersistenceContextType.EXTENDED)
private EnterpriseManager emgr;

SCJP - prawda i mity

W ostatnim czasie wykonałem podejście zakończone sukcesem do egzaminu "Sun Certified Java Programmer" dla wersji Java 6.0. Wiele wcześniej czytałem na różnych blogach na temat samego egzaminu i sposobów na jego zdanie. Z wszystkimi, którzy przymierzają się do podejścia do tego egzaminu chciałbym podzielić się moimi wrażeniami i doświadczeniami.

Wielu pisze na blogach, że do podejścia do egzaminu trzeba się długo przygotowywać conajmniej 1,5 miesiąca. To moim zdaniem jest mit. Ja przygotowywałem się do niego stricte 3 dni i to wystarczyło na 84% :) Zapytacie jak to jest możliwe ? Otóż pomimo tego, że egzamin jest trudny to doświadczenie w pisaniu aplikacji w języku Java jest nieocenione i jest podstawą do podejścia w tak krótkim czasie. Jednak samo doświadczenie niestety nie wystarczy choć, gdy ktoś będzie zadowolony z uzyskania wyniku w okolicach 65% to może się udać. Co warto zrobić oprócz doświadczenia, to zapoznać się z moim zdaniem bardzo dobrą książką "SCJP Sun Certified Programmer for Java 6 Study Guide (CX-310-065): Exam 310-065" oraz wykonać serię testów na symulatorze. Ja korzystałem z symulatora JQ+.

Do podejścia należy zapoznać się dokładnie z zawartością książki o której pisałem wcześniej, następnie wykonać testy zawarte w tej książce, wykonać jak największą ilość testów z JQ+, a na samym końcu w dniu egzaminu lub w przeddzień wykonać final test z symulatora JQ+.

Na co zwrócić szczególną uwagę:
1. wątki i co będzie się pojawiać na ekranie przy działaniu wielu wątków. W tym zwrócić należy uwagę na to co jest pewne w takim zrzucie na konsolę np. poprawna kolejność elementów wyrzuconych na konsolę.
2. garbage collector i co jest a co nie jest dostępne do czyszczenia po serii wykonanych linii kodu
3. Kolekcje a w szczególności Generics i obsługa Enum-ów
4. Sprawdzanie kodu składniowo przed zabraniem się za analizę czyli ręczny debugging :)
5. Zapoznanie się się z API w szczególności metody i klasy umożliwiające dostęp do plików, Regular Expression i API dla klasy Console.

Warto podejść do egzaminu jeżeli ma się doświadczenie w pisaniu kodu Java, a to dlatego, że pozwala to na zapoznanie się z elementami języka o których nawet programując ponad 5 lat można nie wiedzieć a także pozwala na systematyzację wiedzy na temat składni języka.