ESTUDO DAS TECNOLOGIAS UTILIZANDO TROCA DE MENSAGEM E ARMAZENAMENTO EM FILA JMS COM CONSUMIDOR MDB MESSAGE-DRIVEN-BEAN

Transcrição

1 UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ DEPARTAMENTO ACADÊMICO DE INFORMÁTICA CURSO DE ESPECIALIZAÇÃO EM TECNOLOGIA JAVA EDSON VIEIRA ESTUDO DAS TECNOLOGIAS UTILIZANDO TROCA DE MENSAGEM E ARMAZENAMENTO EM FILA JMS COM CONSUMIDOR MDB MESSAGE-DRIVEN-BEAN MONOGRAFIA DE ESPECIALIZAÇÃO CURITIBA 2012

2 EDSON VIEIRA ESTUDO DAS TECNOLOGIAS UTILIZANDO TROCA DE MENSAGEM E ARMAZENAMENTO EM FILA JMS COM CONSUMIDOR MDB MESSAGE-DRIVEN-BEAN Monografia apresentada ao Departamento Acadêmico de Informática, Curso de Especialização em Tecnologia Java da Universidade Tecnológica Federal do Paraná UTFPR, como requisito parcial para obtenção do título de Especialista em Tecnologia Java. Orientador: Prof. Esp. Paulo Bueno CURITIBA 2012

3 RESUMO Com surgimento de novas empresas e crescimento das tecnologias no mercado, cresceu a necessidade da integração de sistemas em diferentes plataformas, tornando-se a integração um fator indispensável que vem ocorrendo constantemente, existe uma grande gama de sistemas, em cada empresa atualmente, cada um atendendo a uma determinada área, porém, esses sistemas trabalham com características, velocidades de processamento e linguagens de programação diferentes, influenciando diretamente na dificuldade da comunicação entre sistemas, uma alternativa que Possibilita a comunicação entre sistemas tecnologicamente diferentes são as filas JMS (Java Message System) para troca de mensagens. Desta forma, o presente trabalho apresenta o estudo das tecnologias que permitam a troca de mensagens em um ambiente confiável e assíncrono com o consumidor MDB Message-Driven-Bean. Palavras-chave: Java Message Service, Troca de Mensagens, Mensage-Driven-Bean, Web Service, Weblogic 11g.

4 ABSTRACT With the emergence of new companies and technologies in the market growth, increased the need for systems integration across platforms, making it an indispensable factor integration that is occurring constantly, there is a wide range of systems, each company currently each covering a certain area, however, these systems work characteristics, processing speeds and different programming languages, directly influencing the difficulty of communication between systems, an alternative that enables communication between different systems are technologically queues JMS (Java Message System ) for messaging. Thus, this paper presents the study of technologies that allow the exchange of messages in a reliable environment with the consumer and asynchronous MDB Message- Driven-Bean. Keywords: Java Message Service, Messaging, Mensage-Driven-Bean, Web Service, Weblogic 11g.

5 LISTA DE FIGURAS Figura 1 Documento XML Figura 2 Documento XSD Figura 3 Passos processo Binding JAXB Figura 4 Leitura Arquivo JAXB Figura 5 Parser arquivo JAXB Figura 6 Processo API Java Persistence API Figura 7 Exemplo de utilização de fila de mensagem Figura 8 Envio de mensagem de um sistema Java para um sistema legado Figura 9 Troca de Mensagem utilizando o modelo PTP Figura 10 Troca de Mensagem utilizando o modelo PUB/SUB Figura 11 Modelo de arquitetura da API JMS Figura 12 Console Administrativo Weblogic 11g Figura 13 Exemplo Criando Acesso a Fila Figura 14 Exemplo Enviando Mensagem para fila JMS Figura 15 Exemplo Recebimento de Mensagem de uma fila JMS Figura 16 Tela Estrutura de Domínio Figura 17 Exemplo Projeto XSD Figura 18 Exemplo Documento XSD Figura 19 Exemplo Gerar JAXB através Documento XSD Figura 20 Exemplo Schema criado através Documento XSD Figura 21 Exemplo Script Criação Fila JMS Figura 22 Exemplo SQL Developer Criar fila JMS Figura 23 Exemplo MDB Message-Drive-Bean Figura 24 Tela Estrutura Domínio Figura 25 Tela Servidor JMS Figura 26 Configurando Servidor Figura 27 Tela Filtro JMS Figura 28 Tela Módulo JMS Figura 29 Tela Configurando Servidor Módulo JMS Figura 30 Filtro Módulo JMS Figura 31 Tela Configura Tipo Fila JMS Figura 32 Tela Configuração Recurso Módulo JMS Figura 33 Tela Filtro Recurso JMS Figura 34 Tela Configuração de Armazenamento e Envio Figura 35 Tela Configuração Agente de Armazenamento Figura 36 Tela Filtro Agente de Armazenamento... 37

6 LISTA DE ABREVIATURAS E SIGLAS API Application Programming Interface (Interface de Programação de Aplicativos) EJB Enterprise JavaBeans HTTP HyperText Transfer Protocol HTTPS HyperText Transfer Protocol Secure JAXB Java Architecture For XML Binding JPA Java Persistence API JTA Java Transaction API J2EE Java Platform Enterprise Edition JVM Java Virtual Machine JMS Java Message Service POJO Plain Old Java Object PTP Ponto a Ponto PUB/SUB Publicação / Assinatura SOAP Single Object Access Protocol MDB Message-Drive-Bean MOM Message Oriented Middleware IDE Integrated Development Environment (Ambiente Integrado para Desenvolvimento) XSD XML Schema Definition XML extensible Markup Language (Linguagem Extensível de Marcação)

7 SUMÁRIO 1. INTRODUÇÃO TEMA JUSTIFICATIVA OBJETIVO GERAL OBJETIVOS ESPECÍFICOS PROPOSTA DA PESQUISA JAVA WEB SERVICE XML: DEFINIÇÃO DOS DADOS JAXB (JAVA ARCHITECTURE FOR XML BINDING) JPA (JAVA PERSISTENCE API) JMS (JAVA MESSAGE SERVICE) MIDDLEWARE MOM MESSAGE ORIENTED MIDDLEWARE CLIENTE E PROVEDOR JMS TROCA DE MENSAGENS PERSISTÊNCIA DE MENSAGENS TRANSAÇÃO CONHECENDO API JMS TIPOS DE MENSAGENS MDB MESSAGE-DRIVEN-BEAN SERVLETS & JAVA SERVER PAGES (JSP) SERVLETS JAVA SERVER PAGES (JSP) ABORDAGEM PRÁTICA ENVIO DE MENSAGEM PARA FILA JMS RECEBIMENTO DE MENSAGEM DE UMA FILA JMS ARQUITETURA DO PROTÓTIPO CONFIGURAÇÃO FILA JMS WEBLOGIC 11G SERVER CONCLUSÃO TRABALHOS FUTUROS REFERÊNCIAS BIBLIOGRÁFICAS... 40

8 7 1. INTRODUÇÃO 1.1 TEMA Este trabalho apresenta um estudo sobre troca de mensagens e armazenamento em fila JMS, com consumidor MDB e WebService articulados a componentes nativos do WebLogic 11g, permitindo que os componentes do aplicativo baseado em J2EE possam criar enviar, receber e ler mensagens, onde há necessidade de atender a requisitos de performance, permitindo uma comunicação flexível, confiável e assíncrona. 1.2 JUSTIFICATIVA Atualmente as empresas estão cada vez mais investindo em novas tecnologias, pois a concorrências impõem que sejam informatizadas e inovadoras com maior capacitação na sua agilidade de resposta a mudança. Além de mais eficiente e ágil, as empresas de maior conteúdo tecnológico, permitem margens de rentabilidade mais elevadas, mas em contrapartida crescem as exigências em investimentos associadas às inovações tecnológicas no mercado. O estudo visa mostrar o interesse em novas tecnologias e o uso da fila JMS, para uma facilidade na sincronização e confiabilidade das informações ao serem consumidas pelo MDB Message-Driven-Bean. 1.3 OBJETIVO GERAL Estudar as tecnologias, fazendo o uso dos conceitos técnicos de troca de mensagens e a utilização da fila JMS entre processos assincronamente com consumidor MDB e WebService a componentes nativos do WebLogic 11g.

9 8 1.4 OBJETIVOS ESPECÍFICOS - Estudo das tecnologias disponíveis e como estão sendo utilizadas para a troca de mensagens. - Explorar ferramentas disponíveis e como estão sendo utilizadas durante o desenvolvimento. - Trabalhar com a plataforma de desenvolvimento Weblogic 11g, com a utilização da IDE Eclipse. - Estudar os objetos da especificação JMS.

10 9 2. PROPOSTA DA PESQUISA Após uma análise nas tecnologias de mercado disponíveis, optou-se pelas tecnologias abaixo indicadas, considerando fatores com custo, segurança, conhecimento prévio, aplicabilidade comercial, estabilidade no mercado, dentre outras. 2.1 JAVA Segundo Serson (2007), Java é uma linguagem de programação versátil e segura, desenvolvida para ser multiplataforma, pois executa em uma máquina virtual que interpreta o código compilado e permite que qualquer programa seja executado em qualquer sistema operacional que contenha uma máquina virtual instalada. Hoje se podem encontrar tecnologias Java em celulares, eletrônicos (INDRUSKIAK, 1996). No ano de 1995, a empresa Sun Microsystems que já se destacava no mercado desde a década de 80 pela fabricação de computadores e condutores que lança sua plataforma de desenvolvimento de software a partir de tecnologias utilizadas na internet e em rede corporativas (SILVA, 2006). 2.2 WEB SERVICE Com o crescimento de novas funcionalidades e tecnologias e serviços disponibilizados na internet surgiram as necessidades de aplicativos que permitem uma ampla integração entre plataforma de software e serviço e uma padronização de protocolos para troca de informação (NETO e LINS, 2006). Portanto, hoje é possível realizar troca de informações em redes através de aplicações distribuídas e tarefas complexas, com um gerenciamento de transações de serviços distribuídos utilizando-se interfaces de acesso simples e bem definidas. Para agilizar uma comunicação entre as aplicações existente no mercado, utiliza-se das tecnologias Web Service e XML, onde quaisquer que sejam as tecnologias envolvidas a comunicação poderá ser feita em forma XML (CUNHA, 2002). A tecnologia Web Service são serviços distribuídos e utilizados na integração entre diferentes plataformas, permitindo que novas aplicações possam se comunicar com aquelas já

11 10 existentes, realizando-se uma comunicação de forma direta com outras aplicações fazendo o uso da Internet (RECKZIEGEL, 2006). CARACTERÍSTICA WEB SERVICE Alto desempenho onde as aplicações podem distribuir carga de processamento em diversos servidores. Baixo custo com alto grau de reutilização de componentes, permitindo o acesso através de redes e reduções nos custos de desenvolvimento. Comunicação entre os sistemas e a utilização de diferentes tecnologias envolvidas. 2.3 XML: DEFINIÇÃO DOS DADOS A linguagem XML significa extensible Markup Language, ou seja, linguagem extensível de marcação em formato de texto, tornando-se uma linguagem padrão para troca de dados entre aplicações através da Web, o uso da tecnologia XML é semelhante ao HTML proporcionando uma flexibilidade na qual usuário pode definir suas próprias tags (ENDREI, 2004). As definições de tags devem ser parametrizadas nas normas das especificações da W3C, que obriga o fechamento de todas as tags no corpo documento, documentos XML trafegam pela rede através dos protocolos HTTP (ou HTTPS para uma conexão mais segura). Um arquivo XML é valido por um documento DTD (Document Type Definition), ou seja, XSD (XML Schema Definition) responsável em determinar a estrutura do arquivo XML correspondente, assim como as tags que podem ser utilizadas, a validação visa certificar que o documento XML mantém as estrutura definida pelo DTD (ou XSD) e possui apenas tags válidas (SINGH ET al., 2004). O objetivo da tecnologia XML é suprir a carência do HTML, permitindo que os desenvolvedores criem e manipulem suas próprias estruturas para armazenar a informação, sendo seus formatos baseado em texto, tornando mais fácil manuseá-los conforme mostram as Figuras 1e 2.

12 11 Figura 1 Documento XML Figura 2 Documento XSD Abaixo estão descritas algumas destas vantagens na utilização da tecnologia XML, no que diz a respeito à apresentação e manipulação das informações (MINK CARLO, 2000). Facilidade para alterar a visualização dos documentos escritos em XML de forma rápida e automática por serem documentos estruturados. Possibilidade de reaproveitar documentos escritos: um dos principais problemas atualmente é reaproveitar um mesmo material em diversas aplicações. Com a XML é possível reaproveitar a informação de forma lógica e prática. Facilidade na identificação das informações: esta vantagem é bem nítida, pois a linguagem permite a criação das tags pelo próprio autor, o que resulta em facilidade para identificar as informações.

13 JAXB (JAVA ARCHITECTURE FOR XML BINDING) JAXB (Java Architecture for XML Binding) é uma API responsável por proporcionar uma maneira de realizar o binding entre os esquemas XML com suas representações em Java, com objetivo de tornar uma agilidade e facilidade para os desenvolvedores Java incorporarem os dados XML e funções em aplicações Java. A API JAXB fornece métodos de marshalling que transforma classes e métodos Java para conteúdo XML e unmarshalling de documentos XML para conteúdo em Java (The Java Web Services Tutorial, 2006). SCHEMA Bind JAXB Follows Unmarshal (validate) Instance of DOCUMENT OBJECTS marshal (validate) Figura 3 Passos processo Binding JAXB Fonte: The Java Web Service Tutorial (2006). Portanto JAXB facilita o uso do XML compilando um esquema XML em uma ou mais classes Java, ou seja, elimina a necessidade de codificar classes para manipular XML, onde permite que os desenvolvedores Java realizem o mapeamento entre XML e código Java de forma eficiente e padronizada. Utilizando API JAXB o desenvolvedor não necessita conhecer a fundo todos os conceitos do padrão XML para poder desenvolver aplicações baseadas em XML. Destacam-se APIs como: JAXP (Java API for XML Processing), para leitura, criação, manipulação e transformação de XML, e JAXB (Java API for XML Binding), que mapeia classes Java a documentos XML.

14 13 CARACTERÍSTICA JAXB Leitura arquivo XML: Define a responsabilidade para transportar objeto em XML e vice-versa. API do JAXB é quem será responsabilizada por essas transformações. Transformando Objetos XML: responsável em transportar um objeto XML chamado Marshal, com isso JAXB transforma um objeto em XML fazendo o uso de um JAXBContext onde fornecerá o Marshaller que vai transformar um objeto (JAXBElement) em XML. Figura 4 Leitura Arquivo JAXB Parse XML: tem a função de realizar o caminho contrário, ou seja, popular um objeto Java com dados de um XML com a necessidade de um JAXBContext comunicando com Unmarshaller recebendo um arquivo XML e devolve um JAXBElement contendo um objeto manipulado e preenchido. Figura 5 Parser arquivo JAXB O JAXB caracteriza um desempenho eficiente para os programadores Java, para realizar o consumo e criação do XML. API também fornece outros recursos como, validação, geração de schema(a partir de classes Java, criar um XSD), com a opção de trabalhar com Namespace. 2.5 JPA (JAVA PERSISTENCE API) O JPA é uma API que permite criar uma arquitetura de objetos distribuídos na internet, com intuito de oferecer uma infraestrutura para o desenvolvimento de aplicações

15 14 distribuídas. A tecnologia EJB disponibiliza para o desenvolvedor os serviços mais aptos aos ambientes distribuídos como: gerenciamento de transações para tratamento de acessos simultâneos de usuários diferentes em um mesmo registro de uma tabela. Segurança no controle de acesso de usuários sobre os dados. As especificações de EJB faz com que o desenvolvedor defina as regras de negócios, otimizando e facilitando o desenvolvimento de aplicações distribuídas. Persistência está acoplada na especificação de EJB com vantagens da orientação a objetos, enquanto persistem os dados de forma automática, implicitamente. A Figura 6 ilustra o mapeamento objeto-relacional da API JPA, especificando as entidades POJO (Plain Old Java Objects), que simplificam bastante o processo de desenvolvimento (SANTANA et al, 2007). CAMADA DE APRESENTAÇÃO CAMADA DE NEGÓCIO UTILIDADE DE CLASSE CAMADA DE PERSISTÊNCIA BANCO DE DADOS Figura 6 Processo API Java Persistence API Fonte: Santana (2007). 2.6 JMS (JAVA MESSAGE SERVICE) No ano 1998 a Suns Microsystems em conjunto com alguns associados tiveram a ideia de desenvolver uma API JMS na utilizacão em aplicativos Java para definir funções

16 15 como: criar, enviar, receber e ler mensagens, bem como se comunicar com outras implementações de envio de mensagens. (WAENEY e NUMAZAKI, 2004). A tecnologia JMS oferece uma comunição fracamente acoplada, onde o remetente e o destinatário necessariamente não precisam conhecer nenhuma informação um do outro. Na arquitetura J2EE, o JMS é considerado um recurso de gerenciador de contêiner, onde clientes de aplicativos EJB e componentes da Web, fazem o uso da API JMS para gerenciar no envio e receber mensagens (BOND et al., 2003) 2.7 MIDDLEWARE Segundo Juric (2001), Middleware tem como definição, camada de software que realiza a mediação entre um sistema operacional e uma aplicação local do sistema, podendo um software ser usado para mover informação de um programa para um ou mais programas em um ambiente distribuído. Atualmente os sistemas legados possuem interfaces específicas, e o custo de mudança de interface para realizar uma comunicação entre sistemas torna-se um fator negativo, assim sendo, o uso de um objeto Middleware, pode-se resolver a integração de sistemas legado para novos sistemas com diferentes interfaces. A JMS pode ser considerada um middleware conforme visto no tópico 2.6, porém ela é orientada a mensagens, assim como veremos no próximo tópico. 2.8 MOM MESSAGE ORIENTED MIDDLEWARE O Message Oriented Middleware é uma implementação do middleware com objetivo de solucionar problemas de troca de mensagens, o que é fundamental na computação distribuída, e permite uma troca de mensagens utilizando fila, alocando mensagens em filas e obtendo mensagens da fila. O MOM permite que os produtores e consumidores se comuniquem por uma rede sem a necessidade de estarem conectados no mesmo instante. Portanto desta forma se um dos sistemas estiver ocupado, tera a opção de recuperar a mensagem mais tarde, sem restrições de tempo (ORFALI et al, 1996). A Figura 7 ilustra um exemplo de utilização de mensagens.

