Na vaše otázky k architektuře orientované na služby odpovídal Jindřich Kasal, technický konzultant pro portfolio softwarových produktů divize HP Software společnosti Hewlett-Packard (dříve známých pod značkou HP OpenView), zaměřených na správu a monitoring sítí, serverů, aplikací a produktů podporujících procesní řízení IT. V rámci HP Software nyní mimo jiné zodpovídá za softwarové produkty pro oblast SOA Management a SOA Governance.
V tomto článku najdete otázky a odpovědi týkající se tématu rozhovoru. Některé dotazy a odpovědi jsme kvůli přehlednosti zkrátili, jiné rozdělili do více částí. Některé otázky se opakovaly a v takových případech byly zpravidla zodpovězeny jen jednou. Originální verzi rozhovoru najdete na této stránce.
Odpovědi na otázky čtenářů Živě.cz
Jak se díváte na akvizici firmy Systinet? Co HP přinese? (milan boruvka)
Jindřich Kasal: Společnost HP zakoupila v loňském roce firmu Mercury, přičemž Systinet byl součástí Mercury od jara loňského roku. Produkty Systinetu směřují do oblasti SOA Governance a podporují tak procesně a technicky správu SOA. V rámci portfolia HP Software a tzv. SOA Lifecycle nabízíme produkty na management infrastruktury SOA, kvalitu SOA (funkční a zátěžové testovaní kompozitních aplikací, diagnostika) a Governance pro řízení pravidel, politik a organizačních aspektů SOA.
Co říkáte na novou architekturu TOE od Novellu? Myslím, že v porovnání se SOA systémy od HP je o tři až čtyři úrovně lepší. (Tonda Vokouřil)
Jindřich Kasal: Nevím o tom, že by Novell nabízel nějakou architekturu pod názvem TOE. HP nenabízí „architekturu“ ale řešení pro správu architektury. Nemyslím, že by v tomto smyslu byla nabídka HP a Novellu srovnatelná.
Kde SOA projekty selhávají? (Jan Zadak)
Jindřich Kasal: Obecně řečeno, k neúspěchu je odsouzena každá iniciativa směrem k SOA, která vychází jen z řad programátorů. Potom hrozí, že SOA skončí u frameworku pro integraci aplikací na bázi ESB nebo jiné technologie. Podcenění kulturních a organizačních dopadů na transformaci do SOA je prvním indikátorem neúspěchu. Interoperabilita aplikací je totiž pouze nutnou, nikoliv postačující, podmínkou.
Technologie by se měly řešit až po architektuře firemních procesů a zvážení dopadu na organizační strukturu a definici odpovědností. Kritické je podcenění fáze, kdy se v rámci organizace sjednocují „slovníky“ mezi různými týmy, tvoří se společná sémantika, definují se služby (nikoliv implementují), odpovědnosti, kontrakty o použití služby, prahové hodnoty pro definici kvality služeb, metody měření apod.
Dalším předpokladem je existence funkčních procesů a nástrojů pro správu konfiguračních položek v IT, proces řízení změn, proces správy incidentů a problémů. Výše jmenované termíny jsou indikátory zralosti pro implementaci SOA. Zdůrazňuji že SOA = web services. Interoperabilita aplikací a znovu použitelnost kódu jsou jedním z výchozích principů SOA, nikoliv důsledkem.
Podle mě patří SOA jednoznačně k největším buzzwordum posledních let v IT. Je to jen použití nových názvů pro staré problémy, které existují už od dob CORBY. Snaha udělat vědu z něčeho co vědou není. Je to jen snaha IT firem prodat nové balíky softwaru do podniků zaměřená na jejich management. Po nějakých prezentacích BEA a Systinetu (pardon, HP), na kterých se dvě hodiny jen mlátila prázdná sláma musím říct, že celkový přínos je prostě nulový. (Pavel Veselý)
Jindřich Kasal: Tak abych to vzal popořádku. SOA není něco, co si koupíte v krabici Je to architektura, metodologie, ke které organizace dospěje v procesu hledání dalších konkurenčních výhod na trhu (a teď nemluvím jen o IT). V organizaci, kde není jako kritická hodnocena schopnost rychle a transparentně integrovat IS/IT po akvizici jiné firmy, rychle zavádět nové produkty (podporované IT) na trh (typicky v telekomunikacích nové mobilní služby, služby pro poskytování obsahu) a integrovat je do stávajících billing/provisioning/ERP/CRM systémů, nebude SOA na pořadu dne. Znovu použitelnost kódu, oddělení rozhraní od implementace, to skutečně nejsou vynálezy SOA, ale pouze předpoklady jejího nasazení.
U některých zákazníků je SOA také postavena na ORB modelu a místo webservices jsou služby implementovány v mainframových messagingových systémech. Naprogramovat službu a oddělit její rozhraní od implementace skutečně už dlouhé léta není žádný problém. Sám ale tušíte, že interoperabilita CORBA vs. Java, PHP, C++ zajištěná přes XML je flexibilnější a lépe se implementuje v heterogenních systémech.
Pokud jste byl přítomen na prezentaci BEA/Systinet a domníváte se, že SOA Governance je „logování a dokumentace“, obávám se, že došlo k nesprávnému pochopení. V prostředích, ve kterých se odehrávají denně desítky a stovky změn, je jistě možné udržovat povědomí o aktuálním stavu v podobě spreadsheetového dokumentu, projekty řídit pomocí tužky a papíru. Podle toho bude vypadat aktuálnost, přesnost a kvalita dat. Governance je rozhodně více než jen dokumentace. Je to o způsobu, jak klasifikovat systémy, udržovat metadata o službách, poskytovat ve správný čas informace správným osobám či organizačním složkám a především dodržování těchto pravidel kontrolovat a automaticky vynucovat.
Existuje jiná implementace SOA než ve formě web services, které jsou napsány v zapráskané Javě, která je sama o sobě zásadním úzkým hrdlem (z hlediska výkonnosti) jakékoliv aplikace? (MartinH)
Jindřich Kasal: Webservices můžete implementovat v PHP, Perlu, C++, .NET. Rozhodně nejste omezen jen na použití Javy. V čem je algoritmus / služba na pozadí implementován, také není závislé na programovacím jazyku. Dost často je služba implementována třeba v PL/SQL na úrovni databázového serveru, což je u operací s daty zřejmě výkonnostně optimální řešení. Mýtus Java=SOA=web services pramení z toho, že integrační projekty se zpravidla řeší ve velkých podnikových IT prostředích, kde je Java silná.
Programátoři enterprise aplikací, na kterých jich pracují desítky a mnohdy v oddělených týmech, evidentně z nějakého důvodu preferují Javu před Perlem. Existuje kolem ní velké množství frameworků, podpora u všech velkých dodavatelů middlewaru, aplikačních serverů, vývojových nástrojů. To, že si trh vybral Javu, není rozhodně výsledkem zlomyslné snahy psát pomalé aplikace a prodávat tak výkonnější hardware. Java umožňuje tvořit škálovatelné a bezpečné aplikace a za efektivitou se skrývá jak znalost jazyka mezi komunitou programátorů, tak i opensource frameworky a podpora Javy od dodavatelů middlewaru a aplikačních serverů.
Mimochodem například .NET je celkem neprávem v otázkách čtenářů přehlížen. J2EE rozhodně neposkytuje výkon jako CORBA, zároveň ale není tak složitá a lépe se s ní naplňuje princip tvorby distribuovaných aplikací s „volnými vazbami“.
Víte alespoň o jedné kompletní implementaci SOA v ČR? Mám na mysli kompletní – tedy včetně registrátora služeb? (MartinH)
Jindřich Kasal: Ano, o takové implementaci vím. Nemám ale v tuto chvíli ze své pozice svolení jmenovat konkrétního zákazníka a podrobnosti o této implementaci. Rozhodně se ale nejedná o jednoho zákazníka. V různém stádiu zralosti existuje SOA u více zákazníků. Liší se rozsahem, mírou použití podpůrných nástrojů a podílem na celkovém počtu služeb či aplikací, které provozují.
SOA je pěkný koncept, který je tak obecný, až se hodí na všechno. Řídí se jím naši vývojáři? Mám dojem, že jsme v oblasti vývoje někde u XML, maximálně jsou pokusy používat BPEL, ale vždy to skončí na proprietárním programování na úrovni aplikačního serveru a vše zpomalující Javy. (MartinH)
Jindřich Kasal: SOA není koncept jen pro vývojáře. Vývojář vyvine to, co mu analytik předloží a analytik předloží to, co si zákazník přeje a zákazník zaplatí. Nemyslím, že v ČR by byl problém s přijímáním moderních technologií a praktik. Názor na vše zpomalující Javu jsem vyjádřil výše. Službu můžete implementovat klidně Perlovským skriptem nebo uloženou procedurou v databázi. V okamžiku, kdy je třeba řídit transakce napříč různými systémy, kdy existují velké požadavky na škálovatelnost a zároveň potřebujete v rozumném čase vybudovat tým programátorů, kteří mají s daným jazykem zkušenost, padne vaše volba asi právě na Javu.
Lze koncept SOA aplikovat i mimo programování? Třeba na úrovni podniku? (MartinH)
Jindřich Kasal: Velmi zajímavý dotaz. Napadá mě právě příměr k funkční organizační struktuře, kde jsou v rámci některé funkční domény (finance, výroba, logistika) koncentrovány příbuzné služby a jsou definována vstupní rozhraní pro vyvolávání těchto služeb (podatelna) a popis rozhraní v podobě formuláře, který si na podatelně vyzvednete. „Center of Excelence“, tedy jakési expertní jednotky, sloužící napříč útvary se dají přirovnat ke štábům. Fungování dnešních organizací je orientováno na procesy, jejichž vlastností je právě to, že prochází napříč funkčními doménami.
Tuto odpověď berte, prosím, s rezervou.
Proč je SOA stále jen teorií? Proč není používaná, když je tak zásadně, objevně a nepřekonatelně efektivní? (MartinH)
Jindřich Kasal: Každý kapitálový výdaj, ať už to je stroj, licence nebo špičkově školený zaměstnanec, je pro firmu zdrojem zisku, pokud firma dokáže tento výdaj vhodně využít na trhu jako svou konkurenční výhodu. Pokud se pohybujeme v prostředí kde „IT doesn’t matter“, tak jistě nebudeme investovat čas, úsilí a peníze do přeměny IT architektury, když přínosy nepřevýší náklady a rizika s tím spojená. SOA je praxí pro firmy, které z ní dokáží vytěžit zisk, nebo podíl na trhu. Teorií je pro ostatní, kteří se pohybují ještě pod „bodem zvratu“, kdy náklady převyšují potenciální přínosy. Tak je to se všemi technologiemi a koncepty, SOA není výjimkou.
Správa SOA si bohužel vyžaduje nemalé investice do software pro správu SOA prostředí, které jsou, jak jinak, nekompatibilní se současnými nástroji pro správu. Existuje nějaký standard (nebo alespoň koncept) pro měření SLA v prostředí SOA? Něco jako ARM, JMX, DSI nebo něco objevně nového, co konečně dovolí měřit SLA jako celek. (MartinH)
Jindřich Kasal: Nástroje mohou být v zásadě rozděleny na ty, které podporují monitoring infrastruktury (sítě, servery, aplikace), správu konfigurací (discovery, automatická správa konfigurace OS a aplikací), automatizaci procesů (nástroje podporující procesy vymezené v ITIL), IT Governance a nástroje pro tzv. end2end monitoring a diagnostiku, které měří dostupnost a kvalitu IT služeb a technologií z pohledu koncového uživatele.
SLA (Service Level Agreement) si nastavuje každý zákazník dle svých potřeb a není důvod podporovat toto standardem. Nemyslím, že by ARM, JMX měly se SLA něco společného. SLA je definováno spíš „netechnickým“ jazykem a vyjadřuje, jak kvalitní službu si zákazník platí a IT garantuje. Je úkolem nástroje, aby umožnil zákazníkovi nastavit si přesně takové SLA, jaké potřebuje a zohlednil při tom různé výjimečné stavy, plánované odstávky i podporu vlastních vzorců pro výpočet SLA. SLA bude tím složitější, čím abstraktnější službu popisujeme. V SOA může SLA nad webovou službou, která přijme požadavek, zpracuje ho a vrátí výsledek, být mnohem jednodušší, než SLA nad komplexními síťovými službami (VoIP, VPN) u telekomunikačního operátora, které se SOA nemají nic společného.
Jak se díváte na projekty SOA, které selhaly? Není důvodem nedodržování standardů? Existuje alespoň jeden projekt v rámci ČR, který lze prohlásit za využití (implementaci) SOA? Existují standardy na SOA? (MartinH)
Jindřich Kasal: Řekl bych, že standardy jsou v zásadě dvou druhů.
První skupinu tvoří standardy technologické, více či méně přijímané velkými dodavateli jako jsou standardy od OASIS, W3C. Druhou skupinu tvoří ty standardy, které si musí organizace vytvořit sama ve svém prostředí na míru, tak aby odrážely její potřeby.
Tento typ standardů se v podmínkách SOA označuje jako „policies“ a definují pravidla obchodní, technická, bezpečnostní. Tyto politiky, jsou uloženy v centrálním repozitáři jako metadata a jsou přiřazovány službám. Každá služba má tedy v katalogu nejen technologický popis rozhraní, ale i jasně definovaný popis o bezpečnostních požadavcích, vazbě na kontrakty o použití služby (doporučený počet požadavků za den), o kvalitě služby (stanovený dobu odezvy), vazbu na SLA, údaje o účtování za použití služby a samozřejmě jednoznačně definovaného vlastníka. SOA je především o schopnosti budovat „loosely coupled“ vztahy.
Pro to, abych v novém obchodním procesu použil službu, kterou implementoval někdo, koho neznám, neznám ani osoby které službu provozují a nemám informace o kvalitativních parametrech služby, potřeboval bych značnou dávku odvahy, abych ji použil a implementoval se svém procesu. Problémem může být i správa verzí služeb. V případě, že se vlastník služby, který je zodpovědný za implementaci, rozhodne provést změnu, governance nástroj mu umožní publikovat novou verzi služby a zároveň je automaticky všem odběratelům služby rozeslána zpráva o tom, že existuje nová verze, jak dlouho bude stará verze podporována apod.
To je jeden z příkladů, jak mohou (a dokonce musí) vypadat „obchodní“ pravidla. Bez takovéto komunikace a sdílení informací není možné budovat důvěryhodný vztah mezi dodavateli a poskytovateli služeb. Nástroj, který mi budování takového důvěrného vztahu umožní, patří do kategorie SOA Governance nástrojů.
Má smysl se zabývat SOA governance, když pro fungující SOA potřebuji napřed zajistit fungování všech úrovní IT? Mám na mysli síť, servery, aplikace, technologické a aplikační služby atd. Kolik je dnes v ČR IT, které mají implementovánu alespoň část ITILu a využívají ji? A kolik z nich je schopno následně zajistit fungování SOA, kde je vše o službách? Máme u nás vůbec SO IT (místo „A“ je „IT“)? (MartinH)
Jindřich Kasal: Zcela souhlasím. Pokud v IT není funkční konsolidovaný monitoring infrastruktury a na správu sítě, serverů a aplikací se používají nástroje bez integrace, bez centrální dohledové konzole, která v reálném čase zobrazuje stavy technologií a mapuje technologické prvky na IT služby, nejsme ve stavu, kdy bychom mohli SOA technologicky podporovat při zajištění dostatečné dostupnosti, a minimální míře rizik.
SOA je složitá distribuovaná architektura a je zcela nezbytné garantovat provoz technologií, nad kterými je vybudována. Nemá smysl míchat maltu na cihly v okamžiku, kdy není hotová projektová dokumentace stavby. Bez schopnosti rychle identifikovat příčiny nedostupnosti IT služby, bez měření SLA, bez stabilizované správy IT konfigurací, bez nastavených a měřených IT procesů, má firma před sebou v IT oblasti ještě mnoho práce před okamžikem, kdy pro ni bude SOA tématem dne.
Co je SOA Governance? Není to náhodou jen nastavení provozních procesů? Nelze se obejít bez drahých a málo efektivních nástrojů pro měření SOA komponent? (MartinH)
Jindřich Kasal: O tom, co je IT / SOA Governance by se dalo napsat hodně a je to spíš téma na samostatný článek. V některých odpovědích jsem naznačil, co se pod pojmem Governance skrývá, takže jen krátký výčet.
Pravidla (předpisy, politiky, normy), nástroje pro jejich centrální sběr a publikaci, dále jsou to nástroje, které umožňují klíčové procesy a aktivity automaticky kontrolovat z hlediska dodržování oněch pravidel a tvoří výstupy v podobě auditních reportů. IT / SOA Governance občas přirovnávám k fungování státu. Stát je vymezen územím (systémy), obyvateli (uživatelé, partneři), zákony (pravidla, politiky), aparátem pro kontrolu dodržování zákonů a především nástroji, jak tyto zákony vynucovat. V takovém státě se díky zajištění pravidel hry lépe žije a lépe podniká.
Co se týče drahých a málo efektivních nástrojů, můžete samozřejmě řídit projekty pomocí tužky a papíru, můžete vést data o zákaznících ve sklepních kartotékách. Softwarové nástroje jsou od toho, aby práci ulehčovaly, aby umožnily pohled na aktuální firemní data v reálném čase a aby automatizací úkolů přispěly se snižování chyb vyplývajících ze „selhání lidského faktoru“. Softwarové nástroje umožňují automatizovat a monitorovat procesy jako posloupnosti aktivit mezi lidmi, kteří se nikdy nemusí potkat, umožňují zaznamenávat každý krok v rámci procesu, zpětně odhalovat pochybení a včas reagovat na výjimečné stavy.
Můžete principy governance aplikovat bez softwarových nástrojů, ale obávám se, že od určitého okamžiku ztratíte kontrolu a náklady na „governance“ porostou exponenciálně. Myslím, že kontrola nad stovkami a tisíci služeb, na kterých závisí fungování firmy, vyžaduje speciální nástroje a jejich efektivnost si každý zákazník před koupí velmi dobře spočítá.
To jsem fakt zvědavý, co se od tahače kabelů, prodejce železa a člověka zabývajícího se čistě infrastrukturálními věcmi dozvím o architektuře a integraci systémů. Kdyby HP nekoupila Mercury a ta čistě náhodou předtím Systinet, tak budete dnes „specialistou“ třeba na tiskárny a nebo možná na něco úplně jiného. Vždyť HP OVO má k SOA asi tak blízko jako nebe k dudám. (Jan Vodák)
Jindřich Kasal: Můžeme také říci, že kdybych se narodil v Jižní Americe, byl bych dnes velmi dobrý ve sběru čajových lístků. V mém profilu je uvedeno mé zařazení v divizi HP Software, s hardwarem nemám nic společného.
Cílem tohoto rozhovoru není rozebírat techniky a nástroje pro integraci aplikací, ale problémy, které souvisí se SOA jako celkem. Technologie pro integraci aplikací jsou jen zlomkem problematiky SOA Vrátím se tedy k Vašemu poznatku, když uvádíte jako příklad produkt OV Operations. Jak jistě víte, OVO je založeno na správě serverů prostřednictvím softwarových agentů. Na tyto agenty se distribuje logika, specifická pro sledované aplikace. Mezi desítkami jiných bych tedy jmenoval tzv. Smart-PlugIns pro Tibco, Bea Weblogic/Integration, IBM MQ/Websphere a další.
HP před koupí Mercury prodávalo produkt SOA Manager, pro správu webových služeb a middlewaru založeném na JMS, dále produkt Internet Services pro monitoring dostupnosti mj. webových služeb z pohledu koncového uživatele a další. Znalost produktů pro monitoring vyžaduje i znalosti o tom, jak vůbec monitorované systémy fungují a jaké informace správci integračních platforem mohou dostat. Monitoring a diagnostika middlewaru a aplikačních serverů je z mého pohledu klíčová aktivita managementu SOA. Takže „nebe“ a „dudy“ to rozhodně nejsou.
Jaký je typický příklad pro použití SOA architektury. Je tato architektura vhodná i pro menší informační systémy? V jakých případech je SOA dobrou volbou, a kdy není? (Jiří Duda)
Jindřich Kasal: Na toto neexistuje jednoznačná odpověď. Záleží na tlaku na integrace „malého“ informačního systému na systémy zákazníků, dodavatelů a partnerů.
Na tom, jestli má organizace zájem část své infrastruktury outsourcovat, případně nakupovat aplikace formou ASP. V současnosti nejsou všechny balíkové softwary psány tak, aby je zákazník mohl s minimálním náklady v SOA prostředí použít a domnívám se, že SOA začne být pro sféru malých a středních podniků tématem, až dodavatelé softwaru sami SOA metodologii začnou vycházet vstříc.
Projekt SOA tranformace vyžaduje hodně práce konzultantů, úzkou specializaci a to není v současnosti sousto, které by malá firma mohla financovat. Vyvedení aplikačních rozhraní formou web services není dostatečné. Je třeba implementovat nástroj nezávislý na business aplikacích, který umožní nezávisle všechny business funkce spravovat bez ohledu na to, jaký dodavatel mi dodává implementaci (např. ERP) tak, abych mohl dodavatele vyměnit a novému předložit pouze popis rozhraní a požadavky na kvalitu jednotlivých služeb. SOA vyžaduje znalost metodiky a nástrojů a takového zaměstnance malý podnik zřejmě v dnešní době neuživí.
Je možné uvést nějaké konkrétní příklady aplikace přístupu SOA v ČR? (Jakub Skorepa)
Jindřich Kasal: Nemohu uvádět v ČR konkrétní firmy, ale SOA se rozhodně stává aktuálním tématem pro banky, pojišťovny a telekomunikační operátory.
V jakých oblastech nejsou SOA řešení vhodná? (Jiří Kadlčík)
Jindřich Kasal: Jak jsem uváděl výše, SOA není zřejmě aktuální pro firmy, kde IT není zdrojem konkurenční výhody – tam, kde se změny v IT neodehrávají často, nedochází k integraci s ekosystémem partnerů a odběratelů zboží/služeb.
SOA nepřináší primárně úspory a zjednodušení prostředí. Naopak, IT prostředí se stane díky rozbití monolitických aplikací ještě složitějším a bez efektivního SOA governance nástroje a implementovaných pravidel takové prostředí není možné uřídit. Výměnou za ostrý řez IT, organizace získává schopnost flexibilně, rychle a s nízkým rizikem zavádět nové procesy, měnit stávající, díky oddělení rozhraní od implementace získává i větší nezávislost na dodavatelích aplikací a dodavatelé aplikací dostávají šanci stát se jedním z poskytovatelů služeb i u velkých zákazníků jako jsou banky nebo telekomunikační firmy.
SOA tedy není vhodná tam, kde nová rizika a náklady nepřevyšují přínos v podobě dodatečných tržeb, vyššího zisku a větší flexibility.