Rozprawa doktorska mgr Dariusza Mikułowskiego, pt. Koncepcja i realizacja rozproszonych ontologii w systemie entish

Instytut Podstaw Informatyki Polskiej Akademii Nauk Rozprawa doktorska mgr Dariusza Mikułowskiego, pt. Koncepcja i realizacja rozproszonych ontologii w systemie entish Promotorem rozprawy jest dr hab. Stanisław Ambroszkiewicz Warszawa 2005

Przedmowa Niniejsza rozprawa dotyczy dziedziny wiedzy i technologii związanych z integracją heterogenicznych rozproszonych aplikacji. Oprócz obszernego wprowadzenia do języka XML oraz przedstawienia i omówienia specyfikacji związanych z Web serwisami a także Semantic Web, autor przedstawia system entish zrealizowany w ramach projektu KBN pt. Semantyczna interoperabilność w przestrzeni agentowej jako środek umożliwiający tworzenie dynamicznych organizacji, przedsiębiorstw i elektronicznych rynków. Indywidualnym wkładem autora jest opracowanie i realizacja rozproszonego słownika w ramach systemu entish. Ten rozproszony słownik służy do definiowania pojęć w sposób zrozumiały dla aplikacji. Słownik taki można by nazwać ontologią. Jednak ponieważ termin ontologia ma już swoje specyficzne znaczenie w literaturze, więc ten sposób opisywania i definiowania pojęć został nazwany usługą słownikową (ang. Dictionary Service). Taka usługa słownikowa jest bardzo pomocna przy automatycznej kompozycji aplikacji. Indywidualnym wkładem autora jest również programistyczna realizacja rozproszonego słownika, XML-owa składnia języka Entish, a także implementacja parsera struktur XML, w których wyrażane są formuły i termy języka Entish. Kluczową rolę w automatycznej kompozycji aplikacji odgrywają, tzw. ontologie. Klasyczna definicja ontologii jest następująca. Ontologia jest to formalna specyfikacja konceptualizacji. Czyli w rozumieniu logiki jest to teoria (zbiór aksjomatów) w pewnym formalnym języku. W DAML+OIL oraz OWL przyjmuje się w zasadzie tę definicję ontologii, jednak sposób jej reprezentacji jest specyficzny, ponieważ bazuje na RDF. W rozumieniu autora ontologia, czyli rozproszony słownik, jest uporządkowanym w pewien sposób zbiorem definicji pojęć. Aplikacja nie musi rozumieć tych definicji, ale musi potrafić je przetwarzać i używać. Definicja każdego pojęcia jest unikalna. Zostało to osiągnięte poprzez wprowadzenie podstawowej struktury dla nazwy każdego pojęcia; jest to tzw. concept name. Nazwa pojęcia składa się z dwóch elementów: short name, która jest lokalną nazwą danego pojęcia używaną w celu łatwiejszego przetwarzania oraz long name, która jest długą, unikalną nazwą tego pojęcia. Długa nazwa jest adresem URI miejsca, w którym znajduje się definicja danego pojęcia. To właśnie dzięki wprowadzeniu długich nazw nazwy pojęć są unikalne. Definicja pojęcia może zawierać odniesienia do innych już zdefiniowanych pojęć. Poprzez takie połączenia definicji tworzone są całe drzewa składające się z nazw pojęć. Na liściach takiego 1

2 drzewa znajdują się pojęcia pierwotne, które również są wprowadzane do słownika poprzez definicje, ale oczywiście nie zawierają one już odniesień do innych pojęć. Poprzez zastosowanie tak rozumianego concept name, ontologie mogą być całkowicie rozproszone, ponieważ każda definicja może znajdować się w innym miejscu sieci. Dzięki innemu rozumieniu tego, czym jest ontologia, oraz innej koncepcji języka, przedstawiony przez autora rozproszony słownik stanowi dużo prostszy sposób definiowania pojęć, niż ten proponowany np. w Semantic Web. Jest to możliwe, ponieważ aplikacje nie starają się implementować zrozumienia pojęć, lecz pozostawiają to rozumienie po stronie użytkownika. Muszą one jednak potrafić odszukiwać, używać i przetwarzać definiowane pojęcia. Jest to zasadniczym powodem tego, że rozproszony słownik może mieć mniej skomplikowaną strukturę i być wyrażony w prostszej formie. W projekcie entish możliwe jest automatyczne tworzenie kompozycji Web serwisów. Jest to osiągnięte dzięki możliwości definiowania nowych pojęć w Dictionary Service, językowi opisu usług Entish, oraz specjalnemu protokołowi kompozycji aplikacji.

Spis treści 0 Wstęp 5 1 Podstawowe technologie 11 1.1 Język XML................................ 12 1.2 XML Schema Definition......................... 17 1.3 Podsumowanie............................. 31 2 Bazowy stos technologii realizujący Web serwisy 33 2.1 SOAP (Simple Object Access Protocol)................ 35 2.2 WSDL (Web Services Description Language)............. 40 2.3 UDDI (Universal Description Discovery and Integration)....... 46 2.4 Podsumowanie.............................. 50 3 Technologie realizujące Web serwisy oparte na SOAP i WSDL 51 3.1 Języki opisujące dodatkowe cechy Web serwisów........... 52 3.2 Web Service Choreography Interface.................. 69 3.3 Business Process Execution Language................. 77 3.4 WS-Transaction i WS-Coordination.................. 85 3.5 Web Services Composite Aplication Framework............ 89 3.6 Technologie wieloagentowe........................ 94 3.7 Podsumowanie.............................. 99 4 Semantic Web 101 4.1 Czym są ontologie?............................ 102 4.2 Języki do opisu wiedzy.......................... 104 4.3 Resource Description Framework.................... 104 4.4 DAML+OIL oraz DAML-S....................... 108 4.5 Ontology Web Language......................... 130 4.6 Podsumowanie.............................. 140 5 Koncepcja systemu opartego na języku Entish 143 5.1 Ogólna idea................................ 145 5.2 Konstrukcja i składnia języka Entish.................. 156 5.3 Protokół do automatycznej kompozycji Web serwisów........ 185 5.4 Rozproszony słownik Dictionary Service................ 193 5.5 Przykłady zadań użytkownika...................... 221 5.6 Podsumowanie systemu entish..................... 256 3

4 Spis treści 6 Prototypowa implementacja systemu entish 257 6.1 Architektura systemu.......................... 258 6.2 Parser języka Entish........................... 265 6.3 Implementacja rozproszonego słownika Dictionary Service...... 280 6.4 Podsumowanie implementacji...................... 289 Konkluzje 290 Bibliografia 296 A Schematy XML definiujące język Entish 305 A.1 Dokument definitions.xsd....................... 307 A.2 Schemat formula.xsd.......................... 310 A.3 Schemat info.xsd............................ 312 A.4 Schemat properentish.xml....................... 313 A.5 Schemat message.xsd.......................... 323 A.6 Schemat state.xsd............................ 325 B Schematy XSD dla struktur Dictionary Service 327 B.1 Schemat ontology.xsd.......................... 329 B.2 Schemat registrationinfo.xsd...................... 330 C Klasy i interfejsy parsera języka Entish 331 C.1 Interfejs ieformula............................ 333 C.2 Interfejs ieinfo.............................. 334 C.3 Interfejs iemessage............................ 335 C.4 Interfejs iestate.............................. 337 C.5 Klasa EFormula.............................. 338 C.6 Klasa EFormInOut............................ 346 C.7 Klasa EInfo................................ 347 C.8 Klasa EMessage.............................. 349 C.9 Klasa EState............................... 354 C.10 Klasa EParser............................... 358 D Klasy i interfejsy Dictionary Service 363 D.1 Klasa Definer............................... 365 D.2 Klasa Ontology.............................. 369 D.3 Klasa RegistrationDefiner........................ 372 D.4 Klasa TaskDefiner............................ 374

Rozdział 0 Wstęp W ciągu ostatnich kilkunastu lat, znacznie wzrosła potrzeba używania komputerów w każdej dziedzinie naszego życia. Komputery wraz z różnorodnym oprogramowaniem stały się narzędziem pracy, rozrywki, nauki. Obecnie nie można sobie wyobrazić funkcjonowania jakiejkolwiek instytucji publicznej, urzędu, instytutu naukowego, czy podmiotu gospodarczego, bez działającego w nim systemu informatycznego. Różnorodne technologie informatyczne, a w szczególności te związane z sieciami komputerowymi, pozwalają na integrowanie i współdziałanie firm, które dokonuje się na poziomie ich systemów informatycznych. Nikt już nie wątpi, że integracja wielu aplikacji wewnątrz i pomiędzy przedsiębiorstwami, która ma się odbywać za pośrednictwem Internetu, stała się wyraźną potrzebą. Zapewnienie takiej integracji nie jest jednak łatwe, gdyż wymaga prawidłowego współdziałania wielu programów napisanych w różny sposób, różnie funkcjonujących i umieszczanych na rozmaitych platformach sprzętowo-programowych. Jednym ze sposobów rozwiązania tego problemu jest próba zrealizowania koncepcji tzw. Web serwisów (ang. Web services). Mimo, że intuicyjne zrozumienie pojęcia Web serwis jest mniej więcej jasne, jest ono odmiennie rozumiane przez różnych autorów, dostawców usług i użytkowników. Odpowiedzmy sobie więc na pytanie: Czym są, a raczej czym mają być, te dostępne w Internecie usługi zwane Web serwisami? Web serwisy mają być nową jakością usług internetowych, która pozwoli na utworzenie pomostu łączącego różniące się od siebie aplikacje biznesowe. Web serwisy mają umożliwić bezpieczną ekspozycję logiki biznesowej poza obszar zamkniętych systemów istniejących w firmach. Mają one integrować Web, czyli WWW (ang. World Wide Web) i tradycyjne aplikacje za pomocą całego szeregu komponentów oprogramowania, warstw pośredniczących i protokołów. Taka integracja ma zredukować do minimum koszty wkładane we wdrażanie systemów informatycznych oraz zminimalizować interwencje człowieka. Oprócz możliwości integrowania i porozumiewania się różnych aplikacji, Web serwisy mają pozwolić na bezpieczny przepływ, często bardzo poufnych danych, tworzenie całych procesów biznesowych, realizacje transakcyjnych protokołów takich jak 2PC czy 3PC, a w przyszłości także na negocjacje pomiędzy firmami. Być może najlepszą, a na pewno najbardziej popularną, definicję Web serwisów można znaleźć na portalu IBM (47), (48): Web serwisy są to autonomiczne, samo opisujące się złożone aplikacje, które mogą być opublikowane i umieszczone w sieci. Są one także za jej pomocą udostępniane i uruchamiane. Web serwisy mogą realizować różne operacje, począwszy od prostych odpowiedzi na pytania użytkownika, aż po złożone procesy biznesowe. Po opubliko- 5

6 Rozdział 0. Wstęp waniu Web serwisu w sieci inne aplikacje, a także inne usługi, (także Web serwisy) mogą odkryć i uruchomić opublikowany Web serwis. W projekcie DAML+OIL (29) proponowana jest inna, bardziej zwięzła, ale być może łatwiejsza do zrozumienia, definicja: Web serwisy są to dostępne poprzez Internet (WWW) programy (aplikacje). Nie tylko dostarczają one użytkownikowi wielu różnorodnych informacji, ale także przez swoją funkcjonalność dają mu możliwość spowodowania efektu w świecie rzeczywistym. Jeszcze inną definicję proponuje konsorcjum W3C (97), zajmujące się ustalaniem standardów obowiązujących na WWW. To bardzo wpływowe konsorcjum opublikowało szereg istotnych standardów związanych z Web serwisami jak np. SOAP czy WSDL. Proponuje ono następującą definicje Web serwisu: Web serwis jest aplikacją, która może być dostępna w sieci poprzez swój adres internetowy URI (zgodnie z definicją znajdującą się w dokumencie RFC 2396) (96). Jej interfejsy, a także sposób użycia jest zdefiniowany, opisany i odkrywany za pomocą struktur wyrażonych w języku XML. Aplikacja będąca Web serwisem musi być zdolna do nawiązania poprawnej interakcji z innymi usługami poprzez wysyłanie i odbieranie wiadomości wyrażonych w języku XML i przekazywanych zgodnie z protokołami obowiązującymi w Internecie. Zauważmy, że oprócz zwykłej funkcjonalności, jaką posiada każda aplikacja, Web serwis ma jeszcze jedną ciekawą własność. Może być odkryty, uruchomiony i zintegrowany z innymi usługami poprzez Internet, po to, by stworzyć nową funkcjonalność. Z punktu widzenia dostawcy usług, zainstalowanie aplikacji jako Web serwisu będzie oznaczało, z jednej strony, podłączenie jej funkcjonalności do globalnej wspólnoty. Dzięki temu każdy inny Web serwis, czy też klient, z łatwością skorzysta z możliwości dostarczanych przez tę aplikację. Z drugiej zaś strony inne usługi w internetowej wspólnocie mogą wzbogacić zakres stosowania podłączonej aplikacji. Z punktu widzenia klienta pojawienie się nowego Web serwisu będzie oznaczało możliwość wykonywania innych, być może niemożliwych do tej pory, zadań poprzez przysłowiowe kliknięcie. Web serwisy mają realizować tzw., Service-Oriented Architecture (w skrócie SOA) w globalnym środowisku sieciowym. SOA jest uznanym powszechnie modelem programowania, według którego mają być konstruowane architektury realizujące usługi webowe. Definiuje ona ogólny schemat publikowania, wyszukiwania i uruchamiania Web serwisów przez inne aplikacje. SOA ustala trzy główne komponenty środowiska w jakim funkcjonują usługi: dostarczyciel usług (ang. Service Provider), odbiorca usług (ang. Service Requester), rejestr usług (ang. Service Registry). Dostarczyciel usług posiada serwer, na którym zainstalowane są usługi oraz kontroluje dostęp do nich. Jest także odpowiedzialny za opublikowanie opisu usługi w rejestrze usług.

Odbiorca usług (klient) jest aplikacją działającą w imieniu użytkownika. Pozwala on użytkownikowi na wykonanie zadania poprzez odszukanie i uruchomienie odpowiednich usług. Rejestr usług jest specjalnego rodzaju centralnym repozytorium, które umożliwia z jednej strony publikacje usługi przez jej dostarczyciela, a z drugiej strony odszukanie i użycie usługi przez klienta. Ta podstawowa architektura Web serwisów jest już implementowana na różne sposoby. Jest ona jednak zbyt ogólna, aby sprostać coraz większym wymaganiom stawianym usługom internetowym przez świat biznesu. Web serwisy mają być nie tylko programami, które można odszukać i użyć przy pomocy WWW, ale mają stać się złożonymi aplikacjami realizującymi często bardzo skomplikowane procesy biznesowe. Powinny także działać zgodnie z mechanizmami transakcyjnymi. Dlatego też bardzo intensywnie pracuje się na całym świecie nad uzupełnieniem podstawowej architektury Web serwisów, tak, aby mogła ona spełnić te wymagania. Prace te są prowadzone obecnie przez najważniejsze firmy i grupy badawcze zajmujące się rozwojem technik informatycznych. Są to firmy takie jak IBM, Microsoft, czy HP oraz konsorcja takie jak DARPA, OASIS czy W3C. Istnieje jeszcze wiele innych definicji Web serwisów, a każda z nich zwraca uwagę na nieco inne ich własności. Niewątpliwie Web serwisy stanowią nowy paradygmat w Internecie, wprowadzają nową jakość dostępu do informacji i ich przetwarzania. Są naturalnym etapem rozwoju technologii internetowych, w którym nie chodzi już tylko o sam dostęp do informacji, ale także o tworzenie całych procesów produkcyjnousługowych. Trzeba podkreślić, że takie procesy biznesowe, nie odbywają się tylko w świecie wirtualnym. Powodują one również widoczne efekty w świecie rzeczywistym. Najbardziej trafne, może nieco frywolne, ale w pełni oddające istotę rzeczy, polskie tłumaczenie terminu Web Services pochodzi od Prof. Mariana Srebrnego; jest to Łebskie Usługi. Niektórzy nazywają je także usługami webowymi. Wszystkie niemal ośrodki akademickie, konsorcja ustalające ogólnoświatowe standardy w dziedzinie Internetu, a także firmy komercyjne zgadzają się z tym, że dobrą podstawą dla budowania architektur realizujących pomysł Web serwisów jest język XML. Ponieważ XML stanowi podstawę proponowanej w tej pracy systemu do kompozycji Web serwisów, dlatego też zostanie on przybliżony w pierwszym rozdziale pracy. W następnych rozdziałach będą przedstawione technologie realizujące podstawową architekturę Web serwisów SOA. Są nimi SOAP+WSDL+UDDI, które zostały zaproponowane przez firmy IBM i Microsoft, a przyjęte przez konsorcjum W3C jako propozycje standartów. Spełnienie wymagań, jakie stawia świat biznesu przed Web serwisami nie jest rzeczą łatwą. Próbują temu sprostać różne grupy badawcze i firmy rozwijające oprogramowanie. Trzeba powiedzieć, że udaje się im to tylko częściowo, mimo, że tworzone przez nie rozwiązania technologiczne są bardzo złożone. W kolejnym rozdziale zostaną przedstawione próby rozwiązań problemu integracji i kompozycji Web serwisów, dla których podstawą są WSDL, SOAP i UDDI. Są nimi inicjatywy takie jak: BPEL4WS, WS-Choreography, WS-Transaction + WS-Coordination, i inne. Wy- 7

8 Rozdział 0. Wstęp mienione wyżej rozwiązania dostarczają sposobów na uruchamianie i współdziałanie wielu Web serwisów oraz konstruowanie przy ich pomocy tzw. procesów biznesowych. Nie odbywa się to jednak w sposób automatyczny. Aby zintegrować grupę istniejących usług, programiści muszą zaprojektować i zaimplementować proces biznesowy, który będą one realizowały. Tak więc wymagania dotyczące redukcji kosztów, automatycznego komponowania usług, a także zmniejszenia wysiłku człowieka, nie są jeszcze w dostateczny sposób spełnione. Inną, poważną inicjatywą dotyczącą Web serwisów, jest projekt DAML+OIL (29). Jest on związany z pomysłem tzw. Semantic Web. Został on zaproponowany przez Timothy Berners-Lee (twórcę WWW) i jest rozwijany przez grupę badawczą związaną z amerykańską organizacją DARPA (ang. Defense Advanced Research Projects Agency). Proponowane w tym projekcie rozwiązanie opiera się na pomyśle, aby aplikacja (także Web serwis) potrafiła zrozumieć informacje, które są publikowane na stronach internetowych. To pozwoli jej na lepsze dostosowanie się do wymagań użytkownika oraz zintegrowanie się z innymi aplikacjami w celu stworzenia całego procesu biznesowego. W projekcie tym zaproponowany został sposób opisywania oraz definiowania pojęć, który jest czytelny dla aplikacji. Są nim tzw. Ontologie, czyli specjalnego rodzaju rozproszone słowniki. Ontologie są także używane do opisywania Web serwisów. Pozwalają one również na tworzenie kompozycji Web serwisów, czyli procesów biznesowych. Podobnie, jak wymienione wcześniej technologie jest to rozwiązanie bardzo rozbudowane co wiąże się z trudnościami realnego wprowadzenia go do użytku. Ta inicjatywa zostanie przedstawiona w trzecim rozdziale. Proponowany w następnych rozdziałach system do integracji Web serwisów jest rozwiązaniem dużo prostszym od wyżej wymienionych. Składa się on z języka opisu Web serwisów, protokołu oraz specjalnego, rozproszonego słownika, który pozwala na podłączanie aplikacji jako Web serwisów. W naszym podejściu możliwe jest automatyczne tworzenie kompozycji Web serwisów, które jest zapewnione dzięki ontologiom zdefiniowanym w słowniku pojęć oraz specjalnemu protokołowi. Ponadto proponowany tu słownik jest dużo prostszym opisem pojęć od tego, który jest oferowany w projekcie DAML+OIL. W naszej propozycji słownik zawiera definicje pojęć używanych wyłącznie do realizacji architektury Web serwisów. Może mieć on więc mniej skomplikowaną strukturę i być wyrażony w prostszym języku.

9 Podziękowania Niniejsza praca została napisana w ramach projektu KBN nr. 7T11C04020 pt. Semantyczna interoperabilność w przestrzeni agentowej jako środek umożliwiający tworzenie dynamicznych organizacji, przedsiębiorstw i elektronicznych rynków. Projekt ten był realizowany w Instytucie Informatyki Akademii Podlaskiej w Siedlcach oraz Instytucie Podstaw Informatyki PAN w Warszawie. Niniejsza praca jest jednocześnie rozprawą doktorską mgr Dariusza Mikułowskiego napisaną pod kierunkiem dr hab. Stanisława Ambroszkiewicza. Do jej powstania przyczyniło się wiele osób, które uczestniczyły w dyskusjach i przedsięwzięciach realizowanych w ramach projektu oraz udzielały cennych wskazówek dotyczących zawartości samej pracy. W związku z tym autor chciałby podziękować następującym osobom: Prof. Lesławowi Szczerbie: za skierowanie jego zainteresowań w stronę informatyki i nauki w ogóle. dr hab. Stanisławowi Ambroszkiewiczowi: za wiele poświęconego czasu, wspólne dyskusje nad problemami poruszonymi w pracy, a także za wytrwałe wskazywanie merytorycznych i technicznych błędów oraz pomoc przy ich poprawianiu. Prof. Andrzejowi Barczakowi: za popieranie wszelkich działań związanych z realizacją projektu oraz za cenne uwagi dotyczące treści pracy. Leszkowi Rozwadowskiemu, Tomaszowi Nowakowi, Krzysztofowi Miodkowi: za wspólne, długie i burzliwe dyskusje, które pozwoliły na wykrystalizowanie się nowych idei i rozwiązań prezentowanych w tej pracy. Dariuszowi Pawluczukowi, Michałowi Całce, Piotrowi Izdebskiemu: za ich konstruktywną krytykę oraz cenne uwagi, które były bardzo przydatne przy dokonywaniu poprawek rozwiązań proponowanych w tej pracy. Żonie Joannie: za pomoc w dokonywaniu licznych poprawek oraz za cierpliwość okazaną podczas powstawania tej pracy.

10 Rozdział 0. Wstęp

Rozdział 1 Podstawowe technologie 1.1 Język XML..................................... 12 1.2 XML Schema Definition.............................. 17 1.3 Podsumowanie.................................. 31 11

12 Rozdział 1. Podstawowe technologie Powstanie Internetu a później, opartego na pomyśle Timothy Berners-Lee, WWW spowodowało bardzo szybki i dynamiczny rozwój wielu technologii informatycznych. Wśród nich zaczęły powstawać także różne języki hypertekstowe i protokoły służące do publikowania informacji na stronach internetowych. Najważniejszymi technologiami związanymi z WWW stały się: język HTML, jako sposób na publikowanie dokumentów oraz protokół HTTP, używany do ich przesyłania. W miarę rozwoju WWW, HTML stał się niewystarczający. Powstał więc język XML, który jest znacznie bardziej elastyczny. Nadawał się on dużo lepiej niż HTML do różnorodnych zastosowań. Do dzisiaj jest podstawową technologią stosowaną we wszystkich aplikacjach internetowych, a także w rozwijających się właśnie Web serwisach. Ponieważ XML oraz inne rozszerzające go języki, są podstawowymi technologiami, które posłużyły do rozwoju całej idei Web serwisów, w tym rozdziale przedstawimy je nieco bliżej. 1.1 Język XML Extensible Markup Language (w skrócie XML) jest uniwersalnym, hypertekstowym językiem służącym do tworzenia struktur danych. Dzięki dużej elastyczności, a także innym własnościom, jest on łatwiejszy w użyciu i znacznie bardziej uniwersalny niż języki, z których się wywodzi, a mianowicie HTML i SGML (87). XML pozwala na transfer zestrukturalizowanych danych za pomocą powszechnie używanych protokołów sieciowych, takich jak HTTP czy SMTP. Dzięki swojej uniwersalności, a także takim własnościom jak rozszerzalność, czy użycie tzw. przestrzeni nazw (ang. namespaces), stał się już powszechnym standardem będącym podstawą do realizacji wielu internetowych technologii, w tym także idei Web serwisów. Z punktu widzenia jego zastosowania, XML może być widziany jako zbiór reguł służących do definiowania elementów (tagów), które dzielą dokument na części. Tworzą w ten sposób zhierarchizowaną strukturę. Zdefiniowane elementy pozwalają zidentyfikować poszczególne fragmenty dokumentu. XML jest jednak czymś więcej niż tylko językiem do tworzenia dokumentów. Często jest on używany także jako metajęzyk definiujący składnię innych hypertekstowych języków, które są specyficzne dla różnych dziedzin zastosowań. Zasadniczą rzeczą, jaka różni XML od innych tego typu języków, takich jak HTML czy SGML, jest to, że nie definiuje on skończonego zbioru tagów, które opisują skończony zbiór elementów. Dla użytkownika oznacza to możliwość samodzielnego dodawania do języka nowych elementów. W przypadku XML daje to możność definiowania własnych tagów. Własność ta jest nazywana rozszerzalnością (ang. extensibility). Dużym utrudnieniem przy stosowaniu zamkniętego języka takiego jak np. HTML, było to, że jeśli użytkownik nie znalazł w nim potrzebnego dla siebie w danej chwili tagu mógł co najwyżej oczekiwać na kolejną wersję języka, w której być może znajdzie rozwiązanie swojego problemu. Przy stosowaniu XML taka trudność nie występuje, ponieważ opiera się on na idei, która stanowi, że użytkownik sam de-

1.1. Język XML 13 finiuje tagi, ich strukturę i atrybuty w zależności od tego, jakie aktualnie ma w tym względzie potrzeby. Specyfikacja XML dostarcza jedynie ogólnych zasad mówiących w jaki sposób takie tagi powinny być umieszczane w dokumencie. Użytkownik ma całkowitą swobodę w określeniu ich znaczenia i uporządkowania. Nie jest on zobligowany do tego by swoje dane umieszczać w ściśle określonych paragrafach, listach, tabelach itp., ale może samodzielnie zaprojektować nazwy tagów oraz ich rozmieszczenie tak, by jak najlepiej odpowiadało to strukturom jego danych. Wprowadzane przez użytkownika tagi mogą być definiowane w specjalnym fragmencie dokumentu, lub w zewnętrznym dokumencie zwanym DTD. DTD (ang. Document Type Definition) jest zbiorem deklaracji, który definiuje to, jakie struktury danych będą umieszczane we właściwym dokumencie XML. Może być on rozumiany jako słownik zawierający nazwy tagów oraz definiujący ich strukturę. Raz stworzony dokument DTD może być używany do tworzenia wielu dokumentów XML. Za jego pomocą można zdefiniować specyficzne języki (rozszerzające XML) takie jak np. MusicML, MathML (60), czy CML (25). Aplikacja, która potrafi zinterpretować dokument DTD definiujący taki język, może używać dokumentów XML stworzonych zgodnie z definicją zawartą w tym DTD. Dowolność w definiowaniu tagów, ich atrybutów i struktury, powoduje, że przeglądarka często nie wie, w jaki sposób wyświetlać dokument XML. Problem ten został rozwiązany poprzez wprowadzenie tzw. arkuszy stylów XSL. Są to specjalne zbiory, dołączane do właściwego dokumentu XML, które zawierają szczegółową instrukcję tego, w jaki sposób przeglądarka powinna wyświetlać zawartość poszczególnych tagów. Mimo że XML nie jest łatwy w czytaniu i pisaniu dla człowieka, może być dobrym sposobem na przesyłanie skomplikowanych struktur danych pomiędzy różnorodnymi aplikacjami. Dzięki temu każda aplikacja potrafiąca posługiwać się XML może bez przeszkód przetwarzać dane pochodzące od innej aplikacji. Użytkownik języka XML może także używać różnych narzędzi do różnych celów np. osobnego narzędzia do przeglądania, a innego do edycji danych. Prosty przykład dokumentu XML zawierającego dane może być następujący: Przykład 1.1 <?xml version="1.0"?> <PERSON ID="p1100" SEX="M"> <NAME> <GIVEN> Jan </GIVEN> <SURNAME> Kowalski </SURNAME> </NAME> <BIRTH> <DATE> 21 Feb 1834 </DATE> <PLACE> Siedlce </PLACE> </BIRTH> <DEATH>

14 Rozdział 1. Podstawowe technologie <DATE> 9 Dec 1905 </DATE> <PLACE> Wladywostok </PLACE> </DEATH> </PERSON> Użytkownik, nie zorientowany w XML, który potrafi porozumiewać się w języku angielskim, może bez problemu stwierdzić, że powyższy dokument opisuje mężczyznę o imieniu i nazwisku Jan Kowalski, który urodził się w Siedlcach, 21 lutego 1834 roku, a zmarł we Władywostoku, 9 grudnia 1905. Po pewnym czasie użytkownik języka XML może mieć potrzebę użycia tagów, które zostały zdefiniowane przez innego użytkownika. W takim przypadku może napotkać na problem powtarzających się nazw tagów, które dla różnych użytkowników oznaczają co innego. Nazwa <title> może na przykład dla jednego użytkownika oznaczać tytuł książki, natomiast dla innego tytuł naukowy pewnej osoby. Problem ten został rozwiązany w XML poprzez wprowadzenie tzw. przestrzeni nazw (ang. namespaces) (63). Działanie takiej przestrzeni nazw polega na powiązaniu pewnego zbioru nazw tagów (używanego w dokumencie XML) z unikalnym adresem internetowym URI, poprzez dodanie do każdego elementu z tego zbioru odpowiedniego przedrostka. Przedrostek mówi o tym, do którego zbioru (przestrzeni nazw) należy wskazany element. Można więc w jednym dokumencie używać tagów i atrybutów pochodzących z wielu różnych przestrzeni nazw, a mających często identyczne nazwy. Wprowadzenie do dokumentu elementu pochodzącego z nowej, nie używanej dotąd, przestrzeni nazw dokonuje się w dwóch krokach. Pierwszy krok polega na poprzedzeniu nazwy nowego elementu odpowiednim przedrostkiem. Drugim krokiem jest zadeklarowanie tej przestrzeni nazw poprzez dodanie do tego elementu atrybutu xmlns, którego wartością jest adres przestrzeni nazw z jakiej pochodzi użyty element. Od tej chwili wszystkie inne elementy poprzedzone danym przedrostkiem są przypisane do zadeklarowanej przestrzeni nazw. Aby lepiej przedstawić użycie przestrzeni nazw posłużymy się przykładem: Przykład 1.2 <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <m:getendorsingboarder xmlns:m="http://namespaces.snowboard-info.com"> <manufacturer>k2</manufacturer> <model>fatbob</model> </m:getendorsingboarder> </SOAP-ENV:Body>

1.1. Język XML 15 </SOAP-ENV:Envelope> W powyższym fragmencie dokumentu użyte zostały elementy pochodzące z dwóch przestrzeni nazw, a mianowicie SOAP-ENV oraz m. Każda z nich została zadeklarowana przy okazji pierwszego pojawienia się elementu pochodzącego z tej przestrzeni. Deklaracja takiej przestrzeni nazw polega na wprowadzeniu atrybutu xmlns:soap-env w przypadku elementu pochodzącego z przestrzeni SOAP-ENV oraz atrybutu xmlns:m w przypadku elementu pochodzącego z przestrzeni m. Wartościami tych atrybutów są adresy deklarowanych przestrzeni nazw. Pierwsze użycie elementu <Envelope> pochodzącego z przestrzeni nazw SOAP-ENV ma następującą postać: <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"> W przykładowym dokumencie zostały użyte dwa elementy pochodzące z przestrzeni nazw SOAP-ENV, a mianowicie <Envelope> oraz <Body>, który jest poprzedzony tylko przedrostkiem. Są także trzy elementy pochodzące z przestrzeni nazw m. Są to tagi <GetEndorsingBoarder>, <manufacturer>, oraz <model>. Trzeba tu zauważyć, że elementy <manufacturer> i <model> nie zostały poprzedzone przedrostkami określającymi ich przynależność do przestrzeni nazw. Stało się tak, ponieważ znajdują się one wewnątrz tagu <GetEndorsingBoarder>, który został zadeklarowany jako element należący do przestrzeni nazw m. Elementy znajdujące się w jego wnętrzu należą do tej samej co on przestrzeni nazw i dlatego nie trzeba ich poprzedzać żadnym przedrostkiem. Jak już zostało powiedziane, XML często jest używany do budowania specyficznych języków dla różnych zastosowań. Proces budowania takiego języka jest dosyć prosty. Najpierw tworzone są dokumenty DTD definiujące zbiór używanych tagów, ich atrybuty i wzajemne powiązania. Następnie dokumenty DTD są umieszczane w miejscu dostępnym na WWW. Od tej pory, każdy może użyć tych nowych tagów w swoim dokumencie, pod warunkiem, że zadeklaruje odpowiedni typ dokumentu. Deklaracja typu dokumentu wskazuje na nazwę głównego elementu dokumentu, a także na adres pod jakim dostępne są dokumenty DTD definiujące nowy język. Każdy dokument XML używający nowych tagów, jest poddawany procesowi sprawdzania zgodności (ang. validation) z dokumentem DTD, w którym te tagi zostały zdefiniowane. Jeżeli struktura dokumentu XML odpowiada ograniczeniom zdefiniowanym w DTD, to dokument jest uznawany za poprawny. W przeciwnym przypadku, dokument jest uznawany za błędny. DTD pozwala na zdefiniowanie listy elementów i ich atrybutów, które mają się znajdować we właściwym dokumencie, a także określa pewne bardzo ogólne relacje, jakie mają zachodzić pomiędzy nimi. Jest on zbiorem reguł definiujących strukturę właściwego dokumentu. Mogą być to reguły mówiące na przykład, że główny tag dokumentu o nazwie <KSIAZKA> może mieć w swoim wnętrzu jeden lub więcej tag

16 Rozdział 1. Podstawowe technologie <Autor>, dokładnie jeden tag <Tytul>, zero lub więcej tagów <Podtytul> oraz dokładnie jeden tag <ISBN>. Oprócz tego, dokument DTD może zawierać deklaracje atrybutów oraz odniesień, które będą używane w podstawowym dokumencie XML. Prosty dokument DTD, opisujący powyższy przykład, może być następujący: Przykład 1.3 <?xml version="1.0"?> <!DOCTYPE KSIAZKA[ <!ELEMENT KSIAZKA ( Autor+, Tytul, Podtytul*, ISBN )> <!ELEMENT Autor ( #PCDATA )> <!ELEMENT Tytul ( #PCDATA )> <!ELEMENT podtytul ( #PCDATA )> <!ELEMENT ISBN ( #PCDATA )> ]> Pierwsza linia dokumentu jest deklaracją wersji XML. W drugiej linii znajduje się deklaracja <!DOCTYPE>. Jest to deklaracja typu dokumentu. Wskazuje ona na to, że jest to dokument DTD. Atrybutem elementu <!DOCTYPE> jest nazwa typu dokumentu, KSIAZKA, do którego odwołania będą umieszczane we właściwych dokumentach XML. W nawiasach kwadratowych następujących po deklaracji <!DOCTYPE> umieszczane są deklaracje wszystkich elementów, atrybutów i odniesień, jakie mają wystąpić we właściwym dokumencie XML. W tym przypadku, w nawiasach kwadratowych, jako pierwsza została umieszczona deklaracja głównego elementu dokumentu, który ma nazywać się <KSIAZKA>. W nawiasach następujących po nazwie deklarowanego elementu są wymienione wszystkie pod-elementy, jakie mają być w nim umieszczone. Po nazwie pod-elementu umieszcza się znaki takie jak: +, *,? mówiące o ilości jego wystąpień we właściwym dokumencie. I tak po nazwie pod-elementu Autor umieszczony został znak +, mówiący o tym, że książka może mieć jeden lub więcej autorów, a po elemencie Podtytul znak * mówiący o tym, że książka może mieć zero lub więcej podtytułów. W kolejnych liniach dokumentu DTD znajdują się deklaracje wszystkich pod-elementów. Pod-elementy te mają zawierać dane tekstowe, co określa się przy pomocy słowa #PCDATA umieszczanego w nawiasie znajdującym się po nazwie danego elementu. Dokument DTD został zapisany w pliku o nazwie ksiazka.dtd. Właściwy dokument XML, zgodny z taką definicją, będzie miał następującą postać: Przykład 1.4 <?xml version="1.0"?> <!DOCTYPE KSIAZKA SYSTEM "Ksiazka.dtd"> <!-- Dokument XML zawierający informacje o książce --> <KSIAZKA> <Autor>Henryk Sienkiewicz</Autor>

1.2. XML Schema Definition 17 <Tytul>Ogniem i Mieczem</Tytul> <ISBN>83-88556-02-9</ISBN> </KSIAZKA> Pierwsza linia dokumentu jest deklaracją wersji XML. Kolejna zawiera deklarację typu dokumentu, w której wskazywany jest plik, w jakim znajduje się DTD definiujący jego strukturę. Ponieważ wskazanie na nazwę DTD ma charakter lokalny, zostało ono poprzedzone słowem SYSTEM. Zamiast tego, można tam umieścić pełen adres URI. Po deklaracji typu dokumentu umieszczony został komentarz w języku naturalnym, który jest przeznaczony dla człowieka czytającego dokument. Komentarz taki nie będzie interpretowany przez aplikację, która przetwarza dokument. Trzeba tu zauważyć, że komentarz taki jest umieszczony wewnątrz specjalnie przeznaczonego do tego tagu, a mianowicie <!-- -->. Komentarze można umieszczać w dowolnym miejscu, istnieje tylko takie wymaganie, aby nie znajdował się on poza głównym elementem dokumentu. W dalszej kolejności umieszczony jest główny element <KSIAZKA>, którego struktura i zawartość jest zgodna z dokumentem DTD. Jak już wspomnieliśmy, XML jest językiem, który pozwala na wyrażanie w nim różnorodnych struktur danych. Nie zawiera on jednak wbudowanych sposobów na wyświetlanie i wizualne ich przedstawianie. Jest to realizowane poprzez dołączanie do właściwych dokumentów XML specjalnych arkuszy stylów. Takie arkusze stylów, podobnie jak miało to miejsce w HTML, zawierają reguły mówiące o tym, w jaki sposób przeglądarka odczytująca dokument powinna wyświetlić go użytkownikowi. 1.2 XML Schema Definition Sposób definiowania struktur XML, jaki oferował DTD okazał się być niewystarczający do tworzenia bardziej skomplikowanych języków. DTD nie posiada na przykład możliwości definiowania ograniczeń nakładanych na dane, a także własnych typów danych wbudowanych w język. Dlatego powstał nowy język do tworzenia schematów opisujących struktury danych w dokumentach XML. Został on nazwany XML Schema Definition (w skrócie XSD) (121). XSD jest, alternatywnym w stosunku do DTD, sposobem na tworzenie języków rozszerzających XML. Służy on do tworzenia tzw. schematów, które ograniczają i definiują zawartość właściwych dokumentów XML i pozwalają na rozszerzanie umieszczanych w nich informacji. Takie rozszerzanie nie może być całkowicie dowolne. Musi być ono zgodne z pewnymi ustalonymi regułami. Reguły takie są wyznaczane właśnie przez schemat XSD. XSD jest stworzony do budowania schematów dla zestrukturalizowanych danych. Posiada on możliwość tworzenia nowych, bardziej złożonych, typów danych poprzez rozszerzanie lub ograniczanie wcześniej zdefiniowanych. Za jego pomocą można two-

18 Rozdział 1. Podstawowe technologie rzyć definicje elementów o unikalnych nazwach oraz definiować elementy zastępowalne czyli mające różne nazwy, ale taką samą strukturę: np. książkę można zastąpić w niektórych przypadkach publikacją. Podobnie jak wszystkie inne rozszerzenia XML, XSD jest wprowadzany do języka poprzez użycie odpowiedniej przestrzeni nazw (63). Schemat XSD definiuje strukturę właściwego dokumentu XML, a więc służy do definiowania tagów, atrybutów oraz ich wzajemnego powiązania. Schemat XSD zawiera dwa rodzaje komponentów. Są to definicje typów oraz deklaracje elementów. Są one używane do określenia struktury, jaką ma posiadać dokument XML, będący instancją tego schematu. XSD pozwala także na nakładanie różnorodnych ograniczeń na wartości atrybutów oraz na tekstową zawartość elementów właściwego dokumentu. Dzięki tej własności można dosyć precyzyjnie określić, jaki format danych ma być umieszczony wewnątrz każdego tagu. Przypuśćmy na przykład, że chcemy zdefiniować prosty element o nazwie protocolversion. Ma on zawierać dwie liczby dziesiętne oddzielone kropką. Pierwsza z nich ma składać się z jednej cyfry, a druga z dwóch. Taki element może być zdefiniowany za pomocą następującego fragmentu schematu XSD: Przykład 1.5 <xsd:element name="protocolversion"> <xsd:simpletype> <xsd:restriction base="xsd:string"> <xsd:pattern value="\d{1}.\d{2}"/> </xsd:restriction> </xsd:simpletype> </xsd:element> Użycie elementu <xsd:restriction> oznacza, że dane, które mają być zawarte w definiowanym elemencie są ciągiem znaków (są typu xsd:string). Następujący po nim element <xsd:pattern> służy do precyzyjnego podania wzorca, jaki mają spełniać dane wprowadzane w definiowanym elemencie. Przykładowy fragment dokumentu XML, będący instancją powyższego schematu może być następujący: Przykład 1.6 <protocolversion>1.01</protocolversion> Struktury danych, zaprojektowane przez użytkownika, można definiować w XSD na dwa sposoby: Poprzez zadeklarowanie elementu (tagu) i tego, jakie elementy mogą wystąpić wewnątrz niego, a także jakie atrybuty musi on posiadać. Aby użyć tego elementu w dalszej części schematu, trzeba podać jego nazwę tak, jak została