Как создать веб сервис в visual studio. Создание проекта сервиса

Optionally, add text to the page for captions.

For this walkthrough, the layout of the page is not important.

Double-click ConvertButton to create an event handler for its Click event.

Make sure your event handler code matches the code in the following example.

Dim wsConvert As New localhost.Convert() Dim temperature As Double temperature = System.Convert.ToDouble(TemperatureTextbox.Text) FahrenheitLabel.Text = "Fahrenheit To Celsius = " & _ wsConvert.FahrenheitToCelsius(temperature).ToString() CelsiusLabel.Text = "Celsius To Fahrenheit = " & _ wsConvert.CelsiusToFahrenheit(temperature).ToString() protected void ConvertButton_Click(object sender, EventArgs e) { localhost.Convert wsConvert = new localhost.Convert(); double temperature = System.Convert.ToDouble(TemperatureTextbox.Text); FahrenheitLabel.Text = "Fahrenheit To Celsius = " + wsConvert.FahrenheitToCelsius(temperature).ToString(); CelsiusLabel.Text = "Celsius To Fahrenheit = " + wsConvert.CelsiusToFahrenheit(temperature).ToString(); }

Press CTRL+F5 to run the page.

In the text box, type a value, such as 100, and then click Convert .

The page displays the result of converting the temperature value into both Fahrenheit and Celsius.

You can debug a Web service in the same way that you debug Web pages.

Visual Web Developer Express and Visual Studio Standard do not support stepping into a Web service from a page that references it. If you are using Visual Web Developer Express or Visual Studio Standard, skip this section and the ones following. For more information about how to debug Web sites, see Walkthrough: Debugging Web Pages in Visual Web Developer .

To start, you must configure the Web site that contains the Web service to enable debugging.

On the File menu, click Open Web Site .

Click Local IIS .

Click TemperatureWebService, and then click Open .

On the Website menu, click ASP.NET Configuration

Click Application , and then click Application Configuration .

Under Debugging and Tracing , click .

Select the Enable debugging check box .

The Web Site Administration Tool creates a Web.config file for the Web site and sets a configuration option to enable debugging.

To see the Web.config file in Solution Explorer, click the Web site name and then, on the Solution Explorer toolbar, click Refresh .

You must now enable debugging for the Web site that uses the Web service.

Open the TemperatureWeb site.

On the Website menu, click ASP.NET Configuration to open the Web Site Administration Tool.

Click Application , click Application Configuration , under Debugging and Tracing , click Configure debugging and tracing , and then select the Enable debugging check box .

Close the Web Site Administration Tool.

To see the Web.config file in Solution Explorer, select the Web site name and then, on the Solution Explorer toolbar, click Refresh .

In Solution Explorer, right-click Default.aspx, and then click View Code .

Visual Web Developer opens the code file for the page.

Position the pointer in the following line:

Temperature = System.Convert.ToDouble(TemperatureTextbox.Text) double temperature = System.Convert.ToDouble(TemperatureTextbox.Text);

Press F9 to set a breakpoint on the line.

Both the Web site and the Web service are configured for debugging, so that you can now try debugging. You will start in the Default.aspx page and step through the code until the code invokes the Web service. The debugger will switch to the Web service and continue stepping through the code.

Press F5 to run the Default.aspx page with debugging.

The page appears in the browser.

In the box, type a value, such as 100, and then click Convert .

Visual Web Developer starts running the code for the page, but stops and highlights the line with the breakpoint on it.

Press F11 to step to the next line.

Press F11 again.

Because the next line invokes the Web service, the debugger steps into the Web service, stopping on the first line of the FahrenheitToCelsius method.

Continue pressing F11.

The debugger steps through the rest of the method, and then returns to the calling page. If you continue stepping, the debugger will step back into the Web service and into the CelsiusToFahrenheit method.

Close the browser, which also closes the debugger.

This walkthrough has illustrated the basic principles of creating a very simple Web service and using it in an ASP.NET application. You might want to experiment with additional, more complex Web service features. For more information, see.

Данная статья открывает курс уроков по технологии WCF и рассчитана в первую очередь на новичков в программировании веб-сервисов.

В данном уроке мы создадим простой WCF-сервис «калькулятор», реализующий четыре базовые арифметические операции, научимся размещать сервис на IIS и публиковать на сервере. Кроме того, расскажем о том, как подключиться к сервису из другого приложения на C# или с помощью бесплатной программы SoapUI , а также добавим функционал для вызова сервиса через веб (например, из браузера или Ajax).

Урок рассчитан на начинающих программистов C#, решивших освоить технологию WCF. Опытным разработчикам может быть полезна информация из раздела , посвященного созданию конечных точек для Ajax.

В работе используется Visual Studio 2013 Professional, версия фреймворка 4.5.1. Для заметки: за некоторыми небольшими исключениями, разницы между версиями 4.0. и 4.5.1 нет, но использование последней предпочтительней, т.к. добавляет полезную функцию генерации WSDL одним файлом, но об этом ниже.

Итак, запускаем студию и создаем проект типа WCF Service Application в соответствующем разделе, называем его SampleService .

После создания проекта рассмотрим структуру решения в обозревателе решений:

1. IService1.cs содержит описание интерфейса сервиса, т.е. набор методов, которые наш сервис предоставляет.
2. Service1.svc состоит из двух частей — реализация сервиса (Service1.svc.cs) и разметка (Markup), доступная в меню по клику правой кнопкой мыши.
3. Web.config — конфигурация сервиса.
4. Папка App_Data нам пока не нужна — удаляем.

Для начала переименуем сервис и его интерфейс, придав им имена Calculator и ICalculator соответственно, а также изменим строчку в разметке сервиса (файл Calculator.svc):

Теперь опишем сам интерфейс нашего калькулятора. Объявим стандартные арифметические операции, такие как сложение (Addition), вычитание (Subtraction), умножение (Multiplication) и деление (Division). Также добавим дополнительный метод TestConnection, возвращающий строку. С помощью этого метода клиенты смогут проверить, что сервис функционирует, т.к. стандартного «пинга» WCF не предоставляет. Все методы интерфейса должны быть помечены атрибутом , иначе они не будут видны клиентам.

В итоге, интерфейс примет следующий вид:

ICalculator.cs

