Введение

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

Данная статья является первой в серии из четырех статей, исследующих сценарий из реальной жизни - систему резервирования для здравоохранения. Архитектура системы является сервис-ориентированной (Service-Oriented Architecture - SOA) с применением WebSphere Enterprise Service Bus. В данной статье приведены пошаговые инструкции по расширению системы для реализации новой функциональности, основанной на системе обмена сообщениями промежуточного уровня, использующей WebSphere DataPower SOA Appliances, чтобы гарантировать конфиденциальность данных.

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

• Часть 1, в которой предполагается наличие у читателя базовых знаний Web-сервисов и которая ориентирована на использование сообщений интегрированной среды, предоставляет полный обзор сценария и, следовательно, показывает принятое решение с архитектурной точки зрения.
• Часть 2 охватывает аспекты защищенности системы, шифрования данных, управления сертификатами и системы WebSphere DataPower SOA Appliances. В ней подробно рассказывается, что происходит за кулисами процессов, а также объясняется процесс настройки системы WebSphere DataPower SOA Appliances и функции ее расширения для внедрения инфраструктуры с открытыми ключами (Public Key Infrastructure - PKI).
• Часть 3 предоставляет подробное описание модуля-посредника Enterprise Service Bus (ESB) и действия по настройке ESB на работу с конфиденциальной информацией.
• Часть 4 посвящена клиентской стороне приложения, принимающего JMS-сообщения (Java™ Message Service) из Enterprise Service Bus и дешифрующего важные данные для реконструкции оригинального сообщения.

В начало

Система резервирования для здравоохранения

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

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

Система резервирования, как показано на рисунке 1, включает в себя централизованную систему резервирования и локальные системы, управляемые отдельными учреждениями. Централизованная система предоставляет интерфейс Web-сервисов для добавления нового центра здравоохранения (registerNewPartner). Каждый центр, в свою очередь, должен реализовать набор интерфейсов Web-сервисов для взаимодействия с централизованной системой резервирования (makeReservation, queryReservation, cancelReservation).

То есть мы идентифицировали двух различных актеров (actor), взаимодействующих с системой:

• Партнер (partner) выполняет базовый набор административных задач, таких как регистрация новых партнеров и публикация расписания.
• Пациент (patient) представляет собой обычного пользователя системы резервирования, который запрашивает систему с целью записи на прием или переноса уже запланированной встречи.

На рисунке 1 показаны основные потоки действий.

Давайте рассмотрим рисунок 1 подробно:

1. Учреждение, которое хочет воспользоваться преимуществами, предоставляемыми централизованной системой резервировании, может зарегистрировать себя в роли партнера и предоставить список сервисов и доступных временных интервалов, в которые пациенты могут записаться на прием (красный цвет): партнеры взаимодействуют с системой, используя интерфейс Web UI (1.1), активизируется registerNewPartner (1.2) и данные сохраняются в базу данных централизованной системы резервирования (1.3).
2. Пациент вводит всю необходимую информацию в исходную форму (2.1) и получает список доступных вариантов, соответствующих критерию поиска (синий цвет).
3. Пациент подтверждает запрос на резервирование (3.1), используя Web UI. Централизованная система резервирования (3.2) должна в интерактивном режиме транзакций найти партнерские сервисы доступных провайдеров, соответствующие требованиям пациента. Эта задача решается шиной WebSphere Enterprise Service Bus, которая позволяет реализовать более высокий уровень абстракции, скрывая детали месторасположения сервиса и обеспечивая посреднические функции, динамический поиск, маршрутизацию и поддержку ведения журналов регистрации событий (3.3). Система направляет запрос провайдеру сервиса на утверждение (то есть активизирует Web-сервис makeReservation) (3.4) и, наконец, подтверждает резервирование пациенту.

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

Мы должны рассмотреть следующие вопросы:

• Медицинские офисы обычно не всегда находятся в режиме онлайн, поэтому надежная доставка расписания должна быть гарантирована, даже если клиенты временно находятся в отключенном состоянии.
• Поскольку медицинские офисы могут быть подключены к сети по медленным каналам, количество передаваемых данных должно быть ограничено.
• Данные, содержащиеся в расписании, являются строго конфиденциальными, поэтому они должны быть защищены каким-либо способом. Конфиденциальность в асинхронном сценарии обеспечить непросто, поскольку PKI-методики, используемые при прямом взаимодействии между клиентом и провайдером сервиса, применить нельзя. Для прямых взаимодействий (один к одному), безусловно, можно использовать открытый ключ сервиса. Но при работе с несколькими провайдерами сервисов возникает вопрос: с каким открытым ключом системе нужно выполнять шифрование?

