BIVŠ. 1. Vývoj architektur podnikových systémů 2. SOA 3. Postup implementace 4. Nové trendy v SOA.

Prezentace na téma: "BIVŠ. 1. Vývoj architektur podnikových systémů 2. SOA 3. Postup implementace 4. Nové trendy v SOA."— Transkript prezentace:

1 BIVŠ

2 1. Vývoj architektur podnikových systémů 2. SOA 3. Postup implementace 4. Nové trendy v SOA

3 FutureToday1990 Monolithic Architecture 1980 Client-Server Architecture Component Oriented Architecture Service Oriented Architecture Dynamic Reconfiguration Architecture Structured programming Object oriented programming Distributed object technology (CORBA, DCOM, MOM) Web services (WSDL, SOAP, WSBPEL, ESB) Flexibility Time 2000

4  Monolitická architektura- jednovrstvá, uživatel obsluhuje počítač pomocí terminálu  C/S architektura (desktopové aplikace):  část aplikační logiky na straně klienta, GUI – tlustý klient  Nevýhoda: pracná údržba (správa verzí), změna-potřeba reinstalace na všech klientech

5  Komponentově orientovaná architektura (vícevrstvá, webové aplikace)  Aplikační logiku zajišťují komponenty na straně serveru-distribuovaná internetová architektura  Komunikace prostřednictvím internetového prohlížeče (tenký klient)  Výhoda: snazší údržba aplikací-jen na straně serveru

6  Sw aplikace se skládá z nejrůznějších objektů, objekty je možné sdružovat do větších celků – komponent  Základní jednotka použitelnosti, objekty s podobnou funkcionalitou  Vlastnosti komponent:  Komponenty jsou znovupoužitelné  Mají jasně definované rozhraní  Mají zapouzdřenou funkcionalitu (rozhraní jediným možným přístupovým bodem)  Komponenta je černá skříňka – použití nevyžaduje znalost vnitřních procesů a objektů Příklady komponent (spustitelný program, knihovna, textový soubor, tabulka v databázi,...). Příklady komponent (spustitelný program, knihovna, textový soubor, tabulka v databázi,...). Komponenty vznikají při tvorbě architektury jako samostatně navržené, vyvinuté a otestované části software, integrované do systému. Existují znovupoužitelné komponenty pro řešení častých problémů, vyvinuté v rámci projektu nebo samostatně (standardy JavaBeans, CORBA, ActiveX). Komponenty vznikají při tvorbě architektury jako samostatně navržené, vyvinuté a otestované části software, integrované do systému. Existují znovupoužitelné komponenty pro řešení častých problémů, vyvinuté v rámci projektu nebo samostatně (standardy JavaBeans, CORBA, ActiveX).

7  DCOM (Distribuovaný komponentový objektový model)  Uveden v roce 1996  Proprietární technologie Microsoft  Základem COM – komponentový model, který umožňuje komunikaci mezi klientem a serverem po síti  Složitá, nedostatečné zabezpečení  CORBA (Common Object Request Broker Architecture  OMG (Open Object Management Group), 90. léta  Podpora komunikace v distribuovaných systémech  Konec s nástupem internetu (standard http universálnější)

8  SOA je druh architektury, návrhu a integrace podnikových aplikací  Integrace na úrovni obchodních procesů - nejvyšší úroveň obchodní integrace  Prostředky pro správu obchodních procesů (Business Process Management Systems) umožňují definovat vztahy mezi jednotlivými aplikacemi a systémy ve formě, která odpovídá obchodním procesům rozumí jí i uživatel bez zvláštní znalosti programování

9  Statická architektura  pevná struktura daná při návrhu systému  komponentové modely ( diagramy v UML)  Dynamická architektura  struktura se vyvíjí za běhu, části systému vznikají a zanikají podle pravidel daných při návrhu systému)  Např. komponentový model Fractal, částečně SOFA  Mobilní (plně dynamická) architektura  části systému se přesouvají za běhu, mění vztahy s okolím podle funkčních požadavků, volné vazby)  Př. částečně SOFA 2.0 ( „nested factory“ komponent a mobilita „utility interface“)

10  Nejsou sjednocené definice  Wikipedia:  „SOA je softwarová architektura, kde funkcionalita je seskupena okolo business procesů a zabalena jako spolupracující služba (interoperable service).  SOA také popisuje IT infrastrukturu, která umožňuje různým aplikacím vyměňovat navzájem data podle jejich návaznosti v business procesu.  Záměr je volné navázání (loosely coupling) služeb s operačními systémy, programovacími jazyky a ostatními technologiemi, které jsou pod aplikacemi.“

11  „Servisně orientovaná architektura je architektonický styl, který podporuje servisní orientaci.  Servisní orientace je způsob myšlení v termínech služba a vývoj založený na službách.  Služba je logická reprezentace opakující se business aktivity, která má definovatelný výsledek (př. zkontroluj výši účtu zákazníka, vrať data o počasí apod.), je celistvá (self-contained), může se skládat z dalších služeb a pro zákazníky služby představuje ‘black box’.  Architekturní styl SOA má tyto rozlišující vlastnosti:  je založen na otevřených standardech; jednotlivé aplikace se prezentují jako služba,  definuje způsob reprezentace služeb a interakce mezi nimi,  aplikace se vnímají jako stavební bloky, které se dají znovupoužít v jiných službách/aplikacích,  vnímá IT infrastrukturu výhradně v kontextu business procesu  vyžaduje přísnou kontrolu a dohled (governance) nad službami a jejich implementací

12  Poskytovatel služby  Poskytovatel je vlastník služeb (SW, popisuje službu a ukládá do registru)  Register- broker  úložiště informací o poskytovatelích a jejich softwarových prostředcích  Spotřebitel služby  aplikace která vyhledává a iniciuje interakci s poskytovatelem služby

