PMP Certification Links

Project Management Professional Exam Information; FAQ and few practical tips
How to Prepare and fill PMP application form
PMI Experience worksheet
The PMP® Exam Experience Verification Worksheet
How to prepare your PMP exam application
PMP Certification, A Beginner's Guide

Linki do stron o SmartGWT

Konfiguracja środowiska do pracy z GWT i Maven'em
SmartGWT Show Case
SmartGWT - projekt od podstaw za pomocą mavena
Setting Up SmartGWT 2.1 and GWT 2.0 with Eclipse 3.5
GWT 2.0.3 + Maven2 + Eclipse

Single Responsibility Principle - zasada pojedynczej odpowiedzialności

Single Responsibility Principle - każdy obiekt powinien mieć pojedynczą odpowiedzialność i wszystkie jego usługi powinny być blisko sprzymierzone z tą odpowiedzialnością. Na pewnym poziomie Spójność (cohesion) jest uważana za synonim dla SRP.

Odpowiedzialność (responsibility) - powód do zmiany. W przypadku, gdy mamy więcej niż jeden powód do zmiany klasy, oznacza to, że klasa ma więcej niż jedną odpowiedzialność. Przykładowo mając interfejs poniżej widzimy cztery sensowne funkcje modemu:

interface Modem {
  void dial(String phone);
  void hangup();
  void send(char ch);
  char recv();
}

jednak, przy bliższym spojrzeniu można dostrzec dwie odpowiedzialności. Pierwsza z nich dotycząca zarządzania połączeniem oraz druga związana z przesyłaniem danych. Lepszym rozwiązaniem byłoby rozdzielenie tych dwóch odpowiedzialności pomiędzy dwa interfejsy, tak jak poniżej:

interface Connection {
  void dial(String phone);
  void hangup();
}

interface DataChannel {
  void send(char ch);
  char recv();
}

class ModemImpl implements DataChannel, Connection {
}

Spójność (cohesion) - miara jak silno-skojarzona jest funkcjonalność wyrażona przez kod źródłowy modułu oprogramowania. Metody pomiaru spójności zmieniają się od miar jakościowych klasyfikujących tekst źródła podlegającego analizie używając rubryki z hermeneutykami do jakościowych miar które badają tekstowe charakterystyki kodu źródłowego by wskazać wartość numeryczną spójności.

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.

Wersjonowanie - adnotacja Version

Adnotacja Version specyfikuje pole lub właściwość typu wersja dla encji i służy jako wartość optymistycznego lokowania. Wersja jest używana w celu zapewnienia integralności w przypadku wykonywania operacji łączenia (merge) i kontroli współbieżności typu optymistycznego.

Reguły dotyczące pól / właściwości typu Version:
1. Jedynie jedna właściwość lub pole dla klasy może być oznaczona adnotacją Version.
2. Właściwość Vesion musi być mapowane do głównej tabeli dla klasy encji.
3. Właściwości typu Version nie powinny być aktualizowane bezpośrednio przez aplikację.
4. Pola następującego typu mogą być oznaczone przez Version: int, Integer, short, Short, long, Long, Timestamp
5. Operacje grupowe (bulk operations) nie respektują atrybutu Version. Tego typu operacje aktualizują poprostu wiersze w bazie danych, niezależnie od wartości wersji. Ponadto, zmiany wprowadzone przez aktualizacje nie są uwzględniane w encjach istniejących w kontekście persystencji.

Domyślne mapowanie dla pól i właściwości nie-relacyjnych

W przypadku pola lub właściwości innej niż właściwość relacyjna nie oznaczonej adnotacją mapującą zdefiniowaną w rozdziale 9 specyfikacji ejb-3_0-fr-spec-persistance (lub w przypadku braku odpowiadającej specyfikacji informacji mapującej w pliku deskryptora XML) stosowane są następujące reguły domyślnego mapowania:
• Jeżeli typ jest klasą, która jest oznaczona adnotacją Embeddable, następuje mapowanie w ten sam sposób jak w przypadku pola lub właściwości oznaczonej jako Embedded
• Jeżeli typ pola lub właściwości jest jednym z podanych, następuje mapowanie w ten sam sposób jak gdyby pole oznaczone było adnotacją Basic: prymitywne typy Java, wrappery na typy prymitywne, java.lang.String, java.math.BigInteger, java.math.BigDecimal, java.util.Date, java.util.Calendar, java.sql.Date, java.sql.Time, java.sql.Timestamp, byte[], Byte[], char[], Character[], enums, lub jakakolwiek klasa oznaczona jako Serializable.

