Começando

Parte 1 é destinado a leitores que são novos para o desenvolvimento de componentes web. Apresentamos a você os conceitos que você precisa entender antes de começar os capítulos que incidem sobre os objetivos do exame. Nossos tópicos aqui incluem o Servlet e JSP tecnologias, aplicações web, e do protocolo HTTP.

INTRODUÇÃO

O objetivo deste livro é explicar como você pode usar J2EE para criar esses componentes web dinâmicas. Nós vamos fazer isso por discutir servlets e JavaServer Pages (JSPs) em grande profundidade técnica. Vamos apresentar a teoria por trás desses conceitos, e, em seguida, completar a teoria com o código de prática. Em seguida, usando Tomcat ou um servidor de web semelhante, você pode construir o seu próprio código para cimentar o material em sua mente.

1.1 O que é um servlet?

Como resulta do seu nome, um servlet é uma entidade do lado do servidor. Mas o que exatamente significa isso? É um novo padrão de design para servidores escrever? É uma nova classe Java? Ou é uma nova tecnologia? A resposta para todas essas perguntas é sim, embora em diferentes contextos. Para entender qualquer conceito novo, é importante conhecer as razões por trás de sua concepção. Então, vamos começar por ter um olhar para as tarefas que um servidor precisa fazer.

1.1.1 responsabilidades do Servidor

Cada servidor que fornece serviços para clientes remotos tem duas responsabilidades principais. O primeiro é para lidar com pedidos de clientes; a segunda é a de criar uma resposta a ser enviada de volta. A primeira tarefa envolve a programação no nível de soquete, extrair informações de mensagens de solicitação e implementação de protocolos cliente-servidor, tais como FTP e HTTP. A segunda tarefa, criando a resposta, varia de serviço para serviço. Por exemplo, no caso dos servidores de FTP que servem pedidos de transferência de arquivos, criação de resposta é tão simples como a localização de um arquivo na máquina local. Por outro lado, os servidores HTTP que aplicações web verdadeiras integral de acolhimento são obrigados a ser mais sofisticado na maneira de gerar a saída. Eles têm que criar a resposta de forma dinâmica, que pode envolver tarefas complexas, tais como a recuperação de dados a partir do banco de dados, aplicação de regras de negócio, e apresentando a saída nos formatos desejados pelos clientes diferentes.

Uma maneira de escrever um servidor simples que serve apenas dados estáticos seria codificar tudo em um único programa executável. Este único programa iria cuidar de todas as diferentes tarefas, tais como a gestão da rede, implementação de protocolos, localizar dados e responder. No entanto, para servidores HTTP que servem de dados sindicados, que exigem um design altamente flexível e extensível. A lógica de aplicação continua a mudar, os clientes precisam vistas personalizadas de informações e parceiros de negócios precisam de regras de transformação customizadas. Não podemos escrever um único programa que lida com todas essas tarefas. Além disso, o que se uma nova funcionalidade tem de ser adicionado? E se as alterações de formato de dados? Modificando os arquivos de origem (especialmente após o desenvolvedor deixou!) para adicionar um novo código é certamente a última coisa que queremos fazer.

Bem, há um projeto melhor para esses tipos de servidores: dividir o código em duas partes e um executável que lida com a rede e que fornece a aplicação lógica e deixar os dois executáveis tem uma interface padrão entre eles. Este tipo de separação torna possível modificar o código na lógica da aplicação sem afetar o módulo de rede, desde que siga as regras do interface. Tradicionalmente, as pessoas têm implementado este projeto para servidores HTTP usando Common Gateway Interface (CGI). De um lado dessa interface é o servidor web principal, e do outro lado estão as scripts CGI. O servidor web funciona como o módulo de comunicações de rede e gerencia os clientes, enquanto os scripts CGI atuar como módulos de processamento de dados e entregar o resultado. Eles seguem as regras do "Common Gateway Interface" para passar dados entre eles.

1.1.2 extensões de servidor

