Интеграция служб здравоохранения: Часть 1. Использование архитектуры Enterprise Service Bus

Настройка сервера Java Business Integration для обеспечения взаимодействия приложений с различной архитектурой

Чтобы различные приложения, необходимые для оказания медицинской помощи пациентам, могли работать качественно и эффективно, они должны взаимодействовать между собой. В этой первой части серии из двух статей, рассматривается объединение медицинских служб с использованием архитектуры Java™ Business Integration (JBI). Такая интеграционная платформа – сервисная шина здравоохранения (HSB) – может быть легко адаптирована к применению в других отраслях.

Билал Сиддикви, внештатный консультант, WaxSys

Билал Сиддикви (Bilal Siddiqui) является инженером-электронщиком, консультантом по XML и соучредителем WaxSys, компании, чья деятельность направлена на упрощение электронного бизнеса. После окончания в 1995 г. Инженерно-технологического Университета, г. Лахор, и получения степени по электронной технике, он начал разрабатывать программные продукты для промышленных систем управления. В дальнейшем он занимался XML и использовал свой опыт в программировании C++ для разработки Web- и Wap-базируемых инструментов для XML-технологий, серверных парсинговых программных продуктов и служебных приложений. Билал – проповедник передовых технологий и часто публикуется в этой области.



23.05.2011

В этой серии из двух статей рассматривается процесс объединения различных медицинских служб с использованием сервисной шины, которую я естественным образом назвал сервисной шиной здравоохранения (Healthcare Service Bus, HSB). Эту статью я начну с рассмотрения сценария, в котором различные медицинские приложения подключаются к шине HSB, и расскажу о возможностях, которые обеспечивает такой подход. Далее я расскажу об архитектуре Java Business Integration (JBI), на основе которой построена шина HSB. Рассмотрев последовательность процессов, происходящих внутри сервера JBI, вы поймете внутреннюю логику работы архитектуры JBI и то, как ее компоненты взаимодействуют с внешними приложениями. В заключительном разделе этой статьи приведены конфигурационные примеры, демонстрирующие, как можно настраивать компоненты JBI для работы со службами здравоохранения. Из второй части серии вы узнаете, как реализовать шину HSB с помощью Apache ServiceMix – пакета с открытым исходным кодом, основанного на спецификации JBI.

Сервисная шина здравоохранения

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

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

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

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

Объединение служб

Из этого сценария видно, что шина HSB обеспечивает разнородным приложениям общую среду взаимосвязи и взаимодействия, позволяя тем самым объединять различные службы. К шине HSB подключаются приложения двух типов – потребители услуг и поставщики услуг. В рассмотренном примере приложение по работе с медицинскими рецептами, которое передает запросы о переливании крови на шину HSB, выступает в роли потребителя (приложение, запрашивающее, или потребляющее услугу), а приложение по работе с донорами, рассылающее SMS-сообщения потенциальным донорам – в роли поставщика (приложение, предоставляющее запрашиваемую услугу). Взаимосвязь (interconnection) и взаимодействие (interoperation) являются отдельными требованиями, которые вместе обеспечивают объединение служб. Взаимосвязь означает, что поставщики и потребители услуг соединены между собой (и могут находить друг друга) в общей среде и, таким образом, могут взаимодействовать (обмениваться информацией и сообщениями) друг с другом. Для обеспечения совместимости при обмене сообщениями в HSB используется популярный формат XML.

HSB в качестве сервис-ориентированной архитектуры

Архитектура, подобная HSB, основанная в значительной степени на "сервисах" (услугах), называется сервис-ориентированной архитектурой (Service Oriented Architecture, SOA). SOA подразумевает, что все ее компоненты представляют собой сервисы (службы). Приложение по работе с донорами – это сервис, отправляющий SMS-сообщения. Рентгенологическое отделение – это тоже сервис, выполняющий диагностические мероприятия по запросу. В модели SOA любое приложение, предоставляющее определенный сервис, является поставщиком, а приложение, требующее, запрашивающее или использующее сервис – потребителем услуги.

На рисунке 1 изображены поставщики и потребители услуг, подключенные к шине HSB.

Рисунок 1. Поставщики и потребители услуг, подключенные к шине HSB
Рисунок 1. Поставщики и потребители услуг, подключенные к шине HSB

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

Требования к функционалу HSB

Для обеспечения взаимосвязи шина HSB должна обладать следующими функциональными возможностями:

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

Взаимосвязи между шинами HSB

Архитектура взаимосвязей между шинами HSB изображена на рисунке 2.

Рисунок 2. Взаимосвязи между шинами HSB
Рисунок 2. Взаимосвязи между шинами HSB

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

Использование XML для обеспечения взаимодействия медицинских сервисов

Существует два способа использования XML для обеспечения взаимодействия медицинских служб:

  • Web-сервисы. Web-сервисы, основанные на языке WSDL (Web Services Description Language) и протоколе SOAP (Simple Object Access Protocol), часто используются в самых различных отраслях, включая здравоохранение. Определения сервисов, то есть описания предоставляемых этими службами интерфейсов, пишутся на языке WSDL, основанном на XML. Основанный на XML протокол SOAP используется для фактического обмена данными между поставщиками и потребителями сервисов (более подробную информацию о WSDL и SOAP вы можете найти в разделе Ресурсы). Шина HSB должна иметь возможность взаимодействовать с любым медицинским приложением, использующим WSDL и SOAP.
  • "Седьмой уровень". Седьмой уровень (Health Level 7, HL7) – это набор популярных стандартов, определяющих различные форматы данных для работы с медицинской информацией, такой как медицинские записи, рецепты и истории болезней. Более ранние версии HL7 (версии 1 и 2) были основаны на ASCII. В текущей (третьей) версии HL7 для определения форматов данных используется XML.

Использование шины HSB в других отраслях

Обсуждаемое в этой статье взаимодействие актуально не только в медицине, но и в других отраслях. Например, различные службы туристического бизнеса – отели, системы авиалиний, службы проката автомобилей и туристические агентства – должны взаимодействовать между собой для качественного обслуживания клиентов. Три функции обеспечения взаимосвязи и взаимодействия HSB применимы также и в туристическом бизнесе. Различные поставщики услуг, такие как отели и службы проката автомобилей могут с легкостью обеспечивать взаимодействие при помощи WSDL и SOAP; основанные на XML стандарты, подобные HL7, также могут существовать в любой отрасли.

Шина HSB, которую я продемонстрирую вам, может обеспечивать взаимодействие медицинских приложений, использующих WSDL, SOAP и стандарты HL7.

Шина ESB: обобщенная архитектура для обеспечения взаимосвязи и взаимодействия

Обобщенная архитектура для обеспечения взаимосвязи и взаимодействия обычно называется корпоративной сервисной шиной (Enterprise Service Bus, ESB). Шина ESB обладает следующими свойствами:

  • Основана на архитектуре SOA.
  • Позволяет поставщикам и потребителям услуг использовать WSDL и SOAP.
  • Обладает гибкостью и масштабируемостью, позволяя поставщикам и потребителям услуг использовать специализированные отраслевые стандарты на основе XML, такие как HL7.

Идея шины ESB не нова, и на сегодняшний день существует несколько ее реализаций (ссылки на самые популярные из них вы можете найти в разделе Ресурсы). Это означает, что нет необходимости строить шину HSB с нуля. Можно сконфигурировать существующую шину ESB для работы в сфере здравоохранения.


Использование JBI в качестве HSB

Спецификация JBI (Java Business Integration) определяет стандартизированную среду взаимодействия компонентов бизнес-приложений, основанную на Java. Стандарт JBI обладает всеми функциями ESB, о которых я упоминал ранее, поэтому я буду использовать его для построения шины HSB.

Существует несколько реализаций JBI, включая популярную реализацию с открытым исходным кодом от Apache под названием ServiceMix. Далее в этой серии статей я буду рассказывать об использовании JBI и настройке ServiceMix для построения шины HSB.

Применение компонентов JBI в сфере здравоохранения

На рисунке 3 показано, как можно использовать среду JBI в качестве шины HSB.

Рисунок 3. Применение компонентов JBI в качестве шины HSB
Рисунок 3. Применение компонентов JBI в качестве шины HSB

Как видно из рисунка 3, тремя главными составляющими среды JBI являются связующие компоненты (Binding Components, BC), источники сервисов (Service Engines, SE) и маршрутизатор нормализованных сообщений (Normalized Message Router, NMR).

Я объясню работу компонентов JBI, рассмотрев последовательность событий (см. рисунок 4), происходящих при подключении приложения по работе с медицинскими рецептами (потребитель сервиса) к приложению по работе с донорами (поставщик сервиса).

Рисунок 4. Подключение потребителя сервиса к его поставщику через JBI
Рисунок 4. Подключение потребителя сервиса к его поставщику через JBI

На рисунке 4 показана следующая последовательность событий.

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

Шаг 2. Среда JBI направляет запрос на соответствующий связующий компонент, который получает все запросы на предоставление услуг от приложения по работе с медицинскими рецептами. Каждый потребитель или поставщик услуги, работающий с JBI, имеет свой собственный связующий компонент внутри этой среды.

Шаг 3. Связующий компонент переводит запрос на предоставление услуги в нормализованный формат в соответствии со спецификацией JBI. Нормализация необходима для обеспечения внутреннего взаимодействия между связующими компонентами. Все связующие компоненты JBI понимают нормализованный формат. Кроме того, каждый связующий компонент понимает формат потребителя или поставщика услуги, за которым он закреплен. Другими словами, функция нормализации JBI представляет собой общий формат, к которому приводятся все сообщения, получаемые от потребителей или поставщиков услуг.

Шаг 4. Связующий компонент приложения по работе с медицинскими рецептами передает нормализованное сообщение маршрутизатору NMR, изображенному на рисунке 4. В среде JBI существует единственный маршрутизатор нормализованных сообщений.

Шаг 5. Работа маршрутизатора NMR заключается в получении нормализованных сообщений от одного связующего компонента, определении конечного поставщика запрашиваемой услуги и перенаправлении (или маршрутизации) полученного сообщения другому связующему компоненту, закрепленному за этим поставщиком. На этом шаге маршрутизатор NMR направляет нормализованное сообщение связующему компоненту, подключенному к приложению по работе с донорами.

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

Шаг 7. Связующий компонент передает денормализованное сообщение приложению по работе с донорами.

Эта последовательность иллюстрирует две важные особенности JBI.

  • Работа JBI основана на идее маршрутизации нормализованных сообщений. Каждое сообщение нормализуется связующим компонентом и передается маршрутизатору NMR. Маршрутизатор направляет это сообщение другому связующему компоненту, который переводит его в формат, понимаемый конечным поставщиком услуги.
  • Механизм маршрутизации нормализованных сообщений реализует развязанную (decoupled) архитектуру. Термин "развязанная" означает, что поставщики и потребители услуг взаимодействуют между собой только через механизм маршрутизации нормализованных сообщений и не взаимодействуют друг с другом напрямую.

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

Например, для того чтобы интегрировать в JBI стандарт HL7, потребуется связующий компонент, который понимает стандарт HL7. Если у вас есть такой компонент, вы можете интегрировать любую службу на основе HL7 в среду JBI и, таким образом, создать шину HSB.

Во второй части этой серии статей я приведу практический пошаговый пример создания связующего компонента на основе HL7 и интеграции стандарта HL7 в JBI. А сейчас поговорим подробнее о JBI.

Одновременное использование внутренних и внешних сервисов в JBI

Обсуждая процесс, показанный на рисунке 4, мы рассматривали взаимодействие между поставщиком и потребителем услуги, расположенными за границами среды JBI.

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

Источники сервисов похожи на связующие компоненты, но имеют одну дополнительную особенность: источник сервисов содержит также бизнес-логику внутренней службы (например, приложения рентгенологического отделения). Как связующие компоненты, так и источники сервисов подключены к маршрутизатору нормализованных сообщений среды JBI, как это видно из рисунка 3. На рисунке 5 приложение рентгенологического отделения представлено в качестве источника сервисов.

Рисунок 5. Представление приложения рентгенологического отделения в качестве источника сервисов
Рисунок 5. Представление приложения рентгенологического отделения в качестве источника сервисов

Последовательность действий для доступа к внутренней службе (к источнику сервиса) показана на рисунке 6.

Рисунок 6. Потребитель услуги, обращающийся к поставщику внутреннего сервиса
Рисунок 6. Потребитель услуги, обращающийся к поставщику внутреннего сервиса

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

Шаг 1. Приложение по работе с медицинскими рецептами (потребитель услуги) подключается к среде JBI и запрашивает услугу, поставляемую приложением рентгенологического отделения.

Шаг 2. Среда JBI направляет запрос связующему компоненту приложения по работе с медицинскими рецептами.

Шаг 3. Связующий компонент переводит запрос на предоставление услуги в нормализованный формат.

Шаг 4. Связующий компонент передает нормализованное сообщение маршрутизатору NMR.

Шаг 5. Маршрутизатор NMR направляет нормализованное сообщение приложению рентгенологического отделения (выступающему в роли источника сервиса).

Шаг 6. Источник сервиса денормализует сообщение и обрабатывает его с помощью внутренней бизнес-логики.

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

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

Связывание шин ESB, основанных на JBI

Вспомните рисунок 2, на котором было изображено соединение двух шин HSB. Такое соединение можно создать с помощью JBI, как показано на рисунке 7.

Рисунок 7. Две среды JBI, соединенные между собой
Рисунок 7. Две среды JBI, соединенные между собой

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

Шаг 1. Приложение по работе с медицинскими рецептами (потребитель услуги) подключается к первой среде JBI и запрашивает услугу, поставляемую приложением по работе с банком крови.

Шаг 2. Первая среда JBI направляет запрос связующему компоненту приложения по работе с медицинскими рецептами.

Шаг 3. Связующий компонент переводит запрос на предоставление услуги в нормализованный формат.

Шаг 4. Связующий компонент приложения по работе с медицинскими рецептами передает нормализованное сообщение маршрутизатору NMR.

Шаг 5. Маршрутизатор NMR направляет нормализованное сообщение связующему компоненту, взаимодействующему со второй средой JBI.

Шаг 6. Связующий компонент, подключенный ко второй среде JBI, денормализует полученное сообщение.

Шаг 7. Связующий компонент, подключенный ко второй среде JBI, передает денормализованное сообщение во вторую среду JBI.

Шаг 8. Вторая среда JBI получает запрос и направляет его связующему компоненту, взаимодействующему с первой средой JBI. Таким образом, две среды JBI соединяются между собой через соответствующие связующие компоненты.

Шаг 9. Связующий компонент, взаимодействующий с первой средой JBI, переводит запрос на предоставление услуги в нормализованный формат.

Шаг 10. Связующий компонент, взаимодействующий с первой средой JBI, передает нормализованное сообщение маршрутизатору NMR.

Шаг 11. Маршрутизатор NMR направляет нормализованное сообщение приложению по работе с банком крови (выступающему в роли источника сервиса).

Шаг 12. Источник сервисов денормализует сообщение и обрабатывает его с помощью внутренней бизнес-логики.

Схемы обмена сообщениями в среде JBI

В процессах, изображенных на рисунках 4, 5, 6 и 7, используется одностороннее взаимодействие – отправка сообщения потребителем услуги ее поставщику. Поставщик услуги (например, приложение по работе с донорами) не отправляет ответное сообщение. В терминах JBI такая схема обмена сообщениями называется только запрос (in-only). Эта схема подходит для сервисов, предоставляемых такими приложениями, как приложение по работе с донорами, которому необходимо лишь получать запросы. Возвращать какую-либо информацию приложению, отправившему запрос, не нужно.

Другие службы (такие как приложения портала страховой компании) могут посылать ответные сообщения. Такая схема взаимного обмена сообщениями также возможна в JBI и называется запрос-ответ (in-out). Как можно догадаться, ответные сообщения передаются в среде JBI точно так же – от поставщика услуги через связующие компоненты, источники сервисов и маршрутизатор NMR потребителю этой услуги. Так что я не буду дополнительно приводить здесь последовательность действий для случая запрос-ответ.


Настройка и начальная загрузка среды JBI

Спецификация JBI содержит подробную схему XML для задания способа работы всех связующих компонентов и источников сервисов, которые будут размещены внутри среды JBI. Сейчас я объясню, как использовать схему JBI для настройки JBI в качестве шины HSB.

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

Тег <component> определяет компонент JBI, которым может являться связующий компонент или источник сервисов. В листинге 1 представлен пример XML-конфигурации связующего компонента приложения по работе с медицинскими рецептами.

Листинг 1. XML-конфигурация связующего компонента приложения по работе с медицинскими рецептами
<?xml version="1.0" encoding="UTF-8"?>
<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">
<component type="binding-component" 
    component-class-loader-delegation="parent-first" 
    bootstrap-class-loader-delegation="parent-first">
    <identification>
        <name>Prescription-Application</name>
        <description>Binding Component for the prescription application</description>
    </identification>
    <component-class-name>
        org.apache.servicemix.cxfbc.CxfBcComponent
    </component-class-
    <component-class-path>
      <path-element>lib/servicemix-cxf-bc-2009.01.jar</path-element>
      <path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path-element>
      <!-- other path-element tags -->
    </component-class-path>
    <bootstrap-class-name>
        org.apache.servicemix.common.DefaultBootstrap
    </bootstrap-class-name>
    <bootstrap-class-path>
      <path-element>lib/servicemix-cxf-bc-2009.01.jar</path-element>
      <path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path-element>
      <!-- other path-element tags -->
    </bootstrap-class-path>
</component>
</jbi>

Вы видите, что код листинга 1 содержит тег <component> с атрибутом type и пятью дочерними тегами с именами <identification>, <component-class-name>, <component-class-path>, <bootstrap-class-name> и <bootstrap-class-path>.

Атрибут type определяет, является ли компонент связующим компонентом или источником сервиса. Конфигурация связующего компонента приложения по работе с медицинскими рецептами приведена в листинге 1, поэтому атрибуту type следует присвоить значение binding-component.

Тег <identification> в листинге 1 содержит имя и описание связующего компонента.

Тег <component-class-name> определяет Java-класс, в котором реализована логика, требующаяся для связующего компонента. Спецификация JBI имеет стандартный интерфейс с именем javax.jbi.component.Component, который должен быть реализован во всех связующих компонентах. Для демонстрации работы шины HSB в этой серии статей я буду использовать пакет Apache ServiceMix. ServiceMix содержит связующий компонент, который можно использовать для работы с клиентами Web-сервисов, основанных на SOAP. Класс, в котором реализована логика этого связующего компонента, называется org.apache.servicemix.cxfbc.CxfBcComponent. Во второй части я буду использовать этот класс для демонстрации того, как приложение по работе с медицинскими рецептами работает с JBI. Вот почему в листинге 1 тег <component-class-name> содержит в качестве имени класса значение org.apache.servicemix.cxfbc.CxfBcComponent.

Теперь взгляните на тег <component-class-path> в листинге 1. Он содержит два дочерних тега с названием <path-element>. Эти теги задают пути ко всем JAR-файлам, необходимым для выполнения класса компонента. Это означает, что теги <component-class-name> и <component-class-path> составляют пару, определяющую имя Java-класса связующего компонента, а также полные пути ко всем файлам, необходимым для его выполнения.

В листинге 1 вы обнаружите еще одну пару тегов с именами <bootstrap-class-name> и <bootstrap-class-path>, похожую на предыдущую пару <component-class-name> и <component-class-path>. Пара bootstrap определяет имя Java-класса, содержащего логику для начальной загрузки связующего компонента, а также полные пути ко всем необходимым файлам.

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

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

Листинг 2. XML-конфигурация внешнего поставщика сервиса
<?xml version="1.0" encoding="UTF-8"?> 
<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">
<component type="binding-component" 
    component-class-loader-delegation="parent-first" 
    bootstrap-class-loader-delegation="parent-first">
    <identification>
        <name>Donor-Group-Application</name>
        <description>Binding Component for the Donor Group application</description>
    </identification>
    <component-class-name>
        org.apache.servicemix.cxfbc.CxfBcComponent
    </component-class-
    <component-class-path>
      <path-element>lib/servicemix-cxf-bc-2009.01.jar</path-element>
      <path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path-element>
      <!-- other path-element tags -->
    </component-class-path>
    <bootstrap-class-name>
        org.apache.servicemix.common.DefaultBootstrap
    </bootstrap-class-name>
    <bootstrap-class-path>
      <path-element>lib/servicemix-cxf-bc-2009.01.jar</path-element>
      <path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path-element>
      <!-- other path-element tags -->
    </bootstrap-class-path>
</component>
</jbi>

В листинге 3 содержится еще один тег <component>, дающий пример определения источника сервисов для внутреннего поставщика сервисов (такого как приложение рентгенологического отделения).

Листинг 3. XML-конфигурация внутреннего поставщика сервисов
<?xml version="1.0" encoding="UTF-8"?> 
<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">
<component type="service-engine" 
    component-class-loader-delegation="parent-first" 
    bootstrap-class-loader-delegation="parent-first">
    <identification>
      <name>Radiology-Department-Application</name>
      <description>Radiology Department Service Application</description>
    </identification>
    <component-class-name>
        org.hsb.radiology.RadiologyBean</component-class-name>
    <component-class-path>
      <path-element>lib/radiology-bean.jar</path-element>
      <path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path-element>
      <!-- other path-element tags -->
    </component-class-path>
    <bootstrap-class-name>
        org.apache.servicemix.common.DefaultBootstrap
    </bootstrap-class-name>
    <bootstrap-class-path>
      <path-element>lib/ radiology-bean.jar</path-element>
      <path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path-element>
      <!-- other path-element tags -->
    </bootstrap-class-path>
  </component>

</jbi>

Сравнив код листинга 3 с кодом листинга 2, вы найдете лишь одно существенное отличие: атрибут type в листинге 2 имеет значение binding-component (поскольку это конфигурация связующего компонента внешнего поставщика сервисов), тогда как атрибут type, выделенный жирным шрифтом в листинге 3, имеет значение service-engine, поскольку это источник сервисов, являющийся внутренней службой.


Что дальше

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

Реализации JBI, такие как ServiceMix, содержат предопределенные связующие компоненты, являющиеся частью дистрибутива. Для таких связующих компонентов нет необходимости даже настраивать тег <component>. Реализация JBI уже будет знать о классах и других параметрах этих связующих компонентов.

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

Ресурсы

Комментарии

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=Технология Java, Open source
ArticleID=660292
ArticleTitle=Интеграция служб здравоохранения: Часть 1. Использование архитектуры Enterprise Service Bus
publish-date=05232011