↓Přeskočit na hlavní obsah
  1. Tags/

Soa

2013

Oracle SOA certifikace

·3 min
Soa Certifikace Knihy Oracle Soa-Suite
Půlrok se sešel s půlrokem a já jsem si vystřihnul další certifikaci. Tentokrát jsem chtěl něco, čím bych zakončil své roční působení na projektu a důstojně :-) tak završil trnitý proces získávání znalostí o nové technologii: Oracle SOA Suite.

Okolnosti tomu chtěly, že jsem se zrovna trefil do přelomu, kdy Oracle jednu  SOA certifikaci nahrazuje jinou. Aktuální certifikace, která je k dispozici od letošního ledna, se jmenuje  Oracle SOA Suite 11g Certified Implementation Specialist. Já, protože jsem se ke zkoušce přihlásil již dříve, jsem nyní obdržel certifikaci Oracle Service Oriented Architecture Infrastructure Implementation Certified Expert. Uff! To je titul :-/

Každopádně, co je nám po jménu? Podstatné je, jestli se obě zkoušky od sebe nějak obsahově liší. Liší? Ano, ale pouze drobně - v nové certifikaci přibylo pouze něco málo o governance, deploymentu a monitoringu, ale gró zůstává stejné: jednotlivé komponentní technogie (viz Exam Topics).

Jak dlouho jsem se na certifikaci připravoval? Přípravě přímo na zkoušku jsem věnoval cca 3 týdny - přečetl jsem si guide (viz dále) a prošel testovací otázky. Ale obecně jsem k certifikaci studijně směřoval téměř celý rok. Za jeden z podstatných zdrojů vědomostí totiž považuji přímou zkušenost s technologií - 7 měsíců intenzivního "programování".

Kniha

Vývoj samotný z učedníka mistra neudělá. Primárním zdrojem informací jsou pro mne knihy, takže od nich jsem začal: hned z počátku práce na projektu jsem si koupil knihu Oracle SOA Suite 11g Handbook.

Jde o 800stránkový opus a pokud to někdo myslí se SOA Suitou vážně, tak rozhodně tuto knihu doporučuji - obsahuje vyčerpávající sumu témat (daleko přesahující rozsah zkoušky), které umožní pochopit principy, které za SOA Suitou stojí a provede návrhem, vývojem, testováním a provozem jednotlivých komponent a technologií. Ještě jednou: vysoce doporučuji!

Školení

Školení obvykle v portfoliu přípravných zdrojů nemám, tentokrát se mi ovšem naskytla příležitost, tak jsem ji využil a absolvoval školení hned tři:
  • Oracle SOA Suite 11g Implementation Bootcamp
  • Oracle Service Bus 11g
  • Oracle BPM Suite 11g Implementation Bootcamp
Školení nebyla špatná. Probíhala formou labů, takže si člověk mohl věci prakticky vyzkoušet. Tematicky školení zkoušku více méně pokrývala (s výjimkou BPM, který v certifikaci není) a umožnila mi trochu jiný pohled na věc, než byl třeba v knize, nebo jsem sám získal praxí. Z pohledu certifikace nejsou školení nutností, ale příjemným bonusem - stejné informace se dají získat i jinde a levněji :-)

Certifikační guide

Krátce před zkouškou jsem pořídil knihu Oracle SOA Infrastructure Implementation Certification Handbook, což je certifikační guide zaměřený na původní zkoušku (1Z0-451). Co se týká obsahu, kniha je slušným, velmi lehkým úvodem do SOA Suite. Jako studijní materiál je nedostačující. Co je na ní cenné, je sada testovacích otázek a odpovědí ke každému tématu, plus závěrečný test (také s řešením).

Závěr

Pokud vezmu v potaz svoji celoroční "přípravu", tak pro mne certifikace splnila (opět) svůj hlavní účel - motivační prostředek pro sebevzdělávání. Tak jako u jiných zkoušek i nyní mě certifikace přinutila podívat se do hloubky i na témata, která nutně (projektově) nepotřebuju a umožnila mi tak lépe pochopit celý kontext dané technologie.

Kecám, nepřinutila - já to dělám rád ;-)

Související články

2012

SOA Patterns, kniha

