Integrando serviços de assistência médica, Parte 2: Usando o Apache ServiceMix como barramento de serviço de assistência médica

Interconexão de múltiplos servidores JBI que hospedam aplicativos de assistência médica

O barramento de serviço de assistência médica (HSB) possibilita que diversos aplicativos de assistência médica se interconectem e interoperem para fornecimento de serviço eficiente. A Parte 1 deste artigo de duas partes trata da agregação de serviços de assistência médica usando a arquitetura de Java™ Business Integration (JBI). Esta parte concludente mostra como usar uma implementação JBI de software livre — Apache ServiceMix — como HSB. Configuraremos um aplicativo como serviço interno hospedado no ServiceMix, aprenderemos a interconectar múltiplos ambientes JBI e descobriremos como integrar um padrão de mercado para interoperabilidade de assistência médica no ServiceMix.

Bilal Siddiqui, Consultant

Bilal Siddiqui é engenheiro eletrônico, consultor de XML e cofundador da WaxSys, empresa concentrada em simplificação de e-business. Após se formar, em 1995, em engenharia eletrônica na Universidade de Engenharia e Tecnologia, em Lahore, Paquistão, ele começou a projetar soluções de software para sistemas de controle industrial. Depois, ele começou a trabalhar com o XML e usou sua experiência em programação em C++ para criar ferramentas de processamento XML baseadas na Web e em WAP, soluções de análise do lado do servidor e aplicativos de serviço. Bilal é divulgador da tecnologia e um autor técnico publicado com frequência.



29/Set/2010

Ao conectar vários aplicativos de assistência médica em um servidor de Java Business Integration (JBI), é possível criar um barramento de serviço corporativo para assistência médica: um barramento de serviço de assistência médica (HSB). A Parte 1 deste artigo em duas partes apresenta a JBI, explica sua arquitetura e trata de como ela pode ser usada como HSB que agrega serviços, como aplicativos de prescrição, de departamento de radiologia e de grupo de doadores.

Esta segunda parte demonstra como configurar esses serviços de modo que o servidor JBI possa começar a funcionar como HSB. Mostrarei como usar o Apache ServiceMix, uma implementação JBI popular em software livre, como HSB. Começarei apresentando o ServiceMix e um de seus componentes importantes. A seguir, descreverei como usar esse componente para configurar um aplicativo como serviço interno hospedado no Apache ServiceMix. A terceira seção mostrará como interconectar dois ambientes JBI de modo que um aplicativo conectado a um ambiente JBI possa se interconectar e interoperar com um aplicativo conectado a outro ambiente JBI. A última seção fornece algumas dicas sobre como integrar a funcionalidade do HL7 (Nível de assistência médica 7, um padrão popular de assistência médica apresentado na Parte 1) à JBI.

Apresentação do Apache ServiceMix

O Apache ServiceMix pode hospedar aplicativos JBI, como aqueles mostrados nas Figuras 4, 5, 6 e 7 da Parte 1. Para implementar componentes do ambiente JBI, o ServiceMix usa a popular estrutura de software livre Spring (veja Recursos). Usamos a configuração XML do Spring para configurar serviços dentro do ambiente JBI, o que torna fácil especificar as classes Java que precisam ser instanciadas.

Além de implementar a especificação JBI, o ServiceMix vem com alguns componentes úteis pré-configurados que podem ser usados diretamente no seu aplicativo JBI. Lembre-se que na seção Misturando serviços internos e externos na JBI na Parte 1 mencionamos que é preciso um Mecanismo de serviço (SE) a fim de implementar um serviço interno, como o aplicativo do departamento de radiologia. O ServiceMix fornece uma variedade de SEs reutilizáveis que podem ser usados para criar seus serviços internos. Neste artigo, usaremos o SE do ServiceMix chamado CXF Service Engine (CXFSE).

O CXFSE é um wrapper para a estrutura de serviços da Web Apache CXF, de software livre. Isso permite usar a funcionalidade do Apache CXF em um aplicativo do ServiceMix. O Apache CXF permite criar aplicativos de serviço da Web totalmente integrados com a lógica de negócios interna. O CXFSE tem muitos recursos que o tornam adequado para uso em aplicativos como o HSB.