W przypadku, gdy żadna z powyższych reguł nie zachodzi i pole lub właściwość nie zostało oznaczone żadną adnotacją zgłoszony zostanie błąd.

Klasy osadzone (Embeddable Classes)

Encja może używać innych drobnoziarnistych klas do reprezentowania jej stanu. Instancje tych klas, w przeciwieństwie do samych instancji encji nie posiadają identyfikatora persystencji. Zamiast tego, istnieją wyłącznie jako obiekty osadzone
w encji, do której należą. Takie osadzone obiekty należą wyłącznie do encji, w których zostały osadzone i nie są współdzielone z innymi encjami. Próba współdzielenia obiektów osadzonych w ramach encji ma niezdefiniowaną semantykę. Ponieważ takie obiekty nie mają persystentnej identyfikacji, są zwykle mapowane wspólnie z instancją encji, do której należą.

Klasy osadzone muszą być zgodne z wymaganiami dla encji określonymi w pkt 2.1 specyfikacji (ejb-3_0-fr-spec-persistance) z wyjątkiem takim że, klasy osadzone nie są oznaczone adnotacją Entity. Klasy osadzone muszą być oznaczone adnotacją Embeddable lub oznaczone jako takie w deskryptorze XML. Typ dostępu do osadzonego obiektu określa typ dostępu dla encji, w której obiekt jest osadzony. Specyfikacja wymaga obsługi tylko jednego poziomu osadzania.

Adnotacja Embeddable jest używana w celu specyfikacji klasy, której instancje są przechowywane jako nieodłączna część encji i współdzielą identyfikację z tą encją. Każda z perystentnych właściwości lub pól obiektu osadzonego jest mapowana do tabeli bazy danych odpowiadającej encji. Mapowane adnotacje Basic, Column, Lob, Temporal i Enumerated mogą być jedynie przenośnie użyte do mapowania pól lub właściwości persystentnych klasy oznaczonej jako Embeddable.

W celu specyfikacji pola lub właściwości encji, której wartość jest instancją klasy osadzonej należy użyć adnotacji Embedded. Adnotacje AttributeOverride i / lub AttributeOverrides mogą być użyte w celu przykrycia mapowania kolumn zadeklarowanych wewnątrz klasy osadzonej, które są mapowane do tabeli skojarzonej z encją. Nie jest wymagane od implementacji wsparcie dla obiektów osadzonych mapowanych na więcej niż jedną tabelę. Użycie adnotacji Embedded dla pola lub właściwości jest tożsame z użyciem pola lub właściwości klasy oznaczonej jako Embeddable.

Kontekst persystencji dla zarządzanego przez aplikację EntityManager-a

Kontekst persystencji (Persistence context) istnieje od momentu utworzenia Entity Manager-a przy użyciu metody EntityManagerFactory.createEntityManager do czasu zamknięcia Entity Manager-a, czyli do czasu wywołania metody EntityManager.close. Rozszerzony kontekst persystencji pobrany z Entity Manager-a zarządzanego przez aplikację jest niezależnym kontekstem persystencji to znaczy, że nie jest on propagowany wraz z transakcją.

Kontekst persystencji istnieje niezależnie od transakcji, jednakże zazwyczaj w tym samym czasie co transakcja. Entity Manager jest zwykle tworzony zaraz po rozpoczęciu transakcji, a kończy swoje działanie po powrocie z metody (lub w przypadku manager-a zarządzanego przez aplikację) po wywołaniu EntityManager.close.

Co to jest Mapped Superclass ?

Mapped Superclass oznacza klasę, dla której informacja o mapowaniu jest wprowadzana do encji, które z niej dziedziczą. Dla klasy tego typu nie ma zdefiniowanej oddzielnej tabeli. Klasa oznaczona adnotacją MappedSuperclass może zostać zmapowana w ten sam sposób jak encja z wyjątkiem tego, że wprowadzone mapowania będą miały znaczenie jedynie w jej podklasach. Takie zachowanie jest uwarunkowane tym, że dla klasy Mapped Superclass nie istnieje skojarzona tabela. W podklasach, odziedziczone z Mapped Superclass mapowania zostają wprowadzone w kontekście tabel zdefiniowanych dla tych podklas. Odziedziczone informacje o mapowaniu mogą zostać przykryte w takich podklasach przy użyciu adnotacji AttributeOverride i AssociationOverride lub odpowiadających im elementów z XML-a.