В начало

Поиск решения

Поскольку данный сценарий явно асинхронный, он хорошо подходит для реализации через парадигму системы обмена сообщениями. Фактически, используя ориентированную на сообщения промежуточную систему, обычно можно использовать преимущества расширенных функциональных возможностей, гарантирующих надежную доставку сообщений даже при временном отключении клиентов (медицинских офисов). Эти функциональные возможности обычно не доступны при использовании однонаправленного взаимодействия на основе Web-сервисов. В свете этих соображений ESB отлично походит для данного сценария, поскольку она не только гарантирует основанное на сообщениях взаимодействие, но и обеспечивает прозрачные возможности переключения транспортного протокола. Эти возможности используют преимущества концепции связываний (bindings), которые могут быть определены для сервисов внутри ESB. Через эти связывания пользователь может предоставить шине ESB специфичные для протокола параметры, управляющие входящими и исходящими сообщениями. Связывание экспорта (export binding) описывает, как клиент взаимодействует с модулем-посредником. Связывание импорта (import binding) описывает, как модуль-посредник взаимодействует с определенным сервисом. Эти связывания дают возможность подключиться к медицинским офисам, не добавляя какую-либо логику взаимодействия в прикладной код. Для реализации описанного сценария мы определили модуль-посредник и соединили его с SOAP/HTTP-связыванием экспорта и JMS-связыванием импорта, как показано на рисунке 2.

Таким образом, модуль-посредник осведомлен о получении сообщений по протоколу SOAP/HTTP и необходимости преобразования этих сообщений в соответствии с требованиями протокола JMS. Связывание импорта позволяет пользователю указать адресат, которому нужно передать сообщение. Этот адресат может быть темой или очередью, в зависимости от прикладной области. Преимущество использования очередей заключается в предоставлении специализированного коммуникационного канала между запросчиком сервиса и провайдером сервиса, а недостаток состоит в необходимости настройки на ESB очередей, по одной для каждого развернутого провайдера сервиса. Использование темы устраняет массу работы по настройке очередей, но, в то же время, имеет недостаток, заключающийся в необходимости регистрации на тему всех медицинских офисов для прослушивания поступающих в нее сообщений. Таким образом, медицинский офис может получать также сообщения, предназначенные другим провайдерам, и это может стать проблемой, поскольку возникают вопросы, связанные с обеспечением конфиденциальности и насыщением полосы пропускания. Позднее в данной статье вы увидите практическое решение обоих этих ограничений. Это решение описывается здесь с архитектурной точки зрения, но все подробности, связанные с аспектами технической реализации и настройки, можно найти в третьей части данной серии статей.

В начало

Предотвращение насыщения полосы пропускания при помощи селекторов сообщений

Спецификации JMS предоставляют возможность определять сообщения, использующиеся в качестве фильтров для предоставления JMS-клиенту информации о сообщениях, которые он должен обрабатывать (только те сообщения, которые предназначены для него). Эту информацию можно поместить в какой-нибудь не зарезервированный JMS-заголовок (например, в JMSType) или дополнительные JMS-свойства перед направлением сообщения в JMS-тему. В данном сценарии каждый провайдер сервиса уникально идентифицируется посредством кода serviceProviderId. Система централизованного резервирования имеет список, содержащий эти идентификационные коды, по одному на каждого провайдера сервиса. Когда система резервирования собирается передать обновленное расписание провайдеру сервиса, она подготавливает SOAP-сообщение (позднее вы увидите, как оно форматируется), добавляет нужный идентификационный код в тело сообщения и направляет его в ESB. Поскольку ESB ответственна за преобразование этого сообщения в JMS-трафик и перенаправление его в предопределенную тему, резонно реализовать определенную логику внутри ESB для добавления этих идентификационных кодов в заголовок JMS-сообщения, используя, таким образом, serviceProviderId, содержащийся в теле сообщения, в качестве селектора сообщения. К счастью, ESB предоставляет промежуточный примитив message element setter, который можно использовать для проверки формата входящего сообщения и добавления некоторой информации в заголовок исходящего сообщения. Этот примитив был представлен в WebSphere Enterprise Service Bus V6.0.2 и используется в данном решении для пополнения заголовка JMS-сообщения, как показано на рисунке 3.