O Apache CXF usa o conceito de interceptors para integrar o front-end de um serviço da Web (ou seja, a interface definida em um arquivo de linguagem de descrição de serviços da Web [WSDL]) à lógica de negócios do serviço da Web. O CXF fornece vários interceptors prontos para usar e também permite adicionar outros. Um interceptor executa uma tarefa específica, e é possível configurar uma cadeia de interceptors para fazer exatamente o que sua lógica de negócios exige. Por exemplo, é possível configurar a seguinte cadeia de interceptors:

  1. Um interceptor recebe um pedido de serviço de um consumidor de serviço e o transforma em outro formato.
  2. Outro interceptor cria objetos Java a partir do pedido.
  3. O terceiro interceptor invoca a lógica de negócios de passa os objetos Java juntamente com o chamado de invocação.
  4. Um ou alguns outros interceptors podem conter a lógica de negócios real.
  5. O quinto interceptor pega os novos objetos Java do aplicativo de lógica de negócios.
  6. O sexto interceptor transforma os objetos Java em formato XML e envia a resposta de volta para o consumidor de serviço.

Não vou tratar dos detalhes de criação ou configuração de interceptors CXF neste artigo. Em vez disso, usarei uma combinação padrão simples de interceptors prontos que podem invocar o aplicativo do departamento de radiologia. Para saber mais sobre o Apache CXF, veja Recursos.

O CXFSE é um wrapper configurável, ou seja, é possível controlar o comportamento do seu SE escrevendo um arquivo XML. Demonstrarei brevemente como escrever a configuração XML para o CXFSE do aplicativo do departamento de radiologia. Mas primeiro, apresentarei um plano de alto nível para todas as ações necessárias para hospedar um aplicativo (ou serviço) interno no ServiceMix.


Hospedando o aplicativo do departamento de radiologia como serviço interno

O procedimento para hospedar um serviço interno no ServiceMix exige várias configurações, que dividirei nas seguintes cinco etapas:

  1. Escrever e compilar a classe Java que contém a lógica de negócios do aplicativo do departamento de radiologia e expor a classe como serviço da Web.
  2. Configurar as classes Java do aplicativo do departamento de radiologia na estrutura Spring, de modo que esta instancie as classes e as disponibilize de acordo como os requisitos do aplicativo.
  3. Escrever uma interface WSDL para o aplicativo do departamento de radiologia. A especificação JBI usa WSDL 2.0 para definir a interface de serviços expostos por provedores de serviços internos e externos.
  4. Escrever as configurações de JBI para o prestador de serviços (ou seja, o aplicativo do departamento de radiologia), bem como para o consumidor de serviço. (Lembre-se do aplicativo de prescrição na Figura 6 da Parte 1, que é um consumidor de serviço que envia pedidos de serviço para o aplicativo do departamento de radiologia.)
  5. Empacotar o aplicativo do departamento de radiologia como montagem de serviço JBI e copiar o pacote para o ServiceMix.

Depois de executar a Etapa 5, veremos o HSB em ação enviando mensagens do aplicativo de prescrição (um consumidor de serviço) para o aplicativo do departamento de radiologia.

Agora, descreverei e demonstrarei cada etapa.

O aplicativo do departamento de radiologia como classe Java simples

A listagem 1 mostra uma classe Java simples chamada RadiologyDepartment, que tem apenas um método, chamado performTest():

Listagem 1. Classe 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);
    }
}

O método performTest() usa dois parâmetros: testDetails e testResults. Como se pode ver, eles são do tipo Holder <String>. Holder é uma classe definida pelo Java API for XML-Based Web Services (JAX-WS). O CXFSE usa o JAX-WS, de modo que é conveniente usar uma instância dessa classe para trocar informações com a classe Java. A classe Holder tem métodos para inserir dados nessa instância e recuperá-los dela. A estrutura CXF preenche internamente os dados da mensagem de pedido XML para o objeto Holder e passa o objeto Holder para a classe Java do aplicativo do departamento de radiologia.

Deixei o método performTest() vazio (exceto por algumas instruções System.out), apenas por questão de brevidade. Em um aplicativo real, o método performTest() seria ligado à lógica de negócios do aplicativo do departamento de radiologia.

É preciso compilar a classe RadiologyDepartment. O download deste artigo contém uma pasta chamada sample1\RadiologyService, onde se encontra o código da classe RadiologyDepartment e uma forma compilada da classe.

Também será preciso gerar os arquivos de Java API for XML Binding (JAXB) correspondentes à classe RadiologyDepartment. Esses arquivos JAXB são usados pelo JAX-WS API, de modo que o Apache CXF precisa deles para expor sua classe RadiologyDepartment como serviço da Web. Use uma ferramenta útil chamada wsgen para gerar todos os arquivos necessários a partir da sua classe RadiologyDepartment. O wsgen encontra-se na pasta ..\jdk1.6.0_12\bin da sua instalação de JDK1.6. (Consulte Recursos para saber mais sobre a ferramenta wsgen.)

Para os fins deste artigo, forneci um arquivo ws.bat no download. Basta executar o ws.bat para gerar os arquivos JAXB necessários. Também é possível encontrar esses arquivos na forma fonte ou compilada na pasta sample1\RadiologyService.

Configurando a classe RadiologyDepartment na estrutura Spring

A listagem 2 mostra o arquivo de configuração XML de Spring para a classe RadiologyDepartment:

Listagem 2. Configuração XML de Spring para o serviço do departamento de radiologia
<?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>

Note que a tag raiz da listagem 2 é <beans>, que faz parte do espaço para nome XML de Spring. O propósito da tag <beans> é conter os diferentes Java beans (ou instâncias de classes Java) do seu aplicativo. É possível configurar seus Java beans específicos do aplicativo dentro da tag <beans>. O Spring trata da instanciação de classes Java e as disponibiliza para o aplicativo que precisa usá-las. Não é preciso se preocupar sobre quem instanciará as classes Java e como as instâncias ficarão disponíveis umas para as outras. Isso é trabalho do Spring. Basta escrever as classes e configurá-las no Spring.

A tag <beans> da listagem 2 contém a declaração de espaço de nomes para um espaço de nomes http://servicemix.apache.org/cxfse/1.0. O ServiceMix define esse espaço de nomes, cujo propósito é especificar o comportamento do CXFSE de acordo com os requisitos do seu aplicativo. Chamarei esse espaço de nomes de cxfse.

O espaço de nomes cxfse contém tags para especificar exatamente para que queremos usar o CXFSE. Há várias opções disponíveis. Pode-se ver na listagem 2 que a tag raiz <beans> contém uma tag <endpoint> que pertence ao espaço de nomes cxfse. A tag <endpoint> é o início ou fim de um canal de comunicação.

Para entender totalmente o que é um terminal, consulte novamente a Figura 6 da Parte 1, na qual o aplicativo de prescrição envia uma mensagem para o aplicativo do departamento de radiologia. O aplicativo de prescrição e o aplicativo do departamento de radiologia são os terminais. A mensagem se origina do aplicativo de prescrição, passa por vários componentes do ambiente JBI — como componente de ligação (BC), roteador de mensagens normalizadas (NMR) e SE — e, por fim, acaba no aplicativo do departamento de radiologia.

Estamos configurando o aplicativo do departamento de radiologia na listagem 2, de modo que usamos a tag <endpoint> diretamente dentro da tag <beans>. Isso diz ao ServiceMix que estamos configurando um terminal.

Os terminais podem ser de vários tipos. Por exemplo, um terminal pode ser uma cadeia de interceptors que executa diversas tarefas em sequência (como a cadeia de interceptors que vimos na seção Apresentação do Apache ServiceMix). Mas para simplificar, vou usar uma classe Java simples (a classe RadiologyDepartment) neste artigo. Uma instância de uma classe Java simples normalmente é chamada de Plain Old Java Object (POJO). O espaço de nomes cxfse contém uma tag chamada <pojo>, que fica dentro de uma tag <endpoint> para especificar que esse terminal é apenas uma instância de uma classe Java simples.

Por fim, na listagem 2, podemos ver uma tag <bean>, que faz parte do espaço de nomes do Spring e especifica o bean (instância de uma classe Java) que agirá como terminal. A tag <bean> tem um atributo chamado class, que especifica o nome completo da classe (a saber, com.hsb.RadiologyDepartment) cuja instância será o terminal.

