01-08, Programowanie, ! Java, Java i XML

1

Wprowadzenie

XML. W ciągu ostatnich dwóch lat chyba każdy programista w którymś momencie poczuł ciarki na plecach związane z tym skrótem. Ciarki na plecach, choć z różnych powodów: konieczność wyuczenia się kolejnego skrótu, ekscytacja nową technologią, zagubienie. I, co ciekawe, każda z tych reakcji na XML jest uzasadniona. Tak, trzeba zapamiętać nowy skrót, a także skróty jemu towarzyszące: XSL, XSLT, PI, DTD, XHTML i inne. Tak, XML oferuje nowe możliwości: to, co Java wniosła w przenośność kodu, XML ma wnieść w przenośność danych. W ostatnich mie­siącach Sun promuje nawet to rozwiązanie następującym sloganem: „Java + XML = przenośny kod + przenośne dane”. I wreszcie — tak, XML powoduje pewne zagubienie. Spróbujemy przy­bli­żyć i rozgryźć XML — będziemy omawiać go tylko na tyle ogólnie i abstrakcyjnie, żeby nie po­paść w bezużyteczność, i tylko na tyle szczegółowo, żeby nie tworzyć kolejnej suchej specyfikacji. To książka dla programisty Javy, który chce poznać i nauczyć się korzystać z narzędzi ope­rują­cych na tej technologii.

Przed programistą współczesnej aplikacji WWW stoi wiele problemów, których dziesięć lat temu nie było nawet w prognozach. Pojawiła się konieczność uruchamiania szybkich i bezawaryjnych systemów rozproszonych na przestrzeni tysięcy kilometrów, konieczność pobierania danych z sys­te­mów heterogenicznych, baz danych, usług katalogowych i aplikacji bez utraty choćby jednej cyfry po przecinku. Aplikacje muszą porozumiewać się nie tylko z innymi komponentami danej firmy, ale także z innymi systemami biznesowymi — często znajdującymi się w innych firmach i zbudowanymi w oparciu o inne technologie. Klienty to już nie tylko klienty uproszczone (ang. thin client), ale całe przeglądarki WWW obsługujące HTML, telefony komórkowe z obsługą pro­to­kołu aplikacji bezprzewodowych (WAP) czy asystenty osobiste („organizery”) obsługujące zu­peł­nie inne języki znaczników. Oreganizacja danych i ich przetwarzanie — oto podstawowe za­dania współczesnych aplikacji.

XML pozwala programiście sprostać wszystkim tym wyzwaniom. Programiści Javy mają zaś je­szcze do dyspozycji arsenał interfejsów umożliwiających korzystanie z XML-a i jego to­warzy­szy bez konieczności opuszczania zintegrowanego środowiska programistycznego Javy (Integrated Development Environment — IDE). Jeśli to wszystko wydaje się zbyt piękne, by było prawdziwe — warto czytać dalej. Poznamy zalety i wady interfejsów API Javy służących do przeprowadzania operacji na XML-u, a także korzyści płynące z zastosowania najnowszych specyfikacji XML-a. Cały czas będziemy przyjmować punkt widzenia programisty. Ta książka nie mówi o tym, dla­cze­go powinno się korzystać z XML-a, ale jak to robić. Jeśli w specyfikacji znajdą się elementy niezbyt przydatne, to powiemy, dlaczego tak jest, i przejdziemy dalej; jeśli jakieś zagadnienie jest szczególnie godne uwagi, poświęcimy mu więcej czasu. Będziemy traktować XML jako na­rzę­dzie, a nie jako slogan reklamowy czy kolejną „zabawkę”. Pamiętając o tym, spróbujmy od­po­wiedzieć na pytanie, czym jest XML.

Co to jest XML?

XML to Extensible Markup Language, czyli rozszerzalny język znaczników. Podobnie jak jego przodek, SGML, XML jest metajęzykiem służącym do definiowania innych języków. Jest jednak o wiele prostszy i bardziej praktyczny niż SGML. XML to język znaczników, w którym nie spre­cy­zowano ani zestawu znaczników, ani gramatyki języka. Zestaw znaczników (ang. tag set) w ję­zy­ku znaczników określa, jakie znaczniki mają znaczenie dla parsera języka. Na przykład, w HTML-u można używać znaczników ze ściśle określonego zestawu. Możemy wstawić znacznik <TABLE>, ale nie możemy użyć <KRZESLO> (angielskie słowo table oznacza nie tylko tabelę, ale także stół). Pierwszy ze znaczników ma dla aplikacji wykorzystującej dane HTML specyficzne zna­cze­nie, a drugi nie — większość przeglądarek po prostu go zignoruje, ale niektóre mogą zachować się nieprzewidywalnie. Wszystko to dlatego, że kiedy definiowano standard HTML, określono w nim konkretny zestaw znaczników. W każdej kolejnej wersji HTML-a dodawane są nowe znaczniki. Jeśli jednak znacznik nie jest zdefiniowany, to przetwarzanie dokumentu zawierającego taki znacznik może spowodować błąd. Gramatyka języka definiuje poprawne użycie jego znaczników. I znów weźmy HTML jako przykład. Do znacznika <TABLE> można dodać szereg atrybutów, określających szerokość tabeli, kolor tła, wyrównanie itd. Nie możemy jednak wstawić np. atry­butu TYPE, bo nie pozwala na to właśnie gramatyka języka.

XML nie definiuje ani znaczników, ani gramatyki. Ma więc nieograniczone możliwości rozbu­do­wy, jest rozszerzalny — i stąd jego nazwa. Jeśli postanowimy korzystać ze znacznika <TABLE>, a potem jeszcze w danych objętych tym znacznikiem zagnieździć kilka znaczników <KRZESLO>, to bez trudności możemy to zrobić. Jeśli chcielibyśmy zdefiniować atrybut określający typ krzesła, np. TYPE, też mamy taką możliwość. Możemy nawet wstawiać znaczniki o nazwach takich jak imio­na naszych dzieci! Możliwości te zostały przedstawione w przykładzie 1.1.

Przykład 1.1. Przykładowy plik XML

<?xml version="1.0" encoding="ISO-8859-2"?>

<pokoj-jadalny>

<table typ="okragly" drewno="klon">

<producent>Drewnosklep S.A.</producent>

</table>

<krzeslo drewno="klon">

<ilosc>2</ilosc>

<jakosc>doskonała</jakosc>

<poduszka zawarta="true">

<kolor>niebieski</kolor>

</poduszka>

</krzeslo>

<krzeslo drewno="dab">

<ilosc>3</ilosc>

<jakosc>średnia</jakosc>

</krzeslo>

</pokoj-jadalny>

Jeśli Czytelnik nigdy nie widział pliku XML, a miał do czynienia tylko z HTML-em lub innymi językami znaczników, to przykład może się wydawać dość osobliwy. To dlatego, że znaczniki i gra­matyka opisująca dane zostały w całości zmyślone. Żadna strona WWW ani specyfikacja nie definiuje znaczników <table>, <krzeslo> czy poduszka (ale mogłoby tak być — w po­do­bny sposób specyfikacja XHTML definiuje znaczniki HTML wewnątrz XML-a). Tu właśnie drze­mie siła XML-a — umożliwia on definiowanie zawartości danych na różne sposoby i wymaga jedynie zgodności z ogólną strukturą języka. W dalszej części książki są przedstawione różnego ro­dzaju ograniczenia, ale na razie wystarczy pamiętać, że XML został stworzony po to, by za­pew­nić ela­sty­czność formatowania danych.

Ta elastyczność jest jedną z największych zalet XML-a, a jednocześnie jedną z jego największych wad. Dokumenty XML można przetwarzać na tak wiele różnych sposobów i w tak wielu różnych celach, że powstała bardzo duża liczba związanych z XML-em standardów opisujących tłuma­cze­nie formatów danych i same formaty. Te dodatkowe skróty i ich nieustanne pojawianie się „w oko­licach” XML-a często powoduje błędne rozumienie idei tego standardu. Kiedy ktoś mówi „XML”, to jest niemal pewne, że nie ma na myśli samego języka XML, tylko jedno z towarzyszących mu narzędzi. Niejednokrotnie zajmować się będziemy właśnie tymi narzędziami; trzeba jednak pa­mię­tać, że najczęściej „XML” nie oznacza samego języka, lecz „XML i towarzyszące mu wspaniałe metody manipulowania danymi”. Skoro to rozróżnienie mamy już za sobą, możemy przejść do roz­szyfrowania najbardziej popularnych skrótów związanych z XML-em. Skróty te są nie­zwy­kle istotne dla całej książki, a więc warto zostawić w tym miejscu zakładkę, aby móc w każdej chwili zajrzeć na te strony. Poniższe opisy powinny przybliżyć Czytelnikowi wzajemne związki między narzędziami związanymi z XML-em oraz wyjaśnić, czym jest XML. Nie będziemy tutaj omawiać mechanizmów publikacyjnych, aplikacji i narzędzi dla XML-a, bo są one przedstawione w dalszej części książki. Poniżej Czytelnik znajdzie informacje jedynie o specyfikacjach i zale­ce­niach. Większość z nich powstała z inicjatywy W3C (World Wide Web Consortium). Organizacja ta zajmuje się definiowaniem standardów XML i spełnia rolę podstawowej bazy informacji o tym standardzie — podobnie jak firma Sun jest podstawowym źródłem informacji o Javie i związanych z nią interfejsach API. Więcej informacji o W3C można znaleźć pod adresem http://www.w3.org.

XML

XML to oczywiście punkt wyjścia wszystkich tych trzy- i czteroliterowych skrótów. Definiuje sam język i określa strukturę metadanych. XML sam w sobie ma niewielką wartość — to tylko stru­k­tura. Ale rozmaite technologie bazujące na tej strukturze dają programistom i administratorom zawartości niespotykaną do tej pory elastyczność w zarządzaniu i przesyłaniu danych. XML ma już status ukończonego zalecenia W3C, co oznacza, że nic się nie zmieni aż do opublikowania nowej wersji standardu. Pełna specyfikacja XML 1.0 znajduje się pod adresem http://www.­w3.­org/ TR/REC-xml/. Specyfikacja ta jest trudną lekturą nawet dla programistów dobrze znających XML, więc po­le­cał­bym raczej zapoznanie się z jej doskonałą wersją opatrzoną komentarzami, dostępną pod adresem http://www.xml.com.

Temat ten będzie w dalszych rozdziałach omawiany szczegółowo, więc teraz wystarczy pamiętać o dwóch podstawowych koncepcjach koniecznych do zrozumienia istoty dokumentu XML. Pierw­sza mówi, że dokument XML, aby był w jakikolwiek sposób przydatny i mógł zostać przetwo­rzo­ny, musi być poprawnie uformowany. Poprawnie uformowany dokument to taki, w którym każ­de­mu znacznikowi otwierającemu odpowiada znacznik zamykający, w którym znaczniki nie są za­gnież­dżone niezgodnie z regułami oraz którego składnia jest zgodna ze specyfikacją. Ale zaraz — czyż nie powiedzieliśmy wcześniej, że XML nie posiada żadnych reguł składniowych? Niezupełnie. Powiedzieliśmy, że nie ma reguł gramatycznych. Dany dokument może definiować własne zna­cz­ni­ki i atrybuty, ale wciąż musi być zgodny z regułami ogólnymi. Reguły te wykorzystywane są następnie przez aplikacje i parsery znające XML w celu odczytania danych z dokumentu i wy­konania na nich pewnych czynności — np. znalezienia ceny krzesła czy utworzenia z danych dokumentu PDF. Zagadnienie to jest dokładniej omówione w rozdziale 2., Pisanie w XML-u.

Druga istotna koncepcja związana z dokumentami XML mówi, że mogą one — ale nie muszą — być poprawne. Poprawny dokument to taki, który spełnia wymagania odpowiadającej mu definicji typu dokumentu DTD (o niej za chwilę). Mówiąc krótko, DTD definiuje gramatykę i zestaw zna­cz­ników na potrzeby określonego formatowania XML. Jeśli w dokumencie określono konkretną de­finicję DTD i jeśli jest on zgodny z tą definicją, to dokument taki określa się jako poprawny. Dokumenty XML mogą zostać także zawężone w ramach schematu — jest to nowy sposób narzu­ca­nia formatu XML, który wyprze DTD. Dokument może być więc także zgodny ze schematem. W dalszej części książki zajmiemy się dokładniej przedstawionymi wyżej zagadnieniami. Naj­pierw jednak musimy poznać kilka skrótów i specyfikacji używanych wewnątrz dokumentu XML.

PI

PI to instrukcja przetwarzania (ang. processing instruction) w dokumencie XML. Instrukcja prze­twa­rzania nakazuje aplikacji wykonanie określonego zadania. Instrukcje PI, choć zajmują niewiele miejsca w specyfikacji XML, są na tyle ważne, że znalazły się wśród omawianych akronimów. PI wyróżnia się spośród innych danych w dokumencie XML tym, że oznacza polecenie prze­ka­zy­wa­ne parserowi XML lub innemu programowi korzystającemu z dokumentu. W naszym przy­kła­dowym dokumencie 1.1 pierwszy wiersz, wskazujący wersję standardu XML, stanowi instrukcję przetwarzania. Informuje parsery, z której wersji standardu będziemy korzystać. Instrukcje prze­twa­rzania mają postać <?cel instrukcje?>. Wszystkie instrukcje PI, w których jako cel okreś­lono XML, należą do standardowego zestawu instrukcji określonego w ramach XML-a i po­win­ny być rozpoznawane przez parsery. Nazywa się je często instrukcjami XML. Ale instrukcje PI mogą także zawierać informacje, które mają zostać wykorzystane przez aplikacje przechwytujące czynności parsera; w takim przypadku jako cel instrukcji przetwarzania można określić słowo klu­czowe odpowiadające danej aplikacji (np. „cocoon”).

Instrukcje przetwarzania nabierają dużego znaczenia, gdy dane XML wykorzystywane są w apli­kacjach znających ten standard. Rozważmy aplikację, która przetwarza nasz przykładowy plik XML, a następnie tworzy reklamę mebli opartą na produktach wymienionych w dokumencie. Instrukcja przetwarzania może poinformować aplikację, że dany mebel jest na liście „za­po­trze­bo­wania” i że ma zostać przekazany do innej aplikacji, np. takiej, która wysyła zamówienia — zatem taki mebel ma nie pojawiać się w reklamie. Parser XML rozpozna instrukcje PI odwołujące się do celów zewnętrznych i przekaże je w niezmienionej postaci zewnętrznym aplikacjom.

DTD

DTD to document type definition, czyli definicja typu dokumentu. DTD narzuca szereg ograniczeń na dokument (lub grupę dokumentów) XML. Definicja DTD sama w sobie nie jest specyfikacją, ale została zdefiniowana jako część specyfikacji XML. Deklaracja typu dokumentu wewnątrz do­ku­mentu XML może sama zawierać ograniczenia odnośnie znaczników, ale może także odwo­ły­wać się do zewnętrznego dokumentu opisującego takie ograniczenia. Definicją typu dokumentu jest suma tych dwóch powyższych zestawów ograniczeń. DTD definiuje sposób, w jaki ma być skon­­struo­wa­ny dokument XML. Ponownie spójrzmy na przykład 1.1. Choć stworzyliśmy grupę włas­nych znaczników, to dokument taki jest bezużyteczny dla innej aplikacji, a nawet dla innego użyt­­kow­ni­ka, który nie potrafi zinterpretować naszych znaczników. Powstają wątpliwości — czy znacznik <ilosc> mówi nam, ile krzeseł jest na stanie? Czy atrybut drewno może zostać użyty w zna­cz­niku <krzeslo>? Jeśli dokument ma zostać poprawnie przetworzony przez parser, na te wszy­stkie pytania trzeba znaleźć odpowiedzi. Dokument uważa się za poprawny, jeśli jest zgodny z ograniczeniami narzucanymi przez DTD odnośnie formatowania danych XML. Jest to szcze­gólnie istotne, gdy zamierzamy przenosić dane pomiędzy aplikacjami — wymaga to uzgodnienia formatu i składni, aby dwa różne systemy mogły się porozumieć.

Jak już wcześniej wspomniano, definicja DTD definiuje ograniczenia, mówiąc inaczej — zawęża konkretny dokument lub zestaw dokumentów XML. Programista lub autor zawartości tworzy także definicję DTD w postaci dodatkowego dokumentu, do którego odwołuje się z plików XML; może także za­wrzeć ją w samym pliku XML — w każdym razie definicja nie ingeruje w żaden sposób w do­ku­ment XML. Tak naprawdę to właśnie DTD przyczynia się do przenośności danych XML. Może ona na przykład określać, że jedynymi poprawnymi wartościami atrybutu drewno są „klon”, „sosna”, „dąb” i „ma­hoń”. Dzięki temu parser potrafi określić, czy zawartość dokumentu jest do przy­jęcia, i za­pobiec ewentualnym błędom formatowania danych. Definicja DTD określa także kolejność za­gnież­dżania znaczników. Może na przykład stanowić, że znacznik <poduszka> ma prawo być zagnieżdżany jedynie w znacznikach <krzeslo>. Dzięki temu inna aplikacja, która otrzymuje nasz przy­kładowy plik XML, wie, jak przetworzyć i przeszukiwać otrzymane dane. Defi­nicja DTD nie tylko przy­czynia się do wysokiej elastyczności formatowania danych w XML-u, ale także umożliwia prze­twarzanie i sprawdzanie poprawności danych w dowolnym systemie po­tra­fiącym odnaleźć tę definicję.

Przestrzeń nazw

Przestrzeń nazw to jedno z niewielu pojęć związanych z XML-em, dla których nie wymyślono akronimu. Nie ma takiej potrzeby — w tym przypadku nazwa dobrze odpowiada funkcji tego ele­mentu. Przestrzeń nazw (ang. namespace) to odwzorowanie pomiędzy przedrostkiem elementu a iden­tyfi­ka­to­rem URI. Odwzorowanie to umożliwia zapobieżenie kolizjom przestrzeni nazw oraz określenie struktur danych, które pozwalają parserom zapobiec takim kolizjom. Przeanalizujmy przy­kład kolizji prze­strze­ni nazw. Załóżmy, że w dokumencie pomiędzy znacznikami <krzeslo> i </krzeslo> znajduje się zna­cznik <cena>. Ale w ramach definicji krzesła jest też znacznik <poduszka>, który przecież także może posiadać własny znacznik <cena>. Zauważmy rów­nież, że dokument może odwoływać się do innego dokumentu XML w celu pobrania informacji o prawach autorskich. W obu dokumentach powinny pojawić się znaczniki <data> lub np. <fir­ma>, ale jak rozpoznać, który znacznik odwołuje się do czego? Taka dwuznaczność to pro­blem dla parsera XML. Czy znacznik <cena> ma być in­terpretowany w różny sposób zależnie od tego, w którym elemencie jest zagnieżdżony? Czy może autor zawartości pomyłkowo użył go w dwóch kontekstach? Bez informacji o przestrzeni nazw nie jest możliwe określenie, czy był to błąd w konstrukcji dokumentu XML, a jeśli było to działanie celowe — jak rozporządzić da­nymi kolidujących znaczników.

Zalecenie opisujące przestrzenie nazw w XML-u definiuje mechanizm do kwalifikowania nazw. Mechanizm ten wykonuje swoje zadanie z użyciem identyfikatora URI, ale tego na razie nie mu­simy wiedzieć. Poprawne stosowanie znaczników w rodzaju opisywanego <cena> nie wymaga wpisywania niezbyt mądrych nazw w rodzaju <cena-krzesla> czy <cena-poduszki>. Zamiast tego przestrzeń nazw tworzona jest z wykorzystaniem przedrostka w postaci elementu XML — a więc na przykład: <krzeslo:cena> czy <poduszka:cena>. Parser XML umie potem rozróżnić te przestrzenie i wcale nie trzeba tworzyć nowych nazw. Przestrzenie nazw są najczęściej używane w dokumentach XML, ale pojawiają się także w schematach i arkuszach sty­lów i w innych specyfikacjach powiązanych z XML-em. Zalecenie odnośnie przestrzeni nazw moż­na znaleźć pod adresem http://www.w3.org/TR/REC-xml-names.

XSL i XSLT

XSL to Extensible Stylesheet Language, czyli rozszerzalny język arkuszy stylów. Służy do prze­kształcania i tłumaczenia danych XML z jednego formatu XML na inny. Rozważmy przykład, w którym ten sam dokument XML musi zostać wyświetlony w formatach HTML, PDF i Post­script. Bez zastosowania XSL-a dokument XML musiałby być ręcznie skopiowany, a następnie przekształcony na jeden ze wspomnianych formatów. Mechanizm XSL umożliwia zde­finiowanie arkuszy stylów wykonujących to zadanie. Zamiast zmieniać dane pod kątem różnych repre­zen­tacji, rozdzielamy dane (zawartość) od reprezentacji — właśnie za pomocą języka XSL. Jeśli do­ku­ment XML musi zostać odwzorowany w postaci innej reprezentacji, jest używany XSL. Wykonuje podobne zadanie jak program w Javie, który tłumaczy dane na format PDF lub HTML, ale zadanie to wykonuje z wykorzystaniem standardowego interfejsu.

Tłumaczenie może dokonywać się za pomocą obiektów formatujących (ang. formatting objects) za­wartych wewnątrz dokumentu XSL. Obiekty te mają postać specyficznych, nazwanych znacz­ni­ków, pod które może zostać podstawiona zawartość składająca się na docelowy typ dokumentu. Typowym obiektem formatującym jest znacznik, który przez jakiś procesor wykorzystywany jest do przetworzenia dokumentu XML na PDF; w takim przypadku znacznik ten zostanie zastąpiony informacją specyficzną dla dokumentu PDF. Obiekty formatujące to specyficzne instrukcje XSL i choć zostaną pokrótce omówione, to jednak wykraczają poza tematykę niniejszej książki. Skon­cen­trujemy się natomiast na XSLT, całkowicie tekstowym procesie transformacyjnym. W wyniku działania procesu XSLT — transformacji rozszerzalnego języka arkuszy stylów (ang. Extensible Stylesheet Language Transformation) — tekstowy arkusz stylów XSL oraz tekstowy dokument XML są „łączone”, tworząc dane XML sformatowane zgodnie z arkuszem stylów XSL. Zagad­nie­nie to przybliża przykład 1.2.

Przykład 1.2. Inny przykładowy plik XML

<?xml version="1.0" encoding="ISO-8859-2"?>

<?xml-stylesheet href="akuku.xsl" type="test/xslt"?>

<!-- Tutaj przykładowy plik XML -->

<strona>

<tytul>Strona testowa</tytul>

<content>

<akapit>WYSIWYG, czyli What you see is what you get!</akapit>

</content>

</strona>

Powyższy dokument zadeklarowano jako dane XML w wersji 1.0. Następnie podano położenie od­powiadającego mu arkusza stylu XSL, akuku.xsl. Podobnie deklaruje się definicję DTD — do DTD odwołujemy się w XML-u po to, aby określić strukturę danych, zaś do pliku XSL po to, aby określić, w jaki sposób dane mają być wyświetlane i prezentowane. W przykładzie 1.3 jest przed­stawiony arkusz stylów XSL, do którego odwołujemy się w dokumencie.

Przykład 1.3. Arkusz stylów dla przykładu 1.2

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:template match="strona">

<html>

<head>

<title>

<xsl:value-of select="tytul" />

</title>

</head>

<body bgcolor="#ffffff">

<xsl:apply-templates />

</body>

</html>

</xsl:template>

<xsl:template match="akapit">

<p align="center">

<i>

<xsl:apply-templates />

</i>

</p>

</xsl:template>

</xsl:stylesheet>

Ten arkusz stylu ma za zadanie przekształcić bazowy dokument XML na postać HTML-ową, nadającej się do obejrzenia w przeglądarce WWW. Wszystkie te zagadnienia zostaną omówione w dal­szej części książki, tutaj przyjrzymy się tylko znacznikom <xsl:template match="[nazwa elementu]">. Każde wystąpienie takiego znacznika powoduje, że odpo­wied­ni element, na przy­kład akapit, jest zamieniany na zawartość arkusza XSL — w tym wy­pad­ku powoduje to wsta­wienie znacznika <p> i ustawienie pochyłości czcionki. Po transformacji do­kumentu XML zgod­nie z pokazanym arkuszem XSL otrzymujemy taki wynik, jak w przy­kła­dzie 1.4.

Przykład 1.4. Wynikowy dokument HTML powstały z przykładów 1.2 i 1.3

<html>

<head>

<title>Strona testowa</title>

</head>

<body bgcolor="#ffffff">

<p align="center">

<i>

WYSIWYG, czyli What you see is what you get!

</i>

</p>

</body>

</html>

Nie szkodzi, że na razie nie są zrozumiałe wszystkie przedstawione konstrukcje XSL i XSLT; wy­star­czy, że Czytelnik zda sobie sprawę z faktu, iż korzystanie z XSL-a umożliwia uzyskanie bar­dzo różnych formatów dokumentów na podstawie tych samych danych bazowych XML. Więcej informacji na temat XSL-a zawarto w rozdziale 6., Przekształcanie XML-a. Standard XSL w orga­ni­zacji W3C ma obecnie status Working Draft (wersja robocza). Zalecenie odnośnie standardu XSL moż­na znaleźć pod adresem http://www.w3.org/Style/XSL.

XPath

XPath (język XML Path Language) stanowi samodzielną specyfikację, ale jest intensywnie wy­ko­rzystywany w ramach XSLT. Specyfikacja XPath określa, w jaki sposób zlokalizować określony element dokumentu XML. W tym celu wykorzystuje się odwołania do specyficznych węzłów do­kumentu XML; węzeł (ang. node) oznacza dowolny komponent XML, taki jak element, atrybut czy dane tekstowe. Według specyfikacji XPath, dokument XML stanowi strukturę drzewiastą takich węzłów. Dostęp do dowolnego węzła można osiągnąć poprzez określenie położenia w da­nym drzewie. Szczegóły związane z XPath zostaną przedstawione dopiero przy dokładniejszym oma­wia­niu XSL i XSLT, ale trzeba pamiętać, że z XPath będziemy korzystali wszędzie tam, gdzie mu­simy odwołać się do specyficznych danych wewnątrz dokumentu XML. Oto przykładowe wy­rażenie XPath:

*[not(self::JavaXML:Tytul)]

Powyższe wyrażenie oznacza wszystkie elementy potomne elementu bieżącego, których nazwa jest inna niż JavaXML:Tytul. W przypadku poniższego fragmentu dokumentu:

<JavaXML:Ksiazka>

<JavaXML:Tytul>Java i XML</JavaXML:Tytul>

<JavaXML:Spis>

<!-- tutaj mamy rozdzialy -->

</JavaXML:Spis>

<JavaXML:Copyright>&OReillyCopyright;</JavaXML:Copyright>

</JavaXML:Ksiazka>

wykonanie wyrażenia, gdy bieżącym węzłem jest element JavaXML:Ksiazka, spowoduje zwró­cenie elementów JavaXML:Spis oraz JavaXML:Copyright. Pełna specyfikacja XPath jest dostępna pod adresem http://www.w3.org/TR/xpath.

XML Schema

Schemat XML Schema to zamiennik definicji DTD o znacznie większych możliwościach. Służy do ograniczania (zawężania) dokumentów XML. Choć tylko pobieżnie omówiliśmy definicje DTD, to już można dostrzec dość poważne ograniczenia tego standardu: brak znajomości hierarchii, trudności w obsłudze konfliktów przestrzeni nazw i niemożność określenia dozwolonych relacji pomiędzy dokumentami XML. Ograniczenia te są ze wszech miar usprawiedliwione — skąd zes­po­ły pracujące nad specyfikacją miały wiedzieć, że XML będzie wykorzystywany na tak wiele róż­nych sposobów? Jednak wady definicji DTD zaczęły dokuczać autorom i programistom korzy­s­ta­jącym z XML-a.

Najistotniejszą cechą XML Schema jest fakt, że umożliwia on zbliżenie definicji DTD do języka XML. To może wydawać się niejasne, ale przypomnijmy sobie, że każdy akronim, o którym osta­tnio mówiliśmy, określany jest na podstawie standardu XML. Arkusze stylów, przestrzenie nazw i cała reszta korzystają z XML-a w celu zdefiniowania specyficznych zastosowań i właściwości tego języka. A definicje DTD są zupełnie inne — nie wyglądają jak XML, nie współdzielą hie­rarchicznej struktury XML-a i nawet nie reprezentują w ten sam sposób danych. Definicje DTD nie przystają więc zbytnio do świata XML, a ponieważ to właśnie one obecnie definiują, jak do­kumenty XML mają wyglądać, łatwo się w tym wszystkim pogubić. Problem ten naprawia XML Schema — w standardzie tym definiowanie XML-a odbywa się za pomocą samego XML-a. Nie mówiliśmy jeszcze wiele o „definiowaniu danych opisujących dane”, ale także to potrafi XML Schema. Specyfikacja XML Schema pozwala w większym stopniu korzystać z konstrukcji tylko jednego języka; nie trzeba uciekać się do innych konstrukcji definicji DTD.

Członkowie W3C i twórcy XML-a słusznie uznali, że przebudowa DTD nie przyniosłaby ocze­ki­wa­nego rezultatu. Dlatego postanowiono stworzyć schematy XML Schema, poprawiając w ten sposób nieodłączne wady DTD oraz dodając nowe funkcje, odpowiadające współczesnym zasto­so­waniom

XML-a. Więcej informacji o tym istotnym projekcie W3C można znaleźć pod adre­sami http://www. w3.org/TR/xmlschema-1 oraz http://www.w3.org/TR/xmlschema-2. Ciekawe wprowa­dze­nie do XML Schema jest dostępne pod adresem http://www.w3.org/TR/xmlschema-0.

XQL...

XQL to język zapytań, dzięki któremu w dokumentach XML można w prosty sposób odwoływać się do baz danych. XQL, choć jeszcze nie został formalnie przyjęty przez W3C, jest na tyle po­wszechny i przydatny, że faktycznie stanowi już popularną metodę uzyskiwania dostępu do baz danych z dokumentów XML. Struktura zapytania definiowana jest za pomocą pojęć XPath, a ze­staw wynikowy — za pomocą standardowego XML-a i znaczników specyficznych dla XQL-a. Na przykład, poniższe wyrażenie XQL przeszukuje tablicę ksiazki i zwraca wszystkie rekordy, w których tytuł zawiera słowo „Java”. Dla każdego rekordu wyświetlany jest odpowiadający mu re­kord w tablicy autorzy:

//ksiazki[tytul contains "Java"] ( .//autorzy )

Zestaw wynikowy takiego zapytania może wyglądać następująco:

<xql:result>

<ksiazka>

<autor nazwisko="Richard Monson-Haefel" miejsce="Minnesota" />

</ksiazka>

<ksiazka>

<autor nazwisko="Jason Hunter" miejsce="California" />

<autor nazwisko="William Crawford" miejsce="Massachusetts" />

</ksiazka>

</xql:result>

Najprawdopodobniej w miarę dojrzewania specyfikacji nastąpią w niej jakieś zmiany; na pewno jednak warto trzymać rękę na pulsie i interesować się XQL-em. Obecna propozycja standardu XQL znajduje się pod adresem http://metalab.unc.edu/xql/xql-proposal.html. Spotkała się ona z za­interesowaniem grupy W3C w styczniu 2000 roku, a obecne wymagania odnośnie języka za­pytań XML można znaleźć pod adresem http://www.w3.org/TR/xmlquery-req.

... i cała reszta

Mamy już za sobą pobieżne wprowadzenie do najważniejszych z omawianych w książce spe­cy­fikacji powiązanych z XML-em. Nie zostały omówione wszystkie liczące się akronimy, a jedynie te, które mają szczególne znaczenie przy omawianiu języka XML z punktu widzenia Javy. Pozo­sta­łe są wy­­mienione poniżej, wraz z adresami odpowiednich zaleceń lub projektów roboczych:

— XLink: http://www.w3.org/TR/xlink/

— XPointer: http://www.w3.org/TR/xptr/

Kiedy Czytelnik będzie czytał tę książkę, prawdopodobnie powyższa lista będzie już nieaktualna — wciąż pojawiają się nowe rozwiązania w ramach XML-a. Nie wszystkie zostały szczegółowo omó­wione w tej książce, ale to wcale nie znaczy, że nie zasługują na uwagę. Nie są po prostu tak bardzo istotne przy omawianiu obsługi XML-a z poziomu Javy. Pełne zrozumienie XML-a na pew­no wymaga opanowania zarówno tych technologii, które dokładniej opisujemy, jak i tych je­dynie wspomnianych. Ale i tak może się zdarzyć, że w pewnym miejscu książki Czytelnik napotka stan­dardy, które nie zostały omówione — wówczas takie zagadnienie zostanie dokładnie przed­stawione.

Jak z tego korzystać?

Wszystkie wspaniałe zalety XML-a nie na wiele się zdadzą, jeśli nie będzie narzędzi umoż­li­wia­ją­cych zastosowanie ich w naszym ulubionym środowisku programistycznym. Na szczęście, XML jest związany z Javą. Java posiada najpełniejszy wybór interfejsów API do obsługi XML-a bez­po­średnio z kodu. Co prawda języki takie jak C, C++ i Perl nadrabiają zaległości w tym zakresie, ale to właśnie Java ustanawia standardy dotyczące sposobu obsługi XML-a z poziomu aplikacji. Z pun­k­tu widzenia aplikacji, cykl działania dokumentu XML dzieli się na dwa etapy (rysunek 1.1): prze­twarzanie dokumentu i analizowanie danych w nim zawartych.

0x01 graphic

Rysunek 1.1. Cykl dzialania dokumentu XML z punktu widzenia aplikacji

Jako programiści Javy, mamy dostęp do bardzo prostych sposobów wykonywania powyższych, a także wielu innych czynności.

SAX

SAX to Simple API for XML, czyli prosty interfejs API do obsługi XML-a. Do przetwarzania danych XML — czyli procesu odczytywania dokumentu i rozbijania danych na odpowiednie ele­menty — udostępnia strukturę opartą na obsłudze zdarzeń. Na każdym etapie definiowane są zda­rze­nia, które mogą wystąpić. Na przykład SAX definiuje interfejs org.xml.sax.Con­tentHandler, który z kolei definiuje metody, takie jak startDocument() i endEle­ment(). Za pomocą takiego interfejsu można uzyskać pełną kontrolę nad odpowiednimi etapami procesu przetwarzania dokumentu XML. Podobny interfejs stworzono do obsługi błędów i kon­strukcji leksykalnych. Definiowany jest zestaw błędów i ostrzeżeń, co umożliwia obsługę różnych sytuacji mogących wystąpić w czasie przetwarzania dokumentu XML — np. napotkanie doku­men­tu niepoprawnego lub źle sformatowanego. Można dodawać nowe zachowania, co umożliwia obsługę zadań związanych z bardzo specyficznymi aplikacjami — a wszystko to w ramach stan­dar­dowego interfejsu XML. Dokumentacja i inne informacje na temat interfejsu SAX znajdują się pod adresem http://www.megginson.com/SAX.

Przed przystąpieniem do omawiania kolejnych zagadnień należy koniecznie wyjaśnić pewne nie­po­rozumienie związane z interfejsem SAX. Otóż SAX często jestb uważany za parser XML-a. Na­wet tutaj piszemy, że SAX umożliwia przetwarzanie danych XML. Ale tak naprawdę --> SAX udo­stęp­nia tylko strukturę [Author:AJ] dla parserów i definiuje zdarzenia procesu przetwarzania podlegające moni­to­­ro­wa­niu. Żeby jakiekolwiek przetwarzanie mogło nastąpić, konieczne jest jeszcze zastosowanie zew­nę­trzne­go parsera. Powstało wiele świetnych parserów napisanych w Javie, takich jak Project X Suna, Xerces z Apache Software Foundation, XML Parser firmy Oracle i XML4J IBM-a. Wszy­stkie one podłączane są do interfejsu SAX i umożliwiają uzyskanie przetworzonych danych XML. Inter­fejs SAX udostępnia sposób na przetwarzanie dokumentu, ale sam nie jest parserem.

DOM

DOM to interfejs API dla obiektowego modelu dokumentu (ang. Document Object Model). SAX umożliwia jedynie dostęp do danych w dokumencie XML, natomiast DOM pozwala na ma­ni­pulowanie danymi. W ramach interfejsu DOM dokument XML reprezentowany jest jako struktura drzewiasta. Ponieważ taki sposób reprezentowania znany jest już od dawna, nie ma trudności z prze­szukiwaniem i przetwarzaniem tego rodzaju struktur z poziomu języków oprogramowania — a więc także z poziomu Javy. W interfejsie DOM cały dokument XML wczytywany jest do pa­mię­ci, a wszystkie dane są składowane jako węzły, a więc bardzo szybko uzyskać można dostęp do po­szczególnych części dokumentów — wszystko jest w pamięci dopóty, dopóki istnieje drze­wo DOM. Poszczególne węzły odpowiadają konkretnym danym pobranym z oryginalnego dokumentu.

DOM ma jednak pewną poważną wadę. Ponieważ cały dokument wczytywany jest do pamięci, zasoby szybko ulegają wyczerpaniu, często powodując spowolnienie działania aplikacji, a nawet uniemożliwienie jej poprawnego działania. Im większy i bardziej złożony jest dokument, tym bardziej spada wydajność. Należy o tym pamiętać — DOM to użyteczny i popularny, ale nie jedyny sposób manipulacji danymi XML. Interfejsowi temu poświęcimy nieco czasu; napiszemy także kod służący do manipulacji danymi wprost z interfejsu SAX. Charakterystyka aplikacji za­de­cyduje o tym, które rozwiązanie okaże się lepsze w danym projekcie programistycznym. Zalecenie W3C odnośnie interfejsu DOM znajduje się pod adresem http://www.w3.org/DOM.

JAXP

JAXP to interfejs Javy do przetwarzania XML-a (ang. Java API for XML Parsing) firmy Sun. Interfejs ten, będący całkiem nowym narzędziem w arsenale programisty XML-a, ma na celu na­danie spójności interfejsów SAX i DOM. Nie jest rozwiązaniem konkurencyjnym w stosunku do nich, nie został też stworzony jako ich następca — JAXP oferuje uproszczone metody mające na celu ułatwienie korzystania z interfejsów Javy do obsługi XML-a. Jest zgodny ze specyfikacjami SAX i DOM, a także ze wspomnianym wcześniej zaleceniem dotyczącym przestrzeni nazw. JAXP nie definiuje zachowania interfejsów SAX ani DOM, ale zapewnia standardową warstwę dostępu dla wszystkich parserów XML-a z poziomu Javy.

Oczekuje się, że JAXP będzie ewoluował w miarę modyfikacji interfejsów SAX i DOM. Można także założyć, że ostatecznie zajmie on miejsce wśród innych specyfikacji firmy Sun, jako że za­rów­no mechanizm serwletów Tomcat, jak i specyfikacja EJB 1.1 wymagają plików konfi­gu­ra­cyj­nych i wdrożeniowych sformatowanych w XML-u. Choć specyfikacje J2EE® 1.3 oraz J2SE® 1.4 nie mówią jawnie o JAXP, to oczekuje się, że także w tych narzędziach zostanie zintegrowana ob­sługa JAXP. Pełna specyfikacja JAXP znajduje się na stronie http://java.sun.com/xml.

Te trzy interfejsy składają się na warsztat programistów Javy mających do czynienia z formatem XML. Nie jest to zatwierdzone formalnie, ale właśnie ta trójka oferuje mechanizm pobierania i manipulowania danymi z poziomu zwykłego kodu w Javie. Interfejsy te będą nam potrzebne w całej książce; dowiemy się wszystkiego o klasach, które każdy z nich udostępnia.

Dlaczego warto korzystać z technologii XML?

W powyższych podrozdziałach zostały omówione najważniejsze skróty opisujące technologie zwią­zane z XML-em. Być może Czytelnik zorientował się już, że XML to coś więcej niż kolejny sposób tworzenia warstwy prezentacji. Ale nie jest jeszcze pewien, w którym miejscu tworzonych aplikacji standard ten można zastosować. Nie udałoby nam się jeszcze przekonać pracodawcy, że powinniśmy poświęcić więcej czasu na poznawanie XML-a — po prostu nie umielibyśmy udo­wo­dnić mu, że XML może przyczynić się do stworzenia lepszej aplikacji. Chcielibyśmy pewnie nawet wypróbować to lub tamto narzędzie do pracy na dokumentach XML, ale nie wiemy, od cze­go zacząć.

Jeśli Czytelnik ma teraz takie właśnie odczucie — zainteresowanie nową technologią i trudność zde­cydowania, co robić dalej — to warto czytać dalej! W tej części poznamy relacje między XML-em a rzeczywistymi aplikacjami i uzasadnimy potrzebę korzystania z tego standardu. Najpierw zo­sta­nie omówione zastosowanie języka XML we współczesnych aplikacjach. Następnie autor przed­sta­wi wsparcie oferowane dla XML-a i powiązanych z nim technologii — wszystko to w świetle aplikacji w Javie. Java oferuje cały wachlarz parserów, narzędzi przekształcających, mecha­niz­mów publikacyjnych i struktur opracowanych specjalnie pod kątem XML-a. W zakończeniu zostaną omówione kierunki rozwoju XML-a. Te wiadomości będą argumentami służącymi do przekonania przełożonego (i jego przełożonych), jak bardzo XML liczy się teraz na rynku.

Java i XML — --> małżeństwo idealne[Author:AJ]

Wiemy już, że XML to naprawdę przydatna technologia i że zdobywa ogromną popularność, jednak Czytelnik tej książki może sobie zadawać pytanie, dlaczego traktuje ona o Javie i XML-u, a nie tylko o tym ostatnim. Otóż Java idealnie pasuje do XML-a z jednego zasadniczego powodu: Java to przenośny kod, XML to przenośne dane. Oddzielnie obie te technologie są naprawdę bar­dzo dobre, ale mają ograniczenia. Java wymaga od programisty tworzenia formatów danych do przesyłania przez sieć i do prezentacji oraz korzystania z technologii typu Java Server Pages™ (JSP), które nie zapewniają faktycznej separacji warstw zawartości i prezentacji. XML to po pro­stu metadane i bez parserów czy procesorów XSL jest to „oprogramowanie - widmo”. Kiedy Java i XML zostaną połączone, wszystkie te ograniczenia programistyczne znikają.

Kiedy napiszemy program w Javie, to mamy pewność, że skompilowany kod bajtowy będzie mógł zostać uruchomiony na dowolnym sprzęcie i w dowolnym systemie operacyjnym wyposażonym w wirtualną maszynę Javy (JVM). Jeśli do tego dodamy możliwość reprezentacji danych wejś­cio­wych i wyjściowych aplikacji z wykorzystaniem niezależnej od systemu, standardowej warstwy da­nych, to otrzymujemy całkowitą przenośność informacji. Aplikacja jest przenośna i porozu­mie­wa się z dowolną inną aplikacją za pomocą tych samych (szeroko przyjętych) standardów. Mało tego, wspomnieliśmy już także, że Java udostępnia szerszy wachlarz interfejsów, parserów, pro­ce­so­rów, struktur publikacji i narzędzi dla XML-a niż jakikolwiek inny język. Pamiętając o tym wszystkim, zobaczymy, jak te dwie technologie współpracują dziś i jak ta współpraca będzie prze­biegała w latach następnych.

XML dzisiaj

Wśród wielu programistów i pracowników firm branży technologicznej panuje przekonanie, że XML to rzeczywiście nowoczesna technologia, ale że nie jest jeszcze gotowa do zastosowania w apli­ka­cjach krytycznych, od których zależy funkcjonowanie całej firmy. To mylna opinia. XML i spo­krew­nione technologie, o których wspomnieliśmy, trwale zadomowiły się w aplikacjach — przyjęły się znacznie szybciej niż zaprezentowana kilka lat temu Java. Najprawdopodobniej to właśnie XML pobił rekord Javy w zdobywaniu rynku informatycznego. My, programiści, musimy sobie zdawać sprawę z faktu, że te dwie technologie uzupełniają się, a nie zwalczają. Dane i aplikacje nie mogą być już bardziej przenośne niż te napisane w Javie i XML-u. Obydwie technologie są już teraz bardzo często stosowane.

XML w prezentacji danych

XML najczęściej stosowany jest do rozdzielania zawartości od sposobu jej prezentacji. Za­war­tością (ang. content) nazywamy dane, które mają zostać wyświetlone u klienta, zaś prezentacją (ang. pre­sen­tation) samo formatowanie tych danych. Na przykład, nazwa i adres pracownika dzia­łu administracji to zawartość, a sformatowana strona w HTML-u, z grafiką i emblematem firmy, to prezentacja. Za­sa­dnicza różnica polega na tym, że zawartość jest uniwersalna względem aplikacji i może zostać poddana dowolnemu formatowaniu; prezentacja natomiast związana jest z konkret­nym typem klienta (prze­glą­darką WWW, telefonem z obsługą Internetu, aplikacją Javy) oraz z fun­kcjami udostępnianymi przez klienta (HTML 4.0, język WML, Java™ Swing). Za zawartość od­powiedzialny jest wtedy XML, zaś za prezentację odpowiadającą poszczególnym klientom — XSL i XSLT.

Jednym z największych wyzwań stojących przed współczesnymi aplikacjami, szczególnie apli­ka­cjami WWW, jest różnorodność klientów z nich korzystających. Jeszcze dziesięć lat temu istniały niemal wyłącznie klienty pełne (ang. thick clients), z zainstalowanym oprogramowaniem pozwa­la­ją­cym na korzystanie z aplikacji. Trzy lata temu klienty aplikacji miały niemal zawsze postać prze­glą­darek internetowych „rozumiejących” HTML. Obecnie korzysta się z przeglądarek na najrozmaitszych platformach systemowych, popularne stały się telefony komórkowe z obsługą bezprzewodowego języka znaczników WML (ang. Wireless Markup Language) oraz asystenty kieszonkowe („or­ga­ni­ze­ry”) z obsługą podzbioru HTML-a. Taka różnorodność powoduje, że nieraz tworzy się niezli­czo­ne wersje tej samej aplikacji — po jednej wersji dla każdego typu klienta — a i tak nie wszystkie klienty są poprawnie obsługiwane. Aplikacja nie musi koniecznie obsługiwać np. telefonu ko­mór­kowego, ale przecież jeśli już odbiorcy lub pracownicy firmy wyposażeni są w takie urządzenia, to czy nie warto z nich skorzystać? Może i kieszonkowy asystent nie umożliwia wykonywania wszy­stkich operacji, jakie udostępnia zwyczajna przeglądarka WWW, ale czy osoby często przeby­wa­jące w podróży nie docenią możliwości przynajmniej podstawowej obsługi swoich spraw w naszej firmie za ich pośrednictwem? Twórcy aplikacji i osoby zarządzające firmami mają dylemat — czy tak jak dawniej oferować wszystkie funkcje tylko wybranym klientom, czy, zgodnie z nowymi ten­den­cjami, oferować jedynie ograniczone funkcje, ale wszystkim klientom? Odpowiedzią jest XML.

Jak powiedzieliśmy wcześniej, XML nie jest technologią prezentacyjną. Jedynie może być użyty do wygenerowania warstwy prezentacyjnej. Jeśli Czytelnik nie dostrzega różnicy, może warto od­wołać się do HTML-a jako technologii prezentacyjnej. HTML ma postać języka znaczników do­branych tak, że umożliwiają graficzne rozplanowanie elementów na stronie wyświetlanej przez przeglądarkę WWW. Ale przecież zastosowanie HTML-a nie jest dobrym sposobem reprezentacji danych. Dokumentu w tym formacie ani łatwo się nie przeszukuje, ani nie przetwarza. Format zo­stał zdefiniowany dość swobodnie, a przynajmniej połowę pliku zajmują znaczniki prezentacji
— właś­ciwe dane to tylko niewielki procent dokumentu. XML jest zupełnie inny. Ten język znaczników ukierunkowany jest na dane, a nie na prezentację. Niemal całość dokumentu XML to dane i opis ich struktury. Do danych nie odwołują się jedynie instrukcje dla parsera XML lub apli­kacji przechwytujących. Przeszukiwanie dokumentu XML i jego przetwarzanie z wykorzystaniem interfejsów API i narzędzi jest proste, dzięki ściśle określonej strukturze narzuconej przez DTD lub schemat. XML jest całkowicie odłączony od warstwy prezentacji. Może jednak zostać wyko­rzystany do tworzenia warstwy prezentacyjnej poprzez zastosowanie spokrewnionych technologii XSL i XSLT. W ramach XSL tworzona jest definicja i konstrukcje odpowiedzialne za prezentacje, a także instrukcje informujące, jak te konstrukcje mają się do danych w dokumencie XML. XSLT umożliwia wyświetlenie oryginalnego dokumentu XML u klienta na różne sposoby, także poprzez bardzo złożony format HTML. Przez cały ten czas bazowy dokument XML pozostaje odsepa­ro­wa­ny od warstwy prezentacji. W każdej chwili może w równie prosty sposób zostać dostosowany do zupełnie innego stylu prezentacji, np. interfejsu użytkownika Swing, bez konieczności wprowa­dza­nia jakichkolwiek zmian w oryginalnych danych.

Być może najpotężniejszą funkcją oferowaną przez XML i XSL na potrzeby prezentacji jest moż­liwość tworzenia wielu arkuszy stylów odpowiadających dokumentowi XML albo narzucania z zewnątrz takich arkuszy. Ta możliwość zwiększa elastyczność prezentacji: nie tylko można ko­rzystać z tego samego dokumentu XML na potrzeby wielu prezentacji, ale struktura publikacji dokonująca transformacji może sama określić, od jakiego klienta nadeszło żądanie dokumentu, i wy­brać odpowiedni arkusz stylu. Nie istnieje standardowy sposób przeprowadzania tego procesu nie ma też standardowych kodów odpowiadających różnym klientom, ale struktura publikacji XML pozwala na przeprowadzanie takich czynności w sposób dynamiczny. Proces tworzenia wielu arkuszy stylów XSL w ramach dokumentu XML nie jest zależny od produktu żadnej firmy, więc jedyne, co należy zrobić w dokumencie XML w celu wykorzystania go w strukturze publikacji, to wprowadzenie jednej czy dwóch instrukcji przetwarzających. Instrukcje takie, jeśli nie są obsłu­gi­wa­ne ze strony aplikacji, zostają zignorowane, a więc oznakowane w ten sposób dane pozostają cał­kowicie przenośne i w stu procentach zgodne ze standardem XML.

XML w komunikacji

Ten sam dokument XML może zostać nie tylko przekształcony, jak to zostało opisane wyżej, moż­liwe jest również przesłanie danych, które zawiera, do innej aplikacji. Wdrożenie takiej komu­ni­kacji nie sprawia żadnych trudności, ponieważ dane XML nie są związane z żadnym typem klienta — nie są nawet wykorzystywane bezpośrednio przez klienta. W szybki sposób uzyskać można również prostą reprezentację danych, łatwą do przesłania w sieci. To właśnie ten aspekt XML-a
— łatwość przesyłania danych — jest chyba najbardziej niedoceniany.

Aby zrozumieć, jak dużo daje możliwość komunikacji za pośrednictwem standardu XML, trzeba najpierw rozszerzyć swój sposób postrzegania aplikacji-klienta. Kiedy omawialiśmy prezentację, w typowy sposób założyliśmy, że klient to użytkownik uzyskujący dostęp do części aplikacji. Ale w dzisiejszych czasach jest to duże uproszczenie. Klient to tak naprawdę cokolwiek (tak, co­kol­wiek!), co uzyskuje dostęp do danych lub usług aplikacji. Klienty to np. komputery lub telefony komórkowe użytkowników; klienty to inne aplikacje, systemy składowania danych w rodzaju baz danych lub usług katalogowych; klientem może być nawet aplikacja łącząca się sama z sobą. Tak szerokie pojęcie klienta pozwala zrozumieć, jak duże znaczenie może mieć XML.

Spróbujmy najpierw podzielić klienty na dwie grupy: klienty wymagające warstwy prezentacji i te, które warstwy takiej nie wymagają. Nie zawsze łatwo przeprowadzić taki podział. Na pewno formaty HTML i WML (Wireless Markup Language) to prezentacja, ale co zrobić, jeśli dane mu­szą zostać sformatowane jedynie nieznacznie na potrzeby innej aplikacji — np. poprzez odfil­tro­wa­nie danych zabezpieczonych lub zmianę nazw elementów? Tak naprawdę rzadko mamy do czy­nie­nia z klientem, który nie wymaga jakiegoś konkretnego formatowania danych.

Powyższa próba kategoryzacji powinna przekonać Czytelnika, że dane niemal zawsze podlegają transformacji, często wielokrotnej. Rozważmy dokument XML, który został przekonwertowany na format użyteczny dla innej aplikacji za pomocą arkusza XSL (rysunek 2.2). Plik wynikowy jest wciąż dokumentem XML. Taka aplikacja może następnie wykorzystać dane do stworzenia nowego ze­stawu wynikowego i utworzenia nowego dokumentu XML. Nowe informacje mają zostać prze­kazane ponownie pierwszej aplikacji, a więc nowy dokument XML jest znów przekształcany na oryginalny format — choć teraz zawiera inne dane! To bardzo typowy scenariusz.

0x01 graphic

Rysunek 1.2. Transformacje XML/XSL pomiędzy aplikacjami

To właśnie ten cykliczny proces przetwarzania dokumentu i nieustannego tworzenia nowej postaci wynikowej XML czyni z XML-a tak potężne narzędzie komunikacyjne. Ten sam zestaw zasad wy­korzystywany jest na każdym etapie procesu. Zawsze rozpoczyna się od dokumentu XML, prze­kształca zgodnie z jednym lub więcej arkuszami stylów XSL i uzyskuje się dokument XML, który wciąż jest użyteczny dla tych samych narzędzi, które stworzyły dokument oryginalny.

Zauważmy także, że XML to dane reprezentowane w sposób czysto tekstowy. Ponieważ repre­zen­ta­cja tekstowa nie wymaga dużych zasobów i łatwo wykonać na niej serializację danych, zatem prze­syłanie tego typu danych w sieci jest łatwiejsze. Niektóre formaty binarne można przesyłać bardzo wydajnie, a jednak tekstowy XML niemal zawsze okazuje się szybszym sposobem komunikacji.

XML-RPC

Specyfikacja, w której skupiono się właśnie na wykorzystaniu XML-a w komunikacji, to XML-RPC. Opisuje ona komunikację nie tyle pomiędzy aplikacjami, co pomiędzy poszczególnymi elemen­ta­mi aplikacji albo współdzielonymi usługami działającymi pomiędzy aplikacjami. RPC to skrót utwo­rzony od słów Remote Procedure Calls (zdalne wywoływanie procedur). Jest jednym z naj­ważniejszych poprzedników technologii zdalnego wywoływania metod RMI (ang. Remote Method Invocation). Za pomocą RPC możliwe jest wywoływanie procedur poprzez sieć i — także poprzez sieć — otrzymywanie odpowiedzi. Należy zauważyć, że to rozwiązanie jest zasadniczo różne od RMI, technologii, która pozwala klientowi uruchamiać metody na danym obiekcie za pośred­ni­ctwem „namiastek” metod (ang. stub) i szkieletów ładowanych poprzez sieć. Główna różnica po­le­ga na tym, że wywołania RPC powodują wygenerowanie odpowiedzi zdalnie; odpowiedź taka zwracana jest później poprzez sieć, a klient nigdy nie komunikuje się bezpośrednio z obiektem zdalnym (żąda wywołania metody za pomocą interfejsów RPC). Natomiast technologia RMI umożliwia klientowi bezpośrednią interakcję z obiektem zdalnym i nie ma żadnego „pośred­ni­czenia” w żądaniach. Bardziej szczegółowy opis zasady działania technologii XML-RPC można znaleźć pod adresem http://www.xml-rpc.com.

Technologia XML-RPC stała się bardzo użytecznym sposobem odwoływania się do zdalnych usług. Z powodu trudności stworzenia standardowego modelu żądanie-odpowiedź, technologia RPC niemal zupełnie przestała być używana w programach w Javie — zastąpiono ją technologią RMI. Istnieją jednak sytuacje, w których wysyłanie i odbieranie danych tekstowych jest wy­dajniejsze niż ładowanie zdalnych „namiastek” i szkieletów. RPC obciążony jest historycznym problemem polegającym na tym, że zawsze starano się reprezentować złożone obiekty wyłącznie tekstowo (zarówno żądania, jak i odpowiedzi). Problem ten rozwiązano w XML-u i RPC znów oka­zuje się dobrym sposobem komunikacji systemów zdalnych. Dzięki standardowi umożli­wia­ją­ce­mu reprezentowanie dowolnego typu danych za pomocą dokumentów tekstowych mechanizm XML-RPC potrafi odwzorowywać parametry egzemplarza (ang. instance) obiektu na elementy XML i w prosty sposób dekodować ten „graf” obiektu na serwerze. Uzyskana odpowiedź może znowu zostać przekształcona na „graf” XML-a i zwrócona klientowi (rysunek 1.3). Więcej infor­ma­cji o mechanizmie XML-RPC można znaleźć w rozdziale 10., XML-RPC.

0x01 graphic

Rysunek 1.3. Komunikacja i powiadamianie w standardzie XML-RPC

Firma-firma

Ostatni ze sposobów zastosowania XML-a w celach komunikacyjnych tak naprawdę nie stanowi oddzielnej metody czy specyfikacji; ponieważ jednak pojęcie komunikacji i handlu typu firma-fir­ma (ang. business-to-business) jest ostatnio bardzo popularne, należy je objaśnić. Komunikacja fir­ma-firma oznacza nie tyle porozumiewanie się dwóch różnych aplikacji, co komunikację pomiędzy przedsiębiorstwami, a nawet całymi branżami. XML jest w takich przypadkach naprawdę pomoc­nym narzędziem — zapewnia komunikację pomiędzy systemami zamkniętymi, umożliwiając wdro­żenie usług, na które kiedyś mogły sobie pozwolić jedynie największe firmy. Przeanalizujmy to zagadnienie na przykładzie. Załóżmy, że niewielki, lokalny operator telekomunikacyjny sprzedaje swojemu klientowi linię do przesyłania danych, np. DSL lub T1. Pociąga to za sobą szereg pro­cesów (rysunek 1.4). Trzeba złożyć zamówienie u dostawcy linii, należy skonfigurować router. O ustawieniach routera trzeba poinformować usługodawcę internetowego (ISP). Następnie prze­pro­wadzana jest faktyczna instalacja, do wykonania której może zostać wynajęta — np. na zasa­dzie outsourcingu — jeszcze inna firma. W tej względnie prostej operacji sprzedaży łącza sieciowego biorą udział aż trzy firmy! Jeśli do tego dodamy techników zatrudnionych przez producenta rou­tera, firmę telekomunikacyjną świadczącą inne usługi klientowi czy NASK zajmujący się reje­stracją domeny, to cały proces zaczyna urastać do sporego problemu.

Na szczęście proces ten można uprościć, właśnie za pomocą XML-a (rysunek 1.5). Wyobraźmy so­bie, że pierwotne zamówienie na założenie łącza zostaje wprowadzone do systemu, który kon­wer­tuje je na doku­ment XML. Dokument ten jest przetwarzany (za pomocą XSL-a) na format, który można przesłać dostawcy linii. Dostawca linii dodaje do tego dokumentu własne informacje i przekształca go na nowy dokument XML, który zwracany jest naszemu lokalnemu operatorowi. Ten nowy dokument przekazywany jest firmie instalującej z dodatkowymi informacjami o tym, gdzie znajduje się firma klienta. Po instalacji firma instalująca dodaje do dokumentu notatkę in­for­mu­­jącą o powodzeniu lub niepowodzeniu instalacji i po przekształceniu (znów za pomocą XSL-a) do­kument jest oddawany do głównej aplikacji u operatora. Elegancja tego rozwiązania po­le­ga na tym, że zamiast kilku sys­te­mów firmowych, z których każdy ma swój sposób for­ma­to­wa­nia, na każ­dym etapie wyko­rzys­ty­wany jest ten sam interfejs XML — bez względu na rodzaj aplikacji, systemu czy firmy.

0x01 graphic

Rysunek 1.4. Proces instalowania łącza sieciowego z wykorzystaniem systemów firmowych

XML w konfiguracji

Jeszcze jedno istotne zastosowanie standardu XML w aplikacjach i technologiach związanych z Ja­vą ma miejsce na poziomie serwera aplikacji. Specyfikacja Enterprise JavaBeans (EJB) 1.1 wymaga, aby deskryptory wdrożeniowe dla programów JavaBean (definiujące sposób działania i inne pa­ra­metry związane z EJB) oparte były na XML-u. Wcześniej w tym celu używano serializowanych deskryptorów wdrożeniowych. W środowisku programistów EJB tę zmianę przyjęto z zado­wo­le­niem, ponieważ deskryptory wdrożeniowe nie muszą być już tworzone zgodnie z wymogami roz­wią­zań firmowych. Ponieważ deskryptory wdrożeniowe mają być teraz zgodne z wcześniej zdefi­nio­waną definicją DTD, wszyscy producenci wykorzystują te same deskryptory. To zaś przy­czynia się do zwiększenia przenośności kodu EJB.

0x01 graphic

Rysunek 1.5. Proces instalowania łącza sieciowego z wykorzystaniem danych w standardzie XML

Standard XML wykorzystywany jest także w konfiguracji interfejsu API serwletów (wersja 2.2). Plik XML opisuje konfigurację samego mechanizmu serwletów (określa parametry złącza, począt­ko­wy kontekst serwleta i inne aspekty specyficzne dla mechanizmu). Pliki konfiguracyjne XML wykorzystywane są także do konfigurowania indywidualnych serwletów — umożliwiają przeka­zywanie argumentów początkowych, konfigurację wielu nazw serwleta oraz dopasowywanie adre­sów URL w specyficznych kontekstach serwletów.

Chociaż zarówno specyfikacja EJB 1.1, jak i mechanizm serwletów Tomcat są nowymi ele­men­ta­mi w krajobrazie języka Java, to zastosowanie XML-a jako podstawy konfiguracji świadczy o tym, że firma Sun przyjęła strategię wykorzystywania standardu XML w tego typu zastosowaniach. W miarę wzrostu popularności parserów XML, pliki konfiguracyjne w XML-u będą stosowane coraz częściej, i to nie tylko w serwerach opartych na Javie — również w np. serwerach HTTP czy bazach danych.

Obsługa XML-a

W drugiej połowie 1999 roku standard XML przeżył rozkwit. Pojawiły się — a w chwili obecnej zyskały już stabilność i wysoką wydajność — parsery XML, procesory XSLT, struktury publi­ka­cji, edytory XML i zintegrowane środowiska programistyczne IDE, a także całe bogactwo narzę­dzi pokrewnych. Choć tematem tej książki jest interfejs API Javy do manipulacji danymi XML, to jednak parsery, procesory i inne elementy niewątpliwie stanowią część procesu przetwarzania XML-a, a więc poświęcone im będzie należne miejsce. Ponieważ technologia XML zmienia się niezwykle szybko, nie będziemy tutaj mówili o konkretnych wersjach — w czasie pojawienia się tej książki na rynku będą już zapewne nowsze. Ponadto jest bardzo możliwe, że wtedy dostępne będą nowe narzędzia. Jeśli Czytelnik nie znajdzie w książce informacji o obsłudze XML-a z poziomu określonego narzędzia, powinien uzyskać je od producenta oprogramowania.

Parsery

Parser stanowi jedną z najważniejszych warstw aplikacji obsługującej XML. Element ten odpo­wie­dzialny jest za niezwykle istotne zadanie analizowania dokumentu. Sprawdza, czy jest po­prawnie sformatowany, czy umieszczono w nim odwołanie do odpowiedniej definicji DTD lub schematu; może także sprawdzać poprawność składni. Po takim przetworzeniu zazwyczaj uzys­ki­wana jest struktura danych — w naszym przypadku przeniesiona na grunt Javy — którą łatwo potem manipulować poprzez inne narzędzia XML lub interfejs API Javy. Nie będziemy teraz szczegółowo opisywać takich struktur, ponieważ są one przedstawione w kolejnych roz­dzia­łach. Tymczasem wystarczy pamiętać, że parser to jeden z najważniejszych składników mechanizmu przetwarzania dokumentu XML.

Wybór parsera XML nie jest zadaniem prostym. Nie obowiazują tutaj sztywne zasady, ale za­zwy­czaj brane są pod uwagę dwa kryteria. Pierwsze z nich to szybkość parsera. W miarę coraz czę­stszego wykorzystywania dokumentów XML i zwiększania ich złożoności szybkość parsera za­czyna mieć istotny wpływ na ogólną wydajność aplikacji. Drugie kryterium to zgodność ze specyfikacją XML. Ponieważ to właśnie wydajność jest często ważniejsza niż niektóre rzadko wykorzystywane cechy XML-a, niektóre parsery nie są w stu procentach zgodne ze specyfikacją XML. Użytkownik musi więc wypośrodkować pomiędzy tymi dwoma kryteriami, biorąc pod uwagę konkretne za­sto­so­wanie. Ponadto niektóre parsery potrafią sprawdzać poprawność składni XML na podstawie definicji DTD, a inne nie. Jeśli tego wymaga dana aplikacja, musimy skorzystać z parsera po­sia­da­jącego taką umiejętność.

Poniżej przedstawiony jest spis najpopularniejszych parserów XML. Nie zamieszczono tutaj in­formacji, czy dany parser wyposażony jest w funkcję sprawdzania poprawności składni, ponieważ w niektórych przypadkach funkcja taka jest właśnie dodawana. Nie przedstawiono tutaj także oceny tych parserów, ale informacje przedstawione na wymienionych stronach WWW powinny wystarczająco ułatwić wybór:

0x01 graphic

Na tej liście celowo nie umieszczono parsera Microsoftu. --> Wygląda [Author:AJ] na to, że firma ta nie zamierza teraz ani w przyszłości utrzymywać zgodności ze standardami W3C. Mi­crosoft najwyraźniej opracowuje własną wersję XML-a. Ileż to już razy przerabia­liśmy... W każdym razie trzeba mieć się na baczności, gdy sytuacja zmusi nas do wykorzystania parsera Microsoftu, MSXML.

Procesory

Po przetworzeniu dokumentu XML niemal zawsze następuje jego przekształcenie (transformacja). Przekształcenie to, jak już wspomnieliśmy, wykonywane jest za pomocą XSLT. Podobnie jak w przetwarzaniu, również na tym etapie obróbki dokumentu XML możemy wybierać spośród wie­lu narzędzi. Znów dwoma podstawowymi kryteriami wyboru są szybkość przekształcania i zgodność ze specyfikacjami XSL i XSLT. W czasie pisnia tej książki standard XSL zyskał status ukoń­­czo­nego zalecenia W3C, a więc obsługa konstrukcji i opcji XSL bardzo gwałtownie się roz­wi­ja. Najlepszym źródłem informacji o danym procesorze jest wymieniona strona WWW — tam znaj­­dziemy informacje dotyczące zgodności narzędzia ze specyfikacjami, tam też są zamieszczone te­sty porównawcze.

Struktury publikacji

Struktura publikacji (ang. publishing framework) to termin nieco mglisty, nie stanowiący for­mal­nej definicji. Na potrzeby niniejszej książki strukturą publikacji standardu XML nazwiemy zestaw narzędzi XML wykonujących przetwarzanie, przekształcanie (transformację) oraz do­datkowe czyn­ności na dokumentach XML w aplikacji. Przetwarzanie i transformacja są zazwyczaj wyko­ny­wane za pomocą wspomnianych wyżej narzędzi; struktura publikacji łączy zaś wszystkie te ope­ra­cje w jedną całość z interfejsem API Javy i zapewnia standardowy interfejs całości. W bar­dziej zaawan­sowanych strukturach możliwe jest przetwarzanie zarówno statycznych dokumentów XML, jak i tych stworzonych w aplikacjach Javy. Niektóre udostępniają także edytory i me­cha­niz­my do tworzenia komponentów, dzięki czemu wygenerowany XML zgodny jest z wymaganiami narzuconymi przez daną strukturę.

Ponieważ nie istnieje żadna specyfikacja określająca zachowanie takich struktur, wymienione po­niżej rozwiązania są bardzo różne. Każde posiada cechy, które sprawiają, że warto się mu przyj­rzeć bliżej. Niektóre struktury są rozprowadzane na zasadzie oprogramowania open source (OSS), są więc nie tylko ogólnie dostępne, ale także otwarte w tym sensie, że można sprawdzić, w jaki sposób dane funkcje zostały zaimplementowane. Kiedy później zajmiemy się budową po­szczególnych komponentów aplikacji, wybierzemy taką strukturę, która najlepiej pasuje do danego zadania. Teraz jednak decyzję tę odkładamy, aby Czytelnik mógł sam zdecydować, co jest dla nie­go najlepsze.

Edytory i środowiska IDE dla standardu XML

Istnieje wiele potężnych parserów i procesorów XML. Tego samego nie można jednak powiedzieć o edytorach. Niestety, XML jest w tym aspekcie w podobnej sytuacji, co kilka lat temu HTML. Niewielka grupa specjalizowanych programistów „pisze XML” zazwyczaj w vi, emacsie lub No­ta­tniku. Pojawiły się ostatnio edytory przeznaczone specjalnie dla XML-a, są to jednak jeszcze projekty niedojrzałe i ich praktyczna przydatność jest niewielka. Istotne postępy robi na tym polu IBM — dotychczasowe wyniki pracy tej firmy można zobaczyć na stronie http://alpha­works.­ibm.com. Odsyłacze do najświeższego oprogramowania można też znaleźć w świetnym serwisie http:// www.xmlsoftware.com.

Przyszłość XML-a

Aby dopełnić obraz XML-a, spróbujmy jeszcze przewidzieć, jak standard ten będzie wyko­rzy­sty­wa­ny w przyszłości. XML często określa się mianem „technologii przyszłości”. W niejednej fir­mie nie zdecydowano się na korzystanie z tego standardu, twierdząc że to technologia jeszcze niedopracowana. Jednocześnie wszyscy przyznają, że jej znaczny wpływ na sposób tworzenia apli­kacji jest już przesądzony. Po tym, jak omówiliśmy sposoby zastosowania XML-a, trudno zgo­dzić się z tezą o jego niedojrzałości. Ale twierdzenie, że standard ten zrewolucjonizuje proces tworzenia aplikacji jest jak najbardziej prawdziwe. Nawet ci, którzy nie korzystają jeszcze inten­sywnie z XML-a, są świadomi, że wkrótce będą to musieli robić — a to „wkrótce” jest z każdym dniem bliżej.

Mimo całego tego zamieszania otaczającego technologię XML oraz wielkich nadziei, jakie ona ze so­bą niesie, prawie niemożliwe jest przewidzenie, jakie znaczenie będzie ona miała za rok, czy na­wet za pół roku. To trochę tak, jakbyśmy jakieś cztery lata temu próbowali przewidzieć przy­szłość tego śmiesznego języka obiektowego zwanego Javą, przydatnego, owszem, do budo­wania aple­tów... Są jednak pewne tendencje w XML-u, które pozwalają domyślić się, jakie zmia­ny nastąpią w najbliższym czasie. Przyjrzyjmy się tym najbardziej rzucającym się w oczy.

Repozytoria konfiguracji

Jak już wspomnieliśmy, XML jest coraz częściej wykorzystywany w konfiguracjach serwerów, ponieważ umożliwia niezwykle prostą reprezentację danych idealnie spełnia potrzeby plików kon­fi­guracyjnych. Tradycyjnie pliki takie były dość zawiłe, trudne w użyciu i modyfikacji oraz spe­cyficzne dla danego producenta. Spójrzmy na fragment pliku konfiguracyjnego serwera HTTP Apache (przykład 1.5).

Przykład 1.5. Plik konfiguracyjny serwera HTTP Apache

ServerType standalone

ServerRoot "e:/java/server/apache/http"

PidFile logs/httpd.pid

ScoreBoardFile logs/apache_status

Timeout 300

KeepAlive On

MaxKeepAliveRequests 100

KeepAliveTimeout 15

MaxRequestsPerChild 0

ThreadsPerChild 50

Listen 80

Listen 85

Plik taki jest niezbyt skomplikowany, ale zasadniczo różni się od pliku konfiguracyjnego serwera Weblogic (przykład 1.6).

Przykład 1.6. Plik konfiguracyjny serwera Weblogic

weblogic.security.ssl.enable=true

weblogic.system.SSLListenPort=7002

weblogic.httpd.register.authenticated=

weblogic.t3.srvr.ClientAuthenticationServlet

weblogic.security.certificateCacheSize=3

weblogic.httpd.register.T3AdminCaputreRootCA=admin.T3AdminCaputreRootCA

weblogic.security.clientRootCA=SecureServerCA.pem

weblogic.security.certificate.server=democert.pem

weblogic.security.key.server=demokey.pem

weblogic.security.certificate.authority=ca.pem

weblogic.httpd.register.Certificate=utils.certificate

weblogic.allow.execute.weblogic.servlet.Certificate=system

weblogic.httpd.enable=false

Te dwa pliki konfiguracyjne mają całkowicie inną składnię. Choć w różnych usługach wyko­rzys­ty­wane będą zazwyczaj różne definicje DTD i nazwy elementów, to jednak XML umożliwia sfor­ma­lizowanie i ustandaryzowanie formatowania plików, przyczyniając się do powstania uniwer­sal­nego języka konfiguracyjnego. To są naprawdę dobre wiadomości dla administratorów sieci, sys­te­mów i dla programistów.

Czytelnik może zauważyć, że pliki konfiguracyjne już omawialiśmy — dlaczego powracamy do te­go tematu? Obecnie każdy serwer posiada lokalny plik (lub pliki) konfiguracyjne. Choć w nie­któ­rych serwerach ostatnio umożliwia się także odczytywanie konfiguracji poprzez usługi katalo­go­we, to jednak ta metoda przyswajana jest powoli i wymaga znajomości protokołu usług katalo­go­wych, naj­częściej LDAP (Lightweight Directory Access Protocol). Widać coraz silniejszą tendencję tworzenia repozytoriów XML zawierających konfiguracje (rysunek 1.6). Coraz chętniej ko­rzysta się również z interfejsu Java Naming and Directory Interface™ dla standardu XML (usługa po­dob­na do udostępniania plików). W takiej sytuacji XML może funkcjonować albo oddzielnie od usług katalogowych, albo jako abstrakcyjna warstwa „na” usługach katalogowych, pozwalająca aplikacjom posiadającym jedynie parser XML uzyskiwać ustawienia konfiguracyjne. To znacznie prostsze rozwiązanie niż udostępnianie serwerom bibliotek LDAP. Ponadto, w miarę wzrostu licz­by serwerów poprawnie interpretujących język XML, możliwość przechowywania konfiguracji w jednym, centralnym miejscu pozwala zapewnić wzajemną współpracę poszczególnych ele­men­tów systemu. Serwery HTTP będą mogły rozpoznawać, jakie mechanizmy serwletów są do­stępne, i samodzielnie konfigurować połączenia. Serwery JavaBean mogą odnajdywać usługi katalogowe w sieci i rejestrować tam swoje „fasolki”, a także odkrywać bazy danych, które można wyko­rzystać do przechowywania obiektów. To tylko niektóre możliwości wiążące się z wprowa­dza­niem serwerów sieciowych (korzystających ze wspólnego repozytorium XML) w miejsce ser­werów samodzielnych.

0x01 graphic

Rysunek 1.6. Repozytorium konfiguracji oparte na XML-u

XSP

XSP to Extensible Server Pages, czyli rozszerzalne strony serwera. To jeszcze jeden akronim związany z XML-em, którego wprowadzenie może mieć ciekawe konsekwencje dla pro­gra­mo­wa­nia w Javie. Na razie standard ten ma status projektu roboczego autorstwa Ricardo Rocha i Stefano Mazzocchiego, głównych programistów pracujących nad projektem Apache Cocoon. W czasie pisania tej książki projekt nie był jeszcze przyjęty formalnie przez W3C ani inną organizację, ale kiedy książka będzie w sprzedaży, sytuacja ta może już przedstawiać się inaczej. Mówiąc skrótowo, XSP to zewnętrzny interfejs struktury XML. Umożliwia tworzenie dynamicznych stron XML przetwarzanych i przekształcanych w ramach struktury. Strony takie umożliwiają współ­pra­cę pomiędzy aplikacjami. W systemie składowane są jako pliki statyczne.

Czytelnicy zaznajomieni z elementami Javy uruchamianymi po stronie serwera zapewne odnoszą wrażenie, że jest to coś w rodzaju JSP, a przynajmniej „XML-owej” wersji JSP. To do pewnego stopnia prawda. XSP to interfejs do XML-a; stanowi alternatywny język skryptowy do tworzenia stron i całych serwisów WWW. W wielu aplikacjach biznesowych pisanych w Javie duży nacisk kładzie się na odseparowanie zawartości od aplikacji i logiki biznesowej. Podobną rolę spełnia XSP w aplikacjach opartych na XML-u. Choć taką separację warstw w ramach skompilowanego kodu umożliwia wiele dostępnych obecnie struktur XML-a, to jednak zmiany w formatowaniu samych danych zawartych w dokumencie XML wymagają zmian w kodzie Javy i rekompilacji. A do tego dochodzą jeszcze zmiany wynikające z prezentacji za pomocą odpowiedniego arkusza stylów XSL. W ramach interfejsu XSP można także zdefiniować proces opisujący transformacje XSLT zachodzące w dokumencie — transformacje zarówno programowe, jak i prezentacyjne. Przyj­rzyjmy się przykładowemu dokumentowi XSP (opartemu na przykładzie z projektu robo­czego XSP — przykład 1.7).

Przykład 1.7. Prosta strona XSP

<?xml version="1.0" encoding="ISO-8859-2"?>

<xsp:page

language="java"

xmlns:xsp="http://www.apache.org/1999/XSP/Core"

>

<title>Prosta strona w XSP</title>

<p>Czołem. Otwarto mnie <licznik /> razy.</p>

</xsp:page>

W takiej stronie mamy tylko ładnie sformatowany i w prosty sposób weryfikowany język XML. Nie ma w nim logiki programistycznej. Na tym właśnie polega różnica pomiędzy językami XSP a JSP — logika i kod programu zdefiniowane są w odpowiednim arkuszu logiki (ang. logicsheet), a nie w samej stronie XSP. Dzięki temu zachowujemy całkowitą niezależność od języka takiej stro­ny oraz abstrakcję konstrukcji specyficznych dla danego języka w ramach arkusza logiki. Tran­sformację znacznika <counter/> oraz reszty strony może obsługiwać np. arkusz logiki za­pre­zentowany w przykładzie 1.8.

Przykład 1.8. Arkusz logiki XSP

<?xml version="1.0" encoding="ISO-8859-2"?>

<xsl:transform

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

xmlns:xsp="http://www.apache.org/1999/XSP/Core"

>

<xsl:template match="xsp:page">

<xsp:page language="java">

<xsp:structure>

<xsp:include>java.lang.*</xsp:include>

</xsp:structure>

<xsp:logic>

private static int licznik = 0;

private synchronized int obecnaLiczba() {

return ++licznik;

}

</xsp:logic>

<xsp:content>

</xsp:content>

</xsp:page>

</xsl:template>

<xsl:template match="licznik">

<xsp:expr>obecnaLiczba()</xsp:expr>

</xsl:template>

<!-- Resztę zostawiamy tak jak jest -->

<xsl:template match="*|@*|comment()|pi()|text()">

<xsl:copy>

<xsl:apply-templates />

</xsl:copy>

</xsl:template>

</xsl:transform>

Nie trzeba chyba szczegółowo wyjaśniać zasady działania powyższych przykładów. XSP oferuje pe­wne nowe konstrukcje, takie jak <xsp:structure> oraz <xsp:logic>, ale poza tym do­kument wygląda jak standardowy arkusz stylów XSL. Znaczniki XSP są zrozumiałe — pozwalają na wprowadzenie wyniku działania kodu w Javie.

Choć interfejs XSP jest obecnie dostępny jedynie jako część projektu Apache Cocoon, to jest to pomysł niezwykle starannie przemyślany. Umożliwi oddzielenie aplikacji „rozumiejących” XML od szczegółów prezentacji w sposób bardziej wydajny niż do tej pory. Upraszcza także wpro­wa­dzanie samego XML-a, tak jak strony JSP zachęcały programistów do poznawania Javy i prze­cho­dze­nia do bardziej złożonych interfejsów. XSP może także przyczynić się do większego upow­szech­nienia XML-a. Więcej informacji o XSP oraz pełny projekt roboczy tego standardu znaleźć można pod ad­resem http://xml.apache.org/cocoon/xsp.html.

Co dalej?

Po tym niezwykle szybkim omówieniu technologii XML oraz interfejsów API Javy umoż­li­wia­ją­cych jej obsługę gotowi jesteśmy do zagłębienia się w szczegóły. Następne dwa rozdziały po­świę­cimy omawianiu składni XML-a oraz sposobu korzystania z tego standardu w aplikacjach WWW. To umożliwi nam zrozumienie dokumentów XML, jakie będziemy potem tworzyć, formatować i przetwarzać z poziomu naszych aplikacji. W następnym rozdziale szczegółowo opiszemy sposób tworzenia dokumentu XML; powiemy także, co to znaczy, że dokument XML jest „poprawnie sfor­matowany”.

Zanim zaczniemy, jeszcze jedna istotna uwaga — szczególnie ważna dla tych, którzy tylko przej­rzeli niniejszy rozdział. Technologię XML od samego jej poczęcia otacza atmosfera niezro­zu­mie­nia i niedoinformowania. Autor niniejszej książki zakłada, że Czytelnik nie miał jeszcze kontaktu z XML-em, a zatem nie jest obciążony tego typu uprzedzeniami (szczególnie tym mówiącym, że XML służy do prezentacji). Nie będziemy omawiali dokumentów XML pod kątem ich prezentacji ani przekształcania informacji — raczej pod kątem sposobu zapisu prostych danych. To cha­ra­kte­ry­styczne podejście może na początku wydawać się dziwne, ponieważ większość osób słysząc „XML” wciąż jednak ma na myśli prezentację. Ale jako programiści Javy będziemy traktować do­ku­menty XML jako dane i nic więcej. Większa część tej książki jest poświęcona czynnościom innym niż formatowanie dokumentów XML — ich przetwarzaniu i obróbce. Siła XML-a leży w możliwości przesyłania danych z systemu do sytemu, aplikacji do aplikacji, firmy do firmy. Po­zbycie się błędnych założeń odnośnie XML-a pomoże Czytelnikowi czerpać większą przyjemność z czytania tej książki, a także umożliwi poznanie sposobów zastosowania XML-a, o których być może nawet nie myślał.

40 Rozdział 1. Wprowadzenie

Co dalej? 41

C:\Helion\Java i XML\jAVA I xml\01-08.doc — strona 40

C:\Helion\Java i XML\jAVA I xml\01-08.doc — strona 41

C:\Helion\Java i XML\jAVA I xml\01-08.doc — strona 15

W.D.: platformę

W.D.: frazeologia: od czasu Van De Veldego — „doskonałe”. (tłumacz: oczywiście, powinno być „doskonałe”)

W.D.: wskazuje. (tłumacz: tak)


Wyszukiwarka