Интеграция служб здравоохранения: Часть 2. Использование Apache ServiceMix в качестве сервисной шины здравоохранения

Настройка связи между несколькими серверами JBI, поддерживающими приложения для отрасли здравоохранения

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

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

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



23.05.2011

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

Во второй части я покажу, как настроить эти сервисы таким образом, чтобы сервер JBI мог выступать в роли шины HSB. Я покажу вам, как использовать в качестве шины HSB пакет Apache ServiceMix – популярный open-source пакет, основанный на спецификации JBI. Я начну с рассказа о ServiceMix и об одном из его важнейших компонентов. Затем я расскажу, как использовать этот компонент для настройки приложения в качестве внутреннего сервиса под управлением Apache ServiceMix. В третьей части статьи я покажу, как организовать связь между двумя средами JBI таким образом, чтобы приложения, подключенные к первой среде JBI, могли взаимодействовать и общаться с приложениями, подключенными ко второй среде JBI. Наконец, в последней части я дам несколько рекомендаций, касающихся реализации в среде JBI функциональности "седьмого уровня" (HL7, Healthcare Level 7 – популярного набора медицинских стандартов, о котором рассказывалось в первой части).

Введение в Apache ServiceMix

Apache ServiceMix может выступать в качестве среды для поддержки приложений JBI, таких как приложения, показанные на рисунках 4, 5, 6 и 7первой части серии. Для реализации компонентов среды JBI в ServiceMix используется популярная инфраструктура с открытым кодом Spring (см. раздел Ресурсы). Для настройки сервисов внутри среды JBI используется XML-конфигурация Spring, позволяющая напрямую указывать Java-классы, экземпляры которых необходимо создать.

В дополнение к реализации JBI в состав ServiceMix входят несколько полезных предварительно сконфигурированных компонентов, которые можно напрямую использовать в JBI-приложениях. Вспомните раздел Совместное использование внутренних и внешних служб в JBI из первой части серии, в котором для организации внутреннего сервиса (приложение рентгенологического отделения) было необходимо использовать источник сервисов. В ServiceMix имеется множество источников сервисов многократного применения, которые можно использовать для организации внутренних сервисов. В этой статье мы будем использовать источник сервисов из состава ServiceMix под названием CXF Service Engine (CXFSE).

CXFSE – это упаковщик для open-source инфраструктуры Web-сервисов Apache CXF, позволяющий использовать функциональность Apache CXF в приложениях ServiceMix. Apache CXF позволяет создавать Web-сервисы, которые полностью содержат всю внутреннюю бизнес-логику. CXFSE обладает многочисленными возможностями, позволяющими использовать его в приложениях, подобных шине HSB.

Для объединения клиентской части Web-сервиса (то есть интерфейса, определенного в WSDL-файле) с его бизнес-логикой в Apache CXF используется концепция перехватчиков. CXF имеет в своем составе несколько готовых к использованию перехватчиков, а также позволяет добавлять новые. Каждый перехватчик выполняет определенную работу, и вы можете строить цепочки перехватчиков, чтобы получить результат, которого требует ваша бизнес-логика. Например, вы можете выстроить следующую цепочку перехватчиков.

  1. Первый перехватчик получает запрос от потребителя сервиса и преобразует его в другой формат.
  2. Второй перехватчик создает на основе этого запроса Java-объекты.
  3. Третий перехватчик вызывает выполнение бизнес-логики и вместе с запросом на исполнение передает Java-объекты.
  4. В четвертом перехватчике может непосредственно быть реализована бизнес-логика.
  5. Пятый перехватчик доставляет новые Java-объекты из приложения, в котором реализована бизнес-логика.
  6. Шестой перехватчик преобразует Java-объекты в формат XML и возвращает ответ потребителю услуги.

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

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


Настройка работы приложения рентгенологического отделения в качестве внутреннего сервиса

