Prezentacja z WJUG 224

1. Integracja systemów
od strony praktycznej
Autor: Marek Horbań
Kontakt: mahh@interia.pl

2. Czym będzie ten wykład?
 Podzielenie się swoimi doświadczeniami
o integracji systemów
 Co oznacza „od strony praktycznej”?
- praktyczne uwagi w odniesieniu
do styli i wzorców
- problemy, błędy z praktyki
- dobre praktyki
 Czego nie będzie?
- warsztat
- case studies

3.  Czym jest integracja systemów
 Style integracji
 Wzorce integracji
 Apache Camel i inne technologie
 Przykład – Camel route
 Projekt integracji – co powinien zawierać
 Typowe problemy w integracji
 Błędy popełniane w integracji

4. Czym jest integracja systemów i
dlaczego jest trudna w realizacji

5. Integracja systemów to połączenie ze sobą co najmniej
dwóch niezależnych systemów dziedzinowych w taki
sposób, aby mogły wymieniać ze sobą dane lub usługi.

6. Integracja systemów to połączenie ze sobą co najmniej
dwóch niezależnych systemów dziedzinowych w taki
sposób, aby mogły wymieniać ze sobą dane lub usługi.
Integracja systemów nie jest tematem nowym jednak wciąż
pozostaje w centrum zainteresowania IT.

7. Jest to obszar trudny, gdyż:
 dziedziczy wszystkie problemy systemów rozproszonych

8. Jest to obszar trudny, gdyż:
 dziedziczy wszystkie problemy systemów rozproszonych
 połączenie często nieprzystających technologii lub
procedur biznesowych

9. Jest to obszar trudny, gdyż:
 dziedziczy wszystkie problemy systemów rozproszonych
 połączenie często nieprzystających technologii lub
procedur biznesowych
 czynnik ludzki – uzgadnianie, implementacja i testy muszą
się odbywać w porozumieniu z niezależnymi osobami /
firmami (opóźnienia)
Estymata wdrożenia integracji powinna to uwzględniać

10. Style integracji
File transfer
- wciąż bardzo popularne
- uniwersalne ze względu na zapis w systemie plików
- odpowiednie przy bardzo dużych danych
- potencjalnie kosztowne

11. Shared database
- nie zawsze możliwe - security jest problemem
- bardzo wydajne dla dużych danych
- najmniej kłopotliwe w utrzymaniu
- bezpośrednio (dblink) lub z użyciem magistrali danych
- silnie wiązanie systemów
- Oracle DB z AQ (Advanced Queuing) dopełnia możliwości

12. Remote Procedure Invocation (RPC)
RMI, SOAP (webservices) i inne
- dość skomplikowany
- synchroniczny (async jest kłopotliwe)
- RMI – wspiera transakcje rozproszone
- SOAP wciąż bardzo popularny, standard kontraktu -
WSDL

13. REST Representational State Transfer
- najpopularniekszy styl architektoniczny (z JSON i HTTP)
- bezstanowy, synchroniczny
- oparty na reprezentacji zasobów
- Swagger (OpenAPI)

14. Messaging
- podejście „wyślij i zapomnij”
- komunikacja asynchroniczna – luźne wiązanie systemów
- JMS (Java Message Service)
- EIP, Apache Camel
- dość złożone
- nieodpowiednie dla „real time”

15. Wzorce integracji
EIP – Enterprise Integration Patterns
 Enterprise Integration Patterns, Gregor
Hohpe, Bobby Woolf
- biblia nie tylko wzorców integracji, ale
identyfikująca podstawowe abstrakcje i
charakterystyki integracji, wydane w
2004 roku!
 Książka „zaimplementowana” niemal w
całości przez Apache Camel i Spring
Integration

16. Message Routing

17. Podstawowe abstrakcje integracji typu
messaging
 Channel, message, endpoint

18. Podstawowe abstrakcje integracji typu
messaging
 Exchange
- Event message – inOnly
- Request Reply – inOut

19. Wybrane wzorce integracji
 Pipes and filters
- sekwencja filtrów i procesorów
- główny wzorzec konstruowania route’y

20. Wybrane wzorce integracji
 Message router i content based router
- sterowanie przez header / content wiadomości
- istnieje też dynamic router – dynamiczny endpoint
końcowy

21. Wybrane wzorce integracji
 Splitter
- dzieli jedną wiadomość na wiele osobnych

22. Wybrane wzorce integracji
 Aggreagator
- najbardziej złożony wzorzec Camel
- stanowy
- wymaga m. in. correlation key, aggregation strategy oraz
completion size/timeout/predicate

23. Wybrane wzorce integracji
 Message broker
- centralna konfiguracja integracji
- jednolite reguły bezpieczeństwa
- może być wąskim gardłem

24. Wybrane wzorce integracji
 Message bus (ESB)
- model kanoniczny – jedna implementacja reguł
biznesowych
- łączy wiele systemów wej/wyj za pomocą adapterów
- można włączać/odłączać systemy

25. Apache Camel i inne popularne
technologie integracji
 Implementacje EIP
- Apache Camel
- Spring Integration
 Enterprise Service Bus (ESB)
