Разработка составных бизнес-сервисов на базе сервис-ориентированной архитектуры (SOA): Часть 7. Поддержка множественной принадлежности для составных бизнес-сервисов

В предыдущих статьях серии мы ввели понятие составных бизнес-сервисов (CBS) и описали некоторые необходимые для них ключевые элементы среды развертывания. Множественная принадлежность (multi-tenancy) - это способность обслуживать несколько организаций (клиентов) в среде хостинга совместного использования. В данной статье описано понятие множественной принадлежности и подход к программному обеспечению как к сервису, основанному на сетевой доставке (network-delivered approach).

Эмбер Рой-Чаудхури, старший инженер-программист, IBM

Эмбер Рой-Чаудхури (Amber Roy-Chowdhury) - старший инженер-программист компании IBM, работающий в её отделении в Северной Каролине, Рисерч Трайэнгл-Парк. Он занимается архитектурой и разработкой WebSphere Portal. Сейчас он архитектор и технический руководитель брокерской коммуникационной сети, известной как Property Broker. Ранее Эмбер работал на ведущих должностях при разработке WebSphere Application Server и Encina Transaction Processing Monitor. Эмбер получил степень доктора в Университете Иллинойса, г. Урбана-Шэмпейн.



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

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



Карл Осипов, архитектор ПО, IBM

Карл Осипов (Carl Osipov) - архитектор ПО, подразделениe стратегий и технологий IBM Software Group. Обладает большим опытом в области распределенных вычислений, разработке приложений по распознаванию живой речи и компьютерной обработке естественного языка. Имеет ряд публикаций и выступлений по вопросам Сервис-ориентированной архитектуры и управлением разпознования речи перед образовательской и бизнес аудиторией. На данный момент он в основном занимается проектированием технологий повторного использования для составных бизнес-сервисов.



01.12.2008

Введение

В предыдущих статьях серии мы ввели понятие составных бизнес-сервисов (CBS) и описали некоторые необходимые для них ключевые элементы среды развертывания. В данной статье описано понятие множественной принадлежности - способности обслуживать несколько организаций (клиентов) в среде хостинга совместного использования. Также описан подход к программному обеспечению как к сервису (software-as-a-service - SaaS), основанному на сетевой доставке и объяснены принципы и технические процессы, которые поддерживают множественную принадлежность в хостинговой среде Saas. В данной статье предлагается реализация платформы с множественной принадлежностью, в которой используется WebSphere® Process Server и Portal, виртуальные порталы, а также шаблон реализации clone-and-configure для портлетов. В этом примере также показаны изменения в реализации портлетов, поддерживающие расширенную информацию профилей для ролей портала. Данная статья посвящена изменениям дизайна программных сервисов и основанных на портлетах пользовательских интерфейсов, направленным на поддержку подписчиков и конечных пользователей.

Множественная принадлежность

В модели доставки сервисов SaaS, которую также называют ПО "по требованию", например, сервисов, описываемых на языке WSDL, процесс основан на сетевом доступе к ПО сервис-провайдера. Этот подход противоположен традиционному, при котором коробочное программное обеспечение поставляют с механизмом установки. Как правило, сервис-провайдер содержит свои программы в большом центре данных и осуществляет их доставку через Интернет. Хотя примеры нашей статьи основываются на конкретном случае, в котором провайдер сервиса представляет собой независимую фирму, он также может являться подразделением более крупного предприятия.

На рисунке показан пример SaaS. Здесь сервис-провайдер по открытию банковского счёта (Bank Account Opening) хранит на сервере реализацию сервиса открытия счета, а подписчиками (арендаторами) сервиса являются банки, в данном случае Первый банк NA и Второй канадский банк. В свою очередь, каждый из этих банков поставляет своим клиентам специально настроенный под конкретный банк сервис открытия счета.

Рисунок 1. Пример SaaS
Пример SaaS

