STUDIA IN FO RM A TIC A Volume 23
2002 N um ber 2B (49)
Michał SW IDERSK I
Politechnika Śląska, Instytut Informatyki
KONCEPCJA OBIEKTÓW SAMODZIELNIE KOMUNIKUJĄCYCH SIĘ Z BAZAMI DANYCH, OSADZANYCH W STRONACH WWW*’
Streszczenie. Artykuł om aw ia popularne im plem entacje fizyczne logicznego m odelu trój w arstw ow ego oraz je d n ą z m ożliw ych ich m odyfikacji. Przedstaw iona je s t także aplikacja w ykorzystująca zaproponow aną koncepcję.
CONCEPT OF OBJECTS INDIVIDUALLY ACCESSING DATABASE, EMBEDDED IN HTML PAGES
Sum m ary. This article describes the m ost popular im plem entations o f logical three-tier m odel and one o f the possible m odifications. There is also presented an application built upon the proposed im plem entation.
1. Wstęp
Jednym z głów nych elem entów projektow ania aplikacji je st określenie architektury systemu, która definiuje, za ja k ą część funkcjonalności odpow iada dana część aplikacji oraz jak części aplikacji w spółdziałają ze sobą. N iniejsza praca skupia się na im plem entacjach
fizycznych logicznego m odelu trójwarstwowego.
Trójwarstw owy m odel logiczny dzieli aplikację na trzy logiczne kom ponenty [I],
1 Praca finansow ana z funduszu Badań Statutowych Instytutu Inform atyki w roku 2002
68 M. Świderski
' U s łu g i p re z e n ta c ji
U s łu g i b iz n e s o w e
V_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
U s łu g i d a n y c h
Rys. 1. Logiczny model trójwarstwow y Fig. 1. Logical three-tier model
U sługi danych - łączą rekordy i utrzym ują integralność bazy danych - np. nakładają ograniczenia na wartości danych w prowadzanych do tabel i w ym uszają zachow anie relacji pom iędzy tabelami.
Usługi biznesow e - stosują reguły i logikę biznesow ą - np. do d ają zgłoszenia do bazy danych, przeprow adzają autoryzację i nadają upraw nienia w systemie.
U sługi prezentacji - im plem entują interfejs użytkow nika i obsługują w prow adzane przez niego dane.
2. Aplikacje trójwarstwowe
Model logiczny nie określa jednoznacznie im plem entacji fizycznej aplikacji, istnieje bowiem wiele sposobów implementacji logicznego m odelu trój w arstw ow ego na fizycznych maszynach. Poniżej zostaną krótko scharakteryzow ane najpopularniejsze im plem entacje fizyczne.
2.1. Fizyczna im plem entacja dwuw arstw owa z “grubym klientem ” (fat client)
C zęstą m etodą tw orzenia aplikacji je st fizyczna im plem entacja dw uw arstw ow a z grubym klientem , gdzie zarówno usługi biznesowe, ja k i prezentacji pracują po stronie klienta. W takiej implementacji serw er pracuje jedynie ja k o serw er bazodanowy.
K oncepcja obiektów sam odzielnie kom unikujących się z bazam i d a n y c h . 69
U s łu g i p re z e n ta c ji
U s łu g i b iz n e s o w e
C--- -5 U s łu g i
1 D a n e j d a n y c h
Rys. 2. Im plem entacja dw uw arstw ow a (gruby klient) Fig. 2. T w o-tier im plem entation (fat client)
By rozdzielić część biznesow ą od kodu prezentacji w sam ym kliencie, m ożna um ieścić kod odpow iedzialny za reguły biznesow e w odrębnym obiekcie C O M lub klasie Java. Jeśli interfejs użytkow nika i obiekt biznesow y pracują na kom puterze klienta, je s t to w ciąż implem entacja dw uw arstw ow a. R ozdzielenie kodu um ożliw i je d n ak pow tórne użycie obiektu w innych zastosow aniach, w ygodniejszą pielęgnację system u oraz um ożliw i łatw e przejście do trój w arstw ow ego m odelu fizycznego opisanego poniżej.
Zalety rozw iązania:
• N arzędzia do tw orzenia tego typu im plem entacji są bardzo zaaw ansow ane i um ożliw iają łatwe tw orzenie tego typu aplikacji.
• Często sytuacją p ożądaną je st, by dane zw iązane z se sją były przechow yw ane po stronie klienta. Jest to sytuacja dom yślana w tej im plem entacji.
W ady rozw iązania:
• U m ieszczenie reguł biznesow ych po stronie klienta zazwyczaj oznacza w zm ożony ruch w sieci, poniew aż dane m u szą być przesłane do klienta, by podjąć decyzje biznesow e.
2.2, Fizyczna im plem entacja dw uw arstw ow a z “grubym serw erem ” (fat server)
W fizycznej im plem entacji dw uw arstw ow ej z grubym serw erem logika biznesow a i usługi danych s ą zaim plem entow ane na serw erze bazodanow ym . W tej im plem entacji logika biznesow a je s t zazw yczaj tw orzona ja k o procedury (ang. stored procedures) i w yzw alacze (ang. triggers) w ew nątrz bazy danych. W iele aplikacji pracujących w przem yśle korzysta z podobnego scenariusza.
70 M. Świderski
U s łu g i p re ze n ta cji
U słu g i b iz n e s o w e
U słu g i d a n y c h
Rys. 3. Im plem entacja dw uw arstw ow a (gruby serw er) Fig. 3. Tw o-tier im plem entation (fat server)
Zalety rozwiązania:
• G łów ną zaletą takiej im plem entacji je st wydajność. Logika biznesow a pracuje w tej samej przestrzeni procesu co kod mający dostęp do danych, w ięc dane nie m uszą być ani przenoszone, ani kopiow ane, co sprawia, że ruch w sieci pom iędzy klientem i serwerem je st zm niejszony.
W ady rozwiązania:
• G łów ną w adą je s t ograniczony zestaw narzędzi do tw orzenia takich aplikacji, ponieważ procedury zazwyczaj m ogą być pisane tylko w języku obsługiwanym przez bazę danych.
2.3. Fizyczna im plem entacja trójwarstwowa
Fizyczna im plem entacja trójw arstw ow a, zwyczajowo określana ja k o “model trój warstwowy", często traktowana je s t błędnie jako jedyna im plem entacja fizyczna logicznego m odelu trójwarstwowego.
W tej im plem entacji logika biznesow a pracuje w oddzielnym procesie, który m oże być skonfigurow any tak, by pracował na serw erze bazodanow ym lub na innym serwerze. Tym , co odróżnia fizyczną im plem entację trójw arstw ow ą od poprzednich im plem entacji, je s t fakt wykonywania usługa danych, biznesowych i prezentacji przez osobne procesy pracujące najczęściej na różnych kom puterach. W iele poważnych aplikacji finansow ych je st zbudow anych w ten sposób.
K oncepcja obiektów sam odzielnie kom unikujących się z bazam i danych .. 71
Rys. 4. Im plem entacja trójw arstw ow a Fig. 4. T hree-tier im plem entation
Zalety rozw iązania:
• N iezależność aplikacji od bazy danych. W iększość fizycznych im plem entacji trój w arstw ow ych korzysta z kilku baz danych w ykorzystując tylko standardow e kom endy SQL.
• N iektóre w ersje im plem entacji o ferują niezależność od ję zy k a program ow ania.
• W niektórych przypadkach fizyczna im plem entacja trójw arstw ow a je s t bardziej skalow alna niż inne im plem entacje. Jeśli kod logiki biznesow ej bardzo obciąża procesor lub pam ięć fizyczną, m ożna um ieścić te procesy na jednym lub w ielu serw erach oddzielnych od baz danych, tak by zm niejszyć obciążenie serw era. Potencjalny w zrost skalow alności zm niejszany je s t jed n ak przez dodatkow y koszt p rzesyłania danych do usług biznesowych.
• Istnieje m ożliw ość dostępu do w ielu baz danych zaw ierających tylko częściow e dane, jednakże takie rozw iązanie m oże w prow adzić ogrom ne kom plikacje w obsłudze danych i
nie je st często stosow ane w przemyśle.
W ady rozw iązania:
• A plikacje tego typu zazw yczaj w ym agają więcej obsługi niż poprzednie im plem entacje.
• Zazwyczaj w artość w spółczynnika ceny do w ydajności aplikacji je s t gorsza od wartości w spółczynnika d la im plem entacji dw uw arstw ow ej z w ykorzystaniem grubego serwera.
2.4. Im plem entacja internetow a
Internet w prow adził now y zw rot w logicznym m odelu trój w arstw ow ym : m ożliw ość rozdzielenia usług prezentacji na przeglądarkę klienta i serw era internetow ego, który je st właściwie odpow iedzialny z a form atow anie stron, które ogląda użytkow nik. Przeglądarka je s t odpow iedzialna za w yśw ietlanie tych stron i ew entualne pobieranie dodatkow ego kodu potrzebnego strom e. D obór m iejsca um ieszczenia usług biznesow ych podlega takim sam ym
72 M . Świderski
zasadom ja k w poprzednim przypadku. Zazwyczaj w im plem entacji internetow ej umieszcza się usługi biznesow e i prezentacji na serwerze internetowym.
P rze g lą d a rk a klienta
U s łu g i p rezen ta cji
U słu g i b iz n e s o w e
C Ż
D a n e v - , —
U słu g i d a n y c h
Rys. 5. Implementacja internetowa Fig. 5. Internet im plem entation
Zalety rozwiązania:
• Każdy klient wyposażony w standardow ą przeglądarkę m oże korzystać z aplikacji, poniew aż cała wymagana od klienta funkcjonalność dostarczana je s t przez standardową przeglądarkę.
• Łatw ość zarządzania aplikacją. Zm iana oprogram ow ania na serw erze internetowym autom atycznie pociąga za sobą zm ianę oprogram ow ania na w szystkich klientach.
Zarządzanie kodem na kilku serwerach je st łatw iejsze niż zarządzanie kodem na wielu klientach.
Wady rozwiązania:
• Podstaw ow e im plem entacje internetowe nie s ą aplikacjam i wysokowydajnym i. (Można jed n ak zwiększyć wydajność takich aplikacji um ieszczając logikę biznesow ą w
procedurach um ieszczanych w bazie danych)
3. Obiekty samodzielnie komunikujące się z bazą danych
Im plem entacja internetow a opisana powyżej je st bardzo uniw ersalna i szeroko stosowana, jednakże dla szczególnej klasy zastosow ań m oże okazać się, że w prow adzenie pewnych m odyfikacji m oże zwiększyć w ydajność aplikacji i jej niezawodność. Je d n ą z możliwych m odyfikacji je st połączenie m odelu internetowego z m odelem grubego klienta.
Koncepcja obiektów sam odzielnie kom unikujących się z bazam i danych . 73
Rys. 6. Połączenie im plem entacji internetow ej z grubym klientem Fig. 6. C om bination o f internet and fat client im plem entations
W proponowanej im plem entacji przeglądarka nie służy ju ż tylko ja k o aplikacja prezentująca w ynik pracy usług prezentacji pracujących na serw erze internetow ym , ale przejmuje na siebie część lub całość pracy zw iązanej z przetw arzaniem danych otrzym anych od usług biznesow ych. Sytuację ta k ą m ożna osiągnąć poprzez w staw ienie w treść strony HTML skryptu lub skom pilow anego obiektu klienta, który potrafiłby im plem entow ać interfejs, obsługiwać żądania użytkownika oraz generować wyniki przetw arzania danych.
Wybór m iędzy zastosow aniem skryptu lub osadzanego obiektu zależy od zadań spełnianych przez konkretną aplikację, jednak w bardziej zaaw ansow anych przypadkach obiekt w ykazuje w iększą stabilność, w iększą w ydajność oraz w iększe m ożliw ości tunkcjonalne, dlatego w łaśnie ten przypadek będzie dalej om awiany [2].
Obiekt klienta pow inien funkcjonow ać na podstaw ie danych zaw artych bądź w treści strony, bądź też pobranych z obiektu biznesowego. D ruga z m ożliw ości w ydaje się jed n ak zasadnie]sza, poniew aż zakładając, że obiekt korzysta z danych zaw artych w treści strony, zakładamy jednocześnie, że strona ta m usi być form atow ana po stronie serw era internetowego, co w ym usza z kolei rozbudow ę w arstw y prezentacji na tym że serw erze.
W świetle poczynionych założeń koncepcja obiektów sam odzielnie kom unikujących się z bazami danych, osadzanych w stronach W W W , przedstaw ia się następująco:
• Aplikacja pow inna korzystać z ogólnie stosow anych technologii internetow ych i współpracować z popularnym i przeglądarkam i.
• W treści strony um ieszczony je s t obiekt, który na podstaw ie danych pobranych bezpośrednio z obiektu biznesow ego obsługuje interfejs użytkow nika oraz m odyfikuje swoje działanie.
74 M. Świderski
3.1. Zalety rozwiązania
3.1.1. Wydajność aplikacji
• D la pewnej klasy zadań korzystniejsze je st przesłanie danych potrzebnych do wygenerow ania wyniku niż przesłanie sam ego wyniku. D zieje się tak często w przypadku wykresów, dla których rozm iar danych potrzebnych do jego w ykreślenia m oże być kilkakrotnie mniejszy od rozm iaru pliku graficznego prezentującego wykres.
• W proponowanej koncepcji istnieje m ożliw ość jednorazow ego załadow ania danych i zapam iętania ich w pam ięci podręcznej. Jeżeli aplikacja byłaby zm uszona pobrać dodatkowe dane, m oże pobrać tylko brakujące, a nie w szystkie, ja k w klasycznym przypadku, co w znaczący sposób m oże zm niejszyć ruch w sieci.
• Skom pilow any obiekt pracujący w przeglądarce m oże pracow ać w ydajniej niż analogiczny kod um ieszczany zazwyczaj jako skrypt po stronie serw era internetow ego.
• Przeniesienie usług prezentacji z serwera internetowego do przeglądarki m oże w znaczący sposób odciążyć serw er internetowy.
3.1.2 Niezawodność i bezpieczeństwo
• Skom pilow any obiekt podlega awariom znacznie rzadziej niż interpretow any skrypt [3].
• Technologie obiektów osadzanych um ożliw iają podpisyw anie kodu, dzięki czemu użytkownik ufający danem u producentowi oprogram ow ania m oże być pew ien, że aplikacja będzie działać prawidłowo.
3.1.3. Zaawansowany interfejs użytkownika
• Dzięki um ieszczeniu w ciele strony skom pilowanego obiektu m ożliw e je s t tworzenie interfejsu użytkownika o funkcjonalności odpowiadającej aplikacjom system owym .
• Przechowyw anie danych w pamięci podręcznej um ożliw ia zapis danych wejściow ych i wynikowych na kom puterze klienta w różnej formie.
3.1.4. Możliwość rozbudowy
• Proponow ana koncepcja m oże być dowolnie łączona z innymi im plem entacjam i modelu trójwarstw owego. Obok siebie może w ięc funkcjonować klasyczny m odel internetowy oraz proponowany przez autora.
Koncepcja obiektów sam odzielnie kom unikujących się z bazam i d a n y c h .. 75
3.2. W ady rozw iązania
3.2.1. Wymagania programowe
Proponowana im plem entacja narzuca duże w ym agania program ow e zarów no na serw er internetowy, ja k i na przeglądarkę. Zazwyczaj podstaw ow a konfiguracja serw era internetowego nie w ystarcza, poniew aż m usi on m ieć m ożliw ość odpow iedzi na żądania obiektu i przesyłania danych żądanych przez obiekt klienta ja k o strum ień bitowy.
3.2.2. Ograniczona przenośność
W zw iązku z dużym i wym aganiam i program ow ym i przenośność podobnego rozw iązania może być ograniczona.
3.2.3. Utrudnione zarządzanie aplikacją
Każdorazow a zm iana w kodzie obiektu pociąga za so b ą konieczność pobrania now ej jego wersji z serw era internetowego.
4. Praktyczna realizacja koncepcji
Do im plem entacji proponow anej koncepcji użyto serw era internetow ego IIS w w ersji 5.0 pracującego pod k o ntrolą system u W indow s 2000 Professional. O biekt osadzany w ciele strony został zaim plem entow any ja k o kontrolka A ctiveX pobierana przez przeglądarkę z serwera internetowego. Zastosow anie technologii A ctiveX ogranicza uniw ersalność rozwiązania, poniew aż nie w szystkie przeglądarki internetow e potrafią j ą obsłużyć, jed n ak zapewnia stabilność aplikacji oraz d u żą w ydajność. Spow odow ane je s t to faktem , że kod kontrolki A ctiveX kom pilow any je s t do postaci binarnej, podczas gdy bardziej uniw ersalne rozwiązania stosują kod w postaci bajtow ej, co niekorzystnie w pływ a na w ydajność i stabilność tych rozw iązań. Technologia dostępu do bazy danych zostanie opisana poniżej.
4.1. K om unikacja obiektu z bazą danych
Do kom unikacji obiektu A ctiveX klienta z b azą danych w ykorzystano m echanizm Remote D ata Service (RD S), który w ykorzystuje zbiór kom ponentów dostarczanych z biblioteką M icrosoft D ata A ccess C om ponents (M D AC ) [4],
RDS pozw ala aplikacjom na dostęp do źródeł O LE D B, pracujących na odległych komputerach. Użycie RDS m oże być przedstaw ione na przykładzie:
A. Użytkownik w prow adza adres strony startowej aplikacji.
76 M. Świderski
B. Żądanie użytkownika je st tłum aczone na żądanie H TTP i w ysłane przez przeglądarkę do serwera W W W .
C. Użytkow nik otrzym uje stronę HTM L z um ieszczoną kontrolką obiektu, która zawiera kontrolkę RDS D ata Control.
D. Użytkow nik za pom ocą interfejsu kontrolki obiektu określa rodzaj zadania, które m a być wykonane, kod obiektu decyduje, ja k ie dane należy pobrać z serw era, a RDS Data Control kom unikuje się z serwerem poprzez standardow e protokoły, takie jak : HTTP i D CO M , zgłaszając żądanie.
E. Kom ponent RDS um ieszczony na serw erze spraw dza upraw nienia i ewentualnie wykonuje żądanie użytkownika i tw orzy ja k o wynik obiekt AD O Recordset, który jest zm ieniany w strum ień binarny i wysyłany do klienta.
F. N a kom puterze klienta obiekt R ecordset je s t odtw arzany w ew nątrz kom ponentu RDS.
K ontrolka obiektu operuje na standardowych strukturach danych i generuje wynik.
G. Ewentualne zm iany w obiekcie Recordset m ogą być przesłane z pow rotem do bazy danych na serw erze poprzez kontrolkę RDS.
Technicznie proces kom unikacji wygląda to następująco:
A. Żądanie generowane przez RDS.D ataControl konw ertow ane je st na żądanie H TTP przez obiekt RD S.D ataSpace i wysyłane do serwera.
B. N a serwerze kom ponent RDS ADISAPI m apuje żądania H TTP na m etody wywołujące i sterujące obiektem RDS.DataFactory.
C. RD S.D ataFactory tworzy obiekt R ecordset i pobiera do niego dane poprzez bezpośrednie odw ołania do źródła OLE DB.
D. Pozyskany obiekt Recordset je s t szeregow any w strum ień binarny poprzez OLE DB Persistence provider (M SPersist).
E. Ze strum ienia w obiekcie Cursor Engine odtw arzany je s t obiekt R ecordset, który następnie przesyłany je st do RDS.DataControl.
Koncepcja obiektów sam odzielnie kom unikujących się z bazam i danych .. 77
Rys. 7. K om unikacji z b az ą danych za p om ocą RDS Fig. 7. C om m unication w ith data base using RDS
4.2. Zadania obiektu klienta
Obiekt klienta zbudow any zgodnie z zaproponow aną koncepcją w chodzi w skład system u monitorującego stan rzeki Odry. D o zadań obiektu należy:
• umożliwienie w yboru punktu pom iarow ego na hierarchicznym m enu m ap Polski oraz udostępnienie w form ie graficznej ostatnich pom iarów na tejże m apie;
• umożliwienie określenia, z jakiego okresu interesują użytkow nika pom iary;
• prezentacja pom iarów w formie:
- konfigurow alnych w ykresów dw u- i trójw ym iarow ych, - tabelarycznej,
- wydruków na drukarce;
• zapis pom iarów na dysku klienta;
• wykrywanie stanów aw aryjnych w punktach pom iarowych;
• wykreślanie profilu rzeki w danym m om encie czasowym .
M. Świderski
Rys. 9. Zakładka wykresu obiektu klienta Fig. 9. C lient’s object chart tab
O biekt klienta implementuje bardzo bogaty interfejs użytkownika. Z akładka startowa um ożliw ia wybór obszaru Polski, a następnie punktu pom iarow ego. Z punktem pomiarowym stow arzyszona je st jego fotografia oraz aktualny stan.
L u W - t i 1 O U.M TW ] 1 A 4nv| |W U * * w s i n * i |
Rys. 8. Zakładka startowa obiektu klienta Fig. 8. C lient’s object startup tab
Zakładka prezentująca pomiary um ożliw ia obserwację pom iarów z zadanego przez użytkownika okresu. Dostępne są funkcje skalow ania wykresu, w ycinania serii, wyboru sposobu prezentacji na wykresie i wiele innych.
4.3. Prezentacja obiektu klienta
Koncepcja obiektów sam odzielnie kom unikujących się z bazam i danych . 79
Zakładka prezentująca profil rzeki um ożliw ia porów nanie całościow ego stanu rzeki z jego stanem podczas pow odzi. W ykres taki dostarcza hydrologom inform acji ogólnych (ryzyko powodzi) i szczegółow ych (szybkość przem ieszczania się fali pow odziow ej).
Fig. 10. R iver profile tab
4.4. Ocena im plem entacji
Zaimplementowany system działa zgodnie z oczekiw aniam i. Do szczególnie wyraźnych zalet należą:
• Stabilność - obiekt klienta działa bez zarzutu m im o bogatego interfejsu i dużej ilości obliczeń przez niego przeprowadzanych.
• Niskie obciążenie sieci:
- obiekt przechow uje dane w pam ięci podręcznej, przez co nie m usi ich w ielokrotnie pobierać z serwera,
- w w ielu sytuacjach potw ierdza się teza, że oszczędniej je s t pobrać dane do wykreślenia w ykresu niż gotow y wykres w form ie pliku graficznego. D la rzeczywistego profilu rzeki obiekt klienta pobiera 4,3 kB danych, natom iast odpow iadający m u plik graficzny w form acie g if zajm uje 15,8 kB, zatem proporcja wynosi ponad 3,6 na korzyść proponow anego rozw iązania.
Do wad należą:
• Wysokie w ym agania program ow e, tj: ja k o serw er internetow y m oże być wykorzystyw any jedynie M icrosoft IIS, jako przeglądarka jedynie Internet Explorer.
• Pokaźnych rozm iarów obiekt klienta, który należy pobrać z serw era internetow ego.
80 M. Świderski
5. Wnioski
Standardow a im plem entacja m odelu trójw arstw ow ego dla sieci internet je s t wystarczająca dla w iększości popularnych zastosowań, jednakże dla specjalizow anych aplikacji warto ją m odyfikow ać, tak by uzyskać szczególnie pożądane właściwości.
Przedstawiona koncepcja m oże być z pow odzeniem stosow ana do budowania w ydajnych aplikacji, m oże także wchodzić w skład w iększych projektów . Zauw ażone wady m ożna zneutralizow ać rozbudow ując sam ą koncepcję oraz dobierając odpow iedni zestaw technologii zastosow anych do jej im plementacji.
LITER A TU R A
1. M icrosoft SQL Server Developer’s Resource Kit, M SDN July 1999.
2. Campbell B., Darnell R.: Dynamic HTML. Helion, Gliwice 1998.
3. Lalani S., Chandak R.: ActiveX. Biblioteka programisty. M ikom , W arszawa 1997.
4. M icrosoft Data Access Com ponents 2.5 SDK Beta - Technical A rticles, M SDN July 1999.
Recenzent: D r inż. A rkadiusz Sochan
W płynęło do Redakcji 8 kw ietnia 2002 r.
Abstract
This paper describes different im plem entations o f the logical three-tier m odel giving both advantages and disadvantages o f each option.
At first, it introduces a physical tw o-tier im plem entation w ith fat clients, where the business logic and presentation services run on the client side (see Fig.2). A primary advantage o f this fat client im plem entation is that the tools that support it are pow erful and well established. The second im plem entation is that w ith a fat server, w here business logic and presentation services are deployed from the server database (see Fig.3). In this im plem entation, business logic is m ainly written as stored procedures and triggers w ithin the database. The third described im plem entation is the physical three-tier im plem entation (see Fig-4) that offers an advantage o f database independence. Then, we m ove to Internet
Koncepcja obiektów sam odzielnie kom unikujących się z bazam i d a n y c h . 81
implementation (see Fig.5) w hich a key advantage is that anybody who has a brow ser client can access these applications.
From a com bination o f the Internet and fat client im plem entations w e derive a new one (see Fig.6), w hich w e take a closer look at. The paper discusses this case m ore thoroughly, showing num erous strengths and w eaknesses o f this im plem entation. The key advantages o f the concept are: perform ance, stability, security and advanced user interface.
The last section presents an exam ple o f an application built upon the proposed implementation.
