ESB. Instrukcja techniczna. Wydatek współfinansowany przez Unię Europejską ze środków Europejskiego Funduszu Rozwoju Regionalnego

Transkrypt

1 Wydatek współfinansowany przez Unię Europejską ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Regionalnego Programu Operacyjnego Województwa Mazowieckiego ESB Strona 1 z 29

2 SPIS TREŚCI. 1. Wstęp Cel dokumentu Warunki początkowe Referencje do innych dokumentów Budowanie źródeł aplikacji serwera Zmiany w źródłach Aktualizacja modułu logowania jboss-logging do wersji GA Kompilacja źródeł serwera JBOSS Budowanie źródeł szyny ESB Zmiany w źródłach Kompilacja źródeł szyny ESB Zmiana silnika JBoss-WS-Native na JBoss-WS-CXF Konfiguracja regionalnej szyny ESB z serwerem bazy danych MSSQL Konfiguracja lokalnej szyny ESB z serwerem bazy danych PostgreSQL Wdrożenie szyny ESB na serwer JBoss Usługi ESB - struktura źródeł aplikacji Warunki początkowe Założenia wynikające z wymagań Mechanizm podpisywania kopert SOAP w oparciu o silnik WSS4j Schemat ogólny struktury usługi ESB Usługi ESB Usługi dynamicznie routowane Usługi typu SOAP Proxy Konfiguracja SSL usługi Konfiguracja WS-Security usługi Konfiguracja ról dostępowych do usługi Dodanie nowej usługi ESB Kompilacja źródeł usług ESB Strona 2 z 29

3 1. Wstęp. 1.1 Cel dokumentu. Celem dokumentu jest przekazanie wiedzy programistycznej w zakresie zmian wykonanych w źródłach serwera JBoss oraz szyny ESB, aktualizacji bibliotek silnika usług sieciowych JBoss-WS-CXF, a także implementacji, testowania i wdrożenia usług centralnych oraz lokalnych na szynie ESB. 1.2 Warunki początkowe. Osoba wykonująca jakiekolwiek prace związane z implementacją usług powinna posiadać ogólną wiedzę programistyczną z zakresu specyfikacji Java EE 5/6. W szczególności wymagana jest wiedza z zakresu: język programowania JAVA, implementacja usług sieciowych w oparciu o silnik Apache CXF z wykorzystaniem mechanizmów zabezpieczeń WS-Security, w tym podpis elektroniczny, a także standardowe uwierzytelnienie (login/haslo) w kopercie SOAP, JMS Server i konfiguracja kolejek JMS. Wymagana dodatkowa wiedza z zakresu administracji systemem operacyjnym, obsługi plików XML oraz XSD, a także generowaniem i podpisywaniem certyfikatem kopert SOAP. Wymagana również wiedza z zakresu przesyłania informacji protokołami: HTTP, szyfrowanym HTTP, SOAP, a także wykorzystania interfejsów REST. Wymagana wiedza ogólna z zakresu konfiguracji i wdrożenia usług na szynie ESB. Zakłada się również, że środowisko pracy ze źródłami jest poprawnie skonfigurowane. Poprawna konfiguracja obejmuje: instalację środowiska uruchomieniowego JAVA, Strona 3 z 29

4 instalację narzędzi do automatycznego budowania MAVEN oraz ANT, instalację środowiska deweloperskiego Eclipse lub JBoss Developers Studio. Wykorzystane wersje oprogramowania: Oprogramowanie Wersja JAVA JDK jdk1.6.0_45 MAVEN apache-maven ANT apache-ant JBoss Developers Studio jbdevstudio-product-universal v H213- GA.jar 1.3 Referencje do innych dokumentów. Podręcznik Administratora ESB 2. Budowanie źródeł aplikacji serwera 2.1 Zmiany w źródłach Aktualizacja modułu logowania jboss-logging do wersji GA Aktualizacja modułu logowania umożliwi łatwiejsze zarządzanie logami usług ESB oraz samego serwera JBOSS. Modyfikacja obejmuje zmianę wersji bibliotek logowania w pliku konfiguracyjnym: /jboss ga-src/component-matrix/pom.xml <dependency> <groupid>org.jboss.logging</groupid> <artifactid>jboss-logging-spi</artifactid> <version>2.1.1.ga</version> </dependency> <dependency> <groupid>org.jboss.logging</groupid> <artifactid>jboss-logging-jdk</artifactid> <version>2.1.1.ga</version> </dependency> <dependency> Strona 4 z 29

5 <groupid>org.jboss.logging</groupid> <artifactid>jboss-logging-log4j</artifactid> <version>2.1.1.ga</version> <exclusions> <exclusion> <groupid>apache-log4j</groupid> <artifactid>log4j</artifactid> </exclusion> </exclusions> </dependency> Po zmianie wymagane jest przebudowanie aplikacji zgodnie z sekcją Kompilacja źródeł serwera Kompilacja źródeł serwera JBOSS Warunki początkowe: zainstalowane narzędzie ANT, widoczne z linii komend zainstalowane środowisko uruchomieniowe JAVA dostęp do internetu Konfiguracja repozytorium JBoss Należy zweryfikować konfigurację publicznych repozytorium czy zawierają listę poniższych serwerów. Gdyby, któryś z serwerów był niedostępny należy znaleźć inne publiczne repozytorium zawierające niezbędne biblioteki i dodać je do listy repozytoriów. Konfiguracja publicznych repozytoriów znajduje się w pliku pom.xml, w głównym katalogu archiwum jboss ga-modified-src.zip: <repositories> <repository> <id>jboss-public-repository-group</id> <name>jboss Public Repository Group</name> <url> <layout>default</layout> <releases> <enabled>true</enabled> <updatepolicy>never</updatepolicy> </releases> <snapshots> <enabled>true</enabled> <updatepolicy>never</updatepolicy> </snapshots> </repository> <repository> <id>jboss-deprecated</id> <name>jboss Strona 5 z 29

