Vstříc otevřeným službám

Mnozí z odborníků se shodují na tom, že cestou budoucnosti v oblasti vývoje softwaru je architektura orientovaná na slu...


Mnozí z odborníků se shodují na tom, že cestou budoucnosti v oblasti vývoje
softwaru je architektura orientovaná na služby, tedy tzv. SOA (Service-Oriented
Architecture). V praxi tak budeme vytvářet volně propojované webové služby a
posléze je postupně skládat do smíšených systémů. Výhody jsou jasné:
škálovatelnost, neutralita vůči operačnímu systému a programovacím jazykům i
jednoduchá integrace. Začíná být ovšem zřejmé, že SOA musí čelit také obtížným
problémům.
Jak lze např. monitorovat, testovat a debugovat distribuovaný systém, jestliže
vaší přímé kontrole podléhají pouze některé z jeho komponent? V jistém smyslu
nejde o nic nového. Zprávy "spouštějí" další zprávy. Nejhorší noční můrou je
potom chyba, která se projeví pouze tehdy, jestliže zprávy přijdou v určité
sekvenci. Vysoce škálovatelné událostmi řízené systémy, které jsou založeny na
web services, se takto budou pro mnoho vývojářů nepochybně často stávat zlým
snem.
Na úrovni komponent v současnosti dochází k výraznému pokroku a vývoji. Amitabh
Srivastava působí jako Microsoft Distinguished Engeneer, který ve firmě vede
Programmer Productivity Research Center (PPRC). Jeho skupina vyvinula
technologii pro zajištění korelace programů s jejich testovacími sadami a
určování priorit, jestliže jsou v programech provedeny změny. Detaily (viz
odkazy) jsou velmi zajímavé, ale podstata je přibližně taková: Jestliže je
zaregistrována pozměněná DLL knihovna např. aplikace Microsoft Word nebo SQL
Server, může rychlá analýza binárního kódu uvést změny do souladu s příslušnými
testy a dále může seřadit testy podle stupně jejich dopadu. Tato technika
pracuje nezávisle na tom, zda jde o platformy x86 či IA-64 a MSIL.
Aby bylo zřejmé, proč je nutné určovat priority testů, představte si, že chcete
dodat bezpečnostní patch. Samozřejmě by bylo vhodné, aby nový kód prošel bez
problémů celou sadou testů, nicméně to může trvat někdy i týden, zatímco vy
potřebujete takový patch rozdistribuovat řádově během několika hodin. Budete-li
se však soustředit na ty testy, které jsou zmíněným patchem nějak ovlivněny,
budete mít velkou výhodu.
Granulární data o změnách v softwaru, jsou-li k dispozici, pak mohou být
využita mnoha různými a zajímavými způsoby. Jak se např. obvykle rozhodujete,
kdy upgradovat na patchovanou verzi programu nebo kdy aplikovat service pack?
Jestliže není nezbytný pro řešení opravdu naléhavého problému, poradíte se
pravděpodobně nejprve s odborníky, projdete si newsgroups. Z kvantitativního
hlediska vlivu změny můžete učinit rozhodnutí na základě přesnějších informací.
Případně můžete také využít zmíněné informace pro určení priorit při testování
vašeho vlastního, na zmíněných změnách závislého softwaru.

Otevřený či uzařený?
S tím, jak se kombinují jednotlivé komponenty do jediného systému, se také
postupně rozmazává přesná hranice a odlišnosti mezi open source a "uzavřeným"
kódem. Komponenty, ať už jsou postaveny na jakékoliv technologii, poskytují
určité služby, a právě otevřenost těchto služeb je tím, co bude mít nakonec ve
svém důsledku hlavní význam. Využití XML přitom zajišťuje nezbytnou
transparentnost ve vrstvě zpráv. Toho využívají firmy jako Mindreef nebo
Confluent Software. Diagnostický nástroj pro webové služby SOAPScope prvně
jmenované firmy umožňuje odladit (debugovat) jakýkoliv soubor koncových bodů
(služeb) a nástroj CORE Manager Confluentu umožňuje zabezpečit smlouvy o úrovni
služeb (SLA, Service Level Agreement). Avšak WSDL rozhraní, jak poznamenává
Srivastava, vám neřekne, jak testovat služby, ale pouze jak je vyvolat.
Dnes už není možné jednoduše rozkouskovat životní cyklus softwaru do zřetelně
oddělených částí. Individuálně můžeme stále navrhovat, vyvíjet, testovat a
nasazovat, avšak kolektivně se vše stává kontinuálním procesem. Např.
technologie pro správu testování, které skupina PPRC vyvinula, slouží i
samotným programátorům Microsoftu k tomu, aby se se současnou realitou snáze
vyrovnali. Jestliže se Microsoftu povede implementovat ji do jeho komerčních
nástrojů, budou podobnými možnostmi v budoucnu disponovat i vývojáři třetích
stran.
Naproti tomu vývojáři patřící do početné open source komunity mají své vlastní
bohaté testovací zvyky a metody. Např. populární nástroj JUnit není pouze
výzbrojí pro regresní testování. Pro praktikanty různých metod vývoje řízeného
testy představuje framework, který podporuje inkrementální průzkum návrhové
oblasti. Tyto testy mohou a budou sloužit i k jiným účelům.
Hladká interpolace distribuovaných služeb bude vyžadovat více než správně
formulované SOAP pakety a rozhraní kompatibilní s WSDL. Budeme také potřebovat
metody pro popis předpokladů použití našich služeb zakódovaných přímo do nich.
K tomu právě mohou sloužit softwarové testy. Lze tedy předpokládat, že
schopnost výměny testů a testovacích metadat bude jedním z rysů definujících
otevřené služby.

Doporučené webové odkazy
n ftp://ftp.research.microsoft.com/pub/tr/tr-2002-15.pdf
n ftp://ftp.research.microsoft.com/pub/tr/tr-2001-50.pdf
n www.mindreef.com
n www.confluentsoftware.com
n www.junit.org









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.