Miało być łatwiej, wyszło jak zwykle

XML przeszedł poważną ewolucję. Z prostego formatu do zapisu danych stał się dziś językiem programowania o niezliczonych odcieniach i zastosowaniach. Czy jednak XML uprościł projektowanie, tworzenie albo wdrażanie aplikacji?

XML przeszedł poważną ewolucję. Z prostego formatu do zapisu danych stał się dziś językiem programowania o niezliczonych odcieniach i zastosowaniach. Czy jednak XML uprościł projektowanie, tworzenie albo wdrażanie aplikacji?

Nad rolą XML jako uniwersalnego formatu zapisu danych nikt dziś już nie dyskutuje. To, że struktura dokumentu XML jest jawna nie oznacza jednak, że jest prosta czy łatwa do zrozumienia. Rola XML przestała się ograniczać jedynie do opisu danych. Coraz częściej struktura XML de facto "steruje" określonymi działaniami w aplikacji lub większym systemie jako usługa Web, komponent SOA, a nawet bardziej bezpośrednio - jako "format wykonywalny". Ten ostatni kierunek rozwoju XML może stworzyć zupełnie nowy nurt technologiczny, nie wolny od pułapek związanych z bezpieczeństwem, ale potencjalnie bardzo użyteczny.

Kilka lat zmienia wszystko

Warto pokrótce przypomnieć kilka zwrotów w historii formatów komunikacyjnych opartych na XML - czyli takich, gdzie protokołem HTTP przesyłamy jakiś dokument XML wywołujący określoną funkcjonalność, czyli tzw. usług Web. Na początku (rok 1998) nie był dostępny żaden system typów czy ogólnie - opisu struktury dokumentu XML - poza bardzo ograniczonym DTD. Dopiero Microsoft opracował "pierwszy" SOAP pozwalający przekazywać tzw. typy proste (liczby, łańcuchy itp.) oraz tablice i struktury. Ale początkowo pojemnik, w jakim te dane mają być zapisane, nie był jeszcze ściśle określony. Najpierw miał być to jakiś format binarny (ASN.1 BER, NDR, XDR, CDR, JRMP) i normalny protokół RPC - ze świata CORBA (GIOP/IIOP) albo Windows (DCE/DCOM) czy Java (RMI). Dla lepszego zrozumienia ewolucji XML warto przeczytać artykuł Dona Boxa, który ówcześnie zajmował się tym tematem ( webservices.xml.com/pub//a/ws/2001/04/04/soap.html ).

Miało być łatwiej, wyszło jak zwykle
SOAP nie był naówczas formatem publicznym, a raczej wewnętrznym projektem zespołu Microsoft zajmującym się technologią COM. XML stał się domyślnym pojemnikiem dopiero po połączeniu tego projektu z innym rozwiązaniem o nazwie XML-Data. W 1999 r. format został opublikowany przez Microsoft jako SOAP 1.0 i przez chwilę (z uwagi na brak zgody wśród "wielkich graczy", a zwłaszcza Suna) wydawało się, że nic z tego pomysłu nie wyjdzie. SOAP od końca 1999 r. bazował już na referencjach i całej koncepcji zawartej w systemie typów W3C XML Schema.

SOAP 1.1 z 2000 r. to już wspólne dzieło IBM i Microsoftu. Jego specyfikacja została przekazana do W3C. Tak zaczęła się historia usług Web, i choć szybko okazało się, że początkowy "prosty protokół komunikacyjny" nie był zbyt prosty w praktyce, Web Services zajęli się wszyscy. Jednym z ważniejszych problemów dalszego rozwoju XML stała się potrzeba opisania warstwy metadanych, by usługa mogła "przedstawić się" i określić, jak ją wywołać (czyli jak sformatować komunikat SOAP). Tak powstał WSDL - język opisu usług.

WSDL jest daleki od perfekcji, ale jako specyfikacja namaszczona na standard spełnia swoje zadania. Największym mankamentem WSDL jest to, że częściowo powiela on "rolę" W3C Schema. Do tego istnieją struktury niekompatybilne pomiędzy tymi standardami. Pomimo faktu, że większość technologii XML wykorzystuje XML Schema, to w momencie przekazywania danych za pośrednictwem usługi Web i tak trzeba się ograniczyć do tego, co jest możliwe w WSDL.

Później pojawiła się próba stworzenia wyższej warstwy abstrakcji - rejestrów usług UDDI, które miały ułatwiać wyszukiwanie usług spełniających określone wymagania.

UDDI wywodzi się z opracowanych przez HP koncepcji e-speak, ale ani ona, ani pierwsza koncepcja UDDI nie zyskały uznania. Obecnie UDDI "powraca" na fali zainteresowania architekturami SOA, choć w nieco innej postaci.

Koniec prostoty i nowe problemy

Założenie, że protokołem HTTP przesyłamy żądania do systemów IT, które powodują automatyczne uruchamianie procesów, wymaga odpowiednich zabezpieczeń. HTTPS zapewnia bezpieczeństwo, ale jedynie samemu kanałowi transmisji. Dopiero w 2002 r. powstał pierwszy zarys standardu WS-Security opisującego mechanizm pozwalający zabezpieczyć treść komunikatu w taki sposób, by tylko docelowy serwer był w stanie ją odkodować.

Inny standard - WS-Policy pozwala definiować wymagania i zasady współpracy usług, zaś standard WS-Attachments określa sposoby przekazywania danych binarnych. W konsekwencji prosta idea, w miarę wzrostu liczby zastosowań, obrastała (i nie przestaje obrastać) w coraz bardziej wyrafinowane mechanizmy. W oczywisty sposób przekłada się to na wzrost komplikacji samego strumienia danych wymienianego przez współpracujące ze sobą usługi.

Na początku rewolucji XML technologia ta była lansowana jako prosta i zrozumiała dla człowieka, co, na marginesie, dało początek zupełnie nowej generacji aplikacji narzędziowych. Okazało się wszakże, że trudno jest wykorzystać takie "czyste" usługi Web do czegoś więcej niż testowe odpytywanie serwisów pogodowych (ulubiony przykład na większości prezentacji Web Services na przełomie wieków), czy (bardziej ogólnie) przekazywanie jakichś poleceń do systemu biznesowego na zasadzie RPC.

Te czasy szybko minęły i dziś bez specjalistycznego parsera nie da się nic zrozumieć z transmitowanej informacji. SOAP to jednak wciąż nie binarne wywołania RPC i próba użycia tej technologii w taki sposób, jak np. RMI czy CORBA, prowadzi do katastrofy. Pojawia się konieczność pilnowania sesji, narzut komunikacyjny itp. - szkoda czasu.

Aby wykorzystać możliwości tkwiące w XML, trzeba było zmienić sposób myślenia o architekturze systemów IT. Stąd obecnie mówi się nie tyle o usługach Web, ile o architekturze zgodnej (czyli opartej na SOA - Service Oriented Architecture). W SOA aplikacja udostępnia swoją funkcjonalność w formie komponentów realizujących określone zadania biznesowe (zgodnie z zadanym kontraktem), a elementem "spinającym" jest pewna warstwa integracyjna. Dopiero ona stanowi de facto aplikację w tradycyjnym rozumieniu. To otwiera nowe pole do standaryzowania, chociażby tego, w jaki sposób można zapisać dany kontrakt obejmujący pewien aspekt działalności biznesowej, albo jak zarządzać taką aplikacją. Ostatnio toczą się prace nad specjalnym standardem języka SDL (Service Definition Language).

Substytut integracyjny

Patrząc bardziej ogólnie, XML (pośrednio dzięki usługom Web) stał się językiem, który powoduje wykonanie określonych czynności - jak "normalny" język programowania kompilowany czy interpretowany. Istnieje co najmniej kilkanaście różnych dialektów "uruchomieniowego XML" - czyli takiego, w którym XML jawnie określa, jakie operacje są wykonywane przez system. Takim mechanizmem jest np. BPEL. Technicznie jest to XML, ale podczas parsowania steruje on procesem integracyjnym. Również XAML (język definiujący wygląd formatek z animacjami i działanie Workflow Foundation w .Net 3.0) jest czymś, co jest wykonywane jako program.

Wszystkie pomysły na XML jako język wykonywalny realizują dużą część funkcji tzw. języków dynamicznych, które dzielą program na część główną (kompilowaną), dynamiczną (parsowaną) oraz wykonywany plik XML. Z jednej strony XML stanowi tu substytut dla specyficznych metod opisu, z drugiej, pozwala uwolnić programistów znających Javę czy C# od zgłębiania innych języków.

Warto też zadać sobie pytanie, dlaczego tak często wybierany jest XML, skoro często plik tekstowy jest lepszym wyborem. Jednym z powodów jest to, że dla XML dostępne są obecnie narzędzia, które z góry zakładają, że plik wejściowy ma strukturę XML. Jeżeli mamy np. jakąś konfigurację zapisaną w formacie pochodzącym od XML i potrzebujemy wygenerować "przyzwoicie wyglądający" raport, XML pomaga. Łatwo też przekształcić jeden plik XML w inny.

Proszę też zauważyć, że chyba wszystkie serwery integracyjne, jeżeli mają format "zewnętrzny" to najpierw przekształcają go do XML, a dopiero potem ponownie do formatu "wyjściowego". Dzięki temu wewnętrznie można stosować ogólne narzędzia posługujące się XML, bogate API i biblioteki do parsowania/transformacji itp. Do tego dużo jest mechanizmów sprawdzających poprawność XML - zarówno składniową, jak i (chociaż częściowo) logiczną. W przypadku własnego formatu, no cóż, takie elementy trzeba samodzielnie napisać.

XML do programowania

Dobrym przykładem takiego "samodzielnego" środowiska uruchomieniowego opartego na XML jest Jelly rozwijany pod auspicjami Apache Foundation. Przekształca on dokument XML w kod wykonywalny. Jelly może być użyty z poziomu Ant (pakiet do kompilacji wsadowej), Maven (do zarządzania projektem) czy jako element we wzorcach np. Cocoon.

Podstawą Jelly jest dokument XML przekształcany w specjalny skrypt pośredni. Następnie taki skrypt generuje zdarzenia XML, które powodują, że pewne elementy są przekształcane w tekst, XML, HTML itp. Elementy te mogą być dowiązane do kodu Javy - domyślnie używane są Jelly Tags realizowane jako komponenty Java Beans implementujące odpowiedni interfejs. Gdy uruchamiany jest skrypt, przekazywane są odpowiednie właściwości dowiązane do danych elementów i wykonywana jest metoda doTag(), która wywołuje ciało danego elementu XML. Przypomina to działanie JSP czy dyrektyw Velocity.

Można pójść dalej. Proces obsługi Web wygląda zwykle tak, że żądanie spływa do serwera WWW, który dekoduje komunikat SOAP i parsuje zawartą w nim wiadomość, by później na podstawie jej treści wywołać właściwą metodę aplikacji. Na wyjściu dane generowane przez metodę są ponownie przekształcane w XML i odsyłane. Oczywiście, tego typu operacje zwykle realizuje odpowiedni framework. Warto pamiętać, że nierzadko zdarza się sytuacja, w której programista musi mieć pełną kontrolę nad tym jak będzie wyglądał SOAP.

Z tą myślą firma XAware opracowała dla Javy narzędzie XA-Script. U jego podstaw leży koncepcja wykorzystująca mechanizmy deklaratywne XML. Pewne elementy związane z generowaniem dokumentu są automatycznie wstawiane w odpowiedni wzorzec. W ten sposób mamy czytelny, a przy tym dynamiczny dokument XML, który w zależności od kontekstu będzie uzupełniony właściwymi informacjami. Dokument zawiera opis orkiestracji, a można w nim też zapisać logikę biznesową - jest to więc praktycznie język programowania.

Najciekawsze jest to, że to nie program generuje XML, tylko XML "się wypełnia" przy użyciu dedykowanej biblioteki uruchomieniowej. W konsekwencji programista może zapomnieć o całym API do ręcznej manipulacji dokumentami XML (JDOM). Idea jest bardzo prosta, ale rozwiązanie zapewnia dużą elastyczność, zwłaszcza gdy ten mechanizm wykonywany jest "wewnątrz" np. brokera integracyjnego czy wewnątrz usługi Web do generowaniu odpowiedzi na komunikat, który napłynął z zewnątrz.

W narzędziu XAware łatwo można śledzić wszelkie modyfikacje XML - struktura dokumentu XML po prostu zawsze jest widoczna. Firma opracowała też specjalne narzędzie do projektowania (XA-Designer, integruje się z IDE Eclipse). Do tego można uzyskać dostęp do zasobów zarządzanych przez środowisko J2EE, czyli m.in. monitora transakcyjnego, puli połączeń itp. Oczywiście, zawsze można dodać tu dodatkowy komponent Java, ale - jak podkreśla Xaware - duża część usług Web jest i tak tylko interfejsem, pośrednikiem dla funkcjonalności już napisanych.

Ułatwianie przez utrudnianie

Bez względu na to jak potoczą się losy "wykonywalnego XML", warto zwrócić uwagę na rosnącą komplikację zapór ogniowych. Już od dawna proste rozwiązania oparte na filtrach pakietów (jak słynny linuxowy iptables) nie wystarczą do ochrony aplikacji. Coraz częściej firewall musi znać treść informacji, jaka jest przekazywana do/z serwerów firmowych, i pracować w "wyższych" warstwach OSI niż 3 czy 4.

Powszechne wykorzystanie HTTP nie zawsze jest błogosławieństwem. Nawet przy prostej komunikacji serwer proxy może zafałszować wyniki, np. za długo buforować wynik zwracany przez usługę. Także specjalizowane frameworki nie dają pełnej gwarancji. W przypadku WS-Security może się okazać, że bezpieczny pakiet po przejściu przez cache, które np. "potnie" żądanie czy odpowiedź, będzie odrzucony przez docelowy serwer. Co prawda, tym procesem można sterować, wybierając odpowiednie opcje w konfiguracji serwera proxy//cache, ale początkowym założeniem całego stosu tej technologii była przecież neutralność warstwy transportowej.

Poza tym coraz częściej do obsługi usług Web nie używa się portu 80, tylko inne. Dodając do tego fakt, że zarówno w świecie Javy, jak i .Net (WCF z .Net 3.0) bez większych problemów można "przepiąć" usługę Web z protokołu HTTP na protokół binarny, można sobie zadać pytanie, po co w ogóle potrzebny jest serwer WWW.

Mechanizmy współpracy międzyplatformowej i tak w praktyce okazały się zależne od wielu dodatkowych czynników. W praktyce jest tak, że programista szybko pisze usługi Web dla jednorodnej platformy lub też używa stosu specyfikacji WS-I (Basic Profile). To jednak dotyczy tylko relatywnie prostych środowisk.

W większych, bardziej skomplikowanych środowiskach do integracji wykorzystywany jest broker - nawet wtedy, gdy systemy bazują wyłącznie na usługach Web. Zwolennikom zapisywania wszystkiego w XML-u warto polecić jeszcze lekturę (primaaprilisowego) artykułu Charlesa Petzolda -http://www.charlespetzold.com/etc/CSAML.html , opisującego hipotetyczny język obiektowy w całości oparty na XML. Pytanie czego jeszcze nie zapisano w XML jest ciągle otwarte.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200