elementu P je volitelný, což má neblahé následky na jeho používání – tvůrci stránek obvykle odstavce nijak neukončují. Programátoři HTML si zvykli neuzavírat elementy, jejich lenost se tak přenáší i tam, kde to vadí, a nakonec vynechávají ukončovací tagy i tam, kde jsou povinné. Proč vůbec prohlížeče takto špatně napsané stránky neodmítají? Inu, protože žádný výrobce nechce, aby jeho výrobek získal pověst nemehla, co nedokáže přečíst veškerý obsah webu. Firmy vyrábějící prohlížeče tedy ve skutečnosti soutěží o to, čí výrobek dokáže přečíst nejhůře napsané stránky! V takovém prostředí však tvůrci stránek HTML budou stále psát špatně, protože jejich chyby nečeká žádný trest. Špatný kód bude plodit další nekvalitní stránky, a tak pořád dokola.
12
HTML je definováno jako pevná sada tagů, optimalizovaných pro doručování elektronických dokumentů. HTML obsahuje elementy sloužící jako formátovací příkazy, například P (odstavec), LI (seznam) či TABLE (tabulka). Nenajdete tu žádné elementy, jejichž názvy by zněly například číslo_faktury, použitá_taktika nebo krevní_tlak. Pokud potřebujete zachytit v dokumentu tento typ informace, není HTML příliš vhodný, HTML nemůžete přímo uzpůsobit svým potřebám. Konsorcium W3C (skupina firem podílejících se na vývoji a správě základních technologií Internetu) vypracovala nový standard HTML, který přísněji dodržuje daná pravidla a zároveň je rozšiřitelný. Tato specifikace (XHTML) vyřeší problémy se špatně napsaným kódem, protože prohlížeče odpovídající této specifikaci odmítnou načíst nesprávně zformovaný dokument. To je výtečné, ovšem jen pro nově vytvářené dokumenty, bude však nutné opravit ohromné množství starších stránek. Taková zásadní korekce se dá očekávat jen stěží, proto budou muset mít analyzátory i do budoucna v sobě zabudovány procesor pro špatně napsaný kód. 3.2.3 SGML: Co je na něm dobré International Organisation for Standardisation (ISO) vytváří a udržuje standardy, které pomáhají lidem v rámci celosvětového obchodu i podnikání. ISO vlastní například standardy pro výrobu šroubů, díky kterým si lze objednat šrouby od výrobce z Lucemburska a na ně našroubovat matice vyrobené na Tchajwanu. Jazyk SGML (Standard Generalised Markup Language) je jedním ze standardů ISO. Cílem SGML bylo umožnit sdílení informací v rámci podniků, které mají odlišné informační systémy. V dobách, kdy SGML vznikalo – začátkem osmdesátých let – o něj měly zájem například firmy IBM, CEC nebo the U. S. Internal Revenue Service (IRS). Po dokončení tohoto standardu se na jeho konkrétní specifikaci začaly podílet i další velké průmyslové firmy a federální orgány. Mezi ty nejaktivnější patřilo ministerstvo obrany. Ministerstvo obrany chtělo snížit náklady na uzavření a doručení kontraktů od funkcionářů ministerstva novým smluvním partnerům. Cena za převod dokumentů ze systému aktuálního dodavatele do systému nového dodavatele byla někdy tak vysoká, že vojenští
13
funkcionáři vlastně upřednostňovali nové zájemce – ti totiž nemuseli náklady na převod zahrnout do svých nabídek. Nakonec tedy ministerstvo obrany začalo pátrat po technologii umožňující práci se standardním dokumentem, jejíž používání by bylo pro dodavatele nutnou podmínkou k výhře v konkursu. Touto technologií se stalo SGML. Od té doby musí vojenští dodavatelé zasílat veškerou dokumentaci ve formátu SGML. Díky tomuto standardu je pak možné, aby noví smluvní partneři, kteří přebírají dlouhodobé dodávky, mohli tyto podpůrné dokumenty snadno přečíst. Skutečnost, že ministerstvo obrany a IRS rychle přijaly standard SGML, vedla některé lidi k tomu, že si tuto zkratku začali rozepisovat jako „Standard Government Markup Language“. SGML bylo prvním standardem umožňujícím oddělit data od operací na nich prováděných. Uživatelé během analýzy informací zjistili strukturu dat a obsah. Podle výsledků této analýzy byl pak vytvořen slovník označovaný jako DTD (definice typu dokumentu). DTD určovalo jednotlivé třídy informací, každé DTD bylo tedy přizpůsobeno určité sadě údajů. DTD dále naznačovalo obsah jednotlivých objektů, a to tzv. objektovým modelem s přesně definovanou syntaxí. SGML umožňuje podnikům opakovaně využít ty samé údaje v různých procesech. Stručně se to dá vyjádřit takto: „Jednou vytvoříš, mnohokrát použiješ“. Například návrhář učebních kurzů může stejný zdroj SGML použít pro vytváření příručky pro studenty a příručky pro lektora, protože většina informací je sdílena v obou typech příručky. Sázecí stroj při tisku příručky posluchačů vytiskne jen otázky, lektor však bude mít vytištěny také odpovědi. Dokument SGML je tvořen ASCII textem složeným ze značkování a obsahu. Analyzátor tento dokument přečte a určí strukturu podle značkování. Pozornost věnuje pochopitelně i obsahu jednotlivých elementů. Protože dokument SGML je napsán ve formě prostého textu ASCII, je přenosný a lze ho načíst na libovolném systému, kde běží analyzátor. Jak bude brzy řečeno, XML má tyto přednosti většinou také. Jakožto standard ISO je SGML stabilní a jen obtížně ho lze změnit. Každý standard ISO musí být jednou za pět let znovu zkontrolován výborem, který ho vytvořil a stará se o něj, aby se ověřilo, zda je tento standart ještě potřebný, a pokud ano, zda nevyžaduje
14
aktualizaci. Tento kontrolní postup sice funguje dobře u šroubů a matic, ale obchodní dokumenty se přece jen mění častěji než jednou za pět let – a tím se dostáváme k jednomu z problémů, jež bude podrobněji rozebrán hned v další části. 3.2.4 SGML: to špatné SGML není schopen reagovat na požadavky webu. Vznikl v době pomalých a drahých počítačů (podle dnešních měřítek). Aby bylo možné z těchto primitivních systémů získat maximum, vybavili SGML jeho vývojáři komplexní sadou minimalizačních nástrojů – ty měly výsledné soubory stlačit na co nejmenší velikost. Jenže důsledkem to byla zase složitost zpracování a finanční náročnost na zavádění SGML do praxe. Analyzátory SGML byly pomalé a drahé. Pokud chtěl uživatel vytvořit dokument v jazyku SGML, musel mít po ruce příslušnou DTD, která popisovala strukturu informací. Znamenalo to, že uživatel musel nejdříve provést drahý rozbor údajů a definovat jejich strukturu jednoznačnými pojmy (elementy) ještě předtím, než začal psát vlastní dokument. Hotová DTD pak byla zapojena do každé fáze zpracování dokumentu. Později uvidíte, že v případě změny struktury dat nebo DTD je velmi obtížné ověřit, zda je dokument formálně v pořádku. Dalším problémem je fakt, že SGML patří akademické obci, která viditelně upřednostňuje dodržování standardu nad jeho použitelností. Během dvou posledních revizí tohoto standardu, v roce 1991 a 1996, měla příslušná skupina šanci zjednodušit SGML tak, aby odpovídal potřebám webu. Z mnoha stran se ozývalo volání po „zjednodušeném SGML“, jehož syntaxe by byla výrazně omezena, aby ji webový prohlížeč dokázal zpracovat. Výbor ISO však odmítl provést jakékoli změny, které by SGML zeštíhlily. Jenže web vyžaduje něco přenosného, ale také levného, rychlého a snadného – něco, co se bude podobat HTML, ale zároveň s možností pozdějšího doplňování jako u SGML. A samozřejmě tato očekávaná novinka by měla být kompatibilní s tím, co je již známo, aby se mohli používat již známé technologie a nástroje.
15
3.2.5 Potřebujeme XML Nechuť výboru ISO modernizovat standard SGML měla za následek vstup skupiny internetových profesionálů do konsorcia W3C (které v té době bylo na poli standardizátorů nováčkem), kde vznikl návrh zeštíhleného SGML, který by byl použitelný na webu, ale zároveň slučitelný se SGML i HTML. Členové této skupiny se domlouvali převážně emailem a během let 1996 a 1997 vypracovali specifikaci, kterou nazvali XML (eXtensible Markup Language).
Při návrhu XML se členové skupiny drželi deseti hlavních cílů: 1. XML bude přímo použitelný na Internetu. 2. XML bude podporovat širokou paletu aplikací. 3. XML bude kompatibilní s jazykem SGML. 4. Tvorba programů pro zpracování XML bude snadná. 5. Počet volitelných částí XML bude minimalizován, v ideálním případě nebudou žádné volitelné části standardu. 6. Dokumenty XML by měl člověk bez problémů přečíst a pochopit. 7. Návrh XML musí být hotov rychle. 8. Návrh XML bude metodický a stručný. 9. Vytváření dokumentů XML bude snadné. 10. Obsažnost značkování XML nebude mít téměř žádný význam.
16
3.3 Jazyk XML, syntaxe XML dokumenty se skládají ze značek a obsahu (content). Existuje několik základních druhů značek, které se mohou v dokumentech vyskytnout. Jsou to: •
elementy (elements),
•
entity (entities), resp. odkazy na entity (entity references),
•
komentáře (comments),
•
zpracovatelské instrukce (processing instructions, PIs),
•
sekce CDATA (CDATA sections) a
•
deklarace typu dokumentu (document type declarations).
V následující části budou postupně popsány. 3.3.1 Elementy Jsou nejčastější formou značky. Elementy identifikují obsah který obklopují, z hlediska zápisu stejně jako v HTML. Element začíná start-tagem a je ukončen end-tagem, v následující syntaxi: <element> ...
Element může mít určité atributy, jejichž název a obsah je definován v rámci starttagu:
je element s názvem báseň a jedním atributem, pojmenovaným název, který má hodnotu Máj. Specifickým případem je tzv. prázdný (empty) element, jehož syntaxe je následující: <element/>
17
3.3.1.1
Deklarace typu elementu
Specifikuje jméno elementu a druh jeho obsahu. Deklarace vypadá následovně:
Tato deklarace identifikuje element nazvaný báseň. Za jménem následuje model obsahu elementu (content model), který definuje co element může obsahovat. Ve výše uvedeném případě element musí obsahovat titul a sloku a může obsahovat verš. Znak + za slokou znamená, že element sloka se může v rámci elementu báseň opakovat více než jednou a musí se vyskytnout minimálně jednou, otazník za veršem znamená, že verš může být v elementu báseň obsažen, ale nemusí. Titul, u kterého není žádný doplňující znak, se musí v elementu objevit právě jednou. Další možností by byla hvězdička (*), která znamená, že element se může v rámci jiného elementu objevit vícekrát, ale nemusí ani jednou. Čárky mezi názvy elementů znamenají, že v elementu báseň musí být obsaženy v pořadí, v jakém jsou definovány.
3.3.1.2
Deklarace atributů
Elementy mohou mít atributy, které musí být v dokumentu (resp. i mimo něj - tzv. externí deklarace - viz níže) deklarovány - určuje se, jaké atributy mohou elementy mít, jakých hodnot mohou atributy nabývat, jakého jsou typu a jaká je defaultní hodnota atributů. Elementy mohou mít libovolné množství atributů. Slouží jako metainformace k elementům. Deklarace:
•
jméno_elementu: element, ke kterému se atribut vztahuje
•
deklarace_atributu: skládá se ze tří částí 1. jméno atributu (stejné omezení jako pro jméno elementu) 2. typ atributu 3. standardní hodnota, případně zda je použití povinné
18
3.3.2 Entity Stejně jako v jiných jazycích i v XML jsou určité znaky vyhrazeny pro určitý účel např. pro označení začátku tagu - např. „<“. Aby bylo možné tyto znaky použít ve vlastním obsahu dokumentu, existuje zde alternativní možnost jejich zobrazení, kterou poskytují právě entity. Kromě toho se entity používají k odkazu na často opakované části textu a k vkládání obsahu externích souborů. Každá entita musí mít unikátní jméno. Chceme-li na ní v dokumentu odkázat, použijeme znaky & jako počáteční a ;jako koncový. Rozeznáváme tři typy entit:
3.3.2.1
Interní entity.
Tyto entity spojují jméno entity s určitým textem. Deklarace takové entity vypadá takto:
Následně při použití &firma; kdekoli v dokumentu bude vložen text „ABC, s. r. o." na dané místo. Interní entity tedy umožňují definovat zkratky pro často se opakující části textu, u kterých mohou nastat změny a právě použitím interní entity se dají usnadnit případné změny - např. při změně názvu firmy toto stačí upravit v deklaraci entity. 3.3.2.2
Externí entity.
Tyto entity spojují jméno entity s obsahem nějakého souboru. Příkladem deklarace externí entity budiž např.:
Použití &pozn; vloží obsah souboru poznamka.txt. 3.3.2.3
Parametrické entity.
Používá se např. u stejných typů atributů u více entit. Nechá se říct, že je to jakási zástupka. Definuje se následně:
19
Smysl použití je tedy stejný jako u interních a externích entit, rozdíl je v zápisu (používá se znak procenta namísto ampersandu) a v použití - odkaz na parametrovou entitu se používá v deklaraci, zatímco odkaz na interní/externí entitu ve vlastním těle dokumentu.
3.3.3 Komentáře Komentáře umožňují do textu vložit libovolné řetězce, kterými autor dokumentu může vkládat jakékoli informace, obdobně jako se píší komentáře ve zdrojových kódech programovacích jazyků jako jsou C++, Pascal apod. Komentáře jsou pak XML procesorem ignorovány. 3.3.4 Zpracovatelské instrukce (PIs) Tyto instrukce představují způsob, jak předat instrukce nějaké aplikaci pracující nad XML procesorem. Forma zápisu je následující:
Jmeno identifikuje instrukci pro aplikaci, která jej podle něj identifikuje a zpracuje. Za instrukcí mohou následovat data potřebná k provedení instrukce. 3.3.5 Sekce CDATA Sekce CDATA oznamuje XML procesoru, aby ignoroval všechny značky (markups) obsažené v sekci, což je možné využít např. v případě, kdy chceme, aby určitý obsah určitého elementu obsahoval ukázku XML textu a v té podobě by byla vypsána na obrazovku – tedy, aby jednotlivé značky nebyly interpretovány jako značky, ale jako normální text. 3.3.6 Deklarace Deklarace jednotlivých elementů, entit, atributů se nachází v části dokumentu, která je označována jako deklarace typu dokumentu (document type declaration, DTD), která musí být první věcí v dokumentu za volitelnými PI (viz výše) a případnými komentáři -
20
musí být před prvním elementem v dokumentu. Deklarace kromě jiného identifikuje tzv. kořenový element (root element), který zahrnuje celý obsah dokumentu (v níže uvedeném případě se jedná o element kniha). Deklarace může být buď externí nebo interní. O interní deklaraci se jedná v případě, že všechny deklarace (elementů, entit, atributů) jsou uvedeny přímo v dokumentu; o externí v případě, že dokument obsahuje odkaz na externí soubor, který tyto deklarace obsahuje (DTD) - jedná se tak o zvláštní typ externí entity. XML dokument může obsahovat také jak interní, tak externí deklarace. XML procesor nejprve čte interní deklarace a poté externí. Pokud není požadováno, aby dokument byl platný (valid, viz níže) není nutné číst externí.
3.3.6.1
Dobře vytvořené a platné dokumenty
Dokument je dobře vytvořený (well-formed), pokud splňuje obecná pravidla syntaxe XML - tzn. jednotlivé elementy, atributy entity jsou správně a na správném místě zapsány - mají start-tag a end-tag (nejedná-li se o prázdné elementy), žádný atribut není v jednom start-tagu vícekrát, dokument má kořenový element, používané entity jsou správně předem deklarovány apod. Dokument je platný (valid), pokud obsahuje deklaraci typu dokumentu (document type declaration), resp. je použita externí deklarace = odkaz na DTD, a pokud splňuje stanovení daná touto deklarací (je správné pořadí a hnízdění elementů, jsou uvedeny požadované atributy, hodnoty atributů jsou správného typu apod.). Dá se říci, že platný dokument je na o něco vyšší úrovni než dobře vytvořený - pro profesionální použití je vhodnější. V XML existují pouze výše uvedené dva druhy dokumentů. Pokud dokument nesplňuje kritéria valid ani well-formed, pak se nepovažuje za XML dokument. Zda je dokument dobře vytvořený či platný je možné ověřit parserem, který tak plní podobnou roli jako např. kompilátor u Pascalu, který před překladem nejprve zkontroluje správnost zápisu programového kódu.
21
3.4 Použití XML 3.4.1 Aplikace XML XML používá v těchto typech aplikací: •
Dokumentové aplikace pracující s informacemi, které jsou primárně určeny pro lidi,
•
Datové aplikace pracující s informacemi, které jsou primárně určeny pro další zpracování pomocí softwaru.
Rozdíl mezi uvedenými typy aplikací je rozdílem kvalitativním. Jde o stejný standard XML, který je implementován pomocí stejných nástrojů, ale slouží různým cílům. V čem je tento poznatek důležitý? Lze používat stejné nástroje a zkušenosti pro tvorbu různých druhů aplikací.
3.4.1.1
Dokumentové aplikace
Publikování dokumentů je první oblastí, kde je XML používáno. Hlavní výhodou XML je tu fakt, že se soustřeďuje na strukturu dokumentu, což ho činí nezávislým na distribučním médiu.
22
Obrázek č.1 XML je nezávislé na médiu
Díky tomu je možné editovat a spravovat dokumenty psané v XML a automaticky je publikovat na různých typech médií. Důraz je kladen na slovo automaticky. Schopnost směřovat výstup na různá média bude stále důležitější, protože mnohé publikace jsou dostupné v tištěné a elektronické podobě. Také je třeba brát ohled na to, že web se mění velmi rychle. Co se hodí tento rok, bude příštím rokem zastaralé, ke slovu tedy přijde potřeba rychle přeformátovat celé sídlo. Zapomenout se nesmí ani na to, že některá webová sídla jsou optimalizovaná pro určité prohlížeče. Častým následkem je pak nutnost udržovat dvě či více verzí stejného sídla. Pokud je toto nutné dělat ručně, je to velmi nákladné. Ze všech těchto důvodů má význam udržovat obecnou verzi dokumentu ve formátu nezávislém na médiu, například v XML, a podle potřeby ho automaticky převádět do formátů pro publikování, například do HTML, PostScriptu, PDF, RTF a dalších.
23
Čím více typů médií musíme podporovat a čím je dokument rozsáhlejší, tím důležitější je automatizace koncového publikování dokumentu.
3.4.1.2
Datové aplikace
Jedním z původních cílů při vývoji SGML bylo zpřístupnit pro oblast správy dokumentů ty softwarové nástroje, které jsou používány pro správu dat, například databáze. XML tohoto cíle dosáhlo – přináší totiž do oblasti publikování určitý způsob distribuce dat. Tím se dostáváme k pojmu aplikace jako dokument, kde v zásadě vzato již není rozdíl mezi dokumentem a aplikací. Vskutku, jestliže můžeme strukturu dokumentu vyjádřit jazykem XML, dokážeme tak vyjádřit i strukturu databáze.
Obrázek č.2 Struktura dokumentu vyjádřená v XML
24
Obrázek č.3 Struktura databáze vyjádřená v XML O jednom z nejdůležitějších nasazení XML v datových aplikacích pojednává následující část.
3.4.1.2.1
XML a elektronický obchod
3.4.1.2.1.1
Vývoj elektronického obchodu
Za první formu elektronického obchodu bývá často označován fax. Přenos dat, se kterými by se dalo dále plnohodnotně pracovat, však umožnila až elektronická pošta. Na systémy elektronické pošty, která se dnes používá především pro komunikaci mezi osobami (interpersonal messaging), navázala elektronická výměna dat EDI (electronic data interchange). Ta umožnila výměnu dat na úrovni počítačových aplikací (systémy skladové evidence, účetnictví, platby atp.), čímž byla odstraněna nutnost zásahů ze strany člověka při provádění dílčích transakcí. Předpokládá se, že dalším stádiem ve vývoji elektronického obchodu budou systémy založené na XML, které postupně nahradí poměrně náročnou a těžkopádnou technologii EDI.
25
3.4.1.2.1.2
Přínosy elektronického obchodu
Hlavními přínosy elektronického obchodu v oblasti B2B (business to business, elektronické obchodování mezi firmami) je výrazná úspora provozních nákladů. Tato úspora spočívá zejména v digitalizaci a automatizaci většiny činností (odstranění potřeby opětovného zaznamenávání údajů, odstranění nákladů na tvorbu, evidenci a archivaci papírových dokladů, odstranění nákladů na opravu chyb) a ve využití moderních komunikačních prostředků, především Internetu (výrazné zrychlení přenosu dat, snížení nákladů na komunikaci, vyšší operativnost).
3.4.1.2.1.3
EDI
EDI je elektronická výměna strukturovaných standardních zpráv mezi dvěma aplikacemi dvou nezávislých subjektů. V systémech EDI spolu přímo komunikují počítačové aplikace nebo informační systémy obchodních partnerů a mohou si tak automatizovaně nebo s minimem lidských zásahů předávat obchodní dokumenty, jako jsou faktury a objednávky, dvacet čtyři hodin denně. Hlavním cílem těchto systémů je postupné nahrazování papírových dokumentů elektronickými, které mají nakonec stejnou právní váhu jako dokumenty klasické. Jsou však daleko bezpečnější a jejich předávání je efektivnější a levnější. EDI se nasazuje všude tam, kde se pravidelně předávají standardní doklady. V současnosti je EDI nosnou technologií v řadě případů elektronického obchodování v oblasti B2B. Použití elektronických dokladů bude v následujících letech zaznamenávat rapidní vzestup.
3.4.1.2.1.4
XML na poli EDI
Problémy v oblasti EDI během posledního čtvrtstoletí (dlouhá doba vývoje, nejrůznější požadavky ze stran různých firem, obtížná implementace ve stylu jeden-stylmusí-vyhovovat-všem) by měly být lekcí pro všechny, kdo pracují na výměnných standardech používajících XML.
26
Definice XML je jednodušší než definice EDI, cena implementací vychází nižší a popularita XML mezi výrobci softwaru stále roste. Jazyku XML rozumějí databázové aplikace a díky tomu mu brzy budou rozumět i firemní aplikace – účetní software, evidence zákazníků a obchodní případů, systém pro řízení toku dokumentů atd. Praktické zkušenosti ukazují, že jazyk XML je dobrým řešením elektronické obchodní komunikace, ale není všelékem. Firma zavádějící systém na bázi XML musí vyřešit zpětnou kompatibilitu s EDI a stávajícími systémy, které není možné opustit ze dne na den. Řešení zpětné kompatibility je obtížné a drahé. Dalším problémem je dohoda na společném využití stejných XML formátů mezi firmami, které jsou konkurenty na trhu. Flexibilita jazyka XML každou firmu přímo pobízí k návrhu vlastního řešení na bázi XML, vzájemné propojení těchto řešení je ovšem komplikované a přináší stejné problémy jako zmiňovaná rozšíření EDI. Jazyk XML je velmi obecný a slouží k definici konkrétních datových formátů, specializovaných pro dané řešení. Standardizační organizace nabízejí normy, například ebXML pro elektronickou komerci a cXML pro elektronickou výměnu katalogů, ceníků a objednávek. Firma, která investovala do vlastního řešení, jej ovšem bude prosazovat na úkor standardu. Je tedy zřejmé, že síla XML do jisté míry záleží na dohodě mezi jednotlivými hráči na trhu o vzájemné kompatibilitě. Pokud jejich systémy porozumí stejnému formátu dat založenému na XML, nastane v jejich oboru skutečná elektronická komerce B2B. Úplná dohoda všech zúčastněných není v konkurenčním světě možná, přesto má XML cenu i v takovém případě. 3.4.2 Uplatnění XML v budoucnosti Mezi oblasti, kde se XML uplatní v blízké budoucnosti (včetně těch, kde se již používají nyní), patří: •
Údržba a správa rozsáhlých webových sídel (XML v tomto případě poslouží pro vytváření dokumentů HTML)
•
Výměna informací mezi podniky
27
•
Offloading a reloading databází
•
Sdružený obsah, který je dostupný více webovým sídlům najednou
•
Aplikace pro elektronické obchody, u kterých různé podniky spolupracují s cílem co nejlépe obsloužit zákazníka
•
Vědecké aplikace obsahující nové značkovací jazyky pro matematické a chemické vzorce
•
Elektronické knihy s novými značkovacími jazyky pro vyjádření autorských práv a vlastnictví publikace
•
Příruční
zařízení
a
chytré
telefony
s novými
značkovacími
jazyky,
optimalizovanými pro tato alternativní zařízení
3.5 Doprovodné standardy Hodnota XML nespočívá jen v tom, že jde o značkovací jazyk, ale že je to standardizovaný značkovací jazyk. Jistě by nebylo těžké vytvořit si vlastní značkovací jazyk s využitím vlastních zvyklostí. Pokud však přijmeme standard XML, vstupujeme do stále se rozšiřující společnosti, podporované množstvím standardů a výrobků. Z toho vyplývá, že bude rozhodně snadnější najít případnou podporu, ať už ve formě knih, příkladů či služeb. Stejně tak bude snadné se dostat k softwaru pro tvorbu, správu, ukládání a výměnu dokumentů XML. Protože XML tvoří pevný standard, je stále více podporováno ze strany dodavatelů softwaru. Díky tomu ho přijímá stále větší počet zákazníků. Mohutnější trh opět vyvolá další kladnou reakci ze strany dodavatelů, kteří přijdou s dalšími nástroji pro XML. A tak dále. Pojem XML znamená tedy více než jen značkovací jazyk – je to vlastně celá řada nástrojů, které můžeme ve svém prostředí využít. Konsorcium W3C vyvinulo další standardy, které doplňují XML. Tyto standardy jsou často označovány jako doprovodné standardy XML.
28
3.5.1 Jmenné prostory XML Jmenný prostor XML je často přehlíženým doprovodným standardem, i když se dá říci, že nad něj není. Jmenný prostor totiž přiřazuje elementy jejich vlastníkům. Tento fakt umožňuje velkou přizpůsobitelnost XML, protože organizace může k existujícím elementům přidávat další a jasně u nich vyznačit, kdo je za tato rozšíření zodpovědný. Tak se dá zabránit konfliktu duplicitních názvů a je to jediný způsobit, jak umožnit opakované používání standardních struktur. 3.5.2 Kaskádové styly XML je podporováno dvěma jazyky pro vytváření stylů: XSL (XML Stylesheet Language) a CSS (Cascading Style Sheet). Styly jsou pravděpodobně nejčastěji probíranými doprovodnými standardy. Určují totiž, jak bude dokument XML reprodukován na obrazovce, na papíru nebo v editoru. XSL je sice výkonnější, ale CSS má zase výhodu mnohem širší implementace. 3.5.3 DOM a SAX Objektový model dokumentu (DOM; Document Object Model) a jednoduché API pro XML (SAX; Simple API for XML) jsou API pro přístup k dokumentům XML. Umožňují aplikacím načítat dokumenty XML bez nutnosti starat se o použitou syntaxi. Doplňují se navzájem: DOM se hodí především pro formuláře a editory, SAX je nejlepší pro výměnu informací mezi aplikacemi. 3.5.4 Xpath Xpath je syntaxí pro výběr požadovaných částí dokumentu XML. Může se používat buď jako syntax vložená v jiných jazycích jako např. XSLT nebo jako samostatná specifikace pro dotazování XML.
29
3.5.5 XSL eXtensible Stylesheet Language (XSL) je jazyk, kterým vytváříme pravidla pro transformaci jedné třídy XML dokumentů na jiný XML dokument. Výsledný dokument, který vznikne aplikováním transformačních pravidel, je použit pro zobrazení. Dnes se nejčastěji XSL styl vytváří tak, aby výsledkem jeho aplikování byl HTML dokument. To umožňuje využít současná jádra prohlížečů, která si se zobrazením HTML poradí. Navíc lze XML dokumenty pomocí XSL transformovat do HTML ještě na serveru a tak zpřístupnit XML dokumenty libovolnému prohlížeči. 3.5.6 Xlink a XPointer Jde o jazyky poskytující mechanismus pro vytváření relací ( vztahů ) mezi různými XML dokumenty. XLL (jak někdy bývají souhrně označovány jazyky XLink a XPointer) samozřejmě umožňují jak vytváření jednoduchých odkazů, které známe z HTML, tak i odkazy na tu část stránky, která neobsahuje žádné návěstí (například odkázat na třetí odstavec, který následuje po kapitole, jež se jmenuje "Ze života hmyzu"). Další novinkou je možnost vytvářet obousměrné odkazy, které jasně vyjadřují souvislost dvou stránek. Problémem nejsou ani odkazy, kdy jeden odkaz ukazuje najednou na několik dalších zdrojů. Uživatel pak má možnost vybrat si zdroj, který jej nejvíce zajímá.
3.6 Odvozeniny XML Následuje seznam dalších technologií a jazyků, vzniklých na základě XML. 3.6.1 Jazyky k prezentaci informací Jedná se o velmi hojně zastoupenou množinu jazyků založených na XML, které se používají pro prezentovaní dat na různých zařízeních.
30
Velmi často používanou metodou pro prezentaci dat je jejich převedení z jakéhokoliv zdroje do XML a poté použít XSLT k následnému převedení XML dokumentů do požadovaného jazyka. 3.6.1.1
XHTML
Možnost vytvářet si v jazyce XML dokumenty, které budou používat vlastní sadu tagů vyhovujících našim požadavkům, je velice lákavá a užitečná. Na druhou stranu, pokud budou dokumenty zveřejňovány především na Webu, není nutné vše dělat znovu od začátku. V mnoha případech bude mnohem jednodušší a rychlejší použít zažité a časem ověřené značky, které známe z HTML, a pouze je doplnit o pár nových tagů, které našim dokumentům přidají inteligenci. Stránky XHTML musí splňovat mnohem přísnější syntaktická pravidla než dnešní HTML stránky. Dnešní prohlížeče se dokáží vypořádat s mnoha chybami ve stránkách, jako jsou překřížené elementy, špatně spárované tagy apod. XHTML však vyžaduje, aby všechny stránky byly XML-dokumenty, a musí proto dodržovat správnou strukturu.
3.6.1.2
WML
Wireless Markup Language je jazyk pro prezentaci pro zařízení s malými obrazovkami, s malou pamětí a s menší výkonností. Byl navržen pro mobilní telefony, ale může být použit i pro další zařízení podporující WML 3.6.1.3
SVG
Scalable Vector Graphics je jazyk pro popis dvourozměrných objektů v XML. Umožňuje popis tří typů grafických objektů – vektorové grafické modely, obrázky a text. 3.6.1.4
VoiceXML
Je to značkovací jazyk umožňující hlasovou prezentaci
31
3.6.2 Sémantický web Sémantický web je jakási kolekce metadat, která jsou potřebná pro počítače a jejich aplikace, aby porozuměli webovým dokumentům. V dnešní době je WWW komplexní sítí dokumentů; informace v nich obsažené nemohou být jednoduchým způsobem indexovány a kategorizovány do příslušných skupin a taktéž nemohou být jednoduchým způsobem zpracovány programy, neboť neobsahují dostatek metadat potřebných pro popis informací obsažených v dokumentu. 3.6.2.1
RSS
RSS (Rich Site Summary) poskytuje formát pro zveřejnění obsahu webové stránky na stránce jiné. V dnešní době se RSS vyvinulo v populární prostředek sdílení webových obsahů mezi webovými sídly (např. CNN, BBC, Slashdot, ZDNet). To napomáhá vyřešit množství problémů jako zvyšující se provoz na webu při distribuování zpráv a novinek.
3.6.2.2
RDF
RDF (Resource Description Framework) bylo založeno konsorciem W3C, aby napomohlo vytvořit sémantický web. Bylo vytvořeno proto, aby umožňovalo aplikacím zpracovávat metadata. Poskytuje tak aplikacím, které si vyměňují informace přes web, vzájemnou spolupráci a prostředí, kterému komunikující strany rozumí. 3.6.3 Webové služby Web services jsou distribuované služby, které jsou nezávislé na zařízením, na kterém se budou používat. Nezávislost na zařízení a softwaru je zajištěna všeobecně uznávanými standardy XML a HTTP. Hlavní myšlenka web services je v jejich komponentovosti. Typickou web service by mohla být například služba předpovědi počasí, která by nedělala nic jiného, než že by na požadavek, který by obsahoval místo a datum, odpověděla, kolik bude stupňů a jestli bude pršet. Web services nemají žádné grafické rozhraní jako prohlížeče HTML, jedná se pouze o výměnu informací ve formátu XML. 32
Největší použitelnost web services je ve formě jakéhosi lepidla, kterým se dají poměrně jednoduše propojit už existující systémy, které mají spolupracovat. Celá infrastruktura webových služeb je založena na třech základních technologiích: •
SOAP (Simple Object Access Protocol) - protokol používaný pro komunikaci,
•
WSDL (Web Services Description Language) - standardní formát pro popis rozhraní webové služby,
•
UDDI (Universal Description, Discovery and Integration) - standardní mechanismus umožňující registraci a vyhledávání webových služeb.
Vzájemné vztahy mezi těmito třemi technologiemi jsou zachycené na obrázku č.4. Ke každé webové službě by měl být k dispozici její formální popis v jazyce WSDL. Z tohoto popisu již jde automaticky vygenerovat soapový požadavek. Ve větších systémech nebo přímo v otevřeném prostředí Internetu se popis služby může zaregistrovat do UDDI registru. Ten slouží jako jakýsi telefonní seznam ("zlaté stránky"), který umožňuje vyhledávání služeb s určitými parametry. Klient, který chce využít webovou službu, získá přes UDDI přímo její popis. Z něj je jasné, jakou strukturu má mít soapová zpráva a kam se má webové službě poslat, aby ji rozpoznala.
33
Obrázek č.4. Vztah tří základních technologií (SOAP, WSDL a UDDI) webových služeb
3.6.3.1
SOAP
SOAP je základem webových služeb. Ostatní standardy jako WSDL a UDDI vznikly až později po uvedení SOAPu a jen dále rozšiřují jeho možnosti a snadnost použití. SOAP umožňuje zaslání XML zprávy mezi dvěma aplikacemi a pracuje tedy na principu peer-to-peer. Zpráva je jednosměrný přenos informace od odesílatele k příjemci, ale díky kombinování několika zpráv můžeme pomocí SOAPu snadno implementovat běžné komunikační scénáře. Tento protokol je detailněji probrán v samostatné kapitole (viz kapitola 3.6.4). 3.6.3.2
WSDL
Jazyk WSDL slouží k popisu síťových služeb jako množiny koncových bodů zpracovávajících zprávy. Operace a zprávy jsou popisovány na abstraktní úrovni a teprve
34
poté jsou svázány s konkrétním síťovým protokolem a datovým formátem. To umožňuje snadné vytvoření popisu rozhraní, které nabízí jednu službu několika způsoby. V praxi WSDL popisy nejčastěji popisují služby, které si posílají zprávy pomocí formátu SOAP a protokolu HTTP.
3.6.3.3
UDDI
UDDI nabízí mechanismy pro registrování, kategorizování a vyhledávání webových služeb. UDDI funguje jako velký adresář, který obsahuje informace o subjektech (firmách) a jimi poskytovaných službách. Samotný registr pracuje rovněž jako webová služba a komunikace s ní tedy opět probíhá pomocí SOAPu. Typická práce s UDDI probíhá tak, že vývojář prohledá registr a najde si služby, které potřebuje. Získá pro ně popis WSDL a může je začít rovnou používat. Dodejme ještě, že UDDI nemusí obsahovat jen popisy webových služeb ve WSDL, lze do něj ukládat popisy služeb v libovolném formátu. Z důvodu interoperability se však společně s UDDI používá právě SOAP a WSDL.
3.6.3.4
XML-RPC
Je protokol, který umožňuje volání vzdálených procedur z klienta na serveru a kde XML je použito k zakódování, resp. k dekódování těchto volání, resp. odpovědí a kde HTTP zde slouží jako transportní protokol. XML-RPC se používá pro: •
programování distribuovaných aplikací
•
vývoj a přístup k webovým službám
•
definici vzdálených API pro aplikace
3.6.4 SOAP SOAP (Simple Object Access Protocol - jednoduchý protokol pro přístup k objektům) je protokol na bázi XML, který definuje rámec pro předávání zpráv mezi 35
individuálními systémy prostřednictvím Internetu. Tento protokol je typicky využíván pro volání a provádění procedur na dálku. SOAP byl původně koncipován pro použití jako nadstavba nad HTTP, což by umožnilo jeho snadné začlenění do webových aplikací, ale jiné transportní protokoly, jako např. SMTP, lze využít rovněž.
3.6.4.1
Příkad použití
Buduje se internetová aplikace pro poskytování služeb. Zákazníci budou s aplikací pracovat tak, že jí budou poskytovat informace. Servery zpracují data a vrátí výsledky zpět zákazníkům. Jaký je nejlepší způsob pro zadání dat do systému a jejich následné zpětné získání? Mohla by se například postavit na míru šitá aplikace typu klient/server a požadovat od zákazníků, aby při přístupu k ní používali klientský software. Ale pokud se provozuje obchod prostřednictvím Internetu, bude nutno postavit klienta, který by běžel na všech myslitelných klientských platformách, jako jsou Windows, Macintosh, UNIX, Linux atd. To by znamenalo spoustu práce s psaním klientského softwaru. A co tedy raději použít Web? To by šlo, ale stále ještě je zde nutnost brát v potaz typ prohlížeče, stále ještě se bude muset vybudovat infrastruktura k zasílání a přijímání vstupů a výstupů a formátovat data a datové pakety pro přenos. V případě komplikované aplikace se může sáhnout po jazyce Java nebo ActiveX, ale pak se nejspíš skončí s tím, že se budou ztrácet uživatelé v důsledku problémů se šířkou pásma a s bezpečností.
Nalezené řešení. Je tedy zapotřebí jednoduchý protokol, který usnadňuje paketování aplikačních dat a jejich posílání tam a zpět přes Web, přičemž k tomu využívá obsahově vázané značky (tags) jazyka XML. Tím se zajistí, že jak vysílající, tak i přijímající systém bude moci snadno interpretovat obsah jakékoli zprávy. A tím, že se využije http jakožto transportní protokol, se zajistí, že nebude třeba vytvářet nové díry skrze firewally.
36
Tato filozofie velmi dobře vystihuje koncepci a fungování protokolu SOAP. Jde o jednoduchý protokol, který umožňuje, aby uzly dálkově aktivovaly aplikační objekty a přijímaly výsledná data. SOAP představuje nejmenší společný jmenovatel pro aplikace, aby mohly posílat zprávy. Klient může zaslat zprávu, která aktivuje nějaký program určitého objektu, a server může vrátit výsledky po proběhnutí tohoto programu. SOAP je skutečně velmi jednoduchý. Zprávy nejsou ničím jiným než XML dokumenty, které mohou obsahovat instrukce protokolu SOAP. Ačkoli alespoň teoreticky může SOAP být svázán s jakýmkoli transportním aplikačním protokolem, bývá daleko nejčastěji používán společně s HTTP.
3.6.4.2
Struktura zprávy
Zpráva v SOAPu je jednoduchý XML dokument, který má kořenový element Envelope. V této obálce jsou pak uzavřeny dva elementy Header (hlavička) a Body (tělo). Hlavička je přitom nepovinná a používá se pro přenos pomocných informací pro zpracování zprávy - například identifikaci uživatele, autentizační informace (jméno, heslo) apod. O to nejdůležitější se stará tělo zprávy, v němž se přenášejí informace identifikující volanou službu a předávané parametry, resp. návratové hodnoty služby. SOAP používá jmenné prostory pro identifikování jednotlivých částí XML zprávy. Obálka, hlavičky a tělo zprávy patří do jmenného prostoru http://schemas.xmlsoap.org/soap/envelope/.
3.6.4.3
Model výměny zpráv SOAP
Zprávy SOAP jsou přenášeny pouze v jednom směru – od odesílatele k příjemci, ale lze je také často kombinovat a vytvářet tak různé modely (jako např. požadavek – odpověď). Implementace řešení SOAP lze optimalizovat tak, aby bylo možné těžit z jedinečné charakteristiky jednotlivých síťových systémů. Vazba na protokol HTTP umožňuje, aby
37
odpovědi SOAP byly doručovány jako odpovědi HTTP, přičemž při této implementaci mohou využívat stejného připojení jako příchozí požadavek.
SOAP Sender [NODE]
SOAP Request <xml>
SOAP Receiver [NODE]
SOAP Response <xml> Some Server-side processing • PHP • CGI • Java Servlet • COM/CORBA • SHELL CMD
Obrázek č.5 Žádosti a odpovědi zpráv SOAP jsou XML dokumenty
3.6.4.4
Transportní mechanismy
Jelikož se dnes SOAP typicky používá pro RPC volání, je celkem přirozené, že se pro přenos požadavku/odpovědi nejčastěji používá protokol HTTP. Důvodem je zejména široká podpora HTTP v různých aplikacích. Výhoda použití HTTP také spočívá v tom, že stávající síťová infrastruktura, zvláště ve firemní sféře, dovoluje v podstatě neomezenou komunikaci na portu vyhrazeném pro HTTP (TCP port 80). SOAP požadavek se zasílá v těle HTTP požadavku. Používá se přitom metoda POST, která dovoluje posílat data v těle HTTP požadavku. Požadavek musí obsahovat HTTP hlavičku SOAPAction, která identifikuje SOAP požadavek.
3.6.4.5
Vzorek použití SOAP
Následující příklad uvádí SOAP-žádost nazvanou GetLastTradePrice, která umožňuje klientovi požádat o sdělení nejnovější ceny určité akcie na burze. 38
SOAP požadavek zaslaný přes HTTP POST/StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8" Content-length: nnnn SOAPAction: "SomeURI" <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="urn:x-example:services:StockQuote"> <symbol>MOT
Prvních pět řádek představuje část HTTP hlavičky a indikuje typ zprávy (POST), hostitele, typ obsahu a délku i akční hlavičku SOAP, která poskytuje informaci o intencích soapové žádosti. Vlastní zpráva SOAP je XML dokument představený soapovou obálkou a následovaný vlastním XML prvkem, který specifikuje prostor názvu v SOAP a atributy, pokud existují. Soapová obálka může obsahovat hlavičku, následovanou tělem soapové zprávy. V našem příkladě tělo specifikuje žádost GetLastTradePrice a symbol specifické akcie, jejíž cena je požadována. Reakce na tuto žádost SOAP by mohla vypadat následovně:
SOAP odpověď přenášená pomocí HTTP HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: nnn <SOAP-ENV:Envelope
39
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <SOAP-ENV:Body> <m:GetLastTradePriceResponse xmlns:m="urn:x-example:services:StockQuote">
První tři řádky opět představují část hlavičky HTTP a vlastní soapová zpráva sestává z obálky,
která
obsahuje
reakci
na
původní
žádost,
označenou
labelem
GetLastTradePriceResponse, a obsahuje vrácenou číselnou hodnotu, v našem případě 14,5.
40
4. Modul obchodně-informačního systému 4.1 Požadavky na systém. Cílem bylo vytvořit aplikaci, jež bude demonstrovat možnosti využití XML při elektronické výměně strukturovaných dat. Pro tento účel se autor rozhodl sestrojit modul skladu, který umožní sledovat stav materiálu na skladě a v případě potřeby zařídit objednání potřebného množství materiálu od svého dodavatele. Na tento modul byly stanoveny následující požadavky: •
Aplikace umožní sledovat pohyby stavu materiálu na skladě; musí brát v potaz spotřebu, inventuru a dodávky daného materiálu
•
U spotřeby je nutno znát závislost na té které zakázce, na kterou byl materiál použit
•
Měl by umět vést evidenci výše uvedených spotřeb, inventur a dodávek
•
Umožnit snadné objednání materiálu v případě nízkého stavu na skladě a zjednodušit správu těchto objednávek
•
Zefektivnit správu došlých dodávek od dodavatele
4.2 Projektový návrh Projektový návrh požadované aplikace byl proveden v CASE nástroji MetaEdit+ verze 3.0, metodologií BORM a UML. Nejprve byly identifikovány požadované funkce na systém (Required System Functions) a jednotlivé scénáře (Scenarios). Tyto scénáře byly dále rozpracovány jako Business Process Modely. Těmito modely jsou popsány souvislosti mezi jednotlivými participanty, jejich stavy a aktivitami. Poté byli identifikováni účastníci, kteří budou systém používat a případy užití, což je posloupnost transakcí mezi uživatelem a systémem. Tento model umožňuje pohled na systém z pohledu uživatele. Nakonec byl vytvořen komponentový diagram, který zobrazuje softwarové komponenty, které tvoří danou aplikaci, a vztahy mezi nimi.
41
Obrázek č.6 System requirements (BORM)
42
Obrázek č.7 Business Process Model (BORM) – Objednání materiálu od dodavatele
43
Obrázek č.8 Use Case Model (UML)
Obrázek č.9 Component Model (UML)
44
4.3 Výběr vhodného programovacího jazyka 4.3.1 Výběr jazyka. Hlavním požadavkem volby vhodného programovacího jazyka byla především jeho podpora XML. Ale protože se jazyk XML již nějakou dobu používá a jeho obliba a použití neustále roste, je výčet programovacích jazyků podporujících XML téměř stejně tak dlouhý, jako seznam všech programovacích jazyků vůbec. Zřejmě nejpropracovanější řešení a největší podporu různých nástrojů v této oblasti nabízí jazyk Java od firmy Sun Microsystems (JAXP – Java API for XML, …) a různé nástroje od firmy Microsoft (BizTalk, platforma .NET). Přesto byl pro tuto práci zvolen skriptovací jazyk PHP (Personal Homepage), především pro jeho snadnou implementaci. Tento jazyk sice nedisponuje takovou podporou XML, jako výše jmenovaní, ovšem pro nasazení v této práci plně postačuje. Přehled jeho výhod a nevýhod je uveden níže. 4.3.2 Výhody PHP. •
podobnost jazykům C či Perl
•
třídy (objekty), možnost jednoduchého zapouzdření (ovšem bez kontroly bezpečnosti)
•
obrovské množství funkcí již v základní výbavě (komprimace, hashování, kódování, šifrování, posílání pošty, kalendářní funkce, file system, sessions, atd.
•
rychlost (Zend Optimizer)
•
možnost kompilace do binárního kódu a znemožnění tak zákazníkovi modifikovat skripty (Zend Compiler)
•
nativní support mnoha databází, namátkou: InterBase, Solid, mSQL, MySQL, MSSQL, Sybase, Oracle, Oracle8, PostgreSQL, Informix a jiné včetně ODBC
•
podpora protokolů NIS (Network Information Service - zabezpečení centralizace distribuovaného databázového systému), IMAP, SNMP, NNTP, POP3 (Post Office Protocol), LDAP, FTP a HTTP, otevírání socketů
•
regulární výrazy
•
tvorba obrázků GIF, JPEG a PNG jakožto i PDF souborů za běhu 45
•
úplná podpora WDDX a XML
•
dokumentace a API, pomocí kterého si lze vytvářet vlastní knihovny funkcí (třeba v C++ Builderu)
•
dynamické dohrávání knihoven (so nebo DLL)
•
mnoho pluginů, např. konektivita na Javu (vytváření instancí tříd, tvorba servletů...) nebo možnost vytvářet Macromedia Flash přímo ze skriptu
•
nepřeberné množství již hotových knihoven, tříd, funkcí a projektů, které jsou většinou open source
4.3.3 Nevýhody PHP. •
absence jakéhokoliv aktivního debbugeru (pouze možnost logování volání funkcí) avšak i na něm se u Zendu pracuje
•
zatím žádné řádné vývojové prostředí (pouze editory, které zvýrazňují syntaxi)
•
ve většině případů nutná relativně složitá konfigurace a následná kompilace
4.3.4 Podpora XML v PHP. Pro práci s XML nabízí PHP tyto prostředky: •
SAX parser
•
DOM rozšíření, která zahrnuje podporu Xpath a Xpointer
•
XSLT podporu
Kromě výše zmíněných existují třídy a knihovny pro práci s dalšími XML deriváty jako např. RSS, RDF, Xquery, SOAP, XML-RPC, SVG, WML a další zřejmě budou přibývat.
4.4 Použité technologie Samotná aplikace je postavena převážně na open source technologiích, hlavně kvůli jejich nulové ceně. Využívá tedy:
46
•
Apache webový server,
•
PHP 4 skriptovací jazyk na straně serveru,
•
MySQL databázi,
•
JavaScript skriptovací jazyk na straně klienta.
Při tvorbě aplikace se používaly následující nástroje:
Photoshop 6.0 CE
Dreamweaver
Poznámkový blok
EasyPad
4.5 Vlastní aplikace Na základě výše uvedených funkčních požadavků a vytvoření projektových návrhů byla sestrojena aplikace podle následujících kroků. Nejdříve byl vytvořena intranetová aplikace, která slouží především pro správu zakázek truhlářské firmy. I když v této práci slouží spíše jako podkladová část pro nasazení a použití další části – skladového a objednávkového systému, její existence tu dotváří pohled komplexnosti celé aplikace a napomáhá tak i představám, jak celá věc může pracovat i v praxi. K této aplikaci byl poté přidán modul skladu, který kromě sledování a zadání změn množství materiálu na skladě umožňuje i jeho objednávání, které probíhá s minimem lidských zásahů a kdy mezi sebou komunikují spíše aplikace na stranách objednavatele a dodavatele.
47
V další části bude nejdříve stručně popsána aplikace pro správu zakázek a poté se zvlášť rozebere objednávkový systém, který v této práci tvoří tu důležitější část a je to právě on, kdo demonstruje využití XML při výměně strukturovaných dat mezi aplikacemi.
4.5.1 Popis systému pro správu zakázek Truhlářská firma vyrábí především na zakázku. Její specialitou je výroba točitých schodišť s okrasnými madly a šprdlinkami. Jedná se o poměrně rozsáhlé projekty a proto je třeba spousta informací, které si firma potřebuje schraňovat o zakázkách. K tomu slouží právě tato aplikace, která tyto informace uchovává a zefektivňuje manipulaci s nimi. Aplikace má čtyři základní moduly: 1. Zakázky, jež umožňuje manipulaci s daty jako: • základní údaje zakázce (název, datum vytvoření, fáze vývoje, atd) •
adresy důležitých participantů na zakázce (investor, stavební firma, architekt)
•
produkty, z nichž je výsledná zakázka tvořena, jejich cena, použitý materiál atd.
•
odkazy na umístění souborů, které se týkají procesu práce na projektu
•
celkové ceny za již vyrobený materiál v rámci zakázky a průběh plateb a záloh od objednavatele
2. Dodavatelé, což je databáze firem, které využívá tato firma pro výrobu dílčích částí projektu a kteří tvoří seznam pro výběr u modulu zakázky 3. Úkoly, jež slouží pro výměnu a zadávání úkolů mezi jednotlivými uživateli systému 4. Tiskové sestavy – např. seznamy zakázek, smlouvy o dílo, cenové nabídky atd.
48
Obrázek č.10 Náhled na aplikaci správy zakázek Pro uchovávání informací je použita databáze MySql, funkčnost obstarávají skripty PHP a jako webový server je použit Apache. 4.5.2 Popis skladového modulu Do výše uvedeného systému byl přidán modul skladu, který celé aplikaci přidává následující funkčnosti a možnosti: •
evidence stavů materiálů na skladě
•
přidávání, mazání a úpravy spotřeby materiálu k příslušné zakázce
•
přidávání, mazání a úpravy inventur
•
evidence a úpravy dodávek materiálu
49
•
objednávání
materiálu
od
dodavatele,
při
kterém
dochází
k výměně
strukturovaných objednávek elektronickou formou. Data mohou proudit přímo z aplikace do aplikace. Vše probíhá jen s minimem lidských zásahů, což eliminuje počet chyb vznikajících při ručním zadávání dat.
4.5.3 Použité zjednodušení Vytvořit objednávkový systém, kdy mezi sebou komunikují dvě firmy, respektive jejich systémy, předpokládá vytvoření obou těchto systémů. Toto řešení by však bylo poměrně náročné a nutností vyřešit další spektrum problematiky, týkající se jejich provozu, komunikace a testování, by přesáhly rámec této práce, kde se autor pokouší demonstrovat „pouze“ využití XML v těchto typech aplikací. Ke zjednodušení tedy došlo na straně dodavatele, který je reprezentován pouze vlastní databází a několika skripty, tak aby bylo možné demonstrovat funkčnost objednávkového systému. 4.5.4 Databázová vrstva Datový model byl vytvořen v nástroji PowerDesigner od firmy Sybase, který z výsledného modelu tabulek, jejich prvků a vztahů, umožňuje generovat jak např. obrázek, tak i SQL script, který může být použit pro vytvoření celé databáze. Pro objednávkový modul byly tedy vytvořeny dvě databáze, které prezentují dvě strany komunikujících firem používajících odlišné úložiště, a to stranu objednavatele a stranu dodavatele. Strana dodavatele: Tabulky: •
material – zde jsou uloženy informace o materiálu, který firma dodává svým klientům
•
objednavatele – obsahuje seznam klientů, kterým poskytuje svůj materiál a služby; obsahuje též jejich adresy, kontakty, bankovní konta
50
•
objednavky – sem se ukládají informace o objednávkách, o které si zažádali jednotliví odběratelé; jsou zde obsaženy i cizí klíče přiřazujíc objednávku příslušnému objednavateli a příslušnému materiálu
Strana objednavatele Tabulky: •
material – seznam všech materiálů, jejich maximální množství na skladě a hranice jejich minima, kdy se doporučuje objednat materiál nový
•
inventura – datum provedení a zjištěná manka, popř. přebytek u jednotlivých materiálů na skladě při provádění inventur
•
dodávky - dodávky materiálu umožňujících rozlišovat, zda se jedná o dodávky teprve objednané či již přijaté na slad
•
spotreba - zaznamenává spotřebu materiálu pro jednotlivé zakázky
51
Obrázek č.11 Náhled na databázový model celé aplikace
52
4.5.5 Komunikace mezi aplikacemi Strany objednavatele a dodavatele spolu komunikují pomocí strukturovaných dokumentů XML. A protože se firmy mohou dohodnout na určité struktuře dokumentů (kontrola pomocí dohodnutých DTD), kterou budou používat, pak se data, přenášená v takto strukturovaných dokumentech, mohou přímo zpracovat aplikacemi. Výčet výhod při tomto druhu komunikace byl popsán výše v části o XML v elektronickém obchodování (viz kapitola 3.4.1.2.1) . Problematika přenosu dat mezi aplikacemi nebyla v této práci řešena. Dobrým řešením by však mohlo být použití protokolu SOAP, který definuje rámec pro předávání zpráv mezi individuálními systémy prostřednictvím Internetu a využívá HTTP jako transportní protokol (viz kapitola 3.6.4). Pro komunikaci
v tomto objednávkovém systému se používají dva dokumenty
XML. Podle dohody obou stran, tedy dodavatele i objednavatele, mají dokumenty určitou strukturu, kterou kontroluje příslušné DTD. Tak se zajistí, že komunikující strany budou moci zpracovat dokumenty, jejichž struktura jim bude předem známa. První z nich představuje objednávku, která obsahuje požadované informace potřebné k objednání. V případě nedostatku materiálu na skladě je vygenerována a zaslána dodavateli, který ji následně zpracovává.
XML dokument reprezentující objednávku
53
Tato objednávka musí splňovat strukturu, která je dána přiřazeným DTD. Jak je vidět z následujícího výpisu, objednávka musí obsahovat kód objednavatele, číslo objednávky, datum objednávky a kód objednávaného materiálu s jeho množstvím. Respektive musí obsahovat tagy, v nichž jsou tyto hodnoty uvedeny.
DTD pro XML dokument reprezentující objednávku
54
Druhý XML dokument slouží pro předávání zpráv od dodavatele k objednavateli a obsahuje informace o výsledcích
zpracování a na základě jejich hodnot pak dochází
k odlišným zpracováním na straně objednavatele.
XML dokument reprezentující zprávu od dodavatele
A příslušné DTD, které kontroluje, aby odpověď obsahovala číslo objednávky, kód objednavatele a výsledek zpracování, respektive tagy a jejich strukturu, kde jsou zmíněné informace uloženy.
DTD pro XML dokument reprezentující zprávu od dodavatele
55
4.5.6 Popis funkčností modulu sklad 4.5.6.1
Skladový systém
Změny stavu materiálu na skladě mohou nastat ve třech případech: •
v důsledku dodávky materiálu, který stav zvýší
•
v důsledku spotřeby materiálu, který stav snižuje
•
v důsledku provedených inventur, které mohou stav snížit i zvýšit podle toho, co se při inventuře zjistí.
Z tohoto důvodu byly v aplikaci vytvořeny záložky spotřeba, inventura a dodávky.
4.5.6.1.1
Spotřeba
Při spotřebě materiálu bylo potřeba zohlednit, ke které zakázce a ke kterému produktu, který je součástí celé zakázky, byl materiál vydán. Když se tedy zadává spotřeba, uživatel musí nejdříve zvolit příslušnou zakázku s příslušným produktem a teprve poté zadat spotřebu. Pří zadávání spotřeby se ještě zohledňuje postup spotřeby, to znamená, že existuje záznam o množství každé zadané spotřeby. Celková spotřeba se pak po každé změně přepočítává a zobrazuje ve vedlejším sloupci. Uživatel má ještě možnost přidat další materiál, který se přidá do seznamu materiálů a je možné si pak přidávat spotřebu i do takto nově přidané položky.
56
Obrázek č.12 Náhled na záložku Spotřeba materiálu
4.5.6.1.2
Inventura
Při pravidelných inventurách se zjišťuje, jaké množství materiálu je skutečně na skladu. Zjištěné množství je poté porovnáno s hodnotami, které jsou zapsány v systému. Případné přebytky či manka se poté mohou zaevidovat v této záložce a svými hodnotami tak synchronizovat databázi se skutečným stavem. Spolu s materiálem a zjištěnými odchylkami, se ukládá též číslo inventury a datum provedení, jak je vidět níže (viz obrázek č.13).
57
Obrázek č.13 Náhled na záložku Inventura
4.5.6.1.3
Dodávky
Pokud si firma objedná materiál, je tento záznam zobrazen v záložce objednané dodávky. Když pak dorazí dodávka materiálu od dodavatele, může se vyhledat v tomto seznamu podle čísla objednávky, kterou objednavatel odeslal dodavateli s objednávkou a je přesunuta do sekce přijaté dodávky s datem tohoto přijetí. Přesun objednávky do přijatých ovlivní stav materiálu na skladě, který se automaticky zvýší o přijaté množství. Může se stát, že přijatá dodávka nebude obsahovat příslušné množství materiálu, uvedeného na objednávce,
a tak je povolena i editace objednaných dodávek podle
skutečného množství.
58
Obrázek č.14 Náhled na záložku Dodávky
4.5.6.2
Objednávkový systém
O aktuálním stavu materiálu nás informuje záložka Stav materiálu na skladě. Každý materiál tu má zobrazenou též hodnotu maximálního množství, kterou lze skladovat ve firmě a hranici minima stavu materiálu, při kterém by bylo záhodno objednat materiál nový. Tyto hodnoty si může uživatel nastavit sám podle vlastního uvážení tak, aby mu napomáhaly při jeho práci. Dojde-li k úbytku materiálu na skladě pod stanovenou minimální úroveň, je o tomto stavu informován uživatel zvýrazněním hodnoty stavu na skladě červenou barvou. Uživatel pak může využít nabídky systému a materiál si objednat. Označí si materiál, který chce objednávat, ponechá či upraví přednastavené hodnoty množství materiálu (počítaného jako rozdíl maximálního množství na skladě a aktuálního stavu na skladě) a z takto nastavených požadavků vygeneruje nabídku.
59
Obrázek č.15 Náhled na záložku Stav materiálu na skladě Při tomto generování se vytvoří XML dokument (viz. kapitola 4.5.5) obsahující nutné prvky a hodnoty potřebné k objednání a samozřejmě s takovou strukturou, jakou si předem dohodli s dodavatelem. Uživateli se pak zobrazí náhled objednávky na monitoru (viz obrázek č.16). Je-li uživatel s touto objednávkou spokojen, odešle ji ke zpracování dodavateli. K objednavateli dorazí XML dokument s údaji o objednávce. Následně ji zpracovává ve dvou krocích: 1. nejdříve si z objednávky vytáhne údaje o objednavateli a materiálu, respektive jejich kódová označení a porovná je s údaji ve vlastní databázi materiálů a objednavatelů. Tím si ověří a zajistí, že se jedná o dodavatele a materiály, se kterými obchoduje a je možné tyto údaje zpracovat. •
Pokud pro výše uvedené údaje nenalezne odpovídající ve vlastní databázi, objednávku již dále nezpracovává a odešle objednavateli zprávu, že objednávku
60
nemůže akceptovat. Tato zpráva je opět dokumentem XML sestavená podle předem dohodlé struktury. •
Dopadne-li tato kontrola úspěšně, je objednávka předána k druhému kroku zpracování.
2. Po splnění předchozí podmínky dochází k uložení údajů do dodavatelovy databáze, kde je zaevidována jako nová. •
Nepodaří-li se objednávku uložit, zpracování objednávky končí a objednavateli je zaslána zpráva o neúspěchu zpracování, opět jako XML dokument (viz kapitola 4.5.5).
•
Podaří-li se zprávu uložit, je odeslána objednavateli zpráva o úspěchu celé operace, stejně jako v případě předchozích dvou případů (nepřijetí objednávky v důsledku neodpovídajících údajů a chyba při ukládání) je zpráva ve stejném formátu (struktuře) ovšem s rozdílnými hodnotami.
3. Když objednavatel obdrží zprávu, „vytáhne“ z ní výsledek o zpracování na straně dodavatele. •
Pokud ho dodavatel informuje, že zpracování proběhlo v pořádku a objednávku si zaevidoval, uloží si i objednavatel tuto objednávku a informuje uživatele o akceptování objednávky a jejím zaevidování na obou stranách.
•
Dostane-li objednavatel zprávu o neúspěchu, objednávku dále již nezpracovává a tudíž ji i neeviduje. O neúspěchu pak uživatele informuje.
V případě úspěchu objednání se pak objednávka zobrazí mezi dodávkami se statutem objednaná a dále se s ní nakládá tak, jak je uvedeno v části Dodávky.
61
Obrázek č. 16 Náhled objednávky
4.5.6.3
PHP skripty
Práci s daty zajišťují PHP skripty. V této aplikaci byly použity především pro práci s databází a pro práci s XML dokumenty. Pro práci s XML byla využita především podpora DOM technologie. Ta umožňuje načíst obsah XML dokumentu a poté procházet jeho stromovou strukturou.
62
Ukázka kódu při vytváření XML dokumentu pomocí DOM //funkce doplní existující xml dokument o další tagy function genxml_start($cislo) { global $doc; //globální proměnná $datum = Date("d.m.Y"); //přiřadí proměnné dokument, který bude upravovat $data_file = "DOC_ROOT\objednavka_sablona.xml"; //načte xml dokument $doc = xmldocfile($data_file); //získá referenci na nejvyšší uzel v objektové struktuře dokumentu $root = $doc->document_element(); //získá seznam uzlů, které obsahuje nejvyšší uzel $rootNodes = $root->child_nodes(); //pokud se nachází v uzlu objednavka_detail, vytvoří další požad. uzly foreach ($rootNodes as $rootNode) { if ($rootNode->tagname == 'objednavka_detail') { $obj_cislo = $rootNode->new_child('objednavka_cislo',$cislo); $obj_datum = $rootNode->new_child ('objednavka_datum',$datum); DisplayObj ($datum,$cislo); $obj_zbozi = $rootNode->new_child('objednavka_zbozi'); } } return $obj_zbozi; }
63
K ukládání hodnot z XML dokumentů do databáze byla použita třída „xmlfile.php“, která je volně dostupná na adrese http://phpclass.kiffer.idv.tw/browse.html/package/4.html . Ukázka kódu, při kterém se XML dokument uloží do databáze function parse_mat($tag) { foreach($tag->tags as $k => $v ) { global $citac, $mat_data; // načte hodnoty, pokud je v tagu material if( 0 ==
strcmp( $v->name , "MATERIAL" ) ) {
++$citac; } if( 0== strcmp ( $v->name, "MATERIAL_KOD" )) { $mat_data[$citac-1][$v->name] = $v->cdata; } if( 0== strcmp ( $v->name, "MATERIAL_MNOZSTVI" )) { $mat_data[$citac-1][$v->name] = $v->cdata; } //rekurze parse_mat($v); } } $db = DB::connect($dsn, true); for( $i=0 ; $i < count($mat_data) ; ++$i ) { // vytvoří SQL dotaz $sql = "INSERT INTO $tablename (dodcis , doddat , matkod , matmno,dodsta) VALUES (".$db->quote($cislo).", ".$db->quote($datum).", ".$db->quote($mat_data[$i]["MATERIAL_KOD"]).",
64
".$db>quote($mat_data[$i]["MATERIAL_MNOZSTVI"]). ", ".'0'.")"; // spusti dotaz $result = $db->query($sql); if (DB::isError($result)) { $chyba = 1; } } // odpoji spojeni $db->disconnect();
4.5.6.4
Další prvky aplikace
V hojné míře se tu vyskytují formuláře, které napomáhají ukládání uživatelských dat do databáze. Kontrolu nad prací s formulářemi zajišťují skripty vytvořené v JavaScriptu.
Obrázek č.17 JavaScript dohlíží na uživatelské akce
65
4.6 Přínosy objektového přístupu Ačkoliv samotná aplikace nebyla napsána podle zásad objektového programování (jazyk PHP však podporu objektového programování obsahuje), objektové nástroje tu sehráli svou roli, a to v části analýzy a návrhu. Přínosy objektového přístupu zhodnotím proto z použití v této fázi vývoje. Pro projektovou analýzu byl použit produkt MetaEdit od firmy MetaCase. Tento nástroj umožňuje zobrazit si problematiku reálných potřeb a požadavků na vyvíjený systém do podoby modelů s odpovídajícími prvky a vztahy. Modely vytvořené v metodologiích BORM a UML tak přehledně popsaly proces životního cyklu vývoje, počínaje základními požadavky na systém a konče navržením konkrétní softwarové architektury. Při tvorbě či studiu jednotlivých modelů si lze snáze uvědomit jednotlivé prvky a vztahy, což lze s výhodou uplatnit např. při programátorské části. Výhodu použití objektových nástrojů tu spatřuji především ve zpřehlednění celé problematiky a snadnějšímu pochopení. Nepostradatelným prvkem jsou především při tvorbě rozsáhlejších projektů. Z pohledu vývoje této aplikace se použití objektových nástrojů jeví jako velmi přínosné a efektivní.
4.7 Shrnutí vlastní práce Cílem této aplikace bylo demonstrovat možnosti využití XML jakožto prostředku pro elektronickou výměnu strukturovaných dat. Tento cíl se podařilo splnit. Naprogramovaná aplikace, v podobě skladového a objednávkového systému, poměrně výstižně demonstruje nasazení XML v oblasti elektronické výměny dokumentů. Nebylo však cílem naprogramovat aplikaci, kterou by byla nasazena v reálném provozu. Tato oblast je doménou pro aplikace typu business to business (B2B), kde probíhají elektronické transakce mezi firmami. Tento typ obchodování je dominantou především velkých firem,
66
kde je pro nasazení v reálných podmínkách potřeba řešit rozsáhlou problematiku, na níž pracuje celý tým programátorů. Vytvořenou aplikaci by bylo možno vylepšit například v následujících oblastech: • Přenos dat mezi aplikacemi; zde se jeví jako vhodné použít protokol SOAP společně s protokolem HTTP • Zabezpečení přenášených dat • Řešení chybových stavů; například co dělat, když jedna ze stran dostane zprávu v chybném formátu, s chybnými údaji, atd. • Problematika placení • a další by jistě vyvstali v průběhu vývoje pro reálné nasazení
67
5. Závěr Rozvoj Internetových technologií je závratný, čehož je XML zářným příkladem. Stále přibývají další technologie a standardy, které rozšiřují možnosti využití, již nyní hojně zastoupené, „rodiny“ XML. Ačkoli samozřejmě není možné reflektovat všechny nejnovější postupy a použití tohoto jazyka, nastiňuje tato práce alespoň rámcový pohled na nejnovější trendy, které v současnosti bez nadsázky hýbou světem Internetu. Možná až donedávna se zdála schopnost přežití XML sporná. Počítačoví odborníci, kteří v XML věřili a předvídali mu slibnou budoucnost se však nemýlili. Dnes, po několika málo letech života tohoto jazyka, začíná vznikat spousta prostředí, kde se XML či jeho modifikace používají a odvádějí velmi dobrou práci. Za všechny lze jmenovat alespoň celosvětově rozšířené modifikace XML: CML (chemical markup language) a MML (math markup language) či fenomén jménem WAP. Záběr XML technologie je obrovský. Od ovládání jednoduchých elektronických spotřebičů, přes přenos dat po Internetu, elektronický obchod až k přenosu dat do mobilních sítí. Co se týče výhledů do budoucnosti, lze předpokládat, že jazyk XML pronikne do dalších oblastí lidského života (viz kapitola 3.4.2 ). V této diplomové práci jsem se pokusil objasnit problematiku XML. Je zde popsán její vývoj, od problémů na poli HTML vedoucích k jeho vzniku, přes syntaxi až po nynější možnosti jeho uplatnění v praxi. Podrobněji bylo rozebráno postavení XML na poli elektronického obchodování a jeho uplatnění v B2B aplikacích. Dále jsem se věnoval doprovodným standardům, technologiím a nástrojům vzniklých v prostředí XML, které významně rozšiřují možnosti jeho použití. Zvýšená pozornost je tu věnována protokolu SOAP a webovým službám. Výsledná aplikace, kterou jsem v rámci této diplomové práce naprogramoval, plně odpovídá zadání a požadovaným funkcím. Poměrně výstižně demonstruje nasazení XML v oblasti elektronické výměny dokumentů, která, až do nedávné doby, byla výhradně dominantou EDI systémů.
68
I když pro použití v profesionálních aplikacích typu B2B by bylo vhodnější zvolit jiné nástroje a technologie, úspěšné otestování, v této práci vytvořené aplikace, dokázalo, že použité technologie, tj. PHP, Apache a MySql, mohou být efektivně použity pro práci v XML aplikacích. Rovněž bylo názorně předvedeno, že jazyk XML je dobrým řešením elektronické obchodní komunikace a je stávajícím systémům EDI více než vhodnou alternativou.
69
6. Použitá literatura 1. Kolektiv autorů. Professional PHP4 XML. Chicago: Wrox Press inc., 2002. 943 s. ISBN 1-861007-21-3 2. Kolektiv autorů. PHP – Programujeme profesionálně. Praha: Computer Press, 2002. 656 s. ISBN 80-7226-310-2 3. Spainhour, Stephen; Eckstein, Robert. Webmaster v kostce. Praha: Computer Press, 1999. 504 s. ISBN 80-7226-251-3 4. Benoit Marchal. XML v příkladech. Praha: Computer Press., 2000. 447 s. ISBN 807226-332-3 5. Brian E. Travis. XML a SOAP – Programování serverů BizTalk. Praha: Computer Press, 2000. 419 s. ISBN 80-7226-303-X 6. Kosek, Jiří. PHP – tvorba interaktivních internetových aplikací: podrobný průvodce. 1.vydání. Praha: Grada Publishing, spol. s r. o. 1999. 492 s. ISBN 80-7169-373-1 7. Bakken, S. S. a kol. PHP FAQ [online].
70
14. Pospíšil, Robert. EDI v kostce [online].
71