ganho em performance na utilizao de Servlets: ao invs de iniciar um novo processo a cada requisio recebida, um Servlet fica carregado em memria

e atende as requisies recebidas atravs de novos threads. Servlet pode tirar proveito dessa persistncia para manter tambm em memria recursos que demandem grande processamento para serem inicializados. Um exemplo tpico, para esse caso, a manuteno de conexes com banco de dados: ao invs de inicializar uma nova conexo com o banco de dados a cada requisio recebida, um Servlet pode inicializar diversas conexes ao ser carregado, e simplesmente alocar uma conexo desse pool a cada requisio recebida (e retornar a conexo ao pool aps o atendimento da requisio). possibilita uma maneira mais padronizada e portvel de se distribuir / implantar sua aplicao. Servlets podem ser instalados em qualquer ambiente onde haja um Servidor de Aplicaes que implemente a especificao de Servlets. Servlets so classes Java, desenvolvidas de acordo com uma estrutura bem definida, e que, quando instaladas junto a um Servidor que implemente um Servlet Container (um servidor que permita a execuo de Servlets, muitas vezes chamado de Servidor de Aplicaes Java), podem tratar requisies recebidas de clientes.

Ao receber uma requisio, um Servlet pode capturar parmetros desta requisio, efetuar qualquer processamento inerente a uma classe Java, e devolver uma pgina HTML por exemplo.

Exemplo de Servlet
As pginas JSP, ou Java Server Pages, foram criadas para contornar algumas das limitaes no desenvolvimento com Servlets: se em um Servlet a formatao da pgina HTML resultante do processamento de uma requisio se mistura com a lgica da aplicao em si, dificultando a alterao dessa formatao, em uma pgina JSP essa formatao se encontra separada da programao, podendo ser modificada sem afetar o restante da aplicao. Assim, um JSP consiste de uma pgina HTML com alguns elementos especiais, que conferem o carter dinmico da pgina. Esses elementos podem tanto realizar um processamento por si, como podem recuperar o resultado do processamento realizado em um Servlet, por exemplo, e apresentar esse contedo dinmico junto a pgina JSP. recurso adicional pginas JSP: a recompilao automtica, que permite que alteraes feitas no cdigo da pgina sejam automaticamente visveis em sua apresentao. Assim, no necessrio interromper o funcionamento da aplicao para incorporar uma modificao de layout, por exemplo. ambiente bsico: o Java Standard Development Kit (JSDK), utilizado para compilar aplicaes Java, e um Servlet Container, que ir executar os Servlets desenvolvidos. Apesar de existirem diversos servidores disponveis no mercado, para efeito dos exemplos apresentados neste livro, utilizaremos o Apache Tomcat, disponvel no site Esse servidor de aplicaes atende s especificaes mencionadas

Para entender um pouco mais a fundo o funcionamento do Tomcat, deve-se examinar os diretrios criados durante o processo de instalao. Os principais diretrios criados so: Conforme vimos anteriormente, existe um diretrio no Apache Tomcat chamado webapps onde devem ser instaladas as diversas aplicaes desenvolvidas por voc ou por terceiros.

Aplicao Web: Aplicao composta de Servlets + Pginas JSP + Bibliotecas e classes Java + imagens + pginas HTML e outros componentes estticos que podem ser empacotados juntos e instalados em qualquer Servlet Container.

Para uma determinada aplicao Web, a estrutura de diretrios mnima que deve ser criada abaixo do diretrio webapps a seguinte:

Conforme pode ser visto na figura anterior, deve ser criado, abaixo do diretrio , um diretrio com o nome da aplicao. Esse diretrio deve conter pelo menos um subdiretrio ; podem haver alm do subdiretrio , por outro lado, outros subdiretrios e arquivos, como pginas html, pginas JSP etc. O diretrio , por sua vez, deve conter um arquivo chamado web.xml e dois subdiretrios: classes, com todas as classes, e lib, com as bibliotecas utilizadas. Obviamente, abaixo do diretrio classes podem haver subdiretrios para refletir o path relacionado aos packages Java (mais informaes sobre packages podem ser obtidas em qualquer livro introdutrio sobre a linguagem Java). Utilizando como exemplo uma aplicao chamada , contendo o Servlet RemoteIPServlet do exemplo do captulo 1 desse livro, uma estrutura possvel abaixo do diretrio webapps seria a seguinte:

Figura 2.3 Exemplo de estrutura para aplica o RemoteIP . Obviamente, podem haver diversas aplicaes instaladas, gerando diversas rvores de diretrios abaixo do diretrio webapps:

Figura 2.4 Exemplo de algumas aplica es instaladas abaixo do diret rio webapps. Cada uma dessas aplicaes carregada pelo Servidor em um Servlet Context (Contexto do Servlet). Cada contexto d sua aplicao uma URL base, chamada de Context Path (Path do Contexto), e prov um ambiente comum para todos os Servlets da aplicao. O path do contexto serve para que o Servidor possa mapear e distribuir as requisies recebidas para as diversas aplicaes instaladas. No Apache Tomcat, o path do contexto coincide com o nome do subdiretrio criado abaixo do webapps.

Assim, no nosso exemplo, supondo que o endereo IP do servidor onde instalamos o Apache Tomcat , teremos os acessos s URLs iniciadas por direcionadas para a aplicao , os acessos s URLs iniciadas por direcionadas para a aplicao , e assim por diante.

Figura 2.5 Exemplo de mapeamento de requisi es para aplica es instaladas no Tomcat. Por fim, conforme o leitor pode ter reparado nos exemplos citados anteriormente, para cada aplicao h um Deployment Descriptor: trata-se de um arquivo, chamado web.xml e localizado abaixo do diretrio , e que contm informaes de configurao da aplicao, tais como, parmetros de inicializao, mapeamentos de Servlets, entre outros.
Deployment Descriptor: Arquivo XML com as informaes de configurao de uma Aplicao Web. Esse arquivo fica abaixo do diretrio WEB-INF e se chama web.xml.

Um possvel Deployment Descriptor para a aplicao RemoteIP, por exemplo, seria o seguinte:

Exemplo de Deployment Descriptor

Como o Deployment Descriptor composto de muitas sees, procuraremos apresentar as principais e suas respectivas funes, usando como exemplo a aplicao mencionada anteriormente. Uma apresentao mais detalhada e aprofundada desse arquivo pode ser encontrada na prpria especificao de Servlets. Pressupomos, para essa apresentao um conhecimento mnimo de XML; caso voc no tenha familiaridade com esse tipo de documento, sugerimos que voc tente acompanhar os exemplos, e os utilize como templates para criar seus prprios Deployment Descritors.

Estrutura geral do Deployment Descriptor

Assim, como em qualquer documento XML, inicialmente so colocados os elementos de declarao do XML e do tipo de documento (XML declaration e Document type declaration). Na figura anterior, esses elementos correspondem s 6 primeiras linhas listadas. Em seguida, vem o elemento : esse o elemento (raiz) desse XML, ou seja, deve haver somente um elemento , e abaixo dele devem ficar todos os outros elementos do XML. Os principais elementos abaixo do elemento , , , e so os seguintes: . , ,

O elemento deve conter um nome da aplicao a ser apresentado por ferramentas GUI de gerenciamento/desenvolvimento de Aplicaes Web. Esse elemento opcional, porm caso voc decida utiliz-lo, importante que haja somente um desses elementos por Deployment Descriptor.

Exemplo de utilizao do elemento display-name

O elemento context-param serve para que se possam definir parmetros de inicializao do contexto da aplicao; esses parmetros estaro disponveis para todos os Servlets e pginas JSP da aplicao. Cada elemento presente deve conter o nome de um parmetro e o seu valor correspondente. O desenvolvedor pode tambm optar por no utilizar nenhum desses elementos em seu XML.

Exemplo de utilizao do elemento context-param

O elemento seguinte, , serve para que se possa especificar o perodo mximo, em minutos, de uma sesso (esse recurso explicado mais adiante no livro, no captulo 6 Sesses). Assim como o elemento , esse elemento opcional, mas caso o desenvolvedor opte por utiliz-lo, deve existir somente uma instncia desse elemento no arquivo.

Exemplo de utilizao do elemento session-config

Os elementos e contm, respectivamente, a lista ordenada de pginas a serem utilizadas como index e as pginas a serem apresentadas em casos de erros HTTP ou excees no tratadas pela aplicao. Esses dois elementos so opcionais, sendo que somente o primeiro admite uma instncia por Deployment Descriptor.

Exemplo de utilizao dos elementos welcome-file-list e error-page

De acordo com o que apresentado na listagem anterior, se tomarmos como exemplo nossa aplicao , quando feito um acesso a URL , o Servidor tentar retornar a pgina index.html, conforme especificado na lista do . Caso essa pgina no exista, o Servidor tentar utilizar a pgina index.jsp. A figura anterior tambm demonstra a utilizao do elemento duas vezes: a primeira vez para mapear erros HTTP 404 (pgina no encontrada) a uma pgina de erro-padro, e a segunda, para mapear exceptions com.minhaempresa.exceptions. DBConnException a uma outra pgina de erro. Os ltimos dois elementos, e , servem para definir, respectivamente, os Servlets da aplicao, com seus respectivos parmetros, e os mapeamentos de URLs a cada Servlet da aplicao. Cada elemento , por sua vez, composto dos seguintes elementos: servlet-name: deve conter o nome do Servlet. servlet-class: deve conter o nome da classe (incluindo a informao sobre o package, se existir). init-param: deve conter um parmetro de inicializao do Servlet; pode haver nenhum, somente um, ou mais de um elemento deste tipo para cada Servlet. load-on-startup: deve conter um inteiro positivo indicando a ordem de carga deste Servlet em relao aos outros Servlets da aplicao, sendo que inteiros menores so carregados primeiro; se este elemento no existir, ou seu valor no for um inteiro positivo, fica a cargo do Servlet Container decidir quando o Servlet ser carregado (possivelmente, no instante em que chegar chegar a primeira requisio a esse Servlet).

Exemplo de utilizao do elemento servlet

Por fim, um elemento servlet-mapping contm um nome de Servlet, conforme definido em , e um padro da URL do Servlet no servidor (URL pattern). Exemplo de utilizao do elemento

servlet-mapping

No exemplo anterior, todos as requisies com URLs iniciadas por sero mapeadas para o Servlet cujo nome . Outros mapeamentos interessantes podem ser obtidos atravs de padres de URL do tipo , como por exemplo, ou , de maneira que o acessos a todas as URLs com o sufixo indicado sejam tratados por um mesmo Servlet. Um ltimo exemplo de mapeamento interessante diz respeito ao padro , que define o Servlet default para todos os acessos que no se encaixarem em nenhum outro padro. Juntando ento todos os elementos apresentados anteriormente, temos o Deployment Descriptor de exemplo apresentado a seguir:

Exemplo de Deployment Descriptor completo para a aplicao CadastroClientes

Nesse captulo, exploramos as caractersticas bsicas de Servlets, mostrando o funcionamento e sua interao com o Servlet Container. Implementamos tambm nossos primeiros Servlets de exemplo.

Antes que voc possa iniciar o desenvolvimento de seus Servlets, imprescindvel que voc tenha disponvel a biblioteca de Servlets Java (normalmente, um arquivo chamado ; se voc estiver utilizando o Apache Tomcat, voc pode encontrar esse arquivo abaixo do diretrio de instalao do Tomcat, no subdiretrio ). Essa biblioteca contm todas as classes e interfaces necessrias para o desenvolvimento de Servlets, e deve estar contida em seu classpath. Outro item importante, embora no imprescindvel, a documentao da API de Servlets. Por meio dessa documentao, voc poder verificar todos as classes, com seus respectivos mtodos e variveis, com os quais voc poder contar durante o processo de desenvolvimento. Essa documentao pode ser obtida diretamente do site oficial do Java ( ).

Embora Servlets possam ser utilizados no s para o desenvolvimento de aplicaes HTTP, a maior parte das aplicaes desenvolvidas so destinadas a esse fim. Sendo assim, vale a pena estudar um pouco mais a fundo o funcionamento e caractersticas desse protocolo. O protocolo HTTP utilizado na navegao nas pginas da Internet: quando voc abre uma janela de um browser, acessa uma pgina Web e navega em seus links, voc est, na verdade, utilizando esse protocolo para visualizar, em sua mquina, o contedo que est armazenado em servidores remotos. O HTTP um protocolo de comunicao cliente-servidor: o cliente envia uma requisio para o servidor, este processa a requisio e devolve uma resposta para o cliente, sendo que, a princpio, nenhuma informao mantida no servidor em relao s requisies previamente recebidas. Assim, quando digitamos o endereo de uma pgina em um browser Web, estamos gerando uma requisio a um servidor, que ir, por sua vez, devolver para o browser o contedo da pgina HTML requisitada. A requisio enviada por um cliente deve conter, basicamente, um comando (tambm chamado de mtodo), o endereo de um recurso no servidor (tambm chamado de path) e uma informao sobre a verso do protocolo HTTP sendo utilizado. Supondo, por exemplo, que utilize-se o mtodo , o path protocolo HTTP (o que equivale a digitar um endereo em um browser), temos a seguinte requisio enviada: e a verso 1.0 do

Exemplo de requisio HTTP

Existem diversos mtodos HTTP que podem ser especificados em requisies, sendo os mais comuns o mtodo , normalmente utilizado para obter o contedo de um arquivo no servidor, e o mtodo , utilizado para enviar dados de formulrios HTML ao servidor. Alm desses mtodos,

o protocolo HTTP 1.0 admite tambm o mtodo , que permite que o cliente obtenha somente os headers da resposta; j o protocolo HTTP verso 1.1 admite os seguintes mtodos: PUT: transfere um arquivo do cliente para o servidor DELETE: remove um arquivo do servidor OPTIONS: obtm a lista dos mtodos suportados pelo servidor TRACE: retorna o contedo da requisio enviada de volta para o cliente Alm do mtodo, path e verso, uma requisio pode conter parmetros adicionais, chamados headers. Dois headers comuns so, por exemplo, o header , que contm informaes sobre o cliente que est gerando a requisio (tipo, verso do browser etc.) e o header , que serve para especificar os tipos de recursos aceitos pelo cliente para a requisio enviada.

Exemplo de requisio HTTP com headers

Uma vez processada a requisio, o servidor, por sua vez, manda uma resposta para o cliente, sendo que essa resposta tambm tem um formato predeterminado: a primeira linha contm informaes sobre a verso do protocolo, um cdigo de status da resposta e uma mensagem associada a esse status; em seguida so enviados tambm headers (com informaes do servidor que gerou a resposta, por exemplo); e finalmente, enviado o contedo, propriamente dito, da resposta. Exemplo de resposta HTTP com headers Assim, no exemplo anterior, o cdigo de status indica que houve sucesso no atendimento da requisio enviada pelo cliente, os headers indicam o tipo, tamanho e data e hora de ltima modificao do contedo requisitado, e por fim, temos uma pgina HTML em branco, com o contedo propriamente dito. Outros cdigos de status bastante comuns so o , que indica que o recurso no foi localizado no servidor, e o cdigo , que indica que houve erro no processamento da requisio enviada.

Conforme descrito anteriormente, um Servlet nada mais que uma classe Java que obedece a uma estrutura bem definida. Em especial, essa classe deve implementar a interface . Existem duas classes, na biblioteca de Servlets, que implementam essa interface: e sua subclasse, . A classe , como o prprio nome indica, serve para atender requisies genricas (utilizando qualquer protocolo), e a classe , para atender requisies HTTP.

Figura 3.1 Hierarquia de classes associadas a um Servlet. No desenvolvimento do Servlet de nossa aplicao exemplo , temos assim a seguinte declarao de classe:

Declarao do Servlet ProcCadastro

Todo Servlet segue, por outro lado, um ciclo de vida composto de 3 fases: inicializao, atendimento de requisies e finalizao. A inicializao ocorre quando o Servlet Container carrega o Servlet: se o parmetro , do Deployment Descriptor (vide seo 2.2), estiver presente e contiver um inteiro positivo, essa carga ocorre quando o prprio servidor iniciado; caso contrrio, essa carga ocorre quando recebida a primeira requisio a ser mapeada para a aplicao que contm o Servlet. Aps a inicializao, o Servlet pode atender requisies. Assim, enquanto o servidor estiver ativo, e a aplicao que contem o Servlet estiver carregada, este permanecer na fase 2 de seu ciclo. Um ponto importante com relao a essa fase, e que na verdade constitui uma vantagem da tecnologia de Servlets e pginas JSP com relao a outras tecnologias, que o fato do Servlet permanecer carregado permite que dados armazenados em variveis de classe persistam ao longo das diversas requisies recebidas. Assim, possvel manter um pool de conexes ao banco de dados, por exemplo, de maneira que no seja necessrio iniciar e estabelecer uma nova conexo ao banco de dados a cada requisio recebida. Finalmente, quando o servidor finalizado, ou quando a aplicao tornada inativa pelo Servlet Container, o Servlet finalizado.

Figura 3.2 Ciclo de vida de um Servlet. Cada uma das fases se traduz, na verdade, em mtodos do Servlet que so chamados pelo Servlet Container nos diversos instantes do ciclo. Apresentamos, nas sees subsequentes, os mtodos relacionados s fases de inicializao, finalizao e de atendimento de requisies.

Conforme apresentado nos pargrafos anteriores, a inicializao do Servlet ocorre no instante em que feita a carga da aplicao pelo Servlet Container. Nesse instante, o Servlet Container executa o mtodo init do Servlet, dando chance ao Servlet de executar quaisquer passos necessrios para sua inicializao, tais como: 1) leitura de parmetros de configurao 2) inicializao de variveis de classe (variveis estticas) 3) inicializao de conexes ao banco de dados, etc.

Assim, podemos ter implementado em nosso Servlet ProcCadastro, por exemplo:

Inicializao do Servlet ProcCadastro

As assinaturas do mtodo so:

Assinaturas do mtodo init ()

Conforme pode ser visto, o mtodo admite duas assinaturas, sendo que em uma delas, recebido como parmetro um objeto da classe : atravs desse objeto, o Servlet pode obter os parmetros de inicializao do Servlet, contidos no Deployment Descriptor (veja seo 2.2). Por outro lado, caso voc opte por implementar o mtodo sem nenhum parmetro, possvel tambm obter uma referncia para o objeto por meio da chamada da prpria classe .

Assinatura do mtodo getServletConfig ()

Para obter um parmetro de inicializao do Servlet usando o objeto , deve-se utilizar o mtodo , passando como parmetro o nome do parmetro que se deseja obter.

Assinatura do mtodo getInitParameter ()

Temos, a seguir, um exemplo de uso desse mtodo:

Exemplo de uso do mtodo getInitParameter() de um objeto ServletConfig

Obviamente o mtodo pode retornar um valor nulo caso o parmetro inicial a ser obtido no tenha sido definido, e por isso importante que voc faa a verificao do String retornado pela chamada do mtodo antes de utiliz-lo. possvel tambm, a partir de um objeto da classe , percorrer a lista dos parmetros de inicializao do Servlet, bastando utilizar o mtodo .

Assinatura do mtodo

getInitParameterNames ()
Temos, a seguir, um exemplo de uso deste outro mtodo:

Exemplo de uso do mtodo getInitParameterNames() de um objeto ServletConfig

Assim, em nossa aplicao de exemplo , podemos implementar o mtodo de inicializao do Servlet como: Inicializao do Servlet ProcCadastro Outro uso comum para o mtodo de inicializao do Servlet para o despacho de um ou mais Threads, que devero ser executados durante o perodo em que o Servlet permanecer carregado. Assim, um serlvet pode, por exemplo, iniciar um Thread que ir verificar continuamente a disponibilidade de uma conexo com o banco de dados, independente de qualquer requisio que receba. Este Servlet de exemplo apresentado a seguir:

Inicializao do Servlet VerificaConBD

Uma observao importante com relao a esse processo de inicializao que o Servlet somente poder receber requisies aps a concluso de seu processo de inicializao. O desenvolvedor pode, por outro lado, indicar que esse processo de inicializao no foi bem sucedido, atravs do lanamento da exceptions ou ; nestes casos, o Servlet Container ir deixar o Servlet em um estado inativo, ou seja, sem poder receber requisies. A exception , em particular, pode receber como parmetro em seu construtor, um nmero de segundos com uma estimativa de quanto tempo o Servlet dever ficar inativo.

Exemplo de uso da exceo UnavailableException para indicar fracasso na inicializao

No caso de voc no ter percebido, todos os mtodos apresentados at agora nos exemplos foram declarados de maneira a possibilitar o lanamento do exception : isso necessrio devido chamada do mtodo , que pode, por si, lanar essa exceo para indicar problemas em sua execuo.

Alm da referncia ao objeto da classe recebido como parmetro na inicializao, o Servlet pode obter tambm uma referncia a um objeto da classe atravs do mtodo .

Assinatura do mtodo getServletContext ()

Esse objeto contm os atributos e informaes sobre o contexto em que o Servlet est sendo executado e, sendo assim, compartilhado por todos os Servlets que fazem parte da Aplicao Web. Analogamente ao que acontece com o objeto , existem mtodos para recuperar os parmetros iniciais do contexto definidos no DeploymentDescriptor (vide seo 2.2).

Assinatura dos mtodos getInitParameterNames () e getInitParameter ()

Por outro lado, importante fazer a distino entre os parmetros iniciais do Servlet e os parmetros iniciais do contexto, lembrando sempre que esses parmetros so definidos em sees distintas do DeploymentDescriptor.

Exemplo de uso do mtodo getInitParameter do objeto ServletConfig e do objeto ServletContext

Alm dos parmetros de inicializao do contexto do Servlet, podemos usar esse objeto para atribuir e recuperar atributos que sero compartilhados por todos os Servlets do contexto. Assim, temos os mtodos:

Assinatura dos mtodos getAttribute (), getAttributeNames (), removeAttribute() e setAttribute()

No exemplo a seguir, temos dois Servlets que fazem parte de uma mesma Aplicao Web e que utilizam os atributos do contexto para indicar falhas em suas respectivas inicializaes.

Exemplo de uso dos mtodos getAttribute e setAttribute do objeto ServletContext

Por fim, h um outro mtodo da classe que vale a pena conhecer: o mtodo permite que voc adicione mensagens em um arquivo de log do Servidor de Aplicaes. Voc poder utilizar esse mtodo para depurar seus Servlets, gerar alertas de problemas na sua execuo etc.

Assinatura dos mtodo log ()

Em alguns Servidores de Aplicao voc pode tambm tentar usar as sadas-padro (System.out, System.err) para gerar suas mensagens de log, porm, muito mais interessante que voc use o mtodo anterior, de maneira que o ServletContainer possa separar as suas mensagens em um log diferenciado. No caso especfico do Tomcat, as mensagens geradas por meio do mtodo so adicionadas a um arquivo de log normalmente chamado , onde uma extenso contendo a data corrente.

Exemplo de uso do mtodo log () (da classe ServletContext)

A finalizao de um Servlet deve ser tratada atravs da implementao do mtodo : no instante em que o Servlet descarregado, seu mtodo , se tiver sido implementado, chamando, permitindo a execuo de rotinas de finalizao (como por exemplo, o encerramento de conexes com bancos de dados, finalizao de threads que tenham sido lanados etc.). A assinatura do mtodo a seguinte:

Assinatura do mtodo destroy ()

Utilizando nosso exemplo de cadastro de clientes, temos a seguir um exemplo de nosso Servlet com os mtodos e implementados:

Inicializao do Servlet VerificaConBD

No exemplo, o mtodo serve para indicar que o thread deve ser finalizado: a atribuio do valor varivel faz com que o looping principal do mtodo seja finalizado.

Conforme descrito anteriormente na seo sobre o ciclo de vida de um Servlet, entre as fases de inicializao e finalizao, existe uma fase onde o Servlet ir, efetivamente, atender as requisies recebidas. No caso da classe , que a classe utilizada para Servlets genricos (classe-pai para a classe , que atende requisies HTTP), o mtodo relacionado a essa fase o mtodo .

Assinatura do mtodo service ()

Assim, para cada requisio recebida de um cliente, o ServletContainer efetua uma chamada a esse mtodo do Servlet; os parmetros desse mtodo so referncias para um objeto que encapsula a requisio recebida e para um objeto que encapsula a resposta que dever ser encaminhada para o cliente. Por outro lado, como voc normalmente estar desenvolvendo Servlets HTTP, dificilmente voc ter que implementar esse mtodo; em vez disso, para classes que extendam a classe , voc dever implementar um ou mais dos seguintes mtodos: , , , , ou .

Assinatura dos mtodos de atendimento de requests da classe HttpServlet

Quando uma requisio HTTP recebida por uma classe que estende HttpServlet, seu mtodo chamado, sendo que a implementao default desse mtodo ir chamar a funo correspondente ao mtodo da requisio recebida. Ou seja, caso uma requisio com mtodo , por exemplo, seja recebida (vide seo 3.2, sobre o protocolo HTTP), o mtodo implementado por voc ser chamado. Geralmente, desenvolvedores de Servlets implementam somente os mtodos e ; os mtodos restantes s so implementados em casos especiais, e requerem um conhecimento mais avanado por parte do desenvolvedor. Por ora, estaremos utilizando o mtodo ; nos captulos seguintes demonstraremos com mais detalhes alguns dos outros mtodos (principalmente, o mtodo ).

Um exemplo simples de implementao do mtodo pode ser observado a seguir: Servlet

HelloWorld

Durante o ciclo de vida de um Servlet, o ServletContainer ir fazer a carga de um Servlet instanciando um nico objeto e chamando seu mtodo ; a finalizao tambm efetuada chamando o mtodo desse objeto. Na fase de atendimento de requisies, por outro lado, o mtodo (e, consequentemente, os mtodos , no caso de Servlets HTTP), so chamados na medida em que so recebidas as requisies, ou seja, pode haver, em um determinado instante, um ou mais threads do ServletContainer executando mtodos simultaneamente.

Figura 3.3 Concorr ncia no atendimento de requisi es. Por isso muito importante que voc se preocupe com acesso a variveis de instncia ou classe e concorrncia no seu desenvolvimento (maiores detalhes sobre esses tpicos podem ser obtidos, por exemplo, no livro Aprendendo Java 2, da Editora Novatec).

Nesse sentido, uma opo para garantir a execuo livre de problemas de concorrncia a implementao da interface em seu Servlet. Essa interface no define, na verdade, novos mtodos ou variveis de classe, ela serve somente para indicar ao ServletContainer que o atendimento de requisies do Servlet em questo deve ser feito de forma a serializar as chamadas ao mtodo . Ou seja, somente uma requisio ser atendida por vez pelo seu Servlet.

Exemplo de Servlet que implementa a interface SingleThreadModel

No exemplo anterior, o Servlet utiliza uma varivel de instncia e, por isso, h a necessidade de se preocupar com a concorrncia no acesso a esta varivel. Imagine, por exemplo, que esse Servlet no implemente a interface , e receba duas requisies simultaneamente: o primeiro poderia incrementar o contador, seguido do segundo incrementando o contador, seguido dos dois threads, cada um por sua vez, imprimindo o valor do contador. Nessa situao, o mesmo valor de contador seria impresso nas duas pginas HTML resultantes. Resultado da primeira requisio

Resultado da segunda requisio

Obviamente a implementao dessa interface tem um custo na performance de execuo do Servlet, pois, no Servlet anterior, por exemplo, no s o acesso a varivel serializado, mas a execuo do mtodo como um todo. Em particular, a execuo dos cdigos de gerao do header e do footer HTML no precisariam ser serializados, mas so. Por isso, em vez de implementar esta interface, na maioria das vezes mais conveniente implementar diretamente um cdigo de sincronizao nos trechos que precisam ser

serializados. O Servlet , por exemplo, poderia ser implementado da seguinte forma (com exatamente o mesmo resultado):

Exemplo de Servlet que substitui a implementao da interface SingleThreadModel por cdigo de sincronizao

Alm dos mtodos , de um Servlet.

, voc tambm pode implementar o mtodo

Assinatura do mtodo getServletInfo () da classe HttpServlet

A implementao desse mtodo dever retornar um texto contendo informaes gerais sobre o Servlet desenvolvido, como por exemplo, o autor, verso e informaes de copyright de seu Servlet. Implementando esse mtodo para o nosso Servlet , temos:

Servlet HelloWorld com implementao do mtodo getServletInfo()

Caso voc no implemente esse mtodo, um texto vazio ser retornado pela implementao default desse mtodo. Embora j tenhamos visto um pouco sobre o funcionamento da gerao de uma resposta simples de um Servlet, estaremos neste captulo analisando esse processo mais a fundo e apresentando algumas funcionalidades mais avanadas.

Quando o Servlet recebe uma requisio, sem mtodo chamado com dois parmetros: uma referncia a um objeto da classe , que encapsula a requisio recebida, e uma referncia a um objeto da classe , que encapsula a resposta do Servlet.

Figura 4.1 Atendimento de uma requisi o por um Servlet. Sendo assim, a manipulao da resposta do Servlet passa, na verdade, pela manipulao do objeto dessa classe . Para gerar uma sada simples, por exemplo, voc deve utilizar o mtodo desse objeto. A chamada desse mtodo ir retornar uma referncia a um objeto da classe , que encapsula um stream de sada para um contedo do tipo texto. Esse stream deve ser utilizado para enviar a resposta de seu Servlet para o cliente que enviou a requisio.

Assinatura do mtodo getWriter ()

Embora a anlise dos mtodos dessa classe fuja um pouco ao escopo deste livro (tratase de uma classe do prprio core Java), interessante apresentar alguns de seus mtodos aqui. Os mtodos e dessa classe, por exemplo, podem ser utilizados para adicionar Strings ao stream de sada do Servlet; como a sada mantida em um buffer por questes de performance, voc pode tambm utilizar o mtodo para forar a liberao desse buffer de sada, fazendo que o contedo da resposta definido por voc seja imediatamente enviado para o cliente.

Exemplo de gerao de sada simples de Servlet

Assim, nesse exemplo, utilizamos o objeto da classe para adicionar um contedo texto (no caso uma pgina HTML) ao stream de sada do Servlet. A resposta recebida pelo cliente ser justamente essa pgina HTML. Se voc observou o exemplo anterior com cuidado (e, na verdade, todos os exemplos anteriores que incluiam algum mtodo ), voc percebeu que o mtodo foi declarado de maneira a possibilitar o lanamento de uma exceo : essa exceo pode ser lanada pelo mtodo caso haja algum problema gerao de sada do Servlet. Outra opo de implementao para o Servlet seria, portanto: Dessa forma, podemos capturar e tratar a exceo caso ela ocorra, gerando, por exemplo, uma mensagem de log. Mais detalhes sobre essas excees lanadas durante o processo de gerao da sada do Servlet, incluindo suas possveis causas, so apresentadas ao longo das prximas sees desse captulo.

Conforme apresentado na seo 3.2 deste livro, a resposta a uma requisio HTTP composta de diversos elementos, sendo que alguns desses elementos so headers (cabealhos) HTTP.

Exemplo de resposta HTTP do Servlet HelloWorld

Embora alguns headers sejam adicionados por default pelo ServletContainer, como no caso da resposta do Servlet HelloWorld acima, podem haver situaes em que voc queira definir ou modificar seus prprios headers HTTP, e para fazer isso, voc deve utilizar o mtodo setHeader ().

Assinatura do mtodo setHeader ()

Para indicar, por exemplo, que a resposta de um Servlet no deve ficar armazenada em nenhum cache (armazenamento temporrio) do browser do usurio, nem em nenhum proxy, podemos definir alguns headers adicionais especiais por meio do seguinte trecho de cdigo:

Headers para evitar cacheamento da resposta de um Servlet

Nesse cdigo, o header Expires indica a data de expirao, o header Last-Modified indica a data de ltima modificao, e os headers Cache-Control e Pragma indicam o tratamento que o documento (ou seja, a resposta do Servlet) deve receber se houver cacheamento. Com a incluso do cdigo anterior, a resposta do Servlet passa a ser:

Exemplo de resposta HTTP do Servlet HelloWorld com headers adicionais

Uma observao muito importante que essas adies / modificaes de headers HTTP devem acontecer antes da gerao do contedo da sada, para garantir a ordem dos elementos da resposta HTTP (ou seja, primeiro status, depois headers e, por fim, contedo). A alterao de um header aps a escrita de parte ou de todo o contedo pode gerar uma exceo e interromper o processo de gerao da sada do Servlet. Assim, o cdigo completo para o Servlet sem cacheamento pode ser escrito como:

Servlet HelloWorld com headers para evitar cacheamento da pgina

Se voc observou atentamente o cdigo para a modificao dos headers, voc deve ter reparado no uso de um mtodo : esse mtodo , na verdade, uma variante do mtodo que simplifica a definio de um header com uma data. Assim como esse mtodo, existe um outro mtodo para a definio de headers que contenham valores inteiros.

Assinaturas dos mtodos setDateHeader() e setIntHeader()

O segundo parmetro do mtodo deve conter o nmero de milisegundos desde epoch (meia-noite, do dia 1 de Janeiro de 1970); o mtodo do objeto retorna esse valor para o instante corrente. Alm dos mtodos anteriores, existe o mtodo , para verificar se um header j foi definido, e os mtodos , e que permitem a adio de mais de um valor para um mesmo header.

Assinaturas dos mtodos containsHeader(), addHeader (),addDateHeader() e addIntHeader()

Podemos usar o mtodo containsHeader() para verificar, por exemplo, se o header ContentType j foi definido, e defini-lo em caso negativo:

Servlet HelloWorld com definio do header Content-Type

A funo desse header informar o tipo do contedo que est contido na resposta, para que o browser (ou dispositivo cliente que est fazendo o acesso) saiba como esse contedo deve ser interpretado e apresentado. Nos exemplos anteriores esse header no foi definido explicitamente em cdigo: nesses casos, o ServletContainer automaticamente define seu valor como . Esse valor indica que o contedo deve ser interpretado pelo browser como uma pgina HTML. Outro header que definido automaticamente pelo ServletContainer, caso o desenvolvedor no o defina explicitamente, o header . Esse header indica o tamanho em bytes do contedo contido na resposta. Podem haver casos em que seja necessrio se alterar esse comportamento default: nesses casos, o desenvolvedor pode utilizar os mtodos apresentados anteriormente, ou o mtodo diretamente. Assinatura do mtodo setContentLength()

Conforme mencionado no na seo anterior, o header serve para indicar o tipo do contedo contido na resposta do Servlet. Dessa maneira, o valor indica uma pgina HTML, o valor indica uma imagem JPEG, e assim por diante. Devido a sua importncia, existe uma funo especial utilizada para a definio do valor desse header.

Assinatura do mtodo setContentType()

Embora a gerao de uma sada HTML seja a situao mais comum, podem haver situaes em que voc deseje gerar outros tipos de sada. Nesses casos, voc deve utilizar o mtodo para especificar o tipo do contedo desejado. Assim, podemos usar o seguinte trecho de cdigo para retornar uma imagem JPEG contida em um arquivo: Servlet ImageServlet

No exemplo anterior, voc poder observar tambm a utilizao do mtodo . Esse mtodo deve ser utilizado, em substituio ao mtodo que foi usado nos exemplos anteriores, para obter uma referncia a um stream de sada binria do Servlet. Assim, quando voc desejar que seu Servlet retorne um contedo binrio (no-texto), como uma imagem JPEG no cdigo anterior, voc dever utilizar esse mtodo , e obter uma referncia a um objeto da classe . Esse stream ServletOutputStream extende, na verdade, a classe e, sendo assim, herda os diversos mtodos e o mtodo da classe-me. Assinaturas dos mtodos write() e flush

()

Obviamente, a utilizao dos mtodos anteriores e at mesmo a obteno desse stream de sada binria do Servlet podem gerar excees do tipo , em situaes em que o usurio que est operando o browser aperta o boto , antes de todo o contedo gerado pelo seu Servlet seja enviado, por exemplo. Por isso importante que voc se preocupe em capturar essas excees, e fazer os tratamentos necessrios caso isso ocorra.

Dentre os diversos tipos de contedos que podem ser gerados como resposta de um Servlet, apresentamos aqui, como mais um exemplo, a gerao de documentos XML. Documentos XML so normalmente usados para estruturar um conjunto de dados de maneira simples, bem-definida e eficiente. Um exemplo de documento XML j foi apresentado no Cap tulo 2 Instala o e Configura o: o Deployment Descriptor um arquivo XML que descreve a maneira como o ServletContainer deve carregar e gerenciar uma Aplicao Web. Um outro tipo de documento XML bastante utilizado atualmente o WML (definido dentro do padro WAP, ou Wireless Application Protocol): atravs desse formato, um servidor pode formatar um contedo que ser visualizado na tela de telefones celulares. Embora a explicao detalhada do formato de um documento WML fuja ao escopo deste livro (mais detalhes podem ser obtidos no site do WapForum, ), apresentamos abaixo o cdigo de um Servlet que gera uma pgina WML apenas para exemplificar a gerao de um documento XML.

Servlet HelloWorldWML
interessante observar no exemplo anterior a utilizao do mtodo para indicar o tipo do contedo na resposta; embora para documentos XML esse tipo seja geralmente o , no caso especfico do WML ele deve ser definido como .

Como explicamos na seo 3.2 deste livro, alm dos headers e do contedo propriamente dito, a resposta a uma requisio HTTP deve conter tambm a informao do status da resposta, sendo que essa informao composta por um cdigo numrico mais um string com uma mensagem. Esse status utilizado no s para indicar se o processamento da requisio recebida foi bemsucedida ou no, mas tambm para indicar algumas outras situaes possveis, como por exemplo que o documento solicitado encontra-se disponvel em uma outra URL. Um Servlet pode definir esse status atravs do mtodo da classe , sendo que, conforme explicado anteriormente, para preservar a ordem dos elementos da resposta HTTP, a chamada a esse mtodo deve ser feita antes de qualquer definio de headers ou incio da gerao do contedo da resposta. Assinatura do mtodo setStatus() Nos exemplos apresentados anteriormente, como esse status no foi atribudo explicitamente em cdigo, automaticamente o ServletContainer o definiu como sendo 200, ou status . Vemos a seguir, por exemplo, a resposta do Servlet :

Exemplo de resposta HTTP do Servlet HelloWorld

Temos, a seguir, uma tabela com alguns dos cdigos de status HTTP existentes e seus respectivos significados:
Cdigo de Status Mensagem Significado

200 302

OK

Requisio foi processada com sucesso. Moved Temporarily disponvel em outra URL. O documento solicitado encontra- se

404 500

Page Not Found

O documento solicitado no foi encontrado. Internal Server Error Erro no processamento / obteno do documento requisitado.

503

Service Unavailable

O servio no se encontra disponvel.

Assim, no caso de nosso Servlet de gerao de imagem JPEG ImageServlet, podemos modific-lo de forma que ele retorne um cdigo caso o arquivo com a imagem a ser gerada no exista.
Servlet ImageServlet com possvel uso do cdigo de status HTTP 404

Podemos ver, nessa implementao, que o cdigo de status definido pela constante numrica da classe .

Utilizao de constante SC_NOT_FOUND da classe javax.servlet.HttpServletResponse

Para cada cdigo de status HTTP existente, a classe HttpServletResponse define uma constante correspondente, sendo que voc deve dar preferncia ao uso dessas constantes (em vez do nmero em si) para aumentar a legibilidade de seu cdigo.
Cdigo de Status Mensagem Constante

200 302 404 500 503

OK Moved Temporarily Page Not Found Internal Server Error Service Unavailable

SC_OK SC_MOVED_TEMPORARILY SC_NOT_FOUND SC_INTERNAL_SERVER_ERROR SC_SERVICE_UNAVAILABLE

Vale observar tambm que, para alguns cdigos de status, existem headers auxiliares que contm indicaes sobre o que o cliente deve fazer ao receber aquele cdigo de status. Assim, no caso do cdigo ( ), voc pode definir o valor do header para indicar o tempo estimado em segundos at que o servio volte a ficar ativo. Outro exemplo o cdigo de status ( ): ao definir esse cdigo de status, voc deve definir tambm o valor do header para indicar a URL onde o novo documento pode ser encontrado. Temos a seguir o exemplo de um Servlet que, dependendo do endereo IP do cliente que envia a requisio, redireciona o acesso para uma nova pgina contendo uma mensagem de acesso negado. Servlet CheckIPAccess

Essa situao de redirecionamento do acesso mostra-se to frequente que um outro mtodo, chamado , disponibilizado pela API de Servlets para a obteno desse mesmo efeito.

Assinaturas do mtodo sendRedirect()

Desta forma, poderamos trocar, no Servlet anterior, o trecho de cdigo:

Pelo cdigo:

Veremos a seguir uma variao do ServletContador, apresentado anteriormente neste livro, que utiliza o mtodo para redirecionar o milsimo acesso para uma pgina especial:

Variao do ServletContador: redireciona milsimo acesso

Alm dos mtodos e que permitem a manipulao do status da resposta do Servlet, possvel tambm utilizar o mtodo para indicar erros no processamento da requisio recebida.

Assinaturas do mtodo sendError()

Esse mtodo deve ser utilizado para a definio de cdigos de status nas faixas dos e , como por exemplo, os cdigos e , sendo que, se o segundo parmetro for utilizado, este deve conter a mensagem descritiva que acompanha o cdigo de status. Vale lembrar que de acordo com a configurao das pginas de erro da Aplicao Web (descrita no Deployment Descriptor, vide seo 2.2), a definio de um cdigo de status de erro pode levar apresentao de uma pgina alternativa de erro.

Um ltimo recurso interessante relacionado ao processo de gerao de resposta do Servlet o buffering do contedo dessa resposta. Esse buffering controlado atravs dos seguintes mtodos da classe :

Assinaturas dos mtodos relacionados ao buffering de resposta do Servlet

Ao invs de simplesmente repassar para o cliente contedos parciais a cada chamada aos mtodos de escrita da classe (como por exemplo, os mtodos e ), para otimizar o desempenho da aplicao o ServletContainer armazena esse contedo em um buffer, sendo que esse contedo repassado para o cliente somente quando o buffer enche ou quando encerrada a execuo do Servlet. Dessa forma, embora tenhamos dito anteriormente que h uma ordem de definio dos elementos HTTP de resposta de um Servlet a ser obedecida, utilizando essas funes de manipulao do buffer de resposta, possvel contornar essa regra. No exemplo a seguir, utilizamos essa funcionalidade para, dependendo do processamento realizado, redefinir os elementos da resposta do Servlet. Servlet com manipulao dos

buffers da resposta

Alm de gerar uma resposta para cada requisio recebida, outro trabalho importante que deve ser realizado por um Servlet o de capturar e tratar os parmetros da requisio (gerados, por exemplo, a partir de um formulrio HTML). Conforme o resultado desse tratamento, um Servlet pode gerar respostas diferentes. Esse captulo explora exatamente esse processo de captura dos parmetros da requisio recebida.

No Cap tulo 3 Servlets caracter sticas b sicas desse livro (sees 3.5 e 3.6), apresentamos algumas das funes para a obteno de parmetros e atributos do Servlet e de seu contexto. Alm dos mtodos apresentados anteriormente, possvel obter algumas informaes adicionais relevantes, como o nome do Servlet corrente, e os dados referentes a verso da API de Servlets suportada pelo ServletContainer (disponvel somente para ServletContainers que implementem a especificao de Servlets 2.1 ou superior).

Assinaturas dos mtodos getServletName (), getMajorVersion() e getMinorVersion()

Existem tambm mtodos para a obteno de informaes sobre o servidor em si, tais como: nome do servidor, que pode ser o prprio nome da mquina na rede (dependendo de como o servidor foi instalado); a porta onde o servidor recebe as requisies; e um texto de identificao do servidor, que normalmente contm o nome e verso do software que implementa o ServletContainer.

Assinaturas dos mtodos getServerInfo (), getServerName() e getServerPort ()

Em particular, os mtodos e devem ser chamados a partir do objeto da classe : como cada servidor pode definir diversos servidores virtuais, atravs de uma tcnica chamada de virtual hosts, necessrio se utilizar o prprio objeto da requisio para distinguir qual o servidor (virtual) que gerou a chamada ao servlet. Mais informaes sobre esse recurso de virtual hosts podem ser encontradas, geralmente, na documentao de servidores Web. No prximo exemplo, utilizamos os mtodos apresentados anteriormente para construir uma pgina HTML com todas as informaes conhecidas sobre o servidor, o Servlet e seu contexto.

Servlet para apresentao de parmetros do servidor

Conforme mostramos na seo 3.2 desse livro, uma requisio HTTP recebida por um Servlet composta de alguns elementos bsicos: mtodo, path, informaes sobre a verso do protocolo e headers. A API de Servlets permite que o desenvolvedor acesse todas essas informaes associadas a cada requisio recebida. Assim, temos de incio as seguintes funes: Assinaturas dos

mtodos associados a captura de informaes de requisio

Essas funes permitem recuperar o endereo IP do cliente que gerou a requisio, o nome da mquina associada a esse endereo IP (se for possvel obter esse nome), e o mtodo, path, e protocolo e sua verso associados a essa requisio. O protocolo da requisio pode tambm ser chamado de esquema (= scheme). Temos, a seguir, um Servlet que imprime essas informaes para cada requisio recebida.

Servlet que imprime informaes sobre cada requisio recebida

Assim, uma sada possvel para esse Servlet poderia ser:

Exemplo de pgina retornada pelo Servlet ServletInfoReq

Alm do mtodo utilizado em nosso exemplo, a API de Servlets disponibiliza algumas funes adicionais para a obteno de informao relacionadas ao path da requisio.

Assinaturas de mtodos adicionais para a obteno de informaes de path

Os mtodos , e retornam, respectivamente, o caminho do contexto, o caminho do Servlet abaixo do contexto, e o restante do path da requisio (se exclurmos as duas primeiras informaes). Em particular, no ambiente apresentado no Cap tulo 2 Instala o e Configura o desse livro (utilizando o Apache Tomcat), o caminho do contexto equivale ao subdiretrio criado abaixo da pasta , ou seja, o subdiretrio da aplicao Web. Por outro lado, o caminho do Servlet, corresponde ao mapeamento (servletmapping) que originou a chamada ao Servlet. Se o Servlet anterior, , estivesse instalado junto a uma aplicao Web , por exemplo, e, no Deployment Descriptor dessa aplicao Web, houvesse um mapeamento da URL para esse Servlet, teramos os seguintes resultados para cada requisio recebida:
Entra tabela

A funo seguinte, , tenta traduzir a informao de path da requisio para o caminho real do recurso no disco. importante observar que essa funo s funciona caso a aplicao web no tenha sido implantada como um arquivo WAR (explicado mais adiante no Cap tulo 9 T picos Adicionais). A ltima funo, , serve para construir a URL que gerou a requisio ao Servlet, incluindo as informaes de esquema, protocolo, mtodo etc. Essa funo deve ser chamada diretamente a partir da classe do pacote , pois trata-se de um mtodo esttico dessa classe. Agregando, ento, essas novas funes ao Servlet , temos o cdigo a seguir:

Servlet que imprime informaes sobre cada requisio recebida

Com essas novas funes, uma possvel sada para esse Servlet passaria a ser:

Exemplo de pgina retornada pelo Servlet ServletInfoReq

Se voc j construiu pginas HTML, ou at mesmo navegou na Internet, voc j deve ter se deparado com formulrios HTML. Formulrios HTML possibilitam, por exemplo, que digitemos textos ou selecionemos valores em campos de uma pgina HTML, sendo que, ao final, normalmente clicamos em um boto para que essas informaes sejam enviadas para o servidor. Ao fazermos isso, h, na verdade, uma requisio que gerada pelo browser, sendo que as informaes digitadas e selecionadas por ns so anexadas como parmetros dessa requisio. Temos, a seguir, um exemplo de pgina HTML com um formulrio de cadastro. Exemplo de

pgina HTML com formulrio de cadastro

Nesse formulrio, existem 3 parmetros que sero enviados junto com a requisio ao servidor quando clicamos no boto Enviar: , e . Em particular, o parmetro pode estar associado a mais de um valor, dependendo de quantas cores forem selecionados pelo usurio que visitar essa pgina. Uma outra forma de enviar parmetros a sua concatenao diretamente no path da requisio, bastando para isso acrescentar o caractere ao final do path, seguido de pares , separados pelo caractere . Poderiamos, por exemplo, simular um envio de informaes do formulrio anterior atravs do seguinte de requisio: Nesse caso, todo o texto que segue o caractere chamado de texto da query. importante observar que os nomes e valores dos parmetros contidos nesse texto devem estar codificados no formato MIME x-www-form-urlencoded.

Infelizmente, um estudo mais aprofundado da linguagem HTML e do protocolo HTTP foge ao escopo desse livro, sendo deixado para o leitor a opo de consultar a literatura especfica para maiores esclarescimentos.

A API de Servlets disponibiliza diversos mtodos para capturar os parmetros de uma requisio:

Mtodos para a captura de parmetros de formulrios HTML

O primeiro mtodo para a obteno de parmetros da requisio o mtodo : ele recebe um nome de parmetro e retorna o valor associado a esse nome de parmetro. Por outro lado, conforme vimos no formulrio de exemplo da seo anterior, podem existir campos com diversos valores associados a um mesmo nome (vide campo do exemplo). Nesses casos, devemos utilizar o mtodo , que ir retornar no um nico valor, mas sim um array de valores. O mtodo seguinte, , retorna uma lista enumerada com todos os nomes de parmetros recebidos. Dessa forma, possvel iterar nessa lista e obter os respectivos valores de parmetros. Por fim, o ltimo mtodo, , retorna justamente o texto da query explicado na seo anterior, ou seja, a parte do path de requisio que vem aps o caractere (se existir). O Servlet usa os mtodos apresentados anteriormente para capturar os parmetros enviados pelo usurio e apresent-los em sua sada

Servlet que imprime parmetros de cada requisio recebida

Se utilizarmos o formulrio apresentado na seo anterior para enviar informaes para esse Servlet, uma sada possvel seria:

Exemplo de pgina retornada pelo Servlet ServletInfoReq

Frequentemente, quando voc quiser adicionar interatividade a sua aplicao Web, permitindo que o usurio envie dados ao servidor, voc ir utilizar formulrios HTML, e por isso, muito importante que voc domine os mtodos apresentados nessa seo.

Assim como acontece na resposta de um Servlet, a requisio recebida tambm pode conter headers. Esses headers podem servir para indicar, por exemplo, caractersticas sobre o cliente que gerou a requisio.

Mtodos para a captura de informaes de headers da requisio

Os mtodos , e servem para recuperar o contedo de um header e se comportam de maneira anloga aos respectivos mtodos apresentados na seo 4.2 desse livro: o mtodo recupera o contedo de um header contendo uma data, e o mtodo recupera o contedo de um header contendo um nmero inteiro. O mtodo , por sua vez, permite obter todos os valores associados a um determinado header: caso voc saiba de antemo que um header ir ter diversos valores associados, voc deve utilizar esse mtodo para garantir a recuperao de todos esses valores. Por fim, o mtodo retorna uma lista enumerada de todos os nomes de headers recebidos. Com isso, voc pode usar essa funo para iterar na lista de todos os headers recebidos. Um uso frequente para esses mtodos o de verificao do header , que indica o tipo e verso do software do cliente que enviou a requisio. Por meio desse header, voc pode gerar um documento diferenciado para cada tipo de browser que acessa a sua aplicao. O header tambm bastante importante: ele indica os tipos de contedos aceitos pelo cliente. O Servlet a seguir verifica o contedo desse header e, dependendo de seu valor, retorna uma pgina de saudao em formato HTML ou WML; dessa forma, ele pode ser usado tanto para

atender requisies de browsers normais da Internet, como tambm para atender requisies de browsers de telefones celulares (vide seo 4.3).

Servlet ServletVerAccept

Alm dos campos normais de input, seleo e botes de um formulrio HTML, existe um tipo de campo especial que permite o upload (ou transferncia) de arquivos da mquina do usurio para o servidor.

Exemplo de pgina HTML com formulrio para upload de arquivo

Nesse formulrio de exemplo, o campo do tipo ; esse campo permite que seja selecionado um arquivo do disco local que ser enviado junto com a requisio. Vale a pena observar tambm que existe um atributo adicional , com contedo , que deve ser especificado junto ao elemento . A maneira mais fcil de se tratar esse tipo de parmetro de requisio em um Servlet utilizando classes prontas de terceiros. Um exemplo de uma biblioteca que pode ser utilizada para esse tipo de tratamento pode ser encontrada no endereo . O Servlet a serguir utiliza essa biblioteca para tratar arquivos carregados pelo formulrio HTML do exemplo anterior.

Servlet ServletUploadArq
No Servlet anterior, usamos alguns dos mtodos disponveis na biblioteca . Para conhecer todos as suas funcionalidades, voc deve fazer o download da biblioteca, e observar a documentao de sua API.

Finalmente, alm de todos os mtodos apresentados anteriormente, existem mtodos para definir e recuperar atributos da requisio. Esses atributos funcionam como os atributos do contexto do Servlet apresentados na seo 3.6, exceto que seu escopo est limitado requisio.

Mtodos para definir / recuperar atributos da requisio

Embora estejamos falando desses mtodos pela primeira vez nesse captulo, exemplos e uma explicao mais detalhada de seu uso sero apresentados no Cap tulo 8 Modelo MVC. Nesse captulo so explorados os conceitos de Cookies e Sesses: atravs dessas tcnicas, veremos como possvel armazenar informaes sobre os usurios que utilizam nossas aplicaes.

Como explicamos na seo 3.2, o HTTP um protoloco stateless, ou seja, ele no mantm um histrico das requisies recebidas de um mesmo cliente. Assim, imaginando uma aplicao simples como um carrinho de compras de uma livraria virtual, por exemplo, como devemos proceder para manter o histrico dos livros j selecionados pelo nosso cliente? Se a seleo de cada livro gera 1 ou mais requisies, no momento do fechamento da compra, como fazemos para saber quais foram todos os livros selecionados? Existem algumas maneiras diferentes de resolver esse problema, de maneira a contornar essa limitao do protocolo HTTP, como veremos a seguir.

Alm dos tipos de campos de formulrios HTML apresentados na seo 5.3 desse livro, existe tambm um tipo, chamado hidden, que pode ser usado para esconder parmetros da requisio. Na pgina HTML seguinte, o campo do tipo hidden.

Exemplo de formulrio HTML com campo hidden

Se voc tentar abrir essa pgina em um browser, voc poder observar que o campo no visvel; por outro lado, o nome e valor desse campo sero recebidos normalmente como um parmetro de requisio pelo seu Servlet. Assim, podemos construir o Servlet a seguir para contar o nmero de requisies recebidas de cada cliente:

Servlet ServletContadorReq

O Servlet anterior usa o campo escondido para armazenar o valor do contador na ltima requisio recebida, sendo que esse valor repassado de volta para o Servlet cada vez que o cliente pressiona o boto . Assim como acontece nesse Servlet, voc pode utilizar campos escondidos de formulrios HTML para armazenar informaes e fazer com que sejam passadas para seus Servlets junto com as requisies futuras recebidas. Por outro lado, esse mtodo tem uma grande desvantagem: para utiliz-lo, voc precisa garantir que, uma vez armazenado um valor em um campo escondido, todas as requisies recebidas carregaro esse parmetro junto. Isso pode gerar um grande trabalho na construo de sua aplicao, alm de no funcionar em todos os casos: se o usurio de sua aplicao sair de sua pgina, ou at mesmo usar os botes de navegao de seu browser (como o boto de voltar, por exemplo), ele automaticamente ir perder os ltimos parmetros definidos.

Outra forma de armazenar / passar informaes entre requisies subsequentes de um mesmo cliente utilizando as informaes adicionais de caminho. O Servlet da seo anterior, por exemplo, poderia ser modificado para passar o valor atual do contador como uma informao adicional do caminho.

Servlet ServletContadorReqMod

Em relao a utilizao de campos escondidos, essa tcnica possui a vantagem de simplificar um pouco a construo de seus Servlets. Por outro lado, ela no resolve os problemas apontados anteriormente com relao a perda dos parmetros definidos.

Para resolver esse problema da persistncia das informaes associadas a um cliente, necessria a utilizao de Cookies. Cookies so pacotes de dados, gerados pelo servidor, e que so enviados junto com a resposta de uma requisio, ficando armazenadas pelo browser do usurio. Posteriormente, a cada requisio enviada, o browser anexa tambm as informaes desses Cookies, permitindo que o servidor recupere os valores definidos anteriormente. Um estudo completo de Cookies foge ao escopo desse livro; para obter mais detalhes sobre eles, deve-se consultar a RFC 2109 (mais informaes no site ), que contm sua especificao. Por outro lado, vale a pena conhecer os principais atributos de um Cookie; alm de um nome, que identifica o Cookie para um determinado servidor e path nesse servidor, e o valor, que contm os dados em si, um Cookie possui tambm alguns atributos adicionais: Comentrio (Comment): deve conter um texto descrevendo o propsito e funo do Cookie; Perodo de expirao (MaxAge): determina por quanto tempo (em segundos) o Cookie ser vlido; Domnio (Domain): por default, uma vez definido, um Cookie s retornado junto com requisies para o mesmo servidor que o gerou. Esse atributo permite, por outro lado, que esse Cookie seja enviado para todos os servidores abaixo de um mesmo domnio (conforme especificado na RFC 2109); Caminho (Path): por default, uma vez definido, um Cookie s passado junto com as requisies para os recursos abaixo do diretrio virtual do recurso que gerou o Cookie. Se esse caminho for definido, por outro lado, o Cookie passa a ser enviado junto com as requisies para qualquer recurso abaixo caminho especificado; A API de Servlets disponibiliza uma classe especial para representar um Cookie, a classe , sendo que os mtodos dessa classe permitem definir / recuperar os valores de seus diversos atributos.

Mtodos para definir / recuperar os principais atributos do Cookie

Para usar um Cookie, primeiro devemos cri-lo, passando como parmetros de seu construtor o nome e valor do Cookie, e, em seguida, devemos definir seus atributos. Finalmente, o Cookie deve ser adicionado ao objeto para que seja enviado para o browser do usurio.

Exemplo de cdigo com definio de Cookie

No cdigo anterior, estamos gerando um Cookie de nome , com o valor , e que ter validade de 60 segundos a partir do instante em que for recebido pelo usurio; passado esse perodo, o Cookie automaticamente descartado pelo browser. Um valor negativo para o perodo de expirao indica que o Cookie deve ser vlido enquanto o browser no for encerrado, e o valor indica que o Cookie deve ser removido imediatamente pelo browser. importante observar tambm que, a menos que voc esteja fazendo o controle do buffer de resposta conforme descrito na seo 4.6, esse procedimento de criao e adio de Cookies a resposta do Servlet deve acontecer antes de gerar o contedo da resposta propriamente dito, de forma a preservar a ordem dos elementos HTTP da resposta do Servlet. Aps gerarmos todos os Cookies desejados, podemos recuper-los nas requisies seguintes atravs do mtodo da classe . Esse mtodo retorna se no houver nenhum Cookie na requisio recebida, ou um Array com os Cookies recebidos. Infelizmente, no existe um mtodo para a recuperao direta de um Cookie especfico; necessrio utilizar esse mtodo para recuperar todos os Cookies, e, ento, iterar nessa lista at acharmos o Cookie que estamos procurando. Assim, podemos utilizar o trecho de cdigo a seguir para obter o valor do Cookie definido anteriormente.

Exemplo de cdigo para obteno de um Cookie

Com os mtodos e recursos apresentados, podemos reimplementar nosso Servlet da seguinte forma:

Reimplementao do Servlet ServletContadorReq

Nessa nova implementao do Servlet, vale a pena observar que no necessrio que o usurio de nossa aplicao clique em nada para que o contador seja atualizado, basta que ele recarregue a pgina. At mesmo se o usurio visitar outra pgina e depois voltar para o endereo desse Servlet, o contador incrementado. Infelizmente, existem situaes em que Cookies no funcionam: geralmente isso acontece quando o browser do usurio est configurado explicitamente para no aceitar Cookies. Com as crescentes preocupaes em torno da privacidade de quem navega na Internet, alguns usurio passaram a bloquear o armazenamento de Cookies em seus browsers.

A API de Servlets disponibiliza um mdulo extremamente til no controle de informaes associadas ao usurio que acessa nossa aplicao: o mdulo de gerenciamento de sesses de usurios. Basicamente, esse mdulo funciona da seguinte forma: a primeira vez que o usurio acessa nossa aplicao, criado para ele um identificador de sesso, ao qual associado um objeto da classe na memria do servidor de aplicaes. A partir da, o servidor de aplicaes procura fazer com que todas as requisies vindas daquele usurio carreguem esse identificador de sesso, seja atravs da definio de Cookies, ou atravs da reescrita das URLs (com informaes adicionais de caminho) para que incorporem essa informao. Recebido esse identificador, a API automaticamente disponibiliza para o Servlet o objeto criado anteriormente. Dessa forma, um Servlet pode utilizar esse objeto em memria para armazenar informaes que queira associar a um usurio especfico que acessa a aplicao. Essas informaes estaro disponveis em todas as requisies posteriores recebidas no s pelo Servlet que as armazenou, mas tambm para todos os Servlets que compartilharem do mesmo contexto. Para obter uma referncia ao objeto dessa classe , um Servlet deve utilizar o mtodo da classe ; esse mtodo possui, na verdade, duas assinaturas.

Assinaturas para o mtodo getSession () da classe HttpServletRequest

A primeira assinatura retorna sempre um objeto da sesso, sendo que esse objeto pode ter sido criado nesse instante, ou ter sido criado em uma requisio anterior (ou seja, j havia uma sesso criada). A segunda assinatura, por sua vez, admite um parmetro que, se for , faz com que o mtodo tenha o mesmo comportamento da primeira assinatura. Caso contrrio, o mtodo pode retornar null: se ainda no houver uma sesso criada, ao invs de criar uma nova sesso, o mtodo retorna null. Podemos, ento, utilizar o seguinte trecho de cdigo para obter o objeto com a sesso corrente:

Primeira alternativa de cdigo para obteno do objeto HttpSession para a sesso corrente

O cdigo anterior utiliza a segunda assinatura do mtodo para obter a sesso corrente. Uma alternativa melhor de cdigo apresentada a seguir, utilizando a primeira assinatura do mtodo :

Cdigo para obteno do objeto HttpSession para a sesso corrente

No cdigo anterior, podemos observar tambm a utilizao de um mtodo da classe : esse mtodo indica se o identificador da sesso j foi enviado para o browser cliente ou no (ou seja, se a sesso acabou de ser criada). Alm desse mtodo, a classe oferece diversos outros mtodos: Mtodos da classe HttpSession

Os primeiros quatro mtodos apresentados permitem gerenciar os objetos que queremos associar a sesso do usurio de forma similar a manipulao de uma Hashtable. Dessa forma, para cada objeto que queremos armazenar na sesso HTTP, ns devemos associar um nome de atributo, e manipular o objeto como valor desse atributo. Assim, se quisermos definir um atributo de sesso de nome , contendo o valor do contador de requisies usados nos Servlets , podemos utilizar o seguinte trecho de cdigo:

Cdigo com exemplo de definio de atributo de sesso

Para recuperar o valor desse atributo posteriormente, podemos utilizar esse outro trecho de cdigo:

Cdigo com exemplo de recuperao de atributo de sesso

Os trs mtodos seguintes, , e , retornam, respectivamente, o identificador dessa sesso, o instante de criao da sesso e o instante de ltimo acesso do usurio com a sesso corrente (esses dois ltimos valores em milisegundos, desde 1 de janeiro de 1970 GMT). O Servlet a seguir utiliza os mtodos apresentados anteriormente para construir uma pgina HTML com todas as informaes sobre a sesso corrente do usurio:

Servlet ServletInfoSessao

A outra caracterstica importante desse mdulo de gerenciamento de sesses que ele permite que sesses criadas automaticamente expirem aps um determinado tempo de inatividade. Obviamente, o desenvolvedor tambm pode expirar uma sesso explicitamente atravs de sua programao. Essa funcionalidade, presente em diversas tecnologias de desenvolvimento de aplicaes para a Web, pode ser observada, por exemplo, em sites que exigem a autenticao do usurio, como por exemplo, em um site de Internet Banking. Nesses sites, aps o login, se o usurio ficar um longo perodo de tempo sem interagir com o site, sua sesso expirada, de forma que ele no consiga utilizar mais nenhuma funo do site antes de efetuar o login novamente. O mesmo ocorre se o usurio clicar no boto ou link de sair / logoff. Isso ocorre dessa maneira para reforar a segurana do sistema; uma segunda pessoa que utilize o mesmo browser do usurio que acessou a aplicao ter que efetuar o login para conseguir ter acesso as funes do sistema. Caso contrrio esse segundo usurio poderia simplesmente usar o sistema em nome do primeiro usurio. A API de Servlets oferece as seguintes funes para controlar a expirao da sesso do usurio.

Mtodos para controle da expirao da sesso

As duas primeiras funes permitem, respectivamente, obter e definir o perodo mximo de inatividade em segundos antes que o ServletContainer invalide a sesso do usurio, e o terceiro mtodo permite que essa sesso seja expirada (ou invalidada) explicitamente pela aplicao. Para exemplificar o uso de todas as funes apresentadas nessa seo, vamos construir um esqueleto de uma aplicao que requer a autenticao de usurios. Mais tarde, voc poder utilizar os cdigos apresentados a seguir para construir sua prpria aplicao autenticada. Primeiro devemos construir um Servlet que apresenta a tela de login propriamente dita:

Servlet FormLogin

Em seguida, temos um Servlet que faz, efetivamente, a autenticao. Se a autenticao for bem sucedida, esse Servlet armazena, como atributo da sesso, o nome do usurio, e redireciona a requisio para o menu principal de nossa aplicao.

Servlet Login

Um detalhe interessante com relao ao Servlet anterior que ele no retorna nenhum contedo HTML por si, ele simplesmente efetua um processamento e, conforme seu resultado, redireciona a requisio para Servlets que apresentaro um contedo. Esse modelo de funcionamento ser explorado com mais detalhes no Cap tulo 8 Modelo MVC. Finalmente, teremos o Servlet que apresenta o menu principal da aplicao (caso a autenticao tenha sido bem sucedida).

Servlet MenuPrincipal
Caso a aplicao venha a ter mais Servlets autenticados (que s podero ser acessados aps o login do usurio), pode valer a pena criar uma hierarquia de classes para facilitar o processo de desenvolvimento. Assim, podemos criar uma classe abstrata que faz a validao da sesso do usurio, verificando se o usurio j efetuou o login, e, se isso no tiver acontecido, redirecionando a requisio para o Servlet .

Servlet ServletLogado
Utilizando a classe anterior, podemos criar tantos Servlets autenticados quanto quisermos: basta que esses Servlets estendam a classe e implementem o mtodo , em vez do mtodo . Poderamos, por exemplo, implementar o Servlet da seguinte forma:

Servlet MenuPrincipal

Nos quatro captulos anteriores, exploramos com detalhes como um Servlet pode tratar uma requisio HTTP e gerar sua resposta. Infelizmente, as aplicaes que pudemos desenvolver at agora tem uma sria limitao inerente a prpria tecnologia de Servlets: a formatao do contedo da resposta est totalmente integrada a programao da lgica da aplicao. A tecnologia de pginas JSP, que estudaremos nesse captulo, nos ajudar a transpor essa limitao.

Em nossos Servlets de exemplo apresentados nos captulos anteriores, geramos, como resposta, pginas HTML simples, sem nenhuma formatao. O primeiro Servlet apresentado (seo 1.2), por exemplo, pode gerar a seguinte pgina HTML ao receber uma requisio:

Essa pgina HTML no tem, praticamente, nenhuma formatao; um Webdesigner sugeriria, com certeza, diversas alteraes no cdigo HTML para tornar o layout da pgina mais atrativo. Assim, poderamos alterar esse cdigo minimamente para: Apesar da pgina apresentar exatamente as mesmas informaes, a formatao pode tornar o contedo muito mais atraente para o usurio que estiver visitando nossa aplicao. Por outro lado, essa modificao faz com que a codificao do Servlet fique muito mais trabalhosa, pois agora a resposta do Servlet precisa conter todos esses dados de formatao adicionais. Assim, se originalmente o cdigo do mtodo do Servlet era

, agora esse cdigo passa a ser

Alm disso, qualquer modificao na formatao dessa pgina torna necessrio o envolvimento do programador, j que ele precisa incorporar essa modificao ao cdigo do Servlet e recompilar seu cdigo. Por exemplo, se nosso Webdesigner decidir que a cor do texto agora precisa ser verde, precisamos alterar o cdigo anterior para Todo esse processo faz com que o desenvolvedor tenha um grande trabalho cada vez que a formatao da pgina precise ser modificada, tornando esse processo lento e pouco flexvel.

Se em um Servlet a incluso e a modificao da formatao da resposta precisam ser feitas pelo desenvolvedor diretamente no cdigo da aplicao, em uma pgina JSP a idia que esse processo possa ser feito diretamente pelo responsvel pelo looknfeel (layout) da aplicao. Assim, uma pgina JSP nada mais , na verdade, que uma pgina HTML, com elementos especiais onde o desenvolvedor pode programar o contedo dinmico da aplicao. Porm, ao contrrio de uma pgina HTML cujo nome de arquivo tem extenso .htm ou .html, arquivos com pginas JSP devem ser nomeados com extenso .jsp. A primeira verso do Servlet apresentado na seo anterior (sem nenhuma formatao), por exemplo, poderia ser reescrito como a seguinte pgina JSP PrimPag.jsp

Primeiro exemplo de pgina JSP

Nessa pgina JSP, o contedo dinmico est contido no elemento Desde que esse elemento no seja alterado, podemos incluir / alterar livremente a formatao da pgina sem afetar o funcionamento da aplicao. Podemos, portanto, modificar essa pgina de maneira a ter a segunda verso do Servlet apresentado na seo anterior:

Segundo exemplo de pgina JSP

Aps fazer essa modificao, ao contrrio do que acontece quando se trabalha diretamente com Servlets, voc no precisa recompilar a aplicao, essa modificao j passa a ser automaticamente visvel para os usurios.

A mgica por trs de uma pgina JSP a seguinte: existe um Servlet especial, chamado , que intercepta requisies direcionadas a recursos com extenso .jsp. No instante em que recebida uma requisio para uma pgina JSP, o Page Compiler transforma essa pgina em um Servlet e o compila, sendo que o resultado dessa compilao carregado em memria para evitar que esse processo tenha que ser repetido para todas as requisies recebidas. A primeira verso de nossa pgina de exemplo , por exemplo, transformada no seguinte Servlet

Primeira verso da pgina JSP PrimPag.jsp transformada em Servlet

O Page Compiler tambm verifica a data de alterao do arquivo que contm a pgina JSP: caso essa data se modifique, o processo de compilao executado novamente para garantir que modificaes feitas na pgina sejam visveis para os usurios da aplicao. Devido a todo esse processo de compilao / recompilao, voc poder observar que o primeiro acesso aps a criao ou modificao de uma pgina JSP sempre mais lento que os acessos seguintes (at que haja uma modificao no contedo da pgina).

O fato de uma pgina JSP ser convertida para um Servlet faz com que ela tenha o mesmo ciclo de vida apresentado na seo 3.4 desse livro: existe uma etapa de inicializao, uma etapa de atendimento de requisies, e finalmente, uma etapa de finalizao. No existem mtodos equivalentes ao ou de um Servlet para a etapa de atendimento de requisies, j que o prprio contedo da pgina contm o cdigo a ser executado e retornado para o browser a cada requisio. Por outro lado, existem os mtodos e que possibilitam a implementao de cdigos de inicializao e finalizao, respectivamente, da pgina JSP. A maneira pela qual esses dois mtodos podem ser declarados para uma pgina JSP ser apresentada na seo Declaraes mais adiante nesse mesmo captulo.

J vimos nas pginas JSP apresentadas at agora um exemplo de um elemento dinmico; na pgina apresentada na seo 7.2 desse captulo, por exemplo, temos a seguinte linha contendo um elemento dinmico: , onde o contedo do elemento dinmico est delimitado pelos caracteres e .

Este apenas um tipo de elemento dinmico, chamado comumente de expresso. Alm desse, existem outros 4 tipos principais de elementos dinmicos que podem estar presentes em uma pgina JSP: diretivas, scriptlets, declaraes e JavaBeans. As sees seguintes iro apresentar, de maneira mais detalhada, cada um desses tipos de elementos dinmicos que podero ser utilizados por voc em suas pginas JSP.

O primeiro tipo de elemento dinmico que iremos estudar ser a diretiva. O formato bsico de uma diretiva o seguinte:

Formato bsico de uma diretiva de uma pgina JSP

, onde a palavra deve ser substituda por , ou . Para cada um desses tipos de diretivas, existem conjuntos de atributos especficos utilizados para parametrizar a diretiva.

Conforme o prprio nome indica, a diretiva serve para se definir diretivas da pgina; embora existam diversos atributos possveis para essa diretiva, os atributos mais comuns so os seguintes: , , import, e . O atributo info deve ser utilizado para se definir um texto informativo sobre a pgina sendo construda; seu valor retornado pelo mtodo do Servlet (veja seo 3.10).

Exemplo de diretiva page com atributo info

Da mesma forma que o mtodo apresentado na seo 4.2 desse livro, o atributo serve para indicar o tipo de contedo sendo gerado pela pgina JSP. Assim, podemos utilizar a seguinte diretiva no incio de uma pgina JSP para indicar que seu contedo uma pgina HTML.

Exemplo de diretiva page com atributo contentType

O atributo seguinte, deve ser utilizado para indicar pacotes a serem importados no Servlet que ser gerado (via declarao ). Assim, devemos indicar por meio desse atributo todos os pacotes que estaremos utilizando na programao de nossa pgina JSP. Se quisermos utilizar a classe do pacote , e as classes que esto no pacote , por exemplo, poderamos declarar a diretiva com os seguintes atributos:

Exemplo de diretiva page com atributo import

Finalmente, o atributo serve para indicar a pgina JSP a ser exibida em caso de erro no processamento da pgina corrente. A pgina JSP que for exibir o erro deve, por sua vez, declarar a diretiva com o atributo definido explicitamente como . Usando todos esses atributos da diretiva , poderamos implementar uma pgina JSP simples de impresso da data corrente da seguinte forma:

Pgina JSP que imprime data corrente (datacorrente.jsp)

Alm do tipo de diretiva ao qual todos os atributos apresentados anteriormente se referem, existe tambm um outro tipo de diretiva, a diretiva . Essa diretiva admite um nico atributo .

Essa diretiva deve ser utilizada para incluir o contedo de outro arquivo na pgina JSP corrente, sendo que esse arquivo tanto pode conter um contedo esttico, como uma pgina HTML (ou pedao de uma pgina HTML), como um contedo dinmico, ou seja, uma outra pgina JSP. Sendo assim, podemos reescrever a pgina JSP anterior da seguinte forma Segunda verso

da pgina JSP que imprime data corrente

, sendo que o contedo do arquivo

Cabealho para pgina JSP que imprime data corrente (cabecalho.jsp)

, e o contedo do arquivo

Rodap para pgina JSP que imprime data corrente (rodape.html)

A vantagem de utilizar essa diretiva est no fato de que voc pode manter contedo esttico ou dinmico comum a diversas pginas JSP em arquivos separados, includos, atravs dessa diretiva, conforme a necessidade. Podemos, por exemplo, construir novas pginas JSP que incluem o arquivo de cabealho e : se for necessrio mudar o contedo do cabealho ou do rodap, no precisaremos editar todas as nossas pginas, apenas o contedo desses arquivos.

Em todas as pginas JSP construdas at agora utilizamos um elemento dinmico chamado de : esse elemento serve para imprimir o resultado de uma expresso Java. Sua sintaxe bsica a seguinte:

Sintaxe de uma expresso JSP

Obviamente, esse elemento pode ser utilizado para imprimir o contedo de uma varivel do tipo , ou at mesmo de uma constante . Supondo que seja uma varivel , por exemplo, poderamos incluir o seguinte elemento em uma pgina JSP para imprimir o contedo da varivel:

Exemplo de incluso de uma expresso JSP para a impresso do contedo de uma varivel do tipo String

Por outro lado, podemos formar expresses mais complexas, como na pgina JSP que imprime a data corrente, desde que o resultado dessas expresses sejam Strings.

Expresso que imprime a data corrente na pgina JSP datacorrente.jsp

Uma expresso JSP possibilita o processamento de uma expresso Java, e a impresso de seu resultado junto com o contedo da pgina JSP. Embora esse recurso seja bastante poderoso, ele no serve para situaes quando precisamos efetuar um processamento mais complexo, utilizando, por exemplo, diversos blocos de cdigo Java. Um Scriptlet permite a insero de um bloco de cdigo Java diretamente no corpo da pgina JSP. Sua sintaxe a seguinte: Sintaxe de um Scriptlet JSP Ns podemos utilizar um Scriptlet para incrementar um pouco nossa pgina JSP :

Terceira verso da pgina JSP que imprime data corrente

Nesse exemplo de pgina JSP, utilizamos um Scriptet para definir variveis cujos contedos so posteriormente impressos por expresses JSP. De fato, podemos combinar o uso de Scriptlets e expresses, desde que, obviamente, seja preservada a semntica Java (ou seja, variveis sejam utilizadas somente aps serem declaradas, por exemplo). Construmos, a seguir, um exemplo um pouco mais elaborado de pgina JSP utilizando Scriptlets: trata-se de um formulrio HTML para input do ms do aniversrio do usurio, sendo que Scriptlets so utilizados para construir os meses possveis da caixa de seleo do formulrio.

Pgina JSP com formulrio HTML de input do ms de aniversrio do usurio (formmesaniv.jsp)

interessante observar nesse exemplo a combinao de Scriptlets, expresses e elementos estticos da pgina: o bloco de cdigo Java iniciado no primeiro Scriptlet da pgina no finalizado nesse prprio Scriptlet, mas sim em um outro Scriptlet, inserido aps a impresso de um contedo esttico e de 2 expresses JSP.

No nosso primeiro exemplo de pgina JSP (veja seo 7.2), fizemos referncia a um objeto que no foi declarado em nenhum ponto da pgina: na expresso JSP dessa pgina, existe uma referncia a um objeto . Primeiro exemplo de pgina JSP

Esse objeto equivale, na verdade, a instncia da classe passada como parmetro para o Servlet quando esse recebe uma requisio, conforme estudamos no Cap tulo 5 Captura de par metros da requisi o desse livro. Alm desse objeto, que representa a requisio recebida pela pgina, a API de pginas JSP disponibiliza outros objetos implcitos que podem ser utilizados nos elementos dinmicos programados pelo desenvolvedor. Segue uma lista dos principais objetos implcitos, com suas respectivas classes:
Objeto Classe

request response

javax.servlet.http.HttpServletRequest javax.servlet.http.HttpServletResponse out

javax.servlet.jsp.JspWriter session javax.servlet.http.HttpSession application

javax.servlet.ServletContext config javax.servlet.ServletConfig

Voc deve utilizar esses objetos implcitos da mesma maneira como voc utilizaria os objetos das respectivas classes na programao de seus Servlets. Em particular, o objeto implcito , da classe , prov funcionalidade semelhante a da classe que utilizamos na maior parte dos exemplos com Servlets desse livro. No exemplo seguinte, reescrevemos o formulrio de input do ms de aniversrio do usurio utilizando o objeto implcito :

Segunda verso para pgina JSP de input do ms de aniversrio do usurio (formmesaniv.jsp)

Podemos tambm construir a pgina JSP que far o tratamento dos dados submetidos pelo formulrio da pgina , utilizando os objetos implcitos e :

Pgina JSP que faz o tratamento dos dados submetidos pelo formulrio formmesaniv.jsp (procmesaniv.jsp)
Nesse exemplo, tomamos o cuidado de tratar o parmetro recebido e, conforme o caso, gerar o redirecionamento da requisio logo no incio da pgina, antes de escrever qualquer outro contedo esttico ou dinmico: da mesma forma que no desenvolvimento de Servlets, precisamos obedecer a ordem de gerao dos elementos da resposta HTTP, ou seja, os headers do redirecionamento devem ser gerados antes da escrita de qualquer elemento do contedo da resposta (veja seo 4.2).

Esse tipo de elemento dinmico especial de uma pgina JSP serve para definir cdigos Java que devero ficar fora do mtodo de atendimento das requisies (o mtodo , no mais alto nvel). Assim, esse elemento serve para declarar variveis de classe (estticas), variveis de instncia, ou at mesmo novos mtodos. Sua sintaxe a seguinte:
Sintaxe de uma declarao JSP

Em particular, esse elemento deve ser utilizado para definir os mtodos e (mencionados na seo 7.4) caso voc opte por incluir um cdigo de inicializao ou finalizao da pgina JSP. A pgina JSP seguinte aperfeioa um pouco mais nossa pgina input do ms de aniversrio do usurio, imprimindo o nome do ms por extenso na caixa de seleo do formulrio. O array de mapeamento do nome do ms declarado em um elemento de declarao JSP, para evitar a alocao de memria adicional a cada atendimento de requisio.

Terceira verso para pgina JSP de input do ms de aniversrio do usurio (formmesaniv.jsp)

Existem, na verdade, dois tipos de comentrios que voc poder utilizar em sua pgina JSP. Um primeiro tipo o comentrio HTML: independente de ser uma pgina JSP (ou seja, mesmo sendo uma pgina HTML esttica), voc pode utilizar esse elemento para incluir um texto que no aparecer diretamente para o usurio que estiver visualizando sua pgina. O usurio poder, por outro lado, ler o comentrio caso visualize o fonte da pgina. A sintaxe de um comentrio HTML a seguinte:

Sintaxe de um comentrio HTML

O outro tipo de comentrio que voc poder utilizar um comentrio JSP: ao contrrio de um comentrio HTML, o texto escrito por voc no aparecer para o usurio mesmo que ele

visualize o fonte da pgina. A sintaxe de um comentrio JSP a seguinte: Sintaxe de um

comentrio JSP
Exemplificando o uso dos dois tipos de comentrios:

Pgina JSP com exemplo de uso dos dois tipos de comentrios (HTML e JSP)

JavaBeans so, na verdade, classes Java reutilizveis que seguem algumas regras bem definidas para nomeao de seus mtodos e variveis. A idia por trs do uso desses JavaBeans em nossas pginas JSP, que eles encapsulem a lgica de nossa aplicao, separando-a do restante da pgina. Embora a definio exata de JavaBeans fuja ao escopo desse livro, para efeitos de uso do uso dessas classes em pginas JSP, necessrio que se siga algumas regras bsicas no seu desenvolvimento: 1) O construtor da classe, se declarado, no deve receber nenhum argumento. 2) Podem existir um ou mais mtodos pblicos para a definio de valores de propriedades do Bean; esses mtodos so chamados de mtodos . 3) Podem existir um ou mais mtodos pblicos para a obteno de valores de propriedades do Bean; esses mtodos so chamados de mtodos . Temos, a seguir, uma exemplo de classe JavaBean que implementa uma lgica bsica de nossa aplicao:

Primeiro exemplo de JavaBean: encapsula lgica de clculo de preos de um produto

Uma vez construdo o JavaBean, para referenci-lo em nossa pgina JSP, devemos utilizar o elemento dinmico , que tem a seguinte sintaxe:

Sintaxe de um elemento para incluso de um JavaBean

Na sintaxe anterior, deve conter o nome do JavaBean como ele ser referenciado na pgina e deve conter o nome da classe incluindo informaes sobre seu pacote (como por exemplo, ). O atributo , por outro lado, deve conter um dos seguintes valores: (pgina; o valor default caso esse atributo no seja explicitamente definido), (requisio), (sesso) ou (aplicao); esse valor indica o escopo dentro do qual o JavaBean ser visvel. Assim, se o escopo de um JavaBean for de sesso, ele ser armazenado como um atributo de sesso, podendo ser referenciado em todas as requisies dessa mesma sesso. Se quisssemos utilizar o JavaBean em uma pgina JSP, por exemplo, poderamos incluir as seguintes linhas de cdigo:

Exemplo de pgina JSP utilizando o JavaBean PrecoProdBean

Esse elemento no o nico elemento disponibilizado pela API de pginas JSP para trabalhar com JavaBeans: existem elementos para referenciar diretamente os mtodos e dos JavaBeans desenvolvidos. Ainda no exemplo de JavaBean anterior ( ), vamos acrescentar mtodos e propriedade com o preo de unidade do produto: para a

Segundo exemplo de JavaBean: aperfeioa PrecoProdBean com mtodos getter e setter para o preo de unidade

Para referenciar o mtodo de um JavaBean, a API de pginas JSP disponibiliza o elemento , cuja sintaxe :

Sintaxe de um elemento para referenciar o mtodo getter de um JavaBean

Para imprimir o valor do preo unitrio de um produto, por exemplo, poderamos acrescentar as seguintes linhas em nossa pgina JSP:

Segundo exemplo de pgina JSP utilizando o JavaBean PrecoProdBean

Da mesma forma como existe um elemento dinmico para referenciar mtodos de JavaBeans, tambm existe um elemento dinmico para os mtodos . A sintaxe desse elemento :

Sintaxe de um elemento para referenciar o mtodo setter de um JavaBean

Podemos, ento, modificar o exemplo de pgina JSP anterior para definir o valor do preo unitrio do produto antes de exibi-lo:

Terceiro exemplo de pgina JSP utilizando o JavaBean PrecoProdBean

Esse elemento de referncia a mtodos de JavaBeans admite, ainda, outra sintaxe de uso:

Sintaxe alternativa de elemento para referenciar o mtodo setter de um JavaBean

Nessa sintaxe, o valor que ser recebido pelo JavaBean para a propriedade em questo, ser o valor do parmetro , conforme recebido pela requisio HTTP.

Existe um ltimo tipo de elemento dinmico que pode ser utilizado em uma pgina JSP: um elemento de referncia a uma biblioteca de Tags.

Uma biblioteca de Tags permite que voc tambm separe a lgica de programao de sua aplicao do contedo da pgina JSP, assim como JavaBeans se prope a fazer. No entanto, ao contrrio de JavaBeans, uma biblioteca de Tags oferece um acesso nativo aos objetos da pgina JSP, como por exemplo, o objeto que encapsula a resposta do Servlet correspondente a pgina JSP. Nessa seo estaremos explorando algumas caractersticas bsicas de biblioteca de Tags. Uma explicao mais detalhada e aprofundada sobre TagLibs pode ser obtida em . Existem 4 componentes principais por trs do uso de uma biblioteca de Tags. O primeiro componente um arquivo chamado de Descritor de Bibliotecas de Tags (Tag Library Descriptor): esse arquivo, nomeado com extenso .tld e colocado no diretrio , contm as configuraes das bibliotecas de Tags utilizadas pela aplicao.

Exemplo de um Descritor de Bibliotecas de Tags (minhabibliotags.tld)

Nesse exemplo de Descritor de Biblioteca de Tags, podemos observar diversos elementos: os elementos , e contm, respectivamente, a verso da biblioteca de Tags, seu nome (conforme referenciado posteriormente na pgina JSP) e um texto informativo sobre a biblioteca. O ltimo elemento no descritor de nosso exemplo um elemento tag: esse elemento serve para especificar um nome de uma Tag ( ) e a respectiva classe que ir tratar essa Tag quando utilizada na pgina JSP ( ). O elemento especifica o tipo de tratamento que o contedo da Tag dever receber: no nosso exemplo, esse contedo dever ser vazio, ou seja, no dever haver texto nenhum entre o elemento de incio e fim da Tag; outros valores possveis para esse elemento so e . Embora em nosso exemplo haja somente um elemento do tipo tag, pode haver mais de um elemento desse tipo no mesmo Descritor de Biblioteca de Tags. O componente seguinte por trs do uso de uma biblioteca de Tags, o Deployment Descriptor, j apresentado no Cap tulo 2 Instala o e Configura o desse livro. Para que se possa utilizar uma biblioteca de Tags, necessrio incluir um mapeamento de uma URI, referenciada na pgina JSP, ao arquivo .tld com a biblioteca de Tags correspondente. Assim, poderamos incluir as seguintes linhas no Deployment Descriptor de nossa aplicao:

