Artigos Java A tão sonhada SCWCD – Parte 1 - Java Magazine 88
Demais posts desta série:
A tão sonhada SCWCD – Parte 2
Artigo no estilo: Curso

De que trata o artigo:

Trata do conteúdo cobrado na prova para a certificação SCWCD e dos cuidados que você deve ter para não cair nas armadilhas do exame. Ao final de cada seção, apresentamos questões semelhantes às que você poderá encontrar no exame. Sobre cada uma delas faremos uma breve discussão.


Para que serve:

Ajudar o desenvolvedor que deseja obter a certificação a conhecer os principais objetivos exigidos e cuidados que devem ser tomados na prova.


Em que situação o tema é útil:

O artigo é interessante para quem já leu algum material de apoio para a prova, como: livros, guia de referência, apostilas, entre outros. A ideia é mostrar ao leitor quais os aspectos importantes da prova e detalhes que devem ser memorizados, sempre ilustrados com exercícios de exemplo.

A tão sonhada SCWCD:

Apresentamos neste artigo as cinco primeiras seções que fazem parte da prova SCWCD. Foram abordados pontos importantes que merecem um cuidado em especial e exercícios semelhantes aos que você encontrará na prova.

A prova de certificação Sun Certified Web Component Developer 5, agora, após a aquisição da Sun pela Oracle, denominada Java Enterprise Edition 5 Web Component Developer Certified Professional, é, sem dúvida, a certificação que os profissionais da área de desenvolvimento para web mais buscam depois da de programador (Oracle Certified Professional, Java SE Programmer).

O exame exige um grande conhecimento da API de Servlets e JSP, pois é preciso saber o papel de cada classe, diferenciar nomes de métodos, de interfaces, saber qual método usar em determinado momento, ou seja, é interessante ter uma vivência com a plataforma Enterprise Edition antes de prestar o exame.

Para o profissional que almeja esta certificação, é necessário que o mesmo tenha obtido a SCJP em qualquer uma de suas versões. Na Figura 1 podemos visualizar um diagrama de todas as certificações Java, disponíveis no mercado, e seus requisitos prévios.

Figura 1. Certificações Java.

A certificação SCWCD é dividida em 11 seções das quais, nesta edição, vamos analisar cinco. As seis restantes, o faremos num próximo artigo. Ao final de cada seção, apresentaremos um exercício típico da prova. Iremos também respondê-lo e discuti-lo. A intenção é apresentar ao leitor detalhes que devem ser conhecidos e os principais objetivos da prova, servindo como material de complementação e como guia de estudo.

A prova consiste de 69 questões, sendo necessário acertar, pelo menos, 49 questões (70%) para ser aprovado. Você terá 180 minutos para responder a prova. Não se preocupe! É tempo suficiente para quem se preparou. Outro detalhe importante: a prova está disponível em duas línguas: inglês e francês.

As cinco primeiras seções, que analisaremos neste artigo, são: The Servlet Technology Model, The Structure and Deployment of Web Applications, The Web Container Model, Session Management e Web Application Security.

The Servlet Technology Model

A primeira seção da prova basicamente irá abranger questões de Servlets e o protocolo HTTP.

O protocolo HTTP é composto por oito métodos, onde cada um exerce uma função específica. Os dois principais – os mais conhecidos pelos desenvolvedores – são o GET e o POST. Para a prova de certificação, será necessário conhecer todos eles e as suas funcionalidades, embora, na prática, você basicamente utilize o POST e o GET. A seguir, apresentamos uma breve descrição da funcionalidade de cada um:

• GET: é o método mais simples do protocolo HTTP. Seu objetivo é requisitar ao servidor determinado recurso e enviá-lo de volta ao cliente (método doGet() da API de Servlets);

• POST: é semelhante ao GET, porém é possível enviar dados para o servidor no corpo de uma mensagem HTTP. Com o método GET também podemos enviar informações ao servidor, mas na forma de parâmetros (método doPost() da API de Servlets) e está limitado a 255 caracteres;

• HEAD: solicita apenas o header dos dados que o GET vai retornar. É como um GET sem corpo na resposta (método doHead() da API de Servlets);

• TRACE: pede um loopback da mensagem de solicitação. Permite assim que o cliente possa analisar o que está sendo recebido na outra ponta e usar estas informações para diagnóstico, teste ou troubleshooting (método doTrace() da API de Servlets);

• PUT: solicita para colocar a informação anexada (o corpo) na URL requisitada (método doPut() da API de Servlets);

• DELETE: solicita a remoção de um determinado recurso no servidor a partir da URL requisitada (método doDelete() da API de Servlets);

• OPTIONS: solicita uma lista de métodos HTTP, que podem ser respondidos pela URL requisitada (método doOptions() da API de Servlets);

