Ewolucja Javy

Chociaż Sun przekonuje, że J2EE jest idealnym rozwiązaniem do tworzenia usług sieciowych, to firma nie udostępniła jeszcze narzędzi i specyfikacji, pozwalającej w standardowy sposób tworzyć takie usługi. Coraz częściej firmę wyręczają inni producenci.

Chociaż Sun przekonuje, że J2EE jest idealnym rozwiązaniem do tworzenia usług sieciowych, to firma nie udostępniła jeszcze narzędzi i specyfikacji, pozwalającej w standardowy sposób tworzyć takie usługi. Coraz częściej firmę wyręczają inni producenci.

Ewolucja Javy

Architektura Javy

Początki Javy sięgają 1990 r., kiedy to James Gosling rozpoczął pracę nad językiem, który mógłby być nie tylko implementowany na wielu różnych platformach, ale i ułatwiać programowanie urządzeń elektronicznych. Miał to być język zbliżony do popularnego C czy C++, a jednocześnie niezależny od platformy, tak by stało się możliwe tworzenie uniwersalnego, przenośnego kodu.

Idea J. Goslinga we wczesnych latach 90. nie zyskała popularności. Wróciła natomiast wraz z nastaniem rewolucji internetowej, kiedy to czysto tekstowe strony internetowe zaczęto zastępować bardziej graficzną i interakcyjną zawartością. Potencjał Javy w tym zakresie został dostrzeżony przez Suna, który promował ten język zarówno jako sposób na ożywienie statycznych stron, jak i idealne narzędzie do tworzenia aplikacji klienckich, niezależnych od systemu operacyjnego i architektury sprzętowej. Szybko jednak okazało się, że złożone aplikacje z rozbudowanymi funkcjami, pisane w Javie, nie działają zbyt dobrze. Ówcześnie powszechnie stosowane komputery były zbyt słabe do szybkiego wykonywania interpretowanego języka.

Java jednak okazała się idealnym rozwiązaniem dla wielu systemów serwerowych. Firmy programistyczne, zamiast opracowywać własny język programowania i kompilatory, tworzyły bądź licencjonowały od Suna maszynę wirtualną Javy. Dzięki udostępnieniu maszyny wirtualnej programiści zyskali możliwość tworzenia rozwiązań dla wybranej platformy z wykorzystaniem znanych im narzędzi, napisanych w Javie. Co więcej, aplikacje mogły być tworzone i testowane na innych platformach niż docelowa (nawet na komputerach klasy PC), a dopiero potem być uruchamiane na "dużych" maszynach. Równocześnie starsze architektury serwerowe zostały wyposażane w nowoczesne funkcje, np. wątki, mechanizmy automatycznego zwalniania zarezerwowanej pamięci, czy nawet w ogóle inne zarządzanie pamięcią systemową. Możliwość posługiwania się Javą przez programistów systemów korporacyjnych sprawiła, że oprogramowanie aplikacji dla zaplecza (Back Office) stało się (teoretycznie) przenośne między Unixem, mainframe, VMS czy AS/400.

Usługi sieciowe w otwartym kodzie

Chociaż środowisko open source nie udostępniło gotowego, zintegrowanego pakietu do tworzenia usług Web z wykorzystaniem Javy, to są już dostępne wszystkie niezbędne do tego elementy. Programiści mogą korzystać z bazy danych opartej na XML Xindice, analizatora składni XML Xerces, serwera WWW Apache, standardowo obsługującego SOAP, oraz serwera aplikacyjnego Tomcat, obsługującego strony JSP i servlety. Rozwiązania te wchodzą również w skład niektórych pakietów komercyjnych. Tak naprawdę usługa Web jest "opakowaniem" pewnej funkcjonalności realizowanej na serwerze. Nic nie stoi na przeszkodzie, by za obsługę SOAP odpowiadały inne komponenty, np. rozwiązanie portalowe Novell Portal Services.

Ta "migracja" Javy z komputerów klienckich na serwery doprowadziła do upowszechnienia architektury trójwarstwowej, w której dodatkowy poziom stanowią serwery aplikacyjne. Dzięki temu bardziej realne stało się również stosowanie Javy do tworzenia rozwiązań klienckich, oczywiście pod warunkiem że główna część obliczeń związanych z pracą aplikacji jest wykonywana na serwerach.

Dużym problemem pozostały jednak biblioteki. Chociaż Java jest przenośna, to często zdarza się, że biblioteka jest silnie osadzona w konkretnej architekturze, na konkretnej platformie. Ze względu na wydajność część bibliotek była i jest pisana za pomocą narzędzi innych niż Java.

JCP - sposób na udoskonalanie API

Początkowo Sun samodzielnie rozwijał standard Javy, w wyniku czego powstało wiele mechanizmów do tworzenia GUI (AWT, Swing), apletów, API zarządzających wątkami, API do obliczeń matematycznych itd. Dopiero w październiku 1998 r. firma zaproponowała licencjobiorcom stworzenie wspólnego komitetu, którego głównym zadaniem miało być sterowanie pracami nad interfejsem programistycznym Javy. Sun rozważał nawet udostępnienie Javy zewnętrznemu komitetowi standaryzacyjnemu, ale ostatecznie zrezygnował z tego pomysłu.

Pierwsza specyfikacja procesu standaryzacyjnego Java Community Process miała charakter testowy. Funkcjonowała ponad półtora roku i była krytykowana przez niektórych licencjobiorców Suna. Przełom w rozwoju Javy nastąpił wraz z ogłoszeniem w lipcu 2000 r. JCP 2.0. Obecnie prace nad API są prowadzone zgodnie ze schematem JCP 2.1, opracowanym w czerwcu 2001 r.

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

TOP 200