6 Deprecated</name> <url> d/</url> <layout>default</layout> <releases> <enabled>true</enabled> <updatepolicy>never</updatepolicy> </releases> <snapshots> <enabled>false</enabled> </snapshots> </repository> <repository> <id>jboss-maven2-brew</id> <name>jboss Maven 2 Brew Repository</name> <url> <layout>default</layout> <releases> <enabled>true</enabled> <updatepolicy>never</updatepolicy> </releases> <snapshots> <enabled>false</enabled> </snapshots> </repository> </repositories> W celu kompilacji źródeł serwera JBOSS należy: znajdować się w katalogu z źródłami aplikacji serwera [JBOSS_5.1.0.GA_SRC_HOME]/build wykonać poniższe polecenie w celu usunięcia katalogu wynikowego ant clean wykonać poniższe polecenie w celu kompilacji źródeł ant 3. Budowanie źródeł szyny ESB 3.1 Zmiany w źródłach W celu poprawy błędu obsługi kopert SOAP w wersji 1.2 wprowadzono zmiany w klasach org.jboss.soa.esb.services.security.auth.ws.soapconstants oraz Strona 6 z 29

7 org.jboss.soa.esb.services.security.auth.ws.soapextractionutil. Należy podmienić pliki znajdujące się w katalogu: jbossesb-4.11-modifiedsrc.zip/trunk/product/rosetta/src/org/jboss/soa/esb/services/security/auth/ws/ na pliki z katalogu esb_modified. 3.2 Kompilacja źródeł szyny ESB W celu kompilacji źródeł szyny ESB należy: znajdować się w katalogu: [JBOSSESB_4.11_SRC_HOME]/product wykonać poniższe polecenie w celu usunięcia katalogu wynikowego ant clean wykonać poniższe polecenie w celu kompilacji źródeł ant dist 4. Zmiana silnika JBoss-WS-Native na JBoss- WS-CXF Warunki początkowe: zainstalowane narzędzie ANT, widoczne z linii komend zainstalowane środowisko uruchomieniowe JAVA Przejść do folderu głównego aktualizacji (do którego została rozpakowana zawartość jbossws-cxf ga.zip): [jbossws-cxf-bin-dist] Skonfigurować: ścieżkę do domowego folderu serwera JBoss w pliku konfiguracyjnym./ant.properties (usunąć fragment rozszerzenia pliku.example): jboss510.home <- w sekcji # Optional JBoss Home np. jboss510.home=d:/umwm/esb/src/ws/jboss ga profil konfiguracji serwera w sekcji # The JBoss settings: jboss.server.instance np. jboss.server.instance=all Strona 7 z 29

8 Polecenie wdrożenia aktualizacji silnika WS (wykonać z poziomu folderu [jbossws-cxf-bin-dist]): ant -Djboss.server.instance=all deploy-jboss Konfiguracja regionalnej szyny ESB z serwerem bazy danych MSSQL W celu konfiguracji szyny ESB z SZBD (Systemem Zarządzania Bazą Danych) MSSQL należy usunąć konfigurację domyślną bazy Hypersonic oraz dostarczyć odpowiednią konfigurację dla bazy MSSQL. Należy usunąć foldery:./jboss ga/server/default./jboss ga/server/minimal./jboss ga/server/standard./jboss ga/server/web Należy usunąć pliki:./jboss ga/server/all/hsqldb-ds.xml./jboss ga/server/all/deploy/messaging/hsqldb-persistenceservice.xml Do katalogu./jboss ga/server/all/deploy/messaging/ należy skopiować plik konfiguracyjny dedykowany dla SZBD MSSQL: mssql-persistence-service.xml z katalogu mssql Następnie należy podmienić poniższe pliki na ich odpowiedniki dedykowane dla SZBD MSSQL (znajdują się one w katalogu mssql):./jboss ga/server/all/deploy/jbpm.esb/jbpm-service.xml./jboss ga/server/all/deploy/jbpm.esb/hibernate.cfg.xml./jboss ga/server/all/deploy/jbossesb.esb/jbossesb-service.xml./jboss ga/server/all/deploy/jbossesb-registry.sar/juddi_config/meta- INF/persistence.xml Konfiguracja sterownika JDBC dla wybranej wersji MSSQL: Skopiować do katalogu./ jboss ga/server/all/lib plik sqljdbc4.jar z katalogu mssql. Konfiguracja połączenia do wybranej bazy danych została umieszczona w plikach konfiguracyjnych w kilku lokalizacjach: 1. Konfiguracja DataSource dla instancji bazy danych localdb serwera JBoss oraz pozostałych źródeł danych dla aplikacji wdrażanych na serwer: Strona 8 z 29

9 $JBOSS_HOME/server/all/deploy/mssql-ds.xml 2. Konfiguracja DataSource dla juddidb - rejestru serwisów ESB: $JBOSS_HOME/server/all/deploy/jbossesb-registry.sar/juddi-ds.xml 3. Konfiguracja DataSource dla instancji bazy danych jbossesb - źródła danych dla szyny ESB, składowania kolejek JMS oraz innych danych konfiguracyjnych: $JBOSS_HOME/server/all/deploy/jbossesb.esb/message-store-ds.xml Konfiguracja przewiduje utworzenie struktur DB w pustych bazach danych podczas pierwszego rozruchu serwera. Wymagane jest aby utworzyć puste instancje baz danych (localdb, juddidb, jbossesb) w systemie zarządzania bazą danych oraz przypisać do nich odpowiedniego użytkownika jbossesb. Opcjonalna konfiguracja bazy danych dla katalogu raportów wymaga, aby w SZBD utworzyć bazę danych o nazwie esblogging oraz wykonać na niej dostarczony skrypt mssql_create.sql. Konfiguracja przechowywana jest w pliku konfiguracyjnym mechanizmów logowania na serwerze JBoss (jboss-log4j.xml). W celu nawiązania komunikacji z bazą danych MSSQL należy w plikach konfiguracyjnych (wymienionych powyżej) ustawić wskazane atrybuty (w zależności od pliku mogą być dostępne różne, wymienione niżej atrybuty): Konfiguracja URL połączenia z instancją DB: connection-url jdbc:sqlserver://[host]:[port];databasename=[database_name] Klasa sterownika dla MSSQL: driver-class com.microsoft.sqlserver.jdbc.sqlserverdriver Użytkownik administracyjny user-name [NAZWA_UZYTKOWNIKA] Hasło użytkownika: password [HASLO_UZYTKOWNIKA] Mapowanie typów metadanych w wybranej wersji MSSQL: type-mapping MS SQLSERVER2000 Konfiguracja URL połączenia z instancją DB: URL jdbc:sqlserver://[host]:[port];databasename=[database_name] Klasa sterownika dla MSSQL: driver com.microsoft.sqlserver.jdbc.sqlserverdriver Użytkownik administracyjny user [NAZWA_UZYTKOWNIKA] Hasło użytkownika: password [HASLO_UZYTKOWNIKA] Strona 9 z 29