Exemplo de linhas includas no Deployment Descriptor para utilizao de uma biblioteca de Tags

O componente seguinte de uma biblioteca de Tags a classe que ir gerenciar a Tag ( ). Essa classe, especificada pelo elemento do Descritor da Biblioteca de Tags, responsvel por executar as rotinas pertinentes quando a Tag encontrada na pgina JSP. Essa classe que gerencia a Tag deve implementar a interface ou : a diferena bsica entre essas duas interfaces diz respeito ao tratamento do contedo da Tag. Como em nosso exemplo no estamos interessandos no contedo da Tag, a classe que apresentamos implementa a interface .

Exemplo de classe para gerenciar uma Tag (Tag Handler)

Os mtodos mais importantes dessa classe so os mtodos , chamado quando a Tag encontrada, , chamado aps o processamento do contedo da Tag, e , chamado ao trmino de todo o processamento devendo liberar quaisquer recursos alocados durante o processo. interessante observar que no mtodo obtemos uma referncia ao stream de sada da pgina, e utilizamos esse stream para imprimir nosso texto . Finalmente, o componente final de nossa biblioteca de Tags a pgina JSP em si. Para utilizar a biblioteca de Tags , podemos elaborar a seguinte pgina JSP de exemplo:

Exemplo de pgina JSP que utiliza a biblioteca de Tags minhabibliotags.tld (exemplotags.jsp)

Nessa pgina, primeiro inclumos um elemento , cujo atributo contm a URI especificada no Deployment Descriptor (que por sua vez faz o mapeamento com o arquivo .tld correto), e cujo atributo prefix especifica o prefixo a ser utilizado antes de cada Tag. Na linha seguinte, temos a utilizao da Tag em si: h um prefixo, conforme especificado pelo atributo do elemento taglib, seguido da Tag, que dever ter sido declarada no descritor de bibliotecas de Tags. Ao encontrar esse elemento, o container ir carregar a classe que gerencia esse Tag, e chamar os mtodos pertinentes. importante observar que no existe nenhum contedo para a tag ; a notao abreviada equivalente se escrever . Caso houvesse algum contedo para essa tag, teramos que utilizar um valor diferente para o atributo no descritor de bibliotecas de Tags, e poderamos considerar a implementao da interface em vez de para a classe . A pgina HTML resultante do processamento da pgina JSP apresentada anteriormente ser ento:

Resultado do processamento da pgina exemplotags.jsp

Embora voc possa construir suas prprias bibliotecas de Tags, normalmente mais prtico e fcil utilizar uma biblioteca j pronta, como o Apache Jakarta Struts, disponvel no site http://jakarta.apache.org/struts/.

Nesse captulo apresentamos o modelo MVC: atravs desse modelo, procuramos mostrar como podemos separar o trabalho de desenvolvimento do trabalho de formatao e layout da aplicao.

Normalmente, o desenvolvimento de uma aplicao Web envolve o trabalho de duas equipes distintas: os desenvolvedores so responsveis pela programao, e os webdesigners so responsveis pela formatao e layout do front-end da aplicao. Pelo que vimos at agora, existe uma interseco entre esses dois mundos: na verdade, qualquer que seja a tecnologia que se utilize para desenvolver aplicaes Web, sempre existe um ponto em que se mistura os trabalhos dessas duas equipes. Agora imagine uma situao onde o incio do trabalho de uma equipe dependa da outra equipe finalizar a sua parte; imagine tambm que, qualquer alterao feita por uma equipe precise necessariamente envolver o trabalho da outra equipe. Essas situaes podem onerar tanto o cronograma quanto o custo de um projeto. Assim, tanto para efeitos de construo, quanto da manuteno da aplicao desenvolvida, muito importante que haja a maior separao possvel entre esses dois trabalhos, de maneira que as duas equipes possam trabalhar de forma independente, sem dependerem uma da outra. Embora j tenhamos visto nesse livro algumas tcnicas que auxiliam na separao entre lgica da aplicao e apresentao, apresentaremos nesse captulo uma tcnica muito mais eficaz e que pode ser utilizada de maneira complementar as apresentadas anteriormente.

A arquitetura bsica do modelo MVC, ou Model-View-Controller, se vale do uso de Servlets, JavaBeans e pginas JSP: os Servlets controlam as requisies recebidas (Controller), os JavaBeans implementam a lgica da aplicao (Model), e as pginas JSP se encarregam da apresentao do resultado (View). Podemos representar melhor essa arquitetura atravs da seguinte figura:

Figura 8.1 Arquitetura b sica MVC.

Toda vez que uma requisio recebida, o Servlet de controle repassa a requisio para a pgina JSP responsvel pela apresentao da resposta, sendo que JavaBeans so utilizados pela pgina JSP para obter os dados dinmicos da aplicao.

Para que um Servlet possa repassar a requisio recebida para uma pgina JSP, necessrio utilizar um mtodo especfico da classe .

Assinatura do mtodo getRequestDispatcher () da classe HttpServletRequest

Esses mtodo retorna uma referncia para um objeto que implementa a interface e que atua como um wrapper para o recurso indicado no path passado como parmetro para a funo. Assim, se voc passar como parmetro, por exemplo, o caminho relativo de uma pgina JSP, esse mtodo retornar uma referncia a um wrapper dessa pgina JSP. Esse wrapper, por sua vez, disponibiliza um mtodo que permite que voc repasse a requisio para o recurso encapsulado pelo wrapper.

Assinatura do mtodo forward () da interface RequestDispatcher

Podemos, dessa forma, implementar um Servlet de exemplo que no faz nada, apenas repassa todas as requisies recebidas para uma pgina JSP.

Exemplo de Servlet que repassa requisies para uma pgina JSP

No Servlet anterior, existe um ponto importante que deve ser observado: o path passado como parmetro para a funo referencia um recurso contido na mesma aplicao Web do Servlet, e, dessa forma, deve excluir a parte referente ao diretrio virtual da aplicao (ou seja, esse path no deve ser escrito como ). Alm disso, importante observar que o mtodo poder lanar uma exceo: uma das causas pode ser uma exceo lanada pelo prprio recurso referenciado pelo . Podemos tambm implementar a pgina JSP referenciada no Servlet anterior como:

Exemplo de pgina JSP OlaMundo.jsp

Assim, a cada requisio recebida, o Servlet repassa a requisio para a pgina JSP , que por sua vez retorna para o Browser a seguinte pgina HTML Resposta do Servlet

ServletRepassaReqs

Existe ainda um outro recurso da API de Servlets que iremos utilizar no desenvolvimento de nossas aplicaes Web no modelo MVC: esse recurso a definio / obteno de atributos da requisio. A classe possui quatro mtodos que podem ser utilizados para gerenciar os atributos de uma requisio.

Assinatura dos mtodos da classe HttpServletRequest que gerenciam os atributos de uma requisio
Esses mtodos funcionam de maneira semelhante aos mtodos da classe apresentada na seo 3.6: eles permitem definir, remover ou obter valores de atributos de uma requisio. Esses valores de atributos no precisam necessariamente ser objetos , eles podem ser objetos quaisquer Java. Para exemplificar o uso dessas funes, vamos implementar novamente nosso Servlet da seguinte forma:

Segunda verso para Servlet que repassa requisies para uma pgina JSP

A pgina JSP

, por sua vez, pode ser implementada como:

Pgina JSP ApresentaMensagem.jsp

Dessa forma, alm de repassar a requisio do Servlet para a pgina JSP, estamos tambm passando objetos, definidos no Servlet, para a pgina JSP. Esse mecanismo funciona graas aos atributos de requisio. Juntando os recursos apresentados nas sees anteriores, podemos finalmente apresentar o modelo MVC com todos os seus componentes. Para fazer essa apresentao, reimplementaremos e estenderemos a aplicao de login da seo 6.4 desse livro. Agora, a aplicao de login passar a prever tambm um nvel de acesso associado a cada usurio que efetua a autenticao: se o usurio tiver nvel de acesso administrativo, ser apresentada a interface do administrador, caso contrrio ser apresentada a interface do usurio comum. Assim, o Servlet de Login ser:

Servlet Login

Conforme voc pode observar no Servlet anterior, no existe nenhuma codificao feita que se relaciona a apresentao da interface para o usurio da aplicao. O Servlet simplesmente trata os parmetros recebidos, repassando a requisio para as diversas pginas JSP da aplicao, que devero ser responsveis pela interface em si. Pgina JSP FormLogin.jsp

Pgina JSP UsuarioComum.jsp Pgina JSP Administrador.jsp

Essas pginas JSP podero ser trabalhadas pelos responsveis pelo layout e formatao de nossa aplicao, sem afetar a lgica e o trabalho de desenvolvimento.

J apresentamos nos captulos anteriores as principais caractersticas e funcionalidades referentes ao desenvolvimento de aplicaes Web com Servlets e pginas JSP. Estaremos, nesse captulo, apresentando alguns tpicos adicionais que complementaro todo o conhecimento que voc obteve at agora: voc ir conhecer arquivos WAR, mecanismos de autenticao HTTP e pools de conexes a uma base de dados.

J apresentamos, na seo 2.2, uma maneira atravs da qual voc pode instalar uma aplicao Web em um servidor de aplicaes: voc pode fazer essa instalao criando, abaixo do diretrio , uma pasta com o nome de sua aplicao, com o contedo dessa pasta obedecendo a um formato especfico (veja seo 2.2). Embora essa forma de instalar a aplicao funcione, considerado mais elegante distribuir sua aplicao no formato de um arquivo WAR, ou Web Application Archive. Um arquivo WAR nada mais que um arquivo .jar, nomeado com a extenso .war. Assim, voc deve gerar o arquivo WAR utilizando o aplicativo jar para juntar todo o contedo do diretrio de sua aplicao (retirando, obviamente, os arquivos fontes .java). Assim, poderamos, por exemplo, remover os arquivos .java de dentro do diretrio (que contm a nossa aplicao), e, a partir de um PROMPT DOS e de dentro desse diretrio, digitar a linha de comando . Com um arquivo .war, podemos instalar nossa aplicao Web em qualquer servidor de aplicaes: basta copiar esse arquivo para a pasta do servidor. Obviamente, devemos tomar cuidado para no instalar o arquivo .war mais o diretrio com toda a nossa aplicao juntos em um mesmo servidor de aplicaes.

Na seo 6.4 desse livro, apresentamos um exemplo de aplicao contendo uma autenticao baseada em formulrios HTML. Essa no a nica forma de fazer a autenticao de usurios de uma aplicao. O protocolo HTTP incorpora uma funcionalidade que pode auxiliar na implementao de um mecanismo de autenticao. Estaremos, nessa seo, mostrando o funcionamento de um tipo especial de autenticao, a partir do protocolo HTTP, chamada de Basic Authentication (autenticao bsica). Para implementar esse tipo de autenticao, precisamos utilizar o cdigo de status de resposta ( ) e o header de resposta . Ao retornar uma resposta com esse cdigo de status e esse header de resposta contendo um valor , onde deve ser substitudo por um nome do domnio no qual estamos fazendo a autenticao (cada domnio deve proteger um conjunto de recursos de sua aplicao), faremos com que o browser do usurio de nossa aplicao mostre uma caixa de dilogo pedindo um usurio e senha de acesso. O usurio e senha digitados nessa caixa pelo usurio sero enviados, por outro lado, junto com uma nova requisio a nossa aplicao, atravs do header . O valor desse header estar

codificado no formato Base64, sendo necessrio utilizar um decodificador para ler, efetivamente, seu contedo: esse contedo ser um texto no formato . O Servlet a seguir exemplifica o uso desse tipo de autenticao HTTP:

Exemplo de Servlet que utiliza autenticao HTTP para controlar acesso

Existe tambm uma maneira de implementar a autenticao de usurios que esto acessando nossa aplicao baseada em elementos de segurana configurados no Deployment Descriptor de nossa aplicao (veja seo 2.2). Para implementar essa autenticao dessa forma, voc deve adicionar elementos elemento ao Deployment Descriptor de sua aplicao. e um

Exemplo de configurao de segurana no Deployment Descriptor da aplicao

Os elementos apresentados na listagem anterior, por exemplo, definem que os acessos a URL devem ser autenticados. Em particular, o elemento define o grupo de usurios que deve ter acesso a URL em questo: os diversos grupos, com seus respectivos usurios / senhas, devem, nesse caso, ser configurados no arquivo abaixo do diretrio de instalao do Apache Tomcat. Se voc optar por utilizar esse mtodo de autenticao, voc deve chamar em seu cdigo os mtodos e , da classe , para obter o nome do usurio e seu grupo. Mais detalhes com relao a autenticao baseada em elementos de segurana do Deployment Descriptor da aplicao podem ser encontrados na especificao de Servlets. Uma das grandes vantagens no desenvolvimento de aplicaes Web com Servlets e pginas JSP a performance obtida em funo da persistncia dos objetos carregados em memria. Em particular, conforme mostramos em diversos exemplos ao longo desse livro, o estado de uma varivel esttica pode ser mantido ao longo das diversas requisies recebidas pela aplicao. Um dos recursos que mais se beneficiam dessa persistncia em memria so as conexes com o banco de dados: como o processo de abrir uma nova conexo com o banco de dados pode pesar significativamente na performance da aplicao, vale a pena manter as conexes abertas, em vez de abrir uma nova conexo a cada requisio recebida. Esse tipo de persistncia , normalmente, implementado por meio de um gerenciador de conexes a base de dados: a cada requisio recebida, um Servlet chama um mtodo desse gerenciador para alocar uma conexo; ao trmino de seu processamento, o Servlet chama outro mtodo para liberar a conexo previamente alocada. O gerenciador, por sua vez, responsvel por estabelecer efetivamente novas conexes quando necessrio, e armazenar essas conexes abertas. A classe , a seguir, implementa um gerenciador de conexes a base de dados: Classe PoolConBD: implementa gerenciador de pool de conexes com a base

de dados

 interessante observar que a classe anterior permite que sejam configurados / utilizados no apenas um nico pool de conexes a base de dados, mas sim diversos pools: como so declaradas variveis estticas, todas as aplicaes Web sendo executadas na mesma instncia da mquina virtual Java iro compartilhar esses mesmos objetos. Sendo assim, necessrio prever a alocao e liberao de conexes por aplicao, de forma que o funcionamento de uma aplicao no interfira no funcionamento de outra. Esse gerenciador de conexes ao banco de dados utiliza tambm uma classe do tipo para indicar falhas em seu funcionamento. Segue a implementao dessa classe :

Classe PoolConBDException: excees associadas a classe PoolConBD

Finalmente, temos a seguir um Servlet para exemplificar o uso de nosso gerenciador de pool de conexes:

Servlet ServletTestePool: exemplifica o uso de nosso gerenciado de pool de conexes a base de dados

O mercado de desenvolvimento de aplicaes na dcada de setenta e oitenta era baseado em sistemas centralizados executando sobre um nico computador. O desenvolvimento contnuo da tecnologia diminuiu o preo de componentes de hardware. Com a queda no preo de componentes de hardware tornou-se vivel a aquisio de computadores, agilizando, principalmente, o processo produtivo de empresas. As empresas, que adquiriram muitos computadores, comearam a perceber a utilizade em criar canais de comunicao entre estas mquinas, este foi o desenvolvimento prtico das redes de computadores. As redes deixaram de estar na teoria de livros e partiu para o cotidiano do mercado. A vantagem das redes de computadores estava ligada, principalmente, possibilidade de acesso compartilhado de recursos tais como impressoras e arquivos. Com o desenvolvimento das redes de computadores diversas empresas comearam a oferecer sistemas operacionais que suportassem tal interconexo em rede. Desenvolveram-se, ento, sistemas como o Novell, Windows for Workgroups, Linux que mais tarde foram evoluindo para os sistemas mais utilizados atualmente. Com o desenvolvimento dos sistemas operacionais de rede, que permitiam o compartilhamento de recursos, os desenvolvedores se depararam com clientes desejando softwares capazes de executar em todos seus computadores, atualizando um mesmo banco de dados. Neste ponto houve o desenvolvimento da tecnologia cliente-servidor, utilizando linguagens tais como Clipper, Visual Basic e Delphi. Nas implementaes da tecnologia cliente-servidor era utilizado um computador central com o banco de dados. Cada um dos computadores que participavam da rede tinha instalado um software que acessava remotamente este banco de dados. Esta foi a forma encontrada para que todos pudessem executar o software com desempenho desejvel. Nos anos noventa, com o desenvolvimento da Internet, um novo mercado foi criado. Este mercado exigiria mais conhecimentos dos desenvolvedores, e especializao at mesmos dos vendedores de tecnologia. Estes sistemas de Internet executavam sobre um determinado computador, que tinha um Web Server (tal como Apache, Microsoft IIS, etc) e uma banco de dados (PostgreSQL, Oracle, etc). Quando um usurio acessasse um servidor via um navegador (Netscape, Opera, Microsoft Internet Explorer, etc), este servidor retornaria uma pgina, esta pgina conteria contedo em HTML, que mais tarde evoluiu para outros formatos. No incio os servidores de pginas na Internet, hospedavam apenas pginas em HTML com figuras (gifs, jpegs, etc). Pginas HTML no poderiam gerar dinamicamente dados, tal como obter, inserir e alterar informaes em um banco de dados. Neste momento houve o desenvolvimento de CGIs (Common Gateway Interfaces). Os CGIs eram pequenos programas em linguagens como por exemplo C. Estes CGIs eram chamados pelo servidor Web para acessar um banco de dados ou executar qualquer tipo de tarefa que deveria ser dinmica, e no esttica, tal como so as pginas HTML.

Figura 10.1 Servidor WEB com CGI. Os CGIs eram mais difceis de se desenvolver (nesta poca se utilizava linguagem C), ento diversos desenvolvedores iniciaram a criao de suportes modulares nos sevidores Web para permitir a integrao direta com linguagens de desenvolvimento. Os CGIs eram executados como processos parte do Web Server, o que necessitava a alocao de mais memria e sobrecarregava o sistema, em casos com muito acesso. Diversas linguagens de script se desenvolveram aps os CGIs, tais como PHP, ASP, Perl, Phyton e JSP. A execuo de scripts (pequenos programas) criados nestas linguagens era feita como observado na figura 10.1, o que diminuia o consumo de memria do servidor, gerando menos atrasos no tempo de resposta do cliente e minimizando a sobrecarga do servidor.

Figura 10.2 Suporte a M dulos. O desenvolvimento nas linguagens de script o mais comum at hoje para sistemas na Internet. Contudo, desenvolver neste modelo tem diversas limitaes tais como escalabilidade, comunicao entre processos, acesso simultneo a bancos de dados, transaes entre bancos de dados que esto localizados em diferentes computadores e distribuio de carga. Para solucionar as limitaes das linguagens de script diversos trabalhos estavam paralelamente em desenvolvimento. Estes projetos visavam a construo de suportes para a construo de sistemas distribudos. Os sistemas distribudos permitem que computadores executem computaes de forma cooperativa, e alm disto oferecem um grau de transparncia para o usurio final. Contudo, desenvolver neste tipo de arquitetura distribuda no era uma tarefa simples, alis, o desenvolver precisava ter altssima especializao. Para isto empresas tais como a Sun Microsystems se uniram em torno de um padro chamado J2EE (Java

2 Enterprise Edition) para o desenvolvimento de aplicaes distribudas, oferecendo aos desenvolvedores uma base slida e mais simples (no que seja to simples assim) para desenvolvimento.

Antes de aprofundar em qualquer arquitetura de sistema distribudo, deve-se aprender mais sobre sistemas distribudos. A definio mais simples de sistemas distribudos um conjunto de computadores interligados em rede, que executam operaes computacionais de forma cooperativa e transparncia para o usurio final. Ter uma rede o primeiro passo para a construo destes sistemas, o prximo passo criar um sistema que seja modular, onde cada mdulo execute em um computador distinto. Estes mdulos trocam informaes entre si para executar determinada operao computacional. O termo transparncia se refere a criar um nvel de abstrao entre o usurio e o sistema, desta forma o usurio no sabe que seu sistema executa uma parte em cada computador, simplesmente para ele, o sistema esta sendo executado. Este usurio enxerga o conjunto de computadores interligados em rede para execuo cooperada de computaes tal como um nico computador virtual (maiores informaes no livro Distributed Systems, autor Andrew S. Tanembaum).

Figura 10.3 Computador Virtualmente nico Os benefcios de um Sistema Distribudo sobre um sistema que executa em um nico computador compreendem a economia, velocidade, desenvolvimento de aplicaes naturalmente distribudas, confiabilidade, crescimento incremental. Um caso prtico da economia encontra-se em certa situao vivenciada por um dos autores que, na poca, desenvolvia sistemas para a Internet. Determinado sistema havia sido contrudo em PHP, uma linguagem de script, para acessar um banco de dados e realizar determinandas operaes. Aps certo tempo este sistema tornou-se um dos sites mais acessados do pas, e o servidor que o executava ficou cada vez mais carregado. Havia ento dois caminhos a se tomar: o primeiro seria comprar um computador maior e com mais capacidade, o outro desenvolver a aplicao novamente para executar como uma aplicao distribuda. Para tratar da questo que envolvia esta aplicao em PHP foram realizados diversos estudos comparando custos e desempenho computacional. Foi observado que seria necessrio adquirir uma workstation da Sun Microsystems para atender a aplicao, caso contrrio seria necessrio desenvolver novamente. Contudo, caso a aplicao fosse implementada para funcionar sobre um sistema distribudo seriam necessrios trs computadores pessoais para execut-la, o que era em torno de 12 vezes mais barato.

Figura 10.4 Economia de Recursos A velocidade outra questo de interessante anlise. A velocidade de um hardware chega a limites da prpria fsica, contudo como ultrapassar estes limites impostos pelos materiais existentes? Utilizar um ambiente distribudo pode colaborar neste sentido, pois subdividir uma aplicao em mdulos, que executem em paralelo, cada um em um computador distinto, divide a carga e permite que a aplicao tenha maior desempenho final. Contudo, subdividir uma aplicao em mdulos no uma tarefa trivial. Um exemplo de aplicao prtica para atingir alta velocidade na execuo da aplicao o site de buscas Google ( ). Imagine buscas muito complexas, existe um computador nico que conseguiria atender a este sistema? No. Construir um hardware para isto seria vivel? No, pois o custo seria proibitivo. Para resolver este tipo de problema, os envolvidos criaram uma aplicao que executa sobre diversos computadores, particionando as operaes de busca e indexao das informaes.

Figura 10.5 Google. H aplicaes que so naturalmente distribudas, onde mdulos precisam executar tarefas distintas, contudo em algum momento necessitam trocar mensagens para sincronizar determinadas informaes. Este tipo de aplicao altamente privilegiada pelos sistemas distirbudos.

A confiabilidade de um sistema pode ser atingida de duas formas: atravs da replicao de hardware e da replicao de software. Replicar hardware tem o intuito de no deixar o sistema cair em casos onde um dos componentes fsicos venha a ter problemas, este tipo de soluo conhecida como tolerncia a falhas. A rplica de software tem o intuito de copiar softwares para diferentes computadores, caso um dos computadores pare, outro poder reiniciar a aplicao e o sistema continua disponvel, este tipo de soluo conhecida como alta disponibilidade. A alta disponibilidade algo inerente de um sistema distribudo. Como existem vrios computadores em uma rede, torna-se muito acessvel desenvovler uma aplicao onde sejam criados mdulos e rplicas destes mdulos possam existir em outros computadores. Caso um dos computadores tenha problemas, outro poder assumir.

Figura 10.6 Alta Disponibilidade. O crescimento incremental est relacionado necessidade do sistema de suportar maiores cargas. Em um sistema centralizado, quando este torna-se muito carregado (veja o exemplo citado sobre o aspecto econmico de sistema distribudos) deve-se adquirir um novo hardware para execut-lo, e este com certeza ser de maior custo. Contudo, numa aplicao distribuda bem subdividida em mdulos, no caso do ambiente ficar muito carregado, pode-se adicionar novos computadores ao sistema, redistribuir os mdulos entre os computadores de tal forma que atinja maior desempenho e atenda seus novos requisitos.

Figura 10.7 M dulos do Sistema Distribu do.

Figura 10.8 M dulos do Sistema Distribu do Redistribu dos. As desvantagens de um Sistema Distribudo compreendem o desenvolvimento de software, sobrecarga no meio de comunicao, segurana. Para projetar um sistema distribudo o desenvolvedor precisa de conceitos adicionais e sempre ter em mente aspectos tais como multithreading, acesso compartilhado a recursos, comunicao em rede de computadores, acesso simultneo a recursos e outros conceitos. Isto tona o desenvolvimento de aplicaes distribudas algo complexo para os desenvolvedores mais comuns. Subdividir os mdulos de uma aplicao distribuda no uma tarefa simples. Para isto deve-se ter em mente a necessidade de criar mdulos que tenham pouca comunicao entre si,

sobrecarregando o mnimo possvel o meio de comunicao. Tendo, por exemplo, cinco objetos, sendo que trs deles comunicam-se em demasia, crie um mdulo para estes trs, caso os outros tenham pouca comunicao, subdividaos entre os demais computadores.

Figura 10.9 Subdivis o de M dulos. Observando a figura 10.9 pode-se pensar: caso a aplicao fique muito carregada posso redistribuir os mdulos B e C, conforme a figura 10.10.

Figura 10.10 Redistribui o de M dulos. Contudo, se o mdulo A tornar seu computador muito carregado como resolver tal questo? Pode-se tentar subdivid-lo, mas se a rede ficar muito sobrecarregada com tal diviso pode ser necessrio comprar um computador de alto desempenho somente para executar este mdulo. Os sistemas distribudos minimizam em cerca de 95% dos casos que envolvem aquisio de

hardware, contudo h problemas que se resolvidos de forma distribuda podem tornar a rede sobrecarregada e gerar um pior desempenho final. O principal objetivo de um sistema operacional de rede o compartilhamento de recursos em uma rede de computadores. Suponha uma rede onde existe apenas uma impressora, mais fcil compartilh-la para todos os usurios do sistema do que comprar uma impressora para cada computador. Para solucionar este tipo de problema foram desenvolvidos os sistemas operacionais de rede. So exemplos de sistemas operacionais de rede o Linux e Windows 95/98/NT/2000. Em um sistema operacional de rede, os computadores so enxergados pelos usurios como mquinas distintas. Desta forma, para acessar um determinado recurso, deve-se saber em qual computador ele se localiza. Em um sistema operacional de rede a comunicao entre computadores realizada atravs de arquivos compartilhados, isto ocorre tanto no acesso a diretrio (ou pastas) compartilhadas, quanto no uso da impressora, que cria uma fila de impresso para recepo de arquivos compartilhados. Um sistema distribudo oferece ao usurio a imagem de um nico recurso computacional. O usurio final no sabe se parte de sua aplicao executa nos computadores A, B e C. Alm disto, as partes em que sua aplicao foi subdividida comunicam-se entre si para sincronizar informaes e, portanto, executar uma operao em conjunto. Suponha uma aplicao que necessita realizar muitos clculos, enquanto outra parte da aplicao utiliza os resultados destes clculos. Pode-se subdividir esta aplicao em dois mdulos. Cada um deles executando em um computador diferente. O projetista do sistema conhece estes aspectos do sistema, contudo o usurio final acredita que o sistema est executando em apenas um computador, pois ele desconhece o funcionamento do sistema e suas operaes. A comunicao em um sistema distribudo feita atravs de mensagens que trafegam sobre a rede. Ao contrrio dos sistemas operacionais de rede que podem trafegar arquivos completos. Com as definies anteriores pode-se notar que executar um sistema operacional como Linux ou Windows em uma rede no ter um sistema distribudo. Ter um sistema distribudo construir uma aplicao que seja subdividida em mdulos, cada um deles executando em um computador distinto e trocando mensagens entre si para sincronizar todas as tarefas que esto sendo executadas.

CORBA (Common Object Request Broker Architecture) um padro que definido pela OMG (Object Management Group), organizao que rene cerca de 800 empresas do mundo todo. Este padro foi desenvolvido para a construo de aplicaes distribudas. Por ser um padro, para aplic-lo, deve-se ter acesso a um suporte ou ferramenta que o implemente. Diversas empresas e interessados desenvolveram suas prprias verses seguindo o padro Corba, dentre estas pode-se destacar o Mico ( ), OmniOrb (), Visibroker (), Jacorb () entre outros. Segundo o padro Corba, aplicaes para um ambiente distribudo podem estar sendo executadas em diferentes plataformas de hardware e sistemas operacionais. Alm disto,

podem ter sido construdas em diferentes linguagens de programao tais como C, C++, Java ou Delphi. Uma das vantagens do padro Corba ser aberto, isto permitiu que vrias empresas implementassem suas prprias verses, deixando de limitar o desenvolvedor tal como ocorre com solues proprietrias. E o mais importante, fossem interoperveis entre si. Isto de fato o objetivo, contudo fazer duas verses de Corba diferentes interoperarem no to simples quanto parece. Um desenvolvedor contri sua aplicao sobre uma verso do Corba, e desta forma, pode distribuir as partes desta aplicao em uma rede. Assim a aplicao ir funcionar como um sistema distribudo.

Figura 10.11 Corba. A principal limitante no crescimento do uso de Corba a complexidade em desenvolver para esta arquitetura. H muitas exigncias para os desenvolvedores, que necessitando de produtividade acabaram deixando esta arquitetura.

Com o desenvolvimento da plataforma Java, a Sun Microsystems observou um grande horizonte no desenvolvimento de aplicaes em rede de computadores e iniciou o desenvolvimento de um suporte para objetos distribudos chamado Java/RMI. RMI significa Remote Method Invocation, ou seja, a invocao de mtodos remotos. Este suporte simplificou a construo de aplicaes distribudas, contudo funciona apenas para a linguagem Java, ao contrrio de Corba.

Chamada

Objeto Cliente

Stub Cliente

Retorno

Stub Servidor

Objeto Servidor

Figura 10.12 Java/RMI. RMI contou com o apoio de diversas empresas, que interessadas na plataforma Java, desenvolveram uma srie de IDEs (Integrated Development Environments), aquelas ferramentas grficas que simplificam o desenvolvimento, prontas para implementar usando a nova tecnologia. Isto agregou muito e diversos desenvolvedores voltaram sua ateno para Java. RMI possibilitava as mesmas funcionalidades que Corba, contudo, com o apoio de fabricantes, em pouco tempo surgiram boas ferramentas e aplicaes neste suporte. Alm disto, a Sun Microsystems criou o suporte Java/IDL para comunicar Java com Corba, isto permitia que desenvolvedores utilizando Corba pudesse at mesmo migrar para Java e continuar o desenvolvimento em RMI.

Observando o lado promissor da tecnologia Java/RMI a Sun Microsystems desenvolveu um padro chamado J2EE (Java 2 Enterprise Edition). Com isto, a empresa segmentou a tecnologia Java e comeou cada vez mais a se preocupar com o mercado de aplicaes distribudas. J2EE uma arquitetura que utiliza a mesma pilha de protocolos de Java/RMI o que permite comunicao com Corba, e alm disto, permite continuidade aos desenvolvedores Java/RMI. Nesta tecnologia uma srie de suportes foram oferecidos. Programar para um ambiente distribudo tornou-se mais simples, pois uma base slida de componentes haviam sido desenvolvidos para isto. Diversos fabricantes se interessaram pela arquitetura J2EE, mais ferramentas de desenvolvimento foram lanadas e o mercado aumentou sua aceitao para esta tecnologia. Dentre os fabricantes destaca-se a Oracle, IBM, Sun Microsystems, Bea Systems, etc.

Observando a conquista do mercado pelo J2EE, a Microsoft no se agentou e lana sua prpria tecnologia para o desenvolvimento de aplicaes distribudas. Esta tecnologia proprietria e no um padro aberto tal como Corba e J2EE, por isto, somente a Microsoft a oferece.

O mercado atual tem se voltado cada vez mais para a tecnologia Java, e dentro deste enfoque a arquitetura para sistemas distribudos a J2EE. Apesar da grande evoluo desta arquitetura, o projeto de aplicaes distirbudas ainda exige conhecimentos adicionais dos desenvolvedores.

Cada vez mais desenvolver torna-se uma tarefa que exige estudos sobre conceitos e novas tecnologias, ao contrrio de estudar uma linguagem comum. O mercado tem optado por tecnologias baseadas em plataformas abertas e isto pode ser cada vez mais notado. Empresas como IBM e Oracle voltaram-se muito para este segmento de mercado, suportando sistemas operacionais livres como o Linux e partindo para a tecnologia Java. Aos poucos as empresas notam que tecnologias fechadas, tais como o Microsoft .NET, limitam o cliente, pois h a dependncia nica e exclusiva da Microsoft, ao contrrio do J2EE que oferecido por vrios fabricantes. No se encontrar neste mercado promissor algo que preocupa muitos projetistas e desenvolvedores. Portanto, conhecer uma tecnologia como J2EE necessrio e abre caminhos, no s no cotidiano de escrita de cdigo, mas sim nas tcnicas e escolha das melhores arquiteturas e opes para desenvolvimento.

J2EE, ou Java 2 Enterprise Edition, uma plataforma para desenvolvimento de aplicaes distribudas. Apresenta facilidades para a utilizao dos recursos computacionais e distribudos tais como acesso banco de dados, componentes Web, utilizao de mensagens assncronas, execuo de processos transacionais, persistentes ou no etc. Apresenta uma API, especificada pela Sun MicroSystems, que proporciona um padro para a implementao dos diversos servios que oferece, sendo que isto pode ser feito diferentemente por vrias empresas, de formas distintas mas ainda assim oferecendo as mesmas facilidades, por estarem de acordo com as especificaes impostas para a sua construo. Para um programador que j tenha tido contato com a linguagem Java e suas APIs na J2SE (Java 2 Standart Edition), este no ter muitas dificuldades no entendimento e na utilizao de J2EE. O que precisa-se entender os detalhes da arquitetura e onde se encontram cada componente e seus recursos, isto , se faz necessrio se ambientar neste contexto para se fazer o uso correto da plataforma.

A arquitetura J2EE se apresenta em vrias camadas, sendo que cada camada composta por componentes e servios que so providos por um container. A idia de container e componentes pode ser facilmente entendida por meio de um exemplo. Imagine uma colmia de abelhas, que contm abelhas obviamente, pulpas, zanges, a abelha rainha, o mel real etc. Podemos fazer um paralelo e entender como container a colmia, que fornece recursos para as abelhas sobreviverem. Por sua vez, as abelhas em suas diferentes funes, tais como as operrias e as reprodutoras, podem ser vistas como os componentes que sobrevivem dentro do container, isto , a colmia. Podemos ainda expandir esse exemplo em um apirio, imaginando que cada colmia seja um container e todas as colmias juntas, ou seja, o apirio, represente o servidor J2EE. Outro exemplo um pouco mais tcnico, o uso de pginas HTML em um Web Browser em uma simples navegao em um site qualquer. Podemos entender como container, o prprio navegador que fornece recursos e facilidades para o componente, neste caso as pginas HTML. O componente por sua vez, pode oferecer diversos servios ao usurio, atravs do suporte do container, tais como facilidades visuais como botes, hiperlinks, figuras e tabelas, e o prprio servio de navegao. Em um servidor J2EE, podemos ter diversos containers interagindo entre si. Veremos a seguir uma breve explicao de cada camada da arquitetura e de seus componentes. Camada cliente: acesso por meio de interfaces stand-alone (aplicaes Java), pginas HTML ou Applets. Nesta camada os componentes residem em um Applet Container, em um HTML container (Web browser) ou em um Application Client Container. O Applet container, fornece recursos para um componente Applet executar e se tornar funcional para o usurio. O Web Browser apresenta recursos e funcionalidades para o uso de pginas HTML e por fim o Application Client container fornece recursos para a execuo das classe stand-alone utilizadas pelos usurios para interagirem no sistema. Camada Web: esta camada implementada por JSPs e Servlets, que fornecem a lgica para a camada cliente ( ou de apresentao ) do negcio. JSPs e Servlets residem no Web Container. JSPs oferecem a facilidade de utilizar algumas lgicas de apresentao em uma

pgina web sem muitas dificuldades tecnolgicas. O Servlet apresenta-se como um controlador das aes executadas pelos usurios nas pginas de apresentao, e fornece recursos para obtr dados dessas aes e realizar as operaes desejadas. Os componentes Web residem no Web Container que pode ser um servidor TomCat ou outro similar. Camada de Negcios: esta camada trata da lgica de negcio da aplicao. nela que implementa-se todas as regras de negcio, alocao de recursos, persistncia de dados, validao de dados, gerencia de transaes e segurana, providos por componentes conhecidos por EJBs. Este por sua vez residem no EJB Container. Camada EIS - Enterprise Information System, ou Sistema de informaes empresariais: nesta camada que se encontram os sistemas de banco de dados, sistemas legados, integrao com outros sistemas no J2EE etc.

Figura 11.1 Camadas, seus respectivos componentes e containers e a intera o entre eles.

Para obter o kit de desenvolvimento para J2EE, acesse o site da Sun MicroSystems em J2EE - e faa o download do J2SDKEE e de suas documentaes. A sua instalao segue praticamente o mesmo esquema da verso J2SE. Por fim se faz necessrio a criao da varivel de ambiente . Inclua tambm o diretrio na varivel de ambiente PATH. Para acessar a biblioteca J2EE, aponte o classpath da sua aplicao para o diretrio . Os pacotes desta API tem o prefico javax e nele podem ser encontrados todos os recursos disponveis para a especificao J2EE. Utilizaremos para a execuo dos nossos exemplos, o servidor de aplicaes da Sun MicroSystems, que tambm faz parte do kit J2EE e pode ser acessado no diretrio . Um outro aplicativo muito til a ser utilizado para realizar a instalao dos componentes no servidor ser o deploytool, tambm disponvel no kit e acessado no mesmo diretrio.

Enterprise JavaBeans so objetos distribudos que apresentam uma estrutura bem definida, isto , implementam interfaces especficas e que rodam no lado do servidor. Tambm so conhecidos como EJBs (Enterprise JavaBeans) e sero tratados dessa forma neste livro. So nada mais do que simples objetos que devem seguir algumas regras. Estas regras foram definidas pela Sun MicroSystems atravs da especificao de EJBs na arquitetura J2EE. Apresentam mtodos para a lgica de negcio e mtodos que tratam da criao (instanciao), remoo, atualizao do EJB entre outros, dentro do ambiente aonde sobrevive. (Isto ser abordado durante o livro no tema ciclo de vida do EJB). Conforme definido pela Sun MicroSystems Enterprise JavaBean uma arquitetura para computao distribuda baseada em componentes ... Devemos entender que EJBs, no so simples classes Java, mas sim componentes distribudos que fornecem servios e persistncia de dados, alm de processamento assncrono e que podem ser invocados remotamente.

EJBs so normalmente utilizados para executarem a lgica de negcio do lado do servidor de forma distribuda. Podemos ter EJBs sobrevivendo em ambientes distintos, em mquinas diferentes, em locais geograficamente diversos e ainda assim utilizando de servios eficientes. Utilizando EJBs, sua aplicao ir se beneficiar de servios como transaes, segurana, tolerncia a falhas, clustering, distribuio, controle de sesso entre outros. Estes servios so fornecidos pelo ambiente que o EJB sobrevive, o container EJB, que ser visto em mais detalhes nos captulos seguintes. EJBs residem em um mundo chamado container. Este local conhece muito bem a interface implementada pelos EJBs e sendo assim, consegue tratar cada tipo de EJB diferente um do outro e de forma correta. Veremos mais adiante que o cliente que deseja utilizar um EJB, no acessa-o diretamente, mas sim utiliza-o atravs do container, que encaminha as chamadas de mtodo ao EJB e retorna a chamada ao cliente quando for necessrio. Vejamos a seguir como isto feito pelo container, implementando um exemplo de acesso remoto a um servio, utilizando a API de Sockets e o recurso de serializao de objetos.

Figura 11.2 Exemplo de servi o e troca de objetos utilizando Sockets e Serializa o. Os tipos de Enterprise JavaBeans especificados at a edio deste livro so: Session Bean : Stateless e Stateful Entity Bean : Bean-Managed Persistence e Container-Managed Persistence Message-Driven Bean Um EJB Session Bean prov servios, isto , define mtodos de negcio que podem ser acessados remotamente e que disponibilizam operaes relevantes aplicao. O tipo Session Bean Stateless no apresenta um estado como o prprio nome j diz, e fornece servios para clientes locais e remotos. O EJB Session Bean Stateful, tambm fornece servios localmente ou remotamente, mas apresenta uma relao forte com um cliente, isto , mantm o estado que um cliente define, assim este cliente pode configurar e recuperar dados deste EJB. Os EJBs Entity Beans representam entidades, objetos que so persistidos. Podem apresentar a manipulao e persistncia do objeto de duas formas: BMP ou CMP. No tipo BMP (BeanManaged-Persistence), o cdigo de persistncia e manipulao do objeto deve ser fornecido pelo Bean, isto , deve ser programado. J o tipo CMP (Container-Bean-Managed) provido pelo prprio container, no tendo a necessidade de escrever linhas de cdigo para estas operaes. Message-Driven-Bean so EJBs que fornecem servios assncronos e podem ser comparados a Session Beans Stateless, que tambm fornecem servios aos clientes locais e remotos, mas de forma assncrona. Um EJB do tipo Message-Driven-Bean se comporta como um listener que aguarda o recebimento de mensagens atravs de um MOM (Middleware Oriented Message). Detalhes de cada tipo de EJB sero vistos na Parte II Tipos de Enterprise JavaBeans.

Cada tipo de EJB deve implementar interfaces diferentes e definidas pela API J2EE. Estas interfaces definem o comportamento que o EJB deve apresentar. Alm de implementar uma interface definida pela API, devemos criar duas interfaces que sero utilizadas pelos clientes para acessarem os EJBs. Estas interfaces so conhecidas como e e devem ser definidas para os EJBs do tipo

(Stateless e Stateful) e Entity Bean (BMP e CMP). Para EJBs do tipo no precisamos definir nenhuma interface e conforme veremos em um prximo captulo. No se preocupe com detalhes destas classes e interfaces neste momento, pois logo adiante detalharemos cada uma delas, nos tipos especficos de EJB.

O acesso remoto utilizado quando o EJB e o cliente esto em mquinas diferentes. Se o cliente e o Enterprise JavaBean estiverem na mesma mquina o acesso remoto ser realizado igualmente. Acessamos um Enterprise JavaBean na mesma mquina ou em outra mquina da mesma forma (transparncia). Para criarmos um Enterprise JavaBean com acesso remoto, devemos implementar a interface Remote e a interface . A interface define os mtodos de negcio especficos do EJB e a interface define os mtodos do ciclo de vida do EJB. Para os Entity Beans a interface tambm define os mtodos de busca (create e finders).
<< Interface >> javax.ejb.EJBHome getEJBMetaData() getHomeHandle() remove() remove()

java.rmi.Remote

Figura 11.3 Diagrama de Classes UML da Interface Home.

<< Interface >> javax.ejb.EJBObject getEJBHome() getHandle() getPrimaryKey() isIdentical() remove()

java.rmi.Remote

Figura 11.4 Diagrama de Classes UML da Interface Remote. No acesso local, o cliente e o EJB devem estar na mesma JVM. O acesso ao EJB no transparente, dessa forma devemos especificar que o acesso local. O acesso local pode ser usado em vez do remoto para melhora no desempenho do negcio, mas deve-se fazer isto com cautela, pois um EJB definido como acesso local no pode ser executado em container em forma de cluster, isto , no pode ser acessado remotamente de forma alguma. Para criarmos um Enterprise JavaBean com acesso local, devemos implementar a interface Local e a interface . A interface define os mtodos de negcio especficos do EJB (assim como a interface Remote) e a interface define os mtodos do ciclo de vida do EJB (assim como a interface ). Para os Entity Beans a interface tambm define os mtodos de busca (finders).
<<Interface>> javax.ejb.EJBLocalHome

remove()

Figura 11.5 - Diagrama de Classes UML da Interface LocalHome

<<Interface>> javax.ejb.EJBLocalObject getEJBLocalHome() getPrimaryKey() remove() isIdentical()

Figura 11.6 - Diagrama de Classes UML da Interface Local Para um EJB do tipo , no precisamos implementar nenhuma dessas interfaces porque, como veremos no Cap tulo 5 Message-Driven Beans, este tipo de Enterprise JavaBean apresenta um comportamento diferente de um Session Bean e um Entity Bean, proporcionando processamento assncrono. O que precisamos fazer implementar uma interface de Listener que ser associado ao MOM.
<<Interface>> javax.jms.MessageListener onMessage()

Figura 11.7 Diagrama de Classes UML da Interface Listener.

Como podemos observar ao longo dos tpicos explicados at este ponto, vimos que os componentes EJB no so acessados diretamente, isto , no acessamos a instncia do Bean diretamente, mas fazemos o acesso aos servios disponveis por eles atravs de interfaces que so disponibilizadas para acesso remoto ou local. Outro detalhe que pode ser observado, que apesar de utilizarmos as interfaces de um componente EJB para acessar seu mtodos, vimos que a implementao dos seus servios oferecidos, isto , o Bean no implementa as interfaces oferecidas por ele. Bem, conhecendo a definio de interfaces e herana devemos nos perguntar: Por que o Bean no implementa as interfaces locais e remotas? E no implementando estas interfaces, como possvel acessar os mtodos contidos no Bean? Esta pergunta pode ser respondida simplesmente pela explicao de como o container se comporta com os componentes EJB. Cada fabricante de servidores de aplicao prov a implementao para as interfaces remote e home definidas para o componente e que so respectivamente as classes e . A classe implementa a interface remote para os acessos remotos e locais e encapsula (wraps) a instncia do EJB que foi solicitada pelo cliente. O criado baseado nas informaes contidas nos arquivos de deploy e na classe de Bean. No caso da classe EJB Home, esta se comporta da mesma forma que a classe . Ela implementa todos os mtodos da interface home para os acessos remotos e locais e ajuda o container a gerenciar o ciclo de vida do Bean, tais como sua criao, remoo etc.

Quando um cliente solicita uma instncia de um EJB atravs da interface home pelo mtodo , a classe cria uma instncia da classe que faz referncia instncia do EJB solicitado. A instncia do EJB associada com a classe e o mtodo implementado no Bean chamado. Depois que a instncia criada, a classe retorna uma referncia para a interface (o stub) da classe para o cliente. Com a referncia da interface remota, o cliente pode executar os mtodos de negcio do Bean. Estas chamadas so enviadas do stub para a classe que repassa as chamadas para os mtodos corretos na instncia do Bean. No caso de retorno de valores nos mtodos, o mesmo faz o caminho de volta pelo mesmo caminho utilizado na chamada do mtodo, retornando os valores para o cliente.

Figura 11.8 Cliente acessando o servidor EJB, com as classe EJB Home e EJB Object (encapsulando o EJB).

Construir um EJB pode parecer difcil, mas apesar de ser uma tarefa demorada, no apresenta uma complexidade muito elevada. Esta demora pode ser diminuda utilizando de ferramentas que propiciam a sua criao de uma forma automatizada. Primeiro se faz necessrio identificar qual tipo de EJB, ou quais tipos de EJB sero necessrios para uma determinada aplicao. Definido os EJBs que faro parte da aplicao, deve-se definir os mtodos de negcio de cada um deles, ou seja, definir o comportamento de cada um. Aps isso, comeamos o desenvolvimento do EJB. Com os EJBs definidos, e assim, com seus mtodos de negcio definidos, devemos criar as interfaces necessrias que sero usadas pelos clientes para o acessarem. No caso de Session Beans ou Entity Beans, devemos definir a interface (ou Local caso o acesso seja somente local) com os mtodos de negcio do EJB. Logo aps, definimos a interface (ou para acesso local) com os mtodos do ciclo de vida do EJB, isto , normalmente com os mtodos de criao do EJB e mtodos de busca (utilizados em Entity Beans e conhecidos como finders). Como j foi dito, para o EJB Message-Driven Bean no precisamos definir as interfaces Home (ou ) e (ou Local), pois o mesmo se comporta diferentemente dos outros EJBs.

Por fim, devemos criar o EJB propriamente dito, implementando a interface especfica de cada tipo de EJB e codificando cada mtodo de negcio. Depois de ter construdo os EJBs necessrios para uma aplicao, devemos empacotar os mesmo em um arquivo, ou em arquivos separados. Para empacotar um Enterprise JavaBeans, devemos utilizar do utilitrio jar, que fornecido juntamente com o JSDK e que facilita a criao do Java Archive (JAR). Com uma linha de comando e alguns argumentos, empacotamos os EJBs em arquivos JAR. Observe que um arquivo JAR pode ser instalado tranqilamente em um servidor de aplicao, mas h um outro tipo de arquivo, que empacota todos os recursos da aplicao alm dos EJBs, em um mesmo arquivo. Este arquivo conhecido como EAR (Enterprise Archive) e contempla arquivos JAR, arquivos WAR (Web Archive), arquivos RAR (Resource Adapters Archive), arquivos de configurao, figuras entre outros recursos. extremamente aconselhvel o uso deste tipo de arquivo, para a instalao de aplicaes Enterprise, conforme especificado pela Sun MicroSystems. Estas operaes sero descritas com mais detalhes na Parte III Instalando e Executando EJB. Aps ter feito isso, podemos instal-los em um servidor de aplicao. Note que o processo de instalao de um EJB nos servidores de aplicao variam de acordo com cada fabricante, ento sugerido uma leitura da documentao do servidor de aplicao especfico. Para acessar um EJB, precisamos criar um cliente que consiga localizar o EJB onde ele est residindo (servidor de aplicao - container), obtr uma referncia ao EJB remoto ou local e obtr uma instncia para acessarmos os mtodos de negcio do EJB. Claro que para o EJB do tipo Message-Driven Bean, como apresenta um comportamento diferente e se prope a solucionar um problema diferente, utilizamos seus servios de forma diferente tambm. No caso mais comum devemos realizar um lookup, isto , procurar pelo EJB no servidor de aplicao que ele est instalado. Quando criamos um EJB, definimos um nome para ele, e este nome ser utilizado pelo cliente para localizar o EJB. Com a referncia do EJB em mos, podemos acess-lo pela sua interface (ou ), obtr uma referncia para a interface (ou ) e executar os mtodos de negcio desejados. Lembre-se que o acesso ao EJB pelo cliente realizado atravs das interfaces e , sendo que o acesso diretamente instncia do EJB propriamente dito de responsabilidade do container, que opera sobre o Enterprise JavaBean e executa seus mtodos e retorna valores, atravs das solicitaes dos clientes, por meio das interfaces (stubs e skeletons). Session Beans so componentes que apresentam servios para seus clientes. Estes servios so fornecidos para o cliente pelas interfaces do EJB Session Bean e implementadas pelos mtodos de negcio no prprio Bean. O estado do objeto Session Bean consiste no valor da instncia de seus atributos, sendo que estes no so persistidos. Imagine que uma aplicao necessite realizar alguns clculos e retornar este valor para o cliente, sendo que deseja-se que este servio seja remoto para ser acessado por vrios clientes pelo pas. Isto pode ser implementado por um EJB do tipo Session Bean e disponiblizado em um servidor de aplicaes para todos os clientes. Este um exemplo de utilizao de um Session Bean. Mais adiante veremos os cdigos fonte de Session Bean exemplo.

Figura 12.1 Diagrama de Classes UML do Session Bean. Analisando o diagrama de classes acima temos uma classe e duas interfaces. A classe do EJB Session Bean ( ) e as interfaces ( ) e (Home). Para cada classe do Bean devemos definir as interfaces ( e/ou e e/ou ). No exemplo acima, foram definidas as interfaces e , mas poderiam ter sido definidas as interfaces e ou todas elas (com isto teramos acesso local e remoto ao mesmo EJB). O Bean deve conter os mtodos definidos para um EJB Session Bean conforme a API J2EE que so: , , , e . Tambm devem apresentar os mtodos de negcio com suas devidas implementaes que sero os servios disponibilizados pelo EJB. Na interface do EJB devemos definir o mtodo , que ser utilizado pelo cliente para solicitar ao container que crie uma instncia do Bean e fornea uma referncia para acessar os seus servios ou os mtodos de negcio atravs da interface . Interface Home : SBExampleHome Na interface do EJB devemos definir os mtodos de negcio que fornecero ao cliente os servios disponibilizados pelo Bean. Estes mtodos tem a mesma assinatura tanto na interface quanto na prpria implementao do Bean. A seguir veremos como poderia ser definido esta interface, com um exemplo de servio fornecido pelo Bean, para calcular o valor de um desconto informando alguns parmetros.

Interface Remote: SBExample.

A seguir apresentamos a implementao do Bean deste exemplo.

Bean: SBExampleBean.

Para obter este servio, o cliente deve realizar a localizao do EJB no servidor de aplicao utilizando a API JNDI, solicitar uma referncia para a interface do EJB e com ela executar o mtodo de ciclo de vida: . Assim, o cliente ter acesso interface Remote que apresenta os mtodos de negcio, isto , os servios disponveis para o EJB e dessa forma, poder executlos para as operaes desejadas. Maiores detalhes de localizao e obteno das referncias para as interfaces, sero vistas no Ap ndice A que apresentar exemplos mais detalhados de EJB e a utilizao de cada servio, alm de especificar os arquivos de instalao (deployment descriptors). At aqui introduzimos o EJB Session Bean, mas ainda no detalhamos os dois tipos de Session Bean que sero vistos nos prximos tpicos e que so: Session Bean Stateless Session Bean Stateful

Deve-se utilizar um Session Bean quando deseja-se prover servios a seus clientes, sendo que estes servios sejam transacionais e seguros, rpidos e eficientes. Session Beans apresentam uma forma de executar a lgica de negcio do lado do servidor, com todos os ganhos que um servidor de aplicao apresenta e vistos nos captulos anteriores dessa segunda parte do livro.

Um Session Bean no mantm o estado cliente em particular. invocamos um mtodo, de suas variveis se apenas durante a deste mtodo. Quando finalizado o estado retido. So componentes que no associados a um cliente e, portanto, implementam comportamentos que necessidade de muitos

Stateless para um Quando o estado mantm invocao o mtodo no esto especfico

atendem a clientes.

Session Bean

Stateless:

SBStatelessExampleBean.
A figura 12.2 representa o ciclo de vida de um Session Bean Stateless. 1. 2. Class.newInstance() setSessionContex t()

3.

ejbCreate()

Figura 12.2 Ciclo de vida de um Session Bean Stateless. Assim que o servidor de aplicaes inicializado, no existem beans instanciados, ento, dependendo das polticas de pooling adotadas, o container instancia o nmero definido de beans. Caso o container decida que precisa de mais instncias no pool, instancia outros beans. Os beans no pool devem ser equivalentes (porque so Stateless), pois eles podem ser reutilizados por diferentes clientes. Quando o container decide que no precisa mais de instancias no pool, ele as remove.

EJB Session Bean Stateful so componentes que mantm o estado dos seus atributos e um relacionamento forte com o cliente que o utiliza. Se a execuo termina ou se o cliente solicita a remoo da instncia deste EJB para o container, a sesso finalizada e o estado perdido, isto , o valor dos atributos configurados pelo cliente para este EJB so perdidos e em uma prxima utilizao estaro com seus valores nulos. Este tipo de Session Bean, diferente do Session Bean Stateless, mantm os valores dos atributos entre vrias chamadas aos seus mtodos de negcio (ou servios), sendo assim, o cliente pode configurar os valores dos atributos do Bean atravs dos mtodos setters e assim o EJB pode utilizar estes valores para os mtodos de negcio.

Session Bean Stateful : SBStatefulExampleBean.

O diagrama a seguir, figura 12.3, representa o ciclo de vida de um Session Bean Stateful. Temos as transies entre estado ativo e passivo, nos quais o bean deixa de ser utilizado por um tempo e fica aguardando novas chamadas do cliente quando esta passivo, e ativo quando volta a ser utilizado pelo cliente. Nestes dois momentos, podese liberar os recursos alocados para determinado bean que se tornar passivo, e obter estes recursos quando o bean se tornar ativo.

Figura 12.3 Ciclo de vida de um Session Bean Stateful. Entity Bean so Beans de Entidade, isto , representam entidades persistentes. Em outras palavras, so componentes de negcio com mecanismo de persistncia de dados. O estado do Entity Bean pode ser persistido em um banco de dados relacional, arquivo XML alm de outros tipos de repositrios de dados. Isto quer dizer que o estado do Entity Bean mantido alm do tempo de vida da aplicao ou do servidor J2EE. Esta uma caracterstica muito til em situaes onde deseja-se utilizar os dados desta entidade em momentos que seria invivel mante-los em memria. Existem dois tipos de Entity Beans: Bean-Managed Persistence. Container-Managed Persistence.

Figura 13.1 Diagrama de Classes UML do Entity Bean. Deve-se utilizar o EJB do tipo Entity Bean quando seu estado precisa ser persistido. Se a instncia do EJB no estiver ativa ou se o servidor de aplicaes for derrubado, pode-se recuperar o estado do mesmo, pois estar persistido na base de dados. O que torna os Entity Beans diferentes dos Sessions Beans que primeiramente o estado do Entity Bean salvo atravs de um mecanismo de persistncia, alm disso possui uma chave primria que o identifica.

Utilizando esta estratgia, a codificao das chamadas de acesso base de dados esto na classe de negcios do EJB e so responsabilidade do desenvolvedor. Ento, para os mtodos de busca (mtodos utilizados para encontrar Entity Beans na base de dados) e para os mtodos de criao, remoo e atualizao dos Entity Beans, devese codificar os comandos responsveis por realizar estas operaes. O Entity Bean BMP - Bean de Entidade com Persistncia Gerenciada pelo Bean oferece ao desenvolvedor a flexibilidade de desenvolver as operaes de persistncia de dados que em alguns casos, podem ser complexas de serem implementadas pelo container. Esta estratgia demanda mais tempo de desenvolvimento e alguns autores sugerem que se utilize a estratgia de persistncia CMP (Container-Managed-Persistence), que ser vista a seguir. Detalhes de implementao de um EJB Entity Bean BMP, assim como os deployment descriptors sero vistos no Ap ndice A.

Entity Bean BMP: EBBMPExampleBean.

