V Konferencja PLOUG
Zakopane
Paź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.

2

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.

3

• 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óź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

4

Obiekt MapInfo.Application

Komponent MapiX

Klient OLE

Metody (interfejs IMapInfo)

OLE Callbacks

Metody (interfejs DMapiX)

Zdarzenia komponentu

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

5

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 źródłowego co automatycznie rozwiązuje problem własności

intelektualnej (nie ma możliwości bezprawnego użycia kodu źródłowego komponentu – nie ma potrzeby

rozprowadzania kodu ź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

6

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 doraź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

7

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

8

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.

9

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.