Java i .Net: komponenty
- Tomasz Kopacz,
- 17.06.2002
ASP.Net pozwala na pełną separację kodu HTML i kodu wspomagającego generowanie strony. Nie trzeba, tak jak w JSP, mieszać znaczników HTML i fragmentów Javy.
Model komponentowy
W świecie Javy podstawowym elementem są komponenty EJB (Enterprise JavaBeans). Można je podzielić na dwa typy "logicznie" - komponenty encji i komponenty sesji.
Komponenty encji zapewniają interfejs obiektowy do tworzenia i modyfikowania danych. Odpowiadają współdzielonym danym w systemie bazodanowym. Są trwałe, dostępne dla wielu sesji i wielu klientów. To pewnego rodzaju menedżer zasobów. Można je podzielić na komponenty, którymi zarządza tzw. kontener (wtedy on zajmuje się przechowywaniem stanu), i te, którymi zarządza sam bean.
Z kolei komponenty sesji nie są obiektami trwałymi. To tymczasowe struktury, które mogą wykonywać pewnego rodzaju operacje biznesowe (w tym pewne czynności w bazie danych). W ich przypadku można wyróżnić dwa dodatkowe podtypy: komponent zachowujący stan i nie zachowujący stanu. Pierwszy przechowuje stan tak długo, jak długo jest aktywna sesja klienta. Komponent, który nie zachowuje stanu, jest obiektem użytkowym, tworzonym w momencie przyjścia żądania klienta - wykonuje określoną operację, po czym jest usuwany.
Podobne możliwości oferuje platforma .Net. Można tworzyć obiekty typu singleton, które z założenia mają obsługiwać wielu klientów. Po stronie serwera działa jedna instancja obiektu, do którego jest kierowanych wiele różnych połączeń.
Innym typem obiektu .Net jest komponent "pojedynczego wywołania". To najbardziej skalowalny typ komponentu, który powstaje w wyniku żądania klienta. Jest tworzony na serwerze, a po wywołaniu metody natychmiast kasowany lub zwracany do puli obiektów.
Trzeci typ obiektu w .Net powstaje wtedy, gdy po stronie klienta przy użyciu polecenia NEW jest tworzony zdalny komponent (tak naprawdę jest generowana lokalna instancja proxy, której odpowiada utworzenie obiektu po stronie serwera). W tym momencie można mówić o pewnego rodzaju komponencie sesji. Serwer może zidentyfikować klienta (obsługa sesji w EJB jest znacznie wygodniejsza).
Sesje bardzo upraszczają kodowanie aplikacji. W przypadku Javy to naturalny mechanizm, .Net ma natomiast architekturę dostosowaną do bezstanowych komponentów wywoływanych jak usługi Web, gdzie nie można nawiązać ciągłego połączenia między serwerem a klientem.
Sesje są wygodniejsze. Pozwalają łatwiej rozwiązywać wszelkiego rodzaju blokady przy aplikacjach rozproszonych. Niestety, wymagają znacznie potężniejszego sprzętu. Kolejna wersja EJB/J2EE będzie mieć dodatkowo mechanizm dzielenia kontekstu (np. pomiędzy kilku klientów). Obecnie to mechanizm niestandardowy, spotykany tylko w niektórych rozwiązaniach producentów serwerów aplikacyjnych.
W .Net można łatwo wykorzystywać standardowy mechanizm sesji protokołu HTTP.
W przypadku EJB (J2EE) i obiektów COM po stronie serwera aplikacyjnego dostępne jest specjalne repozytorium, w którym są zarejestrowane komponenty do wykorzystania przez klienta. W .Net nie ma takiego mechanizmu. Po stronie serwera należy jawnie uruchomić proces, który "nasłuchuje" i oczekuje żądania klienta. Można tu także wykorzystać mechanizmy serwera WWW (przypomina to już usługi Web).