·2 min
Patterns Soa Knihy
SOA je široké téma a kde kdo si do něj schová kde jakou webovou službičku. Určitě proto není na škodu se občas trochu ochytřit a zjistit, "jak se to správně dělá". Jednou z knižních alternativ, po které se dá sáhnout je počin mého oblíbeného vydavatelství Manning, které čersvě vydalo knihu SOA Patterns jejímž autorem je Arnon Rotem-Gal-Oz.

Hned na úvod je potřeba říct, že titul knihy je zavádějící. Daleko přesnější by byl název "Distributed Systems Patterns" s podtitulem "Taking SOA into Account". Nicméně kniha rozhnodně stojí za přečtení a je vhodným doplňkem k jiným "patternovým" knihám. Pokud byste chtěli opravdu SOA patterny, je pravděpodobně jediným dostupným titulem na trhu SOA Design Patterns od Thomase Erla.

Co v knize najdeme? Kniha sleduje klasické schéma návrhových vzorů, takže každý vzor je popsání pomocí sekcí: problém, řešení, technologické mapování a atributy kvality. Vzory (celkem jich je 26) jsou pak seskupeny do jednotlivých kapitol:
  • Foundation structural patterns
  • Patterns for performance, scalability and availability
  • Security and manageability patterns
  • Message exchange patterns
  • Service consumer patterns
  • Service integration patterns

Následují kapitoly s anti-patterny, case study a úplným závěrem je zajímavá kapitola, kde se SOA srovnává s jinými architekturními styly: REST, Cloud computing a Big data.

Jak už jsem psal, SOA je široké téma, takže kniha jej pokrývá pouze z části. Vzhledem k tomu, že titul vyšel u Manningu, tak nepřekvapí, že většina vzorů je "nízkoúrovňových" tzn., že je využijete, pokud bude servisní architekturu implementova from-the-scratch. Tomu odpovídají i příklady uváděné z autorovy praxe - systém pro námořní hlídkování, vyhledávač videí apod., čili dosti specifické systémy, které vyžadují dobrou performance a těžko by se na ně aplikovalo nějaké krabicové řešení.

Pokud ovšem sáhnete po nějaké hotovém/předpřipraveném řešení (a nemusí to být zrovna nějaké dělo od Oracle nebo IBM, ale klidně třeba Apache Camel nebo ServiceMix), tak už tam většina vzorů bude naimplementovaná "pod kapotou". Ovšem samozřejmě, že neškodí vědět, jak to tam sviští.

Životní cyklus webových služeb

·5 min
Soa Governance Web-Services
Jedním z aspektů SOA governance, který by se měl zvážit, pokud začneme s verzováním služeb, je definování a správa životního cyklu služeb (service lifecycle). Podobně jako se u vystavených rozhraní služeb snažíme, aby jejich změny byly pro uživatele předvídatelné a srozumitelné (k čemuž nám pomůže snaha o zpětnou kompatibilitu a verzování), měli bychom se podobně snažit o srozumitelnost a předvídatelnost ohledně (časové) dostupnosti služby samotné.

SOA jako taková, je poměrně volné téma, takže každý dodavatel řešení k ní přistupuje po svém (a většinou si ji ohýbá, podle svého technologického a business portofolia. Výjimkou je v tomto většinou open source, který se snaží implementovat podle návrhových vzorů a nemá přitom vedlejší úmysly). Podobně kreativní jsou výrobci i v oblasti životního cyklu SOA služeb. Pokud bysme chtěli vědět, jak vypadá nějaký "obecný" lifecycle, tak brzy zjistíme, že žádný takový není.

Service Lifecycle podle ITIL
Obecně má lifecycle nějaké hlavní fáze, rozdělené do dílčích fází. Např. Oracle má hlavní fáze pouze dvě (design a runtime), ITIL má tři (design, transition a operation) a IBM čtyři (model, assemble, deploy a manage).

Service Lifecycle podle IBM (zdroj IBM)
Pokud bychom si však přesto chtěli takový obecný lifecycle načrtnout, mohlo by to vypadat nějak takto: Na počátku je vždycky požadavek na novou business funkčnost, což by mělo vést k analýze - jestli může požadavek pokrýt nějaká stávající služba/y (nebo jejich kompozice), jestli bude potřeba stávající službu upravit (pak se musí udělat dopadová analýza - impact analysis), nebo jestli vznikne úplně nová služba. Když jsou tyto věci jasný, může se služba zaplánovat (např. kdy se nasadí na produkci).

