Estudo de caso: Mule como um transporte JMS Comum

A equipe de integração aplicações tiveram que lidar com seis fornecedores

diferentes. JMS e SOAP emergiu como os transportes comuns para todas

as aplicações; 90% das comunicações poderia ter lugar ao longo JMS.

A configuração normal JMS exigiria que cada aplicativo para criar filas de

entrada e saída para cada aplicativo que ele precisa interagir. Esta

configuração "ponto-a-ponto" explodiria complexidade porque mais

aplicativos de fornecedores viria a ser adicionado à mistura, e cada

aplicativo teria que ser revisto para adicionar novas definições de

interface cada vez. A equipe de integração decidiu em vez de aproveitar os

recursos da mula para simplificar isso criando uma fila única, comum onde

todas as mensagens são enviadas. Cada mensagem tem um atributo que

indica seu tipo e encaminha para a aplicação adequada. O aplicativo capta

a mensagem na sua fila de entrada privada, processá-lo e responde

colocando uma resposta na fila comum. rotas mula a resposta para os

aplicativos apropriados.

Listagem 1 é um arquivo de configuração Mule para lidar com as

interações entre os componentes de aplicativos se comunicam através de

JMS. As regiões coloridas corresponder cada um dos próximos parágrafos.

As peças em cinza da lista são redundâncias ou exigir nenhuma explicação.

Baixar arquivo de configuração Mule

O primeiro passo consiste em definir o nome e tipo de conector. Qualquer

provedor JMS, open-source ou comercial, pode ser definida aqui,

enquanto Mule pode alcançar o servidor através da rede. As propriedades

adicionais, tais como credenciais ou nomes deve ser definido aqui

também. Mule vai usar esse conector para todo o tráfego JMS. Mais do

que uma peça de ligação do mesmo tipo podem ser definidos, se

necessário. Os conectores são identificados pelo nome; estes nomes são

usados Mule para determinar qual deles lida com uma determinada

interação. Conectores para outros transportes seria definida de um modo

semelhante.

Em seguida, defina os parâmetros globais. Estes terminais são as

interfaces entre cada aplicação e Mule. Um componente objeto de serviço

de vias de comunicação entre terminais; os parâmetros podem ser

definidos no nível do componente objeto de serviço ou podem ser

definidos globalmente. Parece mais fácil defini-las globalmente para que o

modelo e roteador configuração Mule é menos detalhada. Use a

abordagem que funciona melhor para sua aplicação.

Mule é bastante silencioso por design. Ele apenas se senta lá e aguarda o

tráfego para passar, obedientemente escrever mensagens de status para

seus logs. Algumas vezes é conveniente definir filas de saída do console

para fins de depuração já que nem todos podem ter acesso a um console

JMX. Consolas exibir ASCII ou UTF-8 saída, mas o tráfego enviado através

desta configuração mula é toda a JMS. Assim, dois transformadores são

definidos. Uma converte mensagens JMS para objetos de mula, o outro

converte esses objetos para cordas; o console pode exibir as seqüências

de diagnóstico sem problemas. Essas mensagens também podem ser

encaminhados via e-mail para cada fornecedor utilizando os transportes

Java Mail da mula sem ter que extrair o texto a partir dos registros, etc.

O modelo Mule gerencia o comportamento de tempo de execução de uma

instância de servidor e encapsula todas as suas funcionalidades. O modelo

é responsável por manter a configuração e instâncias do objeto de serviço.

O modelo para este exemplo tem um descritor, o

JMSMessageSwitchboard, que irá encaminhar todas as mensagens entre

diferentes aplicações através de seus terminais. Este contém todos os

roteadores, regras de filtragem, e definições de ponto final para garantir

que as mensagens viajam dentro das aplicações com precisão.

Uma vez que os integradores decidiu que todas as mensagens são

introduzidos através de um único ponto de entrega, eles definiram um

único roteador de entrada que escuta em um conector JMS específico.

Enquanto cada aplicação define suas saídas de mensagem para o terminal

outJMSBitco, Mule será capaz de encaminhá-los para o destino adequado.

definições de roteamento de saída requer duas partes: primeiro, definir

uma regra que corresponde a todas as mensagens JMS e os envia para

filtros específicos para definição roteador de cada aplicação; isso é o que o

todo o jogo = "true" é para. Em seguida, cada ponto de extremidade

correspondente a uma determinada aplicação contém um filtro que

corresponde a um atributo específico definido no cabeçalho da mensagem

JMS, como OrderHistoryRequest. Note-se que, neste caso, as

comunicações são assíncronas. Aplicações colocar pedidos na fila comum

e passar para outras tarefas. As respostas vão voltar em suas filas

específicas do aplicativo. Cada resposta também terá um cabeçalho da

mensagem JMS identificação; analisar a validade do cabeçalho e a carga

de dados são de responsabilidade de cada aplicação.

Cada mensagem que circula através do JMSMessageSwitchboard deve

corresponder a uma regra filtrada. Se isso não acontecer, isso significa que

um integrador esqueceu de atualizar o arquivo de configuração Mule, um

novo serviço já está on-line e usando a fila de entrada, ou há um erro de

ortografia. Um modo rápido de detectar este é o roteador catchall saída

definida para o fim das etiquetas descritor mula. Se nenhuma das regras

corresponde, Mule irá encaminhar a mensagem para stdout depois de

converter para uma string (lembre-se esses transformadores que

definimos anteriormente?).

Adicionando um novo aplicativo para este mashup torna-se um exercício

trivial: garantir que ele usa JMS para comunicações de entrada e de saída,

definir seu atributo de encaminhamento, e atualizar o arquivo de

configuração do Mule. Se o novo aplicativo se comunica através de um

protocolo diferente, como SOAP, definir o conector, terminais e um

transformador para converter JMS-to-SOAP e volta. O processo de

integração todo vai demorar cinco minutos, no máximo. Esse é o poder da

mula.