Vzal jsem si na projektu na starost SOA governance a s tím související nalezení nějakého vhodného nástroje, který by ji podpořil. Protože to budu muset v brzké (a nejspíš i pozdější) době prezentovat, chci si tady k tomu sepsat pár bodů, o čem to vlastně je. Co to je SOA ví každé malé dítě ;-) takže se tím nebudeme zdržovat a jdeme rovnou na věc.3 P
Tři P můžou znamenat cokoliv, v tomto případě jsou to: lidé (people), procesy a politiky a v těchto kategoriích si můžeme klást následující otázky:
People:
Tyto otázky bychom měli mít do určité míry zodpovězené. S jejich tvorbou a udržováním by nám měl pomoci vhodný nástroj.
Tvrzení známe i z jiných IT domén, např. unit testy. Tvrzení by mělo být měřitelné a mělo by mít disjunktní odpověď pravdivé/nepravdivé (true/false). Vlastník politiky je jasný - je za politiku zodpovědný, udržuje ji atd.
Prosazování politiky může probíhat dvěma způsoby. Buď technologicky, nějakým automatizovaným nástrojem, nebo pomocí review. Obojí opět známe odjinud, např. automatizovaná statická analýza zdrojového kódu vs. "ruční" review.
V případě prvních dvou bodů pomůže repository, kde se dají politiky a služby zaregistrovat. V případě služeb (design fáze) bude ještě potřeba o nich udržovat metadata. Pro runtime fázi bude potřeba nějaký monitorovací nástroj, v SOA se běžně používají řešení, která spadají do kategorie Business Activity Monitor (BAM).
Design-time politiky:
Runtime politiky:
People:
- Kdo je business vlastníkem služeb?
- Kdo používá naše služby?
- Kdo je za služby techn(olog)icky zodpovědný?
- Které procesy definují politiky?
- Jaké business procesy závisí na našich službách?
- Je zde proces pro životní cyklus služeb?
- Jaké politiky jsou pro naše služby definované?
- Jak jsou politiky aplikované během design a runtime fáze?
Tyto otázky bychom měli mít do určité míry zodpovězené. S jejich tvorbou a udržováním by nám měl pomoci vhodný nástroj.
3 části politiky
Politika se skládá ze tří částí:- tvrzení (policy assertion),
- vlastníka (policy owner)
- a prosazení/vynucení (policy enforcement).
Tvrzení známe i z jiných IT domén, např. unit testy. Tvrzení by mělo být měřitelné a mělo by mít disjunktní odpověď pravdivé/nepravdivé (true/false). Vlastník politiky je jasný - je za politiku zodpovědný, udržuje ji atd.
Prosazování politiky může probíhat dvěma způsoby. Buď technologicky, nějakým automatizovaným nástrojem, nebo pomocí review. Obojí opět známe odjinud, např. automatizovaná statická analýza zdrojového kódu vs. "ruční" review.
3 oblasti podpory SOA governance
Nástroj pro SOA governance by nám měl pomoci ve třech oblastech:- Vytváření a správa politik.
- Aplikování těchto politik v design fázi.
- Aplikování těchto politik v runtime fázi.
V případě prvních dvou bodů pomůže repository, kde se dají politiky a služby zaregistrovat. V případě služeb (design fáze) bude ještě potřeba o nich udržovat metadata. Pro runtime fázi bude potřeba nějaký monitorovací nástroj, v SOA se běžně používají řešení, která spadají do kategorie Business Activity Monitor (BAM).
Příklady politik
Aby jsme si pod politikami představili něco konkrétního, uvedu pár příkladů.Design-time politiky:
- Nevytváříme duplicitní služby. Tohle bývá těžký, nápomocná může být impact analýza. Služba se většinou v čase mění, přibývají nové funkčnosti a využití a tak časem může dojít i k rozštěpení služby na dvě. Při změnách v čase je potřeba mít neustále na paměti zpětnou kompatibilitu kontraktu služby.
- Technologická standardizace. Velkou část za nás řeší zvolená SOA platforma, ale některé věci je potřeba definovat politikou. Např. interní služby používají REST, externí služby jedou přes WS-*.
- Validace zpráv. Celkem jasný. Problém bývá validaci vůbec zapnout.
Runtime politiky:
- Dostupnout služby 24x7. Služba buď běží, nebo neběží. Tohle souvisí se Service Level Agreement (SLA).
- Služby používají zabezpečený kanál. HTTPS atd.
- Služby jsou "sebe-popisné" (self-describing). Tohle může být i součástí design fáze. V runtime je to myšleno tak, že po deploymentu je služba použitelná i bez dodatečné dokumentace.