Подробные примеры ролей в ПО для банковских сервисов SaaS описаны в статье Разработка составных бизнес-сервисов на базе сервис-ориентированной архитектуры (SOA), часть 1: Разработка составных приложений на базе SOA для запуска бизнес-сервисов. В первой части способность поддержки нескольких подписчиков (арендаторов) бизнес-сервиса из одной общей хостинговой среды сервис-провайдера называется множественной принадлежностью.

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

По существу, все варианты использования платформы с множественной принадлежностью можно свести к следующим:

  • Нет общего использования
  • Общим является сам сервер
  • Общее использование приложения

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

  • Общая только инфраструктура поддержки, осуществляемая такими продуктами, как Tivoli® Provisioning Manager
  • Общая система безопасности, например, Tivoli Access Manager и WebSeal
  • Общие сервисы баз данных, например, через DB2
  • Общее связующее ПО, например, серверы приложений, процессов и порталов

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

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

Рисунок 2. Сервисы для составных приложений
Сервисы для составных приложений

Корпоративные сервисы

В приведенном в данной статье примере платформы множественной принадлежности при создании инфраструктуры для составных бизнес-сервисов (CBS) использовались следующие продукты:

  • WebSphere Portal
  • WebSphere Process Server
  • WebSphere Service Registry and Repository
  • DB2
  • Набор продуктов Tivoli, в том числе Directory Server
Рисунок 3. Архитектура составных бизнес-сервисов
Архитектура составных бизнес-сервисов

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

  • На сервере каталогов LDAP (Tivoli Directory Server) надо создать выделенную область действий. У этой области заранее определяется каталог структур, ожидаемый WebSphere Portal.
  • Подписчику необходимо назначить идентификатор (ID) его учетной записи. Этот идентификатор используется с функцией виртуального портала WebSphere Portal и является частью уникального URL-адреса, служащего подписчику адресом Web-канала.
  • Для каждого банка надо разработать темы и скины, определяющие внешний вид и функции виртуального портала подписчика, а также отдельных портлетов. Эти темы и скины необходимо установить на WebSphere Portal, на котором запущена платформа множественной принадлежности.

Сервисы представления

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

  • Адрес канала предоставляет конечным пользователям точку входа в платформу. Например, адресом Web-канала может служить уникальный URL, а для IVR-канала можно использовать и бесплатный телефонный номер.
  • Изолированность подписчика гарантирует, что пользователи отдельных подписчиков не могут получить доступ к бизнес-сервису и информации о других подписчиках данной платформы. Например, в ситуации, когда у одного провайдера банковских сервисов, SaasBank, есть два подписчика на банковские сервисы: Первый банк NA и Второй канадский банк. В этом примере, когда клиент Первого банка NA входит в платформу через Web-сайт, клиент должен пройти процедуру аутентификации по списку пользователей Первого банка NA, а не Второго канадского банка или банка SaasBank.
  • Фирменное оформление продукта обеспечивает, что когда конечный пользователь получает доступ к адресу канала, он попадает в среду, которую настроили именно для данного подписчика. Например, после входа в систему клиента Первого банка NA пользовательский интерфейс определяется конкретным банком, а настройки внешнего вида и функций (размещение элементов, определенный скин и т. д.) должны быть уникальными для данного банка.

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

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

Для выполнения вышеизложенных требований к конфигурации, при реализации и развертывании портлетов в приложениях множественной принадлежности можно использовать метод clone-and-configure (клонирование+конфигурация). WebSphere Portal допускает клонирование отдельных портлетов, развернутых на сервере. Для каждого файла WAR, содержащего код портлета, можно создать клон или копию портлета с различными конфигурационными опциями. Для обеспечения поддержки различных установок для каждого подписчика администратор сервис-провайдера должен клонировать портлеты для каждого подписчика и настроить авторизацию на портале таким образом, чтобы подписчики имели доступ только к своим клонам. Кроме того, администратор сервис-провайдера предоставляет дополнительные права администраторам подписчика, чтобы дать им полномочия конфигурировать клонированные портлеты.

