Transakcyjność i walidacja danych w rozwiązaniach XML-owych. Bober Dariusz, Piotr Muryjas Streszczenie Ukazanie potrzeby zapewnienia transakcyjności komunikatów e-biznesowych opartych o technologię XML oraz propozycja od autorskich rozwiązań. 1. Wstęp XML jako metajęzyk do budowania specyjalizowanych języków/aplikacji branżowych/środowiskowych. XML zyskał już sobie miano metajęzyka znacznikowego, a to za sprawą szeregu wypracowanych rozwiązań nazwijmy je branżowych, należy tu wymienić[1]: BITS Język technologii bankowych IFX Wymiana danych finansowych BIPS Bankowy system płatności internetowych TIM Znaczniki wymiany danych telekomunikacyjnych SIF Szkielet współpracy międzyszkolnej CBL Biblioteka biznesowa ebxml XML dla biznesu elektronicznego PDML Znacznikowy język opisu produktów FIX Protokół wymiany danych finansowych TEI Program kodowania tekstu CML Chemiczny język znaczników Każde z tych rozwiązań to specjalizowany język nazywany zamiennie aplikacją XML. Aplikacja XML, czyli zastosowanie XML, to zastosowanie tego języka do jakiejś dziedziny; i tak MathML to XML zastosowany w matematyce. Aplikacja XML nie jest programem służącym do obsługi XML takie potoczne rozumienie słowa aplikacja jest błędne. Każde ze środowisk dokonało/dokonuje takiej specyjalizacji języka XML, tak wykożystuje mechanizm znaczników aby uzyskać aplikację zapewniającą jak największą jej funkcjonalność w aspekcie własnych indywidualnych/określonych potrzeb. W każdej z branż dokumenty zapisane w danym języku są łatwo interpretowalne niezależnie od ich miejsca powstania. 2. Adaptacja XML do specyfiki wymagań funkcjonalnych w różnych obszarach działania czyli krótko o wybranych językach / omówienie wybranych aplikacji XML. Technologia XML, pomimo młodego wieku 5 lat, doczekała się już wielu implementacji. Elastyczność w definiowaniu znaczników i łatwość interpretacji zapisanej informacji sprawiła, że język XML jest używany obecnie w produktach Netscape i Microsoftu oraz w instalacjach wielu programów np. Perl. Poszczególne środowiska/firmy tworzą własne aplikacje adaptując XMLa do specyfiki własnych wymagań funkcjonalnych.
Oto kilka wybranych przykładów specjalizacji środowiskowych języka XML [1]: Zdefiniowanie własnego języka znaczników jest bardzo przydatne dla grup ludzi o wspólnych zainteresowaniach, na przykład dla fizyków czy chemików, gdyż umożliwia to używanie jednolitych symboli i jednolitej grafiki w wyspecjalizowanych przeglądarkach. CML - Chemiczny język znaczników Dokument zapisany w CML jest zrozumiały dla środowiska chemików, który wykorzystują go m.in. do zapisu wzorów cząstek chemicznych. Istnieją również przeglądarki, które zawierają parser (parser program służący to tłumaczenia kodu dokumentów znacznikowych, parz więcej [1],[2]) obsługujący CML, i które potrafią na podstawie kodu narysować strukturę takiej cząsteczki, rysunek 1. <?jumbo:namespace ns="http://www.xml-cml.org" prefix="c" java="jumbo.cmlxml.*node"?> <C:molecule id="thiophenol"> <C:atomArray builtin="elsym"> C C C C C C C S C C O O </C:atomArray> <C:atomArray builtin="x2" type="float"> 0 0.866 0.866 0-0.866-0.866 0.0 0.0 1.732-1.732 1.732-1.732 </C:atomArray> <C:atomArray builtin="y2" type="float"> 1 0.5-0.5-1.0-0.5 0.5-2.0 2.0 1.0 1.0 2.0 2.0 </C:atomArray> <C:atomArray builtin="atid1"> 1 2 3 4 5 6 1 4 2 9 6 10 </C:atomArray> <C:atomArray builtin="atid2"> 2 3 4 5 6 1 8 7 9 11 10 12 </C:atomArray> <C:atomArray builtin="order" type="integer"> 4 4 4 4 4 4 1 1 1 2 1 2 </C:atomArray> </C:molecule> Rysunek 1. Język CML a)definicja cząstki Triofenolu, b) widok cząstki w przeglądarce Jumbo Dzięki CML chemicy mogą tworzyć i publikować opisy cząsteczek i łatwo je między sobą wymieniać. CML daje również możliwość wyszukiwania związków o cechach spełniających jakieś warunki. MathML - Matematyczny język znaczników Matematyczny język znaczników powstał, aby umożliwić publikację dokumentach sieciowych zawierających równania matematyczne i różne symbole matematyczne. MathML jest specyfikacją W3C [10], grupa udostępnia również pod adresem www.w3.org/amaya/ przeglądarkę o nazwie Amaya umożliwiającą prezentację równań matematycznych napisanych w tym języku. Rysunek 2 przedstawia równanie 3Z 2 6Z + 12 = 0 zapisane w dokumencie MathML oraz widok tego dokumentu w przeglądarce Amaya.
<?xml version="1.0" encoding="iso-8859-2"?> <html xmlns:m="http://www.w3.org/tr/rec-mathml/"> <math> <m:mrow> <m:mrow> <m:mn>3</m:mn> <m:mo>&invisibletimes;</m:mo> <m:msup> <m:mi>z</m:mi> <m:mn>2</m:mn> </m:msup> <m:mo>-</m:mo> <m:mrow> <m:mn>6</m:mn> <m:mo>&invisibletimes;</m:mo> <m:mi>z</m:mi> </m:mrow> <m:mo>+</m:mo> <m:mn>12</m:mn> </m:mrow> <m:mo>=</m:mo> <m:mn>0</m:mn> </m:mrow> </math> Rysunek 2. Przykład dokumentu MathML a) kod równania b) widok równania w przeglądarce Amaya SMIL - Język synchronizacji multimediów Język synchronizacji multimediów (Synchronized Multimedia Integration Language, SMIL), standard W3C [11], jest próbą rozwiązania problemu przeglądarek multimedialnych, które zwykle potrafią obsłużyć jeden tylko rodzaj danych multimedialnych na raz: obraz wideo, dźwięk lub obrazki. Zadaniem języka SMIL jest tworzenie podobnych do telewizyjnych prezentacji multimedialnych, odbywa się to poprzez wskazanie, które pliki multimedialne kiedy mają być odgrywane. Sam język nie definiuje ani nie zawiera zasobów multimedialnych. Na rysunku 3. przedstawiono przykład dokumentu SMIL tworzącego sekwencję multimedialną: najpierw odgrywane są pliki mozart1.wav i amadeus1.mov, następnie prezentowany jest plik mozart1.htm, następnie odgrywane są mozart2.wav i amadeus2.mov, w końcu wyświetlany jest mozart2.htm. <?xml version="1.0" encoding="iso-8859-2"?> <!DOCTYPE smil PUBLIC "-//W3C//DTD SMIL 1.0//EN" "http://www.w3.org/tr/rec-smil/smil10.dtd"> <smil> <body> <seq id="mozart"> <audio src="mozart1.wav"/> <video src="amadeus1.mov"/> <text src="mozart1.htm"/> <audio src="mozart2.wav"/> <video src="amadeus2.mov"/> <text src="mozart2.htm"/> </seq> </body> </smil> Rysunek 3. Przykład prezentacji multimedialnej zdefiniowanej w języku SMIL. Język SMIL został wykorzystany w oprogramowaniu do obsługi strumieni multimedialnych RealNetworks [12] oraz Apple Quicktime [13].
W tej sytuacji Microsoft w przeglądarce Internet Explorer nie zaimplementował obsługi SMIL,, choć pewien jej fragment umieszczono w wersji 5.5 przeglądarki. W Internecie pod adresem www.empirenet.com/~joseram znajdziesz napisany w Javie aplet SMIL wraz z niesamowitymi przykładami symfonii połączonych z obrazami. HTML+TIME alternatywa dla języka SMIL Firmy Microsoft, Macromedia oraz Compaq stworzyły propozycję konkurencyjną dla języka SMIL aplikację XML stanowiącą multimedialne interaktywne rozszerzenie języka HTML synchronizowane czasem (Timed Interactive Multimedia Extensions) o nazwie HTML+TIME [14]. Dokumenty SMIL umożliwiają przetwarzanie innych plików, natomiast dokumenty HTML+TIME pozwalają obsługiwać w ramach jednej strony kod HTML oraz prezentacje multimedialne. Język ten został zaimplementowany w Internet Explorerze jako zachowanie (ang. behavior) jest to nowość Explorera 5 pozwalająca oddzielić kod od danych. Na rysunku 4. przedstawiono przykład dokumentu HTML+TIME, który wyświetlającego słowa Pozdrowienia, ze, świata i HTML+TIME, przy czym poszczególne słowa pojawiają się kolejno co dwie sekundy, sekwencja powtarza się pięciokrotnie. <HTML> <HEAD> <TITLE> Użycie HTML+TIME </TITLE> <STYLE>.time {behavior: url(#default#time);} </STYLE> </HEAD> <BODY> <DIV CLASS="time" t:repeat="5" t:dur="10" t:timeline="par"> <DIV CLASS="time" t:begin="0" t:dur="10">pozdrowienia</div> <DIV CLASS="time" t:begin="2" t:dur="10">ze</div> <DIV CLASS="time" t:begin="4" t:dur="10">świata</div> <DIV CLASS="time" t:begin="6" t:dur="10">html+time</div> </DIV> </BODY> </HTML> Rysunek 4. Przykład dokumentu w języku HTML+TIME a)kod dokumentu b) prezentacja dokumentu w przeglądarce Internet Exploer. XHTML HTML 4.0 przepisany przez W3C jako aplikacja XML XHTML (Extensible HyperText Markup Language) jest jedną z największych aplikacji XML stanowiącą pomost między HTML a XML, napisaną przez W3C celem rozpowszechnienia standardu XML. XHTML to aplikacja naśladująca HTML 4.0 tak, aby można było wyświetlać jego dokumenty w zwykłych przeglądarkach sieciowych [15]. Na rysunku 5. przedstawiono przykładowy dokument XHTML.
<?xml version="1.0" encoding="iso-8859-2"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/tr/xhtml1/dtd/xhtml1- transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title> Strona WWW numer 1 </title> </head> <body> <h1> Witaj w XHTML! </h1> <center> Strona ta zawiera tylko zwykły tekst. <p> To jest nowy akapit. </p> </center> </body> </html> Rysunek 5. Dokument w języku XHTML a) kod dokumentu b) sposób wyświetlania w przeglądarce. W języku XHTML dokument koduje się bardzo podobnie jak HTML, należy jednak ściśle przestrzegać składni XML (zamykać wszystkie elementy znacznikami końcowymi, znaczniki zgodnie z normą XHTML zapisywać małymi literami).. <HTML xmlns:v="urn:schemas-microsoft-com:vml"> <HEAD> <TITLE> Użycie wektorowego języka znaczników VML </TITLE> <STYLE> v\:* {behavior: url(#default#vml);} </STYLE> </HEAD> <BODY> <CENTER> <H1> Użycie wektorowego języka znaczników VML </H1> </CENTER> <P> <v:oval STYLE='width:100pt; height:75pt' fillcolor="yellow"> </v:oval> <P> <v:rect STYLE='width:100pt; height:75pt' fillcolor="blue" strokecolor="red" STROKEWEIGHT="2pt"/> <P> <v:polyline POINTS="20pt,55pt,100pt,-10pt,180pt,65pt,260pt,25pt" strokecolor="red" STROKEWEIGHT="2pt"/> </BODY> </HTML> Rysunek 6. Dokument VML a) kod dokumentu b) prezentacja w przeglądarce Internet Exploer
VML - Wektorowy język znaczników Wektorowy język znaczników VML (Vector Markup Language) to aplikacja zaproponowana przez Microsoft [16] dająca możliwość rysowania wielu figur geometrycznych poprzez podanie ich wektorowego opisu. Rysunek 6. zawiera przykład dokumentu VML, który powoduje wyrysowanie żółtej elipsy, niebieskiego prostokąta oraz czerwonej linii łamanej. XUL - język interfejsu użytkownika XUL (XML-based User Interface Language) to oparty na XML język interfejsu użytkownika pochodzący od Netscape i Mozilli umożliwia opisanie elementów interfejsu użytkownika, które mają być wyświetlone w przeglądarce. Obecnie XUL obsługiwany jest jedynie w programie Netscape Navigator 6 [17]. Przedstawiony na rysunku 7. dokument w języku XUL powoduje dodanie w oknie przeglądarki bocznych pasków przewijania <?xml version="1.0" encoding="iso-8859-2"?> <window align="horizontal" xmlns="http://www.mozilla.org/keymaster/ gatekeeper/there.is.only.xul"> <scrollbar align="vertical"/> <box align="vertical" flex="100%"> <scrollbar align="horizontal"/> <spring flex="100%" style="background-color: white"/> <scrollbar align="horizontal"/> </box> <scrollbar align="vertical"/> </window> Rysunek 7. Języku XUL a)kod dokumentu b)prezentacja w przeglądarce Netscape. XBRL - Rozszerzalny język raportów biznesowych XBRL (Extensible Business Reporting Language) to otwarta specyfikacja używająca XML do opisywania warunków finansowych [18]. XBRL pozwala na takie zakodowanie raportów finansowych, aby ułatwić ich przeszukiwanie i pobieranie z nich potrzebnych informacji. Przykład raportu finansowego zakodowanego w języku XBRL przedstawiony jest na rysunku 8. To tylko wybrane przykłady specjalizowanych rozwiązań z pośród licznej rodziny aplikacji XML jakie twórcy poszczególnych języków zaimplementowali do potrzeb własnych środowisk. Wielość dziedzin w których XML znalazł swoje zastosowanie świadczy o jego przydatności w tworzeniu szczegółowych rozwiązani. Takie a nie inne zachowanie się poszczególnych przeglądarek (patrz rysunki 1 do 8) wynika z odpowiedniego zrozumienia kodu danego języka. Interpreterami kodów języków XML są programiki zwane PARSERAMI. To od parsera zależy jak zostanie odczytany dany fragment kodu i jaka na nim zostanie wywołana akcja. Jako obszar dalszych rozważań autorów zostanie obrany e-bussines. Pod kątem specyfiki transakcji biznesowych drogą elektroniczną (elektronicznej wymiany dokumentów EDI) zostanie przebadana technologia XML. Zweryfikowane zostaną
istniejące rozwiązania wykorzystujące tą technologię oraz ich komletność w sęsie zapewnienia pełnej funkcjonalności dla prowadzenia biznesu drogą elektroniczną. <?xml version="1.0" encoding="utf-8"?> <group xmlns="http://www.xbrl.org/us/aicpa-us-gaap" xmlns:gpsi="http://www.xbrl.org/taxonomycustom.xsd" id="543-ab" entity="nasdaq:gpsi" period="1999-05-31" schemalocation="http://www.xbrl.org/taxonomycustom.xsd" scalefactor="6" precision="9" type="usgaap:financial" unit="iso4217:usd" decimalpattern="" formatname=""> <item id="is-025" type="operatingexpenses.researchexpense" period="p1y/1999-05-31">20427</item> <item id="is-026" type="operatingexpenses.researchexpense" period="p1y/1998-05-31">12586</item> </group> <group type="gpsi:detail.quarterly" period="1998-05-31"> <item period="1997-12-01/1998-02-28">0.17</item> <item period="1998-03-01/1998-05-31">-0.12</item> <item period="1998-06-01/1998-05-31">0.33</item> </group> <group type="gpsi:detail.quarterly" period="1999-05-31"> <item period="1998-12-01/1999-02-28">0.23</item> <item period="1999-03-01/1999-05-31">0.28</item> <item period="1998-06-01/1999-05-31">0.86</item> </group> Rysunek 8. Przykład rapotu finansowego zapisanego w języku XBRL. 3. XML w rozwiązaniach e-biznesowych. Język XML w biznesie elektroniczna wymiana dokumentów Analiza istniejących rozwiązań W istniejących na rynku rozwiązaniach biznesowych wykorzystujących język XML wykreśla się pewien standard co do treści przesyłanych komunikatów. Najczęściej przesyłane komunikaty to [9]: - zapytanie ofertowe - zamówienie - potwierdzenie zamówienia - faktura - zapytanie o stany magazynowe - inne Komunikaty te są naturalnym odzwierciedleniem życia gospodarczego przedsiębiorstw i reprezentują większość procesów zachodzących pomiędzy partnerami biznesowymi, a tradycyjnie realizowanych z wykorzystaniem nośnika papierowego. Niemniej jednak w każdym indywidualnie rozpatrywanym przypadku struktura dokumentów wybranego komunikatu różniła się od struktury dokumentu tego komunikatu proponowanego przez innego kontrahenta. Główne różnice to: - zmiana nazewnictwa poszczególnych wskaźników - zmiana wymagalności ich wystąpień - zmiana kolejności znaczników
- duża dowolność w definiowaniu atrybutów poszczególnych znaczników W praktyce format dokumentu(jego dane i struktura organizacji danych) proponowanego przez danego kontrahenta zależał od jego indywidualnych potrzeb, lub też od rozwiązań jakie przyjęła firma świadcząca usługi informatyczne kontrahentowi. Próby zestandaryzowania komunikatów biznesowych są trudnym zadaniem. Obecnie najbliżej miana standardu znajdują się rozwiązania oparte o specyfikację ebxml [3] [9] [5] [6] [7] [8], uznawaną m.in. przez organizacje UN/CEFACT (podać pełną nazwę), OASIS (i tu) oraz EAN.UCC(i tu). Komunikaty e-biznesowe wg specyfikacji ebxml /Elektroniczne dokumenty biznesowe proponowane przez EAN.UCC W lipcu 2001 EAN Int. i UCC opublikowały zestaw schematów komunikatów XML, zgodnych zarówno ze specyfikacjami ebxml, jak i pozostałymi standardami systemu EAN.UCC [9]. Poszczególne komunikaty biznesowe zostały pogrupowane w poniższe dokumenty[9]: A. Dokumenty rdzenia - Core Item (pozycja towarowa) realizuje proces komunikacji obowiązkowych elementów danych, podających podstawowy numer identyfikacyjny produktu, opis pozycji, jednostkę miary i klasyfikację pozycji. - Core Party (dane firmy) zawiera podstawowe dane biznesowe wspólne dla wszystkich stron biorących udział w wymianie informacji pomiędzy partnerami handlowymi, obejmujące identyfikację partnera, szczegółowe informacje o firmie i jej funkcji w wymianie, nazwę i adres oraz informacje finansowe. - Core Order (zamówienie) zapewnia nabywcy złożenie zamówienia do sprzedawcy na zakup danej ilości towarów i usług, i dostarczenie ich do wskazanej lokalizacji. - Core Despatch Advice (awizo wysyłki) umożliwia dostawcy przekazanie szczegółowej informacji o zawartości wysyłki, oraz umożliwia odbiorcy dostawy potwierdzić otrzymanie dostawy zgodnej z zamówieniem. - Core Request for Payment (żądanie zapłaty) zdefiniowano jako żądanie zapłaty za towary lub usługi na warunkach uzgodnionych między sprzedawcą i nabywcą. B. Dokumenty rozszerzeń - Item Relationship Dependent Data Extension (informacje dodatkowe o pozycji) zawiera atrybuty pozycji towarowej, które nie znalazły się z Core Item. - FMCG Item Extension (fast moving consumer goods - towary szybko rotujące) zdefiniowano na podstawie wspólnych wymagań dla wymienianych danych dotyczących towarów szybko rotujących. Dane te natępnie posłużą do głębszej analizy sprzedaży. - Simple Invoice Extension (faktura) jest rozszerzeniem dla Core Request for Payment. Zawiera dane dotyczące kalkulacji cen i numery referencyjne
(w polsce dane wymagane ustawą o podatkach oraz ustawą o rachunkowości) - Party Financial Institution Information Extension (informacja o instytucji finansowej) zapewnia realizację opcji identyfikacji instytucji finansowej upoważnionej do realizacji transakcji finansowej. Informacja ta obejmuje numer konta bankowego, kod banku, nazwę właścicie-la konta, walutę transakcji, nazwę banku. - Party Pallet System Extension (system palet) wspomaga proces zamawiania, przyjmowania i wysłania palet. Statyczna informacja o systemie paletowania może być ustalona w procesie uzgodnienia danych albo to rozszerzenie można zastosować z innym komunikatem. - Allowance-Charge Extension zawiera szczegółowe informacje o zniżkach lub opłatach. - Payment Terms Extension (warunki płatności) zapewnia sprzedawcy możliwość poinformowania o warunkach płatności za towary lub usługi. Czy zatem, skoro technologia XML jest coraz powszechniej wykorzystywana przez środowiska e-biznesowe oraz został wypracowany jakiś standard wymienianych komunikatów. To czy można tu już mówić o istnieniu języka/aplikacji XML-owej specyficznej tylko dla tego środowiska. Czy rozwiązania oparte o wspomnianą specyfikę zapewniają pełną funkcjonalność obsługi komunikatów za którymi idą nierzadko konkretne pieniądze. Otóż zdaniem autorów artykułu tak nie jest. 4. Budowanie tezy: Rozwój i specjalizacja języka/aplikacji XML w obszarze e biznesu. /Specyfikacja funkcjonalna środowiska e-biznesowego. Z uwagi na specyfikę środowiska biznesu, autorzy artykułu wnoszą o zasadność tezy: aby aplikacja obsługująca elektroniczną wymianę dokumentów zapewniała pełną funkcjonalność w zakresie walidacji przesyłanych komunikatów jak i transakcyjności ich zajścia cech zaczerpniętych z systemów bazodanowych/systemów zintegrowanych. Potrzeba walidacji wynika z konieczności weryfikowania przesyłanego dokumentu do/od kontrahenta pod względem poprawności merytorycznej. Dokument winien zawierać wszystkie wymagane, określone wcześniej pola (znaczniki). Wartości przekazywane za pomocą znaczników i ich atrybutów winny być określonego typu. Transakcyjność oferuje dwustanową obsługę komunikatów biznesowych albo dokument trafił do (został prawidłowo zaimportowany przez system) kontrahenta i odnotowuje się to we własnym systemie, albo nie dotarł (utknął na łączach internetu) należy go wysłać powtórnie. Jest to szczególnie istotne w przypadku bardziej złożonych modeli biznesowych 1 funkcjonujących w rzeczywistości gospodarczej. 1 Dla celów projektu autorzy wprowadzają pojęcie tzw modeli biznesowych będących odzwierciedleniem ilości firm współpracujących w łańcuszku dostaw, szczegóły w punkcie 7.
5. Mechanizmy języka XML pozwalające na weryfikację poprawności danych walidację Walidacji struktury dokumentu XML w zakresie poprawności nazw i kolejności znaczników, kompletności atrybutów i zgodności typów danych można dokonać tylko wówczas gdy dostępna jest definicja tej struktury. Strukturę dokumentu opisuje się na dwa sposoby: poprzez elementy DTD Definicji typu dokumentu lub schematy XML [4b]. 5.1. Definicja typu dokumentu (DTD) Dokument XML można walidować, jeśli związana jest z nim definicja typu dokumentu (DTD) i kiedy dokument jest z nią zgodny. DTD dokumentu określa jego prawidłową składnię. DTD mogą być przechowywane w osobnym pliku lub w samym dokumencie, w elemencie <!DOCTYPE>. Na rysunku 10 zamieszczono przykład, w którym do dokumentu zamówienia zakupowego dołączony jest element <!DOCTYPE>. <?xml version="1.0" encoding="iso-8859-2"?> <?xml-stylesheet type="text/css" href="zamowienia.css"?> <!doctype zamowienie [ <!element zamowienie (linia*)> <!element linia empty> <!attlist zamowienie nr cdata #required> <!attlist zamowienie data cdata #required> <!attlist zamowienie od cdata #required> <!attlist linia nr id #required> <!attlist linia indeks cdata #required> <!attlist linia nazwa cdata #required> <!attlist linia ilosc cdata #required> <!attlist linia jm cdata #required> ]> <zamowienie nr= 0300123 data= 2003-03-26 od= xyz s.a. > <linia nr= 1 indeks= 10012 nazwa= makaron pastella ilosc= 450 jm= kg /> <linia nr= 2 indeks= 22012 nazwa= paluszki słone ilosc= 100 jm= sz /> </zamowienie> Rysunek 10. Komunikat zamówienia zakupu z DTD Podczas przetwarzania dokumentu zamówienia parser sprawdzi czy znacznikiem głównym dokumentu jest znacznik o nazwie <zamowienie>, czy znacznik ten zawiera elementy o nazwie <linia>. Nastąpi również weryfikacja poszczególnych znaczników ze względu na ich atrybuty, wszystkie posiadają status #REQUIRED (wymagany). Wszystkie poza numerem lini są typu CDATA (ciąg znaków), natomiast numer lini jest typu ID co oznacza, że atrybut ten musi zawierać unikatową wartość w skali dokumentu (numer linii na zamówieniu nie może się powtórzyć). Więcej o DTD znajdziesz w [2].
5.2. Schematy XML DTD choć prostszy w definicji w stosunku do Schema XML, posiada jednak ograniczone możliwości przy definiowaniu złożonych struktur danych. Jest również sztywny ma niewielkie możliwości w rozbudowie raz już zdefiniowanych modeli. Schematy XML pozwalają nie tylko opisać składnię dokumentu, tak jak DTD, ale pozwalają określić typy danych w treści elementów, umożliwiają dziedziczenie składni po innych schematach, wstawianie komentarzy, używanie schematów posługujących się wieloma przestrzeniami nazw, tworzenie prostych i złożonych typów danych, określanie minimalnej i maksymalnej liczby wystąpień elementu, tworzenie typów w postac i list, tworzenie grup atrybutów, ograniczanie zakresu informacji, które inne schematy mogą dziedziczyć po danym, łączenie wielu schematów w całość, wymuszanie niepowtarzalności wartości atrybutów itp [1] [4a]. Rysunek 11 zawiera przykład zamówienia prezentowanego wcześniej, tym razem struktura dokumentu określona jest poprzez schematy XML. <?xml version="1.0" encoding="iso-8859-2"?> <?xml-stylesheet type="text/css" href="zamowienia.css"?> <schematy_zamowienia xmlns= http://pluton.pol.lublin.pl/xml/schematy xmlns:xsi= http://www.w3.org/2001/xmlschema-instance xsi:schemalocation= http://pluton.pol.lublin.pl/xml/schematy zamowienia.xsd > <zamowienie nr= 0300123 data= 2003-03-26 od= xyz s.a. > <linia nr= 1 indeks= 10012 nazwa= makaron pastella ilosc= 450 jm= kg /> <linia nr= 2 indeks= 22012 nazwa= paluszki słone ilosc= 100 jm= sz /> </zamowienie> </schematy_zamowienia> Rysunek 11. Komunikat zamówienia zakupu z Schema XML W elemencie głównym <schematy_zamowienia> zdefiniowano domyślną przestrzeń nazw (XML namespace [1] [2]), jest ona zgodna z przestrzenią docelową schematu. Powołano się również na przestrzeń nazw określającą atrybut schemalocation, służący do wskazania schematu. Dokument zamówienia winien mieć teraz zbudowany schemat i zapisany w pliku zamowienia.xsd. Przykład takiego schematu przedstawiono na rysunku 12. Elementy należące do przestrzeni nazw oznaczonej prefiksem xsd stanowią składniki języka definiowania schematów. 6. Transakcyjność w rozwiązaniach XML-owych Technologia XML nie dostarcza naturalnych mechanizmów, takich jakimi w przypadku walidacji jest definicja struktury dokumentu (DTD, Shema XML), pozwalających na odnotowanie zajścia/bądź-nie transakcji. By zapewnić transakcyjność wykonywanych operacji przesyłania danych poprzez internet, stosuje się zewnętrzne rozwiązania softwerowe.
<?xml version="1.0" encoding="iso-8859-2"?> <xsd:schema xmlns:xsd= http://www.w3.org/2001/xmlschema targetnamespace= http://pluton.pol.lublin.pl/xml/sch ematy xmlns= http://www.w3.org/2001/xmlschema elementformdefault= qualified version= 1.1 > <xsd:element name= schematy_zamowienia > <xsd:complextype> <xsd:sequence> <xsd:element ref= zamowienie minoccurs= 1 maxoccurs= unbounded /> </xsd:sequence> </xsd:complextype> </xsd:element> <xsd:element name= zamowienia > <xsd:complextype> <xsd:sequence> <xsd:element ref= linia minoccurs= 1 maxoccurs= unbounded /> </xsd:sequence> </xsd:complextype> <xsd:key name= dane_zamowienia > <xsd:selector xpath= zamowienie /> <xsd:field xpath= @nr type= xsd:string /> <xsd:field xpath= @data type= xsd:date /> <xsd:field xpath= @od type= xsd:string /> </xsd:key> <xsd:attribute name= nr /> <xsd:attribute name= data /> <xsd:attribute name= od /> </xsd:element> <xsd:element name= linia > <xsd:key name= szczegoly > <xsd:selector xpath= linia /> <xsd:field xpath= @nr type= xsd:string /> <xsd:field xpath= @index type= xsd:string /> <xsd:field xpath= @nazwa type= xsd:string /> <xsd:field xpath= @ilosc type= xsd:decimal /> <xsd:field xpath= @jm type= xsd:string /> </xsd:key> <xsd:attribute name= nr /> <xsd:attribute name= index /> <xsd:attribute name= nazwa /> <xsd:attribute name= ilosc > <xsd:simpletype> <xsd:restriction base= xsd:decimal > <xsd:minexclusive value= 1 /> </xsd:restriction> </xsd:simpletype> </xsd:attribute> <xsd:attribute name= jm /> </xsd:element> </xsd:schema> Rysunek 12. Schemat XML dokumentu zamówienia.
6.1 Zastosowanie zewnętrznych mechanizmów transakcyjności na przykładzie aplikacji ebxdi/ Transakcyjność w praktyce/ Praktyczne rozwiązanie problemu transakcyjności na przykładzie aplikacji edxdi/ ebxdi jako przykład kompleksowego podejścia do potrzeb środowiska e-biznesu/ 6.1 Transakcyjność w układach prostych Układem prostym jest taki model implementacji elektronicznej wymiany dokumentów, w którym komunikaty potwierdzające zajście operacji gospodarczej przesyłane są wyłącznie pomiędzy partnerami biznesowymi dokonującymi tej operacji. Droga dokumentów elektronicznych pokrywa się z drogą operacji gospodarczej. Takie rozwiązanie zwane jest też często dwuwęzłowym modelem biznesowym (rysunek 13). A producent Dokumenty elektroniczne Operacje gospodarcze B hurtownia Rysunek 13. Dwuwęzłowy model biznesowy. Przykładem oprogramowania umożliwiającego realizację prostego modelu biznesowego jest ebxdi firmy EBS.COM (Electronic Business Solutions) [3][4][19][20]. ebxdi została zbudowana w technologii Java 2 Platform Enterprise Edition, przez co jest niezależna od platformy sprzętowej i systemów operacyjnych, w pełni skalowalna, stabilna, otwarta na potrzeby i technologie, które pojawią się w przyszłości. Logika działania ebxdi została przedstawiona na rysunku 14. Rys. 14. Schemat wymiany informacji biznesowej z wykorzystaniem ebxdi
Każdy z partnerów biznesowych może pracować z własnym formatem danych, gdyż ebxdi zapewni elektroniczną wymianę danych w formacie tekstowym (w tym XML, HTML, inne), rozwiązane jest to poprzez arkusze stylów XSL [1] [2]. ebxdi może być eksploatowane praktycznie na każdej platformie systemowej, sprzętowej czy programowej. Można wśród nich wymienić: serwery sprzętowe oparte na procesorach RISC czy Intel x386 (np. Pentium III/IV); systemy operacyjne: Linux, Unix, Microsoft Windows NT/2000; bazy danych: PostgreSQL, IBM DB2, Oracle, Microsoft SQL Server; serwery aplikacji J2EE: JBoss, IBM WebSphere, BEA WebLogic, iplanet. ebxdi cechują niewygórowane wymagania w zakresie mocy obliczeniowej serwera - wystarczy "zwykły" komputer z jednym procesorem klasy Intel Pentium III/1 GHz, wyposażony w 256 MB RAM, dowolny dysk IDE lub SCASI i kartę sieciową łączącą serwer z systemami obsługi zaplecza (niekoniecznie klasy ERP). W zakresie bezpieczeństwa przesyłania danych, ebxdi stwarza możliwość użycia dwóch rodzajów kodowania. W przypadku wymiany typu Web-EDI - poprzez strony WWW - dokumenty XML z danymi kodowane są za pomocą protokołu SSL (ang. Secure Sockets Layer). W przypadku wymiany danych poprzez szyfrowany port TCP/IP, kodowanie następuje za pomocą protokołu TLS (ang. Transfer Layer Security). Rysunek 15. Organizacja transakcyjnoci rozwiązań XMLowych na przykładzie produktu ebxdi W ebxdi za transakcyjność odpowiada tzw. serwer komunikatów. Przesyłany komunikat biznesowy zapisywany jest do bazy XMLowej (rysunek 15), następnie jest wysyłany do klienta. Dokument pozostaje w bazie XMLowej do czasu otrzymania potwierdzenia odbioru przez klienta wysłanego dokumentu. W przypadku gdy potwierdzenie powróci dokument jest usuwany z bazy XMLowej o informacja o dokonaniu transakcji trafia do właściwego systemu ERP. W przypadku nie pojawienia się potwierdzenia serwer komunikatów ponownie wysyła dokument do klienta. 6.2 Transakcyjność w układach złożonych Układ złożony występuje wówczas gdy firmy dokonujące operacji biznesowych korzystają, w zakresie elektronicznej wymiany dokumentów, z usług zewnętrznych firm
informatycznych. W zależności od ilości firm biorących udział w procesie wymiany dokumentów elektronicznych realizowany jest: - trójwęzłowy model biznesowy dwie firmy dokonujące operacji gospodarczej plus jedna pośrednicząca, świadcząca usługi informatyczne obu partnerom. - czterowęzłowy model biznesowy dwie firmy dokonujące operacji gospodarczej plus dwie firmy pośredniczące, każdy z partnerów jest obsługiwany przez własną firmę informatyczną (rysunek 14). - n-węzłowy model biznesowy firm pośredniczących jest k, gdzie n=k+2; k <1, n-2>; model ten wprowadzono dla uogólnienia układów złożonych. W układach złożonych droga dokumentów elektronicznych nie pokrywa się z drogą operacji gospodarczej. M partner Dokumenty elektroniczne Dokumenty elektroniczne N partner Dokumenty elektroniczne Operacje gospodarcze Firma D informatyczna Operacje gospodarcze Dokumenty elektroniczne Firma C informatyczna Dokumenty elektroniczne A producent Operacje gospodarcze B hurtownia Rysunek 16. Model biznesowy cztero-węzłowy, w elektronicznej wymianie dokumentów biznesowych pośredniczą dwie firmy informatyczne. W złożonych modelach biznesowych konieczne staje się zastosowanie bardziej wyrafinowanych metod zapewnienia transakcyjności. Sam serwer komunikatów, który sprawdza się na węzłach sąsiadujących nie wystarcza, konieczne jest udrożnienie węzłów pośredniczących, tak aby otrzymanie komunikatu o powodzeniu/ niepowodzeniu z węzła k, powodowało, oprócz zarejestrowania powodzenia operacji wysłanie do węzła k-2 zgodnej treści komunikatu. W układach złożonych nie stwierdzono mechanizmów zapewniających pełną transakcyjność. Najczęściej każdy z węzłów pośredniczących (każda z firm informatycznych) stosuje lokalnie (w komunikacji z sąsiednimi węzłami) własne rozwiązania. Co jednak w skali kompletnej operacji gospodarczej, daje w najlepszym przypadku efekt zbliżony do oczekiwanego. Potrzeba jest zatem opracowania zasad i stworzenia aplikacji XML-owej zawierającej mechanizmy walidacji poprawności napisanego w niej dokumentu biznesowego, oraz
zapewniającej obsługę transakcyjności przesyłania tych dokumentów pomiędzy partnerami biznesowymi, niezależnie od tego czy znajdują się oni na biegunach dwu, trój, czy n-węzłowego modelu biznesowego. Aplikacja ta miała by zapewnić węzłom pośredniczącym przezroczystość w stosunku do węzłów pomiędzy którymi zachodzi operacja gospodarcza. Wykorzystanie tej aplikacji przez firmy informatyczne oferujące usługi e-biznesowe (węzły pośredniczące), dostarczyło by język, z pomocą którego firmy te mogły by tworzyć własne systemy do obsługi elektronicznej wymiany dokumentów w pełni otwarte na przyszłe kontakty biznesowe ich klientów. 8. Cel-Własna aplikacja XML dla środowiska biznesowego Prezentowany problem jest o tyle istotny, że oprócz zwykłej konsekwencji finansowej wynikającej z opóźnień w dostawie towaru (nie ma dostawy jeżeli nie ma zamówienia na daną dostawę), firmy niejednokrotnie podpisują ze sobą umowy z których wynika, że w przypadku nieterminowej realizacji zamówienia, lub całkowitym braku realizacji zamówienia, firma zobowiązana jest zapłacić określoną (najczęściej wysoką) kwotę kary. Zatem istnieje zasadność stworzenia takiej specyfikacji języka XML-biznesowego, który mógłby w oderwaniu od ilości węzłów, przez które przechodzi dokument elektroniczny, zapewnić transakcyjność operacji. Zagadnienie, którym autorzy artykułu chcą sie zając w przyszłości wstępnie zostało formułowane jako: Opracowanie, w oparciu o istniejące standardy i najnowsze osiągnięcia z dziedziny technologii XML, specjalizowanego języka dla obsługi środowiska biznesowego, który niezależnie od ilości węzłów pośredniczących, sprowadzi model biznesowy n-węzłowy do modelu biegunowego (prostego 2- węzłowego). 9. Wstępne propozycje rozwiązań do dalszych rozważań Poprzez rejestrację węzłów: Należało by stworzyć XML-ową bazę danych do której były by wpisywane informacje o każdym węzłów przez które przechodzi dokument. Dokumenty komunikatów będą zawierać predefiniowane w własnej przestrzeni nazw znaczniki określające nadawcę, sumy kontrolne, dodatkowe informacje. Predefiniowane elementy będą załączone w pliku dokumentu, lub w oddzielnym pliku powiązanym z dokumentem. Węzeł otrzymując dokument odczytuje z niego, bądź dołączonego pliku, informacje o nadawcy (czytaj serwerze nadawcy) i na podstawie dodatkowych informacji (np login i hasło) wysyła na serwer komunikat z numerem dokumentu, cyfrą kontrolną i własny unikatowy identyfikator (np. GLN). Po czym wysyła dokument dalej. Kolejne węzły dokonują logowania/wpisów do bazy danych, na tej podstawie śledzona jest droga dokumentu i ewentualne miejsce awarii. Otrzymanie wpisu od węzła docelowego jest jednoznacznie interpretowane jako zakończenie transakcji. Wstępna ocena tego rozwiązania wskazuje na: - zwiększenie ruchu w sieci - rozrastanie się danych w przypadku większej ilości węzłów pośrednich,
- rejestracja węzłów pośrednich kłóci się również z założeniem przezroczystości sieci z punktu widzenia węzłów skrajnych dokonujących transakcji gospodarczej. - Rozwiązanie zapewnia pełną ewidencję ruchu dokumentów w sieci, oraz odtworzenie transakcji w przypadku uszkodzenia łącza. Poprzez łańcuch-ze-źródłem: Dokonuje się takiej modyfikacji dokumentu komunikatu, poprzez zdefiniowanie odpowiednich znaczników w własnej przestrzeni nazw, lub też dowiązuje się zewnętrzny plik do dokumentu komunikatu, w którym każdy z węzłów będzie mógł za pomocą określonych znaczników wpisać własną cyfrę kontrolną, oraz aders mailowy/ftp (rysunek 18). Wpisanie tej informacji do pliku będzie opcjonalne, a pojawienie się wpisu z danego węzła będzie równoznaczne z deklaracją otrzymywania informacji o dalszej drodze danego dokumentu. Każdy z węzłów odsyłał by informacje o otrzymaniu dokumentu i poprawnym przetworzeniu tylko do węzłów które zamieściły by swój wpis w dołączonym pliku. Wstępna ocena tego rozwiązania wskazuje na: - możliwość śledzenia ruchu dokumentu (i ewentualne podejmowanie interwencji) przez dowolny węzeł w sieci. - dodatkowe zwiększenie ruchu w sieci - rozrasta się wielkość przesyłanych dokumentów <?xml version="1.0" encoding="iso-8859-2"?> <?xml-stylesheet type="text/css" href="zamowienia.css"?> <dokument_transakcyjny xmlns= http://pluton.pol.lublin.pl/xml/schematy xmlns:xsi= http://www.w3.org/2001/xmlschema-instance xsi:schemalocation= http://pluton.pol.lublin.pl/xml/schematy transakcja.xsd > <zamowienie nr= 0300123 data= 2003-03-26 od= xyz s.a. > <linia nr= 1 indeks= 10012 nazwa= makaron pastella ilosc= 450 jm= kg /> <linia nr= 2 indeks= 22012 nazwa= paluszki słone ilosc= 100 jm= sz /> </zamowienie> <transakcja:weryfikuj> <transakcja:numer_dokumentu nr= 0300123 /> <transakcja:ilosc_rekordow> 2 </transakcja:ilosc_rekordow> <transakcja:powiadom> administrator@pluton.pol.lublin.pl </transakcja:powiadom> </transakcja:weryfikuj> </dokument_transakcyjny> Rysunek 18. Propozycja dodatkowych predefiniowanych elementów funkcyjnych w komunikacie zamówienia zakupowego. 10. Wnioski Projekt stworzenia specyjanlizowanego języka dla potrzeb środowiska biznesowego, jest stosunkowo młodym projektem (liczonym jeszcze w tygodniach) stąd wyniki badań na obecny moment sprowadzają się do zdefiniowania problemu i uogólnienia go do skali zagadnienia n-węzłowego. Zapoznanie się z możliwościami technologii XML w
zakresie walidacji i transakcyjności operacji wykonywanych z jej użyciem. Rozpoznanie i adaptacja przyjętych standardów w obszarze elektronicznej wymiany dokumentów i e-biznesu. Cel, który został przez autorów obrany, a więc stworzenie własnej aplikacji XML-owej jeżeli przyniesie pozytywne efekty, to - rozwiąże problemy jednej rzeczywistej firmy - może zostać zaakceptowany przez szersze grono odbiorców u zyskując tym samym godne miano języka środowiskowego. - opublikowane osiągnięcia na polu transakcyjności mogą zostać wykorzystane przez inne ośrodki w tworzeniu rozproszonych rozwiązań internatowych. Literatura: [1] Steven Holzner XML Vademecum profesjonalisty Helion 2001 [2] Elliote Rusty Harold XML Księga eksperta Helion 2000 [3] Muryjas Piort, Bober Dariusz ebxdi technologia EDI za rozsądne pieniądze s.85 Wdrażanie i eksploatacja systemów informatycznych pod redakcją Marek Miłosz, PTI, Lublin 2002 [4] Marek Miłosz, Dariusz Bober Elektroniczna wymiana dokumentów z wykorzystaniem technologii XML s. 185, matriały do IV Lubelskiego Akademickiego Forum Akademickiego, Informatyka Stosowana 2002. [4a] Tomasz Traczyk Schematy XML, materiały z koferencji PLOUG 2001, Zakopane. [4b] Sharon L Hoffman XML Blueprint, s.20-23, iseries NEWS, February 2003. Strony www: [5] Informacje o EDI i XML http://edi.start4all.com [6] Repozytorium XML elementów danych: http://xml-edi.tie.nl [7] Zastosowanie XML do EDI: http://www.xedi.org [8] Oprogramowanie serwera XML (freeware) dla gospodarki elektronicznej, rozwiązania dla ERP i EDI: http://www.xmls.com [9] Strona Towarzystwa EAN.UCC: http://www.ean.pl [10] Specyfikacja języka MathML: www.w3.org/math [11] Specyfikacja języka SMIL: www.w3.org/audiovideo [12] http://service.real.com/help/library/guides/production/realpgd.htm [13] www.apple.com/quicktime/authoring/qtsmil.html [14] Specyfikacja języka HTML+TIME: http://msdn.microsoft.com/workshop/author/behaviors/time.asp [15] Specyfikacja języka XHTML 1.0: www.w3.org/tr/xhtml1 [16] Specyfikacja języka VML: www.w3.org/tr/note-vml [17] Specyfikacja języka XUL: http://www.mozilla.org/projects/l10n/xulstyleguide.html [18] Specyfikacja języka XBRL: www.xfrml.org [19] www.geac.com.pl [20] www.esupplychain.pl