Manifest technologii jutra

Transmisja w kolorze Indigo

Indigo to warstwa komunikacyjna, która ma ujednolicić sposób przesyłania informacji między systemami i aplikacjami - bez względu na fizyczne medium. Indigo oraz nowa architektura .Net Framework znacznie upraszczają tworzenie aplikacji zgodnych z promowaną przez Microsoft architekturą SOA (Service Oriented Architecture). Traktuje ona oprogramowanie jako zbiór wzajemnie powiązanych usług.

Ma ono także być przystosowane do sieci tworzonych ad-hoc - np. gdy urządzenie znajdzie się w zasięgu sieci radiowej. Sieci tego typu niosą wiele różnych problemów, jak choćby kłopot w definiowaniu "tymczasowych" węzłów. Interfejsy API Indigo zaprojektowano w taki sposób, aby informacja nie zaginęła, mimo nagłych problemów z komunikacją. Poza tym droga komunikatu (zasady routingu) mogą zależeć od aktualnie dostępnych połączeń, choć oczywiście Indigo nadaje się do wykorzystania w sieciach ze ściśle zdefiniowanym szkieletem. Dla programisty ważne jest to, że w obu sytuacjach komunikację programuje się identycznie.

Indigo bezproblemowo współpracuje zarówno z usługami COM+, MSMQ, WSE (Web Service Extensions), jak i "zwykłymi" usługami Web. Dla każdego z tych środowisk Indigo udostępnia ten sam zestaw API i ujednolicony model komunikacji między usługami. Znakomicie upraszcza to budowanie nawet bardzo skomplikowanych, rozproszonych aplikacji, programisty nie interesuje bowiem, czy faktycznie komunikacja wykorzystuje usługi web, czy też jakiś mechanizm typu remoting.

W architekturze .Net Framework 1.x komponenty realizujące transakcje korzystały z motoru COM+.

Indigo będzie zgodne koncepcyjnie z EnterpriseServices (COM+), a jednocześnie da mu zupełnie nowe możliwości. Przykładowo, w ramach jednej transakcji będzie można wykonać dowolny ciąg instrukcji CLR - i dopiero po ich wykonaniu zdecydować, czy transakcję należy potwierdzić, czy też ją wycofać. Definicja transakcyjności w Indigo precyzuje wiele zagadnień związanych z przekazywaniem tzw. kontekstu transakcji. Na przykład dzięki odpowiedniej konstrukcji klas można dokładnie decydować, które funkcje mają prawo "zatwierdzania" transakcji, a które nie.

Pełna implementacja Indigo będzie dostępna dopiero w momencie ukazania się systemu Longhorn, jednak spory podzbiór jego docelowych funkcji ma zostać udostępniony znacznie wcześniej - mniej więcej w połowie 2004 r. wraz z wersją Whitbey pakietu Visual Studio .Net.

Rewolucja na styku

W Longhorn pojawi się zupełnie nowa warstwa interfejsów API o nazwie WinFX. Microsoft tworzy ją od podstaw, będzie więc ona wolna od wad i historycznych zaszłości trapiących API Win32. WinFX to przeorganizowane logicznie Win32 wzbogacone w funkcje wynikające z nowych możliwości Longhorn i udostępnione jako zestaw przestrzeni nazw platformy .Net. Aplikacje zgodne z API Win32 będzie można nadal pisać i uruchamiać w środowisku Longhorn - Microsoft udostępni odpowiednią warstwę pośrednią. Jednak nie ma co ukrywać - różnica między WinFX a Win32 jest mniej więcej taka jak między Win32 a Win16, czyli zasadnicza. Dopiero zastosowanie .Net pozwoli wykorzystywać rozliczne zalety systemu Longhorn.

Na białym koniu

Whitehorse to nowy zestaw narzędzi pozwalający programiście łatwiej zrozumieć trudności wynikające z wdrażania jego dzieła w konkretnym środowisku. Za jego pomocą poszczególne składniki aplikacji można dostosować do lokalnych warunków wykonawczych, np. zdefiniować, jakie porty muszą być otwarte na zaporze firewall czy też jakie uprawnienia mają być przypisane poszczególnym komponentom. Nawet w edytor Visual Studio .Net wbudowano wiele mechanizmów, które "sprawdzają", czy przy danych warunkach aplikacja będzie działać. Wszystko to pozwala projektować aplikacje, uwzględniające kształt istniejącej w firmie infrastruktury, i dostosować je na bieżąco do zmieniających się warunków. Innymi słowy, Whitehorse pozwala zaprojektować całą infrastrukturę SOA - od poziomu najbardziej ogólnego, aż do poszczególnych usług.


TOP 200