Różnorodna współpraca

W KDE i GNOME, środowiskach graficznych Linuxa, inaczej rozwiązano współpracę aplikacji.

W KDE i GNOME, środowiskach graficznych Linuxa, inaczej rozwiązano współpracę aplikacji.

Trudno sobie wyobrazić nowoczesne środowisko aplikacyjne bez współpracy poszczególnych jego składników. Współczesne aplikacje nie są już monolitami, a użytkownicy wymagają, by współpracowało niemal "wszystko ze wszystkim". W Windows sytuacja jest dosyć prosta - istnieje wspólny model obiektowy (COM), zapewniający uniwersalny sposób komunikacji dowolnych dwóch aplikacji, które są w stanie odczytać swój interfejs. Microsoft predefiniował pewną liczbę interfejsów, określając np. standard OLE jako pozwalający na tworzenie dokumentów złożonych, gdzie poszczególne fragmenty są kontrolowane przez różne aplikacje.

Współpraca w Linuxie

W Linuxie problem współpracy aplikacji jest bardziej złożony. W przypadku aplikacji konsolowych obowiązywała zasada, że niemal każdy program mógł korzystać z tzw. standardowego wejścia i wyjścia. Dzięki temu, że powłoki Linuxa pozwalają dokonywać pewnych operacji na potokach, przekazywanie wyniku z jednej aplikacji do drugiej było łatwe. Zaawansowany użytkownik mógł przekazać dokument tekstowy do systemu składu druku, potem do aplikacji, która generowała plik postscriptowy i wysyłała go do aplikacji wizualizującej lub na drukarkę (odpowiednie wyrażenie zajmowało zwykle jedną, dwie linie).

W przypadku aplikacji opartych na X Windows sytuacja jest bardziej skomplikowana. Po pierwsze, należy uzmysłowić sobie, że cały ten podsystem z punktu widzenia Linuxa jest po prostu aplikacją, która korzysta z pewnych usług jądra. Aby użytkownik mógł pracować w X Windows, musi uruchomić konkretnego menedżera okien (desktop) - najczęściej KDE lub GNOME. Również każda aplikacja przeznaczona dla końcowego użytkownika działa pod kontrolą określonego menedżera okien (nieliczne mogą współpracować z wieloma różnymi desktopami). O osadzaniu dokumentów w aplikacjach linuxowych (podobnie jak OLE w Windows) czy o mechanizmie "kopiuj i wklej" można mówić tylko w przypadku konkretnego menedżera okien.

