Компонентные технологии разработки web-приложений

Защита

Защищенность J2EE приложения поддерживается несколькими способами.

• С помощью определения методов аутентификации, т.е. определения идентичности пользователей. Эти методы определяются в дескрипторе развертывания приложения. Можно использовать следующие способы аутентификации.
  • Отсутствие аутентификации.
  • С помощью базового механизма протокола HTTP. При попытке обращения к ресурсу по протоколу HTTP будет запрошено имя пользователя и пароль, которые будут проверены Web-сервером. Этот способ не слишком хорошо защищен, поскольку реквизиты пользователя пересылаются по сети в незашифрованном виде.
  • С помощью дайджеста (digest). Этот метод работает так же, как базовый механизм аутентификации по HTTP, но имя и пароль пользователя пересылаются в зашифрованном виде. Такой способ используется достаточно редко.
  • С помощью специальной формы. При этом определяется страница, на которой расположена форма аутентификации (обычно это те же поля для ввода имени пользователя и пароля, но, может быть, и каких-то других его атрибутов), и страница, на которой находится сообщение, выдаваемое при неудачной аутентификации.
  • С использованием сертификата клиента. Этот метод требует использовать протокол HTTPS. Клиент должен предоставить свой сертификат или открытый ключ, удовлетворяющий стандарту X.509 на инфраструктуру открытых ключей. Можно использовать и взаимную аутентификацию — в этом случае и клиент, и сервер предоставляют свои сертификаты.
• С помощью соединений по протоколу HTTP поверх уровня защищенных сокетов (Secure Socket Layer, SSL, на HTTP поверх SSL часто ссылаются с помощью отдельной аббревиатуры HTTPS).

  Можно потребовать использовать только такие соединения, указав атрибуты CONFIDENTIAL и/или INTEGRAL в дескрипторе развертывания приложения. Первый атрибут означает, что данные, передаваемые между клиентом и приложением, будут зашифрованы, так что их тяжело будет прочитать третьей стороне. Второй атрибут означает, что эти данные будут сопровождаться дополнительной информацией, гарантирующей их целостность, т.е. то, что они не были подменены где-то между участвующими в связи сторонами.
• C помощью механизма описания ролей, определения доступности различных методов Web-компонентов и EJB-компонентов для разных ролей, а также задания политик переноса или создания ролей при совместной работе нескольких методов. Роли, политики их переноса и правила доступа различных ролей к методам описываются в дескрипторах развертывания компонентов.

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

  Это можно делать при помощи методов isUserInRole() и getUserPrincipal() интерфейса HTTPServletRequest, используемого для представления запросов к Web-компонентам, и аналогичных методов isCallerInRole() и getCallerPrincipal() интерфейса EJBContext, используемого для описания контекста выполнения методов EJB-компонентов.

Работа с XML

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

Библиотеки для работы с XML-документами находятся в пакетах javax.xml, org.w3c.dom и org.xml.sax, a также во вложенных в них пакетах. В этих пакетах определяются следующие интерфейсы.

• Общий интерфейс обработчиков XML находится в пакете javax.xml.parsers. Такие обработчики могут быть основаны на простом интерфейсе работы с XML (Simple API for XML, SAX ) [15] или на объектной модели документов (Document Object Model, DOM ) [16]. Оба этих подхода основаны на стандартах W3C.
• Простой интерфейс для работы с XML ( SAX ) [15] определяется в пакете org.xml.sax. Это интерфейс, основанный на событиях, — XML-парсер, реализующий его, последовательно разбирает XML-данные и генерирует очередное событие в зависимости от вида обнаруженной конструкции. Для работы с XML-документами необходимо написать ряд обработчиков таких событий, являющихся реализациями интерфейса org.xml.sax.ContentHandler.
• Объектная модель документов ( DOM ) [16] представляет собой интерфейс работы с XML-документом, представленным в виде дерева его элементов. Java-представление этого интерфейса описано в пакете org.w3c.dom. Одной из его реализаций является JDOM [17], а dom4j [18] предоставляет несколько упрощенную и более удобную с точки зрения Java, но не вполне соответствующую стандарту DOM реализацию.
• Обработка XML-документов может быть построена на базе расширяемого языка трансформаций на основе таблиц стилей (Extensible Stylesheet Language Transformations, XLST) [19]. При этом процесс обработки документов описывается в виде XSLT -программы, которая затем подается на вход интерпретатору XSLT ( XSLT -процессору) вместе с обрабатываемым XML-документом. Интерфейсы для работы с XSLT определены в пакете javax.xml.transform. Широко используемыми XSLT -процессорами являются Saxon [20] и Xalan [21].
• В новую версию J2EE 5.0, ожидаемую в 2006 году, должны войти интерфейсы для потоковой обработки XML-документов (Streaming API for XML, StAX ). В этом подходе XML-документ рассматривается как поток различных конструкций, которые становятся доступными по запросу (pull-модель), в отличие от работы на основе событий в SAX, когда каждая конструкция порождает событие, которое нужно обработать (push-модель). Обработка XML-документов в стиле StAX гораздо более гибкая, чем в SAX, и вполне сравнима с ней по удобству. В настоящее время уже доступны спецификации интерфейсов StAX [22] и несколько их реализаций.

Платформа .NET

Среда .NET предназначена для более широкого использования, чем платформа J2EE. Однако ее функциональность в части, предназначенной для разработки распределенных Web-приложений, очень похожа на J2EE.

В рамках .NET имеются аналоги основных видов компонентов J2EE. Web-компонентам соответствуют компоненты, построенные по технологии ASP.NET, а компонентам EJB, связывающим приложение с СУБД, — компоненты ADO.NET. Компонентная среда .NET обычно рассматриваются как однородная. Однако существующие небольшие отличия в правилах, управляющих созданием и работой компонентов ASP.NET и остальных, позволяют предположить, что в рамках .NET присутствует аналог Web-контейнера, отдельная компонентная среда для ASP.NET, и отдельная — для остальных видов компонентов. Тем не менее, даже если это так, эти среды тесно связаны и, как и контейнеры J2EE, позволяют взаимодействовать компонентам, размещенным в разных средах. Компонентная среда для ASP.NET, в отличие от Web-контейнера в J2EE, поддерживает автоматические распределенные транзакции.

Тем самым, типовая архитектура Web-приложений на основе .NET может быть изображена так, как это сделано на рис. 13.2.

увеличить изображение
Рис. 13.2. Типовая архитектура Web-приложения на основе .NET

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

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