Technologia Brazil stanowi w pewnym sensie konkurencję dla .NET Microsoftu. Pozwala tworzyć aplikacje działające w środowisku Web, gdzie poszczególne źródła informacji komunikują się poprzez protokół HTTP za pośrednictwem adresów URL, a każda maszyna - zarówno komputer, jak i inteligentna lodówka - jest wyposażona w stos HTTP napisany w Javie.

Początków projektu Brazil należy szukać w małym projekcie rozwijanym w laboratoriach Suna, który miał na celu stworzenie stosu HTTP o minimalnych wymaganiach sprzętowych. Powstała aplikacja w Javie, której jądro wymagało zaledwie 100 KB. Dzięki temu obsługa HTTP mogła być wbudowana w inteligentne karty chipowe, a nawet w... lodówkę. Na początku ten stos nie miał być pełnym serwerem WWW. Co więcej, we wczesnej fazie rozwoju projektu jego nazwą było NAWS, od Not A Web Server.

Dzięki małym wymaganiom stawianym stosowi HTTP stało się realne, że do każdego urządzenia, w którym działa maszyna wirtualna Java, można odwoływać się za pośrednictwem adresu URL. A co ważniejsze, każde urządzenie (na razie jest ich niewiele) może odpowiadać na zapytania sformułowane jako odpowiednie "odsyłacze" URL. W ten sposób można ujednolicić komunikację z niemal wszystkimi urządzeniami z wbudowaną maszyną wirtualną Javy.

Od lodówki do usług Web

Tradycyjny serwer Web zarządza ustaloną strukturą dokumentów, która czasami jest powiązana z zewnętrznymi źródłami danych. Pozwala zwykle wykonywać operacje po stronie serwera (skrypty CGI itp.) i dostarcza klientowi wynik w postaci zrozumiałej dla przeglądarek. Technologia Brazil w pewnym sensie zastępuje serwer Web - dostarcza odpowiednie informacje po przekazaniu zapytania HTTP. Jednak jej zaleta polega na tym, że nie ma centralnego źródła danych.

Brazil może działać jako mikroserwer, co sprawia, że HTTP jest po prostu protokołem komunikacyjnym, pozwalającym obsługiwać i odczytywać stan urządzenia. Z punktu widzenia nowej strategii Suna bardzo ważne jest to, że "urządzeniem", które korzysta z technologii Brazil, może być także usługa sieciowa, np. usługa autoryzacji kart kredytowych, udostępnianych przez HTTP w połączeniu z serwerem Brazil.

Brazil może także pełnić rolę metaserwera, który będzie integrował dane pochodzące z różnych mikroserwerów. W ten sposób, zamiast tworzyć centralny duży serwer WWW, powstaje ciąg powiązanych ze sobą małych serwerów HTTP, dostarczających jednostkowe informacje. W Brazil wbudowane są mechanizmy, które pozwalają w dużym stopniu transformować dane pochodzące z innych serwerów WWW.

Silny manipulator

Architektura Brazil składa się z czterech głównych komponentów.

Pierwszy to obiekt Server, który odpowiada za zarządzanie serwerem HTTP. Drugim jest Request, którego zadaniem jest przekierowanie żądania przychodzącego do serwera do właściwego tzw. manipulatora - trzeciego obiektu, nazwanego Handler. Czwarty komponent to framework - jest wbudowany w serwer Brasil i realizuje określone funkcje usługowe.

Manipulator jest tym elementem infrastruktury Brazil, który odpowiada za wykonywanie określonych czynności np. za pośrednictwem konkretnego urządzenia. W przypadku rozwiązań związanych z usługami Web może to być także np. czynność polegająca na autoryzacji karty płatniczej. Implementacja manipulatora (czyli tak naprawdę API) w Sun Brazil jest dość prosta. API rozszerzające korzysta z mechanizmu delegacji. Programista ma za zadanie oprogramować w Javie tylko dwie metody interfejsu manipulatora: inicjalizacyjną i wywoływaną w momencie nadejścia żądania do serwera Brazil. Warto podkreślić, że konfiguracja konkretnego manipulatora jest tworzona dynamicznie, z chwilą nadejścia zapytania. W ten sposób w pamięci znajduje się niemal tylko kod aktualnie wykorzystywanych manipulatorów.

