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

3Z2 – 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 biznesowych1 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/schematy” 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 BOperacje

gospodarcze

Dokumenty

elektroniczne

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

N BOperacje

gospodarcze

Dokumentyelektroniczne

partner hurtownia

DFirma

informatyczna

Dokumenty

elektroniczne

M AOperacje

gospodarcze

Dokumenty

elektroniczne

partner producent

CFirma

informatyczna

Dokumenty

elektroniczne

Op

erac

je

gosp

od

arcz

eDokumenty

elektroniczne

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/xul-

styleguide.html

[18] Specyfikacja języka XBRL: www.xfrml.org

[19] www.geac.com.pl

[20] www.esupplychain.pl