KPart - wymiana a` la KDE

W nowym środowisku KDE 2.0 wprowadzono specjalny protokół, który ma ułatwić współpracę aplikacji okienkowych. W poprzedniej wersji komunikacja miała być oparta na standardzie CORBA. Jednak w wersji 2.0 twórcy KDE zdecydowali o stworzeniu także własnego sposobu komunikacji pomiędzy programami (mimo to pozostawiono wsparcie dla CORBA). Programiści uznali bowiem, że na potrzeby komunikacji między aplikacjami działającymi na jednym komputerze CORBA jest zbyt złożona i ma za duże wymagania zarówno wobec struktury aplikacji, jak i zasobów systemowych.

Powstał też protokół komunikacji DCOP i moduł KPart przeznaczony do obsługi "osadzonych" dokumentów. DCOP jest mechanizmem komunikacji między procesami (opartym na bibliotece X Windows libICE). Jest dosyć prosty i ma małe wymagania sprzętowe. W efekcie komunikacja pomiędzy procesami nie wymaga zbyt wiele zasobów procesora.

Jednocześnie, dzięki użyciu libICE, KDE korzysta z mechanizmów autoryzacji wbudowanych w X11. Skrót DCOP pochodzi od Desktop Communication Protocol i tak naprawdę jest warstwą komunikacyjną, odpowiedzialną za rozdzielanie (marshalling) danych. Aplikacje "rejestrują" się w KDE i przesyłają między sobą komunikaty. Informacje można przesyłać zarówno poprzez gniazda Unixa, jak i wtyczki (socket) TCP/IP czy DECnet.

Twórcy DCOP opracowali połączenie pomiędzy tym protokołem a implementacją XML-RPC. Trwają też prace nad interfejsem pozwalającym na łączenie dowolnego DCOP z każdym protokołem IIOP zgodnym z CORBA. Warto wspomnieć, że desktop KDE jest oparty na bibliotece obiektowej QT, która zawiera mechanizmy komunikacji pomiędzy różnymi aplikacjami.

KPart jest technologią umożliwiającą osadzanie aplikacji w dokumentach tworzonych w innych programach. Podobnie jak w Windows, dzięki KPart można osadzić arkusz kalkulacyjny KSpread w oknie edytora KWord itp. Jednak należy podkreślić, że o ile dla DCOP zdefiniowano mechanizmy komunikacji z zewnętrznymi aplikacjami (nie korzystającymi z KDE), o tyle KPart jest ściśle związana ze środowiskiem KDE 2. Nie jest więc możliwe "przeciągnięcie" danych pomiędzy KWord a aplikacją, która korzysta z innego linuxowego menedżera okien, np. z GNOME.

Wysokie wymagania Bonobo

Twórcy GNOME dysponują innym rozwiązaniem, pozwalającym na współ-pracę między aplikacjami. Na podstawie standardu CORBA powstała specyfikacja interfejsów, które - tak jak w przypadku COM na Windows - udostępniają listę obsługiwanych funkcji. Rozwiązanie Bonobo definiuje sposób tworzenia komponentów i format dokumentu złożonego. Zdefiniowany jest mechanizm rejestrowania poszczególnych komponentów i sposób zdalnej współpracy pomiędzy fragmentami aplikacji.

Koncepcyjnie Bonobo jest bardziej zbliżone do rozwiązań COM niż DCOP/KPart. Programista ma do dyspozycji interfejs QueryInterface, który odpowiada na pytanie, czy dany obiekt implementuje żądany interfejs. Tak samo jak w PersistFile Windows, można zapisać stan obiektu. Podobnie tworzone są wizualne kontrolki, m.in. specjalne przyciski czy siatka prezentująca wyniki.

Twórcy Bonobo pracują nad możliwością wykorzystania transakcji w tym modelu obiektowym. Warto podkreślić, że dzięki użyciu standardu CORBA stosunkowo prosta jest współpraca z zewnętrznymi obiektami (zarówno lokalnymi, jak i zdalnymi), co sprawia, że ten model komponentów może służyć do tworzenia znacznie większych aplikacji niż DCOP/KPart. Niestety, Bonobo ma jednocześnie znacznie większe wymagania niż rozwiązanie oparte na KDE.

Co z tym zrobić?

Należy zastanowić się, czy w ogóle taki sposób rozwiązywania współpracy aplikacji ma sens. Z jednej strony, KPart w obrębie KDE 2.0 działa bardzo dobrze i zapewnia niemal bezproblemową współpracę pomiędzy aplikacjami napisanymi specjalnie dla tego środowiska (z niemal wszystkimi mechanizmami znanymi z Windows). Podobnie jest w przypadku GNOME. Kłopoty pojawiają się wtedy, gdy ktoś chce dane z aplikacji Gnumeric przenieść do edytora KWord. Nie wszystkie aplikacje mają odpowiedniki dostosowane zarówno do GNOME, jak i KDE. Trzeba podkreślić, że jeszcze inaczej rozwiązano komunikację pomiędzy aplikacjami wchodzącymi w skład StarOffice, najpopularniejszego chyba pakietu biurowego dla Linuxa.

Gdyby udało się stworzyć uniwersalny, wygodny mechanizm współpracy komponentów działający na poziomie X11 albo wręcz połączony z jądrem Linuxa, uprościłoby to wiele spraw. Jeśli ma się stać systemem wykorzystywanym przez korporacje, problem współpracy aplikacji musi zostać rozwiązany.