Datová úložiště v servisně orientovaných systémech

1. Datová úložiště v servisně orientovaných systémech SOA a dávkové subsystémy

2. Servisní orientace • Mnoho definic a variant SOA, • všechny mají společné to, že je systém z technického hlediska sítí autonomních entit, které se chovají velmi podobně jako služby reálného světa • Takový systém musí být z technického hlediska virtuální p2p síť autonomních komponent • My budeme diskutovat sítě, které jsou v praxi nutné pro SOA velkých systémů, jako je e-government nebo IS globálního podniku • Test SOA – integrace existujících systémů (legacy systems)

3. Rozhraní systému 1 Příklad SOA Rozhraní systému A – aplikační služba, B – její rozhraní (primární brána) UR je uživatelské rozhraní, např. portál Staré aplikační rozhraní je u komplexnějších služeb nutností (viz IS úřadů), usnadňuje podstatně vývoj.

4. Janusovské tváře SOA • Zdá se samozřejmé a není (specifické paradigma) • Desetinásobné snížení pracnosti realizace velkých systémů • Zdá se, že to není nic nového avšak jde o podstatné změny • Marketingové – co koupit, co znovu využít • Technické – nejde v prvé řadě o podporu distribuovanosti, jiné vzory a antivzory než v OO • OO Antivzor Legacy systems je základním SO vzorem • Inversní přístup – programují se hlavně (architekturní) služby sloužící jako rozšíření middlewaru a budování SOA, aplikace se většinou již s výjimkou bran neprogramují

5. Důvody pro používání existujících aplikací • Přímé úspory na vývoj • Nepřímé úspory na straně uživatele • Používá se pro staré funkce beze změn, lidé se nemusí zaučovat • Úspory spojené s náklady přechodu a nové funkce • Úspory způsobené začátečnickými chybami • Úspory plynoucí ze stability systému • Úspory na údržbu • Větší důvěra v systém • Nelze někdy jinak (IS úřadů) • Podpora autonomie divizí a dceřinných závodů

6. Základní prvky SOA • Aplikační služby resp. Systémy (často znovupoužité existující aplikace) • Prostředky pro přenos zpráv a formátování zpráv – middleware • Dolní vrstvy OSI • Doplňkové služby • výrobci jich nabízejí stále více a více (srv BEA ESB)

7. Stumpf Jindřich, Progress Software, Systémová integrace 2004 “Do roku 2005 bude Podnikovou sběrnici služeb (ESB) kombinující messaging, webové nebo i jiné služby, inteligentní směrování a transformaci dat, modelovánía řízení business procesů, používat většina podniků.“ Roy Schulte, VP and Research Fellow, Gartner Inc. ERP Budoucíaplikace Vlastní aplikace JMS Adapter XML/HTTP-D Sonic Enterprise Service Bus (ESB) Definice směrovací služby Definice transformačníslužby Internet JCA SOAP/HTTP SOAP/HTTP Legacysystems .NETApplication Web service Co je podniková sběrnice služeb?

8. Jak na SOA/ESB Které middlewarové funkce nakoupit a které si vyvinout sám? • Ne vše, co se nabízí, je vhodné a leccos úplně chybí (např. datová úložiště, uživatelsky orientovaná rozhraní) • Co integrovat do aplikačních služeb,obvykle do bran • Adaptér- objekt, ne vždy rozumně lze, datové úložiště • Co do služeb podporující integraci (dále architekturní služby) • Adaptér - služba • Někdy je i možnost změn programů implemetujících část middlewaru

9. Interaktivní a dávkové služby • Většina komponent v SOA komunikuje prostřednictvím ne extrémně dlouhých zpráv a doba provedení požadavků zpravidla není příliš dlouhá • Někdy je ale vhodné/nutné použít nebo znovupoužít komponenty, pro které to neplatí a musí pracovat dávkově • Algoritmy rozvrhování, programy spolupracující s reálným světem, čištění dat, transformace finančních dat • Někdy je vhodné použít osvědčené dávkové programy, nebo je dokonce znovu napsat včetně používání DFD • Snazší vývoj, úspory díky znovupoužití • Větší spolehlivost • Větší stabilita (zkušenost z Y2K)

10. Řešení – část SOA jsou dávkové programy komunikující tak, jak předpokládá digram toku dat

11. uživatelé nebo „řídící“ služby Dávková služba   řídící zprávy Vstupní/výstupní kolekce dat Architekturní služba     „Datové úložiště“  ostatní služby Integrace dávkového programu do SOA Architekturní služba, nástroj budování architektury

12. Kdy jsou potřeba komunikační služby s datovými úložišti • Služba běží dlouho a produkuje velké množství dat (plánování), nebo je prostě dávková • Je žádoucí použít existující dávkovou službu • Implementace složitých variant komunikace (obsluha částečně záměných pracovišť) • Snazší a stabilnější implementace nebo snazší sourcing • Decentralizace repositářů (globálních služeb) • Úložiště může být použito pro určitý typ uživatelů, kteří mají specifické principy na hodnocení souhrnné kvality souborů dat, obsahujících podmnožiny dat různé kvality

13. Co s centrálními repositáři • p2p se nesnáší s centrálními službami • Neúspěch UDDI jako celosvětových repositářů • Co s repositáři, které např. potřebuje business intelligence • Repositář byznys procesů? • Řešení: Repositář může být decentralizovaný a nemusí být v konkrétním případě použit

14. Business proces v SOA • Síť kroků • Krok je provedení příkazu nějakou službou (i sítí služeb, kompositní službou) • Je vhodné si pamatovat průběh provedených procesů, resp. modelovat proces • Neměl by být centrální repositář modelů procesů využívaný v průběhu celého procesu (důsledek p2p architektury), raději distribuovaná databáze • Potřeba využívání různých prostředků popisu procesů (volný text, BPEL, Aris, Petriho sítě,…. )

15. Požadavky na business procesy v SOA • Za akce procesu (provedení služeb) je někdo odpovědný (vlastník procesu), musí jim proto rozumět, • to je prakticky možné jen, když má služba vhodné (uživatelsky orientované) rozhraní • Postup procesu musí mít možnost sledovat objednatel procesu (viz SCM) • Data používaná procesem mohou být nekvalitní, proces musí často reagovat na náhlé změny podmínek • Proces lze agilně měnit • Příkazy procesu musí být srozumitelné uživatelům (rozhraní musí být usable)

16. Business procesy, enactment • Řešení:Specializovaná služba manažer pro každý proces, simuluje prvky portálu, iniciální data z repozitáře Vlastník procesu Portál Inicializace Aplikační služby Repozitář Manažer Iniciální data Řízení Manažer se vytváří pro každý proces znovu, je to služba, která se chová jako instance procesu Repositář nemusí obsahovat žádný vhodný model, pak ho bude skrytě vytvářet vlastník procesu. Vlastník procesu může vytvářet model, nebo ho modifikovat, následně doplní parametry –proces inicializuje. Tím vzniknou řídící data procesu v BPEL

17. Business procesy, run Portál Majitel procesu Řízení Inicializace Cizí zájemci, objednatelé Repozitář Aplikační služby Manažer • Řešení s využitím standardů popsaných v www.bpmi.org • Modely procesů v BPML (dialekt XML), které se při inicializaci mění na datovou strukturu v BPEL používanou v manažeru jako „program“ procesu • Data manažeru v BPEL (XML), upravují se podle parametrů inicializace zadané vlastníkem procesu • Při provádění procesu může Majitel data procesu v BPEL a tím i proces měnit (agilita). Manažer používá rozhraní dané instance procesu. Vlastník není programátor  rozhraní kroků musí být uživatelské (použitelné, usable).

18. Jak vyrobit usable rozhraní • POUŽÍT ADAPTÉR transformující zprávy služby do vhodného formátu • Adaptér jako objekt integrovabý do brány služby • Sahám do černé skříňky!!!! • Adaptér jako služba • Obecnější • Je logicky předřazen bráně B služby

19. Logický a implementační pohled na předřazenou bránu Aplikační B služba Nízkoúrovňové zprávy Zprávy deklarativní Předřazená brána a) Logický pohled Aplikační B služba Předřazená brána Nízkoúrovňové zprávy Zprávy deklarativní M I D D L E W A R E b) Implementace

20. Výhody použitelného (usable) rozhraní • Založeno na dlouhodobé zkušenosti uživatelů – bude stabilní • Lze snadno vyrobit prototypy • Důležité pro agilitu byznys procesů • Větší autonomie částí (rozhraní skrývá implementační detaily)

21. Prototypování, ladění SOA systémů Uživatelské rozhraní (portál) Implementovaná služba Přesměrováno, lze pomocí architekturních služeb Implementovaná služba Middleware Dosud neimplementovaná služba Implementovaná služba; SIMULATOR log Zprávy lze přesměrovat beze změny implementovaných služeb buď na uživatelské rozhraní (efektivní prototyp, použitelné i za běhu systému), nebo dokonce na simulátor (ladění RT systémů)

22. SOA s přeřazenými branami, logický pohled UR A B PB PB A1 B A B Middleware PB Staré rozhraní pro A1 PB log A B UR Předřazená brána, může jich být více, mohou i chybět. Pozor! B a PB také komunikují přesmiddleware PB

23. Nejsilnější varianta architekturní služby log

24. Záhlaví kompositní služby Varianta GPP (specializace), Předřazená brána je specializace záhlaví kompositní služby

25. Varianta GPP (specializace), portál, vnější „služby“ jsou uživatelé

26. Problémy • Nové marketingové, obchodní a manažerské přístupy • Optimální vyžití architekturních služeb • Využití výzkumu gridů • Rovnováha kupovaného, starého a nově vyvíjeného softwaru • Zvládnutí nových vzorů a optimální kombinace OO a SO

27. Závěr • Ve většině servisně orientovaných systémů nemůže mít databáze centrální roli. • Ve většině případů je lépe, aby data zůstala „uvnitř“ jednotlivých služeb a byla přístupná jako virtuální a centrální databáze. • Toto řešení je vyhovující, jsou-li všechna data vyhovující kvality. Pokud tomu tak není, je ve většině případů nutné, aby se virtuální integrace dat prováděla pod dohledem uživatelů, kteří vyhodnotí/zvolí kvalitu integrovaných dat.

28. Závěr • Přístup k datům je vhodné implementovat jako architekturní služby, které mohou být s výhodou použity jako zapouzdřená datová úložiště, která lze výhodně využít pro integraci aplikací běžících v dávkovém režimu, pro rozšíření možností komunikačních protokolů a virtualizaci centrální databáze. • Architekturní služby včetně datových úložišť jsou základními vzory v SOA, • Umožňují prototypování • Umožňují tvorbu agilních business procesů a „service governance“ • Ve formě PB zvyšují použitelnost procesů a zlepšují SW inženýrské vlastnosti systému