Embora CGI oferece um design modular, tem várias deficiências. O principal problema para sites de alto tráfego é a escalabilidade. Cada nova invocação pedido envolve a criação e destruição de novos processos para executar os scripts CGI. Isto é altamente ineficiente, especialmente se os scripts executar rotinas de inicialização, tais como ligar a uma base de dados. Além disso, eles usam ficheiro de entrada / saída (I / O), como um meio de comunicação com o servidor, causando um aumento significativo no tempo de resposta global. A melhor maneira é ter o apoio servidor módulos executáveis separadas que podem ser carregados para a memória e inicializadas apenas uma vez, quando o servidor é iniciado. Cada pedido pode, então, ser efetuada mediante a já na memória e pronto a servir cópia dos módulos. Felizmente, a maioria dos servidores de força industrial têm vindo a apoiar tais módulos por um longo tempo, e eles fizeram os scripts CGI fora-de-memória obsoleto. Estes módulos executáveis separados são conhecidos como extensões de servidor. Em outras plataformas de Java, extensões de servidor são escritas usando APIs de língua nativa prestados pelos fornecedores de servidores. Por exemplo, o Netscape Server fornece a programação Netscape Application Server Interface (NSAPI), e do Microsoft Internet Information Server (IIS) fornece a Internet Server Application Programming Interface (ISAPI). Em Java, extensões de servidor são escritos usando a API Servlet, e os módulos de extensão de servidor são chamados servlets.

1.2 O QUE É um contêiner de servlet?

Um servidor web usa um módulo separado para carregar e executar servlets. Este módulo especializado, que se dedica à gestão de servlet, é chamado de um servlet container, ou mecanismo de servlet.

1.2.1 O retrato grande

A Figura 1.1 mostra como os componentes diferentes se encaixam no quadro geral. Arquivos HTML são armazenados no sistema de arquivos, servlets são executados dentro de um servlet container, e dados de negócios está no banco de dados. O navegador envia pedidos para o servidor web. Se o destino for um arquivo HTML, o servidor processa-lo diretamente. Se o alvo é um servlet, os delegados do servidor a solicitação para o servlet container, que por sua vez encaminha para o servlet. O servlet utiliza o sistema de arquivos e banco de dados para gerar a saída dinâmica.

1.2.2 Entendendo contêineres de servlet

Conceitualmente, um servlet container é uma parte do servidor web, mesmo que possa ser executado em um processo separado. A este respeito, contêineres de servlet são classificados em três tipos seguintes:

• Standalone-Servlet deste tipo são tipicamente servidores web baseados em Java, onde os dois módulos o servidor web principal e o servlet container são parte integrante de um programa único (figura 1.2). Tomcat (vamos aprender sobre Tomcat em breve) que funciona por si só é um exemplo deste tipo de servlet container. Corremos o Tomcat como faríamos com qualquer programa Java normais dentro de uma máquina virtual Java (JVM). Ele contém manipuladores para conteúdo estático, como arquivos HTML e manipuladores para a execução de servlets e páginas JSP.

• In-processo-Aqui, o servidor web principal eo servlet container são programas diferentes, mas os contentores é executado no espaço de endereço principal do servidor como um plug-in (figura 1.3). Um exemplo deste tipo é Tomcat rodando dentro Apache Web Server. Apache carrega um JVM que executa Tomcat. Neste caso, o servidor web lida com o conteúdo estático, por si só, e Tomcat manipula os servlets e páginas JSP.

• Out-of-process-Like in-processo servidores, o servidor web principal eo servlet container diferentes programas. No entanto, com out-of-processo, o servidor web é executado em um processo, enquanto os contentores servlet é executado em um processo separado (figura 1.4). Para se comunicar com o servlet container, o servidor web usa um plug-in, que é normalmente fornecido pelo exemplo vendor.An servlet container deste tipo é Tomcat executado como um processo separado configurado para receber solicitações de Apache Web Server. Apache carrega o mod_jk plug-in para se comunicar com Tomcat.

Cada um desses tipos tem suas vantagens, limitações e aplicabilidade. Nós não vamos discutir esses detalhes, uma vez que eles estão fora do escopo deste livro. Muitos recipientes de servlet estão disponíveis no mercado-Tomcat (Apache), resina (Caucho Technology), JRun (Macromedia), WebLogic (BEA), e WebSphere (IBM), só para citar alguns. Algumas delas, como o WebLogic e WebSphere, são muito mais do que apenas recipientes de servlet. Eles também fornecem suporte para Enterprise JavaBeans (EJB), Java Message Service (JMS) e outras tecnologias J2EE.

1.2.3 Usando o Tomcat

Tomcat é um servlet container desenvolvido no âmbito do projecto Jakarta na Apache Software Foundation (ASF). Você pode obter uma riqueza de informações sobre Tomcat de http://jakarta.apache.org/tomcat. Decidimos utilizar o Tomcat versão 5.0.25 para os exemplos neste livro por causa das seguintes razões:

• É de graça.

• Ele implementa as últimas Servlet 2.4 e JSP 2.0 especificações, que é o que precisamos para o exame.