Wyjaśnienia wymaga pojęcie związane z konfiguracją manipulatorów. Każde tworzone API może mieć pewną liczbę parametrów (duża ich część jest już zdefiniowana w pakiecie Brazil). Parametrem jest np. domyślny wzorzec odpowiedzi generowanej przez manipulator czy sposób tworzenia puli manipula- torów danego typu. Wszystkie te elementy mogą zostać określone w momencie wywoływania manipulatora - innymi słowy klient w żądaniu HTTP może określić oczekiwany wzorzec odpowiedzi czy sposób filtrowania "podwyników", gdy Brazil zbiera dane z mikroserwerów. W ten sposób tworząc odpowiednio sparametryzowany manipulator, tworzymy bardzo elastyczne narzędzie, które może zostać wykorzystane na wiele sposobów. W momencie wywołania Brazil tworzy manipulator o danych parametrach po czym, gdy już nie jest potrzebny, usuwa go. Jednak można dostroić system tak, by część lub cały obiekt pozostawały w pamięci.

Programiści Suna zdecydowali, że komponenty muszą być jak najmniejsze, a co za tym idzie powinny mieć niewielkie wymagania i oferować proste API. Duża modularność rozwiązania pozwala także, by pewne usługi programista bez większych trudności zastępował własnymi implementacjami. Warto dodać, że powstały już manipulatory do Brazil pozwalające korzystać niemal z każdej technologii Java. Można stosować kolejki komunikatów Java Message Queue i API JMS. Można też tworzyć rozwiązania korzystające z J2EE czy RMI.

Należy podkreślić, że w przypadku wywoływania usług za pośrednictwem HTTP i Sun Brazil nie ma możliwości zapewnienia silnej kontroli typów. O ile do implementacji manipulatoru (pisanej w Javie) można używać silnej kontroli typów, o tyle w przypadku wywołań HTTP Brazil jest to niemożliwe. Brak silnej kontroli typów pozwolił na współpracę manipulatorów Brazil z innymi językami niż tylko Java. Ma to jednak konsekwencje - może powodować powstawanie trudnych do wykrycia błędów związanych z niepoprawnym "opakowaniem" typu w żądaniu HTTP. Microsoft ze swoją technologią .NET zdecydował się zaimplementować silną kontrolę typów, tworząc specjalną specyfikację CLR, nakładającą określone wymagania na języki, z których w pełni korzystają usługi Web.

Warto też wspomnieć o specjalnym języku skryptowym BSL, który może być osadzany na stronach HTML i ma za zadanie pośredniczyć pomiędzy stroną HTML a manipulatorami serwerów Brazil. Jest to język przypominający XML. Sun prawdopodobnie dlatego zrezygnował z pełnego XML/XSL, który wydawałby się tu naturalnym rozwiązaniem, ponieważ parser XML jest dużą aplikacją, a przetwarzanie dokumentu jest procesem złożonym i kosztownym obliczeniowo. Brazil Scripting Language tworzy dynamiczne strony HTML i oddziela kod, odpowiadający za układ strony, od danych.

Usługi po brazylijsku

Warto przyjrzeć się także usługom, jakie serwer Brazil udostępnia programistom. Podstawowym jego elementem jest spec-jalna biblioteka, która zapewnia obsługę zewnętrznych witryn WWW. Mogą to być zarówno witryny pochodzące z dużego, tradycyjnego serwera WWW, jak i dane generowane przez mikroserwery. Dostępne są funkcje, które wczytają określony wzorzec filtra lub pozwolą zarejestrować klasy, samodzielnie doko- nujące filtrowania.

W Brazil zawarte są funkcje usługowe, które z jednej strony wspierają samodzielną analizę składniową (parsing) stron HTML, z drugiej pozwalają łatwo złożyć gotową stronę HTML, która będzie ustalonym wzorcem. Pakiet ma bardzo rozbudowane wyrażenia regularne, czyli takie, które pozwalają wyszukiwać fragmenty tekstu/ciągów znaków pasujących do wzorca. Interesującą cechą jest możliwość analizy niemal dowolnych plików znacznikowych, zarówno XML, jak i nawet SGML.

Nie można pominąć narzędzi, które pozwalają przekierowywać zapytania HTTP np. do innego serwera. Podczas przekierowywania komunikat może zostać przekształcony np. tak, by pasował do zmienionego API, udostępnionego przez inny manipulator. Mogłoby się wydawać, że akurat ta część "przetwarzająca" serwera Brazil odpowiada funkcjonalnie przetwarzaniu dokumentów XML/XSL. Jednak jest realizowana mniejszym kosztem niż parsing złożonej struktury XSL. W Brazil zaimplementowano dosyć efektywne algorytmy słownikowe, które potrafią operować nawet na dużych zbiorach danych.

W Brazil jest dostępnych wiele funkcji ułatwiających testowanie rozwiązań. Na razie nie ma narzędzia typu RAD (czy debugger) specjalnie dostosowanego do architektury Brazil, dlatego programiści zmuszeni są do korzystania ze standardowych pakietów IDE dla Javy.

Brazil może wykorzystywać architekturę LDAP. Istniejąca implementacja opiera się na bibliotece dostępnej wraz z Netscape Navigator.

Należy podkreślić, że podstawowa rama (framework) Brazil ma wbudowany mechanizm obsługi sesji. Serwer tworzy dla sesji unikatowy identyfikator, który przekazuje do klienta, czyli do drugiego serwera Brazil. Co ważniejsze, sesja nie jest związana z pojedynczym żądaniem, a np. z danym połączeniem czy klientem. Po stronie serwera dostępne są mechanizmy do zarządzania pulą sesji czy tworzeniem tzw. trwałych sesji, których stan jest przechowywany po stronie serwera aż do kolejnego dołączenia określonego klienta.

W dostępnej wersji Brazil zaimplementowano specjalne interfejsy, pozwalające wykorzystywać przy tworzeniu manipulatorów fragmenty kodu napisane w językach innych niż Java. Obecnie powstały dwie biblioteki: dla Tcl i Pythona. W przyszłości prawdopodobnie Brazil będzie można łączyć z Perlem.

W przypadku Pythona na stronach HTML można osadzać specjalne skrypty, które mają być wykonywane po stronie serwera. Natomiast w przypadku języka Tcl, który efektownie można połączyć z Javą, można wręcz implementować manipulatory w Tcl.

Bezpieczeństwo w Brazil jest oparte na mechanizmie zbliżonym do ACL (Access Control List). Przychodzący URL jest porównywany z określonymi wyrażeniami (wzorcami regularnymi) i w zależności od wyniku podejmowane są odpowiednie czynności. Najprostsza metoda autoryzacji (BasicAuthHandler) polega na tym, że informacje o użytkowniku i haśle przesyłane są jawnie razem z identyfikatorem sesji. Jeżeli komunikacja odbywa się bezpiecznym protokołem, np. SSL, to w wielu przypadkach jest to rozwiązanie wystarczające.

Istnieje także ogólny mechanizm autoryzacji (SunNetAuthHandler), który ma dostarczyć swego rodzaju interfejs użytkownika do zaawansowanej metody autoryzacji dla witryn WWW. Przewiduje on możliwość skorzystania z mechanizmu wyzwalanie-reagowanie (challenge-response), kluczy prywatnych/publicznych itp. Zawiera też mechanizmy, które automatycznie określają, czy klient musi ponownie uwierzytelnić się, czy hasło może być przechowane w plikach cookies itp.

Polityka wobec rywala

Należy podkreślić jeszcze jedną cechę Brazil. W przypadku .NET komunikacja jest realizowana w standardzie SOAP, który już teraz ma wiele niezależnych implementacji zgodnych ze specyfikacją. W Brazil komunikacja odbywa się w zasadzie pomiędzy dwoma serwerami HTTP napisanymi w Javie i (w dużym uproszczeniu) polega na wywołaniu odpowiedniego URL, który odpowiada konkretnej funkcji API, i zamieszczeniu w URL parametrów wywołania.

SOAP pozwala formułować komunikaty w XML i z ich poziomu odwoływać się do obiektów, metod czy właściwości. Obsługuje metody pakowania złożonych struktur danych czy wygodne zwracanie wyników. Manipulatory, czyli API Brazil, są znacznie prostsze i dzięki temu ich implementacja ma mniejsze wymagania. Mało prawdopodobne, by kod pozwalający na wywołania RPC typu SOAP mieścił się w 100 KB. Jednakże SOAP staje się standardem i daje znacznie większe możliwości w budowie usług Web.

W Brazil brakuje mechanizmu wyszukiwania usług. Dotąd nie opracowano żadnych założeń pozwalających stworzyć repozytorium (odpowiadające technologii UDDI), w którym można by wyszukiwać usługi Web według określonych kryteriów.