Основы проектирования корпоративных систем Зыков Сергей

Глава 9

Разработка интерфейсов корпоративных систем по технологии Windows Forms

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

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

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

Прежде всего следует обсудить технологии построения интерфейсов на основе специализированных библиотек ввода данных. Задача ввода данных является нетривиальной, поскольку сотрудники корпорации должны интуитивно достаточно хорошо представлять себе, каким образом происходит ввод данных, и осуществлять его без коррекций, противоречий и дублирования. Интерфейсы должны быть эргономичны. В Microsoft сейчас работает, пожалуй, лучшая команда по usability. Большое количество пользователей во всем мире общается с ОС семейства Windows, офисными приложениями семейства Office, и эти интерфейсы им близки и естественны.

Рассматривая технологии Microsoft для ввода данных, представления данных и отчетов, следует сосредоточиться на технологии Windows Forms, которая служит не только для ввода данных, но и для построения отчетов. Одной из целей корпоративных систем является подготовка консолидированной отчетности, которая дает руководству возможность эффективно управлять корпорацией на основе динамики людских и финансовых ресурсов, основных средств, специализированных ресурсов (нефть, газ) и т. д. Здесь очень важны интерфейсы, их элементы, способы построения – все то, что дает возможность в интуитивно-явном режиме получать, интегрировать, консолидировать информацию и производить те самые формы вывода (отчеты) из интегрированных и гетерогенных систем, которые и учитывают различные корпоративные ресурсы. Информация об этих ресурсах в ряде случаев представляет собой не только хорошо структурированные данные, но и аудио-, видео-, отсканированные документы. Да и в случае структурированных документов они могут быть представлены в виде других приложений, и нам нужно объединять информацию из интернет-браузера (как тонкого клиента), из офисных приложений Word, Excel и строить достаточно сложные отчетные формы. Некоторые из них будут рассмотрены в данной главе.

Итак, технология Windows Forms. Что она включает? Какие инструменты важны? Постараемся сосредоточиться на инструментах для корпоративных приложений, в частности на примере построения элементарной формы. Пример будет включать фрагменты кода, что позволит нам понять, как корпоративные системы реагируют на события, происходящие в программной среде. Они могут быть инициированы как пользователем, так и ОС Windows и, естественно, корпоративными приложениями.

Прежде всего рассмотрению подлежат основные понятия, связанные с технологией Windows Forms. Это определение, что такое формы как программные объекты, каким образом осуществляется взаимодействие с ними, технология умных клиентов Smart Clients и др. Следует отметить, что Windows Forms дает возможность взаимодействовать с клиентами в интерактивном режиме, что предполагает свободу и высокую степень вовлеченности пользователя в систему и взаимодействие с элементами интерфейса, знакомыми нам по офисным приложениям, такими как командные кнопки, контекстное меню и др.

Речь идет о том, что в одном из пространств имен, надстроенном на. NET Framework, над базовыми классами. NET существует серьезная и большая по объему коллекция классов, которые представляют собой элементы интерактивных элементов Windows Forms, некоторые из них были перечислены выше. Рассмотрим более подробно, как выглядит интерфейс CASE-средства Visual Studio и как осуществляется визуальное проектирование интерфейсов с использованием этого средства. Далее будет описано понятие «событие» в среде Windows применительно к корпоративным приложениями, обсудим, каким образом осуществляется обработка событий, т. е. создание программного кода на языке C# на платформе. NET, которая осуществляет реакцию на действия пользователя в направлении элементов управления, т. е. тех элементов, которые составляют элементы формы и отчетные формы, – библиотеку классов Windows Forms. Рассмотрим классификацию элементов управления Windows Forms и познакомимся с категориями, включая выпадающие списки, элементы, связанные с веб-интерфейсом, построением таблиц для отчетов баз данных и сложных отчетных форм, включающих гетерогенную информацию, например таблицы Excel. Пользователь имеет возможность не только использовать наперед определенные классы, библиотеки Windows Forms, но и создавать, в том числе на их основе с использованием концепции наследования в среде Visual Studio, собственные элементы управления. Зачем это необходимо пользователю? Заметим, что в Windows Forms существует достаточно большое количество предопределенных классов, с помощью которых можно создавать интерфейсы, и код событий уже предопределен. Но если существует необходимость создавать специализированные системы с расширенными возможностями, у пользователя также есть выбор и свобода это сделать. Также рассмотрим специализированный инструмент Windows Forms Designer, являющийся частью среды разработки Visual Studio.NET. Познакомимся с его возможностями и посмотрим, насколько удобно им пользоваться для создания Windows-приложений. Подводя итоги, мы рассмотрим важные аспекты, которые связаны с особенностями и преимуществами для таких сфер, как отображение данных и манипулирование данными, включая взаимодействия с СУБД SQL Server.

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

Итак, что такое Windows Forms? Это технология Microsoft, являющаяся надстройкой над. NET Framework – базовым семейством классов. NET и, по сути, это набор объектно-ориентированных библиотек – семейство классов, которые облегчают дизайн приложений и их интерфейсов. В первую очередь это ввод данных, вывод отчетов, использование файловой системы. То есть реализация интерактивных пользовательских интерфейсов. Каковы основные возможности приложений Windows Forms? Речь идет о создании компонентов на основе базовых классов, реализованных в этой библиотеке, т. е. о надстройках в приложении, о программной надстройке над. NET Framework. Какие возможности имеют эти приложения? Технология Windows Forms тесно интегрирована с Microsoft.NET. Более того, используется инструмент Form Designer, который позволяет нам быстро осуществлять построение программных интерфейсов. Прежде всего, пользователи получают возможность вывода данных и построения отчетов, обмена информацией с удаленными компьютерами по сети через Интернет или посредством сетевого соединения. При этом применяется технология Smart Client, строятся специальные приложения, использующие технологию обмена по сети этим специальным способом, не имея информации о пользователе, который запрашивает данные. Подробнее эта технология будет рассмотрена позже.

Итак, какие базовые элементы включает технология Windows Forms? Другими словами, какие интерфейсные элементы содержатся в этой библиотеке классов? Отметим важные особенности – все эти элементы являются интерактивными, т. е. дают возможность пользователю взаимодействовать с элементами управления, входящими в состав форм.

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

Еще одним важным элементом Windows Forms является элемент управления, или Control. По сути, это некий атом функциональности пользовательского интерфейса. Скажем, элементарная командная кнопка, или переключатель, или флажок, или строка ввода данных, которая предназначена для ввода или отображения данных, является достаточно примитивным элементом библиотеки Windows Forms и надстраивается над. NET Framework. Windows Forms – это некий класс, который представляет собой с точки зрения программирования код на языке C# и во многом для удобства бизнес-пользователей строится визуально, поскольку речь идет о достаточно сложных манипуляциях графическими объектами, достаточно сложным и ресурсоемким по времени занятием является ручная настройка формы. Если мы будем выверять форму и ее размеры вплоть до пикселя, процесс проектирования займет огромное время (если вводить линейные размеры вручную, код каждого управления и т. д.). Конечно же, визуальное создание приложений, особенно с таким приятным и удобным интерфейсом, который предоставляет Visual Studio.Net, является предпочтительным. Таким образом, создание элемента Windows Forms происходит так: сначала рисуется форма – прямоугольный объект, после этого на форму (как бы поверх) набрасываются, добавляются с помощью drag&drop (как фишки на игровое поле) те или иные элементы управления. Они упорядочиваются, при этом все это тоже происходит визуально. И все необходимые атрибуты для управления формой производятся автоматизированно в средстве Visual Studio.Net. Кроме того, определены базовые сценарии действий для основных событий, которые может инициировать пользователь, такие как щелчок мыши, двойной щелчок, нажатие клавиши, drag&drop, горячие клавиши и др.

Теперь рассмотрим, как выглядит визуальный интерфейс в Visual Studio.Net в Windows Forms. Скриншот Visual Studio при создании формы представлен на рис. 9.1.

Рис. 9.1. Интерфейс Visual Studio.NET

Итак, сначала создали элементарную форму Form1.cs, т. е. код, который описывает все ее детали – линейные размеры, имя, ряд других аспектов. В частности, можно заметить, что на ней расположена командная кнопка button1. Все это задается автоматически при перемещении кнопки из репозитория основных элементов формы, доступных в Visual Studio. Как только создали форму, становятся доступными и стандартные кнопки, к которым мы привыкли в Windows, – минимизация формы, разворачивания на весь экран, закрытия. И, естественно, все коды, связанные с событиями, доступны автоматически, и этот код уже существует.

В окне Solution Explorer мы видим, что нами создан код Form1.cs – это код на C#. А в правом окне мы видим все метаданные. У этой формы есть файл designer, файл ресурсов – res, где описаны все метаданные, и есть окно свойств, где описаны основные параметры этой формы. В частности, видно, что размер линейный в самом нижней строчке скриншота, является 300 на 300 точек. Кроме того, программный код создан на C# и описывает все действия, которые будут производиться с этой формой. Рассмотрим, каким образом происходит управление событиями, связанными с формами, каким образом пользователь может осуществлять контакт с формой. Речь идет об обработке событий. При взаимодействии пользователя с формой, при визуальном ее изменении: щелчок на «свернуть», drag&drop, щелчок левой кнопкой мыши по кнопке Button1, и целым рядом других действий пользователя автоматически генерируется событие – Event. Приложение реагирует на событие с помощью кода. Существует некий код на C#, связанный с событиями. Он автоматически активизируется при обработке события.

В окне «Свойства» (Properties) на рис. 9.1 мы можем увидеть список событий, которые связаны с этой кнопкой. Интересно, что справа от имени кнопки button1 мы видим, что она расположена в пространстве имен System.Windows.Forms.Form1, т. е. в том классе, который описывает форму, и кнопка является ее атрибутом. Далее следует список событий. Например, событие click – однократный щелчок по Button1. Если мы откроем свойство, связанное с этим событием, мы можем просмотреть стандартный код и изменить его, если это необходимо.

В описании события «щелчок левой кнопкой мыши» по командной кнопке Button1 присутствует код, представленный на рис. 9.2.

Рис. 9.2. Код события «щелчок левой кнопкой мыши»

Возникает класс Form1, который является, по сути, подклассом стандартного класса Form, и внутри существует метод, также общедоступный, который называется Form1 – по сути конструктор. Он вызывает единственный метод InitializeComponent. Дальше отправляется событие, что форма начала существовать с некими аргументами, связанными с событиями этой формы (е). Это также фигурирует в окне свойств Button1.

Достаточно интересна полнота представления различных видов элементов управления для создания форм ввода данных и построения отчетов. Microsoft подходит к этому достаточно гибко и широко. На рис. 9.3 видно, что существует большое количество предопределенных элементов управления – Control, а в левом окне можно открыть панель управления – Toolbox. Это десятки предопределенных элементов Windows Forms. Таким образом, там содержится много элементов управления, которые перетаскиванием мыши можно разместить на форме. Это Poiner, командная кнопка, Checkbox-флажок и т. д. Различного рода метки – текст со ссылкой, выпадающий список и целый ряд других элементов. Скажем, существует командная кнопка, которую можно представить как изображение. Progress Bar, т. е. индикатор некоторого процесса, к примеру загрузки файла через Интернет. Radio кнопка – переключатель. Rich text box – мини-текстовый редактор, который также доступен изначально как готовый элемент управления. Интересно, что даже веб-страница существует как готовый элемент управления.

Рис. 9.3. Набор предопределенных элементов управления

Кроме тех элементов, которые были перечислены, пользователь может создать свои элементы. Для этого используется специальный класс user control. Естественно, можно использовать те классы, которые уже предопределены в. Net, конкретно в Windows Forms, в пространстве имен System.Windows.Forms и на основе классов – каждый элемент управления является классом – можно создавать собственные элементы управления, добавляя и убавляя свойства.

