universidade tecnológica federal do paraná - DAINF

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
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
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.
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 – MessageDriven-Bean.
Keywords: Java Message Service, Messaging, Mensage-Driven-Bean, Web Service,
Weblogic 11g.
LISTA DE FIGURAS
Figura 1 – Documento XML .................................................................................................. 11
Figura 2 – Documento XSD ................................................................................................... 11
Figura 3 – Passos processo Binding JAXB ........................................................................... 12
Figura 4 – Leitura Arquivo JAXB ........................................................................................ 13
Figura 5 – Parser arquivo JAXB........................................................................................... 13
Figura 6 – Processo API – Java Persistence API ................................................................. 14
Figura 7 – Exemplo de utilização de fila de mensagem ...................................................... 16
Figura 8 – Envio de mensagem de um sistema Java para um sistema legado .................. 17
Figura 9 – Troca de Mensagem utilizando o modelo PTP .................................................. 19
Figura 10 – Troca de Mensagem utilizando o modelo PUB/SUB ...................................... 19
Figura 11 – Modelo de arquitetura da API JMS ................................................................. 21
Figura 12 – Console Administrativo Weblogic 11g ............................................................. 27
Figura 13 – Exemplo Criando Acesso a Fila ........................................................................ 28
Figura 14 – Exemplo Enviando Mensagem para fila JMS ................................................. 28
Figura 15 – Exemplo Recebimento de Mensagem de uma fila JMS .................................. 29
Figura 16 – Tela Estrutura de Domínio. .............................................................................. 29
Figura 17 – Exemplo Projeto XSD ........................................................................................ 30
Figura 18 – Exemplo Documento XSD ................................................................................. 30
Figura 19 – Exemplo Gerar JAXB através Documento XSD ............................................. 31
Figura 20 – Exemplo Schema criado através Documento XSD ......................................... 31
Figura 21 – Exemplo Script Criação Fila JMS ..................................................................... 31
Figura 22 – Exemplo SQL Developer Criar fila JMS ........................................................... 32
Figura 23 – Exemplo MDB – Message-Drive-Bean .............................................................. 32
Figura 24 – Tela Estrutura Domínio .................................................................................... 33
Figura 25 – Tela Servidor JMS ............................................................................................. 33
Figura 26 – Configurando Servidor ...................................................................................... 34
Figura 27 – Tela Filtro JMS .................................................................................................. 34
Figura 28 – Tela Módulo JMS ............................................................................................... 34
Figura 29 – Tela Configurando Servidor Módulo JMS ...................................................... 35
Figura 30 – Filtro Módulo JMS............................................................................................. 35
Figura 31 – Tela Configura Tipo Fila JMS .......................................................................... 35
Figura 32 – Tela Configuração Recurso Módulo JMS ....................................................... 36
Figura 33 – Tela Filtro Recurso JMS ................................................................................... 36
Figura 34 – Tela Configuração de Armazenamento e Envio.............................................. 37
Figura 35 – Tela Configuração Agente de Armazenamento .............................................. 37
Figura 36 – Tela Filtro Agente de Armazenamento ............................................................ 37
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
Desenvolvimento)
XSD
XML Schema Definition
XML
eXtensible Markup Language (Linguagem Extensível de Marcação)
para
SUMÁRIO
1. INTRODUÇÃO .................................................................................................................. 7
1.1
TEMA .......................................................................................................................... 7
1.2
JUSTIFICATIVA ........................................................................................................ 7
1.3
OBJETIVO GERAL .................................................................................................... 7
1.4
OBJETIVOS ESPECÍFICOS ...................................................................................... 8
2. PROPOSTA DA PESQUISA ............................................................................................. 9
2.1
JAVA ........................................................................................................................... 9
2.2
WEB SERVICE ........................................................................................................... 9
2.3
XML: DEFINIÇÃO DOS DADOS ........................................................................... 10
2.4
JAXB (JAVA ARCHITECTURE FOR XML BINDING) ........................................ 12
2.5
JPA (JAVA PERSISTENCE API) ............................................................................ 13
2.6
JMS (JAVA MESSAGE SERVICE) ......................................................................... 14
2.7
MIDDLEWARE ........................................................................................................ 15
2.8
MOM – MESSAGE ORIENTED MIDDLEWARE ..................................................... 15
2.9
CLIENTE E PROVEDOR JMS ................................................................................ 17
2.10
TROCA DE MENSAGENS ...................................................................................... 18
2.11
PERSISTÊNCIA DE MENSAGENS ........................................................................ 19
2.12
TRANSAÇÃO ........................................................................................................... 20
2.13
CONHECENDO API JMS ........................................................................................ 20
2.14
TIPOS DE MENSAGENS......................................................................................... 24
2.15
MDB – MESSAGE-DRIVEN-BEAN ....................................................................... 24
2.16
SERVLETS & JAVA SERVER PAGES (JSP) ......................................................... 25
2.16.1
SERVLETS ........................................................................................................ 25
2.16.2
JAVA SERVER PAGES (JSP) .......................................................................... 26
3. ABORDAGEM PRÁTICA .............................................................................................. 27
3.1
ENVIO DE MENSAGEM PARA FILA JMS ........................................................... 28
3.2
RECEBIMENTO DE MENSAGEM DE UMA FILA JMS ...................................... 29
3.3
ARQUITETURA DO PROTÓTIPO ......................................................................... 29
3.4
CONFIGURAÇÃO FILA JMS WEBLOGIC 11G SERVER ................................... 33
4. CONCLUSÃO .................................................................................................................. 38
5. TRABALHOS FUTUROS ............................................................................................... 39
6. REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................. 40
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.
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.
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á
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.
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.
12
2.4
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).
JAXB
SCHEMA
Bind
Instance of
Follows
Unmarshal
(validate)
OBJECTS
DOCUMENT
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.
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
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
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.
16
Varias
horas
mais tarde
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.
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).
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:
19
Fila
4
Cliente 1
3
2
Consome
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
4
Cliente 1
Confirma
1
Publica
5
Consome
Cliente 3
2
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.
20
2.12
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.
2.13
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.
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)
Mais nenhuma
Mensagem
Cria Sessão
(Session)
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,
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;
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.
Um Session tem como responsabilidade administrar os consumidores e produtores de
mensagens:
 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.