Например, в банковском приложении с множественной принадлежностью можно представить себе портлет, в котором используется конечный пользовательский интерфейс сервиса Funds Transfer. Если воображаемый сервис-провайдер банка SaasBank захочет предоставить портлет Funds Transfer Второму канадскому банку, он должен будет выполнить следующие шаги для использования метода клонирование+конфигурация:

  1. Открыть в Консоли администратора (Administrative console) группу WebSphere Portal Portlet Management.
  2. Включив опцию Manage Portlets, найти и создать клонированную копию портлета Funds Transfer.
  3. Используя Resource Permissions в Консоли администратора, найти клон портлета Funds Transfer.
  4. Добавить администратора подписчика из Второго канадского банка в качестве администратора портлета Funds Transfer.

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

  1. Найти портлет Funds Transfer, перейдя в Консоли администратора к > Portlet Management > Manage Portlets.
  2. Открыть окно конфигурации портлета Funds Transfer и указать идентификатор учетной записи подписчика Второго канадского банка.
  3. Проанализировать и при необходимости изменить остальные настройки портлета Funds Transfer, например, конечные точки сервиса.

Бизнес-сервисы

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

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

Передача идентификатора подписчика с уровня представления на уровень бизнеса имеет два следствия для реализации бизнес-сервиса. Во-первых, в WSDL-интерфейсе, а именно в схеме сообщений для потока входных данных сервиса в качестве одного из параметров должен содержаться идентификатор подписчика. Например, в нижеприведенном фрагменте кода идентификатор подписчика реализован как переменная с именем bankID. Это часть сообщения processLoan, использованного в примере бизнес-процесса по оценке кредитного заявления.

Листинг 1. Пример максимально расширенного кода
<!-- 
    <wsdl:types>
    <schema elementFormDefault="qualified" 
	  targetNamespace="http://process91958946.www.example.com" 
	  xmlns="http://www.w3.org/2001/XMLSchema"
	  xmlns:impl="http://process91958946.www.example.com" 
	  xmlns:intf="http://process91958946.www.example.com" 
	  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
	  xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <element name="processLoan">
    <complexType>
     <sequence>
      <element name="bankId" nillable="false" type="xsd:string"/>
      <element name="loanAmount" nillable="true" type="xsd:decimal"/>
      <element name="customerId" nillable="true" type="xsd:string"/>
      <element name="ssn" nillable="true" type="xsd:string"/>
     </sequence>
    </complexType>
   </element>
   <element name="processLoanResponse">
    <complexType>
     <sequence/>
    </complexType>
   </element>
  </schema>
 </wsdl:types>

Во-вторых, чтобы гибко реагировать на разных подписчиков и конечных пользователей, реализация сервисов на коммерческом уровне нуждается в идентификаторе подписчика. У платформы с множественной принадлежностью на основе WebSphere Process Server (WPS) имеется несколько возможностей добавления вариативности в реализацию сервиса. Например, бизнес-процесс, созданный с помощью WebSphere Business Modeler, можно дополнить указаниями на точки вариативности, транслируемые в бизнес-правила BPEL, пригодные для выполнения на WPS. Есть и другой вариант: указать бизнес-правила непосредственно в рабочих потоках BPEL, с помощью WebSphere Integration Developer и без участия WebSphere Business Modeler. Например, одно правило в процессе оценки кредитного заявления может использовать разные кредитные баллы на стадии предварительного одобрения по кредитованию. К примеру, автоматические одобрения генерируются в случае с Первым банком NA - для заявителей, имеющих кредитный балл более 720, а для клиентов Второго канадского банка требуется балл не менее 750.

Заключение

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

Ресурсы

Научиться

Обсудить

Комментарии

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=355452
ArticleTitle=Разработка составных бизнес-сервисов на базе сервис-ориентированной архитектуры (SOA): Часть 7. Поддержка множественной принадлежности для составных бизнес-сервисов
publish-date=12012008