using System; using System.Collections.Generic; using System.Linq; using System.Runtime.Serialization; using System.ServiceModel; using System.ServiceModel.Web; using System.Text; namespace SampleService { public interface ICalculator { #region Common Methods /// /// OK string TestConnection(); #endregion #region Arithmetic /// /// сложение /// /// Слагаемое 1 /// Слагаемое 2 /// сумма double Addition(double a, double b); /// /// вычитание /// /// Уменьшаемое /// Вычитаемое /// разность double Subtraction(double a, double b); /// /// умножение /// /// Множитель 1 /// Множитель 2 /// произведение double Multiplication(double a, double b); /// /// деление /// /// Делимое /// Делитель /// частное double Division(double a, double b); #endregion } }

Теперь реализуем интерфейс в классе сервиса:

Calculator.svc.cs

using System; using System.Collections.Generic; using System.Linq; using System.Runtime.Serialization; using System.ServiceModel; using System.ServiceModel.Web; using System.Text; namespace SampleService { public class Calculator: ICalculator { #region Common Methods /// /// проверка соединения /// /// OK public string TestConnection() { return "OK"; } #endregion #region Arithmetic /// /// сложение /// /// Слагаемое 1 /// Слагаемое 2 /// сумма public double Addition(double a, double b) { return a + b; } /// /// вычитание /// /// Уменьшаемое /// Вычитаемое /// разность public double Subtraction(double a, double b) { return a - b; } /// /// умножение /// /// Множитель 1 /// Множитель 2 /// произведение public double Multiplication(double a, double b) { return a * b; } /// /// деление /// /// Делимое /// Делитель /// частное public double Division(double a, double b) { return a / b; } #endregion } }

Логика сервиса описана, теперь необходимо его разместить на хостинге.

Сам по себе сервис представляет библиотеку (в нашем случае файл SampleService.dll), и для ее запуска в виде сервиса необходимо воспользоваться одним из предоставляемых WCF методов:

• 1. Хостинг на IIS.
• 2. Запуск в виде службы Windows.
• 3. Self hosting (сервис выполнен в виде консольного приложения, запускающего сервис).

Принципиального различия в этих методах нет, поэтому выберем простейший вариант — размещение на IIS. Для этого откроем конфигурацию проекта и выберем вкладку «Web». Параметры по умолчанию вы можете наблюдать у себя, а вот так выглядят настройки для нашего сервиса:

Раздел Start Action определяет, что произойдет при запуске проекта в студии:

• Current Page (по умолчанию) – запуск последней открытой страницы в браузере. У нашего сервиса пока нет настроенных url-адресов методов, поэтому этот вариант не подходит.
• Specific Page – запуск конкретной страницы.
• Start External program – запуск указанного исполняемого файла, который инициирует сервис, например, вызовет метод, нуждающийся в отладке.
• Start URL – открытие указанного в поле URL адреса в браузере.
• Don"t open a page – ничего не открывать, но ждать запроса от стороннего приложения.

Во всех случаях сервис «запускается» в режиме отладки и ведет себя как обычное приложение в студии, т.е. реагирует на контрольные точки. Последний вариант удобен тем, что ничего не открывается в браузере, т.к. отладка с помощью браузера — не лучший вариант для WCF сервиса, но об этом ниже.

Раздел Servers определяет, где будет размещен сервис. По умолчанию выбран IIS Express (строенный в студию вариант IIS), но мы будем продвинутыми и разместим сервис на нормальном IIS. Разумеется, для этого необходимо установить IIS в панели управления и включить необходимые компоненты (ASP .NET, Basic-авторизация и другие).

Под спойлером указан один из вариантов набора компонентов для работы сервисов.

Компоненты IIS

После указания адреса в настройках необходимо нажать кнопку «Create Virtual Directory». Затем можно скомпилировать проект и запустить диспетчер служб IIS . Наше приложение уже должно появиться в списке приложений сайта по умолчанию (Default Web Site), а также ему должен быть назначен пул (DefaultAppPool). Рекомендуется создать отдельный пул для ваших сервисов, указав в качестве платформы.NET 4.0:

После создания пула, назначьте его вашему приложению (Default Web Site > Lesson1 > Дополнительные параметры > Пул приложений).

Последний штрих — проверка вашего приложения. Для этого откройте в браузере строку, указанную в конфигурации проекта, добавив в конце имя сервиса, в нашем случае это Calculator.svc: http://localhost/Lesson1/Calculator.svc . Итог должен быть примерно следующим:

Внимание! Если в качестве платформы вы выбрали.NET 4.0 и при этом на машине, где размещается сервис установлен.NET 4.0, ссылки на WSDL одним файлом (http://localhost/Lesson1/Calculator.svc?singleWsdl) не будет. Поэтому рекомендуется установить на сервер фреймворк версии не ниже 4.5, даже если сам сервис скомпилирован на.NET 4.0. Это достаточно забавная особенность, но за эту ссылку отвечает именно фреймворк на сервере, а не тот, для которого компилировался сервис. Это, пожалуй, единственное существенное отличие.NET 4.0 от.NET 4.5 с точки зрения интерфейса сервиса.

Под публикацией сервиса подразумевается его компиляция для дальнейшего выкладывания сборки на сервер. Рассмотрим на конкретном примере, выложив сервер на демонстрационный сервер компании.

Для начала, необходимо создать профиль публикации, для этого кликнем правой кнопкой мыши на имени проекта и выберем пункт Publish...:

Мастер предложит нам несколько вариантов публикации, выберем Custom, профиль назовем Demo.
Затем выберем метод публикации File System и укажем путь, куда будет сохраняться наша сборка:

Проект готов к публикации, но желательно еще перейти к следующей вкладке (Settings) и отметить галочку «Delete all existing files prior to publish» (удалять все файлы перед публикацией) и выбрать конфигурацию.

Выполняем публикацию и смотрим, что получилось в итоге:

Чтобы разместить сервис на вашем сайте, скопируйте папку на сервер и подключите к IIS как приложение, как если бы это был обычный сайт (Default Web Site > Add Application...)

Готово! Сервис размещен по адресу http://dszss.proitr.ru/WCFLesson1/Calculator.svc .

В данном разделе мы рассмотрим три способа использования нашего сервиса: вызов через приложение на C#, обращение через SoapUI и запрос посредством URL (WebInvoke).

Для начала рассмотрим обращение к нашему сервису через клиент на C#. Так как WCF интегрирован в Visual Studio, создать клиент не составит труда. Все, что нам надо знать — это адрес WSDL сервиса, в которому мы хотим подключиться.

Создадим в нашем решении еще один проект типа Console Application и назовем его TestClient. Назначим его исполняемым и добавим ссылку на сервис:

В открывшемся окне введем адрес локальный сервиса, по желанию укажем имя пространства имен и дополнительные настройки. Здесь же можно посмотреть, какие методы предоставляет наш сервис:

После создания ссылки на сервис, в проекте появится папка «Service References», в которой будет находиться сгенерированный сутидей клиент. Его код при желании вы можете посмотреть самостоятельно, надо только включить отображение скрытых файлов или перейти по F12 внутрь кода клиента.

Теперь напишем код для подключения к сервису и вызов арифметических операций, предоставляемых им:

Тестовый клиент

Program.cs

using System; using System.Collections.Generic; using System.Globalization; using System.Linq; using System.Text; using System.Threading.Tasks; // ссылка на пространство имен сервиса using TestClient.RemoteService; namespace TestClient { class Program { static void Main(string args) { // помощник вывода в консоль ConsoleWriter writer = new ConsoleWriter(); // создадим клиент сервиса CalculatorClient client = new CalculatorClient("BasicHttpBinding_ICalculator"); try { // проверка соединения writer.Write("Проверка соединения с сервисом... "); if (!string.Equals(client.TestConnection(), "OK", StringComparison.InvariantCultureIgnoreCase)) { throw new Exception("Проверка соединения не удалась"); } writer.WriteLineSuccess(); writer.WriteLine(); // лямбда-функция проверки метода var CheckArithmeticOperation = new Action ((operation, operationName, arg1, arg2, expectedResult) => { writer.Write("Проверка операции ""); writer.Write(ConsoleColor.White, operation.Method.Name); writer.Write("", {0} {1} {2} = ", arg1.ToString(CultureInfo.InvariantCulture), operationName, arg2.ToString(CultureInfo.InvariantCulture)); double result = operation(arg1, arg2); if (result == expectedResult) { // проверка пройдена writer.Write("{0} ", result.ToString(CultureInfo.InvariantCulture)); writer.WriteLineSuccess(); } else { // ошибка throw new Exception(string.Format("Ошибка проверки метода "{0}": {1} {2} {3} != {4}", operation.Method.Name, arg1.ToString(CultureInfo.InvariantCulture), operationName, arg2.ToString(CultureInfo.InvariantCulture), expectedResult.ToString(CultureInfo.InvariantCulture))); } }); // проверка метода Addition CheckArithmeticOperation(client.Addition, "+", 2.5, 5, 2.5 + 5); // проверка метода Subtraction CheckArithmeticOperation(client.Subtraction, "-", 2.5, 5, 2.5 - 5); // проверка метода Multiplication CheckArithmeticOperation(client.Multiplication, "*", 2.5, 5, 2.5 * 5); // проверка метода Division CheckArithmeticOperation(client.Division, "/", 2.5, 5, 2.5 / 5); // в конце работы закрываем клиент client.Close(); } catch (Exception ex) { // в случае ошибки необходимо принудительно закрыть клиент методом Abort() client.Abort(); // выводим информацию об ошибке writer.WriteLine(); writer.WriteLineError("Ошибка: {0}", ex.Message); } Console.WriteLine(); Console.WriteLine("Нажмите любую клавишу для продолжения..."); Console.ReadKey(); } } }

ConsoleWriter.cs

using System; namespace TestClient { /// /// консольный писатель /// public class ConsoleWriter { #region Declarations private ConsoleColor _successColor; // цвет сообщений для успешных операций private ConsoleColor _errorColor; // цвет сообщений об ошибках private ConsoleColor _warningColor; // цвет сообщений-предупреждений private string _successText; // текст сообщений для успешных операций private string _errorText; // текст сообщений об ошибках private string _warningText; // текст сообщений-предупреждений #endregion #region Properties /// /// цвет сообщений для успешных операций /// public ConsoleColor SuccessColor { get { return _successColor; } set { _successColor = value; } } /// /// цвет сообщений об ошибках /// public ConsoleColor ErrorColor { get { return _errorColor; } set { _errorColor = value; } } /// /// цвет сообщений-предупреждений /// public ConsoleColor WarningColor { get { return _warningColor; } set { _warningColor = value; } } /// /// текст сообщений для успешных операций /// public string SuccessText { get { return _successText; } set { _successText = value; } } /// /// текст сообщений об ошибках /// public string ErrorText { get { return _errorText; } set { _errorText = value; } } /// /// текст сообщений-предупреждений /// public string WarningText { get { return _warningText; } set { _warningText = value; } } /// /// цвет текста /// public ConsoleColor ForegroundColor { get { return Console.ForegroundColor; } set { Console.ForegroundColor = value; } } /// /// цвет фона /// public ConsoleColor BackgroundColor { get { return Console.BackgroundColor; } set { Console.BackgroundColor = value; } } #endregion #region Constructors /// /// конструктор /// public ConsoleWriter() { _successColor = ConsoleColor.Green; _errorColor = ConsoleColor.Red; _warningColor = ConsoleColor.Blue; _successText = "OK"; _errorText = "ERROR"; _warningText = "WARNING"; } #endregion #region Private methods #endregion #region Protected methods #endregion #region Public methods #region Write | WriteLine /// /// Сообщение public void Write(string value) { Console.Write(value); } /// /// записать сообщение в консоль /// /// Цвет сообщения /// Сообщение public void Write(ConsoleColor color, string value) { ConsoleColor oldColor = Console.ForegroundColor; Console.ForegroundColor = color; Console.Write(value); Console.ForegroundColor = oldColor; } /// /// записать сообщение в консоль /// /// Строка формата /// Аргументы public void Write(string format, params object args) { Console.Write(string.Format(format, args)); } /// /// записать сообщение в консоль /// /// Цвет сообщения /// Строка формата /// Аргументы public void Write(ConsoleColor color, string format, params object args) { ConsoleColor oldColor = Console.ForegroundColor; Console.ForegroundColor = color; Console.Write(string.Format(format, args)); Console.ForegroundColor = oldColor; } /// /// записать перевод строки в консоль /// public void WriteLine() { Console.WriteLine(); } /// /// записать сообщение в консоль /// /// Сообщение public void WriteLine(string value) { Console.WriteLine(value); } /// /// записать сообщение в консоль /// /// Цвет сообщения /// Сообщение public void WriteLine(ConsoleColor color, string value) { ConsoleColor oldColor = Console.ForegroundColor; Console.ForegroundColor = color; Console.WriteLine(value); Console.ForegroundColor = oldColor; } /// /// записать сообщение в консоль /// /// Строка формата /// Аргументы public void WriteLine(string format, params object args) { Console.WriteLine(string.Format(format, args)); } /// /// записать сообщение в консоль /// /// Цвет сообщения /// Строка формата /// Аргументы public void WriteLine(ConsoleColor color, string format, params object args) { ConsoleColor oldColor = Console.ForegroundColor; Console.ForegroundColor = color; Console.WriteLine(string.Format(format, args)); Console.ForegroundColor = oldColor; } #endregion #region WriteSuccess | WriteLineSuccess /// /// записать сообщение в консоль /// public void WriteSuccess() { Write(_successColor, _successText); } /// /// записать сообщение в консоль /// /// Сообщение public void WriteSuccess(string value) { Write(_successColor, value); } /// /// записать сообщение в консоль /// /// Строка формата /// Аргументы public void WriteSuccess(string format, params object args) { Write(_successColor, string.Format(format, args)); } /// /// записать сообщение в консоль /// public void WriteLineSuccess() { WriteLine(_successColor, _successText); } /// /// записать сообщение в консоль /// /// Сообщение public void WriteLineSuccess(string value) { WriteLine(_successColor, value); } /// /// записать сообщение в консоль /// /// Строка формата /// Аргументы public void WriteLineSuccess(string format, params object args) { WriteLine(_successColor, string.Format(format, args)); } #endregion #region WriteError | WriteLineError /// /// записать сообщение в консоль /// public void WriteError() { Write(_errorColor, _errorText); } /// /// записать сообщение в консоль /// /// Сообщение public void WriteError(string value) { Write(_errorColor, value); } /// /// записать сообщение в консоль /// /// Строка формата /// Аргументы public void WriteError(string format, params object args) { Write(_errorColor, string.Format(format, args)); } /// /// записать сообщение в консоль /// public void WriteLineError() { WriteLine(_errorColor, _errorText); } /// /// записать сообщение в консоль /// /// Сообщение public void WriteLineError(string value) { WriteLine(_errorColor, value); } /// /// записать сообщение в консоль /// /// Строка формата /// Аргументы public void WriteLineError(string format, params object args) { WriteLine(_errorColor, string.Format(format, args)); } #endregion #region WriteWarning | WriteLineWarning /// /// записать сообщение в консоль /// public void WriteWarning() { Write(_warningColor, _warningText); } /// /// записать сообщение в консоль /// /// Сообщение public void WriteWarning(string value) { Write(_warningColor, value); } /// /// записать сообщение в консоль /// /// Строка формата /// Аргументы public void WriteWarning(string format, params object args) { Write(_warningColor, string.Format(format, args)); } /// /// записать сообщение в консоль /// public void WriteLineWarning() { WriteLine(_warningColor, _warningText); } /// /// записать сообщение в консоль /// /// Сообщение public void WriteLineWarning(string value) { WriteLine(_warningColor, value); } /// /// записать сообщение в консоль /// /// Строка формата /// Аргументы public void WriteLineWarning(string format, params object args) { WriteLine(_warningColor, string.Format(format, args)); } #endregion #endregion } }

Результат исполнения:

В целом, вызов методов сервиса ничем не отличается от вызова методов обычного интерфейса C#, а т.к. клиент и сервис находятся в пределах одного решения, вы можете поставить контрольные точки в методах сервиса, которые сработают при их вызове. Также вы можете запустить отдельный проект сервиса в режиме ожидания запроса от стороннего приложения ().

Технически, при обращении к сервису клиент формирует Soap сообщение (обычная XML), которое предается по HTTP-каналу и может быть перехвачено сниффером. Разумеется, в арсенале WCF существуют и другие методы передачи, а также возможность шифрования и/или подписи сообщений, но это уже тема другого урока.

Переходим к другому способу вызова сервиса.

Эти ограничения не препятствуют использованию функции обратного вызова ASP.NET AJAX по ее прямому назначению - в качестве механизма выполнения страницей задач серверного приложения. Если ранее вам приходилось использовать веб-службы для представления серверной функциональности "толстым" клиентам, сторонним разработчикам и приложениям на платформах, отличных от.NET, вы увидите, что применение веб-служб в ASP.NET AJAX несколько проще.

Существует ряд способов обхода этих ограничений. Например, в своем веб-приложении можно вызвать веб-метод, который, в свою очередь, обращается к веб-методу, существующему в другом домене. Этот метод установления связи работает, поскольку код веб-сервера не имеет ограничения, присущего браузеру - он волен запускать междоменные вызовы других веб-служб.

Веб-службы, используемые с AJAX ASP.NET, состоят из двух частей: файла.asmx, который действует в качестве конечной точки веб-службы, и файла.cs, который содержит фактический код C#. Эти файлы необходимо добавить к веб-сайту, содержащему страницу AJAX ASP.NET, которая будет использовать веб-службу.

Самый быстрый способ создания веб-службы в среде Visual Studio - выбрать пункт меню Website --> Add New Item, указать шаблон Web Service, назначить имя файлу (в следующем примере - TerritoriesService) и щелкнуть на кнопке Add (Добавить). При создании веб-сайта без проекта файл.asmx будет помещен в каталог веб-приложения, а соответствующий файл.cs - в папку App_Code для автоматической компиляции.

Чтобы веб-службы можно было использовать с ASP.NET AJAX, веб-приложение не обязательно размещать в виртуальном каталоге IIS. Вместо этого для тестирования приложения можно применять встроенный веб-сервер Visual Studio. Это возможно потому, что код сценария, который автоматически вызывает веб-службу, использует относительный путь. В результате, независимо от порта, выбираемого веб-сервером Visual Studio, веб-страница сможет сформировать правильный URL-адрес.

Файл.asmx не представляет особого интереса - если его открыть, в нем обнаружится единственная строка с директивой WebService, которая определяет язык кода, расположение файла отделенного кода и имя класса:

В этом примере создается веб-служба TerritoriesService.asmx с файлом отделенного кода TerritoriesService.cs. В файле отделенного кода определен класс TerritoriesService, который выглядит следующим образом:

Public class TerritoriesService: System.Web.Services.WebService { // ... }

По умолчанию атрибут ScriptService закомментирован. Чтобы создать веб-службу, которую можно будет вызывать из страницы ASP.NET AJAX, не забудьте удалить символы комментария.

Этот класс является производным от System.Web.Services.WebService , который служит традиционным базовым классом для веб-служб. Однако этот подход выбран лишь для удобства и не является обязательным. Наследование от WebService предоставляет доступ к ряду встроенных объектов (таких как Application, Server, Session и User) без необходимости обращения к статическому свойству HttpContext.Current.

Обратите также внимание, что объявление класса веб-службы содержит три атрибута. Два первых - WebService (устанавливает пространство имен XML, используемое в сообщениях веб-службы) и WebServiceBinding (указывает уровень соответствия стандартам, поддерживаемый веб-службой) - применяются только при вызове веб-службы с помощью сообщений SOAP и не имеют значения в страницах ASP.NET AJAX. Однако третий атрибут - ScriptService - значительно важнее. Он конфигурирует веб-службу, разрешая JSON-вызовы из клиентов JavaScript. Без этого веб-службу нельзя было бы применять в странице ASP.NET AJAX.

После выполнения описанных действий можно приступать к написанию кода для своей веб-службы. Каждая веб-служба содержит один или более методов, которые помечены атрибутом WebMethod . Этот атрибут делает метод доступным для удаленного вызова. Если добавить метод, который не содержит атрибут веб-метода, серверный код сможет его использовать, но клиентский код JavaScript не сможет вызывать его непосредственно.

Public class TerritoriesService: System.Web.Services.WebService { public string HelloWorld() { return "Hello World"; } }

He обязательно делать метод общедоступным (как в этом примере), но обычно это делают согласно принятым соглашениям. На веб-методы накладываются определенные ограничения. Типы данных, используемые для значений параметров и возвращаемых значений, должны быть из числа тех, что описаны в таблице ниже:

Атрибут WebMethod принимает ряд параметров, большинство из которых несет определенную нагрузку в странице ASP.NET. Одним исключением является свойство EnableSession , которое по умолчанию имеет значение false, в результате чего состояние сеанса визуализации веб-службе недоступно. Это значение по умолчанию имеет смысл в традиционной веб-службе, не использующей ASP.NET AJAX, поскольку какая-либо информация о сеансе может не существовать, а клиент может вообще не поддерживать cookie-набор сеанса. Но в случае веб-службы ASP.NET AJAX вызовы веб-службы всегда осуществляются из контекста веб-страницы ASP.NET, которая выполняется в контексте текущего пользователя веб-приложения, и у этого пользователя имеются действующий сеанс и cookie-набор сеанса, автоматически передаваемые вместе с вызовом веб-службы.

Ниже приведен пример предоставления веб-методу доступа к объекту Session:

Public void DoSomething() { if (Session["myObject"] != null) { // (Использовать объект в состоянии сеанса.) } else { // (Создать новый объект и сохранить его в состоянии сеанса.) } }

Для примера с раскрывающимся списком веб-служба должна обеспечить способ получения регионов, расположенных на данной территории. Ниже приведен код веб-службы, содержащей веб-метод GetTerritoriesInRegion(), который извлекает регионы:

Using System; using System.Collections.Generic; using System.Web; using System.Web.Services; using System.Data; using System.Data.SqlClient; using System.Web.Configuration; public class TerritoriesService: System.Web.Services.WebService { public List GetTerritoriesInRegion(int regionID) { SqlConnection con = new SqlConnection(WebConfigurationManager.ConnectionStrings["Northwind"].ConnectionString); SqlCommand cmd = new SqlCommand("SELECT * FROM Territories WHERE RegionID=@RegionID", con); cmd.Parameters.Add(new SqlParameter("@RegionID", SqlDbType.Int, 4)); cmd.Parameters["@RegionID"].Value = regionID; List territories = new List(); try { con.Open(); SqlDataReader reader = cmd.ExecuteReader(); while (reader.Read()) { territories.Add(new Territory(reader["TerritoryID"].ToString(), reader["TerritoryDescription"].ToString())); } reader.Close(); } catch { // Маскировать ошибки throw new ApplicationException("Ошибка данных"); } finally { con.Close(); } return territories; } }

Код метода GetTerritoriesInRegion() подобен коду, который применялся ранее для обслуживания клиентского обратного вызова. Однако у этого кода имеется основное отличие - вместо того, чтобы возвращать единственную длинную строку с результатами, он возвращает информацию, используя строго типизированный список объектов Territory. Это - намного более строгий подход, предотвращающий случайные ошибки.

Класс Territory охватывает две части строковой информации. В нем определены общедоступные переменные-члены, а не свойства, поскольку он призван играть роль исключительно контейнера данных, который транспортирует информацию по сети:

Public class Territory { public string ID; public string Description; public Territory(string id, string description) { this.ID = id; this.Description = description; } public Territory() { } }

Это определение класса можно поместить в тот же файл кода, что и веб-служба, или в отдельный файл внутри каталога App_Code.

Теперь, когда нужная веб-служба создана, необходимо сконфигурировать страницу так, чтобы ей было известно о службе TerritoriesService. Для этого к странице нужно добавить элемент управления ScriptManager. Затем в дескриптор этого элемента управления потребуется добавить раздел .

С помощью элементов ServiceReference этого раздела перечисляются все используемые страницей службы и их расположения. Добавление ссылки на ранее приведенный файл TerritoriesService .asmx выполняется следующим образом:

При визуализации страницы на сервере ScriptManager будет генерировать прокси-объект JavaScript. В клиентском коде этот прокси-объект JavaScript можно применять для выполнения вызовов. Ниже приведен код двух списков, помещенных в веб-форму:

Первый список заполняется посредством обыкновенной привязки данных ASP.NET с помощью элемента управления источником данных SqlDataSource. Больший интерес представляет то, что он использует атрибут onchange для привязки к клиентскому обработчику события. В результате, когда пользователь выбирает новую территорию, JavaScript-функция GetTerritories() запускается, и текущее значение списка передается в качестве аргумента.

Формально весь код функции GetTerritories() можно было бы поместить непосредственно в атрибут события onchange, тем самым уменьшив количество создаваемых функций JavaScript. Однако отделение кода, который вызывает веб-службу, улучшает читабельность кода и облегчает его сопровождение.

Код JavaScript-функции GetTerritories() имеет следующий вид:

function GetTerritories(regionID) { TerritoriesService.GetTerritoriesInRegion(regionID, OnRequestComplete, OnError); }

Если вам ранее приходилось программировать с применением веб-служб ASP.NET, вы заметите, что синтаксис клиентского кода вызова веб-службы ASP.NET AJAX отличается от синтаксиса.NET. В приложении.NET сначала должен быть создан прокси-объект, а затем вызвана веб-служба на этом объекте. В странице ASP.NET AJAX используется готовый прокси-объект с тем же именем, что и у класса веб-службы.

Клиентские вызовы веб-службы являются асинхронными, поэтому наряду с исходными параметрами веб-метода всегда нужно предоставлять один дополнительный параметр, идентифицирующий клиентскую функцию JavaScript, которая должна вызываться после получения результата. (В рассматриваемом примере это функция OnRequestComplete.) Дополнительно можно добавить еще одну ссылку, указывающую на функцию, которая должна использоваться при возникновении ошибки. (В данном примере это функция OnError.)

Чтобы завершить пример, нужно предоставить клиентскую функцию, которая обрабатывает ответ. В данном примере это функция OnRequestComplete(). Она принимает возвращаемое значение в единственном параметре, а затем добавляет информацию во второй раскрывающийся список на веб-странице:

Function OnRequestComplete(result) { var lstTerritories = document.getElementById("lstTerritories"); lstTerritories.innerHTML = ""; for (var n = 0; n

Примечательной особенностью этого кода является то, что он в состоянии работать с результатом, возвращенным из веб-метода, без выполнения каких-либо дополнительных действий по десериализации. Еще больше впечатляет то, что веб-метод возвращает обобщенный список объектов Territory, который, очевидно, не имеет никакого эквивалента в коде JavaScript. Вместо этого ASP.NET AJAX создает определение для объекта Territory и возвращает полный список в массиве. Это позволяет коду JavaScript просматривать в цикле массив и проверять свойства ID и Description каждого элемента.

В данном случае можно воспользоваться одним небольшим ухищрением. Вместо метода document.getElementById() допускается применять псевдоним $get из ASP.NET AJAX, который выполняет ту же функцию и имеет следующий вид:

Var lstTerritories = $get("lstTerritories");

Этот прием - обычное соглашение, применяемое в страницах ASP.NET AJAX.

Теперь этот пример работает совершенно так же, как версия клиентского обратного вызова, описанная ранее. Различие между ними состоит в том, что эта версия использует строго типизированный веб-метод без громоздкого кода сериализации строк. Кроме того, не нужно добавлять никакой серверный код для динамического приема ссылки обратного вызова и ее вставки. Вместо этого можно применять простой прокси-объект, который обеспечивает доступ к веб-службе.

В качестве последнего штриха можно задать лимит времени и функции обработки ошибок, например:

Function OnError(result) { var lbl = document.getElementById("lblInfo"); lbl.innerHTML = "" + result.get_message() + "
"; lbl.innerHTML += result.get_stackTrace(); }

Функция OnError() получает объект ошибки, содержащий метод get_message() , который извлекает текст ошибки, и метод get_stackTrace() , который возвращает подробный стек вызовов с указанием места возникновения ошибки. На рисунке ниже показано, что происходит, когда веб-методу не удается подключиться к базе данных, и он генерирует стандартное исключение ApplicationException:

В этом примере продемонстрирована версия ASP.NET AJAX модели клиентского обратного вызова. Хотя она использует те же внутренние механизмы, что и функция клиентского обратного вызова ASP.NET, версия ASP.NET AJAX обеспечивает более прочный фундамент построенный на основе веб-служб. Тем не менее, оба подхода обладают одной общей чертой - независимо от применяемого подхода придется писать собственный код JavaScript для обновления страницы.

В большинстве случаев для обработки обратных вызовов ASP.NET AJAX целесообразно создавать отдельную веб-службу. Обычно этот подход ведет к созданию более четких страниц и облегчает отладку и совершенствование кода. Тем не менее, в некоторых ситуациях могут существовать один или более веб-методов, которые явно предназначены для использования на единственной странице и действительно не будут применяться в других частях приложения. В этом случае можно создать выделенную веб-службу для каждой страницы или же переместить код веб-службы в страницу.

Помещение кода веб-метода в страницу не представляет сложности - фактически, для этого достаточно простого перетаскивания. Для начала скопируйте свой веб-метод (дополненный атрибутом WebMethod) в класс отделенного кода страницы. Затем измените его на статический метод и добавьте атрибут System.Web.Script.Services.ScriptMethod . Ниже приведен пример помещения веб-метода (GetTerritoriesInRegion) в веб-страницу:

Public partial class _Default: System.Web.UI.Page { public static List GetTerritoriesInRegion(int regionID) { // Передать работу классу веб-службы TerritoriesService service = new TerritoriesService(); return service.GetTerritoriesInRegion(regionID); } }

Установите свойство ScriptManager.EnablePageMethods в true и удалите ссылку в разделе кода ScriptManager (при условии, что не собираетесь использовать какие-либо веб-службы, не встроенные в страницу):

И, наконец, измените код JavaScript так, чтобы он вызывал метод посредством объекта PageMethods, как показано в следующем примере:

Function GetTerritories(regionID) { PageMethods.GetTerritoriesInRegion(regionID, OnRequestComplete, OnError); }

Объект PageMethods представляет все веб-методы, добавленные в текущую веб-страницу.

Одно из преимуществ помещения веб-метода в страницу состоит в том. что метод больше не представляется через файл.asmx. В результате он не считается частью общедоступной веб-службы, и его обнаружение кем-либо посторонним затруднено. Это обстоятельство - веский аргумент, если веб-службы желательно скрыть от любопытных глаз.

Еще одна возможная причина кодирования веб-методов непосредственно в классе страницы - необходимость считывания значений из состояния представления или элементов управления, расположенных на странице. При вызове метода страницы запускается упрощенная версия жизненного цикла страницы, как это имело место при использовании функции клиентского обратного вызова ASP.NET. Конечно, попытка модификации деталей страницы лишена какого-либо смысла, поскольку страница не визуализируется и, следовательно, любые вносимые изменения будут просто отброшены.

С точки зрения безопасности приложения не имеет никакого значения, размещаются веб-методы в странице или в выделенной веб-службе. Размещение веб-метода в странице может скрыть его от случайных пользователей, но настоящий взломщик начнет с просмотра HTML-кода страницы, который включает в себя ссылку на прокси-объект JavaScript. Злоумышленники могут легко использовать прокси-объект JavaScript для выполнения подложных вызовов веб-метода. Для защиты от подобных угроз веб-методы должны всегда реализовывать те же самые меры безопасности, которые применяются в веб-страницах. Например, любой принимаемый ввод должен быть проверен на достоверность, код должен отказываться возвращать уязвимую информацию не аутентифицированным пользователям, а при доступе к базе данных должны применяться параметризованные команды для предотвращения атак внедрением SQL.

A web service is a web-based functionality accessed using the protocols of the web to be used by the web applications. There are three aspects of web service development:

• Creating the web service
• Creating a proxy
• Consuming the web service

A web service is a web application which is basically a class consisting of methods that could be used by other applications. It also follows a code-behind architecture such as the ASP.NET web pages, although it does not have a user interface.

To understand the concept let us create a web service to provide stock price information. The clients can query about the name and price of a stock based on the stock symbol. To keep this example simple, the values are hardcoded in a two-dimensional array. This web service has three methods:

• A default HelloWorld method
• A GetName Method
• A GetPrice Method

Take the following steps to create the web service:

Step (1) : Select File -> New -> Web Site in Visual Studio, and then select ASP.NET Web Service.

Step (2) : A web service file called Service.asmx and its code behind file, Service.cs is created in the App_Code directory of the project.

Step (3) : Change the names of the files to StockService.asmx and StockService.cs.

Step (4) : The .asmx file has simply a WebService directive on it:

Step (5) : Open the StockService.cs file, the code generated in it is the basic Hello World service. The default web service code behind file looks like the following:

Using System; using System.Collections; using System.ComponentModel; using System.Data; using System.Linq; using System.Web; using System.Web.Services; using System.Web.Services.Protocols; using System.Xml.Linq; namespace StockService { // // Summary description for Service1 // // To allow this Web Service to be called from script, // using ASP.NET AJAX, uncomment the following line. // public class Service1: System.Web.Services.WebService { public string HelloWorld() { return "Hello World"; } } }

Step (6) : Change the code behind file to add the two dimensional array of strings for stock symbol, name and price and two web methods for getting the stock information.

Using System; using System.Linq; using System.Web; using System.Web.Services; using System.Web.Services.Protocols; using System.Xml.Linq; // To allow this Web Service to be called from script, // using ASP.NET AJAX, uncomment the following line. // public class StockService: System.Web.Services.WebService { public StockService () { //Uncomment the following if using designed components //InitializeComponent(); } string[,] stocks = { {"RELIND", "Reliance Industries", "1060.15"}, {"ICICI", "ICICI Bank", "911.55"}, {"JSW", "JSW Steel", "1201.25"}, {"WIPRO", "Wipro Limited", "1194.65"}, {"SATYAM", "Satyam Computers", "91.10"} }; public string HelloWorld() { return "Hello World"; } public double GetPrice(string symbol) { //it takes the symbol as parameter and returns price for (int i = 0; i < stocks.GetLength(0); i++) { if (String.Compare(symbol, stocks, true) == 0) return Convert.ToDouble(stocks); } return 0; } public string GetName(string symbol) { // It takes the symbol as parameter and // returns name of the stock for (int i = 0; i < stocks.GetLength(0); i++) { if (String.Compare(symbol, stocks, true) == 0) return stocks; } return "Stock Not Found"; } }

Step (7) : Running the web service application gives a web service test page, which allows testing the service methods.

Step (8) : Click on a method name, and check whether it runs properly.

Step (9) : For testing the GetName method, provide one of the stock symbols, which are hard coded, it returns the name of the stock

For using the web service, create a web site under the same solution. This could be done by right clicking on the Solution name in the Solution Explorer. The web page calling the web service should have a label control to display the returned results and two button controls one for post back and another for calling the service.

The content file for the web application is as follows:

Untitled Page Using the Stock Service

The code behind file for the web application is as follows:

Using System; using System.Collections; using System.Configuration; using System.Data; using System.Linq; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.HtmlControls; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using System.Xml.Linq; //this is the proxy using localhost; namespace wsclient { public partial class _Default: System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { if (!IsPostBack) { lblmessage.Text = "First Loading Time: " + DateTime.Now.ToLongTimeString } else { lblmessage.Text = "PostBack at: " + DateTime.Now.ToLongTimeString(); } } protected void btnservice_Click(object sender, EventArgs e) { StockService proxy = new StockService(); lblmessage.Text = String.Format("Current SATYAM Price:{0}", proxy.GetPrice("SATYAM").ToString()); } } }

A proxy is a stand-in for the web service codes. Before using the web service, a proxy must be created. The proxy is registered with the client application. Then the client application makes the calls to the web service as it were using a local method.

The proxy takes the calls, wraps it in proper format and sends it as a SOAP request to the server. SOAP stands for Simple Object Access Protocol. This protocol is used for exchanging web service data.

When the server returns the SOAP package to the client, the proxy decodes everything and presents it to the client application.

Before calling the web service using the btnservice_Click, a web reference should be added to the application. This creates a proxy class transparently, which is used by the btnservice_Click event.

Protected void btnservice_Click(object sender, EventArgs e) { StockService proxy = new StockService(); lblmessage.Text = String.Format("Current SATYAM Price: {0}", proxy.GetPrice("SATYAM").ToString()); }

Take the following steps for creating the proxy:

Step (1) : Right click on the web application entry in the Solution Explorer and click on "Add Web Reference".

Step (2) : Select "Web Services in this solution". It returns the StockService reference.

Step (3) : Clicking on the service opens the test web page. By default the proxy created is called "localhost", you can rename it. Click on "Add Reference" to add the proxy to the client application.

Include the proxy in the code behind file by adding.

Сегодня существует два фундаментально различных способа реализации Web сервисов, основанных на HTTP, в Microsoft® .NET. Первой и наиболее низкоуровневой техникой является написание специального класса IHttpHandler, который вставляется в цепочку.NET HTTP pipeline. Этот подход требует использования System.Web API для обработки входящих HTTP сообщений и System.Xml API для обработки конверта SOAP, находящегося в теле HTTP. При написании специального обработчика также требуется создать вручную документ WSDL, который точно описывает вашу реализацию. Чтобы сделать все это правильно, необходимо глубокое понимание спецификаций XML, XSD, SOAP и WSDL, что является для большинства устрашающим условием.

Более продуктивным способом реализовать Web сервисы является использование WebMethods оболочки Microsoft ASP.NET. С ASP.NET поставляется специальный класс IHttpHandler для.asmx (называемых WebServiceHandler), который обеспечивает набор необходимых вам функциональных возможностей XML, XSD, SOAP и WSDL. И, поскольку WebMethods оболочка защищает вас от сложностей, лежащих в основе XML технологий, вы можете быстро сосредоточиться на существующих проблемах бизнес логики.

Выбор между техниками реализации приводит к общему сравнению выгод и потерь между гибкостью и продуктивностью, как показано на Рисунке 1. Создание специального IHttpHandler дает вам неограниченную гибкость, но также требует большего времени на написание, тестирование и отладку кода. Оболочка WebMethods облегчает организацию вашего Web сервиса и быстроту разработки, но вы явно ограничены рамками оболочки. Однако в случаях, когда оболочка WebMethods не обеспечивает именно того, что вам надо, есть возможность расширить ее, добавляя собственные дополнительные функциональные возможности.

В общем, пока вы не освоили XML, XSD, SOAP и WSDL и не хотите утруждаться, работая с ними напрямую, лучше продолжайте работать с оболочкой WebMethods. Она поставляет основные сервисы, которые необходимы большинству конечных Web сервисов, а также некоторые интересные возможности расширения, которые позволяют привести оболочку в соответствие вашим конкретным надобностям. Исходя из этого, далее в статье обсуждаются внутренние механизмы работы WebMethods. Если вы новичок в XML Schema и SOAP, перед тем как продолжить прочитайте Understanding XML Schema (http://msdn.microsoft.com/webservices/building/frameworkandstudio/default.aspx?pull=/library/en-us/dnxml/html/understandxsd.asp ) и Understanding SOAP (http://msdn.microsoft.com/webservices/building/frameworkandstudio/default.aspx?pull=/library/en-us/dnsoap/html/understandsoap.asp ).
Оболочка WebMethods

Оболочка WebMethods занимается преобразованиями SOAP сообщений в методы класса.NET. Это делается, прежде всего, путем аннотирования ваших методов атрибутом , находящемся в пространстве имен System.Web.Services. Например, следующий класс.NET содержит четыре метода, два из которых аннотированы атрибутом :

using System.Web.Services; public class MathService { public double Add(double x, double y) { return x + y; } public double Subtract(double x, double y) { return x - y; } public double Multiply(double x, double y) { return x * y; } public double Divide(double x, double y) { return x / y; } }

Чтобы использовать этот класс с оболочкой WebMethods, вам надо компилировать его в сборку и скопировать в виртуальную директорию директории bin. В этом примере методы Add и Subtract затем могут быть раскрыты как операции Web сервиса, в то время как с методами Multiply и Divide этого сделать нельзя (т.к. они не были отмечены атрибутом ).

Вы раскрываете Add и Subtract как операции Web сервиса через.asmx файл. Чтобы сделать это, создайте новый текстовый файл Math.asmx, содержащий следующее простое описание, и поместите его в ту же виртуальную директорию, которая содержит и сборку (обратите внимание: файл помещается в саму виртуальную директорию, а не в ее дочернюю директорию bin):

Это описание указывает обработчику.asmx, какой класс использовать для WebMethods, а обработчик чудесным образом заботится обо всем остальном. Например, предположим, виртуальная директория называется ‘math’ и содержит Math.asmx наряду с тем, что дочерняя директория bin содержит сборку, вызов http://localhost/math/math.asmx приводит к тому, что обработчик.asmx генерирует страницу документации, показанную на Рисунке 2 (см. далее).

Это один из основных вариантов работы обработчика.asmx. Файл.asmx обычно содержит только описание WebService, которое ссылается на класс Web сервиса по имени (как в примере, показанном ниже). Следовательно, в этом случае, сборка должна уже быть скомпилирована и размещена в директории bin виртуальной директории. Обработчик.asmx также обеспечивает JIT компиляцию исходного кода, находящегося в файле.asmx. Например, следующий файл (названный Mathjit.asmx) содержит описание WebService вместе с исходным кодом класса, на который ссылается.

using System.Web.Services; public class MathServiceJit { public double Add(double x, double y) { return x + y; } public double Subtract(double x, double y) { return x - y; } public double Multiply(double x, double y) { return x * y; } public double Divide(double x, double y) { return x / y; } }

Когда к этому файлу доступаются через HTTP впервые, обработчик.asmx компилирует источник и правильно размещает сборку. Обратите внимание, что в описании WebService должен быть также указан и язык программирования, чтобы обработчик.asmx мог выбрать в среде выполнения правильный компилятор. Явным недостатком этого подхода является то, что вы не знаете об ошибках компиляции до тех пор, пока не обратитесь к файлу.

При создании нового проекта Web сервиса в Visual Studio® .NET вы всегда используете технику “двух файлов”, когда исходный файл класса отделен от файла.asmx, который на него ссылается. Интегрированная среда разработки (IDE) хорошо скрывает это от вас, но если вы нажмете Show All Files на панели инструментов Solution Explorer, вы увидите в проекте по два файла для каждого класса Web сервиса. Кстати, Visual Studio .NET не поддерживает для файлов.asmx синтаксическое выделение или IntelliSense®, поэтому вы сами решаете, следовать ли в этом направлении. В Web проектах Visual Studio .NET также заботится о создании виртуальной директории и автоматическом компилировании сборки в директорию bin виртуальной директории.

Перед погружением в детали работы обработчика.asmx давайте коротко обсудим, как обрабатываются сообщения от Internet Information Server (IIS), прежде всего, в обработчике.asmx. Когда входящее HTTP сообщение достигает порта 80, для того, чтобы определить, какая ISAPI DLL должна использоваться для его обработки, IIS использует информацию метабазы IIS. Инсталляция.NET связывает расширения.asmx с Aspnet_isapi.dll, как показано на Рисунке 3.

Aspnet_isapi.dll – это стандартное расширение ISAPI, поставляемое.NET Framework, которое просто направляет HTTP запросы в отдельный рабочий процесс, называемый Aspnet_wp.exe. Aspnet_wp.exe выполняет роль хоста для общеязыковой среды выполнения и.NET HTTP pipeline. Как только сообщение входит в.NET HTTP pipeline, pipeline просматривает в файле конфигурации, какой класс IHttpHandler надо использовать для данного расширения. Если вы посмотрите свой файл Machine.config, то увидите, что он содержит httpHandler, связанный с расширением.asmx, как показано здесь:

...

Итак, когда сообщение поступает в.NET HTTP pipeline, нацеливаясь на файл.asmx, pipeline заходит в класс WebServiceHandlerFactory, чтобы создать новый объект WebServiceHandler, который может использоваться для обработки запроса (с помощью метода IHttpHandlerProcessRequest). Затем объект WebServiceHandler открывает физический файл.asmx, чтобы определить имя класса, содержащего ваш WebMethods. Более подробная информация о работе.NET HTTP pipeline представлена в HTTP Pipelines: Securely Implement Request Processing, Filtering, and Content Redirection with HTTP Pipelines in ASP.NET (http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/02/09/HTTPPipelines/default.aspx).

Сразу после того, как.NET HTTP pipeline вызывает обработчик.asmx, чудесным образом начинается обработка XML, XSD, SOAP и WSDL. Остальные функциональные возможности, предоставляемые обработчиком.asmx, могут быть разделены на три основные группы: 1) координирование сообщений, 2) преобразование XML в объекты и 3) автоматическое генерирование WSDL и документации. Давайте каждую из этих групп рассмотрим более детально.
Диспечеризация сообщений

Когда HTTP pipeline вызывает обработчик.asmx, просматривая описание WebService в файле.asmx, он определяет, какой класс.NET использовать. Затем он просматривает поступившее HTTP сообщение, чтобы определить, какой именно метод вызывать в данном классе. Чтобы вызвать операцию Add, показанную в предыдущих примерах, входящее HTTP сообщение должно выглядеть примерно так:

POST /math/math.asmx HTTP/1.1 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "http://tempuri.org/Add" 33 66

На самом деле во входящем HTTP сообщении есть два участка, которые могут использоваться для определения метода, который должен быть вызван в классе: заголовок SOAPAction или имя запрашиваемого элемента (т.е. имя элемента в пределах элемента soap:Body). В этом случае хотя бы один из них определяет имя метода, который хочет вызвать отправитель.

Для диспечеризации сообщения обработчик.asmx по умолчанию использует заголовок SOAPAction. Значит, обработчик.asmx смотрит на заголовок SOAPAction в сообщении, а затем, используя.NET рефлексию, проверяет методы класса. Он рассматривает только методы, помеченные атрибутом , но, просматривая значение SOAPAction каждого метода, он точно определяет, какой метод вызывать. Поскольку мы явно не определили значение SOAPAction в методах нашего класса, обработчик.asmx принимает, что значением SOAPAction будет сочетание пространства имен Web сервиса и имени метода. Поскольку мы также не определили и пространство имен, обработчик по умолчанию присваивает http://tempuri.org. Таким образом, значение по умолчанию SOAPAction для метода Add будет http://tempuri.org/Add.

Вы можете изменить пространство имен Web сервиса, помечая класс атрибутом , так же как и точное значение SOAPAction, помечая WebMethods атрибутом , как показано далее:

using System.Web.Services; using System.Web.Services.Protocols; public class MathService { public double Add(double x, double y) { return x + y; } public double Subtract(double x, double y) { return x - y; } ... }

Теперь обработчик.asmx ожидает, что значение SOAPAction для метода Add будет http://example.org/math/Add и urn:math:subtract для метода Subtract (поскольку мы явно задали это значение). Например, следующее сообщение HTTP запроса вызывает операцию Subtract:

POST /math/math.asmx HTTP/1.1 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "urn:math:subtract" 33 66

Если обработчик.asmx не находит SOAPAction, подходящего для входящего HTTP сообщения, он просто формирует исключительную ситуацию (позже рассмотрим, как обрабатываются исключительные ситуации). Если для диспечерезации метода вы не используете заголовок SOAPAction, помечая класс свойством RoutingStyle атрибута , вы можете указать обработчику.asmx использовать имя элемента запроса. Если вы делаете это, то также надо указать, что WebMethods не нуждаются в значении SOAPAction, путем установления их значений в пустую строку, как показано ниже:

using System.Web.Services; using System.Web.Services.Protocols; public class MathService { public double Add(double x, double y) { return x + y; } public double Subtract(double x, double y) { return x - y; } ... }

В этом случае обработчик даже не рассматривает значение SOAPAction – он использует вместо него имя элемента запроса. Например, ожидается,что имя элемента запроса для метода Add будет Add (из пространства имен http://example.org/math), как показано в этом сообщении HTTP запроса:

POST /math/math.asmx HTTP/1.1 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "" 33 66

Значит, первое, что делает обработчик.asmx при получении входящего HTTP сообщения, – он определяет, как перенаправить сообщение в соответствующий WebMethod. Однако до того как он действительно сможет вызвать метод, он должен преобразовать входящий XML в.NET объекты.
Преобразование XML в объекты

Как только обработчик WebMehod определил, какой метод надо вызвать, он должен десериализовать XML сообщение в.NET объекты, которые могут быть предоставлены во время вызова метода. Так же как и при диспечеризации сообщения, обработчик проверяет класс с помощью рефлексии, чтобы выяснить, как обрабатывать входящее XML сообщение. Класс XmlSerializer осуществляет автоматическое преобразование между XML и объектами в пространстве имен System.Xml.Serialization.

XmlSerializer делает возможным преобразование любого public типа.NET в тип XML Schema и, вместе с тем, может проводить автоматические преобразования между.NET объектами и документами XML (см. Рисунок 4). XmlSerializer ограничен теми возможностями, которые сегодня поддерживает XML Schema, поэтому он не может работать со всеми сложностями сегодняшних объектных моделей, такими как комплексные не древовидные диаграммы объектов, дублирующие указатели и т.д. Несмотря на это, XmlSerializer может работать с большинством комплексных типов, используемых разработчиками.

Для приведенного выше примера Add XmlSerializer преобразует элементы x и y в.NET double значение, которые затем смогут предоставляться при вызове Add. Метод Add возвращает вызывающему значение типа double, которое затем должно быть опять сериализовано в XML элемент в рамках SOAP ответа.

Также XmlSerializer может автоматически работать с комплексными типами (за исключением описанных выше ограничений). Например, следующий WebMethod вычисляет расстояние между двумя структурами Point:

using System; using System.Web.Services; public class Point { public double x; public double y; } public class Geometry { public double Distance(Point orig, Point dest) { return Math.Sqrt(Math.Pow(orig.x-dest.x, 2) + Math.Pow(orig.y-dest.y, 2)); } }

SOAP сообщение запроса для этой операции будет содержать элемент Distance, который включает два дочерних элемента, orig и dest, и каждый из этих элементов должен содержать дочерние x и y элементы:

0 0 3 4

В этом случае SOAP сообщение ответа будет содержать элемент DistanceResponse, включающий элемент DistanceResult типа double:

5

Применяемое по умолчанию XML преобразование использует имя метода в качестве имени элемента запроса и имена параметров в качестве имен дочерних элементов. Структура каждого параметра зависит от структуры типа. Имена public полей и свойств просто преобразовываются в дочерние элементы, как в случае x и y (в Point). Именем элемента ответа по умолчанию становится имя элемента запроса, оканчивающееся словом "Response". Элемент ответа также содержит дочерние элементы, названные так же как и элементы запроса, только оканчивающиеся словом "Result".

Есть возможность освободиться от стандартного XML преобразования путем использования большого количества встроенных атрибутов преобразования. Например, для преобразования имени типа и пространства имен можно использовать атрибут . Чтобы контролировать то, как параметры или члены класса преобразовывают элементы или атрибуты, вы можете пользоваться атрибутами и , соответственно. А для контроля за тем, как сам метод преобразовывается в имена элементов в сообщениях запроса/ответа, можно воспользоваться атрибутом . Например, ознакомьтесь со следующей версией Distance, в которой используются различные атрибуты:

using System; using System.Web.Services; using System.Web.Services.Protocols; using System.Xml.Serialization; public class Point { public double x; public double y; } public class Geometry { public double Distance(Point orig, Point dest) { return Math.Sqrt(Math.Pow(orig.x-dest.x, 2) + Math.Pow(orig.y-dest.y, 2)); } }

В этой версии Distance ожидается, что входящее SOAP сообщение будет выглядеть следующим образом:

И будет сгенерировано такое SOAP сообщение ответа:

5

Для реализации и определения приведенного выше преобразования, применяемого по умолчанию, обработчик.asmx использует документ/литерал стиль SOAP. Это означает, что описание WSDL будет содержать буквенные определения XML schema, описывающие и элементы запроса, и элементы ответа, используемые в SOAP сообщениях (т.е. правила SOAP кодирования не используются).

Обработчик.asmx также делает возможным использование rpc/литерал стиля SOAP. Это означает, что SOAP Body содержит XML представление вызова RPC и параметры сериализовываются с использованием правил SOAP кодирования (т.е. XML Schema не нужна). Соответственно, вместо атрибутов и вы используете и . Более подробно о различиях в этих стилях см. в разделе MSDN Understanding SOAP (http://msdn.microsoft.com/webservices/building/frameworkandstudio/default.aspx?pull=/library/en-us/dnsoap/html/understandsoap.asp).

Как видите, есть возможность полностью изменить процесс преобразования данного метода в SOAP сообщение. XmlSerializer обеспечивает мощный механизм сериализации со многими возможностями, о которых у нас нет времени здесь говорить. Более подробно о том, как работает XmlSerializer, см. в разделе MSDN Moving to .NET and Web Services (http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/01/11/webserv/). Я также рассмотрел многие нюансы XmlSerializer, не раскрытые в моей ежемесячной колонке MSDN Magazine, XML Files (http://msdn.microsoft.com/msdnmag/find/default.aspx?type=Ti&phrase=XML%20Files) (смотрите список колонок в online архивах).

Кроме работы по десериализации параметров, обработчик.asmx также может десериализовать/сериализовать SOAP заголовки. SOAP заголовки обрабатываются не так, как параметры, поскольку они обычно считаются несвязанной информацией без прямой привязки к конкретному методу. Поэтому обработка заголовка обычно делается с помощью уровней перехвата, полностью защищающих WebMethods от необходимости иметь дело с обработкой заголовков.

Если, все-таки, вы хотите использовать информацию заголовка из WebMethod, вы должны предоставить класс.NET, наследуемый от SoapHeader, который представляет XML Schema заголовков (следуя рекомендациям преобразования, приведенным выше). Затем вы определяете переменную члена этого типа, выполняющую роль «заполнителя» для экземпляров заголовка. И наконец, вы помечаете каждый WebMethod, нуждающийся в доступе к заголовку, определяя имя того поля, куда вы хотите его направить.

Например, SOAP запрос, содержащий заголовок UsernameToken с целью аутентификации:

Mary yraM ...

Чтобы сделать возможной для обработчика.asmx десериализацию заголовка, сначала надо определить класс.NET, представляющий предполагаемый тип XML Schema (обратите внимание: если у вас на самом деле есть XML Schema для заголовка, вы можете генерировать класс, используя xsd.exe /c). В этом случае соответствующий класс выглядит следующим образом:

Public class UsernameToken: SoapHeader { public string username; public string password; }

Затем просто надо определить переменную члена в вашем классе WebMethod, чтобы хранить экземпляр класса заголовка, и аннотировать WebMethods атрибутом , как показано ниже:

using System; using System.Web.Services; using System.Web.Services.Protocols; public class Geometry { public UsernameToken Token; public double Distance(Point orig, Point dest) { if (!Token.username.Equals(Reverse(Token.password))) throw new Exception("access denied"); return Math.Sqrt(Math.Pow(orig.x-dest.x, 2) + Math.Pow(orig.y-dest.y, 2)); } }

Затем в WebMethod вы можете обратиться к полю Token и извлечь информацию, которая была предоставлена заголовком. Вы также можете отправить заголовки обратно клиенту, используя ту же технику – вам просто надо определить направление заголовка в описании атрибута . Более подробную информацию об обработке SOAP заголовков в оболочке WebMethods см. в разделе MSDN Digging into SOAP Headers with the .NET Framework. (http://msdn.microsoft.com/webservices/building/frameworkandstudio/default.aspx?pull=/library/en-us/dnservice/html/service06182002.asp)

Обработчик.asmx также обеспечивает автоматическую сериализацию исключительных ситуаций.NET. Любая необработанная исключительная ситуация,перехваченная обработчиком.asmx, автоматически сериализуется в элемент SOAP Fault в ответе. Например, в предыдущем примере, если имя пользователя не совпадает с паролем, наш код формирует исключительную ситуацию.NET. Тогда обработчик.asmx обработает ее и сериализует в SOAP ответ, как показано ниже:

soap:Server Server was unable to process request. --> access denied

Если вы хотите еще больше контролировать элемент SOAP Fault, вы можете также явно сформировать объект SoapException, определяя все детали элемента SOAP Fault, такие как элементы faultcode, faulstring, faultactor и detail. Более подробная информации представлена в разделе MSDN Using SOAP Faults (http://msdn.microsoft.com/webservices/building/frameworkandstudio/default.aspx?pull=/library/en-us/dnservice/html/service09172002.asp).

Как видите, чтобы понять, как работает WebMethods, необходимо еще разобраться с механизмом, лежащим в основе сериализации, и всем многообразием его возможностей. Преимуществом механизма сериализации является то, что он скрывает весь лежащий в основе XML API код, который обычно вам приходится писать в специальном обработчике. Однако, в то время как большинство разработчиков считают это положительным моментом, некоторые называют это недостатком, потому что все еще хотят самостоятельно работать с SOAP сообщением в пределах реализации WebMethod. Более детально о том, как использовать такой смешанный подход, см. в разделе MSDN Accessing Raw SOAP Messages in ASP.NET Web Services (http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/03/03/WebServices/default.aspx).
Автоматическое генерирование WSDL

Клиентам надо точно знать, как должно выглядеть SOAP сообщение, чтобы успешно работать с ним. Общепринятым является предоставлять описания Web сервиса через WSDL (и встроенные XSD определения). Для этого обработчик.asmx автоматически генерирует и страницу документации, и описание WSDL, которое точно отражает интерфейс WebMethod. Если вы применили группу атрибутов преобразования к вашим WebMethods, все они будут отражены в сгенерированной документации.

Если вы посмотрите файл.asmx, то найдете страницу документации, такую как показано на Рисунке 2. Эта страница документации генерируется страницей.aspx, называемой DefaultWsdlHelpGenerator.aspx (находящейся в C:windowsMicrosoft.NETFramework v1.0.3705config). Если откроете файл, вы увидите, что это всего лишь стандартная страница ASP.NET, которая использует.NET рефлексию для генерирования документации. Эта возможность позволяет документации всегда соответствовать коду. Просто модифицируя этот файл, вы можете изменять генерируемую документацию.

Также можно блокировать генерирование документации на основе виртуальной директории, определяя другой файл документации в файле Web.config:

...

Если клиент завершает запрос GET для.asmx символами "?wsdl" в строке запроса, обработчик.asmx вместо документации генерирует описание WSDL. Клиенты могут использовать описание WSDL для генерирования proxy классов, которые автоматически знают, как общаться с Web сервисом (т.е. используя Wsdl.exe в.NET).

Чтобы изменить процесс генерирования WSDL, вы можете написать класс SoapExtensionReflector и зарегистрировать его с оболочкой WebMethods в файле Web.config. Затем, когда обработчик.asmx будет генерировать описание WSDL, он вызовет ваш класс и даст вам возможность изменить окончательное описание, поставляемое клиенту. Более подробно о том, как писать классы SoapExtensionReflector, см. в разделе MSDN SoapExtensionReflectors in ASP.NET Web Services (http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20030320WebServicesMP/manifest.xml).

Используя две различные техники, вы можете полностью блокировать процесс генерирования WSDL. Во-первых, для доступа клиентами вы можете предоставить статический WSDL документ в вашей виртуальной директории и затем блокировать генератор документации, удалив его из вашего файла Web.config, как показано ниже:

...

Немного более автоматизированной техникой является использование атрибута для определения местоположения статического документа WSDL в виртуальной директории, которую реализовывает класс WebMethod. Вы также должны определить имя WSDL binding, которое реализовывает каждый WebMethod, используя атрибут . Процесс автоматического генерирования WSDL импортирует ваш статический WSDL файл и «завернет» его в новое описание сервиса. Более подробная информация по этой технике представлена в статье MSDN Place XML Message Design Ahead of Schema Planning to Improve Web Service Interoperability (http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/02/12/WebServicesDesign/).

Сегодня очень тяжело вручную создавать WSDL, потому что до сих пор нет достаточного количества доступных редакторов WSDL. Поэтому автоматическое генерирование документации/ WSDL является ценной частью оболочки WebMethods, которая облегчит жизнь многим разработчикам.
Заключение

Оболочка WebMethods ASP.NET обеспечивает высокопроизводительный подход к построению Web сервисов. WebMethods сделали возможным использовать традиционные методы.NET в качестве операций Web сервиса, которые поддерживают HTTP, XML, XML Schema, SOAP и WSDL. Обработчик WebMethod (.asmx) автоматически определяет, как отправить входящие SOAP сообщения в соответствующий метод, в какой точке он автоматически сериализует входящие XML элементы в соответствующие объекты.NET. И упрощая жизнь клиента, обработчик.asmx также обеспечивает автоматическую поддержку для генерирования документации для человека (HTML) и для машины (WSDL).

Хотя по сравнению со специальным IHttpHandlers оболочка WebMethods может выглядеть несколько ограниченной, она обеспечивает мощную модель расширяемости, известную как оболочка SOAP расширения. Расширения SOAP обеспечивают возможность для удовлетворения ваших конкретных нужд ввести дополнительные функциональные возможности, помимо обсуждаемых здесь. Например, Microsoft выпустила Web Services Enhancements 1.0 для Microsoft .NET (WSE), которые просто предоставляют класс SoapExtension, вводящий в оболочку WebMethods поддержку для нескольких GXA спецификаций. Более подробная информация по написанию SOAP расширений представлена в MSDN Fun with SOAP Extensions (http://msdn.microsoft.com/webservices/building/frameworkandstudio/default.aspx?pull=/library/en-us/dnaspnet/html/asp03222001.asp).

HttpModule - глобальный обработчик запросов ко всем страницам приложения, с помощью которого можно "вклиниваться" в различные этапы обработки запроса (не…

Тип double - это основной тип данных, который используется для переменных, содержащих числа с дробной частью. Double используется в C, C++, C# и других языках…

Однажды посмотрев HTML-документ, генерируемый ASP.NET и содержащий GridView, я заметил, что большое количество символов, содержащихся на странице - пробелы и знаки…