A figura 13.2, representa o ciclo de vida dos Entity Beans BMP. Todos os mtodos so chamados pelo container para o bean. Para criar um novo Entity Bean utilizado o mtodo create e para remov-lo necessrio executar o mtodo . Pode-se carregar um Entity Bean usando os mtodos de busca do entity bean ( , ). Quando o bean ativado, ele carrega o dado do meio de persistncia e quando desativado, persiste o dado no meio de persistncia.

mtodos de negci o ou ejbFin d()

Figura 13.2 Ciclo de vida BMP Entity Bean.

Entity Beans CMP (Bean de Entidade com Persistncia Gerenciada pelo Container) oferecem mais rapidez e facilidade no desenvolvimento de objetos persistentes pois o desenvolvedor no precisa escrever os comandos para persistir e manipular os dados. O container se encarrega de realizar estas operaes e retornar os valores desejados. Ele faz isso para as operaes triviais tais como insero do objeto, remoo, atualizao e seleo pela chave- primria ( , , e respectivamente). Para as operaes especficas de consulta a objetos persistidos, se faz necessrio o uso de uma linguagem de consulta conhecida como EQL (EJB Query Language). Os detalhes desta linguagem sero vistos a seguir. Estas operaes devem ser definidas no arquivo de deploy do componente ( l) utilizando-se de EQL para cada operao desejada. Neste arquivo define-se os campos que sero persistidos e os relacionamentos entre Entity Beans. Detalhes de implementao de um EJB Entity Bean CMP, assim como os deployment descriptors sero vistos no Ap ndice A.

Entity Bean CMP: EBCMPExampleBean.

A Figura 13.3, representa o ciclo de vida do Entity Bean CMP. Ele praticamente o mesmo de um Entity Bean BMP, sendo que a nica diferena que pode-se chamar o mtodo ejbSelect(), tanto nos beans que esto no pool quanto nos que esto ativos.

mtodos de negcio ou ejbFind() e ejbSelect()

Figura 13.3 Ciclo de vida CMP Entity Bean. Um entity bean pode se relacionar com outro, como um relacionamento entre duas tabelas de um banco de dados relacional. A implementao de um relacionamento para entity beans BMP feita por meio da codificao na classe de negcio do EJB, enquanto para os entity beans CMP o container se encarrega de oferecer os mecanismos de relacionamento atravs dos elementos de relacionamento definidos no deployment descriptor.

Um relationship field equivalente a uma chave estrangeira em uma tabela de um banco de dados relacional e identifica um entity bean atravs do relacionamento.

Existem quatro tipos de multiplicidades: 1 1: Cada instncia de um entity bean pode se relacionar com uma nica instncia de outro entity bean. Por exemplo, um entity bean marido tem um relacionamento com o entity bean esposa, supondo que esta relao ocorra numa sociedade onde no permitido a poligamia. 1 N: Uma instncia de um entity bean pode se relacionar com mltiplas instncias de outro entity bean. O entity bean gerente, por exemplo, tem um relacionamento com o entity bean empregado, ou seja, um gerente pode ter vrios empregados sob seu comando. N 1: Mltiplas instncias de um entity bean podem se relacionar com apenas uma instncia de outro entity bean. Este caso o contrrio do relacionamento , ou seja, o entity bean empregado tem um relacionamento com o entity bean gerente. N M: Instncias de entity beans podem se relacionar com mltiplas instncias de outro entity bean. Por exemplo, em um colgio cada disciplina tem vrios estudantes e todo estudante pode estar matriculado em vrias disciplinas, ento o relacionamento entre os entity beans disciplina e estudante .

Um relacionamento entre entity beans pode ser bidirecional ou unidirecional. Num relacionamento bidirecional cada entity bean tem um campo (relationship field) que referencia outro entity bean. Atravs deste campo um entity bean pode acessar o objeto relacionado.Em um relacionamento unidirecional, apenas um entity bean tem o campo referenciando outro entity bean.Consultas em EJB-QL podem navegar atravs destes relacionamentos. A direo dos relacionamentos determina quando a consulta pode navegar de um entity bean para outro. Sendo um relacionamento bidirecional as consultas EJB-QL podem navegar nas duas direes acessando outros entity beans atravs dos campos de relacionamento. A tag no arquivo ejbjar-xml define o nome do campo do relacionamento e na classe abstrata do entity CMP teremos os respectivos mtodos abstratos e relacionados a este campo. Os tipos que um mtodo get como esse retorna o tipo da interface local do objeto relecionado sendo um relacionamento , caso o relacionamento seja o tipo retornado pode ser ou ou . Sempre que tivermos campos de relacionamento no entity bean no devemos invocar o seu mtodo set no , ele deve ser invocado no mtodo ou atravs dos mtodos set e get que estiverem disponveis na interface local. Exemplos: Relacionamento bidirecinal:

Esposa
marido

Marido
esposa

Figura 13.4 Relacionamento Bidirecional Entity Bean CMP.

Neste caso podemos ver que os dois entity beans podem navegar e acessar as informaes sobre o entity bean relacionado, s para visualizar iremos agora mostrar como ficariam as configuraes no deployment descriptor.

Na verdade no ser precisa digitar todo esse cdigo xml para criarmos os relacionamentos pois existem ferramentas que fazem isso por voc, mas voc deve ter idia de como funciona e o que configurado nesse arquivo. A tag configura o nome do campo do ejb nos quais sero criados os mtodos get e set que estaro disponveis na interface local, caso configuramos a multiplicidade , se fssemos configurar por exemplo deveramos trocar a tag para many e acrescentaramos a tag como o exemlo mostra a seguir:

Neste caso voc pode escolher se o tipo retornado ser

ou

Esposa
marido

Marido

Figura 13.5 Relacionamento Unidirecional Entity Bean CMP. Aqui temos um relacionamento unidirecional onde apenas a esposa pode encontrar o marido, o marido no capaz de recuperar informaes das mulheres por meio do relacionamento. Neste caso a tag no deployment descriptor no estar configurada no lado em que definimos o relacionamento do lado do EJB marido. EQL ou EJB-QL a linguagem portvel utilizada para construir os mtodos de consulta dos EJBs CMP de acordo com a especificao 2.0. Esta linguagem no utilizada para os EJBs BMP, pois os mesmos utilizam a API JDBC, ou outro mecanismo de persistncia para acesso base de dados.

Devemos utilizar EQL para implementar os mtodos de busca de seus Entity Beans CMP que no seja a partir de sua chave-primria ( ), pois este j oferecido automaticamente pelo container.

Um comando EJB-QL contm trs partes: Uma clusula SELECT Uma clusula FROM Uma clusula opcional WHERE

A clusula ela define o domnio de uma consulta, indica qual parte de uma base de dados voc ir consultar. No caso de uma base de dados relacional, a clusula tipicamente restringe quais tabelas sero consultadas. Por exemplo:

Aqui estamos declarando uma varivel na clusula . Esta varivel o pode ser usada posteriormente em outras clusulas desta mesma consulta, neste caso estamos reusando a varivel na clusula . Algumas vezes precisamos declarar variveis na clusula valores: que representa um conjunto de

A frase o declara a varavel o que representa os entity beans , e a frase a declara a varivel a que representa uma coleo de items do entity Bean . Ento AS usado quando a varvel declarada representa um nico valor e usado quando a varivel representa uma coleo de valores. A Clusula restringe o resultado da consulta, voc escolhe os valores desejados a partir das variveis declaradas na clusula :

Esta consulta recupera todas as pessoas que possuem o atributo nome igual ao parmetro que ser passado no mtodo. Por exemplo, o mtodo poderia ser construdo da seguinte forma: Para ultizar collections na clusula voc precisa declar-la primeiramente na clulua :

Algumas vezes voc pode declarar mais de uma varavel que representa o mesmo entity bean. Quando fazemos comparaes este artifcil muito til:

A clusula

especifica o resultado retornado pela consulta. Por exemplo:

Na consulta so definidas duas variveis p e a, a clusula select determina qual deve ser selecionada. Neste exemplo a consulta retorna todos os produtos em todas as regras que contem items:

Como voc pode ver podemos utlizar o ponto para acessar relacionamentos na clusula . Este cdigo interpretado para um SQL-padro onde um JOIN feito para recuperar os dados desejados. Perceba que nest exemplo no utlizamos a notao , ele apenass utilizado quando se trata de uma varivel simples que no faz uso do ponto para acessar informaes por meio dos relacionamentos entre entity beans. Outra informao importante que a clusula no trabalha com collections, apenas aceita variveis simples, ou seja:

Esta query no est correta, a forma correta : Para filtrar as informaes, ou seja, no trecuperar informaes repetidas utlizado o filtro :

Voc pode tambm fazer que seu mtodo de busca retorne um que no permite que valores repetidos sejam inseridos. Agora a seguir temos um exemplo de como um mtodo definido no arquivo pode ser acessado por meio das interfaces e/ou do EJB. Na interface o mtodo estaria assim:

Este mtodo vai retornar todas as pessoas que tem o nome passado como parmetro. No arquivo temos:

So um tipo de componentes EJB que recebem mensagens por meio de um JMS (Java Message Service). Enquanto tradicionalmente os outros Beans so acessados atravs de interfaces (RMIIIOP) com acesso sncrono, os Message-Driven Beans, tambm conhecidos pela sigla MDB, so utilizados por meio de mensagens, com acesso assncrono. Isso se d por meio de um middleware orientado a mensagens (MOM), localizado entre o cliente, , e o bean, . Este middleware recebe mensagens de um ou mais clientes e envia as mensagens para os Beans destino. JMS a API utilizada para receber as mensagens dos clientes e enviar as mensagens aos Message-Driven Beans. O estado do objeto muito simples e semelhante a um EJB Session Bean Stateless que no mantm o estado para um cliente em particular. Quando enviamos uma mensagem para invocamos um Message-Driven Bean, o estado de suas variveis se mantm apenas durante a invocao. Quando o processamento requerido finalizado o estado no retido. So componentes que no esto associados a um cliente especfico e, portanto, implementam comportamentos que atendem a necessidade de muitos cliente.
<<EJBMessage>> MDBExampleBean EJB_Context : MessageDrivenContext = null MDBExampleBean() ejbCreate() onMessage() ejbRemove() setMessageDrivenContext()

Figura 14.1 Diagrama de Classes UML do Message-Driven Bean Message-Driven

Bean : MDBExampleBean.
Deve-se utilizar EJB Message-Driven Bean quando necessita-se de operaes assncronas sendo executadas no servidor (container). Observe que para realizarmos um processamento em paralelo no servidor sem o uso de Message-Driven Bean, era necessrio o uso de Threads em EJB Session Bean Stateless. Esta prtica desaconselhada pela prpria Sun MicroSystems Inc., pois recai em vrios problemas, um deles a falta de controle dessas execues por parte do container, perdendo assim as facilidades e ganhos que o container oferece. Para sanar este problema, foi criado o EJB Message-Drive Bean que pode ter vrias instncias de um mesmo componente sendo executados em paralelo, para realizar a mesma operao.

A Figura 14.2, representa o ciclo de vida do Message-Driven Bean. Ele bem simples comparado aos outros beans, pois o container instancia um determinado nmero de beans e os mantm no pool de acordo com as necessidades e removidas quando o container decidir, da

mesma forma que o Session Bean Stateless. Assim que uma mensagem recebida pelo JMS, ela redirecionada para um bean especfico, para que seja tratada.

1.

Class.newInstance()

2. 3.

setMessageDrivenContext() ejbCreate()

Figura 14.2 Ciclo de vida Message-Driven Bean.

Antes de falarmos a respeito de JMS, devemos enteder o conceito de Messaginig (envio de mensagens). Messaging pode ser entendido pela troca de mensagens entre duas aplicaes, programas ou componentes. Um cliente pode enviar mensagens para um ou mais receptores, que tambm pode retornar um outra mensagem, ou executar algum mtodo de negcio. Utilizando este recurso, o receptor de mensagens no precisa estar disponvel no mesmo momento que o cliente enviou a mensagem, podendo consumi-la, ou receb-la posteriormente, isto , no momento em que seu servio estiver ativo. Assim, o cliente que envia a mensagem e o receptor da mensagem devem somente conhecer bem o formato da mensagem, com os dados que ela carrega.

Para fazer uso destes recursos na linguagem Java, foi criada uma API conhecida como JMS Java Messaging Service. Esta API fornece servios que permitem a criao, envio, recebimento e leitura de mensagens. O importante a saber que um cliente cria uma mensagem e a envia utilizando esta API. Um receptor de mensagens, receber esta mensagem atravs de um Message-Oriented-Middleware ou MOM. Alguns conceitos muitos usados nas referncias a JMS so produtores e consumidores de mensagem (producers / consumers), para designar um cliente como um produtor de mensagens e um componente EJB Message-Driven Bean por exemplo, como um consumidor de mensagens. O caminho percorrido pela mensagem bem simples. Vamos ver isso na figura abaixo, na qual o produtor envia a mensagem, que recepcionada pelo MOM e a seguir redirecionada para o consumidor correto. Observe na figura, que o produtor tambm pode ser um consumidor de mensagens e que o consumidor de mensagens tambm pode ser um produtor.

P1

MOM
Figura 14.3 MOM.

P2

A arquitetura JMS composta por cinco partes que so: Provedor JMS, que implementa as interfaces definidas na API JMS e prov recursos para administrar esse servio; os clientes JMS que podem ser programas ou componentes que agem como produtores e consumidores de mensagens; as mensagens propriamente ditas que so objetos que transportam os dados do cliente para o receptor; os objetos de administrao do servio JMS que so utilizados pelos clientes para enviar as mensagens; e os clientes nativos que so clientes que usam produtos de Messaging nativos e no da API JMS. A seguir vamos detalhar os dois tipos de postagem de mensagens e enteder as diferenas entre eles. Point-to-Point Publish/Subscribe.

O conceito de mensagens Point-To-Point PTP de enfileirar as mensagens para serem consumidas. Os produtores enviam as mensagens para uma determinada fila (Queue), que so consumidas por um destinatrio. Assim que receber a mensagem, o destinatrio avisa ao MOM que a mensagem foi recebida e processada corretamente (sinal de acknowledge). A fila armazena todas as mensagens que so enviadas, at o momento que so consumidas pelos receptores, ou at o momento que forem expiradas. Observe ainda, que vrios consumidores de mensagens (muitas instncias do mesmo consumidor) podem consumir mensagens do MOM. Este recurso normalmente disponibilizado e gerenciado pelo servidor de aplicaes para processamento de mensagens em paralelo. O cliente pode enviar mensagens para o MOM, mesmo sem existir nenhum consumidor de mensagens ativo naquele momento.

Figura 14.4 Point-To-Point (Queue).

No uso de Publica/Inscreve os clientes enviam a mensagem para um tpico (topic). Os consumidores registram-se nos tpicos que lhes so convenientes e so notificados da chegada de uma nova mensagem. Os consumidores podem somente consumir mensagens que foro postadas depois de terem se registrado (inscrito) no MOM, isto , as mensagens enviadas pelos clientes antes disto, no podem ser consumidas por eles. Observe que neste caso, cada mensagem pode ter mais de um tipo de consumidor. Se algum cliente emviar uma mensagem para um tpico que no possue nenhum consumidor registrado, esta mensagem no ser entregue. Aps o consumidor se registrar, as mensagens que chegam ao MOM so notificadas aos consumidores, que fornece estas mensagens a eles. Por haver uma dependncia muito grande do tempo em que o consumidor deve estar ativo enquanto o cliente envia a mensagem, os consumidores podem fazer registros durveis ( ) e receber mensagens enviadas enquanto eles no estam ativos. Isto permite a facilidade de uma fila, com a diferena de consumo de mensagens por diversos tipos de consumidores.

Figura 14.5 Publish/Subscribe (Topic).

A seguir apresentamos um exemplo simples do envio de mensagens por um cliente e o recebimento das mensagens por um Message-Driven Bean .

Teste de envio de mensagens: TestClient Message-Driven Bean : TestMDB

A proposta inicial da API desenvolvida para a plataforma Java a de prover aos desenvolvedores os recursos bsicos de infra-estrutura e permitir que eles pudessem se concentrar na implementao das regras de negcio de suas aplicaes. Assim, foram disponibilizadas bibliotecas para trabalhar com colees, com entrada e sada de dados, com recursos de internacionalizao, entre outras. Esta idia foi utilizada novamente na especificao da plataforma J2EE, com o objetivo de prover implementaes para problemas recorrentes de aplicaes distribudas, agilizando seus tempos de desenvolvimento e permitindo que o foco do desenvolvimento fique nas regras de negcio a serem atendidas, deixando os recursos de infra-estrutura complexos a cargo dos fabricantes dos containers. Desta forma, h um aumento significativo nas chances das necessidades dos clientes serem atendidas e, por consequncia, os sistemas construdos serem bem sucedidos. Entre a gama de servios previstos na especificao da plataforma J2EE ligados aos Enterprise JavaBeans, sero abordados dois dos mais usados: transaes e segurana. O primeiro servio serve para garantir a integridade dos dados, permitindo que falhas e execues concorrentes no tornem as informaes gerenciadas pela aplicao inconsistentes. O segundo servio trata da proteo da aplicao com relao ao acesso no autorizado s funcionalidades disponibilizadas por ela.

Tipicamente os sistemas provem funcionalidades para seus clientes baseados em uma massa de dados armazenados em um meio peristente. A integridade das informaes armazenadas neste repositrio fundamental para o correto funcinamento do sistema e muitas vezes a perda de informaes pode causar prejusos para seus usurios. Os problemas relacionados a manuteno da integridade das informaes armazenadas em um meio persistente podem ser causados por fatores fsicos ou lgicos. Dentre os fatores fsicos podemos destacar a falta de energia eltrica durante o processamento de uma funcionalidade que envolva vrias operaes sobre os dados. J fatores lgicos esto relacionados com erros na programao do acesso concorrente aos dados, onde alteraes realizadas por um processo podem ser sobrepostas por outros processos executando de forma concorrente. Estes problemas so significativamente agravados quando estamos desenvolvendo em um ambiente distribudo. Uma vez que partes de nossas aplicaes podem ser executadas em mquinas diferentes, h a chance de uma delas quebrar sem que o restante da aplicao tenha conhecimento disto, fazendo com que uma operao realizada pela aplicao seja executada parcialmente, o que pode corromper os dados sendo manipulados. Tambm h a chance de uma infomao ser alterada por uma parte da aplicao sem que a outra seja notificada, o que tambm ocasiona resultados errneos. Como soluo a estes problemas, foi desenvolvido o conceito de transaes. Para tanto feito um agrupamento das operaes realizadas em uma determinada poro do software em uma unidade denominada transao, que apresenta quatro propriedades fundamentais, chamdas de ACID: Atomicidade - garante a completude da execuo das operaes de uma transao, ou seja, ou todas as operaes de uma transao so executadas ou nenhuma operao realizada. Caso no seja possvel completar uma operao aps outras terem sido executadas, deve ser possvel anular o efeito destas ltimas para atender a esta propriedade.

Consistncia - garante que o conjunto de operaes que compem uma transao nunca deixem o sistema em um estado inconsistente. Isolamento garante que a execuo de uma transao no seja afetada pela execuo de outra transao. Esta propriedade especialmente importante quando h aplicaes concorrentes que acessam os mesmos dados, uma vez que durante a execuo de uma transao os dados podem ficar temporariamente inconsistentes, levando outras transaes que utilizam estes dados a produzirem resultados incorretos e possivelmente violarem a propriedade de consistncia. Durabilidade - garante que os resultados obtidos em uma transao sejam armazenados em um meio persistente. Para ilustrar estas propriedades, vamos utilizar como exemplo uma transao bancria de transferncia de fundos de uma conta corrente para outra. Suponha a existncia da seguinte classe responsvel por realizar a transferncia:

Classe usada para demonstar propriedades transacionais.

A necessidade da primeira propriedade pode ser logo vista nas duas ltimas operaes do mtodo de transferncia entre contas correntes. Caso logo aps a primeira operao ser processada ocorra uma queda do sistema, por falta de energia eltrica, por exemplo, o montante ser reduzido da primeira conta mas no ser creditado na segunda. Isto significa que o montante iria simplesmente desaparecer, tornando a base de dados do sistema bancrio inconsistente. A segunda propriedade diz respeito demarcao dos limites da transao. Ela garante que uma transao conter um mtodo de negcio completo. Assim, no caso do mtodo de transferncia entre contas correntes, no seria possvel inclir a operao de dbito em uma transao e a de crdito em outra, pois neste caso ao final da primeira transao o sistema estaria inconsistente. O isolamento diz respeito a tornar a execuo em paralelo de transaes independentes. Como a consistncia s garantida no trmino de uma transao, possvel que durante sua execuo o sistema esteja num estado inconsistente (no exemplo esta situao seria atingida no momento aps a operao de dbito e antes da operao de crtido). Assim, caso uma outra transao seja iniciada enquanto uma primeira ainda no terminou, possvel que seus resultados no sejam corretos, uma vez que a premissa da consistncia que o sistema estaria inicialmente consistente.

A ltima propriedade trata da confirmao dos resultados efetuados pelas transaes. Neste caso, aps a confirmao das operaes, seus resultados so efetivamente armazenados em meios persistentes. Assim, garantido que em caso de falhas no sistema aps o encerramento da transao, seus resultados ainda podero ser vistos aps o restabelecimento do sistema.

O uso de transaes traz muitas vantagens e garante a integridade dos dados, mas h um custo alto em utiliz-las. Os controles que so utilizados para garantir as propriedades ACID podem tornar uma aplicao lenta de tal forma que se torne sua utilizao invivel. Assim, este recurso deve ser usado de forma consciente, ficando a cargo dos desenvolvedores determinar as operaes de negcio que necessitam de transaes e as que no. Ele tambm deve determinar a melhor forma de agrupar as operaes em transaes. Na especificao J2EE h duas formas do desenvolvedor informar aos containers EJB quais so as operaes transacionais e como elas devem se comportar com relao s outras: uma forma programtica e outra declarativa. A primeira forma consiste na incluso no cdigo fonte dos EJBs instrues para que as transaes sejam iniciadas e terminadas. Uma vez que o controle todo de quando as transaes iniciam e so concludas faz parte da especificao do bean, este tipo de delimitao chamada de BMT (Bean Managed Transaction). A forma declarativa de determinar os limites das transaes feita atravs de instrues nos arquivos descritores dos EJBs. Desta forma, o prprio container fica a par da existncia das transaes no momento do deploy e capaz de controlar sua execuo. Este tipo de transao chamado de CMT (Container Managed Transaction) e permite um elevado grau de flexibilidade para mudanas na poltica de controle de transaes da aplicao. Os dois tipos de transaes sero discutidos com detalhes nas prximas sees. Transaes BMT (Bean Managed Transactions) ou programadas permitem maior controle por parte do desenvolvedor, pois ele que insere em seu cdigo instrues que indicam o momento em que a transao foi iniciada, o momento em que ela foi concluda com sucesso ou que ocorreu um erro e a transao deve ser abortada. As instrues para o controle das transaes so disponibilizadas numa API chamada JTA (Java Transaction API). Ela permite o acesso transparente aos mais variados gerenciadores de transaes disponveis nos containers. A implementao da Sun para tal API o JTS (Java Transaction Service). A comunicao com um gerenciador de transaes se inicia com a obteno de uma referncia para a interface javax.transaction.UserTransaction, que feita atravs do contexto do EJB. Esta interface permite enviar comandos para delimitar o incio de uma transao (begin), concluso com sucesso (commit) ou solicitar que as operaes realizadas sejam descartadas pela ocorrncia de falhas (rollback). Abaixo um exemplo de uso de uma transao gerenciada pelo bean em um mtodo que realiza a transferncia de um montante de uma conta corrente para outra. Exemplo do uso de JTA

Este tipo de transaes pode ser utilizado apenas Session Beans e Message Driven Beans. Os Entity Beans exigem um maior controle do container sobre suas aes e portanto no tem disponvel o gerenciamento de transaes feito por ele prprio.

Transaes CMT (Container Managed Transactions) ou declarativas podem ser utilizadas com qualquer tipo de EJB. Neste tipo de transao no h a necessidade de programao explcita das delimitaes das transaes, esta tarefa efetuada automaticamente pelo prprio container. Para tanto, necessrio informar nos descritores dos EJBs a necessidade de suporte transacional s operaes e como ele deve gerenci-lo. Uma vez que no h a necessidade de incluso de cgido especfico para gerncia de transaes, a flexibilidade de mudana da estratgia de emprego deste recurso muito maior, pois basta alterar os descritores dos EJBs para atingir este objetivo. Abaixo est um exemplo de descritor que define a incluso de suporte transacional num EJB pra gerenciamento de contas bancrias: Exemplo de descritor - ejb-jar.xml:

O suporte a transaes definido dentro do assembly-descriptor. Nele so definidos, para cada mtodo do EJB, qual o seu atributo transacional. Observando o exemplo, verifica-se que para o EJB chamado so definidas dois blocos de transaes. No primeiro definido o atributo Required para todos os seus mtodos atravs do uso do wildcard *. Logo em seguida este atributo sobreposto para o mtodo transferenciaEntreCC, modificando o atributo para . O atributo transacional, citado acima, usado para dizer ao container como as transaes devem ser efetuadas quando os mtodos especificados so chamados. Deve-se levar em conta que o cliente do EJB, que pode uma aplicao Swing, um Servlet ou mesmo outro EJB, tambm pode estar usando transaes para efetuar suas tarefas e a chamada a um mtodo do EJB deve levar isto em conta. Tendo isto em mente, a segir sero mostrados os possveis atributos transacionais definidos na especificao EJB 2.0 e o comportamento do container para cada um

deles. Required (Requerido): Configura o bean (ou mtodo) para sempre executar em uma transao. Se a chamada for feita dentro de uma transao no cliente, a chamada de mtodo passar a fazer parte desta transao. Caso contrrio, uma nova transao criada. RequiresNew (Requer novo): Utilizada para que o mtodo do EJB sempre execute dentro de uma transao nova. Assim, o mtodo executar dentro de uma transao prpria que ser encerrada quando o mtodo termina sua execuo. Caso o mtodo seja chamado dentro de uma transao do cliente, esta suspensa, criada uma nova transao para o EJB, executada e finalizada, e s ento a transao do Cliente retomada. Mandatory (Mandatrio): Indica que o mtodo somente pode ser chamado dentro de uma transao do cliente. Diferente do Required, que caso o cliente no esteja numa transao cria uma nova, este atributo gera uma exceo se sua chamada no for dentro de uma transao. NotSupported (No Suportado): Usado para indicar que o mtodo no ir executar dentro de uma transao. o complementar do Required, ou seja, caso o cliente esteja ou no dentro de uma transao o mtodo ser executado sempre fora de uma transao. Supports (Suportado): Nesta modalidade, o mtodo do EJB ser executado em uma transao caso o cliente esteja em uma transao. Caso contrrio, o EJB ser executado sem nenhuma transao. Este o caso menos recomendvel para uso de transaes, uma vez que os resultados da execuo so inesperados, devido dependncia do suporte transacional do cliente. Never (Nunca): Utiliza-se este atributo quando o EJB (ou mtodo) no pode ser chamado por um cliente que esteja dentro de uma transao. Caso isto ocorra lanada uma exceo. Normalmente usado quando o mtodo acessa algum recurso que no transacional e portanto no capaz de prover as garantias definidas para as transaes. A seguir apresentamos uma tabela que demonstra os efeitos do uso de cada atributo de transao. No exemplo, temos um cliente e um EJB, os quais apresentam transao ou no. Temos duas transaes, a transao - T1 - e a transao - T2. Observe os efeitos de cada atributo de transao, quando o cliente define e no define uma transao.
Atributo Transacional Transao do Cliente
Nenhuma Required T1 Nenhuma Requires New T1 Nenhuma Mandatory T1 Nenhuma NotSupported T1 Nenhuma Supports T1 T2 T1 T2 T2 Exceo T1 Nenhuma Nenhuma Nenhuma T1

Transao do Bean

Nenhuma Never T1

Nenhuma Exceo

Em uma aplicao J2EE, h duas formas que os clientes devem ser avaliados no acesso ao sistema e aos componentes que ele utiliza. Para um cliente acessar um sistema, inicialmente ele dever estar autenticado no mesmo. Autenticar um cliente significa que o sistema deve verificar se o cliente quem ele diz que . Para isso o mesmo dever fornecer algumas informaes como usurio e senha, ou algum cdigo de acesso ou algo parecido. O sistema autenticar o usurio e sendo assim, associar o mesmo a uma identidade de segurana pr estabelecida, tal como um perfil de administrador, coordenador ou atendente por exemplo. Assim que o usurio autenticado e acessa o sistema, este ltimo dever apresentar formas de autorizar o usurio a acessar operaes do sistema vlidas para o seu perfil de usurio. Por exemplo, se o perfil do usurio de atendente, o mesmo no poderia acessar a operao de relatrios gerenciais. A autenticao feita antes de realizar as operaes nos EJBs e veremos mais adiante as formas que podem ser utilizadas para tal. J a autorizao realizada durante a chamada de mtodos dos EJBs, que permitem ou negam o acesso de determinado perfil de usurio. Veremos a seguir uma breve explicao da API JAAS e como utiliz-la

JAAS (Java Authenticated and Autorizated Service) apresenta interfaces que possibilitam que usurio sejam autenticados e autorizados em aplicaes J2EE. Com isso, permite que o usurio acesse sistema e operaes dele, no importando como implementado pelo fabricante do servidor J2EE. E assim, o servidor J2EE se encarrega de localizar os dados dos usurios que esto aptos a acessar o sistema, o perfil de cada um, possibilitando os mesmos de acessarem operaes especficas oferecidas pela aplicao em questo. Um usurio poder acessar um sistema e estar autenticado para o mesmo, sendo ele uma aplicao Web ou uma aplicao standalone. Isso dever ser transparente para o usurio, sendo que a aplicao J2EE poderia prover as duas interfaces para o usurio com as mesmas funcionalidades.

Em verses mais antigas da especificao EJB no havia uma API que definia os servios necessrios para operaes de segurana. Com a criao da API JAAS isto foi possvel e autenticar um usurio ficou mais simples e portvel. Com foi dito anteriormente, um usurio poder acessar um sistema por uma interface Web ou standalone, sendo que a aplicao dever prover os mesmos recursos para o usurio. Em interfaces standalone, a autenticao parece ser mais simplista, tendo a aplicao que utilizar a API JAAS para autenticar o usurio, a partir das informaes fornecidas pelo mesmo. Em interfaces Web isto tambm necessrio, sendo que o usurio tambm dever fornecer informaes como usurio e senha para o servidor Web que ir verificar a autenticidade da informao. Para fazer isso, o navegador poder apresentar quatro formas de realizar uma autenticao que so: Basic Authentication (Autenticao Bsica), Form-Based Authentication

(Autenticao baseada em Formulrios), Digest Authentication (Autenticao com Mensagem Alterada) e Certificate Authentication (Autenticao com Certificado Digital). Iremos a seguir detalhar cada uma delas. Basic Authentication - o navegador apresenta uma tela de login e fornece ao servidor o usurio e senha para a autenticao. Esta tela depende do navegador que est sendo utilizado. Form-Based Authentication - a aplicao fornece uma pgina HTML (que poder ser gerada por um JSP, por exemplo) com um formulrio no qual o cliente informaria o usurio e senha. Para isso, h um padro utilizado pela API JAAS.
...

...

Digest Authentication - para este tipo de autenticao usado um algoritmo para converter o usurio e senha em um texto ilegvel leitura, dificultando que usurios mau intencionados descubram estas informaes. Esta informao passada ao servidor que utilizando do mesmo algoritmo, autentica o cliente em questo. Certificate Authentication - o servidor recebe do cliente um certificado digital pelo qual ser autenticado. Assim que o cliente autenticado pela aplicao, o mesmo estar associado a uma identidade ou perfil, que ser propagado por toda a aplicao e utilizado pelo servidor para a execuo dos mtodos dos EJBs, isto , o seu perfil ser utilizado na sua autorizao.

Estando cliente autenticado, ele dever ser autorizado a realizar certas operaes fornecidas pelo sistema, de acordo com o seu perfil de usurio. Para isso, a aplicao deve estar configurada com security policies ou regras de segurana para cada servio fornecido por seus componentes, isto , para cada mtodo de cada EJB. A autorizao pode ser apresentada de duas formas: Autorizao Programtica ou Declarativa. Na Autorizao Programtica o programador deve implementar a verificao de segurana no EJB, isto , deve verificar qual usurio est acessando o servio e validar o mesmo. Na Autorizao Declarativa o container realiza toda a validao de segurana, no sendo preciso implement-la. Para isso, deve-se configurar no deployment descriptor as propriedades de segurana para cada EJB e para cada mtodo do mesmo. Em um mundo perfeito, o melhor forma a utilizar a Autorizao Declarativa. Haver casos que ser necessrio mesclar as duas formas de autorizao, sendo que somente a declarativa no ser suficiente. Por exemplo, se em uma rede de lojas um usurio com perfil de gerente pode acessar o servios de obteno de relatrios gerenciais, sendo somente permitido acessar esses dados das redes de uma determinada praa (regio de So Paulo, por exemplo), se faz necessrio incluir uma validao programtica da regio da rede de lojas que o gerente em questo atua.

O conceito de security roles simples, mas necessrio para o entendimento do uso de autorizao. Uma security role um conjunto de identidades de usurios (identity). Para um usurio ser autorizado a realizar um operao por exemplo, sua identidade dever estar na correta security role (perfil) para a operao em questo. O uso de security roles interessante, pois o desenvolvedor no precisa especificar o perfil do usurio no cdigo do EJB.

Para realizar a autorizao de forma programtica, se faz necessrio obter as informaes do usurio autenticado na implementao do EJB. Isto deve ser feito utilizando a interface javax.ejb.EJBContext que fornece os mtodos e . Vejamos a seguir os mtodos desta interface.

O mtodo fornece informaes do usurio atual, autenticado no sistema. Este mtodo retorna o objeto no qual pode-se obter informaes importantes do usurio, utilizadas para a sua autorizao. O mtodo verifica se o usurio atual est dentro de uma security role especfica. Dessa forma, pode-se realizar a autorizao para um determinado servio do EJB de forma programtica. Vejamos a seguir um exemplo de deployment descriptor, configurando secutiry roles e links para as security roles reais. Esta ltima propriedade pode ser configurada, pois em tempo de desenvolvimento o programador pode definir uma security role dentro do seu cdigo e depois no momento da instalao do sistema, a security role real tem um nome diferente, ento criase um link para o nome correto. A diferena de utilizar autorizao declarativa ao invs da declarao programtica que no h a necessidade de programar a autorizao, necessitando somente de configurar o deployment descriptor, definindo qual para cada EJB a security role a ser utilizada. Pode-se definir uma security role para todos os mtodos do EJB, ou definir uma especfica para cada mtodo. H a possibilidade de excluir mtodos que no desejase que seja acessado por nenhum perfil de usurio, e isto tambm deve ser feito no deployment descriptor. Observe que se alguma operao realizar uma chamada a algum mtodo com um perfil inadequado, isto , com um perfil que no foi configurado ou definido para o mtodo, o container lanar um exceo do tipo . Vejamos a seguir um exemplo de deployment descriptor, configurando security roles e as permisses para os mtodos dos EJBs. Em uma aplicao J2EE, teremos com certeza casos em que servios de alguns EJBs utilizam servios de outros. Dependendo da aplicao, poderamos querer que a identidade do usurio (perfil) seja propagado para os mtodos que esto sendo chamados pelos prprios EJB para outros EJBs, ou em vez disso, definir um perfil para executar um determinado mtodo em um EJB especfico.

Imagine uma situao em que um cliente acessa um servio de clculo de um certo imposto para a venda de um produto. Chamaremos este como servio do EJB . Este mtodo chamaria outro mtodo do EJB , o mtodo . Podemos definir na aplicao, que este ltimo mtodo execute com a identidade do chamador, isto , utilize a mesma identidade do cliente que chamou o mtodo do EJB . Ou ainda poderamos definir que o mtodo do EJB rodasse com uma nova identidade, definida pela aplicao. Essas duas opes podem ser configuradas no deployment descriptor da aplicao. Vejamos um exemplo a seguir:

Veremos a seguir, um exemplo de mdulo de segurana utilizando a API JAAS. Observe que no provemos uma implementao especfica para o mdulo, sendo o intuito mostrar somente um

esqueleto com os mtodos principais que devem ser implementados conforme o contrato estabelecido pelas interfaces. Fica a cargo do leitor implementar os mtodos se desejado.

ExampleLoginModule.java

ExamplePrincipal.java

ExampleRoleGroup.java

ExampleTest.java

ExampleMain.java
Observamos que o uso de transaes inevitvel para que a aplicao apresente eficincia e robustez. Agora sabemos que a arquitetura J2EE prov transaes do tipo e que podemos utiliz-las, tanto como Container-Managed como Bean-Managed, para gerenciar as transaes de nossa aplicao.

A quantidade de servidores de aplicao J2EE encontrados no mercado hoje grande. Existem servidores de aplicao de uso livre e outros proprietrios, alguns dispondo de alguns servios como diferenciais, outros dispondo de um desempenho melhor. Quando decidimos em usar a tecnologia J2EE e precisamos escolher qua servidor de aplicaes utilizar, devemos levar em considerao aspectos como desempenho, tamanho da aplicao, recursos que sero utilizados, custos entre outros. Para executar e exemplificar a aplicao J2EE que iremos apresentar neste captulo, iremos utilizar o servidor de aplicaes livre Jboss na verso 3.0.1. J existem novas verses deste servidor de aplicaes, mas no entraremos em detalhes. A escolha deste servidor de aplicaes, se deve ao seu grande uso em aplicaes J2EE que no necessitam de um servidor proprietrio. Apresenta uma soluo tima e de alto desempenho para os custos envolvidos. No o enfoque deste tpico avaliar outros servidores de aplicao e decidir qual deles o melhor, mas nas referncias no final do livro, pode-se ter acesso aos links dos fabricantes de diversos servidores de aplicaes comerciais.

No existem muitos segredos para instalar, configurar e executar o servidor de aplicaes Jboss. O que devemos fazer copiar o pacote do servidor de aplicaes Jboss na verso 3.0.1, do site do prprio Jboss ( ). O arquivo que foi copiado deve ter sido um arquivo compactado. Este arquivo deve ser descompactado em um diretrio ou sub-diretrio no qual deseja-se ter a instalao do servidor de aplicaes Jboss. Aps esta fase a instalao est completa. O interessante que no precisaremos realizar nenhuma configurao para executar os exemplos contidos neste livro. A configurao padro da instalao do Jboss j nos proporciona todos os servios necessrios para a nossa aplicao exemplo. Veremos que necessitaremos de utilizar um banco de dados, mas isto no ser problema e nem precisaremos nos precocupar em instalar um. O Jboss oferece um banco de dados para realizar testes e executar exemplos. Assim, a fase de configurao tambm est completa sem muita dificuldade. Para executar o servidor de aplicaes Jboss tambm uma operao muito simples. Execute o prompt de comando do seu sistema operacional e acesse o diretrio de instalao do Jboss. Entre no diretrio , isto , , e execute o comando run.bat para iniciar o servidor. Ento deve-se ter o seguinte: . Com isto, o servidor de aplicaes inicializar, gravando vrias mensagens no console, at aparecer a ltima mensagem informando que o servidor foi inicializado com sucesso. Assim, poderemos realizar a instalao da aplicao exemplo que veremos logo a seguir, que tambm no apresentar muita dificuldade. Observe que tambm no o intuito deste captulo, explorar os recursos e detalhes de configurao do servidor de apliaes Jboss. Para maiores detalhes consulte a documentao oferecida e disponvel no site do Jboss. Se no for o suficiente, o Jboss vende uma documentao mais completa para pessoas que desejam utilizar o servidor Jboss em aplicaes comerciais, e que necessitam de informaes mais complexas sobre o servidor. Veremos a seguir, tpicos que exemplificam na forma de uma aplicao, os tipos de EJB apresentados nos captulos anteriores deste livro. A aplicao completa se encontra no final do livro no apndice Aplicao . Ento, cada tpico seguinte trar explicaes detalhadas do que

foi implementado em cada EJB. No fim, poderemos juntar todos os EJBs e outras classes auxiliares em uma nica aplicao e fazermos a instalao e acesso aplicao exemplo. A aplicao exemplo apresentada nos prximos tpicos se trata de uma aplicao de venda de produtos, no qual um usurio poder escolher alguns produtos, calcular algumas informaes pertinentes a estes produtos e incluindo estes produtos em uma cesta de compras. Poder ainda excluir, alterar ou remover todos os produtos de sua cesta. Na finalizao da compra, os dados dos produtos escolhidos sero persistidos e o usurio ser avisado do trmino da compra, com os dados dos produtos vendidos.

Neste tpico sero analisadas as partes da codificao do EJB Session Bean Stateless, que faz parte da aplicao exemplo. No detalharemos as interfaces, pois elas s apresentam o contrato dos mtodos de negcio e ciclo de vida. Os mtodos de negcio sero brevemente explicados. O EJB Session Bean utilizado como exemplo, apresenta servios de clculo do desconto concedido ao usurio e clculo de parcelas para um produto em venda. O nome deste EJB SalesSupportBean. O cdigo a seguir, pertencente a interface do EJB SalesSupportBean, apresenta o mtodo que solicita a criao do EJB e retorna a referncia para a execuo dos mtodos de negcio.

Observe que o mtodo ao ser executado, solicita ao container que crie uma instncia do EJB SalesSuuportBean. Dessa forma o container cria a instncia do objeto, do tipo que encapsula o EJB SalesSupportBean e retorna ao cliente chamador uma referncia da interface , na qual se tem acesso aos mtodos de negcios ou servios disponveis para o EJB em questo. A seguir, observe os mtodos da interface do EJB SalesSupportBean, mtodos de negcio utilizados pelo cliente para calcular o desconto concedido ao produto vendido e clculo das parcelas a serem pagas.

A seguir vamos analisar a implementao do EJB SalesSupportBean. Iremos somente comentar os mtodos de negcio deste EJB que so muito simples. Os mtodos de ciclo de vida do EJB sero somente citados. No mtodo de ciclo de vida que apresenta a mesma assinatura da interface Home SalesSupportHome, no foi necessrio nenhuma implementao, sendo assim este mtodo no contm lgica. Isto tambm ocorreu para os mtodos , e , por no necessitar de executar operaes nos momentos de criao e remoo da instncia do EJB, e na ativao e passivao quando ocorre a liberao de recursos alocados, mas que no o caso. Os mtodos de negcio e apresentam operaes simples para o

clculo do desconto concedido na venda do produto e clculo do valor de parcelas de acordo com o valor da venda.

Observe que o mtodo retorna o resultado da operao do valor de venda diminuido do valor de desconto concedido de acordo com o percentual informado. O mtodo somente divide o valor total da venda pela quantidade de vezes tambm informada para o mtodo. Veja que as operaes implmentadas so bem simples e tambm no o escopo deste livro, detalhar demasiadamente as operaes, sendo que estas servem somente de exemplo e apresentam uma idia de como deve-se implementar os servios oferecidos pelo EJB Session Bean Stateless. Abaixo veremos o deployment descriptor do EJB SalesSupportBean, arquivo que deve ser criado juntamente com o EJB e utilizado pelo servidor de aplicaes para obter informaes adicionais do EJB e realizar o deploy do mesmo. Este arquivo tende a ser simples para EJBs Session Bean. Iremos somente comentar algumas linhas. As linhas iniciais apresentam o nome de exibio e o nome propriamente dito do EJB, utilizados pelo servidor de aplicaes. A seguir seguem os nomes das interfaces e e o nome da classe que implementa o EJB em questo. Depois informado o tipo de EJB Session Bean, que pode ser Stateless ou Stateful e por fim o tipo de transao, isto , se ser gerenciada pelo Container ou pelo Bean. Por fim definido o tipo de transao utilizada para cada mtodo especfico do EJB. Deve-se fazer referncia ao EJB que se est definindo as propriedades de transao, pelo seu nome anteriormente definido e a seguir, definir para cada mtodo o tipo de transao que este se enquadrar. No nosso caso utilizamos um asterstico, com isso todos os mtodos do EJB informado utilizaro o mesmo tipo de transao que foi definida como Required.

Iremos agora detalhar um exemplo de EJB Session Bean Stateful, utilizado na aplicao exemplo. No sero detalhados os mtodos de ciclo de vida da interface neste tpico, pois o mesmo j foi abordado no tpico anterior e o seu comportamento o mesmo. A nica exceo se faz para o mtodo , por um pequeno detalhe que ser mostrado. Este EJB, chamado de SalesBasketBean, ser encarregado de prover todos os servios de venda dos produtos escolhidos. Para isso, fornece mtodos de negcio tais como adicionar produtos na cesta de compras, remov-los, limpar a cesta, calcular o preo total dos produtos etc. Assim, vamos analisar cada mtodo de negcio deste EJB. A seguir segue a assinatura dos mtodos de negcio constantes na interface . Na classe de implementao do EJB SalesBasketBean, criamos um atributo chamado , que uma Map que mantm os produtos adicionados na cesta de compras. Com isto, entendemos a diferena do EJB Session Bean Stateless do EJB Session Bean Stateful, no qual este ltimo mantm os dados de um cliente especfico, isto , mantm os produtos na cesta de um determinado cliente e no compartilha estes dados com outros usurios.

Tambm mantemos no EJB SalesBasketBean os dados do usurio que iniciou a compra, para no final desta, validarmos seus dados e relacionarmos os produtos comprados para um determinado usurio. Observe que existe um objeto do tipo . Este objeto utilizado para carregar informaes do usurio em questo.

O mtodo do EJB SalesBasketBean somente inicializa a Map que contm os produtos comprados por um determinado usurio.

O EJB SalesBasketBean dispe de um mtodo utilizado par ainicilizar a venda. Para isso, configura o usurio que estar realizando a compra. Observe que esta operao poderia ser executada no mtodo , passando o objeto como parmetro no momento da criao da instncia do EJB.

O trecho a seguir implementa o mtodo de finalizao da compra. Esta operao um pouco mais complexa que as apresentadas at o momento, ento atente para os detalhes. Inicialmente solicitado uma classe chamada de , uma referncia para a instncia do EJB

Entity Bean ProductBean, utilizado para persistir os dados dos produtos vendidos para determinado usurio. A operao de obter a referncia para o EJB ProductBean est implementada na classe como pode-se notar. Esta classe implementa um Design Pattern bastante conhecido, no qual oculta a implementao da localizao do EJB e facilita esta operao para as classes que a utilizaro. No o intuito deste livro detalhar Design Patterns utilizados nos cdigos. Para maiores detalhes consulte as referncias bibliogrficas. Aps os detalhes deste mtodo, apresentamos a implementao do mtodo do SalesServiceLocator que localiza o EJB e retorna a referncia para os seus clientes. Com a referncia da interface , podemos realizar a execuo do mtodo create() para cada produto contido na cesta de produtos. Persistimos cada produto da cesta do usurio, fazendo isso por meio de um iterador. Este iterador ir obter cada produto contido na Map e criar uma instncia do EJB ProductBean.

A seguir vemos a implementao do mtodo , da classe , na qual obtido referncia para as interfaces dos EJBs contidos no servidor de aplicao. Veja que a operao simples, somente realizando um lookup (localizao) do EJB solicitado pelo seu nome JNDI. Para efeito de melhora de desempenho, a referncia para as interfaces Home solicitadas so armazenadas em um cach e podendo ser utilizadas futuramente em outras chamadas a este mtodo.

A seguir continuamos com os mtodos do EJB SalesBasketBean. A implementao dos mtodos e que adicionam e removem produtos da cesta simples. Utilizamos os mtodos de adio e remoo de objetos do tipo na Map. Tambm h a implemetao de um servio para limpar todos os produtos da cesta. Este mtodo tambm aproveita o mtodo da Map e executa-o.

O EJB tambm apresenta o mtodo de clculo do preo total dos produtos contidos na cesta. Esta tambm uma operao simples, que consiste em iterar todos os produtos contidos na cesta, acumulando os valores dos produtos e retornando este valor.

Observe que este EJB tambm no apresenta complexidade de implementao de cdigo, mas como j foi dito, este no o intuito do livro. O enfoque desta aplicao exemplo de somente validar os conhecimentos de EJBs.. A seguir segue o deployment descriptor do EJB SalesBasketBean. Tambm no apresenta muitos segredos e a nica diferena para o deployment descriptor do EJB Session Bean Stateless visto no tpico anterior, na tag tipo de EJB Session Bean. Nesta configurado o nome Stateful, para informar que o EJB a qual est se referenciando, se trata de um EJB Session Bean Stateful. Tambm no houve alteraes na configurao do tipo de transao para cada mtodo, utilizando o mesmo tipo de transao para todos os mtodos do EJB SalesBasketBean, conforme explicado no tpico anterior. O prximo EJB a ser comentado ser o EJB Entity Bean BMP UserBean. Neste EJB foi implementado toda a lgica de persistncia e manipulao do objeto. Para realizar a persistncia em um banco de dados, no precisaremos instalar e configurar um. O prprio servidor de aplicaes Jboss fornece um banco de dados como padro, que pode ser utilizado

para executar exemplo de aplicaes J2EE. Ento utilizaremos esse recurso para manter os EJB Entity Beans. Veremos as interfaces , , e que so respectivamente , , e . No iremos detalhar todas, somente a e , pois as interfaces utilizadas para acesso local apresentam os mesmos mtodos, somente suprimindo a exceo. A seguir temos o contrato da interface que apresenta os mtodos de ciclo de vida do EJB. O mtodo utilizado para solicitar-se uma instncia do EJB para o container. Neste mtodo so informados os valores do objeto que sero persistidos. Este mtodo declara as excees utilizada em caso de erro na persistncia do objeto, sendo uma exceo de e a utilizada para outros erros que poderiam ser tratados. Veremos mais detalhes deste mtodo, isto , da sua implementao no prprio EJB UserBean. O outro mtodo de ciclo de vida definido nesta interface o mtodo . Este mtodo utilizado para localizar um objeto persistido atravs de sua chave primria, que no nosso caso ser o CPF do usurio. Na execuo deste mtodo, no necessrio utilizar o mtodo , pois no iremos criar um novo objeto e sim localizar um objeto anteriormente persistido. Com isso, o mtodo tambm retorna uma referncia para a instncia do EJB. Declara as excees FinderException utilizada caso no consiga localizar o objeto atravs da chave-primria informada, e a exceo para outros erros na execuo do mtodo.

O cdigo a seguir apresenta os mtodos de negcio do EJB. Estes mtodos so definidos nas interfaces e . Iremos detalhar somente a interface - pois a interface - apresenta os mesmo mtodos e a nica diferena que os mtodos no declaram exceo necessariamente. Vemos os mtodos de negcio do EJB UserBean. So definidos nesta interface os mtodos getters e setters para o objeto em questo. A nica particularidade da interface em relao a como dito anteriormente a exceo , sendo que no acesso remoto utilizado em caso de erro na execuo dos mtodos de negcio que seguem.

Veremos em seguida o detalhamento da implementao do EJB Entity Bean BMP UserBean.

Definimos um atributo chamado connection, utilizado para manter a conexo com o banco de dados responsvel por manter os dados do objeto. Essa conexo obtida por meio de um nome JNDI definido pelo servidor de aplicaes Jboss como DataSource padro configura neste servidor. Usaremos este para persistirmos os objetos. Veremos que definimos um mtodo para obter a conexo, o mtodo utilizado em alguns mtodos de persistncia do objeto. Seguem tambm alguns atributos definidos como constantes que apresentam as operaes de seleo, remoo, atualizao e localizao dos objetos em SQL. Estes atributos so utilizados em determinados mtodos que sero vistos posteriormente, para realizar as operes respectivas. Observe que essas operaes no banco de dados poderiam no ser definidas como constantes do EJB, mas serem criadas somente em cada mtodo. Esta uma deciso do programador e aqui segue somente como exemplo. Vemos a seguir a implementao do mtodo definido na interface e . Neste mtodo so informados os atributos do objeto a serem persistidos e nele implementado a operao de gravao dos dados em um banco de dados. Observe que obtemos uma conexo com o banco de dados, preparamos a operao a ser executada, realizamos o bind dos atributos e em seguida executamos o comando. Por fim, so configurados todos os atributos do objeto e retornado o seu atributo chave-primria para o container. Este tratar essa informao e retornar ao objeto chamador uma referncia para a interface ou , disponibilizando assim a execuo dos mtodos de negcio. No mostramos detalhes do mtodo , pois no h implementao. Somente importante salientar que este mtodo deve ter a mesma assinatura do mtodo . Normalmente ele utilizado para configurar relacionamente entre EJB Entity Beans, mas isto no detalhado neste livro. Maiores detalhes sobre relacionamentos de EJB Entity Bean consulte a bibliografia. O mtodo a seguir trata da remoo do objeto do meio persistente. Como no mtodo , o mtodo tambm obtm uma conexo com o meio de persistncia, prepara a execuo do comando , realiza o bind da varivel pelo chave-primria e executa o comando. Assim, o registro definido com a chave-primria informada removido do banco de dados. Esse mtodo no retorna nenhum valor, mas em caso de erro na execuo do mtodo, a exceo lanada e poder ser tratada pelo objeto chamador.

O prximo mtodo apresenta a localizao do objeto por meio de sua chave-primria. A chave deve ser informada para o mtodo e o objeto localizado no meio persistente e uma instncia sua criada no container do servidor de aplicao. ento retornado sua chave primria que ser tratada pelo container que disponibilizar para o objeto chamador a referncia para interface ou , para a execuo dos mtodos de negcio. A implementao deste mtodo tambm muito parecida com os anteriores, obtendo uma conexo, preparando o comando , realizando o bind da varivel tida como chave-primria, executando o comando, configurando cada atributo com os valores localizados no meio persistente e por fim, retornando para o container a chave-primria do objeto. Em caso de erros na localizao do objeto, uma exceo lanada.

O mtodo executado pelo container quando este deseja carregar os dados do objeto do meio persistente e mant-lo em memria. Tambm no retorna nenhum valor, somente atualiza os dados do objeto atual. A implementao tambm trivial realizando as mesmas operaes dos mtodos de persistncia anteriores. O mtodo tambm no apresenta nenhuma complexidade e muito parecido com o mtodo anterior. Este mtodo responsvel por atualizar os dados do objeto em memria no meio persistente, isto , para cada atributo configurado no objeto em memria, este objeto executado para manter o sincronismo com os dados persistentes. Observe que este mtodo executa a operao contrria do mtodo .

No iremos detalhar os mtodos e , pois os mesmo no apresentam implementao. Os mtodos setters e getters tambm no sero explorados por no apresentarem nenhuma dificuldade. Tambm suprimimos os mtodos e pelos mesmos motivos. Por fim observamos o deployment descriptor do EJB Entity Bean BMP = User Bean - o qual apresenta algumas particularidades e diferenas em relao aos anteriores EJB Session Bean e por isso sero detalhados. Observe que a tag posterior a enterprise-beans a tag entity, informando que os dados que seguem iro informar detalhes de um EJB Entity Bean. As linhas iniciais so as mesmas, definindo o nome do EJB a ser mostrado e o nome utilizado pelo container para referenciar o EJB. Aps so informados os nomes das interfaces , , e e o nome da classe que implementa o EJB. A seguir o tipo de persistncia utilizado par aum EJB Entity Bean que podem ser duas: Bean ou Container. No nosso caso, como implementamos os mtodos de persistncia do EJB, esta deve ser configurada como Bean. Depois devemos informar qual a classe da chave-primria do EJB. Vemos que neste caso a classe uma classe da API Java, mas poderia ser uma classe definida para a aplicao. Por fim, a tag reentrant define se o EJB pode chamar outro EJB. Os atributos de transao no mudaram, sendo iguais aos dos EJB Session Beans.

Vamos agora analisar os detalhes da implementao do EJB Entity Bean CMP ProductBean. Este EJB apresenta as interfaces , , e que so , , e , alm da classe de implementao do EJB ProductBean e seu deployment descriptor. H uma novidade para este EJB. Implementamos a classe da chave- primria que se chamada . Como vimos no exemplo do EJB Entity Bean BMP UserBean - este no implementava uma classe para a chave primria, utilizando uma classe da API Java. Faremos diferente neste EJB para exemplificar o seu uso.

A seguir vemos um trecho do cdigo da interface . Ela define os mtodos de ciclo de vida do EJB tais como o , que recebe como parmetros os valores a serem persistidos no bando de dados e tambm declara as excees , quando ocorre algum erro na persistncia do objeto e a para outros erros. Define tambm os mtodos conhecidos como finders, utilizados para localizar objetos j persistidos. Neste caso, definimos somente o mtodo-padro informando qual o valor da chave- primria do objeto que deseja-se localizar. Este mtodo tambm declara as excees , para erros na localizao do objeto no meio persistente e a para outros erros. A interface tambm define os mesmos mtodos, tendo a nica difereno de no declarar as excees remotas - .

A interface - apresenta os mtodos de negcio do EJB. Neste somente declaramos os mtodos getters e setters para o EJB Entity Bean CMP - ProductBean. No iremos detalh-los, pois so muito simples. A interface - tambm define esses mesmos mtodos, com a nica diferena de no declarar as excees remotas . Logo a seguir apresentamos a implementao da classe de chave-primria, utilizada para o EJB ProductBean. Esta classe tambm no apresenta nenhuma complexidade, somente apresentando os atributos de chave-primria que no caso somente um id. Importante salientar que como esta classe ser utilizada pelos clientes remotos, ela deve implementar a interface .

O prximo cdigo apresenta a implementao do EJB Entity Bean CMP - Product Bean propriamente dito. Veremos que tambm no apresenta muita complexidade, pois os mtodos de persistncia e manuteno do objeto so implementadas pelo container do servidor de aplicaes, tirando essa responsabilidade do implementador, assim no havendo cdigos para estes mtodos. A classe deve ser declarada como abstrata, pois o container ir implement-la quando esta for instalada no servidor de aplicaes na aplicao exemplo.

Observe que o mtodo somente configura os atributos do objeto e retorna o valor da chaveprimria. A persistncia dos seus dados fica a cargo do container. Veja tambm que os mtodos de manipulao do objeto tais como , e so desprovidos de implementao, ficando tambm a cargo do container esta tarefa. Os mtodos de negcio tambm no apresentam implementao, mas a diferena para os mtodos de ciclo de vida que devem ser declarados como abstratos, pois sero implementados pelo prprio container novamente.

O deployment descriptor do EJB Entity Bean CMP - Product Bean - no traz muitas novidades em relao ao EJB Entity Bean BMP - UserBean. Uma das poucas diferenas deste que o tipo de persistncia do EJB deve ser configurado como Container, pois ficar a cargo deste realizar a persistncia. Informamos tambm a classe da chave primria, que neste caso ser a classe que implementamos exclusivamente para esse propsito. A seguir vemos a definio da verso de CMP que no nosso caso utilizamos a verso 2.x e a seguir o nome abstrato do esquema, utilizado para as consultas EQL. Por fim definimos cada campo CMP. Estes campos devem ter os mesmos nomes dos contidos na implementao do EJB. A ltima linha define qual o nome do atributo que ser utilizado como chave para a persistncia do objeto. A configurao dos tipos de transao para cada mtodo, segue a mesma configurao utilizada para os outros EJBs anteriores. O prximo EJB a ser comentado ser o EJB Message-Driven Bean - UserNotifierBean. Como vimos nos tpicos tericos deste tipo de EJB, o mesmo no necessita da definio de interfaces como nos EJB Session Bean e EJB Entity Bean. O que devemos fazer implementar a classe do EJB que servir como consumidor de mensagens e a mensagem propriamente dita, sendo que esta ltima pode ser utilizada como uma das implementaes definidas pela API Java. Vamos analisar o EJB UserNotifierBean, que nos apresentar algumas diferenas dos outros exemplos apresentados anteriormente. Vemos inicialmente que a classe deve implementar a interface e a interface . A primeira interface utilizada pelo container para tratar do ciclo de vida do EJB, tais como as interface e . A segunda interface utilizada para definir a classe como um consumidor de mensagens. Nesta interface est declarado o mtodo , o qual veremos sua implementao logo a seguir.

Os EJBs do tipo Message-Driven Bean somente definem os mtodos de ciclo de vida e . Os mesmos no nosso caso esto desprovidos de implementao, por isso no sero detalhados. O mtodo de negcio importante para a execuo deste tipo de EJB o mtodo . Este mtodo executado assim que mensagens so enviadas pelos produtores de mensagens, isto , os clientes que realizam as chamadas assncronas ao EJB. Estas mensagens so postadas em um MOM e logo em seguida consumidas pelo EJB Message-Driven Bean. Para isto, a mensagem enviada como parmetro para o mtodo , que valida a mensagem, recupera os dados contidos nela e realiza a lgica de negcio necessria. No nosso exemplo, a mensagem validada verificando se a mesma uma instncia do tipo de mensagem que estamos esperando receber. Caso isto ocorra, obtemos a mensagem atravs do mtodo da interface e realizamos a lgica de negcio, que neste caso ser enviar um email para o usurio que efetuou a compra dos produtos. Observe que todas as mensagens customizadas, isto , definidas para uma determinada aplicao, devem implementar a interface . Este EJB tambm apresenta um mtodo privado chamado , no qual implementado a lgica de envio de emails. Ele no ser detalhado. A classe que implementa a mensagem UserMessage tambm no ser detalhada, pois no apresenta uma complexida extra. Somente define atributos que sero utilizados para carregar os dados da mensagem do produtor para o consumidor, isto , do cliente que est efetuando a chamada assncrona, para o EJB Message-Driven Bean que executar a operao.

A seguir vemos o deployment descriptor do EJB Message-Driven Bean UserNotifierBean. Nele podemos observar algumas particularidades para este tipo de EJB. Como define somente a classe de implementao do EJB, nele definimos somente este atributo, alm do nome de visualizao e do nome utilizado pelo container para referenciar o EJB. O tipo de transao tambm definida como nos outros tipos de EJB. A particularidade do EJB Message-Driven Bean est em definir o destino da mensagem. Devemos informar qual o tipo de destino utilizado para receber a mensagem, se Queue ou Topic.

Para empacotar a aplicao, podemos faz-la de vrias formas. Podemos utilizar os empacotadores do prprio J2SDK e J2SDKEE que so o jar e o packager respectivamente. Poderamos utilizar do ANT, uma ferramenta muito utilizada no meio Java para criar makefiles. Utilizaremos um arquivo de build do ANT para realizar tal operao. Observe que o intuito deste tpico no de explicar as particularidades dessa ferramenta. Para maiores detalhes veja no tpico as referncias para o ANT. A seguir apresentamos o arquivo , utilizado como makefile para compilar a aplicao, gerar documentao, criar os pacotes (jar) e a aplicao Enterprise (ear).

Build File : build.xml

A instalao de uma aplicao J2EE no servidor de aplicao Jboss no uma tarefa muito difcil nem complexa. Configuraes adicionais no prprio servidor de aplicao no sero necessrias, pois no utilizamos recursos adicionais, mas se isso fosse preciso tambm no seria uma operao muito complexa. Tendo em mos o arquivo EAR, a nica tarefa que devemos realizar a cpia do Enterprise Archive no diretrio de deploy do Jboss. Devemos nos certificar de executar o Jboss com as configuraes padres, isto , executar o comando ou , que inicializar o servidor em seu modo de configurao padro. Sendo assim, podemos realizar o deploy da aplicao, somente copiando o arquivo para o diretrio . Algumas informaes sobre o deploy sero impressas no console do Jboss, detalhando a instalao do pacote. Por fim, se nenhum problema no arquivo EAR for detectado pelo servidor de aplicao, a mensagem de deploy realizado com sucesso ser impressa no console. Observe que o servidor de aplicaes Jboss pode ser configurado para inicializar com servios e recursos a mais ou a menos. A instao padro sem configuraes adicionais, nos apresenta trs modos de configurao fornecidos pelo servidor de aplicao. A configurao recomendvel a ser utilizada para a execuo da aplicao exemplo deste livro a configurao default. Para maiores detalhes sobre as outras configuraes ou configuraes customizadas, consulte a documentao do servidor de aplicao. Deployment descriptors ou arquivos descritores so utilizados pelos componentes da arquitetura J2EE para definir seus detalhes, informaes que so usadas pelo container para gerenciar esses objetos. Existem vrios tipos de descritores, um diferente do outro e especficos para cada tipo de componente. So alguns exemplos de descritores: web.xml para componentes Web; ejbjar.xml para componentes EJB; application.xml para o empacotamente de aplicaes enterprise etc. Para componentes EJB por exemplo, se faz necessrio o uso de um arquivo denominado ejbjar.xml, especificado pela Sun MicroSystems Inc. para aplicaes enterprise e que apresenta informaes dos componentes EJB tais como Session Bean, Entity Bean e Message-Driven Bean. Alm disso, apresenta formas de definir o escopo da transao na qual ir sobreviver o EJB, segurana e autenticao, relacionamentos entre Entity Beans, tipo de sesso, persistncia dos Entity Beans, consultas em EQL para Entity Beans, tipo de Session Bean, recursos remotos ou locais localizados atravs de JNDI entre outros. A seguir veremos mais detalhes do deployment descriptor ejb-jar.xml.

O deployment descriptor de um pacote de componentes EJB, deve ter o nome de e estar no diretrio da aplicao. Este arquivo ser empacotado juntamente com as classes que os componentes utilizaro. Este arquivo tem sua estrutura definida por um DTD (Document Type Definition). Iremos apresentar uma breve explicao de cada elemento e atributo do deployment descriptor ejbjar.xml. Para maiores delhaes, consulte o DTD ejb-jar_2_0.dtd. O arquivo em questo, deve ter como linha inicial com a seguinte declarao:

O elemento-raiz do deployment descriptor ejb-jar.xml o elemento . A seguir iremos detalhar seus atributos e elementos.

<description> : atributo que apresenta a descrio do pacote EJB. <display-name> : atributo com nome do mdulo de EJB a ser utilizado por outras ferramentas para referenciar a este pacote. <small-icon> : atributo com o caminho completo de uma figura que ser utilizada como um cone pelas ferramentas, que manipularo este mdulo. 16x16 pixels. <large-icon> : atributo com o o mesmo que a small-icon, sendo que esta cone poder ser maior. 32x32 pixels. <enterprise-beans> : elemento que define as informaes dos EJBs contidos neste pacote. Neste elemento estaro as informaes de cada EJB Session Bean, Entity Bean e MessageDriven Bean. <relationships> : elemento que apresenta os relacionamentos entre os EJB Entity Bean CMP. <assembly-descriptor> : elemento que define as informaes de segurana e transaes. <ejb-client-Jar> : elemento usado para conter o nome do pacote com as classe para acesso remoto aos EJBs.

O elemento define informaes de cada tipo de EJB, tais como, Session Bean, Entity Bean e Message-Driven Bean, e no possui atributos. A seguir iremos detalhar seus elementos. O elemento define informaes para os EJBs Session Bean contidos no arquivo de deploy, sendo assim, podemos ter vrias ocorrncias deste elemento. A sua declarao apresenta alguns atributos e elementos.

<description>: descrio do EJB Session Bean. <display-name>: nome utilizado pelo container para se referir ao EJB. <small-icon>: caminho completo de uma figura que ser utilizada como um cone pelas ferramentas, para este EJB. <large-icon>: caminho completo de uma figura que ser utilizada como um cone pelas ferramentas, para este EJB. <ejb-name>: nome do EJB, utilizado posteriomente dentro do prprio deployment descriptor para referenciar este EJB. <home>: nome completo da interface Home do EJB. <remote>: nome completo da interface Remote do EJB. <local-home>: nome completo da interface LocalHome do EJB. <local>: nome completo da interface Local do EJB. <ejb-class>: nome completo da classe que implementa o EJB. <session-type>: tipo de EJB Session Bean. Pode ser Stateless ou Stateful. <transaction-type>: define quem gerenciar a transao. Pode ser Bean ou Container. <env-entry>: define propriedades de ambiente para o EJB. <ejb-ref>: declara referncias para outros EJBs. <ejb-local-ref>: declara referncias locais para outros EJBs. <security-role-ref>: declara referncia para regras de segurana para este EJB. <security-identity>: informa como propagar o contexto de segurana. <resource-ref>: declara referncia para recursos que podem ser utilizados pelos EJBs. <resource-env-entry>: associa os recursos com nome JNDI. O elemento apresenta informaes do EJB Entity Bean e tambm pode ocorrer mais de uma vez no arquivo de deploy. Alm de apresentar informaes do EJB, pode definir as querys utilizadas pelo container para um EJB CMP.

<description>: descrio do EJB Entity Bean. <display-name>: nome utilizado pelo container para se referir ao EJB em questo. <small-icon>: caminho completo de uma figura que ser utilizada como um cone pelas ferramentas, para este EJB. <large-icon>: caminho completo de uma figura que ser utilizada como um cone pelas ferramentas, para este EJB. <ejb-name>: nome do EJB, utilizado posteriomente dentro do prprio deployment descriptor para referenciar este EJB. <home>: nome completo da interface Home do EJB. <remote>: nome completo da interface Remote do EJB. <local-home>: nome completo da interface LocalHome do EJB. <local>: nome completo da interface Local do EJB. <ejb-class>: nome completo da classe que implementa o EJB. <persistence-type>: tipo de persistncia do objeto. Pode ser BMP ou CMP. <prim-keyclass>: nome completo da classe que define a chave primria da entidade. <reentrant> : pode ser True ou False. <cmp-version>: verso de CMP. Depende da implementao do servidor de aplicao. Pode ser 1.x ou 2.x. <abstract-schema-name>: nome do objeto utilizado adiante para criar em EQL, formas de consulta e manipulao do objeto em questo. <cmp-field>: apresenta todos os campos de um EJB Entity Bean CMP que sero persistidos. <primkey-field>: campo de um EJB Entity Bean CMP que ser considerado como chave primria. <env-entry>: define propriedades de ambiente para o EJB. <ejb-ref>: declara referncias para outros EJBs. <ejb-local-ref>: declara referncias locais paa outros EJBs. <security-role-ref>: declara referncia para regras de segurana para este EJB. <security-identity>: informa como propagar o contexto de segurana. <resource-ref>: declara referncia para recursos que podem ser utilizados pelos EJBs. <resource-env-entry>: associa os recursos com nome JNDI. <query>: apresenta uma lista de cdigos de manipulao de objetos, utilizado para EJB Entity Bean CMP, utilizando a linguagem EQL (EJB Query Language). O elemento define as informaes dos EJB Message-Driven Bean. Como nos outros casos, o arquivo de deploy pode conter mais de uma ocorrncia deste elemento, isto , no caso de deploy de mais de um EJB. A seguir os seus atributos e elementos. <description>: descrio do EJB Message-Driven Bean.

<display-name>: nome utilizado pelo container para se referir ao EJB. <small-icon>: caminho completo de uma figura que ser utilizada como um cone pelas ferramentas, para este EJB. <large-icon>: caminho completo de uma figura que ser utilizada como um cone pelas ferramentas, para este EJB. <ejb-name>: nome do EJB, utilizado posteriomente dentro do prrprio deployment descriptor para referenciar este EJB. <ejb-class>: nome completo da classe que implmenta o EJB em questo. <transaction-type>: define quem gerenciar a transao. Pode ser Bean ou Container. <message-selector>: filtra mensagems baseadas no seletor de strings do JMS. <acknowledge-mode>: especifica como sero as mensagens de confirmao (acknowledge). Pode ser Auto-acknowledge ou Dups-ok-acknowledge. <message-driven-destination>: define o tipo de destino da mensagem que pode ser ou Alm de definir a durabilidade do envio da mensagem que pode ser Durable ou NonDurable. <env-entry>: define propriedades de ambiente para o EJB em questo. <ejb-ref>: declara referncias para outros EJBs. <ejb-local-ref>: declara referncias locais paa outros EJBs. <security-identity> : informa como propagar o contexto de segurana. <resource-ref> : declara referncia para recursos que podem ser utilizados pelos EJBs. <resource-env-entry> : associa os recursos com nome JNDI. .

O elemento apresenta o relacionamento entre EJBs Entity Bean CMP, sendo que podem ocorrer nenhum, um ou mais relacionamentos entre EJBs deste tipo. Define outro elemento, , no qual so configurados cada relacionemento entre dois EJBs. A seguir vemos uma breve explicao dos atributos do elemento <description> : descrio do relacionamento entre EJB Entity Bean CMP. <ejb-relation> : define o relacionamento entre dois EJB Entity Bean CMP. Sub-elemento do elemento que define define o relacionamento entre dois EJB Entity Bean CMP. <description>: descrio do relaciomento entre dois EJB Entity Bean CMP. <ejb-relation-name>: nome do relacionemnto. <ejb-relationship-role>: elemento que deve ser configurado para cada um dos dois EJBs que possuem o relacionemnto. Sub-elemento do elemento que descreve um regra de relacionamento dentre dois EJBs. .

<description>: descrio da regra de relacionamento. <ejb-relationship-role-name>: nome da regra de relacionamento. <multiplicity>: multiplicidade do relacionamento. Pode ser One ou Many. <cascade-delete>: define se o relacionamento de um para muitos de um EJB Entity Bean CMP dependente da vida do outro EJB. Sendo assim, s pode ser configurado para o EJB Entity Bean com multiplicidade um (One) no relacionamento. <relationship-role-source>: define qual EJB estar relacionando com este. <cmr-field> : define qual o campo utilizado para o relacionamento. Apresenta atributos que definem a descrio do campo de relaciomento, o nome do campo propriamente dito e o tipo do campo.

O elemento define as regras de segurana, a permisso de acesso (execuo) dos mtodos dos EJBs, atributos de transao para cada mtodo de cada EJB e a lista dos mtodos excludos do deploy.

<security-role> : define a regra de segurana utilizada para acesso aos EJBs. Como atributos define uma descrio da regra de segurana e o nome da regra propriamente dita. <method-permission> : quais mtodos podem ser acessados por quem a partir da regra de segurana definida em . Para cada mtodo, informa-se o nome do EJB que o contm, alm de informar se este mtodo acessado para alguma interface, o seu nome e os parmetros que ele recebe. Pode-se definir uma regra para todos os mtodos de um EJB, utilizando o asterisco (*) no elemento <methodname>, por exemplo. Este elemento pode aparecer quantas vezes for necessrio, para configurar uma regra de segurana para um mtodo de um EJB. <container-transaction> : define atributos de transao para cada mtodo de cada EJB. Pode conter um atributo que descreve a transao e deve conter para cada mtodo o nome do EJB e o nome do mtodo que ser utilizado um tipo de transao, configurada no elemento . <exclude-list> : lista dos mtodos excludos do deploy. Apresenta um atributo com a descrio da lista de excluso e um elemento que contm o nome de cada mtodo de cada EJB que ser excludo do deploy.

Este apndice apresenta um guia de referncia rpida para a API Enterprise JavaBeans. Observe que a API da plataforma J2EE muita mais extensa, sendo que esta apresentada neste tpico somente uma parte dela. No visamos tambm explicar em detalhes a API EJB. Para detalhes consulte a documentao oficial da API e a especificao EJB 2.0. Iremos apresentar o pacote explicando as suas interfaces e excees.

A interface extendida pelos contextos de cada tipo de EJB, isto , pelas interfaces , e . Fornece informaes de segurana, transao e dados sobre as interfaces ( e ) do EJB, sendo possvel utiliz-la para criar, destruir ou localizar um objeto por exemplo.

Esta interface deve ser extendida pelas interfaces (acesso ) dos componentes EJBs implementados. Ela oferece servios para criao, remoo e localizao de objetos EJB. Oferece informaes sobre o metadados do EJB e o handle do EJB, que pode ser utilizado para futuras chamadas de mtodos ao objeto, sem a necessidade de realizar a sua localizao por exemplo.

Deve ser extendida pelas interfaces (acesso ) dos componentes EJBs. Apresenta servios de criao, remoo e localizao dos objetos EJB.

A interface deve ser extendida pela interface (interface ) para os EJBs que provm acessos locais. Apresenta mtodos para obter referncia para a interface LocalHome e obter a chaveprimria (Primary Key) do objeto caso o mesmo seja um EJB Entity Bean. Alm de prover um mtodo para destruir a instncia do objeto e um servio que avalia se o objeto atual, isto , o idntico a outro informado. Quando definir a interface para um componente EJB, a mesma deve conter os mtodos de negcio que estaro disponveis para o cliente local.

Permite que o cliente acesse informaes dos metadados do EJB. Esta interface no muito utilizada, mas pode ser obtida atravs da chamada ao mtodo . As informaes contidas nesta interface e fornecidas ao cliente remoto em forma de um objeto serializado, pode ser utilizado para obter dinamicamente informaes sobre o EJB. Esta interface deve ser extendida pela interface (acesso remoto) dos componentes EJBs. Apresenta uma viso dos servios oferecidos pelo EJB para o cliente remoto. A interface definida para cada EJB, deve conter as assinaturas dos mtodos de negcio que o EJB implementa e as quais o cliente remoto ter acesso. Por esta interface, o cliente pode ter acesso a referncia para a interface do EJB, obter a chaveprimria no caso de EJB Entity Bean, remover a instncia do objeto, obter o Handler deste objeto que contm informaes sobre ele e verificar se algum objeto idntico ao objeto atual.

A interface a interface genrica de cada tipo de EJB. Ela extendida pelas interfaces , e . Alm de ser serializada utilizada como uma interface , isto , informa que a interface realmente um EJB.

Quando implementamos EJB EntityBean, devemos implementar esta interface. Apresenta os mtodos de ciclo de vida do EJB, executados pelo container nos momentos apropriados. Define os mtodos para configurar e desconfigurar o contexto associado ao EJB Entity Bean, mtodo de remoo da entidade persistente, ativao da entidade caso tenha sido passivada pelo container, passivao da entidade em caso de falta de recursos ou porque muitos EJBs esto instanciados por exemplo, carrega uma entidade do meio persistente para a memria quando o container precisa atualizar os dados do objeto, ou atualiza os dados no meio persistente de acordo com os valores dos atributos constantes em memria. Alm destes mtodos, se faz necessrio a implementao do mtodo j mencionado anteriormente, o qual ir criar a instncia do objeto em memria e persistir o mesmo. Apresenta a interface especfica do EJBContext para um EJB Entity Bean. Ela associada ao objeto aps a criao da sua instncia.

Um Handle uma referncia persistente de um componente EJB. Ela implementada por todos os EJB Handles. Muito til quando a aplicao necessita persistir a referncia para um objeto EJB e recuper-la posteriormente.

Tal como o Handle uma referncia persistente para a interface de um EJB, a HomeHandle uma referncia persistente para interface Home de um EJB. Tambm til para manter a referncia da interface de um EJB, persistente em algum meio e recuper-la posteriomente para acessar a interface Home.

Esta interface deve ser implementada por cada EJB Message-Driven Bean. Define os mtodos de ciclo de vida deste tipo de EJB. Observe que estes mtodos no so executados pelos clientes, pois como este componente tem um comportamento de execuo assncrona por meio de mensagens (JMS), os mtodos so executados pelo container no recebimento de mensagens dos clientes. Observe que o nico mtodo de negcio que a implementao de um EJB MessageDriven Bean deve oferecer o mtodo , implementado da API JMS. Este mtodo ser invocado pelo

container no recebimento de mensagens dos clientes e deve executar a lgica de negcio para o EJB em questo. Apresenta a interface especfica de EJBContext para um EJB Message-Driven Bean. Tambm associa o contexto ao EJB, depois que sua instncia criada.

Deve ser implementada por todo EJB Session Bean. Apresenta os mtodos do ciclo de vida do EJB, tais como associao do contexto ao EJB, remoo da instncia do objeto, ativao e passivao do objeto pelo container, alm de definir o mtodo que criar uma instncia do objeto pelo container.

Esta a interface especfica de EJBContext para um EJB Session Bean. Tambm associada a instncia do objeto aps a sua criao.

Esta interface pode ser implementada por EJB Session Bean Stateful, quando deseja-se sincronizar o estado transacional do objeto. Cada mtodo executado a cada etapa das fases de transao. Exceo lanada caso o chamador no tem acesso para executar o mtodo. Utilizado para objetos locais.

Deve ser definida no mtodo de criao da instncia de cada EJB. Ela lanada quando ocorrer uma falha na criao da instncia de um objeto EJB.

Esta exceo lanada quando no pode-se criar um objeto, pois a sua chave j existe e est sendo utilizada por outro objeto. Normalmente utilizada no mtodo do EJB Entity Bean.

Informa ao objeto chamador que ocorreu uma falha no recupervel, ou um erro inesperado. lanada quando ocorre erros deste tipo nos mtodos de ciclo de vida ou nos mtodos de negcio. a nica exceo do pacote que extende a exceo de - e no permite ao chamador se recuperar do erro. As excees , , e e extendem esta exceo.

Deve ser utilizada em todos os mtodos finders, normalmente usados em EJB Entity Bean. So lanadas quando um erro de localizao do objeto ocorre.

lanada pelo container quando em um EJB Entity Bean executado um mtodo, para o qual no existe o objeto em questo. Pode ser utilizada pelos mtodos de negcio do EJB e pelos mtodos de ciclo de vida e de um EJB Entity Bean.

Parecida com a exceo locais que no exitem mais.

, diferindo que esta lanada para objeto

lanada por um mtodo , para avisar que um objeto no existe. Deve-se utilizar esta exceo quando um mtodo finder retornar somente um objeto. No caso de vrios objetos, deve-se retornar uma coleo nula. A exceo RemoveException lanada quando o container no pode remover a instncia do objeto. utilizada no mtodo .

Informa que a requisio no encontrou uma transao e a mesma era requerida.

Indica que a transao foi marcada com rollback ou estava sendo executado o rollback, mas ocorreu algum erro nesta operao.

A seguir apresentamos o cdigo completo da aplicao exemplo. Esta aplicao consiste de cinco EJBs, sendo um para cada tipo de EJB definido pela especificao EJB 2.0. Ento sero: EJB Session Bean Stateless - SalesSupportBean EJB Session Bean Stateful - SalesBasketBean EJB Entity Bean BMP - UserBean EJB Entity Bean CMP - ProductBean Message-Driven Bean - UserNotifierBean Observe que existe um deployment descriptor para cada EJB nesta aplicao exemplo. Isto no necessrio nem possvel em uma aplicao J2EE, na qual faam parte dela todos esses EJBs. Para isso preciso criar um nico deployment descritor , no qual inclumos todas as informaes de todos os EJBs contidos na aplicao J2EE em questo. Este arquivo mostrado no final deste apndice. Iremos apresentar tambm o arquivo especfico para o servidor de aplicaes Jboss, utilizado para criar as tabelas do banco de dados utilizado para persistir os objetos da aplicao. Este arquivo, chamado de est mostrado no final deste apndice tambm. Salientamos que este arquivo no faz parte da especificao J2EE e um arquivo complementar e de uso exclusivo para o servidor de aplicaes Jboss. Vejamos o cdigo completo do EJB Sesison Bean Stateless - SalesSupportBean. Apresentamos as interfaces e , e respectivamente, a implementao do EJB SalesSupportBean e por fim o deployment descriptor ejb-jar.xml deste EJB.

Interface Home : SalesSupportHome. Interface Remote : SalesSupport.

Session Bean Stateless : SalesSupportBean.

Deployment Descriptor : SalesSupportBean.

No prximo cdigo, apresentamos o EJB Session Bean Stateful - SalesBasketBean. Inicialmente seguem s interfaces e , e respectivamente, a implementao do EJB SalesBasketBean e por fim o deployment descriptor deste EJB. Interface Home :

SalesBasketHome.

Interface Remote : SalesBasket.

Session Bean Stateful : SalesBasketBean.

Deployment Descriptor : SalesBasketBean.

Vemos a seguir os cdigos do EJB Entity Bean BMP - UserBean. Para este, alm das interfaces e para acesso remoto, dispomos das interfaces para acesso local. Ento seguem as interfaces , , e . Depois a implementao do EJB UserBean e por fim o seu deployment descriptor.

Interface Home : UserHome. Interface Remote : User.

Interface LocalHome : UserLocalHome.

Interface Local : UserLocal. Entity Bean BMP : UserBean.

Deployment Descriptor : UserBean.

O prximo cdigo apresenta o EJB Entity Bean CMP - ProductBean. Este EJB apresenta tambm as interfaces , , e que so respectivamente, , , e . Neste Entity Bean usamos uma classe de chave-primria especfica, isto , definimos uma nova classe para este fim que a e segue na seqncia. Em seguida temos a implementao do EJB ProductBean. Observe que como definimos este EJB como Entity Bean CMP, a implementao do EJB ProductBean no apresenta codificao para os mtodos de persistncia do objeto. Como sabemos, isto feito pelo prprio container do servidor de aplicaes. Bem, por fim apresentamos o deployment descriptor deste EJB.

Interface Home : ProductHome.

Interface Remote : Product.

Interface LocalHome : ProductLocalHome.

Interface Local : ProductLocal. PrimaryKey : ProductPK.

Entity Bean CMP : ProductBean.

Deployment Descriptor : ProductBean.

Apresentamos a seguir, o cdigo do EJB Message-Driven Bean - UserNotifierBean. A implementao do EJB segue logo a seguir. Aps segue a implementao da mensagem utilizada para notificar o EJB MDB UserMessage e por fim o deployment descriptor deste EJB.

Message-Driven Bean : UserNotifierBean.

Mensagem : UserMessage.

Deployment Descriptor : UserNotifierBean.

Foi criado um EJB Session Bean Stateless - ProjecSupportBean - com o intuito de preparar o ambiente da aplicao exemplo. O cdigo do EJB, tais como suas interfaces, implementao e deployment descriptors no foram comentadas pois utilizado somente como um servio auxiliar para a aplicao. Segue os cdigos do EJB.

Interface Home : ProjectSupportHome. Interface Remote : ProjectSupport.

Session Bean Stateless : ProjectSupportBean.

Deployment Descriptor : ProjectSupportBean.

Deployment Descriptor da Aplicao Exemplo : ejb-jar.xml

Deployment Descriptor especfico para o JBoss : jboss.xml Deployment Descriptor especfico para o JBoss : jbosscmp-jdbc.xml

GNU Free Documentation License Version 1.2, November 2002

0. PREAMBLE The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference. 1. APPLICABILITY AND DEFINITIONS This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law. A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none. The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words. A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque". Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only. The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition. The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be

included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License. 2. VERBATIM COPYING You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies. 3. COPYING IN QUANTITY If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document. 4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. B. List on the Title Page, as authors, one or more persons or entities responsible forauthorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement. C. State on the Title page the name of the publisher of the Modified Version, as thepublisher. D. Preserve all the copyright notices of the Document. E. Add an appropriate copyright notice for your modifications adjacent to the othercopyright notices. F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. G. Preserve in that license notice the full lists of Invariant Sections and requiredCover Texts given in the Document's license notice. H. Include an unaltered copy of this License. I. Preserve the section Entitled "History", Preserve its Title, and add to it an itemstating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. J. Preserve the network location, if any, given in the Document for public access toa Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

L. Preserve all the Invariant Sections of the Document, unaltered in their text andin their titles. Section numbers or the equivalent are not considered part of the section titles. M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version. N. Do not retitle any existing section to be Entitled "Endorsements" or to conflictin title with any Invariant Section. O. Preserve any Warranty Disclaimers. If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles. You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version. 5. COMBINING DOCUMENTS You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements." 6. COLLECTIONS OF DOCUMENTS You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document. 7. AGGREGATION WITH INDEPENDENT WORKS A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate. 8. TRANSLATION Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail. If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title. 9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 10. FUTURE REVISIONS OF THIS LICENSE The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/. Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. How to use this license for your documents To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with...Texts." line with this: If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation. If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.