Lecture13 (1133570), страница 4
Текст из файла (страница 4)
Если в них возникаетнеобходимость, разработчик должен сам реализовывать эти механизмы либо пользоватьсяготовыми решениями за рамками платформы J2EE.ЗащитаЗащищенность J2EE приложения поддерживается несколькими способами.• С помощью определения методов аутентификации, т.е.
определения идентичностипользователей. Эти методы определяются в дескрипторе развертывания приложения.Можно использовать следующие способы аутентификации.o Отсутствие аутентификации.o С помощью базового механизма протокола HTTP. При попытке обращения к ресурсу попротоколу HTTP будет запрошено имя пользователя и пароль, которые будутпроверены Web-сервером. Этот способ не слишком хорошо защищен, посколькуреквизиты пользователя пересылаются по сети в незашифрованном виде.o С помощью дайджеста (digest). Этот метод работает так же, как базовый механизмаутентификации по HTTP, но имя и пароль пользователя пересылаются взашифрованном виде. Такой способ используется достаточно редко.o С помощью специальной формы.
При этом определяется страница, на которойрасположена форма аутентификации (обычно это те же поля для ввода имени••••пользователя и пароля, но, может быть, и каких-то других его атрибутов), и страница,на которой находится сообщение, выдаваемое при неудачной аутентификации.o С использованием сертификата клиента. Этот метод требует использовать протоколHTTPS.
Клиент должен предоставить свой сертификат или открытый ключ,удовлетворяющий стандарту X.509 на инфраструктуру открытых ключей. Можноиспользовать и взаимную аутентификацию — в этом случае и клиент, и серверпредоставляют свои сертификаты.С помощью соединений по протоколу HTTP поверх уровня защищенных сокетов (SecureSocket 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 forXML, 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.Web-сервер(Microsoft InternetInformation Services)Клиент —Web-браузерHTMLстраницыСреда .NETHTTPASP.NETкомпонентыДругие .NETкомпонентыХранилищеданных(СУБД)Схема БДРисунок 73.
Типовая архитектура Web-приложения на основе .NET.В рамках .NET имеются аналоги основных видов компонентов J2EE. Web-компонентамсоответствуют компоненты, построенные по технологии ASP.NET, а компонентам EJB,связывающим приложение с СУБД, — компоненты ADO.NET. Компонентная среда .NET обычнорассматриваются как однородная. Однако существующие небольшие отличия в правилах,управляющих созданием и работой компонентов ASP.NET и остальных, позволяют предположить,что в рамках .NET присутствует аналог Web-контейнера, отдельная компонентная среда дляASP.NET, и отдельная — для остальных видов компонентов.
Тем не менее, даже если это так, этисреды тесно связаны и, как и контейнеры J2EE, позволяют взаимодействовать компонентам,размещенным в разных средах. Компонентная среда для ASP.NET, в отличие от Web-контейнера вJ2EE, поддерживает автоматические распределенные транзакции.Тем самым, типовая архитектура Web-приложений на основе .NET может быть изображенатак, как это сделано на Рис. 73.В целом, Web-приложения на основе .NET используют тот же набор архитектурных стилей,что и аналогичные J2EE-приложения.Обычно .NET-компоненты представляют собой набор .NET-классов и конфигурационныхфайлов, играющих роль дескрипторов развертывания и также представленных в некоторомформате на основе XML.
Для приложений в целом тоже пишутся особые конфигурационныефайлы.СвязьСвязь между компонентами в рамках .NET осуществляется при помощи механизма Remoting,реализующего как RMI, так и асинхронную передачу сообщений.Классы и интерфейсы, служащие основой механизма Remoting, находятся в пространстве именSystem.Rutime.Remoting и его подпространствах, в сборках mscorlib и System.Rutime.Remoting.В рамках Remoting объекты, которые могут участвовать в качестве целей удаленного вызова,его параметров и результатов, делятся на передаваемые по значению (marshal-by-value) ипередаваемые по ссылке (marshal-by-reference).Тип объекта, передаваемого по значению, должен реализовывать интерфейсSystem.Runtime.Serialization.ISerializable или должен быть помечен атрибутомSystem.SerializableAttribute. В последнем случае .NET автоматически создает код,необходимый для сериализации или десериализации данных объекта.
Исключения, которые могутбыть созданы методом, вызываемым удаленно, также должны быть передаваемы по значению.Объекты, передаваемые по ссылке, должны наследовать классу System.MarshalByRefObject.При передаче такого объекта как аргумента или результата в другом процессе (или зонеприложения, см.
следующий раздел) создается клиентская заглушка, связанная с этим объектом иназываемая в .NET посредником (proxy).Более тонкую настройку удаленных вызовов можно делать при помощи наследников классаSystem.ContextBoundObject. Наследование этого класса говорит о том, что удаленные вызовы вобъекте этого класса должны происходить в рамках некоторого контекста, являющегося частьюего зоны приложения. Примером такого контекста служит контекст транзакции. При вызовахтаких объектов .NET проводит дополнительные проверки, связанные с разницей контекстовмежду вызывающим объектом и вызывающим.Ниже находится пример взаимодействующих по механизму Remoting классов, имеющий ту жефункциональность, что и пример, приведенный для Java RMI.Код класса, реализующего метод для удаленных обращений.using System;namespace Examples.Remoting{public class Hello : MarshalByRefObject{public String HelloMethod() { return "Hello!"; }}}Код сервера, ожидающего обращения клиентов.using System;using System.Runtime.Remoting;namespace Examples.Remoting{public class HelloImpl{public static void Main(){RemotingConfiguration.Configure("RemotingServer.exe.config");Console.ReadLine();}}}Код клиентского класса.using System;using System.Runtime.Remoting;namespace Examples.Remoting{public class HelloClient{public static void Main(){RemotingConfiguration.Configure("RemotingClient.exe.config");Hello stub = new Hello();Console.WriteLine("response: " + stub.HelloMethod());}}}Кроме классов, должны быть написаны конфигурационные файлы серверного и клиентскогоприложений.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
