Współdzielenie listy zakupów – „pull” czy „push”?

W ramach poprzedniego wpisu dotyczącego elektronicznej listy zakupów wskazałem, że jedną z funkcjonalności dostępnych w aplikacjach wspierających zakupy, jest możliwość współdzielenia listy zakupów. W aplikacji, z której korzystałem, to współdzielenie oparte było o podawanie adresu e-mail, przy założeniu, że zarówno tworzący listę, jak i ją otrzymujący jest zarejestrowanym użytkownikiem aplikacji i ma założone konto na serwerze aplikacji.

Użytkownicy aplikacji w ramach udostępnionej listy mogą:

• dodawać/edytować produkty na liście,
• śledzić postęp zakupów realizowanych przez drugą osobę,
• kopiować listę na przyszłość.

Założeniem dla funkcjonowania współdzielenia listy zakupów, był dostęp do sieci Internet z poziomu urządzenia, na którym jest zainstalowana aplikacja. W sytuacji utraty dostępu do sieci Internet, zmiany na liście oczekiwały na podłączenie się drugiego użytkownika listy. W przypadku dostępu do sieci Internet przez obydwa urządzenia, zmiany były przekazywane w miarę na bieżąco.

Wspólny proces dla obydwu użytkowników jest przedstawiony na poniższym diagramie.

Dla współdzielenia listy można byłoby zastosować dwa modele „współpracy”:

• model „push” (aplikacja inicjująca zmianę przy pomocy pośrednika przekazuje zmiany do drugiej aplikacji)
• model „pull” (jedna aplikacja przekazuje zmiany do wspólnego miejsca, a druga odpytuje o ewentualne zmiany w liście)

Wariant: model „push”
Użytkownik – właściciel listy – rejestruje listę, udostępnia ją, a następnie wprowadza na niej zmiany. Wszystkie te elementy są przesyłane na serwer obsługujący aplikację. Każda zmiana jest rejestrowana i przekazywana do aplikacji odbiorcy listy (wskazanego poprzez e-mail). Serwer wysyła informację o zmianach do aplikacji użytkownika, rejestrując wysłane zmiany. Ewentualna zmiana przez drugą aplikację jest wysyłana analogiczną ścieżką. Na diagramie przedstawiona została ta komunikacja, gdzie każda zmiana jest „pchana” (ang. push) na serwer a następnie do drugiej aplikacji.

W tym celu został wykorzystany wykres wyglądający jak diagram sekwencji (znany z UML) z pewnymi dodatkami. W projektowaniu rozwiązań można znaleźć wzorzec fire-and-forget, w którym informacje są przesyłane bez oczekiwania na reakcję odbiorcy. Trochę jak tutaj, bo w tym modelu aplikacja nie czeka na informację zwrotną.

Wariant: model „pull”
Podobnie jak w poprzednim wariancie, użytkownik – właściciel listy – rejestruje listę, udostępnia ją, a następnie wprowadza na niej zmiany. Wszystkie te elementy są przesyłane na serwer obsługujący aplikację. Trafiają na listę zmian/działań (ang. queue) wykonanych na liście zakupów w postaci zdarzeń typu: udostępnienie listy, zmiana listy, zakup produktu (a dokładnie jego odklikanie) itd. W momencie ustawienia udostępnienia listy, zmiany na utworzonej liście są dostępne do pobrania/odczytania (ang. pull) przez drugą aplikację. W sytuacji, gdy takie udostępnienie nie nastąpi, zmiany są odnotowywane na serwerze i są dostępne tylko dla właściciela listy.

Na diagramie jest przedstawiony ten model. W projektowaniu rozwiązań można znaleźć wzorzec publish-subscribe, który zakłada, że odbiorcy pobierają interesujące ich informacje z miejsca, gdzie zostały wystawione.

Pewnie można byłoby jeszcze zidentyfikować kilka innych wariantów, gdzie ta komunikacja jest bardziej dwustronna. Jednakże biorąc pod fakt, że aplikacja jest zainstalowana na urządzeniach mobilnych i nie w każdej sytuacji aplikacje będą miały dostęp do internetu, jakiś sposób przechowywania i kolejkowania zmian jest konieczny.  Dodatkowo użytkownicy wykonują często operacje zmiany i przeglądania zmian w różnym czasie lub tworzenie listy jest rozłożone w czasie. Patrząc od strony „odbiorcy” listy, także może zmodyfikować listę w czasie jej dostępności. Takie zmiany są „przesyłane zwrotnie” do właściciela listy.

Reklama

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.