Service Lifecycle podle Oracle (zdroj Oracle)
Následuje klasický vývojový cyklus, tj. analýza, vývoj a testování služby, nasazení na různá prostředí a pak se služba dostane do produkční fáze - začnou ji používat klienti. Časem se může stát, že služba už nebude splňovat požadavky na ni kladené, změní se požadavky a služba už nebude potřeba, anebo vznikne nová verze služby. Je čas, aby služba odešla do důchodu.

Skutečná podoba lifecyclu se ale bude vždycky odvíjet od procesu, který daná organizace má (nebo by měla mít) pro správu a řízení IT artefaktů. Protože SOA governance je pořád jen podmnožina (a rozšíření) IT governance.

Pokud máme vydefinovaný životní cyklus služby, naskýtá se otázka, kde jej spravovat. Ano, nabízejí se jednoduchá a přímočará řešení - už jsem viděl případy, kdy byla governance služeb držená v Excelu, nebo ji tvořily tři(!) tabulky v databázi. Pokud se však nechceme vydat touto svůdnou cestou a nechceme znovu vymýšlet kolo, je vhodné použít nějakou SOA governance repository.

Toto bývá dost často kamenem úrazu celé SOA governance, protože komerční repository jsou častokrát dražší, než celé zbývající SOA řešení. Pokud však nemáme velké oči (ještě nikdy jsem neviděl SOA governance implementovanou v celé své šíři), dají se, se stejným úspěchem, využít i open source řešení.

Například my jsme na projektu použili WSO2 Governace Registry, profesionální open source řešení, které (prozatím) splňuje naše požadavky. Ke každé registrované (a spravované službě) se dá přiřadit nějaký lifecycle (každá služba může mít jiný) a nastavit konkrétní fázi.


Lifecycle, který jsem pro aktuální projekt adaptoval vypadá následovně. Životní cyklus se skládá z několika stavů, kdy každý z nich může mít několik požadavků, které musí být splněny, aby se služba mohla posunout do dalšího stavu. Cyklus je znázorněn pomocí UML state diagramu, jednotlivé požadavky jsou zobrazeny jako responsibilities:

  • Initial: Začátek lifecyclu, resp. procesu pro správu a životní cyklus služby. U nás takový proces de facto chybí a je nahrazen požadavky jednotlivých projektů. To je samozřejmě z hlediska SOA governance špatně - služba totiž nepřestane existovat jen proto, že je nasazena na produkci a je akceptována (což je pohled projektu).
  • Development: Tady pro nás začíná design fáze lifecyclu (na obrázku zeleně).
  • Contract created: bylo vytvořeno WSDL a bylo akceptováno konzumenty.
  • Implemented: služba byla plně vyvinuta a nasazena na prostředí, kde ji můžou (integračně) otestovat klienti.
  • Documented: služba byla zdokumentována. Pro nás to znamená, že byl jednak plně okomentáván kontrakt (elementy v XSD a služba a operace ve WSDL) a jednak byla zdokumentována orchestrace a externí komunikace služby pomocí CASE nástroje.
  • In Test: Služba byla nasazena na testovací prostředí. Není explicitně řečeno jaké (FAT/SIT/UAT), protože jednotlivé požadavky se týkají různých prostředí.
  • Smoke test passed: release manager ověřil, že služba po nasazení na SIT prostředí "žije".
  • Test cases passed: test manager nechal projít všechny test casy a schválil posunutí služby do UAT testů.
  • Accepted: služba byla akceptována v rámci UAT testů.
  • Available: služba byla na sazena na produkční prostředí a je tak k dispozici konzumentům. Zde začíná run-time fáze cyklu (oranžově).
  • Deprecation notification: konzumenti služby byli notifikování, že služba k nějakému datu přejde do stavu deprecated.
  • Deprecated: služba je označena jako deprecated (určena k penzionování), nicméně stále je ještě k dispozici konzumentům. Pokud je služba označena jako deprecated, je zpravidla již k dispozici její novější verze (jejíž nasazení by mělo být synchronizováno s tímto stavem). Výjimkou může být, pokud je služba rušena bez náhrady - v tom případě je služba označena jako deprecated, ale není nasazena její novější verze.
  • Retirement notification: konzumenti služby byli notifikováni, že služba k nějakému datu přejde do stavu retired.
  • Retired: služba byla penzionovaná - stažena z používání a je klientům nedostupná. Služba v tomto stavu by stále měla být evidovaná v SOA governance repository. Například proto, aby bylo dohledatelné, v jakém časovém rozmezí byla služba aktivní apod.

