Jak wybrać serwer aplikacyjny Javy?

Pierwsi użytkownicy uważają skalowalność i wydajność za kryteria podstawowe.

Pierwsi użytkownicy uważają skalowalność i wydajność za kryteria podstawowe.

Jak wybrać serwer aplikacyjny Javy?

Szacowane dochody z produktów i usług w sferze webyfikacji istniejących aplikacji w przedsiębiorstwach (w mld USD)

W krótkiej historii Weba najważniejsze decyzje o wyborze oprogramowania związanego z tą technologią dotyczyły serwera webowego. Dzisiaj dla dużych korporacji coraz częściej kluczową sprawą staje się podjęcie decyzji o wyborze serwera aplikacyjnego Javy. Wybór serwera aplikacyjnego jest dużo bardziej skomplikowany niż wybór serwera webowego, ale na szczęście można się już podpierać doświadczeniami pierwszych użytkowników tych systemów.

Serwery aplikacyjne można traktować jako mosty łączące Web z istniejącymi systemami wspierającymi transakcje z bazami danych i aplikacjami biznesowymi. W sensie technicznym serwer aplikacyjny oferuje trzy rzeczy: narzędzia do budowy aplikacji w postaci komponentów programowych, programy serwerowe jako zasobniki do uruchamiania tych komponentów i zarządzania nimi oraz interfejsy pozwalające komponentom współpracować z całym wachlarzem istniejących systemów.

Programy napisane w Javie mogą być zasobnikami komponentów programowych Enterprise JavaBeans napisanych pod jedno z API, określone w specyfikacji J2EE (Java 2 Enterprise Edition), opublikowanej formalnie pod koniec września br. i postrzeganej przez wielu użytkowników jako kluczowa dla wdrażania dużych aplikacji Javy wykorzystujących technikę webową, a to z powodu dodatkowych usług, które ona opisuje, jak również stosowanego modelu Enterprise JavaBeans. Specyfikacja ta już jest implementowana w serwerach aplikacyjnych wielu dostawców.

Najnowszy raport Ovum, instytucji badawczej w Londynie, zapowiada gwałtowny wzrost obrotów na rynku serwerów aplikacyjnych w ciągu najbliższych pięciu lat. Analityk Ovum, Gary Barnet, przewiduje, że produkty z górnej półki staną się „hubami integracyjnymi”, które pozwolą korporacjom na selektywne gwarantowanie dostępu do wewnętrznych procesów biznesowych dla użytkowników zewnętrznych - dostawców, klientów i partnerów.

W większości przypadków zespoły IT oceniają zapewne serwery aplikacyjne jak każdą składową sieci. Wykonują one analizę potrzeb, tworzą listy kontrolne porównywalnych mechanizmów, uwzględniają czynnik ceny, oceniają dostawców i przeprowadzają testowanie wybranych produktów.

Jednak użytkownicy, którzy wdrożyli już serwery aplikacyjne, są przekonani na podstawie własnych doświadczeń, że w ocenie tych produktów trzeba brać pod uwagę również inne elementy.

Ponieważ serwer aplikacji Javy jest wybierany dla aplikacji webowych zorientowanych na transakcje online, to jest konieczne zachowywanie ciągłej dyspozycyjności w świadczeniu swoich usług, niezależnie od zmieniających się potrzeb i obciążeń.

Przy tworzeniu systemu Javy po stronie serwera, dla zapewnienia skalowalnej niezawodności w czasie przeciążeń lub uszkodzeń, najlepiej zdać się na serwer aplikacji tworzący zasobnik dla Enterprise JavaBeans.

Skalowalność czy też zdolność pracy serwera aplikacji na rosnącej liczbie procesorów i komputerów są równie ważne. Serwer aplikacji, który nie może być skalowany, jest bezużyteczny. W praktyce zaleca się, aby serwer aplikacji mógł obsługiwać obciążenie trzykrotnie większe od przewidywanego.

Cechą ściśle powiązaną ze skalowaniem jest wydajność. Serwer aplikacji powinien być systemem wykorzystującym techniki pracy wielowątkowej w celu uzyskania optymalnej mocy przetwarzania. Dla prawidłowej oceny tego parametru należy oszacować liczbę transakcji wykonywanych w danym czasie i upewnić się, że serwer może je obsłużyć. Po uruchomieniu serwera potrzebne jest ciągłe monitorowanie jego wydajności. Pozwoli to na formułowanie wymagań w zakresie rozszerzenia wydajność produktu.

Powinny być udokumentowane i ocenione także mechanizmy ochronne serwera aplikacji.

Narzędzia projektowe do budowania komponentów goszczących na serwerze aplikacji - a zwłaszcza te, które są zgodne z IDE (Integrated Development Environments) - są w ciągłej ewolucji. Takie zestawy narzędzi mają zapewnić projektantowi wszystko to, co jest niezbędne do budowy aplikacji, gwarantując jednocześnie gładką współpracę miedzy narzędziami. Rzeczywistość jest jednak zupełnie inna. Jakość narzędzi Java IDE jest przedmiotem krytyki ze strony wielu projektantów. Głównym grzechem jest mała wydajność wizualnych form projektowania, które praktycznie nie nadają się do użycia w serwerowej stronie projektu.

Analiza narzędzi projektowania Weba i połączonych z nimi serwerów aplikacyjnych ujawnia znaczne różnice w kompletności mechanizmów zawartych w tych zestawach. Raport TechMetrix Research z Burlington wymienia dostawców łączących różne serwery aplikacyjne w jeden pakiet z narzędziami aplikacyjnymi. Jako przykład można podać WebObjects z Apple, Sapphire/Web z Bluestone Software, HatSite z Hat Software i Tango z firmy Pervasive. Inne bardziej znane to Netscape Application Server (znany wcześniej jako Kiva) i Oracle Application Server.

Prawie wszyscy ci dostawcy zapowiedzieli wsparcie J2EE, a w szczególności Enterprise JavaBeans. Ale pamiętać należy, że aplikacyjne serwery Javy są złożone i trzeba włożyć sporo wysiłku w wybór i implementację tych ciągle rozwijających się produktów.

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

TOP 200