Java i .Net: komponenty

.Net oferuje wyrafinowane metody obsługi automatycznie generowanych proxy dla zdalnych komponentów. Często pisząc aplikacje, do końca nie wiadomo, gdzie dany komponent zostanie uruchomiony (zależy to np. od testów wydajnościowych). W związku z tym, nawet jeżeli posługujemy się mechanizmami zdalnego wywoływania obiektów, to kompilator JIT i motor EE (Execution Engine) wymienią "narzut" związany niepotrzebnym proxy i zastąpią go "zwykłym" tworzeniem obiektów.

Warto wspomnieć o składnikach Enterprise Services w .Net. Są to "opakowania" odpowiednich elementów funkcjonalnych COM+ czy MTS. Dostępne są wszystkie usługi COM+, m.in. transakcje, tworzenie puli obiektów, integracja z CICS/IMS, mechanizm luźno powiązanych zdarzeń, obsługa kolejki itp. Ponadto są oferowane klasy do obsługi SOAP i udostępniania komponentów jako usług Web, a także mechanizm autoryzacji i ochrony oparty na rolach.

W Javie do komunikacji ze zdalnymi komponentami przeznaczony jest mechanizm RMI. Składa się on z trzech podstawowych warstw: szkieletu (odpowiadająca proxy .Net), przenoszącej referencje między klientem a serwerem i transportowej. W przypadku .Net przekazanie referencji do obiektu nie wymaga szczególnych zabiegów. Implementacja warstwy transportowej w RMI zależy od serwera aplikacyjnego.

J2EE udostępnia mechanizm pozwalający na współpracę z technologią CORBA. RMI over IIOP umożliwia pisanie aplikacji CORBA bez potrzeby znajomości IDL i innych technologii związanych ze standardem CORBA. To pewnego rodzaju CORBA Object Request Broker, który przenosi żądania do zdalnych komponentów CORBA.

W .Net warstwą transportową mogą być zarówno HTTP (w tym standard SOAP), jak i TCP (metoda bardziej wydajna). Nie są dostępne mechanizmy współpracy ze standardem CORBA.

Sposób działania transakcji w .Net i Javie jest podobny. W .Net transakcje są oparte na semantyce COM+. Z punktu widzenia programisty, należy dodać odpowiedni atrybut, by stało się możliwe otwieranie czy potwierdzanie transakcji. W przypadku Javy można dodatkowo zlecić zarządzanie transakcją kontenerowi EJB - serwerowi aplikacyjnemu, który uruchomił obiekt. Projektanci interfejsu JTS (komponentowego monitora transakcyjnego w Javie) oparli swoje rozwiązanie na propozycjach CORBA Object Transaction Service (OTS).

Wybór komponentów

Java i .Net: komponenty

Intersejs JNI

Wchodząc na dowolną witrynę internetową poświęconą komponentom, można dostrzec olbrzymi wybór gotowych składników aplikacji. Średni koszt komponentu wynosi kilkaset dolarów. Dostępne są różne elementy - od takich, które są przeznaczone do tworzenia atrakcyjnego interfejsu użytkownika, przez użytkowe np. do sprawdzania poprawności kart kredytowych, generowania raportów, po gotowe generatory bloków kodu. Można też znaleźć bardzo zaawansowane moduły do tworzenia klastra obliczeniowego w technologii COM czy narzędzie, które przekształca arkusz Excel w kod Javy.

Gdyby podsumować liczbę microsoftowych komponentów COM i MTS, okaże się, że jest ich znacznie więcej niż komponentów przeznaczonych dla Javy. Rodzimych modułów stworzonych dla .Net nie ma jednak zbyt wiele. Można znaleźć komponenty ułatwiające opracowanie ciekawego interfejsu użytkownika (siatki, paski narzędziowe, nawet pełne generatory kodu). Istnieją też gotowe rozwiązania upraszczające wykonywanie standardowych operacji, np. obsługę większości protokołów internetowych.

Ogólnie brak jest gotowych komponentów, które byłyby przydatne w rozwiązaniu skomplikowanych problemów biznesowych. Komponenty biznesowe nadal są pisane na potrzeby pojedynczych projektów, rzadko natomiast są tworzone po to, by można było bez zmian wykorzystać je w innym projekcie.


TOP 200