W jaki sposób są usługi downstream i upstream?

W przypadku systemu składającego się z wielu usług, które do siebie dzwonią (np. Front End -> Backend -> Storage), często słyszałem osoby używające terminologii, takiej jak usługi „downstream” lub „upstream”. Nie jestem pewien, w jakim kierunku one oznaczają. Dane przepływają w obu kierunkach. Żądania przepływają z bardziej ukierunkowanej na użytkownika do bardziej wewnętrznej usługi, ale odpowiedzi płyną w przeciwnym kierunku, więc wydaje mi się, że można argumentować w jeden z tych dwóch sposobów

Usługi niższego szczebla to te, które korzystają z usługi wyższego szczebla. W szczególności zależą one od usługi wydobywczej. Zatem front-end znajduje się za back-endem, ponieważ zależy od back-endu. Back-end może istnieć sensownie bez front-endu, ale front-end nie ma sensu bez back-endu.

Zależność nie musi być tak silna, jak pokazałem w poprzednim akapicie. Mówiąc bardziej ogólnie, usługi wyższego szczebla nie muszą wiedzieć ani dbać o istnienie usług niższego szczebla. Usługi na rynku niższego szczebla dbają o istnienie usług na rynku wyższego szczebla, nawet jeśli opcjonalnie z nich korzystają.

Niestety istnieją różnice w opiniach na temat znaczenia wyższego / niższego szczebla. Mówiąc o architekturze systemu, definiuję ją w następujący sposób:

Biorąc pod uwagę system budzący obawy, systemy inicjujące wymianę komunikatów / danych do systemu budzącego obawy są systemami wyższymi, a systemy, od których zależy system budzący obawy (tj. Te, od których mój system inicjuje wymianę danych) są systemami niższymi.

Ten link od IBM opisujący interakcje z jednym z ich produktów potwierdza ten pogląd: Integracja z systemami upstream i downstream https://www.ibm.com/support/knowledgecenter/en/SSWSR9_11.3.0/com.ibm.pim.dev.doc /integration/pim_con_dev_creatingjobsforintegrationcontainer.html

System nadrzędny to każdy system, który wysyła dane do systemu Collaboration Server. System podrzędny to system odbierający dane z systemu Collaboration Server.

Biorąc pod uwagę terminologię „pod prąd” i „pod prąd”, pomocne może być dokonanie analogii z rzeką. Jeśli upuścisz wiadomość (dane) w rzece, przepłynie ona z góry (inicjator) do rzeki (odbiornik).

Anegdotycznie stwierdziłem, że architekci i programiści używają tej definicji, a programiści odwrotnie (być może z powodu „wysyłania”).

W przypadku osi czasu zdarzenia zdarzenie jest wysyłane w górę, gdy ma miejsce przed punktem na osi czasu (tj. Wyzwala inne zdarzenie), a w dół, gdy ma miejsce później (tj. Odbiera zdarzenie). To, co jest w górę i w dół w sekwencji zdarzeń, zależy zatem od tego, gdzie jesteś na osi czasu. Zdarzenie może mieć charakter zarówno wyjściowy, jak i wyjściowy, w zależności od tego, czy punkt początkowy znajduje się przed, czy po nim.

Jak zauważa @Jack RFC7230 tools.ietf.org/html/rfc7230#section-2.3 ma to:

Pojęcia „upstream” i „downstream” są używane do opisania
wymagań kierunkowych w odniesieniu do przepływu komunikatów: wszystkie
komunikaty przepływają z góry do dołu

Chciałbym zobaczyć na głosach, z których najczęściej korzysta się!

Najlepszym sposobem, aby o tym pomyśleć, jest myślenie o rzece.

Dolna część rzeki nie może dostać żadnej wody, chyba że pochodzi z górnego biegu rzeki, tzn. Dolna część rzeki zależy od jej górnej części.

Gdyby ktoś zniszczył dolną część rzeki, nie miałoby to wpływu na rzekę. Jeśli ktoś zniszczy górną część rzeki, wpłynie to na rzekę, tzn. Nie dostanie wody.

Tak więc usługi powiązane zależą od usług wyższych. Jeśli usługi nadrzędne zostaną usunięte, usługi podrzędne nie będą działać poprawnie.

Może to być bardziej problem językowy i geograficzny niż techniczny.

• Żądanie informacji idzie w górę. Pochodzi z późniejszego systemu.

• Odpowiedź na żądanie informacji (wymagane informacje) jest przesyłana dalej i jest wysyłana przez system nadrzędny.

Nie ma różnicy między klasycznym widokiem IBM a użyciem terminów przez dzisiejszą społeczność internetową.

• Usługodawca (serwer) będzie umiejscowiony powyżej, w porównaniu do usługobiorcy, i wysyła informacje do konsumenta.

• Usługobiorca (klient) będzie zlokalizowany niżej niż usługodawca i wysyła żądania do dostawcy.

Teoretycznie role układów fizycznych mogą się zmienić natychmiast, podobnie jak kierunek strumienia między tymi układami. W sieci peer-to-peer może tak być.

Warunki wysyłania i pobierania są warunkami skoncentrowanymi na kliencie. Z punktu widzenia klienta przesyłane jest żądanie i pobierana jest odpowiedź zgodna z metaforą strumienia.