REDAKTOR CENTRUM
Piotr Waszczuk, redaktor Centrum Wiedzy erpstandard.pl czeka na Państwa komentarze i opinie dotyczące serwisu.
reklama
reklama
reklama
WHITEPAPERS
VSoft
Obieg dokumentów. VSoft SA - case study
Firma VSoft SA stanęła przed problemem coraz większej ilości otrzymywanych i wysyłanych dokumentów, w tym faktur kosztowych. Rozbudowana struktura oraz konieczność ciągłej weryfikacji i akceptacji ponoszonych kosztów czyniły obieg faktur w formie papierowej procesem kosztowym i czasochłonnym. I wtedy pojawił się VIMS.
powiększ tekst 
ARCHIWUM
Integracja á la carte
8 maja 2006
Jakub Chabik W integracji aplikacji pada dziś nowe pytanie. Wcześniej stawiane ''czy już czas na SOA?'' coraz częściej zastępowane jest pytaniem ''jak wdrożyć SOA?''. Razem ze zmianą pytania zmienia się jego adresat: dziś nie jest nim już menedżer, a architekt systemów.Computerworld — Wdrożenie SOA w przedsiębiorstwach dotychczas postępowało dość wolno głównie ze względu na niepewność efektu. Cały problem w tym, że migracja w kierunku architektury opartej na usługach przypomina podróż z nieznanego w nieznane z przewodnikiem, który niewiele ma do pomocy poza własną wiedzą i doświadczeniem.
Koszty takiej podróży mogą się różnić o rząd wielkości w zależności od przyjętej strategii integracji oraz prawidłowego określenia stanu aktualnego i docelowego. Rzadko które przedsiębiorstwo posiada dobrze udokumentowaną bazę konfiguracji zawierającą kompletny opis architektury technicznej i aplikacyjnej. Do tego cel pozostaje ruchomy - bo wdrożenie SOA to zwykle przedsięwzięcie rozłożone na lata, a technologia w tym czasie zmienia się nieustannie.
Jak widać z powyższego, SOA znaczy duże ryzyko. Ryzyko to można minimalizować poprzez określenie strategii architektury korporacyjnej (enterprise architecture) i oparcie jej na wzorcach (enterprise architecture patterns).
Architektura a style integracji Przypomnijmy cztery zasadnicze style integracji:
- wymiana plików,
- dzielona baza danych,
- wywoływanie zdalnych procedur,
- przekazywanie wiadomości (komunikatów).
Dwa pierwsze modele integracji uważane są już za raczej archaiczne. Ich wady to niewielka elastyczność i wynikające z niej wysokie koszty utrzymania. Model pierwszy grzeszy także opóźnieniami: przesyłanie plików pomiędzy systemami z reguły wymaga sekwencyjnych przetwarzań wsadowych, co w przypadku wielu systemów wydłuża okres nieaktywności związany z tzw. oknem przetwarzań (batch window). Wadą rozwiązania trzeciego jest konieczność, by każdy system wiedział o wszystkich, które ma wywołać; dodanie nowej usługi do całej infrastruktury wymaga "powiadomienia" wszystkich o nowych interfejsach. Drugi minus to stosowanie przede wszystkim komunikatów synchronicznych; w przypadku wolnych połączeń lub niskiej dostępności aplikacja wołająca procedurę innego systemu po prostu zatrzymuje swoje działanie, czekając na wykonanie komendy przez zdalny komputer.
Integracja oparta na przesyłaniu komunikatów stara się odpowiedzieć na wszystkie problemy trzech wcześniejszych modeli. Przede wszystkim "rozrywa" nadawcę i odbiorcę, uniezależniając ich wzajemnie od formatów danych i protokołów wołania funkcji. Po drugie, zapewnia, że aplikacja z jednej strony zawsze będzie miała dokąd wysłać komunikat - niezależnie od tego, czy zdalny system jest fizycznie osiągalny czy nie (jeśli nie, broker po prostu przechowa komunikat i doręczy go kiedy odbiorca "wstanie"). Poza tym może dostarczyć ten sam komunikat do wielu odbiorców. To właśnie z powodu tych cech integracja oparta na komunikatach i magistrali usług uznawana jest za najbardziej obiecujący styl integracji systemów. Ale do naprawdę dojrzałej i skutecznej integracji potrzeba wzorców.
Wzorce, czyli menu rozwiązań
Pojęcie wzorca (pattern) pochodzi z głośnej książki Christophera Alexandera "The Timeless Way of Building". Wzorzec stanowi uniwersalne, sprawdzone w praktyce rozwiązanie często pojawiającego się problemu. Christopher Alexander twierdził, że wzorzec definiowany jest przez trzy elementy: system sił (opisanie celu, problemu i czynników, które należy wziąć pod uwagę), rozwiązanie (konstrukcja, która wyraża najlepsze zrównoważenie sił lub oferuje najlepsze osiągnięcie celu przy założonych czynnikach) oraz kontekst (opis warunków zewnętrznych, w których rozwiązanie dobrze funkcjonuje). Wzorce stanowią język opisu typowych problemów i ich rozwiązań.
Informatykom wzorce najlepiej znane są z książki "Wzorce projektowe". Elementy oprogramowania wielokrotnego użytku autorstwa tzw. bandy czworga (E. Gamma, E. Helm, R. Johnson, J. Vlissides, wydanie polskie WNT 2005). Nie ma chyba firmy software'owej, gdzie ta książka nie stałaby na półce albo wręcz leżała na biurkach informatyków. Nie ma chyba produktu informatycznego, w którym nie zostałyby zastosowane wzorce projektowania. Ten sam paradygmat zastosowany do architektur systemów operacyjnych pozwoli w sposób systematyczny podejść do "rozplątywania spaghetti", jakim jest architektura systemów informatycznych we współczesnych przedsiębiorstwach.
Omówmy kilka najważniejszych wzorców integracji, aby "poczuć" informację, jaką z sobą niosą dla architekta:
Przełącznik oparty na zawartości (content-based router) to rozwiązanie, które przekazuje otrzymaną wiadomość do odpowiedniego adresata w zależności od jej zawartości. Nadawca, wysyłając komunikat do magistrali usług, nie wie, kto ostatecznie ją obsłuży (na tym m.in. polega wyższość stylu integracji opartego na komunikatach nad wołaniem procedur zdalnych). To przełącznik oparty na zawartości (funkcję tę powinien spełniać element brokera komunikatów) dostarczy ją do właściwego systemu, gdzie zostanie prawidłowo obsłużona.
Wydawca-prenumerator (Publisher-subscriber) - analogia tego wzorca do gazet i rynku wydawniczego bardzo dobrze ilustruje jego funkcjonalność. Wydawca publikuje pewną informację nie wiedząc, kto jest zainteresowany jej otrzymaniem. Odbiorcy mogą "zaprenumerować" informacje określonego rodzaju, rejestrując się w serwisie. Z tego wzorca korzystają w niektórych krajach narodowe systemy ewidencji ludności (takie jak PESEL) - gdy ktoś przeprowadzi się, nie musi informować wszystkich, którzy potrzebują jego adresu (np. urzędów, banków, operatorów telefonicznych) - a jedynie poinformować "wydawcę", który zadba już o to, by "prenumeratorzy" otrzymali uaktualniony adres.
Komunikat o czasowej ważności (message expiration) - ten wzorzec używany jest do oznaczania skończonej trwałości komunikatu. Dobrym przykładem są komunikaty o transakcjach giełdowych. Ich trwałość można określić albo poprzez warunek czasowy (np. tylko do zamknięcia sesji giełdowej danego dnia) lub warunek cenowy (tylko powyżej pewnej ceny). Oryginalny wzorzec kieruje wiadomości wygasłe (expired) w tzw. martwy kanał, aby były tam dostępne ewentualnie w celach audytowych.
Metryczka (routing slip) - to w pewnym sensie instrukcja obsługi danego komunikatu przez inne systemy. Na przykład informacja o zamówieniu od klienta wygenerowana przez system sprzedaży online powinna najpierw być przetworzona przez system magazynowy, potem logistyczny i na końcu księgowy. Otóż podczas projektowania każdego z tych czterech systemów nie musieliśmy wiedzieć, jakie zamówienia będą przychodzić i w jakiej kolejności będą przetwarzane. Dopiero w platformie integracyjnej podejmujemy tę decyzję, dołączając metryczkę do komunikatów.
Obejście (detour) - wzorzec integracyjny potrzebny w szczególności na etapie konstrukcji i zmiany systemu, kiedy np. system jest nieaktywny, ale musimy "udawać", że nadal jego usługi są dostępne w magistrali. Obejście przyda się także do testowania systemu, gdy chcemy np. komunikaty poddać analizie w celu sprawdzenia, czy integracja działa prawidłowo.
wydrukuj
Komentarze
Ten artykuł nie ma jeszcze żadnych komentarzy. Twój może być pierwszy...