Для реализации сервиса рентгенологического отделения в ServiceMix необходимо выполнить ряд настроек, который я разбил на пять этапов.

  1. Написать и скомпилировать Java-класс, содержащий бизнес-логику приложения рентгенологического отделения, и сделать его видимым в качестве Web-сервиса.
  2. Настроить Java-классы приложения рентгенологического отделения в инфраструктуре Spring так, чтобы эти классы создавались и становились доступными в этой инфраструктуре в соответствии с требованиями приложения.
  3. Написать WSDL-интерфейс для приложения рентгенологического отделения. Для определения интерфейсов сервисов, предоставляемых внутренними и внешними поставщиками услуг, в спецификации JBI используется WSDL 2.0.
  4. Написать JBI-конфигурации для поставщика сервиса (то есть, для приложения рентгенологического отделения), а также для потребителя сервиса (вспомните рисунок 6 из первой части серии, на котором приложение по работе с медицинскими рецептами является потребителем услуги, посылающим запросы приложению рентгенологического отделения).
  5. Упаковать приложение рентгенологического отделения в сервисную сборку JBI и скопировать ее в ServiceMix.

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

А сейчас давайте подробно рассмотрим каждый этап.

Приложение рентгенологического отделения как простой Java-класс

В листинге 1 показан простой Java-класс с именем RadiologyDepartment, содержащий всего один метод под названием performTest().

Листинг 1. Класс RadiologyDepartment
package com.hsb;

import javax.jws.WebService;
import javax.xml.ws.Holder;

import com.hsb.Radiology;

@WebService(serviceName="RadiologyService", 
   targetNamespace="http://hsb.org/radiology-department", 
   endpointInterface="com.hsb.Radiology")

public class RadiologyDepartment implements Radiology {