17 16 Varias horas Figura 7 Exemplo de utilização de fila de mensagem Fonte: Waeney e Numazaki (2004). As filas utilizadas são criadas na memória virtual do sistema operacional, cada uma com seu nome próprio, podendo existir várias filas sendo utilizadas no mesmo instante. Segundo Orfali et al, (1996), as mensagens seguem a seguinte ordem de envio e recebimento utilizando fila. A primeira mensagem ao entrar na fila será a primeira a sair, e a última a entrar será a última a sair, podendo uma fila de mensagens ser acessada simultaneamente. Pode-se definir filas de mensagens persistentes e não persistentes, onde as persistentes são consideradas mais lentas, porém podem ser recuperadas em caso de queda de energia ou após a reinicialização do sistema. O MOM deve ser usado também, quando um componente não depende da interface do outro (JURIC, 2001). Segundo Barbieri (2001), cita algumas características do MOM são: Garantia de Entrega: as mensagens enviadas têm a entrega garantida, independente se houver ou não distúrbios na rede. Garantia de Integridade: as mensagens são tratadas de forma que somente uma vez serão enviadas, garantindo fundamentos essenciais em transações eletrônicas, como por exemplo: enviar um pedido de compra duas vezes, ou até mesmo, que dois pagamentos sejam enviados pelo mesmo evento. Disparo de triggers: com a chegada de uma nova mensagem na fila, poderá se disparar uma trigger que realizará certo processamento, isso vale para qualquer acontecimento no sistema MOM, tanto na alocação de mensagens, no envio, no recebimento, ou na sua leitura. Tipos de leitura de mensagem: um sistema MOM disponibilizará mecanismo de integração entre os programas e os gerenciadores de fila, garantindo a chegada da mensagem na fila.

18 17 O mecanismo Síncrono: o programa receptor aguarda a chegada da mensagem. Mecanismo de Loop Contínuo: o programa receptor executa um loop contínuo, perguntando a todo tempo: Tem mensagem pra mim?. Mecanismo Assíncrono: o programa receptor registra um pedido no sistema, de modo que quando chegar uma mensagem ele será avisado. 2.9 CLIENTE E PROVEDOR JMS Os aplicativos Java que utilizam a API JMS são chamados de clientes JMS, e os sistemas responsáveis pelo gerenciamento de envio de mensagens são chamados de provedores JMS. Portanto O objetivo dos clientes JMS é alterar ou obter dados de uma máquina destino. Um cliente que tem a responsabilidade de enviar mensagens é chamado de produtor, e os clientes que recebem mensagens são chamados de consumidor, sendo que um cliente pode assumir os dois papéis tanto produtores quanto consumidor. Assim sendo um aplicativo JMS pode conter muitos clientes JMS ou muitos provedores JMS (KURNIAWAN, 2000). A utilização de um provedor é que o sistema JMS pode ser integrado a um ambiente heterogêneo, ou seja, sistemas legados podem fazer parte de um componente Java e utilizar a sua linguagem nativa para atualização da base de dados. A Figura 8 ilustra o exemplo de um sistema Java trocando mensagens com um sistema legado, onde um provedor de mensagens JMS se comunica com o provedor de mensagens assíncronas da IBM (WAENEY e NUMAZAKI, 2004). Envia Mensagem Fila de Pergunta Há Mensagem? Envia Respostas Sistema Java JMS Fila de Respostas MQ Series Sistema Legado Figura 8 Envio de mensagem de um sistema Java para um sistema legado Fonte: Waeney e Numazaki (2004).

19 18 Vantagens da utilização de provedores JMS. Facilita a integração com sistemas incompatíveis. Uma comunicação de um para muitos Realizar uma Troca de Mensagens Transacional 2.10 TROCA DE MENSAGENS Segundo Temple (2004) a troca de mensagens é um serviço que tem objetivo de realizar uma comunicação entre aplicativos ou componentes de software. No serviço de troca de mensagens que a JMS implementa é possível o remetente enviar uma mensagem para um destino sem precisar saber quem a consumirá, após o envio da mensagem o consumidor receberá uma notificação avisando que chegou uma nova mensagem para ser consumida, ele tem a responsabilidade de recuperar a mensagem a qualquer momento após o envio da mensagem e retornará uma confirmação para o remetente avisando que a mensagem foi consumida com sucesso. Kurniawan (2000) define que mensagem JMS são objetos serializáveis, onde através de um conjunto de provedores JMS trocam informações ou executam procedimentos em dois ou mais clientes JMS. Provedores JMS são sistemas que gerenciam o envio de troca de mensagens e os clientes JMS são os aplicativos que usam JMS. Um cliente que envia mensagem é chamado de produtor, e um cliente que recebe mensagens é chamado de consumidor sendo que um cliente pode assumir vários papéis. A JMS é responsável em implementar dois modelos de envio de troca de mensagens, que serão apresentados a seguir. TROCA DE MENSAGEM UTILIZANDO PONTO-A-PONTO (PTP) Remetente e o destinatário seguem um destino da mensagem conhecida como fila. O remetente tem responsabilidade de enviar mensagem para a fila e o destinatário a consome a qualquer momento após o envio, permanecendo na fila até ser removida pelo consumidor (HAASE, 2002). Neste modelo haverá somente um consumidor de mensagens, assim como na Figura 9:

