Integracja systemów informatycznych [PL]

Przeczytałem niedawno artykuł Bartka Szafko pod tytułem: „Integracja systemów”, ponieważ w firmie w której pracuję (CAS), często mamy do czynienia z integracją systemów, dlatego postanowiłem dorzucić do tego tematu swoje trzy grosze.

Jak integrować systemy informatyczne? Na co należy zwracać uwagę? Czego unikać? Jaką architekturę wybrać?

We wspomnianym artykule autor wymienił zagadnienia, które trzeba wziąć pod uwagę przy integracji systemów:

• Cele Biznesowe
• Dostęp do danych
• Odporność na błędy
• Skalowalność
• Diagnozowanie
• Utrzymanie

Zagadnienia wymienione przez autora są ogólnie poprawne, choć przyznam, że według mnie wymagają uzupełnienia. Swoją wiedzę opieram na doświadczeniach z uczestnictwa w wielu projektach, które integrowały różne systemy informatyczne (często warstwy biznesowej i produkcyjnej).

Zacznijmy więc od „dostępu do danych”, autor pisze o różnych API, które są dostępne w systemach i że jeśli takie API jest, to że trzeba je wykorzystać. Nie piesze jednak jakie API wybrać, jeżeli dostępnych jest kilka. Nie zawsze musi być to API, często jest to jakiś kanał komunikacyjny, który można wykorzystać. Nie zawsze trzeba programować! Czasem wystarczy coś skonfigurować lub doinstalować jakiś komponent komunikacyjny.

Nie zawsze trzeba programować! Wybierajmy integrację bez programowania!

Wybierajmy sprawdzone standardy komunikacyjne, zamiast tworzenia własnych rozwiązań komunikacyjnych. Naszym celem powinno być zapewnienie otwartości systemu. Otwartość systemu oznacza jego niezależność od dostawców lub operatorów zewnętrznych i jest niezbędnym elementem każdej bezpiecznej inwestycji. System otwarty to taki, który zapewnia możliwość rozbudowy.

Wybierajmy sprawdzone standardy komunikacyjne, zamiast tworzenia własnych rozwiązań komunikacyjnych.

Co możemy stosować? Według mnie stosujmy:

• Web-serwisy oparte o SOAP z precyzyjną definicją w WSDL'u
• Komunikację pomiędzy bazami danych
• Systemy kolejkowe dla wiadomości
• OPC i OPC UA zwłaszcza w celu integracji systemów warstwy biznesowej z produkcję

Stosujmy Web-serwisy (bazujące na SOAP, WSDL), komunikację bazodanową, systemy kolejkowe, OPC, OPC UA.

Unikajmy:

• Bio interfejsów, w których pewna osoba musi ręcznie pewne czynności wykonać
• Tajnych linków, które zostały wdrożone z nagłej potrzeby, których specyfikacja znana jest tylko wykonawcy, które nie wykorzystują żadnych standardów.
• Plików – w tym momencie już widzę krytyków, którzy opierają całą integracja na wszechmogących plikach, ale ja uważam, że jest to zły sposób. Korzystając z plików trudniej zautomatyzować integrację, trudniej zapewnić odporność na błędy, skalowalność itp... Jeżeli już musimy korzystać z plików, to niech to nie będą pliki typu TXT, HTML, PDF, DOC, one służą prezentacji danych (są zorientowane wizyjnie), takie pliki (dane) trudno jest przetwarzać. Czasami można wykorzystać pliki typu CSV (ang. Comma Separated Values, w których wartości rozdzielone przecinkiem - format przechowywania danych w plikach tekstowych, w których poszczególne wartości oddzielone są od siebie przecinkiem, bądź średnikiem) jednak według mnie jedynym akceptowalnym formatem plikowym jest XML, najlepiej z precyzyjnym schematem (ang. Schema), który definiuje co i jak może być przesyłane. Tutaj warto zwrócić uwagę na jeszcze jeden aspekt, mianowicie nie wyważajmy drzwi, a otwórzmy je! Najprawdopodobniej ktoś inny wymyślił już dobry schemat dla zapisu danych w tych plikach, więc wykorzystajmy to, zwróćmy uwagę na standardy jak ISA 95 i język B2MML (ang. Business To Manufacturing Markup Language).

