Integracja systemów informatycznych

wrz 7 2010 w Artykuly przez Maciej Zbrzezny | Wyświetleń: 2 497 |

(6 głosów, średnia: 3,67 / 5)

Integracja systemów informatycznych staje się coraz istotniejsza. Coraz częściej przedsiębiorstwa wdrażają systemy „zintegrowane” i tworzące pewną spójną całość. Ponieważ w firmie w której pracuję (CAS), często mamy do czynienia z integracją systemów, a współtworzone przeze mnie oprogramowanie CommServer jest wykorzystywane do integracji, 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ć?

Wśród zagadnień najczęściej wymienianych jako te, które należy wziąć pod uwagę przy integracji systemów można wymienić:

Cele biznesowe
Sposoby dostępu do danych
Odporność na błędy
Skalowalność
Sposoby diagnozowania i utrzymania

Wymienione zagadnienia są ogólnie poprawne, choć przyznam, że według mnie wymagają uzupełnienia.

Przedstawione w tym artykule porady 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”,twórcy oprogramowania oferują różnego rodzaju sposoby dostępu do danych. Czasem może to być jakieś API, z wykorzystaniem którego można utworzyć fragment nowego oprogramowania, które posłuży do komunikacji. Jednak jak wiadomo nowe oprogramowanie może oznaczać nowe błędy, konieczność nowych, dokładniejszych testów itd… Nie zawsze jednak musi być to API, często może to być jakiś kanał komunikacyjny, który można wykorzystać. Nie zawsze trzeba programować! Czasem (jeżeli mamy szczęście) wystarczy coś skonfigurować lub doinstalować jakiś komponent komunikacyjny. Szukajmy takich możliwości i nie wybierajmy łatwiejszych tylko z pozoru.

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: