C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 15

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 przybli-
ż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 operują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-
temó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-
tokołu aplikacji bezprzewodowych (WAP) czy asystenty osobiste („organizery”) obsługujące
zupeł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 towarzyszy
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, dlacze-
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

16

Rozdział 1. Wprowadzenie

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 16

szczególnie godne uwagi, poświęcimy mu więcej czasu. Będziemy traktować XML jako narzę-
dzie, a nie jako slogan reklamowy czy kolejną „zabawkę”. Pamiętając o tym, spróbujmy odpo-
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-
cyzowano ani zestawu znaczników, ani gramatyki języka. Zestaw znaczników (ang. tag set) w języku
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 znacze-
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 rozbudo-
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
imiona 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>

Co to jest XML?

17

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 17

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 podo-
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
rodzaju ograniczenia, ale na razie wystarczy pamiętać, że XML został stworzony po to, by zapew-
nić elastyczność 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łumaczenie
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 pamię-
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
rozszyfrowania najbardziej popularnych skrótów związanych z XML-em. Skróty te są niezwykle
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 zaleceniach.
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 struk-
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 polecał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. Pierwsza
mówi, że dokument XML, aby był w jakikolwiek sposób przydatny i mógł zostać przetworzony,
musi być poprawnie uformowany. Poprawnie uformowany dokument to taki, w którym każdemu
znacznikowi otwierającemu odpowiada znacznik zamykający, w którym znaczniki nie są zagnież-
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.

18

Rozdział 1. Wprowadzenie

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 18

Powiedzieliśmy, że nie ma reguł gramatycznych. Dany dokument może definiować własne znacz-
niki 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 znacz-
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-
cania 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. Najpierw
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-
twarzania 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 przekazy-
wane parserowi XML lub innemu programowi korzystającemu z dokumentu. W naszym przykł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-
twarzania 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-
winny 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 „zapotrzebo-
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-
kumentu 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ć
skonstruowany dokument XML. Ponownie spójrzmy na przykład 1.1. Choć stworzyliśmy grupę
własnych znaczników, to dokument taki jest bezużyteczny dla innej aplikacji, a nawet dla innego
użytkownika, który nie potrafi zinterpretować naszych znaczników. Powstają wątpliwości — czy

Co to jest XML?

19

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 19

znacznik <ilosc> mówi nam, ile krzeseł jest na stanie? Czy atrybut drewno może zostać użyty
w znaczniku <krzeslo>? Jeśli dokument ma zostać poprawnie przetworzony przez parser, na te
wszystkie 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 zawrzeć ją w samym pliku XML — w każdym razie definicja nie ingeruje w żaden sposób w do-
kument 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 „mahoń”. Dzięki temu parser potrafi określić, czy zawartość dokumentu jest do przyjęcia,
i zapobiec 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
przykładowy plik XML, wie, jak przetworzyć i przeszukiwać otrzymane dane. Definicja DTD nie tylko
przyczynia się do wysokiej elastyczności formatowania danych w XML-u, ale także umożliwia
przetwarzanie i sprawdzanie poprawności danych w dowolnym systemie potrafią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 elementu.
Przestrzeń nazw (ang. namespace) to odwzorowanie pomiędzy przedrostkiem elementu a identyfikato-
rem URI. Odwzorowanie to umożliwia zapobieżenie kolizjom przestrzeni nazw oraz określenie struktur
danych, które pozwalają parserom zapobiec takim kolizjom. Przeanalizujmy przykład kolizji przestrze-
ni nazw. Załóżmy, że w dokumencie pomiędzy znacznikami <krzeslo> i </krzeslo> znajduje
się znacznik <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ównież, ż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. <firma>, ale jak rozpoznać, który znacznik
odwołuje się do czego? Taka dwuznaczność to problem dla parsera XML. Czy znacznik <cena> ma
być interpretowany 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ć danymi 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-

20

Rozdział 1. Wprowadzenie

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 20

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 zdefiniowanie
arkuszy stylów wykonujących to zadanie. Zamiast zmieniać dane pod kątem różnych reprezen-
tacji, rozdzielamy dane (zawartość) od reprezentacji — właśnie za pomocą języka XSL. Jeśli do-
kument 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)
zawartych wewnątrz dokumentu XSL. Obiekty te mają postać specyficznych, nazwanych znaczni-
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-
centrujemy 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. Zagadnie-
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
odpowiadają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>

Co to jest XML?

21

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 21

<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 dalszej części książki, tutaj przyjrzymy się tylko znacznikom <xsl:template
match="[nazwa elementu]">. Każde wystąpienie takiego znacznika powoduje, że odpo-
wiedni element, na przykład akapit, jest zamieniany na zawartość arkusza XSL — w tym wypad-
ku powoduje to wstawienie znacznika <p> i ustawienie pochyłości czcionki. Po transformacji do-
kumentu XML zgodnie z pokazanym arkuszem XSL otrzymujemy taki wynik, jak w przykładzie 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-
starczy, ż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-
nizacji 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 wyko-
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-

22

Rozdział 1. Wprowadzenie

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 22

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 danym
drzewie. Szczegóły związane z XPath zostaną przedstawione dopiero przy dokładniejszym oma-
wianiu XSL i XSLT, ale trzeba pamiętać, że z XPath będziemy korzystali wszędzie tam, gdzie
musimy 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 zespoł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 korzystają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 oczekiwa-
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 zastosowaniom

Co to jest XML?

23

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 23

XML-a. Więcej informacji o tym istotnym projekcie W3C można znaleźć pod adresami http://www.
w3.org/TR/xmlschema-1 oraz http://www.w3.org/TR/xmlschema-2. Ciekawe wprowadzenie 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
rekord 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 zainteresowaniem 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 specy-
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ą wymienione poniżej, wraz z adresami odpowiednich zaleceń lub projektów roboczych:

• Struktura Resource Description Framework (RDF): http://www.w3.org/TR/PR-rdf-schema/
• Język odsyłaczy XML (ang. XML Link Language — XLL):

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

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

• XHTML: http://www.w3.org/TR/xhtml-basic/

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

24

Rozdział 1. Wprowadzenie

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 24

pewno wymaga opanowania zarówno tych technologii, które dokładniej opisujemy, jak i tych
jedynie wspomnianych. Ale i tak może się zdarzyć, że w pewnym miejscu książki Czytelnik
napotka standardy, które nie zostały omówione — wówczas takie zagadnienie zostanie dokładnie
przedstawione.

Jak z tego korzystać?

Wszystkie wspaniałe zalety XML-a nie na wiele się zdadzą, jeśli nie będzie narzędzi umożliwiają-
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 bezpo-
ś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 punktu widzenia aplikacji, cykl działania dokumentu XML dzieli się na dwa etapy (rysunek
1.1): przetwarzanie dokumentu i analizowanie danych w nim zawartych.

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ą

zdarzenia, 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-

mentu 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-

dardowego interfejsu XML. Dokumentacja i inne informacje na temat interfejsu SAX znajdują się

pod adresem http://www.megginson.com/SAX.

Jak z tego korzystać?

25

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 25

Przed przystąpieniem do omawiania kolejnych zagadnień należy koniecznie wyjaśnić pewne niepo-
rozumienie związane z interfejsem SAX. Otóż SAX często jestb uważany za parser XML-a. Nawet
tutaj piszemy, że SAX umożliwia przetwarzanie danych XML. Ale tak naprawdę SAX udostępnia
tylko strukturę dla parserów i definiuje zdarzenia procesu przetwarzania podlegające monitorowa-
niu. Żeby jakiekolwiek przetwarzanie mogło nastąpić, konieczne jest jeszcze zastosowanie zewnę-
trznego 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.
Interfejs 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 mani-
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 przeszukiwaniem 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
poszczególnych części dokumentów — wszystko jest w pamięci dopóty, dopóki istnieje drzewo
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 zade-
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ówno mechanizm serwletów Tomcat, jak i specyfikacja EJB 1.1 wymagają plików konfiguracyj-
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

26

Rozdział 1. Wprowadzenie

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 26

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 udowo-
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 zosta-
nie omówione zastosowanie języka XML we współczesnych aplikacjach. Następnie autor przed-
stawi 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, mechaniz-
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

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
danych, to otrzymujemy całkowitą przenośność informacji. Aplikacja jest przenośna i porozumie-
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, proce-
soró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.

Dlaczego warto korzystać z technologii XML?

27

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 27

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 aplika-
cjach krytycznych, od których zależy funkcjonowanie całej firmy. To mylna opinia. XML i spo-
krewnione 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. Zawartością
(ang. content) nazywamy dane, które mają zostać wyświetlone u klienta, zaś prezentacją (ang. presen-
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. Zasa-
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 konkretnym typem klienta (przeglą-
darką WWW, telefonem z obsługą Internetu, aplikacją Javy) oraz z funkcjami udostępnianymi przez
klienta (HTML 4.0, język WML, Java™ Swing). Za zawartość odpowiedzialny 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 aplika-
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 pozwalają-
cym na korzystanie z aplikacji. Trzy lata temu klienty aplikacji miały niemal zawsze postać przeglą-
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 („organi-
zery”) z obsługą podzbioru HTML-a. Taka różnorodność powoduje, że nieraz tworzy się niezliczo-
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 komó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 przebywa-
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-
dencjami, 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

28

Rozdział 1. Wprowadzenie

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 28

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 odseparowa-
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-
dzania 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ługi-
wane 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 komuni-
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, cokol-
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 odfiltro-
wanie danych zabezpieczonych lub zmianę nazw elementów? Tak naprawdę rzadko mamy do
czynienia z klientem, który nie wymaga jakiegoś konkretnego formatowania danych.

Dlaczego warto korzystać z technologii XML?

29

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 29

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.

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ż reprezenta-
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 elementa-
mi aplikacji albo współdzielonymi usługami działającymi pomiędzy aplikacjami. RPC to skrót
utworzony 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średni-
ctwem „namiastek” metod (ang. stub) i szkieletów ładowanych poprzez sieć. Główna różnica pole-
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

30

Rozdział 1. Wprowadzenie

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 30

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średni-
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
okazuje się dobrym sposobem komunikacji systemów zdalnych. Dzięki standardowi umożliwiają-
cemu 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-
macji o mechanizmie XML-RPC można znaleźć w rozdziale 10., XML-RPC.

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.

Dlaczego warto korzystać z technologii XML?

31

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 31

O ustawieniach routera trzeba poinformować usługodawcę internetowego (ISP). Następnie prze-
prowadzana jest faktyczna instalacja, do wykonania której może zostać wynajęta — np. na zasadzie
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
sobie, że pierwotne zamówienie na założenie łącza zostaje wprowadzone do systemu, który kon-
wertuje je na dokument 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ę infor-
mującą o powodzeniu lub niepowodzeniu instalacji i po przekształceniu (znów za pomocą XSL-a)
dokument jest oddawany do głównej aplikacji u operatora. Elegancja tego rozwiązania polega na
tym, że zamiast kilku systemów firmowych, z których każdy ma swój sposób formatowania, na
każdym etapie wykorzystywany jest ten sam interfejs XML — bez względu na rodzaj aplikacji,
systemu czy firmy.

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

32

Rozdział 1. Wprowadzenie

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 32

XML w konfiguracji

Jeszcze jedno istotne zastosowanie standardu XML w aplikacjach i technologiach związanych z Javą
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 para-
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 zadowole-
niem, ponieważ deskryptory wdrożeniowe nie muszą być już tworzone zgodnie z wymogami
rozwiązań firmowych. Ponieważ deskryptory wdrożeniowe mają być teraz zgodne z wcześniej
zdefiniowaną definicją DTD, wszyscy producenci wykorzystują te same deskryptory. To zaś przy-
czynia się do zwiększenia przenośności kodu EJB.

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-
kowy 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 elementa-
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.

Dlaczego warto korzystać z technologii XML?

33

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 33

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 publika-
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-
wiedzialny 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 uzyski-
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 rozdział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 zazwyczaj
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 zaczyna 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 zasto-
sowanie. 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 posiada-
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:

• Apache Xerces, http://xml.apache.org
• IBM XML4J, http://alphaworks.ibm.com/tech/xml4j
• James Clark's XP, http://www.jclark.com/xml/xp
• OpenXML, http://www.openxml.org
• Oracle XML Parser, http://technet.oracle.com/tech/xml
• Sun Microsystems Project X, http://java.sun.com/products/xml

34

Rozdział 1. Wprowadzenie

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 34

• Tim Bray's Lark and Larval, http://www.textuality.com/Lark
• Grupa W3C poinformowała, że zamierza opublikować parser sprawdzający poprawność na

podstawie schematu. Parser będzie oprogramowaniem typu open source.

Na tej liście celowo nie umieszczono parsera Microsoftu. Wygląda 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
wielu 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ńczonego zalecenia W3C, a więc obsługa konstrukcji i opcji XSL bardzo gwałtownie się roz-
wija. Najlepszym źródłem informacji o danym procesorze jest wymieniona strona WWW — tam
znajdziemy informacje dotyczące zgodności narzędzia ze specyfikacjami, tam też są zamieszczone
testy porównawcze.

• Apache Xalan, http://xml.apache.org
• James Clarks's XT, http://www.jclark.com/xml/xt
• Lotus XSL Processor, http://www.alphaworks.ibm.com/tech/LotusXSL
• Oracle XSL Processor, http://technet.oracle.com/tech/xml
• Keith Visco's XSL:P, http://www.clc-marketing.com/xslp
• Michalel Kay's SAXON, http://users.iclway.co.uk/mhkay/saxon

Struktury publikacji

Struktura publikacji (ang. publishing framework) to termin nieco mglisty, nie stanowiący formal-
nej definicji. Na potrzeby niniejszej książki strukturą publikacji standardu XML nazwiemy zestaw
narzędzi XML wykonujących przetwarzanie, przekształcanie (transformację) oraz dodatkowe
czynności na dokumentach XML w aplikacji. Przetwarzanie i transformacja są zazwyczaj wyko-
nywane za pomocą wspomnianych wyżej narzędzi; struktura publikacji łączy zaś wszystkie te ope-
racje w jedną całość z interfejsem API Javy i zapewnia standardowy interfejs całości. W bardziej
zaawansowanych 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 mechaniz-
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),

Dlaczego warto korzystać z technologii XML?

35

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 35

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.

• Apache Cocoon, http://xml.apache.org
• Enhydra Application Server, http://www.enhydra.org
• Bluestone XML Server, http://www.bluestone.com/xml
• SAXON, http://users.iclway.co.uk/mhkay/saxon

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 Nota-
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://alphaworks.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 wykorzysty-
wany 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
aplikacji 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
sobą 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ć przyszłość
tego śmiesznego języka obiektowego zwanego Javą, przydatnego, owszem, do budowania aple-
tów... Są jednak pewne tendencje w XML-u, które pozwalają domyślić się, jakie zmiany 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-
figuracyjnych. 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).

36

Rozdział 1. Wprowadzenie

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 36

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 wykorzys-
tywane będą zazwyczaj różne definicje DTD i nazwy elementów, to jednak XML umożliwia sfor-
malizowanie i ustandaryzowanie formatowania plików, przyczyniając się do powstania uniwersal-
nego języka konfiguracyjnego. To są naprawdę dobre wiadomości dla administratorów sieci, sys-
temów i dla programistów.

Czytelnik może zauważyć, że pliki konfiguracyjne już omawialiśmy — dlaczego powracamy do
tego tematu? Obecnie każdy serwer posiada lokalny plik (lub pliki) konfiguracyjne. Choć w niektó-
rych serwerach ostatnio umożliwia się także odczytywanie konfiguracji poprzez usługi katalogowe,
to jednak ta metoda przyswajana jest powoli i wymaga znajomości protokołu usług katalogowych,
najczęściej LDAP (Lightweight Directory Access Protocol). Widać coraz silniejszą tendencję
tworzenia repozytoriów XML zawierających konfiguracje (rysunek 1.6). Coraz chętniej korzysta
się również z interfejsu Java Naming and Directory Interface™ dla standardu XML (usługa po-
dobna do udostępniania plików). W takiej sytuacji XML może funkcjonować albo oddzielnie od

Dlaczego warto korzystać z technologii XML?

37

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 37

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 elemen-
tów systemu. Serwery HTTP będą mogły rozpoznawać, jakie mechanizmy serwletów są dostę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 wprowadza-
niem serwerów sieciowych (korzystających ze wspólnego repozytorium XML) w miejsce serwerów
samodzielnych.

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 programowa-
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

38

Rozdział 1. Wprowadzenie

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 38

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.
Przyjrzyjmy 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
strony 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 zapre-
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() {

Co dalej?

39

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 39

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
pewne 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 wprowadzanie
samego XML-a, tak jak strony JSP zachęcały programistów do poznawania Javy i przechodzenia do
bardziej złożonych interfejsów. XSP może także przyczynić się do większego upowszechnienia
XML-a. Więcej informacji o XSP oraz pełny projekt roboczy tego standardu znaleźć można pod
adresem http://xml.apache.org/cocoon/xsp.html.

Co dalej?

Po tym niezwykle szybkim omówieniu technologii XML oraz interfejsów API Javy umożliwiają-
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
sformatowany”.

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 niezrozumie-
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 charakte-
rystyczne 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-
kumenty 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

40

Rozdział 1. Wprowadzenie

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 40

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ł.

Co dalej?

41

C:\WINDOWS\Pulpit\Szymon\Java i XML\01-08.doc — strona 41