Ewolucja Javy
-
- Tomasz Kopacz,
- 29.04.2002
WSDP nie udostępnia wprawdzie narzędzi graficznych, które wspierałyby tworzenie usług Web, ale Sun opracowuje specjalną wersję Forte for Java 3.0, wyposażoną w kreatora przeznaczonego do tego celu. Ma on zawierać mechanizm, który niemal bez udziału programisty będzie tworzyć usługi Web na podstawie istniejących komponentów EJB. Uprości także wiązanie metod EJB z dowolnymi interfejsami, zdefiniowanymi w języku XML (nie tylko wymaganymi przez SOAP).
Sun Microsystems zmienia nazwy wszystkich produktów wchodzących w skład linii iPlanet, Forte i Chili!Soft. Będą teraz oferowane pod wspólną marką Sun ONE (Open Net Environment). Ich promocją zajmować się będzie utworzony właśnie nowy dział. Firma nie ujawniła szczegółów finansowych przedsięwzięcia. W skład serii Sun ONE zdecydowano włączyć również pakiet programów biurowych Star Office. Jego najnowsza, szósta wersja zostanie udostępniona w przyszłym miesiącu.
Usługi Web od innych
Programiści przyzwyczajeni do Javy nie są jednak zdani wyłącznie na Suna. Wiele bibliotek powstaje w wyniku prac niezależnych producentów, tworzących serwery aplikacyjne. Praktycznie każdy liczący się producent oferuje już zestaw technologii, pozwalających tworzyć usługi Web z wykorzystaniem technologii Java.
Hewlett-Packard niedawno udos-tępnił bezpłatnie serwer aplikacyjny HP Application Server 8.0 oraz związany z nim zestaw bibliotek do tworzenia usług Web. Oferuje też na- rzędzie do graficznego mapowania interfejsów WSDL, znacznie upraszczające instalowanie usług na serwerze HP-AS 8.0. Wraz z pakietem programista może pobrać ciekawą dokumentację, która przybliża problematykę programowania usług Web i ułatwia odpowiedź na pytanie, kiedy naprawdę warto je stosować.
Jednym z elementów oferty HP jest gotowy komponent, pozwalający na tworzenie repozytorium UDDI. Dzięki niemu firmy mogą budować włas- ne, centralne repozytoria usług Web. Producent opracowuje również testową implementację specyfikacji HP- -WST - Web Services Transaction. Ma ona umożliwić wykonywanie usług transakcyjnych w obrębie usług Web z wykorzystaniem tzw. długich transakcji, gdzie w całym procesie bierze udział wiele firm (tzn. ich serwerów), oddzielonych firewallami.
IBM oferuje Web Services Toolkit - pakiet z zestawem funkcji API, umożliwiający tworzenie usług Web. Podobnie jak w przypadku narzędzi HP, zalety darmowego pakietu IBM to: dokumentacja, mechanizmy demonstrujące współpracę UDDI i WSDP oraz rozwiązanie do półautomatycznego generowania szkieletu usługi. Web Services Toolkit wymaga do pracy Javy 1.3.
Enterprise Application Server 4.1 firmy Sybase także zapewnia wsparcie dla usług Web. Aplikacja udostępnia programiście graficzne narzędzie do odwzorowywania komunikatów XML na komunikaty kierowane do komponentów Javy. Dzięki temu serwer aplikacyjny pełni rolę pośrednika, tłumaczącego odwołania usług Web na język Javy. Oznacza to, że teoretycznie dla komponentu EJB nie ma znaczenia, że dany komunikat był przekazany w pakiecie SOAP.
BEA Systems na konferencji JavaOne poinformowała, że poddała procesowi standaryzacyjnemu opracowany przez siebie mechanizm Java Web Services (JWS), umożliwiający łatwe tworzenie usług Web w środowisku WebLogic Workshop. Pliki JWS konstrukcyjnie przypominają JSP. Na podstawie schematu (tak jak w JSP) powstaje usługa Web, łącząca elementy napisane w Javie: odwzorowanie do XML, akcje SOAP czy mechanizmy odwołania do bazy danych. Tak jak w wyniku działania JSP powstaje fragment HTML, tak w przypadku JWS powstaje usługa Web. Środowisko IDE WebLogic umożliwia tworzenie takich usług niemal metodą "rysowania diagramów". Programista przeciąga komponenty i umieszcza na obszarze projektowym, a następnie łącząc je tworzy powiązania między elementami, składającymi się na usługę Web. Środowisko WebLogic też wyposażono w mechanizmy testowania usług Web.
Większość elementów niezbędnych do tworzenia i uruchamiania usług Web znalazło się również w oprogramowaniu Oracle9iAS. Na pozostałe trzeba będzie poczekać do udostępnienia drugiej wersji (Release 2) tego serwera aplikacyjnego.
Także w następnej wersji Oracle JDeveloper ma się znaleźć nowe narzędzie, które na podstawie opisu usługi Web w WSDL będzie generować odpowiednie klasy w Javie. Będzie ono mogło tworzyć zarówno kod działający po stronie klienta, jak i "szkielet" komponentu serwerowego. JDeve- loper umożliwi więc zdefiniowanie interfejsu WSDL (przy użyciu specjalnego kreatora), a następnie automatycznie wygeneruje dla niego odpowiedni kod.
Powrót do korzeni
Obecnie Sun prowadzi coraz bardziej intensywne prace w celu... przeniesienia Javy z powrotem na małe urządzenia elektroniczne: telefony, komputery naręczne itp. Na konferencji JavaOne ogłoszono specyfikację Java 2 Mobile Edition (J2ME) for XML and RPC - API, pozwalające na tworzenie odwołań XML-RPC z platform "naręcznych" do innych komponentów. Specyfikacja ta nie zapewnia jednak wsparcia dla SOAP i WSDL (standardu, pozwalającego opisywać usługi Web i automatycznie odczytywać parametry, jakie musi przekazać wywołujący).
Jednocześnie Sun ogłosił, że prowadzi prace nad projektem, wstępnie określonym mianem Matey, którego celem jest 10-krotne zwiększenie wydajności J2ME.
Sun wkłada wiele wysiłku w stworzenie alternatywy dla szeroko reklamowanej platformy .Net Microsoftu. Dysponuje fundamentem, na którym taką alternatywę można budować. Tyle że dotąd ten potencjał firmy nie został w pełni wykorzystany. Platformie J2EE brakuje odpowiednich interfejsów, narzędzi i szczegółowych specyfikacji, które pozwalałby programistom na tworzenie usług Web w zgodzie ze standardem. Na szczęście, na tym odcinku sporą część pracy wykonały za Suna firmy licencjonujące Javę. Niezależni od Suna producenci oprogramowanie samodzielnie opracowali niezbędne mechanizmy, dzięki którym usługi Web można już realizować również w Javie, i robi to coraz więcej osób.
Na pierwszy rzut oka taka sytuacja stawia programistów Javy w lepszej sytuacji niż zwolenników .Net, związanych z jednym dostawcą i w gruncie rzeczy skazanych na jego wizję rozwoju Web Services. Z wielu produktów różnych firm mogą wybrać najlepszy, który będzie najpełniej odpowiadał ich wymaganiom. Być może jednak pewnego dnia przyjdzie zapłacić za ten pluralizm. Co zrobić, jeśli wybrany dziś serwer aplikacyjny Java okaże się niezgodny z J2EE 1.4, gdy specyfikacja ta wreszcie stanie się dostępna? Pocieszeniem może być to, że wstępne specyfikacje oczekiwanej nowej wersji J2EE były dostępne, przynajmniej członkom Java Comunity Process, i nadzieja, że producenci zastosowali się do nich.
Odrębnym problemem pozostaje wzajemna zgodność poszczególnych serwerów aplikacyjnych Javy. Nawet te, które nominalnie tworzone są wg zaleceń z J2EE 1.2, inaczej interpretują pewne elementy API. Na szczęście niedawno Sun udostępnił specjalne narzędzie do weryfikowania zgodności serwera aplikacyjnego ze standardem Java. J2EE Application Verification Kit (AVK) wyszukuje elementy aplikacji, które wykraczają poza bazową specyfikację J2EE 1.3. Należy mieć nadzieję, że udostępnianie przez Suna takich narzędzi wejdzie do kanonu standaryzacyjnego. Ułatwi to nie tylko dostawcom serwerów aplikacyjnych testowanie własnych produktów, ale również umożliwi programistom tworzenie naprawdę przenośnego kodu, który bez zbędnych komplikacji można uruchamiać na różnych serwerach aplikacyjnych. A przecież o to chodzi w Javie.
