ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

Троелсен Эндрю

‹%@ Application Language="C#" %›

‹script runat="server"›

void Application_Start(Object sender, EventArgs e) {

 Application["SimplePI"] =3.14F;

}

…

‹/script›

Вдобавок к поддержке переменных уровня приложения можно использовать свойство Session для поддержки сеансовой информации. Для примера реализуйте метод Session_Start в файле Global.asax так, чтобы каждый зарегистрированный

пользователь идентифицировался случайным значением.

‹%@ Application Language="C#" %›

‹script runat= "server"›

…

void Session_Start(Object sender, EventArgs e) {

 // Чтобы сделать доступными сеансовые данные Web-сервиса,

 // присвойте каждому пользователю случайное число.

 Random r = new Random ;

 Session["SessionRandomNumber"] = r.Next(1000);

}

…

‹/script›

С целью проверки в рамках класса Service создайте новый Web-метод, возвращающий присвоенное пользователю случайное значение.

public class Service: System.Web.Services.WebService {

 …

 [WebMethod(EnableSession = true,

Description = "Получите ваше случайное значение!")]

 public int GetMyRandomNumber { return (int)Session["SessionRandomNumber"]; }

}

Заметим, что здесь атрибут [WebMethod] явно устанавливает для свойства EnableSession значение true (истина). Этот шаг необходим, поскольку по умолчанию для любого Web-метода контроль его данных сеансового состояния отключен. Если вы теперь запустите два или три экземпляра браузера (чтобы сгенерировать множество идентификаторов сеанса), вы обнаружите, что каждый зарегистрировавшийся пользователь возвращает уникальное числовое значение. Например, первый пользователь может получить следующий XML-код:

‹?xml version="1.0" encoding="utf-8"?›

‹int xmlns="http://www.IntertechTraining.com/WebServers"›931‹/int›

в то время как второй может получить значение 472.

‹?xml verslon="l.0" encoding="utf-8"?›

‹int xmlns="http://www.IntertechTraining.com/WebServers"›472‹/int›

Настройка данных сеансового состояния с помощью Web.config

Наконец, напомним, что файл Web.config можно изменить с тем, чтобы в нем указывалось место, где должны запоминаться данные состояния для Web-сервиса XML. Для этого используют элемент ‹sessionState› (описанный в предыдущей главе).

‹sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20" /›

Исходный код. Файлы примера CalculatorService размещены в подкаталоге,

соответствующем главе 25.

Язык описания Web-сервисов (WSDL)

В последних нескольких примерах вы могли видеть отдельные фрагменты WSDL-кода. Напомним, что WSDL – это основанная на XML грамматика, предназначенная для описания возможностей взаимодействия внешних клиентов с Web-методами, доступными по данному адресу URL в рамках каждого из поддерживаемых протоколов связи. Во многих отношениях WSDL-документ может рассматриваться, как "контракт" между клиентом Web-сервиса и самим Web-сервисом. Это еще один метаязык. В частности, WSDL используется для описания следующих характеристик любого доступного Web-метода:

• имя Web-метода XML;

• число, тип и порядок следования параметров (если таковые имеются);

• тип возвращаемого значения (если таковое предусмотрено);

• условия вызова HTTP GET, HTTP POST и SOAP.

В большинстве случаев WSDL-документы генерируются автоматически соответствующим Web-сервером. Напомним, что при добавлении суффикса?wsdl к адресу URL, указывающему на файл *.asmx, Web-сервер генерирует WSDL-документ для указанного Web-сервиса XML.

http://locаlhost/SomeWS/theWS.asmx?wsdl

Но если IIS автоматически генерирует WSDL-документ для данного Web-сервиса XML, зачем тогда нужно глубокое понимание синтаксиса генерируемых WSDL-данных? Ответ обычно зависит от того, как ваш сервис будет использоваться внешними приложениями. В случае Web-сервисов XML, предназначенных для "внутреннего" использования, сгенерированного Web-сервером WSDL-кода будет, как правило, достаточно.

Между тем. вполне возможно начать разработку Web-сервиса XML с создания WSDL-документа вручную (об этом уже говорилось выше). Главная идея начала разработки с создания WSDL-документа связана с вопросами совместимости. Вспомните о том, что до появления спецификации WSI различные инструменты построения Web-сервисов нередко генерировали несовместимые WSDL-описания. Если начинать разработку с WSDL-кода, вы можете построить документ так, как требуется.

Как вы можете догадаться, для начала разработки Web-сервиса XML с создания WSDL-документа требуется очень хорошее знание грамматики WSDL, обсуждение которой в контексте этой главы не предусмотрено. Но мы рассмотрим базовую структуру WSDL-документа. Разобравшись в основах, вы сможете оценить пользу утилиты командной строки wsdl.exe.

Замечание. Самую свежую информацию о языке WSDL можно найти на страницах http://www.w3.org/tr/wsdl.

Определение WSDL-документа

Действительный документ WSDL открывается и закрывается корневым элементом ‹definitions›. В открывающем дескрипторе обычно определяются различные атрибуты xmlns. Они задают пространства имен XML, определяющие различные подчиненные элементы. Как минимум, элемент ‹definitions› должен указать пространство имен, где определены сами элементы WSDL . Для того чтобы быть полезным, открывающий дескриптор ‹definitions› должен, кроме того, указать пространства имен XML, определяющие простые типы данных WSDL, типы XML-схемы, элементы SOAP, а также целевое пространство имен. Например, вот как выглядит раздел ‹definitions› для нашего Web-сервиса калькулятора.