Na závěr ještě malá ukázka, jak vypadá část lifecyclu v nástroji WSO2 Governace Registry:


    U služby je vždy zobrazen aktuální stav cyklu, požadavky stavu jsou prezentovány checkboxy. Pokud služba splňuje podmínky přechodu do dalšího stavu (a tento stav skutečně již nastal), lze službu posunout do dalšího stavu tlačítkem Promote. Přechody mezi stavy a splnění požadavků lze svázat s formální kontrolou (např. kontrola verzí závislých artefaktů) a konkrétní uživatelskou rolí.

    Související články:

    Verzování XSD v SOAP webových službách

    ·3 min
    Soa Governance Soap Web-Services Xsd Wsdl
    Když jsem psal minule o verzování SOAP webových služeb, zaměřil jsem se pouze na verzování v rámci WSDL. Letmo jsem také popsal WSDL strukturu, s tím, že jsem nijak neřešil definici datových typů. Tady se může skrývat další úskalí (nebo příležitost pro) verzování.

    Datové typy jsou uvedeny v elementu types. Pokud není definice typů triviální, nebo pokud není ve službě definovaná pouze jedna operace, tak se zpravidla drží definice externě v XSD souboru a do WSDL se pouze naincludují (pokud chceme mít typy ve stejném namespace, jako má WSDL), nebo naimportují (pokud chceme, aby XSD mělo samostatný namespace).

    Myslím, že je lepší používat element import. Kromě toho, že je to podmínka, aby kontrakt splňoval WS-I Basic Profile, tak to umožňuje dodržovat následující konvenci:
    1. Součástí namespace WSDL je název služby.
    2. Každá operace má svoje vlastní XSD (v němž je definovaný request a response).
    3. Součástí namespace XSD je název služby a název operace.
    4. Plus samozřejmě verzujeme.
    Takže pokud bysme měli službu s názvem MyService a operaci s názvem myOperation, tak by namespacy vypadaly takto:

    WSDL:
    http://sw-samuraj.blog/ws/MyService-v1

    XSD:
    http://sw-samuraj.blog/ws/MyService-v1/myOperation

    Podobně jako u WSDL, je v namespace uvedena pouze major verze a jelikož je už ji obsahuje název služby (MyService-v1), není potřeba ji duplikovat ještě v názvu operace.

    Kromě namespaců verzujeme také samotný XSD soubor, např. myOperation-v1.2.xsd. Což nás staví před následující dilema. Představme si, že máme službu, která obsahuje dvě operace. Něco jako:
    <?xml version="1.0" encoding="UTF-8"?>
    <definitions
      targetNamespace=
          "http://sw-samuraj.blog/ws/MyService-v1"
      xmlns="http://schemas.xmlsoap.org/wsdl/"
      xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
      xmlns:xsd="http://www.w3.org/2001/XMLSchema">

      <types>
        <xsd:schema>
          <xsd:import
            namespace=
              "<trimmed>/MyService-v1/myOperation"
            schemaLocation="xsd/myOperation-v1.2.xsd"/>
          <xsd:import
            namespace=
              "<trimmed>/MyService-v1/yourOperation"
            schemaLocation="xsd/yourOperation-v1.2.xsd"/>
        </schema>
      </types>

      <!-- messages omitted -->

      <portType name="MyServicePort-v1.2">
        <operation name="myOperation">
          <!-- input, output and fault omitted -->
        </operation>
        <operation name="yourOperation">
          <!-- input, output and fault omitted -->
        </operation>
      </portType>

      <!-- binding omitted -->

      <!-- service omitted -->

    </definitions>
    Dilema zní: pokud dojde ke změně kontraktu pouze v rámci jedné operace, změním verzi pouze u XSD, které této operaci odpovídá, nebo změním verzi u všech XSD, které jsou součástí kontraktu? (V obou případech samozřejmě verzujeme WSDL tak, jak bylo uvedeno v předešlém článku.)

    Pokud by se nám změnila operace myOperation, tak v prvním případě by import vypadal takto:
    <types>
      <xsd:schema>
        <xsd:import
          namespace=
            "<shortened>/MyService-v1/myOperation"
          schemaLocation="xsd/myOperation-v1.3.xsd"/>
        <xsd:import
          namespace=
            "<shortened>/MyService-v1/anotherOperation"
          schemaLocation="xsd/anotherOperation-v1.2.xsd"/>
      </schema>
    </types>

    <portType name="MyServicePort-v1.3">
    <!-- rest omitted -->
    Výhodou této volby je, že verzujeme pouze XSD, u nichž opravdu došlo ke změně, zbytek necháváme na pokoji. Nevýhodou je, že verze XSD se nám rozjedou - jednak vůči sobě a jednak vůči WSDL. Reálně pak verzujeme XSD jako samostatný artefakt a ne jako součást kontraktu. To může být korektní situace, někdy vznikají XSD bez vazby na WSDL - v rozsáhlých projektech jsou často XSD vytvářena týmy analytiků a jejich import do WSDL zajišťují vývojáři.

    V případě druhé možnosti by import vypadal následovně:
    <types>
      <xsd:schema>
        <xsd:import
          namespace=
            "<shortened>/MyService-v1/myOperation"
          schemaLocation="xsd/myOperation-v1.3.xsd"/>
        <xsd:import
          namespace=
            "<shortened>/MyService-v1/anotherOperation"
          schemaLocation="xsd/anotherOperation-v1.3.xsd"/>
      </schema>
    </types>

    <portType name="MyServicePort-v1.3">
    <!-- rest omitted -->
    Nevýhodou této možnosti je, že musíme převerzovat všechy XSD v kontraktu, i ty, které se nezměnily (což se může zdát nepřirozené). Výhodou je, že kontrakt má jednotné verzování, takže mmj. nemusím kontrolovat jestli mám všechny XSD ve správné verzi. Zároveň je explicitně řečeno, že XSD je součástí kontraktu (ve smyslu objektové kompozice) a kontrakt (WSDL + XSD) by měl být vytvářen jedním týmem.

    U nás na projektu o tom byla poměrně bouřlivá diskuze, kterou variantu zvolit. Argumenty byly poměrně vyrovnané a více méně odpovídaly těm uvedeným výše. Nakonec jsme se rozhodli pro jednotný kontrakt, takže se změnou verze WSDL převerzováváme i všechny XSD.

    Verzování webových služeb, SOAP

    ·4 min
    Soa Governance Soap Web-Services Wsdl
    Před časem jsem napsal lehký úvod do SOA governance. Chtěl bych se k tomuto tématu vracet a prezentovat principy, které postupně zavádíme na projektu. Momentálně nás daleko víc pálí věci, které spadají do design fáze služeb, takže řešíme věci jako verzování, reusabilita, granularita služeb apod.

    Aspekt, který jsme řešili jako první (a nyní už i zavedli v praxi) je verzování služeb. Jelikož používáme řešení založené na SOAP webových službách (jak jinak v enterprise :-) podíval bych se právě na toto téma. Jestliže budu dále mluvit o webových službách (WS), mám tím vždy na mysli WS založený na SOAP.

    Proč?

    Otázka je, proč vlastně webové služby verzovat? Dejme tomu, že z nějakého důvodu chceme, na určitém prostředí, držet více verzí jedné služby. Tím důvodem může být např. to, že už máme nějaké stávající konzumenty dané služby a zároveň chceme touto službou poskytnout nové (business) funkcionality. Stávající klienti ovšem nemohou (nebo také odmítnou) přejít na novou verzi služby. Starou verzi služby tedy necháme funkční a zároveň nasadíme verzi novou. V případě SOA by toto mělo být definováno/podpořeno nějakou politikou, např. podpora více verzí služeb.

    Kontrakt

    Jak z hlediska SOA, tak z hlediska klienta se webová služba (a její konzumace) točí kolem kontraktu. Kontrakt, jako takový, se skládá z několika částí. Jednak definuje nějaké designové věci jako datové typy, zprávy a rozhraní (ve smyslu OOP). Dále definuje technologické záležitosti, tj. jaké se používají protokoly, jaké jsou endpointy služby. A konečně jsou to nefunkční požadavky.

    Pro SOAPovské služby je tímto kontraktem WSDL (Web Service Definition Language). Pokud pomineme nefunkční požadavky (které stejně nejsou definovány ve WSDL namespacu, ale jinde), má WSDL následující strukturu (zeleně jsou designové části, červeně implementační):

    • types - element definující pomocí XML Schema datové typy používané ve zprávách.
    • message - abstraktní definice přenášených dat (zpráv), sestavená z typů definovaných v předešlém elementu. Každá zpráva se skládá z jedné a více logických částí (parts). Pokud je částí ve zprávě více, jde o službu založenou na RPC.
    • portType - množina abstraktních operací, víceméně odpovídá rozhraní v OOP. Každá operace (metoda) by měla odkazovat vstupní a výstupní zprávu. Operace může být jedním ze čtyř typů: Request-response (klasika), One-way (obsahuje pouze vstupní zprávu), Notification (obsahuje pouze výstupní zprávu) a Solicit-response (endpoint pošle zprávu a očekává odpověď).
    • binding - sváže definovaný portType s konkrétním protokolem (SOAP, HTTP, JMS) a formátem zpráv (např. Document/literal, RPC/encoded).
    • port - definuje endpoint služby.
    • service - množina souvisejících portů.

    Sémantika verzování

    Není potřeba znovu-vymýšlet-kolo. Archetypem verzování je formát <major>.<minor>.<micro>. U služeb nás micro verze nebude moc zajímat - je vyhrazená pro implementační změny, které neovlivňují vyšší řády verze a nijak se tedy nepromítají do kontraktu. minor verze je vyhrazená pro změny rozhraní, které jsou zpětně kompatibilní. No a major verze indikuje změnu rozhraní, která není zpětně kompatibilní, tj. rozbíjí kontrakt.

    Změny, které jsou zpětně kompatibilní:
    • přidání nové operace do služby,
    • přidání nového XML typu do schématu.

    Změny, které nejsou zpětně kompatibilní:
    • odebrání operace ze služby,
    • přejmenování operace,
    • změna XML typů a atributů zprávy,
    • změna namespace.

    Jak?

    Jako best-practice se uvádí, že verzování by pro konzumenty mělo být explicitní, tj. uvádět číslo verze v elementech, URL apod. Co všechno v kontraktu verzovat, může být předmětem diskuzí na konkrétním projektu a technologiích, nicméně dá se vyjít z těchnto pravidel:
    1. Vkládat major a minor verzi do názvu WSDL souboru: MyService-v1.2.wsdl.
    2. Vkládat major verzi do targetNamespace WSDL souboru:
      <definition
        targetNamespace=
            "http://sw-samuraj.blog/ws/MyService-v1"
        xmlns="http://schemas.xmlsoap.org/wsdl/">
    3. Vkládat major a minor verzi do portType elementu:
      <portType name="MyServicePort-v1.2">
    4. Vkládat major a minor verzi do service elementu:
      <service name="MyService-v1.2">
    5. Vkládat major verzi do endpointu služby:
      <soap:address
        location=
          "http://sw-samuraj.blog/myService/v1"/>
    Pokud bychom si ukázali celé WSDL, vypadalo by takto:
    <?xml version="1.0" encoding="UTF-8"?>
    <definitions
      targetNamespace=
          "http://sw-samuraj.blog/ws/MyService-v1"
      xmlns="http://schemas.xmlsoap.org/wsdl/"
      xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
      xmlns:xsd="http://www.w3.org/2001/XMLSchema">

      <types>
        <xsd:schema
          targetNamespace=
                "http://sw-samuraj.blog/ws/MyService-v1">
          <!-- schema omitted -->
        </xsd:schema>
      </types>

      <!-- messages omitted -->

      <portType name="MyServicePort-v1.2">
        <!-- operations omitted -->
      </portType>

      <!-- binding omitted -->

      <service name="MyService-v1.2">
        <port binding="MyServiceSOAP"
              name="MyServiceSOAP">
          <soap:address
            location="http://sw-samuraj.blog/myService/v1"/>
        </port>
      </service>

    </definitions>

    Závěr

    Verzování poměrně úzce souvisí s dalším SOA governance aspektem a sice životním cyklem služeb (což je téma, na které se podíváme někdy příště). To že držíme na prostředí (typicky produkci) více verzí jedné služby má samozřejmě svoje náklady a ideálním stavem je, když služba běží pouze v jedné (nejaktuálnější) verzi.

    Se správou více verzí nám může pomoci vhodný nástroj - SOA governance repository, která drží o konrétní verzi služby různá meta-data a mmj. také to, v jaké životní fázi se služba nachází, nebo kdo ji konzumuje (a koho musíme notifikovat o penzionování služby).

    SOA governance, lehký úvod

    ·3 min
    Soa Governance

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

    2011