Для создания собственных форм и элементов управления и коррекции их в визуальном режиме используется средство Windows Forms Designer. Это компонент, встроенный в Visual Studio. Он позволяет создавать свои формы путем комбинирования элементов управления. Существует возможность выравнивания без особых затрат труда, поскольку это происходит визуально. В связи с этим есть возможность построения интерактивных интерфейсов, поскольку пользователь может взаимодействовать с ними посредством событий, и интеграция с Microsoft Office. Это интерфейс, который основан на знакомых нам приложениях и ОС Windows, и MS Office. Скажем, существуют элементы управления Tool strip и Menu strip, как в Word. Это может быть представлено как в форме меню, так и в форме инструментов – командных кнопок. По сути, они уже существуют в виде примитивов в пространстве имен и могут быть использованы в нужной конфигурации и автоматически собраны при просто визуальном перенесении пользователем их на форму. Таким образом можно быстро создавать меню, глубокую вложенность подменю, которые могут содержать и другие элементы управления.

Как упоминалось ранее, пользователь может создавать собственные элементы управления, для этого используются классы, содержащиеся в System.Drawing. Напомним, что структура. NET Framework достаточно четко разграничена. Прямо на форме можно осуществлять прорисовку или выполнение несложных иллюстраций, скажем, рисовать линии, прямоугольники, овалы и т. д. В Word тоже есть панель рисования. Очень важным является вопрос интеграции данных из гетерогенных источников. В части корпоративных приложений речь идет о гетерогенных системах, которые могут включать как хорошо структурированную информацию, так и плохо структурированную – видео, аудио, сканы. К каждому фотоизображению прилагается информация о том, когда была сделана фотография, каким фотоаппаратом, каков ее размер. При этом Windows Forms имеет специальный элемент управления DataGrid-View, чтобы из гетерогенных источников можно было извлекать данные и формировать отчеты. При этом могут быть использованы разные источники данных – БД: SQL Server, Access. Позже мы посмотрим, как выглядит отчет в DataGridView. Это представление среза данных, которое хешируется и хранится на клиентской части приложения и необязательно отражает актуальное состояние базы данных. Можно брать данные из специализированных данных формата XML, веб-сервисов и т. д. Какие возможности получает пользователь при работе с этим сложным элементом управления? Какие потери могут быть понесены, если попытаться создавать его самостоятельно? Мы можем динамически менять размер строк и столбцов, фиксировать их, настраивать представление, цвет фона, шрифта и т. д. Наконец, можно осуществлять отображение сложных объектов внутри каждой ячейки – не только текст, но и фото, видео. При этом внедрение на форму элемента управления DataGridView происходит стереотипно и так же легко для пользователя, как и размещение элементарной кнопки – drag&drop из репозитория на форму.

Очень важным при этом является свойство Entry Point – связь с гетерогенным источником данных – различной природы. Это могут быть хорошо структурированные реляционные данные, гетерогенно представленные в хранилище данных на основе xml метаданных.

Еще одной технологией, которая активно используется в связи с WinForms, является технология интеллектуальных клиентов SmartClients. С помощью этой технологии есть возможность взаимодействия с источником данных через сетевое соединение (через интернет-канал). Это крайне важно для корпоративных систем, так как дает возможность получения корпоративных данных через Интернет из любой точки земного шара. Для корпорации значение этой технологии трудно переоценить. На рис. 9.4 показан компонент BindingSource, мы видим его в Solution Explorer и в левом окне, которое представляет собой Design View, т. е. визуальное представление формы. Данный компонент дает возможность связать определенный элемент DataGridView с тем или иным источником данных, который позволяет нам извлечь гетерогенные данные той или иной природы (мы уже описывали виды источников данных, которые используются) и разместить их в форме.

Рис. 9.4. Компонент BindingNavigator

Компонент BindingSource является частью среды Microsoft.NET Framework и позволяет управлять целым рядом параметров взаимодействия корпоративного пользователя с источником данных. Это такие характеристики, как параметры соединения с источником данных, организация связи данных, которые извлекаются из того или иного источника с элементами управления (например, с ячейкой DataGridView), с определенными текстовыми элементами, скажем, многострочный вывод, однострочный и т. д., веб-страница, навигация между записями источника данных, если этот источник возможно представить в виде нескольких записей, например файл или таблицу в базе данных, редактирование записей источника данных – можно вносить через сетевое соединение изменения в данные на этом удаленном источнике и записывать изменения в источник данных.

Здесь есть достаточно серьезная проблема, связанная с управлением транзакциями, поскольку корпоративных пользователей, которые занимаются редактированием или просмотром объекта одновременно, достаточно много. Возникает вопрос: какие изменения и в какой последовательности записывать и как они будут отражены? Оптимально при правильном управлении транзакциями пользователь должен воспринимать информацию в параллельном режиме с другими пользователями, как будто он взаимодействует с базой только один. BindingSource и технология SmartClients во многом, естественно вкупе с другими технологиями, позволяют решить эти проблемы. Кроме того, существует элемент управления BindingNavigator, который дает возможность разработчикам использовать данный интерфейс для визуальной обработки записей данных из гетерогенных источников через сетевое соединение. На рис. 9.5 показан пример применения BindingNavigator и его размещение на Windows Form (на форме Form1 в данном случае) и организации визуального интерфейса с гетерогенным источником данных. При этом используется компонент BindingSource, построен конкретный пример объекта этого класса, который называется BindingSource1 и присутствует как в Solution Explorer, так и в Design View.

Рис. 9.5. Применение BindingNavigator

Другой способ связи основан на взаимодействии приложений и называется Application Settings. Это тоже подход SmartClients, использующий Windows Forms. Форматом хранения данных является XML. Файл описывает состояние приложения и фиксирует такие параметры, как линейные размеры формы на экране, персональные предпочтения пользователя, какие элементы и в каком положении он хочет видеть на форме, как, скажем, мы можем создать «мой Яндекс», упорядочить или определить свои предпочтения по тому, каким образом представлены элементы управления и в каком порядке они расположены на Яндекс-баре или других элементах интерфейса, можно изменить место хранения файлов по умолчанию и целый ряд других параметров. При этом во время выполнения приложения возможна автоматическая загрузка в память элементов данных и фактически осуществление кэширования информации на клиенте.

Теперь следует рассмотреть, каким образом это происходит визуально, как осуществляется работа с гетерогенными источниками данных на основе Application Settings. Сначала создается элемент управления Application Settings, в Solution Explorer – Properties появляется описание метаданных, которые связаны с Application Settings, здесь есть параметр PropertyBinging и ряд параметров, которые показывают связи с целым рядом атрибутов конкретного приложения. Есть параметры, описывающие линейные размеры, – Margin, Location, шрифт, местоположение файлов и т. д. Таким образом, на форме можно в динамическом режиме конкретизировать параметры источника данных, из которого извлекается информация. При извлечении данных из приложения необходимо использовать параметр Location, чтобы увидеть, как они отображаются в визуальном интерфейсе.

Важным аспектом корпоративных систем, который обеспечивает сокращение совокупной стоимости владения, является технология экономичного развертывания приложения. Ранее была рассмотрена технологии ClickOnce, которая позволяет быстро и в ряде случаев одним щелчком мыши и без участия специалистов по администрированию систем на уровне пользователя осуществить установку стандартных компонентов корпоративных приложений. Под развертыванием стоит понимать установку пользователем на клиентском компьютере – своей машине. Это может быть ноутбук, рабочая станция, смартфон или коммуникатор, т. е. некое клиентское устройство, для которого существует. NET Framework и соответствующие компоненты, объектные библиотеки и прикладные интерфейсы. Естественно, речь идет о том, что приложение может быть установлено после того, как оно разработано и для последующего использования. При реализации концепции быстрого развертывания приложения существуют проблемы. Это прежде всего массовая рассылка обновлений. Естественно, в корпорации функционирует далеко не одна информационная система. В каждом офисе существует большое количество гетерогенных информационных систем, при этом каждая система имеет некий номер версии, и отслеживание взаимосвязи этих версий – достаточно сложный процесс. Для этого используется специальное ПО – контроль версий: нужно отслеживать возможность согласованного использования компонентов этих приложений и, естественно, тех дополнений, доработок, которые разработаны для этих приложений с целью обеспечения их взаимной совместимости. Достаточно сложно – если речь идет о десятках тысяч пользователей – упростить рассылку обновлений и установку приложений. Если предположить, что каждый пользователь должен тратить 5 минут в день для установки приложений и их согласованной работы, получим тысячи человеко-часов. Чтобы этого избежать и повысить отдачу от использования приложений и снизить стоимость владения, Microsoft разработала ClickOnce – по сути, механизм сборок, описание кода, компонентов корпоративных систем с точки зрения как хранимых данных, так и метаданных, которые требуются этим сборкам, и, естественно, политики безопасности. Технология ClickOnce позволяет достаточно просто и быстро развертывать приложения при наличии Visual Studio и. NET одним или несколькими щелчками мыши, без ввода данных с клавиатуры, т. е. стандартным образом. Пользователь практически не может запутаться, повести себя двусмысленно – есть только один путь установки приложения, прямой и простой, и за короткое время без участия администратора пользователь может установить и настроить дополнение к приложению, как мы устанавливаем дополнения к приложению в Windows или Office.

Именно поэтому еще одним достоинством является интернет-ориентированность. Пользователю необязательно получать весь код, просто URL-ссылку на веб-сервер, на котором хранится код приложения в форме сборки. И после щелчка мыши по установке сборка сама, вместе с технологией ClickOnce, определяет возможность установки, программной среды, версии сборки, подлинность сборки, уровень безопасности, и в соответствии с политикой безопасности осуществляется установка дополнения на клиентский компьютер. Продолжим описание преимуществ технологии Click-Once. Поскольку вся информация о компоненте приложения локализована в сборке, осуществляется унификация управления как элементами данных, так и зависимостями. Для корпоративной системы сложно переоценить значение сборки как средства управления зависимостями между компонентами приложения. Автоматически осуществляется определение возможности установки, сборки в программную среду пользователя, притом что программное окружение пользователя является сложным и гетерогенным и производится или не производится установка. Осуществляется проверка корректности установки – удалось/не удалось и почему. Если установить продукт не удалось, пользователь может обратиться к администратору и четко передать то сообщение, которое на экране свидетельствует о том, что версия сборки не соответствует версии программной среды. Более того, возможно автоматическое обновление приложения на основе информации из Интернета. Также автоматическое обновление осуществляется практически без участия клиента, если клиент подтверждает возможность осуществления такого обновления в принципе. Кроме того, при обновлении приложения разработчику, который осуществляет коррекцию кода в терминах сборки, достаточно опубликовать новый манифест, т. е. метаданные сборки по указанному URL. Следовательно, не нужно тиражировать на все компьютеры пользователя и заботиться о совместимости программной среды того компонента, который вновь разработан, и того, что имеется у пользователя. Каким образом осуществляется публикация изменений или вновь разработанных корпоративных приложений иллюстрирует рис. 9.6. Здесь речь идет о размещении приложения на локальном компьютере, тем не менее это можно сделать и на FTP– и HTTP-сервере при наличии соответствующих прав доступа. Кроме того, если мы один раз указали местоположение, то именно по этому местоположению будет производиться размещение последующих апдейтов, сервис-паков, патчей и т. д. Именно этот интерфейс и использует Publish Wizard, т. е. средство упрощения развертывания приложений. Эта технология основана на подходе ClickOnce, при этом пользователю также достаточно выбрать автоматизированное обновление, и при помощи технологии ClickOnce осуществляется обновление приложений, пополнение, коррекция в автоматизированном режиме.

Рис. 9.6. Публикация разработанного приложения

