Introdução a JAX–RS – Java API for RESTful Web Services

sábado, 16 de outubro de 2010

JAX-RS é a solução do JCP para o estilo de programação REST. A proposta final da especificação foi liberada para o público no inicio de Agosto de 2008,. A especificação define um conjunto de APIs Java para
auxiliar no desenvolvimento de web services baseados em REST.
O objetivo da API é fornecer um conjunto de anotações, classes e interfaces para expor uma classe POJO
como um web service RESTful, de modo que possamos fazer uma programação fácil e de alto nível.


Trabalhando com os recursos

Para uma classe ser determinada como um recurso, ela tem que ser uma classe POJO com pelo menos um método anotado com a anotação @Path.
A anotação @Path pode ser colocada na declaração de classe ou de um método e possui o elemento value
obrigatório. Por este elemento definimos o prefixo da URI que a classe ou o método irá atender. Na Listagem 01, a classe Repositorio é identificada pela URI relativa “/repositorio/{id}”, onde {id} é o valor do parâmetro id, fornecido junto a URI.
Mais adiante, demonstraremos como extrair valores como esse de uma URI utilizando anotações especificas.

@Path("/repositorio/{id}")
public class Repositorio { ... }
Listagem 01 - Mapeando uma URI para uma classe com @Path.

A especificação define que no ciclo de vida de um recurso, por padrão, sempre que for feito uma requisição a um recurso, será criada uma nova instância de uma classe REST. Primeiro o construtor é chamado pelo contêiner, por conta disto, o construtor da classe deve ser público. Após este primeiro passo, o contêiner efetua as injeções de dependência nos devidos métodos e o método designado para aquele recurso é invocado. E finalmente após a chamada ao método o objeto fica disponível para o garbage collector.
Geralmente a anotação @Path é incluída na declaração de um método quando queremos atribuir um caminho mais específico para um recurso, de forma a especializar nosso método, como na Listagem 02. Note no exemplo como a URI é mapeada com a classe e o método.
@Path("/vendas/")
public class Repositorio {
  @GET
  @Produces("application/xml")
  @Path("/pedidos/{numPedido}/")
  public PedidoAsXML getPedido(@PathParam("numPedido") Integer id){
    // retorna Pedido em formato XML.
  }
}
Listagem 02 - Mapeando uma URI para uma classe com @Path.

Acessando os Recursos

Para acesso aos recursos, a especificação JAX-RS define um conjunto de anotações correspondentes aos métodos HTTP, como @GET, @POST, @PUT, @DELETE, @HEAD.. Elas devem ser atribuídas a métodos públicos. O método anotado com @GET, por exemplo, irá processar requisições HTTP GET na URI atribuída. O comportamento do recurso é determinado pelo método HTTP ao qual o recurso está respondendo.
É bom entender o papel e o uso de cada um destes métodos HTTP no momento de projetar nossos serviços.
Além dos métodos definidos pelo JAX-RS, podemos criar uma anotação customizada como @MKCOL, com uso da anotação HttpMethod, conforme ilustra a Listagem 03.
Com esta anotação podemos criar métodos customizados e extender a gama dos métodos pré-existentes e utilizar os métodos definidos pelo WebDAV, como fazemos na Listagem 3, ou podemos alternar um método padrão para a anotação customizada, onde para isso poderíamos simplesmente informar como valor para anotação HttpMethod o valor do método que queremos sobrepor, por exemplo, para sobrepor o método PUT a declaração da anotação ficaria
@HttpMethod("PUT").

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@HttpMethod("MKCOL")
public @interface MKCOL {
}
Listagem 03: Utilizando a anotação HttpMethod para criar uma anotação customizada.

Representações: Quais são os sabores?

As classes de uma aplicação RESTful podem ser declaradas para suportar diversos tipos de formatos durante um ciclo requisição-resposta. Para isso a especificação define as anotações @Consumes e @Produces para o tratamento da request e response respectivamente.
Com estas anotações o servidor declara o tipo de conteúdo que será trafegado, através do cabeçalho (header) do protocolo HTTP, estas anotações podem ser aplicadas na declaração de uma classe, ou podemos utilizar estas anotações na declaração do método para sobrescrever a declaração da classe, na ausência destas anotações, será assumido como default qualquer tipo de retorno ("*/*").
No caso da anotação @Produces, ela é utilizada para mapear uma requisição de um cliente com o cabeçalho do cliente (parâmetro Accept). Desta maneira, podemos definir mais de um tipo de retorno da URI solicitada, como JSON e XML, como no exemplo da Listagem 04:
@GET
@Produces({"application/xml", "application/json"})
public PessoaConverter getPessoa(@QueryParam("CPF") String numCPF) {
  // Retorna representação em XML ou JSON
}
Listagem 04 - Declarando o tipo de retorno com a anotação @Produces.

Pegando o exemplo da Listagem 04, podemos testar o retorno da chamada utilizando uma das ferramentas
citadas no tópico "Como consumir serviços REST", como a ferramenta RESTClient, por exemplo, e incluir na aba "Headers" o parâmetro "Accept" e no campo Value especificar o tipo de retorno primeiro com XML e depois com JSON, conforme Figura 01:

Figura 01 - Testando tipos de retorno para a mesma URI com RESTClient.

Com a anotação @Consumes por outro lado, podemos definir os tipos de mídia que um recurso em particular consome. Como o exemplo da Listagem 05, onde estamos declarando que o método consome apenas formatos do tipo XML e JSON:
@PUT
@Consumes("application/xml","application/json")
@Path("/autores/")
public Response putPessoa(PessoaBinding pessoa) {}
Listagem 05: Uso da anotação @Consumes.

Extraindo parâmetros e valores da URI na requisição.

JAX-RS fornece algumas anotações para extrair informações de uma requisição. Existem seis tipos de parâmetros (ver Tabela 01) que podemos extrair para utilizar em nossa classe recurso. Para os parâmetros de query utilizamos a anotação @QueryParam. Para os parâmetros de URI(path) existe a anotação @PathParam.
Para os parâmetros de formulário existe @FormParam. Já para parâmetros de cookie existe @CookieParam.
Para os parâmetros de header existe @HeaderParam e, finalmente, para os parâmetros de matriz existe a anotação @MatrixParam.
Estas anotações podem ser aplicadas diretamente a parâmetros de um método. Desta forma vinculamos o valor do parâmetro de uma URI a algum parâmetro de entrada de um método. Para contextualizar, veja um exemplo na Listagem 06:
@Path("/editora/")
public class EditoraResource {
  @GET
  @Produces("application/xml")
  @Path("/autores/{nomeAutor}/")
  public PessoaBinding getPessoa(@PathParam("nomeAutor") String name,
                       @QueryParam("idade") int idade,
                       @HeaderParam("CPF") String numCPF,
                       @MatrixParam("statusCivil") String statusCivil) {
     return new PessoaBinding(name, idade, numCPF, statusCivil);
  }
}
Listagem 06 – Mapeando os parâmetros de uma URI para os parâmetros de um método.

Na Listagem 06, vemos a aplicação de várias anotações de parâmetro de URI em um único método. Para entender melhor como será feito o DE-PARA da URI para os parâmetros de entrada, vamos fazer uma chamada a este recurso com a biblioteca curl, apresentado na Figura 02.

Figura 02 - Fragmentando a URI para demonstrar anotações de mapeamento.



Tabela 01 - Anotações JAX-RS para extração de informações da URI.

No exemplo da Listagem 06 não demonstramos o uso das anotações CookieParam e FormParam, mas o seu uso é bem similar. No caso de FormParam, esta anotação pode capturar todos os valores submetidos de um formulário HTML e injetá-los nos parâmetros desejados. Veja um exemplo simples na listagem 07. Trata-se de um formulário HTML e de um método que irá receber estas informações.

Nome: Idade:
@Path("/editora/")
public class EditoraResource {
  @GET
  @Path("/autores/")
  public PessoaBinding getPessoa(@FormParam("nomeAutor") String name,
                       @FormParam("idade") int idade) {
    return new PessoaBinding(name, idade);
  }
}
Listagem 07 - Uso da anotação FormParam.

No caso da anotação CookieParam, conseguimos injetar o valor de cookie ou a classe Cookie do javax.ws.rs.core, que representa o valor de um cookie HTTP na invocação de um método.

Dados de Contexto

A especificação JAX-RS dispõe de um recurso para a obtenção de informações do contexto da aplicação e de requisições individuais. Estas informações são disponíveis tanto para as classes recursos quanto para os providers. Para a recuperação destas informações existe a anotação @Context, que ao ser aplicada sobre um campo, método ou parâmetro, identifica um alvo a ser injetado pelo contêiner.
O contêiner fornece instâncias dos recursos listados na tabela 02, mediante a aplicação da anotação @Context.


Tabela 02: Lista de recursos injetados pelo contêiner pela anotação @Context.

Tratando o retorno dos métodos ao Cliente.

Os tipos de retorno de uma chamada a um método recurso podem ser do tipo void, Resource, GenericType ou outro tipo Java. Esses tipos de retorno são mapeados ao entity body da Response cada um de uma maneira, de acordo o provider padrão, conforme veremos a seguir.
Para os retornos do tipo void, o retorno será um corpo vazio com status 204 do HTTP. Para tratar o retorno ao cliente foi disponibilizada a classe abstrata Response. Com essa classe definimos um contrato entre a instância de retorno e o ambiente de execução, quando uma classe precisa fornecer metadados para ambiente de execução.
Podemos estender esta classe diretamente ou, ainda melhor, podemos criar uma instância utilizando sua classe interna ResponserBuilder. Por essa classe podemos construir objetos do tipo Response, adicionar metadados, adicionar cookies, adicionar dados no Header, informar a linguagem, entre outras informações.
Na Listagem 08, no método putPessoa, fazemos uso do método Response. Note que não a instanciamos diretamente, pois ela é uma classe abstrata que implementa o padrão de projeto Builder.
Dentro do método, primeiramente efetuamos uma chamada ao método estático created, passando como parâmetro a URI que obtemos através da classe injetada UriInfo. Esta classe retorna o objeto ResponseBuilder, que é uma subclasse de Response, esta subclasse é utilizada exclusivamente para criar instâncias de Response.
Por ResponseBuilder ser uma classe de construção (Builder), podemos efetuar chamadas recursivas aos métodos de parametrização. Após a chamada ao método created, chamamos o método status, no qual atribuímos o código de status HTTP 202 (Accepted) e logo após atribuímos uma entidade à requisição, no nosso exemplo um código HTML simples, pelo método entity. Na chamada ao método type seguinte, especificamos o tipo de mídia trafegado, neste caso TEXT_HTML. No final fazemos uma chamada ao método build, que constrói o objeto Response.
E por fim o objeto GenericEntity representa uma entidade de um tipo genérico, muito útil quando precisamos retornar uma Response personalizada e reter informações genéricas. Pois informações de tipos genéricos são apagadas ao utilizar uma instância.

@Context protected UriInfo uriInfo;
@PUT
@Consumes("application/xml")
@Path("/MundoJava/update/")
public Response putPessoa(PessoaBinding pessoa) {
     String retorno = "Bem vindo "+pessoa.getNome();
     Response response = Response.created(uriInfo.getAbsolutePath()).
                                       status(Response.Status.ACCEPTED).
                                       entity(retorno).
                                       type(MediaType.TEXT_HTML).
                                       build();
     return response;
}
Listagem 08 – Tratando a Response do cliente.

Entity Providers

Entity providers fornecem serviços de mapeamento entre representações e seus tipos associados Java. Existem dois tipos de entity providers, MessageBodyReader e MessageBodyWriter.
A especificação JAX-RS define que para alguns tipos, o contêiner pode automaticamente serializar (marshal) e deserealizar (unmarshal) o corpo de diferentes tipos de mensagens, listados na tabela 03.
Tabela 03: Tipos de Mídia e seus tipos Java correspondentes.

Para requisições HTTP, podemos mapear o corpo da entidade para um parâmetro de método com uso da interface MessageBodyReader, para o tratamento das responses, o valor de retorno é mapeado para o corpo da entidade de um método HTTP com uso da interface MessageBodyWriter.
Pode ser que no desenvolvimento de nossas aplicações, estes tipos padrões não atendam a necessidade de negócio e tenhamos que lidar com tipos que não sejam suportados pelos tipos default, para contornar esta limitação, a API JAX-RS permite que a criação de Providers para Message Body customizáveis, com métodos para conversão de InputStream/OutputStream para objetos Java do tipo T.
Para criar nosso próprio provider customizado, a especificação disponibiliza a anotação @Provider, que ao ser aplicado sobre uma classe, estamos automaticamente registrando este classe junto ao contêiner. 
Porém, é importante ressaltar, que esta funcionalidade apesar de muito útil, pode ser tornar um problema em grandes projetos, que podem utilizar providers com o mesmo nome em diferentes bibliotecas, podendo ocasionar conflitos.
Caso a aplicação necessite de informações adicionais, como HTTP Headers ou um código de status diferente, o método pode retornar o objeto Response que encapsule a entidade. 
Veja um exemplo extraído de um sample da implementação de referência da Sun, o Jersey, na listagem 09, esta classe implementa um MessageBodyWriter para uma classe Properties.

@Produces("text/plain")
@Provider
public class PropertiesProvider implements MessageBodyWriter {
    public void writeTo(Properties p, 
            Class type, Type genericType, Annotation annotations[],
            MediaType mediaType, MultivaluedMap headers, 
            OutputStream out) throws IOException {
        p.store(out, null);
    }
    public boolean isWriteable(Class type, Type genericType, Annotation annotations[], MediaType mediaType) {
        return Properties.class.isAssignableFrom(type);
    }
    public long getSize(Properties p, Class type, Type genericType, Annotation annotations[], MediaType mediaType) {
        return -1;
    }
}
Listagem 09: Uso da tag @Provider.
Tratando Exceções

Para tratamento de exceções, a especificação JAX-RS define a exceção WebApplicationException que estende RuntimeExcetion, que pode ser lançada por um método de recurso, por um provider ou por uma implementação de StreamingOutput. Esta exceção permite que abortemos a execução de um serviço JAX-RS. 
Como parâmetro de construtor, podemos utilizar um código de status HTTP ou até um objeto Response. Veja um exemplo na listagem 10:

@GET
@Produces("application/xml")
@Path("/autores/{personName}/{idade: [0-9]+}/")
public PessoaBinding getPessoa(@PathParam("personName") String name, @PathParam("idade")
    int idade, @HeaderParam("CPF") String numCPF) {
    if (idade <= 0 || idade > 120){
        throw new WebApplicationException(Response.
                                          status(412).
                                          entity("Idade inválida!").
                                          build());
    }
  return new PessoaBinding(name, idade, numCPF);
}
Listagem 10: Uso de exceção com WebApplicationException.

Por padrão, quando uma classe JAX-RS ou um método provider lança uma exceção em tempo de execução, essa exceção é mapeada a um código de status HTTP adequado. Nós podemos customizar a nossa exceção conforme a necessidade, para isto, a especificação define a interface ExceptionMapper, com ela podemos criar nossos próprios providers e customizar este mapeamento, para tanto, a implementação desta interface deve estar anotada com @Provider. Veja um exemplo na listagem 11:

