## Czym jest integracja i dlaczego nie jest najważniejsza?
Integracja sama w sobie nie jest pojęciem nowym. Na pewno nie należy utożsamiać integracji z pojęciem ESB. Integracja była zanim ESB stało się powszechne i będzie, kiedy ESB stanie się już niemodne, zostanie zastąpione czymś innym - nowym podejściem, inną metodyką, która na końcu będzie miała za zadanie to samo: zmuszenie do komunikacji określonej ilości systemów ze sobą. Nie umiem powiedzieć, ile lat potrzebował rynek IT w Polsce, by dojść do sytuacji, w której chyba każda większa firma prywatna czy państwowa posiada wdrożone jakieś dedykowane integracji rozwiązanie. Uwierzcie na słowo, kiedy zaczynałem swoją pracę w IT, powszechną praktyką było tworzenie aplikacji klasy JavaEE odpowiedzialnych za integrację, gdzie, żeby zintegrować CRM z Provisioningiem, tworzyło się dedykowaną aplikację w EJB instalowaną na serwerze aplikacyjnym, gdzie całą komunikację realizowało się w Java, gdzie na końcu tworzyło się dzięki Java jakiś „lepszy” interfejs wejściowy niż RMI dla naszych operacji. Często był to SOAP z wygenerowaną toną kodu w Javie. Czy było to dobre, czy złe to kwestia gustu, na pewno swój cel realizowało tak jak warstwa integracyjna w oparciu o EJB 2.0 gdzie systemy domenowe głównie bazodanowe, C++ i Cobolowe miały napisane adaptery w JNI odpowiedzialne za komunikację z usługami w EJB. To też jest integracja która działała produkcyjnie i może dalej działa.
Dlaczego zatem taki rozwój narzędzi klasy EAI a później ESB ? Pierwszy powód, to na pewno marketing, bo znacznie łatwiej jest sprzedać coś, co jest „dedykowanym produktem do realizacji integracji” niż serwer aplikacyjny z możliwością uruchomienia aplikacji w Java, które uprzednio musimy sobie napisać. Klienci często też oczekują „zamkniętego, dedykowanego narzędzia” do realizacji określonych zadań, mimo iż często z tym zamkniętym dedykowanym narzędziem musimy namęczyć się znacznie więcej niż ze stworzeniem własnego rozwiązania rękami kilku programistów, nie wspominając o kosztach. Nie jestem przeciwnikiem technologii integracyjnych, uważam iż mają sporo zalet. Dla mnie największą jest wbudowana ilość konektorów do tych wszystkich SAP-ów, CRM-ów i wielu innych systemów, dzięki czemu stworzenie i opublikowanie w organizacji usługi odpowiedzialnej za pobranie danych o kliencie z Salesforca jest bardzo szybkie i proste od strony technicznej, nie trzeba wgryzać się w specyficzne API, tracić czasu w poznanie takiego API, żeby móc korzystać z niego na poziomie nieco wyższym niż typowym podstawowym. Kilka kolejnych zalet można by wymienić, jednak nie jest tak, iż ESB jest lekiem na całe integracyjne piekło tego świata. Jest na pewno rozwiązaniem dobrym, spełniającym oczekiwania i dającym spore możliwości, ale problemem integracji samej w sobie jest to, iż z punktu organizacji nie jest najważniejsza, z punktu widzenia biznesu jest często postrzegana jako dodatkowy „koszt”, „fanaberia” bo przecież nie jest to CRM, gdzie możemy sobie wprowadzić i zarządzać klientami, nie jest to Provisioning, który ustawi nam router czy dekoder telewizji, nie jest to system transakcyjny, który „wypchnie” przelewy, więc po co to jest ? Wielokrotnie spotykałem się z takimi stwierdzeniami, pewnie nie tylko ja, ale tak czy inaczej na końcu ludzi z biznesu, którzy są „sponsorami” zmian w IT udaje się przekonać, ponieważ ostatecznie te rozwiązania pojawiły się i są powszechnie używane.
Drugim istotnym problemem samej integracji jest to, iż często pomimo szczerych chęci zrobienia jej naprawdę dobrze, zdefiniowania dobrego i przemyślanego modelu danych, stworzenia dobrze zorganizowanego katalogu usług nie jesteśmy w stanie tego zrealizować z jednej prostej przyczyny – gdy pojawiamy się z naszą nową integracją (niech to będzie nasze ESB) często zastajemy już pewien byt. Oczywiście zdarzają się projekty zupełnie nowe, gdzie cała architektura ulega zmianie, gdzie tworzymy nasz katalog usług w oparciu o nasz nowy model i w ramach większego projektu, wszystkie systemy dziedzinowe muszą się dostosować, jednak zwykle wygląda to tak, iż mamy duża firmę X z wdrożonymi systemami od X czasu, w chaotycznej architekturze często Point-to-Point, czasem próbami zrealizowania warstwy integracyjnej w oparciu np. o aplikacje JavaEE, czasem pomieszanymi podejściami i jest decyzja – wdrażamy ESB, przechodzimy na architekturę usługową. Do tego momentu jest dobrze, problemy pojawiają się wraz z presją czasu i budżetu na realizację tego projektu, gdzie nie możemy stworzyć fajnego lekkiego uporządkowanego interfejsu w podejściu REST-owym, ponieważ nasz SAP od zawsze wołał serwisy SOAP i tam „development jest drogi i nie będziemy tego zmieniać”, „model danych musi zostać, pomimo iż jest zły i źle zaprojektowany”. Taki zarys projektu zwykle krystalizuje się po pierwszych kilku tygodniach prac projektowych i wtedy już wiemy, iż pomimo tego, iż kupimy i wdrożymy rozwiązanie, które ma wiele możliwości, tak naprawdę to nie będzie istotne, ponieważ w wielu aspektach będziemy musieli zachować status obecny.
## Prosty scenariusz integracyjny w świecie nieidealnym
Omówimy teraz uproszczony scenariusz integracyjny, ale problem w nim przedstawiony jest jednym z rzeczywistych problemów, z którymi spotkamy się w realnym projekcie, w typowej firmie decydującej się na wdrożenie/tworzenie nowej warstwy integracyjnej usługowej w oparciu o system klasy ESB.
Rozważmy sytuację, w której, wdrażając ESB, chcemy stworzyć usługę pobierania danych użytkownika z systemu CRM, jako wiodącego systemu zarządzania klientami w organizacji. Mamy też stary system oparty na bazie danych z klientami, którzy nie zostali zmigrowani do CRM. Chcemy stworzyć lekką usługę REST-ową dostępną dla naszych systemów domenowych, opartą o kanoniczny model danych, którego właścicielem będzie dział integracji. Mamy jednak system, który w tej chwili jest zintegrowany dzięki SOAP, z interfejsem odbiegającym od nowego docelowego modelu. Musi on pozostać w niezmienionej formie. Wszystkie serwisy powinny wykorzystywać SSL, dodatkowo dla serwisów restowych chcemy mieć Http Basic Auth. Obecna architektura przewiduje wykorzystanie zewnętrznego load balancera, docelowa architektura będzie dodatkowo wykorzystywać Mule API Gateway, więc rozwiązanie powinno możliwie najłatwiej dać się “podpiąć” pod Mule API Gateway.
Ogólny zarys powyższej architektury przedstawia diagram poniżej. Widzimy na nim dwa systemy, SAP dostępny w ramach intranetu wykorzystujący SOAP, łączący się do ESB dzięki wewnętrznego load balancera oraz zewnętrzny system wykorzystujący usługę REST oraz load balancer dedykowany dla ruchu spoza sieci wewnętrznej. Po drugiej stronie mamy dwa systemy Salesforce zintegrowany z ESB dzięki natywnego konektora dostarczonego wraz z Mule ESB oraz nasz “stary” bazodanowy system zintegrowany przez JDBC.
W samym serwisie można wyodrębnić trzy istotne rzeczy wpływające na przebieg jego implementacji:
1. Konwersja requestu do jednolitego interfejsu: w sytuacji posiadania wymagania na publikację usługi dla dwóch różnych systemów wymagających różnych interfejsów (REST/JSON oraz SOAP) musimy wyodrębnić miejsce odpowiedzialne za realizację wszystkich operacji związanych z obsługą systemu zlecającego, takich jak mapowanie requestu do modelu ESB, ewentualne security, o ile nie możemy ich zrealizować przed ESB. W naszym przypadku aktualna architektura pozwala nam na konfigurację SSL na poziomie load balancerów, nie mamy jednak możliwości konfiguracji Http Basic Auth, będzie to zatem realizowane na poziomie przepływów Mule ESB.
1. Logika biznesowa naszego serwisu: nasze wymaganie mówi wyraźnie, w przypadku braku konta w systemie Salesforce powinniśmy podjąć próbę wyszukania go w starszym systemie bazodanowym. Dobrą praktyką jest oddzielenie operacji związanych bezpośrednio z kanałami zlecającymi od logiki która powinna być re-używana i mieć jeden wspólny interfejs.
1. Obsługa systemów domenowych odpowiedzialnych za dostarczenie danych: ostatnie główne wymaganie do naszej usługi, zapewnienie miejsca odpowiedzialnego za realizację integracji z systemami domenowymi odpowiedzialnymi za dostarczenie danych. Ponownie jak w powyższym przypadku, tak tu nie powinniśmy mieszać logiki biznesowej z realizacją integracji do systemów domenowych z jednej prostej przyczyny - kiedyś może Salesforce albo DB System zostanie zastąpiony przez inny CRM czy inną bazę danych, w takim przypadku konieczność zmian nie powinna ingerować w kod odpowiedzialny zarówno za warstwę kanałową jak i logikę biznesową serwisu, ponieważ te składowe nie ulegają zmianie.
Poniższy diagram jest prezentacją pierwszego wymagania. Widzimy na nim dwa systemy SAP i Web App. Każdy z nich wywołuje usługę dzięki innego interfejsu. Każdy z tych systemów ma dedykowaną aplikację na Mule odpowiedzialną za publikację/implementację API. W przypadku systemu SAP mamy sap-channel który jest odpowiedzialny za wystawienie SOAP API oraz późniejszą transformację requestu XML do interfejsu REST, który jest interfejsem wyjściowym dla serwisu odpowiedzialnego za realizację logiki biznesowej. System Web App korzysta z interfejsu REST oraz modelu kanonicznego (wykorzystywanego przez Mule ESB), nie ma zatem potrzeby robić transformacji, ponieważ model wykorzystywany przez Web App jest zgodny z modelem używanym przez ESB. Mamy jednak wymaganie zapewnienia HTTP Basic Auth dla aplikacji Web App i realizacja tego będzie odbywać się na poziomie webapp-channel.
Dwa kolejne wymagania to poniższy diagram. Pierwsze istotne zagadnienie to realizacja logiki biznesowej, które została wyniesiona do dedykowanej aplikacji business-account. Tak naprawdę, to właśnie w tym miejscu zaczyna się implementacja naszego realnego serwisu do pobierania konta. Aplikacja business-agreement publikuje serwis REST-owy, wykorzystując model kanoniczny. Zadaniem aplikacji kanałowych jej jej wykorzystanie, albo poprzez zwykłe wywołanie jak w Web App, gdzie nie ma konwersji protokołu, czy jak w przypadku aplikacji sap-channel, gdzie musimy dokonać konwersji z SOAP do REST. Wcześniej wspomniana logika biznesowa została “zamknięta” w ramach aplikacji business-account. W tym przypadku logika jest dość prosta, jeżeli nie znajdziemy danych użytkownika w systemie Salesforce, musimy odpytać system DB System. Zarówno Salesforce jak i DB System są systemami domenowymi, z którymi nasze ESB musi zostać zintegrowane. Podobnie jak w przypadku części kanałowej i biznesowej, tak w przypadku implementacji integracji na poziomie systemów domenowych, zostały przygotowane dedykowane aplikacje (adaptery) odpowiedzialne za integrację. Podstawowe zadanie tych aplikacji to zbudowanie requestu do systemu domenowego i jego wywołanie. W naszym przypadku wykonanie zapytania SELECT w oparciu DQL (DataSense Query Language) przy użyciu dostarczonego z Mule konektora Salesforce w przypadku salesforce-adapter oraz zapytania w języku SQL przy wykorzystaniu JDBC dla systemu Web App.
Te trzy istotne zadania implementacyjne, o których wspomniałem wyżej zostały przypisane do trzech typów aplikacji:
1. Publikacja interfejsu dla aplikacji klienckiej, konwersja protokołu, modelu danych oraz ewentualne security - aplikacje typu channel
1. Jednolity interfejs, kanoniczny model danych oraz logika biznesowa - aplikacje typu business
1. Konwersja do requestu dla systemu domenowego, wywołanie systemu oraz przemapowanie odpowiedzi do modelu kanonicznego - aplikacje typu adapter.
W przedstawionym wpisie wprowadziłem i omówiłem pojęcie integracji systemów, omówiliśmy czym jest integracja systemów i jaka jest jej relacja z narzędziami klasy ESB. W drugiej części przedstawiłem w pewnym uproszczeniu jeden z typowych scenariuszy, problemów które możemy spotkać podczas wdrożenia ESB w ramach istniejącego już IT przedsiębiorstwa. W kolejnym wpisie omówię realizację powyższego scenariusza w oparciu o Mule ESB.
### Wszystkie posty z tego cyklu:
1. [Wstęp do integracji systemów w oparciu o Mule ESB]({{ "/wstep-do-integracji-systemow-w-oparciu-o-mule-esb/" | prepend: site.baseurl }})
2. [Wstęp do integracji systemów w oparciu o Mule ESB (część 2)]({{ "/wstep-do-integracji-systemow-w-oparciu-o-mule-esb-czesc-2/" | prepend: site.baseurl }})
