Чтобы полностью отключить проверку соответствия BP 1.1 для Web-сервиса XML, определите в соответствующем файле Web.соnfig элемент
‹conformanceWarnings›.
‹configuration›
‹webServices›
‹conformanceWarnings›
‹remove name="BasicProfile1_1" /›
‹/conformanceWarnings›
‹/webServices›
‹/system.web›
‹/configuration›
Замечание. Атрибут [WebServiceBinding] можно также использовать для определения предполагаемых связей конкретных методов по значению свойства Name. Соответствующие подробности можно найти в документации .NET Framework 2.0 SDK.
Атрибут [WebMethod] должен указываться для каждого метода, который вы хотите сделать доступным в рамках данного Web-сервиса XML. Как и большинство других атрибутов, тип WebMethodAttiibute может иметь целый ряд необязательных именованных свойств. Давайте рассмотрим каждую из имеющихся здесь возможностей по очереди.
Описание Web-метода с помощью свойства Description
Как и в случае атрибута [WebService], свойство Description атрибута [WebMethod] позволяет описать функциональные возможности Web-мeтoдa.
public class Service: System.Web.Services.WebService {
[WebMethod(Description = "Вычитание целых чисел.")]
public int Subtract (int x, int y) { return x – y; }
[WebMethod(Description = "Сложение целых чисел.")]
public int Add(int x, int y) { return x + y; }
}
При указании свойства Description в пределах атрибута [WebMethod] в WSDL-документ в контексте имени метода добавляется новый элемент ‹documentation›.
‹wsdl:operation name="Add"›
‹wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"› Выполняет сложение целых чисел.
‹/wsdl:documentation›
‹wsdl:input message="tns:AddSoapIn" /›
‹wsdl:output message="tns:AddSoapOut" /›
‹/wsdl:operation›
Устранение конфликтов имен WSDL с помощью свойства MessageName
Одним из WSI-правил ВР 1.1 является то, что каждый метод в WSDL-документе должен быть уникальным. Таким образом, если вы хотите, чтобы ваш Web-сервис XML удовлетворял спецификациям ВР 1.1, вы не можете использовать перегруженные методы. Однако для примера предположим, что вы все-таки использовали перегрузку метода Add(), чтобы вызывающая сторона могла передать как два целых числа, так и два числа с плавающей точкой. В результате вы должны увидеть следующее сообщение среды выполнения.
Both Single Add(Single, Single) and Int32 Add(Int32, Int32) use the message name 'Add'. Use the MessageName property attribute to specify unique of the WebMethod custom message names for the methods.
(Сообщение гласит: Single Add(Single, Single) и Int32 Add(Int32, Int32) используют одно и то же имя 'Add' для своих сообщений; используйте свойство MessageName атрибута WebMethod, чтобы указать для этих методов уникальные пользовательские имена сообщений.)
Здесь лучшим решением является отказ от перегрузки метода Add(). Если же перегрузка необходима, для устранения конфликтов имен в документах WSDL можно использовать свойство MessageName атрибута [WebMethod].
public class Service: System.Web.Services.WebService {
[WebMethod(Description = "Сложение чисел с плавающей точкой.",
MessageName = "AddFloats")]
public float Add (float x, float y) { return x + y; }
[WebMethod(Description = "Сложение целых чисел.",
MessageName = "AddInts")]
public int Add(int x, int y) { return x + y; }
}
Поcле этого генерируемый WSDL-документ будет внутренне ссылаться на каждую из перегруженных версий метода Add() по уникальным именам (AddFloats и AddInts). Но с точки зрения агента на стороне клиента будет существовать только один перегруженный метод Add().
Поддержка данных состояния Web-сервисов с помощью свойства EnableSession
Вы, наверное, помните из главы 24 о том, что свойства Application и Session позволяют Web-приложению ASP.NET поддерживать данные состояния. Web-сервисы XML обеспечивают те же возможности с помощью базового класса System.Web.Services.WebService. Например, предположим, что ваш Web-сервис калькулятора поддерживает переменную уровня приложения (которая, таким образом, должна быть доступной любому сеансу), содержащую значение PI, как показано ниже.
public class CalcWebServicе: System.Web.Services.WebService {
// Этот Web-метод обеспечивает доступ к переменной SimplePI
// уровня приложения.
[WebMethod(Description = "Получение значения РI.")]
public float GetSimplePI() { return (float)Application["SimplePI"]; }
…
}
Начальное значение переменной SimplePI уровня приложения можно установить в обработчике Application_Start(), определенном в файле Global.asax. Добавьте в свой проект глобальный класс приложения (щелкнув правой кнопкой мыши на пиктограмме проекта в окне обозревателя решений и выбрав Add New Item из появившегося меню), а затем измените Application_Start() так, как предлагается ниже.
‹%@ 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-кода будет, как правило, достаточно.
