Integracja aplikacji opartych na Forms 5.0 z narzędziem do prezentowania map MapInfo Professional

Transkrypt

1 V Konferencja PLOUG Zakopane Październik 1999 Integracja aplikacji opartych na Forms 5.0 z narzędziem do prezentowania map MapInfo Professional Tomasz Ostrowski Tomasz.Ostrowski@itti.com.pl 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. 2

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 3

4 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

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 5

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 6

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

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

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