ActiveX

Microsoft wprowadził wraz z Internet Explorer 3.0 nowy typ obiektów ActiveX, które są nie tylko "przeciwwagą" dla apletów Javy (zwłaszcza że specyfikacja ta pojawiła się wtedy, gdy popularność Javy znacznie rosła). ActiveX mogą zastąpić aplety Javy tylko tam, gdzie strony WWW działają na komputerach wyposażonych w system operacyjny obsługujący COM. Są zbiorem pewnych interfejsów pozwalających wykorzystywać istniejące elementy OLE do współpracy z Internetem oraz mechanizmów obsługujących standardy internetowe. Istnieją więc kontrolki ActiveX – odpowiednik elementów kontrolnych OLE – które mogą być osadzane na stronach !WWW. Istnieją serwery ActiveX – odpowiednik serwerów OLE obsługujących dokumenty złożone – które mogą także wyświetlać dokument w oknie przeglądarki i obsługiwać osadzone obiekty ActiveX.

Zamiast dokumentu złożonego, jest dokument ActiveX, który w odróżnieniu od tradycyjnego nie jest dokumentem statycznym, ale może zmieniać się w czasie przeglądania. Dokumenty z elementami ActriveX - z jednej strony - przypominają dokumenty np. Worda, z drugiej - aktywne strony !WWW. Obiekty ActiveX mogą także działać po stronie serwera i stamtąd modyfikować stronę WWW widzianą przez klienta (podobnie jak skrypty CGI).

Każdy obiekt ma w rejestrze zapisany unikatowy numer (tworzony z liczby losowej, aktualnej daty oraz numeru karty sieciowej komputera). Powstaje on w czasie tworzenia danej aplikacji/obiektu i nie powinien się zmieniać. Posługując się tym numerem, można znaleźć obiekt i konkretny interfejs.

CORBA a COM

Dla porównania warto przedstawić inny model komponentów obiektowych – CORBA grupy OMG i dokumentu złożonego OpenDoc. CORBA to specyfikacja obiektowa, zapis semantycznych powiązań oraz idei, oddzielony od implementacji. Obiekt w specyfikacji CORBA przypomina obiekty znane z języków programowania – możliwe jest np. dziedziczenie jednego obiektu przez drugi. Ponadto obiekt jest tu tworem samoopisującym się – nie trzeba tworzyć specjalnych narzędzi do odczytu opisu interfejsu (jak IDispatch w COM).

CORBA była tworzona z myślą o środowisku rozproszonym. Dzięki temu w specyfikacji są zawarte odpowiednie mechanizmy, pozwalające działać poszczególnym obiektom za pośrednictwem sieci. Jednak CORBA nie definiowała sposobu, w jaki taka komunikacja ma być wykonywana (określony był tylko model obiektowy), producenci więc w różny sposób go wdrażali. Podobnie było w przypadku łączenia obiektów i języka programowania. Tym zadaniem zajmuje się m.in. ORB (Object Request Brooker) - sposób tworzenia referencji do danego obiektu znów zależy od producenta konkretnej implementacji. Natomiast w specyfikacji CORBA 2.0 określono IOR (Interoperable Object Reference) - standard pozwalający łączyć się z ORB-ami różnych producentów.

Proces tworzenia statycznego obiektu CORBA składa się z następujących elementów. Najpierw tworzony jest skrypt IDL (podobny do tego w obiektach COM), który określa powiązania między obiektami oraz ich interfejsy. Następnie specjalny analizator składniowy tworzy szkielet dla konkretnego języka programowania. Po zaimplementowaniu metod i ich skompilowaniu, tworzony jest właściwy obiekt. Powstaje specjalny nagłówek (stub) dla klienta, a na serwerze łączony jest podobny nagłówek z implementacją. Równocześnie informacja o obiektach umieszczana jest w tzw. Interface Repository, specjalnej bazie danych, zawierającej informacje o "zarejestrowanych" obiektach. CORBA pozwala na lepsze wykorzystanie technik obiektowych podczas tworzenia komponentów, toteż w tej bazie zawarte są pełne informacje o obiektach, a nie - jak w COM - tylko unikatowe numery przypisane interfejsom/obiektom. Dzięki takiej strukturze łatwiej jest sprawdzać poprawność przekazanych typów danych, odczytywać informacje o obiekcie czy łączyć się między ORB-ami różnych producentów. Dynamiczny obiekt CORBA nie korzysta ze specjalnego nagłówka, ale bezpośrednio pyta Interface Repository o nazwę i opis obiektu, po czym - na podstawie uzyskanych informacji - tworzy odpowiedni element. Jest to działanie podobne do mechanizmu automatyzacji w COM.

Współpraca obiektów CORBA i COM

Można łączyć CORBA/OpenDoc i COM/OLE. Powstały specjalne bramki łączące te dwa modele, np. ComponentGlue firmy Novell. W czerwcu 1995 r. OMG opublikował standard bramki łączącej CORBA i COM.

Zalety składania aplikacji

Programowanie przy użyciu komponentów ma zalety i wady. Na pewno monolityczna aplikacja, napisana przez jednego producenta, jest bardziej spójna. Jednak wykorzystanie gotowych obiektów ma również zalety. Po pierwsze, łatwiej można pracować w dużej grupie, ponieważ istnieje standard łączenia poszczególnych elementów. Po drugie, jeżeli produkt składa się z komponentów, to stosunkowo łatwo dostosowywać go do indywidualnych wymagań firmy lub do zmian, jakie zaszły na rynku. Po trzecie, na rynku programistycznym automatycznie znalazło się miejsce dla małych developerów, którzy produkują komponenty wykorzystywane przez innych. Po czwarte, zadowolony jest ostateczny użytkownik, który łatwiej wymienia dane z innymi programami, a korzystając ze skryptów i automatyzacji, może dostosowywać aplikację do swoich potrzeb.