24
2.14
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
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).
2.16
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).
2.16.1 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.
26
2.16.2 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).
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 http://www.oracle.com/technetwork/middleware/ias/downloads/wls-main097127.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, http://blog.erkobridee.com/2010/03/08/webservice-oracleweblogic-server-11g/.
Já com Weblogic Server instalado e configurado juntamente com o servidor, é
possível
iniciar
o
mesmo,
podendo
em
seguida
acessá-lo
(http://localhost:7001/console), como apresentado na Figura 12.
Figura 12 – Console Administrativo Weblogic 11g
via
browser
28
3.1
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
29
3.2
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.
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.
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.
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
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
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
35
Figura 29 – Tela Configurando Servidor Módulo JMS
Figura 30 – Filtro Módulo JMS
Figura 31 – Tela Configura Tipo Fila JMS
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:
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.
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.
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.
40
6.
REFERÊNCIAS BIBLIOGRÁFICAS
ALBINADER NETO, Jorge; LINS, Rafael Dueire. Web Services em Java. Rio de
Janeiro: Brasport, 2006.
Arquiteturas
de
Middleware:
Orientado
a
Mesagem
(JMS)
http://www.cin.ufpe.br/~redis/courses/plataformas-distribuicao/intranet/in1118-notaul08.pdf: Disponível em: 03, Maio, 2012.
ALLEN, Paul e BAMBARA Joseph. Sun Certified Enterprise Architect for J2EE:
Guia Oficial de Certificação. Rio de Janeiro: Campus, 2003.
BARBIERI, Carlos. BI – Business Intelligence. Rio de Janeiro: Axcel Books, 2001.
BODOFF, Stephanie e GREEN, Dale. Tutorial do J2EE. Rio de Janeiro: Elsevier
Editora Ltda, 2002.
BOND, Martin et al. Aprenda J2EE em 21 Dias. São Paulo: Pearson Education, 2003.
FIELDS, Duane K. e KOLB, Mark Desenvolvendo na Web com JavaServer Pages.
Editora Ciência Moderna, 2000.
GIOTTA P., et all. Professional JMS Programming. United States: Wrox Press, 2000.
HAASE, Kim. Java Message Service API – Tutorial. Califórnia: Sun Microsystems,
Inc, 2002.
HAEFEL, Richard Monson e CHAPPELL, David A. Java Message Service. O’Reilly,
2001.
JURIC, M. B., et all. Professional J2EE EAI. Wrox Press. United States, 2001.
41
KURNIAWAN, Budi. Java Para Web com Servlets, JSP e EJB. Rio de Janeiro:
Editora Ciência Moderna, 2002.
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, 2002.
ORFALI, Robert. Cliente/Servidor. Guia essencial de sobrevivência. Rio de Janeiro:
Info book, 1996.
Oliveira, A. P. Apostila Servlet/JSP. Universidade Federal de Viçosa. Departamento
de Informática, 2001.
RECKZIEGEL, M. Gerenciamento de infra-estruturas de medição usando Web
Service, 2006.
ROMAN, Ed e AMBLER, Scott e JEWELL, Tyler. Mastering Enterprise JavaBeans.
Segunda Edição. John Wiley and Sons, Inc., 2002.
SERSON, Roberto Rubinstein. Programação Orientada a Objetos com Java 6. Rio de
Janeiro: Brasport, 2007.
SILVA, Luiz Augusto Matos. Plataforma Java J2EE. A atual pedida no cenário
corporativo.
Manaus.União
Nacional
do
Norte
(UNINORTE),
2006.
Sun Microsystems. Java 2 Platform, Enterprise Edition (J2EE) disponível em.:
http://java.sun.com/j2ee/. 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:
42
http://www.oracle.com/technetwork/articles/javase/index-140168.html
Acesso em 03/05/2012
TITTEL, E. (2003), Coleção Schaum – XML, Bookman, 2003.
ORACLE disponível em: http://www.oracle.com/technetwork/pt/middleware/oracleweblogic-server-technical-wh-134365-ptb.pdf.