• Ela tem a capacidade de funcionar como um servidor web por si só (modo Standalone) .Não há necessidade de um servidor web separado.

Temos dado instruções de instalação para o Tomcat no apêndice A. Nas discussões dos exemplos ao longo do livro, assumiu-se que o diretório de instalação do Tomcat é c: \ jakarta-tomcat-5.0.25. Note-se que uma vez que você tenha instalado o Tomcat, você deve definir o CATALINA_HOME, JAVA_HOME, e variáveis CLASSPATH, conforme descrito no apêndice A.

1.3 OLÁ MUNDO servlet

Nesta seção, vamos olhar para o quatro passos básicos codificação, compilação, implantação e funcionando-necessário para desenvolver e executar o servlet habitual Olá Mundo, dois que imprime Olá mundo! na janela do navegador. By the way, você sabe quem começou a tendência de escrever "Olá mundo!" Como um programa de introdução?

1.3.1 O código

Listagem 1.1 contém o código para HelloWorldServlet.java.

1.3.2 Compilação

Observe as instruções de importação na Listagem 1.1. Eles importam as classes dos pacotes javax.servlet e javax.servlet.http. No Tomcat, eles São fornecidas como parte do arquivo servlet-api.jar, que está no diretório c: \ jakarta-tomcat 5.0.25 \ common \ lib \. Para compilar o programa na listagem 1.1, incluem o arquivo JAR no classpath, conforme indicado no apêndice A. Vamos explicar os detalhes desses pacotes na secção 1.4.

1.3.3 implantação

A implantação é um processo de duas etapas. (Nós vamos discutir a estrutura de implantação no capítulo 5.) Em primeiro lugar, nós colocamos os recursos para o diretório necessário. Então, eu informo sobre o nosso servlet Tomcat editando o arquivo web.xml:

1 Copie o arquivo para o diretório HelloWorldServlet.class

c: \ jakarta-tomcat-5.0.25 \ webapps \ chapter01 \ WEB-INF \ classes

2 Crie um arquivo de texto chamado web.xml no

c: \ jakarta-tomcat5.0.25 \ webapps \ chapter01 \ WEB-INF.

Escreva as seguintes linhas no arquivo:

Você também pode copiar o diretório chapter01 diretamente do site da Manning no seu c: \ jakarta-tomcat-5.0.25 diretório \ webapps. Isto irá fornecer todos os arquivos que você precisa para executar o exemplo.

1.3.4 Execução

Comece Tomcat com um atalho ou com o prompt do DOS (c: \ jakarta-tomcat5.0.25 \ bin \ startup.bat).

Abra uma janela do navegador e vá para a URL http: // localhost / chapter01 / servlet / HelloWorldServlet.

Olá Mundo! deve aparecer na janela do navegador.

1.4 A relação entre um servlet CONTAINER EO API Servlet

Especificação Servlet da Sun fornece um padrão e uma estrutura independente de plataforma para a comunicação entre servlets e seus containers. Este quadro é constituído por um conjunto de interfaces e classes Java. Essas interfaces e classes são chamados coletivamente os Application Programming Interfaces Servlet, ou a API Servlet.

Simplificando, podemos desenvolver servlets usando esta API, que é implementado pelo contêiner servlet (veja a figura 1.5). A API Servlet é tudo que nós como desenvolvedores de servlet precisa saber. Uma vez que todos os contêineres de servlet deve fornecer esta API, os servlets são verdadeiramente independente de plataforma e servlet container-. Essencialmente, a compreensão das regras deste API e a funcionalidade que ele fornece é o que a programação servlet tem tudo a ver! A API Servlet é dividido em dois pacotes: javax.servlet e javax.servlet.http. Vamos discutir esses pacotes em mais detalhes à medida que progredimos através do livro, mas por agora, vamos dar uma olhada rápida para eles.

1.4.1 O pacote javax.servlet

Este pacote contém as interfaces de servlets genéricos e classes que são independentes de qualquer protocolo.

A interface javax.servlet.Servlet

Esta é a interface central no API servlet. Cada classe servlet deve directa ou indirectamente implementar essa interface. Tem cinco métodos, tal como mostrado na tabela 1.1.

O método de service () lida com as solicitações e cria respostas. O servlet container chama automaticamente esse método quando ele recebe qualquer pedido para este servlet. A assinatura completa deste método é

public void service (ServletRequest, ServletResponse)

throws ServletException, java.io.IOException;

A classe javax.servlet.GenericServlet

