sobota, 20 marca 2010

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

Najwyższy czas na przygotowanie aplikacji, która umożliwi klientom składanie wniosków o produkty bankowe. Zanim powstanie program należy zdefiniować kontrakt pomiędzy nim, a systemem procesującym wnioski na szynie usług. Komunikacja odbywać się będzie za pomocą usługi WebService. Należy zatem przygotować definicję tej usługi - plik WSDL oraz powiązany z nim model zapisany w pliku XSD. Zatem do dzieła.

Zastanówmy się nad tym jakie dane potrzebujemy zebrać od klienta, w celu poprawnego przeprocesowania wniosku. Na pewno potrzebne są dane osobiste: imię, nazwisko, numer Pesel, seria oraz numer dowodu osobistego lub paszportu. Dodatkowo potrzebujemy dane adresowe klienta. Ostatnią i najważniejszą rzeczą jest wybór produktów - rachunku i karty.

Podsumowując aplikacja wnioskowa prosi klienta o podanie następujących danych:
  • Imię
  • Nazwisko
  • Numer Pesel
  • Seria i numer dowodu osobistego
  • Seria i numer paszportu
  • Ulica z numerem domu i mieszkania adresu zameldowania
  • Miasto
  • Kod pocztowy
  • Rodzaj konta - waluta rachunku
  • Typ karty
Na podstawie tych wymagań utworzono dokument XSD. Znaleźć go można pod następującym adresem projektu BankSourceSystem.

Potrzebujemy zdefiniować dodatkowo sytuacje wyjątkowe ich opis, w postacie XSD, również udostępniłem w projekcie BankSourceSystem (dokładny link do pliku).

Ostatnim zadaniem jest utworzenie samego pliku WSDL. Interfejs samej usługi jest prosty: jako parametr przyjmuje dane wypełnione przez klienta i zwraca identyfikator uruchomionej sprawy. W razie niepowodzenia zwraca wyjątek wyżej wymieniony. WSDL dostępny jest pod następującym linkiem.

Z tak przygotowanym opisem usługi jesteśmy gotowi do napisanie aplikacji zbierającej wnioski. Opis tego komponentu przedstawię jednak następnym razem.

sobota, 13 marca 2010

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

Obiecałem ostatnio, że przedstawię aplikację, której zadaniem będzie zbieranie od klientów wniosków o konto osobiste z opcjonalną kartą. Postanowiłem jednak, że w pierwszej kolejności powinniśmy bliżej poznać architekturę technologiczną całego projektu. Dlatego dzisiaj postaram się przybliżyć serce całego rozwiązania, czyli OpenESB - platformę integracyjną.

Głównym celem postawionym przed OpenESB jest uproszczenie integracji komponentów korzystających z różnych technologii. U podstaw architektury tego rozwiązania leży implementacja specyfikacji JBI. Standard ten dzieli wszystkie komponenty na dwa rodzaje: komponenty połączeniowe (BC) oraz silniki usług (SE). Natomiast komunikacja między komponentami odbywa się za pomocą mechanizmu NMR (znormalizowany ruter wiadomości). Całość wygląda w następujący sposób (diagram zaczerpnięty ze strony JBI Component Technical Overview):
JBI Messaging Infrastructure (NMR) spina wszystkie komponenty, Service Engine (SE) oferują usługi wewnątrz kontenera, natomiast Binding Component oferują łączność z systemami zewnętrznymi.

Jakie usługi mogą oferować SE? W przypadku OpenESB jest to np.: BPEL SE oferujący możliwość instrumentacji procesów biznesowych; JavaEE SE, który zapewnia dostępność wszystkich komponentów JavaEE jako usługi JBI; XSLT SE oferujące transformacje XML czy WLM SE zapewniający zarządzanie zadaniami wymagającymi interakcji z człowiekiem.

Co oferują komponenty BC? Komunikację z zewnętrznymi usługami FTP (FTP BC), SMTP (SMTP BC), JMS (JMS BC), systemami plików (File BC), usługami REST (REST BC) i wiele innych.

Należy wziąć pod uwagę, że dołożenie kolejnych komponentów SE jak i BC nie stanowi problemu i ciągle rozwijane są nowe elementy systemu. Na następującej stronie można znaleźć listę wszystkich obsługiwanych przez OpenESB komponentów

Skoro posiadamy już ogólną wiedzę o OpenESB sprawdźmy czego będziemy potrzebować przy realizacji postawionych w pierwszym poście serii wymagań.

Aplikacja BankSourceSystem(BSS) symulująca systemy bankowe została wykonana w całości w technologii JEE. Z racji tego, że OpenESB posiada komponent JavaEE SE, można wyżej wymienioną aplikację zdeployować i korzystać z jej funkcjonalności wewnątrz kontenera JBI. Jest to pierwsze rozwiązanie, które nasuwa się po zapoznaniu się z architekturą szyny. Jednak początkowo zamierzałem wykorzystać funkcjonalności BSS w zupełnie inny sposób. Aplikacja BSS miała być odseparowana od OpenESB - znajdować się na zupełnie innym serwerze aplikacji, a komunikacja z szyną miała odbywać się za pomocą usług WS wystawionych przez BSS. Ponieważ pojawiły się dwa rozwiązania spróbuję wdrożyć, a właściwie wypróbować oba. W pierwszym przypadku wykorzystam komponent JavaEE SE do komunikacji z aplikacją zdeployowaną razem z JBI, natomiast w drugim przypadku skorzystam z HTTP BC do komunikacji z odpowiednimi usługami wystawionymi przez BSS. 

Komponent HTTP BC zostanie wykorzystany również do odbierania informacji od aplikacji wnioskowej.

Centralnym punktem, gdzie znajdować się będzie logika biznesowa jest komponent BPEL SE. Usługa, która zostanie wystawiona w tym kontenerze będzie definiowała cały proces biznesowy realizacji zgłoszonego wniosku. Przepływ zdefiniowany w BPEL SE powiąże wszystkie pozostałe usługi w innych komponentach w całość.

W cały procesie zdefiniujemy jeden element styku, który wymagać będzie interakcji z użytkownikiem. Za realizację tego punktu odpowiadać będzie komponent WLM SE.

Podsumowując komponenty JBI, których wykorzystanie planujemy w ramach realizacji projektu: BPEL SE, JavaEE SE, WLM SE i HTTP BC.

Poniżej diagram prezentujący architekturę komponentów w pierwszym przypadku - wykorzystanie komponentu JavaEE SE:
Oraz drugi diagram prezentujący architekturę komponentów drugiego przypadku - dodatkowe wykorzystanie komponentu HTTP BC:
To by było na tyle jeżeli chodzi o opis wykorzystania szyny OpenESB i poszczególnych komponentów JBI. Co czeka nas w najbliższej przyszłości? Po pierwsze przygotowanie WSDLa za pomocą którego składane będą wnioski z aplikacji wnioskowej. Po drugie utworzenie samej aplikacji wnioskowej. Na samym końcu przygotowanie obsługi całego procesu wewnątrz kontenera JBI.