Inicjowanie – „Zapomnij” lub „Poczekaj”

Załóżmy, że w systemie cyklicznie jest uruchamiany określonego dnia i godziny proces ładowania danych z systemów dla Hurtowni Danych. W mechanizmie inicjowanym o określonej porze (tzw. Scheduler) następuje weryfikacja, czy są do wykonania procesy ładowania danych. Jeżeli taki proces istnieje, jest uruchamiany. Poniższy diagram w BPMN przedstawia sytuację, gdy następuje uruchomienie procesu ETL (ang. Extract, Transform, Load) pobierającego dane z bazy danych i po przetworzeniu umieszczającego je w Hurtowni danych. Proces ETL składa się z 3 etapów – Pobierania danych (ang. Extract), Przetwarzania (ang. Transform) oraz Ładowania (ang. Load) do Hurtowni. W każdym z tych etapów są wykonywane zaplanowane czynności. Dla przykładu przedstawiono kilka kroków z procesu Pobierania danych.

Wróćmy jednak do tytułu – „Zapomnij” lub „Poczekaj”. Tytuł sygnalizuje dwa wzorce postępowania możliwe do wykorzystania w ramach procesów i realizowanych czynności w ramach procesu. Zapomnij wskazuje na wzorzec Fire and Forget (Strzel/Uruchom i Zapomnij), który oznacza, że proces inicjujący działanie lub inny proces nie czeka na jego zakończenie, wynik działania. Z kolei Poczekaj wskazuje na inny wzorze – Request-Response (Zażądaj Odpowiedzi), który polega na oczekiwaniu na odpowiedź z wykonania procesu, czynności, czy usługi. Obydwa wzorce są wykorzystywane w systemach informatycznych. Pierwszy z nich, jest specyficzny dla długich procesów, związanych z przetwarzaniem danych, z czasami nieokreślonym czasem trwania i niemożliwym wręcz do zdefiniowania tzw. timeoutem.

Na powyższym diagramie komunikat „Uruchom proces ETL” jest odpalany bez oczekiwania na odpowiedź przez Harmonogram. Drugi ze wzorców został natomiast zasygnalizowany poprzez komunikaty „Q” i „A” przy poszczególnych krokach procesu Extract. Jest on specyficzny dla czynności, dla których musi wrócić odpowiedź do inicjatora – odpytanie o dostępność („DB”), odpytanie o wielkość („WD”) oraz odpytanie o dane („DZ”). Z czynnościami opartymi o wzorzec Request-Response jest silnie związania obsługa błędów oraz statusów.

Reklama

Komunikacja osmotyczna = wzorzec publish/ subscribe?

Poprzedni wpis dotyczący komunikacji osmotycznej został skomentowany na innym blogu („Komunikacja osmotyczna czyli po Brzytwie przypadków użycia” na it-consulting.pl/blog), ze wskazaniem, że „komunikacja osmotyczna” to inna nazwa dla wzorca „publish/subscribe”. Muszę przyznać, że nie do końca się mogę zgodzić.

Należy zwrócić uwagę na pojęcie „Subscriber” – oznacza ono, że odbiorca podłączył się do huba, rozdzielnika, czy tematu. „Publisher” określa kto i do czego może się „subscriber” podłączyć. Komunikacja jest jednokierunkowa i wskazuje na pewne rozdzielenie „publikującego” oraz „subskrybującego”, o czym można poczytać na stronach MSDN.

W przypadku komunikacji osmotycznej jest mowa bardziej o dynamicznych rozwiązaniach, gdzie „odbiorcy” nie subskrybowali danej informacji, a jedynie reagują na nią bądź nie. Komunikacja jest w takiej sytuacji dwukierunkowa i nie ma określenia kto, czym może się zainteresować i czy może się wypowiedzieć. Reakcja odbiorcy może spowodować dalszą reakcję innych osób. O ile dobrze rozumiem w przypadku modelu „publish/subscribe” odbiorca komunikatu musiałby określić ponownie swoich „subscriber’ów”.

Moim zdaniem Alistair Cockbourn spojrzał z wyższego poziomu abstrakcji i nie skupił się na rozwiązaniu systemowym. Rozwiązanie z wzorcem „publish/subscribe” umiejscawia rozważania na poziomie rozwiązań informatycznych, wspierane przez odpowiednie modele, narzędzia, opisy wymagań. Jednakże nie zawsze o to chodzi.

Dlatego też, brzytwa Ockhama raczej nie znajduje tutaj zastosowania – trudno mówić o powieleniu bytów. Jednakże zaznaczam, że jest to moja opinia. Mogę się jedynie zgodzić, że od komunikacji osmotycznej możemy przejść do wskazanego wzorca, choć można by spróbować także poszukać innych rozwiązań „biznesowych” wspominanych przy metodach zwinnych.

Komunikacja osmotyczna a proces

Załóżmy, że w pewnej jednostce ma miejsce proces składający się z 4 kroków.  W celu zaspokojenia potrzeby inicjatora procesu należy zawsze wykonać wszystkie 4 kroki. Każdy z kroków realizowany jest w osobnym 4 osobowym zespole. Taką sytuację obrazuje poniższy diagram:W trakcie procesu, wykonawca kroku 2, po jego podjęciu z wewnętrznej kolejki zadań, zwraca się do pozostałych członków zespołu z pytaniem. Elipsa umiejscowiona wokół wykonawcy obrazuje potencjalnych odbiorców zadanego pytania. Jedni z nich zareagują na pytanie, a inni nie. Najprawdopodobniej odpowiedź padnie od członków zespołu, jednakże może także wywołać reakcję członka zespołu odpowiedzialnego za krok 3. Może to być prosty komunikat o czym nie można zapomnieć albo na co zwrócić uwagę podczas realizacji zadania.

Jest to specyficzne dla tzw. komunikacji osmotycznej, która może pozytywnie wpłynąć na realizację procesu. Słyszenie o problemie lub poznanie go z wyprzedzeniem może ułatwić rozwiązanie postanowionego problemu.

Alistair Cockburn przytacza na swojej stronie definicję stwierdzającą, że „komunikacja osmotyczna oznacza, że informacja przepływa w tle słyszana przez członków zespołu, dzięki czemu mogą zapoznać się z informacją jakby przez osmozę. Zwykle jest to realizowane przez zespół siedzący w jednym pomieszczeniu. W momencie, gdy jedna osoba zadaje pytanie, inni w pomieszczeniu mogą albo zareagować lub zignorować pytanie, zaangażować się w dyskusję lub kontynuować swoją pracę.”