10 6. Konfiguracja lokalnej szyny ESB z serwerem bazy danych PostgreSQL W celu konfiguracji szyny ESB z SZBD PostgreSQL należy usunąć konfigurację domyślną bazy Hypersonic oraz dostarczyć odpowiednią dla bazy PostgreSQL. Należy usunąć foldery:./jboss ga/server/default./jboss ga/server/minimal./jboss ga/server/standard./jboss ga/server/web Należy usunąć pliki:./jboss ga/server/all/hsqldb-ds.xml./jboss ga/server/all/deploy/messaging/hsqldb-persistenceservice.xml Do katalogu./jboss ga/server/all/deploy/messaging/ skopiować plik konfiguracyjny dedykowany dla SZBD PostgreSQL o nazwie postgresqlpersistence-service.xml z katalogu postgresql Następnie należy podmienić poniższe pliki na ich odpowiedniki dedykowane dla SZBD PostgreSQL (znajdują się w katalogu postgresql):./jboss ga/server/all/deploy/jbpm.esb/jbpm-service.xml./jboss ga/server/all/deploy/jbpm.esb/hibernate.cfg.xml./jboss ga/server/all/deploy/jbossesb.esb/jbossesb-service.xml./jboss ga/server/all/deploy/jbossesb-registry.sar/juddi_config/meta- INF/persistence.xml Konfiguracja sterownika JDBC dla wybranej wersji PostgreSQL 9.1: Skopiować do katalogu./jboss ga/server/all/lib plik postgresql jdbc4.jar z katalogu postgresql. Konfiguracja połączenia do wybranej bazy danych została umieszczona w plikach konfiguracyjnych w kilku lokalizacjach: 1. Konfiguracja DataSource dla instancji bazy danych localdb serwera JBoss oraz pozostałych źródeł danych dla aplikacji wdrażanych na serwer : $JBOSS_HOME/server/all/deploy/postgresql-ds.xml 2. Konfiguracja DataSource dla juddidb - rejestru serwisów ESB: $JBOSS_HOME/server/all/deploy/jbossesb-registry.sar/juddi-ds.xml 3. Konfiguracja DataSource dla instancji bazy danych jbossesb - źródła danych dla szyny ESB, składowania kolejek JMS oraz innych danych konfiguracyjnych: Strona 10 z 29

11 $JBOSS_HOME/server/all/deploy/jbossesb.esb/message-store-ds.xml Konfiguracja przewiduje utworzenie struktur DB w pustych bazach danych podczas pierwszego rozruchu serwera. Wymagane jest aby utworzyć puste instancje baz danych (localdb, juddidb, jbossesb) w systemie zarządzania bazą danych oraz przypisać do nich odpowiedniego użytkownika jbossesb. Opcjonalna konfiguracja bazy danych dla katalogu raportów wymaga, aby w SZBD utworzyć bazę danych o nazwie esblogging oraz wykonać na niej dostarczony skrypt postgresql_create.sql. Konfiguracja przechowywana jest w pliku konfiguracyjnym mechanizmów logowania na serwerze JBoss (jbosslog4j.xml). W celu nawiązania komunikacji z bazą danych PostgreSQL należy w plikach konfiguracyjnych (wymienionych powyżej) ustawić wskazane atrybuty (w zależności od pliku mogą być dostępne różne, wymienione niżej atrybuty): Konfiguracja URL połączenia z instancją DB: connection-url jdbc:postgresql://[host]:[port]/[nazwa_bazy_danych] Klasa sterownika dla PostgreSQL: driver-class org.postgresql.driver Użytkownik administracyjny user-name [NAZWA_UZYTKOWNIKA] Hasło użytkownika: password [HASLO_UZYTKOWNIKA] Mapowanie typów metadanych w wybranej wersji PostgreSQL: type-mapping PostgreSQL 8.0 Konfiguracja URL połączenia z instancją DB: URL jdbc:postgresql://[host]:[port]/[nazwa_bazy_danych] Klasa sterownika dla PostgreSQL: driver org.postgresql.driver Użytkownik administracyjny user [NAZWA_UZYTKOWNIKA] Hasło użytkownika: password [HASLO_UZYTKOWNIKA] 7. Wdrożenie szyny ESB na serwer JBoss W celu wdrożenia szyny ESB na serwer JBoss należy w pierwszej kolejności przeprowadzić konfigurację ścieżki do serwera w pliku konfiguracyjnym: jbossesb-4.11-modified-src.zip\trunk\product\install\deployment.properties Następnie należy wykonać poniższe operacje: Zmienić rozszerzenie pliku jbossesb-4.11-modifiedsrc.zip\trunk\product\install\deployment.properties-example na deployment.properties Skonfigurować właściwości: Strona 11 z 29

12 o org.jboss.esb.server.home=d:/bgwm/esb/src/cxf/jboss ga o Profil serwera: org.jboss.esb.server.config=all Wykonać komendę (z poziomu folderu instalacyjnego./jbossesb/install/): ant deploy 8. Usługi ESB - struktura źródeł aplikacji 8.1 Warunki początkowe Serwer i szyna ESB są poprawnie zainstalowane, połączone z zewnętrznym systemem bazy danych. 8.2 Założenia wynikające z wymagań Dostęp do usług ESB chroniony jest podpisem koperty SOAP przy użyciu certyfikatu prywatnego oraz oznaczeniem koperty czasem wygenerowania żądania. Podpis obejmuje sekcje nagłówka koperty SOAP w zależności od usługi (Timestamp, BinarySecurityToken, Body lub bez sekcji BinarySecurityToken), Usługa ESB dostępna na szynie ESB poprzez przedstawienie się prywatnym certyfikatem wygenerowanym przez Lokalne Centrum Certyfikacji, Komunikacja po szyfrowanym protokole HTTP, Zgodność ze specyfikacją WS-Metadata-Exchange, Transparentność WSDL wystawianej usługi, niezależnie od tego czy usługa jest zewnętrzna, czy wewnętrzna, Zgodność z SOAP 1.1, SOAP 1.2, Zgodność wersji WSS4J oraz XML-Security pomiędzy szyną ESB, serwerem JBoss oraz bibliotekami usług sieciowych JBoss-WS-CXF Strona 12 z 29

13 8.3 Mechanizm podpisywania kopert SOAP w oparciu o silnik WSS4j W celu realizacji wymagania zabezpieczenia przesyłanych wiadomości podpisem elektronicznym został zaimplementowany mechanizm podpisywania i weryfikacji przesyłanych kopert SOAP na poziomie łańcucha akcji usługi ESB. Koperta zawierająca podpis elektroniczny podlega weryfikacji na poziomie mechanizmu logowania operacji wykonywanych przez szynę ESB. Dzięki temu uzyskujemy informację o tym, kto przesyła wiadomość i czy ma odpowiednie prawa do korzystania z funkcjonalności usługi ESB. Moduł podpisujący jest częścią wspólną wszystkich usług ESB, zarówno na szynie centralnej, jak i na szynach lokalnych. Moduł podpisu obsługuje koperty SOAP w wersji 1.1 oraz Schemat ogólny struktury usługi ESB [/ESB_SERVICE_NAME.esb] jbm-queue-service.xml jbossesb-properties.xml log4j.properties ----lib [esb-common-utils].jar ----META-INF [PROXY_WSDL].wsdl crypto_[system]_client_check.properties crypto_[system]_client_request.properties crypto_[system]_client_response.properties deployment.xml https-443.properties jboss-classloading.xml jboss-esb.xml MANIFEST.MF ---maven ---com.comarch.umwm.esb.services ---[ESB_SERVICE_PROJECT_NAME] pom.properties pom.xml ---pl ---gov Objaśnienia:. W folderze głównym usługi znajduje się konfiguracja kolejek JMS (dla komunikacji synchronicznej Strona 13 z 29

14 /lib META-INF /maven /pl/gov/... żądanie/odpowiedź) usługi (plik jbmqueue-service.xml) oraz parametrów dodatkowych, dedykowanych dla wdrożonej usługi (jbossesbproperties.xml), a także konfiguracja mechanizmu logowania log4j dla usługi. Folder przechowuje biblioteki zależne, wymagane do wdrożenia i poprawnego działania usługi na szynie ESB Folder przechowuje kluczową konfigurację usługi. Istotnym plikiem konfiguracyjnym jest jboss-esb.xml, który zawiera definicję oraz opis funkcjonalny usługi ESB. W celu poprawnego wdrożenia usługi wymagane jest również dodanie pliku wdrożenia, który stanowi o kolejności ładowania zależności usługi (deployment.xml). Pozostała konfiguracja dotyczy konfiguracji klienta HTTP, którego wewnętrznie wykorzystuje usługa do komunikacji z systemami zewnętrznymi (https- 443.properties). Pozostałe właściwości dotyczą mechanizmu podpisu elektronicznego wiadomości, przechowują konfigurację certyfikatów dla podpisu oraz jego weryfikacji. Niektóre usługi mogą wymagać ustawienia izolacji ładowania zależnych bibliotek w oparciu o odpowiedni poziom ClassLoader'a (jboss-classloading.xml). Informacje o zależnościach źródeł dla procesu automatycznego budowania aplikacji. Skompilowane klasy funkcji, które realizuje usługa ESB. 8.5 Usługi ESB Usługi ESB zostały zintegrowane z bramką HTTP oraz kolejkami JMS, które stanowią punkt dostępowy do usługi odpowiednio z zewnątrz oraz z wewnątrz Strona 14 z 29

15 szyny ESB. Bramka HTTP umożliwia przyjęcie przez szynę wiadomości w formacie niezrozumiałym jeszcze przez szynę ESB, z kolei JMS przyjmuje wiadomość zrozumiałą dla szyny, mechanizmy konwersji zapewniają poprawną transformację wiadomości pomiędzy punktami dostępowymi. Każda usługa została zintegrowana z rozbudowanym modułem weryfikacji certyfikatów, zapewniającym uwierzytelnienie klientów usług na podstawie podpisu wiadomości. Usługi zostały podzielone na publiczne i prywatne. Do realizacji grupowania usług został wykorzystany mechanizm ról dostępowych powiązanych z klientami usług, który jest częścią składową rozszerzonego modułu uwierzytelniania klientów usług poprzez prywatny certyfikat. W środowisku projektowym wszystkie usługi mają status public. Kolejny podział usług niewynikający z ról dostępowych uwzględnia centralne oraz lokalne usługi ESB, zgodnie z podziałem infrastruktury ESB dla opracowywanego systemu. Każda usługa przechowuje fizyczny plik WSDL, który jest skonfigurowany jako parametr wejściowy akcji SOAPProxy lub DynamicEndpointProxyAction. Plik WSDL przechowuje adres końcowy/dostępowy do zewnętrznej usługi. Przykład pliku WSDL: <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions targetnamespace=" xmlns:impl=" xmlns:intf=" xmlns:tns2=" xmlns:tns3=" xmlns:wsaw=" xmlns:wsdl=" xmlns:wsdlsoap=" xmlns:wsi=" xmlns:xsd=" <wsdl:types> <schema targetnamespace=" xmlns=" xmlns:tns2=" Strona 15 z 29

16 xmlns:wsdl=" xmlns:xsd=" <import namespace=" /> <element name="gettpuserinforesponse"> <complextype> <sequence> nillable="true" <element name="gettpuserinforeturn" type="tns2:tpuserinfo" /> </sequence> </complextype> </element> <element name="gettpuserinfo"> <complextype> <sequence> type="xsd:string" /> <element name="tgsid" nillable="true" nillable="true" type="xsd:string" /> <element name="systemorganisationid" </schema> </element> </sequence> </complextype> <schema targetnamespace=" xmlns=" xmlns:wsdl=" xmlns:xsd=" <complextype name="tpuserinfo"> <sequence> Strona 16 z 29

17 <element nillable="true" type="xsd:string" /> name="account address" type="xsd:string" /> <element name="claimedrole" nillable="true" </schema> </sequence> </complextype> <schema targetnamespace=" xmlns=" xmlns:wsdl=" xmlns:xsd=" <complextype name="tpuserinfoexception"> <sequence> type="xsd:string" /> <element name="message" nillable="true" </sequence> </complextype> <element name="tpuserinfoexception" nillable="true" type="tns3:tpuserinfoexception" /> </schema> </wsdl:types> <wsdl:message name="gettpuserinforesponse"> <wsdl:part name="parameters" /> element="intf:gettpuserinforesponse" </wsdl:message> <wsdl:message name="gettpuserinforequest"> <wsdl:part element="intf:gettpuserinfo" name="parameters" /> </wsdl:message> Strona 17 z 29

18 <wsdl:message name="tpuserinfoexception"> <wsdl:part element="tns3:tpuserinfoexception" name="fault" /> </wsdl:message> <wsdl:porttype name="tpuserinfoservice"> <wsdl:operation name="gettpuserinfo"> <wsdl:input name="gettpuserinforequest" /> <wsdl:output name="gettpuserinforesponse" /> <wsdl:fault name="tpuserinfoexception" /> message="intf:gettpuserinforequest" message="intf:gettpuserinforesponse" message="intf:tpuserinfoexception" </wsdl:operation> </wsdl:porttype> <wsdl:binding type="intf:tpuserinfoservice"> name="tpuserinfoservicesoapbinding" <wsaw:usingaddressing wsdl:required="false" /> <wsdlsoap:binding style="document" transport=" /> <wsdl:operation name="gettpuserinfo"> <wsdlsoap:operation soapaction="gettpuserinfo" /> <wsdl:input name="gettpuserinforequest"> <wsdlsoap:body use="literal" /> </wsdl:input> <wsdl:output name="gettpuserinforesponse"> <wsdlsoap:body use="literal" /> </wsdl:output> <wsdl:fault name="tpuserinfoexception"> Strona 18 z 29

19 use="literal" /> <wsdlsoap:fault name="tpuserinfoexception" </wsdl:fault> </wsdl:operation> </wsdl:binding> <wsdl:service name="tpuserinfoserviceservice"> <wsdl:port name="tpuserinfoservice"> binding="intf:tpuserinfoservicesoapbinding" <wsdlsoap:address location=" services/tpuserinfoservice" /> <wsp:policyreference URI="#x509SecuritySignPolicy" xmlns:wsp=" /> </wsdl:port> </wsdl:service> <wsp:usingpolicy Required="true" xmlns:wsp=" /> <wsp:policy wsu:id="x509securitysignpolicy" xmlns:wsp=" xmlns:wsu=" wss-wssecurity-utility-1.0.xsd"> <wsp:exactlyone> <wsse:securitytoken xmlns:wsse=" <wsse:tokentype> " wss-x509-token-profile-1.0#X509v3" </wsse:tokentype> Strona 19 z 29

20 </wsse:securitytoken> </wsp:exactlyone> </wsp:policy> </wsdl:definitions> Usługi dynamicznie routowane Usługi dynamicznie routowane są typem usług, których odbiorca (endpoint) jest zmienny w zależności od parametru przekazanego w kopercie SOAP. Ten typ usług jest wykorzystywany m.in. przez usługę EZDStatusService. Dynamiczny routing pozwolił znacznie ograniczyć liczbę usług ESB świadczonych przez szynę. Dynamiczny mechanizm wyznaczania trasy został zrealizowany w oparciu o rozbudowany mechanizm akcji SOAPProxy oraz rozbudowany mechanizm publikowania kontraktu na szynie ESB. Programowe wywołanie usługi SOAPProxy umożliwiło dynamiczną konfigurację docelowych punktów odbioru wiadomości. Usługa dynamicznie routowana pobiera atrybut partnerid z nagłówka koperty SOAP, a następnie odnajduję adres hosta z pliku konfiguracyjnego partners.properties (JBOSS_HOME\server\all\conf\partners.properties). Przykładowa zawartość pliku partners.properties: TEST=TESTEURZAD-JST.wrotamazowsza.pl:8543 OSostroAndrzGW=OSTROANDRZGWVM1.wrotamazowsza.pl:8543 CPplonsBabosGW=PLONSBABOSGWVM1.wrotamazowsza.pl:8543 OSostroBaranGW=OSTROBARANGWVM1.wrotamazowsza.pl: Pozostała konfiguracja jest zawarta w pliku jboss-esb.xml usługi (wewnątrz archiwum *.esb\meta-inf), gdzie zamiast akcji SOAPProxy należy podać poniższy wpis: <action name="wsdlcontractpublisher" class="pl.gov.ezd.esb.custom.actions.wsdlservicecontractpublisheracti on"> <property name="wsdl" value="classpath:///meta- INF/statusService.wsdl" /> </action> <action class="pl.gov.ezd.esb.custom.actions.dynamicendpointproxyaction" name="request-action"> <property name="routedestinations" value="c:/comarch/szyna_esb/jboss GA/server/all/conf/partners.properties" /> <property name="file" value="/meta-inf/https-443.properties" /> <property name="clientcredentialsrequired" value="false" /> Strona 20 z 29

