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

Web-решения, использующие модель SaaS (Software as a Service - программа в виде сервиса), которая позволяет пользователям подписываться на программу и обращаться к ней через сайт провайдера сервиса, а не покупать лицензию на установку ее в своем офисе, могут предложить интересные бизнес-преимущества для предприятий любого размера. Разработчики, проектирующие новые решения или преобразующие существующие, и провайдеры сервисов, развертывающие эти решения, сталкиваются с несколькими техническими проблемами. Одним из примеров является "коммунальная" модель совместного использования (multitenancy), когда один экземпляр программного обеспечения, работающий в компьютерах провайдера сервисов, обслуживает несколько организаций. В данной серии статей рассматриваются различные шаблоны решения этих проблем, часто использующие технологию сервис-ориентированной архитектуры (Service-Oriented Architecture - SOA). Также рассматривается информация о том, как программные продукты IBM® могут помочь в создании и развертывании масштабируемых, настраиваемых, рентабельных коммунальных Web-решений для совместного использования.

Герман Гольдшмидт, почётный инженер, IBM

Д-р Герман Гольдшмидт (German Goldszmidt) - почётный инженер в IBM Software Group, занимающийся архитектурой интегрированной платформы для доставки, настройки и развёртывания составных бизнес-сервисов SOA. Ранее он работал исследователем в Исследовательском центре имени Т. Дж. Уотсона компании IBM и руководил проектированием и реализацией некоторых технологий, в том числе Océano (прототип электронной утилиты для автономных вычислений) и Network Dispatcher (компонент для балансировки нагрузки, входящий в состав продуктов WebSphere).



Индраит Поддар (Indrajit Poddar), инженер-программист и консультант, IBM

фото авораИндражит Поддар (Indrajit Poddar) состоит в команде по разработке стратегии, технологии, архитектуры и доработки отдела групповых программных стратегий компании IBM (Software Group Strategy), в которой он занимается концепцией интегрирования при создании составных бизнес-сервисов. Он имеет степень магистра по информатике и вычислительной технике (диплом Университета штата Пенсильвания) и бакалавра по информатике и вычислительной технике (Индийский технологический институт, Хагагпур, Индия). Он также был призером IBM за выдающиеся достижения в технологии 2005 года за вклад в диагностическую систему разгрузки памяти (memory dump) в инструментарии Java.



30.12.2009

Что такое коммунальная модель (multitenancy), каковы ее преимущества и недостатки?

Способность доставлять программное обеспечение нескольким организациям-клиентам (или арендаторам), используя один общий экземпляр программы, является важным требованием для Web-решений. Например, представьте себе простое банковское приложение, предлагаемое в виде сервиса провайдером банковского сервиса. Коммунальная модель в данном контексте означает способность предложить банковский сервис нескольким банкам, используя один общий экземпляр банковского приложения. На рисунке 1 продемонстрирован коммунальный банковский сервис, предлагаемый двум банкам - 1st Bank N.A. и 2nd Canada Bank. Этот сервис поддерживается общими серверами приложений, базами данных, операционными системами и физическими серверами.

Рисунок 1. Пример коммунального Web-сервиса для банков, созданного с использованием общего аппаратного обеспечения и программ промежуточного уровня
Рисунок 1. Пример коммунального Web-сервиса для банков, созданного с использованием общего аппаратного обеспечения и программ промежуточного уровня

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

Однако коммунальная модель несет в себе потенциальные проблемы, например:

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

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

Другим подходом к созданию коммунальной архитектуры является виртуализация на уровне операционной системы (ОС). Например, VMWare, Xen или OpenVZ обеспечивают работу нескольких виртуальных экземпляров операционной системы на одном общем аппаратном обеспечении. Каждый экземпляр виртуальной ОС может выполнять приложения для какого-либо арендатора. Еще одним подходом является установка барьеров на уровне операционной системы для каждого арендатора. Например, каждое приложение могло бы выполняться на новом экземпляре (другой процесс операционной системы) сервера приложений IBM WebSphere® Application Server.


Технические проблемы коммунальной модели

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

