[an error occurred while processing this directive] IT • archiv :: Print

IT • archiv


[an error occurred while processing this directive]

[an error occurred while processing this directive]

Tapestry — централизованная система управления

[an error occurred while processing this directive](none) [an error occurred while processing this directive](none)[an error occurred while processing this directive] ::
[an error occurred while processing this directive](none)
[an error occurred while processing this directive]([an error occurred while processing this directive] Чанг Сау Чионг [an error occurred while processing this directive])

[an error occurred while processing this directive](none)

Как упростить процесс разработки приложений с помощью новой пользовательской системы управления.

User Management
PDF versionPDF версия
Обзор
Насколько бы мощным, умным и функционально богатым не было бы созданное вами приложение, без надёжной и устойчивой пользовательской системы управления вам ни как не обойтись. К сожалению, очень часто разработчики программного обеспечения недооценивают этот очень существенный момент, воспринимая его, как нечто само собой разумеющееся. Однако при этом, в области пользовательских систем управления пока нет единых стандартов — ни один из программных продуктов на сегодняшний день не объясняет, как это может быть на самом деле сделано в единой централизованной форме. В качестве решения этой проблемы можно привести пользовательскую систему управления Tapestry, разработанную под платформу Java, и в основу которой заложены WSDL и SOAP, определяющие её функциональные возможности, и UDDI для работы в ней. (5000 слов)

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

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

В этой статье описывается централизованная пользовательская система управления под названием Tapestry (гобелен), которая позволяет разработчикам многократно использовать одни и те же наборы пользователей для любого из приложений, создаваемых ими. Работа над Tapestry продолжается. Более детальное описание системы можно найти на соответствующем Web-сайте.

Прочитав эту статью, вы сможете:

Управление пользователями

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

Но само по себе наличие такого механизма уже говорит о его важности: каждая система должна уметь создавать пользователей, управлять их действиями и доступом к своим функциям, позволять конфигурировать себя только определённому кругу лиц. Модуль пользовательского управления представляет собой наиболее существенный компонент любого приложения, потому что от него зависит доверие пользователей к системе.

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

Принимая во внимание этот факт, странно видеть, что большинство, если не все, приложения имеют свои собственные системы управления пользователями, созданные с нуля. Учитывая всё сказанное ранее, было бы логичнее предположить, что использование типовых управленческих модулей (см. Рисунок 1), либо встроенных, либо выполненных в виде платформы управления, было бы более удобным вариантом при разработке новой системы. Кроме того, использование уже проверенных и зарекомендовавших себя компонентов помогло бы сократить общее время на разработку.

Централизованная система управления.
Рисунок 1. Централизованная система управления.

В число преимуществ использования централизованной системы управления входят:

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

Подходы к разработке

Как же можно создать централизованную систему управления пользователями, которая бы охватывала и решала проблемы, оговоренные выше? Существует три подхода:

Каждый раз с нуля

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

Использование программной оболочки

Подход, при котором используются некие системные оболочки, представляет собой абстрактный набор программных объектов, служащих для решения какого-либо вида производственных задач посредством гибкой расширяемой архитектуры. Обычно это программный продукт, который может неоднократно использоваться, расширяться или подгоняться в зависимости от текущих требований. Оболочки не имеют строгой архитектуры, поэтому создание новой системы — процесс достаточно гибкий. Но при этом использование программных оболочек требует определённой предварительной работы, в результате которой ничего конкретного не создаётся, хотя чётко прорисовывается приличный кусок инфраструктуры. И наконец, общее время разработки сокращается и, поскольку оболочка в достаточной мере стандартизирует доступ к данным, достигается определённое единообразие. К тому же, все оболочки проходят тестирование.

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

Использование центрального сервера

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

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

Другой проблемой будет разница в атрибутах, которыми обладает пользователь в каждой конкретной прикладной системе, не говоря уже о разнице в правах доступа к разным системам. В качестве примера рассмотрим сценарий, в котором исходная среда включает в себя одну систему управления пользователями и три приложения. Более того, проблема с разделением логик пользователя и приложения мы тоже разобрались. Однако, при добавлении четвёртого приложения мы рискуем запустить мартышку в антикварную лавку (см. Рисунок 2). Используемые в этом приложении пользовательские атрибуты потребуют от нас переделок в системе управления пользователями, что в свою очередь потребует внести изменения в остальные три приложения. Это может здорово подорвать стабильность всей системы.

