Koniec integracji

Microsoft dąży do tego, by w długim okresie potrzeba integracji aplikacji przestała istnieć. Aplikacje mają integrować się same, automatycznie, bez dodatkowych zabiegów - to tylko jeden z wątków konferencji TechEd 2005.

Microsoft dąży do tego, by w długim okresie potrzeba integracji aplikacji przestała istnieć. Aplikacje mają integrować się same, automatycznie, bez dodatkowych zabiegów - to tylko jeden z wątków konferencji TechEd 2005.

W tym roku TechEd 2005 zgromadziła ponad 6 tys. ludzi. Konferencja była poświęcona nie tyle zapoznawaniu słuchaczy z nowymi technologiami, ile raczej temu, w jaki sposób można je wykorzystać przy tworzeniu nowych aplikacji. Mowa oczywiście o .Net 2.0, SQL Server 2005 i Visual Studio .Net 2005. Nikomu nie przeszkadzało, że są to technologie mające wciąż jeszcze status wersji beta - widać było, że słuchacze większości wykładów już od pewnego czasu zajmują się tymi produktami. Po krótkiej rozmowie okazywało się zwykle, że w .Net 2.0 stworzyli już niemal gotowe aplikacje, korzystając z licencji "go live".

Wszędzie architektura

W tym roku duża część sesji poświęcona była architekturze rozwiązań projektowanych i realizowanych w .Net 2.0. Microsoft, jak się wydaje, kładzie coraz większy nacisk na właściwą organizację aplikacji. Firma coraz bardziej postrzega systemy informatyczne jako pewnego rodzaju federację usług - które trzeba ze sobą połączyć. Stąd właśnie gwałtowny rozwój Indigo - już nie jako części Longhorn, ale po prostu biblioteki komunikacyjnej. Oczywiście, w tle cały czas mowa była o bezpieczeństwie oraz o różnych technikach programistycznych.

Wiele prezentacji miało za zadanie pokazać, jak konstruować komunikację przy tworzeniu aplikacji SmartClient oraz jak organizować komunikację w architekturze SOA. Bardzo pożyteczne były wskazówki na temat tego, w jaki sposób łączyć pojęcia ze świata usług (w rozumieniu SOA) z ich obiektową implementacją. To jest problem, który często napotykają początkujący architekci rozwiązań SOA. Inną ważną sprawą omawianą szczegółowo było konstruowanie "kontraktów" i problemów związanych z wersjonowaniem komunikatów.

W tym miejscu warto dodać, że celem twórców .Net 2.0 było znaczne skrócenie kodu pisanego w celu rozwiązania standardowych elementów aplikacji. Coraz wyraźniej rysuje się tendencja, by aplikacja składała się z gotowych prefabrykatów (wywołań API) połączonych jak najmniejszą ilością kodu pisanego przez programistę. Sama logika aplikacji oczywiście musi być opisana kodem, ale tu z pomocą mają przyjść specjalne języki DSL. Pomocna ma być też koncepcja Software Factories (SF), która według Microsoftu ma być gotową do zainstalowania w Visual Studio "paczką z wiedzą", pozwalającą programiście szybciej zrozumieć dziedzinę/branżę. Na konferencji pokazano narzędzia pozwalające tworzyć SF, a także jak można konstruować własne języki DSL. Technicznie nie jest to operacja skomplikowana, podstawowy problem to dopracowanie spójnego słownika pojęć, a więc wiedza o tym, jak język ma funkcjonować.

Na przykład pokazany był specjalny język graficzny umożliwiający opis sposobu poruszania się użytkownika w aplikacji okienkowej (z wykorzystaniem User Interface Application Block). Projekt interakcji był diagramem przypominającym schemat blokowy. Prezentowano także narzędzie GAT i pakiet DSL Tools (do pobrania ze stron MSDN), które upraszczają konstruowanie SF. Pozwalają np. dodać odpowiednie zasoby, reguły walidujące oraz sposób, w jaki na podstawie symboli graficznych ma być generowany kod. Do opisu tego ostatniego procesu służy specjalny język T4 - przypominający trochę ASP.

Studio i Server

Większość prezentacji była poświęcona Visual Studio .Net 2005, .Net Framework 2.0 i SQL Server 2005. Każda z tych technologii była dosyć dokładnie opisywana na łamach CW, niemniej warto podkreślić, że wraz z nowym Visual Studio Microsoft rozpoczął chyba największy projekt związany z masowym i publicznym udostępnieniem wersji beta komercyjnej aplikacji. Chętnych do zgłaszania błędów jest ponad 33 tys. osób! Testerzy zgłosili ponad 15 tys. błędów i ponad 7 tys. sugestii i usprawnień.

Co ciekawe, spośród owych 15 tys. błędów tylko ok. 10% (i mniej niż 1 tys. sugestii) nie zostało jeszcze zamkniętych/uwzględnionych. Jednym ze zrealizowanych już postulatów wspólnoty programistów było dodanie opcji pozwalającej na edycję kodu aplikacji bez przerywania śledzenia także w języku C# - początkowo opcja ta miała być dostępna tylko w Visual Basic .Net.

