Microsoft .NET to propozycja środowiska do tworzenia rozproszonych aplikacji. Jego podstawowymi elementami są tzw. Web Services komunikujące się z wykorzystaniem standardów internetowych.

Web Services odpowiadają obiektom COM i ActiveX, ale są definiowane w inny sposób. COM jest specyfikacją binarną. W uproszczeniu oznacza, że pewne elementy obiektu muszą znajdować się w ściśle określonych miejscach pliku. Natomiast Web Service określa sposób, w jaki aplikacja udostępnia swój interfejs. Specjalny język (WDLS), oparty na XML, pozwala dokładnie opisać każdą z metod, typy parametrów itp. Komunikacja - zdalne wywoływanie metod czy dostęp do interfejsu - odbywa się za pośrednictwem SOAP lub metod GET/POST protokołu HTTP. Web Service jest niezależny od platformy. Odpowiedni interfejs może być udostępniany zarówno przez aplikację bankową napisaną w COBOL-u i działającą na mainframe, jak i przez stronę ASP+ funkcjonującą na serwerze IIS 5.0.

Wspólny runtime

Aplikacja przeznaczona dla .NET korzysta ze specjalnej maszyny wirtualnej i środowiska, które izoluje program od podstawowych usług systemu operacyjnego. W ten sposób aplikacja .NET nie może zawiesić całego systemu operacyjnego, podobnie jak w przypadku Javy.

Common Language Runtime (CLR) - runtime wspólny dla wielu języków programowania - korzysta z tego, że kompilatory dla platformy .NET mogą tworzyć specjalny, zoptymalizowany pod względem wielkości kod w MSIL (Microsoft Intermediate Language). Po wgraniu go na maszynę kliencką jest on kompilowany do kodu binarnego właściwego danej platformie (native code) i wykonywany. Kompilator więc znajduje się na komputerze użytkownika. CLR odpowiada za zarządzanie pamięcią, wywoływanie metod, tłumaczenie typów danych między obiektami tworzonymi w różnych językach itp.

Elastyczny interfejs

Na podstawie CLR zdefiniowano dwie biblioteki odpowiadające za interfejs użytkownika: WinForm i WebForm.

WebForm to model obiektowy dostosowany do interfejsu internetowego, opartego na HTML/XML/DHTML. Co ciekawe, dokładny wygląd interfejsu nie musi być określony. Środowisko .NET ma możliwość automatycznego dostosowywania interfejsu do możliwości przeglądarki. Jeżeli klient posługuje się przeglądarką obsługującą tylko HTML 3.2, niektóre operacje związane z obsługą interfejsu użytkownika będą zrealizowane przy użyciu specjalnych kontrolek działających po stronie serwera. Jeżeli będzie to Internet Explorer 5.0, zostanie przygotowana strona DHTML. Projektowanie WebForm z poziomu Visual Basic 7 przypomina projektowanie standardowych formatek VB - programista, znający Visual Basic, szybko przyswoi posługiwanie się WebForm.

WinForm jest kolekcją obiektów odpowiadających klasycznym elementom interfejsu Windows. WinForm można traktować jak obiektowy odpowiednik biblioteki GDI. Programista, manipulując określonymi zestawami właściwości, może ustawiać atrybuty obiektów - kolor czcionki czy sposób cieniowania. Ciekawostką jest to, że jeżeli zmiana właściwości wymaga ponownego utworzenia okna, to WinForm automatycznie wykona określone operacje, ponownie tworząc okno i ustalając jego zawartość. WinForm zawiera rozbudowaną bibliotekę, która automatycznie rozmieszcza obiekty po zmianie wielkości okna bądź automatycznie kontroluje jego strukturę.

W WinForm zdefiniowano mechanizm pozwalający na przejmowanie pewnych komunikatów przekazywanych do elementów interfejsu użytkownika. Przechwytywanie komunikatów przy użyciu WinForm jest łatwiejsze niż w C++ czy VB 6.0. Dzięki temu, że wszystkie operacje są kontrolowane przez CLR, istnieje możliwość kontynuowania działania nawet po błędnej obsłudze komunikatu.

Jakkolwiek WinForm i WebForm mają podobny model obiektowy, to nie są zgodne. Nie jest możliwe automatyczne przekształcenie aplikacji z interfejsu opartego na WinForm na interfejs typu WebForm.

Uniwersalna architektura

Środowisko .NET pozwala także na tworzenie i uruchamianie "klasycznych" aplikacji, które bezpośrednio komunikują się z API systemu operacyjnego czy korzystają z istniejących kontrolek ActiveX. Wówczas jednak nie jest możliwe wykorzystanie wszystkich możliwości .NET

Specyfikacja .NET, co należy pod-kreślić, jest niezależna od języka programowania. API .NET jest tak skonstruowane, że może być wykorzystywane z poziomu dowolnego języka, który ma zaimplementowane niezbędne mechanizmy. Microsoft zdefiniował Common Language Specification, która określa, jakie elementy muszą być zaimplementowane w danym języku, by było możliwe korzystanie i tworzenie obiektów .NET. Dzięki takiemu rozszerzeniu języka programistę nie interesuje to, czy biblioteka powstała w C# czy języku Eiffel. Podobnie wyjątek zgłoszony w C++ może być przechwycony w Visual Basicu.

Każdy obiekt .NET ma być samoopisującym się obiektem. Nie jest konieczne dołączanie np. plików nagłówkowych czy tworzenie oddzielnych plików IDL definiujących interfejs. Obecnie schematy pozwalające korzystać z .NET opracowano dla ponad 17 języków.

