Do premiery Longhorn - nowej wersji systemu operacyjnego Windows - upłynie jeszcze co najmniej 1,5 roku. Liczba i zakres zmian, jakie czekają twórców aplikacji, będą ogromne, dlatego już dziś warto przyjrzeć się nowej platformie.

Z punktu widzenia programisty Longhorn wprowadzi rewolucję, zasadniczo zmieniając konstrukcję i sposób pracy z systemowymi interfejsami API. Dotychczas Microsoft w kolejnych wersjach Windows zamieszczał kolejne edycje interfejsów API Win32. W każdej z nich ogólne zasady tworzenia aplikacji się nie zmieniały, pojawiały się jedynie nowe funkcje czy struktury. Interfejsy architektury .Net Framework 1.1 są w wielu przypadkach identyczne jak API Win32 (zwłaszcza Windows Forms). W Longhornie tymczasem będziemy mieć do czynienia z całkowicie przeorganizowanymi interfejsami API o nazwie WinFX. Według Microsoftu istniejące aplikacje korzystające z API Win32 będzie można uruchamiać na nowej platformie, jednak w niektórych miejscach będzie to wykonywane za pomocą warstw pośrednich "tłumaczących" wywołania Win32 na WinFX.

Na WinFX składają się trzy główne biblioteki: Avalon (warstwa odpowiadająca za wektorowy interfejs użytkownika), Indigo (środowisko zapewniające pewną komunikację w dowolnym środowisku sieciowym i umożliwiające praktyczną realizację wizji architektury SOA - Service Oriented Architecture) oraz WinFS (oparty na NTFS system plików z mechanizmami transakcyjnymi).

Wyślij i zapomnij

W dotychczasowych systemach operacyjnych jest udostępniany jeden stos sieciowy (i komunikacyjny), zakładający stałe lub prawie stałe połączenie między maszynami. W systemie Longhorn, oprócz tradycyjnego mechanizmu sieciowego, zostanie wprowadzony specjalny zestaw interfejsów API do obsługi połączeń sieciowych ad hoc, np. powstających w wyniku pojawienia się użytkownika w zasięgu sieci bezprzewodowej itp.

Z punktu widzenia programisty ważne jest to, że te dwa sposoby komunikacji są obsługiwane w taki sam sposób - wysokopoziomowe API w Indigo w podobny sposób obsługuje m.in. usługi Web, mechanizm .Net Remoting i Enterprise Services.

Warstwa komunikacyjna pomiędzy usługami jest pewna i niezawodna - dostarczenie komunikatu jest zawsze gwarantowane. Ponadto WinFX obejmuje API pozwalające łatwo wykrywać zmiany stanu aplikacji sieciowych. Aby np. zobaczyć wszystkie otwarte gniazdka i nasłuchujące porty TCP/IP czy znaleźć aplikację, która dane porty otworzyła, wystarczy kilka linijek kodu. Można więc łatwo obsłużyć zdarzenie zgłaszane w momencie, gdy kabel zostanie odłączony od karty sieciowej, albo gdy pojawi się urządzenie wykorzystujące Bluetooth. Także dostrzeżenie zmian konfiguracji będzie łatwe, a aplikacja odpowiednio na nie zareaguje.

W komunikacji można zarówno stosować API przypominające zdalne wywołanie procedur (RPC), jak i wykorzystać mechanizm przekazywania komunikatów (definiując porty, kanały itp.). W perspektywie doprowadzi to do zmiany myślenia o aplikacjach desktopowych. Każdy komponent systemu Longhorn jest bowiem usługą, mogąca działać samodzielnie lub jako element szerszego zestawu usług. SOA w pewnym sensie zaciera różnice między aplikacjami: serwerową i kliencką.

Duże zmiany wprowadzono w obsługujących komunikację klasach System .Net. W wielu miejscach domyślnie wykorzystywany jest protokół IPv6, zaś w system będą wbudowane m.in. obsługa protokołu FTP, buforowanie żądań HTTP czy automatyczne wykrywanie ustawień serwerów proxy. W systemie znajdzie się także tzw. HTTP Listener - moduł będący miniserwerem WWW, dzięki któremu stanie się możliwe stworzenie aplikacji wykorzystującej protokół HTTP bez konieczności instalowania IIS.

Gniazdka w WinFX mogą wykorzystywać mechanizm SSL i automatycznie szyfrować całą komunikację za pomocą wybranych certyfikatów. Tak samo można zaszyfrować komunikację w .Net Remoting.

Do komunikacji są wykorzystywane specjalne klasy obsługujące strumienie, a więc z punktu widzenia aplikacji nie ma większej różnicy, czy jest wykorzystywany SSL, czy też nie.

Jednym z problemów w .Net 1.1 było przekazywanie informacji o uwierzytelnianiu. W WinFX pojawia się klasa Authenticator, która pozwoli zapisać w dowolnym strumieniu (także przekazywanym kanałem .Net Remoting) informacje związane z uwierzytelnianiem, tak by np. po stronie klienta można było wykonać operację przy użyciu takiego właśnie kontekstu.

Transakcje zostały wbudowane w jądro systemu Longhorn w postaci komponentu KTM (Kernel Transaction Manager). Ma on być używany i przez system operacyjny, i aplikacje użytkowe. KTM działa z wykorzystaniem dwufazowego protokołu potwierdzeń, także w przypadku transakcji lokalnych. Uczestnikami tego typu transakcji mogą być izolowane procesy. Dzięki zastosowaniu mechanizmów transakcyjnych stanie się możliwe m.in. tworzenie niezawodnych tzw. punktów odzyskiwania danych (save points) i wiele innych funkcji.

Transakcja nie musi się ograniczać do operacji zachodzących na jednym komputerze - mechanizm KTM może wykorzystać usługi DTC (menedżera rozproszonych transakcji) albo integrować się z warstwą protokołów sieciowych, zapewniając transakcyjność na poziomie komunikacji! Indigo ma udostępniać specjalny mechanizm umożliwiający wykonanie w ramach transakcji dowolnego kodu .Net, i to bez konieczności pisania kodu kompensacyjnego, jak w przypadku architektury COM.