Обзор технологий разработки серверных веб-приложений

Разбить на страницы

Показывать лекцию целиком

Стандарт CGI

Круг задач, решаемых Web -сервером, ограничен. В основном он сводится к поддержке НТТР -взаимодействия и доставке клиенту Web -документов. Любые "нестандартные" действия реализуются с помощью специальной программы, которая взаимодействует с веб-сервером и клиентом. Это взаимодействие подчиняется определенным правилам.

Основной набор таких правил - стандарт CGI ( Common Gateway Interface - интерфейс общего шлюза), который определяет порядок запуска программы на компьютере-сервере, способы передачи программе параметров и доставки результатов ее выполнения клиенту. Программа, написанная по правилам CGI, называется CGI -сценарием ( script CGI ), хотя это не означает, что на сервере не может выполняться двоичный файл.

Благодаря этому интерфейсу для разработки приложений можно использовать любой язык программирования, который располагает средствами взаимодействия со стандартными устройствами ввода/вывода. Такими возможностями обладают также сценарии для встроенных командных интерпретаторов операционных систем.

Выполнение любой программы (в том числе CGI -сценария) можно условно разделить на пять этапов.

Запуск программы.

Инициализация и чтение выходных данных.

Обработка данных.

Вывод результатов выполнения.

Завершение программы.

Различия между CGI -сценарием и консольным приложением касаются первого, второго и четвертого этапов выполнения.

Каждый раз, когда веб-сервер получает запрос от клиента, он анализирует содержимое запроса и возвращает соответствующий ответ:

Если запрос содержит указание на файл, находящийся на жестком диске, то сервер возвращает в составе ответа этот файл ;

Если запрос содержит указание на программу и необходимые для нее аргументы, то сервер исполняет программу и результат ее работы возвращает клиенту.

CGI определяет:

каким образом информация о сервере и запросе клиента передается программе в форме аргументов и переменных окружения ;

каким образом программа может передавать назад дополнительную информацию о результатах (например о типе данных) в форме заголовков ответа сервера.

В подавляющем большинстве случаев запуск CGI -сценария осуществляется щелчком на кнопке Submit, сформированной с помощью дескриптора <input тyре = "submit"> , который находится на HTML -странице между <form> и </form> . Не зная назначения атрибутов action и method, невозможно понять, как происходит вызов программы и передача параметров.

Значением атрибута action дескриптора <form> является URL файла, содержащего код CGI -сценария. Так, приведенное ниже выражение означает, что файл с кодом CGI -сценария находится на сервере www.myhp.edu в каталоге cgi-bin в файле script.рl.

<form action="http://www.myhp.edu/cgi-bin/script.pl" method="post">

Сценарии

К основным достоинствам разработки приложений на стороне веб-сервера в форме сценариев можно отнести следующие:

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

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

Поддержка кроссплатформенности.

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

В плане быстродействия сценарные языки можно разделить на:

Языки динамического разбора (например command.com ). Интерпретатор считывает инструкции из файла программы минимально требующимися блоками, и исполняет эти блоки, не читая дальнейший код.

Предварительно компилируемые (например Perl ). Вначале считывается вся программа, затем компилируется либо в машинный код, либо в один из внутренних форматов, после чего получившийся код исполняется.

Наиболее распространенными языками разработки серверных сценариев являются Perl, PHP, ASP, Ruby, Python.

ASP

ASP (Active Server Pages) - технология, разработанная компанией Microsoft, позволяющая легко создавать приложения для Веб.

Программирование на ASP дает разработчикам доступ к интерфейсу программирования приложений Internet Information Server с помощью языка сценариев VBScript и JScript.

ASP работает на платформе операционных систем линии Windows NT и на веб-сервере Microsoft IIS.

Архитектура ASP представлена на рис.12.1.

(рис 12.1) Архитектура ASP

Файлы ASP представляют собой сценарии, интерпретируемые по мере поступления запросов. ISAPI -расширение ASP.DLL связано в IIS с расширениями файлов .asp или .asa.

Порядок обработки таких файлов выглядит следующим образом:

ASP.DLL просматривает файлы с указанными расширениями на наличие тегов, обозначающих внедренный код для выполнения на сервер и передает найденный код в Windows Script Host (WSH) .

WSH выполняет этот код и возвращает результат файлу ASP.DLL.

ASP.DLL передает IIS этот результат и содержимое самого файла ASP.

IIS возвращает ответ клиенту, от которого поступил запрос.

Рассмотрим основы синтаксиса ASP.

IIS различает код, выполняющийся на сервере, и содержимое, отправляемое клиенту с помощью ASP.DLL, анализируя файл ASP на наличие начального "<%" и конечного "%>" тегов и выполняя код, расположенный между ними, с помощью WSH.

Рассмотрим пример:

<% Language=VBScript %>
<HTML>
<BODY>
<%
Response.Write("<p>Hello world!</p>")
%> 
</BODY>
</HTML>

В примере первая строка кода <% Language=VBScript %> сообщает о необходимости использовать интерпретатор языка VBScript. Для вставки строки в документ был использован метод Write стандартного объекта Response.

Событие веб-запроса в ASP обрабатывается с помощью следующих объектов:

Response. Используется для записи данных в запрос HTTP, возвращаемый клиенту.

Application. Содержит параметры и конфигурации по настройке работы ASP для данного веб-сайта.

Request. Хранит содержимое HTTP -запроса и обеспечивает вспомогательные функции для обработки данных HTTP -запроса.

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

Session. Представляет собой состояние заданного веб-сеанса с заданным хостом клиентом.

ISAPI

Для веб-сервера IIS (Internet Information Server) . был разработан специальный программный интерфейс для создания приложений расширяющих стандартные возможности веб-сервера.

ISAPI (Internet Server Application Programming Interface) - многозвенный API для веб-сервера IIS.

ISAPI также реализован в виде модуля mod_isapi для веб-сервера Apache. Таким образом, серверные приложения, разработанные для MS IIS могут также выполняться в Apache и других веб-серверах.

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

ISAPI включает в себя 2 компоненты: расширения и фильтры.

Таким образом, все многообразие разрабатываемых ISAPI -приложений сводится только к этим двум типам. И фильтры и расширения компилируются в DLL файлы динамически запускаемые веб-сервером.

ISAPI приложения могут разрабатываться с помощью любых языков, поддерживающих экспорт стандартных С -функций, например С, С++, Delphi. Для разработки имеется ограниченное число библиотек для разработки ISAPI приложений, например Intraweb -компоненты Delphi Pascal, специальные MFC -классы, специальная С++ библиотека серверных технологий ATL.

К наиболее важным особенностям ISAPI -расширений можно отнести следующие:

ISAPI - расширения имеют доступ ко всем функциональным возможностям IIS

Реализуются в виде DLL -модулей, загружаемых в пространстве процесса, контролируемого IIS.

Клиенты могут обращаться к ISAPI - расширениям также как к статическим HTML страницам.

ISAPI - расширения могут быть ассоциированы с отдельными расширениями файлов, с целыми каталогами или сайтами.

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

Фильтры также как и расширения реализуются в виде DLL файлов.

Обычно ISAPI -фильтры используются для решения следующих задач:

Изменение данных в запросе клиента ( URL или заголовков).

Управление отображением URL в физические файлы.

Управление именами и паролями пользователей при анонимной или базовой аутентификации.

Анализ и модификация запросов по завершении аутентификации.

Модификация ответа веб-сервера.

Ведение журналов и анализ трафика.

Реализация собственной аутентификации.

Управление шифрацией и сжатием.

Стоит отметить, что существуют реализации в виде ISAPI -расширений для таких инструментальных средств как:

ASP (Active Server Pages )

ASP.NET

ColdFusion

Perl ISAPI (Perlis)

PHP

Архитектура веб-приложений ASP.NET. Разработка веб-приложений на платформе .NET

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

ASP.NET внешне во многом напоминает более старую технологию ASP, но в то же время внутреннее устройство ASP.NET существенно отличается от ASP. Система ASP.NET была построена на базе CLR (Common Language Runtime) , который является основой всех приложений .NET. Разработчики могут создавать код для ASP.NET, используя языки программирования, входящие в .NET Framework: C#, Visual Basic.NET, JScript.NET и другие.

Рассмотрим более подробно, чем отличается ASP.NET от ASP.

Классический ASP имеет следующие недостатки:

Используются только языки сценариев, которые дают большой проигрыш в производительности (из-за их интерпретируемости) и не поддерживают многие возможности объектно-ориентированного программирования.

Логика представления (в виде кода HTML ) не отделена от бизнес-логики (исполняемого кода), что приводит перемешиванию в одном файле кода HTML с кодом сценария.

Невозможно повторно использовать готовые решения в других проектах (возможно только копирование кода сценариев).

В файлах ASP.NET включается код на таких языках программирования как C#, JScript.NET, VisualBasic.NET, что позволяет применять непосредственно в веб-приложениях возможности объектно-ориентированного программирования. Также существенно сокращается объем кода, написанного вручную за счет применения серверных объектов, автоматически генерирующих код элементов управления HTML. Возможно использование стандартной среды разработки Visual Studio.NET, т.е. ASP.NET имеет преимущество в скорости по сравнению со сценарными технологиями, так как при первом обращении код компилируется и помещается в специальный кеш, а впоследствии только исполняется, не требуя затрат времени на парсинг, оптимизацию, и т. д.

Несмотря на возможность совместной работы ASP и ASP.NET на одном веб-сервере, они не могут использовать общий сеанс. Файлы ASP.NET обрабатываются библиотекой aspnet_isapi.dll (а не asp.dll ), которая, в свою очередь, использует для выполнения кода технологию .NET.

Библиотека базовых классов .NET содержит пространства имен 3 основных групп:

элементы web - приложений (протоколы, безопасность и др.);

элементы графического интерфейса ( WebForms ) ;

web - службы.

Как уже указывалось ранее, ASP.NET использует возможности стандартной среды разработки Visual Studio.Net, и в частности классы библиотеки FCL (Framework Class Library) .

Разработчику веб-приложений на ASP.NET доступны классы, входящие в следующие пространства имен:


Пространство имен	Содержание
`System.Web`	Организация взаимодействия `web` -клиента (браузера) с `web` -сервером (запрос-ответ, `cookie` и и др.)
`System.Web.Caching`	Поддержка кэширования при работе `web` -приложений
`System.Web.Configuration`	Настройка `web` -приложения в соответствии с файлами конфигурации проекта
`System.Web.Security`	Реализация системы безопасности `web` -приложений
`System.Web.Services`	Организация работы `web` -сервисов
`System.Web.Services.Description`	Организация работы `web` -сервисов
`System.Web.Services.Discovery`	Организация работы `web` -сервисов
`System.Web.Services.Protocols`	Организация работы `web` -сервисов
`System.Web.UI`	Построение графического интерфейса пользователей `web` -приложений
`System.Web.UI.WebControls`	Построение графического интерфейса пользователей `web` -приложений
`System.Web.HtmlControls`	Построение графического интерфейса пользователей `web` -приложений

В свою очередь пространство имен System.Web включает в себя пространства имен, названия которых знакомы разработчикам веб-приложений на ASP:


Пространство имен	Содержание
`HttpApplication`	Данный класс определяет общие для всех web-приложений члены
`HttpApplicationState`	В данном классе содержится общая информация `web` -приложения для множества запросов, сеансов и каналов передачи данных
`HttpBrowserCapabilities`	Этот класс используется для получения информации о возможностях клиентского браузера, обращающегося к `web` -серверу
`HttpCookie`	Поддержка механизма безопасной работы с объектами `HTTP cookie`
`HttpRequest`	Предоставляет доступ к информации, переданной web-клиентом
`HttpResponse`	Используется для формирования `HTTP` -ответа сервера

В основу разработки веб-приложений на ASP.NET положена модель разделения кода представления и кода реализации, рекомендуемая Майкрософт при создании динамических документов на с помощью программных кодов. Это делается путем размещения программного кода либо в отдельный файл, либо внутри специального тэга для сценариев. Файл такого рода обычно имеет расширение *.aspx.cs (*.aspx.vb) и имеет имя, совпадающее с именем основного ASPX файла. В принципе такой подход позволяет веб-дизайнеру сконцентрироваться работе с кодом разметки документа с минимальными изменениями программного кода, в обычном ASP внедряемого непосредственно в код разметки.

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

При запросе страницы ASPX инициируется событие Page_Init, производящее начальную инициализацию страницы и ее объекта.

Далее инициируется событие Page_Load, которое может быть использовано, например для установки начальных значений для элементов управления. При этом также можно определить была ли загружена страница впервые или обращение к ней осуществляется повторно в рамках обратной отсылки в ответ на события, связанные с элементами управления, размещенными на странице; т.е. проверить свойство Page.IsPostBack.

Далее выполняется проверка валидности элементов страницы с точки зрения корректности введенных пользователем данных.

И, наконец, следует обработка всех событий, связанных с действиями пользователя с момента последней обратной отсылки.

Для сохранения данных веб-страницы в промежутках между обращениями к ней в ASP.NET используются состояния отображения ( view state ).

Если данные, введенные в веб-форму, необходимо сделать доступными другим веб-формам того же приложения, эти данные необходимо сохранить в объектах Application и Session. Объекты Application доступны всем пользователям приложения и могут рассматриваться как глобальные переменные, обращение к которым возможно из любых сеансов. Объекты Session доступны только в рамках одного сеанса, и поэтому они оказываются доступными только одному пользователю.

Серверные элементы управления ASP.NET

Важной особенностью ASP.NET является использование серверных элементов управления на веб-странице (элементы WebForm ), которые являются фактически тэгами, понятными веб-серверу. Эти элементы определены в пространстве имен System.Web.UI.WebControls.

Принято выделять три типа серверных элементов управления:

Серверные элементы управления HTML - обычные HTML тэги.

Элементы управления веб-сервера - новые тэги ASP.NET.

Серверные элементы управления для проверки данных (валидации) - применяются для валидации входных данных от клиентского приложения (обычно веб-браузера).

Преимущества от использования таких элементов при разработке веб-приложений:

Сокращается количество кода, написанного вручную (что особенно заметно в для сложных элементов документа). Элемент просто "перетаскивается" из панели инструментов, после чего выполняется настройка его параметров в специальном окне. При этом все изменения автоматически заносятся непосредственно в *.aspx файл.

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

Для любого элемента управления WebForm определен набор событий, обрабатываемых на веб-сервере.

Для любого элемента управления WebForm предоставляется возможность для проверки ввода данных пользователем.

По умолчанию серверные элементы управления HTML в ASP.NET файлах рассматриваются как текст. Для их программирования требуется добавление атрибута runat="server" в соответствующий HTML элемент. Кроме того, все серверные элементы управления HTML должны быть размещены внутри области действия тэга <form> , также имеющего атрибут runat="server".

Подобно серверным элементам управления HTML элементы управления веб-сервера также создаются на веб-сервере и предполагают добавление атрибута runat="server". Однако они могут и не соответствовать конкретным элементам HTML, но представлять более сложные элементы.

Общий синтаксис для описания таких элементов:

<asp:тип_элемента id="идентификатор" runat="server"/>

Серверные элементы валидации применяются для проверки вводимых пользователем данных.

Имеют следующий синтаксис:

<asp:тип_элемента id="идентификатор" runat="server" />

Работа с источниками данных в ASP.NET

В ASP.NET используются два элемента управления WebForm для управления отображением данных, получаемых из источника данных:

DataGrid - элемент управления, отображающий содержимое объекта ADO.NET DataSet в виде таблицы.

DataList - элемент управления для выбора значений, заполняемых из источника данных.

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

Архитектура MVC (Model - View - Controller)

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

Подход к проектированию программных систем Модель-Вид-Контроллер ( MVC ) основан на разделении программы на три части.

Компонента Модель ( Model ) отвечает за хранение данных и обеспечение интерфейса к ним.

Компонента Вид ( View ) отвечает за представление этих данных пользователю.

Контроллер ( Controller ) управляет компонентами, получая сообщения в виде реакции на действия пользователя, и уведомляя об изменениях компоненту Модель.

Такая внутренняя структура в целом разбивает систему на самостоятельные части и распределяет ответственность всего приложения на различные компоненты. Архитектура такого взаимодействия представлена на рис.12.2

(рис 12.2) Архитектура взаимодействия MVC

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

ASP.NET MVC - продукт выпущенный в апреле 2009 г. компанией Microsoft, призванный упростить разработчикам создание веб-приложений, использующих шаблон MVC (model-view-controller) . Фактически это готовый framework для языка ASP.NET.

ASP.NET MVC обеспечивает полный контроль за HTML -разметкой, структурой URL -адресов, упрощает модульное тестирование и способствует использованию модели разработки TDD (test driven development) .

ASP.NET MVC 1.0 доступен как в виде отдельного пакета, так и через инсталлятор Microsoft Web Platform Installer.

На рис.12.3 представлена структура проекта, созданного на основе шаблона ASP.NET MVC Web Application в Visual Web Developer 2008 Express.

(рис 12.3) Структура проекта, созданного на основе шаблона ASP.NET MVC

Организация процесса разработки веб-контента: CMS/CMF системы

Система управления контентом ( Content management system, CMS ) - компьютерная программа, используемая для создания, редактирования, управления и публикации контента некоторым систематическим образом. Обычно такие системы используются для хранения и публикации большого количества документов, изображений, музыки или видео.

Система управления веб-контентом ( Web content management system, WCMS или Web CMS ) - програмное обеспечения CMS класса, реализованное обычно в виде веб-приложения, и предназначенное для создания, и управления HTML содержимым. WCMS обычно используется для управления и контроля большими, динамически изменяемыми коллекциями веб-материала ( HTML документами и связанными с ними картинками). Такая система упрощает процесс создания, управления, редактирования контента и многие другие важные задачи, связанные с поддержкой этих процессов.

WCMS предоставляет следующие возможности:

Применение автоматических шаблонов отображения (в HTML или XML формате), автоматически применяемых к новому или существующему контенту. Тем самым вид всех документов может задаваться из одного места.

Простота редактирования контента ьзователю достаточно легко создавать и управлять контентом, поскольку ему либо вообще не требуется знания языков программирования или языков разметки, либо требуется минимальное знание таковых.

Масштабируемость. Возможность расширения функциональности существующего сайта путем установки поставляемых с дистрибутивом WCMS плагинов и модулей.

Управление документами. Имеются средства управления жизненным циклом документов с момента создания до удаления.

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

В зависимости от способа применения шаблонов для генерации веб-страниц принято выделять три основные типа WCMS -систем: с автономной обработкой, он-лайн обработкой и гибридные системы.

Автономные системы обрабатывают все содержимое путем применением шаблонов перед публикацией веб-страниц.

On-line системы применяют шаблоны в момент посещения сайта пользователями (либо извлекают страницы и кэша).

Гибридные системы комбинируют первые два подхода. Некоорые из них вместо статических HTML страниц генерируют исполняемые коды ( JSP, PHP, Perl ), избавляя от необходимости установки WCMS -системы на каждом веб-сервере.

В качестве примера системы рассмотрим WCMS Drupal.

Drupal - это WCMS система, разработанная на языке PHP и использующая в качестве хранилища данных реляционную базу данных (поддерживаются MySQL, PostgreSQL и другие). Архитектура Drupal позволяет применять его для построения различных типов сайтов - от блогов и форумов, до информационных архивов или сайтов новостей.

Функциональность обеспечивается подключаемыми модулями, обращающимися к общему API Drupal. Стандартный набор модулей включает, например, такие функции как новостная лента, блог, форум, загрузка файлов, сборщик новостей, голосования, поиск и др.

Наиболее важные функции, предоставляемые модулями входящими в поставку Drupal:

единая категоризация всех видов содержимого (таксономия) - от форумных сообщений до блогов и новостных статей;

широкий набор свойств при построении рубрикаторов: плоские списки, иерархии, иерархии с общими предками, синонимы, родственные категории;

вложенность категорий любой глубины;

поиск по содержимому сайта, в том числе поиск по таксономии и пользователям;

разграничение доступа пользователей к документам;

динамическое построение меню;

поддержка XML -форматов:

вывод документов в RDF/RSS ;

аггрегация материалов с других сайтов;

BlogAPI для публикации материалов с помощью внешних приложений;

поддержка сменных тем оформления сайта с предоставлением нескольких готовых вариантов;

переводы интерфейса сайта на разные языки, а также поддержка ведения разноязычного контента;

возможность создания сайтов с пересекающимся содержимым (например общей базой пользователей или общими настройками);

раздельные конфигурации сайта для различных виртуальных хостов (в том числе собственные наборы модулей и тем оформления для каждого подсайта);

механизм для ограничения нагрузки на сайт (автоматическое отключение при высокой посещаемости части информационных блоков и модулей).

Существует огромное множество систем как коммерческих, так и бесплатных. Например, Microsoft предлагает реализацию WCMS системы на базе Windows SharePoint Services.

CMF системы

Каркасная система управления контентом ( Content Management Framework, CMF ) - это инструментарий для создания систем управления контентом, а также отдельных веб-приложений. Некоторые CMS, предоставляющие API для расширения своей функциональности, можно рассматривать как CMF, например WCMS Drupal .

Интеграция и взаимодействие в сети Веб

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

Практикуются следующие подходы к веб-интеграции:

Интеграция на уровне представления. Данный уровень позволяет пользователю взаимодействовать с приложением. Интеграция на уровне представления даёт доступ к пользовательскому интерфейсу удаленных приложении.

Интеграция на уровне функциональности. Данная интеграция подразумевает обеспечение прямого доступа к бизнес-логике приложений. Это достигается непосредственным взаимодействием приложений с API (программному интерфейсу приложений) или же взаимодействием посредством веб-сервисов.

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

Комплексная интеграция. Коммерческие решения по веб-интеграции, как правило, включают все три типа интеграции

Использование веб-интеграции выгодно по многим причинам:

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

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

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

Веб-интеграция позволяет использовать веб-сервисы разработчиков.

Веб-интеграция позволяет развивать программные интерфейсы приложений через протоколы веб-сервисов без программирования.

Для веб-интеграции обычно используется коммерческое ПО или популярные технологии, такие как PHP/Python/Perl, XForms, SOAP и т.д.

Интеграция на основе XML

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

(рис 12.4) Традиционная схема интеграции приложений

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

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

средства разработки и стандартные библиотеки для XML существуют практически на всех платформах и для большинства популярных языков программирования;

методы работы с XML достаточно стандартны для того, чтобы в разных системах можно было пользоваться одинаковыми приемами;

информация, оформленная в виде XML, может обрабатываться не только машинами, но и человеком (что намного облегчает отладку).

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

XML языки не зависят от аппаратных и программных платформ, что позволяет связывать разнородные системы;

выразительная мощность XML достаточно велика для того, чтобы описать данные практически любой сложности;

(рис 12.5) Схема интеграции приложений на основе XML

Интеграция на основе XML практически реализуется в рамках протоколов:

XML-RPC. Это протокол удаленного вызова процедур с передачей данных в формате XML через TCP -порт 80, т.е. HTTP -порт.

WDDX (Web Distributed Exchange) . Представляет собой механизм обмена сложными структурами данных по протоколу HTTP. Протокол базируется не на структурах, а на событиях.

ebXML (electronic buisiness XML) - XML для электронного бизнеса. Основное назначение - предоставление открытой XML -инфраструктуры, обеспечивающей безопасное глобальное использование информации электронного бизнеса.

Веб-сервисы (веб-службы)

Веб-сервисы

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

Реализация веб-сервисов .NET осуществляется так же просто, как и активизация удаленной веб-сервисы или вызов метода локального класса. Это достигается за счет применения инструментов, предоставляемых системой .NET Framework, которые позволяют создать полноценный веб-сервис, без необходимости изучения деталей работы таких стандартов, как SOAP, WSDL и UDDI. При этом выполняются следующие действия:

Веб-сервис разрабатывается как .NET -класс с атрибутами, которые идентифицируют его как веб-сервис с некоторыми функциями.

В среде .NET автоматически создается документ WSDL, где описывается, как клиент должен взаимодействовать с веб-сервисом.

Потребитель находит созданный веб-сервис и может добавить соответствующую веб-ссылку в проект Visual Studio .NET.

В среде .NET осуществляется автоматическая проверка документа WSDL и генерируется прокси-класс, который позволяет потребителю взаимодействовать с веб-сервисом.

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

Прокси-класс преобразует, переданные параметры в сообщение SOAP и отправляет его веб-сервису.

Затем прокси-класс получает SOAP -ответ, преобразует его в соответствующий тип данных и возвращает его как обычный тип данных .NET.

Потребитель использует полученные данные.

При работе веб-сервисов .NET используется технология ASP .NET, являющаяся частью системы .NET Framework. Она также требует поддержки со стороны сервера Microsoft IIS.

Работа веб-сервисов построена на использовании нескольких открытых стандартов:

XML - расширяемый язык разметки, предназначенный для хранения и передачи структурированных данных;

SOAP - протокол обмена сообщениями на базе XML ;

WSDL - язык описания внешних интерфейсов веб-сервисов на базе XML ;

UDDI - универсальный интерфейс распознавания, описания и интеграции ( Universal Discovery, Description, and Integration ). Каталог веб-сервисов и сведений о компаниях, предоставляющих веб-сервисы во всеобщее пользование или конкретным компаниям.

Спецификация WSDL

Каждый веб-сервис предоставляет документ WSDL (Web Service Description Language - язык описания веб-сервиса), в котором описывается все, что клиенту необходимо для работы с этим сервисом. WSDL -документ предоставляет простой и последовательный способ задания разработчиком синтаксиса вызова любого веб-метода. Более того, этот документ позволяет использовать инструменты автоматического генерирования прокси-классов, подобные включенным в среды Visual Studio .NET и .NET Framework. Благодаря указанным средствам использование веб-сервиса является таким же простым, как и применение локального класса.

WSDL -документ имеет основанный на XML формат, в соответствии с которым информация подразделяется на пять групп. Первые три группы представляют собой абстрактные определения, не зависящие от особенностей платформы, сети или языка, а оставшиеся две группы включают конкретные описания.

Протокол SOAP

Связь между веб-сервисами и их клиентами осуществляется посредством сообщений в формате XML.

SOAP (Simple Object Access Protocol - простой протокол доступа к объектам) представляет собой протокол сообщений для выбора веб-сервисов.

Основная идея стандарта SOAP заключается в том, что сообщения должны быть закодированы в стандартизированном XML -формате.

Кроме сообщений SOAP, для обмена данными с сервисами .NET можно использовать методы GET и POST протокола HTTP.

Преимущества применения формата SOAP перед другими форматами для передачи данных:

Кодировать в XML структуры данных и наборы DataSet с использованием SOAP так же легко, как и данные простых скалярных типов.

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

Имеются наборы инструментов SOAP для различных языков программирования (и даже для предыдущих версий Microsoft C++ и Visual Basic ). Иначе, для того чтобы обеспечить связь с сервисом посредством методов GET и POST протокола HTTP, придется, очевидно, самостоятельно конструировать строку запроса, а затем проводить синтаксический анализ ответа.

Стандарт DISCO

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

DISCO -файл может включать файлы различных веб-серверов и поддерживает "динамический поиск" - автоматический поиск каталога файлов веб-сервисов на сервере.

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

Спецификация UDDI

Спецификация ), включая Sun и Microsoft. Объединив свои усилия, эти компании разработали проект спецификации UDDI, которая по истечении 18 месяцев была стандартизирована.

Информация в этом репозитории должна обновляться вручную. С этой целью некоторые "узловые операторы" хранят идентичные копии репозитория UDDI. Эти компании обеспечивают хранение указанного репозитория и бесплатный доступ к нему для популяризации веб-серисов. Кроме того, Майкрософт включила версию UDDI в программное обеспечение сервера Windows .NET для использования в корпоративных сетях интранета.

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

Главными недостатками веб-сервисов являются меньшая производительность и больший размер сетевого трафика по сравнению с такими технологиями как RMI, CORBA, DCOM за счет использования текстовых XML -сообщений.

Страницы: