Separation of Concerns - separacja zagadnień

Separation of Concerns jest procesem podziału programu komputerowego na odrębne cechy (moduły), które pokrywają się wzajemnie z punktu widzenia funkcjonalnego tak mało jak to tylko możliwe.

Mianem Concern (zagadnienie) określany jest pojedynczy element zainteresowania lub skupienia w programie. Typowo, zagadnienia są synonimami dla cech / właściwości lub zachowań.

Separacja pozwala między innymi na:
- indywidualną pracę w izolacji grupy ludzi nad kawałkami systemu,
- ułatwienie reużywalności,
- zapewnienie obsługiwalności systemu,
- dodawanie nowych właściwości w prosty sposób,
- zapewnienie każdemu lepszego zrozumienia systemu.

SoC nie jest przypisana jedynie do warstwy architektonicznej, często stosowana jest również do wielu innych zagadnień, takich jak:
- obiekt który reprezentuje zagadnienie z punktu widzenia języka,
- SOA może separować zagadnienia w usługi, wydzielając w ten sposób zachowanie jako zagadnienie w logiczne jednostki itd.

Zasada Separation of Concerns stanowi, że elementy systemu powinny mieć rozłączne i osobliwe (jednostkowe) zastosowanie. Inaczej mówiąc, żaden z elementów nie powinien współdzielić odpowiedzialności z innym elementem. Separację zagadnień można osiągnąć poprzez wytyczenie granic, gdzie granicą określamy logiczne lub fizyczne ograniczenie, które wytycza określony zestaw odpowiedzialności. Proces osiągania separacji zagadnień (SoC) zawiera podział zestawu odpowiedzialności, gdzie celem nie jest redukcja systemu na poszczególne części, a organizacja systemu w elementy niepowtarzalnych zestawów spójnych odpowiedzialności.

Celem SoC jest osiągnięcie dobrze zorganizowanego systemu, gdzie każda jego część pełni znaczącą i intuicyjną rolę przy maksymalizacji jej zdolności do adaptacji do zmian.


"Make everything as simple as possible, but not simpler."
Albert Einstein

Jak encje zostają skojarzone z kontekstem transakcji

Kontekst persystencji encji JPA jest zasobem, który jest skojarzony z transakcją. Tym sposobem, kontekst persystencji jest propagowany w ramach wywołania metod tak, że encje w jednostce persystencji (persistence unit) widzą swoje stany pośrednie, w ramach ich wspólnego kontekstu persystencji, gdy są one skojarzone z tym samym kontekstem transakcji. Również, ograniczenie polegające na tym, że jedynie jeden kontekst persystencji dla danej jednostki persystencji musi być skojarzony z określonym kontekstem transakcji zapewnia, że dla jakiejkolwiek encji typu T z identyfikatorem I, jej stan będzie reprezentowany przez jedynie jeden kontekst persystencji wewnątrz danego kontekstu transakcji.
Wewnątrz pojedynczego wątku aplikacji w danym momencie jest dostępny jedynie jeden kontekst transakcji. Serwer EJB jest uprawniony do tego by odłączyć pojedynczy kontekst persystencji od tego wątku i skojarzyć nowy kontekst persystencji z tą samą jednostką persystencji by zapewnić ograniczenia izolacji transakcji. Gdy serwer EJB wykona to, nowo utworzony kontekst persystencji nie jest w stanie zobaczyć zmian pośrednich wykonanych na encjach skojarzonych z uśpionym (suspended) kontekstem perystencji.

Eclipse + Tomcat + JAX-WS

Nadszedł czas by napisać Webservice JAX-WS przy użyciu środowiska Eclipse Helios, który uruchomiony mógłby zostać na serwerze Tomcat. Poniżej podam przepis, który krok po kroku opisuje w jaki sposób można to wykonać. Więc do roboty.

1. Ściągnij sobie APACHE-CXF
2. Rozpakuj w lokalizacji c:\apache-cxf
3. Podepnij APACHE-CXF do Eclipsa Window -> Preferences

4. Skonfiguruj serwer Tomcat w Eclipsie - patrz poniżej



5. Utwórz nowy projekt File -> New -> Dynamic Web Project



6.Utwórzmy sobie prostą klasę Webservice-u:

package pl.masl;

public class TestWebService {
  public void testMethod(String param) {
    System.out.println("TEST: " + param);
  }
}

7. Kliknij prawym na klasie i utwórz Webservice

8. Jako "Webservice runtime" wybierz "Apache CXF 2.x"

9. Po naciśnięciu Next zaznacz pole wyboru Use a Service Endpoint Interface
10. Wybierz Create an SEI
11. Wpisz w odpowiednie pole nazwę interfejsu pl.masl.ITestWebService oraz zaznacz pole wyboru obok testWebservice()
12. Kliknij Next, a następnie wybierz pola wyboru w kolumnach @WebMethod i @WebParam. Poniżej jest podgląd na generowany kod interfejsu.
13.Kliknij Next i zaznacz wszystkie pola wyboru na następnej planszy oraz zakończ przez Finish

Strategie mapowania dzidziczenia w EJB3.0