A classe GenericServlet implementa a interface Servlet. É uma classe abstrata que permite a execução de todos os métodos, exceto o método de serviço () da interface Servlet. Ele também adiciona alguns métodos para apoiar o registo. Podemos estender esta classe e implementar o método de serviço () para escrever qualquer tipo de servlet.

A interface javax.servlet.ServletRequest

A interface ServletRequest fornece uma visão genérica do pedido que foi enviado por um cliente. Ele define métodos que extraem informações do pedido.

A interface javax.servlet.ServletResponse

A interface ServletResponse fornece uma forma genérica de envio de respostas. Ele define métodos que auxiliam no envio de uma resposta apropriada para o cliente.

1.4.2 O pacote javax.servlet.http

Este pacote fornece a funcionalidade básica necessária para servlets HTTP. Interfaces e classes deste pacote estender as interfaces correspondentes e classes do pacote javax.servlet para construir suporte para o protocolo HTTP.

A classe javax.servlet.http.HttpServlet

HttpServlet é uma classe abstrata que estende GenericServlet. Ele adiciona um novo método de serviço () com esta assinatura:

protected void service (HttpServletRequest, HttpServletResponse)

throws ServletException, java.io.IOException;

No exemplo Olá Mundo, nós estendemos nossa classe servlet a partir desta classe e que cancelou o método de serviço ().

A interface javax.servlet.http.HttpServletRequest

A interface HttpServletRequest estende ServletRequest e fornece uma visão específica HTTP do pedido. Ele define métodos que extraem informações, tais como cabeçalhos de HTTP e cookies, a partir da solicitação.

A interface javax.servlet.http.HttpServletResponse

A interface HttpServletResponse estende ServletResponse e fornece uma maneira específica do HTTP de envio de respostas. Ele define métodos que auxiliam na criação de informação, tais como cabeçalhos de HTTP e cookies, para a resposta.

1.4.3 Vantagens e desvantagens da API Servlet

As vantagens do API servlet são os seguintes:

• Flexibilidade-Cada vez que precisa adicionar uma nova funcionalidade ao servidor, todos nós temos que fazer é escrever um novo servlet específico para esse conjunto de requisitos e conecte-o ao servidor, sem modificar o próprio servidor.

• A separação de responsabilidades O servidor principal agora só precisa se preocupar com a conexões de rede e comunicações parte. O trabalho de interpretar os pedidos e criar respostas adequadas é delegada aos servlets.

• É programadores Java Java não precisam aprender uma nova linguagem de script. Além disso, eles podem usar todos os recursos orientados a objetos fornecidos pelo Java.

• Portabilidade-Podemos desenvolver e testar um servlet em um recipiente e implantá-lo em outro. Ao contrário de soluções proprietárias, a API Servlet é independente de servidores web e contêineres de servlet. Nós podemos "write once, run anywhere", enquanto os contentores suportam a API Servlet padrão.

Uma limitação óbvia, ou melhor, restrição, da API Servlet é aquele que é comum a todos os tipos de quadros: você tem que seguir as regras estabelecidas pelo quadro. Isso significa que temos que seguir certas convenções para tornar o servlet container feliz.

Outra desvantagem envolve os recipientes disponíveis no mercado e não a própria API Servlet. Teoricamente, usando a API, você pode escrever servlets para quase qualquer tipo de protocolo, incluindo FTP, SMTP, ou mesmo protocolos proprietários. No entanto, não seria justo esperar que os fornecedores de contêiner servlet para construir o apoio para todos eles. A partir de agora, os mandatos de especificação Servlet apoiar apenas para HTTP através do pacote javax.servlet.http.

1.5 RESUMO

Neste capítulo, nós aprendemos sobre os conceitos básicos de servlets e servlet container, e como eles fornecem extensões para a funcionalidade de um servidor. Nós também correu uma amostra de servlet Olá mundo que exibia uma linha de texto na janela do navegador. Finalmente, nós olhamos a API Servlet e suas classes e interfaces. Armado com este conhecimento, agora nós podemos responder à pergunta "O que é um servlet?" A partir de várias perspectivas diferentes. Conceitualmente, um servlet é um pedaço de código que pode ser

• Ligado a um servidor existente para estender a funcionalidade do servidor

• usado para gerar a saída desejada dinamicamente

Para um contêiner de servlet, servlet é um

• Uma classe Java como qualquer outra classe Java normal,

• Uma classe que implementa a interface javax.servlet.Servlet

Para um desenvolvedor web componente, um servlet, ou especificamente um servlet HTTP, é uma classe que

• Estende javax.servlet.http.HttpServlet

• Reside em um contêiner de servlet (como Tomcat ou JRun)

• Serve solicitações HTTP