Ole, Ole Obiektowe wiraże i miraże

W ciągu ostatnich 20 lat w technologii budowania aplikacji komputerowych zmieniało się niewiele.

W ciągu ostatnich 20 lat w technologii budowania aplikacji komputerowych zmieniało się niewiele. O tempie komputerowej rewolucji decydował sprzęt czy jak kto woli hardware. Doskonaliły się oczywiście języki, przybywało różnych narzędzi wspomagających, powstały systemy zarządzania bazami danych, ale metoda budowy aplikacji nie ulegała zasadniczej zmianie i sprowadzała się do napisania iluś tysięcy linii kodu, i to w językach dostępnych na maszynie, na której system użytkowy miał być eksploatowany. Bowiem także parametry sprzętu, a w szczególności jego szybkość i pojemności pamięci, limitowały i dyktowały sposoby budowy aplikacji. Przypominam o tym, bo w końcu i tutaj nadchodzą zasadnicze zmiany.

Coraz więcej zastosowań komputerowych powstaje z gotowych komponentów. Systemy użytkowe składa się z prefabrykowanych elementów, dopasowuje i dostraja do potrzeb użytkownika, czasami uzupełnia dodatkowym kodem. Technologia obiektowa w budowie aplikacji jest więc faktem. Faktem też jest jej niedoskonałość. Tym jednakże, co najbardziej niepokoi środowisko informatyczne, jest brak standardu. Problem ze standardem jest dość podstawowy i da się sprowadzić do dylematu, jaki mielibyśmy kilka lat temu, gdyby batalia między systemami operacyjnymi Windows i OS/2 była przez długi czas nie rozstrzygnięta. Jaki system wtedy wybrać? Na jakim rozwiązaniu oprzeć komputeryzację firmy? Pomyłka może drogo kosztować.

Standardy informatyczne powstają w wyniku nominacji. Ale na rynku. Standardem zostaje rozwiązanie większościowe, chętniej przyjęte przez użytkowników, niekoniecznie lepsze.

Produkty zgodne z tak przyjętym standardem gwarantują producentom oprogramowania zyski ekstra, wynikające ze skali sprzedaży, użytkownikom zaś dają gwarancję poruszania się po dobrze przetartych ścieżkach. Użytkownicy Apple’a czy OS/2 doświadczają obecnie wielu kłopotów wynikających z tego, że operują w systemie z względnie malejącą liczbą instalacji. Oznacza to mniejszą liczbę gotowego oprogramowania, które ponadto kosztuje drożej i jest wolniej rozwijane.

Wybór systemu operacyjnego, jak i modelu budowy aplikacji, dotyczy zatem strategicznych komponentów komputeryzacji.

Finalna i dotąd nie rozstrzygnięta rozgrywka toczy się w zasadzie między dwoma modelami pretendującymi do stania się przyszłościowym standardem budowy API: między koncepcją Microsoftu zwaną COM (Component Object Model) i opartym na niej produktem ActiveX oraz rozwiązaniem JaveBeans stworzonym przez Suna.

Obie strony nie szczędzą sobie złośliwych uwag. Sztandarowe hasło zwolenników Javy brzmi: "In a world without fances, who needs Gates". Odpłacając pięknym za nadobne, poplecznicy Billa Gatesa regularnie przekręcają nazwę JavaBeans na ExpressBeans, kpiąc w ten sposób ze stosunkowo powolnych aplikacji opartych na tej otwartej i niezależnej, zarówno systemowo, jak i sprzętowo, koncepcji Suna. ActiveX jest produktem powiązanym z serią systemów operacyjnych Windows. Aby uczynić COM bardziej uniwersalnym, Software AG na zlecenie Microsoftu implementuje koncepcje, również na inne systemy. Tutaj także należy upatrywać jednej z przyczyn zakończenia trwającej ponad 20 lat zimnej wojny między Microsoftem a Applem. Otwartości JavaBeans Microsoft zamierza przeciwstawić powszechność COM. Wszystko wskazuje więc na to, że zamiast standardu będziemy mieli do wyboru dwa modele.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200