Atlas interaktywny. Multaj tier architekczur

Rysunek przedstawia schemat w postaci trzech niebieskich pól. Pola połączone są za pomocą strzałek, zaopatrzonych w tytuły, oraz dwóch znajdujących się obok i istniejących niezależnie. Jedno pole jest w kolorze zielonym i ma napis zalety, drugie jest w kolorze czerwonym i ma napis wady.

Nagranie dźwiękowe tożsame z treścią.

Architektura wielowarstwowa. W inżynierii oprogramowania architektura wielowarstwowa (często określana jako architektura n‑warstwowa) to architektura typu klient‑serwer, w której funkcje prezentacji, przetwarzania aplikacji i zarządzania danymi są fizycznie oddzielone. Najbardziej rozpowszechnionym zastosowaniem architektury wielowarstwowej jest architektura trójwarstwowa. Dzieląc aplikację na warstwy, programiści zyskują możliwość modyfikowania lub dodawania określonej warstwy zamiast przerabiania całej aplikacji.

Warstwa prezentacji

Jest to najwyższy poziom aplikacji. Warstwa prezentacji wyświetla informacje związane z takimi usługami, jak przeglądanie towarów, zakupy i zawartość koszyka. Komunikuje się z innymi warstwami, za pomocą których przekazuje wyniki do przeglądarki/klienta oraz do wszystkich innych warstw w sieci. Mówiąc prościej, jest to warstwa, do której użytkownicy mają bezpośredni dostęp (np. strona WWW lub graficzny interfejs użytkownika systemu operacyjnego).

Warstwa logiki biznesowej

Warstwa logiki biznesowej jest wyodrębniona z warstwy prezentacji i jako samodzielna warstwa kontroluje funkcjonalność aplikacji, wykonując szczegółowe przetwarzanie danych.

Warstwa danych

Warstwa danych obejmuje mechanizmy trwałości danych (serwery baz danych, udziały w plikach itp.) oraz warstwę dostępu do danych, która hermetyzuje mechanizmy trwałości i udostępnia dane. Warstwa dostępu do danych powinna udostępniać interfejs API dla warstwy aplikacji, który udostępnia metody zarządzania przechowywanymi danymi bez ujawniania lub tworzenia zależności od mechanizmów przechowywania danych. Unikanie zależności od mechanizmów przechowywania danych pozwala na aktualizacje lub zmiany bez wpływu na klientów warstwy aplikacji, a nawet bez świadomości tych zmian. Podobnie jak w przypadku oddzielenia dowolnej warstwy, istnieją koszty wdrożenia, a często także koszty wydajności w zamian za lepszą skalowalność i łatwość utrzymania.

Wady

Trudno skalowalna, zaciemnia obraz aplikacji, warstwy są ze sobą ściśle powiązane.

Zalety

Umożliwia niezależne uaktualnianie lub zastępowanie dowolnej z warstw w odpowiedzi na zmiany wymagań lub technologii, mechanizm prosty do opanowania, powszechnie stosowana.

Domejn Drajwen dizajn (DiDiDi)

Na ilustracji widoczny jest schemat blokowy w postaci niebieskich prostokątów połączonych ze sobą strzałkami i opatrzonych nagłówkami. Po lewej stronie schematu znajdują się dwa prostokąty z treścią. Treść w górnym: Deklaracja wizji domeny. Treść w dolnym: Eksperci i zespół dostarczający domenę. Od prostokąta na górze do prostokąta na dolne biegnie strzałka. Od dolnego prostokąta biegną dwie strzałki. Pierwsza do prostokąta z napisem: Wszechobecny język. Druga do prostokąta z napisem wiedza. Od prostokąta z napisem wiesza biegną trzy strzałki do prostokątów z napisami: Domeny pomocnicze, domeny ogólne, domeny podstawowe. Wszystkie trzy prostokąty są ze sobą spięte klamrą. Biegnie od nich strzałka do prostokąta z napisem: Wszechobecny język. U dołu schematu znajduje się prostokąt z napisem: Kody i schematy. Od niego biegną trzy strzałki. Pierwsza do prostokąta z napisem wiedza. Druga do prostokąta z napisem: Eksperci i zespół dostarczający domenę. Ostatnia do prostokąta z napisem: Domeny podstawowe. Obok opisanych prostokątów znajdują się dwa, niezależnie: jeden w kolorze zielonym z napisem zalety, a drugi w kolorze czerwonym z napisem wady. Na każdym z pól widoczny jest punktor. Jest ich jedenaście.  U dołu znajduje się spis treści, po kliknięciu w dany punkt podświetla się wybrana część schematu.