К техническим проблемам, с которыми сталкиваются разработчики решений, относятся:

  • Управление доступом. Как можно распределить между арендаторами ресурсы приложения (например, виртуальные порталы, таблицы базы данных, потоки работ, Web-сервисы, J2EE-артефакты (Java™ 2 Platform, Enterprise Edition)), чтобы пользователи одного арендатора, могли обращаться к экземплярам ресурсов, принадлежащим только этому арендатору? Например, как можно гарантировать, что пользователи других банков (например, 1st Bank N.A.) не смогут обратиться к ресурсам (например, к виртуальному порталу), принадлежащим банку 2nd Canada Bank?
  • Настраиваемость:
    • База данных. Как настроить схему базы данных для одного арендатора без влияния на схемы остальных арендаторов? Например, как добавить новое поле данных в общую таблицу базы данных профилей клиентов для банка 2nd Canada Bank, не затрагивая определение схемы для банка 1st Bank N.A.?
    • Интерфейс пользователя. Как настроить внешний вид Web-сайта исключительно через конфигурационные файлы (то есть без изменения кода)? Например, как гарантировать способность администраторов банка 1st bank N.A. и банка 2nd Canada Bank настраивать различные проекты и отображать дополнительные поля в портлетах профилей своих клиентов?
    • Бизнес-логика. Как разрешить настройку бизнес-логики для каждого арендатора без изменения кода? Например, как банк 1st Bank N.A. может использовать минимальный кредитный балл для автоматического отклонения заявок на получение ссуды, отличный от используемого банком 2nd Canada Bank?
    • Потоки работ. Как разрешить банкам-арендаторам настраивать назначение заданий для пользователей и другие условные задания в общих потоках работ? Например, как банк 1st Bank N.A. может гарантировать, что задания по утверждению заявок на получение ссуды в общем потоке работ назначаются только сотрудникам банка 1st Bank N.A.?
  • Управление созданием среды для нового арендатора (tenant provisioning). Как автоматизировать процесс создания среды для нового арендатора? Например, как добавить в рабочую среду новый банк 3rd Fairfield Trust с минимальными ручными усилиями (как, например, автоматизировать создание нового поддерева или базы данных LDAP, создание нового виртуального портала, развертывание новых экземпляров портлетов, регистрацию новых схем IBM DB2® XML)?
  • Измерение показателей использования. Как регистрировать факт использования сервиса так, чтобы спрашивать с каждого арендатора только за использование сервиса? Например, как администратор провайдера банковского сервиса может регистрировать использование сервиса арендаторами (банками 1st Bank N.A. и 2nd Canada Bank) с целью определения количества активизаций их клиентами приложения обработки заявок на получение ссуд?

К техническим проблемам, с которыми сталкиваются провайдеры сервисов, относятся:

  • Общее использование базы данных, настройка, резервное копирование и восстановление специфических для арендаторов данных. Как провайдерам сервисов выбрать одну из схем сегментирования базы данных, основанных на критерии производительности, управляемости и масштабируемости? Например, как провайдер сервиса может обеспечить требования банка 2nd Canada Bank по резервному копированию только его данных из таблиц, совместно используемых несколькими арендаторами?
  • Быстрая реализация коммунальной модели для существующих Web-сервисов. Как предоставить коммунальную функциональность обычным реализациям Web-сервисов с небольшими изменениями кода или вообще без них? Например, как можно реализовать коммунальную функциональность для обычного сервиса проверки кредитоспособности без изменения кода интерфейса Web-сервиса и реализации?
  • Управление подключаемостью большого количества сторонних провайдеров сервисов и потребителей сервисов в разных подразделениях на большом предприятии. Направления деятельности (lines of business - LOB) на больших предприятиях демонстрируют множество характеристик арендатора Web-приложения. Различные LOB на одном и том же предприятии могут потреблять сервисы различных сторонних или внутрикорпоративных провайдеров сервисов. Большое количество таких провайдеров сервисов может привести к проблемам управления в центральном информационном отделе предприятия. Например, различные LOB (кредитный отдел или отдел, занимающийся залогом недвижимости) предприятия провайдера банковских сервисов могут использовать различных провайдеров сервиса проверки кредитоспособности. Как центральный информационный отдел может отслеживать, авторизовать и измерять показатели использования нескольких сервисов проверки кредитоспособности различными подразделениями предприятия?
  • Масштабируемость, эффективное использование аппаратного обеспечения и специфичное для арендаторов качество сервиса (quality of service - QoS). Как провайдеры сервисов могут улучшить использование аппаратного обеспечения, разделяемого между различными арендаторами, и обеспечить масштабируемость? Как провайдеры сервисов могут предлагать различные показатели QoS для различных арендаторов? Например, как бы вы реализовали дифференцированное требование банка 2nd Canada Bank по качеству сервисов, заключающееся в размещении его сервисов на выделенном аппаратном обеспечении, с целью получения более высокой платы за использование сервисов?

Шаблоны решения технических проблем обеспечения коммунальной функциональности

Для решения технических проблем, связанных с коммунальной моделью, можно применить несколько методик построения SOA.

Шаблоны для разработчиков решений

На рисунке 3 показано, как различное промежуточное программное обеспечение IBM в стеках начального уровня и корпоративного уровня реализует эту многоуровневую функциональность.

Рисунок 3. Промежуточное программное обеспечение IBM, используемое для реализации функциональных уровней в примере коммунального приложения
Рисунок 3. Промежуточное программное обеспечение IBM, используемое для реализации функциональных уровней в примере коммунального приложения

Данная серия статей создана на основе упомянутых выше статей и демонстрационных материалов. В ней рассматриваются некоторые технологии повышенного уровня сложности, используемые для создания коммунальных приложений при помощи промежуточного программного обеспечения IBM. Например, в одной из статей демонстрируется, как изолировать задания для пользователей в общих коммунальных потоках работ в WebSphere Process Server. В другой статье рассказывается, как использовать продукт Tivoli Usage and Accounting Manager для реализации измерения активности использования и биллинговых решений.

