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

Очевидно, для Web-сервиса XML это оказывается проблемой, поскольку одной из задач разработки является упрощение способа обработки информации в межплатформенном мультиархитектурном и многоязычном окружении. Чтобы решить проблему, для повышения уровня межплатформенной совместимости Web-сервисов организация WSI предлагает использовать открытые спецификации. В .NET 2.0 свойству ConformsTo атрибута [WebServiceBinding] можно назначить любое значение из перечня WsiProfiles.

public enum WsiProfiles {

// Web-сервис не делает никаких заявлений о совместимости.

None,

// Web-сервис объявляет о совместимости

// с базовым профилем WSI версии 1.1.

BasicProfile1_1

}

По умолчанию Web-сервисы XML, генерируемые с помощью Visual Studio 2005, предполагают согласованность с базовым профилем WSI 1.1. Конечно, простое приравнивание свойства ConformsTo к WsiProfiles.BasicProfile1_1 не гарантирует, что каждый Web-метод будет действительно совместим с этим профилем. Например, одно из правил ВР 1.1 гласит, что каждый метод WSDL-документа должен иметь свое уникальное имя (т.е. ВР 1.1 не допускает перегрузку Web-методов). Но хорошей вестью здесь является то, что среда выполнения ASP.NET позволяет определить различные уровни соответствия ВР 1.1 и сообщит об этом во время выполнения.

В .NET 2.0 Web-сервисы XML автоматически проверяются на соответствие спецификациям базового профиля WSI версии 1.1 (ВР 1.1). В большинстве случаев это хорошо, поскольку позволяет создавать программное обеспечение с самыми широкими возможностями совместимости. Однако в некоторых случаях бывает нужно пренебречь совместимостью с ВР 1.1 (например, при создании внутренних Web-сервисов XML, когда совместимость не столь важна). Чтобы дать указание среде выполнения игнорировать нарушение правил ВР 1.1, установите свойство ConformsTo равным WsiProfiles.None, а свойство EmitConformanceClaims – равным false (ложь).

[WebService(Description = "Чудесный Web-сервис калькулятора",

Namespace = "http://www.IntertechTraining.com/",

Name = "CalculatorWebService")]

[WebServiceBinding( ConformsTo =WsiProfiles.None,

EmitConformanceClaims = false")]

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

Как и следует ожидать, от значения, присвоенного свойству EmitConformanceClaims, зависит, будут ли при публикации WSDL-описания Web-сервиса учиты-ваться сообщения соответствия свойства ConformsTo. В данном случае нарушение правил ВР 1.1 разрешается, но автоматически генерируется страница тестирования все равно будет отображать предупреждения.

Чтобы полностью отключить проверку соответствия 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 может иметь целый ряд необязательных именованных свойств. Давайте рассмотрим каждую из имеющихся здесь возможностей по очереди.

Как и в случае атрибута [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›

Одним из 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().

Вы, наверное, помните из главы 24 о том, что свойства Application и Session позволяют Web-приложению ASP.NET поддерживать данные состояния. Web-сервисы XML обеспечивают те же возможности с помощью базового класса System.Web.Services.WebService. Например, предположим, что ваш Web-сервис калькулятора поддерживает переменную уровня приложения (которая, таким образом, должна быть доступной любому сеансу), содержащую значение PI, как показано ниже.

public class CalcWebServicе: System.Web.Services.WebService {

// Этот Web-метод обеспечивает доступ к переменной SimplePI

// уровня приложения.