O arquivo de configuração XML do Spring mostrado na listagem 2 se encontra como arquivo xbean.xml na pasta sample1\RadiologyService\ de download.

Escrevendo o arquivo WSDL para o aplicativo de radiologia

A listagem 3 mostra a interface WSDL para o aplicativo do departamento de radiologia:

Listagem 3. Interface WSDL para o aplicativo do departamento de radiologia
<?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>

A listagem 4 mostra a ligação de WSDL para o aplicativo do departamento de radiologia:

Listagem 4. Ligação de WSDL para o aplicativo do departamento de radiologia
<?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>

Pode-se ver que o serviço da Web é simples: contém apenas uma operação chamada performTest com alguns parâmetros. Os detalhes da interface e ligação de WSDL estão fora do escopo deste artigo. Veja em Recursos o link para um artigo do developerWorks que explica a WSDL em detalhes.

Na pasta de download sample1\RadiologyService, encontram-se os arquivos WSDL mostrados na listagem 3 e na listagem 4 como Radiology.wsdl e RadiologyService.wsdl, respectivamente.

Empacotando o aplicativo do departamento de radiologia

É preciso empacotar a classe RadiologyDepartment e as classes JAXB acompanhantes, xbean.xml do Spring, e os arquivos WSDL do aplicativo do departamento de radiologia em um arquivo zip chamado RadiologyService.zip. Todos esses arquivos se encontram na pasta sample1\RadiologyService\ em download. Já preparei o arquivo zip para você; está na pasta sample1\.

Configurando e empacotando um consumidor de serviço

Empacotamos nosso aplicativo de radiologia, que é um provedor de serviços. Mas não podemos executar esse aplicativo a menos que tenhamos um consumidor de serviço configurado em um servidor JBI.

Configurar o consumidor de serviço em JBI é bem similar a criar a configuração de provedor que acabamos de ver. É preciso escrever a configuração XML do Spring e o arquivo WSDL para o terminal do consumidor.

A configuração XML do Spring para seu consumidor de serviço é mostrada na listagem 5:

Listagem 5. Configuração XML para um consumidor de serviço
<?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>

Pode-se ver que a listagem 5 é muito similar à listagem 2. A listagem 5 usa um espaço de nomes cxfbc em vez do espaço de nomes cxfse visto na listagem 2. Usamos o espaço de nomes cxfbc aqui porque o consumidor precisa de BC em vez de SE. Consulte novamente as seis etapas que acompanham a Figura 6 da Parte 1, nas quais se pode ver que o aplicativo de prescrição (consumidor de serviço) precisa de BC e o aplicativo do departamento de radiologia (prestador de serviços interno) precisa de SE. O ServiceMix fornece espaços de nomes de SE e BC para os aplicativos CXF, fornecendo total flexibilidade na configuração do seu aplicativo da maneira desejada.

Os arquivos WSDL para o consumidor de serviço são muitos similares aos da listagem 3 e da listagem 4. Essas configurações de consumidor se encontram na pasta sample1\PrescriptionService em download.

Também é preciso empacotar a configuração XML do Spring e os arquivos WSDL do consumidor em um arquivo zip chamado PrescriptionService.zip. Já fiz isso para você. Veja o arquivo PrescriptionService.zip na pasta sample1\ em download.

Montando o aplicativo de radiologia com o aplicativo de prescrição

Já configuramos duas unidades de serviço: uma para o aplicativo do departamento de radiologia (provedor de serviços) e outra para o aplicativo de prescrição (consumidor de serviço). Agora montaremos as unidades de serviço em uma montagem de serviço JBI.

Para criar a montagem de serviço, basta escrever uma configuração XML de JBI, como mostrado na listagem 6:

Listagem 6. Configuração XML de JBI para a montagem de serviço do aplicativo do departamento de radiologia
<?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>

