Obecnie integracja polegająca na wymianie plików brzmi jak rozwiązanie z ubiegłego wieku. W dobie mikroserwisów i rozwiązań chmurowych, wydawać by się mogło, że nikt nie stosuje już takich rozwiązań. Doświadczenie pokazuje jednak, że jest przeciwnie. Od kilku lat pracuję przy projekcie dla dużej firmy o zasięgu międzynarodowym, która jako główny kanał wymiany informacji, między systemami swojej grupy kapitałowej, uznaje plik. Standard jaki opracowali doczekał się już wersji 4.0, jego specyfikacja liczy ponad sto stron i uwzględnia każdy możliwy rodzaj informacji biznesowej składający się na ich procesy. Jak więc widać opisanie takiego stylu integracyjnego jest jak najbardziej uzasadnione.
Zastanówmy się na początek jakie są korzyści z stosowania plików jako stylu integracyjnego. Na pierwszy rzut oka wydawać by się mogło , że rozwiązanie to nie ma plusów. Jednak zaraz spróbuję dowieść, że jest inaczej.
Komunikacja asynchroniczna
Jak przekonują Gregor Hohpe i Bobby Woolf w swojej książce „Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions” asynchroniczna integracja ma znaczną przewagę nad integracją synchroniczną. Wymiana plików należy do pierwszej grupy. Aplikacja produkująca plik umieszcza go we ustalonym miejscu, a po skończonej akcji przechodzi do realizacji kolejnych działań bez konieczności oczekiwania na odpowiedź z systemu konsumującego plik. Jeśli przekazanie odpowiedzi przez system konsumujący plik jest niezbędne, należy zaimplementować to również w sposób asynchroniczny. Taki model komunikacji wpisuje się, w aktualnie popularny trend reaktywny. Marnowanie cykli procesora na bezczynne oczekiwanie jest marnotrawstwem mocy obliczeniowej oraz puli połączeń.
Luźno powiązane systemy (ang. loosely coupled systems)
Luźne powiązanie to jedna powszechnie znanych dobrych praktyk wytwarzana oprogramowania, mająca swoje zastosowanie tak to klas, pakietów i komponentów pojedynczego systemu, jak i do integracji całych systemów. Niezależne elementy powinny mieć jak najmniejszą wiedzę o szczegółach implementacyjnych innych komponentów, natomiast dostępność funkcji jak i całych systemów powinny być jak najmniej uzależnione od dostępności innych integrowanych systemów. Komunikacja asynchroniczna z użyciem pików realizuje tą dobrą praktykę w stu procentach. Aplikacja generując pliki może realizować swoją logikę niezależnie od tego, czy system konsumujący w danej chwili pracuje czy nie. Pliki zakolejkują się we wskazanej lokalizacji na dysku i będą tam czekać, aż zostaną podjęte przez inny system. Również system konsumujący może przetwarzać pliki wyprodukowane przez inny system niezależnie od tego, czy w danym momencie jest on aktywny czy nie.
Ponowienie importu
Wyobraźmy sobie sytuację, kiedy to system importujący plik nie był w stanie przetworzyć poprawnego pliku z powodu wewnętrznych problemów (przykładowo chwilowa niedostępność bazy danych). Ponowienie importu jest, w przypadku plików, banalnie proste. Wystarczy (o ile system jest poprawnie zaimplementowany) ponownie przetworzyć ten sam plik. Wyobraźmy sobie sytuacje, gdzie z tego samego powodu niepowodzeniem kończy się kilkaset synchronicznie wykonanych requestów do web serwisu. W naprawienie sytuacji zaangażować się muszą obydwa integrowane systemy. W przypadku integracji asynchronicznej przez pliki system, który wygenerował plik, nawet nie musi sobie zdawać sprawy z chwilowej niedostępności drugiego z systemów.
Tak wiec, nie takie te pliki zacofane jak by się mogło wydawać. W kolejnych postach postaram się opisać jakie tematy będzie miał do zaadresowania architekt/developer, który zdecyduje się (lub zostanie zmuszony) użyć plików jako medium wymiany danych miedzy systemami.