Tradycyjne metody pracowitego kodowania aplikacji powoli wychodzą z użycia.

W miarę jak aplikacje stawały się bardziej złożone, trudniej było tworzyć spójny i bezbłędnie działający produkt . Problemy pojawiały się zwłaszcza wtedy, gdy zachodziła potrzeba drobnej zmiany w aplikacji (np. usunięcie błędu w procedurze), ponieważ należało ponownie zbudować cały produkt, co wiązało się z kolejnym testowaniem (i dystrybucją). Tak więc zamiast tworzyć jednolite, duże aplikacje, producenci starali się łączyć różne, tak by z pewnego rodzaju "puzzli" powstawał jednolity produkt. Jednak konieczne było stworzenie standardów pozwalających, aby firma mogła wykorzystywać komponenty wytworzone przez inne firmy lub były dostępne ogólne interfejsy, a komponenty danego producenta implementowały poszczególne funkcje, tak by semantycznie odpowiadały one opisowi interfejsu.

Komponenty w Windows

Pierwszym działaniem w kierunku ułatwienia integrowania aplikacji różnych producentów było DDE, czyli Dynamic Data Exchange. Interfejs DDE służył do wymiany danych między aplikacjami. Jest to mechanizm raczej prymitywny, oparty na wymianie kilku komunikatów (obsługiwanych także przez najnowsze wersje Windows), wysyłanych między aplikacją, pełniąca rolę klienta, a aplikacją serwerową. Wszystko to odbywało się na jednym komputerze. Niestety, wykorzystanie DDE nie jest proste – przy komunikacji pojawia się wiele sytuacji szczególnych, które każdy program musiał obsługiwać, a także, należało znać to, co umownie nazywa się "nazwą aplikacji", "tematem danych" i "elementem danych" –aplikacja klienta musiała znać wszystkie dane o serwerze, aby się z nim połączyć, i znać format danych przysyłanych przezserwer. Był to jednak znaczny postęp w łączeniu aplikacji różnych producentów, efektywniejszy od użycia schowka.

Następnie pojawiło się rozszerzenie DDE, tzw. Network DDE, które pozwalało na przesyłanie danych także za pomocą sieci. Komunikaty związane z Network DDE były bardziej złożone niż przy zwykłym DDE i niewiele aplikacji wykorzystało tę nową możliwość.

Lepsze wyniki z OLE

Następnym etapem w integracji aplikacji w systemie Windows była specyfikacja OLE 1.0 (grudzień 1990 r.). Nazwa pochodzi od Object Linking and Embeding i dokładnie określa przeznaczenie pierwszej wersji OLE, czyli model dokumentu złożonego, w którym mogą znajdować się elementy tworzone przy użyciu produktów różnych producentów. OLE 1.0 - jako metodę wymiany danych - wykorzystuje DDE, ale jego stosowanie jest znacznie wygodniejsze dla programisty. OLE pozwala na identyfikację aplikacji serwerowej. W tym celu używany jest rejestr Windows (plik REG.DAT w Windows 3.1), w którym znajduje się nazwa serwera (np. PBrush) oraz ścieżka do pliku, wykonującego wszystkie jego funkcje. Dzięki temu, gdy w dokumencie złożonym pojawia się rysunek Paint Brusha, zawiera on adnotację, że obsługuje go serwer o nazwie PBrush. Przy drukowaniu lub edycji wiadomo, który program jest odpowiedzialny za ostateczną postać dokumentu.

Jednak to rozwiązanie nadal ma wiele wad – przy edycji osadzonego obiektu konieczne jest otwieranie nowej aplikacji, zaś komunikacja odbywa się za pośrednictwem wolnych łączy, opartych na DDE. Ponadto podstawowym składnikiem dokumentu złożonego jest cała aplikacja.

Znacznie ulepszoną specyfikację OLE 2 i model komponentów obiektowych COM (Component Object Model) Microsoft ogłosił w maju 1993 r. COM jest specyfikacją binarną, określającą postać podstawowego obiektu. Na podstawie tego modelu konstruowane są interfejsy budujące OLE.

Ten numer wersji OLE nie ma już większego sensu – nie powstanie kolejna specyfikacja. Obecnie rozszerzany jest zbiór interfejsów dostępnych dla aplikacji, a także zmieniają się dostępne środki komunikacji obiektów (COM+, DCOM itp.). Jednak filozofia i podstawowe struktury pozostają nie zmienione.

Specyfikacja COM

COM to specyfikacja binarna (określane jest położenie wskaźników do poszczególnych interfejsów i funkcji), niezależna od języka programowania. Obiekty można tworzyć przy użyciu dowolnego narzędzia, nawet w asemblerze. Konstrukcja tabeli, która zawiera wskaźniki do metod obiektu COM, jest taka sama, jak konstrukcja tablic funkcji wirtualnych w większości kompilatorów C++ i innych języków. Przy użyciu tych kompilatorów łatwo pisze się obiekty COM, wykorzystując naturalne dla danego języka struktury obiektowe.