[PL] Zaległe pytanie - przyszłość COM?
W lutym w ramach propozycji pytań do Steve'a Sinofsky dostałem parę pytań, których jak na złość nie miałem szans przekazać dalej.
Jedno z pytań, które dostałem na boku (poza komentarzami) dotyczyło przyszłości COM w Windows (w konteście rozwoju .NET Framework). W między czasie sam się zastanowiłem nad potencjalną odpowiedzią na to pytanie.
Zanim jednak odpowiem przydało by się parę spraw wyjaśnić.
Czym jest COM tak własnymi słowami?
* COM to element infrastruktury, który pozwala na rejestracje i instancjonowanie obiektowych komponentów na pojedynczej maszynie.
* COM definiuje zestaw mechanizmów, binarnych formatów danych, itd które COMpatybilne komponenty muszą wspierać. Dzięki temu aplikacja napisana w VB jest dostępna dla aplikacji C++, która znowu może być bez problemu instancjonowana przez Delphi, i tak dalej...
* COM jest szeroko wykorzystywany w komponentach i aplikacjach Microsoft, od systemu operacyjnego Windows poprzez Office System, SQL Server, Exchange i wiele innych aplikacji.
* mamy DCOM, który rozszerza zasięg COM. Pozwala aplikacji komunikować się pomiędzy komponentami COM instancjonowanych na różnych maszynach. Tutaj nie wnikając w technikalia wszyscy pamiętamy parę problemów jakie DCOM napotkał, zatem powstał..
* .. COM+, który jest pakietem usług uruchomieniowych (tu se cymbał trudne słowo na runtime wybrał) , które odpowiadają za cały cykl życia komponentów COM+. Mechanizmy COM wiedzą jak instancjonować obiekty na rządanie, jak je niszczyć gdy już nie są potrzebny. COM+ posiada także pare ważnych cech w kontekście transakcyjności.
Tak w skrócie podsumowując najważniejsze parę rzeczy z COM jakie przyszły mi do głowy pozwolę sobie przeskoczyć na .NET Framework w kontekście COM, gdzie:
* .NET Framework pozwala na o wiele łatwiejsze i bardziej elastyczne stworzenie tego co zapoczątkował COM.
* Pozwala uniknąć parę naturalnych pułapek i trudności jakie COM ze względu na architekturę i dostępne narzędzia reprezentuje.
* .NET Framewok (CLR) po prawdzie sam jest serwerem COM+
* w .NET Framework (System.EnterpriseServices) można programować obiekty widoczne na zewnątrz jako komponenty COM+ (które już system instancjonuje i zarządza jak regularnymi obiektami COM+)
Teraz jak zbiorę tę parę myśli razem i pomyślę o przyszłości to wydaje mi się, że COM na poziomie systemowym pozostanie z nami bardzo długo (nie bałbym się zasugerować okresu dłuższego niż ponad dekadę).
Jako platforma do programowania oczywiście zawsze i wszędzie będę rekomendował .NET Framework (żeby nie było wątpliwości), jednak na poziomie uruchamianych usług i wsparcia systemu dla tej technologii nie wyobrażam sobie, aby nagle Windows przestał wspierać COM w jakiejkolwiek formie.
W tym temacie przypominają mi się bardzo ciekawe opinie na ten temat napisane dawno temu przez Richarda Turnera:
https://blogs.msdn.com/richardt/archive/2004/07/21/190742.aspx - fajny komentarz na temat tego kiedy warto zainteresować się Enterprise Services, kiedy Webservice'ami a kiedy .NET Remoting.
Podobnie zadane pytanie gdyby dotyczyło .NET Remoting (w końcu jest WCF) uzyskuje odpowiedź także na blogu Richarda:
https://blogs.msdn.com/richardt/archive/2004/03/05/84771.aspx
Dla osób zastanawiających się jak będzie niedługo wyglądał świat usług na platformie Microsoft proponuje cały czas proponuje przyglądać się rozwojowi wydarzeń wokół tajemniczo brzmiącego "Oslo", o którym już wielokrotnie wspomniałem. COM'a to napewno nie zabije, aczkolwiek jest co śledzić przyznam :)
Technorati Tagi: Polish posts,babbling,.NET Framework,SOA,Oslo