Перспективные технологии и языки веб-разработки

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

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

Стандарт 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 представлена на рис. 15.1.

    (рис 15.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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • XML языки не зависят от аппаратных и программных платформ, что позволяет связывать разнородные системы;
  • выразительная мощность XML достаточно велика для того, чтобы описать данные практически любой сложности;
    • (рис 15.3) Схема интеграции приложений на основе 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

    Спецификация UDDI (Universal Description, Discovery, and Integration - универсальное описание, поиск и интеграция) позволяет избежать указанных проблем посредством использования специального хранилища (репозитория), где предприятия и организации могут размещать данные о предоставляемых ими сервисах. Инициаторами создания технологии UDDI стали более 100 компаний (полный список можно найти по адресу http://www.uddi.org/community.html), включая Sun и Microsoft. Объединив свои усилия, эти компании разработали проект спецификации UDDI, которая по истечении 18 месяцев была стандартизирована.

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

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

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

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^