SOA w akcji - integracja systemów bankowych (c.d. 2)

W poprzednich "odcinkach" opisałem na czym polega i jaki ma cel nowy projekt, którego realizacji się podjąłem oraz zaprezentował efekt końcowy pierwszego etapu - aplikację BankSourceSystem. Dzisiaj chciałby powrócić do aplikacji i opisać jakie interfejsy symulowanych systemów wystawia ona za pomocą usług WebService.

Na poniższym rysunku przedstawiłem wszystkie interfejsy, które niezbędne są do realizacji postawionego celu biznesowego - automatyzacji procesu zakładania produktów bankowych.

Serwis udostępniany przez system MigDZ służy do sprawdzenia czy podany numer dokumentu (paszport lub dowód osobisty) nie został zastrzeżony. Usługa verifyDocument zwraca true jeżeli dokument znajdzie się w bazie dokumentów zastrzeżonych.

System Sanctions udostępnia usługę sprawdzając czy osoba o podanym imieniu i nazwisku nie znajduje się na liście osób objętych sankcjami. Usługa verifyEntity zwraca wartość true jeżeli imię i nazwisko zostaną dopasowane do jednego z rekordów bazy danych.

System Customers przechowujący informacje o klientach udostępnia 3 usługi pozwalające: zapisać nowego klienta w systemie (createCustomer); wyszukać klientów na podstawie peselu, dowodu osobistego lub numeru paszportu(findCustomers); oraz pobrać informacje o pojedynczy kliencie (getCustomer).

Ostatni system, Products, umożliwia założenie konta (createAccount) oraz karty (createCard) jak również pobranie informacji o konkretnych produktach (getAccount i getCard).

Kolejny etap obejmuje przygotowanie aplikacji wnioskowej, która posłuży zebraniu informacji od wnioskodawcy o produktach, które on zamawia. Opis programu przedstawię w jednym z kolejnych wpisów.

SOA w akcji - integracja systemów bankowych c.d.

Udało się zakończyć pierwszy etap projektu o którym wspominałem w jednym z poprzednich wpisów - przygotować aplikację, która symuluje zachowanie bankowych systemów źródłowych - BankSourceSystem.

Z technologicznego punktu widzenia aplikacja została wykonana z wykorzystaniem: JSF 2.0 oraz EJB 3.1. Zarówno rozwój jak i testy zostały przeprowadzone na serwerze aplikacji - Glassfish v3. Kody źródłowe dostępne są na SVN'owym repozytorium Google'a.

Tak jak wspomniałem poprzednio głównym zadaniem tego programu będzie symulowanie wielu systemów, z których może składać się system informatyczny banku. Symulacja ta ma na celu zademonstrowanie w jaki sposób może przebiegać integracja tych systemów w prostym procesie zamawiania produktów bankowych.

Symulacja jakich systemów wchodzi w grę?

• MigDZ - system, który umożliwia dostęp do informacjach o zastrzeżonych dokumentach: paszportach oraz dowodach osobistych.
• Sanctioned Entities - system przechowujący informacje o osobach znajdujących się na listach sankcyjnych np.: terrorystach, osobach zaangażowanych politycznie itp.
• Customers - prosty system przechowujący podstawowe informacje o klientach banku
• Products - system przechowujący informacje o produktach, które posiadają kliencie banku.

Interfejs aplikacji jest bardzo prosty i składa się z kilku stron, które udostępniają funkcjonalności poszczególnych systemów. Strona główna zawiera odnośniki do stron z poszczególnymi systemami.

Każdy z systemów składa się z dwóch elementów: listy prezentującej zgromadzone w systemie dane oraz formularza umożliwiającego wprowadzanie nowych danych lub modyfikacje istniejących.

MigDZ System

Lista danych:

Edycja danych:

Santioned Entities System

Lista danych:

Edycja danych:

Customers System

Lista danych:

Edycja danych:

Products System - Rachunki

Lista danych:

Edycja danych:

Products System - Karty

Lista danych:

Edycja danych:

Jednak nie to stanowi sedno tej aplikacji. Najważniejszą rzeczą są funkcjonalności udostępnione za pomocą usług WebService. Każdy system udostępnia jedną lub kilka funkcji, których wykorzystanie potrzebne jest do realizacji procesu biznesowego zamawiania produktów bankowych. Opis tych funkcji zamieszczę w następnym wpisie.

HSQLDB w Glassfish v3

Glassfish, jak każdy serwer aplikacji (SA), pozwala definiować pulę połączeń bazodanowych. Na potrzeby jednego z małych projektów próbowałem zaprzęgnąć testową bazę danych, która przechowywałaby informacji wyłącznie w pamięci w czasie działania instancji SA. Jest to bardzo wygodne podczas prowadzenia rozwoju aplikacji, ponieważ nie trzeba zajmować się konfiguracją bazy danych i dbaniem o jej "czystość" po kolejnych przyrostach funkcjonalności. Idealnie do tego zadania nadaje się HSQLDB z trybem "mem". W trybie pamięciowy tworzona jest struktura bazy, a dane zapamiętywane tylko przez okres uruchomienia bazy w maszynie wirtualnej. Kiedy maszyna jest wyłączana automatycznie wszystkie dane są tracone. Jak wspomniałem wcześniej takie działanie ma swoje plusy tylko w określonych sytuacjach. 

Jak skonfigurować połączenia w Glassfish, aby wykorzystywały HSQLDB w trybie "mem"? Pierwszym krokiem jest zaopatrzenie się w jar'a bazą HSQLDB. Na pewno można ją znaleźć na stronach jej twórców. Ściągniętego jar'a należy wgrać do odpowiedniego katalogu w utworzonej domenie Glassfish'a. Według dokumentacji mogą to być katalogi: /lib lub /lib/ext. Po dograniu biblioteki startujemy domenę i przechodzimy do konsoli administracyjnej (np. http://localhost:4848). Następnie w zakładce Resources->JDBC->Connection Pools tworzymy nową pulę połączeń (przycisk New). Nowemu połączeniu nadajemy nazwę i wskazujemy jego typ jako javax.sql.DataSource.

 

Zatwierdzamy zmiany przyciskiem Next. W kolejnym oknie podajemy nazwę klasy implementującej interfejs DataSource dostarczonej przez HSQLDB: org.hsqldb.jdbc.jdbcDataSource. W tym miejscu należy się drobna uwaga odnośnie wersji bazy danych. Zauważyłem, że podany wyżej interfejs od wersji 2.0 nazywa się org.hsqldb.jdbc.JDBCDataSource. Proszę zwrócić uwagę jaką wartość się tutaj podaje. Jeżeli podczas testowania połączenia wyskoczy błąd informujący o tym, że nie można odnaleźć klasy należy zwrócić uwagę na podanie poprawnej nazwy klasy implementującej DataSource.

Ostatnim etapem jest podanie dodatkowych parametrów połączenia bez których nie uda się uruchomić instancji HSQLDB. Poniżej lista parametrów oraz ich wartości:

1. User=sa
2. Password=()
3. driverClass=org.hsqldb.jdbcDriver
4. database=jdbc:hsqldb:mem:testname

Należy w tym miejscu zwrócić uwagę, że dzięki tym parametrom konfiguruje się bazę danych do pracy w trybie pamięciowym (parametr database)

Wprowadzone dane potwierdzamy przyciskiem Finish. Po przejściu w szczegóły nowo  utworzonej puli wykonać należy test poprawności połączenia - przycisk Ping.

Często popełnianym błędem jest niewrzucenie biblioteki do odpowiedniego katalogu w domenie glassfish, przez co sygnalizowany jest błąd o braku możliwości odnalezienie klasy implementującej interfejs DataSource. Zwrócić należy również uwagę na dodatkowe parametry za pomocą których można skonfigurować pulę.

Skoro udało się skonfigurować pulę połączeń to można wrócić do pisania funkcjonalności wykorzystujących DataSource oparte o te pule ;-)

SOA w akcji - integracji systemów bankowych

Powoli moje zainteresowania technologiami Javowymi zaczynają brać górę na blogu. Tym razem chciałbym zaproponować Wam projekt, którego celem będzie zapoznanie się z praktycznym wykorzystaniem SOA oraz technologiami z nim powiązanymi. Całość podzielona będzie na kilka etapów, a końcowym efektem będzie zintegrowana aplikacja do składania wniosków o produkty bankowe.

Integracja jakich systemów może wchodzić w grę w przypadku prostego wnioskowania o konto osobiste z kartą debetową? Po pierwsze należy sprawdzić czy wnioskodawca nie posługuje się zastrzeżonym dokumentem w systemie MigDZ. Po drugie należy sprawdzić czy wniosku nie składa osoba znajdująca się na listach terrorystycznych czy listach osób objętych sankcjami. W kolejnym etapie weryfikacji sprawdzamy czy wnioskodawca nie jest już klientem banku w systemie przechowującym informacje o klientach. Na koniec pozostaje założenie konta i karty w systemie przechowującym informacje o produktach klientów.

Oczywiście powyższy opis jest sporym uproszczeniem. Każdy bank ma zazwyczaj system dostępu elektronicznego, który może oferować jako dodatkowy produkt. Może również posiadać system maklerski, gdzie klienci składają zlecenia kupna i sprzedaży akcji lub jednostek funduszy inwestycyjnych. Nie wspominając już o systemach ubezpieczeniowych za pomocą których można oferować produkty ubezpieczeniowe.

Na potrzeby tego projektu przygotowana zostanie aplikacja symulująca kilku systemów źródłowych - BankSourceSystem. Symulować będzie ona funkcjonalności: sprawdzania klienta w MigDZ, sprawdzania czy nie znajduje się on na liście osób objętych sankcjami (terroryści na przykład), sprawdzania i zapisywania wnioskodawcy w systemie zarządzania klientami, zapisywać informacje o wnioskowanych produktach.

Kolejnym etapem będzie przygotowanie aplikacji, której celem jest zebranie informacji od klienta o produktach o które wnioskuje. Prostota tego typu aplikacji polega na tym, że prezentowanych jest kilka formularzy zbierających dane, które po zatwierdzeniu wniosku przekazywane są do aplikacji przetwarzającej go.


Ostatnim etapem jest przygotowanie aplikacji procesującej wniosek. Rozwiązań może być wiele - można skorzystać z systemu klasy workflow, który zapewni przepływ i realizację zadań w poszczególnych systemach źródłowcy; można również skorzystać z połączenia JBI oraz zintegrowanego silnika WS-BPEL, za pomocą którego również zrealizuje się opisane wcześniej wymagania.

Założeniem projektu co do ostatniego etapu jest skorzystanie z OpenESB. Jest to platforma, której głównym celem jest uproszczenie integracji biznesowej oraz ułatwienie implementacji architektury SOA. Udostępnia ona również komponenty JBI z których podczas wykonywania integracji zamierzam skorzystać.

W najbliższym czasie postaram się przedstawić opis prac nad pierwszym etapem projektu - przygotowaniem aplikacji symulującej systemy bankowe.

Wzorce JEE według Adama Bien'a

Zawodowo zajmuję się programowanie w Javie. Hobbystycznie, natomiast próbuję sił z JEE. Dlatego nie mogłem przejść obojętnie wobec książki, którą zaserwował Adam Bien - "Real World Java EE Patterns - Rethinking Best Practices". Dodatkowo w dotychczasowej karierze zawodowej zajmowałem się wyłącznie aplikacjami J2EE (ku mojemu wielkiemu rozczarowaniu). Jednak coraz więcej firm, dla których tworzone jest oprogramowanie migruje na serwery aplikacji zgodne ze specyfikacją JEE. Z tego powodu kwestią czasu jest kiedy w nowych projektach będzie można skorzystać z jej dobrodziejstw. Nie chcąc pozostać w tyle sięgnąłem po wyżej wymienioną książkę. 

 

Motywem przewodnim są wszechobecne wzorce. Adam skupia się w niej głównie na tych, które mogą być bardzo pomocne w tworzeniu aplikacji JEE. Pisze z perspektywy osoby, która wcześniej dokładnie poznała architekturę J2EE i rozlegle stosowała wzorce zaproponowane przez Sun'a. Wskazuje te które nie mają obecnie żadnego zastosowania w nowej architekturze, ponieważ nowe rozwiązania wyeliminowały potrzebę ich wykorzystania. Ukazuje również te, których znaczenie się nie zmieniło, jednak z przyczyn częstego i błędnego ich stosowania stara się wyraźnie zaznaczyć jak powinno się z nich korzystać.

 