Когда модуль-посредник получает сообщение с запросом, он использует примитив message setter для извлечения serviceProviderId из SOAP-тела запроса и, таким образом, сохраняет его (через действие copy) в JMSHeader выходного сообщения. Затем ESB направляет это сообщение в тему, и медицинские офисы гарантировано получают его. Это решение не требует кодирования на ESB-уровне. Вместо этого на клиентской стороне явно необходимо разработать автономное JMS-приложение или управляемый сообщениям bean-компонент для эмуляции взаимодействий медицинского офиса с темой.

В начало

Гарантирование конфиденциальности данных в теме

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

Предполагается, что каждый медицинский офис имеет свой собственный сертификат и публикует его в централизованной системе резервирования. Как это делается, показано на рисунке 5. Как уже говорилось ранее, каждый SOAP-запрос, поступающий в систему резервирования, имеет некоторую информацию в теле сообщения (serviceProviderId), идентифицирующую провайдера, которому сообщение должно быть передано. При получении SOAP-сообщения для конкретного провайдера сервиса централизованная система резервирования анализирует сообщение, получает serviceProviderId и использует его для шифрования сообщения. Естественно, на стороне клиента понять сообщение может только провайдер сервиса с идентификатором serviceProviderId, поскольку он имеет корректный закрытый ключ для выполнения дешифрования. Провайдер сервиса, злонамеренно подписавшийся на тему, не сможет понять сообщение, поскольку не сможет его дешифровать нужным закрытым ключом. Таким образом, для темы может быть гарантирована конфиденциальность, несмотря на то, что на централизованной системе резервирования должна быть реализована определенная логика для шифрования сообщения. Чтобы не писать большой объем кода для выполнения SOAP/XML маршаллизации и демаршаллизации при шифровании сообщения, мы решили использовать механизм SOA и поэтому делегировали системе WebSphere DataPower SOA Appliances ответственность за выполнение стандартного XML-шифрования конфиденциальной части тела SOAP-сообщения.

За получение сертификатов от медицинских офисов и последующую их загрузку в систему WebSphere DataPower SOA Appliances отвечает администратор. WebSphere DataPower SOA Appliances выступает в качестве прокси Web-сервиса; он шифрует входящие SOAP-запросы и передает зашифрованные сообщения в ESB (дальнейшие подробности описаны в следующей статье данной серии).

В начало

Описание решения

Полная архитектура представлена на рисунке 6.

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

Система резервирования готовит расписание для каждого провайдера сервиса, шифрует (через WebSphere DataPower SOA Appliances) важные данные и направляет зашифрованные сообщения в ESB. ESB получает зашифрованные данные, переключает протоколы и выполняет функции посредника. Медицинский офис подписывается на тему. Каждый провайдер сервиса владеет закрытым ключом и использует его для корректного дешифрования своих собственных сообщений, поступающих в тему. Клиент может быть реализован как JMS-клиент или как управляемый сообщениями EJB-компонент.

В начало

Определение конфигурационных свойств темы и JMS-связывания импорта

Данный раздел содержит пошаговые инструкции, которые нужно выполнить для определения JMS-связывания импорта. На рисунке 7 приведено прекрасное графическое представление этого процесса.

Как уже говорилось, ESB получает SOAP/HTTP-запросы и направляет эти сообщения в JMS-тему, прозрачно управляя, таким образом, переключением протоколов. Для этого ESB должна знать имя темы и свойства соединения, и эта информация должна быть предоставлена при определении связывания импорта как JMS-системы обмена сообщениями. Очевидно, что предоставление этой информации требует предварительного выполнения определенной настройки через консоль администратора.

Давайте выполним подробные инструкции для создания и настройки в ESB приведенных ниже компонентов. Здесь мы сконцентрируемся на настройке области темы, темы и фабрики соединений темы. Вы также узнаете, как импортировать область темы.

Настройка области темы

1. Откройте WebSphere Administrative Console системы Enterprise Service Bus.
2. Разрешите все события из соответствующего ниспадающего списка Available task filters, как показано на рисунке 8.
   
   Рисунок 8. Консоль администратора: разрешение событий
   
   
   
3. В навигационной панели слева выберите Service Integration, а затем Buses. Список доступных шин показан на рисунке 9.
   
   Рисунок 9. Консоль администратора: настройка шины
   
   
   
4. Выполните двойной щелчок левой кнопкой мыши на SCA.APPLICATION.esbCell.Bus. Появится новое окно.
5. Выберите Destination Resources > Destinations. Отобразится список определенных на данный момент адресатов шины.
6. Выберите New > Topic Space. Появится новое окно.
7. Введите TopicImportOut в качестве идентификатора. Оставьте во всех остальных полях значения по умолчанию и нажмите кнопку OK (см. рисунок 10).
   
   Рисунок 10. Консоль администратора: фабрика соединений темы
   
   
   
8. Сохраните конфигурацию при запросе.

Настройка темы

Теперь давайте решим специфичные задачи по настройке самой темы:

9. В навигационной панели консоли администратора выберите Resources > JMS Providers > Default Messaging.
10. В появившемся окне оставьте поле scope в значении Node (по умолчанию). Прокрутите страницу до тех пор, пока не увидите разделы Connection Factories и Destination.
11. Нажмите ссылку JMS topic в разделе Destinations (см. рисунок 11).
    
    Рисунок 11. Консоль администратора: тема
    
    
    
12. В появившемся окне нажмите кнопку New для создания новой темы. Затем введите следующие значения:
    • Name: TopicImportOut
    • JNDI name: jms/TopicImportOut
    • Topic space: TopicImportOut
    • Bus name: SCA.APPLICATION.esbCell.Bus
13. Нажмите кнопку OK и сохраните конфигурацию. В области TopicImportOut создастся новая тема, которая показана на рисунке 12.
    
    Рисунок 12. Консоль администратора: новая тема
    
    
    

Создание фабрики конфигурации темы

Теперь мы готовы приступить к созданию фабрики конфигурации темы:

14. Для того чтобы фабрика конфигурации работала, необходимо обеспечить также корректную настройку поля Provider Endpoints. Это поле содержит список оконечных точек, которые должны использоваться для подключения к механизму начальной загрузки. Если вы не хотите иметь дело с нежелательными исключительными ситуациями при подключении к теме через некоторые JMS-клиенты, то должны предоставить эту настройку, согласно следующему соглашению: esbHostName:bootstrapPort:BootstrapBasicMessaging, где:
    • esbHostName - это имя машины, на которой размещена ESB.
    • bootstrapPort - это порт оконечной точки начального загрузчика.
15. Если вы хотите проверить корректность значения этого порта, выберите ссылку Application servers в разделе Server. Затем выберите сервер по умолчанию (server1) и нажмите ссылку ports в разделе communication на странице server details, которая отображается. Появится новое окно вместе со строкой SIB_ENDPOINT_ADDRESS, которая содержит относящуюся к порту информацию (см. рисунок 13).
    
    Рисунок 13. Консоль администратора: порты
    
    
    
16. В навигационной панели консоли администратора выберите Resources > JMS Providers > Default Messaging.
17. Выберите ссылку JMSTopicConnectionFactory в разделе ConnectionFactories. В появившемся окне выберите New для создания новой фабрики соединений темы (см. рисунок 14).
    
    Рисунок 14. Консоль администратора: новая фабрика соединений темы
    
    
    
18. Настройте административную информацию фабрики соединений темы, введя следующие значения (см. рисунок 15):
    • Name: sampleTCF
    • JNDI name: jms/sampleTCF
19. Настройте информацию о соединении фабрики конфигурации темы. После получения всей информации предыдущих этапов выберите следующие значения из ниспадающего списка:
    • Bus name: SCA.APPLICATION.esbCell.Bus
    • Provider endpoints: esbHostName:bootstrapPort:BootstrapBasicMessaging
20. Настройте информацию постоянной подписки фабрики конфигурации темы. В данном сценарии мы решили использовать постоянную тему (durable topic), для того чтобы гарантировать доставку сообщений даже если медицинские офисы временно отключены. Для завершения этого шага вы должны:
    • Предоставить идентификатор клиента, который будет использоваться для всех подключений, созданных с использованием данной фабрики соединений. Эту настройку можно также предоставить программно, но лучше определить ее на этапе настройки. Для нее можно использовать любую строку, которая вам нравится. В примере в качестве идентификатора клиента мы используем ASLID.
    • Предоставить корректный "дом" (home) постоянной подписки, который является именем механизма системы сообщений, используемого для сохранения сообщений, доставленных для постоянной подписки. Укажите полное имя шины сообщений, использующейся для темы. В данном случае это esbNode.server1-SCA.APPLICATION.esbCell.Bus, где esbNode и server1 соответственно являются именами ESB-узла и сервера по умолчанию.
21. Настройте надежность персистентных сообщений фабрики конфигурации темы (см. рисунок 15):
    • Выберите вариант Assured persistent в ниспадающем списке Persistent message reliability.
    • Выберите уровень локализации, используемый для подключений темы. Имеется несколько возможностей, включая Cluster, Always shared и Never shared. Вы можете выбрать одну из них, которая соответствует вашей прикладной области. В данном сценарии мы используем вариант Always shared, для того чтобы сделать тему общедоступной для нескольких JMS-подписчиков.
    
    
    Рисунок 15. Консоль администратора: настройка фабрики соединений темы
    
    
    

Создание области темы импорта

После создания области темы, темы и фабрики соединений темы можно определить новое JMS-связывание импорта и, следовательно, предоставить эту информацию (см. рисунок 16).

Подробную информацию по выполнению этого шага можно найти в третьей статье данной серии. Но нужно отметить, что вы должны выбрать Business Object XML using JMSTextMessage в качестве типа сериализации. Таким способом вы гарантируете, что зашифрованное тело SOAP-сообщения передается в тему в виде XML, а затем оно может быть проанализировано и воссоздано при помощи определенного стандартного алгоритма дешифрования системы защиты XML (как описывается в последней статье данной серии).

В начало

Заключение

В данной статье приведен полный обзор сценария из реальной жизни, связанный с системой резервирования для здравоохранения, и описана выбранная архитектура. Также были приведены пошаговые инструкции по настройке связывания импорта ESB. Следите за выходом второй статьи (EN) данной серии, посвященной другим компонентам, которые вы должны добавить в данное решение.

Ресурсы

Научиться

• Оригинал статьи "Make SOA real with IBM WebSphere Enterprise Service Bus and IBM WebSphere DataPower SOA Appliances, Part 1: Use WebSphere Enterprise Service Bus for protocol switching of encrypted data" (EN).
  
  
• Обратите внимание на следующие книги IBM Redbooks®:
  • Приступаем к работе с WebSphere Enterprise Service Bus V6 (EN).
  • Шаблоны: реализация SOA с использованием Enterprise Service Bus (EN).
  • Подключение корпоративных приложений к WebSphere Enterprise Service Bus (EN).
  • Шаблоны: интеграция Enterprise Service Buses в сервис-ориентированную архитектуру (EN).
  
  
• Дополнительная информация об IBM WebSphere DataPower SOA Appliances (EN).
  
  
• Дополнительная информация об IBM WebSphere Enterprise Service Bus (EN) и страница продукта на developerWorks (EN).
  
  
• В разделе SOA and Web services на сайте IBM developerWorks размещены сотни информативных статей и учебных руководств начального, среднего и повышенного уровня сложности по разработке приложений для Web-сервисов.
  
  
• Попробуйте IBM SOA Sandbox! Усовершенствуйте свои знания SOA на практических примерах IBM SOA entry points.(EN)
  
  
• На Web-сайте IBM SOA размещен обзор SOA и информация о том, как IBM может помочь освоить эту архитектуру (EN).
  
  
• Следите за техническими событиями и web-трансляциями на developerWorks (EN).
  
  
• Книги по данной и другим техническим темам в книжном магазине Safari.(EN)
  
  
• Демонстрационные материалы по Web-сервисам.(EN)
  
  
• RSS-фид по данной серии статей (подробнее о RSS).(EN)
  
  

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

• Разработайте ваш следующий проект, используя пробное программное обеспечение IBM, доступное для загрузки или на DVD.(EN)
  
  

Обсудить

• Примите участие в обсуждении материала на форуме.
  
  
• Подключайтесь к сообществу developerWorks и примите участие в блогах developerWorks, включая следующие блоги, посвященные SOA и Web-сервисам:(EN)
  • Сервис-ориентированная архитектура - неофициально - Сэнди Картер (Sandy Carter).
  • Передовой опыт в сервис-ориентированной архитектуре - Али Арсанджани (Ali Arsanjani).
  • WebSphere SOA и J2EE на практике - Бобби Вульф (Bobby Woolf).
  • Создание SOA-приложений с использованием шаблонов - Эоин Лэйн (Dr. Eoin Lane).
  • Клиентские приложения, задачи и перспективы в SOA - Кэрри Холли (Kerrie Holley).
  • Сервис-ориентированная архитектура и инструментальные средства бизнес-уровня - Саймон Джонстон (Simon Johnston).
  • SOA, ESB и другие - Сэнджей Боуз (Sanjay Bose).
  
  

Об авторах

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Система резервирования для здравоохранения
• Поиск решения
• Предотвращение насыщения полосы пропускания при помощи селекторов сообщений
• Гарантирование конфиденциальности данных в теме
• Описание решения
• Определение конфигурационных свойств темы и JMS-связывания импорта
• Заключение
• Ресурсы
• Об авторах
• Комментарии