Добавление нового приложения.
Рисунок 2. Добавление нового приложения.

Аналогия со строительством завода

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

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

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

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

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

Tapestry

Созданная на основе технологии Java система управления пользователями под названием Tapestry обеспечивает прежде всего выполнение всех выше перечисленных требований. Её функциональная сторона определена с помощью WSDL и SOAP, а отображение обеспечивается с помощью UDDI. Tapestry-клиентам не обязательно иметь Web-основу, поскольку они могут быть активированы посредством любого совместимого с SOAP клиента на любой платформе. Кроме того, здесь используется HTTP для передачи от клиента к клиенту SOAP-информации, которая в свою очередь транслируется SOAP-маршрутизатором для доступа непосредственно к сервисам.

Что умеет делать Tapestry?

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

Во-первых, Tapestry — это Web-сервис. Запросы к Tapestry выполняются в виде SOAP-пакетов, инкапсулированных в HTTP-запросы, и возвращаются в виде SOAP-ответов, инкапсулированных в HTTP-ответы прикладной системе. Таким образом, системы, использующие Tapestry, не обязательно должны являться системами для Web или даже написанными на Java, если только они понимают SOAP. Это позволяет эффективно отделить функции приложения от непосредственно Web-сервиса. Другими словами, нет необходимости создавать какую-либо систему пользовательского управления или расширять имеющуюся.

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

В-третьих, Tapestry в своей работе использует систему ролевого доступа пользователей (RBAC), определяющую пользователей по ролям, которые они исполняют. В Tapestry каждый из пользователей играют одну или несколько ролей, каждое из приложений видит одну из них. Если мы говорим о базовых классах, то роли динамически генерируются из конфигурационного файла. Более того, эти роли тесно связаны с прикладной системой. К примеру, в системе отдела кадров пользователь играет роль сотрудника. Следующая система в качестве пользователя имеет покупателя, таким образом, пользователь играет роль покупателя, если при этом это один и тоже пользователь, он играет две роли. Роли могут также использоваться для интегрирования с уже существующими системами для доступа к их модулям пользовательского управления. Роли могут использоваться в качестве абстракции пользовательского login в конкретной системе. В приведенном примере вы можете использовать Tapestry для абстрагирования роли пользователя в качестве сотрудника в системе отдела кадров, точно так же как роли покупателя в торговом портале. Его удостоверяющие параметры остаются одними и теми же, но при этом он играет две роли — данные, хранимые в обеих ролях, различны и используются независимо друг от друга, но login и порядок управления доступом остаются одними и теми же. Роли не вступают в конфликт, поскольку они изолированы друг от друга, и связывает их между собой их пользователь. Следовательно, каждое приложение связано с пользователем, хотя и отделено от системы управления пользователями. Результатом данного механизма являются компоненты, из которых можно собирать МОЗАИКУ (Tapestry) без риска нарушить цельность существующей инфраструктуры.

Самое главное заключается в том, что Tapestry можно быстро внедрить в рабочий процесс, чтобы обеспечить централизацию процедуры управления пользователями. И хотя внешне она обеспечивает все функции центрального управляющего сервера, здесь нет ни одной из вытекающих из данного подхода проблем. Она легко конфигурируется через XML, чем могут пользоваться разработчики при создании и внедрении прикладных систем. Отметим только, что Tapestry обеспечивает серверную часть управленческих функций; разработчикам всё же придётся поработать над клиентами приложения для обращения к этим функциям.

Tapestry и порядок управления пользователями

Используемые в Tapestry процедуры (сервисы) управления доступом пользователей выполнены на основе RBAC Reference Model (системной модели ролевого доступа), используемой в Proposed Standard для системы Role-Based Access Control. Tapestry распределяет между пользователями роли и права, соответствующие этим ролям. Основными элементами в Tapestry являются:

Компоненты управления Tapestry.
Рисунок 3. Компоненты управления Tapestry.

Архитектура Tapestry

Web-сервисы Tapestry пересылают SOAP-пакеты через HTTP. А это значит, что наиболее значимым компонентом Tapestry является Web-сервер, занимающийся получением и обработкой Web-сервисов.

