Podejście usługowe SOA
Jolanta Sala Halina Tańska
Usługa jest pojęciem podstawowym dla SOA
• Usługa biznesowa (business service) pojedynczy
komponent dostarczany przez IT do biznesu i wspierający realizację określonego zadania występującego w jednym lub więcej procesach biznesowych
• Usługa sieciowa (web service) komponent programowy niezależny od platformy i implementacji, dostarczający określonej funkcjonalności
• Usługa IT (IT service) wg ITIL opiera się na dostarczaniu i zarządzaniu usługami IT poprzez procesy, w tym
kontekście usługa jest pojęciem komercyjnym, opisanym w umowie pomiędzy Dostawcą (IT) i Odbiorcą (Biznes) m.in. outsourcing usług IT
SOA - usługi na pierwszym miejscu
• Architektura ukierunkowana na usługi to standaryzowane podejście organizacji i projektowania, wiążące ściśle IT z
procesami biznesowymi. Zaczyna się ono i kończy na procesach biznesowych, organizując do realizacji wspólnego celu
rozproszony zestaw technologii.
• SOA (Service Oriented Architecture) to oparta na standardach struktura, w której są budowane, wdrażane, zarządzane i
aranżowane usługi, mające zapewnić sprawniejszą infrastrukturę IT, szybko reagującą na zmieniające się wymagania biznesu.
• W architekturze ukierunkowanej na usługi informacje i procesy - niegdyś przypisane do aplikacji stworzonych do realizacji jednego konkretnego celu - stają się elementami zbioru szeroko
dostępnych i elastycznych usług programowych, które można integrować i wielokrotnie wykorzystywać.
SOA - usługi na pierwszym miejscu
Architektura SOA musi umożliwiać dynamiczne dodawanie i konfigurowanie usług na bieżąco, a także modyfikowanie przepływów logicznych między nimi, dopasowując sposób działania systemu do zmian w procesach biznesowych.
Celem architektury ukierunkowanej na usługi jest stworzenie w przedsiębiorstwie
elastycznej i trwałej infrastruktury,
która ułatwi połączenie dowolnego zbioru aplikacji w dowolnym czasie, tak aby możliwe było
sprostanie wyzwaniom rynkowym.
SOA - usługi na pierwszym miejscu
• Rozmach tego podejścia czyni z SOA koncepcję dość ogólnikową.
• Jednak potencjalne korzyści upatrywane w obniżce kosztów IT oraz większej sprawności biznesowej zachęcają wiele
organizacji do podjęcia trudu wdrożenia tej architektury.
• Jednym z motywów takich decyzji jest też to, że SOA może przynosić "efekt transformacji" w obrębie całego
przedsiębiorstwa, przy zachowaniu większości aplikacji i infrastruktury już wdrożonej.
• U podstaw SOA stoją trzy podstawowe koncepcje:
1. wirtualizacja usług,
2. usługi wielokrotnego użytku, 3. brokery usług.
Wirtualizacja usług
• Usługa jest kawałkiem kodu, który może być wywołany przez innego programistę za pośrednictwem
publikowanego interfejsu metadanych, określanego jako
"kontrakt usługowy".
• SOA wymaga zdefiniowania usług wielokrotnego użytku na wysokim poziomie, bez wikłania w to kodu aplikacyjnego.
• W ramach SOA każda usługa powinna mieć rozpoznawalne funkcje biznesowe, które odgrywają jasno określoną rolę dla wielu aplikacji.
• Przykładem takich usług biznesowych wielokrotnego użytku jest np.: weryfikacja tożsamości, przechowanie danych adresowych, wyliczenie wynagrodzenia itp.
1
Przykład: SOA w instytucji finansowej
Usługa wielokrotnego użytku
• Możliwość wielokrotnego używania usługi, to istotna obniżka kosztów.
• Podstawową zasadą przy wdrażaniu SOA jest zachęcanie
programistów do użytkowania istniejących usług - niezależnie kto je zaprojektował - w jak największym, możliwym
zakresie.
• Programiści, przy konstruowaniu nowych aplikacji, powinni tworzyć jak najmniej nowego kodu.
• Nowy kod powinien jedynie ulepszać aranżację nowych wzorców interakcji między istniejącymi usługami.
• Większy zakres ponownego wykorzystaniu kodów przekłada się na niższe koszty i skraca cykle projektowe.
2
Przykład: SOA w instytucji ubezpieczeniowej
Usługa wielokrotnego użytku
• Większy zakres ponownego wykorzystaniu kodów przekłada się na niższe koszty i skraca cykle projektowe.
• W praktyce cecha ta w dużej mierze zależy od warstwy pośredniczącej, która pozwala na współdziałanie usług za pośrednictwem sieci.
• W coraz większym zakresie wybieraną dla SOA strukturą
pośrednicząca są środowiska web services, wykorzystujące WSDL (Web Services Desciption Language), SOAP (Simple Object Access Protocol) i inne standardy WS-.
• Jednak w wielu implementacjach SOA usługi są współdzielone, aranżowane i wywoływane w tradycyjnych środowiskach
pośredniczących, które współdziałają na różne sposoby.
• Dla ekspozycji interfejsów aplikacyjnych w środowisku SOA można zamiast web services wybrać też XML, który jest transportowany protokołem HTTP lub transferu plików.
2
Brokery usług
• Brokery usług pozwalają programistom na deklarowanie swoich
programowych "kontraktów usług" i innych metadanych opisujących - we współdzielonym rejestrze online, repozytorium czy katalogu.
• Infrastruktura brokerów usług przybiera wiele form i są one często specyficzne dla poszczególnych środowisk pośredniczących i
platformowych.
• Standard UDDI (Universal Desciption, Discovery and Integration) definiuje środowisko brokerów usług dla web services.
• Inne popularne środowiska brokerów usług obejmują: Common Object Request Broker Architecture Naming Service, Distributed
Computing Environment Cali Directory Service, Windows NT Registry, Java Remote Method Invocation Registry i repozytoria Electronic
Business XML.
• W charakterze węzłów brokerów usług SOA można też wykorzystywać systemy zarządzania bazą danych.
3
Podsumowanie 3 koncepcji SOA
• Istotą prawdziwego środowiska SOA jest niezależność od platformy, zarówno operacyjnej, jak i aplikacyjnej.
• Tak więc przy każdej implementacji należy dbać o to, aby nie
wprowadzać specyficznych zależności od WSDL, SOAP, UDDI i innych standardów czy specyfikacji web services.
• Budując SOA, usługi webowe i inne środowiska projektowe,
współdziałania czy operacyjne, powinno się traktować jak szczegół implementacyjny.
• SOA jest ciągle jeszcze w fazie rozwojowej. W rzeczywistości jest
stanem docelowym, do którego wiele organizacji może się zbliżyć, ale nigdy nie osiągnie w pełni.
• Sprowadza się to do maksymalizacji wykorzystania usług i minimalizacji ich redundancji, w złożonych, wieloplatformowych środowiskach
rozproszonych.
12 3
Podsumowanie 3 koncepcji SOA
• SOA jest podejściem do projektowania systemów informatycznych, które zakłada współdzielenie funkcji aplikacyjnych wywoływanych w sieci.
• Jest to sposób na zrobienie więcej mniejszym wysiłkiem.
• Aplikacje mają być budowane szybciej, w sposób przyrostowy, z niewielką liczbą nowych wierszy kodu.
• Potencjał SOA tkwi w tym, że niewielkie koszty budowy nowych
aplikacji ulegają dalszemu zmniejszeniu w miarę zwiększania stopnia wykorzystania usług.
• Trudność polega jednak na tym, że adaptacja SOA wymaga zmiany tradycyjnego myślenia o: modelowaniu, projektowaniu, integracji, wdrożeniu i zarządzaniu aplikacjami.
• Wiele z oszczędności, jakie daje SOA, ma swoje źródło w zdolności
konsolidowania, w ramach całej organizacji, tzw. silosów nadmiarowej funkcjonalności aplikacyjnej i danych.
12 3
Architektura zorientowana na usługi
Przykład podstawowych składników SOA
Według analiz Forrester Research
• Projektowanie oparte na SOA może być początkowo droższe od tradycyjnego podejścia, gdy poszczególne etapy rozpatruje się oddzielnie, z uwzględnieniem budowania poszczególnych
komponentów aplikacji.
• Jednak gdy te aplikacyjne komponenty zaczynają być w coraz szerszym zakresie używane wielokrotnie, SOA staje się
podejściem bardziej efektywnym niż podejście tradycyjne.
• SOA jest jednak nadal koncepcją dość mglistą dla wielu
specjalistów IT i w mniemaniu wielu osób rozciąga się na szeroki krąg luźno związanych ze sobą technologii i podejść.
• Badania przeprowadzone wśród największych firm w Stanach Zjednoczonych (2005), wykazały, że 70% respondentów już
zaimplementowało SOA, a oszacowano, że planuje wdrożyć 51%
średnich firm i 46% małych.
Małymi krokami do celu
• Z SOA wiązane są nadzieje na sprawną przebudowę infrastruktury IT w biegu.
• Im bardziej dynamiczny biznes, tym więcej może skorzystać na dobrej implementacji SOA.
• Także im więcej sprzymierzeńców, którzy podzielają wizję SOA, tym lepiej.
• Pomocne jest w szczególności pozyskanie silnych partnerów w ramach organizacji, szczególnie ze sfery zarządzania biznesowego, którzy rozumieją konieczność obniżki kosztów i przyspieszenia
reakcji na zmiany w całej organizacji.
• Taka wspólna wizja może być rozległa, ale opłaca się startować z małym projektem.
• Dobrze jest zaczynać od udostępnienia w formie usługi kilku tradycyjnych aplikacji o krytycznym znaczeniu, zapewniając na początek dostęp do ważnych danych i funkcji innym aplikacjom.
Struktura usług operatora
telekomunikacyjnego
Małymi krokami do celu
• Można też użyć współdzielonych usług do wyeliminowania
redundancji wśród kilku trudnych do utrzymania aplikacji, których funkcjonalność się pokrywa.
• Takie projekty mogą przynosić widoczne korzyści m.in.:
– ograniczenie kosztów integracji infrastruktury IT i szybsze reagowanie na potrzeby;
– zwiększenie elastyczności i efektywności działania w obliczu takich wyzwań, jak: fuzje i przejęcia, konsolidacja oraz konieczność przestrzegania
przepisów i regulacji prawnych;
– uproszczenie procesu tworzenia, serwisowania i eksploatacji aplikacji oraz obniżenie związanych z tym kosztów;
– zapewnienie działom IT elastyczności pozwalającej sprostać stale zmieniającym się potrzebom przedsiębiorstwa.
• Należy przede wszystkim odpowiedzieć sobie na pytanie, jakie są te problemy biznesowe, które próbujemy rozwiązać, i jak się one mają do innych obszarów funkcjonalnych organizacji?
Narzędzia SOA
• Głównymi poziomami infrastruktury opartej na SOA są brokery usług, motory aranżacji, środowiska warstw pośredniczących opartych na wymianie wiadomości oraz narzędzia zarządzania na poziomie usług.
• Projektanci używają często graficznych narzędzi definiowania procesów, pozwalające im na specyfikowanie zadań aranżacji, zależności, routingu i kroków procesu za pomocą diagramów. Podejście to nazywa się także projektowaniem typu model-driven.
• Środowiska MOM (Message-Oriented Middleware) zapewniają możliwość ponownego użycia usługi, przewidując protokoły:
gwarantowanej dostawy wiadomości (reliable messaging),
powiadamiania o zdarzeniach oraz publikowania i subskrypcji, które łączą punkty końcowe aplikacji heterogenicznych w szynę usługową
przedsiębiorstwa.
• Zarządzanie infrastrukturami na poziomie usług zapewnia
monitorowanie, optymalizowanie, sterowanie i integrację rozproszonych środowisk aplikacyjnych. Bardziej rozpowszechnionym określeniem tej funkcjonalności jest WSM (Web Sentice Management).
Jak to zrobić?
Jednym ze sposobów są działania w trzech obszarach:
• SOA Governance – zadaniem jest przygotowanie reguł, podziału
odpowiedzialności, itp., czyli: modelu procesów, według którego usługi będą przygotowywane (SOA Design) i zarządzane (SOA Management) a następnie monitorowanie wykonania i udoskonalenie tychże procesów.
• SOA Design – jest zespołem działań i środków (w ramach procesów wytyczonych przez SOA Governance mającym na celu przygotowanie nowej usługi lub zmianę (łącznie z wycofaniem) istniejącej usługi.
• SOA Management – obejmuje administrację infrastrukturą IT, monitorowanie, strojenie jak również wsparcie przy wdrożeniu nowych i zmienionych usług.
Obowiązuje zasada 4xP:
• People (zasoby ludzkie, wiedza, umiejętności, świadomość, komunikacja)
• Processes (organizacja zarządzania i pracy poprzez odpowiedni model procesów)
• Products (technologie, oprogramowanie, sprzęt)
• Partners (współpraca z poddostawcami wewnętrznymi i zewnętrznymi, współpraca pomiędzy wszystkimi stronami zainteresowanymi)
Dostawcy SOA
IBM, SAP, Oracle, Software AG, BEA, Cisco, HP, MS i inni
Przykład: Service Oriented Network Arcitecture firmy Cisco
Przykład: SOMA (Service Oriented Modelling and Architecture)
Szablon (SOMA) procesów wytwórczych dla rozwiązań SOA zbudowany przez IBM na bazie klasycznego RUP (Rational Unified Process) jest dostępny w formie plug-in do narzędzia RUP Method Composer lub w formie darmowej publikacji HTML.
Materiały źródłowe
• Józef Muszyński, SOA - usługi na pierwszym miejscu, Computerworld, 2006,
https://www.computerworld.pl/news/SOA-uslugi-na-pierwszym-miejsc u,316935.html
• Jarosław Łagowski, SOA – Ideologia nie technologia, XV Konferencja PLUG, 2009,
http://www.ploug.org.pl/wp-content/uploads/ploug-konferencja-15-13 _SOA_-_Ideologia_nie_technologia.pdf
• Piotr Waszczuk, SOA: czym jest, czym nie jest?, Computerworld, 2008, https://www.computerworld.pl/news/SOA-czym-jest-czym-nie-jest,148 360.html
• Rafał Jakubowski, SOA? O co chodzi?, Computerworld, 2008,
https://www.computerworld.pl/news/SOA-O-co-chodzi,322849.html