Nie stosujmy bio interfejsów, tajnych linków i plików. Jeżeli pliki, to tylko XML z precyzyjnym schematem.

Przyjrzyjmy się teraz „odporności na błędy”. To oczywiste, że musimy zdawać sobie sprawę z tego, że błędy mogą zaistnieć, że trzeba kogoś poinformować o zdarzeniu, które ma negatywne konsekwencje. Pytanie tylko jak temu przeciwdziałać? W rozproszonej infrastrukturze, ścieżki komunikacyjne dla kluczowych obiektów powinny zostać zdublowane (redundantne) po to, aby w przypadku uszkodzenia jednej z nich nadal zagwarantować możliwość transmisji danych. Należy podkreślić, że najczęściej bezpieczeństwo to oznacza transmisję jednocześnie w obu kanałach komunikacyjnych. Skutkiem takiej transmisji jest nadmiarowość danych (dwukrotnie większa transmisja niż jest potrzebna w rzeczywistości). Oczywiście im więcej ścieżek komunikacji, tym większe bezpieczeństwo, ale tym wyższa nadmiarowość danych. Osobnym zagadnieniem jest techniczna możliwość transmisji z danym obiektem. Wiele obiektów wkomponowanych w miejską infrastrukturę nie ma zbyt wielu możliwości podłączenia do systemu. W związku z tym, projektując system, należy od razu odpowiedzieć sobie na pytanie: jaka ma być reakcja w przypadku zaniku łączności?

Kolejnym elementem bezpośrednio związanym z „odpornością na błędy” jest uwzględnienie transakcji w integrowanych systemach! W tym przypadku podejście będzie dość indywidualne, ale jakieś musi być. Dla przykładu rozważmy, co możemy zrobić, gdy integrujemy systemy w oparciu o „wszechmogące pliki”, system wczytuje taki plik i w środku jest bład. Co powinniśmy zrobić? Zignorować błąd? Odrzucić cały plik? Pamiętajmy, decyzja musi być podjęta już na etapie projektowania!

Przejdźmy teraz do „skalowalności” rozwiązania. W przytoczonym artykule autor skupił się na zagadnieniach związanych przede wszystkim z wydajnością. Ja przez skalowalność rozumiem raczej zapewnienie możliwości rozbudowy systemu, o możliwość przetwarzania innej ilości danych, możliwość dodawania kolejnych uczestników wymiany danych itp... Pamiętajmy: dziś integrujemy może tylko dwa komponenty, ale w przyszłości może pojawić się kolejny, co wtedy? Od skalowalności już bardzo blisko do architektury, ale o tym za chwile.

W tym miejscu warto wspomnieć jeszcze o jednym ważnym zagadnieniu, a mianowicie modelowaniu informacji. Informacja, która ma naturę abstrakcyjną, nie może być „sama z siebie” przetwarzana przez fizyczne urządzenia. Rolą technologii, programisty, czy inżyniera jest zapewnienie, by mogła być ona przetwarzanla. W tym celu informacja musi być reprezentowana jako zestaw konkretnych słów lub symboli. Symbole te muszą być oczywiście transferowalne poprzez kanał komunikacyjny (np. jako ciągi bitów poprzez przewód kablowy) i ostatecznie informacja powinna być odczytywalna przez ludzi (którzy mogą ją odczytywać jako ciągi znaków, symbole graficzne, itp.). Wszystkie te symbole (czy słowa) tworzą słownik (vocabulary). Dodatkowo, aby zapewnić powiązania pomiędzy informacją, a jej reprezentacją należy jeszcze zapewnić składnię i semantykę. Składnia definiuje reguły używania słów, a semantyka mapuje zestawy słów (zdania) na określoną informację. W tym przypadku rola Integratora jest dość trudna, najprawdopodobniej każdy z integrowanych systemów ma swój model informacyjny, a integrator musi to uwspólnić, spowodować, by ta sama informacja znaczyła to samo w każdym systemie!

Ta sama informacja musi mieć to samo znaczenie w każdym systemie!

Zagadnienie szczególnie: Integracja systemów automatyki / systemów produkcji