Nagranie dźwiękowe tożsame z treścią.

1. Domejn Drajwen dizajn (DiDiDi) jest metodą projektowania oprogramowania, w której programiści konstruują modele w celu zrozumienia wymagań biznesowych danej domeny. Modele te służą jako koncepcyjne podstawy do tworzenia oprogramowania.

2. Deklaracja wizji domeny to deklaracja wartości biznesowej, jaką ma dawać aplikacja.

3. Eksperci i zespół dostarczający domenę. Osoby mające największą wiedzę na temat funkcjonalności aplikacji.

4. Wszechobecny język . Uniwersalny język pozwalający na porozumienie się programisty z ekspertem domenowym

5. Wiedza . Formalnie uporządkowane informacje, dane

6. Kod i schematy.  W DeDeDe  sposób, forma przekazywania danych

7. Domeny pomocnicze. Są rozbudową domen podstawowych – bez niej domeny pomocnicze są bezwartościowe.

8. Domeny ogólne. Stanowią ważne, acz dodatkowe funkcje.

9. Domeny podstawowe. Domeny podstawowe Stanowią najważniejszą część systemu i odpowiadają za najważniejszą funkcjonalność.

10. Wady. Wysokie koszty początkowe, wciąż mało powszechna.

11. Zalety. Świetnie się sprawdza w przypadku skomplikowanych projektów, odpowiada na potrzeby biznesu.

Model Wju Kontroler

Nagranie dźwiękowe tożsame z treścią.

Wzorzec architektoniczny model‑widok‑kontroler (em wi si) jest powszechnie stosowany do tworzenia interfejsów użytkownika, w których powiązana logika programu jest podzielona na trzy połączone ze sobą elementy. Ma to na celu oddzielenie wewnętrznych informacji od sposobów, w jakie są one prezentowane i odbierane przez użytkownika. Tradycyjnie stosowany w graficznych interfejsach użytkownika, wzorzec ten stał się popularny przy projektowaniu aplikacji internetowych.

Model

Dla przykładu, gdy mamy system kupowania biletów kinowych, w komponencie Modelu zawarte będą takie informacje, jak bilet, dany seans, a także klient, który ów bilet kupuje. Dane wprowadzone przez użytkownika do Kontrolera (i tam poddane weryfikacji) zostaną przetworzone właśnie w Modelu, który niejako pośredniczy między źródłem danych oraz Widokiem.

Kontroler

W naszym przykładzie komponent Kontrolera będzie przyjmował dane użytkownika, czyli np. godzinę rezerwacji biletu, imię i nazwisko klienta oraz płatność, a następnie weryfikował ich poprawność pod kątem formalnym (czy np. wszystkie pola zostały wypełnione zgodnie z założeniami programu). Końcowym etapem działania Kontrolera w tym przykładzie jest przekazanie wszystkich zebranych danych do komponentu Model.

Użytkownik

Wprowadza dane oraz jest ostatecznym konsumentem aplikacji w postaci widoku.

Widok

Widok w naszym przykładzie to wizualna reprezentacja systemu, czyli np. strona internetowa lub aplikacja na telefony, w której znajduje się formularz, za pomocą którego możemy zarezerwować bilet na seans.

Wady

Złożoność w nawigacji po kodzie (przy każdej aktualizacji struktura staje się bardziej złożona). Koszty związane z częstymi zmianami i aktualizacjami. Wzorzec em fał ce może być trudny do zrozumienia ze względu na złożoność i aktualizacje em fał ce, musi mieć ścisłe reguły dotyczące metod (odpowiednie reakcje kontrolera). Programiści muszą znać wiele technologii, aby zrozumieć i używać em fał ce.

Zalety

Możliwość organizowania aplikacji internetowych o dużych rozmiarach. Ponieważ kod jest rozdzielony na trzech poziomach, niezwykle łatwo jest podzielić i zorganizować logikę dużych aplikacji internetowych. Aplikacje em fał ce mogą działać nawet z plikami pe de ef, przeglądarkami specyficznymi dla danej witryny, a także z widżetami na pulpicie - łatwość modyfikacji. Modyfikowanie widoków jest uproszczone ponieważ pojedyncza sekcja jest niezależna od innych sekcji. Krótszy proces tworzenia aplikacji. Ponieważ kod jest rozdzielany na trzech poziomach, tworzenie aplikacji internetowych w modelu em fał ce pozwala jednemu programiście pracować nad konkretną sekcją, podczas gdy inny może jednocześnie pracować nad inną sekcją. Łatwe planowanie i konserwacja. Paradygmat em fał ce jest pomocny w początkowej fazie planowania aplikacji, ponieważ daje programiście zarys tego, jak ułożyć swoje pomysły w rzeczywisty kod. Zwraca dane bez formatowania. Jest to pomocne dla programistów, ponieważ te same komponenty mogą być ponownie wykorzystane w dowolnym interfejsie.Wspiera rozwój sterowany testami. Główną zaletą wzorca em fał ce jest to, że bardzo upraszcza on proces testowania.Wielokrotne widoki. W architekturze em fał ce łatwo jest tworzyć różne komponenty widoku dla komponentu modelu. Umożliwia to tworzenie różnych komponentów widoku, ograniczając w ten sposób powielanie kodu, ponieważ oddziela dane od logiki biznesowej.

Model Wju Prezenter

Na zdjęciu widoczny jest schemat czterech niebieskich prostokątów, opatrzonych nagłówkami i połączonych podwójnymi strzałkami. Po prawej stronie znajdują się dwa prostokąty: zielony z napisem zalety oraz czerwony z napisem wady.

Model Wju Prezenter (eM wi pi) jest pochodną wzorca architektonicznego model‑wiu‑kontroler (em fał ce) i jest używany głównie do budowania interfejsów użytkownika. W em fał pe prezenter przejmuje funkcję pośrednika, a cała logika prezentacji jest przekazywana do prezentera.

Model przekazuje zmiany do prezentera oraz widoku. Widok uaktualnia model.

Model to też ten element kodu, który komunikuje się z bazą danych. Jego zadaniem jest sprawdzanie spójności danych i ich poprawności. Następnie dane te przekazywane są do prezentera.

Prezenter modyfikuje model

Prezenter to komponent pośredniczący pomiędzy modelem oraz widokiem i ta część systemu, w której znajduje się logika biznesowa aplikacji. Rolą Prezentera może być zarówno odczytywanie danych z modelu, jak i wykonywanie obliczeń i przesyłanie danych wynikowych do komponentu Widok. W Prezenterze znajdziemy też narzędzia weryfikacji użytkowników, a także ustawienia dostępowe w aplikacji dla konkretnych typów użytkowników.

Widok uaktualnia prezenter, a prezenter przekazuje powiadomienia do widok

Widok odpowiada za to, w jaki sposób prezentowane są dane przekazane przez komponent Prezenter. To komponent odpowiedzialny wyłącznie za wyświetlanie danych – nie ma w nim więc żadnej logiki biznesowej, co pozwala na łatwe zmiany na przykład interfejsu i wyglądu aplikacji bez konieczności zmian w logice działania.

Użytkownik prezentuje widok, a widok użytkuje użytkownik.

Użytkuje aplikację poprzez obserwowanie widoku.

Wady

Wyższa złożoność, doświadczenie i wiedza decydują o właściwym wdrożeniu, nieodpowiednie dla prostych i małych rozwiązań.

Zalety