Bezpieczeństwo

W architekturze .NET rozbudowa- no model bezpieczeństwa i ochrony. Programista może zdefiniować, jakie uprawnienia są niezbędne, by dany kod mógł być wykonany. Użytkownik może natomiast, na podstawie np. podpisu Authenticode, decydować, czy dana aplikacja otrzyma określone prawa. Weryfikacja uprawnień odbywa się podczas wykonywania kodu aplikacji.

Drugi "model" bezpieczeństwa jest związany z uprawnieniami użytkownika. Jeżeli użytkownik nie ma np. prawa drukować, to wykonanie danego fragmentu kodu zostanie zablokowane przez CLR.

Dystrybucja i instalacja aplikacji

W środowisku .NET niemal całkowicie zmieniono sposób instalowania i dystrybucji aplikacji. W Windows 95 czy NT istnieje pojęcie tzw. bibliotek współdzielonych. Niektóre aplikacje wspólnie wykorzystują pewne biblioteki, np. standardowe zawierające implementację podstawowych struktur danych. Okazało się jednak, że producenci bibliotek współdzielonych często nie zapewniali pełnej zgodności wstecznej. Zdarzało się, że wgranie aplikacji z nowszą wersją biblioteki powodowało, iż inny program przestawał działać.

Jedno z założeń architektury .NET polega na tym, że użytkownik za pośrednictwem Internetu może uzyskać dostęp do aplikacji i będzie częściowo wgrywał je na komputer lokalny. Z tego względu ryzyko zastąpienia bibliotek współdzielonych byłoby duże. Microsoft przyjął więc założenie, że w architekturze .NET każda z aplikacji ma umożliwiać korzystanie dokładnie z tej wersji biblioteki, z którą była testowana. Może więc się zdarzyć taka sytuacja, że w Windows będą istnieć, a czasami nawet działać jednocześnie różne wersje tego samego komponentu.

Projektanci Microsoftu założyli także, że aplikacja musi samodzielnie zainstalować i zarejestrować się w systemie. Proces instalacji ma polegać na skopiowaniu odpowiednich plików. Ponieważ może się zdarzyć, że aplikacja będzie jednak działać z nowszą wersją komponentu niż założył to programista, użytkownik (lub system) musi mieć możliwość samodzielnego określenia zestawu komponentów, które razem będą działać poprawnie.

Kolejne założenie jest ściśle związane z tworzeniem aplikacji pobieranych z Internetu. W środowisku .NET aplikacja może być instalowana "na raty". Przy dostatecznie dokładnym rozbiciu na poszczególne składowe może być tak, że niemal każda funkcja znajduje się w oddzielnej "paczce" i dopiero wtedy, gdy użytkownik będzie chciał skorzystać z danego modułu, zostanie on zainstalowany na jego komputerze. Te wszystkie elementy sprawiają, że format paczki .NET jest złożony. Manifest definiujący to złożenie określa: zawartość paczki, wymagane zewnętrzne obiekty, dopuszczalne wersje tych obiektów, a także to, czy dany element może być współdzielony z innymi aplikacjami, kontrolę nad złożeniem, oprócz programisty, ma także administrator systemu. Może on samodzielnie zdefiniować złożenie, łącząc i dzieląc paczki.

Nie dotyczy to wyłącznie paczek pobieranych z Internetu. Podobnie zorganizowane są pliki EXE. Jednak w tym przypadku możliwe jest utworzenie takiego złożenia, że plik wykonywalny jest samodzielnym programem.

Usługi systemowe .NET

Do podstawowych usług .NET należy wiele zestawów API. Programista odwołując się do .NET/CLR może zarządzać wątkami, uzyskiwać dostęp do urządzeń I/O czy wykonywać operacje na bazach danych korzystając z ADO+. Ponadto określono usługi pozwalające na śledzenie i diagnostykę działania aplikacji. Tak naprawdę debuger jest wbudowany w środowisko .NET, które nie blokuje bezpośredniego dostępu do usług systemu operacyjnego. Jednak wtedy program musi być skompilowany bezpośrednio do asemblera (a nie do MSIL). Jednocześnie taka aplikacja nie może w pełni korzystać z usług .NET

Wraz z rozwojem platformy .NET Microsoft planuje wprowadzić wiele nowych elementów do usług syste- mowych .NET/COM+. Ma być moż- liwe jednoczesne uruchamianie oddzielnych instancji każdego z obiektów, np. z różną konfiguracją. Pozwoli to na kilkakrotne uruchomienie tej samej aplikacji serwerowej, innej dla każ- dego z klientów czy grup klientów. Ten element jest już zrealizowany w SQL 2000 - na jednym kompute- rze może w tym samym czasie działać kilka motorów bazy danych.

System ma mieć możliwość samodzielnego zatrzymywania (z prze- chowaniem stanu) i uruchamiania aplikacji. W ten sposób w razie gdy np. przez dłuższy czas dany element nie jest wykorzystywany, jest on usuwany z pamięci. Dotychczas istniał tzw. object pooling, gdzie niepotrzebne instancje obiektów były usuwane z pamięci. W architekturze .NET możliwe jest usunięcie aplikacji i wszystkich modułów, z których korzysta. Planowane jest także rozszerzenie możliwości śledzenia aplikacji. Środowisko .NET pozwoli na wykonanie "zrzutu" działającego obiektu (i wykonanie jego kopii) bez zatrzymywania pracy aplikacji.