Powyższe informacje dotyczyły ogólnych zagadnień związanych z integracją systemów informatycznych, teraz chciałbym uzupełnić pewne informacje odnośnie integracji systemów związanych z produkcją i automatyką przemysłową. W tym przypadku należy do wymienionych wcześniej zagadnień i zaleceń dodać (źródło: Baza wiedzy wortalu CommServer):

• Dotrzymanie limitów dla opóźnień czasowych. Każda technologia komunikacyjna posiada techniczne limity przepustowości transferu danych. Im więcej systemów korzysta z danej technologii (medium) komunikacji i im więcej transferują one danych, tym większe będą opóźnienia transmisji danych. Oczywiście poziom dopuszczalnych opóźnień zależy od specyfiki procesu produkcyjnego, ale dla każdego przypadku przekroczenie pewnego poziomu będzie oznaczać degradację funkcji systemu.
• Konieczność korzystania z różnorodnych mediów komunikacyjnych. Ciągły rozwój technologii komunikacyjnych oraz rynku usług telekomunikacyjnych, a w szczególności wycofywanie starych technologii, stanowi poważne zagrożenie dla funkcjonowania systemu w przyszłości, jeśli będzie on nierozerwalnie związany z technologią komunikacyjną. Zatem jedyną skuteczną metodą ochrony systemu jest zapewnienie możliwości zmiany technologii łączności w systemie.
• Konieczność pozyskiwania danych w różnych standardach komunikacyjnych – protokołach. Różne komponenty systemów posługują się różnymi „językami komunikacji”, tzw. protokołami komunikacyjnymi. Aby system umożliwiał dalszą rozbudowę, należy zapewnić możliwość podłączania różnych komponentów i obsługę różnych protokołów komunikacji.
• Jednolity model prezentacji danych. Większość systemów pozyskuje i prezentuje dane wyłącznie na swoje potrzeby. Oznacza to w praktyce potrzebę transferu tych samych danych przez infrastrukturę komunikacyjną tyle razy, ile systemów ich potrzebuje. Zatem cechą efektywnego systemu automatyki jest oddzielenie transferu danych od ich przetwarzania i publikowania pozyskiwanych danych, w jednolity sposób, by mogły być wykorzystane przez różne systemy.

Architektura

Ważnym zagadnieniem jest architektura wykorzystywana w integracji. Może się to wydawać na pierwszy rzut oka dziwnym stwierdzeniem, ale według mnie nigdy nie należy patrzeć na integrację z punktu widzenia tylko dwóch systemów. Lepiej zobaczyć, jakie ma ona znaczenie dla całego przedsiębiorstwa. Nie łączmy systemów jak popadnie, jak nam wygodniej, popatrzmy szerzej, by nie doprowadzić do chaosu i w konsekwencji (źródło: artykuł „6 grzechów chaosu” w bazie wiedzy wortalu CommServer):

• trudnej rozbudowy,
• niskiej wydajności,
• dużych kosztów łączności
• niespójności,
• bałaganu i braku dokumentacji,
• anarchii.

Unikajmy też super systemów pochodzących od jednego dostawcy, które później trudno integrować (źródło: artykuł: „Centralizacja zamiast Integracji” w bazie wiedzy wortalu CommServer). Implementacja pewnej platformy zarządzania nie jest zadaniem krótkoterminowym. Biorąc pod uwagę konieczność wieloletniej eksploatacji supersystemów, należy liczyć się z następującymi konsekwencjami ich wdrożenia:

• Wysokie nakłady na wdrożenie totalitarnego super systemu.
• Zastanówmy się czy jesteśmy w stanie utracić dotychczasowe inwestycje, w przypadku chęci wdrożenia nowej funkcjonalności lub w przyszłości w przypadku wycofania super systemu z rynku?
• Monopolizacja roli dostawcy.
• Czy supersystem istnieje?

Zamiast wspomnianych wcześniej chaosu i centralizacji lepiej przy integracji używać dodatkową warstwę standaryzującą wymianę danych, do przykładów takich architektur zaliczyć można:

• Obserwator procesu, na przykład na bazie CommServer
• architektury i platformy typu ESB, czyli Enterprise Service Bus

Zapraszam do dyskusji w komentarzach!