• CONNECT: é usado para efetuar tunneling. Se você precisa acessar um serviço, bloqueado pelo firewall, é possível criar um túnel entre a máquina cliente e a servidora para que se comuniquem entre si, passando assim pelo firewall. É importante lembrar que não existe um método doConnect() na API de Servlets.

Todos os métodos da API de servlets recebem dois objetos por parâmetro: HttpServletRequest e HttpServletResponse. O objeto HttpServletRequest contém os dados enviados pelo browser cliente no momento da sua requisição e o HttServletResponse conterá os dados que o servidor irá enviar de volta ao cliente, respondendo assim sua requisição. É importante saber também que as solicitações GET e HEAD devem ser idempotentes, ou seja, capazes de rodar diversas vezes sem causar nenhum efeito colateral no servidor. Em contrapartida, POST, PUT e DELETE não precisam ser idempotentes e cabe ao desenvolvedor codificar o mesmo para que, caso o cliente envie uma solicitação duas vezes por engano, isso seja tratado. Vale ressaltar que existe uma diferença entre métodos HTTP e as suas representações na API de servlets. O HTTP GET, por exemplo, é sempre considerado idempotente, enquanto a sua representação doGet() pode ser idempotente ou não, dependendo de como o método foi implementado.

A classe HttpServletRequest possui alguns métodos para obter os parâmetros enviados pelo browser cliente, cookies e cabeçalhos HTTP. Listamos e comentamos, a seguir, os métodos que você deverá conhecer:

• getParameter(String name): retorna o valor de um determinado parâmetro. Supondo que você possui em sua página o seguinte trecho de código HTML: <input type=”text” name=“nome”>. Para obter este valor, procedemos da seguinte forma: request.getParameter(“nome”), onde request é uma variável do tipo HttpServletRequest;

• getParameterValues(String name): retorna os valores de um parâmetro multivalorado, por exemplo, um check box;

• getHeader(String name): retorna o valor de um determinado cabeçalho HTTP. Para obtermos o tamanho dos dados, trafegados do browser cliente até o servidor, procedemos da seguinte forma: request.getHeader(“Content-Length”);

• getCookies(): retorna um array de objetos Cookie, onde cada um representa o valor de um cookie: Cookie[] cookies = request.getCookies();

• getRequestDispatcher(String path): pode ser usado para encaminhar uma requisição para um determinado recurso ou para inclui-lo na resposta. Imagine o seguinte caso: request.getRequestDispatcher(“artigo.jsp”).forward(request, response), o objeto request (que possui a requisição do cliente) seria encaminhado para artigo.jsp e este JSP faria parte da resposta para o cliente. Desta forma, podemos perdurar os dados da requisição de uma página para outra, por exemplo.

A classe HttpServletResponse possui diversos métodos, mas os mais importantes para a prova são:

• setContentType(String type): informa o tipo de conteúdo que está sendo enviado. Por exemplo: text/html, text/plain, text/xml, etc.;

• getWriter(): retorna um objeto do tipo PrintWriter. Através dele é possível enviar dados de retorno ao cliente da seguinte forma: response.getWriter().println(“Artigo SCWCD”), onde response é uma variável do tipo HttpServletResponse;

• getOutputStream(): retorna um objeto do tipo ServletOutputStream. Através dele é possível enviar dados de retorno ao cliente que seja diferente de caracteres (por exemplo: uma imagem, um doc, etc.), da seguinte maneira: response.getOutputStream().write(bytes), onde bytes é um byte[] que representa o recurso que queremos enviar. Também é possível enviar caracteres simplesmente obtendo o byte[] correspondente do objeto String, assim: new String(“Artigo SCWCD”).getBytes();

• addHeader(String name, String value): adiciona um cabeçalho HTTP e o seu valor. Se o header já existe, atua da mesma forma que o setHeader(String name, String value);

• setHeader(String name, String value): altera o valor de um cabeçalho já existente. Exemplo: response.setHeader(“Content-Type”, “text/xml”). Se este cabeçalho não existe, ele irá atuar da mesma forma que addHeader(Sting name, String value);

• sendRedirect(String location): faz o redirecionamento para uma nova URL. Este redirecionamento é tratado pelo cliente, como um browser por exemplo.

Após analisarmos os métodos que envolvem o protocolo HTTP e o conceito de solicitação/resposta, veremos como definir a Servlet, que irá responder as requisições feitas pelo cliente. Para criarmos a Servlet, basta definirmos uma classe, fazer com que esta estenda HttpServlet e sobrescreva os métodos desejados como: doPost(), doGet(), doDelete(), entre outros.

...
Quer ler esse conteúdo completo? Tenha acesso completo