Глава 11 Разработка веб-сервисов для корпоративных систем

Данная глава включает в себя две важные темы. Это прежде всего веб-сервисы, основополагающая для. NET технология, на которой зиждется все сетевое взаимодействие в этой среде. Вторая тема продолжает рассказ об архитектурах распределенного взаимодействия и представляет собой описание технологии Windows Communication Foundation (WCF). Исторически одной из наиболее ранних технологий, не считая веб-сервисов как таковых, была технология Remoting, но на сегодняшний день эта технология не является доминирующей, хотя на ее основе до сих пор производится достаточно много полезных приложений серьезного уровня. Напомним, что технология Remoting подразумевает жесткие связи между клиентом и сервером, строгий протокол взаимодействия, в связи с чем на ее основе производится программное обеспечение безопасных информационных систем. Технология же WCF не является, также как сам подход, связанный с веб-сервисами, столь жестким и, возможно, столь безопасным.

Веб-сервисы представляют собой, в том варианте, в котором мы рассмотрим их, вариацию на тему более общего и, может быть, более известного подхода, носящего название сервисно-ориентированной архитектуры, и изначально, наверное, во многом вместе с Microsoft или даже раньше, разрабатывался корпорацией IBM. Те решения, которые созданы на его базе IBM, являются в определенном смысле более открытыми, поскольку не только базируются на платформе операционной системы Microsoft Windows, но и поддерживают целый ряд других платформ, в частности Unix-системы. Поэтому подход SOAP (сервисно-ориентированной архитектуры), которому следуют в том числе и веб-сервисы, является несколько более широким, но поскольку мы сосредоточиваемся преимущественно на технологиях Microsoft, речь пойдет в основном об этих технологиях. Конечно, центральным понятием для архитектуры Microsoft.NET являются веб-сервисы. Ранее уже шла речь о клиент-серверных архитектурах, и понятно, что для реализации корпоративных приложений имеет смысл, конечно же, разделять логику взаимодействия компонентов системы на клиентскую и серверную части, когда у нас одна из них запрашивает ресурс или доступ, а другая этот доступ организует, а ресурс предоставляет. В данной главе будут рассмотрены веб-сервисы, возникновение этой концепции, а также ее особенности для. NET и то, каким образом следует ее использовать, а именно, каковы основные принципы, основные подходы, связанные с реализацией веб-сервисов. Мы рассмотрим достаточно подробно небольшой пример весьма простого веб-сервиса, который создается на основе инструментального средства Microcoft Visual Studio.NET. Покажем, каким образом создаются и применяются веб-сервисы. Более подробно рассмотрим модель реализации веб-сервиса в архитектуре Microsoft.NET, на платформе Microsoft.NET. Вспомним общую схему архитектуры. NET. На самом нижнем уровне находится операционная система Windows и ее сервисы, далее идут. NET Framework, базовые классы, которые осуществляют взаимодействие как с операционной системой, так и с более высокими прикладными уровнями различных информационных систем. И где-то на промежуточном этапе между собственно прикладной логикой и семейством классов. NET Framework находятся в том числе и веб-сервисы, рядом с такими архитектурными компонентами, как, скажем, ADO.NET (Active Data Objects), XML.NET, ASP.NET и целым рядом других элементов.

Более подробно стоит рассмотреть, каким образом веб-сервисы вписываются в общую концепцию и архитектуру Microsoft.NET и, кроме того, обсудить, каким образом осуществляется обнаружение или поиск веб-сервисов. Ведь, по сути, веб-сервис – это некий компонент, который опубликован или, проще сказать, размещен на интернет-сервере. Существует специальный язык, который называется Web Service Definition Language (WSDL) и предназначен для описания веб-сервисов. Это интерфейсный язык, в определенном смысле это достаточно нейтральный стандарт, который можно использовать для описания веб-сервисов. Существует также средство поиска с названием Disco (от слова discovery).

И, конечно же, необходимо обсудить то, как концепция веб-сервисов вписывается в общую архитектуру, в более общую картину SOAP и, естественно, веб-сервисы как элемент этой концепции, сервисно-ориентированной, подчиняются протоколу SOAP, на основе которого функционируют не только веб-сервисы от Micfosoft, но и веб-сервисы от IBM, и большое количество других веб-сервисов. Таким образом этот протокол поддерживается в среде веб-сервисов от Microsoft. Существуют потенциально более безопасные технологии, связанные с сетевым взаимодействием. Это прежде всего Remoting, если рассматривать Microsoft-технологии построения распределенных приложений. Обсудим безопасность веб-сервисов и способы обеспечения этой безопасности, а каким образом ВС, эта центральная часть архитектуры. NET, используется для реализации приложений Microsoft.NET.

