Integrando serviços de assistência médica, Parte 1: Usando barramento de serviço corporativo para assistência médica

Configure um servidor de Java Business Integration para fazer diversas interconexões e interoperações de aplicativos

O ideal é que os diversos serviços de que os pacientes precisam sejam interconectados e interoperacionais para aprimorar a qualidade e eficiência da assistência médica. Este artigo, a primeira de duas partes, trata da agregação de serviços de assistência médica usando a arquitetura de Java™ Business Integration (JBI). Essa plataforma de agregação — um barramento de serviço de assistência médica (HSB) — pode ser facilmente adaptada a outros segmentos de mercado.

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.



02/Jul/2010

Este artigo em duas partes demonstra a agregação de vários serviços relacionados à assistência médica por um barramento de serviço, o que eu chamo (muito bem) de barramento de serviço de assistência médica (HSB). Aqui, na Parte 1, começarei com um cenário de caso de uso no qual vários aplicativos que servem às necessidades do pacientes são conectados a um HSB, e explicarei os recursos que o HSB deve fornecer. A seguir, apresentarei a arquitetura Java Business Integration (JBI), usada na construção do HSB. Seguindo a sequência de eventos que ocorrem dentro de um servidor de JBI, veremos como a JBI funciona internamente e como seus componentes se coordenam com aplicativos externos. A última seção da Parte 1 fornecerá exemplos de configuração que demonstram como é possível controlar o comportamento dos componentes de JBI para que sejam aplicados à assistência médica. Na Parte 2, aprenderemos a integrar serviços de assistência médica usando a funcionalidade existente de uma implementação JBI de software livre (Apache ServiceMix) e implementando nova funcionalidade de ServiceMix.

Barramento de serviço para assistência médica

Um HSB integra uma variedade de serviços relacionados à assistência médica. Imagine as necessidades de um paciente de emergência que exige cuidados salvadores, incluindo serviços como transfusão de sangue, prescrições de emergência e exames radiológicos.

Quando o paciente chega a uma instalação médica, o doutor encarregado usa o barramento de serviço para verificar o histórico de alergia dele em um aplicativo executado no telefone celular do paciente. O doutor também insere as observações iniciais sobre a condição do paciente em um aplicativo de prescrição médica conectado ao barramento. As observações dele percorrem o barramento de serviço até um servidor da Web que serve de host do portal da operadora de plano de saúde do paciente.

O médico prescreve então uma transfusão de sangue ao paciente no mesmo aplicativo de prescrição. A prescrição é enviada automaticamente pelo barramento de serviço não apenas para alguns bancos de sangue, mas também para um aplicativo de grupo de doadores, que envia mensagens SMS para doadores cujas amostras de sangue tenham sido previamente equiparadas às do paciente. O requisito de sangue do aplicativo do grupo de doadores também é enviado pelo barramento de serviço.

O doutor também escreve uma prescrição para medicamentos de emergência e um exame radiológico, que são inseridos no mesmo aplicativo de prescrição. O aplicativo de prescrição envia essas prescrições pelo barramento para a farmácia interna e o departamento de radiologia da instalação médica.

Agregação de serviços

É possível ver nessa história de caso de uso que o HSB permite que diversos aplicativos se interconectem e interoperem, permitindo assim a agregação de serviços. Dois tipos principais de aplicativos — consumidores de serviço e provedores de serviços — se conectem ao HSB. O aplicativo de prescrição que enviou o requisito de transfusão de sangue para o HSB agiu como consumidor do serviço (um aplicativo que solicita ou consome um serviço). O aplicativo de grupo de doadores que enviou as mensagens SMS para os doadores de sangue em potencial agiu como prestador de serviços (um aplicativo que presta o serviço solicitado). Interconexão e interoperação são requisitos diferentes que juntos fornecem agregação de serviços. Interconexão significa que os provedores de serviços e os consumidores de serviço têm um modo em comum de se conectar (alcançar um ao outro), de modo que podem interoperar entre si (trocar informações e mensagens). O HSB usa o popular formato XML para a troca interoperável de mensagens.

HSB como SOA

Uma arquitetura como a do HSB, que depende muito de "serviços", é chamada de Arquitetura Orientada a Serviços (SOA). SOA simplesmente significa que tudo são serviços. O aplicativo de grupo de doadores é um serviço que envia mensagens SMS. O departamento de radiologia também é um serviço, que executa exames radiológicos por demanda. Em uma SOA, qualquer aplicativo que expõe o serviço é um prestador de serviços e o aplicativo que demanda, solicita ou usa o serviço é o consumidor do serviço.

A Figura 1 mostra provedores e consumidores de serviço conectados ao HSB:

Figura 1. Provedores e consumidores de serviço conectados ao HSB
Service providers and consumers connected to an HSB

Note que a Figura 1 mostra três provedores de serviços conectados ao HSB: o portal da operadora de plano de saúde, e os aplicativos do grupo de doadores e do departamento de radiologia. Um HSB deve ser capaz de interconectar consumidores de serviço a provedores de serviços internos e externos, para que possam interoperar entre si. Na Figura 1, o aplicativo do departamento de radiologia existe dentro da instalação médica; os aplicativos do grupo de doadores e do portal da operadora de plano de saúde ficam fora da instalação médica.

Recursos necessários para o HSB

Para possibilitar a interconexão, o HSB deve:

  • Manter um log de todos os provedores de serviços conectados a ele, de modo a poder rotear um pedido de consumo de serviço de um consumidor de serviço para o prestador de serviços apropriado.
  • Fornecer um mecanismo padrão que permita aos provedores e consumidores de serviço conversar entre si por meio do barramento de serviço.
  • Permitir que outros HSBs se interconectem a ele.

Interconexão de HSBs

A interconexão de HSBs é um aplicativo interessante, cuja arquitetura é mostrada na Figura 2:

Figura 2. Interconexão de HSBs
Interconnection of HSBs

A Figura 2 mostra dois HSBs para diferentes instalações médicas. Uma instalação tem um aplicativo de banco de sangue, que o aplicativo de prescrição pode invocar por meio da interconexão dos dois HSBs.

XML para assistência médica interoperável

O XML pode ser usado de duas maneiras para possibilitar a interoperabilidade de serviços de assistência médica:

  • Serviços da Web: Os serviços da Web com base na linguagem de descrição de serviços da Web (WSDL) e no Simple Object Access Protocol (SOAP) são usados com frequência em muitos segmentos de mercado, incluindo assistência médica. O WSDL usa XML para definir o serviço; ou seja, definir a interface que o serviço fornece. SOAP é um protocolo baseado em XML usado para o sistema de mensagens real entre os provedores e consumidores de serviços. (Consulte Recursos para obter mais informações sobre WSDL e SOAP.) O HSB deve ser capaz de interconectar qualquer aplicativo de assistência médica que use WSDL e SOAP para interoperabilidade.
  • Nível de saúde 7: O Nível de saúde 7 (HL7) é um conjunto de normas de assistência médica que define muitas estruturas de dados usadas para especificar informações sobre assistência médica, como prontuários médicos, prescrições e resumos de altas de pacientes. (As versão mais antigas do HL7, 1 e 2, se baseavam em ASCII. A recente versão 3.X do HL7 usa XML como seu formato de dados para definir as estruturas de mensagem.)

Generalizando o HSB para outros segmentos de mercado

Os requisitos de interconexão e interoperabilidade tratados aqui são aplicáveis a outros segmentos de mercado além da assistência médica. Por exemplo, os diversos serviços da indústria turística — hotéis, linhas aéreas, locadoras de veículos e operadoras de turismo — devem se interconectar e interoperar para atender aos seus clientes. Os três recursos de interconexão do HSB se aplicam também à indústria turística. Diferentes provedores de serviços, como hotéis e locadoras de veículos, podem usar facilmente WSDL e SOAP para interoperar. E normas baseadas em XML, específicas do setor, como HL7, podem existir em qualquer outro segmento de mercado.