21 <property name="protocol" value=" /> <property name="serviceendpointurl" value="/esb-local-ezd-status-service/http/soap/ezdlocalstatusws" /> </action> Parametry: wsdl - określa lokalizację pliku WSDL routedestinations określa lokalizację pliku partners.properties file określa lokalizację pliku z konfiguracją dla połączenia HTTPS. Jest to parametr opcjonalny clientcredentialsrequired parametr opcjonalny określający, czy połączenie SSL wymaga clientcredentials protocol określa protokół adresu endpoint serviceendpointurl określa resztę ciągu adresu endpoint usługi. Dla powyżej przykładowej konfiguracji jeśli do szyny ESB trafi koperta z parametrem partnerid ustawionym na TEST, to koperta zostanie przekierowana na adres TESTEURZAD-JST.wrotamazowsza.pl:8543/esb-local-ezdstatus-service/http/SOAP/EZDLocalStatusWS, a nie na adres zawarty w pliku WSDL, jak dla zwykłych akcji SOAP Proxy Usługi typu SOAP Proxy Usługi typu SOAP Proxy są najpopularniejsze i polegają na przekierowaniu koperty wejściowej SOAP na inny adres endpoint. Adres endpoint jest pobierany z sekcji address zawartej w pliku WSDL usługi. Konfiguracja jest zawarta w pliku jboss-esb.xml (wewnątrz archiwum *.esb\meta-inf), usługi, gdzie w łańcuchu akcji należy podać poniższy wpis: <action name="proxy" class="org.jboss.soa.esb.actions.soap.proxy.soapproxy"> <property name="wsdl" value="classpath:///meta- INF/[PLIK_WSDL].wsdl" /> <property name="file" value="/meta-inf/https-443.properties" /> <property name="clientcredentialsrequired" value="false" /> </action> Parametry: wsdl określa lokalizację pliku WSDL z adresem endpoint proxowanej usługi file opcjonalny parametr zawierający lokalizację pliku konfiguracyjnego dla połączeń https Strona 21 z 29

22 clientcredentialsrequired opcjonalny parametr wykorzystywany dla połączeń https. Określa czy połączenie SSL wymaga clientcredentials Konfiguracja SSL usługi Konfiguracja połączenia HTTPS polega na utworzeniu pliku https-443.properties (wewnątrz archiwum *.esb\meta-inf), modyfikacji akcji SOAP Proxy lub DynamicEndpointProxyAction w łańcuchu akcji oraz zmiany protokołu w adresie endpoint. Plik https-443.properties ma poniższą składnię: # HTTP Protocol config configurators=pl.gov.epuap.protocol.config.epuapprotocol # SSLv3 socket factory protocol-socketfactory=pl.gov.epuap.protocol.factory.ssl3protocolsocketfactory # Keystore config keystore=c:/comarch/szyna_esb/jboss ga/server/all/conf/jboss.keystore keystore-passw=changeit # Truststore config truststore=c:/comarch/szyna_esb/jboss ga/server/all/conf/jboss.keystore truststore-passw=changeit # Connection config connection-timeout=1000 host-name=testeurzad-portale.wrotamazowsza.pl Parametry: configurators oraz protocol-socket-factory jest to parametr opcjonalny. Wymusza on połaczenie SSL w wersji 3. Należy go używać wyłącznie dla połączeń SSL, które udostępniają również starsze wersje protokołu SSL keystore oraz trustowe lokalizacja kontenera certyfikatów SSL keystore-passwd oraz trustowe-passws hasło do kontenerów certyfikatów connection-timeout jest to parametr opcjonalny. Definiuje maksymalny czas połączenia host-name jest to parametr opcjonalny z nazwą hosta SSL. Należy go używać wyłącznie gdy nazwa hosta jest stała, np. dla SOAP Proxy. Nie należy go używać dla DynamicEndpointProxyAction Dla usługi typu SOAP Proxy należy w pliku jboss-esb.xml dodać dodatkowe parametry file (określające lokalizację pliku z konfiguracją SSL) i clientcredentialsrequired (parametr ten określa czy połączenie SSL wymaga clientcredentials) oraz w pliku WSDL zmienić adres endpoint na protokół https Np.: Strona 22 z 29

23 <action name="proxy" class="org.jboss.soa.esb.actions.soap.proxy.soapproxy"> <property name="wsdl" value="classpath:///meta- INF/[PLIK_WSDL].wsdl" /> <property name="file" value="/meta-inf/https-443.properties" /> <property name="clientcredentialsrequired" value="false" /> </action> Dla usługi typu DynamicEndpointProxyAction należy w pliku jboss-esb.xml dodać dodatkowy parametry file (określający lokalizację pliku z konfiguracją SSL) i clientcredentialsrequired (parametr ten określa czy połączenie SSL wymaga clientcredentials) oraz zmienić parametr protocol na Np.: <action class="pl.gov.ezd.esb.custom.actions.dynamicendpointproxyaction" name="request-action"> <property name="routedestinations" value="c:/comarch/szyna_esb/jboss GA/server/all/conf/partners.properties" /> <property name="file" value="/meta-inf/https-443.properties" /> <property name="clientcredentialsrequired" value="false" /> <property name="protocol" value=" /> <property name="serviceendpointurl" value="/esb-local-ezd-status-service/http/soap/ezdlocalstatusws" /> </action> Konfiguracja WS-Security usługi Mechnizm WS-Security polega na dodawaniu elementu Timestamp oraz podpisywaniu/weryfikacji elementu Body i Timestamp koperty SOAP. Typ identyfikacji klucza jest ustawiany na: BinarySecurityToken Dodanie WSSecurity do usługi ESB polega na utworzeniu 3 plików properties z konfiguracją certyfikatów oraz dodaniu akcji do łańcucha akcji w pliku jbossesb.xml. [ESB_SERVICE.esb]/META-INF/crypto_client_check.properties weryfikacja podpisu odpowiedzi sytemu zewnętrznego oraz żądania do szyny ESB Zawartość: Atrybut org.apache.ws.security.crypto.provider org.apache.ws.security.crypto.merlin.truststore.type org.apache.ws.security.crypto.merlin.truststore.file Opis Komponent provider a Apache obsługujący kryptografię. Typ pliku repozytorium certyfikatów zaufanych. Ścieżka względna/bezwzględna do pliku. Strona 23 z 29