Архитектура Tapestry.
Рисунок 4. Архитектура Tapestry.

К Tapestry обращается три вида пользователей. Первым видом является приложение или пользователь приложения. Данный пользователь вызывает Tapestry Application Service для выполнения процедур аутентификации, определения роли, предписанной пользователю, и прав, которые предполагает эта роль. Вторым типом является администратор приложений, управляющий всей пользовательской информацией, включая распределение ролей и создание пользователей. Этот пользователь вызывает Tapestry Admin Service. Последним типом пользователя будет системный администратор Tapestry, который контролирует весь процесс, связанный с Tapestry и ролями, исполняемыми пользователями, обеспечивая соответствующие этим ролям права и определяя пределы этих прав. Администратор Tapestry работает с Tapestry Security Service.

Пользователи Tapestry получают доступ к сервисам Tapestry через Web-сервер, переадресовывающий их обращения к SOAP-маршрутизатору. Затем сервисы вызывают ключевые классы Tapestry, которые непосредственно и выполняют требуемую работу. Текущая реализация Tapestry в качестве ключевых классов использует компоненты JavaBeans. В следующих версиях системы предполагается использовать уже компоненты Enterprise JavaBeans. И наконец, ключевые классы хранят свои данные в объeктном хранилище данных (object data store).

Вопросы проектирования Tapestry

Теперь рассмотрим проблемы, связанные с проектированием Tapestry.

Ролевые ограничения

Tapestry реализует три типа ограничений для своих пользователей и процесса распределения ролей:

  1. Статическое разграничение обязанностей — Static separation of duty (SSD): Данное ограничение позволяет присвоить пользователю роль только в том случае, если она не противоречит роли, которая уже есть у этого пользователя. SSD позволяет избежать конфликта интересов одного и того же пользователя. Например, пользователь, играющий роль кассира банка не может при этом играть роль аудитора.
  2. Динамическое разграничение обязанностей — Dynamic separation of duty (DSD): Иногда у пользователя возникает необходимость сыграть несколько конфликтующих между собой ролей. К примеру, пользователь, исполняющий роль сотрудника может одновременно быть и руководителем. В подобных ситуациях Tapestry вводит DSD-ограничение, предоставляющее пользователю право исполнять одну из этих ролей, но не обе сразу. То есть, в данном примере пользователь в конкретный момент может быть только либо сотрудником, либо руководителем, но ни одним и другим одновременно.
  3. Количество ролей — Cardinality of roles: Некоторые роли в определённый момент времени могут исполняться определённым количеством пользователей. Например, в отделе есть некое число пользователей, и только один из них может в данный момент находиться в отпуске. Пользователь может играть данную роль только в том случае, если количество ролей не превышает допустимое число.

Ролевые ограничения проверяются всякий раз, когда роли активизируются или распределяются.

Ролевые иерархии

Роли в Tapestry имеют иерархические отношения. Ролевые иерархии подчиняются принципам включающих отношений (containment relations): роль r1 содержит в себе роль r2, если все пользователи, авторизованные для r1, также авторизованы для r2, что означает, что пользователь с ролью r1 также обладает привилегиями и правами роли r2.

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

Ролевые иерархии выстраиваются в зависимости от ролевых ограничений, о которых было сказано выше. Для разграничения обязанностей при наличии двух взаимоисключающих ролей производные от этих ролей также будут взаимно исключать друг друга. В приведенном ниже примере ролевой иерархии, когда техническая и нетехническая роли образуют SSD-группу, пользователь не может исполнять роль руководителя и оператора ни при каких условиях. Точно также, если они образуют DSD-группу, пользователь не сможет исполнять роли руководителя и оператора сразу в одно и то же время, при этом ничто не мешает ему исполнять эти роли попеременно.

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

Как было сказано выше, Tapestry допускает неоднократные ролевые наследования. Но, тем не менее, Java этого не допускает, если только это не осуществляется через интерфейс. Так как интерфейс не содержит данных, он не может использоваться в моделировании ролевой иерархии. Чтобы обойти это ограничение, в Tapestry применена направленная нецикличная графика (directed acyclic graph) DAG, позволяющая осуществлять однонаправленную передачу. Само название DAG говорит о том, что в ней отсутствует цикличность. В качестве примера DAG можно использовать ролевую иерархию из Рисунка 5.

