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

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

Для лучшего освоения материала мы разработали пример приложения EasyOA, который призван продемонстрировать процесс реализации коммунальной модели при помощи промежуточного программного обеспечения от IBM, в частности IBM WebSphere Application Server (WAS), DB2, Tivoli Directory Server (TDS) и WebSphere Process Server (WPS).

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

Рисунок 1. Шаблон с несколькими экземплярами приложения по сравнению с шаблоном, использующим один общий экземпляр

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

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

Прежде всего, мы должны обеспечить изоляцию между арендаторами на уровне приложения. Несмотря на то, что все арендаторы, по существу, совместно используют одну и ту же инфраструктуру и экземпляр приложения, с точки зрения работы пользователя, качества сервиса (Quality of Service - QoS) и администрирования арендатор, естественно, желает обращаться к сервису и использовать его так, как будто он работает с выделенными ресурсами. Таким образом, практически на всех стадиях проектирования (как на нефункциональном, так и на функциональном уровне) должен серьезно продумываться механизм изоляции, а именно такие его аспекты, как система защиты, производительность, доступность и администрирование.

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

Коммунальные ресурсы: механизм совместного использования, изоляции и настройки J2EE-артефактов

Для J2EE/SOA-приложений существует много типов доступных ресурсов, так же как и артефактов времени исполнения, размещенных на разных уровнях системы, - пользовательский интерфейс, бизнес-логика, процесс/поток работ, модель данных и т.д. Для проектирования высокоэффективного коммунального приложения необходимо тщательно организовать эти ресурсы, в частности:

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

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

Таблица 1. Обзор механизмов совместного использования, изоляции и настройки
КомпонентыОбщие ресурсыПодходы к изоляцииПодходы к настройке Модель персистентности данных Сервер базы данных (JDBC, SDO и т.д.)

Источник данных, пул соединений

Учетная запись базы данных

База данных/схема/таблица/буферный пул и т.д.

Изоляция хранения: выделенная таблица/схема или база данных против общей таблицы/схемы

Изоляция доступа: управление доступом на уровне СУБД через выделенный источник данных и соединение против управления доступом на уровне приложения через фильтр

Схемы базы данных/таблицы

Фиксированные зарезервированные поля

Расширенные подтаблицы

Расширенное поле с XML-данными

Файлы и ввод/вывод

Каталог

Файл

Выделенный каталог/файл

Общие файлы со специфичным для арендатора фильтром

Структура каталогов или формат файлов

Сервер каталогов (LDAP)

Дерево каталогов

Схема

Выделенное поддерево для каждого арендатора

Общее дерево со специфичным для арендатора фильтром

Структура дерева каталогов и определение схемы

Бизнес-логика Аутентификация/авторизация

Структура организации/репозиторий привилегий

Модули регистрации/авторизации

Изолированный репозиторий согласно специфичному персистентному хранилищу данных (LDAP, DB и т.д.)

Расширенный плагин реестра пользователей, различающий арендаторов

Структура организации, роли, привилегии и их отображаемые взаимоотношения

Глобальный Java-объект

Статическая переменная

Переменная класса Singleton

Выделенная (статическая) переменная для каждого арендатора, использующая контейнерный объект

Недоступен

Удаленный доступ (сокет/Http, RMI, CORABA, JNDI, Web-сервис)

Удаленные сервисы

Параметры соединения, такие как URI, порт, имя пользователя, пароль и т.д.

Выделенный удаленный сервис

Общий удаленный сервис, распространение информации об арендаторе удаленным сервисам

Параметры соединения

EJB

Экземпляр State EJB

Соединение с источником данных, таблица Entity Bean

Очередь, идентичность отправителя MDB

Выделенный экземпляр State EJB, MDB, очередь для каждого арендатора

Общий Entity Bean со специфичным для арендатора фильтром

Общий MDB, очередь с идентичностью арендатора, встроенная в сообщение

Зарезервированные атрибуты общего Entity Bean

Настраиваемый формат сообщений

Журналы регистрации событий

Месторасположение log-файлов, содержимое, формат и конфигурация

Выделенный log-файл

Общий log-файл со специфичным для арендатора фильтром

Формат log-файла и параметры установки

Кэш-память

Контейнер кэш-памяти

Выделенный контейнер кэш-памяти

Общий контейнер кэш-памяти со специфичным для арендатора фильтром

Параметры настройки кэш-памяти

Пользовательский интерфейс JSP

Переменная с областью видимости - приложение (tag, usebean, applicationContext и т.д.)

Переменная объявления

Логотип, стиль, схема и т.д.

Специфичный для арендатора фильтр для переменной с областью видимости - приложение

Выделенная переменная объявления

CSS, схема, изображение и т.д.

Сервлет

Однопоточный сервлет

servletContext

Выделенный сервлет для однопоточного сервлета