- Mule ESB
- Apache ServiceMix (ActiveMQ, Camel)
- IBM Integration Bus
 Implementacje kolejek i nie tylko
- Active MQ (included Camel)
- IBM MQ
- RabbitMQ (message broker)

26. Apache Camel - wprowadzenie
Apache Camel jest lekką (camel core
to tylko 5MB) biblioteką opensource
implementującą EIP. Oprócz tego
dostarcza ponad 200 adapterów do
różnych
protokołów/interfejsów/systemów.
Posiada kilkadziesiąt konwerterów
formatów. Nie potrzebuje żadnego
serwera do działania. Świetnie
integruje się zarówno ze Spring jak i
CDI.

27. Apache Camel główne koncepcje

28. Apache Camel główne koncepcje
routes – fluent builder (lub XML)

29. Apache Camel główne koncepcje
- components
- endpoint consumer i producer
- consumer standardowy i poll consumer

30. Camel – przykład route’y
Pełen przykład na: https://github.com/mahhoz/camel-twitter
public class TwitterSearchRoute extends RouteBuilder {
private String searchTerm = "Poland OR Polska";
private String outputFileEnglish = "C:/out/en";
private String outputFilePolish = "C:/out/pl";
private String outputFilethers = "C:/out/others";
@Override
public void configure() throws Exception {
// setup Twitter component
TwitterSearchComponent tc = getContext().getComponent("twitter-search",
TwitterSearchComponent.class);
//removed component configuration ...
TwitterSearchEndpoint twitterEndpoint = (TwitterSearchEndpoint) tc.createEndpoint("twitter-
search://" + searchTerm);
twitterEndpoint.setDelay(4000);
// poll twitter search for new tweets
from(twitterEndpoint)
.to("log:tweet")
.process(new TwitterSearchProcessor())
.filter(onlyWellKnownUserPredicate(200))
.choice() //content base router
.when(langPredicate("PL"))
.to(getFileEndpoint(getContext(), outputFilePolish))
.when(or(langPredicate("EN"), langPredicate("EN-GB")))
.to(getFileEndpoint(getContext(), outputFileEnglish))
.otherwise()
.to(getFileEndpoint(getContext(), outputFileOthers))
.end();
}
//removed implementation of predicates...

31. public class AnonymizedRoute extends RouteBuilder {
public static final String DIRECT_URI = "direct:service1";
private static final String OUT_SERVICE_URI = ServiceUriBuilder.cxfUri()
.withProtocolProperty(Properties.PROTOCOL)
.withHostProperty(Properties.HOST)
.withPortProperty(Properties.PORT)
.withPathProperty("servicePath")
.build();
@EndpointInject(uri = "string-template:ws/templates/anonymized.xml")
private Endpoint stringTemplate;
@Override
public void configure() throws Exception {
Endpoint outEndpoint = CxfEndpointBuilder.createCxfEndpoint(getContext(),
OUT_SERVICE_URI)
.withEndpointConfigurer()
.withUsernameAndPassword()
.withStandardProperties(AnonymizedService.class)
.build();
// Set up general validation exception handling
onException(ValidationException.class)
.handled(true)
.setHeader(Exchange.HTTP_RESPONSE_CODE, constant(SC_BAD_REQUEST))
.setHeader(Exchange.CONTENT_TYPE, constant("text/plain"))
.setBody(exceptionMessage())
.to(loggerEndpointFor(SYSTEM, ERROR).build());

32. // Set up rest configuration for these services.
restConfiguration().component("jetty").host("{{" +
CommonProperties.LOCAL_REST_HOST + "}}")
.port(CommonProperties.LOCAL_REST_INTERNAL_PORT).bindingMode(RestBindingMode.off);
rest(ROOT)
.post("incomePath").route()
.to(DIRECT_URI)
.routeId(this.getClass().getName())
.autoStartup(true)
.endRest();
from(DIRECT_URI).streamCaching()
//convert message json -> xml
.unmarshal().json(Jackson, RequestMessage.class)
.to("bean-validator:validator")
.to(stringTemplate)
.removeHeaders("*")
.marshal().jaxb(true)
.process(new StringToCxfPayloadDispatcher())
.setHeader(OPERATION_NAME, new SimpleExpression("operation"))
.to(outEndpoint)
//convert message xml -> json
.bean(ResponseMessageConverter.class)
.marshal().json(Jackson, ResponseMessage.class)
.removeHeaders("*");
}
}

33. Projekt integracji – dlaczego ważny
 W którym miejscu integracji jesteśmy i co z tego wynika
- oba integrowane systemy oraz komponent integracji jest
naszą / firmy własnością
- jeden z systemów jest naszą własnością i próbujemy
zintegrować się z drugim
- jesteśmy tylko integratorem – nie mamy wpływu na
integrowane systemy

34. Projekt integracji – dlaczego ważny
 Dlaczego projekt integracji jest tak ważny?
- potencjalnie duża liczba stron
- projekt integracji jest jedną z najczęściej czytanych
dokumentacji
- wersjonowanie
- aprobata stron

35. Projekt integracji – co powinien
zawierać
 Cel
 Opis

36. Projekt integracji – co powinien
zawierać
 Cel
 Opis
 Wskazanie systemu inicjującego
 Mapowanie modeli (osobny załącznik)

37. Projekt integracji – co powinien
zawierać
 Cel
 Opis
 Wskazanie systemu inicjującego
 Mapowanie modeli (osobny załącznik)
 Diagram sekwencji
 Opis kroków (opcjonalnie)

38. Projekt integracji – co powinien
zawierać
 Cel
 Opis
 Wskazanie systemu inicjującego
 Mapowanie modeli (osobny załącznik)
 Diagram sekwencji
 Opis kroków (opcjonalnie)
 Obsługa błędów!
- kto jest odpowiedzialny
za rozwiązanie błędnych sytuacji

39. Projekt integracji – co powinien
zawierać
 Cel
 Opis
 Wskazanie systemu inicjującego
 Mapowanie modeli (osobny załącznik)
 Diagram sekwencji
 Opis kroków (opcjonalnie)
 Obsługa błędów!
- kto jest odpowiedzialny
za rozwiązanie błędnych sytuacji
 Security

40. Projekt integracji – co powinien
zawierać
 Cel
 Opis
 Wskazanie systemu inicjującego
 Mapowanie modeli (osobny załącznik)
 Diagram sekwencji
 Opis kroków (opcjonalnie)
 Obsługa błędów!
- kto jest odpowiedzialny
za rozwiązanie błędnych sytuacji
 Security
 Wolumetria!

43. Typowe problemy integracji
 Wydajność
- łatwa skalowalność bezstanowych aplikacji
- Apache Kafka – superwydajny message broker
- protokoły binarne?
- a może streaming zamiast messaging (Spark
Streaming, Flink)

44. Typowe problemy integracji
 Transakcyjność
- XA transaction największa gwarancja w
rozproszonych systemach, wspierana przez RMI,
JMS (w pewnej mierze)
- jak zapewnić możliwie najwyższą gwarancję
transakcji w rozproszonym systemie?
- przykład systemu bankowego i przelewów

45. Typowe problemy integracji
 Idempotentność
- obsługa messageId w systemie docelowym
- wsparcie Camel - Idempotent Consumer wraz z
IdempotentRepository opartym na memory, file,
jdbc, jpa i inne

46. Typowe problemy integracji
 Synchroniczność / asynchroniczność
- kolejki (JMS)
- Camel – komponent SEDA
- w ograniczonych warunkach można zbudować
symulację synchroniczności

47. Typowe problemy integracji
 Zarządzanie konfiguracją
- jedna integracja może mieć od 10 do
kilkudziesięciu parametrów
- narzędzia: puppet, docker

48. Typowe problemy integracji
 Zarządzanie konfiguracją
- jedna integracja może mieć od 10 do
kilkudziesięciu parametrów
- narzędzia: puppet, docker
 Mapowania modeli
- przy dużej ilości mapowań - MapStruct.

49. Błędy popełniane w integracji
 Zbyt obszerne usługi

50. Błędy popełniane w integracji
 Zbyt obszerne usługi
 Ograniczenia architektoniczne pogarszające wydajność

51. Błędy popełniane w integracji
 Zbyt obszerne usługi
 Ograniczenia architektoniczne, pogarszające wydajność
 Bardzo sztywne wiązanie między systemami

52. Błędy popełniane w integracji
 Zbyt obszerne usługi
 Ograniczenia architektoniczne, pogarszające wydajność
 Bardzo sztywne wiązanie między systemami
 Niewłaściwe użycie stylu integracji RPC lub messaging
dla bardzo dużej ilości danych

53. Błędy popełniane w integracji
 Zbyt obszerne usługi
 Ograniczenia architektoniczne, pogarszające wydajność
 Bardzo sztywne wiązanie między systemami
 Niewłaściwe użycie stylu integracji RPC lub messaging
dla bardzo dużej ilości danych
 Implementacja integracji oparta na własnych
rozwiązaniach zamiast użyć dedykowanych technologii
jak Camel

54. Błędy popełniane w integracji
 Zbyt obszerne usługi
 Ograniczenia architektoniczne, pogarszające wydajność
 Bardzo sztywne wiązanie między systemami
 Niewłaściwe użycie stylu integracji RPC lub messaging
dla bardzo dużej ilości danych
 Implementacja integracji oparta na własnych
rozwiązaniach zamiast użyć dedykowanych technologii
jak Camel
 Użycie niestandardowych technologii / protokołów

55. Błędy popełniane w integracji
 Zbyt obszerne usługi
 Ograniczenia architektoniczne, pogarszające wydajność
 Bardzo sztywne wiązanie między systemami
 Niewłaściwe użycie stylu integracji RPC lub messaging
dla bardzo dużej ilości danych
 Implementacja integracji oparta na własnych
rozwiązaniach zamiast użyć dedykowanych technologii
jak Camel
 Użycie niestandardowych technologii / protokołów
 Zbyt skomplikowana, błędogenna sekwencja integracji

56. Przykład zbyt skomplikowanej sekwencji

57. Dziękuję za uwagę!
Pytania?