Перейдем непосредственно к рассказу о ВС: что такое ВС, что понимается под этим термином. Первое слово, которое мы встречаем, – это WEB, т. е. речь идет об Интернете, и поскольку речь идет о сервисе, то здесь мы имеем дело с клиент-серверным взаимодействием, и клиентом, конечно же, является веб-браузер, точно так же, как в случае тонкого клиента. Напомним, что в этом случае на клиенте размещена только презентационная логика, собственно прикладная логика вся размещается на сервере, в связи с чем клиент у нас получается достаточно легким, или, как говорят, тонким. Он ограничен исключительно веб-браузером, и – что имеет принципиальное значение для корпорации – таких клиентов достаточно легко тиражировать, настраивать. Скажем, если появится необходимость из соображений безопасности провести какие-то настройки на клиенте, то это произойдет единообразно для всех компьютеров пользователей, а их в корпорациях тысячи. Если нужно внести какое-то изменение в программную среду клиента, это опять-таки делается и тиражируется с учетом тех средств, которые разработаны, в том числе МС, достаточно легко. Но, надо сказать, что есть интересные средства и у H P, и у Compaq, которые позволяют достаточно эффективно распределять или распространять изменения по компьютерам. И в связи с этим администрирование становится централизованным и во многом упрощается. Итак, ВС – это не просто интернет-приложение, это некий специальный тип, особый вид веб-приложений, который на самом деле не просто создает ответный HTML, появляющийся в браузере пользователя, а характеризуется использованием так называемых веб-методов, т. е. специализированных функций, описанных в среде. NET, которые можно вызывать из браузера. При рассмотрении традиционного клиент-серверного взаимодействия, когда клиент является веб-браузером, понятно, что он читает и воспринимает только статический HTML, в этой связи существует некоторое обобщение.

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

В чем состоят основные особенности реализации и применения ВС? Во-первых, ВС выполняются, конечно же, на сервере, потому что клиент является легким, тонким, по сути это веб-браузер, который имеет только презентационную логику, скажем, определенные формы, которые нужно заполнять, и он обращается к ВС, которые расположены, конечно же, не на клиенте, не в веб-браузере, не на компьютере пользователя, а на сервере. При этом средой выполнения является ASP.NET, т. е. как раз серверная технология, которая предусмотрена для работы в архитектуре клиент– сервер. При этом веб-сервисы осуществляют публикацию, т. е. размещение в Интернете методов, по сути, функций, которые могут быть вызваны внешними клиентами, т. е. интернет-браузерами пользователей, которые эти методы обнаруживают на том или ином сервере в Интернете. То есть сервер, выполняющий запрос пользователя и применяющий при этом ASP.NET, необязательно совпадает с сервером, который хранит и осуществляет взаимодействие пользователя с публикуемыми методами. Взаимодействие при этом, естественно, организуется на основе открытого протокола, стандартного протокола, который поддерживает веб-браузер, это, естественно, HTTP. Существенным минусом или существенной особенностью его является невозможность сохранения состояния, но важно, что это достаточно открытый, стандартный протокол, который поддерживает любой веб-браузер, даже необязательно Microsoft Internet Explorer. Из любого веб-браузера можно осуществить вызов веб-сервиса. Веб-сервисы, те их компоненты, которые отвечают за выполнение этих методов, выполняют запросы, которые могут носить достаточно сложный, гетерогенный, многокомпонентный характер, и возвращают веб-браузеру ответы от сервиса – результаты выполнения этих методов, естественно, с использованием протокола HTTP.

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