Специфичный для арендатора фильтр для переменной servletContext

Недоступен

Процесс/Поток работ Шаблон BPEL-процесса

Атрибут уровня шаблона, действие, условие ссылки и т.д.

Выделенный шаблон процесса

Общий шаблон процесса со специфичным для арендатора фильтром в экземплярах процесса

Скелетный код шаблонов процесса

Задание для пользователей

Команда (verb), пользовательский интерфейс задания и т.д.

Расширенная команда для изоляции механизмов выбора пользователя согласно информации инициатора задания об арендаторе

Элементы пользовательского интерфейса и установка общего задания

Правила выбора пользователей

Бизнес-правило

Правила

Выделенное бизнес-правило

Общее бизнес-правило со специфичным для арендатора фильтром в качестве параметра правила

Настройка значения бизнес-правил

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

EasyOA - это типичное J2EE-приложение, основанное на следующем промежуточном программном обеспечении от IBM:

• IBM WebSphere Application Server V6.02
• IBM WebSphere Process Server V6.02
• IBM Tivoli Directory Server V6.0
• IBM DB2 V8.2

Рисунок 2. Общая архитектура и коммунальные функциональные возможности приложения EasyOA

Приложение EasyOA спроектировано для работы в коммунальном режиме. На рисунке 2 показаны основные поддерживаемые коммунальные функциональные возможности:

• Аутентификация и авторизация представляют, как спроектировать организационную структуру и шаблоны хранения/доступа к данным управления доступом (привилегиями). Они также расширяют стандартные JAAS-модули/процессы (Java Authentication and Authorization Service) в контексте коммунальной модели.
• Общие J2EE-артефакты представляют, как изолировать и настроить ресурсы пользовательского интерфейса и бизнес-логики для арендаторов через неявный механизм, основанный на фильтрах.
• Модель персистентности данных идентифицирует и оценивает все потенциальные коммунальные шаблоны проектирования хранения/доступа к данным со многих точек зрения, таких как изоляция, защищенность, настраиваемость и производительность.
• Бизнес-процесс представляет, как изолировать и настроить выбор пользователей/ролей заданий для пользователей или процессов между арендаторами в совместно используемом шаблоне процесса.

Общее описание архитектуры и реализации этих функциональных возможностей будет приведено в четвертой части данной серии статей.

Коммунальный шаблон проектирования (использование одного общего экземпляра приложения для одновременной поддержки нескольких арендаторов) является очень важным для реализации Web-приложений с точки зрения рентабельности. В данной части мы рассмотрели общие принципы проектирования архитектуры и связанные с этим технологии разработки защищенного и настраиваемого коммунального приложения с использованием промежуточного программного обеспечения от IBM. За этим обзором последует серия статей, в которых будет представлена более подробная информация по данной теме.

Научиться

Получить продукты и технологии

• Загрузите ознакомительные версии продуктов IBM и познакомьтесь с инструментальными средствами разработки приложений и продуктами промежуточного уровня DB2®, Lotus®, Rational®, Tivoli® и WebSphere®.
  
  

Обсудить

Бо Гао (Bo Gao) работает инженером-исследователем в IBM China Research Lab, расположенной в Пекине (Китай). Занимается сервисами следующего поколения и технологией Massive Multi-tenancy в области SaaS (Software as a Service). Имеет богатый опыт работы с типичным стеком программного обеспечения SOA от IBM.

Чан Джи Гуо (Chang Jie Guo) работает исследователем в IBM China Research Lab, расположенной в Пекине (Китай). Занимается сервисами следующего поколения и некоторыми ключевыми технологиями в области Software as a Service (SaaS), включая Massive Multi-tenancy, гибкое управление бизнес-процессами (business process management - BPM) и Web 2.0.

Вэн Хао Ан (Wen Hao An) работает инженером-программистом в IBM China Research Lab, расположенной в Пекине (Китай). Занимается сервисами следующего поколения и технологией Massive Multi-tenancy в области SaaS (Software as a Service).

Вэй Сун (Wei Sun) работает исследователем в IBM China Research Lab, расположенной в Пекине (Китай). Занимается сервисами следующего поколения и исследовательскими проектами, связанными с технологиями Business Process Services, Software as Services и Web 2.0.

Помощь по сообщениям о нарушениях

Спасибо. Эта запись была помечена для модератора.

Помощь по сообщениям о нарушениях

Сообщение о нарушении не было отправлено. Попробуйте, пожалуйста, позже.

developerWorks: вход

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

Вся введенная информация защищена.

Выберите ваше отображаемое имя

При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Вся введенная информация защищена.

SITE_ID=40

Zone=SOA и Web-сервисы

ArticleID=450922

ArticleTitle=Разработка и развертывание коммунальных Web-решений при помощи программного обеспечения IBM : Часть 3. Общее использование ресурсов

publish-date=11302009