Integracja Windows Azure AppFabric Caching z sesjami ASP.NET 

Autor: Piotr Zieliński

Opublikowano: 2011-04-18

Wprowadzenie

W skład AppFabric wchodzi mechanizm buforowania, który umożliwia również przechowywanie sesji aplikacji webowej. Domyślnie wszystkie sesje ASP.NET przechowywane są wraz z procesem, co uniemożliwia jej dystrybucję pomiędzy różne komputery. W klasycznym ASP.NET sesja może być przechowywana w InProc, StateServer lub SQLServer.

Dzięki AppFabric Caching programiści otrzymują obecnie czwartą możliwość – stanowiącą rozproszoną i skalowalną pamięć, która z pewnością nadaje się dla skomplikowanych aplikacji webowych.

Implementacja

Stwórzmy prostą aplikację webową wykorzystującą mechanizm sesji. Aby nie komplikować scenariusza, ograniczmy się po prostu do zapisywania jakieś wartości w sesji podczas ładowania strony, a następnie jej wyświetlania:

1. Tworzymy nowy, pusty projekt Azure (Windows Azure Project).

2. Dodajemy pojedynczą rolę ASP.NET (lub ASP.NET MVC – bez różnicy).

   

3. Aby wykorzystać mechanizm buforowania oraz adaptacji go do sesji ASP.NET, dodajemy referencje do bibliotek Microsoft.ApplicationServer.Caching.Client, Microsoft.ApplicationServer.Caching.Core oraz Microsoft.Web.DistributedCache (Solution Browser -> AddReference). Biblioteki znajdują się w %ProgramFiles%\Windows Azure AppFabric SDK\V2.0\Assemblies\Cache.

4. Gdybyśmy w tej chwili wdrożyli projekt na serwer, okazałoby się, że dodane wcześniej biblioteki nie zostaną tak naprawdę wdrożone. Musimy ustawić parametr Copy Local na True. W tym celu klikamy na nich i z menu kontekstowego wybieramy Properties, a następnie ustawiamy stosownie Copy Local (są to biblioteki niestandardowe i domyślnie nie są zainstalowane na serwerze).

   

5. Musimy skonfigurować odpowiednio aplikację poprzez modyfikację pliku web.config. Aby sobie  jednak ułatwić zadanie, otwieramy przeglądarkę i  logujemy się do panelu administracyjnego AppFabric (w dniu pisania artykułu był to https://portal.appfabriclabs.com/), a następnie przechodzimy do Service Namespace -> Cache.  Odnajdujemy sekcję Application Integration, w której znajdziemy wszystkie modyfikacje, jakie musimy wykonać w pliku konfiguracyjnym. Pierwszą z nich jest dodanie konfiguracji sekcji web.config:

   

Wstawiamy więc powyższy kod w odpowiednie miejsce:

<configSections>
   <section name="dataCacheClient" type="Microsoft.ApplicationServer.Caching.DataCacheClientSection, Microsoft.ApplicationServer.Caching.Core"
       allowLocation="true" allowDefinition="Everywhere"/>
</configSections>

6. Następnie kopiujemy kod odpowiedzialny za konfigurację dostawcy sesji:

Kod umieszczamy pod konfiguracją sekcji:

</configSections>
... 
<dataCacheClient deployment="Simple">
  <hosts>
    <host name="msdnpoland.cache.appfabriclabs.com" cachePort="22233" />
  </hosts>
  <securityProperties mode="Message">
    <messageSecurity 
     authorizationInfo=" ">
    </messageSecurity>
  </securityProperties>
</dataCacheClient>

Należy oczywiście pamiętać, aby przekopiować kod z panelu, a nie z artykułu, ponieważ zawiera on dane specyficzne dla konkretnego konta Azure.

7.     Ostatnią kwestią jest ustawienie wcześniej skonfigurowanego dostawcy sesji (output cache pomijamy):

Kod:

<system.web>
    ...
<sessionState mode="Custom" customProvider="AppFabricCacheSessionStoreProvider">
<providers>
<add name="AppFabricCacheSessionStoreProvider"             type="Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider, Microsoft.Web.DistributedCache"
             cacheName="default"
             useBlobMode="false" />
</providers>
</sessionState>

8.     Na koniec piszemy kod odpowiedzialny za dodanie wartości do sesji (do celi testowych):

   if (Session["text"] == null)
   Session.Add("text",Guid.NewGuid().ToString());
   Response.Write(Session["text"]);

Sesję możemy przetestować, odświeżając kilkukrotnie stronę. Jeśli sesja działa, identyfikator nie powinien generować się ponownie i wartość wyświetlana na ekranie będzie taka sama w ramach sesji.

Zakończenie

Po wdrożeniu i uruchomieniu aplikacji przekonamy się, że mechanizm sesji faktycznie działa. Ponadto mimo mechanizmu balansowania obciążenia (Load Balancer) użytkownik nie straci swojej sesji. W przypadku gdy Load Balancer kierował zapytania do różnych instancji  lub komputerów, wtedy sesja przechowywana w procesie naturalnie nie była współdzielona i tym samym użytkownik musiał np. logować się ponownie (gdy sesja wykorzystywana była do logowania). W przypadku rozproszonej sesji przechowywanej w AppFabric Cache problem znika!