V Konferencja PLOUG
Zakopane
Paz
dziernik 1999
Integracja aplikacji opartych na Forms 5.0 z narzędziem
do prezentowania map  MapInfo Professional
Tomasz Ostrowski
[e-mail]
Instytut Technik Telekomunikacyjnych i Informatycznych, Poznań
Autor
Absolwent Akademii Techniczno-Rolniczej w Bydgoszczy. Od roku członek Zespołu Systemów
Informatycznych i Multimediów, Instytutu Technik Telekomunikacyjnych i Informatycznych w Poznaniu.
Streszczenie
MapInfo jest popularnym programem do prezentowania i przetwarzania danych geograficznych. ITTI
w ramach realizacji systemu informatycznego do zarządzania firmą opracowało technikę integracji MapInfo
Professional z aplikacjami stworzonymi przy użyciu Forms 5.0. Prezentowane rozwiązanie opiera się
specjalne do tego celu zaprojektowanym komponencie ActiveX wykorzystującym możliwości serwera OLE
udostępniane przez MapInfo od wersji 4.0. W efekcie - użytkownik za pośrednictwem aplikacji zarządzania
może przeglądać, modyfikować, drukować mapy oraz wykonać na nich szereg operacji specyficznych dla
wzmiankowanego systemu zarządzania. Wiele firm i instytucji w Polsce używa już MapInfo do różnych
celów i zapewne byłyby zainteresowane wykorzystaniem jego możliwości z poziomu innych aplikacji.
1. Wstęp
Autor niniejszego artykułu miał przyjemność uczestniczyć w pracach nad tworzeniem systemu do
zarządzania wynajmem tablic ogłoszeniowych dedykowanego firmie o ogólnopolskim zasięgu. Powstający
system miał stanowić jednolitą platformę realizującą funkcje spełniane wcześniej przez osiem różnych
aplikacji oraz udostępniać nowe funkcje wyspecyfikowane przez klienta. Do wizualizacji położenia tablic
ogłoszeniowych na planach miast klient używał programu MapInfo Professional (w chwili rozpoczęcia prac
nad systemem w użyciu były wersje 3.0 i 4.0 programu). Nowy system miał przejąć między innymi funkcje
MapInfo. Rdzeń systemu miał być oparty na rozwiązaniach firmy Oracle. Dane przechowuje centralna baza
danych (System Zarządzania Bazą Danych Oracle 8.0.5), do których dostęp jest realizowany za pomocą
aplikacji klienckiej stworzonej w środowisku Developer/2000. Do opracowania aplikacji użyto Oracle Forms
5.0. Aplikacje tworzone z użyciem Oracle Forms 5.0 mogą zostać wyposażone w zdolność współpracy z
komponentami ActiveX. Aplikacja taka może też być klientem OLE.
Jako ogniwo pośredniczące w komunikacji między aplikacją a MapInfo Professional wykorzystano
komponent ActiveX własnej produkcji. Jakkolwiek wspomniany komponent powstał na potrzeby
konkretnego systemu  zaprojektowano go tak aby można go było w przyszłości wykorzystać w innych
aplikacjach.
2. Opis rozwiązania
Prezentowane rozwiązanie jest oparte na technologii OLE. MapInfo Professional oferuje możliwości
serwera OLE od wersji 4.0. Pakiet udostępnia jeden obiekt OLE, który może zostać wykorzystany do
sterowania MapInfo z innej aplikacji zgodnej z OLE. Producent MapInfo proponuje pakiet w dwóch
wersjach: wersja pełna sprzedawana pod nazwą MapInfo Professional (jest to w pełni wyposażona aplikacja
dla MS Windows), oraz wersja MapInfo Runtime  obejmująca wszystkie funkcje oferowane przez pełną
wersję, ale całkowicie pozbawiona interfejsu graficznego (wersja Runtime jest dedykowana właśnie
systemom nastawionym na wykorzystanie możliwości MapInfo, które realizują własny interfejs użytkownika
lepiej przystosowany do potrzeb klienta). Zastosowanie wersji Runtime pozwoliłoby na obniżenie kosztów
systemu (koszt MapInfo przypadający na jedno stanowisko jest ponad 2-krotnie niższy przy zastosowaniu
wersji Runtime).
Dzięki temu że zdecydowano się na integrację systemu z MapInfo w oparciu o technologię OLE, uzyskano
następujące korzyści:
" Pełna integracja systemu z MapInfo. Aplikacja kliencka systemu udostępnia możliwość przeglądania i
modyfikowania map wprost w oknie aplikacji (oczywiście przetwarzanie map jest realizowane przez
MapInfo, ale pozostaje ono  aktorem poza sceną ). Jest to wykorzystanie idei Visual Editing leżącej u
podstaw OLE.
" Użytkownicy systemu w firmie klienta nie muszą zmieniać przyzwyczajeń, nawigowanie w oknie
udostępniającym funkcje MapInfo jest zbliżone do pracy z MapInfo.
2
" Dzięki integracji system udostępnia nowe funkcje, których samo MapInfo nie realizuje (są to np. funkcje
realizujące powtarzalne, czasochłonne sekwencje czynności, funkcje prezentujące na mapach obiekty
wybrane z bazy danych według dowolnych kryteriów itd.
" Zastosowanie MapInfo pozwala na bezbolesne przejście od jednego systemu do drugiego  używane
przed wprowadzeniem nowego systemu mapy mogą zostać wykorzystane wprost w nowym systemie
(nie jest wymagana żadna konwersja ani inne modyfikacje map, ponieważ obowiązek przetwarzania map
nadal spoczywa na MapInfo, chociaż pośrednikiem jest nowa aplikacja)
Dzięki temu że MapInfo jako serwer OLE udostępnia praktycznie wszystkie swoje możliwości klientom
OLE  nie było ryzyka że nie uda się usatysfakcjonować klienta jeśli nie udałoby się zrealizować wszystkich
funkcji MapInfo.
3. Komponent MapiX
MapiX jest komponentem ActiveX umożliwiającym wykorzystanie możliwości MapInfo Professional
(w wersji 4.0 lub póz
niejszej) przez dowolną aplikację która może być klientem OLE. Początkowo zakładano
wykorzystanie możliwości MapInfo Professional bezpośrednio z klienta Forms 5.0 (aplikacje Forms mogą
być klientami OLE). W fazie projektowania rozwiązania okazało się, że korzystne byłoby wykorzystanie
przewidzianej przez producenta MapInfo możliwości definiowania narzędzi użytkownika. Technika narzędzi
użytkownika w MapInfo opiera się na tzw. OLE Callbacks. Definiowanie narzędzia użytkownika składa się z
dwóch kroków:
1. Rejestracja interfejsu IDispatch, który będzie otrzymywał powiadomienia o zdarzeniach
powodowanych przez użytkownika. Dla implementacji MapiX interesujące było tylko jedno
zdarzenie  użyto narzędzia użytkownika . W każdej chwili MapInfo pozwala na zarejestrowanie
najwyżej jednego takiego interfejsu.
2. Właściwa rejestracja narzędzia użytkownika. MapInfo pozwala na obsłużenie narzędzia
użytkownika przez inną aplikację. Składnia definicji narzędzia użytkownika obejmuje m. in.:
" Nazwę metody która ma zostać wywołana jeśli użytkownik użyje narzędzia. Między innymi można
zażądać, żeby użycie narzędzia powodowało wywołanie OLE Callback  w takim razie kiedy
narzędzie zostanie użyte MapInfo podejmie próbę wywołania metody o podanej nazwie z interfejsu
zarejestrowanego w punkcie 1.
" Tryb rysowania (np. linia, okrąg, punkt)
" Typ kursora skojarzonego z narzędziem
3
 Obiekt MapInfo.Application
OLE Callbacks Metody (interfejs IMapInfo)
Komponent MapiX
Zdarzenia komponentu Metody (interfejs DMapiX)
Klient OLE
Rys. 1 Komunikacja między aplikacją Forms a obiektem MapInfo.Application
Jak powiedziano wyżej  aby obsłużyć narzędzie użytkownika MapInfo, trzeba zarejestrować interfejs
IDispatch przez który MapInfo prześle powiadomienia o zdarzeniach drogą wywoływania metod interfejsu.
Aplikacja która udostępnia interfejs IDispatch jest serwerem OLE. Niestety aplikacje oparte na Forms 5.0 nie
mają takich możliwości. Oznacza to, że przy wykorzystaniu MapInfo jako serwera OLE bezpośrednio z
klienta Forms 5.0 możliwa byłaby komunikacja tylko w jedną stronę (wywoływanie metod udostępnianych
przez interfejs IMapInfo). Aby umożliwić wykorzystanie techniki narzędzi użytkownika zdecydowano się
zastosować komponent ActiveX. Aplikacje stworzone w Forms 5.0 mogą być kontenerami OLE (to znaczy 
można w nich osadzać obiekty ActiveX). Kontener OLE może wywoływać metody komponentu, ma dostęp
do jego własności oraz, co ma szczególne znaczenie z punktu widzenia prezentowanego rozwiązania, może
obsługiwać zdarzenia generowane przez komponent. Z kolei komponent ActiveX z definicji jest serwerem
OLE, to znaczy może udostępniać metody przez interfejs IDispatch.
Wobec powyższego  możliwe jest zrealizowanie dwustronnej komunikacji z wykorzystaniem
komponentu pośredniczącego ActiveX.
Ostatecznie rozwiązanie oparto o komponent ActiveX owijający funkcje MapInfo. Komponent
otrzymał nazwę MapiX. MapiX w szerokim zakresie wykorzystuje technikę określaną w specyfikacji COM
jako containment/delegation (zawieranie/delegacja)  wiele z funkcji komponentu sprowadza się do
przekazywania wywołań bez żadnej obróbki do obiektu MapInfo.Application. Komponent wykorzystuje też
aktywację in-place  udostępnia powierzchnię swojego okna tak, że MapInfo może wyświetlać na niej obraz
mapy.
Komponenty ActiveX (zwane dawniej OLE controls) stanowią przykład elastyczności standardu COM.
Są to autonomiczne kontrolki oparte na standardzie COM których idea powstała długo po wejściu tego
standardu w wiek dojrzały. Technologia ActiveX stanowi przedłużenie i rozwinięcie technologii Visual
Basic Controls (VBX). Metody i właściwości wspomnianych komponentów są udostępniane przez interfejsy
zgodne ze standardem COM. Komponent ActiveX może działać tylko wyłącznie w kontekście innej
aplikacji. Aplikacja taka dla celów komunikacji z komponentem utrzymuje tzw. kontener OLE, w którym
zostanie umieszczony komponent ActiveX. Za pośrednictwem kontenera aplikacja uzyskuje dostęp do
4
własności komponentu (odzwierciedlających jego stan) a także może wywoływać jego metody udostępniane
za pośrednictwem (często wielu) interfejsów. Technologia ActiveX jest rozwijana od przełomu lat 1995/96 i
nierozerwalnie wiąże się z Internetem. W ramach ActiveX zdefiniowano takie pojęcia jak dokumenty
złożone (compound documents), Automation, itd.
4. Zalety technologii COM na przykładzie prezentowanego
komponentu
Komponent MapiX pokazuje jedną z podstawowych zalet technologii opartych na COM 
skomplikowany obiekt realizujący przetwarzanie map stworzony przez jednego producenta
(MapInfo.Application) współpracuje z aplikacją stworzoną za pomocą narzędzi innego producenta (Oracle
Forms 4.5), zaś pośredniczeniem w tej współpracy zajmuje się komponent stworzony przez autora niniejszej
pracy. Z powyższego widać że COM oraz technologie na nim oparte (między innymi OLE  w przypadku
prezentowanego rozwiązania) zapewniają możliwość korzystania w jednolity sposób z usług obiektów
niekoniecznie stworzonych przez jednego producenta. Wobec tego  jeśli zachodzi potrzeba wzbogacenia
oprogramowania o nowe funkcje  można to uczynić nabywając gotowe obiekty innego producenta które
realizują te funkcje. Korzyść jest obustronna  potencjalni nabywcy komponentów rozwijanych w oparciu o
standard zyskują możliwość bardzo łatwego rozszerzania swoich produktów, zaś producentom łatwiej jest
sprzedać komponenty, jeśli sposób korzystania z ich usług jest przemysłowym standardem. Standard
rozwiązuje także problem wersji  zastrzegając że nowa wersja komponentu zawsze musi zachowywać
zgodność ze starą; wprowadzanie nowej wersji komponentu wiąże się na ogół z dodaniem nowych
interfejsów do komponentu  modyfikacje interfejsu obiektu takie jak zmiana porządku metod, czy usunięcie
metody są niedozwolone. Z punktu widzenia producentów komponentów COM i pochodne technologie mają
tę zaletę, że komponenty COM są dystrybuowane w postaci binarnej (COM definiuje binarny standard
zgodności komponentów), bez kodu z
ródłowego co automatycznie rozwiązuje problem własności
intelektualnej (nie ma możliwości bezprawnego użycia kodu z
ródłowego komponentu  nie ma potrzeby
rozprowadzania kodu z
ródłowego z komponentem). COM jest standardem o ustalonej pozycji i bardzo
dużym stopniu penetracji rynku produktów dla MS Windows. Wszystkie liczące się aplikacje dla MS
Windows opierają się na OLE. Duże aplikacje są projektowane jako szereg niezależnych komponentów
(aplikacje w rodzaju MS Word rejestrują kilkanaście obiektów OLE, mniejsze aplikacje typowo rejestrują
jeden obiekt zwany Application  tak jest w przypadku MapInfo), zarządzanych przez główną aplikację.
COM stanowi model programowania obiektowego dedykowany współdziałaniu oprogramowania, to
znaczy: umożliwia on dwóm lub więcej aplikacjom (komponentom) łatwą współpracę nawet jeśli zostały one
stworzone w przez różnych producentów, w różnym czasie, w różnych językach programowania a nawet dla
różnych systemów operacyjnych. Aby umożliwić taką współpracę w ramach COM zdefiniowano i
zrealizowano mechanizmy które pozwalają aplikacjom komunikować się z innymi aplikacjami traktowanymi
jako obiekty (specyfikacja COM używa pojęcia software objects). Obiekt w rozumieniu COM jest określony
przez funkcje które może realizować oraz przez stan (struktura danych związana z obiektem). Innymi słowy
 COM, podobnie jak API w tradycyjnych systemach, dostarcza funkcji za pomocą których odbiorca jakiejś
usługi (klient) może nawiązać połączenie z dostawcą (dostawcami) usług (szczegóły implementacyjne usługi
5
są niejawne dla klienta  istotne jest tylko aby w ramach usługi klient otrzymał dokładnie to czego się
spodziewa, bez względu na to w jaki sposób zostanie ona zrealizowana). Inaczej niż w tradycyjnych
systemach  w chwili kiedy połączenie zostało już nawiązane rola COM się kończy. COM umożliwia
połączenie klienta i obiektu świadczącego usługę, ale kiedy połączenie już istnieje klient i usługodawca
komunikują się bezpośrednio bez pośrednictwa centralnego API.
Jak wiele współczesnych technologii COM opiera się na modelu klient-serwer. Przez
klienta w tym kontekście należy rozumieć aplikację korzystającą z usługi dostarczanej przez obiekt COM. Z
kolei usługodawcę określa się jako serwer COM. Na ogół obiekty COM w zależności od doraz
nych potrzeb
spełniają na przemian rolę klienta lub serwera COM.
Intencją przyświecającą tworzeniu COM było zapewnienie zbioru technologii umożliwiających
budowanie niezawodnych grup usług zarówno w systemach jak w aplikacjach przy założeniu że tak usługi
jak i usługobiorcy (klienci) mogą zmieniać się w czasie. Wobec tego COM sprawia, że tworzenie, używanie
oraz ewolucja odbywająca się bez koordynacji (tj. np. bez porozumień między producentami
oprogramowania) obiektów są możliwe. Celem COM nie było stworzenie modelu programowania, który
sprawiłby że programowanie stałoby się znacznie prostsze  w istocie niektóre ostre wymagania nałożone na
model sprawiają, że może wydawać się on złożony. Z drugiej strony COM stanowi podstawę dla rozszerzeń
zorientowanych na łatwość użycia, bazę dla przyjaznych środowisk tworzenia oprogramowania, itd.
Budowa oprogramowania w oparciu o komponenty oparte na standardzie COM umożliwia między
innymi osiągnięcie następujących korzyści:
modularna struktura oprogramowania umożliwia łatwą rozbudowę (dodawanie nowych funkcji) a także
modyfikowanie starych funkcji
unifikacja sposobów komunikacji między komponentami czyni integrację niezależnych produktów
realną
wykorzystanie gotowych, dostępnych komercyjnie rozwiązań jest na ogół bardziej opłacalne niż
rozwijanie wszystkich niezbędnych dla aplikacji modułów własnymi siłami (znikają koszty
wyczerpującego projektowania i testowania modułów oprogramowania)
nie ma znaczenia w jakich językach programowania zostały stworzone moduły składające się na
aplikację
COM nie stanowi środowiska rozwijania aplikacji. Został pomyślany jako architektura umożliwiająca
integrację usług świadczonych przez obiektowe oprogramowanie. Aplikacja stworzona w zgodzie ze
standardem może korzystać z niemałego już potencjału komponentów opartych na standardzie. Oracle Form
Builder 5.0 oferuje częściową zgodność ze standardem COM. Aplikacje stworzone przy użyciu Form Builder
mogą być klientami COM  nie mogą spełniać funkcji serwerów. Niniejszy artykuł opisuje rozwiązanie
umożliwiające zniesienie ograniczeń wynikających z ograniczenia możliwości aplikacji Forms do klienta
OLE.
Każda z usług COM jest dostarczana przez konkretną aplikację zwaną serwerem. Usługa angażuje
przynajmniej jeden komponent COM. Przykładami obiektów COM są Word.Basic (związany z Microsoft
6
Word) oraz MapInfo.Application, z tym ostatnim współpracuje komponent MapiX. Logicznie powiązane
metody i własności są organizowane w grupy zwane interfejsami. Komunikacja pomiędzy obiektami odbywa
się wyłącznie za pośrednictwem interfejsów. Interfejs COM jest niezależny od szczegółów
implementacyjnych obiektu COM. Standard gwarantuje, że zmiana implementacji obiektu (dodanie nowych
cech czy też ulepszenie istniejących metod) może nastąpić tylko na zasadzie zachowania kompatybilności w
dół (to znaczy: aplikacje i komponenty przystosowane do współpracy ze starszą wersją będą funkcjonować
nadal bez przeszkód). W ramach standardu definiuje się pojęcie kontraktu  usługobiorca spodziewa się
określonego zachowania po usługodawcy, to zaś w jaki sposób usługa zostanie wykonana (szczegóły
implementacyjne) nie jest mu znane i nie stanowi przedmiotu kontraktu. Zarejestrowanie obiektu COM w
systemie (odzwierciedlone w rejestrze systemowym) jest jednoznaczne z ogłoszeniem dostępności usługi
oferowanej przez obiekt.
5. MapiX w akcji
Opisywany komponent z powodzeniem został zastosowany w aplikacji opracowanej przez ITTI na
potrzeby firmy o ogólnopolskim zasięgu zajmującej się reklamą zewnętrzną. Implementacja obejmuje dwie
grupy funkcji:
I. Proste funkcje MapInfo
W tej grupie plasują się funkcje które mają za zadanie umożliwić programiście opierającemu swoją
aplikację na MapiX dostęp do komend z menu MapInfo. Komponent w aktualnej wersji nie obejmuje
wszystkich komend z menu MapInfo, lecz ich podzbiór określony autorytatywnie przez autora niniejszej
pracy. Nie ma technicznych przeszkód aby komponent realizował wszystkie funkcje - wywołanie
funkcji z menu MapInfo polega bowiem na wywołaniu metody IMapInfo::RunMenuCommand z
argumentem identyfikującym pożądaną metodę.
7
Rys. 2 Przykład zastosowania komponentu. Widoczne okno z mapą oraz okno podglądu wydruku (w
tle)
II. Funkcje złożone
Do tej grupy należą np. funkcje mające na celu automatyzację żmudnych, powtarzalnych czynności,
oraz te funkcje które wykorzystują dane pobrane z bazy danych.
Przykładem zastosowania funkcji złożonych jest następujący scenariusz: użytkownik wykorzystując
mechanizmy typowe dla Forms dokonuje selekcji obiektów (w przypadku wspomnianej aplikacji są to
tablice ogłoszeniowe), po czym za jednym naciśnięciem klawisza przechodzi do formularza z mapą na
której wybrane obiekty zostaną automatycznie podświetlone. Jeśli wybrane obiekty są związane z
wieloma mapami  istnieje możliwość wygodnego wybrania mapy spośród tych na których odwzorowano
wybrane obiekty. Opisany proces może przebiegać także w drugą stronę, tzn. po dokonaniu wyboru
obiektów na mapie można przejść do formularza prezentującego szczegółowe informacje o tych
obiektach.
8
Rys. 3 Przykład prezentacji danych: formularz z danymi obiektów i ich położenie na mapie
Inny przykład to automatyczne przygotowanie map tematycznych. Mapy w reprezentacji MapInfo
mają strukturę warstwową, typowa mapa w systemie składa się z czterech lub pięciu warstw. Przyjęto, że
obiekty klienta zawsze skupione są w jednej warstwie. System przewiduje możliwość tworzenia na
podstawie map zawierających np. wszystkie obiekty użytkownika w pewnym mieście warstw, które
zawierają obiekty dobrane podług określonych kryteriów. Tak przygotowana mapa może zawierać
dowolny podzbiór obiektów, co stwarza możliwość wygodnego przygotowania danych do prezentacji.
6. Podsumowanie
Integracja typowych mechanizmów aplikacji nad bazą danych takich jak wybór obiektów według
szeregu warunków z możliwościami wizualnej prezentacji danych oferowanymi przez MapInfo stwarza
nowe możliwości dla użytkowników systemu. W firmie dla której powstał opisywany system jak dotąd
używano MapInfo w oderwaniu od danych przechowywanych w bazie danych. Kontrola spójności
danych nie istniała, dane dotyczące obiektów (adres i inne atrybuty) wprowadzano dwukrotnie  raz do
bazy danych i raz przy umieszczaniu punktu oznaczającego punkt na mapie. Nowy system eliminuje
opisane niedogodności, wprowadzając dodatkowe możliwości związane z automatyzacją niektórych prac.
Zamiast kilku wysp oprogramowania (MapInfo, stara baza danych) między którymi komunikacja prawie
nie istniała  powstał jeden system, który mam nadzieję ułatwi życie swoim użytkownikom.
9