Ponowne użycie kodu – zasada separacji problemów zapewnia możliwość ponownego użycia kodu. Projekt będzie miał odpowiedni model domeny i logikę biznesową w swojej logicznej jednostce. Podejście sterowane testami – zastosowanie izolacji umożliwia oddzielne testowanie komponentów. Oddzielenie logicznej części widoku, która jest prezenterem, od widoku wizualnego, który jest widokiem rzeczywistym, ułatwia przeprowadzanie testów jednostkowych. Możliwość dostosowania projektu – zmiany i uzupełnienia są znacznie łatwiejsze do zastosowania, jeśli projekt jest dobry. Izolowany kod zapewnia swobodę wyboru kilku widoków i źródeł danych. Warstwowość – em fał pe oddziela logikę widoku od logiki biznesowej.

Model Wju WjuModel

Na zdjęciu jest schemat w postaci czterech niebieskich prostokątów, połączonych podwójnymi strzałkami. Obok znajdują się dwa prostokąty: zielony z napisem zalety oraz czerwony z napisem wady.

Model Wju WjuModel (eM wi wi eM) to wzorzec architektoniczny oprogramowania, który ułatwia oddzielenie tworzenia graficznego interfejsu użytkownika (widoku) od tworzenia logiki biznesowej lub modelu, dzięki czemu widok nie jest zależny od żadnej konkretnej platformy modelu. Model widoku w em fał fał em jest konwerterem wartości, co oznacza, że jest on odpowiedzialny za eksponowanie (konwersję) obiektów danych z modelu w taki sposób, aby obiekty były łatwo zarządzane i prezentowane. Pod tym względem wiumodel jest bardziej modelem niż widokiem i obsługuje większość, jeśli nie całą, logikę wyświetlania widoku. Został on wymyślony przez architektów firmy majkrosoft, kena kupa i teda pitersa, specjalnie w celu uproszczenia programowania interfejsów użytkownika sterowanego zdarzeniami.

Model przekazuje zmiany do model widoku, a model widoku zarządza i modyfikuje model.

Model odnosi się albo do modelu domeny, który reprezentuje zawartość stanu rzeczywistego (podejście obiektowe), albo do warstwy dostępu do danych, która reprezentuje zawartość (podejście skoncentrowane na danych).

Model widoku połączony jest strzałkami z modelem oraz widokiem.

Model widoku jest abstrakcją widoku, eksponującą publiczne właściwości i polecenia. Zamiast kontrolera we wzorcu em fałce lub prezentera we wzorcu em fał pe, em fał fał em posiada binder, który automatyzuje komunikację między widokiem a powiązanymi z nim właściwościami w modelu widoku. Model widoku został opisany jako stan danych w modelu. Główna różnica między modelem widoku a prezenterem we wzorcu em fał pe polega na tym, że prezenter posiada referencję do widoku, podczas gdy model widoku nie. Zamiast tego widok bezpośrednio wiąże się z właściwościami modelu widoku, aby wysyłać i odbierać aktualizacje. Aby działać wydajnie, wymaga to zastosowania technologii wiązania lub wygenerowania kodu szablonowego do wykonania wiązania.

Widok połączony jest strzałkami z modelem widoku i użytkownikiem.

Podobnie jak we wzorcach model‑wiu‑kontroler (eM wi si) i model‑wiu‑prizenter (eM wi Pi), widok jest strukturą, układem i wyglądem tego, co użytkownik widzi na ekranie. Wyświetla on reprezentację modelu i odbiera interakcje użytkownika z widokiem (kliknięcia myszą, dane wejściowe z klawiatury, gesty stuknięcia w ekran itp.), a następnie przekazuje obsługę tych interakcji do modelu widoku za pomocą wiązania danych (właściwości, wywołania zwrotne zdarzeń itp.), które jest zdefiniowane w celu połączenia widoku i modelu widoku.

Użytkownik połączony jest strzałkami z widokiem.

Użytkuje aplikację poprzez obserwowanie widoku.

Wady

Komunikacja między różnymi komponentami em fał fał em i wiązanie danych jest skomplikowane. Ponowne wykorzystanie kodu widoków i modeli widoków jest trudne. Zarządzanie modelami widoków i ich stanem w zagnieżdżonych widokach i złożonych interfejsach użytkownika jest trudne. Em fał fał em dla początkujących jest trudny do zastosowania.

Zalety

Lepsze rozdzielenie problemów niż w przypadku em fał ce. Lepsza testowalność. Przejrzysta komunikacja. Zmiana sposobu myślenia.

Prezentejszon Abstrakszon Kontrol

Schemat przedstawia trzy główne prostokąty połączone z szeregiem innych, mniejszych prostokątów. Po prawej stronie znajdują się dwa prostokąty: czerwony z napisem wady oraz zielony z napisem zalety.

Nagranie dźwiękowe tożsame z treścią.

Prezentejszon Abstrakszon Kontrol (Pe A si) jest to architektura oprogramowania zorientowana na interakcję i przypomina nieco model‑widok‑kontroler (eM wi si), ponieważ rozdziela interaktywny system na trzy rodzaje komponentów odpowiedzialnych za określone aspekty funkcjonalności aplikacji. W przeciwieństwie do eM wi si, PiAsi jest używany jako hierarchiczna struktura agentów, z których każdy składa się z triady części prezentacyjnej, abstrakcyjnej i kontrolnej. Agenci (lub triady) komunikują się ze sobą tylko poprzez część kontrolną każdej triady. Od eM wi si różni się również tym, że w ramach każdej triady całkowicie izoluje prezentację (widok w eM wi si) i abstrakcję (model w eM wi si). Umożliwia to oddzielne wielowątkowe wykonywanie modelu i widoku, co może zapewnić użytkownikowi bardzo krótki czas uruchamiania programu, ponieważ interfejs użytkownika (prezentacja) może zostać wyświetlony, zanim abstrakcja zostanie w pełni zainicjalizowana. Założeniem Pi ej si (Prezentejszon Abstrakszon Kontrol) jest tworzenie takich struktur, w których różne elementy istnieją w tym samym czasie i każdy z nich ma taką samą, potrójną strukturę. Od tradycyjnego modelu eM fał Ce (Model Wju Kontroler) różni się tym, że Wju to Prezentejszon (prezentacja), a model to abstarakszon (abstrakcja). Co istotne, warstwy prezentacji oraz abstrakcji nie komunikują się ze sobą - dzieje się to tylko za pomocą kontrolera.

Prezentacja

Ten komponent nie jest połączony z innymi komponentami w systemie, a tylko z kontrolerem. Prezentacja to, jak sama nazwa wskazuje, prezentowanie danych, które dostarczone są przez kontroler. Takie dane możemy zaprezentować w postaci HaTe eMeL, IkseMeL , obrazu lub tekstu. Dla przykładu, gdy w aplikacji mamy wyświetlić napis „Wzorce projektowe”, to prezentacja będzie odpowiedzialna za wypisanie lub narysowanie na ekranie tego napisu w odpowiednim miejscu.

Kontroler

To najważniejszy komponent w Pi ej si, którego zadaniem jest komunikowanie się z innymi komponentami. W naszym przykładzie wyświetlania napisu „Wzorce projektowe” zadaniem kontrolera będzie połączenie się z innym elementem systemu tak, by np. otrzymał informację, że teraz trzeba wyświetlić na ekranie ten napis.

Abstrakcja

Ten komponent nie jest połączony z innymi komponentami w systemie, a tylko z kontrolerem. Abstrakcja, podobnie jak Model w modelu MVC, odbiera oraz przetwarza dane. W przykładzie z wyświetlaniem napisu „Wzorce projektowe” komponent abstrakcji będzie zbierał i przygotowywał dane, czyli np. krój pisma, rozmiar pisma i inne informacje, które zostaną wykorzystane w celu zaprezentowania napisu.

Wady

Nieefektywność w dostępie do danych pomiędzy warstwami. Programista musi znać wiele języków programowania. Piejsi  utrudnia także określenie właściwej liczby agentów ze względu na dużą niezależność i luźne powiązania między wieloma agentami. Piejsi jest również nieco bardziej czasochłonny w porównaniu z eMfał.  Złożoność procesu tworzenia aplikacji, ponieważ komunikacja między agentami odbywa się tylko między kontrolkami agentów.

Zalety

Dostarcza nowych sposobów i pomysłów na projektowanie dowolnego oprogramowania lub aplikacji. Pozwala oddzielić dane wyjściowe i nie dopuszcza do mieszania się kwestii związanych z interfejsem graficznym/prezentacją z logiką biznesową. Złożoność jest mniejsza niż w MVC, a projektowanie interfejsu użytkownika łatwiejsze.

Pajps end filters

Schemat przedstawia dwa główne prostokąty z napisem Wejście oraz Wyjście. Pomiędzy nimi znajdują się dwa okręgi z napisem filtr, połączone z prostokątami strzałkami z napisem potok. Na dole mieszczą się dwa prostokąty: czerwony z napisem wady oraz zielony z napisem zalety.

Nagranie dźwiękowe tożsame z treścią.

Wzorzec potoków i filtrów pozwala m.in. na rozłożenie jakiegoś dużego zadania na mniejsze części. To stosunkowo klarowny styl architektoniczny, który inspirowany jest zagadnieniami z systemu juniks, a konkretnie łączeniem wyjścia jednej aplikacji z wejściem innej za pomocą tzw. potoków. We wzorcu tym źródło danych połączone jest z filtrami danych właśnie za pomocą potoków. Jako że wszystkie komponenty korzystają z tego samego interfejsu zewnętrznego, można je łączyć w różne rozwiązania poprzez podłączanie komponentów do różnych potoków. Co więcej, można też dodawać nowe filtry, pomijać istniejące lub zmieniać sekwencję bez konieczności zmiany samych filtrów. Przykładami takiego wzorca mogą być programy juniksowe, w których wyjście z jednego może być połączone potokiem z wejściem innego programu. To także kompilatory, które w kolejnych filtrach wykonują analizy np. leksykalne, parsowanie, analizę semantyczną i generowanie kodu.

Wejście

Źródło danych, może być jedno lub wiele.

Potok

Potok łączy jeden filtr z drugim, przesyłając komunikaty wyjściowe z jednego filtra do drugiego. Dane wędrują potokiem i pojawiają się na wejściu do filtra.

Filtr

Każdy filtr ma bardzo prosty interfejs: odbiera wiadomości z potoku przychodzącego, przetwarza je i publikuje wyniki do potoku wychodzącego. Przetwarzanie to np. parsowanie lub analiza leksykalna kodu. Gdyby dla przykładu istniał plik dane kropka e iks tet, to pierwszym filtrem byłaby w juniksie komenda „grep”, która wyodrębnia jakiś ciąg znaków. Następnie wyodrębnione dane przesyłane są kolejnym potokiem do filtra sortującego, tam sortowane, a następnie przesyłane do pliku wynik kropka te iks te.

Wyjście

Przetworzone dane.

Wady

Brak współpracy pomiędzy filtrami.

Zalety

Możliwość równoczesnej pracy nad różnymi elementami układu. Łatwość utrzymania i rozbudowy; możliwość dodawania nowych filtrów.

Serwis oriented architekczur

Schemat ukazuje dwa niebieskie prostokąty na górze, połączone strzałkami z długim, niebieskim prostokątem, który łączy się z czterema okręgami, a te z długim prostokątem. Po prawej jego stronie znajdują się dwa prostokąty: jeden czerwony z napisem wady, drugi zielony z napisem zalety.

Nagranie dźwiękowe tożsame z treścią zawartą poniżej.

Serwis oriented architekczur (eSOA) to architektura, która skupia się na usługach, a nie jednorodnym projekcie. Przydaje się wszędzie tam, gdzie za pomocą komponentów aplikacji dostarcza się usługi innym komponentom systemu przez jakiś protokół komunikacyjny. Przede wszystkim chodzi w niej o zdefiniowanie usług, które mają za zadanie spełniać wymagania użytkowników. Usługą z kolei jest dowolny element oprogramowania, który ma swój interfejs i działa niezależnie od innych komponentów, a za pomocą którego udostępniane są realizowane funkcje. Architektura es o a jest zbliżona do Iwent‑Drajwen Architekczur (iDiej), gdyż, podobnie jak (iDiej), ma luźne połączenia między komponentami systemu, ale rozwiązania opisywane są w niej na wyższym poziomie abstrakcji. Usługi są w niej implementowane na bazie różnych technologii, zaś ich interfejsy są definiowane niezależnie od platformy programistycznej.

Klienci usług w chmurze

Klienci usług w chmurze to np. aplikacje sklepów internetowych czy aplikacje mobilne, które prezentują jakieś usługi. Klient przyporządkowany jest do warstwy konsumentów, to docelowy odbiorca danych usług. Co istotne, klient nie musi znać szczegółów działania danej usługi ani jakie informacje są przechowywane w danej usłudze. W przypadku np. aplikacji pogodowej nieistotne jest położenie czujników meteorologicznych, a to, czy danego dnia będzie świecić słońce. Istotne jest również pojęcie tzw. orkiestracji, czyli wywoływania innych usług, by odpowiedzieć na potrzeby klientów. Tym samym różne usługi mogą stawać się też klientami dla innych usług.

Przeglądarka

Przeglądarka to jeden z przykładowych komponentów warstwy konsumentów - aplikacje przeglądarkowe to na przykład usługi sklepu, które pozwalają zamówić dane towary za pomocą odpowiednich formularzy.

Szyna usług przedsiębiorstwa

Szyna usług przedsiębiorstwa, czyli e es be (enterprajs serwis bas), to element, który jest centralnym punktem usług. Dzięki niemu można przyłączać lub odłączać poszczególne usługi, które wchodzą w skład całego systemu. To dzięki szynie usług możliwa jest wymiana danych między poszczególnymi systemami i aplikacjami. Szyna pozwala na ustandaryzowanie środowiska aplikacji, interfejsów oraz formatów danych.

Obsługa konta

Jeden z przykładów warstwy dostawców.

Księgowość

Jeden z przykładów warstwy dostawców.

Dział zamówień

Jeden z przykładów warstwy dostawców.

Dział wysyłki

Jeden z przykładów warstwy dostawców.

Bazy danych

Bazy danych to określenie miejsc, w których zgromadzone i uporządkowane są dane cyfrowe na temat usługodawców, biorców oraz usług samych w sobie. Informacje pochodzące z np. działu zamówień czy wysyłki gromadzone są w bazie danych i tam przechowywane, stanowią bowiem np. poczet klientów danej usługi.

Wady

Serwer wysyła i odbiera wiadomości oraz wiedzę często – osiąga dużą liczbę żądań dziennie. W związku z tym do uruchomienia usługi internetowej potrzebny jest serwer o dużej przepustowości i dużej ilości informacji. W es o a wszystkie dane wejściowe mierzą swoją ważność, zanim zostaną wysłane do usługi. Jeśli użytkownik korzysta z wielu usług, system będzie przeciążony dodatkowymi obliczeniami. Kosztowny pod względem zasobów ludzkich, rozwoju i technologii.

Zalety

Niezawodność dzięki małym i niezależnym usługom w architekturze. Usługi są zlokalizowane w rejestrze usług i można się do nich dostać za pomocą jednolitego lokalizatora zasobów (u er el), dlatego mogą zmieniać swoją lokalizację w czasie bez zakłócania pracy systemu, co czyni es o a niezależną od lokalizacji. Ponieważ es o a umożliwia uruchamianie usług na wielu platformach, w różnych językach programowania i w różnych usługach, to znaczy, że usługi architektury zorientowanej na usługi działają na różnych serwerach w danym środowisku, co zwiększa jej skalowalność. Architektura zorientowana na usługi pozwala na tworzenie złożonych aplikacji poprzez integrację różnych usług pochodzących z różnych źródeł, co uniezależnia ją od platformy. Aplikacja oparta na (eSOej) jest tworzona poprzez gromadzenie małych, samodzielnych i luźno powiązanych usług funkcjonalnych. Pozwala to na ponowne wykorzystanie usług w wielu aplikacjach niezależnie, bez konieczności interakcji z innymi usługami. Możliwość tworzenia aplikacji z komponentów lub usług wielokrotnego użytku zamiast przepisywania i ponownego integrowania każdego nowego projektu pomaga programistom szybko zaprojektować aplikację w odpowiedzi na nowe wymagania biznesowe. Łatwość wprowadzania zmian ze względu na to, że składa się ona z wielu niezależnych komponentów.

Iwent‑drajwen architeczur

Schemat ukazuje dwa główne prostokąty z napisem producenci zdarzenia oraz konsumenci zdarzenia, połączone z prostokątem kanały zdarzenia. Po prawej stronie znajdują się dwa prostokąty: jeden czerwony z napisem wady, drugi zielony z napisem zalety.

Nagranie dźwiękowe tożsame z treścią.

Iwent‑drajwen architeczur, czyli architektura sterowana zdarzeniami (iDiej), to nowoczesne podejście do projektowania, które skoncentrowane jest na zdarzeniach, czyli czymś, co przed chwilą nastąpiło. Takie zdarzenia to np. naciśnięcie przycisku, przyłożenie karty płatniczej do czytnika czy odczyt jakiejś danej. Aplikacje w (iDiej) reagują na bazie dopiero co zaistniałych zdarzeń, w przeciwieństwie do tradycyjnego podejścia w architekturze, które operuje danymi jako porcjami informacji, które przetwarzane są w jakiś sposób. Podstawową kategorią w (EDeA)  jest zdarzenie, czyli „zmiana stanu aplikacji, która już nastąpiła”. Zdarzenia to informacje, które przesyłane są pomiędzy różnymi modułami danego systemu. Zdarzenie nie wie, kto z niego korzysta. Zdarzenia wytwarzane są przez producentów, przesyłane do kanału zdarzeń, a następnie po przetworzeniu wysyłane do konsumentów. Same zdarzenia mogą być wewnętrzne lub zewnętrzne.

Producenci zdarzenia

Producent zdarzenia to pierwsza warstwa logiczna i serwis, który wyłącznie produkuje zdarzenia. Wykrywa on jakiś fakt i prezentuje go jako wiadomość o zdarzeniu (czymś, co właśnie nastąpiło), zapisuje raport z takiego zdarzenia i wysyła go do kanału zdarzeń. Może to być np. klient poczty imejl czy fizyczny czujnik, który prowadzi jakiś odczyt.

Kanały zdarzenia

Kanał zdarzeń (szyna zdarzeń) to drugi logiczny element systemu. Jego zadaniem jest filtrowanie i wypuszczanie zdarzeń do konsumentów. W tym samym czasie może być otwartych kilka kanałów zdarzeń. Z uwagi na przetwarzanie wielu kanałów w czasie bliskim rzeczywistemu mogą one być odczytywane asynchronicznie - zdarzenia są wtedy zakolejkowane i przetwarzane w odpowiedniej kolejności. Kanałem zdarzeń może być np. połączenie tisipi/ajPi.

Konsumenci zdarzenia

Konsumentem może być dowolny podmiot, w tym także np. serwis, który jest producentem dla innego zdarzenia. Konsumenci sprawdzają lub nasłuchują zdarzenia i mogą wtedy odpowiedzieć w konkretny sposób. Co więcej, muszą oni zareagować, gdy tylko dostaną informację o zdarzeniu. Dla przykładu, jeśli w magazynie jest mało pił szablastych, wysłane jest zdarzenie z tą właśnie informacją, a konsument reaguje w postaci informacji, np. powiadomienia personelu o konieczności zakupu nowej partii pił szablastych.

Wady

Trudne projektowanie - należy mieć wiedzę na temat programowania asynchronii. Testowanie - architektura ta wymaga specjalnych narzędzi do generowania zdarzeń, nie zawsze także otrzymujemy zdarzenia w tej samej kolejności. Problem kanału - jako że kanał (szyna) zdarzeń jest centrum przepływu danych, to gdy on zostanie uszkodzony, wtedy wszystko przestaje działać

Zalety

Skalowalność - serwisy mają świadomość tylko istnienia szyny zdarzeń. W praktyce można więc tworzyć wiele serwisów i gdy jeden z nich jest uszkodzony, inne działają dalej. Wydajność - wszystkie operacje mogą być wykonywane asynchronicznie, czyli dane wysyłane są w nieregularny sposób. Zwinność - można dodawać lub usuwać stare komponenty, ponieważ ten typ architektury ma luźny tzw. kupling, czyli jest luźno powiązana (producenci nie wiedzą, którzy konsumenci prowadzą nasłuch).