Weblogic Store and Forward e Distributed Destinations - Parte 1 Definições

Analisando uma arquitetura inicial para uma aplicação distribuída que consistia em um servidor que recebe mensagens, este deveria distribuir as mensagens para um cluster onde haveriam milhares de clientes conectados consumindo as mesmas. O principal requisito desta aplicação que foco neste post é que a procura pelos serviços deveria ser transparente de localização nos servidores, ou seja, o lookup do cliente para encontrar o serviço deveria ser local e transparente para aplicação, sendo que a mensagem original em si estaria em outro servidor.

Após alguma análise cheguamos a um modelo inicial de arquitetura utilizando uma feature de infra do weblogic que é o mecanismo de Store and Forward e também o serviço de JMS Distributed Destinations. A imagem abaixo ilustra um primeiro brainstorm da arquitetura do ambiente desejado.



Nesta arquitetura definimos a utilização de dois serviços de JMS do Weblogic Server bastante interessantes que comento à seguir. 1) Store and Forward: O serviço de Store and Forward (SAF) permite que uma instância de weblogic server entregue mensagens entre aplicações que estão distribuídas entre outras instâncias de servidores de forma transparente para o cliente. Este serviço possibilita que uma aplicação que esteja rodando em qualquer instância do weblogic server em um ambiente distribuído, consuma ou envie mensagens para outros servidores de forma transparente de localização para a aplicação, além de garantir a qualidade de serviço.

2) Distributed Destinations: Este serviço pode ser utilizado em um cluster com o objetivo de tornar transparente para produtores e consumidores JMS um ambiente de tolerância à falhas onde o serviço parece único mas está disponível em todo um cluster de servidores, o Weblogic Server abstrai a complexidade, possibilitando assim grande capacidade de tolerância à falhas no ambiente.

Estes são os conceitos básicos de 2 excelentes serviços suportados pelo weblogic server que tornam as aplicações muito mais estáveis e tolerante a falhas para os clientes, serviços fundamentais para a internet de grandes corporações pois aumentam a disponibilidade da aplicação. Em um próximo post irei efetivamente criar o ambiente mencionado acima e mostrar na prática como o serviço pode ser utilizado.

Para mais informações sobre estes serviços, recomendo a utilização da documentação oficial da Oracle para o Weblogic Server nos links(Weblogic v10.3.2): Store and Forward e Distributed Destinations.

[]s

Weblogic JMS - Parte III - Criação de fila JMS

Neste post mostro a configuração de uma fila JMS(Queue) simples no Oracle Weblogic Server 11g(10.3.2).

Para configurar o ambiente inicial que é pré-requisito para este exemplo veja os posts do link: http://mmaiacupofcoffee.blogspot.com/search?q=Oracle+Fusion+Middleware+11g

Para ver a documentação oficial da Oracle sobre a parte administrativa de JMS no weblogic visite o link:
http://download.oracle.com/docs/cd/E15523_01/web.1111/e13738/toc.htm

No exemplo mostrado no vídeo abaixo são configurados todos os elementos JMS necessários para criação de uma fila simples. Existem outras formas de se configurar uma fila no Oracle Weblogic.

[]s

Weblogic JMS - Parte II - Arquitetura JMS

Neste post, faço um resumo da arquitetura de JMS, que é definido pelo item 2 da especificação JMS 1.1.

O item 2.2 define os possíveis participantes de uma aplicação JMS:
• Cliente JMS - Cliente JMS que utiliza linguagem java.
• Cliente não-JMS - Possíveis clientes JMS de uma aplicação escritos utilizando uma linguagem proprietária do provider. Como exemplo pode-se citar um cliente do IBM MQ escrito utilizando uma API proprietária do produto.
• Mensagens - Estas são as mensagens postadas e consumidas no MOM(Message Oriented Middleware).
• Provider JMS - Este é o MOM em si que pode fornecer serviços adicionais à especificação para seus clientes, como é o caso da maioria dos providers.
• Objetos Administrativos - São objetos pré-configurados no provider para facilitar a vida dos clientes, usualmente os objetos são ConnectionFactory e Destinations, estes objetos são registrados na árvore JNDI do servidor por default ou pelos administradores do MOM utilizado.

O modelo de Administração definido é o que proporciona interoperabilidade das aplicações escritas em JMS, isso porque os objetos ConnectionFactory e Destinations são padronizados e as APIs de acesso a estes recursos, fornecidas usualmente pelos providers, disponibilizam interfaces padrão para sua utilização.
ConnectionFactory - Objeto utilizado por clientes para criar uma conexão com o provider utilizado.
Destination - Objeto que o cliente usa para especificar o destino de envio ou recebimento de mensagens.
Estes objetos devem ser disponibilizados na árvore JNDI(Java Naming and Directory Interface) do servidor(JNDI Namespace), possibilitando acesso padronizado através da API padrão de java. Conforme imagem abaixo tirada da especificação JMS 1.1.

