Coulouris zdefiniował systemy rozproszone jako „systemy, w których komponenty sprzętowe i/lub programowe istniejące w sieci komputerowej komunikują się i koordynują swoje działania poprzez wymianę komunikatów”.
Koncepcja ta stała się popularna w ostatnich latach ze względu na kilka czynników. Pierwszym czynnikiem sprzyjającym rozwojowi systemów rozproszonych było pojawienie się szybkich sieci lokalnych. Kolejnym ważnym czynnikiem był postęp technologiczny w wydajności komputerów osobistych oraz rozwój oprogramowania do obsługi aplikacji rozproszonych. Systemy rozproszone są powiązane z koncepcją Sieci i Internetu. Wraz z ewolucją Sieci, pojawianiem się nowych obszarów, interakcji, potrzeb i zastosowań pojawia się koncepcja Web 2.0. Termin ten został ukuty przez Tima O'Reilly'ego w 2004 roku w odniesieniu do drugiej generacji w historii sieci, opartej na społecznościach użytkowników i specjalnej gamie usług, takich jak sieci społecznościowe, blogi, wiki czy folksonomie, które zachęcają do współpracy i szybkiego wymianę informacji między użytkownikami.
Pierwsze architektury, które można uznać za zorientowane na usługi (SOA), były oparte na architekturze CORBA (Common Object Request Broker Architecture), która działała jako warstwa abstrakcji łącząca różne elementy architektury i usługi budowania. Inne wcześniejsze technologie to DCOM (Distributed Component Object Model) lub RPC (Remote Procedure Protocol). Wraz z potrzebą efektywnego projektowania i wdrażania systemów rozproszonych w sieci pojawia się kilka wyzwań, niektóre koncentrują się na samym rozwoju (wydajność, user experience itp.), a inne uzupełniające, oparte na możliwości ponownego wykorzystania i kompatybilności usług. Z tych potrzeb wynikają usługi sieciowe, które zapewniają standardowe mechanizmy łączenia różnych użytkowników z serwerami informacyjnymi.
ARCHITEKTURY ZORIENTOWANE NA USŁUGI
Według SOA (Service Oriented Architecture) są to architektury oprogramowania, które definiują wykorzystanie usług do obsługi wymagań biznesowych, których celem jest osiągnięcie jak najmniejszego sprzężenia między agentami oprogramowania. Usługa to jednostka pracy wykonanej przez usługodawcę w celu osiągnięcia efektu końcowego pożądanego przez usługobiorcę. Role zarówno usługodawcy, jak i konsumenta usługi odgrywają agenci oprogramowania, a nie właściciele oprogramowania. W ogólnym znaczeniu architektura zorientowana na usługi to rozwiązanie programowe, którego celem jest umożliwienie przedsiębiorstwu organizacji i wykorzystania różnych procesów. Dzięki architekturze SOA aplikacje nie są już ogromnymi blokami funkcji i procesów. Zamiast tego aplikacje te składają się z połączonych usług modułowych. Pamiętaj, że usługa to prosta funkcja oprogramowania (taka jak anulowanie płyty CD). Może być uruchamiany na żądanie przez dowolny system, niezależnie od systemu operacyjnego, platformy, języka programowania czy położenia geograficznego.
To, co jest rewolucyjne w SOA, to nie sama koncepcja, która istnieje od dawna, ale fakt, że można ją wdrożyć przez WWW (World Wide Web). W ten sam sposób, w jaki strony internetowe ładują się na dowolnej platformie, usługi sieciowe działają podobnie niezależnie od platformy, na której zostały zbudowane
uniwersalne standardy.
Idea SOA wywodzi się bezpośrednio z programowania obiektowego, co sugeruje związek między danymi a ich przetwarzaniem. W ten sposób formalnie definiują usługi za pomocą interfejsów, które są niezależne od platformy i języka programowania. Interfejsy te ukrywają specyfikę ich implementacji, co czyni je niezależnymi od programista i język programowania. Dzięki tym architekturom możliwe jest projektowanie i wdrażanie wysoce skalowalnych systemów, które odzwierciedlają logikę biznesową, a jednocześnie ułatwiają interakcję między różnymi systemami własnymi lub firm trzecich. Powodem, dla którego chcemy, aby ktoś inny wykonał pracę za nas, jest to, że są ekspertami. Skorzystanie z usługi jest zwykle tańsze i bardziej efektywne niż zrobienie tego samodzielnie. Tak więc większość z nas rozumie, że nie możemy być ekspertami we wszystkim. Tę samą zasadę można zastosować do tworzenia systemów oprogramowania.
Interfejsy są bardzo ważne, jeśli nie są dobrze zdefiniowane lub nie działają, system nie działa. Integracja większej liczby interfejsów jest kosztowna, a także zwiększa ryzyko wystąpienia błędów w aplikacjach rozproszonych. Zdalne interfejsy są najwolniejszą częścią większości aplikacji rozproszonych. Mając to wszystko na uwadze, zamiast budować nowe interfejsy dla każdej aplikacji, bardziej sensowne jest ponowne wykorzystanie ogólnych interfejsów dla wszystkich aplikacji.
Tak więc, ponieważ mamy dostępnych tylko kilka ogólnych interfejsów, musimy zawrzeć w komunikatach semantykę specyficzną dla aplikacji. Poprzez nasze interfejsy możemy wysyłać dowolne wiadomości, ale istnieją pewne zasady, których należy przestrzegać, aby powiedzieć, że architektura jest zorientowana na usługi.
– Po pierwsze, komunikaty muszą mieć charakter opisowy, a nie instruktażowy, ponieważ za rozwiązanie problemu odpowiada usługodawca. Na przykład byłoby to podobne do sytuacji, gdy idziesz do restauracji i mówisz kelnerowi, co chcesz wypić i jakie masz preferencje, ale nie powinniśmy tłumaczyć kucharzowi, jak krok po kroku przygotować twoje danie.
- Po drugie, usługodawcy nie będą w stanie zrozumieć Twojej prośby, jeśli ich wiadomości nie będą napisane w formacie, strukturze i słownictwie zrozumiałym dla wszystkich zainteresowanych. Tak więc ograniczenie słownictwa i struktury komunikatów jest m.in
niezbędne do skutecznej komunikacji. Im węższy przekaz, tym łatwiej go zrozumieć.
- Po trzecie, istotna jest możliwość przedłużenia. Świat jest ciągle zmieniającym się miejscem, podobnie jak środowisko, w którym żyje oprogramowanie. Zmiany te wymagają odpowiednich zmian w oprogramowaniu systemowym konsumentów usług, dostawców i komunikatów, które wymieniają. Jeśli komunikatów nie można rozszerzyć, konsumenci i dostawcy są zablokowani do określonej wersji usługi. Ograniczenie i rozszerzalność są ze sobą głęboko powiązane, potrzebujesz obu, a zwiększenie jednego oznacza zmniejszenie drugiego. Ideałem jest osiągnięcie prawidłowej równowagi.
– Po czwarte, SOA musi posiadać mechanizm umożliwiający konsumentowi odnalezienie usługodawcy w kontekście usługi poszukiwanej przez konsumenta. Mechanizm powinien być elastyczny, a nie scentralizowany rejestr.
- Po piąte, usługa bezpaństwowa: każda wiadomość wysyłana przez konsumenta do dostawcy musi zawierać wszystkie informacje niezbędne dostawcy do jej przetworzenia. To ograniczenie sprawia, że dostawca usług jest bardziej skalowalny, ponieważ dostawca nie musi przechowywać informacji o stanie między żądaniami. Można to nazwać „usługą produkcji masowej”, ponieważ każde żądanie można obsłużyć ogólnie. To ograniczenie zapewnia również lepszą przejrzystość, ponieważ każde oprogramowanie monitorujące może niezależnie sprawdzić żądanie i wyodrębnić jego intencje. Pozwala to również na łatwe odzyskiwanie po częściowych awariach, ponieważ nie ma stanów pośrednich, dzięki czemu usługa jest bardziej niezawodna.
- Po szóste, idempotentne żądania (bez wprowadzania zmian): zduplikowane żądania otrzymane przez agenta oprogramowania mają taki sam skutek jak pojedyncze żądanie. Wymóg ten umożliwia dostawcom i konsumentom zwiększenie ogólnej niezawodności sieci usługi, po prostu powtarzając żądanie, jeśli wystąpiła jakakolwiek awaria.
Można więc powiedzieć, że SOA nie jest narzędziem, ale zbiorem standardów do budowania nowych aplikacji, bardziej dynamicznych i mniej zależnych. SOA ułatwia dostęp do logiki biznesowej i informacji w wielu usługach w systematyczny sposób, a także może skoordynować wiele usług zdalnych, tworząc jedną. większość definicje identyfikują użycie usług sieciowych, co zobaczymy w następnym rozdziale, we wdrażaniu architektury zorientowanej na usługi. Można go jednak wdrożyć przy użyciu dowolnej innej technologii opartej na usługach.