O HSB que demonstrarei pode interconectar aplicativos de assistência médica que usam as normas WSDL, SOAP e HL7.

ESB: Arquitetura geral para interoperabilidade e interconexão

Essa arquitetura interoperável e interconectada generalizada é comumente chamada de barramento de serviço corporativo (ESB), que pode:

  • Ser baseada em SOA.
  • Permitir que os provedores e consumidores de serviços usem WSDL e SOAP.
  • Ser extensível e flexível no sentido de permitir que os provedores e consumidores de serviços usem normas baseadas em XML, específicas do setor, como HL7.

A ideia de ESB não é nova. Hoje existem várias implementações de ESB. (Consulte os links em Recursos que conduzem a alguns ESBs populares de software livre.) Isso quer dizer que não é preciso criar um HSB do zero. É possível configurar um ESB existente para funcionar na área de assistência médica.


Usando JBI como HSB

A especificação JBI define um ambiente de integração de negócios Java padronizado. A JBI fornece todos os recursos de um ESB que mencionei, de modo que o usarei para criar um HSB.

Há várias implementações JBI disponíveis, incluindo uma implementação popular de software livre da Apache chamada ServiceMix. O restante desta série falará sobre o uso de JBI e a configuração de ServiceMix para criar um HSB.

Componentes JBI trabalhando juntos para assistência médica

A Figura 3 mostra como a JBI pode ser usada como HSB:

Figura 3. JBI funcionando como HSB
JBI working as an HSB

Pode-se ver na Figura 3 que os três componentes principais da JBI são componentes de ligação (BCs), mecanismos de serviço (SEs) e um roteador de mensagens normalizadas (NMR).

Explicarei o funcionamento dos componentes JBI com a ajuda da sequência de eventos (mostrada na Figura 4) que ocorre quando o aplicativo de prescrição (consumidor de serviço) se conecta ao aplicativo de grupo de doadores (provedor de serviços):

Figura 4. Consumidor do serviço se conectando a um prestador de serviços por meio de JBI
Service consumer connecting to a service provider though JBI

A sequência a seguir ocorre na Figura 4:

Etapa 1: O aplicativo de prescrição (consumidor de serviço) se conecta à JBI e solicita o serviço oferecido pelo aplicativo de grupo de doadores (prestador de serviços que fica fora do ambiente JBI).

Etapa 2: O ambiente JBI encaminha a solicitação de serviço para um BC adequado — , aquele que recebe todas as solicitações de serviço do aplicativo de prescrição. Cada consumidor ou provedor de serviço que funciona com JBI tem um BC particular dedicado dentro do ambiente JBI.

Etapa 3: O BC transforma a solicitação de invocação de serviço em um formato normalizado definido pela especificação JBI. O propósito de definir o formato normalizado é possibilitar a interoperação entre BCs. Todos os BCs de JBI entendem o formato normalizado. Cada BC também entende o formato do provedor ou consumidor de serviços ao qual o BC é anexado. Em outras palavras, o recurso de normalização de JBI é um formato comum no qual todos os BCs transformam as mensagens recebidas de seus respectivos consumidores ou produtores de serviço.

Etapa 4: O BC do aplicativo de prescrição entrega a mensagem normalizada para o NMR mostrado na Figura 4. O inteiro ambiente JBI inclui um único NMR.

Etapa 5: A tarefa do NMR é receber mensagens normalizadas de um BC, identificar o prestador de serviços de destino e encaminhar (ou rotear) a mensagem normalizada para outro BC do serviço de destino. Nesta etapa, o NMR encaminha a mensagem normalizada para o BC conectado ao aplicativo de grupo de doadores.

Etapa 6: O BC do aplicativo de grupo de doadores desnormaliza a mensagem normalizada, transformando-a assim no formato entendido pelo aplicativo de grupo de doadores.