13  Komponenta podnikových procesů  znovupoužitelné stavebnicové jednotky business funkcionalit, procesů nebo technických funkcí, které jsou zpřístupněné a doručené v opakovatelné podobě spotřebitelům (MARKS)  mechanismus zpřístupňující jednu nebo více funkcionalit. Přístup je umožněn pomocí předepsaného rozhraní a je provozovaný ve shodě s omezeními a pravidly, které jsou specifikovány v popisu služby.“ (OASIS)

14  Příkladem služby vytvoření objednávky, zpracování objednávky, odeslání objednávky, fakturace objednávky, zrušení objednávky, atd. (komponenty procesu Vyřízení objednávky)  Kompozitní služba se skládá z jedné, nebo více jiných služeb  efektivní sdružování do vyšších celků  Řízení granularity návrhu služeb

15  Volné propojení služeb (loose coupling)  Nezávislé, mezi službami jen výměna i-cí o rozhraní (aktualizace = nahrazení jinou se stejným rozhraním)  Znovupoužitelnost služeb (reusability)  Snížení nákladů na vývoj (vše už někde je)  Bezstavovost služeb (statelessness)  Minimalizace množství informací uchovávaných pro další aktivity-vazba na znovupoužitelnost  Abstrakce služeb (abstraction)  skryta logická struktura, jen rozhraní  Autonomie služeb (autonomy)  Služby ovládají jen tu logiku, která je v nich zapouzdřena.

16  Kontrakt služeb (contract)  popisný dokument, určující způsob komunikace služby, transportní protokol, vstupní i výstupní zprávy atd.  Nezávislost na platformě (independency)  Možnost skládat služby (composability)  Nalezitelnost služeb (discoverability)  Standardizované rozhraní (interface)  Standardizované rozhraní (interface)  Spolupráce služeb (interoperability)

17  XML: universální samopopisný formát, prezentace a transformace dat  SOAP:  SOAP: (Simple Object Access Protocol) – protokol používaný pro komunikaci;  WSDL  WSDL (Web Services Description Language) - standardní formát pro popis rozhraní webové služby  UDDI :  UDDI (Universal Description, Discovery and Integration) : standardní mechanismus umožňující registraci a vyhledávání webových služeb

18 1.Vrstva systémů 2.Vrstva komponent 3.Vrstva služeb 4.Vrstva choreografie business procesů 5.Presentační vrstva 6.Integrační vrstva 7.Vrstva governance

19

20 Definice základních stavebních kamenů – služeb. Služby ze základní vrstvy jsou pak zpřístupněny uživatelům přes vrstvu tzv. veřejných služeb (bankomaty, veřejný portál, SMS brána), tedy služby GUI nebo B2B rozhraní. Definice základních stavebních kamenů – služeb. Služby ze základní vrstvy jsou pak zpřístupněny uživatelům přes vrstvu tzv. veřejných služeb (bankomaty, veřejný portál, SMS brána), tedy služby GUI nebo B2B rozhraní.

21  Implementace vrstvy technologických služeb. Integrační HUB zde zajišťuje výměnu dat mezi rezervačním a finančním systémem. Takto navržená architektura může zvýšit výkon celého systému oddělením integračních a prezentačních služeb

22 Procesní vrstva umožňuje snadnou implementaci složitých podnikových procesů, které v sobě mohou zahrnovat složitá rozhodovací kritéria nebo podmíněné spouštění nejrůznějších podsystémů a aplikací. Nová služba v tomto příkladu může obsahovat různé podmínky (nabídka slev na letenky), nebo verifikaci platby s bankou. Procesní vrstva umožňuje snadnou implementaci složitých podnikových procesů, které v sobě mohou zahrnovat složitá rozhodovací kritéria nebo podmíněné spouštění nejrůznějších podsystémů a aplikací. Nová služba v tomto příkladu může obsahovat různé podmínky (nabídka slev na letenky), nebo verifikaci platby s bankou.

23  Pružnost, rychlé zavedení  Snížení nákladů  Snadnější integrace  Zlepšená opakovaná využitelnost hotových řešení  Lepší přizpůsobivost potřebám organizací  Redukce rizika – incrementální implementace  SOA je přeceňovaná – prezentace jako univerzální řešení na IT problémy (to samé bylo s ERP systémy)

24

25 Cíle SOA (% respondentů) Přínosy SOA (výzkum AMR, průměrné náklady SOA projektů byly 667 000 $)

26 Nové Nepokrývají plnou funcionalitu (registr a řízení politik): Microsoft MuleSource Nastel SAP Oracle koupil: Sun Microsystems Amber point

27  Servisně orientované aplikace se stále více rozšiřují. Jejich zdroje jsou různé: dodavatelé balíkových aplikací (ERP systémy), privátní i veřejné cloudy, ale principy architektury stejné  Tyto služby se nabízejí jako Web API (application programming interface = metoda přístupu ke službě v terminologii SOA)  Mobilní aplikace stále více využívají privátní a soukromé API jako doplněk k záznamům podnikových IS  Gartner zavedl nový termín: application services governance  Cílem je upozornit na spojení technologických principů SOA a řízení API (viz dokument "Govern Your Services and Manage Your APIs With Application Services Governance„ https://www.gartner.com/doc/2239615/govern-services- manage-apis-application ) https://www.gartner.com/doc/2239615/govern-services- manage-apis-application

28  Trh je v pohybu, různé akvizice, např. Intel koupil Mashery

29  Popište vývoj architektur IS  Popište principy architektury klient/server  Popište principy architektury SOA (konceptuální model, používané technologie, vrstvy modelu)  Jaké jsou hlavní přínosy SOA, trendy ve vývoji