Какие особенности имеет смысл отметить в Windows Forms в связи с перечисленными задачами по поддержке корпоративных приложений? Прежде всего это высокая степень интерактивности. Ранее описывалось, каким образом осуществляется интеграция приложений, каким образом поддерживаются такие сложные элементы управления, как DataGridView, каким образом пользователь может получить доступ к гетерогенным источникам информации для работы с базами данных, для работы со слабоструктурированной информацией (аудио, видео). Кроме того, поддерживаются окна, ведение диалога, возможен диалог пользователя системы, общение в интерактивном режиме, сценария взаимодействия пользователя с корпоративной системой. Windows Forms поддерживает элементы управления печати корпоративных интерфейсов с WYSIWYG интерфейсом, с помощью интеграции с офисными приложениями. Естественно, интерфейс при этом выглядит привычным пользователю образом, поскольку поддерживаются традиционные командные кнопки, пункты меню и т. д. Можно достаточно легко оснастить компоненты справочной информацией, т. е. онлайновой справочной системой с возможностью гипертекстовых ссылок, контекстного поиска и т. д., как мы видим в Windows и Office, можно добавлять документацию к формам и т. д., можно достаточно легко осуществлять локализацию приложения, перевод на другой язык – важно использование кодировки в Unicode. Кроме того, поддерживаются различные единицы измерения (метры, футы), различные валютные системы (рубли, доллары, евро и т. д.). И еще одна важная особенность Windows Forms: поскольку это надстройка на. Net Framework, можно использовать встроенную систему информационной безопасности, которая основана на реализации механизма сборок. Каждая сборка имеет метаданные, в которых описываются, в частности, автор, версия, цифровая подпись. То есть сборку достаточно сложно подделать или использовать вне контекста приложения, поскольку автор достаточно однозначно определяется сборкой, и сборка, если она подделана, не подойдет, не сможет быть установлена в корпоративную систему и каким-то образом повредить ее целостность, надежность и т. д.

Итак, подводя итоги обсуждения технологии Windows Forms, технологии, поддерживающей эргономичный интерфейс корпоративных приложений, можно сделать следующие выводы. Во-первых, эта технология поддерживает высокую интерактивность, сценарную обработку данных, т. е. обработку данных на основе событий с высокой вариативностью – сценарии эти могут быть достаточно гибкими и адекватно реагирующими на самые разные действия пользователя. Windows Forms имеет огромное количество различных элементов управления, которые позволяют строить достаточно сложные и одновременно привычные пользователю и понятные ему элементы интерфейса – это DataGridView, командные кнопки, элементы меню и т. д. Пользователь в связи с этим получает возможность работать с корпоративными системами предсказуемым образом, повышает свою производительность и, следовательно, производительность труда в корпорации. Кроме того, осуществляется возможность доступа к гетерогенным источникам информации, что важно для корпоративных пользователей, в первую очередь посредством удаленного доступа. Пользователи получают возможность доступа к гетерогенным источникам данных, а также к аудио– и видеоинформации на основе XML-представления. И что очень важно, они имеют возможность агрегировать эту информацию, получать ее в едином интерфейсе, т. е. в гетерогенном отчете может быть представлен как текст, извлечение из отчета базы данных на основе запроса, так и определенная фото– и видеоинформация, которая извлечена из хранилищ данных. Технология Windows Forms позволяет без особых затрат производить обновление, коррекцию, усовершенствование отдельных компонентов программных систем и программных систем в целом. Пользователь получает возможность автоматического обновления, если осуществляется подписка на это обновление, поскольку Windows Forms является надстройкой на. NET и поддерживает все политики, протоколы шифрования данных, протоколы взаимодействия, в том числе по Интернету, которые реализованы для. NET Framework.

Итак, была рассмотрена технология Windows Forms, которая предназначена для создания эргономичных пользовательских интерфейсов корпоративных систем. При этом упоминалось, что эта технология поддерживает распределенные взаимодействия пользователей с гетерогенными источниками данных на основе таких элементов, как BindingSourceNavigator, и подобных средств организации доступа к гетерогенным источникам корпоративной информации. Теперь обсудим, каким образом осуществляется создание и поддержка распределенных приложений на платформе. NET, какие технологии используются. Прежде всего, речь пойдет о веб-сервисах и о технологии Remoting. Последняя разработана Microsoft, является достаточно жесткой, но тем не менее обеспечивает высокую безопасность и надежность приложений, что весьма важно для корпоративных систем. Обсудим ее в связи с другими технологиями сетевого взаимодействия компонентов распределенных приложений в корпоративной интернет-среде.

Во-первых, рассмотрим общий принцип функционирования распределенных приложений, а также их основные особенности, в которых явно выделяются роли клиента и сервера. Клиент и сервер – это не обязательно аппаратное обеспечение, это не обязательно один и тот же компьютер. Сервер может быть распределен по нескольким компьютерам – это, скорее, логические объекты. Мы рассмотрим различия и основные особенности веб-сервисов по отношению к технологии Remoting. Далее речь пойдет об основных понятиях, которыми следует оперировать при определении распределенных приложений. Рассмотрим низкоуровневые средства для работы с сетевыми приложениями и еще раз вернемся к технологии клиент-серверного взаимодействия для построения распределенных приложений корпоративного типа. Очень важна, особенно в связи с Remoting, процедура удаленного вызова процедур (RPC). Это важная технология, которая исторически достаточно рано возникла и, по сути, реализует базовую схему взаимодействия распределенных приложений, в том числе в интернет-среде. Мы обсудим, каким образом осуществляется компонентное проектирование и программирование в среде. NET, центральным понятием идеологии. NET является компонент, синонимом компонента выступает сборка.

По сути, проектирование корпоративных приложений как раз и ведется в терминах компонентов. При этом пользователь или заказчик получает строго определенное корпоративное приложение, собранное по заказу именно из тех компонентов, которые нужны для получения пользователем требуемой им функциональности. Таким образом пользователь может гибко определять необходимую функциональность и экономить средства именно за счет выбора строго определенных компонентов корпоративных приложений. Мы рассмотрим технологию Web Forms в связи с Windows Forms, которые мы рассмотрели раньше, т. е. те формы ввода данных и получения отчетной информации, которые предназначены специально для интернет-взаимодействия, и посмотрим сходства и различия с Windows Forms.

Итак, перейдем к процедуре построения корпоративных распределенных приложений на основе технологии Remoting и других технологий, связанных с веб-сервисами и клиент-серверной архитектурой. Общий принцип построения подобных систем заключается в следующем: объекты или модули распределенного приложения в случае компонентного подхода к проектированию (компоненты или сборки) располагаются физически на нескольких компьютерах и логически – в нескольких процессорах ОС. За счет специализации выделяется слой бизнес-логики, который реализуется на клиентской части и на сервере. За счет этого оптимизируется производительность клиента и сервера и осуществляется взаимодействие элементов распределенного приложения в наиболее выгодном режиме для пользователей, по сути, оптимизируется производительность программной системы, время реакции, производительность пользователей.

Какие основные понятия характеризует веб-сервисы и технологии Remoting? Технология Remoting является достаточно жесткой по сравнению с общей методологией веб-сервисов. Microsoft продвигает принцип предоставления ПО как сервиса, поэтому понятие веб-сервиса не только не чуждо методологии. NET, но и является одним из ее основных компонентов. Веб-сервисы представляют собой слабосвязанную модель взаимодействия объектов на основе общедоступных мировых стандартов. Это в первую очередь протоколы взаимодействия HTTP, SMTP. Веб-сервисы независимы от языка программирования, в отличие от Remoting. Еще очень важно, что веб-сервисы поддерживают модель работы с объектами без сохранения внутреннего состояния. То есть объекты, по сути, не имеют памяти о своей истории. Подход. NET Remoting является более строгим, более жестким, нацеленным исключительно на среду. NET, т. е. прежде всего на ОС Windows. Конечно, NET поддерживается и для узкого круга Unix-систем, в рамках проекта mono, но в целом ориентация преимущественно на. NET и Windows. Кроме того, модель нацелена на более эффективное и безопасное выполнение объектов в. NET, так как содержит встроенную систему безопасности, она поддерживает сборки и подписи, алгоритмы шифрования, поддерживаемые средой. NET. Таким образом, реализуется сильно связанная модель, которая поддерживает память, т. е. состояние объектов, и обеспечивается более эффективное взаимодействие объектов в среде. NET. При этом объекты располагаются на разных компьютерах и в разных процессорах.

При исследовании слабо и сильно связанных (Loosely Coupled и Tightly Coupled) моделей распределенных приложений нужно отметить, что модель Loosely Coupled, также как и Tightly Coupled, предназначена для распределенных приложений. Различие состоит в более свободном выборе протоколов и отношении к сохранению состояния, которое используется в последнем подходе. Loosely Coupled модель подразумевает построение распределенных приложений на основе минимального набора приложений и взаимодействий. Tightly Coupled подход подразумевает более жесткую связь, более строгую однородность частей приложения и в отличие от Loosely Coupled основан на заранее согласованных более строгих протоколах и наборах данных. Loosely Coupled подход использует стандартные протоколы XML и HTTP. Что касается модели взаимодействия объектов, то здесь распределенные объекты взаимодействуют без сохранения памяти о своей истории. Таким образом, с точки зрения ООП можно конкретизировать подход взаимодействия клиента и сервера без сохранения состояния тем, что каждый вызов метода обрабатывает новый экземпляр объекта, который создается заново. В отличие от похода, связанного с наличием состояния, не меняется состояние объекта со старого на новое, а просто создается новый экземпляр объекта.

Что касается работы с сетью, позднее мы увидим, каким образом это связано с пространством имен Remoting. Напомним, что существует пространство имен System, внутри которого находится пространство. NET, а потом —.Sockets (рис. 9.7). Первое подпространство определяет основные параметры источников взаимодействия, т. е. таких точек взаимодействия на клиенте и сервере, как пространство доменных имен, характеристики точек взаимодействия и т. д. И пространство имен Sockets определяет более детально характеристики клиента и сервера, которые связаны с конкретным протоколом, скажем TCP/IP, и построением потока данных для обмена сетевой информацией.

Рис. 9.7. Иерархия пространств имен

Глава 10

Технологии сетевого взаимодействия корпоративных систем

Рассмотрим эволюцию технологий сетевого взаимодействия распределенных приложений и построение такого рода приложений. Одной из наиболее ранних технологий является удаленный вызов процедур – Remote Procedure Call. Во многом эта технология реализуется в Remoting при маршеринге, который будет рассмотрен несколько позднее. Еще одним подходом была передача сообщений, т. е. взаимодействие между распределенным приложением, между объектами. В одном из первых вариантов она называлась DCE – Distributed Computing Environment. Если рассматривать взаимодействие клиента и сервера, концепция открытых систем предполагает явное распределение ролей на клиент и сервер. При этом клиент – это компьютер, который осуществляет преимущественно запрос информации, в данном случае это вызов функции, которая на самом деле обращается к серверу, хотя это очевидно только из ее названия. Сервер осуществляет поиск, получение и предоставление отчетной информации для клиента в соответствии с его запросом. Кроме того, вспоминая главу об архитектуре, заметим, что помимо двух слоев клиент-серверной архитектуры (клиента и сервера), существует еще промежуточный слой, который предназначен для локализации взаимодействия. Но пока рассмотрим уровни клиента и уровни сервера.

Идея взаимодействия состоит в том, что функция, которая в данном случае называется Server Func, формально при чтении кода не должна вызывать ассоциации с сервером. С точки зрения клиента, осуществляется как бы выполнение этой функции. Функция имеет два параметра – символьный Hello и целочисленный 123. И результат должен быть присвоен некоему объекту J. На самом деле на клиенте функционирует специальный слой, который называется промежуточным и транслирует при переводе этой программы в промежуточный код из так называемого верхнего слоя (Top Layer), представляющего собой исходный текст на том или ином языке программирования (в данном случае это язык С), который транслирует этот вызов в некий внутренний вызов и упаковывает его нужным образом. Этот специализированный механизм называется Proxy-клиент. Он осуществляет трансляцию и упаковку этого вызова процедуры в обращение к другому компьютеру (серверу) с нужными параметрами, которые переупаковываются, меняют свои имена. Происходит передача некоего указателя на область памяти (*str) и некоего целочисленного значения v, с кодом, который у нас имеется на клиенте, осуществляется передача его после соответствующей упаковки серверу, Stub серверу, т. е. специальный функциональный компонент сервера осуществляет преобразование этого запроса во внутренний запрос сервера, организацию процедуры, заданной клиентом, и активизацию этой процедуры на сервере с заданными параметрами. Вычисление значений с переданными аргументами происходит путем подстановки вместо параметров их значений. Вычисление связано с работой процедуры на сервере. После этого осуществляется обратная упаковка и передача клиенту в ответ на его запрос. На нижнем уровне (Bottom Layer) осуществляется передача данных по сети на соответствующем уровне. Ниже находятся все последующие протоколы сетевого стека.

В ходе обсуждения взаимодействия RPC – это один из весьма важных механизмов взаимодействия по сети, который принципиально важен для понимания технологии Remoting. Осуществляется взаимодействие между Proxy и Stub. Proxy – это подпрограмма, которую может вызывать клиент на сервере. Поэтому технология называется процедурой удаленного вызова. Proxy передает серверу запрос на вызов подпрограммы, которая работает на сервере, с заданными параметрами, и ждет ответа от сервера. После выполнения процедуры результат возвращается клиенту. При этом вызов Proxy с точки зрения кода клиента не отличается от вызова внутренней подпрограммы или метода. Фактически эта логика взаимодействия удаленного вызова инкапсулируется внутри Proxy. Аналогично, но только на сервере, работает технология, связанная со Stub. Это тот код, который выполняется на сервере. Он получает от клиента запрос на вызов заданной подпрограммы. Осуществляется вызов подпрограммы, которая работает на сервере, а не на клиенте, как кажется клиенту. И результат, который записывается в переменную Result, автоматически после упаковки отправляется по сети на клиент. При этом Proxy и Stub создаются автоматически. Для этого, конечно же, требуется определенного рода описание открытых интерфейсов, т. е. сред взаимодействия между клиентом и сервером. Одним из примеров такого языка является IDL–Interface Definition Language, который используется в технологии брокеров объектных запросов (COBRA).

Итак, мы можем видеть три слоя взаимодействия, если абстрагироваться от сетевого уровня, где все просто описано с точки зрения кода, на уровне исходного текста программ – процедура на клиенте и процедура на сервере. На уровне Middle Layer происходит упаковка Proxy Stub клиента и упаковка параметров, выполнение процедуры на сервере после распаковки и передача упакованного результата через Middle Layer на клиент. Собственно, данные передаются на уровне Bottom Layer по протоколу передачи данных. Естественно, существует стек сетевых протоколов с целым рядом протоколов, которые лежат ниже перечисленных нами уровней процедурного взаимодействия.

Посмотрим, как осуществлялась революция объектных методов RPC в 1990-е гг. При этом объекты могут быть реализованы разными средами разработки и написаны на разных языках программирования.

Объектное RPC скрывает различия между объектами, которые разработаны в разных интегрированных средах и, возможно, на разных языках. В связи с этим сделан большой шаг вперед по сравнению с предыдущим подходом, который на самом деле достаточно жестко завязан на язык программирования. И, конечно же, по сути, объектного взаимодействия в 1980-е гг. в полной мере еще не было. При этом наиболее распространенными подходами следует считать подходы, основанные на компонентной модели COM c динамическим расширением Decom и COM+. И второй важный подход – CORBA. Это альтернативный подход, связанный с брокерами объектных запросов и использующий язык IDL, который описывает интерфейсы взаимодействия между различными объектами. Подход CORBA связан с Object Request Broker, которые реализуют функции, несколько похожие на Proxy и Stub, описанные ранее.

Принципиальной разницей между ранним RPC и объектным RPC является тот факт, что объекты инкапсулируют не только местонахождение, но и язык реализации, среду реализации. То есть в рамках подхода брокеров объектных запросов сервер получает указания о вызове заданного метода для заданного объекта. Брокер находит, получив указания о вызове метода, первый свободный сервер, изначально неизвестный, и тот объект, который может реализовать этот вызов, осуществляет вызов указанного метода посредством использования интерфейса этого объекта и возвращает результат клиенту. При этом важно, что клиент не представляет себе ни языка, ни платформы (т. е. операционной системы), что очень важно для подхода CORBA, этот подход нейтрален относительно операционной системы. Клиент не знает ни языка, ни платформы, где расположены запрашиваемые объекты. По сути, отвечает первый свободный сервер, т. е. CORBA является универсальной шиной, по которой передаются ответы на сервер и обратно. Более концентрированно взаимодействие по схеме CORBA брокеров объектных запросов как развитие объектного RPC представлено на рис. 9.8. Вызов методов осуществляется для сервера, и размещение информации на клиенте происходит посредством брокера объектных запросов, который представляет собой универсальную шину взаимодействия и инкапсулирует логику работы по поиску свободного сервера и передаче параметров от клиента серверу и результата от сервера к клиенту.

Рис. 9.8. Клиент-серверное взаимодействие по схеме COBRA

Итак, какие особенности можно выявить в объектных RPC, объектном подходе к удаленному вызову процедур, с точки зрения взаимодействии Proxy и Stub по сравнению с ранним подходом? Речь идет об объектном взаимодействии. Proxy и Stub выглядят как обычные объекты. Для клиента функция на С выглядит как локальная. Так же и объект при вызове будет выглядеть как локальный объект на клиенте. Но на самом деле этот объект осуществляет упаковку параметров и передачу их серверу. Этот процесс упаковки параметров и их передачи называется маршаллинг и является весьма существенным для. NET и Remoting, так как по сути означает передачу объекта через границу процесса.

Маршаллинг включает упаковку параметра вызова и его передачу в упакованном формате от клиента к серверу. Анмаршаллинг соответственно включает распаковку параметра вызова и передачу распакованной функции или метода серверу, который и выполняет запрос. Затем осуществляются обратный процесс упаковки ответа, передача клиенту брокером этого ответа от сервера, и клиент осуществляет распаковку результата и приложение его вызывающей процедуре. Таким образом, процедуры маршаллинга и анмаршаллинга реализованы тоже полностью в объектном виде и, в частности, включают передачу параметра вызова, ряда других параметров и позволяют осуществить нейтральное взаимодействие относительно характеристик клиента и сервера. То есть клиент ничего не знает о сервере, деталях реализации объекта на сервере. С его точки зрения, речь идет просто об обработке некоего объекта, который хранится как бы локально. А сервер ничего не знает о клиенте, просто выполняет свою функцию.

Теперь обсудим, каким образом осуществляется взаимодействие между клиентом и сервером в RPC по объектной схеме. Как Proxy, так и Stub являются объектами и реализуют в полной мере объектно-ориентированное взаимодействие параметров Operation передачи от клиента серверу и параметров Reply возвращаемого значения от сервера клиенту. При этом взаимодействие между клиентом и сервером, кроме упаковки параметров и ответов, включает, что очень важно, передачу этих параметров через границу различных процессов (1 и 2), которые выполняются, возможно, в различных ОС или на различных машинах. Напомним, что процесс упаковки называется маршаллингом, процесс распаковки – анмаршаллингом. Если перейти от традиционной схемы объектно-ориентированного взаимодействия при реализации технологии удаленного вызова процедур RPC к той технологии, которая реализуется в среде Microsoft.NET и называется. NET Remoting, станет понятно, что взаимодействие организуется очень похоже.

Каким же образом осуществляется взаимодействие между клиентом и сервером через границы процессов и как при этом используются так называемые домены приложений? Рассмотрим это более подробно. При выполнении некоторой программы, написанной для. NET, естественно, следуя главе, в которой речь шла о среде. NET, выполнение это происходит в среде CLR. По сути, компоненты программ, которые реализуются и выполняются в этой среде, оттранслированы в код виртуальной машины. Microsoft Intermediate Language, зависящая от платформы, функционирует в терминах этого языка на той самой виртуальной машине, которая называется CLR машина. При этом загрузчик программы сначала создает хост CLR, по сути, экземпляр виртуальной машины и приложение машины, в которую по умолчанию загружаются сборки, необходимые для выполнения этой программы, и затем осуществляется передача управления этому процессу. В некоторых случаях в одном процессе может сосуществовать несколько различных доменов приложений. Среда CLR – виртуальная машина. NET может поддерживать независимое выполнение программ одного процесса в рамках нескольких доменов приложений. На рис. 9.9 представлен процесс, который на уровне операционной системы реализован в архитектуре приложений 32-разрядной машины Windows. При этом на уровне. NET осуществляется создание хоста CLR, в рамках которого могут функционировать в одном процессе несколько доменов приложений. Далее соотношение между процессами и доменами приложений выглядит следующим образом. В рамках одного и того же компьютера, скажем CLR, могут функционировать несколько процессов в архитектуре той же Windows 32. В каждом из них может быть также не один домен приложения, а несколько. Другой компьютер – это может быть сервер или другой клиент – также может иметь один или несколько процессов Windows 32, внутри которых также может быть несколько (в данном случае три) домена приложений.

Рассмотрим, каким образом осуществляется работа с удаленными объектами, расположенными на сервере? Со стороны клиента это выглядит точно так же, как и в среде. NET. Существует четкое разделение на взаимодействие по имени и взаимодействие по ссылке (Value и Reference). Если мы вспомним систему CPS, систему типизации, которая реализована для. NET, то увидим, что в рамках этой системы типизации существует изначальное четкое разграничение на две большие категории типов – Reference и Value. И обращение с объектами, обработка объектов этих больших категорий происходит различными способами. Напомним, что объекты классов категории Value, например, хранятся в стеке, при копировании создается физическая копия объекта, создается еще один объект стандартного размера, скажем, 4 или 2 байта, в зависимости от типа объекта. Он имеет фиксированный размер, и осуществляется физическое копирование значения. Если рассматривать объекты типа Reference, то осуществляется копирование ссылки, а не самого значения. Размер объекта, который имеет тип ссылку, изначально не определен, и на самом деле речь идем о том, что есть указатель на некую область памяти. Хранится в динамической памяти объект этого типа, т. е. взаимодействие между такого рода объектами, или маршаллинг, также происходит различными способами. То есть в. NET существует подход, который называется Marshal by Value и Marshal by Reference. Рассмотрим основные различия между этими подходами, а также их реализацию.

Рис. 9.9. Домены приложений в Windows

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

Итак, маршаллинг по значению разумен, целесообразен в тех случаях, когда, так же как и в случае объектов типа значения, речь идет о достаточно простых объектах – целочисленных, булевых или о тех объектах, которые редко претерпевают изменения во времени. Маршаллинг по ссылке предполагает передачу от сервера к клиенту параметров вызываемого метода, а не самого объекта. И методы объекта вызываются на стороне сервера. В случае маршаллинга по значению вызываются на стороне клиента, в случае маршаллинга по ссылке – на стороне сервера. В отношении маршаллинга по ссылке и по значению можно отметить следующую специфику: объект содержит ссылки на системные ресурсы, которые специфичны либо для процессора, либо для компьютера. Также объект содержит ссылки на большое количество других объектов на стороне сервера либо часто изменяет свое состояние. Если речь идет о маршаллинге по ссылке, то этот подход предпочтителен для сложных специфичных объектов конкретного процесса или компьютера, для объектов с большим количеством ссылок или для объектов, которые часто изменяют свое состояние. При работе с корпоративными системами также целесообразен маршаллинг по ссылке.

Рассмотрим явное создание объекта как вариант клиент-серверного взаимодействия по технологии Remoting. Здесь мы уже видим в примере кода, что явно используется метод маршаллинга объекта класса Remoting Services. То есть в пространстве имен. NET существует класс Remoting Services, который имеет ряд методов, связанных с реализацией объектов и передачей параметров от клиента серверу различными способами. Итак, при явном создании объекта осуществляется прежде всего создание некоего объекта, вызов конструктора, оператор NEW для объекта Obj класса Server Object. Осуществляется вызов конструктора без параметра, и создается новый объект. После чего осуществляется маршаллинг с явной передачей именно этого объекта путем вызова метода Marshal класса Remoting Services с параметром Obj. Таким образом, объект на сервере создается явно. Он будет иметь имя srv_obj. И объект на сервере существует до тех пор, пока на него имеются ссылки. Реализация уничтожения ссылок явным образом осуществляется посредством вызова специального метода, того же класса Remoting Services, который называется Disconnect. При этом необходимо явно указывать, что речь идет об объекте Obj.

При явном создании объекта клиент может получить ссылку на этот серверный объект двумя способами – используя либо метод Get Object класса Activator (здесь необходимо преобразование к классу Server Object), либо оператор type of, который определяет объект по типу. Для этого явно указывается имя объекта, которое было ранее определено и его местоположение, – Localhost. Другой подход связан с определением типа объекта и явным указанием этого объекта таким же образом, как и в предыдущем методе, а затем созданием объекта явным образом посредством конструктора Server Object.