Если вести речь о корпоративных приложениях, корпоративных системах, то имеет смысл остановиться на корпоративном контенте – к нему относят реляционные данные, которые хранятся и обрабатываются реляционными СУБД, в случае Microsoft это Microsoft SQL Server. Что касается данных, нужно еще отметить, что это не только реляционные данные, но и, скажем, данные мультимедийные, которые поддаются анализу и обработке зачастую не так хорошо и хранятся они иначе, это могут быть отсканированные документы, аудио– и видеозаписи и т. д., но в любом случае над ними есть при корпоративном подходе некоторая надстройка из метаданных. Будем считать, что это XML-описание полей определенного рода и указания на те области, в которых можно хранить значения этих полей. То есть мы определенным образом индексируем видеоинформацию, информацию звуковую, фотоизображения, после чего можем осуществлять в том числе семантический, т. е. осмысленный, поиск по ним или, по крайней мере, по тем метаданным, которые у нас в итоге, скажем в формате XML, представляются. В результате мы получаем возможность посредством веб-сервисов по стандартному HTTP-протоколу со стандартными языками описания, скажем WSDL и др. в рамках стандартной архитектуры, ориентированной на сервисы, и в рамках протокола SOAP осуществить взаимодействие между этими достаточно разнородными системами. Нам открывается важная возможность построения решений принципиально еще более высокого уровня, чем корпоративные системы, которые называются B2B-решения (Business-to-Business), когда речь идет не об организации процессов внутри одной корпорации, а о взаимодействии нескольких корпораций или компаний между собой. Здесь веб-сервисы выступают своего рода каналом взаимодействия, неким gateway, можно сказать, шлюзом между разнородными и разноплановыми системами этих разных корпораций. Мы просто указываем правила этим ВС, по которым нужно осуществлять поставку информации из одних систем, а из других эту информацию консолидировать.

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

Одно интересное приложение веб-сервисов связано с технологией быстрой разработки приложений. Быстрая разработка достаточно важна для корпоративных систем, поскольку прототипирование, разработка быстрых прототипов позволяет экономить трудозатраты и создать рабочую модель программной системы на достаточно ранней стадии. Это стадия анализа и формирования требований к программному продукту, когда мы можем представить проект решения руководству заказчика. При этом речь может идти о заказчике, который находится внутри нашей корпорации и для которого мы (как другая компания этой корпорации) ведем разработку программных систем. Или же это может быть сторонний заказчик, для которого разрабатывается система. В случае корпоративной системы это достаточно большая, тяжелая, затратная система для реализации, мы можем в сжатые сроки, особенно если мы используем инструментарий от Microsoft Visual Studio.NET, представить прототип. То есть реализацию основных функций без уделения сколь-нибудь серьезного внимания надежности, документации, безопасности и т. д. Существует достаточно большая библиотека веб-форм и элементов управления этих веб-форм от Microsoft.NET – библиотека Windows Forms, для того чтобы эффективно строить классы элементов и эффективно прототипировать программное обеспечение до реализации.

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

Каким же образом строятся веб-сервисы? Наверное, имеет смысл привести пример элементарного веб-сервиса, для того чтобы стало понятно, каким образом, используя инструментальные средства Microsoft Visual Studio.NET, осуществить построение более масштабных веб-сервисов и корпоративных информационных систем на их основе. Рассмотрим пример достаточно простого веб-сервиса, который будет вычислять квадратный корень числа, заданного пользователем в веб-браузере в соответствующей форме. Каким образом осуществляется создание такого рода веб-сервиса? Заметим, что мы работаем в рамках технологии ASP.NET, и поэтому, для того чтобы создать веб-сервис, мы должны создать веб-сервис именно этого класса. По сути, мы работаем в пространстве имен ASP.NET и строим веб-сервис на основе тех технологий, тех классов, которые изначально там имеются. В Microsoft Visual Studio.NET мы должны построить новый веб-сайт, мы выбираем в меню «new web site» и затем пункт подменю, который называется ASP.NET Web Service. После этого нужно задать его имя, предположим, мы его называем RootCalculateService. В соответствии с соглашением о наименовании это будет цепочка из трех слов, каждое из которых начинается с заглавной буквы, и между ними нет ни пробелов, ни подчеркиваний. Таким же образом у нас именуются классы в. NET Framework при реализации приложений на основе этой платформы. При этом у нас создается несколько файлов даже при том небольшом коде, который мы в этот веб-сервис внедряем. У нас существуют определенного рода конфигурационные файлы, Web Config, файл, который будет назван service.smx (подробнее структуру и назначение этих файлов рассмотрим далее) и, собственно, код веб-сервиса, который будет называться service.cs, т. е. на языке C# создается исходный код этого веб-сервиса и мы можем его видоизменять.

Такого рода интерфейс предоставляет нам Microsoft Visual Studio.NET, т. е. используются пространство имен, в частности System. Web, и подпространство имен в нем System.Web.Services, в котором у Microsoft Visual Studio.NET имеется достаточно большое количество классов, стандартным образом описывающих веб-сервисы. Здесь мы видим код, тот самый файл service.cs, С# код этого веб-сервиса. Веб-сервис представляет собой не что иное, как класс Microsoft.NET, общедоступный, который называется Public Class Service и включает некий метод, который тоже называется Service по умолчанию и который мы можем соответствующим способом изменять. Он может включать некоторые компоненты и методы для обработки этих компонентов. В рамках этого сервиса существует некий метод, который мы сейчас создали, он называется CalculateRoot, является общедоступным, имеет модификатор доступа Public и тип возвращаемого значения Double – число с плавающей точкой двойной точности. Точно так же и на вход он получает некий элемент Value типа Double, от которого будет вычислять квадратный корень. В итоге он должен выполнить стандартную функцию, которая находится в пространстве имен Math, математическую функцию, которая называется sqrt, и именно этот метод и вызывается с входным параметром Value, который передается веб-сервису. На основе выполнения этого метода он должен будет вернуть результат, что обозначается служебным словом Return.

По сути, весь наш код уместился в две строчки: это сигнатура метода – название метода, тип возвращаемого значения, тип входного значения, и одна строчка – вызов стандартной функции, которая должна вычислить значение и вернуть его сервису, для того чтобы сервис, отработав, передал его в виде HTML по HTTP-протоколу клиенту, т. е. веб-браузеру. Вот такого стандартного рода окно мы получаем при попытке открытия этого веб-сервиса из нашего клиента. Но сервис у нас хранится локально, и в адресе, в URL, у нас записано HTTP, и затем Localhost и нечто дальше. То есть наш сервис еще не размещен на сервере, и сервер мы эмулируем той же самой машиной, на которой размещен код веб-сервиса. Тем не менее в адресной строке мы вызываем тот самый сервис, который называется Service и имеет точный путь RootCalculateService, это в пути указано. В упрощенном варианте в этом примере мы видим, как осуществляется вызов веб-сервиса. При описании этого веб-сервиса мы видим ссылку под словом Service, которая стандартным образом, как это в веб-браузере и отображается, представляется текстом синего цвета с подчеркиванием: CalculateRoot, если мы по ней щелкаем, то осуществляется вызов веб-сервиса. Ниже, под чертой, осуществляется описание пространства имен, в котором выполняется вызов этого сервиса. Здесь указано, каким образом осуществлять вызов из. NET, используя язык C#, Visual Basic, C++. Возможно, существуют и другие интерфейсы. Кроме того, если мы хотим получить описание работы нашего веб-сервиса, мы можем щелкнуть по ссылке Service Description, которая расположена на строчку выше в описании нашего сервиса, и получить подробное описание этого сервиса.

На самом деле, если мы хотим увидеть, как представлен веб-сервис, так сказать, его внутреннее представление, мы можем обратиться к XML-версии и увидеть, что используются стандартный протокол SOAP, язык описания веб-сервисов WSDL и на этом языке (как мы видим, вариант XML версии 1.0) задается описание веб-сервиса. Здесь указывается, где у нас хранится этот веб-сервис, как называется, указано, что есть элемент, который называется CalculateRoot, и какого рода значения он получает на вход: это входной параметр с именем Value и типом Double. Если мы более внимательно просмотрим XML-структуру этого представления, а именно таким образом выглядит веб-сервис в XML-представлении, мы увидим ряд других параметров: параметры, которые он принимает на вход, параметры, которые он возвращает, и то, что взаимодействие осуществляется посредством передачи сообщений на языке WSDL от клиента к серверу и обратно. На самом деле, если посмотреть на скриншот (рис. 11.1), видно, что здесь представлена небольшая часть описания этого веб-сервиса. На самом деле описание даже такого небольшого веб-сервиса на языке XML занимает достаточно много места, поскольку используется большое количество стандартных функций, стандартных методов, которые применяются для. NET веб-сервисов.

Рис. 11.1. Описание веб-сервиса на языке WSDL

Далее при выполнении этого веб-сервиса пользователь в веб-браузере открывает ссылку на сервис, и под строчкой Service, где была ссылка на его имя CalculateRoot, на имя этого веб-сервиса, при щелчке левой кнопкой мыши получает новое окошко с описанием веб-сервиса CalculateRoot на языке XML и окно ввода данных. Здесь он должен ввести параметр, который имеет имя Value. Пользователь вводит сюда некоторое число. Можно было бы посмотреть, как отработал стандартный сервис, если бы пользователь ввел сюда, скажем, отрицательное число или строку символов, каким образом произошла бы обработка исключения. Но в данном случае пользователь вводит корректное число 4, здесь оно представлено как целое, но это вещественное число с точки зрения реализации нашего веб-сервиса. После этого пользователь нажимает на кнопку Invoke, и происходит обращение к серверу, где хранится описание метода, код которого мы видели. Там вызывается стандартный метод из пространства имен Math, который выполняет вычисление корня квадратного из вещественного числа двойной точности. В итоге мы получаем XML-представление в браузере, где фигурирует то самое число 2, которое и возвращается пользователю. Можно было бы это более аккуратно оформить, в виде окна. Таким образом, веб-сервис корректно отработал и вернул именно в том интерфейсе, в интерфейсе веб-браузера, из которого был запрошен, в новом окне этого интерфейса корректное значение. При этом на компьютере пользователя, хотя в данном случае он совпадает с сервером, в общем случае никаких действий по вычислению не производилось бы, а эта вычислительная процедура в форме метода на C# была бы расположена и хранилась на сервере, который производил вычисления.

После того как мы рассмотрели общее представление некоторого примера, пусть достаточно простого, реализации веб-сервиса, мы можем сделать некоторые предварительные выводы и заключения. В частности, у нас веб-сервис был создан как файл с расширением asmx. Именно это расширение регистрируется в файле mashine.config и именно здесь может храниться тот код веб-сервиса, который будет выполнен, тот код на C#, который мы создавали. Кроме того, этот код может храниться и отдельно. Какова структура asmx файла? По сути, он хранит класс, который задает веб-сервис, в данном случае метод CalculateRoot в классе Service, который и был доступен по ссылке. Файл начинается с директивы @service, т. е. показывает, что внутри этого файла содержится описание веб-сервиса, и существует еще атрибут Class, который описывает наш веб-сервис. Классы веб-сервиса могут быть описаны посредством атрибута Web Service, как и XML-описании, но этот атрибут не является обязательным. Важно, что в описании присутствует определение веб-методов, которые определяются как атрибут класса сервиса с тем же самым именем Web Method. При этом такой атрибут может быть присвоен только общедоступным методам заданного класса. То есть методам, которые имеют модификатор доступа Public, как у метода CalculateRoot класса Service.

Нужно сказать, что у Web Method имеется целый ряд атрибутов, связанных с различными параметрами, характеристиками обработки информации, которая поступает от пользователя и выполняется на сервере. При этом веб-сервисы изначально направлены на создание масштабируемых и достаточно мощных распределенных систем. В этой связи существуют такие параметры у веб-методов, как кэширование результата и буферизация. То есть специальные области памяти отводятся под хранение промежуточных результатов или результатов наиболее частых запросов. Существуют также специальные параметры, такие как Transaction Option, которые поддерживают обработку транзакций, т. е. атомов взаимодействия пользователей с данными. Естественно, каждый метод имеет некоторое имя – Message Name и описание – Description.

Взаимодействие между пользователем и сервером осуществляется посредством сеансов связи Session, и существует атрибут Enable Session, который связан с веб-методом и осуществляет включение или выключение поддержки состояния сеанса. Как уже было упомянуто, широко используется технология кэширования, когда тот или иной метод в определенные промежутки времени осуществляет запись ответов метода на запросы для последующего их использования.

При создании веб-сервиса существует достаточно общий и достаточно широкий класс, который так и называется – Web Service, на его основе можно создавать собственные веб-сервисы. Он находится в пространстве имен System.Web.Services. Public Class Service мы создали как раз на основе этого класса System.Web.Services.Web Service, а класс Web Service создали как дочерний на основе этого системного класса, он обладает всеми свойствами своего родителя и реализует все его методы, поскольку речь идет о традиционном объектно-ориентированном подходе. Кроме того, поскольку можно не только использовать существующие атрибуты и методы класса, но и создавать новые, расширять его, мы можем доработать, развить код этого класса, чтобы сделать на его основе свой. Подобно тому, как мы это сделали в примере, когда расширили код созданием дополнительного метода CalculateRoot, который вычислял квадратный корень из числа с плавающей точкой двойной точности, которая в результате и публиковалась на клиенте в веб-браузере.

Мы перечислили целый ряд атрибутов веб-методов. Все эти характеристики доступны из класса Web Service, и мы можем организовать непосредственный доступ к таким параметрам класса Web Service, как сессия, контекст, пользователь, сервер, приложение и т. д. Все они имеются в перечне атрибутов этого класса, управляются его методами, доступны, их описание можно найти в описании этого класса, это свойства Application, Context, User, Server и т. д. И если мы осуществляем наследование от этого класса, т. е. создаем собственные классы на основе данного, мы можем применить технологию. NET Remoting, т. е. использовать не только стандартные средства, связанные с веб-сервисом, но и Remoting для организации удаленного взаимодействия компонентов приложения.

Ранее указывалось, что технология Remoting имеет достаточно развитую библиотеку классов, которая позволяет организовать сессии такого рода взаимодействия. Уже упоминалось слово Disco – это такая странная аббревиатура, которая, к сожалению, явной расшифровки не имеет. Она происходит от слова Discovery – обнаружение, поиск. Это механизм на основе файлов, который служит для обнаружения и поиска локальных веб-сервисов. Кроме того, используются специальный язык WSDL и специальная служба UDDI – Universal Description Discovery and Integration, которая применяется для глобального поиска веб-сервисов. Именно благодаря этой службе становится возможным отыскать веб-сервисы, опубликованные на различных серверах, т. е. компьютерах, расположенных в Интернете. Эта задача на порядок проще, и взаимодействие существенно конструктивнее, чем то, что было сделано в предварительной версии Windows, которая появилась в сети Интернет. Для описания веб-сервисов используется язык WSDL. По сути, это подмножество языка XML, т. е. все, что пишется на WSDL, укладывается в XML-стандарт, но здесь есть специальные теги, подтеги WSDL, которые начинаются со слова WSDL. Здесь описываются type, scheme, element и т. д. То есть речь идет о тех объектах, тех атрибутах объектов и методах, которые используются для описания веб-сервисов. Кроме того, описаны сообщения – Message Name, которыми обмениваются объекты при взаимодействии в рамках веб-сервиса. Здесь используется традиционный протокол, предназначенный для обмена данными по сервисно-ориентированной архитектуре, и язык WSDL.

На самом деле достаточно полезно самостоятельно ознакомиться с описанием веб-сервиса, для того чтобы понять, какое значительное количество кода в нем содержится изначально, который мы не писали, но который автоматически наследуется из стандартного класса Web Service, и, конечно, для того, чтобы понять, какова структура веб-сервиса, какие поля и методы используются, как организуется взаимодействие: как организуются сессии, обмен сообщениями и т. д. Многое можно понять и почерпнуть для себя просто из этого описания, которое на самом деле представляет собой достаточно полное описание всей функциональности и всех атрибутов веб-сервиса. С другой стороны, это описание на достаточно универсальном языке, пусть и несколько громоздком в данном случае, по сути, это XML. Здесь нет в чистом виде C#, а есть основные параметры конфигурации этого веб-сервиса: какие атрибуты ему потребуются. Скажем, у нас есть элемент, который называется Value, имеет тип Double и связан с результатом, который выдает метод CalculateRoot. Выдает он его через объект, называемый CalculateRootResponse. Достаточно много можно почерпнуть из этого описания, если внимательно его просмотреть.

На рис. 11.1 представлена относительно небольшая часть этого описания. Итак, язык WSDL – это не что иное, как просто диалект XML, вариант или подмножество языка XML. Если мы будем стандартным средством разбора просматривать этот текст как XML, мы поймем, что это на самом деле XML. Но сюда включены специфические теги, которые позволяют описывать веб-сервисы. А веб-сервис – это не что иное, как класс, который наследует от стандартного класса Web Service свои свойства и имеет определенные атрибуты и методы. Возвращаясь к рисунку с примером веб-сервиса и его описанием на языке XML, можно заключить, что здесь имеется достаточно глубокая вложенность. То есть это описание имеет не один, а несколько уровней абстракции – имеется XML-схема, которая содержит элементы, скажем, атрибуты и методы. Приблизительно в таком виде выдержано описание веб-сервиса. Следовательно, речь идет об описании класса с достаточно большим уровнем вложенности по атрибутам и методам.

Кроме того, WSDL описывает веб-сервис как модуль, т. е. как некоторую замкнутую, самодостаточную единицу кода, который решает узкую специализированную задачу. В данном случае решается единственная задача – подсчет квадратного корня от того числа, которое будет передано пользователем через Internet Explorer, через веб-интерфейс, и возврат значения в том же интерфейсе. Описание WSDL включается между тегами базового элемента, который называется Definitions и имеет ряд разделов. Эти разделы описывают не только структуру веб-сервиса, но и его функции, не только в смысле его прямого назначения и тех расчетов, которые он осуществляет в данном случае, но и, конечно, в смысле интерфейса, взаимодействия с пользователем. Здесь есть раздел Messages – это сообщения, на основе которых будет строиться обмен с сервером, порты, виды портов, сервисы, которые он задействует, определенного рода Boundings, т. е. связи при осуществлении взаимодействия. Об это речь пойдет более подробно при рассмотрении технологии WCF. Здесь просто отметим, что Bounding – это достаточно важная составляющая. Types and Operations – это, по сути, атрибуты и методы, с которыми имеет дело наш веб-сервис. Нет смысла детализировать каждый из этих разделов, каждый может сделать это самостоятельно, используя XML-представление. Оно, с одной стороны, достаточно большое, с другой – вполне наглядное. Веб-сервисы взаимодействуют между собой на основе протокола SOAP. На самом деле это протокол, который функционирует поверх HTTP. Этот протокол достаточно общего вида, т. е. он никак не связан с Microsoft, с веб-сервисами от Microsoft, по сути, это международный стандарт, который существует для построения веб-сервисов или, лучше сказать, сервисов на основе сервисно-ориентированной архитектуры. Во многом его свойства унаследованы от удаленного вызова процедур. С точки зрения клиента, не существует различия между локальным описанием процедуры, т. е. описанием процедуры, которая будет выполнена локально, и описанием процедуры, которая будет выполнена где-то на удаленном сервере. Примерно таким же образом можно заключить, что нет разницы между описанием сервиса, который будет выполнен локально, так как только в URI разделе фигурирует Localhost. Только поэтому можно заметить, что веб-сервис будет выполнен на том же самом компьютере, с которого и осуществляется вызов. URI – универсальный идентификатор ресурса в Интернете, который, как и любой интернет-адрес, может физически описывать компьютер, находящийся где угодно в Интернете. Таким образом, вызов фактически инкапсулируется внутри самого сервиса. И, что немаловажно, взаимодействие осуществляется по общему протоколу, что позволяет в принципе связывать веб-сервисы, как созданные на основе продуктов Microsoft, так и другие. То есть позволяет строить шлюзы между различными веб-сервисами и вообще различными корпоративными системами. Это очень важно, поскольку корпоративные системы изначально являются гетерогенными. Такая ориентация на открытый протокол позволяет нам реализовывать разветвленные распределенные системы достаточно большого объема и их взаимодействие, независимо или в незначительной степени зависимо от тех технологий, на которых они построены. По сути, так же как в большом количестве других протоколов взаимодействия, речь идет об обмене сообщениями в рамках сессии между клиентом и сервером при таком взаимодействии. Это отчасти похоже и на RPC, скажем, на взаимодействие в связи с подходом CORBA, который был описан ранее, отчасти на COM-модель. По сути, у нас есть некоторый протокол обмена сообщениями, когда каждое сообщение включает в себя заголовок сообщения, некоторое тело, в котором, собственно, говорится о том, что же нужно выполнить, и конверт. Протокол SOAP основан на XML-технологии. То есть он не имеет ничего общего с Microsoft и с технологиями от Microsoft. Он точно так же используется и IBM, и другими. Это открытый протокол, международный стандарт, описание процедур удаленного вызова, описание сообщений в нем реализовано на стандартном XML. При этом среда. NET позволяет настраивать формат сообщений, которые отправляются при помощи веб-метода. Здесь используется протокол SAOP и целый ряд атрибутов, которые являются атрибутами класса Web Service. В частности, имеет смысл отметить пару атрибутов, которые называются SOAP Method Attribute и SOAP RPC Method Attribute. То есть взаимодействие по протоколу SOAP может осуществляться разными способами, в том числе и с явным использованием технологии RPC.

