Transakcyjność i walidacja danych w XML-u.

Transkrypt

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
języków/aplikacji branżowych/środowiskowych.
specyjalizowanych
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>⁢</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>⁢</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.
<!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
multimedialnych RealNetworks [12] oraz Apple Quicktime [13].
strumieni
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>
t:DUR="10">świata</DIV>
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/xhtml1transitional.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
<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-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.
<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”>
<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.
<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”
</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”
<xsd:field xpath=”@index”
<xsd:field xpath=”@nazwa”
<xsd:field xpath=”@ilosc”
type=”xsd:decimal”/>
<xsd:field xpath=”@jm”
</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.
partner
Dokumenty
elektroniczne
A
producent
Dokumenty
elektroniczne
Firma
C
informatyczna
Dokumenty
elektroniczne
Operacje
gospodarcze
M
Operacje
gospodarcze
Firma
Dokumenty
elektroniczne
N
partner
D
informatyczna
Dokumenty
elektroniczne
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 2wę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
<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”>
<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>
‘[email protected]’
</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

Transakcyjność i walidacja danych w XML-u.

Transkrypt

Podobne dokumenty

XML– zadania 1 Zadanie 1 Stwórz dwa dokumenty XML

Narzędzie wstępnej weryfikacji pliku XML - POL-on

wymagania systemowe - talgos

Schematy XML

pobierz pdf

Uchwała w srpawie wzoru deklaracji za gospodarowanie