Główny podział wzorców przebieg według wykorzystania  ich w odpowiednich warstwach. Warstwa integracji zawiera następujące wzorce: Service Facade, Service, Persistent Domain Object, Gateway, Fluid Logic, Paginator, Fase Lane Reader. Warstwa integracji natomiast: Data Access Object, Transfer Object., Service Activator. Dodatkowo w warstwie integracji opisuje strategie migracji beanów 2.x do 3.x ielegancki sposób wykorzystania Java Connector Architecture. 

Oprócz wymienionych wyżej wzorców przyporządkowanych do odpowiednich warstw przedstawione są inne, równie użyteczne jak: Service Starter, Singleton, Bean Locator, Thread Tracker, Dependency Injection Extender, Payload Extractor, Resource Binder i Context Holder.

Książkę czyta się bardzo przyjemnie. Każdy wzorzec zaprezentowany jest z punktu widzenia problemu, który rozwiązuje, strategii, testowania, dokumentowania, konsekwencji które niesie wykorzystanie i wskazania powiązanych wzorców. 

 

Moim zdaniem jest to obowiązkowa lektura dla architektów rozwiązań klasy Enterprise, jak również dla zwykłych programistów, którym przyjdzie implementować konkretne problemy biznesowe.

Prywatny serwer Wave - instalacja wtyczki Wave

Nasze kilkudniowe walki z własnym serwerem Wave zakończyliśmy na instalacji, konfiguracji oraz przetestowaniu serwera OpenFire. Kolejnym wielkim krokiem na drodze do sukcesu jest zainstalowanie samego rozszerzenia Fali i spięcie go z OpenFire.

Całą operację zaczynamy od ściągnięcia źródeł rozszerzenia za pomocą komendy: hg clone https://wave-protocol.googlecode.com/hg/ wave-protocol. Niespodziewanie w tym miejscu pojawił się pierwszy problem - co to za polecenie hg. Z pomocą przyszła konsola podpowiadając, że najpierw trzeba zdobyć samo narzędzie i można to zrobić wykonując następujące polecenie: sudo apt-get install mercurial. Po zainstalowaniu narzędzia wracamy ponownie do ściągnięcia kodów poleceniem: hg clone https://wave-protocol.googlecode.com/hg/ wave-protocol. Ściągnąwszy pomyślnie źródła przechodzimy do jednego z utworzonych katalogów: cd wave-protocol i wywołujemy budowę wtyczki poleceniem: ant. W tym miejscu ponownie zostajemy rozczarowani, ponieważ nie ma takiego polecenia. Na szczęście Ubuntu ponownie przychodzi nam z pomocą i proponuje ściągnięcie odpowiedniej aplikacji: sudo apt-get install ant. Gdy ją zainstalujemy ponownie próbujemy zbudować wtyczkę poleceniem: ant. Po jakimś czasie powinniśmy zostać poinformowani o sukcesie.

Kolejnym krokiem jest wygenerowanie odpowiednich certyfikatów bez których nie uda się uruchomić wtyczki. Mamy dwie opcje, albo wygenerujemy prosty certyfikat, albo certyfikat sygnowany przez centrum certyfikacji. Oczywiście w obu przypadkach posługujemy się znacznym uproszeniem, ale w momencie, gdy zechcemy oferować publiczny dostęp do serwera ważnym elementem może być uzyskanie prawdziwego certyfikatu poświadczonego przez zewnętrzną instytucję. Dla naszych testowych zastosować wystarczy pierwsza opcja. Poniżej znajduje się skrypt, który pozwoli nam wygenerować prosty certyfikat:

#!/bin/bash                                                                       

NAME=$1

if [ "$NAME" == '' ]
then
  echo "$0 " 1>&2
  exit 1
fi
openssl genrsa 1024 | openssl pkcs8 -topk8 -nocrypt -out $NAME.key
openssl req -new -x509 -nodes -sha1 -days 365 -key $NAME.key -out $NAME.crt

Wykonując ten skrypt zostaniemy poproszeni o podanie kilku danych dotyczących miejsca, firmy, nazwy oraz adresu email. W wyniku działania skryptu powinny zostać utworzone dwa pliki: $nazwa.key i $nazwa.crt, gdzie $nazwa to identyfikator podany podczas wywoływania skryptu. Na poniższym rysunku zaznaczyłem wywołanie generowania certyfikatu oraz utworzone pliki.

Zasada posługiwania się certyfikatem polega na tym, że plik z rozszerzeniem *.crt udostępniamy publicznie osobom, które będą mogły potwierdzić otwartą przez nas komunikację (np. maile) oraz zaszyfrować przeznaczoną tylko do nas komunikację. Plik *.key jest natomiast przeznaczonym tylko dla nas kluczem prywatnym - nie można go nikomu przekazywać.


Będąc w posiadaniu obu plików możemy powrócić do konfiguracji pluginu. Po zbudowaniu aplikacji w katalogu wave-protocol dostępny jest plik: run-config.sh.example - jego zawartość należy skopiować do pliku: run-config.sh. Następnie należy dokonać zmian w nowoskopiowanym pliku.

Na powyższym rysunku zaznaczyłem miejsca w których dokonałem zmiany. W pierwszym przypadku zakomentowałem linijkę (znakiem: #). Druga zmiana polegała na podaniu nazwy lub adresu IP serwera - w naszym wypadku adres IP: 192.168.1.51. Kolejna zmiana dotyczy wprowadzenie sekretnego hasła, które podaliśmy podczas konfiguracji OpenFire. Dwie kolejne zmiany polegają na podaniu ścieżek do plików kolejno z kluczem (zmienna PRIVATE_KEY_FILENAME) i certyfikatem (zmienna CERTIFICATE_FILENAME_LIST) wcześniej wygenerowanymi (*.key i *.cert). Następne dwie zmiany polegają na podaniu adresu IP serwera w dwóch parametrach: CERTIFICATE_DOMAIN_NAME oraz XMPP_SERVER_PING. Ostatnia zmiana polegała na podaniu false w elemencie: WAVESERVER_DISABLE_SIGNER_VERIFICATION. 

Sprawdźmy czy poprawnie skonfigurowaliśmy certyfikaty za pomocą polecenia: ./check-certificates.sh. Jeżeli zobaczymy komunikat jak na poniższym obrazku to oznacza, że wszystko jest ok w tym punkcie.

Pozostaje uruchomić samego Wave'a za pomocą polecenia: ./run-server.sh.
Wraz z referencyjną implementacją protokołu dostarczony jest prosty klient konsolowy. Można go uruchomić za pomocą komendy: /run-client-console.sh . Po wydaniu tego polecenia pojawi się konsolowe okienko podzielone na dwie części. W jednej części prezentowany jest podgląd fal, natomiast w drugiej szczegóły tej jednej wybranej.


W celach testowych na dwóch różnych konsolach zalogowałem się jako dwaj różni użytkownicy i spróbowałem nawiązać komunikację. Efekt widać poniżej.

 

Ponieważ klient jest konsolowy wszystkie akcje należy wydawać za pomocą komend. Poniżej kilka poleceń:

1. /new - zakłada nową falę
2. /open - otwiera w prawym oknie podgląd fali o podanym identyfikatorze
3. /add @ - dodaje użytkownika do aktywnej fali
4. /remove @ - usuwa użytkownika z aktywnej fali

Więcej poleceń znaleźć można na następującej stronie.


W ten sposób dobrnęliśmy do końca. Udało się nam uruchomić i przetestować działanie naszego serwera Wave'a. Niestety osobiście odczuwam pewien niedosyt, jak się okazało w tej chwili jedynym znanym i darmowym klientem do otwartych fal jest klient konsolowy dostarczany wraz z referencyjną implementacją serwera. Oczywiście w przyszłości pewnie pojawią się nowe aplikacje, które będą wypełniać tę lukę jednak jak patrzę na webowego klienta Googlowskiego Wave to zaczynam wątpić czy kiedykolwiek będą one w stanie dorównać pierwowzorowi.