A tag raiz na listagem 6, chamada <jbi>, pertence ao espaço de nomes JBI (http://java.sun.com/xml/ns/jbi). A tag <jbi> contém um filho chamado <service-assembly>, que inclui o nome e a descrição do serviço JBI que está sendo implementado, além de várias unidades de serviço na montagem de serviço.

A tag <service-assembly> tem duas tags filho <service-unit>. Cada filho <service-unit> representa uma unidade individual do serviço. Estamos configurando apenas o aplicativo do departamento de radiologia e o aplicativo de prescrição, de modo que sua montagem de serviço contém apenas duas tags <service-unit>, uma para cada aplicativo.

Cada tag <service-unit> inclui o nome da unidade, sua descrição e o arquivo zip da unidade de serviço. Pode-se ver que a tag <artifacts-zip> dentro de cada tag <service-unit> contém o nome do arquivo zip; ele corresponde aos nomes de arquivo para os dois arquivos zip criados no fim das seções Empacotando o aplicativo do departamento de radiologia e Configurando e empacotando um consumidor de serviço. O arquivo RadiologyService.zip refere-se ao aplicativo do departamento de radiologia e o PrescriptionService.zip, ao aplicativo de prescrição.

É preciso salvar a configuração na listagem 6 como arquivo XML chamado jbi.xml. Já fiz isso por você. O arquivo se encontra na pasta META-INF\ de download. Por fim, empacote a pasta META-INF\ e os dois arquivos zip em RadiologyAssembly.zip. Já preparei o arquivo RadiologyAssembly.zip para você; ele se encontra na pasta sample1\ de download.

RadiologyAssembly.zip é o arquivo zip final, que contém tudo o que fizemos até aqui.

Dicas para desenvolver aplicativos em ServiceMix

O download deste artigo inclui o arquivo Tips.txt, que fornece dicas úteis sobre:

  • Ativação do rastreamento de depuração do ServiceMix
  • Limpeza do cache do ServiceMix
  • Reimplementação de um componente do ServiceMix

Não é necessário ler essas dicas para executar o aplicativo de amostra deste artigo, mas elas podem ser úteis para desenvolver seus próprios aplicativos no ServiceMix.

Testando o serviço do departamento de radiologia

Execute as seguintes etapas para testar o aplicativo do departamento de radiologia:

  1. Faça o download do Apache ServiceMix 3.3.1 e instale-o no seu computador (veja Recursos).
  2. Inicie o ServiceMix clicando duas vezes no arquivo servicemix.bat, que se encontra na pasta ..\apache-servicemix-3.3.1\bin da sua instalação ServiceMix. Aguarde alguns momentos para que o servidor inicie seus serviços.
  3. Copie RadiologyAssembly.zip da pasta sample1\ para a pasta ..\apache-servicemix-3.3.1\hotdeploy da sua instalação do ServiceMix. Assim que copiar o arquivo zip, o ServiceMix detectará que um novo aplicativo está sendo implementado. Iniciarei o processo de implementação, que aparecerá no console de saída do ServiceMix. Aguarde a conclusão da implementação.

O ServiceMix fornece um cliente SOAP simples, baseado em navegador, que pode ser usado para testar seus aplicativos do ServiceMix. Esse cliente acompanha vários aplicativos de amostra que vêm empacotados no ServiceMix. Ele se encontra na forma de arquivo client.html na pasta de instalação do ServiceMix: ..\apache-servicemix-3.3.1\examples\cxf-wsdl-first.

Abra o arquivo client.html no seu navegador e digite http://localhost:8092/RadiologyService no campo Target da página HTML. Depois, digite o pedido de SOAP mostrado na listagem 7 na caixa de texto abaixo do campo Target:

Listagem 7. Pedido de mensagem SOAP para testar seu aplicativo de radiologia
<?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>

Forneci essa mensagem de pedido do SOAP na forma do arquivo SOAPRequest.txt no download. É possível copiar o pedido SOAP do arquivo SOAPRequest.txt e colá-lo na caixa de texto abaixo do campo Target. Depois de inserir o endereço e o pedido de SOAP, a página client.html terá a aparência mostrada na figura 1:

Figura 1. Página client.html
The client.html page

Agora, clique no botão Send na parte inferior da página e aguarde alguns momentos. O consumidor de serviço do aplicativo do departamento de radiologia recebe o pedido, roteia-o para o NMR e, em seguida, pelo mecanismo CXFSE para a classe RadiologyDepartment. A classe RadiologyDepartment então responde. A resposta viaja de volta até o cliente SOAP. Pode-se ver a resposta na sua caixa de texto oposta à caixa de texto de pedido, como mostrado na Figura 2:

Figura 2. Resposta mostrada no seu cliente SOAP
Response shown on your SOAP client

Interconectando servidores JBI

Vimos como configurar o aplicativo do departamento de radiologia como prestador de serviços interno e invocá-lo a partir de um consumidor de serviço externo. Agora, demonstrarei como configurar dois servidores JBI de modo que um consumidor de serviço conectado a um servidor JBI possa invocar os serviços oferecidos por um prestador de serviços conectado a outro servidor JBI. Essa situação é similar à Figura 7 da Parte 1, onde discutimos a interconexão de servidores JBI.

Compare as figuras 4 e 7 da Parte 1. A Figura 4 mostra um consumidor de serviço e um prestador de serviços externo conectados a um servidor JBI. A Figura 7 mostra um consumidor de serviço conectado a um JBI e o provedor conectado a outro servidor JBI, enquanto os dois servidores JBI estão interconectados entre si.

Do ponto de vista de JBI, as duas situações são idênticas. Se um serviço é externo ao ambiente JBI, não importa se o serviço externo está conectado diretamente ao servidor JBI ou indiretamente por meio de outro servidor JBI. Isso quer dizer que a configuração JBI feita de acordo com a Figura 7 da Parte 1 também funcionará bem no caso de querermos conectar nossos provedores de assistência médica de acordo com a Figura 4 da Parte 1. Assim, só mostrarei o cenário da Figura 7 neste artigo e deixarei o cenário da Figura 4 para você.

Nesta seção, precisamos de dois servidores JBI. O primeiro servidor tem um consumidor de serviço como prestador de serviços externo. O segundo servidor JBI tem um prestador de serviços interno. Isso é mostrado na Figura 3:

Figura 3. Dois servidores JBI, um com consumidor de serviço externo e outro com prestador de serviços interno
Two JBI servers, one with an external service consumer and another with an internal service provider

O primeiro servidor JBI achará que o segundo servidor JBI é o serviço externo. O segundo servidor JBI achará que o primeiro servidor JBI é um consumidor de serviço.

Isso quer dizer que basta usar a configuração do aplicativo do departamento de radiologia como segundo servidor JBI. Basta configurar um prestador de serviços externo como consumidor no primeiro servidor JBI.

Configurar um prestador de serviços externo simplesmente significa dizer ao primeiro servidor JBI que o segundo é um serviço da Web. Basta fazer duas coisas: escrever um arquivo de configuração XML do Spring similar ao das listagens 2 e 5, e arquivos WSDL similares aos da listagem 3 e 4.

Configurando um prestador de serviços externo para o primeiro servidor JBI

A listagem 8 contém a configuração do Spring para um prestador de serviços externo:

Listagem 8. Configuração do Spring para um prestador de serviços externo
<?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>

Pode-se ver que a tag <beans> na listagem 8 contém a mesma declaração de espaço de nomes cxfbc vista na listagem 5. Isso se dá porque aqui na listagem 8, estamos configurando um prestador de serviços externo, enquanto na listagem 5 configuramos um consumidor de serviço externo. Sempre que estiver configurando um aplicativo externo (provedor ou consumidor), use o espaço de nomes cxfbc.

Note também que a listagem 8 contém uma tag <provider> do espaço de nomes cxfbc (exatamente como a tag <consumer> da listagem 5). A tag <provider> tem vários atributos que especificam detalhes sobre o serviço externo:

  • service: Nome do prestador de serviços de radiologia hospedado no segundo servidor JBI.
  • endpoint: Porta WSDL do aplicativo do departamento de radiologia que aguarda pedidos de serviço.
  • locationURI: Endereço de rede do serviço do departamento de radiologia. Esse endereço de rede existe no segundo servidor JBI. Quando testei esse aplicativo, meu segundo servidor JBI estava sendo executado em uma máquina cujo endereço de rede era 192.168.10.33 e a porta do segundo servidor JBI era 8092.
  • wsdl: Nome e localização do arquivo WSDL. O ServiceMix resolve o caminho de classe até a raiz do arquivo zip para um serviço. Pode-se ver no download deste artigo que o WSDL existe na pasta sampl2\JBI1\RemoteRadiologyService. O conteúdo da pasta RemoteRadiologyService forma a raiz do arquivo zip desse aplicativo. Portanto, simplesmente escrevi classpath:RadiologyService.wsdl como valor do atributo wsdl.

O arquivo WSDL desse serviço de provedor é o mesmo que os arquivos WSDL mostrados nas listagens 3 e 4. A listagem 8 encontra-se como xbean.xml e seu WSDL acompanhante como RadiologyService.wsdl na pasta sample2\JBI1\RemoteRadiologyService de download. É preciso empacotar todo o conteúdo da pasta RemoteRadiologyService em um arquivo zip chamado RemoteRadiologyService.zip. Já preparei o arquivo zip para você; ele se encontra na pasta sample2\JBI1.

Configurando um consumidor de serviço para o primeiro servidor JBI

A configuração de um consumidor de serviço para o primeiro servidor JBI é exatamente igual à configuração feita na listagem 5, então, não repetirei a listagem aqui. Essa configuração de consumidor encontra-se no arquivo xbean.xml na pasta sample2\JBI1\PrescriptionService.

Também é necessário um arquivo WSDL que acompanha a configuração de consumidor. Ele é muito similar ao arquivo WSDL da listagem 3. O arquivo WSDL encontra-se na pasta sample2\JBI1\PrescriptionService. Também empacotei o conteúdo da pasta PrescriptionService em PrescriptionService.zip.

Montando o provedor e o consumidor para o primeiro servidor JBI

Os dois arquivos zip para o primeiro servidor JBI estão prontos. A última etapa é montar os arquivos zip em uma montagem de serviço. O arquivo de configuração JBI para a montagem completa é mostrado na listagem 9:

Listagem 9. Configuração JBI para a montagem completa do primeiro servidor 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>

Pode-se ver que o arquivo de montagem da JBI da listagem 9 é muito similar à listagem 6. Essa configuração JBI encontra-se na listagem 9 como jbi.xml, na pasta sample2\JBI1\META-INF de download.

Por fim, será preciso empacotar jbi.xml juntamente com os arquivos RemoteRadiologyService.zip e PrescriptionService.zip em outro arquivo zip chamado RemoteRadiologyAssembly.zip. Preparei esse arquivo para você; ele se encontra na pasta sample2\JBI1.

Testando a interconexão de servidores JBI

A fim de testar a interconexão de servidores JBI, executaremos o mesmo aplicativo RadiologyAssembly que vimos na seção Testando o serviço do departamento de radiologia. Ele atuará como seu segundo servidor JBI.

Quanto testei essa interconexão JBI, meu segundo servidor JBI estava em execução em uma máquina cujo endereço de rede local era 192.168.10.33. Como dá para imaginar, o provedor do primeiro servidor JBI deve saber o endereço de rede do segundo servidor JBI. Portanto, esse endereço de rede ocorre em dois lugares nos seus arquivos de configuração para o provedor do primeiro servidor JBI:

  • O atributo locationURI no arquivo xbean.xml
  • O atributo address da tag <soap> no arquivo RadiologyService.wsdl

Se seu segundo servidor JBI estiver em execução em um endereço diferente, será preciso fazer as mudanças adequadas nesses dois lugares.

Para executar o primeiro servidor JBI, execute estas etapas:

  1. Instale o Apache ServiceMix 3.3.1 em uma máquina separada. Testei a interconexão dos servidores JBI usando duas máquinas, uma para o primeiro servidor JBI e outra para o segundo servidor JBI.
  2. Inicie o ServiceMix clicando duas vezes no arquivo servicemix.bat, na pasta ..\apache-servicemix-3.3.1\bin da sua instalação ServiceMix. Aguarde alguns momentos para que o servidor inicie seus serviços.
  3. Copie RemoteRadiologyAssembly.zip da pasta sample2\JBI1 para a pasta ..\apache-servicemix-3.3.1\hotdeploy da sua instalação do ServiceMix. Assim que o arquivo for copiado, o ServiceMix detectará que um novo aplicativo está sendo implementado e iniciará o processo de implementação, que aparecerá no console de saída do ServiceMix. Aguarde a conclusão da implementação.
  4. Abra o mesmo arquivo client.html usado antes ao testar o aplicativo do departamento de radiologia no seu navegador. Digite http://localhost:8092/RadiologyService no campo Target da página HTML. Depois, digite o mesmo pedido de SOAP mostrado na listagem 7 na caixa de texto abaixo do campo Target.
  5. Clique no botão Send e aguarde alguns momentos. O pedido irá para o primeiro servidor JBI, viajará pelo seu BC de consumidor, NMR e BC de provedor, e então irá para o segundo servidor JBI. O BC de consumidor no segundo servidor JBI receberá o pedido, o roteará pelo NMR e pelo CXFSE, e, por fim, para a classe RadiologyDepartment, que responderá. A resposta viajará pelos dois servidores JBI de volta até o seu navegador, que exibirá a resposta na sua caixa de texto oposta à caixa de texto de pedido.

Integrando padrões específicos do mercado ao ServiceMix

Vimos como integrar uma variedade de serviços ao ServiceMix. O serviço que usei como exemplo neste artigo (o serviço de aplicativo do departamento de radiologia) se baseia em WSDL. Contudo, como expliquei na seção XML para assistência médica interoperável da Parte 1, nem todos os serviços se baseiam em WSDL. Também podem se basear em padrões específicos do mercado, como HL7. Sempre que quiser integrar um serviço em uma JBI, é preciso um componente JBI, quer o serviço seja baseado em WSDL, quer seja específico do mercado.

Uma norma geral comumente usada para definir interfaces de serviço é que o WSDL pode ser usado entre todos os segmentos de mercado. É por isso que encontramos muitas implementações baseadas em WSDL que podem ser integradas no ServiceMix, e é por isso que o ServiceMix vem junto com o Apache CXF. Esse não é o caso do HL7. O suporte para o HL7 não está disponível no ServiceMix no momento em que escrevo este artigo, embora o Web site da ServiceMix tenha comunicado que o projeto integrará o suporte a HL7 no ServiceMix no futuro.

É possível que encontremos o problema de integrar padrões específicos do mercado ao ServiceMix. Assim, vou mencionar aqui um plano de alto nível para criar seus próprios componentes que funcionem com o ServiceMix.

Sempre que integrar um componente ao ServiceMix, será preciso controlar o modo como ele responde aos pedidos de serviço dos consumidores. O ServiceMix definiu interfaces que permitem controlar o comportamento de um componente JBI específico do mercado exatamente da maneira desejada:

Flexibilidade do ServiceMix

O ServiceMix fornece várias interfaces que podem ser usadas para implementar sua própria funcionalidade de componentes:

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

Veja em Recursos um link para a documentação oficial do ServiceMix, onde se encontram detalhes sobre essas interfaces.

  • É possível controlar o que seu componente fará quando instalado. Por exemplo, é possível criar tabelas de banco de dados durante a instalação de modo que o componente possa armazenar dados do aplicativo.
  • De modo similar, o ServiceMix permite escrever o código de desinstalação que desfaz ou limpa as coisas que seu componente fez durante a instalação.
  • É possível implementar métodos de interfaces do ServiceMix para controlar o início e a interrupção de um componente. Iniciar um componente significa que ele fica pronto para receber mensagens; interrompê-lo significa o contrário.
  • Uma interface do ServiceMix ativa seu componente para aprender e interagir com seu ambiente (ou seja, o ambiente JBI). Por exemplo, é possível escrever código que diz que objetos de comunicação serão usados para trocar mensagens com seu componente via NMR.

Talvez a estratégia mais eficiente para integrar o suporte a HL7 ao ServiceMix é usar uma implementação HL7 de software livre como ponto de partida. Um produto desses é chamado de HAPI (Interface de programação de aplicativos HL7) e já está disponível (veja Recursos). É possível projetar um wrapper leve para HAPI e implementar as interfaces ServiceMix ao seu wrapper.


Download

DescriçãoNomeTamanho
Sample code for this articlej-hsb2.zip232KB

Recursos

Aprender

Obter produtos e tecnologias

  • Apache ServiceMix: Faça o download do ServiceMix.
  • HAPI: Faça o download e teste essa implementação HL7 de software livre.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Segmentos de mercado, Tecnologia Java
ArticleID=499001
ArticleTitle=Integrando serviços de assistência médica, Parte 2: Usando o Apache ServiceMix como barramento de serviço de assistência médica
publish-date=09292010