Java i .Net: komponenty

W technologiach Java i .Net istnieją ustalone sposoby tworzenia komponentów. Oba modele, choć mają wiele podobnych funkcji, różnią się wieloma szczegółami.

W technologiach Java i .Net istnieją ustalone sposoby tworzenia komponentów. Oba modele, choć mają wiele podobnych funkcji, różnią się wieloma szczegółami.

W Javie programiści mają do dyspozycji komponenty JavaBeans i ustaloną przestrzeń bibliotek systemowych, które udostępniają interfejsy API. Również w .Net dostępne są biblioteki standardowe, komponenty .Net oraz interfejsy do komunikacji z technologią COM i usługami Web.

Kłopotliwe biblioteki

Ewolucja technologii i komponentów Microsoftu i Sun Microsystems

Ewolucja technologii i komponentów Microsoftu i Sun Microsystems

Problem bibliotek standardowych jest stary, jak samo . Każdy program działa w pewnym środowisku (systemie operacyjnym), które zapewnia podstawowe usługi, np. wyświetlanie informacji na ekranie, zapis danych do pamięci lub pliku. Większość aplikacji zawiera bardzo zbliżone fragmenty funkcjonalne, np. sortowanie elementów czy operacje matematyczne. Dość szybko pojawiły się więc biblioteki standardowe dla języków Fortranu, C, później dla C++, mniej więcej takie same dla każdego kompilatora. Mimo to nie udało się zapobiec sytuacjom, w których część usług jest niedostępna w danym środowisku albo system operacyjny zapewnia większą funkcjonalność, niż zakłada biblioteka.

W Windows programista ma do dyspozycji:

  • API Win32 nieznacznie różniące się między Windows 9x a NT;

  • Native API, które komunikuje się bezpośrednio z kernelem systemu operacyjnego;

  • biblioteki standardowe danego języka programowania (MFC, runtime VB, VCL Borlanda);

  • komponenty COM realizujące określoną usługę, np. CAPI COM obsługujący kryptografię.

    Aby utworzyć na dysku plik, można użyć jednej z sześciu funkcji Windows, której towarzyszą dodatkowe funkcje do zapisu plików. Co gorsza, nie ma jednej odpowiedzi, który sposób tworzenia pliku jest właściwy - każdy ma wady i zalety.

    W przypadku Javy dochodzi jeszcze konieczność ujednolicania różnych architektur sprzętowych i systemów operacyjnych. Obszerny interfejs API Javy powstał jako pewnego rodzaju kompromis. Jeśli czegoś nie może wykonać bazowy system operacyjny, symuluje to maszyna wirtualna. Problem pojawił się w przypadku wymiany informacji w drugą stronę: gdy program napisany w Javie miał korzystać z niestandardowych możliwości systemu. Sun rozwiązał to opracowując interfejs JNI, który pozwala odwoływać się do niestandardowych interfejsów API bazowej platformy czy biblioteki. JNI jest dostosowany do jednego języka - C. Należy podkreślić, że wiele serwerów aplikacyjnych implementuje dodatkowe mechanizmy współpracy z komponentami np. Borland AppServer i VisiBroker pozwalają na połączenie składników COM, J2EE i CORBA.

    Opublikowany na początku br. .Net jest pierwszą, kompleksową biblioteką standardową na platformie Windows. Obejmuje olbrzymi zakres API: funkcje biblioteczne Win32, standardowe komponenty COM, usługi serwisowe Windows i elementy spotykane w bibliotekach VB czy C++.

    W .Net również pozostawiono "furtkę" do wywołań API bazowego systemu operacyjnego. PInvoke bardzo przypomina interfejs JNI, zawiera jednak mechanizm wspierania rozrządu (marshaling) i przy pewnych zabiegach pozwala na wywoływanie klas napisanych w C++.

    W .Net dostępne są mechanizmy do współpracy z COM. Istnieje odpowiedni zestaw typów i usługi pozwalające odwoływać się z poziomu .Net do komponentów COM, tak jakby były to rodzime komponenty .Net (są tworzone specjalne klasy "szkieletu"). Funkcjonalność jest realizowana za pośrednictwem odwołań do bazowego komponentu COM. Mechanizm ten jest wykorzystywany w wielu klasach .Net.

    Trzeba jednak liczyć się z tym, że nie każdy komponent COM będzie działał na platformie .Net. Nie można uruchomić komponentów wizualnych typu windowless. Niektóre odwołania do interfejsu IDispatch czy parametrów/właściwości bez ściśle określonego typu będą wymagały pisania własnych klas pośredniczących (.Net wymaga w wielu miejscach silnej kontroli typów). Komponent lub klasa .Net może być również "opakowana" w interfejs COM. Paradoksalnie, zazwyczaj to znacznie prostsze niż przystosowanie obiektów COM, by pracowały w środowisku .Net.

    Procedury tworzenia bibliotek Javy i .Net. są całkowicie odmienne. W przypadku Javy mamy do czynienia ze swoistym komitetem, który tworzą producenci serwerów aplikacyjnych i innych elementów platformy J2EE. Ostateczne, "oficjalne" API jest wynikiem kompromisu zawieranego między wieloma producentami oprogramowania. Twórcy Javy nie muszą zachowywać zgodności ze starszymi API - jednak nawet w obrębie samej Javy można znaleźć pewną liczbę interfejsów, które były dostępne w 1.1x a w 1.2x (czy 2.x) zostały zmienione bądź wycofane. Jedynymi mechanizmami zgodności ze starszą technologią są interfejsy do modelu komponentowego CORBA.

    .Net zostało tak skonstruowane, by programista znający główne interfejsy najpopularniejszych obiektów COM czy semantykę API mógł dość szybko poruszać się w nowym środowisku.