Narodziny narzędzi

Gdyby CeBIT miał odbyć się za pół roku, z pewnością uwaga zwiedzających w większym stopniu skupiłaby się na narzędziach do tworzenia aplikacji. W marcu wiele programów prezentowano jeszcze w wersji beta, a niektóre dopiero znalazły się na początku długiego procesu produkcyjnego. Dlatego też narzędzia programistyczne nie były tak szeroko eksponowane, jak gotowe rozwiązania dla biznesu czy nowy sprzęt.

Gdyby CeBIT miał odbyć się za pół roku, z pewnością uwaga zwiedzających w większym stopniu skupiłaby się na narzędziach do tworzenia aplikacji. W marcu wiele programów prezentowano jeszcze w wersji beta, a niektóre dopiero znalazły się na początku długiego procesu produkcyjnego. Dlatego też narzędzia programistyczne nie były tak szeroko eksponowane, jak gotowe rozwiązania dla biznesu czy nowy sprzęt.

Firmy, które prezentowały na targach ofertę dla programistów, dążą do możliwie dużej uniwersalności swoich produktów. Ponieważ programista rzadko ma do czynienia z homogenicznymi systemami komputerowymi, ważne jest, by powstające oprogramowanie nie było zależne ani od sprzętu, ani od systemu operacyjnego. Jednak każda firma inaczej postrzega rozwiązanie tego problemu. W Hanowerze każdy producent oprogramowania zapewniał, iż jego produkt jest zgodny ze standardami. Twórcy narzędzi programistycznych nie przekonają już do swoich produktów twierdzeniem, że są to wygodne narzędzia z wieloma rozszerzeniami języka, które ułatwią pisanie programu.

Współpracujące komponenty

W związku z istnieniem na rynku dwóch konkurencyjnych modeli komponentów: CORBA (grupa OMG) i DCOM (Microsoft), pojawiły się dwa typy rozwiązań. Pierwsze polega na tworzeniu specjalnych "pośredników", czyli programów, które umożliwiają korzystanie z obu standardów (np. rozprowadzany przez Borlanda VisiBroker). Innym jest Entera, także firmy Borland, która jest warstwą pośrednią (middleware) między aplikacją a całym środowiskiem rozproszonym. Entera 4 opiera się na interfejsie DEC i MS RPC (Remote Procedure Call - zdalne wywoływanie procedur). W przyszłości Borland zamierza połączyć Enterę z VisiBrokerem i MIDAS-em (middleware dostarczający pewne serwisy dla wielowarstwowych aplikacji rozproszonych), co pozwoliłoby łatwo obsługiwać zarówno CORBA, jak i DCOM.

Inne podejście zaprezentowała niemiecka Software AG, która zdecydowała się nie na łączenie standardów, ale przeniesienie DCOM na inne platformy. EntireX może działać na Sun Solaris, Digital Unix, HP-UX, AIX, a planowana jest także wersja dla Linuxa. Dzięki temu komponenty ActiveX nie są ograniczone tylko do platformy Windows NT/95. Co ważniejsze, jeżeli aplikacja Windows NT zamierza odwołać się do ActiveX na serwerze Unix, to czynność ta nie musi być wspomagana ze strony klienta. Nie ma więc potrzeby instalowania dodatkowych elementów na stacjach klienckich. Cały pakiet EntireX składa się z niezbędnych elementów, pozwalających tworzyć komponenty DCOM na platformie unixowej. Przeniesiono model COM, rejestr (wraz z narzędziem do edycji), kompilator MIDL, tworzący odpowiednie szkielety, oraz niektóre elementy związane z dokumentami OLE2. Przedstawiciele Software AG zapewniają, że kod DCOM nie wymaga prawie żadnych zmian, by kompilował się na Unixie.

Inaczej w bazach

Inne podejście do przenośności oprogramowania zaprezentowali producenci baz danych. Szczególny nacisk położono na łatwość przenoszenia graficznego interfejsu aplikacji bazodanowej.

Na stoisku Informixa prezentowano narzędzie Four J's Universal Compiler, które pozwala tworzyć aplikację posługującą się równocześnie interfejsem X-Windows, Microsoft Windows 3.11/95/NT i terminalem ASCII. Planowana jest wersja dla Mac-OS. Kompilator języka czwartej generacji tworzy specjalny p-kod (podobnie jak kompilatory Javy), który następnie jest interpretowany przez motor, działający na danej platformie. Dzięki temu aplikacja jest bardzo mała. Zdaniem przedstawicieli Informixa, prędkość działania programu zapisanego w p-kodzie jest porównywalna z innymi programami. Narzędzie to pozwala importować istniejące aplikacje Informixa i "automatycznie" tworzyć graficzny interfejs. Jednak programy napisane w tym języku mogą korzystać tylko z bazy danych Informixa.

Ciekawe rozwiązanie zaproponowała niemiecka firma Tools GmbH, która zaprezentowała produkt o nazwie ISA Dialog Manager. Jest to system projektowania okien dialogowych, który - podobnie jak opisane poprzednio narzędzie - tworzy p-kod (jest on następnie interpretowany przez odpowiedni motor). Motor istnieje dla OSF/Motif, OS/2 i wszystkich wersji Windows. O ile w poprzednim rozwiązaniu nie zapewniono przenośności między terminalem tekstowym a systemami okienkowymi, w tym przypadku istnieje specjalna biblioteka AlphaWindow, pozwalająca, by raz zaprojektowane (graficzne) okno dialogowe można było uruchomić w trybie tekstowym. ISA Dialog Manager nie zajmuje się dostępem do bazy danych. Programista otrzymuje specjalne API (dla danego języka programowania), za pośrednictwem którego posługuje się Dialog Managerem. Interfejsy takie istnieją dla C/C++, Cobola, a nawet dla powłoki Unixa. Istnieje także interfejs dostosowany do współpracy z SQL. Tak więc od programisty zależy, w jaki sposób połączy się z bazą danych (za pośrednictwem ODBC czy za pomocą CLI Oracle lub inaczej).

Inne podejście zaprezentowano w Magic 8. Jak w poprzednich wersjach, tak i tu cały program zapisany jest w wierszach specjalnej bazy danych i na bieżąco interpretowany. Interfejs użytkownika może być natomiast budowany jako formularze Javy czy HTML (można także tworzyć okna dialogowe właściwe dla danego systemu okienkowego). W tym narzędziu nie wymaga się, by programista znał Javę czy HTML. Dysponuje bowiem specjalnym edytorem, w którym projektuje wygląd aplikacji. Magic zawiera aplety Javy, które "rozumieją" polecenia z programu i wyświetlają odpowiednie elementy. Podobne rozwiązanie prezentował Oracle i Sybase.


TOP 200