Proč celé lidstvo nemluví esperantem. XML Prague

Transkript

1 Proč celé lidstvo nemluví esperantem. XML Prague Václav Trojan, Jiří Kamenický, Jiří Měska Anotace: Příspěvek se věnuje prostředkům pro popis XML dokumentů. Primárním úhlem pohledu je požadavek na použitelnost prostředků v procesu popisu XML dokumentu v celém průběhu životního cyklu tvorby informačního systému, který zahrnuje jednání s partnery, analýzu, implementaci, údržbu a změnové řízení. Centrálním požadavkem je na jedné straně srozumitelnost pro účastníky jednotlivých fází tvorby IS a na druhé straně závaznost. Závazností zde rozumíme bezprostřední použitelnost popisu pro strojové zpracovatelný. V příspěvku je představen koncept Xdefinic, popisového aparátu XML dokumentu používaného firmou Syntea a.s.

2 Motivace: Úloha XML v neustále se měnícím světě Jaké jsou výzvy, se kterými se dnes musí vyrovnávat vývoj rozsáhlých informačních systémů (dále IS)? Těch výzev je jistě mnoho, ale rádi bychom zde uvedli jednu, která má dle našeho názoru hluboké dopady na požadavky na XML technologie. Touto výzvou je vývoj a správa IS v neustále se měnícím světě. IS z tohoto pohledu není nejen nikdy hotový, ale také není nikdy finálně vydefinovaný. Se zrychlujícím se tempem se mění nejen technologické prostředí, ale také věcná problematika vlastního řešení. Informační podpora se dostává do oblastí, kde je úzce navázána na stále se měnící společenskou situaci, kterou může být např. vazba na právní normy nebo přizpůsobení se technologickým standardům. S narůstajícím tlakem měnícího se světa narůstá i tlak na flexibilitu a robustnost aplikací tvořící IS. Požadavek na flexibilitu neboli přizpůsobivost aplikací se obvykle projevuje přesunem části logiky aplikace do řídících dat. Tyto se potom stávají parametrem systému, ale pouze za předpokladu, že jsou srozumitelné na konceptuální úrovni systému, ne pouze na úrovni programátorů. V závěru příspěvku se dotkneme tématu robustnosti IS a to v souvislosti s počtem nezávislých míst, které je třeba současně změnit, abychom dosáhly změny řídících dat aplikace. Vraťme se ale k tématu XML, Z technologického pohledu se XML stává díky své jednoduchosti a přitom strukturovanosti všeobecně používaným formátem dat. XML našlo svoji pozici: - jako nástroj pro výměnu strukturovaných dat, - jako nástroj pro parametrizaci a řízení aplikací, - jako nástroj pro popis rozhraní (webové služby) - jako nástroj pro popis business procesů (BPEL). - a mnoho jiných. Spektrum použitelnosti vede k tomu, že se XML dokumenty účastní všech fází vývoje IS. Z toho vyplývají základní kritéria (požadavky), které jsme si stanovili pro popis XML dokumentů: - popisy musí být srozumitelné pro použití v následujících oblastech tvorby IS o jednání s partnery o analýza o tvorba kódu o dokumentaristika - popisy musí být závazné v tom smyslu, že jsou strojově zpracovatelné pro potřeby o validace dat o procesního zpracování dat. Vedle těchto základních filosofických kritérii je třeba stanovit, co věcně musí popisy XML dokumentů zahrnovat: - Popis struktury XML dokumentů - Popis typů hodnot elementů a atributů - Definici integritních omezení - Vazbu na procesní zpracování dat. Odpovědí firmy Syntea a.s na tyto požadavky je koncept Xdefinic a vývoj prostředků na podporu práce s Xdefinicemi.