    public void performTest (Holder<String> testDetails, Holder<String> testResults)
    {
       System.out.println ("
           RadiologyDepartment.performTest()- > TestDetails:"+testDetails.value);
       System.out.println ("
           RadiologyDepartment.performTest()- > TestResults:"+testResults.value);
    }
}

Метод performTest() принимает два параметра: testDetails и testResults. Как можно заметить, это методы типа Holder <String>. Holder – это класс, определенный технологией JAX-WS (Java API for XML-Based Web Services). JAX-WS используется в CXFSE, поэтому вполне разумно использовать экземпляр этого класса для обмена информацией с вашим Java-классом. Класс Holder содержит методы передачи и получения данных из своего экземпляра. В инфраструктуре CXF данные, полученные в XML-запросе, передаются в объект Holder, а затем объект Holder передается в Java-класс приложения рентгенологического отделения.

Для краткости я оставил метод performTest() пустым (за исключением нескольких операторов System.out). В реальном приложении метод performTest() должен быть включен в состав бизнес-логики приложения рентгенологического отделения.

Теперь необходимо скомпилировать класс RadiologyDepartment. В примере для этой статьи (раздел Загрузка) содержится папка с именем sample1\RadiologyService, в которой вы найдете класс RadiologyDepartment как в исходном, так и в скомпилированном виде.

Необходимо также сгенерировать файлы JAXB (Java API for XML Binding) для класса RadiologyDepartment. Файлы JAXB используются интерфейсом JAX-WS API, поэтому они необходимы для инфраструктуры Apache CXF, чтобы класс RadiologyDepartment мог быть опубликован в качестве Web-сервиса. Для генерации всех необходимых файлов на основе класса RadiologyDepartment используйте утилиту wsgen , которая находится в установочной директории JDK1.6 ..\jdk1.6.0_12\bin (для получения дополнительной информации об утилите wsgen обратитесь к разделу Ресурсы).

Специально для этой статьи я создал файл ws.bat (раздел Загрузка). Вы можете запустить этот файл, чтобы сгенерировать все необходимые файлы JAXB. Также вы можете найти эти файлы (как в исходном, так и в скомпилированном виде) в папке sample1\RadiologyService.

Конфигурирование класса RadiologyDepartment в инфраструктуре Spring

В листинге 2 показано содержимое XML-файла конфигурации Spring для класса RadiologyDepartment

Листинг 2. XML-конфигурация Spring для сервиса рентгенологического отделения
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:cxfse="http://servicemix.apache.org/cxfse/1.0">
    <cxfse:endpoint>
        <cxfse:pojo>
          <bean class="com.hsb.RadiologyDepartment" />
        </cxfse:pojo>
    </cxfse:endpoint>
</beans>

Обратите внимание на то, что корневой тег <beans> в листинге 2 является частью адресного пространства XML инфраструктуры Spring. В этот тег заключены различные классы JavaBeans (экземпляры Java-классов, написанные по определенным правилам) вашего приложения. Все классы JavaBeans, относящиеся к конкретному приложению, настраиваются внутри тега <beans>. Инфраструктура Spring управляет созданием экземпляров Java-классов и обеспечивает доступ к ним тех приложений, которым это необходимо, поэтому вам не нужно заботиться об этом. Вы просто создаете классы и конфигурируете их в Spring.

Тег <beans> в листинге 2 содержит объявление адресного пространства http://servicemix.apache.org/cxfse/1.0. Это адресное пространство определено в ServiceMix, и его задачей является настройка функциональности CXFSE в соответствии с требованиями вашего приложения. Я буду ссылаться на это адресное пространство как на адресное пространство cxfse.

Адресное пространство cxfse содержит теги, определяющие конкретную цель использования CXFSE. Доступно несколько параметров. Из листинга 2 видно, что в корневом теге <beans> содержится тег <endpoint>, принадлежащий адресному пространству cxfse. Тег <endpoint>обозначает начало и конец канала связи.

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

В листинге 2 вы конфигурируете приложение рентгенологического отделения, поэтому тег <endpoint> используется непосредственно внутри тега <beans>. Это говорит среде ServiceMix о том, что вы конфигурируете конечную точку.

Существуют различные типы конечных точек. Например, конечной точкой может являться цепочка перехватчиков, последовательно выполняющих несколько заданий (например, цепочка, о которой говорилось в разделе Введение в Apache ServiceMix). Однако для простоты я использую в этой статье простой Java-класс (класс RadiologyDepartment). Экземпляр простого Java-класса обычно называют Plain Old Java Object (POJO). В адресном пространстве cxfse содержится тег <pojo>, заключенный в тег <endpoint> для указания того, что эта конечная точка является лишь экземпляром простого Java-класса.

Наконец, в листинге 2 вы видите тег <bean>, являющийся частью адресного пространства Spring и определяющий экземпляр Java-класса (так называемый bean), который выступает в роли конечной точки. Тег <bean> содержит атрибут с именем class, определяющий полное имя класса (а именно, com.hsb.RadiologyDepartment), экземпляр которого будет служить конечной точкой.

XML-конфигурация Spring, показанная в листинге 2, содержится в файле xbean.xml, который вы можете найти в папке sample1\RadiologyService\ (раздел Загрузка).

Написание WSDL-файла для приложения рентгенологического отделения

В листинге 3 показан WSDL-интерфейс для приложения рентгенологического отделения.

Листинг 3. WSDL-интерфейс для приложения рентгенологического отделения
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<definitions targetNamespace="http://hsb.com/" xmlns="http://schemas.xmlsoap.org/wsdl/" 
xmlns:tns="http://hsb.com/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <types>
    <xsd:schema>
      <xsd:import namespace="http://hsb.com/"
          schemaLocation="Radiology_schema1.xsd"/>
    </xsd:schema>
  </types>
  <message name="performTest">
    <part name="parameters" element="tns:performTest"/>
  </message>
  <message name="performTestResponse">
    <part name="parameters" element="tns:performTestResponse"/>
  </message>
  <portType name="Radiology">
    <operation name="performTest">
      <input message="tns:performTest"/>
      <output message="tns:performTestResponse"/>
    </operation>
  </portType>
</definitions>

В листинге 4 показана привязка WSDL к приложению рентгенологического отделения.

Листинг 4. Привязка WSDL к приложению рентгенологического отделения
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<definitions targetNamespace="http://hsb.org/radiology-department" 
     name="RadiologyService" 
     xmlns="http://schemas.xmlsoap.org/wsdl/" 
     xmlns:tns="http://hsb.org/radiology-department" 
     xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
     xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
  <import namespace="http://hsb.com/" location="Radiology.wsdl"/>
  <binding name="RadiologyDepartmentPortBinding" 
    type="ns1:Radiology" xmlns:ns1="http://hsb.com/">
    <soap:binding transport="http://schemas.xmlsoap.org/soap/http" 
        style="document"/>
    <operation name="performTest">
      <soap:operation soapAction=""/>
      <input>
        <soap:body use="literal"/>
      </input>
      <output>
        <soap:body use="literal"/>
      </output>
    </operation>
  </binding>
  <service name="RadiologyService">
    <port name="RadiologyDepartmentPort" 
         binding="tns:RadiologyDepartmentPortBinding">
      <soap:address location="http://localhost:8092/RadiologyService/ "/>
    </port>
  </service>
</definitions>

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

В папке sample1\RadiologyService (раздел Загрузка) вы найдете WSDL-файлы Radiology.wsdl и RadiologyService.wsdl, показанные в листинге 3 и листинге 4 соответственно.

Упаковка приложения рентгенологического отделения

Теперь необходимо упаковать в ZIP-файл с именем RadiologyService.zip следующие компоненты: класс RadiologyDepartment и сопутствующие JAXB-классы, файл xbean.xml инфраструктуры Spring, а также WSDL-файлы приложения рентгенологического отделения. Все эти файлы вы найдете в папке sample1\RadiologyService (раздел Загрузка). Я заранее подготовил для вас этот ZIP-файл и поместил его в папку sample1\.

Конфигурирование и упаковка потребителя сервиса

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

Конфигурирование потребителя сервиса в JBI очень похоже на конфигурирование поставщика сервиса, которое вы только что видели. Нам необходимо написать XML-конфигурацию Spring и WSDL-файл для конечной точки потребителя.

XML-конфигурация Spring для потребителя сервиса показана в листинге 5.

Листинг 5. XML-конфигурация для потребителя сервиса
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:cxfbc="http://servicemix.apache.org/cxfbc/1.0"
       xmlns:radiology="http://hsb.org/radiology-department">
    <cxfbc:consumer wsdl="classpath:RadiologyService.wsdl"
        targetService="radiology:RadiologyService" />
</beans>

Вы видите, что листинг 5 очень похож на листинг 2. Вместо адресного пространства cxfse, которое используется в листинге 2, в листинге 5 используется адресное пространство cxfbc (поскольку для потребителя сервиса необходим связующий компонент, а не источник сервиса). Вспомните рисунок 6 первой части этой серии, из которого видно, что приложение по работе с медицинскими рецептами (потребитель сервиса) требует наличия связующего компонента, а приложение рентгенологического отделения (поставщик внутреннего сервиса) требует наличия источника сервиса. Для приложений CXF в ServiceMix имеются адресные пространства как источника сервиса (SE), так и связующего компонента (BC), что обеспечивает полную гибкость настройки приложений в соответствии с вашими потребностями.

WSDL-файлы для потребителя сервиса очень похожи на WSDL-файлы, приведенные в листингах 3 и 4. Вы можете найти конфигурации потребителя сервиса в папке sample1\PrescriptionService (раздел Загрузка).

Вам необходимо упаковать XML-конфигурацию инфраструктуры Spring и WSDL-файлы потребителя сервиса в ZIP-файл PrescriptionService.zip. Я уже подготовил для вас этот файл и поместил егов папку sample1\ (раздел Загрузка).

Упаковка приложения рентгенологического отделения и приложения по работе с медицинскими рецептами

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

Для создания сервисной сборки нужно просто написать XML-конфигурацию JBI, как показано в листинге 6.

Листинг 6. XML-конфигурация JBI для сервисной сборки приложения рентгенологического отделения
<?xml version="1.0" encoding="UTF-8"?>
<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">
  <service-assembly>
    <identification>
      <name>radiology-service-assembly</name>
      <description>Radiology Department Service Assembly</description>
    </identification>
    <service-unit>
      <identification>
        <name>radiology-service</name>
        <description>Radiology Department Service Provider</description>
      </identification>
      <target>
        <artifacts-zip>RadiologyService.zip</artifacts-zip>
        <component-name>servicemix-cxf-se</component-name>
      </target>
    </service-unit>
    <service-unit>
      <identification>
        <name>prescription-service</name>
        <description> Prescription Service Consumer</description>
      </identification>
      <target>
        <artifacts-zip>PrescriptionService.zip</artifacts-zip>
        <component-name>servicemix-cxf-bc</component-name>
      </target>
    </service-unit>
  </service-assembly>
</jbi>

Корневой тег <jbi> из листинга 6 принадлежит адресному пространству JBI (http://java.sun.com/xml/ns/jbi). Тег <jbi> содержит дочерний тег <service-assembly>, который упаковывает имя и описание развертываемого сервиса JBI, а также различные служебные компоненты сервисной сборки.

Тег <service-assembly> содержит два дочерних тега <service-unit>, каждый из которых представляет собой отдельный модуль сервиса. Так как мы настраиваем только приложение по работе с медицинскими рецептами и приложение рентгенологического отделения, сервисная сборка содержит два тега <service-unit> – по одному для каждого приложения.

Каждый тег <service-unit> упаковывает имя и описание модуля, а также ZIP-файл сервисной сборки. Можно заметить, что теги <artifacts-zip> внутри тегов <service-unit> содержат имена ZIP-файлов, которые совпадают с именами .zip файлов, созданных в разделах Упаковка приложения рентгенологического отделения и Конфигурирование и упаковка потребителя сервиса. Файл RadiologyService.zip предназначен для приложения рентгенологического отделения, а файл PrescriptionService.zip – для отделения по работе с медицинскими рецептами.

Необходимо сохранить конфигурацию из листинга 6 в виде XML-файла с именем jbi.xml. Я сделал это для вас и поместил этот файл в папку META-INF\ (раздел Загрузка). Наконец, нужно упаковать папку META-INF\ и два .zip файла в архив RadiologyAssembly.zip. Я создал архив RadiologyAssembly.zip и поместил его в папку sample1\ (раздел Загрузка).

RadiologyAssembly.zip – это ZIP-файл, содержащий все, что было сделано до этого момента.

Советы разработчикам приложений ServiceMix

В разделе Загрузка содержится файл Tips.txt с полезными советами, затрагивающими такие темы, как

  • Включение отладочной трассировки для ServiceMix
  • Очистка кэша ServiceMix
  • Перемещение компонентов ServiceMix

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

Проверка работы сервиса рентгенологического отделения

Для проверки работы сервиса рентгенологического отделения выполните следующие шаги.

  1. Загрузите и установите на ваш компьютер пакет Apache ServiceMix 3.3.1 (раздел Ресурсы).
  2. Запустите ServiceMix, дважды щелкнув по файлу servicemix.bat, который находится в папке ..\apache-servicemix-3.3.1\bin установочной директории ServiceMix. Подождите несколько секунд, пока запустятся все службы сервера.
  3. Скопируйте файл RadiologyAssembly.zip из папки sample1\ в папку ..\apache-servicemix-3.3.1\hotdeploy установочной директории ServiceMix. После того, как zip. файл будет скопирован, ServiceMix определит, что выполняется развертывание нового приложения. Запустится процесс развертывания, который будет отображаться на консоли вывода ServiceMix. Дождитесь завершения этого процесса.

В составе ServiceMix присутствует простой браузерный SOAP-клиент, который можно использовать для проверки работы приложений ServiceMix. Вместе с этим клиентом в ServiceMix включены несколько тестовых приложений. Вы можете найти его в виде файла client.html в папке ..\apache-servicemix-3.3.1\examples\cxf-wsdl-first установочной директории ServiceMix.

Откройте файл client.html в Web-браузере и введите адрес http://localhost:8092/RadiologyService в поле Target. Затем введите SOAP-запрос, показанный в листинге 7, в текстовое поле, расположенное ниже поля Target.

Листинг 7. SOAP-запрос для проверки приложения рентгенологического отделения
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
   xmlns:hsb="http://hsb.com/">
   <soapenv:Header/>
   <soapenv:Body>
      <hsb:performTest>
         <arg0>Test1</arg0>
         <arg1>Test2</arg1>
      </hsb:performTest>
   </soapenv:Body>
</soapenv:Envelope>

Я поместил текст этого SOAP-запроса в файл SOAPRequest.txt (раздел Загрузка). Вы можете скопировать текст запроса из этого файла и вставить его в текстовое поле, расположенное ниже поля Target. После того как вы введете адрес SOAP-запроса, страница client.html будет выглядеть, как показано на рисунке 1.

Рисунок 1. Страница client.html
Рисунок 1. Страница client.html

Теперь нажмите кнопку Send внизу страницы и подождите несколько секунд. Поставщик сервиса приложения рентгенологического отделения получает запрос, направляет его маршрутизатору нормализованных сообщений (NMR), а затем через механизм CXFSE запрос передается классу RadiologyDepartment. Далее класс RadiologyDepartment отвечает на запрос и передает ответ назад SOAP-клиенту. Этот ответ можно увидеть в текстовом поле, расположенным напротив текстового поля запроса, как показано на рисунке 2.

Рисунок 2. Ответ, полученный SOAP-клиентом
Рисунок 2. Ответ, полученный SOAP-клиентом

Соединение серверов JBI между собой

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

Сравните рисунки 4 и 7 из первой части этой серии. На рисунке 4 изображены потребитель и внешний поставщик сервиса, подключенные к одному серверу JBI. На рисунке 7 изображены потребитель сервиса, подключенный к одному серверу JBI, и поставщик сервиса, подключенный к другому серверу JBI, а два этих сервера соединены друг с другом.

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

В этом разделе нам потребуется два сервера JBI. К первому серверу будут подключены потребитель и внешний поставщик сервисов. На втором сервере будет работать внутренний поставщик сервисов. Эта схема показана на рисунке 3.

Рисунок 3. Два сервера JBI: с внешним потребителем сервиса (первый сервер) и с внутренним поставщиком сервиса (второй сервер)
Рисунок 3. Два сервера JBI: с внешним потребителем сервиса (первый сервер) и с внутренним поставщиком сервиса (второй сервер)

Первый сервер JBI будет считать, что второй сервер JBI является внешним сервисом. Второй JBI сервер будет считать, что первый сервер JBI является потребителем сервиса.

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

Для настройки внешнего поставщика сервиса нужно просто сказать первому серверу JBI о том, что второй сервер является Web-сервисом. Необходимо сделать лишь две вещи: написать XML-конфигурацию Spring, подобную конфигурациям из листингов 2 и 5, и создать WSDL-файлы, аналогичные файлам из листингов 3 и 4.

Настройка внешнего поставщика сервиса для первого сервера JBI

В листинге 8 представлена XML-конфигурация Spring для внешнего поставщика сервиса.

Листинг 8. XML-конфигурация Spring для внешнего поставщика сервиса
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:cxfbc="http://servicemix.apache.org/cxfbc/1.0"
     xmlns:radiology="http://hsb.org/radiology-department">
        <cxfbc:provider
            service="radiology:RadiologyService"
            endpoint="RadiologyService"
            locationURI="http://192.168.10.33:8092/RadiologyService/"
            wsdl="classpath:RadiologyService.wsdl" />
</beans>

Вы видите, что тег <beans> в листинге 8 содержит объявление того же самого адресного пространства cxfbc, что и в листинге 5. Причина этого заключается в том, что в листинге 8 настраивается внешний поставщик, а в листинге 5 – внешний потребитель сервиса. Адресное пространство cxfbc используется всякий раз, когда настраивается внешнее приложение (неважно, потребитель это или поставщик).

Заметьте также, что в листинге 8 присутствует тег <provider> из адресного пространства cxfbc (аналогично тегу <consumer> из листинга 5). Тег <provider> содержит различные атрибуты, подробно описывающие внешний сервис.

  • service: имя поставщика сервиса рентгенологического отделения, работающей на втором сервере JBI.
  • endpoint: WSDL-порт приложения рентгенологического отделения, принимающий запросы на предоставление сервиса.
  • locationURI: сетевой адрес сервиса рентгенологического отделения, который назначен второму серверу JBI. Когда я запускал это приложение, мой второй сервер JBI был запущен на машине с адресом 192.168.10.33 и номером порта 8092.
  • wsdl: имя и местоположение WSDL-файла. ServiceMix определяет путь к корневому каталогу ZIP-файла сервиса. Как видно (раздел Загрузка), WSDL-файл находится в папке sampl2\JBI1\RemoteRadiologyService. Содержимое папки RemoteRadiologyService формирует корневой каталог ZIP-файла для этого приложения. Поэтому для атрибута wsdl я указал значение classpath:RadiologyService.wsdl.

WSDL-файл этого сервиса поставщика сервиса совпадает с WSDL-файлами из листингов 3 и 4. Содержимое листинга 8 находится в папке sample2\JBI1\RemoteRadiologyService (раздел Загрузка) в виде файла xbean.xml и сопутствующего ему WSDL-файла RadiologyService.wsdl. Вам нужно упаковать все содержимое папки RemoteRadiologyService в ZIP-архив с именем RemoteRadiologyService.zip. Я уже подготовил для вас этот файл и поместил его в папку sample2\JBI1.

Настройка потребителя сервиса для первого сервера JBI

Конфигурация потребителя сервиса для первого сервера JBI полностью совпадает с конфигурацией, представленной в листинге 5, поэтому здесь я не буду приводить ее снова. Данную конфигурацию потребителя сервиса вы найдете в виде файла xbean.xml, который находится в папке sample2\JBI1\PrescriptionService.

Также вам потребуется WSDL-файл, соответствующий конфигурации потребителя сервиса, который очень похож на WSDL-файл из листинга 3. Данный WSDL-файл находится в папке sample2\JBI1\PrescriptionService. Я также упаковал все содержимое папки PrescriptionService в архив PrescriptionService.zip.

Упаковка поставщика и потребителя сервиса для первого сервера JBI

У нас есть два готовых ZIP-файла для первого сервера JBI. Последним этапом является упаковка этих файлов в сервисную сборку. Конфигурационный файл JBI для выполнения этой операции показан в листинге 9.

Листинг 9. Конфигурация JBI для полной сборки первого сервера JBI
<?xml version="1.0" encoding="UTF-8"?>
<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">
  <service-assembly>
    <identification>
      <name>remote-radiology-service-assembly</name>
      <description>Radiology Department Service Assembly</description>
    </identification>
    <service-unit>
      <identification>

        <name>remote-radiology-service</name>
        <description>Radiology Department Service Provider</description>
      </identification>
      <target>
        <artifacts-zip>RemoteRadiologyService.zip</artifacts-zip>
        <component-name>servicemix-cxf-bc</component-name>
      </target>
    </service-unit>
    <service-unit>
      <identification>
        <name>remote-prescription-service</name>
        <description>Prescription Service Consumer</description>
      </identification>
      <target>
        <artifacts-zip>PrescriptionService.zip</artifacts-zip>
        <component-name>servicemix-cxf-bc</component-name>
      </target>
    </service-unit>
  </service-assembly>
</jbi>

Как можно заметить, файл сервисной сборки JBI из листинга 9 очень похож на файл из листинга 6. Конфигурацию JBI, приведенную в листинге 9, вы можете найти в виде файла jbi.xml в папке sample2\JBI1\META-INF (раздел Загрузка).

Наконец, необходимо упаковать файлы jbi.xml, RemoteRadiologyService.zip и PrescriptionService.zip в другой архив с именем RemoteRadiologyAssembly.zip. Я подготовил этот файл и поместил его в папку sample2\JBI1.

Проверка внутреннего подключения серверов JBI

Для проверки внутреннего подключение серверов JBI необходимо запустить приложение RadiologyAssembly, которое упоминалось в разделе Проверка работы службы рентгенологического отделения. Оно будет выступать в качестве второго сервера JBI.

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

  • Атрибут locationURI в файле xbean.xml
  • Атрибут address тега <soap> в файле RadiologyService.wsdl

Если ваш второй сервер JBI запущен на машине с другим адресом, вы должны внести соответствующие изменения в эти два файла..

Для запуска первого сервера JBI выполните следующие действия.

  1. Установите пакет Apache ServiceMix 3.3.1 на отдельную машину. Я проверял работу серверов JBI с помощью двух машин; на одной был запущен первый сервер JBI, а на другой – второй сервер JBI.
  2. Запустите ServiceMix, дважды щелкнув по файлу servicemix.bat, который находится в папке ..\apache-servicemix-3.3.1\bin установочной директории ServiceMix. Подождите несколько секунд, пока запустятся все службы сервера.
  3. Скопируйте файл RemoteRadiologyAssembly.zip из папки sample2\JBI1 в папку ..\apache-servicemix-3.3.1\hotdeploy установочной директории ServiceMix. После того, как zip. файл будет скопирован, ServiceMix определит, что выполняется развертывание нового приложения. Запустится процесс развертывания, который будет отображаться на консоли вывода ServiceMix. Дождитесь завершения этого процесса.
  4. 5. Откройте файл client.html, который вы использовали во время проверки работы приложения рентгенологического отделения, в вашем браузере. В поле Target введите адрес http://localhost:8092/RadiologyService. Затем введите текст SOAP-запроса из листинга 7 в текстовое поле, расположенное ниже поля Target.
  5. Нажмите кнопку Send внизу страницы и подождите несколько секунд. Первому серверу JBI будет направлен запрос, который пройдет через его связующий компонент потребителя сервиса, маршрутизатор нормализованных сообщений (NMR) и связующий компонент поставщика сервиса, а затем попадет на второй сервер JBI. Связующий компонент потребителя сервиса второго сервера JBI получит данный запрос, направит его маршрутизатору NMR, а затем через механизм CXFSE передаст его классу RadiologyDepartment. Класс RadiologyDepartment ответит на запрос и передаст ответ обратно через два сервера JBI в ваш браузер. Этот ответ можно увидеть в текстовом поле, расположенным напротив текстового поля запроса.

Интеграция отраслевых стандартов здравоохранения в ServiceMix

Вы узнали, как можно интегрировать в ServiceMix целый ряд различных сервисов. Сервис, который я рассматривал в этой статье в качестве примера (сервис приложения рентгенологического отделения), основан на WSDL. Тем не менее, как я объяснил в разделе Использование XML для обеспечения взаимодействия медицинских служб первой части этой серии, на WSDL основаны не все сервисы. Сервисы могут быть основаны на отраслевых стандартах, таких как "Седьмой уровень" (Health Level 7, HL7). Когда в среду JBI интегрируется какой-либо сервис, необходимо использовать компонент JBI, независим от того, на чем основан сервис – на WSDL или на отраслевых стандартах.

В качестве общего стандарта, широко используемого для определения интерфейсов сервисов, во всех отраслях может использоваться WSDL. Вот почему существует множество основанных на WSDL решений, которые можно интегрировать в ServiceMix, и почему в состав ServiceMix входит инфраструктура Apache CXF. Однако со стандартами HL7 дело обстоит иначе. На дату написания этой статьи в ServiceMix отсутствовала поддержка стандартов HL7, хотя на Web-странице Apache ServiceMix было объявлено о том, что она будет реализована в будущем.

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

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

Гибкость ServiceMix

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

  • Component
  • ComponentContext
  • ComponentLifeCycle
  • ServiceUnitManager
  • InstallationContext
  • Bootstrap

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

  • Вы можете управлять тем, что будет делать ваш компонент после его установки. Например, во время установки можно создать таблицы базы данных, в которых ваш компонент будет хранить данные приложения.
  • Аналогично, ServiceMix позволяет написать код деинсталляции, который выполняет определенные действия во время удаления компонента.
  • Можно реализовать методы интерфейсов ServiceMix для управления запуском и остановом компонента. Запуск компонента означает его готовность получать сообщения, останов – обратное.
  • Интерфейс ServiceMix позволяет вашему компоненту взаимодействовать с его средой (то есть, со средой JBI). Например, можно написать код, сообщающий о том, какие объекты будут использоваться для обмена сообщениями с вашим компонентом через маршрутизатор NMR.

Вероятно, в качестве отправной точки наиболее эффективным методом интеграции HL7 в ServiceMix будет являться использование open-source реализации HL7. Одним из таких продуктов является интерфейс HAPI (HL7 Application Programming Interface), который вы можете загрузить по ссылке, приведенной в разделе Ресурсы. Вы можете разработать облегченный упаковщик для HAPI и реализовать в нем интерфейсы ServiceMix.


Загрузка

ОписаниеИмяРазмер
Пример для этой статьиj-hsb2.zip232 КБ

Ресурсы

Научиться

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

  • Загрузите пакет Apache ServiceMix (EN).
  • HAPI (EN) – загрузите и испытайте в работе решение по реализации стандартов HL7 с открытым исходным кодом.

Комментарии

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
ArticleID=660296
ArticleTitle=Интеграция служб здравоохранения: Часть 2. Использование Apache ServiceMix в качестве сервисной шины здравоохранения
publish-date=05232011