Шаблоны для провайдера сервисов

  • Выбор правильного уровня изоляции данных для возможной настройки и облегчения управления коммунальными данными. Провайдеры сервисов могут выбрать:
    • Изоляцию данных каждого арендатора в различных базах данных.
    • Изоляцию данных каждого арендатора в отдельных таблицах и схеме.
    • Общее использование одного и того же набора таблиц и схемы всеми арендаторами.
    При совместном использовании схемы несколькими арендаторами настройка полей данных для каждого из них является непростой задачей. В готовящейся статье данной серии оценивается набор шаблонов, решающих эту задачу с разных точек зрения, включая производительность, управление и масштабируемость. Демонстрируются также некоторые методики улучшения управляемости, например, показывается, как реализовать резервное копировании и восстановление данных конкретного арендатора при совместном использовании схемы всеми арендаторами.
  • Быстрая реализация коммунальной модели для существующих Web-сервисов при помощи IBM WebSphere Enterprise Service Bus, IBM WebSphere Business Services Fabric или IBM WebSphere DataPower® SOA Appliances. Провайдерам сервисов может понадобиться быстро реализовать коммунальную модель для существующих реализаций Web-сервисов. Изменение кода в существующих реализациях для поддержки коммунальной модели может потребовать значительных усилий. В качестве альтернативы можно создать основанный на промежуточном программном обеспечении посреднический уровень для реализации оконечных точек различных Web-сервисов, предназначенных для запросов сервисов различными арендаторами. В этом случае реализацию существующего Web-сервиса менять не нужно. В готовящейся статье данной серии демонстрируется, как можно реализовать этот шаблон, используя WebSphere Business Services Fabric, WebSphere Enterprise Services Bus и WebSphere DataPower SOA Appliances.
  • Маршрутизация запросов на активизацию сторонних SaaS-сервисов на большом предприятии через централизованный посреднический уровень. Отдел информационных технологий предприятия может использовать централизованный посреднический уровень для маршрутизации запросов на активизацию всех сторонних сервисов из различных подразделений предприятия. Такой тип посреднического уровня может обеспечить дополнительные функции, такие как авторизация, мониторинг и измерение активности использования сервисов. В готовящейся статье данной серии демонстрируется, как шаблон посредничества, основанный на корпоративной шине сервисов (enterprise service bus - ESB), может поддерживать требования такого типа.
  • Масштабирование с использованием промежуточного программного обеспечения начального уровня и улучшение эффективности использования аппаратного обеспечения при помощи IBM WebSphere Application Server, Extended Edition. Требованиям по обеспечению масштабируемости часто не уделяется должного внимания на начальных этапах разработки. Когда они становятся важными, провайдеры сервисов часто выполняют горизонтальное масштабирование, используя большее количество дешевых серверов. Однако такое масштабирование может быть причиной других проблем. Например, такой подход может привести к:
    • Избыточности аппаратного обеспечения для поддержки редких пиковых нагрузок при небольшом количестве арендаторов.
    • Повышению сложности управления из-за большого числа экземпляров промежуточного программного обеспечения.
  • Изоляция приложений для различных арендаторов и поддержка специфичных требований по QoS при помощи WebSphere Application Server, Extended Edition. Провайдеры сервисов могут изолировать приложение арендатора на выделенном аппаратном обеспечении и запускать приложения других арендаторов на общем аппаратном обеспечении, используя стратегии изоляции сервера в IBM WebSphere Extended Deployment. Кроме того, разработчики решений могут воспользоваться преимуществами программной модели функциональности WebSphere Partitioning Facility в WebSphere Extended Deployment для создания коммунальных приложений. В готовящейся статье демонстрируется, как можно использовать WebSphere Extended Deployment для поддержки специфичных для арендатора требований к QoS и сегментировать приложения для поддержки коммунальной модели.

Заключение

Масштабируемая коммунальная модель является важным требованием для Web-решений (SaaS). Однако создание коммунальных решений сталкивается с некоторыми техническими проблемами. Используя промежуточное программное обеспечение IBM, разработчики решений и провайдеры сервисов могут создавать и развертывать масштабируемые, настраиваемые, управляемые и рентабельные коммунальные решения. В данной серии статей представляются некоторые функциональные возможности и методики промежуточного программного обеспечения IBM, а также рассказывается, как применить их для решения упомянутых выше технических проблем. Оставайтесь на связи!

Ресурсы

Научиться

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

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

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

Выберите имя, которое будет отображаться на экране



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

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

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы
ArticleID=459923
ArticleTitle=Разработка и развертывание коммунальных Web-решений при помощи программного обеспечения IBM промежуточного уровня: Часть 1.Проблемы и архитектурные шаблоны
publish-date=12302009