24 org.apache.ws.security.crypto.merlin.truststore.password timestamp.time.to.live enable.signature.confirmation Hasło do repozytorium zaufanych certyfikatów. Czas ważności znacznika czasu Potwierdzenie weryfikacji podpisu. [ESB_SERVICE.esb]/META-INF/crypto_client_request.properties konfiguracja dla podpisu żądania przesyłanego do systemu zewnętrznego Zawartość: Atrybut org.apache.ws.security.crypto.provider org.apache.ws.security.crypto.merlin.keystore.type org.apache.ws.security.crypto.merlin.file Org.apache.ws.security.crypto.merlin.keystore.alias org.apache.ws.security.crypto.merlin.keystore.password timestamp.time.to.live enable.signature.confirmation Opis Komponent provider a Apache obsługujący kryptografię. Typ pliku repozytorium certyfikatów. Ścieżka względna/bezwzględna do pliku. Alias certyfikatu z podpisem. Hasło do repozytorium certyfikatów. Czas ważności znacznika czasu Potwierdzenie weryfikacji podpisu. [ESB_SERVICE.esb]/META-INF/crypto_client_response.properties konfiguracja dla podpisu odpowiedzi z szyny ESB Zawartość: Atrybut org.apache.ws.security.crypto.provider org.apache.ws.security.crypto.merlin.keystore.type org.apache.ws.security.crypto.merlin.file org.apache.ws.security.crypto.merlin.keystore.alias org.apache.ws.security.crypto.merlin.keystore.password timestamp.time.to.live enable.signature.confirmation Opis Komponent provider a Apache obsługujący kryptografię. Typ pliku repozytorium certyfikatów. Ścieżka względna/bezwzględna do pliku. Alias certyfikatu z podpisem. Hasło do repozytorium certyfikatów. Czas ważności znacznika czasu Potwierdzenie weryfikacji podpisu. Przykładowa zawartość pliku: org.apache.ws.security.crypto.provider=org.apache.ws.security.components.cryp to.merlin org.apache.ws.security.crypto.merlin.keystore.type=jks org.apache.ws.security.crypto.merlin.keystore.password= org.apache.ws.security.crypto.merlin.keystore.alias=central-signature-key org.apache.ws.security.crypto.merlin.file=c:/comarch/szyna_esb/jboss GA/server/all/conf/esb.keystore timestamp.time.to.live=300 enable.signature.confirmation=true Strona 24 z 29

25 W łańcuchu akcji pliku jboss-esb.xml przed oraz po akcji proxującej (SOAPProxy lub DynamicEndpointProxyAction) należy dodać poniższe wpisy: <action class="com.custom.common.logging.esb.actions.systemprintln" name="echo-request1"> <property name="message" value="[esb-eurzad-proxy-pull-service] Message before RequestSignExchangeAction" /> <property name="printfull" value="false" /> <property name="level" value="debug" /> </action> <action class="pl.gov.eurzad.esb.custom.actions.requestsignexchangeaction" name="request-sign-exchange-action"> <property name="senderfilebaseuri" value="/meta- INF/crypto_eurzad_central_request.properties" /> <property name="receiverfilebaseuri" value="/meta- INF/crypto_eurzad_central_check.properties" /> </action> <action class="com.custom.common.logging.esb.actions.systemprintln" name="echo-response1"> <property name="message" value="[esb-eurzad-proxy-pull-service] Message after RequestSignExchangeAction" /> <property name="printfull" value="false" /> <property name="level" value="debug" /> </action> <action class="org.jboss.soa.esb.actions.soap.proxy.soapproxy">... </action> name="proxy" <action class="com.custom.common.logging.esb.actions.systemprintln" name="echo-request2"> <property name="message" value="[esb-eurzad-proxy-pull-service] Message after SOAPProxy" /> <property name="printfull" value="false" /> <property name="level" value="debug" /> </action> <action class="pl.gov.eurzad.esb.custom.actions.responsesignexchangeaction" name="response-sign-exchange-action"> <property name="receiverfilebaseuri" Strona 25 z 29

26 value="/meta- INF/crypto_eurzad_central_check.properties" /> <property name="senderfilebaseuri" value="/meta- INF/crypto_eurzad_central_response.properties" /> </action> <action class="com.custom.common.logging.esb.actions.systemprintln" name="echo-response2"> <property name="message" value="[esb-eurzad-proxy-pull-service] Message after ResponseSignExchangeAction" /> <property name="printfull" value="false" /> <property name="level" value="debug" /> </action> Akcja RequestSignExchangeAction jest wykonywana przed akcją proxującą z parametrami: receiverfilebaseuri wskazanie na plik konfiguracyjny do weryfikacji podpisu przychodzącego do szyny żądania senderfilebaseuri wskazanie na plik konfiguracyjny do podpisu żądania przesyłanego do systemu zewnętrznego zdefiniowanego np. w SOAPProxy Akcja ResponseSignExchangeAction jest wykonywana przed akcją proxującą z parametrami: receiverfilebaseuri wskazanie na plik konfiguracyjny do weryfikacji podpisu odpowiedzi otrzymanej od systemu zewnętrznego zdefiniowanego np. w SOAPProxy senderfilebaseuri wskazanie na plik konfiguracyjny do podpisu odpowiedzi z szyny ESB Dodatkowo zalecane jest przed oraz po akcji do tworzenia/weryfikacji podpisu dodać akcję typu com.custom.common.logging.esb.actions.systemprintln, która doda do logów z określonym poziomem logowania (parametr level) wpis z prefixem (parametr message) i aktualną kopertą SOAP Konfiguracja ról dostępowych do usługi Mechanizm dostępu do usług ESB może zostać dodatkowo rozszerzony o role. Funkcjonalność ta pozwala zdefiniować grupę usług z rolą publiczną (rola public) i prywatną (rola private) oraz ograniczyć dostęp do usługi dla wybranej roli. Mechanizm ten wymaga włączonego mechanizmu WSSecurity dla usługi. Nadanie usłudze wymagalności posiadania wybranej roli pozwoli ograniczyć dostęp do wybranej usługi wyłącznie do klientów posiadających wymaganą rolę. Strona 26 z 29

27 Konfiguracja roli usługi polega na dodaniu poniższego wpisu do pliku jbossesb.xml usługi wewnątrz sekcji service: <security modulename="esbcertlogin" rolesallowed="public" callbackhandler="pl.gov.esb.cert.callback.handler.certcallbackhandler"> </security> Wewnątrz atrybutu rolesallowed należy podać nazwę wymaganej roli. Definicja klientów i ich ról znajduje się w pliku C:\comarch\szyna_esb\ jboss GA\server\all\conf\props\roles.properties Jako nazwę systemu należy podać Common Name (CN) certyfikatu wydanego przez LCC (Lokalne Centrum Certyfikacji), który służy do komunikacji z wykorzystaniem WSSecurity z szyną ESB, natomiast po znaku równości listę ról danego systemu. Przykładowa zawartość pliku: TESTeUrzad-Portale.wrotamazowsza.pl=public TESTEURZAD-JST.wrotamazowsza.pl=public,private OSTROANDRZGWVM1.wrotamazowsza.pl=public 9. Dodanie nowej usługi ESB Dodanie nowej usługi powinno utrzymywać schemat ogólny struktury usług przedstawiony w punkcie 8.4 Schemat ogólny struktury usługi ESB. Zgodność z przygotowanymi usługami ESB zapewni poprawne wdrożenie nowej usługi oraz integrację z przygotowanymi mechanizmami wywołania, konfiguracji i zabezpieczeń na poziomie modułów bezpieczeństwa serwera JBoss. W celu wdrożenia nowej usługi na serwer należy zbudowane archiwum usługi w postaci pliku *.esb skopiować do katalogu JBOSS_HOME/server/all/deploy i zrestartować usługę sieciową serwera JBOSS. 10. Kompilacja źródeł usług ESB Źródła zostały podzielone tematycznie w zależności od przeznaczenia usług ESB. Główna klasyfikacja pozwala odróżnić usługi centralne (services-central) od lokalnych (services-local). Kolejna klasyfikacja pozwala ustalić poziom/zakres integracji, który umożliwia usługa. Strona 27 z 29

28 Szyna regionalna Zakres integracji central comarchportal eop epuap eurzad ezd gis rdp teryt wksp Szyna lokalna Zakres integracji central comarchportal eop eurzad gis plp rdp ezd teryt wksp Opis Usługi świadczone centralnie dla partnerów Integracja z aplikacją Comarch Portal w zakresie publikacji rejestrów BIP, zarządzania użytkownikami Integracja z EOP na poziomie centralnym Integracja z platformą EPUAP Integracja z EUrząd Integracja z EZD Integracja z WMS i WFS Integracja z RDP Integracja z Teryt Integracja z WKSP Opis Integracja z usługami świadczonymi przez szynę regionalną. Usługi komunikują się z centralnymi. Integracja z aplikacją Comarch Portal poprzez szynę centralną w zakresie publikacji rejestrów BIP, zarządzania użytkownikami. Usługi komunikują się z centralnymi. Integracja z EOP na poziomie lokalnym. Integracja z EUrząd na poziomie lokalnym. Usługi komunikują się z centralnymi. Integracja z WMS i WFS na poziomie lokalnym. Usługi komunikują się z centralnymi. Integracja z PLP na poziomie lokalnym. Integracja z RDP na poziomie lokalnym. Usługi komunikują się z centralnymi. Integracja z lokalnymi EZD Integracja z Teryt na poziomie lokalnym. Usługi komunikują się z centralnymi. Integracja z WKSP na poziomie lokalnym. Usługi komunikują się z centralnymi. Strona 28 z 29

29 W lokalizacji głównej ROOT źródeł znajduje się plik konfiguracyjny pom.xml grupujący moduły, które zostaną zbudowane w procesie automatycznego budowania narzędziem MAVEN. Aby zbudować z wiersza poleceń systemu operacyjnego źródła usług ESB należy przejść do głównego folderu źródeł usług ESB i wywołać polecenie: mvn -P[NAZWA_PROFILU] clean install Do działania polecenia mvn należy skonfigurować narzędzie MAVEN, ustawić zmienną środowiskową JAVA_HOME na katalog domowy JDK, dodać do zmiennej środowiskowej PATH katalog bin z Mavenem oraz posiadać dostęp do repozytoriów Maven Dostępne profile: prod profil dla środowiska produkcyjnego np.: EURZAD- ESB.wrotamazowsza.pl prodtest profil dla środowiska testowego produkcyjnego np.: TESTEURZAD-ESB.wrotamazowsza.pl preprod profil dla środowiska przedprodukcyjnego Przykład dla środowiska produkcyjnego: mvn Pprod clean install Strona 29 z 29