Далее следует рассмотреть вопрос явной активизации объектов на сервере. Момент создания объекта в этом случае определяется сервером. При этом речь идет уже о передаче не экземпляра объекта, а его типа. То есть имя присваивается не экземпляру, а типу. И для обработки каждого вызова удаленного метода может создаваться собственно новый экземпляр объекта. При этом используется метод Single Call. Здесь явно указывается имя объекта srv_obj и осуществляется вызов метода Register Service Type, т. е. определенный метод реализации сервиса на основе класса Remoting Configuration. Нужно сказать, что все вызовы удаленного метода могут обрабатываться одним и тем же объектом, сервером, при этом используется метод Single в отличие от предыдущего Single Call. Клиент работает с удаленным объектом полностью аналогично предыдущему случаю. Другая форма взаимодействия между клиентом и сервером основана на активизации объектов клиента. При этом момент создания объекта определяется уже не сервером, а клиентом, и на сервере в этом случае может быть создано много объектов. В этом случае сервер объекта уникально однозначно определяется явным указанием имени компьютера. Мы видим, что осуществляется передача параметра методу Register Activated Service Type, т. е. осуществляется регистрация указанного типа сервиса с параметром того самого объекта типа «сервер», к которому реализуется обращение. При этом, по сути, мы работаем в том же пространстве имен Remoting с тем же классом Remoting Configuration, но другим образом определяем конфигурацию взаимодействия между клиентом и сервером. При активизации объектов клиентом на сервере клиент должен вначале осуществить регистрацию типа объекта с учетом его расположения на сервере, а затем создать объекты, для каждого обращения создается объект (Proxy), который осуществляет инкапсуляцию методов на сервере. Итак, мы используем метод Register Activator Client Type класса Remoting Configuration с явным указанием, что тип объекта расположен на сервере, и явным указанием этой машины. После чего для каждого вызова создается свой объект класса Server Object. По сути, это не совсем объекты, это Proxy. Но для каждого из них осуществляется свой вызов оператора New.

Последнее, что будет обсуждаться касательно Remoting, – это процедура сборки мусора. Вообще, процедура сборки мусора крайне важна для больших объектных систем. Здесь речь идет о том, что существует большое количество объектов типа «ссылки». Следует напомнить, что в. NET, в CTS – системе типизации, существуют два больших подкласса объектов – ссылки и значения. Если рассматривать корпоративные системы, то очевидно, что для реализации распределенных приложений, которые используют большое количество сложных объектов, а вместе с тем эти объекты имеют сложную структуру и динамически взаимодействуют друг с другом, целесообразно использовать типы-ссылки. В связи с этим часто возникают ситуации, когда не вполне корректно уничтожается информация о значении самого типа-ссылки при уничтожении собственно объекта этого типа. То есть не всегда разрывается связь между именем и значением объекта, на которое указывает ссылка с этого имени. Для уничтожения такого рода висячих ссылок, т. е. ссылок, указывающих на некорректную область памяти, которая уже освобождена и не содержит значения типа «ссылки», существует стандартный процесс сборки мусора.

По сути, эта технология характерна для большого количества программных инструментов, программных сред и реализована впервые достаточно давно, в частности одни из первых реализаций были связаны с языками функционального программирования, которые также поддерживают динамические структуры данных (например, LISP). Естественно, в Microsoft.NET, среде, которая призвана поддерживать работу с большим количеством языков программирования, распределенных сложных корпоративных программных систем, актуальность сборки мусора существенно возрастает в связи с частой сменой состояния и значений объектов. Конечно, имеет смысл и для технологии Remoting, и для технологии, которая поддерживает определенное взаимодействие компонентов таких систем, осуществить грамотный оптимальный и достаточно эффективный подход к сборке мусора. И здесь существуют разные подходы: обычный подход к сборке мусора в целом в среде. NET и поход, который связан с реализацией механизмов на основе. NET Remoting.

Если рассматривать классический подход к распределенной сборке мусора между клиентом и сервером, ссылки через границы процессов, то нужно реализовать уничтожение объектов на сервере, на которые ссылки более не актуальны. Это происходит следующим образом: распределенный сборщик мусора подсчитывает количество ссылок на серверный объект, т. е. на тот объект, который находится на сервере, при этом, естественно, поскольку эти ссылки идут на сервер, осуществляется периодический опрос клиентов. Другой подход сводится к тому, что в. NET можно явным образом выполнить функцию сборки мусора, и программист может явно вызвать соответствующий метод, стандартно реализованный в. NET Framework.

Что касается подхода Remoting, то здесь используется механизм аренды. Существует определенный интервал времени, который определяется для каждого серверного объекта. Каждому серверному объекту ставится в соответствие объект специального вида, который имеет интерфейс лизинга. И выглядит следующим образом: существует для маршаллинга по ссылке класс, который определяется как класс Marshal by Ref Object и содержит виртуальный объект, собственно и реализующий инициализацию процедуры обслуживания сборщика мусора. При этом интерфейс лизинга внутри класса осуществляет вычисление времени аренды для каждого объекта, который поставлен в соответствие и для которого существует возможность определения и обновления срока аренды, если такая возможность предоставляется.

На этом рассмотрение реализации технологий распределенных вычислений в среде. NET завершается. Мы познакомились с общим принципом распределенных вычислений, обсудили различие между подходом с сохранением состояний и подходом без сохранения состояний, а также подходом, который связан с Loosely Coupled и Tightly Coupled моделями взаимодействия. Оценили эффективность сильно связанной и большую универсальность слабо связанной модели взаимодействия объектов. Рассмотрели эволюцию архитектур, которые связаны с объектным и дообъектным подходами обмена информацией между клиентом и сервером по технологии RPC. Общим для этих подходов является наличие Proxy и Stub как механизмов упаковки и передачи параметров между клиентом и сервером. При упаковке речь идет о маршеринге, при распаковке – об анмаршаллинге. В объектном подходе имеет место инкапсуляция объектов, т. е. изоляция технологий сред взаимодействия и конкретных языков программирования, на которых реализуются процедуры, методы или функции для клиентов и серверов.

При этом инкапсуляция осуществляется на основе модели объектного вида – это либо COM-модель, либо модель типа CORBA – брокеров объектных запросов, либо компонентная модель, в более позднем варианте представляющая собой динамическую COM-модель, на основе которой реализуется подход, связанный с Remoting. Этот подход основан на использовании жестких протоколов, которые обеспечивают большую безопасность и надежность взаимодействия между компонентами корпоративных систем и распределенных приложений. При более мягком подходе, связанном с веб-сервисами, осуществляется слабосвязанная модель взаимодействия, которая в меньшей степени связана с. NET Remoting.

Как Remoting, так и более поздние технологии, с нашей точки зрения, основаны на интерфейсе, связанном с веб-формами, и существенно его используют. Более поздние технологии – это технологии веб-сервисов, речь о которых пойдет более подробно в следующей главе, и технологии, которые связаны с подходом WCF – Windows Communications Foundations. Эти технологии призваны реализовать подходы, связанные с клиент-серверным взаимодействием на основе более открытых протоколов и объектного распределенного взаимодействия в архитектуре клиент – сервер. Речь идет о сервисно-ориентированной архитектуре и таких протоколах, как SOA, HTTP. Более подробно этот вопрос будет освещен позднее.

Глава 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.

Глава 12

Разработка корпоративной сервисно-ориентированной архитектуры по технологии WCF

Нужно отметить, что существуют и другие подходы к построению распределенных приложений. Ранее был рассмотрен подход, связанный с технологией Remoting, он может использоваться также как расширение веб-сервисов. Сейчас будет рассмотрен еще один подход, который называется Windows Communication Foundations (WCF) и является более открытым и более современным, чем Remoting. Он также предназначен для создания и использования распределенных приложений, т. е. продолжает и развивает концепцию программного обеспечения как сервисов. Рассмотрим особенности общего подхода сервисно-ориентированной архитектуры, которая независима от Microsoft или какого-то другого производителя, является международным стандартом, и реализации этой архитектуры от Microsoft. Это как раз SOAP версия Microsoft. Важными понятиями являются контракты, каналы, связывания. Далее эти элементы и их роль в технологии WCF будут рассмотрены более подробно.

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

Рассмотрим достаточно простой, но важный пример реализации сервиса, по сути, тоже веб-сервиса, на основе технологии WCF. Итак, что такое сервисно-ориентированная архитектура, SOA? Речь идет о том, что это открытый протокол или открытая среда взаимодействия приложений, которая архитектурно основана на использовании сервисов, т. е. реализует концепцию программного обеспечения как сервиса. Естественно, приложения при этом представляют собой распределенные компоненты. Сервисно-ориентированная архитектура регламентирует протоколы и методы, т. е. способы и функции, по которым осуществляется взаимодействие. В концепцию сервисно-ориентированной архитектуры укладываются и веб-сервисы, и технология Remoting, и, конечно же, технология WCF, о которой пойдет речь позднее, и ряд других технологий. Очень важны идеология и подход, связанный с нейтральностью сервисов. То есть при реализации веб-сервисов они остаются независимыми друг от друга и взаимодействуют в независимом режиме. Кроме того, сервисы являются строительными блоками бизнес-процессов, на основе которых осуществляется взаимодействие корпоративных приложений. Каждый такой блок представляет собой либо бизнес-процесс в целом, либо часть этого бизнес-процесса.

Взаимодействие в рамках сервисно-ориентированной архитектуры основано на обмене сообщениями, и эта важная характеристика во многом отличает сервисно-ориентированную архитектуру от других подобных архитектур. Протоколы и технологии взаимодействия являются открытыми: SOAP, XML и т. д. По сути, технология WCF является вариантом реализации Microsoft общей стратегии SOA – сервисно-ориентированной архитектуры, которая была разработана в том числе и корпорацией IBM. Как и другие подходы распределенного взаимодействия на платформе. NET, этот подход связан с использованием библиотеки классов. В данном случае речь пойдет о. NET Framework 3.0 и WCF. Этот подход был разработан, чтобы решить ряд важных задач, в том числе таких, как унификация существующих технологий удаленного взаимодействия приложений, сервисно-ориентированная разработка приложений, т. е. разработка приложений, реализующих концепцию программного обеспечения как сервис, и, что очень важно, кросс-платформенное взаимодействие. То есть подход WCF дает возможность взаимодействия различных платформ. При этом устраняется целый ряд препятствий между корпоративными стандартами от Microsoft, IBM, Sun и других компаний, существует организация WSI Web Service Interability, которая реализует унификацию стандартов и спецификаций взаимодействия приложений, созданных в том числе этими разработчиками. Реализация этих стандартов делает возможным сервисно-ориентированное взаимодействие, в том числе и на основе технологий WCF. Набор стандартов не является монолитным, он реализован таким образом, чтобы давать возможность разработчикам его настраивать, развивать и осуществлять реализацию приложений в достаточно гибком режиме на этой основе. Кроссплатформенное взаимодействие основано на открытых протоколах и позволяет объединить решения от перечисленных производителей на основе целого ряда подходов, связанных с веб-сервисами от Microsoft, NET Remoting, службой распределенных транзакций Enterprise Services и др.

Рассмотрим обобщенную архитектуру WCF. Важными понятиями здесь являются контракты, среда исполнения сервисов, сообщения, хостинг. Контракты определяют целый ряд аспектов взаимодействия между сервисами. При этом существует несколько видов контрактов. Скажем, DataContract, ServiceContract и ряд других. DataContract описывает параметры взаимодействия между сообщениями. MessageContract задает части сообщений в стандартном протоколе SOAP, посредством которого взаимодействуют приложения или их компоненты. ServiceConctract определяет сигнатуру методов сервиса, Policy Bounding Contract – политику безопасности взаимодействия тех протоколов, которые будут использоваться в качестве транспортных, и ряд других аспектов. Среда исполнения определяет поведение сервисов и их обработку в то время, когда осуществляется выполнение кода этих сервисов: в каком режиме осуществляется обработка ошибок, как работает инспекция сообщений, как реализована фильтрация сообщений, как происходит диспетчеризация, т. е., по сути, управление сообщениями, как задаются метаданные, как осуществляется представление метаданных, какое количество экземпляров характеризует каждый сервис. Сообщения, слой сообщений определяет возможные форматы и шаблоны обмена сообщениями в общеархитектурной схеме. Наконец, активация и хостинг определяют последовательность запуска сервисов и контекст протоколов их взаимодействия.

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