Microsoft liczy także na to, że nowe Visual Studio uprości komunikację pomiędzy twórcą rozwiązania a jego administratorem w środowisku produkcyjnym. Projektanci w Visual Studio .Net 2005 mają (w ramach inicjatywy DSI) generować gotowe "polisy" do konfiguracji systemów informatycznych. Chodzi o takie zorganizowanie systemu, by o jego zasięgu i możliwościach wykorzystania stanowiły wyłącznie ustalone polisy, a nie architektura sprzętowa.

Tylko dwie prezentacje były poświęcone językowi C++. Jedna z nich była warsztatem prowadzonym de facto przez Intela, na którym pokazywano możliwości architektury HyperThreading i Dual Core, a także - w jaki sposób można pisać aplikacje, używając biblioteki OpenMP. Druga prezentacja była pokazem nowych elementów standardu C++ związanego z obsługą zarządzanej sterty. Mowa była także o tym, w jaki sposób pisać w C++ aplikacje używające architektury .Net. W .Net 2.0 C++ jest równoprawnym językiem tej architektury, podczas gdy w .Net 1.1 konieczne było zastosowanie konstrukcji "managed extension".

Na konferencji przedstawiony też został system kontroli wersji, będący częścią Team Foundation (TF). TF jest zintegrowaną platformą do zarządzania i tworzenia aplikacji. Zawiera mechanizm raportowania postępów analizujący definiowane tzw. work items czy też analizy postępów w usuwaniu błędów itp. Dla porządku, Hatter (nazwa kodowa nowego narzędzia SCC) nie ma nic wspólnego z Source Safe. Do przechowywania danych wykorzystuje SQL Server 2005. Przechowuje także zmiany (różnice), ale "wstecz", w wyniku czego wersja aktualna jest zawsze dostępna natychmiast.

Nowy SCC dodatkowo może buforować informacje jako pliki, tak by np. w przypadku rozproszonej grupy działało jedno, centralne repozytorium oraz specjalne proxy w biurach oddziałowych, które przyspieszą dostęp do serwera. Pracując z IDE programista może wybrać, czy określone pliki będą pobierane w trybie wyłączności (np. rysunki), czy też w trybie dzielonym, w którym wielu programistów wprowadza zmiany, które potem są razem łączone w momencie zatwierdzania.

Interfejsem dostępowym do serwera są Web Services. Każda operacja może mieć przypisany zestaw polis, które w określonych przypadkach mogą zawierać odwołanie do kodu .Net. Definiując gałęzie tak naprawdę przypisujemy określone "etykiety" wersjom plików. Można określić, jakie warunki musi spełniać kod, by mógł być zatwierdzany w innej gałęzi. Na przykład można wymagać, by przejście pomiędzy gałęzią "testową" a "produkcyjną" było możliwe tylko wtedy, gdy skompilowana aplikacja przejdzie wszystkie testy jednostkowe. Zasady mogą zależeć od tego, kto wysyła plik, do jakiej gałęzi, czy wręcz - jakiego folderu dotyczy.

Microsoft wstępnie zapowiedział, że TF (i narzędzie kontroli wersji) będzie też używane wewnętrznie, przy tworzeniu aplikacji Microsoft. Będą także dostępne aplikacje klienckie do Visual Studio .Net 2003, Visual Basic 6 i Visual C++ 6.0. Firma SourceGear opracowała program Allerton, który pozwala skorzystać z SCC w systemach Unix. Warto też dodać, że Microsoft planuje licencjonowanie Team Server na 2 sposoby: albo "na serwer", albo w taki sposób, że samo oprogramowanie jest darmowe, a klient musi wykupić licencje dostępowe dla programistów.

Programuj po angielsku

Na konferencji była także bardzo bogata ekspozycja firm partnerskich. Jednym z ciekawszych rozwiązań był pakiet iLOG, który pozwala definiować "reguły" biznesowe w języku naturalnym (tu: angielskim). Definiowany jest słownik, w którym do każdego słowa czy stwierdzenia przypisywane są pewne metainformacje. Następnie wszelkie warunki wyrażane są normalnymi zdaniami - trochę "sztywnymi" - ale zrozumiałymi dla "nieprogramisty".

Tak zapisane reguły (mające zwykle postać zdań warunkowych) są przetwarzane przez specjalny serwer reguł. Z punktu widzenia aplikacji - w momencie gdy trzeba podjąć decyzję "biznesową", to wywoływany jest zewnętrzny komponent, który "mówi" co dokładnie trzeba zrobić. A równocześnie komponent ten może być edytowany zupełnie niezależnie od pozostałych elementów aplikacji (tak długo aż zgadzają się parametry wejściowe i postać wyniku). iLOG opracował kontrolki do SharePoint, które pozwalają zwykłym użytkownikom "modyfikować" logikę aplikacji.

Taki sposób programowania ma olbrzymią zaletę - o ile BizTalk pozwala "narysować" proces integracyjny, o tyle iLOG podobny model przenosi znacznie niżej - do samej "logiki" aplikacji. Na razie firma zrealizowała to rozwiązanie dla Visual Studio .Net 2003, ale już trwają prace nad migracją do Visual Studio .Net 2005 (iLOG będzie prawdopodobnie jednym z języków DSL).

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200