W ramach specyfikacji EJB3 możliwe są trzy strategie mapowania dziedziczenia:
1. SINGLE_TABLE - jedna tabela, która zawiera wszystkie pola z wszystkich klas w hierarchii
2. JOINED - tabela na każdą klasę w hierarchii. Tabele dla podklas zawierają jedynie te pola, które są specyficzne dla danej klasy.
3. TABLE_PER_CLASS - tabela na każdą konkretną klasę (nie abstrakcyjną), gdzie każda tabela zawiera wszystkie pola zdefiniowane w super-klasie. Strategia ta jest opcjonalna w specyfikacji EJB3.0.

Cykl życia encji

Stany charakteryzujące instancję encji:
• NEW - instancja encji nie ma identyfikatora perystencji i nie jest skojarzona z kontekstem persystencji
• MANAGED - instancja encji ma identyfikator persystencji i jest skojarzona z bieżącym kontekstem persystencji
• DETACHED - instancja encji ma identyfikator persystencji i nie jest skojarzona z kontekstem persystencji
• REMOVED - instancja encji ma identyfikator persystencji i jest skojarzona z kontekstem persystencji i dodatkowo jest zaplanowana do usunięcia z bazy danych.

Efekty operacji związanych z cyklem życia encji opisano poniżej.
1. Perystencja instancji encji - nowa instancja encji staje się zarządzana (managed) oraz persystentna (peristent) poprzez wywołanie metody persist na niej lub w wyniku kaskadowej operacji persystencji.

Znaczenie operacji persist:
• gdy encja jest w stanie NEW staje się zarządzana (MANAGED). Encja zostanie zapisana w bazie w trakcie komita transakcji lub jako rezultat wykonania flush.
• gdy encja jest w stanie MANAGED jest ignorowana w trakcie operacji.
• gdy encja jest w stanie REMOVED staje się MANAGED.
• gdy encja jest obiektem odłączonym może być wyzwolony wyjątek EntityExistsException w przypadku wywołania operacji lub EntityExistsException lub PersistenceException w trakcie flush lub commit
• dla wszystkich encji (nazwijmy je Y) do których odwołuje się poprzez relacje dana encja, jeżeli relacja do tych encji jest oznaczona jako kaskadowa z cascade=PERSIST lub cascade=ALL operacja jest stosowana do encji skojarzonych (Y).

2. Usunięcie - zarządzana (managed) instancja encji staje się usuniętą (removed) poprzez wywołanie metody remove lub w wyniku wykonania operacji kaskadowej.

Znaczenie operacji remove:
• gdy encja jest w stanie NEW operacja jest ignorowana, ale jest propagowana do encji w relacji
• gdy encja jest w stanie MANAGED operacja powoduje przejście do stanu REMOVED
• gdy encja jest odłączona operacja powoduje wyrzucenie wyjątku IllegalArgumentException
• gdy encja jest w stanie REMOVED operacja jest ignorowana
• faktyczne usunięcie encji z bazy danych następuje po wykonaniu comit lub po wykonaniu flush-a

3. Synchronizacja z bazą danych - stan encji persystentnych jest synchronizowany (synchronized) z bazą danych po zakomitowaniu transakcji. Ta synchronizacja polega na zapisie do bazy danych jakichkolwiek aktualizacji na encji i jej relacjach. Aktualizacja stanu encji zawiera przypisanie nowych wartości do właściwości lub pól persystentnych encji oraz modyfikację zmienialnych wartości dla właściwości i pól persystentnych. Synchonizacja z bazą danych nie zawiera odświeżenia jakichkolwiek zarządzanych encji dopóki operacja odświeżenia nie jest eksplicite wywołana na tych encjach.

Jest ważnym by zapewnić, że zmiany dokonane w części odwrotnej relacji powodowały odpowiednie zmiany w części właściwej, tak by zapewnić by zmiany nie zostały utracone po synchronizacji z bazą danych.


Silnik dostawcy persystencji jest uprawniony do wykonywania synchronizacji z bazą danych w trakcie, gdy transakcja jest aktywna. Można użyć metody flush w celu wymuszenia synchronizacji z bazą danych przez aplikację. Synchronizacja stosuje się do encji skojarzonych z kontekstem persystencji.

4. Encje odłączone (Detached entities) - odłączenie encji może nastąpić w wyniku zakomitowania transakcji gdy używany jest zarządca encji (entity manager) typu transaction-scoped container-managed, zrolbekowania transakcji, wyczyszczenia kontekstu persystencji, zamknięcia zarządcy encji oraz serializacji encji lub przekazania encji przez wartość do separowanej warstwy aplikacji przy użyciu interfejsu zdanego.

Merging Detached Entity State: operacja łączenia (merge) dopuszcza propagację stanu z encji odłączonych do encji persystentnych zarządzanych przez EntityManager-a.

5. Instancje zarządzane - odpowiedzialność aplikacji za zapewnienie, że instancja jest zarządzana w dokładnie jednym kontekście persystencji. Zachowanie nie jest zdefiniowane jeżeli ta sama instancja jest przypisywana do zarządzania w więcej niż pojedynczym kontekście persystencji.

W celu stwierdzenia czy dana instancja encji jest zarządzana w bieżącym kontekście persystencji można użyć metody contains.

contains zwraca true:
• gdy encja została pobrana z bazy danych i nie została usunięta i odłączona,
• gdy instancja encji jest nową i została na rzecz encji wykonana metoda persist
contains zwraca false:
• gdy instancja jest odłączona
• gdy metoda remove została wywołana na rzecz encji lub wystapiło usunięcie kaskadowe
• gdy instancja jest nową i nie została jeszcze wywołana metoda persist na rzecz encji.