3 Příklad: Jazyk pro popis dopravních nehod XML samo o sobě je pouze formát dat. V důsledku toho vznikají specifické XML jazyky (značkovací jazyky, popis XML dokumentu) ať již pro potřeby věcného řešení (např. popis dopravní nehody) nebo pro potřeby technologické (XML schéma, BPEL aj.). V obou případech je třeba minimálně definovat: 1) syntax jazyka 2) sémantiku jazyka a omezující podmínky. Začněme příkladem, kdy je naším úkolem vytvořit IS pro zpracování dopravních nehod (dále DN). Prvním krokem při práci na takovémto systému je vydefinovat konceptuální model DN. Následující dokument je fragment záznamu dopravní nehody (DN) ze dne :00, kdy se střetly dvě vozidla Škoda Oktávie a Trabant. Prvé vozidlo bylo řízeno Frantou Škvorem a na místě spolujezdce seděla jeho manželka Filipína Škvorová. Druhé vozidlo bylo řízeno Slavomilem Tichým. Dopravní nehoda byla zaevidována pod číslem jednacím KRP-P-93/KDI-LM <?xml version="1.0" encoding="windows-1250"?> <DN DatumCas=" :00" Cj="KRP-P-93/KDI-LM-2007" > <Popis> Vozidlo EVČ BB-862 SK při vjezdu na hlavní silnici nedalo přednost vozidlu Oktávie jedoucímu od Přestav. </Popis> <Vozidlo VecOznaceni="Škoda Oktavie" CisloEv="SK-262 AK"> <Osoba RoleSilnicniProvoz="řidič"> <FO Jmeno="Franta" Prijmeni="Škvor" RC=" "/> <Osoba RoleSilnicniProvoz="spolujezdec"> <FO Jmeno="Filipína" Prijmeni="Škvorová" RC=" "/> </Vozidlo> <Vozidlo VecOznaceni="Trabant" CisloEv="BB-862 SK"> <Osoba RoleSilnicniProvoz="řidič"> <FO Jmeno="Slavomil" Prijmeni="Tichý" RC=" "/> </Vozidlo> </DN> Dva alternativní popisy dopravní nehody pomocí XML schémat a pomocí Xdefinic demonstrují dvě různé řešení následujícího dilematu: - zda-li pro popis zákaznického značkovacího jazyka (XML dokumentu) použít nový značkovací jazyk - nebo se snažit najít způsob jak popis zakomponovat do vlastního zákaznického značkovacího jazyka XML Schéma <xs:schema xmlns:xs=" <xs:element name="dn"> <xs:complextype mixed="true"> <xs:sequence maxoccurs="unbounded"> <xs:element ref="popis"/> <xs:element ref="vozidlo"/> </xs:sequence> <xs:attribute name="datumcas" type="xs:string" use="optional"/> <xs:attribute name="cj" type="xs:string" use="optional"/> </xs:complextype> </xs:element> < xs:element name="vozidlo" type = "xs:string" /> <xs:element name="vozidlo"> <xs:complextype> <xs:sequence maxoccurs="unbounded"> <xs:element ref="osoba"/> </xs:sequence> <xs:attribute name="vecoznaceni" use="required"> <xs:restriction base="xs:string"> <xs:maxlength value="80"/> <xs:attribute name="cisloev" use="required"> Xdefinice <xd:def xmlns:xd=" xd:root = "DN" xd:name = "DN"> <DN DatumCas="required datetime('d.m.y H:m')" Cj ="optional string(0,26)"> <Popis> optional string() </Popis> <Vozidlo xd:script="occurs 0..; ref Vozidlo"/> </DN> <Vozidlo VecOznaceni="required string(1,80)" CisloEv ="required string(1,12)"> <Osoba xd:script="occurs 0..; ref Osoba"/> </Vozidlo> <Osoba RoleSilnicniProvoz="optional string(0,36)"> <xd:choice> <FO xd:script="occurs 0..1; ref FO"/> <PO xd:script="occurs 0..1; ref PO"/> </xd:choice> <FO Jmeno ="required string(1,24)" Prijmeni="required string(1,36)" RC ="optional num(9,10)"/> <PO Nazev ="required string(1,50)" ICO ="optional num(8,10)"/> </xd:def>

4 <xs:restriction base="xs:string"> <xs:maxlength value="12"/> </xs:complextype> </xs:element> <xs:element name="osoba"> <xs:complextype> <xs:sequence> <xs:element ref="fo"/> </xs:sequence> <xs:attribute name="rolesilnicniprovoz" use="required"> <xs:restriction base="xs:string"> <xs:enumeration value="spolujezdec"/> <xs:enumeration value="řidič"/> </xs:complextype> </xs:element> <xs:element name="fo"> <xs:complextype> <xs:attribute name="rc" type="xs:long" use="required"/> <xs:attribute name="prijmeni" use="required"> <xs:restriction base="xs:string"> <xs:minlength value="1"/> <xs:maxlength value="36"/> <xs:attribute name="jmeno" use="required"> <xs:restriction base="xs:string"> <xs:minlength value="1"/> <xs:maxlength value="24"/> </xs:complextype> </xs:element> </xs:schema> Xdefinice zde popisuje složitější situaci, která zahrnuje kromě fyzických osob ještě i právnické osoby.

5 Srovnání XSD Schématu a Xdefinice Srovnejme oba popisy z pohledu kritérii, která jsme si vytyčili na počátku: XML Schéma Charakteristika: - Vytváří vlastní značkovací jazyk pro definici zákaznických značkovacích jazyků - Popisovaný značkovací jazyk je ukryt v hodnotách atributů a elementů Hlavní výhody: - Jedná se o existující standardy s širokou nabídkou produktů pro zpracování - Vlastní logika popisu je zpracovatelná běžnými XML technologiemi (XPath, XSLT etc.) Nevýhody: - Obtížně čitelné, stává se výhradní doménou programátorů (resp. analytiků) při implementaci - Není vhodné pro jednání s partnery ani pro management projektu, v této fázi je třeba nahradit minimálně demonstračními příklady nebo jiným alternativním popisem - Pro dokumentaci je třeba rovněž volit ilustrační příklady nebo jiné alternativní popis a schémata považovat za přílohu Xdefinice Charakteristika: - V pravém slova smyslu nevytváří vlastní značkovací jazyk pro definici zákaznických značkovacích jazyků - Vlastní popis zákaznického objektu je proveden řečí tohoto objektu - Vlastní popis se vkládá na místo hodnot elementů a atributů Hlavní výhody: - Čitelnost popisu umožňuje jeho nasazení při následujících činnostech o Jednání s partnery o Analytická fáze projektu o Implementační fáze projektu o Je srozumitelný pro management projektu o Použitelný pro dokumentaci - Popis je závazný, tj. je strojově zpracovatelný. Nevýhody: - Nejedná se o dostupnou a standardizovanou technologii - Pro strojové zpracování nestačí dostupné XML technologie, je třeba vyvinout vlastní nástroje XSD Schéma je s určitou nadsázkou možno označit za esperanto vytvořené pro účely popisu jiných jazyků (angličtiny, češtiny, němčiny) Xdefnice je snaha domluvit se anglicky, česky nebo německy o tom, jak správně psát anglicky, česky nebo německy. Název článku naznačuje naši odpověď na otázku, zda-li se dát cestou univerzálního jazyka nebo se pokusit zapracovat popisy jako extense do existujících jazyků.

6 Příklad: Popis metajazyka pomoci Xdefinice Špatná čitelnost XML schémat je často kompenzována tím, že se použije alternativní popis. NG Relax zavádí dvojí syntaxi. Popis jazyka BPEL je podán metajazykem, závazná syntaxe pomocí XSD Schématu tvoří přílohu standardu. Pro ilustraci uvádíme možnosti použití technologie popisu Xdefinic jako alternativu metajazyka (Web Services Business Process Execution) Version 2.0. Procesy v jazyku BPEL obsahují aktivity. Jednou z aktivit je <receive>, která popisuje chování instance procesu při přijmu zprávy. Popis aktivity <receive> v používané informal syntax je následující (kapitola 5.2 OASIS wsbpel-v2.0-os 11 April 2007): <receive partnerlink ="NCName" porttype="qname"? operation="ncname" variable="bpelvariablename"? createinstance="yes no"? messageexchange="ncname"? standard-attributes> standard-elements <correlations>? <correlation set="ncname" initiate="yes join no"? />+ </correlations> <fromparts>? <frompart part="ncname" tovariable="bpelvariablename" />+ </fromparts> </receive> Výše uvedená definice není XML dokument a nelze ji tedy jako XML dokument zpracovat. Pro strojové zpracování je tato definice přepsána do XML schematu (XSD). Avšak schéma zase není vhodné pro vysvětlení toho, co aktivita <receive> dělá. Popis téže aktivity formou Xdefinice: <receive partnerlink ="required NCName()" porttype ="optional QName()" operation ="required NCName()" variable ="optional BPELVariableName()" createinstance ="optional list('yes','no')" messageexchange ="optional NCName()" xd:scrip="ref standardattributes"> <xd:any xd:script="ref standardelements"/> <correlations xd:script="occurs 0..1"> <correlation xd:script="occurs 0.." set ="required NCName()" initiate ="optional list('yes','join','no')" /> </correlations> <fromparts xd:script="occurs 0..1"> <frompart xd:script="occurs 1.." part ="required NCName()" tovariable ="required BPELVariableName()" /> </fromparts> </receive>

7 Příklad: Událostní model a procesní zpracování Již na úrovni analýzy je třeba specifikovat některé procesy spojené s validací dat. Příkladem je zpracování odkazů do číselníků. Součástí formální specifikace Xdefinic je událostní model validačního procesu. Příkladem jsou události OnTrue nebo OnFalse zavěšené na typovou kontrolu elementu nebo atributu. Událost OnTrue je vyvolána, pokud validace proběhne dobře, událost OnFalse, jestliže neproběhne dobře. Tento model pak umožňuje definovat ve vazbě na tyto události procesní zpracování validovaných dat. Následující příklad demonstruje validaci vstupních dat, kde na vstupu je atribut KodRoleSilnicniProvoz, který je kódem role Osoby v silničním provozu (místo aby tam byl uveden text, tak jak je to v úvodním příkladu). Tento kód je třeba ověřit vůči číselníku a nahradit id vazbou na tento číselník: - cislenik( 'CC_RoleSilnicniProvoz') specifikuje číselník na který kód ukazuje - OnTrue ReplaceWithDBId(); volá proceduru nahrazení kódu za odkaz do databáze - OnFalse error();" zajišťuje chybovou reakci, pokud kód není v databázi nalezen <?xml version="1.0" encoding="windows-1250"?> <xd:def xmlns:xd=" xd:root ="DN" xd:name ="DN"> <DN DatumCas ="required datetime('d.m.y H:m')" Cj ="optional string(1,26)" > <Popis> optional string() </Popis> <Vozidlo xd:script="occurs 0..; ref Vozidlo"/> </DN> <Vozidlo VecOznaceni ="required string(1,80)" CisloEv ="required string(1,12)" > <Osoba xd:script="occurs 0..; ref Osoba"/> </Vozidlo> <Osoba KodRoleSilcicniProvoz ="requested cislenik('cc_rolesilnicniprovoz') OnTrue ReplaceWithDBId(); OnFalse error();" > <xd:choice> <FO xd:script="occurs 0..1; ref FO"/> <PO xd:script="occurs 0..1; ref PO"/> </xd:choice > <FO Jmeno ="required string(1,24)" Prijmeni ="required string(1,36)" RC ="optional num(9,10)" /> <PO Nazev ="required string(1,50)" IC ="optional num(8,10)" /> </xd:def>

8 Flexibilita a robustnost aplikace řízené kontrolními daty Vraťme se k úvodní úvaze o IS v neustále se měnícím světě, kde flexibilita a otevřenost aplikací hrají podstatnou roli. Tyto charakteristiky určují schopnost adaptibility aplikace a tedy její životaschopnost. Primitivní model flexibilních aplikací lze pojmout takto: Control Data Input data File, WS, Forms, Application Output data File, WS, Forms, V uvedeném obrázku aplikace nejprve zpracuje řídicí data (parametry, castomizace, metadata, konfigurace, atd.) a tím nastaví své chování pro zpracování datového vstupu a výstupu. Řídicí data mají dnes většinou formát xml. Bohatost řídicích dat určuje míru flexibility aplikace. Vlastní zpracování řídicích dat pracuje podle stejného modelu. Řídicí data jsou vstupem, který má opět svou definici (tj. své řídicí data). Příkladem takové aplikace může být BPEL stroj. Řídicí data reprezentují BPEL definice, vstupy a výstupy jsou volající a volané webové služby. BPEL definice má svá řídicí data např. BPEL schéma, popisující syntax jazyka BPEL. Porovnejme následující přístupy k řešení: XML Schéma Popis syntaxe řídicích dat je určen lidem a tudíž musí být snadno čitelný. Proto se pro tento popis (tj. pro daný XML jazyk) používá specifických notací. Omezující sémantické podmínky jsou popsány doprovodným textem. Aby bylo možné implementovat zpracování řídicích dat, je nutné přepsat specifickou notaci daného XML jazyka např. do XSD schématu. Zde je možné doplnit některé sémantické podmínky. Takové XSD schéma definuje řídicí data. Implementace zpracování původních řídicích dat znamená naprogramovat jejich dříve uvedenou transformaci. Důsledkem je, že pro zpracování a údržbu řídicích dat existují čtyři zdroje, které je nutno udržovat konzistentní: 1. definice ve specifické notaci, 2. popis sémantiky a omezujících podmínek, 3. závazné XML Schéma (xsd) 4. kód realizující podmínky a transformaci.

9 Pro člověka Většinou kombinace xml a speciálních znaků Sematic conditions Většinou textovým popisem Pro stroj a) xsd schema b) xsd parser Semantic conditions Programovým kódem Xdefinice Snahou technologie Xdefinic je docílit vyšší integrity zdrojů pro zpracování a údržbu. Jedna Xdefinice je použita jak pro lidskou, tak strojovou definici jazyka. Technologie Xdefinic umožňuje začlenit více sémantických podmínek přímo do Xdefinic a tím minimalizovat kód realizující sémantiku. V důsledku tedy existují pouze tři zdroje, které je nutné udržovat konzistentní: 1. závazná xdefinice (stejná pro člověka i stroj) 2. popis sémantiky, 3. redukovaný kód realizující podmínky a transformace, které se nepodařilo začlenit do xdefinice. Pro člověka xdefinition Pro stroj a) xdefinition Sematic conditions a) Xdefinition b) textovým popisem b) xdef parser Semantic conditions Programovým kódem