Orientace na služby -- klíčové paradigma současného softwaru Varování Budu říkat zřejmé věci, kterých si však ke své škodě nevšímáme. Opomíjení samozřejmostí je hlavní problém IT všeobecně a softwaru zvláště. Varování 2 Problémem je, že servisní orientace je zdánlivě samozřejmá. Paradoxně ji právě proto nevěnujeme dostatek pozornosti a nejsme ji proto schopni používat, ačkoliv se stává vedoucí filosofií současného softwaru. Ten se stává síťový z logického hlediska Nová móda? Příklady SO ze života Konfederace a aliance Konfederace volné a úzce vázané Těsnost vazeb * e-komerce * Informační systém státní správy * Spolupráce zdravotnických zařízení * Možná implementace CRM, SCM * Informační systém globálního podniku * Řízení procesů (soft real-time) * OO aplikace Příklady SO ze života Prvky SO se dosti běžně používají Informační systém je vždy součástí většího systému obvykle zahrnujícího i lidi a neautomatizované činnosti Systémy mezi sebou spolupracují Aby mohly být používány rozumně, musí spolupracovat podobně jako služby reálného světa, asynchronně reagovat na požadavky z různých zdrojů a být používány jako černé skříňky. To reálně lze dosáhnout jen, tvoří-li virtuální p2p síť. Pozorování Pozorování * Spolupráce může být dávková -- exportem a importem dat -- pomocí společného (virtuálního) datového úložiště plněného dávkově * Spolupráce může být interaktivní -- Přímá výměna zpráv -- Aktivní databáze * Některé služby mohou být dávkové (Excel) Jak zajistit, aby jedna služba čekala na dokončení jiné služby * Odpověď obsahuje identifikaci volání, tj. odesilatele požadavku, informace, které umožní pokračovat v daném vláknu * Je možné systémově a obecněji, proto standard service bus Praha 1.11.2005 Je běžné, že informační systémy komunikují s jinými informačními systémy. Informační systémy mohou fungovat jako systémy automatického řízení (avionika letadla), dávat rozkazy lidem, být (dočasně) nahrazeny lidmi, řídit procesy reálného světa (tam je nutno řešit problém dostupnosti dat a problém včasnosti odezvy) Servisně orientovaná architektura Nové faktory v SW průmyslu Aliance a konfederace a normy Ukážeme, že servisní orientace je specifické paradigma. Paradigma Problém přijetí paradigmatu Registr účtů a dluhů Registr účtů a dluhů Registr účtů a dluhů Nutnost konfederace, IS globálního podniku Důsledky I. Nutnost konfederace, státní správa Kdy je nutné použít SO, příklad státní administrativy Kdy je nutné použít SO, příklad státní administrativy Kdy je nutné použít SO, příklad státní administrativy, výhody Důsledky II Kdy je nutné použít SO, příklad nákupního kartelu amerických automobilek Jako černé skříňky musí také komunikovat IS jednotlivých složek zdravotního systému. Společné vlastnosti všech servisně orientovaných systémů Společné vlastnosti všech servisně orientovaných systémů II Kdy je nutné použít SO Kdy je nutné použít SO Výhody servisně orientované architektury Výhody servisně orientované architektury Výhody servisně orientované architektury Proč až nyní takový poprask Proč až nyní takový poprask Proč až nyní takový poprask Klíčová role architektury Praha 9.11.2005 Architektura aliance a konfederace Struktura brány Důsledky p2p architektury Důsledky p2p architektury Obvyklá architektura aliance, e-komerce Podmínky spolupráce v alianci Deklarativnost kontra procedurálnost Formáty zpráv v alianci Nevýhody aliancí Nevýhody aliancí Výhody aliancí * V e-komerci v podstatě jinak nelze * Služby lze programovat autonomně, podobně jako kdysi programy používající hloupé terminály * Využívají se webovské služby a výsledky výzkumu sémantického webu * V lidské společnosti fungují služby podobně, lze použít analogické postupy Proč konfederace Souhrn hlavních rysů konfederace Vlastnosti konfederací Vlastnosti konfederací Vlastnosti konfederací II Vlastnosti konfederací III Neinteraktivní komunikace Důvody Řízení na buffery Pozorování Pozorování Pozorování Další výhody konfederací Doporučení, uplatnit, pokud lze Doporučení, uplatnit, pokud lze Klíčová role rozhraní * Stabilita konfederace závisí především na stabilitě (neměnnosti) rozhraní * Jazyk rozhraní by měl být vysoké úrovně (deklarativní) * Rozhraní by se mělo chovat podobně jako rozhraní služeb v reálu (být uživatelsky orientované) -- Být srozumitelné uživatelům, mělo by být podobné tomu, nač jsou zvyklí; je to nutné pro návrh a kontrolu průběhu business procesů -- Takové má šanci nebýt měněno, je vlastně ověřeno dlouhodobým používáním Potřeba metadefinic Hlavní problém uživatelského rozhraní: Potřeba skládat dokumenty Řešení bylo nalezeno také v jazyce XML a nástroji XSLT XML a uživatelské rozhraní XSLT může transformovat v jednom kroku m vstupních zpráv na n výstupních zpráv Takový aparát můžeme chápat jako zobecnění míst (places) v Petriho sítích s barevnými značkami XML a uživatelské rozhraní V čem je XML s podpůrnými nástroji důležitý (nutný) Techniky 1 Zlepšení stability rozhraní Konfederace a SOA Konfederace s přeřazenými branami, konkrétní propojení Jak implementovat brány * Jako zcela plnoprávné uzly * Integrovat do middlewaru * Integrovat do akomponent * Kombinovat přístupy Konfederace s přeřazenými branami Předřazené brány (PB) jako místa v zobecněných Petriho sítích a barvenými značkani Jiný pohled na konfederaci Konfederace pro strojovou byrokracii (podniky) jsou úžeji vázány, lze požadovat větší úpravy komponent a použít pak standardy. Pro takové systémy nemusí být přeřazené brány službami a mohou se implementovat jako rozšíření služeb, tj. splynou s branami služeb spolu s doplňky do Middlewaru N^2 formátů a service bus Co je podniková sběrnice služeb? Co to přineslo Hrozby a příležitosti Co to ale stojí Net Weaver od SAP Business procesy Business procesy Business procesy Business procesy Uživatelsky orientované rozhraní služeb Inženýrské výhody uživatelsky orientovaných rozhraní Principy agilního vývoje 1 Principy agilního vývoje 2 Principy agilního vývoje 3 Agile development prefers: Uživatelsky orientované rozhraní (UOR) a agilní formy vývoje Důsledky Pozorování Typy infrastrukturních služeb Dopad na organizační hierarchii Kde hlavní přínosy Možný model SOA Infrastrukturní služba Logický pohled na konfederaci Neinteraktivní komunikace Specifikace požadavků Objektovost a konfederace Kdy je potřeba objektovost Úvahy a otevřené problémy Úvahy a otevřené problémy Úvahy a otevřené problémy Co chybí Co lze očekávat v budoucnosti Co lze čekat v budoucnosti Příbuzné problémy Důsledky pro SW profese