Kiedy zaproponowano mi napisanie artykułu o roboczym tytule '.Net, Dot What?', analizującego .Net z punktu widzenia inżynierii oprogramowania, moją pierwszą reakcją było: dlaczego nie, znam tę technologię całkiem nieźle i nie powinienem mieć trudności. Kiedy jednak zabrałem się do pisania, szybko doszedłem do wniosku, że trudno odpowiedzieć na pytanie 'Dot What?' bez odpowiedzenia na dwa dodatkowe pytania: 'Dot Why?' i 'Dot How?'. Innymi słowy, trudno jest dyskutować o technologii .Net bez przedstawienia kontekstu, w którym jest ona tworzona.

Zacznę więc od kontekstu i na jego tle krótko opiszę, jak pozornie niezbyt spójna seria technologii układa się w logiczną całość oraz w jakim kierunku zmierza.

Do dzisiaj specjaliści dzielą rynek aplikacji biznesowych na aplikacje biurkowe (desktop applications), zwane również front office albo knowledge worker applications, oraz aplikacje korporacyjne (enterprise applications), zwane też back office albo business core applications. Microsoft jest dominującą siłą w pierwszym z tych dwóch segmentów rynkowych. Oferuje wszystko - począwszy od systemów operacyjnych serii Windows z wbudowaną przeglądarką internetową, przez produkty dla indywidualnego użytkownika sprzedawane w pakiecie Microsoft Office, aż po Microsoft Exchange Server, który pozwala komunikować się grupom użytkowników.

Drugi segment rynkowy był tradycyjnie zdominowany przez produkty sprzętowe i programowe IBM-a, takie jak komputery mainframe, systemy operacyjne IBM-a, baza DB/2 czy monitor transakcji CICS. Produkty unixowe również należałoby zaliczyć do tego segmentu.

Oba te segmenty rynkowe różnią się też zasadniczo pod względem sposobu sprzedaży. W pierwszym z nich sprzedaje się duże ilości w miarę tanich produktów "z pudełka", z małą liczbą usług dodatkowych. W drugim segmencie natomiast sprzedaje się produkty w znacznie mniejszych ilościach i znacznie mniejszej liczbie klientów, ale każdemu produktowi towarzyszy bogata oferta usług.

Na tym rozwarstwionym rynku Microsoft potrzebował strategii, która pozwoliłaby jego produktom przejść z segmentu aplikacji biurkowych do segmentu aplikacji korporacyjnych. Firma postąpiła rozsądnie i nie wzięła bezpośrednio jako cel skomplikowanych, krytycznych (mission critical) systemów dla wielkich korporacji, ale skoncentrowała się na małych i średnich przedsiębiorstwach budujących aplikacje biznesowe z wykorzystaniem technologii z Redmond. Pierwszymi krokami tej strategii były budowa Microsoft Transaction Server (MTS) i późniejsza jego integracja z systemem operacyjnym, budowa Microsoft Message Queue Server (MSMQ), następnie inwestycje w SQL Server oraz praca nad technologiami klastrowymi, a wreszcie seria serwerów, takich jak BizTalk Server, Commerce Server itd.

Wszystkie te inwestycje jako podstawę miały jednak bardzo tradycyjną, trójwarstwową architekturę systemów - z bazami danych u podstawy, logiką biznesową w środku i dialogiem z użytkownikiem na górze. Mniej więcej w tym samym czasie, kiedy Microsoft zaczął agresywnie inwestować w składniki architektury dla aplikacji korporacyjnych (enterprise applications), architektura ta znalazła doskonałe ujęcie w ogólnodostępnej specyfikacji Java 2 Platform Enterprise Edition (J2EE) i wielu produktach, które realizują te specyfikacje. W odpowiedzi na J2EE Microsoft dokonał bardzo interesującego manewru strategicznego. Zamiast rozwijać ekwiwalent J2EE, przedstawił swoją wizję architektury do łączenia rozproszonych systemów, urządzeń i ludzi, bazującą na usługach Web, komunikacji w języku XML i różnego rodzaju serwerach, czyli wyspecjalizowanych systemach wspomagających. .Net to ogólny termin określający tę nową architekturę i jej składniki technologiczne.

Common Language Runtime

Zasadniczym elementem architektury .Net jest .Net Framework. Z punktu widzenia inżynierii oprogramowania jest to bardzo eleganckie rozwiązanie techniczne. Jego podstawą jest Common Language Runtime (CLR). Pojęcie komponentu wykonywalnego (runtime component) nie jest nowe w językach oprogramowania.

Nie tylko Java, ale także Python czy Visual Basic (VB) mają taki komponent. Tym, co wyróżnia CLR, są: ścisłe zintegrowanie z systemem operacyjnym i fakt, iż CLR jest wspólne - stąd common - dla wszystkich języków programowania .Net. Przede wszystkim oczywiście dla języków Microsoftu: VB, C# i C++ (dokładniej mówiąc, zarządzanego managed C++). Innymi słowy, programy napisane za pomocą wszystkich wyżej wymienionych języków platformy .Net są kompilowane to tego samego kodu pośredniego oraz tego samego systemu typów (type system) i na poziomie CLR wyglądają dokładnie tak samo.

Programy pisane dla CLR są grupowane w jednostki nazywane zarządzanymi pakietami kodu (managed code assembly). Każda taka jednostka ma opis, który pozwala CLR na optymalne zarządzanie nią; tworzenie obiektów, wywoływanie metod, zarządzanie pamięcią, odśmiecanie jej (garbage collection), zarządzanie wątkami (thread management), obsługę wyjątków (exception handling) itd. Taki pakiet zastępuje bibliotekę DLL - jest jednostką oprogramowania, która może być łączona z innymi jednostkami za pomocą swojego interfejsu. W tradycyjnym DLL mechanizmy interfejsu bazują na bardzo specyficznych regułach kompilowania, z wykorzystaniem wskaźników do funkcji. W pakiecie .Net wszystkie interfejsy są kompilowane do tego samego formatu i jednakowo interpretowane przez CLR. Środowisko pośredniczy w wywoływaniu metod, przekazywaniu argumentów do nich i zwracaniu wartości. CLR zawiera także system typów, wspólny dla wszystkich języków .Net. Na przykład łańcuch znakowy (string) w C# jest reprezentowany tak samo jak w VB czy zarządzanym C++.

CLR z jednej strony upraszcza model programowania w .Net, z drugiej, stanowi bazę dla nowych narzędzi programistycznych Visual Studio .Net.