Možná je to jen můj dojem, možná je přání otcem myšlenky, ale zdá se mi, že se poslední dobou tvůrci a uživatelé technologií XML stále více zabývají jejich efektivitou. Specifikace, kterých zatím přibývalo jak hub po dešti, už pokrývají všechny hlavní oblasti. U některých byla dokončena druhá, podstatně sofistikovanější a komplexnější generace. Už není moc kam košatět ani spěchat. To je vhodná doba k tomu začít se zajímat o praktickou použitelnost nových technologií. Už jsou dostatečně zralé pro optimalizace.
A optimalizace jsou často opravdu nutné. Při přímočaré implementaci některé složitější posloupnosti operací trvají neúnosně dlouho a s rostoucí velikostí dokumentů se tyto potíže kriticky zhoršují. Příkladem komplexního zpracování může být třeba ověření digitálního podpisu zprávy SOAP. To při standardní doporučené implementaci obnáší parsování dokumentu XML a vytvoření jeho reprezentace v paměti, vyhodnocení výrazu XPath, serializaci výsledné sady uzlů a její převedení do kanonické podoby, výpočet digestu a porovnání s kontrolní hodnotou. V praxi se snadno může stát, že ověření podpisu zabere 90 % času potřebného ke zpracování zprávy. To je příliš vysoká cena za zvýšení bezpečnosti. Kdo opravdu nutně nepotřebuje zabezpečení na úrovni zpráv, spokojí se asi s nesrovnatelně efektivnějším zabezpečením na úrovni transportu.
Dokonce i poměrně jednoduché zpracování dokumentu XML se dostává do vážných problémů, je-li dokument trochu větší. Stačí pár desítek nebo stovek megabajtů. Většina současných technologií XML totiž vyžaduje načtení celého dokumentu do paměti a náhodný přístup k jeho uzlům. Reprezentace dokumentu v paměti v závislosti na implementaci potřebuje pětkrát až desetkrát víc místa, než je velikost původního dokumentu (viz např. kapitolu DOM Parsers for Java z knihy Processing XML with Java od E. R. Harolda). I když je k dispozici dost paměti, načtení moc dlouho trvá. A kdo je trpělivý a počká si, nakonec zjistí jen to, že s tak obrovským objektem se stejně nedá nijak kloudně pracovat.
Takže co s tím? Tyto nepříjemnosti pálí hodně lidí, proto už existují určitá řešení a na dalších se pracuje. Jednou možností je nenačítat dokumenty do paměti, ale uložit je do XML databáze. Na disku je dost místa, odpadá potřeba parsování a pro přístup lze použít indexy. Na XML databáze už se dnes nikdo nedívá jako na experiment. Za poslední roky dozrály, kromě kvalitních komerčních máme i open-source eXist. Samozřejmostí je podpora standardů XPath 1.0 a 2.0 a XQuery 1.0.
Uložit dokument do databáze se vyplatí jen u opakovaně zpracovávaných dokumentů. V případě ověření podpisu zprávy SOAP nám to nepomůže. Tady by bylo ideální budování reprezentace dokumentu úplně vynechat, ale v tom nám brání vyhodnocení výrazu XPath, které se bez načtení do paměti neobejde. Některá řešení se proto pokoušejí o streamovou implementaci podmnožiny jazyka XPath. Tyto systémy si efektivně poradí s běžnými případy, ale nezaručují, že si poradí se vším. V tom je úskalí mnoha současných optimalizací v XML. Pokušení a potřeba zvýšit efektivitu i za cenu nestandardních řešení jsou příliš velké. Osobně se mi tato cesta moc nezamlouvá. Za čistý způsob bych považoval vytvoření jiného navigačního jazyka, který by byl plně implementovatelný na XML streamu. Pro potřeby podepisování zpráv a mnohé další účely by takový jazyk pohodlně stačil. W3C v poslední době o podobné možnosti uvažuje, konkrétně se tímto tématem začala zabývat pracovní skupina XSL.
Už několik let W3C zvažuje jinou možnost optimalizace XML – zavedení efektivnější alternativní serilizace. Po prvních vlaštovkách MTOM a XOP omezených na optimalizaci přenosu zpráv SOAP se hledá obecné řešení. Pracovní skupina XBC nejdříve vyhodnocovala argumenty pro a proti binární serializaci, aby její pokračovatelka EXI dnes mohla vybírat nejvhodnější z existujících nestandardních formátů. Binární serializace, korektně nazývaná formát pro efektivní výměnu XML, by pomohla ve dvou ohledech. Prvním je rychlejší přenos díky menší velikosti serializovaného souboru. Druhým je rychlejší načtení. Výsledný formát by měl být kompromisem těchto dvou hledisek.
Po mnoha měřeních pracovní skupina EXI došla k závěru, že nejvhodnějším základem pro formát EXI bude stávající formát zvaný Efficient XML. Na květen je plánováno vydání první pracovní verze specifikace formátu EXI. Současně budou zveřejněny všechny výsledky experimentů, které vedly k rozhodnutí o použití právě tohoto formátu.
Prostor pro optimalizace zde samozřejmě je i v rámci už existujících standardů. Velkou výzvou jsou například implementace XSLT 2.0 a zéjména XQuery 1.0. Indexace, optimalizace dotazů, streamové zpracování, využití znalosti schématu – to všechno jsou oblasti, kde ještě dlouho bude co zlepšovat. Rezervy se určitě najdou u implementací většiny relativně nových standardů XML. První generace softwaru se pochopitelně zaměřila na správnost a úplnost implementace. Teď je ta správná doba pro rychlejší procesory, validátory, databáze a další nástroje.
