Warszawska konferencja Developers Days 2000 posłużyła Microsoftowi do prezentacji strategii .NET.

Można Microsoftu nie lubić, nie zgadzać się z polityką rynkową koncernu, ale trzeba przyznać, że firma ta organizuje najpoważniejszą, największą, otwartą imprezę dla programistów w Polsce. Przez dwa dni półtora tysiąca osób przysłuchiwało się prezentacjom poświęconym nowej recepcie na tworzenie aplikacji internetowych. W kuluarach mówiło się nawet, że niektóre firmy, np. InsERT z Wrocławia, wysłały na warszawską konferencję kilkudziesięcioosobowe zespoły programistów, zawieszając na ten czas funkcjonowanie działu rozwijającego oprogramowanie.

Na konferencji dało się wyróżnić dwa podstawowe nurty. Pierwszy, poświęcony nowej platformie .NET, która ma uprościć tworzenie aplikacji handlu elektronicznego i wymiany danych między przedsiębiorstwami. Drugi doty-czył platform serwerowych Microsoftu, które mają być podstawą rozwiązań wykorzystujących .NET. Każdy uczestnik konferencji otrzymał wersję beta 1 pakietu programistycznego Visual Studio .Net, a także wersje testowe aplikacji z serii .Net Enterprise Servers.

Szkielet współpracy

Z jednej strony.NET jest technologią rewolucyjną, z drugiej - można ją traktować jak ewolucyjną konsekwencję rosnących wymagań użytkowników. Jak niemal każde rozwiązanie Microsoftu, również .NET pozwala na współpracę nowych technologii z poprzednimi.

Platformę .NET można określić jako pewnego rodzaju ramę, która definiuje wspólne środowisko uruchomieniowe CLR (Common Language Runtime), a także zestaw usług systemowych, dostępnych dla aplikacji. Są to zarówno usługi podstawowe (np. zapis do pliku, wprowadzenie informacji), jak i bardziej zaawansowane, związane np. z obsługą danych.

W skład CLR wchodzi wiele mechanizmów, zapewniających m.in. obsługę wątków, przesyłanie wyjątków, motor do śledzenia aplikacji, kompilator języka pośredniego IL i automatyczny "odśmiecacz". Aplikacja może być kompilowana do IL albo pewne jej fragmenty mogą pomijać CLR i odwoływać się bezpośrednio do systemu operacyjnego.

Koncepcja .NET to w pewnym sensie kolejny, po wykorzystaniu komponentów, etap rozwoju aplikacji. Dzięki powstaniu specyfikacji CSL (Common Language Specification) i temu, że aplikacje mogą korzystać ze wspólnego CLR, w znacznym stopniu ułatwiono współpracę między elementami opracowanymi przy użyciu różnych języków. W ten sposób z komponentu napisanego w C# (język będący ważnym elementem nowej strategii Microsoftu) można dziedziczyć w kodzie Visual Basic (VB), można też w Visual Basicu przechwycić wyjątek, zgłoszony przez fragment kodu C++.

Usługi sieciowe

Dużą zmianą związaną z .NET jest stworzenie nowej kategorii usług. Wprowadzono tzw. usługi Web, mechanizm pozwalający udostępniać pewne funkcje aplikacji za pośrednictwem protokołów interne- towych, zarówno HTTP, jak i bardziej zaawansowanego SOAP. Jednocześnie dzięki zapewnieniu podstawowych usług wyszukiwania opartych na technolo- gii UDDI (pisaliśmy o niej obszernie w CW35/2000) możliwe jest stworzenie interesujących rozwiązań typu B2B. Wykorzystanie do komunikacji języka XML ułatwia łączenie systemów różnych przedsiębiorców, nawet jeżeli interfejsy usługobiorcy i usługodawcy są różne.

.NET pozwala korzystać z istniejących obiektów COM, które mogą działać jako tzw. kod nie obsługiwany, czyli odwołujący się bezpośrednio do systemu operacyjnego. Technologia .NET umożliwia także emulację usług COM. Komponenty .NET będą funkcjonowały wewnątrz obiektów COM. Współpraca przebiega również w przeciwnym kierunku - zestaw narzędziowy SOAP Toolkit dla Visual Basic pozwala udostępnić interfejs obiektu COM jako usługę Web.

Wraz z platformą .NET Microsoft wprowadził nowy model dostępu do danych ADO.NET. Zmiany te pozwalają na takie samo traktowanie informacji w formacie XML, jak danych pochodzących z tzw. providera OLEDB. Do obsługi XML programista stosuje te same narzędzia co do obsługi bazy danych. Jednocześnie wprowadzono nową warstwę w ADO.NET - DataSet, która pozwala odwzorować po stronie klienta związki pomiędzy tabelami znajdującymi się na serwerze bazodanowym.

Co dzieli .NET i Javę

Microsoft w rozwiązaniu .NET prezentuje zupełnie inne podejście niż Sun w technologiach związanych z językiem Java. Po pierwsze, w przypadku Javy jest wymagane, by rozwiązanie powstawało w jednym języku - w Javie. Po drugie, na danej platformie wszystkie rozwiązania towarzyszące muszą być konstruowane w taki sposób, aby to język Java "pasował" do problemu. Teoretycznie, programista, który poznał Javę, może w tym języku tworzyć aplikacje biurowe, komponenty rozproszone (J2EE), procedury wbudowane na serwerze bazodanowym (co drugi motor bazy danych wspiera ten język) czy programować urządzenia przenośne i tworzyć dedykowane sterowniki.

W przypadku .NET jest inaczej. Tak samo jak w języku Java istnieje maszyna wirtualna, z tym że w przypadku technologii Microsoftu jest ściśle określone, iż kod pośredni przed wykonaniem musi być skompilowany. W przypadku maszyn wirtualnych Java, zwykle kod jest interpretowany po stronie klienta. CLR nigdy nie interpretuje kodu: kompilacja zawsze odbywa się po stronie klienta.

W specyfikacji .NET nie ma określonego języka, w którym należy tworzyć rozwiązania. CLS podaje tylko minimalne wymagania, jakie są stawiane kompilatorowi (do kodu pośredniego IL). W ten sposób rozwiązania oparte na .NET można oprogramować w Pythonie, Perlu, Smalltalku, Visual Basicu, C# i innych. Specyfikacja CLS jest publicznie dostępna. Programista może wybrać narzędzie właściwe do danego zagadnienia.

Inne jest także podejście do zagadnień, związanych z bezpieczeństwem. W Javie zabezpieczenie dotyczy danego systemu operacyjnego. Maszyna wirtualna po prostu izoluje kod od systemu, zapewniając, że gdy aplikacja działa poprawnie, maszynę wirtualną można ponownie uruchomić.

W CLR oddano mechanizm cyfrowego podpisywania fragmentów kodu i przypisywania im odpowiednich praw na podstawie identyfikacji. Kod IL można również weryfikować pod kątem bezpieczeństwa sprawdzając, jakiego typu operacje wykonuje.