
- •Протокол soap
- •Створення служби «Hello, World» в середовищі Visual Studio .Net
- •Тестування служби
- •Атрибут WebService
- •Властивість EnableSession
- •InProc - (за замовчуванням) стан сесії існує в рамках процесу мережі користувача
- •Налаштування sql Server для asp.Net sql Server стану сесії
- •Змінити Web.Config файл у вашої програми
- •Властивість CacheDuration
- •Властивість TransactionOption
- •Приклад роботи транзакцій: додавання користувачів – всі або ніхто.
- •Властивість BufferedResponse
- •Кешування
- •Просте кешування результатів
- •Кешування даних в Web - сервісах
- •Встановлення елементів в кеш
- •Установка Web сервера iis
- •Задача 1.2. Створення рівню dal.
- •Задача 1.3. Створення рівню bll.
- •Колекція користувачів.
- •Створюємо тестер.
- •Задача 2. Створення рівня сервіса.
- •Задача 3.Створення тестеру-клієнта .
Властивість EnableSession
Оскільки web-служби ASP .NET (класи, одержані з простору імен System.Web.Services.WebService) існують в контексті додатку ASP.NET, вони мають доступ до об'єктів Application і Session цього додатку. Додаток ASP .NET включає тільки один об'єкт Application, отже, воно здатне підтримувати безліч об'єктів сеансу, призначених для зберігання даних різних клієнтів. За умовчанням такий механізм управління станом відключений; активізувати його можна шляхом привласнення властивості EnableSession значення true. Використовування даного механізму може понизити продуктивність, тому включати його слід лише при необхідності.
Якщо механізм управління сеансами запущений, сервер управляє станом клієнтів за допомогою унікальних об'єктів HttpSessionState. При першій взаємодії користувача з сервером кожному об'єкту Session призначається унікальний ідентифікатор. У разі подальших взаємодій клієнт повинен надати серверу свій унікальний ідентифікатор для витягання всіх клієнтських даних, збережених в попередньому сеансі. Унікальний ідентифікатор може зберігатися в cookie-файлі на комп'ютері клієнта або поміщатися в URL-адресу. У типовому доступному через браузер додатку ASP .NET така система управління станом працює «за кулісами». А якщо в web-браузер включена підтримка cookie-файлів, вони автоматично надаватимуться серверу по відповідному запиту. Оскільки web-служби не можуть одержувати cookie-файли аналогічним чином, то при кожному виклику web-служби вам доведеться указувати cookie-файл програмно.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="AdministrationServiceSoap" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
allowCookies="true" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
…
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost/AdministrationWebService/AdministrationService.asmx"
binding="basicHttpBinding" bindingConfiguration="AdministrationServiceSoap"
contract="AdministrationServiceProxy.AdministrationServiceSoap"
name="AdministrationServiceSoap" />
</client>
</system.serviceModel>
</configuration>
Session timeout
<system.web>
<sessionState mode="InProc" cookieless="false" timeout="1"></sessionState>
…
</system.webServer>
За замовчуванням, сесія буде створена у рамках того ж процесу, що веб-сайт працює в (InProc). Це контролюється за допомогою параметра у файлі web.config:
<sessionState mode="InProc" />
Хоча працювати сесією в процесі досить зручно, це означає, що всі значення сесій будуть втрачені, коли застосування очиститися (наприклад, при розгортанні оновлень). Є альтернативні режими використання, що дозволяє стану сеансу вижити, навіть якщо додаток переробляється. Доступні варіанти: