pobierz plik referatu - BDAS

Transkrypt

Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Rozdział 19
w
w
Synchronizacja systemów baz danych
w przedsiębiorstwie przy zastosowaniu technologii
SOAP i XML
1 Wstęp
da
.b
w
Streszczenie. Rozdział przedstawia zagadnienie synchronizacji danych
w przedsiębiorstwie posiadającym centralną bazę danych i oddziały
z niezależnymi bazami. Przedstawiono możliwe rozwiązania i napotykane
problemy. Zaproponowano metodę synchronizacji różnych systemów baz
danych z zastosowaniem technologii SOAP do przesyłania danych w oparciu
o dokumenty XML.
pl
s.
Celem rozdziału jest przedstawienie metody synchronizacji systemów baz danych
w przedsiębiorstwie. Zacznijmy od sprecyzowania pojęcia systemy baz danych
w przedsiębiorstwie. Wiele firm działa według schematu centrala – oddziały. W centrali
mieści się przeważnie kierownictwo firmy, główne magazyny, centrala spedycyjna itp.
a przede wszystkim główna baza danych przedsiębiorstwa, w której są przechowywane
wszystkie informacje dotyczące jego działalności. W oddziałach działają bazy danych
przechowujące dane istotne dla funkcjonowania placówki, np. baza lokalnych klientów,
pracowników, stanów magazynowych itp.. Oddziały potrzebują jednak pewnych danych
wspólnych dla całego przedsiębiorstwa takich jak: cenniki, opis oferowanych usług
czy towarów, informacje o rozporządzeniach zarządu. Jako oddziały firmy w tym ujęciu
mogą być traktowani mobilni handlowcy, wyposażeni w urządzenia przenośne (laptopy,
pda), oraz firmy współpracujące, np. ajenci prowadzący sprzedaż towarów lub usług
pod szyldem firmy. Oddziały własne przeważnie używają takiego samego oprogramowania
jak centrala, natomiast inaczej może wyglądać sytuacja ajentów i handlowców. Mogą oni
posiadać różne niż centrala oprogramowanie oparte na innym systemie baz danych. Dzieje
się tak, dlatego że ajenci to oddzielne firmy posiadające już systemy do obsługi
przedsiębiorstwa. Handlowcy też mogą być jednoosobowymi firmami współpracującymi
z różnymi przedsiębiorstwami. W związku z tym muszą oni posiadać oprogramowanie
niezależne od dostawcy produktów. Nie jest również możliwe działanie na dwóch
równoległych systemach informatycznych w jednej firmie, ponieważ spowodowałoby to
Jakub Maciejewski, Marcin Lizis: Uniwersytet Łódzki, Instytut Studiów Informatycznych,
Tomaszów Mazowiecki,
ul. Konstytucji 3 Maja 65/67, 97-200 Tomaszów Mazowiecki, Polska
email:{jakmac, marcinl}@math.uni.lodz.pl
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
J. Maciejewski, M. Lizis
podwojenie pracy i częstokroć brak spójności danych. W takiej sytuacji wdrożenie
firmowego oprogramowania w niektórych oddziałach jest bardzo utrudnione lub nawet
niemożliwe. W takim przedsiębiorstwie mamy do czynienia z różnymi systemami baz
danych, gdyż centrala może korzystać z innego oprogramowania niż oddziały. Ponieważ
zarówno centrala potrzebuje danych od oddziałów jak i oddziały od centrali zachodzi
konieczność synchronizacji lokalnych danych z danymi w centrali.
w
2 Dodatkowe założenia i propozycje rozwiązań
da
.b
w
w
Głównym założeniem stawianym powyższemu zagadnieniu jest korzystanie z baz danych
opartych na języku SQL oraz brak wymogu posiadania tego samego systemu bazy danych
w oddziałach i centrali. Drugą ważną sprawą jest fakt, że oddziały nie modyfikują żadnych
danych współdzielonych, gdyż informacje pobierane z centrali są traktowane jako tylko do
odczytu. Jest to naturalne ograniczenie, ponieważ to w centrali zapadają decyzje na temat
polityki cenowej, oferowanych usług czy też odpowiedniego opisu towarów. Oddziały
muszą jedynie pozyskać te informacje. Dane wysyłane do centrali dotyczą tylko
działalności danej jednostki i pozostałe jednostki nie powinny mieć do nich dostępu.
Konsekwencją powyższych założeń jest to, że nie synchronizujemy całych baz danych
a jedynie ich części. Oddziały nie potrzebują, np. informacji kadrowych z centrali,
podobnie jak nie potrzebują informacji o działalności innych oddziałów. W centrali także
nie jest konieczne posiadanie pełnych informacji o oddziałach, wystarczą tylko dane
niezbędne do prawidłowego funkcjonowania przedsiębiorstwa. Jest to zwłaszcza widoczne
w przypadku ajentów, którzy współpracują z innymi firmami. Zrozumiałe jest, że ajent nie
chce zdradzać szczegółowych informacji na temat współpracy z określonymi dostawcami
innej firmie, z którą współpracuje.
Przy takiej architekturze synchronizacja dokonywana jest okresowo. Nie stawiamy
jednak żadnych warunków w stosunku do ilości wykonywanych sesji synchronizacyjnych,
ani czasu ich wykonywania.
Zagadnienie synchronizacji można rozbić na dwa etapy:
1) wybranie danych do przesłania – w sytuacji gdy centrala i oddział korzystają z takiej
samej struktury bazy danych nie sprawia to większego problemu, kłopoty pojawiają
się w sytuacji, gdy oprogramowanie centrali i oddziału korzysta z różnych baz
danych (problem jest szerzej omówiony w dalszej części rozdziału),
2) przesyłanie danych – transfer danych pomiędzy serwerem i klientem może być
zrealizowany na wiele sposobów; w naszych rozważaniach jako format danych
wybraliśmy standard XML a jako oprogramowanie transferujące mechanizm SOAP.
Pierwszym rozwiązaniem, o którym należy wspomnieć, pomimo nie spełniania
wszystkich założeń jest podłączenie oddziałów do centrali on-line. Wszystkie dane mogą
być przechowywane w centralnej bazie danych, w oddziałach zainstalowane są terminale
które umożliwiają dostęp do danych w centrali. Głównym atutem tego rozwiązania jest to,
że w centrali zawsze są dostępne aktualne dane. Rozwiązanie to posiada jednak kilka
istotnych wad:
1) działanie przedsiębiorstwa jest uzależnione od sprawności centrali. Jeśli nastąpi
awaria łącza lub serwera to całe przedsiębiorstwo łącznie ze wszystkimi swoimi
oddziałami, handlowcami i ajentami nie może wykonywać swych zadań,
2) bardzo często handlowcy nie są w stanie wykonywać swojej pracy, gdyż bywają oni
często pozbawieni możliwości połączenia z siecią,
pl
s.
184
Synchronizacja systemów baz danych w przedsiębiorstwie przy zastosowaniu technologii SOAP i XML
w
3) udostępnienie systemu ajentom wiąże się z zainstalowaniem dodatkowego
oprogramowania w ich firmach,
W tym sposobie w zasadzie nie można mówić o synchronizacji danych a jedynie o ich
przesyłaniu. Transfer zostaje zapewniony przez oprogramowanie terminala.
Kolejnym pomysłem na synchronizację danych jest kopiowanie i przesyłanie całych
tabel z danymi. Jest to rozwiązanie proste implementacyjnie, jednak posiadające szereg
wad:
1) przy każdej synchronizacji wymagane jest przesłanie ogromnej ilości danych, ilość
przesłanych danych jest niewspółmiernie duża do zmian które zaszły w bazie,
2) rozwiązanie to wymaga aby tabele przechowujące dane w centrali i oddziałach miały
tą samą strukturę, aby możliwe było bezpośrednie kopiowanie danych.
Ta metoda może być stosować w oddziałach firmowych, jednakże w przypadku ajentów
może być niemożliwa do zastosowania, ze względu na różną strukturę bazy i możliwe
problemy w jej tłumaczeniu.
Naturalne jest, że w celu ograniczenia ilość przesyłanych danych, należy transferować
tylko informacje o zmianach, jakie zaszły w bazie od momentu ostatniej synchronizacji.
Zaproponujemy dwa sposoby uzyskania informacji o zmianach dokonanych w bazie.
Pierwszy opiera się na idei prowadzenia rejestru operacji modyfikujących dane w bazie.
Zapamiętujemy w oddzielnej tabeli wszystkie instrukcje INSERT, DELETE i UPDATE.
Instrukcji takich po stronie serwera może być bardzo dużo. W związku z tym dla
zmniejszenia wielkości bazy określamy skończony zbiór poleceń SQL modyfikujących
dane i tworzymy z nich szablony zapytań. Szablon różni się od zapytania tylko tym,
że zamiast konkretnych danych ma zdefiniowane zmienne. Dzięki takiemu podejściu
programista aplikacji nie musi pisać pełnego zapytania a jedynie wywołuje odpowiednią
metodę, której parametrami są kod zapytania oraz tablica z wartościami zmiennych.
Wspomniana metoda zajmuje się wykonaniem zapytania oraz umieszczeniem kodu
polecenia i zserializowanych danych w tabeli buforującej. Poza tym po stronie serwera
przechowywane są w osobnej tabeli daty wszystkich sesji synchronizacyjnych
dla każdego oddziału, łącznie z określeniem początkowego i końcowego identyfikatora
pobranego w danej sesji.
Dla danych przesyłanych do centrali konieczne jest transferowanie tylko rejestru zmian,
a następnie wyczyszczenie go lub oznaczenie danych jako pobrane. Dla danych
przesyłanych z serwera bufor nie zmienia swojej zawartości po synchronizacji z jednym
oddziałem. Po sesji synchronizacyjnej zapamiętywane są jedynie informacje o pierwszym
i ostatnim rekordzie przesłanym w sesji, o oddziale, do którego informacja została wysłana
oraz o dacie transferu. Podstawową zaletą tego rozwiązania jest wspomniane już wcześniej
ograniczenie ilości transferowanych danych, oraz łatwość implementacji w oddziałach
firmowych i centrali. Niestety zastosowanie tego rozwiązania w oddziałach ajentów może
nastręczać trudności związane z prowadzeniem rejestru.
Kolejny sposób polega na utworzeniu dwóch kopii danych, jedna jest tworzona podczas
poprzedniej synchronizacji, a druga podczas bieżącej. Informacje o zmianach w bazie
uzyskujemy analizując różnice pomiędzy obiema kopiami. Rezultatem będzie podobnie jak
poprzednio informacja o wszystkich koniecznych operacjach INSERT, DELETE
i UPDATE. Rozwiązanie to jest bardziej pracochłonne od poprzedniego, jednakże
umożliwia uzyskanie informacji o zmianach w dowolnym systemie baz. Oba rozwiązania
zostaną szerzej omówione w dalszej części artykułu.
Poza zdefiniowaniem, które dane i w jakie postaci muszą zostać przesłane istotne jest
również określenie, w jaki sposób będzie się odbywała komunikacja. Mamy tutaj kilka
możliwości rozwiązania problemu:
da
.b
w
w
pl
s.
185
w
1) informacje przesyłane są okresowo za pośrednictwem poczty elektronicznej; serwer
wysyła swoje dane synchronizacyjne regularnie co pewien czas; operator w oddziale
odbiera i wysyła swoje dane ręcznie w momencie nawiązania połączenia z siecią;
2) przesyłanie danych synchronizacyjnych odbywa się za pomocą protokołu ftp –
rozwiązanie analogiczne do poprzedniego;
3) centrala korporacji dostarcza interfejs WWW, gdzie wszyscy współpracownicy
po zalogowaniu się na indywidualne konto mają możliwość pobrania i przesłania
danych synchronizacyjnych;
Zapewnienie poprawnego transportu danych może prowadzić do wielu problemów
związanych z brakiem zdefiniowanego standardu przesyłanych informacji, brakiem
odpowiedniego zabezpieczania danych, itp.. W związku z tym dobrym rozwiązaniem może
być skorzystanie z narzędzi, które zostały już odpowiednio przetestowane i jednocześnie
można je w prosty sposób zaadoptować do konkretnego problemu. Takim standardem
przesyłania danych jest SOAP. Jego głównymi zaletami są:
1) za pośrednictwem SOAP przesyłane są dane XML,
2) przesyłanie danych odbywa się za pośrednictwem bardzo popularnego protokołu
http,
3) komunikacja odbywa się na zasadzie pytanie – odpowiedź, co znacznie upraszcza
obsługę sytuacji wyjątkowych (zagubienie części dokumentu),
4) duży nacisk położony jest na kontrolę poprawności transferowanych informacji oraz
autoryzację,
5) SOAP jest niezależny od platformy systemowej i programowej.
Na rynku oprogramowania istnieje wiele rozwiązań synchronizacji baz danych. Coraz
więcej firm oferujących oprogramowanie dla firm jako standard oferuje możliwość
wymiany danych pomiędzy oddziałami firmy. Także dla starszych wersji swojego
oprogramowania oferują nowe moduły do synchronizacji. Istnieje również szereg firm
specjalizujących się w synchronizacji dla istniejącego oprogramowania firm trzecich.
Przeważnie w takich rozwiązaniach dane wymieniane są on-line lub okresowo przy użyciu
np. poczty elektronicznej. Jednakże posiadają podstawową wadę, wymagają posiadania
takiego samego oprogramowania w centrali i oddziałach, co jest wbrew założeniom
rozważanego problemu. Istnieją również systemy mobilnych baz danych, przeznaczone dla
handlowców. Rozwiązania te współpracują z większością popularnych systemów
zarządzania przedsiębiorstwem, umożliwiając handlowcom przebywającym w terenie
wymianę danych z centralą. Niestety, podobnie jak poprzednio przeznaczone są do
współpracy z jednym systemem w centrali. Proponowane w artykule rozwiązanie
z zastosowaniem technologii SOAP umożliwia w łatwy sposób dostosowanie dowolnych
systemów baz danych do synchronizacji z systemem zainstalowanym w centrali firmy.
da
.b
w
w
pl
s.
3 Przykładowa realizacja
Na potrzeby przykładu załóżmy, że firma sprzedaje pewne towary. W centralnej bazie
przechowywany jest cennik udostępniany oddziałom. Przypuśćmy, że tabela cennik
zawiera następujące dane: identyfikator towaru, nazwę towaru i jego opis. Ponieważ
przedsiębiorstwa powszechnie stosują kodowane oznaczenia swoich wyrobów, możemy
założyć, że id_towaru jest jakimś kodem liczbowym. Identyfikator ten będzie także
kluczem głównym tabeli. Do cennika mają mieć dostęp wszystkie oddziały firmy, zatem
powinna istnieć możliwość wprowadzenia danych zawartych w cenniku, do bazy
obsługującej oddział. Nie jest to problemem dla oddziałów firmowych, ale u ajentów mogą
186
w
pojawić się kłopoty. Podstawowym problemem jest to, że ajent posiada swoją bazę,
w której stosowane mogą być inne oznaczenia, inne typy kolumn oraz inne systemy
oznaczeń towarów. Ponieważ pomiędzy bazami wymieniamy tylko pewne elementarne dla
działalności przedsiębiorstwa informacje, ryzyko nie występowania którejś z nich
w korespondującej bazie jest niewielkie. Trudno jest sobie wyobrazić firmę, która sprzedaje
towar nie stosując jego oznaczenia, nazw i cen, które to występują w przykładzie.
Główny problem może stanowić odmienne kodowanie towarów niż w centrali. W tym
miejscu zastosujemy jedyne rygorystyczne wymaganie: kodowanie u ajenta musi zawierać
kod z centralnej bazy będący jednocześnie kodem w bazie ajenta lub będący częścią kodu
towaru u ajenta. W ostateczności można zawsze zastosować dodatkowy moduł tłumaczący
jedno kodowanie na drugie. Jednakże to rozwiązanie nie jest przedmiotem rozważań.
Do określenia, które dane z centrali należy pobrać stosujemy rozwiązanie oparte
na rejestrowaniu wszystkich operacji modyfikujących dane, które zostało opisane we
wcześniejszej części niniejszego rozdziału. Załóżmy na przykład, że wykonywane jest
zapytanie:
w
w
UPDATE cennik SET nazwa='rękawiczki', opis='Rękawiczki damskie,
skórzane, czerwone' WHERE id='234567';
Zastosowanie mechanizmu buforującego wymaga zdefiniowania szablonu zapytania
w następującej postaci:
da
.b
UCNO=”UPDATE cennik SET nazwa='”.$nazwa.”', opis='”.$opis.”' WHERE
id='”.$id.”'”
Samo wykonanie zapytania wymaga wywołania odpowiedniej metody obsługującej system
buforujący, do której przekażemy kod polecenia SQL oraz konkretne dane, które mają
zastąpić parametry tego zapytania:
$dane=array(„nazwa”=>”rękawiczki”,
”opis”=>”Rękawiczki damskie, skórzane, czerwone”,
„id”=>”234567”);
$baza->wykonajZapytanie(„UCNO”,$dane);
Zadaniem metody wykonajZapytanie() jest wykonanie odpowiedniego zapytania
na właściwej bazie systemowej oraz umieszczenie kodu zapytania i zserializowanych
danych w tabelce buforującej:
pl
s.
„INSERT INTO bufor(kod,dane,czas)
VALUES('”.$kod.”','”.serialize(dane).”',now());”
Centrala potrzebuje natomiast od oddziałów dane na temat sprzedaży. Jeżeli oddziały
pracują na oprogramowaniu dostarczonym przez nas, to oczywiście stosowane jest
rozwiązanie opisane wyżej. Problem pojawia się dopiero w sytuacji, gdy mamy
do czynienia z firmą współpracującą, która korzysta z własnego oprogramowania. W takiej
sytuacji aplikacja synchronizacyjna umieszczona po stronie klienta musi wykonywać
pewne dodatkowe czynności wyłuskujące odpowiednie dane z bazy wewnętrznej firmy.
Informacje o sprzedaży są różnie przechowywane w rozmaitych systemach, jednak
powinny składać się z pewnych podstawowych danych, takich jak: symbol towaru, ilość,
cena sprzedaży i data. Aby rekord dotyczący sprzedaży mógł być jednoznacznie
zidentyfikowany ma określony klucz. Na początku sesji serializacyjnej tworzona jest kopia
bazy, która jest porównywana z bazą z poprzedniej sesji w celu znalezienia różnic.
Przypuśćmy, że u ajenta możliwe jest uzyskanie następujących danych: identyfikator
sprzedaży, symbol towaru, cena, ilość, data. Podczas ostatniej synchronizacji została
utworzona tabela kopia_sprzedaży zawierająca wszystkie aktualne dane, przykładowa
zawartość w tabeli 1.
187
Tabela 1. Przykładowa zawartość tabeli kopia_sprzedaży
ilosc
data
s1
123.
30
100
17-08-2005
s2
124
20
2
17-08-2005
s3
w
125
40
1
18-08-2005
s4
126
50
5
19-08-2005
s5
127
60
3
19-08-2005
w
id_sprzedaży symbol_towaru cena
w
W bazie wystąpiły zmiany:
− sprzedano 6 sztuk towaru 126 w cenie 50 dnia 20-08-2005;
− sprzedano 4 sztuki towaru 128 w cenie 33 dnia 20-08-2005;
− odkryto błąd, którego naprawa pociągnęła za sobą konieczność usunięcia rekordu
o id_sprzedaży równym s3;
− odkryto, że w rekordzie s1 błędnie wprowadzono ilość, skorygowano ją na 10.
da
.b
Podczas kolejnej synchronizacji tworzona jest następna kopia danych umieszczona w tabeli
kopia_sprzedazy_2, o następującej zawartości:
Tabela 2. Przykładowa zawartość tabeli kopia_sprzedaży_2
ilosc
data
s1
123
30
100
17-08-2005
s2
124
20
2
17-08-2005
s4
126
50
5
19-08-2005
s5
127
60
3
19-08-2005
s6
126
50
s7
128
33
pl
s.
id_sprzedaży symbol_towaru cena
6
20-08-2005
4
20-08-2005
Następnie musimy określić różnice pomiędzy kopiami. W tym celu określimy,
które rekordy są nowe, następnie których nie ma i na koniec które się zmieniły.
Nowe rekordy zostaną wypisane jako wynik działania następującej instrukcji SQL:
select * from kopia_sprzedazy_2 where (id_sprzedazy) not in (select
id_sprzedazy from kopia_sprzedazy)
Jako wynik otrzymamy rekordy s6 i s7.
Rekordy usunięte (s3) otrzymamy po wykonaniu:
select id_sprzedazy from kopia_sprzedazy where (id_sprzedazy) not in
(select id_sprzedazy from kopia_sprzedazy_2)
Informacje o zmienionych rekordach (s1) uzyskamy w następujący sposób:
188
select * from kopia_sprzedazy_2 where (id_sprzedazy) in (select
id_sprzedazy from kopia_sprzedazy) and
(id_sprzedazy,symbol_towaru,cena,ilosc,data) not in (select * from
kopia_sprzedazy);
w
Aby synchronizować bazę w centrali z bazą w oddziale, należy przesłać tylko rekordy
do wstawienia, usunięcia i modyfikacji. Dane do przesłania sformatujemy do postaci
szablonu opisanego powyżej, wówczas od strony serwera centrali nie będzie rozróżnienia
czy dane pochodzą od ajenta czy oddziału firmowego. Problemem może być stosowanie
różnych kluczy wyróżniających dane o sprzedaży u ajentów, gdyż w bazie centrali dane
będą przechowywane w jednej tabeli z lokalnym kluczem, oraz dodatkową kolumną
informującą, od którego ajenta pochodzą. Rozwiązanie tego problemu jest stosunkowo
proste, przechowujemy w centrali jeszcze jedną kolumnę zawierającą klucz ajenta.
W przypadku kluczy kilku kolumnowych przesyłamy klucz jako złączenie wartości
wszystkich pól klucza w postaci tekstowej. Wówczas, jeśli otrzymamy informacje,
że należy usunąć rekord o kluczu s3 pochodzący od ajenta X, łatwo go odszukamy
w centralnej bazie danych.
Do przesyłania zastosujemy technologię SOAP. W naszym przykładzie, serwer SOAP
udostępnia dwie metody dajCeny(id_zmian) oraz przeslijSprzedaz(id_oddzialu, dane).
Pierwsza metoda zwraca wszystkie zmiany, jakie wystąpiły w bazie centrali od poprzedniej
synchronizacji. Z tabeli buforującej pobierane są wszelkie modyfikacje cennika. Klient
przesyła informacje o ostatnich pobranych zmianach przez argument id_zmian. Po pobraniu
danych system klienta zapamiętuje ostatni otrzymany identyfikator zmian. Klient otrzymuje
z serwera tablice zawierającą wszelkie modyfikacje zapisane w formacie wzorca.
Metoda przeslijSprzedaz(id_oddzialu,dane) przekazuje do centrali informacje
o zmianach sprzedaży w danym oddziale. Metoda posiada dwa argumenty, pierwszy
to identyfikator oddziału przesyłającego dane, a drugi to tablica zawierająca wszystkie
zmiany od czasu poprzedniej synchronizacji, zapisane w formacie wzorca. Na potrzeby
przykładu stworzono serwer SOAP korzystając z biblioteki NuSOAP dla języka PHP.
Ponieważ technologia SOAP doskonale radzi sobie z przesyłaniem tablic, implementacja
powyższych metod nie nastręcza trudności. Oprogramowanie klienckie może być
stworzone w dowolnej technologii współpracującej z SOAP np. PHP, Java, C# i innych.
Przedstawimy przykładowe wiadomości SOAP obsługujące metodę dajCeny(). Klient
wywołuje metodę dajCeny() z argumentem id_zmian=123. SOAP generuje następującą
wiadomość zapytanie:
da
.b
w
w
pl
s.
POST /serwer3.php HTTP/1.0
Host: 127.0.0.1
User-Agent: NuSOAP/0.7.2 (1.94)
Content-Type: text/xml; charset=ISO-8859-1
SOAPAction: ""
Content-Length: 510
<?xml version="1.0" encoding="ISO-8859-1"?>
<SOAP-ENV:Envelope SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAPENC="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<ns1758:DajCeny xmlns:ns1758="http://tempuri.org">
<id_zmian xsi:type="xsd:string">
123
</id_zmian>
</ns1758:DajCeny>
</SOAP-ENV:Body>
189
</SOAP-ENV:Envelope>
W centrali jedyną zmianą, jaka pojawiła się od zmiany numer 123 to instrukcja UPDATE
prezentowana wcześniej:
UPDATE cennik SET nazwa='rękawiczki', opis='Rękawiczki damskie,
skórzane, czerwone' WHERE id='234567';
w
Instrukcja ta jest zapisana w tablicy bufora zmian w odpowiednim omawianym wyżej
formacie. Serwer w odpowiedzi przesyła tablicę zawierającą zmiany:
w
HTTP/1.1 200 OK
Date: Tue, 10 Jan 2006 18:36:21 GMT
Server: Apache
X-Powered-By: PHP/4.4.0-pl1-gentoo
X-SOAP-Server: NuSOAP/0.7.2 (1.94)
Content-Length: 767
Connection: close
Content-Type: text/xml; charset=ISO-8859-1
da
.b
w
<?xml version="1.0" encoding="ISO-8859-1"?><SOAP-ENV:Envelope SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAPENC="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<ns1:DajCenyResponse xmlns:ns1="http://tempuri.org">
<return>
<id_zmian xsi:type="xsd:int">
124
</id_zmian>
<szablon xsi:type="xsd:string">
UCNO
</szablon>
<dane>
<nazwa xsi:type="xsd:string">
rękawiczki
</nazwa>
<opis xsi:type="xsd:string">
Rękawiczki damskie, skórzane, czerwone
</opis>
<id xsi:type="xsd:string">
234567
</id>
</dane>
</return>
</ns1:DajCenyResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>
pl
s.
Klient korzystając z mechanizmów SOAP odczytuje przesłane dane i otrzymuje
następującą tablicę:
Array ( [id_zmian] => 124
[szablon] => UCNO
[dane] => Array ( [nazwa] => rękawiczki [opis] => Rękawiczki damskie,
skórzane, czerwone [id] => 234567 ) )
Zakończeniem synchronizacji jest wprowadzenie danych do bazy i zapamiętanie ostatniego
identyfikatora zmian id_zmian.
190
4 Podsumowanie
w
Nikogo nie trzeba przekonywać o korzyściach płynących z posiadania aktualnych danych.
W przypadku przedsiębiorstw przekłada się to bezpośrednio na wyniki finansowe.
Współpraca z innymi firmami obniża koszty funkcjonowania, ale utrudnia wymianę
informacji. Zaprezentowane metody wymiany danych pomiędzy bazami danych
są stosunkowo łatwe do implementacji. Technologia SOAP umożliwia skonstruowanie
serwera wysyłającego i odbierającego dane z dowolnego systemu, dlatego tworzenie
oprogramowania klienckiego można zlecić dostawcy oprogramowania danej firmy. Jest to
rozwiązanie zdecydowanie obniżające koszty wdrożenia.
w
Literatura
http://www.w3.org/TR/soap/
http://xml.com/
Kline K., Kline D., Hunt B.: SQL in a Nutshell. O’Reilly 2004.
Ullman J. D., Garcia-Molina H., Widom J.: Systemy baz danych; WNT 2006.
Elmasri E., Navathe S. B.: Wprowadzenie do systemów baz danych; Helion 2005.
da
.b
w
1.
2.
3.
4.
5.
pl
s.
191
w
da
.b
w
w
pl
s.

pobierz plik referatu - BDAS

Transkrypt

Podobne dokumenty

BS Jordanów | Numery telefonów

RECEPCJONISTA - Spółdzielczy Bank Rzemiosła i Rolnictwa

Młodszy inżynier rozwoju produktu

Oferta zakupu

Dokumentacja techniczno - ruchowa

Struktura organizacyjna - Bank Spółdzielczy w Jaworznie

Karta katalogowa centrali alarmowej Dialog 512GSM

część 5

wpraktyce z najlepszymi