20 19 Fila Consome Cliente 1 Cliente 2 Envia Confirma Mensagens Figura 9 Troca de Mensagem utilizando o modelo PTP Fonte: Waeney e Numazaki (2004) TROCA DE MENSAGEM UTILIZANDO PUBLICAÇÃO/ASSINATURA (PUB/SUB) Troca de mensagens utilizando publicação pode ser chamada de publicador, que por sua vez passa ter a função de enviar uma mensagem para um tópico, conhecido como fila do tipo PTP, podendo existir vários destinatário, chamados de assinantes. As Mensagens são distribuídas para todos os assinantes correntes e são excluídas quando todos já tiverem consumidos, como na Figura 10 (HAEFEL e CHAPPELL, 2001). Tópico Consome Cliente 2 Cliente 1 Publica Confirma Consome Cliente 3 Confirma Figura 10 Troca de Mensagem utilizando o modelo PUB/SUB Fonte: Waeney e Numazaki (2004) 2.11 PERSISTÊNCIA DE MENSAGENS As mensagens JMS por padrão são persistentes, com isso garante que a mensagem seja distribuída mesmo que o provedor JMS falhe, ou seja, desligado. Um segundo modo são as mensagens não persistentes, que podem ser usadas onde não há exigência de garantia de entrega. Estas mensagens possuem menor sobrecarga, pois não precisam acessar a base de dados (BOND et al., 2003). Será apresentado durante o tópico 2.13 Conhecendo a API JMS, e como enviar mensagens persistentes.

21 TRANSAÇÃO A API JMS garante que uma mensagem seja entregue com segurança, pois quando o destinatário recebê-la ele enviará uma confirmação, porém esta confirmação nem sempre é suficiente para garantir a integridade de um aplicativo. Em uma aplicação empresarial normalmente é necessário agrupar uma série de operações em uma única transação, se acontecerem de uma das operações falharem, a transação pode ser cancelada, e todas as operações devem ser desfeitas e reiniciadas novamente, caso todas as operações ocorrerem com sucesso, a transação pode ser confirmada. Um cliente JMS tem a permissão de agrupar um conjunto de mensagens para que sejam enviadas, caso alguma mensagem não seja entregue, esta transação será cancelada e todas as mensagens descartadas, caso contrário à transação poderá ser confirmada (HAASE, 2002). Considere o seguinte exemplo: Em uma transação bancária são enviadas duas mensagens para debitar um valor de uma conta e creditar o mesmo valor em outra conta. Se apenas uma das mensagens for entregue haverá um problema. Na JMS, pode ser especificado que uma seção suporta transação na criação da fila, e assim como em banco de dados, existe o método commit para confirmar uma transação e rollback para descartar a transação (BOND et al, 2003). No tópico 2.13 Conhecendo a API JMS, será apresentado como enviar mensagens transientes CONHECENDO API JMS Na utilização da API JMS é necessária conhecer a arquitetura da API, e qual o fluxo de acesso entre os objetos e como se utilizam os componentes para enviar e receber mensagens. Conforme Kurniawan (2000), nos próximos tópicos serão apresentados os principais objetos que fazem parte das especificações JMS no pacote javax.jms. Para facilitar o entendimento dos objetos dentro da arquitetura JMS, é apresentado na Figura 11 um exemplo de como os componentes interagem.

22 21 Gerador de Mensagem JMS JNDI Connection Factory Pesquisa fila de Conexão (Destination) Cria Conexão (Connection) Cria Sessão (Session) Pesquisa Fila/Tópico (Destination) Cria Remetente/Publicador (MessageProducer) Cria Mensagem (TextMessage) Cria Sessão (Session) Mais nenhuma Mensagem Fim Mais Mensagem Figura 11 Modelo de arquitetura da API JMS Fonte: baseado em Bond et al. (2003). Os exemplos apresentados a partir daqui, foram utilizados com base em (KURNIAWAN, 2000). CONNECTION FACTORY (FÁBRICA DE CONEXÃO) Connection Factory tem como objetivo de criar uma conexão entre o cliente JMS e o provedor JMS com objetivo de ser uma fábrica de conexões e encapsular as configurações da conexão. A fábrica de conexão do provedor de mensagens JBossMQ é o ConnectionFactory,

23 22 que é implementado sobre o protocolo de comunicação bilateral baseado em soquetes (HAEFEL e CHAPPELL, 2001). DESTINATION (DESTINO) Destination encapsula um endereço específico de provedor, ou seja, é um objeto usado por clientes para especificar o destino para o qual a mensagem deve ser enviada ou de onde receberá a mensagem. No domínio PUB/SUB o destino é chamado de tópico, e no domínio, e no destino PTP o destino onde é considerado é uma fila, para isso são disponibilizadas duas interfaces diretas: Topic (Tópico) e Queue (Fila), ou seja, com um ConnectionFactory obtém-se um objeto destination, Topic ou Queue (HAASE, 2002). Assim quando se estiver conectado com uma fila ou um tópico é necessário criar uma conexão com um provedor JMS, que será apresentado na sequência. CONNECTION (CONEXÃO) Connection representa uma conexão ativa do cliente JMS, onde aloca recursos do provedor fora da máquina virtual Java (WAENEY e NUMAZAKI, 2004). Para estar com um provedor JMS é preciso criar uma sessão que poderão ser feitas algumas configurações como se vê a seguir. SESSION (SESSÃO) Session JMS é um contexto de threads simples que serve para clientes produzirem e consumirem mensagens (WAENEY e NUMAZAKI, 2004). Segundo Giotta (2000) a sessão utiliza de diversos propósitos, entre elas: prover um método alternativo para criar destinos; criar destinos temporários; como fábrica de criação de diferentes tipos de implementação de provedores automatizados de mensagens JMS; criação de produtores e consumidores de mensagens;

24 23 recebimento de mensagens associada a consumidores de mensagens assincronamente. Allen e Bambara (2003), definem os métodos createtopicsession e createqueuesession: transacted: indica que a sessão suporta transação; acknowledgemode: parâmetro que indica se os consumidores reconheceram as mensagens quando receberem. Os valores podem ser um dos três campos da interface Session; AUTO_ACKNOWLEDGE: automaticamente a sessão acusa o recebimento do cliente de uma mensagem. CLIENT_ACKNOWLEDGE: o cliente acusa o recebimento de uma mensagem consumida chamando o método acknowledge da mensagem. DUPS_OK_ACKNOWLEDGE: neste modo a sessão acusará o recebimento a cada dez mensagens recebidas. mensagens: Um Session tem como responsabilidade administrar os consumidores e produtores de MESSAGEPRODUCER (PRODUTOR DE MENSAGENS) MessageProducer é usado por um cliente JMS para enviar mensagens a um destino (Destination), quando o produtor de mensagens é criado é necessário passar o destino do envio da mensagem por parâmetro no método de criação (WAENEY e NUMAZAKI, 2004). MESSAGECONSUMER (CONSUMIDOR DE MENSAGENS) MessageConsumer é um objetivo criado por uma sessão e usado pelo cliente JMS para receber mensagens de um destino. Um consumidor de mensagens permite um cliente JMS registrar um destino como um provedor JMS, assim quando o provedor receber as mensagens ele direciona a todos os registrados a aquele destino (ALLEN e BAMBARA, 2003). Ao criar o produtor e o consumidor de mensagem é preciso conhecer as mensagens que serão trafegadas por eles.

