Universidade Salgado de Oliveira UNIVERSO

Campus Recife
Curso de Tecnologia em Internet e Redes
Prof. Alexandre de Souza Leo
DISCIPLINA
SERVIDORES DE APLICAO PARA INTERNET
Apostila de aula
Recife - PE
Fev. 2007
2
SUMRIO
1. INTRODUO.............................................................................................................................................................5
1.1. OBJETIVO....................................................................................................................................................................5
1.2. CARGA HORRIA.........................................................................................................................................................5
1.3. EMENTA......................................................................................................................................................................5
1.4. MATERIAL...................................................................................................................................................................6
1.5. METODOLOGIA............................................................................................................................................................7
1.6. PROVAS.......................................................................................................................................................................7
1.7. MERCADO DE TRABALHO............................................................................................................................................8
2. UNIDADE I - PRINCPIOS DE SISTEMAS DISTRIBUDOS ...............................................................................9
2.1. OBJETIVOS ..................................................................................................................................................................9
2.2. SISTEMAS DISTRIBUDOS CONCEITOS E EXEMPLOS...................................................................................................9
2.2.1. Introduo a sistemas distribudos ...................................................................................................................9
2.2.2. Definio de sistema distribudo.......................................................................................................................9
2.2.3. Motivao para utilizao de sistemas distribudos .......................................................................................10
2.2.4. Exemplos de sistemas distribudos..................................................................................................................10
2.2.5. Desafios na construo de sistemas distribudos............................................................................................12
2.3. MODELOS DE ARQUITETURA DE SISTEMAS DISTRIBUDOS .........................................................................................13
2.3.1. Modelo de arquitetura de sistema...................................................................................................................13
2.3.2. Modelo de arquitetura de sistemas centralizados...........................................................................................13
2.3.3. Modelos de arquitetura de sistemas distribudos............................................................................................13
2.3.4. Modelo de arquitetura cliente-servidor ..........................................................................................................14
2.3.5. Modelo de arquitetura servidor proxy ............................................................................................................14
2.3.6. Modelo de arquitetura ponto a ponto .............................................................................................................15
2.4. MODELO DE ARQUITETURA CLIENTE-SERVIDOR........................................................................................................16
2.4.1. Utilizao do modelo de arquitetura cliente-servidor ....................................................................................16
2.4.2. Desenvolvimento de aplicaes - Um breve histrico ....................................................................................16
2.4.3. Aplicaes cliente-servidor.............................................................................................................................17
2.4.4. Arquitetura cliente-servidor com arquivos compartilhados ...........................................................................17
2.4.5. Arquitetura cliente-servidor em camadas.......................................................................................................18
2.4.6. Arquitetura cliente-servidor de 02 camadas...................................................................................................18
2.4.7. Arquitetura cliente-servidor de 03 camadas...................................................................................................19
2.5. MODELO DE ARQUITETURA CLIENTE-SERVIDOR DE 03 CAMADAS .............................................................................20
2.5.1. Tipos de servidores de aplicao....................................................................................................................21
2.5.2. Arquitetura C-S de 03 camadas com servidor de mensagens .........................................................................21
2.5.3. Conceitos de transao...................................................................................................................................21
2.5.4. Arquitetura C-S de 03 camadas com servidor TP monitor.............................................................................21
2.5.5. Conceitos de orientao a objetos ..................................................................................................................22
2.5.6. Arquitetura C-S de 03 camadas com servidor de objetos distribudos ...........................................................22
2.6. TECNOLOGIAS UTILIZADAS EM SISTEMAS DISTRIBUDOS...........................................................................................23
3
2.6.1. Conceitos de comunicao entre processos Interprocess Communication (IPC)........................................23
2.6.2. Principais tecnologias utilizadas em sistemas distribudos ............................................................................23
2.6.3. Socket em Redes IP.........................................................................................................................................24
2.6.4. Chamada de Procedimento Remoto - Remote Procedure Call - RPC............................................................24
2.6.5. Common Object Request Broker Architecture - CORBA................................................................................25
2.6.6. Distributed Component Object Model - DCOM.............................................................................................26
2.6.7. Remote Method Invocation - RMI...................................................................................................................27
2.6.8. Message Oriented Middleware - MOM ..........................................................................................................27
2.6.9. Tecnologias X Tipos de servidores de aplicao............................................................................................28
3. UNIDADE II TECNOLOGIA JAVA EE...............................................................................................................29
3.1. OBJETIVOS ................................................................................................................................................................29
3.2. VISO GERAL DA PLATAFORMA JAVA EE..................................................................................................................29
3.2.1. Tecnologia Java..............................................................................................................................................29
3.2.2. Java Platform, Enterprise Edition Java EE.................................................................................................31
3.2.3. Contineres Java EE.......................................................................................................................................32
3.2.4. APIs Java EE..................................................................................................................................................33
3.2.5. Papis e responsabilidades na plataforma Java EE.......................................................................................33
3.3. INTRODUO A XML................................................................................................................................................34
3.3.1. O que XML?.................................................................................................................................................34
3.3.2. XML x HTML..................................................................................................................................................35
3.3.3. Elementos, tags, dados e atributos..................................................................................................................35
3.3.4. Arquivo XML...................................................................................................................................................36
3.3.5. Regras em documentos XML ..........................................................................................................................37
3.3.6. Document Type Definition - DTD...................................................................................................................37
3.3.7. Uso do XML em aplicaes ............................................................................................................................38
3.4. APLICAES E MDULOS JAVA EE............................................................................................................................38
3.4.1. Estrutura de uma aplicao Java EE .............................................................................................................38
3.4.2. Montagem de aplicaes e mdulos Java EE.................................................................................................41
3.4.3. Instalao de aplicaes e mdulos Java EE .................................................................................................41
3.5. COMPONENTES WEB DA PLATAFORMA JAVA EE .......................................................................................................41
3.5.1. HTTP e aplicaes web ..................................................................................................................................41
3.5.2. Componentes web Java EE.............................................................................................................................42
3.5.3. Cenrios de aplicaes Java EE com componentes web................................................................................44
3.5.4. Estrutura de um mdulo web ..........................................................................................................................44
3.5.5. Contexto de um mdulo web...........................................................................................................................45
3.5.6. Acessando componentes web ..........................................................................................................................46
3.6. CONCEITOS DE JNDI .................................................................................................................................................47
3.6.1. Servios de nomenclatura e diretrio .............................................................................................................47
3.6.2. Servios de nomenclatura e diretrio .............................................................................................................48
3.7. CONCEITOS DE JDBC, POOLS DE CONEXES E FONTES DE DADOS.............................................................................49
3.7.1. Java Database Connectivity - JDBC ..............................................................................................................49
3.7.2. Pools de conexes (connection pools) ............................................................................................................49
3.7.3. Fontes de dados JDBC (data sources)............................................................................................................50
4
3.8. COMPONENTES DE NEGCIO DA PLATAFORMA JAVA EE...........................................................................................52
3.8.1. Enterprise JavaBeans - EJBs..........................................................................................................................52
3.8.2. Tipos de EJBs..................................................................................................................................................52
3.8.3. Estrutura de um mdulo EJB..........................................................................................................................54
3.8.4. Acessando session beans.................................................................................................................................54
3.9. SEGURANA NA PLATAFORMA JAVA EE...................................................................................................................56
3.9.1. Viso geral de segurana em Java EE............................................................................................................56
3.9.2. Autenticao e segurana de rede em mdulos web.......................................................................................57
3.9.3. Autorizao em mdulos web .........................................................................................................................58
3.9.4. Autorizao em mdulos EJB.........................................................................................................................58
3.9.5. Responsabilidades pela segurana em Java EE.............................................................................................59
4. JBOSS ..........................................................................................................................................................................60
4.1. OBJETIVO..................................................................................................................................................................60
4.2. VISO GERAL DO JBOSS............................................................................................................................................60
4.2.1. O mercado de servidores Java EE..................................................................................................................60
4.2.2. Histrico do JBoss ..........................................................................................................................................60
4.2.3. Alguma caractersticas do JBoss ....................................................................................................................61
4.3. O SERVIDOR JBOSS ...................................................................................................................................................61
4.3.1. Download e instalao do JBoss ....................................................................................................................61
4.3.2. Estrutura de diretrios do JBoss ....................................................................................................................62
4.3.3. Configuraes de servidor..............................................................................................................................62
4.3.4. O servio Tomcat ............................................................................................................................................64
4.3.5. O servio de log ..............................................................................................................................................64
4.4. ADMINISTRAO DO JBOSS ......................................................................................................................................65
4.4.1. Ferramentas de administrao.......................................................................................................................65
4.4.2. Administrao pela linha de comando............................................................................................................65
4.4.3. Administrao pelo browser ...........................................................................................................................65
5. INFRA-ESTRUTURA E ALTA DISPONIBILIDADE ...........................................................................................68
5.1. OBJETIVO..................................................................................................................................................................68
5.2. CLUSTER JAVA EE.....................................................................................................................................................68
5.2.1. Definio de cluster ........................................................................................................................................68
5.2.2. Cluster Java EE ..............................................................................................................................................68
5
1. Introduo
1.1. Objetivo
Realizar diversos estudos dirigidos e laboratrios para conhecer a plataforma Java
Enterprise Edition (Java EE).
Explorar os recursos da API do Java EE para:
Instalar componentes distribudos (EJB) que utilizam os servios oferecidos por
servidores de aplicaes Java EE como JBoss, BEA Weblogic, Sun IPlanet, IBM
WebSphere, JONAS, OpenEJB e similares.
Integrar com contineres web (Servlet/JSP) como Tomcat.
Conectar com diversos bancos de dados.
Executar tarefas prticas no JBoss como instalao, configurao e manuteno.
Integrar o servidor Java EE com ferramentas de gerenciamento, segurana e
desenvolvimento.
1.2. Carga horria
90 horas-aula
1.3. Ementa
Unidade I - Princpios de sistemas distribudos
Modelos de arquitetura cliente-servidor
Modelo de arquitetura C-S de 3 camadas
Tecnologias:
Socket
RPC
CORBA
DCOM/COM+
RMI
Unidade II - Tecnologia Java EE
Introduo a XML
Servlet/JSP
JNDI
6
JDBC
EJB
Segurana
Unidade III - JBoss
Instalao, configurao, implantao e uso do JBoss com aplicaes distribudas
consistindo de Enterprise Java Beans, Servlets e pginas JSP
Unidade IV - Infra-estrutura e alta disponibilidade
Clusters
Redundncia
Estruturas fsicas
Unidade V - Outras tecnologias distribudas
CORBA
COM/DCOM
MTS
COM+
.Net
1.4. Material
Apostila de aula
Livros eletrnicos
The Java EE 5 Tutorial
http://java.sun.com/javaee/5/docs/tutorial/doc/
JBoss Application Server Guide
http://labs.jboss.com/portal/jbossas/docs
JBoss AS Getting Started Guide
http://labs.jboss.com/portal/jbossas/docs
Outros
Apresentaes, listas de exerccios, artigos e sites na Internet
7
1.5. Metodologia
Aulas expositivas
Com transparncias
Aulas de exerccios
Resoluo de exerccios para fixar o conhecimento.
So 04 listas de exerccios, cada uma podendo valer 0,1 (um dcimo) na mdia final
(V1+V2+VT / 3). Somente os Alunos que tiverem mdia final abaixo de 7,0 tero
direito aos pontos.
A resoluo das listas semelhante a uma prova com consulta. As listas devero ser
respondidas individualmente em folha de papel pautado.
Os Alunos sem a apostila recebero a presena mas no podero participar da aula.
A tolerncia mxima de atraso de 25 minutos.
Aulas prticas no laboratrio
Equipes de 3 Alunos.
1.6. Provas
VT
So 9 exerccios prticos no laboratrio feitos em equipes de 3 Alunos, cada um
valendo de 0 a 10 pontos, sendo:
1,5 (um ponto e meio) pela participao do Aluno;
3,5 (trs pontos e meio) pela execuo dos procedimentos do laboratrio (para toda
a equipe);
5,0 (cinco pontos) pela resoluo e entrega das questes dos laboratrios na data
combinada (para toda a equipe).
A nota da VT ser a mdia das 7 maiores notas.
Cada equipe poder perder at 2 laboratrios. A equipe que no comparecer a um
exerccio de laboratrio perder a nota correspondente.
A tolerncia mxima de atraso de 25 minutos. O Aluno que chegar depois desse prazo
no ter direito pontuao referente participao.
A resoluo das questes entregue aps a data combinada valer 4,0 (quatro pontos).
V1 / V2 / VS
O Aluno s pode fazer a prova na sua turma.
8
1.7. Mercado de trabalho
O desenvolvimento de aplicaes cliente-servidor fez surgir o papel do administrador de banco
de dados (DBA) nas equipes de TI.
Da mesma forma, o desenvolvimento de aplicaes baseadas em servidores de aplicao fez
surgir o papel do administrador de servidor de aplicao.
Equipe de TI
Analistas
de Sistemas
Desenvolvedores
Gerentes
Analistas de Suporte
- Rede
- Hardware
- Software
Tcnicos de Suporte
Gerentes
Desenvolvimento Produo e Suporte
DBA
Administrador
de Servidor
de Aplicao
9
2. Unidade I - Princpios de sistemas distribudos
2.1. Objetivos
Conceituar e exemplificar sistemas distribudos
Identificar e caracterizar os modelos de arquitetura de sistemas distribudos
Definir e identificar as caractersticas do modelo de arquitetura cliente-servidor
Definir e identificar as caractersticas do modelo de arquitetura cliente-servidor de 3
camadas
Identificar e caracterizar as principais tecnologias utilizadas em sistemas distribudos
(Socket, RPC, CORBA, DCOM e RMI/EJB)
2.2. Sistemas distribudos Conceitos e exemplos
2.2.1. Um breve histrico dos sistemas distribudos
At metade da dcada de 80 computadores eram grandes, caros e trabalhavam isoladamente,
formando sistemas centralizados.
A partir da segunda metade da dcada de 80 duas tecnologias surgiram e evoluram
rapidamente, viabilizando a construo de sistemas distribudos:
Microprocessadores;
Redes (LAN e WAN).
O prximo desafio agora era desenvolver o software (de sistema e de aplicao) que permitisse
a descentralizao.
2.2.2. Definio de sistema distribudo
Viso otimista
"Um sistema distribudo um conjunto de computadores independentes que aparecem
para o usurio como um nico computador." [Andrew S. Tanenbaum e Marten van
Steen - Distributed Systems: Principles and Paradigms]
Um sistema distribudo um conjunto de computadores autnomos interligados por
uma rede e com software projetado para produzir um ambiente computacional integrado
para o usurio. [George Colouris, Jean Dollimore e Tim Kindberg Distributed
Systems: Concepts and Design]
10
Viso pessimista
"Voc sabe que tem um quando o defeito de um computador que voc nunca ouviu falar
lhe impede de fazer o seu trabalho." [Leslie Lamport]
2.2.3. Motivao para utilizao de sistemas distribudos
Economia: um conjunto de microprocessadores oferecem uma melhor relao
custo/benefcio do que um grande mainframe.
Replicao de poder de processamento: processadores independentes trabalhando na
mesma tarefa.
Natureza distribuda de algumas aplicaes: rede de supermercados, bancos, jogos em rede.
Separao fsica: para atender a requisitos de confiabilidade e proteo contra desastres.
Distribuio funcional: computadores tem diferentes capacidades funcionais
Cliente >> Entrada de dados;
Servidor >> Processamento de dados.
Necessidade de compartilhamento de recursos: um recurso pode ser compartilhado por
vrios usurios. Ex.: servidor de arquivos, de impresso.
2.2.4. Exemplos de sistemas distribudos
A Internet: rede heterognea de computadores e aplicaes
11
Intranets: redes de computadores e aplicaes restritas ao ambiente de uma organizao
Linhas de montagem robotizadas em fbricas
Sistemas de telefonia fixa
Sistemas wireless: sistema de telefonia mvel celular, laptops, PDAs, etc.
Sistemas embarcados
Gerenciamento de vo em aeronaves
Controle automotivo: automveis Mercedes Classe S so equipados com mais de 50
processadores embarcados autnomos, conectados atravs de um barramento
semelhante a uma LAN
12
2.2.5. Desafios na construo de sistemas distribudos
Heterogeneidade: grande variedade de tecnologias
Hardware e software;
Infra-estrutura de rede;
Linguagens de programao.
Segurana
Confidencialidade: proteo contra acesso a dados por indivduos no autorizados.
Integridade: proteo contra alterao ou corrupo de dados.
Escalabilidade
Um sistema distribudo escalvel se ele permanece efetivo a medida que o nmero de
usurios e/ou recursos cresce.
Confiabilidade
Falhas so mais comuns do que em sistemas centralizados.
Concorrncia
Tratamento de requisies simultneas a um mesmo recurso.
Transparncia
de acesso: permitir que recursos locais e remotos sejam acessados utilizando-se
operaes idnticas;
de localizao: permitir que recursos sejam acessados sem o conhecimento de sua
localizao;
de replicao: utilizar mltiplas instncias de um recurso aumentando a confiabilidade e
a performance, sem o conhecimento dos usurios;
de falha: permitir que os usurios continuem executando suas atividades a despeito de
falhas em componentes de hardware ou software;
de mobilidade: permitir a movimentao fsica de recursos sem afetar a operao de
usurios e programas.
Gerenciamento
13
2.3. Modelos de arquitetura de sistemas distribudos
2.3.1. Modelo de arquitetura de sistema
O modelo de arquitetura de um sistema define seus componentes (processos e computadores) e
os relacionamentos entre eles. representado utilizando-se a seguinte notao:
2.3.2. Modelo de arquitetura de sistemas centralizados
Todo os processos so executados no processador do computador principal (mainframe).
Os usurios interagem com o computador central atravs de terminais que capturam os
eventos de teclado e enviam os dados para o computador central.
Atualmente os mainframes incorporaram tecnologias que os habilitam a participar de um
ambiente de computao distribuda.
2.3.3. Modelos de arquitetura de sistemas distribudos
Cliente-servidor
Servidor proxy
Ponto a ponto
14
2.3.4. Modelo de arquitetura cliente-servidor
Cliente: processo que deseja utilizar recursos, acessar dados ou executar operaes em
um computador remoto.
Servidor: processo que gerencia recursos compartilhados, tais como dados e operaes.
Interao: par de mensagens invocao-resultado ou requisio-resposta.
Os clientes conhecem os servidores mais os servidores no precisam conhecer os clientes.
Exemplos
Browser e servidor HTTP;
MS Outlook e servidor MS Exchange;
Aplicao cliente e servidor de banco de dados.
Arquiteturas multicamadas utilizadas no desenvolvimento de aplicaes so extenses do
modelo cliente-servidor onde mltiplas camadas aumentam a escalabilidade do sistema:
02 camadas;
03 camadas.
2.3.5. Modelo de arquitetura servidor proxy
Servidor proxy: processo que funciona como um cache compartilhado de recursos.
Pode aumentar consideravelmente a performance de muitos sistemas.
15
Exemplos:
Compartilhamento e controle de acesso Internet;
Mecanismos de busca.
2.3.6. Modelo de arquitetura ponto a ponto
Aplicao: processo que executa em cada computador;
Cdigo de coordenao: parte da aplicao que coordena a execuo do processamento.
No existe distino entre cliente e servidor. Cada ponto assume os dois papis.
Aumenta a tolerncia a falhas e a escalabilidade.
A coordenao pode ser extremamente complexa.
Exemplos:
Sistemas de compartilhamento de arquivos pela Internet (Kazaar, eMule, etc...)
16
2.4. Modelo de arquitetura cliente-servidor
2.4.1. Utilizao do modelo de arquitetura cliente-servidor
A existncia de dois processos, sendo um cliente requisitando um servio e um servidor
disponibilizando este servio, caracteriza o modelo de arquitetura cliente-servidor.
Esse modelo utilizado no desenvolvimento de:
Servios de compartilhamento de recursos (arquivos, impressoras);
Sistemas de correio eletrnico;
DNS, FTP, Telnet;
Aplicaes cliente-servidor.
2.4.2. Desenvolvimento de aplicaes - Um breve histrico
At o final da dcada de 60:
Sistemas centralizados e Linguagem Assembly;
Linguagens procedurais (Ex: FORTRAN, COBOL, C).
Durante a dcada de 70:
Computadores pessoais;
Redes locais.
Durante a dcada de 80:
Protocolo TCP/IP;
Socket;
Internet;
Sistemas distribudos construdos com linguagens procedurais e tecnologia Remote
Procedure Call (RPC).
17
Durante a dcada de 90:
Linguagens orientadas a objetos (Ex: C++, Java, Object Pascal);
Sistemas distribudos construdos com linguagens orientadas a objetos e tecnologias
como CORBA, DCOM e RMI;
J2EE.
Aps o ano 2000:
Microsoft .Net;
Web Services.
2.4.3. Aplicaes cliente-servidor
Para desenvolver aplicaes utilizando o modelo de arquitetura cliente-servidor podem ser
utilizadas duas alternativas:
Arquitetura cliente-servidor com arquivos compartilhados;
Arquitetura cliente-servidor em camadas.
2.4.4. Arquitetura cliente-servidor com arquivos compartilhados
Aps o surgimento das LANs, as primeiras aplicaes cliente-servidor desenvolvidas
utilizavam arquivos compartilhados como mecanismo de armazenamento de dados.
Cliente
Apresentao de dados
Processamento de dados
Gerenciamento de dados
Servidor
Armazenamento de dados
(compartilhamento de
arquivos)
Cliente: responsvel pela apresentao (telas), processamento (regras de negcio) e
gerenciamento de dados.
Servidor: responsvel apenas pelo armazenamento de dados atravs do compartilhamento
de arquivos.
Exemplos: aplicaes com MS Access e Borland Paradox
18
Esta arquitetura s funciona bem para um nmero pequeno de usurios concorrentes, alm de
provocar um grande trfego na rede quando se trabalha com grandes volumes de dados.
Para resolver esses problemas foram criados os sistemas de gerenciamento de banco de dados
(SGBD) ou servidores de banco de dados. Um SGBD um processo servidor que gerencia o acesso
concorrente e armazena dados. As requisies so feitas utilizando-se comandos na linguagem SQL
(Structured Query Language). Exemplos: Oracle, MS SQL Server, IBM DB2, MySQL
2.4.5. Arquitetura cliente-servidor em camadas
Toda aplicao cliente-servidor pode ser divida conceitualmente em 3 camadas funcionais:
Apresentao de dados (telas);
Processamento de dados (regras de negcio);
Gerenciamento e armazenamento de dados (SGBD).
Arquiteturas multicamadas utilizadas no desenvolvimento de aplicaes so extenses do
modelo de arquitetura cliente-servidor onde as camadas funcionais da aplicao executam em
processos distintos. Exemplos:
Arquitetura cliente-servidor de 02 camadas
Fat client (cliente gordo)
Thin client (cliente magro)
Arquitetura cliente-servidor de 03 camadas
2.4.6. Arquitetura cliente-servidor de 02 camadas
Fat client (cliente gordo)
Cliente
Apresentao de dados
Processamento de dados
Servidor de
BD
Gerenciamento e armazenamento
de dados
Cliente: responsvel pela apresentao (telas) e processamento dos dados (regras de
negcio);
Servidor de banco de dados: responsvel pelo gerenciamento e armazenamento dos
dados (SGBD).
O gerenciamento mais complexo devido necessidade de redistribuio do software
cliente quando se altera telas ou regras de negcio.
19
Thin client (cliente magro)
Cliente
Apresentao de dados
Processamento de dados
Gerenciamento e armazenamento de dados
Servidor de
BD
Cliente: responsvel apenas pela apresentao dos dados;
Servidor de banco de dados: responsvel pelo processamento, gerenciamento e
armazenamento dos dados (SGBD com suporte a stored procedures e triggers).
Maior carga de processamento no servidor.
Exemplo
Apl VB
Apl VB
SQLServer
Limitaes
Performance degrada para aplicaes com mais de 100 usurios, devido necessidade
de manuteno da conexo do cliente com o servidor.
Pouca flexibilidade para mudar de fornecedor de SGBD, resultando sempre em grande
esforo de adaptao nas aplicaes.
2.4.7. Arquitetura cliente-servidor de 03 camadas
Cliente
Apresentao de dados
Servidor de
Aplicao
Processamento
de dados
Servidor de
BD
Gerenciamento e
armazenamento de dados
Cliente: responsvel pela apresentao dos dados (sempre thin client).
20
Servidor de aplicao: responsvel pelo processamento dos dados (regras de
negcio).
Servidor de banco de dados: responsvel pelo gerenciamento e armazenamento dos
dados (SGBD).
Cada camada da aplicao (apresentao, processamento e gerenciamento e armazenamento
de dados) pode executar em processadores distintos.
Exemplo
Browser
Browser MySQL WebServer
Browser
Quando comparada com a arquitetura cliente-servidor de 02 camadas, oferece mais:
Performance;
Escalabilidade;
Flexibilidade.
Limitaes
Ambientes de desenvolvimento de aplicaes cliente-servidor de 03 camadas ainda so
mais complexos do que ambientes de desenvolvimento de aplicaes de 02 camadas,
diminuindo a produtividade.
2.5. Modelo de arquitetura cliente-servidor de 03 camadas
Cliente
Apresentao de dados
Servidor de
Aplicao
Processamento
de dados
Servidor de
BD
Gerenciamento e
armazenamento de dados
21
2.5.1. Tipos de servidores de aplicao
Os servidores de aplicao da arquitetura cliente-servidor de 03 camadas podem ser
classificados em trs tipos:
Servidor de mensagens;
Servidor monitor de processamento de transaes (TP monitor);
Servidor de objetos distribudos.
2.5.2. Arquitetura C-S de 03 camadas com servidor de mensagens
Esse tipo de servidor de aplicao recebe mensagens pr-definidas dos clientes.
As mensagens so processadas sncrona ou assincronamente.
O Servidor de Aplicao retorna mensagens para os clientes aps o processamento.
Exemplos:
Servidor socket
Servidor web (Apache&PHP, IIS&ASP, Tomcat&Servlet/JSP, etc...)
2.5.3. Conceitos de transao
Transao uma unidade de interao com um SGBD (ou sistema similar), envolvendo leitura
e/ou escrita de dados, que tratada de maneira segura e independente de outras transaes
concorrentes. Uma transao deve ter as seguintes caractersticas, conhecidas pela abreviatura ACID:
Atomicidade: tudo ou nada
Consistncia: integridade referencial e regras
Isolamento
Durabilidade
Exemplo: transferncia bancria (dbito na conta origem e crdito na conta destino).
2.5.4. Arquitetura C-S de 03 camadas com servidor TP monitor
Esse tipo de servidor de aplicao utiliza a tecnologia transaction processing monitor,
disponibilizando:
Capacidade de atualizar mltiplos SGBDs em uma nica transao;
Conectividade com uma grande variedade de fontes de dados incluindo arquivos flat,
SGBDs relacionais e no relacionais, e mainframes;
22
Alto nvel de segurana;
Balanceamento de carga dinmico;
Alta escalabilidade.
Limitaes
Normalmente s permitem a utilizao de algumas linguagens (C, C++ e COBOL) para
o desenvolvimento de aplicaes.
Exemplos:
IBM CICS;
BEA Tuxedo.
2.5.5. Conceitos de orientao a objetos
Uma classe representa um conceito. Exemplos: Automvel, Conta Bancria, Animal.
Um objeto um exemplo (ou instncia) de uma classe com o qual podemos interagir dentro
de um programa. Exemplos:
Classe: Automvel > Objeto: Gol, Uno, Corsa
Classe: Conta Bancria > Objeto: Conta Bancria de Joo
Um classe tem atributos (ou propriedades) e mtodos (ou operaes).
Conta Bancria
Numero
Saldo
consultarSaldo
debitar
creditar
Classe
Atributos
Mtodos
2.5.6. Arquitetura C-S de 03 camadas com servidor de objetos distribudos
Esse tipo de servidor de aplicao utiliza tecnologias de objetos distribudos,
disponibilizando um modelo de programao orientado a objetos.
Assim como um servidor TP monitor, um servidor de aplicao baseado em objetos
distribudos disponibiliza:
Capacidade de atualizar mltiplos SGBDs em uma nica transao;
Conectividade com uma grande variedade de fontes de dados;
Balanceamento de carga dinmico;
23
Alta escalabilidade.
Exemplos:
Borland Visibroker, BEA Tuxedo [CORBA]
Microsoft Transaction Server (MTS) e COM+ [DCOM]
JBoss, IBM WebSphere, BEA WebLogic [RMI/EJB]
2.6. Tecnologias utilizadas em sistemas distribudos
2.6.1. Conceitos de comunicao entre processos Interprocess Communication
(IPC)
Sistemas distribudos so construdos tendo como base processos autnomos que precisam
trocar dados entre si atravs da rede.
Em um mesmo computador, dois processos podem se comunicar atravs de:
Pipes: a sada de um processo conectada a entrada de um outro processo;
Interrupes e sinais: condies de hardware e software, notificao de entrada/sada,
controle de processo e recurso (Ex.: kill no Unix);
Filas de mensagem;
Semforos: utilizados para monitorar e controlar a disponibilidade de recursos do sistema
operacional;
Memria compartilhada;
Sockets: mecanismo de comunicao entre processos bidirecional e ponto a ponto.
Alm de permitir a comunicao entre processos em um mesmo computador, o socket a
forma mais elementar de comunicao entre processos remotos.
2.6.2. Principais tecnologias utilizadas em sistemas distribudos
Socket;
RPC (Remote Procedure Call);
CORBA (Common Object Request Broker Architecture);
RMI (Remote Method Invocation);
DCOM (Distributed Component Object Model);
MOM (Message Oriented Middleware).
24
2.6.3. Socket em Redes IP
Em um rede IP, um socket pode ser criado utilizando-se os protocolos UDP ou TCP.
SMTP
FTP
TELNET
HTTP
UDP, TCP
IP
LAN, MAN, WAN
Internet
O cliente socket precisa conhecer o endereo IP, a porta e o protocolo do servidor socket.
IPC com socket UDP:
No garante a ordem das mensagens enviadas;
possvel a perda de mensagens;
Extremamente leve;
Exemplos: ICQ (conexo entre clientes e servidor pela porta 4000), jogos em rede
(Quake, Half Life, etc.).
IPC com socket TCP:
Comunicao confivel com ordenao garantida;
Exemplos: ICQ (conexo entre clientes), HTTP (porta 80), FTP (porta 21).
2.6.4. Chamada de Procedimento Remoto - Remote Procedure Call - RPC
Tecnologia desenvolvida pela Sun Microsystems para suportar a comunicao cliente-
servidor utilizada no software Network File System (NFS).
Permite a execuo de funes remotas como se fossem funes locais.
Cliente Portmapper
Servidor
1. Se registra,
passando
nome
e porta
2. Envia
nome
Stub
4. Requisio/Resposta
3. Recebe
porta
25
Os programas servidores RPC devem se registrar no servio de mapeamento de portas
(portmapper).
O servio de mapeamento de portas (portmapper) responsvel por informar aos
programas clientes o nmero das portas utilizadas pelos programas servidores.
No Windows: servio Chamada de Procedimento Remoto ou Remote Procedure
Call;
No Unix/Linux: servio rpcbind.
O stub, programa gerado pelo compilador RPC, responsvel pela comunicao de baixo
nvel entre o processo cliente e os processos portmapper e servidor.
RPC utiliza socket UDP ou TCP para estabelecer a comunicao entre cliente, servidor e
portmapper.
No Windows possvel ainda utilizar o recurso Named Pipes com o protocolo SMB.
Os programas cliente e servidor podem ser escritos em diferentes linguagens de
programao e executar em diferentes plataformas de hardware e software.
Existem duas implementaes disponveis:
Sun RPC ou Open Network Computing (ONC) RPC, utilizado na maioria das
plataformas Unix/Linux;
Distributed Computing Environment (DCE) RPC, utilizado em algumas plataformas
Unix e no Windows.
Com o intensificao da programao orientada a objetos, novas tecnologias foram criadas para
suportar a comunicao entre objetos distribudos, tais como CORBA, DCOM e RMI.
2.6.5. Common Object Request Broker Architecture - CORBA
CORBA uma tecnologia de objetos distribudos baseada em um Object Request Broker
(ORB). ORB o software que gerencia toda a comunicao entre clientes e objetos.
Cliente
Stub
Objeto
Skel
ORB ORB
Objeto
Skel
IIOP
26
A especificao da tecnologia CORBA mantida pelo Object Management Group
(OMG), consrcio formado por diversas organizaes de tecnologia da informao.
As implementaes de CORBA utilizam socket ou RPC para estabelecer a comunicao
entre clientes, ORBs e objetos.
possvel a comunicao entre ORBs atravs do protocolo Internet Inter-ORB Protocol
(IIOP).
Os programas cliente, ORB e objeto podem ser escritos em diferentes linguagens de
programao e executar em diferentes plataformas de hardware e software.
Existem diversos servidores de aplicao baseados na tecnologia CORBA: Borland
Visibroker, BEA Tuxedo, etc....
2.6.6. Distributed Component Object Model - DCOM
Component Object Model (COM) uma tecnologia da Microsoft utilizada para o
desenvolvimento de objetos reutilizveis. Distributed COM (DCOM) uma extenso desta
tecnologia que permite a interao entre objetos distribudos.
O cliente pode acessar um objeto DCOM de trs formas:
In-process Object: no mesmo processo;
Local Object Proxy: no mesmo computador;
Remote Object Proxy: em outro computador.
Cliente
In-process
Object
Local
Object
Remote
Object
RPC
RPC
DCOM utiliza RPC para estabelecer a comunicao entre clientes e objetos.
Os programas cliente e objeto podem ser escritos em diferentes linguagens de programao
para a plataforma Windows (C++, MS Visual Basic, Borland Delphi, etc...).
Existem os seguintes servidores de aplicao baseados na tecnologia DCOM:
No Windows NT: Microsoft Transaction Server (MTS);
No Windows 2000 e superior: COM+.
27
2.6.7. Remote Method Invocation - RMI
RMI uma tecnologia desenvolvida pela Sun Microsystems para suportar a implementao
de objetos distribudos em Java.
Objeto
Cliente
RMI Registry
1. Se registra,
passando
nome e Stub
2. Envia nome (porta 1099)
Stub
4. Invoca
Stub
3. Recebe Stub
O RMI Registry responsvel por manter os stubs dos objetos nele registrados e envi-los
para os clientes quando requisitado.
O stub, programa gerado pelo compilador RMI, responsvel pela comunicao de baixo
nvel entre cliente e objeto remoto.
A tecnologia RMI utiliza socket e o protocolo Java Remote Method Protocol (JRMP) para
estabelecer a comunicao entre clientes, RMI Registry e objetos.
Os programas cliente e objeto devem ser escritos na linguagem Java, podendo executar em
diferentes plataformas de hardware e software.
RMI a base da tecnologia de objetos distribudos Enterprise Java Beans (EJB), utilizada
em servidores Java EE (Ex.: JBoss, IBM WebSphere, BEA WebLogic, etc.).
2.6.8. Message Oriented Middleware - MOM
MOM um software que permite a comunicao assncrona entre processos cliente e
servidor.
Cliente
MOM - Message Broker
Servidor
1. Coloca
mensagem
na fila
2. Obtm
mensagem na
fila e processa
3. Coloca
resultado
na fila
4. Obtm
resultado
na fila
28
Exemplos:
MS Message Queue;
IBM WebSphere MQ;
JBoss MQ.
2.6.9. Tecnologias X Tipos de servidores de aplicao
Serv. Aplic.
Mensagens
Serv. Aplic.
TP Monitor
Serv. Aplic.
Objetos Dist.
Socket X X X
(tecn. apoio)
RPC X X
(tecn. apoio)
CORBA X
DCOM X
RMI/EJB X
29
3. Unidade II Tecnologia Java EE
3.1. Objetivos
Definir e identificar as caractersticas da plataforma Java EE:
Componentes
Contineres
Definir, caracterizar e citar aplicaes da tecnologia XML
Identificar e caracterizar as principais tecnologias utilizadas na construo de aplicaes
Java EE:
Web (Servlet/JSP)
JNDI
JDBC
EJB
Segurana
3.2. Viso geral da plataforma Java EE
3.2.1. Tecnologia Java
A tecnologia Java formada pela:
Linguagem de programao Java;
Plataforma Java.
3.2.1.1. Linguagem de programao Java
Caractersticas:
Orientada a objetos;
Interpretada: a Java Virtual Machine (JVM) responsvel por interpretar o bytecode
gerado pelo compilador;
Portvel: qualquer computador que tenha uma JVM, independente da plataforma de
hardware e do sistema operacional, pode executar um programa Java.
30
Na prtica:
Programa Java (cdigo fonte): arquivo *.java
Compilador: javac
Bytecode (programa Java compilado): arquivo *.class
Interpretador: java
3.2.1.2. Plataforma Java
Uma plataforma consiste em uma estrutura de suporte (framework) sobre a qual um software
pode ser desenvolvido e executado. Exemplos: hardwares, sistemas operacionais e mquinas virtuais.
Os componentes da plataforma Java so:
Java Virtual Machine (JVM)
Java Application Programming Interface (API Java): coleo de classes prontas e
agrupadas em pacotes que prov inmeras funcionalidades para o desenvolvimento de
softwares
Existem 04 plataformas Java especializadas para atender a diferentes necessidades:
Java Platform, Standard Edition (Java SE): para o desenvolvimento de aplicaes desktop;
31
Java Platform, Enterprise Edition (Java EE): para o desenvolvimento de aplicaes
corporativas multi-camadas com suporte a objetos distribudos (construda sobre a
plataforma Java SE);
Java Platform, Micro Edition (Java ME): para o desenvolvimento de aplicaes utilizadas
em dispositivos eletrnicos portteis e embarcados, tais como telefones celulares, PDAs,
TVs, etc.;
Java Card Platform: para o desenvolvimento de aplicaes utilizadas em smart cards,
cartes SIM e outros dispositivos com capacidade limitada de memria e processamento.
JVM
Java SE
Java EE
JVM
Java ME
JVM
Java Card
A especificao da tecnologia Java mantida pela Sun Microsystems (http://java.sun.com).
As maiores empresas de software do mundo licenciaram a tecnologia Java para o
desenvolvimento de servidores e ferramentas, entre elas IBM, Oracle, BEA e Microsoft.
3.2.2. Java Platform, Enterprise Edition Java EE
A plataforma Java EE utiliza um modelo de arquitetura cliente-servidor multi-camadas baseado
em componentes e com suporte a objetos distribudos para a construo de aplicaes corporativas.
A figura a seguir mostra dois exemplos de aplicaes Java EE:
32
Em cada camada (em ingls, tier) so utilizados Componentes Java EE com papis
especficos.
Os Componentes Java EE da camada cliente (responsveis pela apresentao dos dados) so:
Clientes de aplicao (no-web);
Applets (web).
Os Componentes Java EE da camada web (responsveis pelo processamento de requisies
HTTP e gerao de contedo HTML, WML, etc...) so:
Servlets;
Java Server Pages (JSPs).
Os Componentes Java EE da camada de negcio (responsveis pelas regras de negcio) so:
Enterprise JavaBeans (EJBs).
3.2.3. Contineres Java EE
Na plataforma Java EE, continer um software que gerencia os componentes de cada camada
e disponibiliza os servios de suporte da plataforma.
Existem 04 tipos de contineres:
O continer web e o continer EJB executam dentro do servidor Java EE;
O continer cliente de aplicao e o continer applet executam no computador do cliente.
33
Continer Gerencia Executa no Servios
Web Servlets e JSPs Servidor Concorrncia
Transao
Segurana
Persistncia
EJB EJBs Servidor Concorrncia
Transao
Segurana
Conectividade
Remota
Persistncia
Cliente de
Aplicao
Clientes de
Aplicao
Cliente Transao
Segurana
Applet Applets Cliente Segurana
3.2.4. APIs Java EE
3.2.5. Papis e responsabilidades na plataforma Java EE
A plataforma Java EE considera a existncia de 5 (cinco) diferentes papis no processo de
desenvolvimento, instalao e administrao de uma aplicao:
34
Fornecedor de produtos Java EE
Empresa que fornece servidores e APIs obedecendo especificao Java EE (servidores de
aplicao, servidores de fila de mensagem, drivers de bancos de dados, etc.).
Ex.: Sun, IBM, BEA, Oracle, JBoss, Borland, etc.
Fornecedor de ferramentas
Empresa ou profissional que fornece ferramentas de desenvolvimento, montagem e
empacotamento de aplicaes.
Ex.: Sun, IBM, Oracle, JBoss, Borland, etc.
Fornecedor de componentes de aplicao
Empresa ou profissional que desenvolve (utilizando ferramentas) e fornece componentes
(Servlets, JSPs, EJBs e Clientes de Aplicao) para uso em aplicaes Java EE
Montador de aplicao
Empresa ou profissional que monta aplicaes Java EE (manualmente ou utilizando
ferramentas) a partir de componentes disponibilizados.
Administrador e instalador de aplicaes
Empresa ou profissional que configura, instala aplicaes Java EE e administra a infra-estrutura
de hardware, software e rede onde as aplicaes executam.
3.3. Introduo a XML
3.3.1. O que XML?
XML significa EXtensible Markup Language (Linguagem de Marcao Extensvel).
Assim como HTML, a linguagem XML foi desenvolvida pelo World Wide Web Consortium
(W3C) e se tornou o padro para troca de dados pela Internet.
Uma linguagem de marcao caracterizada pela existncia de tags (de incio e fim) para
definio de elementos. So exemplos de linguagens de marcao: HTML, XML, WML.
Exemplo de um documento HTML:
<html><body>
<b>Tabela</b>
35
<table>
<tr><td>Coluna 1</td><td>Coluna 2</td></tr>
</table>
</body></html>
Exemplo de um documento XML:
<mensagem>
<para>voce@gmail.com</para>
<de>eu@gmail.com</de>
<assunto>XML</assunto>
<texto>Para que serve XML ?</texto>
</mensagem>
3.3.2. XML x HTML
XML no substitui HTML. So tecnologias diferentes.
HTML foi projetado para exibir os dados, focando em como eles devem ser apresentados e
utilizando tags predefinidas (body, table, td, etc...).
XML foi projetado para armazenar e descrever os dados, devendo o usurio criar suas prprias
tags (por isso ela extensvel).
Em HTML a seqncia <B>Banco Xxx</B> indica que o dado (Banco Xxx) deve ser
exibido em negrito. Em XML esta mesma seqncia poderia servir para armazenar o nome do banco
do qual uma pessoa cliente.
3.3.3. Elementos, tags, dados e atributos
Elemento um dado delimitado por tags. Tags so as marcaes de incio e fim de um
elemento. Dado o contedo de um elemento. Exemplo:
Elemento: <para>voce@gmail.com</para>
Tag de incio: <para>
Tag de fim: </para>
Dado: voce@gmail.com
Elementos podem ser aninhados, ou seja, um elemento pode conter outros elementos. A
possibilidade de aninhar elementos permite armazenar estruturas de dados hierrquicas em
XML.
36
Tags vazias podem ser representadas de duas formas:
<prioridade_alta></ prioridade_alta>
<prioridade_alta/>
Atributos so informaes adicionais includas em uma tag. Exemplo:
<mensagem para=voce@gmail.com de=eu@gmail.com assunto=XML>
<texto>Para que server XML ?</texto>
</mensagem >
3.3.4. Arquivo XML
Um arquivo XML tem sempre a seguinte estrutura:
Prolog, no incio do arquivo:
<?xml version="1.0"?>
Documento XML, logo em seguida:
<mensagem>
...
</mensagem>
O Prolog pode conter a definio do padro de caracteres utilizado no documento XML:
<?xml version="1.0 encoding=UTF-8?>
<?xml version="1.0 encoding=ISO-8859-1?>
Um arquivo XML no pode ter mais de um elemento raiz. A arquivo XML abaixo est
invlido pois tem dois elementos raiz (mensagem e anexo):
<?xml version="1.0"?>
<mensagem>
...
</mensagem>
<anexo>
...
</anexo>
37
3.3.5. Regras em documentos XML
possvel definir regras estruturais para um documento XML, tais como:
Elementos vlidos;
Quantidade de repeties de um elemento;
Um elemento no pode ter contedo (dado);
Tipos de dado (numrico, data, etc.).
Essas regras podem ser definidas utilizando-se:
Document Type Definition (DTD);
Schema.
3.3.6. Document Type Definition - DTD
O elemento DOCTYPE utilizado para especificar a DTD de um arquivo XML. A DTD pode
estar localizada:
Aps o Prolog:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE aluno [
<!ELEMENT aluno (matricula,nome,curso+,desconto?)>
<!ELEMENT matricula (#PCDATA)>
<!ELEMENT nome (#PCDATA)>
<!ELEMENT curso (#PCDATA)>
<!ELEMENT desconto (#PCDATA)>
]>
<aluno>
...
</aluno>
Em um arquivo externo:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE aluno SYSTEM "file:aluno.dtd">
<aluno>
...
</aluno>
38
Em uma URL externa:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE aluno SYSTEM "http://www.universo.edu.br/aluno.dtd">
<aluno>
...
</aluno>
Segue a tabela de qualificadores que definem a repetio de elementos:
Qualificador Significado
? Opcional (zero ou uma vez)
* Zero ou mais vezes
+ Uma ou mais vezes
3.3.7. Uso do XML em aplicaes
XML no faz nada sozinho. Um documento XML apenas um conjunto de elementos, tags e
dados. necessrio algum software para enviar, receber, exibir ou processar este documento.
Para que mltiplas aplicaes utilizem o mesmo documento XML, elas devem ter o mesmo
entendimento de como esse documento est estruturado, ou seja, elas devem conhecer os nomes e a
hierarquia dos elementos.
XML pode ser utilizado para:
Troca de dados
EDI;
Sistema de Pagamentos Brasileiro (SPB);
Single Object Access Protocol (SOAP) utilizado em Web Services.
Apresentao de dados
O mesmo documento XML pode ser exibido em diferentes dispositivos e diferentes
formatos (HTML, WML, PDF, etc.) utilizando-se XSL e XSLT.
Armazenamento de dados (banco de dados)
Tamino da Software AG.
3.4. Aplicaes e mdulos Java EE
3.4.1. Estrutura de uma aplicao Java EE
Uma aplicao Java EE consiste de um arquivo com extenso .ear (Enterprise ARchive) e
formato zip.
39
Arquivo EAR no Windows Explorer
Contedo de um arquivo EAR exibido pelo WinRAR
Deployment descriptor (application.xml) dentro da pasta META-INF
Dentro desse arquivo existem:
Mdulos Java EE (EJB, web e/ou cliente de aplicao);
Deployment descriptor (opcional): arquivo application.xml utilizado para definir
parmetros de configurao da aplicao.
Mdulo Cliente
de Aplicao
Mdulo Web Mdulo EJB
Mdulo Cliente
de Aplicao
(arquivo JAR)
Mdulo Web
(arquivo WAR)
Mdulo EJB
(arquivo JAR)
Aplicao Java EE (arquivo EAR)
application.xml
EJB
ejb-jar.xml
EJB Servlet
web.xml
JSP Java
application-client.xml
Java
40
A estrutura de uma aplicao Java EE pode ser vista na figura a seguir:
DD Java EE (application.xml)
DD de Runtime especfico
do servidor
Raiz
Um mdulo EJB consiste de um arquivo com extenso .jar (Java ARchive) e formato zip que
contm:
Um ou mais EJBs;
Deployment descriptor (opcional): arquivo ejb-jar.xml utilizado para definir parmetros de
configurao dos EJBs.
Um mdulo web consiste de um arquivo com extenso .war (Web ARchive) e formato zip que
contm:
Um ou mais Servlets, JSPs, arquivos HTML, imagens (GIF, JPG, etc...);
Deployment descriptor: arquivo web.xml utilizado para definir parmetros de configurao
das Servlets e JSPs.
Um mdulo cliente de aplicao consiste de um arquivo com extenso .jar (Java ARchive) e
formato zip que contm:
Uma ou mais classes Java
Deployment descriptor (opcional): arquivo application-client.xml utilizado para definir
parmetros de configurao dos clientes de aplicao
Existe ainda um quarto tipo de mdulo denominado mdulo adaptador de recurso. um
arquivo com extenso .rar (Resource adapter ARchive) e formato zip que contm classes Java e outros
programas necessrios para permitir a conexo de uma aplicao Java a um recurso externo ao
servidor Java EE, tais como softwares ERP, mainframes, etc..
41
3.4.2. Montagem de aplicaes e mdulos Java EE
A montagem de aplicaes e mdulos Java EE pode ser feita:
Manualmente, utilizando-se utilitrio de compactao (WinZip, WinRAR, etc.);
Utilizando-se ferramentas de desenvolvimento;
Utilizando-se o utilitrio Ant (http://ant.apache.org).
3.4.3. Instalao de aplicaes e mdulos Java EE
Os servidores Java EE permitem a instalao (ou deploy) de:
Aplicaes Java EE (arquivos EAR) ;
Mdulos Java EE (arquivos WAR ou JAR).
A instalao pode ser feita utilizando-se:
A console de administrao do servidor Java EE;
O recurso hotdeploy ou autodeploy do servidor Java EE: instalao ou reinstalao
automtica dos arquivos EAR, WAR e JAR colocados em um diretrio especfico;
Um utilitrio de administrao de linha de comando disponibilizado juntamente como o
servidor Java EE.
3.5. Componentes web da plataforma Java EE
3.5.1. HTTP e aplicaes web
HTTP significa HyperText Transfer Protocol. Assim como o HTML e o XML, a especificao
do HTTP mantida pelo World Wide Web Consortium (W3C - www.w3c.org).
HTTP o protocolo utilizado na Web para transferir recursos entre servidores e clientes. Um
recurso identificado por uma Unified Resource Location (URL) e pode ser:
Esttico: arquivos, como documentos (HTML, XML, pdf, txt, doc, etc..) e imagens (jpg,
gif, etc...);
Dinmico: programas CGI, ISAPI, NSAPI, scripts (PHP, ASP, etc.), Servlets/JSPs, etc..
O protocolo HTTP baseado no modelo cliente-servidor:
Um cliente HTTP abre uma conexo com um servidor HTTP e envia uma requisio
(request) solicitando um recurso;
O servidor HTTP devolve uma resposta (response) contendo o recurso solicitado;
42
O servidor HTTP fecha a conexo logo em seguida.
Como a conexo no mantida, diz-se que protocolo HTTP um protocolo sem estado
(stateless), ou seja, nele no existe o conceito de sesso.
Sesso algo essencial em aplicaes web. Ex.: carrinho de compras em lojas virtuais. Existem
trs formas de se implementar o controle de sesso em aplicaes Web:
Cookies: seqncia de caracteres que um servidor HTTP pode enviar para um browser. O
cookie armazenado na mquina do cliente e sempre enviado de volta para o servidor a
cada requisio (at a sua expirao). Um cookie pode armazenar dados do usurio ou
apenas o identificador da sesso do usurio. Neste ltimo caso, os dados ficam efetivamente
guardados no servidor.
URL Rewriting: incluso do identificador da sesso do usurio no final de cada URL
enviada para o browser.
http://www.example.com/phpBB/viewtopic.php?PHPSESSID=981e93a9a
http://www.example.com/jspBB/viewtopic.jsp;jsessionid=DA32242SSGE2
Campos ocultos em formulrios HTML: os dados que precisam ser preservados entre cada
requisio so salvos em campos ocultos de formulrios HTML.
<INPUT type=hidden name=cpf value=0034567819>
3.5.2. Componentes web Java EE
Os componentes web da plataforma Java EE so:
Servlets;
Java Server Pages (JSPs).
Servlets e JSPs so componentes Java EE gerenciados pelo continer web e utilizados para
processar requisies e gerar respostas HTTP contendo pginas HTML, WML, documentos XML,
PDF, etc..
43
Servlet uma classe Java, ou seja, consiste de um arquivo .java (contendo o cdigo fonte) e um
arquivo .class correspondente.
JSP um arquivo texto com extenso .jsp que contm cdigo em linguagem de marcao (ex.:
HTML, WML, XML) juntamente com cdigo Java e outros elementos. Quando uma JSP acessada
pela primeira vez por um cliente ela transformada em uma Servlet e compilada logo em seguida pelo
continer web.
Exemplo de Servlet gerando uma pgina HTML:
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class HelloServlet extends HttpServlet {
public void doGet (HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
PrintWriter out = response.getWriter();
out.println(<HTML>");
out.println("Hello + request.getParameter(name));
out.println(</HTML>");
out.close();
}
}
44
Para a requisio:
http://..../HelloServlet?name=Universo
Teremos a seguinte resposta:
Hello Universo
Exemplo de JSP gerando a mesma pgina HTML:
<HTML>
Hello <%=request.getParameter(name)%>
</HTML>
3.5.3. Cenrios de aplicaes Java EE com componentes web
As Servlets so mais indicadas para processar requisies HTTP, acessando bancos de dados e
EJBs. As JSPs so mais indicadas para gerar respostas HTTP (HTML, WML e XML).
Aplicaes Java EE com componentes web podem utilizar um dos seguintes cenrios ou
combinaes deles:
Web
Cliente
SGBD
JSP
Web
Cliente
SGBD
Servlet
Web
Cliente
SGBD
JSP
Servlet
EJB
EJB
EJB
3.5.4. Estrutura de um mdulo web
Os componentes web so empacotados em mdulos web (arquivos .war) juntamente com
recursos estticos como pginas HTML, imagens (gif, jpeg, etc.) e bibliotecas javascript (arquivos .js).
45
As applets, apesar de serem componentes cliente Java EE (no so componentes web),
tambm so empacotadas em mdulos web.
3.5.5. Contexto de um mdulo web
O contexto de um mdulo web um diretrio virtual a partir do qual podem ser acessados os
recursos disponveis dentro desse mdulo web. Exemplos:
http://universo/banco/login.jsp
http://universo/loja/index.html
O contexto definido da seguinte forma:
Quando o mdulo web faz parte de uma aplicao Java EE, o seu contexto definido no
deployment descriptor da aplicao (arquivo application.xml).
...
<module>
<web>
<web-uri>hellomod.war</web-uri>
<context-root>/helloapp</context-root>
</web>
</module>
...
46
Quando o mdulo web independente (no faz parte de uma aplicao Java EE), o seu
contexto pode ser definido de duas formas:
No DD de runtime (especfico do servidor de aplicao);
Pelo nome do arquivo do mdulo web (sem a extenso war).
Ex: Nome do arquivo do mdulo web: hellomod.war
Nome do contexto web: hellomod
3.5.6. Acessando componentes web
No DD Java EE de um mdulo web (arquivo web.xml) so definidos os nomes de seus
componente web (Servlets e JSPs).
A URL de uma Servlet ou JSP tem o seguinte formato:
http://servidor[:porta]/contexto/(url-pattern definido no DD)
Exemplo com Servlet
Servidor: universo
Porta: 80
Contexto Web: internetredes
DD Java EE (web.xml):
<servlet>
<display-name>HelloServlet</display-name>
<servlet-name>HelloServlet</servlet-name>
<servlet-class>test.HelloServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>HelloServlet </servlet-name>
<url-pattern>/hello1</url-pattern>
</servlet-mapping>
URL= http://universo/internetredes/hello1
Exemplo com JSP:
Servidor: universo
Porta: 8080
Contexto Web: internetredes
47
DD Java EE (web.xml):
<servlet>
<display-name>HelloJSP</display-name>
<servlet-name>HelloJSP</servlet-name>
<jsp-file>hello.jsp</jsp-file>
</servlet>
<servlet-mapping>
<servlet-name>HelloJSP</servlet-name>
<url-pattern>/hello2</url-pattern>
</servlet-mapping>
URL = http://universo:8080/internetredes/hello2
O continer web automaticamente faz o mapeamento das JSPs de um mdulo web, no sendo
obrigatrio fazer o mapeamento no DD Java EE (arquivo web.xml). Neste caso a URL de uma JSP
fica com o seguinte formato:
http://servidor[:porta]/contexto/(caminho + nome do arquivo)
Exemplos:
http://universo/banco/menu.jsp
http://universo:8080/banco/transferencia/tipotransf.jsp
3.6. Conceitos de JNDI
3.6.1. Servios de nomenclatura e diretrio
Um servio de nomenclatura (naming service) tem o objetivo de mapear objetos, permitindo
localiz-los a partir do seu nome. Exemplos:
Domain Name Service (DNS): permite identificar o endereo IP de um computador a partir
do seu nome;
Sistema de arquivos (FAT, NTFS, ext2): permite localizar um arquivo a partir do seu nome;
RMI Registry: permite localizar um objeto Java remoto a partir do seu nome.
Um servio de diretrio (directory service) tambm tem o objetivo de mapear objetos. Mas
alm disso, considera que tais objetos tm atributos, permitindo localizar um objeto a partir do seu
48
nome, obter a relao de atributos de um objeto e localizar objetos a partir de seus atributos.
Exemplos:
Active Directory da Microsoft;
Novell Directory Service (NDS) da Novell.
Os servidores Java EE disponibilizam um servio de nomenclatura para mapear objetos tais
como:
Fontes de dados JDBC (para conexo com SGBDs);
Enterprise JavaBeans (EJBs).
Servidor Java EE
Continer Web
Continer EJB
Nomenclatura
3.6.2. Servios de nomenclatura e diretrio
JNDI uma API disponvel nas plataformas Java SE e Java EE que permite a uma aplicao
Java acessar uma enorme variedade de servios de nomenclatura e diretrio, tais como:
Servios de nomenclatura de servidores Java EE;
DNS;
Novell Directory Service (NDS);
Active Directory da Microsoft (protocolo LDAP);
49
RMI Registry;
Servios de nomenclatura CORBA.
Atravs da API JNDI uma aplicao desenvolvida em Java pode permitir que o usurio efetue
login (usurio e senha) utilizando a sua conta de rede, j cadastrada em um servidor Active Directory
por exemplo, evitando a necessidade de se criar e administrar um controle de acesso para essa
aplicao.
3.7. Conceitos de JDBC, pools de conexes e fontes de dados
3.7.1. Java Database Connectivity - JDBC
JDBC uma API disponvel nas plataformas Java SE e Java EE que permite a uma aplicao
Java:
Abrir uma conexo com SGBDs
Enviar comandos SQL
Processar o resultado de comandos SQL
Cada SGBD (IBM DB2, Interbase, Oracle, MS SQL Server, MySQL, etc...) disponibiliza um
driver compatvel com a API JDBC.
3.7.2. Pools de conexes (connection pools)
Abrir uma conexo com um SGBD uma operao custosa em termos de performance (pode
levar mais de 1 segundo) .
50
Um pool de conexes um conjunto de conexes com um SGBD que so mantidas abertas
para serem reutilizadas por uma ou mais aplicaes a qualquer momento, aumentando a escalabilidade
de um sistema.
Quando a conexo fechada pela aplicao, na verdade ela devolvida para o pool, podendo
ser reutilizada logo em seguida.
Os servidores Java EE disponibilizam um servio de pool de conexes.
Servidor Java EE
Continer Web
Continer EJB
Nomenclatura
Pool de Conexes
No modelo de arquitetura C-S de 02 camadas, cada cliente abre uma conexo com o SGBD
(100 clientes = 100 conexes). No modelo de arquitetura C-S de 03 camadas possvel atender
mesma quantidade de clientes com uma quantidade bem menor de conexes, graas ao pool de
conexes.
3.7.3. Fontes de dados JDBC (data sources)
Para abrir uma conexo com um SGBD, uma aplicao Java pode utilizar dois tipos de objetos
disponibilizados pela API JDBC:
Objeto DriverManager;
Objeto DataSource (fonte de dados).
Em aplicaes Java EE utiliza-se objetos DataSource para se obter uma conexo disponvel em
um pool de conexes. A aplicao deve conhecer o nome utilizado para registrar o objeto DataSource
dentro do servio de nomenclatura do servidor Java EE.
51
JDBC
JNDI
Pool de Conexes
1. Obtm
DataSource
(DS)
2. Obtm
Conexo
Cliente
SGBD
DS
Abre
Conexes
3. Envia
Comandos
SQL
Nomenclatura
Servidor Java EE
DS jdbc/DS1
(Pool SGBD1)
Pool SGBD1
DS jdbc/DS2
(Pool SGBD2)
Pool SGBD2
SGBD
Exemplo de cdigo Java utilizando a API JNDI para obter uma conexo da fonte de dados
jdbc/Bank e enviando um comando SQL utilizando a API JDBC:
...
InitialContext initialContext = new InitialContext();
Context envContext = (Context) initialContext.lookup("java:comp/env");
// Obtm fonte de dados no servio de nomenclatura
DataSource dataSource = (DataSource) envContext.lookup("jdbc/Bank");
// Obtm conexo
Connection conn = dataSource.getConnection();
// Executa comando SQL
Statement stmt = conn.createStatement();
ResultSet srs = stmt.executeQuery("SELECT ALUNO_NM FROM ALUNOS");
...
52
3.8. Componentes de negcio da plataforma Java EE
3.8.1. Enterprise JavaBeans - EJBs
EJBs so componentes da plataforma Java EE gerenciados pelo continer EJB e utilizados para
executar as regras de negcio de aplicaes corporativas.
Por exemplo, numa aplicao bancria utilizando a plataforma Java EE, um EJB pode
disponibilizar os mtodos efetuarSaqueContaCorrente e efetuarTransferencia. Esses mtodos podem
ser invocados por diversos clientes, tais como componentes web (Servlet ou JSP), um cliente de
aplicao ou at mesmo uma aplicao no-Java EE, conforme ilustrado na figura a seguir.
Servidor Java EE
Cliente de
Aplicao
Browser
SGBD
Aplicao
No-Java EE
Web
EJB
3.8.2. Tipos de EJBs
Existem 2 tipos de EJBs:
Session beans;
Message-driven beans.
53
EJB
Session
Beans
Message-Driven
Beans
Stateful
Stateless
Um session bean (SB) representa uma sesso de interao de um cliente com o continer EJB
de um servidor Java EE, disponibilizando mtodos para execuo das regras de negcio.
Existem dois tipos de SBs:
Stateless session beans: o estado do session bean (os valores de seus atributos) no mantido
entre invocaes de mtodos pelo cliente.
Stateful session beans: o estado do session bean (os valores de seus atributos) mantido entre
invocaes de mtodos pelo cliente.
O cliente de um SB pode ser um componente web (Servlet ou JSP), um outro EJB, um cliente
de aplicao ou uma aplicao no-Java EE.
EJB
Cliente
SGBD
SB
Um message-driven bean (MDB) permite que aplicaes Java EE processem mensagens
assincronamente utilizando a API Java Message Service (JMS).
Um MDB se conecta a um Message Oriented Middleware (MOM) atravs da API JMS e fica
monitorando as mensagens que chegam em uma determinada fila de mensagens.
As mensagens podem ser colocadas na fila por um componente Java EE (web, EJB ou cliente
de aplicao) ou qualquer outra aplicao no-Java EE.
54
EJB
MOM
SGBD
MDB
Cliente
3.8.3. Estrutura de um mdulo EJB
Componentes EJB so empacotados em mdulos EJB (arquivos .jar), juntamente com outras
classes Java auxiliares.
EJBs e outras
classes Java
DD Java EE
(ejb-jar .xml)
[opcional]
DD de Runtime
especfico do
servidor
[opcional]
Os arquivos DD (do Java EE e de runtime) so opcionais pois possvel configurar os
componentes EJB utilizando-se anotaes no prprio cdigo fonte.
3.8.4. Acessando session beans
Para que um session bean possa ser utilizado pelos clientes o continer EJB precisa registr-lo
no servio de nomenclatura do servidor Java EE.
O nome JNDI de um session bean pode ser definido de duas formas:
55
Utilizando anotaes no prprio cdigo fonte;
No DD de runtime, especfico de cada servidor.
Exemplo:
No DD Java EE (ejb-jar.xml):
...
<enterprise-beans>
<session>
<ejb-name>ConverterBean</ejb-name>
<ejb-class>converter.ConverterBean</ejb-class>
<session-type>Stateless</session-type>
</session>
</enterprise-beans>
...
No DD de runtime:
...
<ejb>
<ejb-name>ConverterBean</ejb-name>
<jndi-name>ejb/SimpleConverter</jndi-name>
</ejb>
...
Os clientes devem utilizar a API JNDI para obter o stub de um session bean no servio de
nomenclatura (semelhante ao RMI).
Servidor Java EE
JNDI
Continer EJB
SB
Nomenclatura
1. Registra
EJBs
2. Obtm
Stub do
SB
3. Invoca
mtodos do
SB
Cliente
Stub
Exemplo de cdigo Java acessando um EJB:
56
...
InitialContext initialContext = new InitialContext();
Context envContext = (Context) initialContext.lookup("java:comp/env");
// Obtm EJB no servio de nomenclatura
Object objref = envContext.lookup("ejb/SimpleConverter");
ConverterHome home = (ConverterHome) PortableRemoteObject.narrow(objref,
ConverterHome.class);
Converter currencyConverter = home.create();
// Invoca mtodo do EJB
BigDecimal param = new BigDecimal("100.00");
BigDecimal amount = currencyConverter.dollarToYen(param);
...
3.9. Segurana na Plataforma Java EE
3.9.1. Viso geral de segurana em Java EE
As funes de segurana em uma aplicao so:
Manuteno de contas de usurios: incluso, atualizao, excluso e bloqueio de usurios;
Autenticao: saber quem o usurio;
Autorizao: saber o que o usurio pode fazer.
Os contineres web e EJB disponibilizam o servio de segurana para os componentes Java EE,
sendo responsveis pelas funes de autenticao e autorizao. Os componentes desse servio so:
Realm (territrio ou domnio de segurana): conjunto de usurios e grupos que so
controlados por uma mesma poltica de autenticao.
Um realm pode estar fisicamente em: arquivo, banco de dados, servidor de diretrio LDAP
(Active Directory, NDS), etc..
Role (Papel): funo desempenhada por usurios ou grupos de usurios dentro de uma
aplicao. Ex.: vendedor, supervisor de vendas, gerente de vendas.
Cada Role est autorizado a acessar um conjunto de recursos dentro de uma aplicao.
57
Na plataforma Java EE as especificaes de segurana podem ser feitas:
Declarativamente
Atravs dos deployment descriptors, ou;
Utilizando anotaes no cdigo fonte (somente para EJBs).
Programaticamente: dentro do cdigo fonte da aplicao.
3.9.2. Autenticao e segurana de rede em mdulos web
O Continer Web suporta trs mtodos de autenticao de usurios:
BASIC: utiliza a tela de login padro do browser (pode utilizar segurana de rede com o
protocolo HTTPs);
FORM-BASED: permite customizar a tela de login com uma pgina HTML ou JSP (pode
utilizar segurana de rede com o protocolo HTTPs);
CLIENT-CERT: o cliente se autentica utilizando um certificado digital no padro X.509 e
obrigatoriamente o protocolo HTTPs.
O mtodo de autenticao e a segurana de rede em um mdulo web so definidos no seu DD
Java EE (arquivo web.xml).
Mtodo de autenticao (auth-method): BASIC, FORM ou CLIENT-CERT;
Segurana de rede com SSL (transport-guarantee): NONE (sem SSL), INTEGRAL (com
SSL) ou CONFIDENTIAL (com SSL)
...
<security-constraint>
...
<user-data-constraint>
58
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>file</realm-name>
</login-config>
...
3.9.3. Autorizao em mdulos web
Especificar as autorizaes em um mdulo web consiste em se criar colees de recursos
contendo JSPs, Servlets e/ou pginas HTML, e associ-las a um ou mais papis definidos na aplicao.
As autorizaes so definidas no DD Java EE (arquivo web.xml).
<security-constraint>
...
<web-resource-collection>
<web-resource-name>InternetBanking</web-resource-name>
<url-pattern>/index.html</url-pattern>
<url-pattern>/transferencia</url-pattern>
<url-pattern>/faleconosco.jsp</url-pattern>
...
</web-resource-collection>
<auth-constraint>
<role-name>bankCustomer</role-name>
</auth-constraint>
...
</security-constraint>
3.9.4. Autorizao em mdulos EJB
Especificar as autorizaes em um mdulo EJB consiste em se definir os papis autorizados a
invocar cada mtodo dos EJBs.
Isso pode ser feito de duas formas:
Utilizando anotaes diretamente no cdigo fonte dos EJBs;
Atravs do DD Java EE (arquivo ejb-jar.xml):
...
59
<method-permission>
<role-name>bankAdmin</role-name>
<method>
<ejb-name>AccountControllerBean</ejb-name>
...
<method-name>addCustomerToAccount</method-name>
</method>
</method-permission>
...
3.9.5. Responsabilidades pela segurana em Java EE
Equipe de desenvolvimento
Define o mtodo de autenticao a ser utilizado;
Define os papis (roles) existentes na aplicao;
Define os recursos (Servlets, JSPs, pginas HTML e EJBs) que cada papel pode acessar.
Equipe de administrao do servidor de aplicao
Define o realm a ser utilizado;
Se o realm utilizado for baseado em arquivos, mantm o cadastro de usurios e grupos;
Associa usurios e grupos cadastrados no realm aos papis definidos na aplicao.
Realm
Grupo A
U1 U2 U3
Grupo B
U4 U5 U6
Aplicao Java EE
Role ou Papel 1
Role ou Papel 2
Role ou Papel 3
Equipe de administrao do servidor de diretrio LDAP
Se o realm utilizado for baseado em um servidor de diretrio LDAP (Active Directory,
NDS, etc.), mantm o cadastro de usurios e grupos.
60
4. JBoss
4.1. Objetivo
Instalar e configurar o JBoss
Executar procedimentos de administrao do JBoss
4.2. Viso geral do JBoss
4.2.1. O mercado de servidores Java EE
O mercado de servidores Java EE se divide em dois grupos:
Servidores Java EE comerciais;
Servidores Java EE open source;
Os principais servidores Java EE comerciais so:
IBM WebSphere;
BEA WebLogic;
Oracle Application Server;
Sun Java System Application Server;
Borland Enterprise Server;
Macromedia Jrun.
Os principais servidores Java EE open source so:
JBoss (www.jboss.org);
Geronimo (geronimo. apache.org);
JOnAS (jonas.objectweb.org);
Resin (www.caucho.com).
4.2.2. Histrico do JBoss
O projeto JBoss (http://labs.jboss.com/portal/) teve incio em 1999. O nome original do projeto
era EJBoss (EJB Open Source Server). O objetivo era desenvolver um continer EJB com cdigo fonte
aberto (open source) e sem custos de licenciamento.
Em 2001 foi criado a empresa JBoss Group, formada por integrantes da equipe de
desenvolvimento, com o objetivo de prover servios profissionais de suporte tcnico aos usurios.
61
Em 2004 a empresa JBoss Group foi transformada em JBoss Inc. (www.jboss.com), que
alm de suporte tcnico, fornece servios profissionais de consultoria e treinamento.
Em 2006 a empresa Red Hat comprou a empresa JBoss.
A partir da verso 2.0 o JBoss se tornou um servidor Java EE completo, incorporando o
continer web Tomcat (tomcat.apache.org), tambm open source.
Hoje o JBoss est entre os quatro servidores Java EE mais utilizados em ambientes de produo
de TI, juntamente com IBM WebSphere, BEA WebLogic e Oracle Application Server.
4.2.3. Alguma caractersticas do JBoss
Nenhum custo de licenciamento;
Grandes empresas patrocinadoras e parceiras de tecnologia e servios, tais como CA, HP,
Novell e Unisys;
Servio profissional de suporte tcnico, inclusive 24 x 7, treinamento e consultoria, atravs
da empresa JBoss Inc. e dos parceiros.
4.3. O servidor JBoss
4.3.1. Download e instalao do JBoss
O download das releases disponveis do JBoss Application Server pode ser feito no site
http://labs.jboss.com/portal/jbossas/download.
Para cada release so disponibilizadas uma distribuio somente com os arquivos binrios (ex.:
jboss-4.0.2.zip) e outra com os arquivos fontes e binrios (ex.: jboss-4.0.2-src.tar.gz).
A instalao consiste em descompactar o arquivo zip em um diretrio (sem espaos em branco
no caminho). Exemplo:
No Windows: c:\
No Linux: /usr/local/
Antes de executar o JBoss necessrio:
Instalar o JDK 1.4 ou superior (no pode ser o JRE);
Definir a varivel de ambiente JAVA_HOME;
Incluir o diretrio JAVA_HOME/bin no PATH.
Alm do servidor JBoss, os seguintes softwares open source tambm esto includos no pacote:
Servidor de banco de dados Hypersonic;
62
Message-Oriented Middleware (MOM) JbossMQ.
4.3.2. Estrutura de diretrios do JBoss
bin: contm scripts (.bat e .sh) de inicializao, encerramento e administrao do servidor;
client: contm arquivos de configurao e bibliotecas de classes Java (arquivos JAR)
necessrios s aplicaes clientes que precisam utilizar os servios do servidor;
docs: contm DTDs e exemplos de arquivos XML de configurao do servidor;
lib: contm o kernel do JBoss e bibliotecas de classes Java (arquivos JAR) utilizadas pelo
kernel;
server: cada subdiretrio corresponde a uma configurao de servidor. Existem 3
configuraes pr-definidas (all, default e minimal), podendo ser criadas outras.
4.3.3. Configuraes de servidor
O JBoss utiliza uma arquitetura extremamente flexvel baseada na tecnologia JMX.
JMX (Java Management Extensions) uma tecnologia Java para gerenciamento e monitorao
de dispositivos, aplicaes e servios (hardware e software).
Todos os servios do JBoss (continer EJB, continer web, nomenclatura JNDI, segurana,
transao, etc..) so implementados como managed beans (MBeans).
Os MBeans so gerenciados pelo servidor MBean, o kernel do JBoss.
63
Aplicao de
Gerenciamento
JMX
JBoss
Continer EJB Continer Web Nomenclatura JNDI
Servidor MBean
MBean
MBean MBean
Esta arquitetura permite criar diversas configuraes de servidor e ativar em cada um delas
somente os servios necessrios s aplicaes em execuo.
possvel ainda ativar, desativar e reconfigurar qualquer um dos servios dinamicamente.
Existem 3 configuraes de servidor pr-definidas:
minimal: ativa o mnimo de servios necessrios ao funcionamento do JBoss. No ativa a
maioria dos servios Java EE (continer EJB, continer web, JMS, etc.).
default: ativa todos os servios Java EE.
all: ativa todos os servios, inclusive o suporte a cluster (alta disponibilidade, alta
escalabilidade e balanceamento de carga).
Essa a estrutura de diretrios de cada configurao:
Os diretrios data, log, tmp e work so criados quando se inicializa o JBoss pela primeira vez.
conf: contm o arquivo jboss-service.xml que especifica os servios que devem ser
ativados, alm de arquivos adicionais de configurao desses servios.
data: utilizado pelos servios que precisam armazenar dados no sistema de arquivos, como
o servidor de banco de dados Hypersonic e o servidor de fila de mensagens JBossMQ.
64
deploy: neste diretrio so colocados diversos tipos de arquivos para instalao no servidor,
tais como aplicaes (EAR, WAR e JAR), resource adapters JCA (RAR), servios hot-
deployable (SAR) como o Tomcat, arquivos de configurao de fontes de dados JDBC,
etc..
lib: contm bibliotecas de classes Java (arquivos JAR) especficos da configurao. Os
drivers JDBC dos bancos de dados devem ser colocados neste diretrio.
log: contm os arquivos do servio de log.
tmp: utilizado para armazenamento temporrio de aplicaes descompactadas (EAR, WAR
e JAR).
work: utilizado pelo Tomcat para compilar as JSPs.
4.3.4. O servio Tomcat
O Tomcat (tomcat.apache.org) um continer web Java EE com cdigo fonte aberto mantido
pela Fundao Apache (www.apache.org).
A partir da verso 4.0 do JBoss o Tomcat passou a ser distribudo como um servio hot-
deployable (diretrio server/[configuracao]/deploy/jbossweb-tomcat-5.0.sar). Para o JBoss o Tomcat
passou a ser mais um MBean (jboss.web:service=WebServer), possibilitando o seu gerenciamento a
partir das ferramentas de administrao do JBoss.
4.3.5. O servio de log
O servio de log do JBoss implementado com a API log4java do projeto Jakarta
(http://jakarta.apache.org/log4j/).
A configurao do servio feita no arquivo server/[configuracao]/conf/log4j.xml.
Na configurao padro do servio de log, o JBoss envia as mensagens de log tanto para a
console como para o arquivo server/[configuracao]/log/server.log.
possvel enviar as mensagens de log por e-mail, mensagens SNMP ou JMS, ou para a
SYSLOG do Linux.
Existem 04 nveis de log: DEBUG, INFO, WARN e ERROR. Exemplos:
...
65
2005-05-15 14:15:01,125 DEBUG [org.jboss.naming.JNDIView] Created
jboss:service=JNDIView
...
2005-05-15 14:35:05,843 INFO [EARDeployer] Undeploying J2EE application, destroy step:
file:/E:/jboss-4.0.1/server/default/deploy/opentier-manager_lite.ear
...
2005-05-15 14:35:05,890 WARN [org.jboss.deployment.DeploymentInfo] Could not delete
file:/E:/jboss-4.0.1/server/default/tmp/deploy/tmp2801opentier-manager_lite.ear restart will
delete it
...
2005-05-15 14:35:05,062 ERROR [com.epiuse.opentier.manager.logging. LogService]
Stopping failed opentier.manager.service:name=LogService
Na configurao padro, os logs de nvel DEBUG no so enviados para a console.
4.4. Administrao do JBoss
4.4.1. Ferramentas de administrao
As ferramentas disponibilizadas no pacote JBoss permitem administrar o servidor via:
Linha de comando;
Browser.
4.4.2. Administrao pela linha de comando
A administrao do JBoss pela linha de comando feita com a ferramenta twiddle (twiddle.bat
ou twiddle.sh) disponvel no diretrio bin.
O twiddle permite monitorar e administrar os MBeans registrados no servidor MBean do JBoss.
possvel administrar um servidor JBoss remoto utilizando a opo -s ou --server:
>twiddle.[bat ou sh] -s lab2-07 ...
>twiddle.[bat ou sh] --server lab2-07:1098 ...
4.4.3. Administrao pelo browser
As ferramentas de administrao do JBoss pelo browser esto disponveis em
http://localhost:8080.
Ao acessar esta URL exibida uma pgina HTML contendo os seguintes links:
66
Tomcat status: exibe informaes de status do Tomcat, o continer web do JBoss (threads,
bytes recebidos e enviados, sesses, etc..);
JMX Console: exibe a console de administrao. A console uma aplicao web (jmx-
console.war) que permite monitorar e administrar os MBeans registrados no servidor
MBean do JBoss.
Os MBeans so agrupados e ordenados pelo domnio a que pertencem. Exemplos
de domnios: Catalina, JMImplementation, jboss.server, jboss.web, etc...
JBoss Web Console: exibe a console de administrao avanada. uma aplicao web
(web-console.war) que alm das funcionalidades da Console JMX, exibe informaes
estatsticas, grficos e alertas de utilizao dos componentes Java EE (Servlets, JSPs e
EJBs).
67
Da mesma forma que na Console JMX, os MBeans so agrupados e ordenados
pelo domnio a que pertencem.
68
5. Infra-estrutura e alta disponibilidade
5.1. Objetivo
Definir e caracterizar um Cluster Java EE
Identificar os mecanismos de implementao de um Cluster Java EE
5.2. Cluster Java EE
5.2.1. Definio de cluster
Um cluster um conjunto de sistemas (hardware e software) que trabalham juntos para prover
servios aos usurios de maneira ininterrupta. Um cluster deve proporcionar:
Escalabilidade: capacidade de responder satisfatoriamente ao aumento do nmero de
usurios.
Alta disponibilidade: capacidade de continuar provendo servios transparentemente, aps a
falha de um dos servidores (redundncia).
Balanceamento de carga: capacidade de distribuir a carga de processamento entre os
servidores do cluster.
5.2.2. Cluster Java EE
Um cluster Java EE formado por um conjunto de sistemas (hardware e software) que utilizam
servidores Java EE configurados para proporcionar alta disponibilidade, alta escalabilidade e
balanceamento de carga para as aplicaes, tanto na camada web como na camada EJB.
Na camada web consegue-se isso de trs formas:
Balanceamento de carga entre servidores HTTP;
Balanceamento de carga entre contineres web de servidores Java EE;
Replicao das sesses web dos usurios.
O balanceamento de carga entre servidores HTTP pode ser feito de duas formas:
Hardware (Ex.: Cisco LocalDirector 410, F5 BigIP);
Software (Ex.: IBM Edge Server, Sun Access Manager).
69
Em cada servidor HTTP (web server) existe um plugin do servidor Java EE. Esse plugin
responsvel por encaminhar as requisies HTTP/HTTPs para o continer web. Quando se tem um
cluster de servidores Java EE, esse plugin tambm responsvel pelo balanceamento de carga entre os
contineres web dos diversos servidores do cluster.
Os dados da sesso web de cada usurio so mantidos pelo continer web no servidor Java EE.
A replicao das sesses web necessria para garantir a continuidade das operaes numa eventual
falha de um dos servidores.
70
A replicao pode ser feito pelo continer web de duas formas:
Em memria: cada servidor do cluster tem em memria uma rplica dos dados da sesso
dos demais servidores;
Em um banco de dados ou sistema de arquivos centralizado.
A utilizao de um dispositivo SAN (Storage Area Network) compartilhado por todos os
servidores Java EE e servidores de banco de dados garante a alta disponibilidade com relao ao
armazenamento.
SAN
Applications
and DB files
Database
Database