Из Рисунка 5 видно, что пользователь, исполняющий роль сотрудника, также играет роли не технического работника, обычного служащего и пользователя. Чтобы определить содержащиеся роли, осуществляется внутренний поиск и сохранение каждой из ролей. Затем результат этого прохождения становится ролями, которые и исполняет пользователь. Таким образом, пользователь может получить роль сотрудника и одновременно оператора. Когда создаётся сессия и роли активизируются, ролевая иерархия обеспечит наличие всех ролей, содержащихся в пользовательской сессии.

Пример ролевой иерархии.
Рисунок 5. Пример ролевой иерархии.

Аутентификация производных объектов

В Tapestry реализована простая схема аутентификация производных объектов (маркеров). Она не шифруется по умолчанию. Тем не мене, дизайн позволяет использовать разные схемы аутентификации с помощью разных интерфейсов. Сам механизм основывается на обычном квитирующем протоколе с подтверждение получения данных (handshake and acknowledgement protocol). Порядок выполняемых действий выглядит следующим образом:

  1. Пользователь регистрируется в приложении, пользуясь своими именем и паролем.
  2. Приложение получает имя пользователя и пароль и пересылает их в Tapestry.
  3. Tapestry вызывает аутентификатор из AuthenticatorFactory и проверяет наличие в системе такого пользователя. Если таковой существует, отсылает обратно приложению сообщение в виде SOAP-пакета и сохраняет производное объекта в репозиторий производных (token repository). Если пользователя с введёнными данными в системе не существует, возвращается невалидное производное. Установленный по умолчанию аутентификатор сверяет наличие и правильность введённых имени и пароля пользователя с имеющимися в базе данных.
  4. Производный объект содержит ID пользователя, поле статуса (valid или invalid) и время истечения срока действия ID.

Каждое последующее обращение к Tapestry будет требовать от производного объекта аутентификации данного обращения. Последовательность этой операции будет выглядеть следующим образом:

  1. Полученный производный объект сначала проверяется на срок действия. Если время его действия просрочено, производный объект аннулируется и возвращается. На этом работа прекращается.
  2. Полученный производный объект сравнивается с уже имеющимся в репозитории. Репозиторий производных реализован в виде развёрнутого дерева, позволяющего оптимальный поиск.
  3. Если производный объект оказывается зарегистрированным, его последующая обработка продолжается, если нет — прекращается

Пользователи, группы и роли

Более детальное изучение модели Tapestry открывает нам скрытые ранее возможности использования ролей и групп. Выражаясь доступным языком, роли это форма группы, объединяющей какое-то число пользователей в целях контроля над доступом. Например, пользователи, исполняющие роль служащего, формируют группу с правами служащих. Разберёмся, какую же функцию в Tapestry играет концепция группы, исходя из того, что роли уже сами по себе представляют наиболее очевидные функции группы?

Ключевым отличием является тот факт, что группы Tapestry не гарантируют управления доступом, они не представляют собой объединение пользователей с одинаковыми правами по отношению к определённому объекту. Группы объединяют пользователей и другие группы пользователей, но пользователи в них совсем не обязательно должны иметь одинаковые роли. Например, руководитель и сотрудник могут принадлежать к одной и той же группе, не нарушая ни каких условий доступа и безопасности друг друга, только потому, что принадлежность к одной группе ещё не гарантирует одинаковых прав. При этом, группа не исполняет роли, хотя и может иметь иерархическую структуру (группы могут содержать подгруппы).

Как же использовать группы, если не группировать управление доступом? Tapestry определяет группы как собрание пользователей и групп, созданное данными пользователями для обеспечения более удобной работы приложения. Непосредственное членство в группе и использование группы определяется самим приложением, создающим и использующим её, но ни как не администратором. Ни один из членов группы не обладает никакими особыми правами — членство произвольно и определяется приложением. В качестве примера можно привести список почтовой рассылки. Ни один из адресатов, перечисленных в списке, не имеет каких-либо особых прав доступа к какой-либо из частей системы. Список создаётся таким образом, чтобы было удобно рассылать почту, вошедшим в него респондентам.

Пользователь в нескольких ролях.
Рисунок 6. Пользователь в нескольких ролях.