В WCF реализуются три вида контрактов: контракт сервиса (Service Contract), контракт данных (Data Conctract), контракт сообщения (Message Contract). Контракты сервисов используются для описания функциональности, которую поставляет сервис. Вместе с операционными контрактами они определяют те методы из. NET Framework, которые описывают операции, осуществляемые сервисами, и те конкретные порты, посредством которых осуществляется взаимодействие. Порты описываются на языке WSDL. Здесь мы видим, что технология WCF тесно связана с технологией веб-сервисов. Она использует тот же самый язык описания. Контракты данных описывают структуры данных, которые служат для взаимодействия сервисов. В частности, определяются типы CLR, среды выполнения Common Language Runtime и XSD, т. е. полностью описываются сериализация и десериализация – преобразование данных при передаче от клиента к серверу. Третьим типом контрактов, на основе которых осуществляется взаимодействие в рамках WCF, являются контракты сообщений. Контракты сообщений описывают, каким образом типы среды взаимодействия CLR будут преобразованы на уровне данных в сообщения протокола SOAP. При этом существует возможность гибких настроек этих сообщений в SOAP, как заголовков, так и тел сообщений. Более подробно сервисные контракты определяют интерфейсы конечных точек веб-сервиса. При этом для указания контрактов используются атрибуты Service Contract и Operation Contract, которые применяются соответственно для классов и интерфейсов и для методов веб-сервисов. Данные контракты используются в технологии WCF как при проектировании, так и при выполнении веб-сервисов. При этом на стадии проектирования определяются те классы, которые при описании веб-сервиса должны быть описаны на языке WSDL как конечные точки сервисов, указываются операции, которые будут задействованы в этих элементах.

На стадии выполнения осуществляются поиск и выполнение методов на сервере, которые связаны с активацией тех или иных сервисов. Если речь идет о Service Contract и Operation Contract, то эти атрибуты задают порядок взаимодействия. В том числе возможно как однонаправленное взаимодействие, так и дуплексное. При однонаправленном взаимодействии, которое кодируется свойствам и атрибута Is One Way, клиент получает только подтверждение взаимодействия с веб-сервисом. При дуплексном взаимодействии устанавливается полноценный двунаправленный обмен сообщениями. При этом сообщения могут посылаться как от клиента серверу, так и от сервера клиенту. Сообщения для этого снабжаются соответствующими атрибутами, такими как адрес, способ связывания и контракт: Address, Binding and Contract. В WCF это основа взаимодействия, которая кодируется аббревиатурой ABC: Address, Binding, Contract. Это является важным порядком, по сути, описанием порядка взаимодействия. При таком взаимодействии используется один и тот же транспортный протокол, при необходимости создается новый канал. При этом в дуплексных контрактах используются контракты как клиента, так и сервера.

Обсудив контракты сервисов, переходим к рассмотрению контрактов данных. Данные сервиса представлены типами CLR, с другой стороны, это внутренние типы среды выполнения Common Language Runtime, извне они поступают как описание веб-сервиса на языке WSDL. Таким образом, контракты данных являются связующим звеном между внешним WSDL и внутренним CLR представлением. Для определения контрактов данных используются атрибуты Data Contract и Data Member. При этом Data Contract используется как атрибут класса, а атрибут Data Member используется как атрибут члена этого класса, семейства или как атрибут поля. Важно отметить, что оба эти атрибута – и Data Contract, и Data Member – используются как при проектировании класса, веб-сервиса, так и при его реализации. Контракт данных обеспечивает сериализацию данных, при этом используется атрибут Data Contract Serializer. Контракты сообщений – это третий тип контрактов, определяют собственно представление сообщений в формате SOAP, т. е. то, каким образом внутренние типы CLR будут представлены в формате взаимодействия. С помощью атрибутов контрактов сообщений – это Message Contract, Message Header, Message Body Member – осуществляется управление разработчиком над представлением данных в формате SOAP. Разработчик при этом получает достаточно мощное средство управления контрактами, представлением этих контрактов. Атрибут Message Contract определяет структуру SOAP сообщения, но не определяет их содержания. То есть он не определяет, скажем, нужно ли сворачивать, архивировать тело сообщения или не нужно. Другие атрибуты используются для настройки заголовка и тела сообщения SOAP. Данный вид контрактов не используется вместе с Data Contract. При этом при использовании с Message Contract необходимо наличие только одного входящего и одного исходящего параметра, поскольку осуществляется прямое преобразование в SOAP.

На рис. 12.1 представлен пример контрактов сервиса и контрактов данных. Следующим важным понятием, описывающим взаимодействие между клиентом и сервером, являются каналы обмена данными WCF. Каналы являются средством взаимодействия сообщениями между сервисами и их потребителями, при этом каналы используются как для подготовки сообщений, так и для их доставки. Для подготовки сообщений используются так называемые протокольные каналы, а для доставки – транспортные. В этом смысле существует разделение между каналами. Для транспортных протоколов по технологии WCF используются протоколы HTTP, TCP, WebSphere MQ и др. Также осуществляется взаимодействие в формате точка-точка и так называемые именованные каналы. Существуют и сторонние реализации, при этом используется ряд протоколов, скажем FTP, SMTP, на основе протокола, который используется для доставки почтовых сообщений, UDP и ряд других протоколов, скажем, WebSphere MQ, реализованный для поддержки продуктов корпорации IBM и основанный на передаче сообщений. По сути, речь идет о стеке каналов, т. е. в каналах существует несколько уровней: транспортный и протокольный. Протокольный уровень находится на более высокой позиции в стеке, чем транспортный. Протокольные каналы служат для осуществления транзакций, т. е. взаимодействия между клиентом и сервером посредством элементарных операций, и для шифрования. Таким образом, архитектура WCF дает достаточно высокую степень гибкости при настройке взаимодействия между сервисами и клиентами, которые запрашивают эти сервисы.

Рис. 12.1. Описание контракта сервиса и контракта данных

Для каналов WCF характерны три вида взаимодействия: 1) однонаправленное; 2) дуплексное или полноценное двунаправленное, когда и клиент, и сервер могут посылать друг другу сообщения; 3) взаимодействие по типу запрос – ответ. При рассмотрении контрактов достаточно подробно обсуждались эти виды взаимодействия, в частности однонаправленное и дуплексное. Для реализации этих шаблонов используется ряд интерфейсов, которые упоминались в примерах кода, в том числе такие как ISessionChannel, IInputSessionChannel, IDuplexSessionChannel, IRequestSessionChannel, IReplaySessionChannel, т. е. по сути интерфейсы реализуют каждое из этих конкретных видов взаимодействия. Кроме того, существует единый базовый интерфейс ICommunicationObject, который поддерживает взаимодействие всех классов объектов, участвующих в канальном взаимодействии. Этот общий интерфейс является неизменным для каналов, а также фабрик каналов и механизмов слушания запросов на сервере и используется для реализации всех механизмов взаимодействия. Таким образом, стек каналов представляет собой многоуровневый стек взаимодействия, включает транспортный и протокольный уровни, и может состоять как из одного канала, так и из нескольких. В этом смысле важным является определение «связанный» или Binding. Нужно сказать, что это понятие весьма важно для объектных систем вообще и в математических формализациях с объектными моделями имеет первостепенное значение, скажем, в теории конечных последовательностей в форме -исчисления, имеет реализацию в форме связывания переменной со значением. В данном случае под связыванием понимается заранее сконфигурированный стек каналов взаимодействия по технологии WCF. При этом с помощью связывания подход WCF инкапсулирует различные сценарии взаимодействия. Например, Basic HTTP Binding заранее сконфигурирован для взаимодействия со стандартными веб-сервисами по технологии SMX. WSHTTP Binding – для более сложного взаимодействия Web Service Addressing. Ряд других вариантов взаимодействия на основе связывания образует стек каналов, который использует также специализированные элементы, называемые элементами связывания. Всего в WCF определено и может быть использовано до девяти типов связывания. Это, по сути, предопределенные конфигурации, которые используют протоколы HTTP, TCP и др. Если ни одна из этих стандартных конфигураций не удовлетворяет разработчиков, есть возможность создания собственных конфигураций на основе существующих.

Взаимодействие между каналами с использованием механизмов связывания имеет достаточно сложную схему, которая логически представлена в форме следующего алгоритма. Прежде всего выявляется наличие необходимости интероперабельности или взаимодействия с другими платформами. Здесь оно представлено ромбом с надписью «Требуется интероперабельность?». При этом в случае позитивного ответа мы перемещаемся вниз, в случае негативного – вправо. Если интероперабельность требуется, то нужно уточнить, какой именно уровень интероперабельности будет использован: общий, на основе Basic HTTP Binding или более сложный, с поддержкой дуплексного взаимодействия, тогда используется WS Dual HTTP Binding. Если требуется повышенный уровень безопасности, будет использоваться еще один уровень связанности. Таким образом, все девять типов связывания присутствуют в схеме.

Локальное связывание использует подход NET Named Binding, а также очереди на основе MSNQ, с поддержкой расширений, в том числе на основе сервисно-ориентированных продуктов сторонних производителей. Могут быть также организованы сети по принципу точка-точка, и тогда используются механизмы, связанные с NET TCP Binding. Кроме того, может использоваться подход, связанный с NET Pear TCP Binding. То есть может быть использован целый ряд априори сконфигурированных сценариев взаимодействия в рамках этой технологии. Как упоминалось ранее, могут быть использованы дополнительные сценарии на основе существующих, полученные посредством их развития. Важным средством взаимодействия между клиентом и сервером является так называемый сценарий поведения. По сути, это класс, который реализован в рамках технологии WCF, существует в соответствующем пространстве имен и оказывает влияние на поведение системы во время выполнения приложения.

В WCF существуют следующие виды сценариев использования. Это сервисный сценарий или сценарий сервера. Он работает на уровне сервиса, реализован на сервере, имеет доступ ко всем конечным точкам сервера и влияет на поведение системы во время выполнения. Реализация этого сценария по принципу передачи сообщения от одной точки к другой. Кроме того, существует возможность создания пользовательских сценариев использования. Сценарии использования, которые отвечают за сервисы, поддерживают обработку транзакций, авторизацию пользователя на сервере, создания пользователями объектов и изменения этих объектов, а также аудит действий пользователя. Другим классом сценариев поведения является сценарий конечных точек или NetPoints. Здесь работа осуществляется на уровне конечных точек, реализуется инспекция, т. е. осмотр и обработка сообщений, которые поступают на сервер. Еще один сценарий – это Callback, сценарий обратного вызова, аналог сценария, который реализуется для сервера, сценария сервисного, и функционирует на клиенте в режиме дуплексного, т. е. полноценного, взаимодействия между клиентом и сервером. Следующий вид сценариев – сценарии операционные, они используются на уровне отдельных операций и управляют сериализацией, т. е. преобразованием форматов данных при передаче от клиента серверу, и наоборот, а также потоком транзакций, т. е. элементов взаимодействия между клиентом и сервером. Сценарии взаимодействия конечных точек отвечают за обрботку данных до и после того, как они попадаются на обработку конечному методу. При этом на клиенте выделяются следующие три вида сценариев поведения: связанные с инспекцией параметров, сообщений и форматирования сообщений. При инспекции параметров данные исследуются, анализируются и преобразуются до их сериализации в XML-представление. При форматировании сообщений данные исследуются и преобразуются во время конвертации в XML в ходе преобразования. И, наконец, при инспекции сообщений представление данных в формате XML преобразуется при трансляции во внутреннее представление Microsoft.NET. При этом на сервере, кроме упомянутых сценариев, реализуются еще два вида специфических для серверной части сценариев. Это выбор операции, т. е. метода, и вызов этой операции. В первом случае рассматривается и анализируется входящее сообщение и происходит определение метода для обработки этого сообщения, того метода, который соответствует этой операции. Во втором случае осуществляется обслуживание этого вызова, т. е. обработка этой операции тем самым методом, который предназначен для нее на сервере.

Рассмотрим некоторые из сервисных сценариев поведения. Заметим, что они определяются соответствующими классами WCF, которые реализованы в. NET. Введем понятие меры параллельности. Это число задач, одновременно выполняемых тем или иным сервисом. То есть таких задач, которые можно понимать как отдельные задачи или отдельные работы. Под временем выполнения задачи будем понимать то время, которое сервис затрачивает на одну задачу. Производительностью будем считать число задач, которые сервис выполняет в единицу времени. Увеличить производительность можно одним из двух способов: либо уменьшить время выполнения, либо увеличить меру параллельности. При этом для задач существуют сценарии поведения, которые называются Instance Context Mode и Concurrency Mode и реализуют соответственно две эти стратегии, увеличивают количество экземпляров сервиса или количество потоков на экземпляр сервиса. Первый класс Instance Context Mode определяет, какое количество экземпляров сервиса будут обслуживать запросы. При этом возможны три режима выполнения: режим Single – единственный экземпляр сервиса для всех запросов, режим Percall – для каждого запроса создается свой отдельный экземпляр сервиса, режим Persession – для каждой сессии создается отдельный экземпляр сервиса. Другой подход связан с числом потоков на экземпляр сервиса и имеет возможные значения: Single, Reentrant, Multiple. Single определяет, что единственный поток имеет доступ к классу сервиса, он может покидать сервисный класс, но обязан вернуться и продолжить операцию. Режим Multiple реализует многопоточный доступ к одному и тому же сервису, а при режиме Reentrant только один поток имеет доступ к классу сервиса. Еще одним важным сценарием поведения является реализованный как класс WCF сценарий Service Meta Data Behaviour, который позволяет публиковать метаданные о сервисе, т. е. все параметры, которые его определяют. Достаточно сказать, что все описание в WSDL-формате может публиковаться этим классом. При этом метаданные предоставляются сервисом посредством конечной точки – Metadata Exchange. То есть существуют специальный формат данных и специальное средство предоставления метаинформации о сервисе.

Как упоминалось ранее, важным средством взаимодействия клиента и сервера при реализации технологии WCF являются транзакции. При этом сценарии поведения на основе этих транзакций могут быть реализованы различными способами. Транзакции бывают двух типов: многошаговые бизнес-процессы и так называемые короткие транзакции, которые, в отличие от первого типа, завершаются достаточно оперативно и затрагивают относительно небольшое количество объектов и связей, зависимостей или ограничений целостности. WCF поддерживает второй вид транзакций, короткие транзакции. Рассмотрим, для чего используется атрибут Operation Behaviour и его свойство Transactionscope Requirement. Это свойство определяет, будет ли операция выполняться в режиме так называемых транзакций, или будет ли транзакция завершаться автоматически (Transaction Scope Complete) при окончании работы метода, или же ее можно будет завершить. В таком случае потребуется поддержка механизма взаимодействия, который реализуется на основе сессий. Важным аспектом взаимодействия между клиентскими и серверными частями приложений по технологии WCF является сериализация и десериализация. Сериализация – это процесс преобразования графа объектов в поток байтов, т. е. в последовательный поток формата XML Info Set. Таким образом, сериализация является эффективным способом сохранения состояния объектов, которое может храниться в базе данных или файле. В WCF состояние объектов хранится исключительно в XML Info Set. Особенность в том, что здесь, в отличие от XML, не задается конкретного формата данных. Используется процесс кодировки, преобразования сообщения WCF в поток байт, во внутреннее представление процесса, и существуют различные виды кодировки, которые доступны в WCF. Всего таких представлений пять. Это двоичный формат, текстовый формат, формат Message Transmission Optimization Mechanism (MTOM), формат, связанный с Java Script, Java Script Object Notation, и формат POX, Plain Old XML, связанный с традиционным XML. При этом выбор кодировки зависит от конкретной ситуации, от конкретных требований ПО по надежности, производительности, интероперабельности, масштабируемости и т. д.

Рассмотрим методы сериализации WCF в сравнении. Произведем сравнение механизмов сериализации, которые реализуются процедурами Data Contract Serializer, Net Data Contract Serializer, XML Serializer и Data Contracts JSON Serializer. Стандартным сериализатором является первый из них, Data Contract Serializer. Он преобразует внутренние типы WCF во внешнее представление XSD, которое является платформенно-независимым. То есть, по сути, не несет связанных с. NET элементов и поэтому может использоваться для взаимодействия со сторонними приложениями, скажем, с приложения, реализованными на основе Java. Для того чтобы этот сериализатор работал с классом, класс необходимо снабдить атрибутом Data Contract, а свойство или поля, которые используются для сериализации, необходимо снабдить атрибутом Data Member. Следующий вид сериализации, Net Data Contract Serializer, близок к первому, но отличается возможностью добавления информации о внутренних типах CLR к тем возможностям, которые имеются у сериализатора по умолчанию. В отличие от первого вида, он используется для. NET приложений и при этом осуществляет взаимодействие между частями этого приложения, причем только одного. NET приложения. Третьим классом, который отвечает за сериализацию, является XML Serializer. Это стандартный сериализатор. NET, который появился еще на уровне Framework 2.0 и сохранился в Framework 3.0. Он позволяет реализовать стандартный механизм сериализации, т. е. работать со стандартными типами. NET, имеет возможность настройки XML-представления, позволяет настраивать выход XML, который генерирует сервис, и работает со стандартными сервисами формата ASP.NET. При этом существуют три основных подхода к использованию данного вида сериализации. Можно использовать стандартную сериализацию, а также атрибуты, связанные с XML: XML Attribute, XML Element. Кроме того, можно использовать интерфейс IXML Serializer, который позволяет организовать взаимодействие с XML-форматом. Еще один важный вид сериализации Data Contract JSON Serializer, который поддерживает стандартную нотацию объектов в формате Java Srcipt.

Важным понятием, характерным для технологии WCF, является понятие host или servicehost. По сути, данное понятие определяет процесс, который несет ответственность за обработку и контекст выполнения веб-сервиса. Это процесс операционной системы, который управляет выполнением сервиса и контекстом, отвечает за старт сервиса, остановку этого сервиса, а также предоставляет важные базовые функции управления сервисом. Хостом сервиса WCF может выступать любой процесс ОС. Такие приложения, как Internet Information Service, Windows Process Activation Service, имеют встроенную поддержку хостинга, т. е. внутреннюю инфраструктуру, которая этот хостинг реализует. Кроме этих подходов можно использовать другой сервис, любой Windows Service, а также любое приложение с пользовательским интерфейсом или консольное приложение для того, чтобы осуществить поддержку хостинга. В зависимости от того, что именно является хостом сервиса, его конфигурация и настройка осуществляются в целом единообразно. Выбор хостинга зависит от требований к приложению, его быстродействию, устойчивости, масштабируемости и т. д. Каждый хост WCF требует реализации трех функциональных элементов: это объект класса ServiceHost, конечная точка и запуск прослушивания сообщений на сервере или процедуры listen.

Перейдем к более подробному описанию среды хостинга Windows (Process) Activation Services или W(P)AS, которая является стандартной средой хостинга (рис. 12.2). Она встроена в новые операционные системы – Windows Vista и серверную ОС Windows Server 2008, поддерживает ряд возможностей, которые раньше были доступны только через Internet Information Service. W(P)AS позволяет размещать сервисы в гибкой среде, которая не требует обязательного использования протокола HTTP. Предположим, что есть однонаправленное взаимодействие с некоторым сервисом и конечный пользователь этого сервиса, который довольно часто находится в отсоединенном от сервиса состоянии. В данном случае в качестве транспортного уровня лучше использовать MSMQ, чем HTTP, который не сохраняет состояния. Или, допустим, у сервиса много клиентов, с которыми он часто обменивается небольшими по размеру сообщениями. В этом протокол HTTP также подходит в меньшей степени, и выгоднее использовать протокол TCP. При этом желательно поддерживать множественность протоколов. Такую возможность дает W(P)AS, эта среда многопротокольная, здесь не требуется обязательное использование протокола обмена HTTP, т. е. осуществляется возможность работы в гибкой среде. Эта возможность поддерживается за счет реализации шаблона Listener Adapter, который абстрагирует слушателей, осуществляющих взаимодействие с процессами, от клиента, от процессов управления.

Рис. 12.2. Схема реализации хостинга в среде W(P)AS

На рис. 12.2, где показана схема взаимодействия процессов различных протоколов с хостом процесса, т. е. с реализацией хостинга на основе технологии W(P)AS, видно, что могут использоваться различные протоколы взаимодействия, и с точки зрения хоста безразлично, каким образом, по какому конкретно протоколу организовано это взаимодействие. Возможно и взаимодействие точка-точка, и взаимодействие по протоколу, который не сохраняет состояние, HTTP, и взаимодействие по TCP-протоколу, и взаимодействие по протоколу, скажем, MSMQ. Рассмотрим небольшой пример веб-сервиса в рамках технологии WCF, который реализует функции калькулятора.

Рассмотренный в предыдущей главе (см. рис. 11.1) пример задействовал всего одну функцию – вычисление квадратного корня. В данном примере будет рассмотрен достаточно простой калькулятор, который осуществляет функции сложения, вычитания, умножения, деления (рис. 12.3). Он заимствован из стандартных примеров кода Microsoft (эти примеры расположены на Micfosoft.Servicemo del. Samples), реализован как интерфейс, который называется ICalculator.

Рис. 12.3. Описание сервиса WCF, реализующего функции калькулятора

На вход каждой операции, которая представляет собой контракт-интерфейс, снабженный атрибутом Service Contract, и в каждой операции мы используем атрибут Operation Contract. Каждая операция представляет собой метод, на вход которого поступают два значения типа Double – число с плавающей точкой двойной точности, выход тоже представляет собой число типа Double. Рассмотрим, каким образом реализуется класс, который выполняет этот контракт. Мы указываем, что это класс общедоступный Calculator Service и использует тот интерфейс, который был ранее определен, определенный нами интерфейсный контракт ICalulator. Контракт реализует соответствующий интерфейс и не требует никаких дополнительных атрибутов. Фактически реализуются те же операции, возвращаются значения суммы, разности, произведения или частного. При этом осуществление вычислений реализуется достаточно наивно, т. е. нет проверки, скажем, на нулевой делитель и других, возможно, важных проверок, которые потребовались бы. Здесь осуществляется просто обращение к стандартным функциям, и будет, видимо, задействовано стандартное исключение CLR, при ошибке, скажем, деления на ноль или другой арифметической ошибке, которая возникнет в случае исключения того или иного рода. Продолжим обсуждение примера – веб-сервиса, который реализует простейший калькулятор. Кроме того, что мы создали описание кода в форме интерфейса и контракта, мы должны реализовать конфигурационный файл, который будет расположен на сервере. Это, естественно, XML-подобное описание, и оно достаточно громоздкое.

В данном случае оно представлено на рис. 12.4. Что характерного в нашем описании сервиса с этой точки зрения можно заметить? Прежде всего, здесь описана конечная точка, через которую ведется взаимодействие. Связывание определено как WSHTTP Binding, т. е. мы используем тип связывания с учетом протокола HTTP. При описании веб-сервиса мы должны определить наше ABC. В рамках выбранной сервисной модели на основе пространства имен System должно быть описано определение, связанное с описанием Calculator Service, который определен ранее, реализует интерфейсный контракт и расположен внутри пространства имен Micfosoft.Servicemodel.Samples. При этом определяется конфигурация поведения Calculator Service Behaviour, а именно какой адрес интерфейса поставляется хостом, где хранится этот интерфейс. Далее указывается необходимый адрес, привязка ABC, которая имеет вид HTTPBinding, и, наконец, интерфейсный контракт, т. е. тот самый интерфейс ICalculator, который у нас описан. Особенности использования связывания типа wsHttpBinding состоят в том, что в качестве протокола взаимодействия используется протокол HTTP, который не сохраняет состояния, и используются стандартные протоколы веб-сервисов WS для организации взаимодействия между клиентом и сервером с точки зрения адресации, безопасности. Сервисы WCF не осуществляют экспорт своих метаданных по умолчанию при такого рода связывании. Для этого сервису необходимо явно указать точку обмена метаданных в виде Metadata Exchange, ее конфигурация явно присутствует в файле конфигурации: явно указаны ABC адрес, связывание и контракт. Вот такое небольшое описание кода завершает наш сервис.

По результатам реализации сервиса осуществляется автоматизированная генерация кода для клиента, которая выполняется при помощи утилиты SWSUtil.exe. Некоторые фрагменты реализации этого кода (рис. 12.5), представляющие собой основные элементы этого кода, выглядят следующим образом: в этом описании присутствуют интерфейсы, которые называются ICalculator и ICalculatorClient. Дано описание класса ICalculatorClient, все, что касается его конечных точек с точки зрения адресов и основных функций, которые он реализует. Функции add, substract, multiply, divide, которые реализованы для этого интерфейса.

Рис. 12.4. Файл конфигурации WCF-сервиса

Заканчивая описание технологий WCF, хочется отметить, что эта технология достаточно зрелая, связана во многом с ядром Indigo, с достаточно поздними реализацией ОС: это прежде всего Windows Vista, Windows Server 2008, и здесь реализуется достаточно открытое по сравнению, скажем, с технологией Remoting, взаимодействие между клиентом и сервером. Как мы видели, существует большое количество возможных протоколов взаимодействия, которые прозрачным образом инкапсулируются в технологии W(P)AS, возможны взаимодействия как по протоколу HTTP, так и по протоколу TCP, MSNQ и т. д. При этом поддерживается взаимодействие не только с приложениями, разработанными на основе технологии. NET, но и на основе целого ряда других технологий. Центральным понятием является понятие хостинга, это реализация процесса, которая отвечает за обработку контекста выполнения сервиса. Принципиально важны процессы преобразования графа объектов в формат XML и обратно, сериализация, десериализация. Существует большое количество сценариев для управления потоками данных как на клиенте, так и на сервере, при этом осуществляется выбор вида данных, которые взаимодействуют, это управление транзакциями, управление безопасностью и т. д. Существует большое количество видов связывания. Для того чтобы осуществить взаимодействие, используется схема ABC, адрес, связывание, контракт. Применяется девять типов связывания, которые зависят от необходимости обеспечить интероперабельное взаимодействие, степень безопасности, вид взаимодействия с учетом используемого протокола, с использованием вида сетевого взаимодействия в его конкретизации: требуется ли связь точка – точка или локальное соединение и т. д. Связь между клиентом и сервером осуществляется на основе каналов, которые представляют собой стек протоколов на основе единого интерфейса ICommunicationObject, каналы при этом делятся на транспортные и протокольные и подразумевают как однонаправленное взаимодействие, так и гибкое взаимодействие по двунаправленной дуплексной схеме. Контракты в WCF имеют троякое представление – для сервисов, для данных и для сообщений и являются важной частью обеспечения взаимодействия между клиентом и сервером по схеме ABC. WCF – это Microsoft-версия реализации стратегии сервисно-ориентированной архитектуры, реализации программного обеспечения как сервиса, она поддерживает все необходимые классы. NET Framework, т. е. большое количество базовых операций и атрибутов по взаимодействию клиента и сервиса, поддерживает технологию Remoting и другие технологии Microsoft, а также дает возможность взаимодействия по открытым протоколам SOAP и HTTP с программным обеспечением других производителей, в том числе на основе стандартизованного языка обмена сообщениями WSDL на основе протокола XML.

Рис. 12.5. Код клиентской части WCF-сервиса

Глава 13

Разработка компонентных корпоративных систем

Эта глава посвящена компонентному программированию, компонентной разработке программных систем, в том числе и корпоративных, и разработке офисных приложений. Как уже говорилось, одним из важных аспектов идеологии. NET является компонентно-ориентированная разработка, которая понимается как развитие объектно-ориентированной парадигмы. Когда обсуждались открытые системы, упоминалось, что компонентный подход достаточно важен при разработке больших открытых систем на основе стандартных протоколов обмена информацией, поскольку в этом случае достаточно легко открываются и используются возможности адаптации, коррекции, развития, расширения программных систем путем изменения относительно небольшой доли кода, заключенного в критически важных компонентах приложения. Компоненты могут разрабатываться в рамках подхода. NET, на разных языках, людьми в географически разных местах и в итоге стыковаться, собираться в приложение. При этом во многом, если говорить о подходе, связанном с. NET, понятие «компонент» близко понятию «сборка». Ниже будет рассмотрена структура сборки, процесс ее дизассемблирования, перевод из языка Microsoft Intermediate Language – промежуточного ассемблера высокого уровня – в язык программирования, например C#. Будет показано, насколько хорошо это делает. NET, а также как выглядят метаданные сборки – те объекты и системные ресурсы, которые требуются компоненту для существования. Все это находится внутри компонента. Необходимо напомнить еще раз, что компонент – это самодостаточная единица с точки зрения развертывания и встраивания в полномасштабное корпоративное приложение.

Вторая тема, которая будет рассмотрена, – это офисные приложения и их разработка на основе Visual Studio Tools for Microsoft Office, вернее, for Microsoft Office System, потому что Microsoft Office – это с недавних пор также платформа, некий базис, на основе которого можно строить свои приложения. И это достаточно важный аспект корпоративных систем, поскольку современные версии Microsoft Office позволяют вести коллективную работу над документом, визировать документ, вести распределенную работу с общим репозиторием, публиковать изменения в Интернете и т. д. На уровне Microsoft Office 2005 будет рассмотрено, до каких технологий и возможностей развилась эта платформа и какие у нее появились возможности. Следует еще раз подчеркнуть, что рассматриваемые офисные приложения понимаются как надстройка над стандартом Microsoft Office, вернее, даже корпоративной версией Microsoft, который сам по себе уже является платформой для корпоративной работы с документами и создания корпоративных приложений.

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

Будет описано, насколько связаны понятия компонента и сборки, каким образом происходит формирование сборки, как обеспечивается взаимодействие сборок между собой, как обеспечивается безопасность приложений при построении их на основе компонентного подхода в рамках идеологии Microsoft.NET. Будет обсуждаться, каким образом происходит развертывание приложений, построенных из компонентов, как строятся интерфейсы, и, кроме того, будет говориться о различных компонентных моделях, прежде всего о моделях на основе подхода. NET, и моделях, связанных с развитием компонентно-объектной модели, COM-модели. Кроме того, будут обсуждены возможности других компонентных подходов, достаточно раннего подхода CORBA, связанного с брокерами объектных запросов, универсальной шины для взаимодействия между объектами. Будет говориться о подходе, разработанном корпорацией Sun Microsystems, который называется Java Beans, или Enterprise Java Beans, и тоже позволяет строить корпоративные приложения на основе компонентов.

Итак, компонент – это структурная единица прикладной программной системы с четко определенным интерфейсом и способом взаимодействия с другими элементами приложения. При этом компонент, несмотря на то что изолирован, во многом выполняет задачу, характерную только для него, работает в среде и использует ряд ее механизмов. Если говорить о. NET, то среда называется Common Language Runtime – среда времени выполнения. И все зависимости и взаимосвязи компонента с программной средой должны быть полно, четко и недвусмысленно описаны в рамках интерфейса. В целях повторного и многократного применения разумного подхода вполне возможным является использование одного и того же компонента, с небольшими вариациями, в разных ролях, в разных соотношениях относительно других компонентов. Поэтому один компонент может иметь несколько различных интерфейсов, т. е. играть в системе разные роли. Ну скажем, сценарий входа в систему для различных пользователей внешне выглядит похоже, но с точки зрения процедур, действий, которые выполняются при входе в систему, и тех полномочий по доступу, которые открываются после корректного входа, конечно, следует соотносить это общую процедуру входа с ролями пользователей, будь то администратор, привилегированный пользователь, аудитор системы и т. д. Этот интерфейс, его описание, называется интерфейсным контрактом или программным контрактом для компонента. Ранее уже говорилось о контрактах, в частности о контрактах данных, когда обсуждалась технология Windows Communications Foundations, но на самом деле, если говорить о компонентах в принципе, взаимодействие организовано очень похожим образом.

Важно отметить, что для каждой операции компонента имеется набор условий, необходимых для корректного начала его работы и корректного ее завершения или, как говорят, предусловия и постусловия. По сути, компонент, или модуль, можно рассматривать как некоторую процедуру или с математической точки зрения – некоторую функцию, которая имеет, как и всякая функция, область определения, область значения, вход и выход, а также ограничения на диапазон входа и выхода. Здесь, в случае интерфейсного контракта, также имеются предусловия и постусловия, которые описывают возможности его операций. Предусловие операции должно быть выполнено при ее вызове, иначе сложно гарантировать корректность результатов выполнения этого компонента, операций в компоненте. Постусловие обеспечивает сам компонент. Если он корректно отрабатывает, то обеспечивается выполнение истинности постусловия. То есть ответственность за корректность состояния по завершении работы компонента возлагается прежде всего на разработчика этого компонента, конечно, при корректном понимании структуры программной системы. В случае корпоративной системы эта структура довольно сложна. Таким образом, постусловие определяет, какие из ее результатов можно считать корректными. В объектно-ориентированном подходе часто говорится о модулях, т. е. о некоторых самостоятельных единицах программного кода, нацеленного на выполнение одной специфичной операции. Но если говорить о корпоративных системах, модуль понимается более широко – как программная единица, которая решает целый ряд взаимосвязанных задач. Это может быть, например, модуль основных средств, модуль учета и управления и планирования основных средств в рамках корпоративной системы класса ERP, Oracle Business Suit.

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

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

Например, в группе компаний «Итера» в свое время была реализована система хранения изображений, которая использовала те DLL, которые отвечали за распознавание текста и стандартное его сканирование.

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

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

Конечно, в исходной системе необходимо соблюсти интерфейсы с этим компонентом, для этого существуют интерфейсные и программные контракты, а также определенного рода стандарты на изготовление интерфейсов. Уже упоминалось, что в подходе CORBA, связанном с брокерами объектных запросов, интерфейсы описывались на языке, который так и назывался Interface Definition Language (IDL). Это достаточно известный язык. К сожалению, может быть в силу того, что он является достаточно громоздким и не вполне удобным для описания, подход CORBA такого большого распространения не получил. Но в свое время, кстати, не так давно, лет десять назад, это был очень распространенный подход, на котором строились в том числе и корпоративные системы. При этом, что важно, он не зависел от программной платформы. Можно было объединять как решения на основе операционной системы Microsoft, компоненты, которые функционируют в Microsoft Windows, так и компоненты, которые работают под управлением UNIX-систем. Примерно то же можно сказать про Java Beans – этот подход также позволяет применять компонентные приложения, работающие на основе виртуальной Java-машины, которая погружается в среду операционной системы, т. е. реализуется принцип «написано раз – работает везде». Существует возможность портирования Java-кода или промежуточного кода из одной среды в другую благодаря различиям в реализации Java-машины и, наоборот, стандартам реализации языка Java.

Если говорить о модели, которую поддерживает Microsoft, то она называется компонентной или COM-моделью (Component-Object Model). Компоненто-объектной моделью с расширениями или дальнейшим развитием в форме DCOM является динамическая модель COM и COM+. Правила, по которым взаимодействуют компоненты, определяются самой моделью, при этом в компонентную модель входят правила, описывающие жизненный цикл компонента, т. е. последовательность состояний, через которые он проходит в рамках функционирования той или иной системы или той или иной процедуры в этой системе, когда он, например, активен, находится в кэше, т. е. области оперативной памяти, которая дает возможность быстрого обращения к нему при необходимости, или наоборот пассивен, загружен он или не загружен и т. д. И естественно, между этими состояниями существуют переходы, которые также описываются компонентной моделью. И как уже говорилось, компонент – более узкое понятие, чем программный модуль, если говорить о корпоративных системах, которые строятся по модульному принципу, где под модулем понимается блок, реализующий развитую функциональность и выполняющий большое количество элементарных функций, которые как раз и сводятся к классам, а на более высоком уровне – к компонентам. Интересно отметить, что если рассматривать компоненты, например, такие как DLL, единицы развертывания либо некоторые небольшие независимые модули – небольшие элементы, которые можно встраивать в программные системы, можно говорить о сборке программного обеспечения на заказ с включением в него только тех компонентов, которые нужны пользователю, которые для него принципиальны и которые он покупает. Таким образом, компонентную модель интересно рассматривать как модель распространения коммерческого программного обеспечения, когда поставка продукта осуществляется в виде того или иного набора взаимодействующих компонентов, выбранного пользователем.