SOA governance, lehký úvod

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:

• Kdo je business vlastníkem služeb?
• Kdo používá naše služby?
• Kdo je za služby techn(olog)icky zodpovědný?

Procesy:

• Které procesy definují politiky?
• Jaké business procesy závisí na našich službách?
• Je zde proces pro životní cyklus služeb?

Politiky

• 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.

Co dál?

Tak. To je momentálně asi všechno, co k tomu můžu obecně napsat, aniž bych zmiňoval konkrétní nástroj. Jestli se nám nějaký podaří na projektu rozjet, tak nějaký článeček určitě přibude.