Estudo de caso: Mule como um transporte JMS Comum

1. 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

2. 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.

3. 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

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