Conforme mencionado anteriormente existem dois tipos de mensagens que podem ser utilizadas conforme a especificação: Point-to-Point ou Publish/Subscriber Messages.

A especificação define então algumas APIs que possibilitam a utilização do tipo de mensagem desejado e ainda um conjunto de interfaces que abstrai essa implementação, conforme o quadro abaixo, retirado da especificação, ilustra.

Segue uma breve definição dos objetos da interface comum:

• ConnectionFactory - Objeto administrativo utilizado pelo cliente para criar uma conexão com o provider.
• Connection - uma conexão estabelecida com o provider.
• Destination - um destino de envio ou recebimento de mensagens.
• Session - um contexto criado com o provider para envio ou recebimento de mensagens.
• MessageProducer - Um objeto criado por uma sessão que efetivamente é utilizado apra envio de mensagens ao destino.
• MessageConsumer - Um objeto criado por uma sessão que é utilizado para consumir mensagens de um destino.

Conforme já foi mencionado, outros serviços não definidos pela especificação podem ser adicionados pelo fornecedor do provider e portanto, os modos de Administração, segurança, timers, dentre outros serviços, podem ser proprietários e definidos através de APIs de cada fornecedor do MOM(provider).

Na questão de acesso concorrente, a tabela mostrada abaixo, retirada da especificação, ilustra bem o modelo utilizado.

A especificação prevê ainda um modelo de Request/Reply para as mensagens poderem definir um estado de conversação. Para isso, é definido no header das mensagens um campo denominado JMSCorrelationID que pode ser utilizado para este fim.

[]s

Weblogic JMS - Parte I - Overview de JMS

Comecei a revisar os conceitos de JMS do weblogic e por isso irei fazer uma série de postagens resumindo estes conceitos. A fonte principal de consulta para estes artigos será a especificação oficial da sun para JMS 1.1 e a documentação oficial de JMS do Oracle Weblogic Server 10.3.

JMS provê uma maneira padronizada para programas java criarem, enviarem, receberem e lerem mensagens de sistemas coorporativos de mensageria como Weblogic JMS Server, IBM MQ Series, Apache Active MQ dentre vários outros. A especificação provê então uma forma para comunicar com qualquer destes ambientes abstraídos de seu fornecedor, bastando, para isso, que o "Message Oriented Middleware" - Middleware orientado a mensagens escolhido implemente a especificação JMS 1.1 que é a abordada neste artigo.

JMS provê um conjunto de interfaces e padrões que definem como um cliente acessa os recursos de um Produto Orientado a Mensagens.

JMS prevê dois tipos básicos de mensagens "point-to-point" e "publish-subscribers". As mensagens point-to-point são mensagens enviadas para uma fila onde apenas um cliente irá publicar e somente um cliente irá receber e processar a mensagem, no modelo publish-subscriber é utilizado um tópico onde vários clientes podem se registrar para publicar e receber as mensagens. Para melhor ilustrar estes modelos basta pensarmos em um ambiente de call center por exemplo que é similar ao modelo point-to-point pois quando um atendente pega a ligação do usuário é feita uma ligação entre dois pontos. Já no modelo publish-subscriber é um modelo parecido com uma lista de discussão ou grupo da internet, onde um ou vários clientes podem postar uma mensagem que será recebida por todos os clientes que estiverem associados aquela lista. Posteriormente entrarei em mais detalhes e exemplos dos dois modelos.

O item 1.2.4 da especificação JMS 1.1 detalha um item bastante importante, listando os itens que não são definidos na especificação e que, portanto, cada fornecedor de produtos de mensageria implementam de forma proprietária ou em muitos casos nem fornece o serviço. Este itens incluem: Serviços de balanceamento de carga e tolerância à falhas, Notificação ou aviso de erros e problemas, Administração, Monitoramento, Segurança e Protocolo de comunicação. O Weblogic Server 10 possui todos estes serviços que podem ser considerados adicionais à especificação, mas que são fundamentais em um produto com qualide de serviços aceitáveis para grandes corporações.

O item 1.4 da especificação define que algumas APIs tem que ser compatíveis e possível de serem utilizadas em uma implementação JMS, e portanto todos os produtos que forem compatíveis com a especificação devem suportar os padrões: JDBC, componentes JavaBeans, EJB, JTA, JTS, JNDI e Java EE.

Neste primeiro artigo fiz um resumo do item 1 da especificação JMS 1.1 destacando seus principais pontos. No próximo irei tratar do modelo de arquitetura do JMS 1.1 que é definido no item 2 da especificação.

[]s