Etapa 7: O BC entrega a mensagem desnormalizada ao aplicativo de grupo de doadores.

Essa sequência de eventos revela dois pontos simples sobre a JBI:

  • A JBI funciona com a ideia de roteamento de mensagem normalizada. Cada mensagem é normalizada por um BC e entregue ao NMR. O NMR roteia a mensagem para outro BC, que a desnormaliza em um formato entendido pelo prestador de serviços desejado.
  • O mecanismo de roteamento de mensagem normalizada fornece uma arquitetura dissociada. Dissociação significa que os provedores e consumidores de serviços interagem entre si apenas por meio do mecanismo de NMR. Não interagem diretamente uns com os outros.

A principal vantagem dessa arquitetura dissociada é que implementamos determinado formato de dados ou padrão apenas uma vez, na forma de BC. Posteriormente, todos os provedores de serviços que fornecem serviços de acordo com o formato de dados determinado simplesmente usam uma instância do BC para se integrarem ao ambiente JBI.

Por exemplo, se for preciso integrar HL7 em JBI, será preciso um BC que entenda o HL7. Se você tiver o BC de HL7, poderá integrar qualquer serviço do HL7 à JBI, formando assim um HSB.

A Parte 2 desta série lhe apresentará etapas práticas para criar um BC baseado em HL7 e integrar o HL7 à JBI. Mas, por enquanto, há mais coisas para aprendermos sobre a JBI.

Misturando serviços internos e externos na JBI

A discussão que acompanha a Figura 4 mostra a comunicação entre um consumidor de serviço e um prestador de serviços que reside fora do ambiente JBI.

Lembre-se do caso de uso no início deste artigo em que o aplicativo de prescrição também enviou uma mensagem para um departamento de radiologia interno. Isso significa que seu ambiente JBI deve ser capaz de hospedar o aplicativo do departamento de radiologia como serviço interno. Os serviços internos na JBI são hospedados como SEs.

Os SEs são idênticos aos BCs, mas com um recurso adicional: Um SE também contém a lógica de negócios do serviço interno (por exemplo, do aplicativo do departamento de radiologia). Os BCs e SEs se conectam ao NMR da JBI, como se vê na Figura 3, que modifiquei na Figura 5 para mostrar o aplicativo do departamento de radiologia como SE:

Figura 5. O aplicativo do departamento de radiologia mostrado como SE
Radiology Department application shown as an SE

A sequência de eventos para acessar um serviço interno (ou seja, um SE) é mostrada na Figura 6:

Figura 6. Consumidor de serviço acessando um prestador de serviços interno
A service consumer accessing an internal service provider

A sequência de eventos mostrada na Figura 6 representa o que acontece quando um consumidor de serviço como o aplicativo de prescrição envia uma mensagem para o aplicativo do departamento de radiologia (um prestador de serviços interno):

Etapa 1: O aplicativo de prescrição (consumidor de serviço) se conecta à JBI e solicita o serviço oferecido pelo aplicativo do departamento de radiologia.

Etapa 2: O ambiente JBI envia o pedido de serviço para o BC do aplicativo de prescrição.

Etapa 3: O BC transforma o pedido de invocação de serviço em uma mensagem normalizada.

Etapa 4: O BC entrega a mensagem normalizada para o NMR.

Etapa 5: O NMR encaminha a mensagem normalizada para o aplicativo do departamento de radiologia (um SE).

Etapa 6: O SE desnormaliza internamente a mensagem e invoca a lógica de negócios necessária.

Essa sequência de eventos — que é muito similar à sequência de eventos mostrada na Figura 4 — mostra que um SE contém a funcionalidade de um BC e também a lógica de negócios do aplicativo do provedor de serviços.

Pode parecer que o SE mistura desnecessariamente duas coisas diferentes (a funcionalidade de um BC e a lógica de negócios). Na Parte 2, demonstrarei como criar a lógica de negócios do seu serviço interno sobre um BC existente, sem mistura desnecessária.

Interconectando ESBs baseados em JBI

Veja novamente a Figura 2, na qual mostro as interconexões de HSBs. Essa interconexão pode ser obtida por meio de JBI, como mostrado na Figura 7:

Figura 7. Dois ambientes JBI interconectados
Two interconnected JBI environments

Note que a Figura 7 mostra diferentes aplicativos conectados a dois ambientes JBI separados. A sequência de eventos a seguir acontece quando o aplicativo de prescrição (mostrado conectado à primeira JBI na Figura 7) envia uma mensagem ao aplicativo do banco de sangue (um prestador de serviços que reside dentro do segundo ambiente JBI):

Etapa 1: O aplicativo de prescrição (consumidor de serviço) se conecta à primeira JBI e solicita o serviço oferecido pelo aplicativo do banco de sangue.

Etapa 2: O primeiro ambiente JBI envia o pedido para o BC do aplicativo de prescrição.

Etapa 3: O BC do aplicativo de prescrição transforma o pedido de invocação de serviço em uma mensagem normalizada.

Etapa 4: O BC do aplicativo de prescrição entrega a mensagem normalizada para o NMR.

Etapa 5: O NMR encaminha a mensagem normalizada para o BC conectado ao segundo ambiente JBI.

Etapa 6: O BC conectado ao segundo ambiente JBI desnormaliza a mensagem.

Etapa 7: O BC conectado ao segundo ambiente JBI entrega a mensagem desnormalizada para o segundo ambiente JBI.

Etapa 8: O segundo ambiente JBI recebe o pedido e o encaminha para o BC conectado ao primeiro ambiente JBI. Isso significa que dois ambientes JBI se conectam entre si por meio de BCs adequados.

Etapa 9: O BC conectado ao primeiro ambiente JBI transforma o pedido de invocação de serviço em uma mensagem normalizada.

Etapa 10: O BC conectado ao primeiro ambiente JBI entrega a mensagem normalizada para o NMR.

Etapa 11: O NMR encaminha a mensagem normalizada para o aplicativo do banco de sangue (um SE).

Etapa 12: O SE desnormaliza internamente a mensagem e invoca a lógica de negócios necessária.

Padrões de troca de mensagem na JBI

As discussões que acompanham as Figuras 4, 5, 6 e 7 mostram comunicação unidirecional — envio de uma mensagem de um consumidor de serviço para um provedor de serviços. O prestador de serviços (como o aplicativo do grupo de doadores) não envia mensagem de retorno. A documentação da JBI se refere a esse tipo de mensagem como troca de mensagem in-only (somente de entrada). O padrão de troca de mensagens in-only é adequado para serviços como o aplicativo do grupo de doadores, que precisa apenas de mensagens unidirecionais para o grupo. Nenhuma informação precisa viajar de volta para o aplicativo de prescrição que faz o pedido.

Outros serviços (como o aplicativo do portal do plano de saúde) podem ter de enviar resposta. Esse padrão de mensagem de pedido-resposta também é permitido na JBI e é chamado de in-out (entrada e saída). Como se pode imaginar, a resposta sempre viaja da mesma maneira do prestador de serviços pelo ambiente JBI — BCs, SEs e NMR — até chegar ao consumidor de serviço. Assim, não vou incluir outra sequência de eventos para descrever as mensagens in-out.


Configurando e autoinicializando seu ambiente JBI

A especificação JBI fornece um esquema XML detalhado para definir o comportamento de todos os BCs e SEs que desejamos hospedar na JBI. Agora, descreverei como usar o esquema JBI para configurar uma implementação JBI como HSB.

Não vou tratar do inteiro esquema JBI neste artigo. Vou me concentrar aqui em uma tag JBI importante chamada <component>. A Parte 2 demonstrará o uso de mais tags de esquema JBI.

A tag <component> define um componente JBI. Um componente pode ser um BC ou SE. A listagem 1 mostra a aparência da configuração XML do BC para o aplicativo de prescrição:

Listagem 1. Configuração XML para o BC do aplicativo de prescrição
 <?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>

É possível ver que a listagem 1 contém uma tag <component> com um atributo type e cinco tags filhas chamadas <identification>, <component-class-name>, <component-class-path>, <bootstrap-class-name> e <bootstrap-class-path>.

O atributo type especifica se o componente é um BC ou um SE. A listagem 1 configura o BC do aplicativo de prescrição, de modo que o valor do atributo type deve ser binding-component.

A tag <identificação> na listagem 1 fornece um nome e descrição para o BC.

A tag <component-class-name> especifica a classe Java que implementa a lógica necessária para o BC. A especificação JBI tem uma interface padrão chamada javax.jbi.component.Component, que todos os BCs devem implementar. Vou usar o Apache ServiceMix nesta série para demonstrar o funcionamento de um HSB. O ServiceMix fornece um BC que pode ser usado para trabalhar com consumidores de serviço que consomem serviços da Web baseados em SOAP. A classe que implementa a lógica desse BC é chamada de org.apache.servicemix.cxfbc.CxfBcComponent. Na Parte 2, usarei essa classe para demonstrar como o aplicativo de prescrição funciona com a JBI. É por isso que a listagem 1 inclui org.apache.servicemix.cxfbc.CxfBcComponent como nome da classe de componente incluída na tag <component-class-name>.

Agora observe a tag <component-class-path> na listagem 1. Ela tem duas tags filhas chamadas <path-element>. Essas tags especificam o caminho para todos os arquivos JAR de que a classe de componente precisa a fim de ser executada. Isso quer dizer que as tags <component-class-name> e <component-class-path> formam um par que especifica o nome da classe Java do BC, bem como o caminho da classe completo que é necessário para executar a classe Java.

Encontramos outro par de tags chamado <bootstrap-class-name> e <bootstrap-class-path> na listagem 1. Esse par é similar ao anterior das tags <component-class-name> e <component-class-path>. O par de autoinicialização especifica o nome e o caminho da classe Java que implementa a lógica de autoinicialização do BC.

Autoinicialização significa colocar o BC em serviço. A autoinicialização ocorre quando iniciamos o servidor JBI (ServiceMix). A classe de autoinicialização contém toda a lógica para ativar o BC e colocá-lo em operação.

Agora observe a tag <component> na listagem 2, que representa um prestador de serviços externo, como o aplicativo do grupo de doadores. A listagem 2 tem exatamente a mesma estrutura da listagem 1, de modo que não precisamos de mais explicações.

Listagem 2. Configuração XML de um prestador de serviços externo
 <?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>

A listagem 3 mostra outra tag <component> que ensina como configurar um SE — um prestador de serviços interno (como o aplicativo do departamento de radiologia):

Listagem 3. Configuração XML de um prestador de serviços interno
 <?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>

Se compararmos a listagem 3 com a listagem 2, veremos uma grande diferença: O valor de atributo type na listagem 2 é binding-component (porque é um BC que representa um prestador de serviços externo), enquanto o valor do atributo type mostrado em negrito na listagem 3 é service-engine porque ele é um SE que representa um serviço interno.


Em breve

Vimos como usar tags <component> de JBI para configurar seus BCs e SEs. O JBI também fornece um mecanismo de reutilização para a criação de BCs de uso geral que podem ser usados em vários cenários.

Implementações JBI, como ServiceMix, fornecem BCs pré-projetados que vêm incluídos na implementação. Nem é preciso configurador a tag <component> desses BCs. A implementação já conhecerá as classes e outros detalhes desses BCs.

A Parte 2 juntará as peças e demonstrará como usar a funcionalidade existente do ServiceMix e criar e configurar a nova funcionalidade, — ou seja, implementar e configurar um BC ou SE — para integrar serviços de assistência médica.

Recursos

Aprender

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, Software livre
ArticleID=498985
ArticleTitle=Integrando serviços de assistência médica, Parte 1: Usando barramento de serviço corporativo para assistência médica
publish-date=07022010