Теперь чуть более подробно о структуре заголовков SOAP, о структуре сообщений в этом протоколе для обмена данными. Существует атрибут SOAP Header Attribute, который как раз и призван осуществлять настройку заголовков. И здесь есть стандартный класс, который называется SOAPHeader и расположен в иерархии пространства имен следующим образом: System.Web.Services, т. е. находится внутри пространства имен веб-сервисов, дальше существует пространство имен Protocols, где есть ряд протоколов, в том числе и SOAPHeader. При этом в описании веб-сервиса для этого атрибута указывается имя переменной класса заголовка. После создания Public Class Service1, который является классом System. Webservices.Webservice, т. е. веб-сервисом, мы создаем некий заголовок Public, имеющий идентфикатор m_full и тип Header1. Затем мы его связываем с классом SOAPHeader и производим дальнейшее преобразование уже с осуществленной привязкой к тому типу заголовка, который мы задали. У протокола SOAP имеется достаточно большое количество расширений, которые мы можем использовать в рамках технологии Web Service от Microsoft для того, чтобы осуществлять обмен данными внутри пакетов в рамках сессий по взаимодействию между клиентом и сервером посредством сообщений. При этом можно осуществлять настройку и обработку этих данных достаточно гибким образом, на основе широких возможностей. Для этого существует класс SOAPExtension, и на его основе можно создать свой класс и использовать атрибут SOAP Extension Attribute для создания собственных расширений и регулирования взаимодействия между компонентами веб-сервиса в рамках этих расширений.

Ранее уже были рассмотрены Proxy и Stub. Proxy является инкапсуляцией сервера веб-сервиса в приложении. При этом Proxy в данном случае объявляется объектом класса, который создается в рамках стандартной библиотеки классов Microsoft.NET Framework и использует наше описание веб-сервиса на языке WSDL. При этом методы класса, который создается и инкапсулирует логику веб-сервиса, соответствуют методам веб-сервиса. Генерация этих классов уже автоматически предполагается в Microsoft.NET Visual Studio. Можно использовать и специальную утилиту, специальное приложение, которое называется WSDL.exe и может осуществлять генерацию такого рода классов, генерацию Proxy веб-сервиса. Интересно, что веб-сервисы могут осуществлять как синхронную, так и асинхронную обработку данных посредством вызова методов. При этом асинхронные методы веб-сервиса отмечаются префиксами begin и end. Каждый раз мы помечаем в квадратных скобках имя метода Method Name, что служит сигналом окончания выхода из процедуры, окончанием вызова метода веб-сервиса. Реализуется специальный интерфейс, который называется IAsyncResult, также можно подписаться на уведомление о завершении метода путем передачи делегата или указателя на событие. Похожего рода обработку информации мы обсуждали во время описания технологии Remoting, возможен вызов метода в асинхронном режиме по похожим схемам.

Последний аспект, который хотелось рассмотреть в связи с веб-сервисами, – это безопасность. Следует напомнить, что достаточно безопасным подходом, который довольно часто, в том числе и в последнее время, используется для производства распределенных приложений на основе технологии. NET, является Remoting. Нужно сказать, что ряд методов может быть использован и в стандартных веб-сервисах, которые работают на основе открытого протокола SOAP, взаимодействуют с клиентом по протоколу HTTP и используются широко в. NET Framework. Наверное, следует разделить эти методы, прежде всего на внутрикорпоративные, т. е. те сети, которые будут использованы для доступных лиц внутри корпорации и, естественно, распределенных приложений, и Интернет – открытую среду. В интранет реализуются технологии межсетевых экранов, firewalls, технологии, связанные с ограничением безопасности на основе протокола IP и IP-конфигурации во внутренних сетях. Создаются и используются технологии на основе VPN – виртуальных частных сетей, также аутентификация на основе протокола взаимодействия SP.net и специализированное расширение, связанное с безопасностью на основе протокола HTTP – это протокол HTTPS и другие варианты. В интернет-системах можно использовать цифровые подписи, применяемые в связи с протоколом SOAP, а также аутентификацию, основанную на использовании элементов конкретных прикладных систем.

На этом закончим обсуждение веб-сервисов. Это достаточно общий подход, который позволяет объединить возможности, которые реализованы Microsoft в платформе. NET, и распространить их на решения более общего вида, на гетерогенные системы, которые функционируют в существенно более гетерогенных средах и объединяют решения не только Microsoft, но и других производителей, поскольку речь идет о взаимодействии на основе протокола SOA и протокола HTTP, которые являются открытыми, и на основе сообщений, которые кодируются или задаются внутри при помощи языка WSDL, который на самом деле есть диалект XML.