Роли представляют собой гибкую и удобную концепцию, позволяющую Tapestry дифференцировать функции пользователя от него самого. При использовании того же сценария, что изображён на Рисунке 2, с тремя уже работающими приложениями, использующими Tapestry, к которым добавляется новое приложение, мы можем рассмотреть решение проблемы гибкости системы с помощью ролей. Пользователь исполняет в каждом из приложений разную роль, а роли в свою очередь содержат информацию, относящуюся к конкретной системе.

Например, пользователь исполняет роль сотрудника в системе Отдела Кадров, где указывается отдел, зарплата, непосредственный начальник и продолжительность отпуска. Если добавляется новая система, в данном случае система Учета Данных, мы можем так же просто добавить роль редактора. Таким образом, информация о пользователе отделена от информации о его роли, при этом они тесно связаны друг с другом, что позволяет централизовано ими управлять.

Добавление нового приложения в Tapestry.
Рисунок 7. Добавление нового приложения в Tapestry.

Для ещё большей гибкости Tapestry реализует пользователей в качестве интерфейсов, когда указанный пользователь не является однажды установленным, а генерируется при каждой имплементации. С практической точки зрения — это необходимо, так как редко могут существовать две имплементации, содержащие одни и те же данные для своих групп пользователей

Кроме того, Tapestry реализует свои данные в виде Java 0бъектов в объектно-ориентированной базе данных. То есть, Tapestry хранит свои объекты в базе, вместо того чтобы конвертировать их в записи, хранящиеся в релятивной базе данных.

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

Связывание пользователя, роли и сессии

Производные объекты реализуют сессии, как это говорилось ранее. Пользователь привязан к производному объекту с момента регистрации (login), и действующие роли также привязаны к производным объектам. Каждый успешный login будет получать производный объект/сессию, который в свою очередь будет содержать какое-то количество активных ролей. Отметим, что роли по-прежнему статически связаны с пользователями, а производные объекты определяют активную в данный момент роль пользователя.

Ролевые ограничения определяют разграничение прав и обязанностей (SSD или DSD) при исполнении той или иной роли в системе. Каждое из ограничений реализовано в виде объекта с перечнем ролей, формирующих либо SSD, либо DSD -пакеты, а также количественные ограничения, определяющие максимальное допустимое число ролей, которые могут активно проявляться в один и тот же момент времени. Система сверяется с ролевыми ограничениями всякий раз, когда активизируется или создаётся какая-либо из ролей.

В принципе, права, объекты и операции тесно связаны с конкретным приложением. Например, каждое приложение будет иметь свой собственный набор транзакций и ресурсов (объектов), а также свой собственный набор операций над данными объектами. В результате, права, приписывающие объекты к соответствующим операциям, должны быть достаточно гибкими, чтобы поддерживать подобное распределение. Заметим, что Tapestry ни коим образом не может навязать приложению своё управление доступом, если оно откажется следовать правилам контроля над доступом Tapestry. Такоие случаи неизбежны, поскольку приложение и механизм, обеспечивающий управление доступом, самостоятельные образования.

Заключение

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

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

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

Об авторе

Chang Sau Sheong является вице-президентом и совладельцем компании elipva (известной ранее как starfire.com), занимающейся разработкой программного обеспечения и оказанием услуг в области электронной коммерции и расположенной в Сингапуре. Он является одним из двух создателей прикладной оболочки elipva Portal Application Framework на J2EE, позволяющей быстро разрабатывать и внедрять различные порталы. Занимается программированием на Java последние четыре года, а непосредственно разработкой сервлетов и EJB с первых дней их появления.

Reprinted with permission from the June 2001 edition of JavaWorld magazine. Copyright © ITworld.com, Inc., an IDG Communications company.
View the original article at: http://www.javaworld.com/javaworld/ jw-06-2001/jw-0615-tapestry.html

Русский перевод опубликован с разрешения Java Журнал © IBA Java Team, 2001. Оригинал статьи: http://java.iba.com.by/javaweb/ibajavat.nsf/ lnarticlesview/DDCE8FF87A28678042256A70003443DC

[an error occurred while processing this directive]
[an error occurred while processing this directive] Перевод на русский © Андрей Чернухо, 2001
< Вернуться на caйт :: Copyright © 1999 — 2010, IT • archiv.