@Provider
public class IdadeInvalidaExceptionMapper implements ExceptionMapper{
  public Response toResponse(IdadeInvalidaException ex) {
    return Response.status(412).entity(ex.getMessage()).build();
  }
}
Listagem 11: Mapeando uma exceção Java para uma Response.

Na listagem 11 perceba que registramos a classe ExceptionMapper da mesma maneira que registramos MessageBodyReaders e MessageBodyWriters. Ao utilizarmos a exceção IdadeInvalidaException em um método RESTful como no método da listagem 12, o contêiner irá em tempo de execução identificar o provider e irá mapear esta exceção com IdadeInvalidaExceptionMapper.


@GET
@Produces("application/xml")
@Path("/autores/{personName}/{idade: [0-9]+}/")
public PessoaBinding getPessoa(@PathParam("personName") String name, @PathParam("idade")
int idade, @HeaderParam("CPF") String numCPF) throws IdadeInvalidaException {
    if (idade <= 0 || idade > 120)
       throw new IdadeInvalidaException("Idade Inválida!");
    return new PessoaBinding(name, idade, numCPF);
}
Listagem 12: Uso de exceção de negócio, que é mapeada para Response.
Assim como toda nova tecnologia, JAX-RS não é uma bala de prata, mas sabendo o momento de usá-la se torna uma ferramenta poderosa de integração, em termos de facilidade no desenvolvimento e requerer uma
infraestrutura mais leve, dispensando o uso de um middleware WS-*.
Use e abuse! Diversão garantida!

Princípios, Padrões e Práticas para um Design Ágil na Java Magazine - Parte 2

quinta-feira, 19 de agosto de 2010

Em Julho, saiu a segunda parte do meu artigo Princípios, Padrões e Práticas para um Design Ágil na revista Java Magazine edição 81,  e dando continuidade no artigo publicado na edição 80.

Para esta segunda parte, vamos abordar as diferenças entre a criação de uma arquitetura seguindo métodos tradicionais, como o Waterfall, e a criação de um Design Ágil a partir de ciclos iterativos de duas a três semanas. Além disso, veremos meios de identificar um software mal planejado através de alguns sintomas conhecidos como Design Smells.
Para tratar estes sintomas, abordaremos alguns princípios de Design OO, que são a base de muitos padrões de projeto e que são o produto de várias décadas de experiência com engenharia de software de não apenas um, mas de vários profissionais consagrados no ramo de tecnologia.
Veremos na prática alguns destes princípios, abordando todo o conceito teórico, expondo através de exemplos, sua utilidade e como eles se relacionam com alguns padrões de projeto, e por fim, veremos a aplicabilidade destes princípios nos cenários apropriados para cada um deles.
Para identificar se nosso sistema está com um bom design, Robert C. Martin, popularmente conhecido como Uncle Bob, apresentou alguns sintomas de design ruim, chamado de Design Smells (algo como Odores do Design). Estes sintomas permeiam a estrutura geral do software, e em seu livro Agile Software Development, Uncle Bob chegou a seguinte classificação:



  • Rigidez
  • Fragilidade
  • Imobilidade
  • Viscosidade (Pode ser 2 tipos: Viscosidade do Software e Viscosidade do ambiente)
  • Complexidade Desnecessária
  • Repetição Desnecessária
  • Opacidade

Uma boa técnica para desenvolver um código expressivo é utilizar uma das principais ideias do Domain Driven Design, a Linguagem Ubíqua (ou Onipresente), proposta por Eric Evans. Esta técnica consiste em aplicar uma linguagem comum entre os desenvolvedores e analistas de negócio, utilizando os conceitos do modelo de domínio como forma primária de comunicação, fazendo com que ela seja aplicada tanto nos discursos entre os técnicos e os stakeholders quanto na documentação do sistema. Como consequência, fazemos com que os mesmos termos utilizados no domínio do negócio sejam expressos também no código, o que torna a comunicação mais transparente entre os times durante as discussões sobre o modelo do domínio.


Os sintomas citados acima, podem ser identificados em qualquer parte do sistema e são causados geralmente pela violação de alguns princípios da Programação Orientada a Objetos. Estes princípios, ainda que antigos, são pouco difundidos, mas essenciais para criar um bom Design em qualquer projeto orientado a objetos.
Os princípios que abordaremos no artigo são:

  •  Princípio Aberto-Fechado (OCP – Open-Closed Principle);
  •  Princípio DRY (Don’t Repeat Yourself);
  •  Princípio da Responsabilidade Única (SRP – The Single Responsibility Principle);
  •  Princípio da Substituição de Liskov (LSP – Liskov Substitution Principle);
  •  Princípio do Conhecimento Mínimo (PLK – The Principle of Least Knowledge)

Diversão Garantida!

Introdução a Portais Corporativos

sexta-feira, 13 de agosto de 2010

Se buscarmos a definição de Portal no dicionário, na maioria delas veremos que ele é definido como “uma porta, portão ou entrada”. Quando falamos em Portais web, estamos nos referindo a sites especiais da web ou intranet, que são designados a agir como um gateway de acesso a outros sites.
Um portal agrega informações de múltiplas fontes e torna estas informações disponíveis para diversos usuários. Além de disponibilizar diversas fontes de informações, eles fornecem um guia de serviços que auxiliam os usuários a se direcionarem no meio de tantas informações na internet.
Mais especificamente, um portal não deve ser visto somente como gateway para outros sites, mas para todos os recursos acessíveis na rede, que envolve intranets, extranets ou a própria Internet. Em outras palavras, um portal oferece acesso centralizado para aplicações e todo conteúdo relevante para a empresa/usuários finais. Na Figura 1 apresentamos a arquitetura de um portal, formado por um servidor web, um contêiner de Servlets/Portlets e as aplicações (portlets) para o portal, conforme veremos em detalhes no decorrer do artigo.

Figura 1. Arquitetura de um portal

Durante muito tempo as ferramentas de portal foram ignoradas e até mesmo discriminadas por muitos programadores que achavam que elas eram de uso exclusivo para web designers. Mas com o surgimento da arquitetura orientada a serviços e a busca frenética das empresas em disponibilizar soluções mais baratas e produtivas, com o intuito de reduzir o Time-to-Marketing, esse tipo de ferramenta voltou com toda a força para fazer o que sempre fez: facilitar a vida de todos. A partir desta análise, mostraremos nesse artigo as vantagens do uso de uma ferramenta de portal, e qual o papel do programador neste contexto.
Segurança
A etapa mais cansativa e torturante para um desenvolvedor é ter que gastar seu tempo desenvolvendo módulos de segurança de uma aplicação, sendo que esses módulos geralmente são constituídos por telas de autenticação, tratamentos de usuários e grupos de usuário, utilização de repositórios LDAP, e em algumas vezes a integração com um autenticador para desfrutar do tão desejável Single Sign On .
Além de ter todas essas características, muitas vezes é necessário desenvolver soluções “self-service”, para que o administrador do ambiente de Portal tenha autonomia para gerenciar o repositório de usuários e dar permissões de uso para as funcionalidades da ferramenta.
Praticamente todas as soluções de portal possuem todo esse mecanismo pronto, possibilitando ao programador se dedicar somente no desenvolvimento das aplicações de automatização do negócio.
Conteúdo
No desenvolvimento completo de uma solução como uma “Intranet”, é comum ver que todo o tempo de desenvolvimento é gasto na criação de aplicações para gerenciamento de conteúdo, como funcionalidades de notícias, biblioteca de documentos, áreas institucionais e qualquer outra seção que necessita de um gerenciamento de informações por parte do usuário do sistema. Em um projeto deste tipo, também é comum que todas essas funcionalidades passem por uma governança editorial, e que inevitavelmente necessitem de um mecanismo de workflow. Essas são funcionalidades típicas nas ferramentas de portal, o que fez com que todos achassem que esse tipo de ferramenta só proporcionava esse benefício.
Há empresas que buscam outras soluções que vão além de um simples gerenciamento de conteúdo, indicando que elas devem ser mais robustas e possuir módulos de digitalização, transformação e busca de conteúdo. Esses sistemas, chamados ECM (Enterprise Content Management), muitas vezes dependem de uma ferramenta de portal para disponibilizar o conteúdo trabalhado. Este é só um exemplo de ferramenta que necessita de um portal como camada de visão. E a forma com a qual esse e outros tipos de ferramentas mostram suas funcionalidades é através dos chamados portlets.
Portlet
A internet fornece um conjunto de informações quase que ilimitado para diversos tipos de dispositivos. Com o advento da web foi criado um universo de padrões e protocolos de comunicação, recursos, e uma linguagem de marcação utilizada para apresentação (HTML). Mas a web e seus protocolos foram projetados para atender ao conceito de uma página como um pedaço estático único de informação, apresentado em um navegador, como uma entidade completa e inalterável. Para visualizar outra página, o usuário tem que chamar outra página.
Até o momento, diversos esforços têm sido feitos para superar esta limitação com o uso extensivo de código, como JavaScript/Ajax, ou alguma solução DHTML para trazer ao usuário uma experiência similar e até mesmo superior ao uso de uma aplicação desktop.
Portlet é uma maneira de superar a natureza “tudo ou nada” de uma página HTML. Para defini-los podemos dizer que os portlets são o núcleo dos serviços de um portal, onde uma ferramenta de portal utiliza os portlets como uma interface de apresentação plugável, ou seja, aplicações que podem ser adicionadas em qualquer página em um ambiente de portal, com o objetivo de fornecer qualquer tipo de informação na camada de apresentação.
O conteúdo gerado por um portlet é chamado de fragmento, que na verdade é um pedaço de marcação (ex: HTML, XHTML, etc.) aderente a certas regras, de forma que possamos agregar pedaços de vários fragmentos para gerar um documento.
A página de um portal é composta por um ou mais portlets, que são normalmente agregados com o conteúdo de outros portlets para formar uma página. O ciclo de vida de um portlet é gerenciado pelo contêiner de portlet, conforme veremos logo a seguir. Na Figura 2 apresentamos uma página de exemplo do portal open source Liferay, com a disposição de vários portlets.

Figura 2. Exemplo de uma página de portal
Se olharmos atentamente o conteúdo do navegador na Figura 2, veremos que a página é formada por diferentes janelas. Temos uma janela para um dicionário, outra para um RSS, uma terceira para um calendário, e por último uma para o Google Maps. Cada uma destas janelas representa um portlet. Ao analisarmos o detalhe de cada janela, vamos perceber que cada uma delas contém uma barra de título e alguns botões, incluindo os botões de maximizar e minimizar.
Na verdade, estas janelas são aplicações diferentes, desenvolvidas independentemente uma das outras. O programador desenvolve o portlet como uma aplicação web e empacota em um arquivo .war, e o administrador do portal efetua o deploy deste arquivo .war no servidor de portal e adiciona o portlet recém instalado em uma ou mais páginas do portal.
Pelo fato de você poder colocar o portlet em qualquer página, faz com que você possa reutilizá-lo a todo o momento no portal, até mesmo em uma mesma página. No caso da Figura 3, apresentamos uma página com várias instâncias de um mesmo portlet (Locadora).
Figura 3. Várias instâncias do mesmo portlet em uma página

Repare nesta figura que temos um mesmo portlet na página, mas com instâncias diferentes. A ferramenta de portal tem a responsabilidade de garantir sessões independentes da aplicação, mesmo estando todos na mesma página.
Contêiner
Portlets são executados em um contêiner de portlets. O contêiner fornece aos portlets o ambiente necessário para sua execução e gerenciam o seu ciclo de vida.
O contêiner de portlets recebe as requisições oriundas do portal para executar ações nos portlets em seu ambiente. É importante entender que contêiner de portlets não é responsável por agregar o conteúdo produzido pelo portlet que ele está hospedando, quem faz esta agregação é o próprio portal.
Figura 4. Fluxo de criação de uma página de portal
A Figura 4 acima, apresenta como funciona a construção da página de um portal. Podemos notar que os portlets rodam dentro do contêiner, que recebe o conteúdo gerado pelos portlets. Na seqüência, vemos que o contêiner retorna o conteúdo do portlet para o portal. Por último, o servidor de portal cria a página com o conteúdo gerado pelos portlets e envia para o dispositivo cliente, onde é renderizada (por exemplo, um navegador).
Contêiners de Portlet e Contêiners de Servlets
Os portlets possuem várias similaridades com os servlets, como ambos serem componentes gerenciados por um contêiner especializado, ambos gerarem conteúdo dinâmico, por ambos interagirem com um cliente web através de request/response HTTP. Entretanto, os portlets não podem ser tratados como servlets por conta dos seguintes fatores:
  • Geram somente fragmentos de página no método de renderização, e não documentos completos;
  • Podem somente ser invocados através de URLs construídas através da API de portlet;
  • Clientes web interagem com os portlets através do sistema de portal;
  • Possuem modos pré-definidos de portlet e estados de janela que indicam a função que o portlet está executando;
  • Possuem um tratamento de requisição refinado para action, eventos, requisições de renderização e requisições a recursos;
  • Não possuem acesso a certas funcionalidades fornecidas pelos servlets, como a URL de requisição do cliente ao Portal, ou atribuir o encoding de caracteres para a resposta ao cliente.
Por conta destas diferenças, o JCP decidiu criar para portlets um novo tipo de componente. Porém, ao formular a especificação de Portlets, o JCP procurou sempre que possível, potencializar o uso das funcionalidades fornecidas pela especificação de Servlets. Isto inclui deployment, classloading, aplicações web, gerenciamento de sessão e request dispatching. Por isso, diversos conceitos e partes da API de Portlets foram modelados a partir da API de Servlet.
Os objetos criados em uma aplicação de portal, como portlets, servlets e JSPs são empacotados como uma aplicação web comum (.war), e irão compartilhar o mesmo classloader, contexto de aplicação e sessão no ambiente de execução.
 
No próximo artigo sobre o assunto, vou falar sobre as JSRs 168 / 286 sobre a criação de Portlets. 

Princípios, Padrões e Práticas para um Design Ágil na Java Magazine - Parte 1

Na revista Java Magazine Edição 80, saiu a primeira parte de uma série de três artigos, onde abordarei diversos assuntos relacionados ao desenvolvimento de software em ambientes ágeis.
Como o nome indica, ele é baseado no obra de Uncle Bob, Robert C. Martin, autor de diversos livros importantes como Clean Code, UML for Java Programmers, Extreme Programming in Practice e o clássico Agile Software Development, Principles, Patterns, and Practices , que é o livro que me baseei para escrever este artigo, obviamente, este livro não foi a única fonte de inspiração, pois falei sobre diversos assuntos, como arquitetura de software e Design, princípios não abordados no livro (Pragmatic Programming), DDD, Effective Java, entre outros.
A primeira parte desta série o objetivo é apresentar conceitos relacionados a arquitetura de software, como Estilos de Arquitetura conhecidos (SOA, DDD, Arquitetura em Camadas, 3/N Tiers). Separação de Responsabilidades (Separation of Concerns) Horizontal e Vertical. Arquitetura Distribuída, Tiers e Layers.
E  visa também demonstrar boas práticas de desenvolvimento de software e explicar os princípios fundamentais para se criar um bom design. E analisar também a aplicação de alguns padrões de projeto pouco difundidos, mas que são de extrema importância no dia a dia do desenvolvedor.
Como os Padrões de Projeto Front Controller, Domain Model e Transaction Script.
Em breve vou publicar neste blog alguns artigos para complementar o assunto,
Diversão Garantida!

Academia Agile - Do Coaching ao Kanban

quarta-feira, 17 de março de 2010


 Muitos já sabem que a Globalcode em conjunto com a Fratech  está lançando a Academia do Agile, uma carreira com a carga horária de 108 horas, e composta por 8  cursos que abordam todos os aspectos necessários para formar um profissional ágil.


CódigoNome do cursoCarga
Horária
Apostila
Demo
AG1Implantando e liderando equipes Ágeis12 hs
AG2Criação de produtos com Requisitos Ágeis12 hs
AG3Otimizando a Comunicação através de DDD12 hs
AG4Modelagem Ágil de Software12 hs
AG5Práticas Ágeis de Engenharia de Software com XP24 hs
AG6Gestão de projetos com Scrum12 hs
AG7Gestão de processos com Kanban e Lean12 hs
AG8Estratégia Ágil para Governança em TI12 hs
Resumo da carreira Academia do Agile108 hs


Serei um dos revisores do material e para as próximas turmas um dos instrutores desta Academia, mas o que posso garantir é que o material foi feito pelos maiores especialistas na área, meus amigos Felipe Rodrigues da Fratech e Manoel Pimentel editor chefe da revista Visão Ágil.

A primeira turma está com 25% de desconto, pelo preço é uma ótima pedida para quem quer conhecer a fundo as disciplinas do Agile.

Segue alguns dos temas que irá rolar em cada módulo.

AG1Implantando e liderando equipes Ágeis
  • Facilitação
    • O que é facilitação
    • Abordagem cognitiva para facilitar mudanças
    • Um breve passeio pela mente humana
    • Estimulando a Neuroplasticidade
    • Compreensão do Sistema Límbico
    • Técnicas de Facilitação durante as atividades Agile
    • Os Seis Chapéus do Pensamento
    • Feedback efetivo através da janela de JOHARI
    • O Que? Para que? E como causar a mudança com a TOC(Theory of Constraints)
    • O desenvolvimento da confiança entre indivíduo
    • Planejamento de eventos de facilitação
  • Coaching
    • Objetivo do Coaching
    • Desfazendo mitos acerca do Coaching
    • Papéis no processo de Coaching
    • Condição Humana
    • Missão e Ideal
    • Valores e Crenças
    • Consciência e Responsabilidade
    • Perguntas Eficazes para gerar mudanças
    • Motivação (verdades e mentiras)
    • Vencendo o Inner Game
    • FFA (Force Field Analysis)
    • Ganhos e Perdas
    • Modelo FARM
    • Modelo GROW
    • House of Change
    • Estrutura das sessões de Coaching
  • Liderança
    • Gestão do tempo para gerar ROE
    • Empatia
    • Técnica Pomodoro
    • GTD - Getting Things Done
    • Covey Planning
    • Liderança baseada em Coaching
    • Coaching para Equipes
    • O Coaching num ambiente Ágil
    • O que fazer com impedimentos?
    • Projeto de aplicação prática de Coaching
AG2 - Criação de produtos com Requisitos Ágeis

  • Definição de escopo
    • O produto do ponto de vista de negócio
    • As dimensões do escopo (Tamanho, simplicidade e aderência.)
    • Processo de aprendizado de escopo
    • Estado Lean para o desenho de software
    • Requisitos ágeis e os casos de usos?
  • User Stories
    • Modelando Papéis
    • Representando desejos com User Story
    • Formato para User Story
    • O modelo INVEST
    • Usando Temas e Épicos
  • Features segundo o FDD
    • Representando desejos com Features
    • O modelo ARO (Ação Resultado Objeto)
    • Aplicando a FBS (Feature Breakdown Structure) da FDD (Feature Driven Development)
    • Usando Áreas e Atividades
    • Priorização por Áreas, Atividades ou Temas
  • Definindo o modelo de Entrega
    • Estratégia de entrega em alto nível
    • Critérios de Aceitação em diferentes níveis
    • DoD (Definition of Done) em diferentes níveis
    • Monitoramento de resultados
  • Aplicando a TOC na engenharia de requisitos
  • Documentação pós-projeto

AG3 - Otimizando a Comunicação através de DDD

  • Introdução ao Domain Driven Design
  • Sinergia entre Domain Driven Design e os princípios Ágeis
  • Uma Linguagem Unificada e abrangente
  • Visão Arquitetural do Domain Driven Design
    • Arquitetura em Camadas
    • Objetos de negócio com Domain Objects
    • Ciclo de vida dos Domain Objects
  • Mantendo um domínio flexível com Supple Design
    • Práticas de suporte
    • Refactoring em busca de aprofundamento
  • Integrando vários domínios com Strategic Desing
    • Delimitando os contextos
    • Integração entre contextos diferentes
    • Estratégias de integração

AG4 - Modelagem Ágil de Software

  • Introdução à Modelagem de software
  • Modelagem no contexto da agilidade
  • Ciclos de modelagem ágil
  • Modelagem em equipe
  • Visualização do modelo
  • Diagramas simples e práticos com Agile Draw
  • Modelagem Ágil e UML
  • Resultados da modelagem ágil
  • Entregáveis

AG5 - Práticas Ágeis de Engenharia de Software com XP

  • Introdução ao Extreme Programming
  • Modelo cíclico de entrega
  • Ciclo PDCA
  • Test Driven Development
    • O modelo Test First
    • Modelando através dos testes
    • Relação custo-benefício dos testes
  • Behavior Driven Development
    • Especificação executável com BDD
    • Casos de negócio
    • Ferramentas de BDD
    • Relatórios de BDD
  • Integração Contínua
    • Processo de desenvolvimento com integração contínua
    • Repositórios de código fonte
    • Integração contínua e os testes
    • Servidores de integração contínua
    • Principios importantes
  • Inspeção
    • Pair-Programming
    • Inspeção segundo o FDD
    • A Inspeção e a Definição de Pronto

AG6 - Gestão de projetos com Scrum

  • Abordagens Ágeis
    • Imergindo no Scrum
    • Conhecendo as fases e ciclo de vida do Scrum
    • A FDD (Feature Driven Development) e como combiná-la com o Scrum
    • Entendendo a influência Lean
  • Engenharia de Requisitos para compor um bom Product Backlog
    • FBS (Feature Breakdown Structure) da FDD
    • Compondo o Product BackLog com funcionalidades
  • Planejamento
    • Os papeis do Scrum
    • O conceito de Sprint
    • Entregas freqüentes de valor para o cliente
    • Gerenciando Business Value
    • Sprint Planning Meeting
    • Desdobramento em tarefas
    • Características do Sprint BackLog
  • Estimativas
    • Apostando no Planning Poker
    • Descobrindo a complexidade
    • Conhecendo o tamanho das coisas
    • Trabalhando com estimativas em horas
    • Qual a granularidade necessária para as estimativas
  • Desenvolvimento
    • Scrum Daily Meeting
    • Gestão de Impedimentos
  • Métricas e Acompanhamentos
    • Foco no Escopo ? Entrega de software funcionado
    • KanBan para facilitar a comunicação durante o processo
    • Conhecendo o BurnDown Chart
  • Entregas
    • Sprint Review
    • Testes de Aceitação
  • Melhoria contínua
    • Sprint Retrospective
    • Uma breve introdução em TOC (Theory Of Constraints) para o Processo de Mudança 
  • Imersão
    • Durante todo o workshop será realizado um laboratório prático através da dinâmica de construção.

AG7 - Gestão de processos com Kanban e Lean
  • Cultura e Filosofia Lean
    • O que é Lean
    • Pensamento Enxuto
    • Impactos econômicos do pensamento enxuto
    • Tipos de cenários para o pensamento Lean
    • Perspectiva de Consumo
    • Geração de Valor
    • Eliminação das Perdas
    • Respeito e Desenvolvimento de Pessoas
  • Ferramentas Lean
    • Hansei e Kaizen para melhoria contínua
    • Poka-Yoke e Jidoka para ajudar a qualidade
    • Andon e Kanban como meio de comunicação
  • Gestão Lean
    • Planejamento e Gestão com pensamento A3
    • WIP (Work-In-Process)
    • Pull System
    • Visualizando o VSM - Value Stream Map
    • O que é Lead Time?
    • Identificando Restrições
    • Resolução de Problemas com The Five Whys
    • Aplicando o clico PDCA
    • Definindo demanda
    • Definindo tamanho
    • Definindo capacidade
    • Usando o sistema Kanban
  • Adoção
    • Aplicação em equipes de projetos
    • Aplicações de equipes de sustentação
    • Lean/Kanban com Scrum
AG8 - Estratégia Ágil para Governança em TI

  • Visão Geral do Ecossistema
    • Pessoas
    • Processos
    • Práticas
    • Ferramentas
    • Parceiros
    • Filosofia e Cultura
    • Missão, Valores e Propósito
  • Introdução ao Enterprise Agile
    • Agile Project Management
    • Enterprise Scrum
    • Engenharia de Software com FDD
    • Lean/KanBan para gestão de processos
    • Definindo escopo de atuação para Agile
    • Planejamento de adoção/implementação de Agile
  • Framework de TI
    • Gestão de Demandas
    • Gestão de Portfólio
    • Gestão de Configuração
    • Gestão de Mudanças
    • Gestão de Serviço de TI
    • Planejamento Estratégico
    • Gestão Financeira
    • Geração de Conhecimento
  • Integrações
    • Dialogando com ITIL e COBIT
    • Gestão Ágil em ambientes PMBoK
    • Agile com modelos de certificação
    • Convivendo com processos auditáveis por órgãos reguladores

Pelo conteúdo apresentado acima, é fácil entender o porque este curso é a formação mais completa que existe sobre agilidade não só no Brasil, mas talvez no mundo, abordando temas como DDD, FDD, BDD, TDD, Lean, Kanban, XP, Scrum, passando por Coaching, e Governança em TI.





A primeira turma começa agora dia 26/03, as aulas serão intercaladas de 15 em 15 dias com aulas ás sextas e sábados. Nos vemos por lá!

Diversão Garantida!!!