25 TIPOS DE MENSAGENS As mensagens podem ser associadas a domínios diferentes onde podem existir diferentes tipos, de modo a satisfazer as necessidades dos sistemas. Allen e Bambara (2003) definem alguns tipos de mensagens JMS: TextMessage: mensagem que contém apenas caracteres, ou seja, é uma string. MapMessage: mensagem que contém um objeto string e um valor primitivo Java. Exemplo: Texto/Valor. BytesMessage: mensagem que contém uma corrente de bytes não interpretados. StreamMessage: mensagem que contém uma corrente de valores primitivos Java. ObjectMessage: mensagem que contém um objeto que pode ser em série 2.15 MDB MESSAGE-DRIVEN-BEAN Dentro da arquitetura J2EE a JMS pode ser considerado um recurso gerenciado pelo contêiner, semelhante a uma conexão JDBC, onde clientes de aplicativos, EJB s e componentes da Web onde todos podem utilizar a API JMS para enviar e receber mensagens (BOND et al., 2003). Antes da especificação EJB 2.0, uma aplicação só podia suportar passagem de mensagens assíncronas escrevendo um programa Java que atuasse como receptor. As mensagens eram recebidas fora do servidor, sendo impossível de fazer parte de uma transação. Para este fim foi desenvolvido o MDB (Message-Driven-Bean), uma combinação das funcionalidades da JMS com o EJB, assim as mensagens são recebidas dentro do servidor e podem utilizar todos os serviços que o contêiner EJB implementa (HAASE, 2002). Allen e Bambara (2003) afirmam que o objetivo do MDB é fazer com que os desenvolvedores de sistemas priorizem a maior parte de seu tempo se preocupando com regras de negócio do projeto, deixando que o MDB se responsabilize com todo o tratamento de fluxo de mensagens, ou seja, os MDB s foram criados para enviar e receberem mensagens assumindo todos os serviços do contêiner. Segundo Bonde (2003) na criação de um MDB é necessário associá-lo a um destino, seja ele uma fila ou um tópico, portanto quando uma mensagem chega a este destino eles são invocados pelo contêiner, ou seja, ele é implementado como um ouvinte de mensagens. O cliente não precisa saber que o consumidor é um Message-Driven-Bean, ele apenas envia sua

26 25 mensagem para um destino, seja ele fila ou tópico e o bean manipula a mensagem quando ela chega. A codificação de produtores de mensagens utilizando MDB é exatamente igual a qualquer aplicativo JMS, ou seja, a mensagem deve obedecer à especificação JMS e o destino deve ser um nome JNDI registrado (HAEFEL, 2001) SERVLETS & JAVA SERVER PAGES (JSP) Servlets e JSP são tecnologias desenvolvidas pela empresa Sun com objetivo de proporcionar um desenvolvimento de aplicações Web acoplado componentes Java que executem do lado de um servidor (Server Side). Servlets e JSP fazem parte da plataforma Java que fornece um conjunto de tecnologias para o desenvolvimento de soluções robustas e confiáveis para a Web (OLIVEIRA, 2001) SERVLETS Segundo Oliveira, (2001) Servlets são classes Java que são executadas e instanciadas em associação com servidores WEB, atendendo requisições realizadas por meio do protocolo HTTP. Ao serem acionados, os objetos servlets são responsáveis por enviar a resposta na forma de uma página HTML ou qualquer outro conteúdo MIME. Portanto Servlets podem ser definidos como uma API para construção de componentes do lado servidor com o objetivo de fornecer um padrão para comunicação entre clientes e servidores (FIELDS e KOLB, 2000). Servlets utiliza instáncias que são executadas dentro de um ambiente Java denominado container, onde o contâiner tem como objetivo gerenciar as instâncias dos servlets e prover os serviços de rede necessários para as requisições e respostas. O contâiner realiza suas ações em associação com servidores WEB recebendo e tratando as requisições enviadas por eles. Tipicamente, existe apenas uma instância de cada servlet, mas o container pode criar várias threads para permitir que uma única instância servlet atenda mais de uma requisição simultaneamente.

27 JAVA SERVER PAGES (JSP) Java Server Pages (JSP) é uma tecnologia adotada na utilização no desenvolvimento de aplicações para Web, onde tem a semelhança à tecnologia Active Server Pages (ASP) da Microsoft. JSP por ser tratar de uma linguagem de programação Java ele tem vantagem de uma portabilidade de plataforma, que permite o usuário executar em outros sistemas operacionais. A vantagem que a tecnologia JSP permite ao desenvolvedor de páginas para Internet produzir aplicações que, acessam o banco de dados, manipulam arquivos no formato texto, captam informações a partir de formulários e captam informações sobre o visitante e sobre o servidor. Uma página utilizando uma tecnologia JSP, depois de instalada em um servidor de aplicação compatível com a tecnologia Java EE, é transformada em um servlet. Sendo assim quando uma página JSP é carrega pelo container JSP pela primeira vez, é gerado código Java, que é compilado, gerando um servlet que, ao ser executado, gera uma página HTML que é enviada ao navegador (OLIVEIRA, 2001).

28 27 3. ABORDAGEM PRÁTICA Com o estudo apresentando no decorrer do trabalho foi possível conhecer as características básicas de utilização das tecnologias fila JMS e MDB como consumidor das mensagens colocadas nas filas. O objetivo deste capítulo é apresentar uma implementação de exemplo com base nos conhecimentos apresentados. Primeiro passo para realizar esse estudo prático foi a escolha de um servidor de aplicação que suportasse os serviços da plataforma J2EE, ou seja, um servidor que suporte a execução da fila JMS, que por si é executado no contêiner WEB e EJB. O servidor escolhido para o desenvolvimento da fila foi o Oracle Weblogic na versão 11g disponível em html. O segundo passo foi realizar o download a IDE de desenvolvimento do Eclipse que suporte a implementação utilizando o Servidor Weblogic que está disponível no site do fabricante. Para configuração do ambiente Weblogic na IDE Eclipse, foi utilizado o tutorial de configuração do seguinte endereço, Já com Weblogic Server instalado e configurado juntamente com o servidor, é possível iniciar o mesmo, podendo em seguida acessá-lo via browser ( como apresentado na Figura 12. Figura 12 Console Administrativo Weblogic 11g

29 ENVIO DE MENSAGEM PARA FILA JMS A Figura 13, linha 8 é utilizado para criar uma URL de acesso a fila QueueTeste e na linha 11 acesso a Factory da fila QueueConnectionFactory. A Figura 14 apresenta o código utilizado para enviar uma mensagem de texto JMS para uma fila. Ainda na Figura 14 as linhas 1, 2, 3 e 4 são utilizadas para criar um contexto com a árvore JNDI e obter a referência com uma fila JMS. Em seguida nas linhas 7 e 8 é criada uma conexão ativa que se conecta na tabela da fila e na linha 11 inicia-se uma sessão com a fila. Na linha 14 é criado um Produtor de mensagens (MessageProducer - QueueSender), objeto utilizado para produzir e enviar mensagens, consequentemente as linhas 16 e 17 criam uma mensagem do tipo texto e atribuem um valor a ela, e a linha 20 envia a mensagem. As linhas 21, 22 e 23 liberam os recursos. Figura 13 Exemplo Criando Acesso a Fila Figura 14 Exemplo Enviando Mensagem para fila JMS

30 RECEBIMENTO DE MENSAGEM DE UMA FILA JMS A Figura 15 apresenta o código utilizado para receber a mensagens, porém a diferença no código está entre as linhas 13 e 20. A linha 13 cria um consumidor de mensagens (MessageConsumer - QueueReceiver), que irá eliminar as mensagens, na linha 14 inicia-se o ciclo de consumo que é executado dentro de uma estrutura de repetição While. Dentro desta estrutura o código da linha 17 consome a mensagem e a linha 19 imprime. Neste exemplo a mensagem é do tipo texto, porém ela poderia estar utilizando todos os tipos de mensagens que a JMS estende. Figura 15 Exemplo Recebimento de Mensagem de uma fila JMS 3.3 ARQUITETURA DO PROTÓTIPO Na Figura 16, ilustra arquitetura utilizada durante o estudo das tecnologias para o desenvolvimento do protótipo: Figura 16 Tela Estrutura de Domínio.

31 30 JSP e SERVLET: é uma camada de apresentação usada na comunicação visual ao usuário. WEB SERVICE: responsável em identificar o tipo da ação enviada através da página Web JSP e SERVLET, via formulário com dados de entrada, criando um objeto comum denominado ConsultaEvent, utilizando o conceito da tecnologia JAXB para realizar o Parser no qual o objeto é criado automaticamente de acordo com as convenções estabelecidas via XSD, realizando a conversão do Bean respectivo para XML, formato adotado para realizar o POST na fila inserindo esta informação na fila correspondente. As Figuras 17, 18 ilustram uma classe Java ConsultaEvent fazendo uso da tecnologia JAXB. Figura 17 Exemplo Projeto XSD Figura 18 Exemplo Documento XSD Após mapear todos os campos no arquivo XSD é possível gerar automaticamente as classes conforme mostram as Figuras 19 e 20 no pacote Schema definido pelo usuário, onde cada classe tem sua função específica criada pelo JAXB e uma comunicação com a tecnologia MDB.

32 31 Figura 19 Exemplo Gerar JAXB através Documento XSD Figura 20 Exemplo Schema criado através Documento XSD BD QUEUE: é uma configuração do ambiente WebLogic 11g Server e banco de dados Oracle SQLDeveloper, usado para criar a Fila e a tabela que irá armazenar os dados manipulados pela mesma. o Script para Criar a estrutura da Fila JMS Figura 21 Exemplo Script Criação Fila JMS A Figura 22 apresenta o resultado após a execução do Script com os procedimentos para criar a fila propriamente dita e a tabela que vai ser responsável em armazenar a informação.

33 32 Figura 22 Exemplo SQL Developer Criar fila JMS MDB Consumidor da Fila tem a função contrária do WebService, pois também faz o uso da tecnologia JAXB, recebendo o bean e o convertendo em XML para realizar ação, monitorando as requisições que a fila recebe e dispara via stubs a execução da ação que foi passada pelo formulário JSP. A Figura 23 ilustra o estudo executado durante o protótipo na utilização do MDB Message-Driven-Bean, para executar a leitura a fila JMS. Figura 23 Exemplo MDB Message-Drive-Bean

34 33 PERSISTE DADOS: após o MDB ler a fila JMS e processar as informações passadas via JSP e SERVLET para uma fila, dispara ação correspondente via Stubs que vai persistir no banco de dados armazenando a informações na base de dados Oracle. 3.4 CONFIGURAÇÃO FILA JMS WEBLOGIC 11G SERVER A tecnologia Oracle Weblogic 11g Server é um servidor baseado no Java EE 5, que visam facilitar o desenvolvimento e o gerenciamento dos serviços fornecendo um acesso em um único ponto às informações que estão distribuídas pela rede externa ou interna de uma empresa, oferecendo compromisso de disponibilizar aos desenvolvedores empresariais uma implementação mais eficiente e produtiva na sua performance, para sua produção e utilização das API aprimoradas. Abaixo serão apresentadas configurações necessárias para criar filas JMS fazendo o uso WebLogic 11g. Figura 24 Tela Estrutura Domínio Servidores JMS: necessário criar um nome para o servidor JMS e um Novo Armazenamento para realizar a comunicação com fila, conforme apresentados nas Figuras 25 e 26: Figura 25 Tela Servidor JMS

35 34 Figura 26 Configurando Servidor A Figura 27 indica que a lista de Servidores JMS foi criada com sucesso. Figura 27 Tela Filtro JMS Criar um Módulo JMS: é responsável por definir filas e tópicos, conforme apresentado nas Figuras 28, 29, 30, 31, 32 e 33: Figura 28 Tela Módulo JMS

36 35 Figura 29 Tela Configurando Servidor Módulo JMS Figura 30 Filtro Módulo JMS Figura 31 Tela Configura Tipo Fila JMS

37 36 Figura 32 Tela Configuração Recurso Módulo JMS Figura 33 Tela Filtro Recurso JMS Agente de Armazenamento e Envio: são responsáveis por armazenar e encaminhar mensagens entre esses pontos finais locais e remotos. Um agente pode ser configurado para ter somente recursos de envio, recursos de recebimento ou ambos, conforme as Figuras 34, 35 e 36:

38 37 Figura 34 Tela Configuração de Armazenamento e Envio Figura 35 Tela Configuração Agente de Armazenamento Figura 36 Tela Filtro Agente de Armazenamento Durante e o estudo foram utilizadas figuras ilustradas acima para descrever os principais passos para configurações e entendimento de Filas JMS no Weblogic 11 g Server.

39 38 4. CONCLUSÃO Com o estudo desenvolvido neste trabalho, foi apresentada a utilização da tecnologia JMS articulada a um MDB (Message-Driven-Bean), de forma a atender a necessidade do desenvolvimento de soluções rápidas e eficientes, no que diz respeito a utilização de filas de comunicação em ambientes de desenvolvimento que possuem uma arquitetura distinta e necessidades de funcionamento integrado entre tecnologias que suportem esta implementação. Para somar ao processo, também foi desenvolvido web services, seguindo o mesmo conceito de articulação entre sistemas distintos. Durante o trabalho foi possível levantar alguns pontos importantes como, a necessidade da integração de aplicativos de software dentro das empresas, evidenciando a necessidade, ou, até mesmo exigência, de tornar o ambiente mais confiável, gerando uma sincronização dos dados na comunicação destas soluções. Tratando-se da abordagem prática realizada durante o estudo, foi possível aplicar os componentes da API e entender suas funcionalidade, demonstrando um ambiente de desenvolvimento mais viável na implementação de troca de mensagens, tanto no quesito de implementação como de suporte posterior e com isso, sendo possível perceber a grande importância na implementação de aplicativos de grande porte na utilização das tecnologias JMS e Web Service para se obter performance e escalabilidade na integração de sistemas de grande porte.

40 39 5. TRABALHOS FUTUROS Como sugestão para trabalhos futuros, sugere-se a implementação da JMS na integração de aplicativos na área comercial, com objetivo de explorar todo conhecimento que foi adquirido neste trabalho. Também estudar outras tecnologias de troca de mensagens assíncronas. E ao longo prazo seria o desenvolvimento de um protótipo de um Framework que encapsule toda a regra de negócio de integração utilizando os códigos.

41 40 6. REFERÊNCIAS BIBLIOGRÁFICAS ALBINADER NETO, Jorge; LINS, Rafael Dueire. Web Services em Java. Rio de Janeiro: Brasport, Arquiteturas de Middleware: Orientado a Mesagem (JMS) Disponível em: 03, Maio, ALLEN, Paul e BAMBARA Joseph. Sun Certified Enterprise Architect for J2EE: Guia Oficial de Certificação. Rio de Janeiro: Campus, BARBIERI, Carlos. BI Business Intelligence. Rio de Janeiro: Axcel Books, BODOFF, Stephanie e GREEN, Dale. Tutorial do J2EE. Rio de Janeiro: Elsevier Editora Ltda, BOND, Martin et al. Aprenda J2EE em 21 Dias. São Paulo: Pearson Education, FIELDS, Duane K. e KOLB, Mark Desenvolvendo na Web com JavaServer Pages. Editora Ciência Moderna, GIOTTA P., et all. Professional JMS Programming. United States: Wrox Press, HAASE, Kim. Java Message Service API Tutorial. Califórnia: Sun Microsystems, Inc, HAEFEL, Richard Monson e CHAPPELL, David A. Java Message Service. O Reilly, JURIC, M. B., et all. Professional J2EE EAI. Wrox Press. United States, 2001.

42 41 KURNIAWAN, Budi. Java Para Web com Servlets, JSP e EJB. Rio de Janeiro: Editora Ciência Moderna, MARK ENDREI, JENNY Ang, ALI Arsanjani, Sook Chua, Philippe Comte, Pål Krogdahl, Min Luo e Tony Newling (2004, Abril). Patterns: Service-Oriented Architecture and Web Services (1ed.). IBM Redbooks. NETO, Kanji Hara. Desenvolvimento de sistemas web utilizando arquitetura em três camadas e applets. Cornélio Procópio: Centro Federal de Coordenação Tecnológica do Paraná - CEFET-PR, ORFALI, Robert. Cliente/Servidor. Guia essencial de sobrevivência. Rio de Janeiro: Info book, Oliveira, A. P. Apostila Servlet/JSP. Universidade Federal de Viçosa. Departamento de Informática, RECKZIEGEL, M. Gerenciamento de infra-estruturas de medição usando Web Service, ROMAN, Ed e AMBLER, Scott e JEWELL, Tyler. Mastering Enterprise JavaBeans. Segunda Edição. John Wiley and Sons, Inc., SERSON, Roberto Rubinstein. Programação Orientada a Objetos com Java 6. Rio de Janeiro: Brasport, SILVA, Luiz Augusto Matos. Plataforma Java J2EE. A atual pedida no cenário corporativo. Manaus.União Nacional do Norte (UNINORTE), Sun Microsystems. Java 2 Platform, Enterprise Edition (J2EE) disponível em.: Acesso em: 03/05/2012. The Java Web Services Tutorial: For Java Web Services Developer s Pack, v2.0. Sun Microsystems. 2006, disponível em:

43 42 Acesso em 03/05/2012 TITTEL, E. (2003), Coleção Schaum XML, Bookman, ORACLE disponível em: