Estilos de Arquitetura e Separação de Responsabilidades para um Design Ágil

Com a grande demanda de profissionais por parte das empresas, muitos deles acabam sendo contratados sem ter o devido conhecimento sobre boas práticas de desenvolvimento de software, infraestrutura de desenvolvimento, protocolos de comunicação, sistemas gerenciadores de banco de dados e muitas vezes até conhecimento básico sobre sistemas operacionais.

Além disso, dentro das empresas existe uma demanda cada vez maior por projetos de software de alta complexidade, com prazos de entrega na maioria das vezes fora da realidade. O que faz com que muitos projetos sejam entregues sem testes, com falhas de implementação, qualidade duvidosa e muitas vezes sem atender ao negócio do cliente.

Como consequência, após implantado, o sistema passa a apresentar sérios problemas como degradação da performance, perda de dados, cálculos incorretos, entre outros problemas, trazendo grandes prejuízos à empresa e fazendo com que os usuários percam a confiança no sistema e por fim os próprios desenvolvedores.

Direcionado para este cenário, o presente artigo visa demonstrar boas práticas de desenvolvimento de software e explicar os princípios fundamentais para se criar um bom design. Veremos 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.

Estilos de Arquitetura

Quando vamos planejar o desenvolvimento de um software, geralmente um dos primeiros itens que o arquiteto de software começa a analisar é qual o melhor estilo de arquitetura que se aplica ao
contexto do projeto. Neste ponto ele leva em consideração diversos fatores, como os requisitos do software, custo, infraestrutura e conhecimento técnico da equipe.

Entender o estilo arquitetural adotado para o desenvolvimento traz diversos benefícios para os desenvolvedores e para a empresa como um todo, entre eles: fornecer uma linguagem comum entre os desenvolvedores e os demais envolvidos no projeto.

Por exemplo, quando o estilo de arquitetura é SOA, os desenvolvedores podem até conversar com pessoas de outras áreas, que não possuem conhecimento técnico (como detalhes da linguagem de programação, servidores de aplicação, etc.), sobre o método envolvido na automação dos processos de negócio, que as mesmas entenderão sobre o que é um serviço, governança e, dependendo do usuário, até termos mais específicos, como escalabilidade.

A Tabela 1 apresenta um resumo dos principais estilos de arquitetura.

Estilo de Arquitetura	Descrição
Client-Server	Também conhecida como arquitetura de duas camadas. Este tipo de arquitetura descreve a interação entre um ou mais clientes e um servidor, através de uma conexão de rede. A aplicação mais comum para esse tipo de arquitetura é um Banco de Dados no lado do servidor com a lógica da aplicação representada em Stored Procedures, e o lado do Cliente representado por aplicações conhecidas como Fat-Clients (Clientes Pesados), que muitas vezes contêm a lógica de negócio embutida no front-end. Como exemplo, podemos citar aplicações desenvolvidas com Delphi, Visual Basic, Oracle Forms, entre outros.
Arquitetura baseada em Componentes	Quando utilizamos uma arquitetura baseada em componentes, decompomos o design da aplicação em componentes lógicos com um fraco acoplamento, de forma que cada um deles seja individual e reutilizável, com uma localização transparente e interface de comunicação bem definida. Uma das grandes vantagens desse tipo de arquitetura é que ela promove a reusabilidade dos componentes e facilita a manutenção da aplicação.
Domain Driven Design	De acordo com o próprio criador, Eric Evans, DDD não é uma tecnologia e nem uma metodologia. DDD é um estilo de arquitetura orientado a objetos, focado em modelar o domínio do negócio e a lógica do domínio com o uso de técnicas, práticas e padrões de projeto.
Arquitetura em Camadas	Esse é o estilo de arquitetura mais conhecido e mais utilizado para o desenvolvimento de aplicações. Ele permite a separação dos módulos do sistema em camadas (layers) diferentes. As principais vantagens desse estilo são a facilidade de manutenção, o aumento da extensibilidade, reusabilidade e escalabilidade.
3-Tiers/N-Tiers	Esse estilo segrega as funcionalidades em segmentos separados de maneira similar ao estilo da arquitetura em camadas, mas com cada segmento alocado em camadas físicas (tiers) separadas, conforme veremos em detalhes no tópico “Arquitetura Distribuída”.  Ele é ideal quando o projeto demanda escalabilidade. Para isso, as camadas lógicas (layers) da aplicação são alocadas em máquinas diferentes.  Geralmente, ao mapear as camadas lógicas (layers) para as físicas (tiers), podemos criar um cluster ou um farm na mesma camada física para aumentar a performance e a confiabilidade da aplicação.
Arquitetura Orientada a Serviços(SOA)	SOA já deixou de ser apenas uma palavra no meio de TI para se tornar um modelo consagrado adotado em muitas empresas. Uma arquitetura orientada a serviços nada mais é do que uma aplicação que expõe e consome as funcionalidades do sistema como serviços por meio de contratos e mensagens.  Algumas das características de uma Arquitetura Orientada a Serviços são: a independência da Plataforma, comunicação baseada em serviços entre os componentes de software, integração de múltiplas funcionalidades em um único componente de interface do usuário e a exposição dos serviços por meio de repositórios ou catálogos.
Arquitetura Orientada a Objetos	Ao aplicar esse estilo, o sistema é dividido em objetos individuais, reutilizáveis e autossuficientes. Cada objeto contém os dados e o comportamento pelos quais é responsável. Uma arquitetura orientada a objetos geralmente busca espelhar objetos do mundo real de modo a tornar simples a modelagem da aplicação.

Tabela 1. Estilos de Arquitetura.

Cluster: É um conjunto de computadores interligados que trabalham em conjunto como se fosse um único computador. Estes computadores são utilizados para suportar aplicações que têm necessidade de alta disponibilidade e alta capacidade de processamento.
Farm: Um Servidor Farm, também conhecido como Data Center, é um conjunto de servidores mantido (geralmente) por uma empresa para atender as necessidades computacionais da corporação, como o processamento de grandes volumes de informação, atender aos sistemas corporativos e prover servidores de contingência no caso de um problema no computador principal.
Repositório: Um Repositório é um local onde todos os clientes de um domínio específico publicam seus serviços, de maneira que todos os usuários passam a conhecer os serviços disponíveis e como acessá-los.
Para tanto, um repositório deve ter uma interface bem definida para publicação dos serviços, funções para localização, controle e maneira uniforme de acesso.

Uma vez que o estilo de arquitetura é definido, o passo seguinte é definir como as funcionalidades do sistema serão divididas, de forma a manter em conjunto os componentes relacionados (alta
coesão), e fazer com que estes possuam o mínimo de conhecimento sobre os outros componentes (baixo acoplamento). Para alcançar o baixo acoplamento e uma alta coesão é importante entender o conceito de Separação de Responsabilidades.


Separação de Responsabilidades (Separation of Concerns)

O termo Separação de Responsabilidades foi criado pelo pai do algoritmo de caminho mínimo, o cientista Edsger W. Dijkstra em 1974, e tem como objetivo dividir a aplicação em funcionalidade distintas com a menor similaridade possível entre elas. Para aplicar com sucesso este princípio, o mais importante é minimizar os pontos de interação para obter alta coesão e baixo acoplamento entre os componentes do sistema. Para tanto, é recomendado, primeiro dividir suas responsabilidades e organizá-las em elementos bem definidos, sem repetição de código ou de funcionalidade.

O tipo de separação de conceito mais difundido é o da separação horizontal, onde dividimos a aplicação em camadas lógicas de funcionalidades, como por exemplo, o protocolo TCP/IP (modelo OSI), que é separado pelas camadas de aplicação, transporte, rede, enlace e física. Neste modelo, cada camada tem sua própria responsabilidade e não precisa conhecer as camadas adjacentes. Voltando ao nosso mundo, em uma aplicação Java EE, as camadas mais conhecidas são a de Apresentação, Serviço, Domínio e Infraestrutura, como ilustra a Figura 1.

Figura 1. Separação Horizontal de Conceitos (Camadas lógicas de uma aplicação).

Podemos também aplicar o tipo de separação vertical, onde dividimos a aplicação em módulos ou funcionalidades que são relacionadas a um subsistema ou grupo de operações dentro de um sistema.
Veja um exemplo na Figura 2.

Figura 2. Separação Vertical de Conceitos.

Separar as funcionalidades de uma aplicação em módulos deixa claro as responsabilidades e dependências de cada funcionalidade, o que ajuda na execução dos testes e na manutenção do
software. Na Figura 2 fazemos um agrupamento por módulos; neste caso a separação foi feita pelos módulos de RH, Contábil e Marketing.

Além disso, podemos utilizar o conceito de separação vertical em conjunto com o conceito de separação horizontal. Veja um exemplo na Figura 3.

Figura 3. Aplicação da Separação de Conceitos Vertical e Horizontal.

Um papel importante da separação de conceitos é o da separação de comportamento, que envolve a divisão dos processos do sistema em unidades lógicas de código reutilizáveis e gerenciáveis. Ao organizar o comportamento, alcançamos os seguintes benefícios:

• Eliminamos a duplicação de funcionalidades;
• Minimizamos as dependências externas;
• Maximizamos o potencial para reuso;
• Restringimos o escopo do trabalho para os limites de cada módulo.

Como vimos, é importante entender a separação de conceitos pois ao modelarmos uma aplicação devemos ter conhecimento das responsabilidades de cada um de seus componentes. Além disso, devemos ter uma ideia de como será feita esta separação e como será feita a distribuição destes componentes na arquitetura disponível pelo cliente.

Para tanto, é preciso levar em consideração outros fatores, como infraestrutura e recursos disponíveis, conforme veremos a seguir, no próximo artigo da série.

Referências

Excelente artigo sobre separação de responsabilidades
http://www.aspiringcraftsman.com/2008/01/art-of-separation-of-concerns/

Biografia de Edsger Dijkstra.
http://pt.wikipedia.org/wiki/Edsger_Dijkstra

Guia de Arquitetura de Aplicações da Microsoft.
http://www.codeplex.com/AppArchGuide

Continuous Delivery, DevOps e Innovation Games na UFSCar

Ano passado, tive a oportunidade de palestrar em eventos importantes como o TDC 2011 em São Paulo, organizado pela Globalcode e no aniversário de 10 anos do evento É Dia de Java, realizado na Faculdade Federal de São Carlos (UFSCar), organizado pelo SOUJava.

Ainda no TDC, participei do painel "O que vem depois do Agile?" com nomes bem conhecidos pela comunidade Ágil. Publiquei um post recentemente sobre o Painel e uma palestra sobre DataGrid e NoSQL com JBoss Infinispan, que em breve publicarei aqui.

O evento É Dia de Java 2011 foi muito especial, primeiro porque foi a celebração de 10 anos do evento, e também porque pude reencontrar grandes amigos como André Fonseca, Vinícius Senger da Globalcode, Fabio Velloso e Bruno Souza do SOUJava e ter a satisfação de conhecer o grande Daniel Wildt.

O evento foi bem bacana, na sexta feira o dia foi reservado para a realizacao de Workshops praticos, no meu caso, fiz um workshop de Innovation Games, uma aborgagem lúdica inovadora criada por Luke Hohmann, para auxílio na criação de produtos, condução de retrospectivas e análise de problemas.

Realizei com a turma, jogos como Product Box, Remember the Future, Speed Boat e como plus (não é um Innovation Game), fizemos uma retrospectiva utilizando a técnica dos 06 Chapéus do Pensamento.

Abaixo uma das Product Box criada por um dos grupos.

No dia seguinte, foram várias palestras, sem falar que o evento estava lotado.

Minha palestra foi sobre Continuous Delivery e DevOps, o feedback foi muito bom, e várias pessoas solicitaram os slides. Sendo assim, aqui está.

Continuous Delivery e DevOps

View more presentations from wrsantos

Parabéns as pessoas que organizaram e participaram do evento na UFSCar e a Globalcode pelo excelente TDC. Esse ano se Deus quiser tem mais.

* Crédito ao pessoal da OCTO por alguns dos slides sobre Integração Contínua.

Diversão Garantida!!!

Continuous Delivery: Case de Sucesso com tecnologias .NET - Deploy em 7000 máquinas com apenas 3 cliques

Em um recente artigo, Maxence Modelin discute de maneira bem detalhada, como a OCTO Technology, criou um fluxo de implantação (Deployment Pipeline), onde com apenas 3 cliques, o deploy de um serviço Windows é feito em 7000 máquinas, de um fornecedor de serviços de hosting, localizado na França.

 A solução descrita, cujo foco envolve o deploy de um serviço Windows, desenvolvido em C#, que se comunica via FTPS com um servidor Java.

Uma caracteristica importante da solução, é o uso de uma plataforma de Integração Contínua baseado em ferramentas open-source, bem populares na comunidade Java, ao invés do uso do Team Foundation Server fornecido pela Microsoft.

Entre as tecnologias utilizadas para Integração Contínua, podemos destacar Jenkins como Servidor de Integração Contínua, Maven para gestão do projeto e Nexus para a gestão do repositório.

Para administração do farm de servidores, foi utilizado o software OCS Inventory. Um aplicativo web, responsável por centralizar todas as informações pelos Agentes OCS instalado em cada um servidores do farm. Que por sua vez, através das informações recebidas, efetua o deploy dos pacotes necessários nos servidores, sem a necessidade de uma ação do usuário.

Para monitoração do ambiente, foi utilizado Zabbix.

A cadeia de entrega contínua, se resume a apenas 3 cliques, onde o primeiro deles, começa com a operação de commit no SVN, que inicia o processo de integração contínua orquestrado pelo Jenkins. Que após efetuar o checkout do projeto, executa o script do Maven, que efetua o build, executa os testes, e por fim, armazena os artefatos gerados no Nexus.

O segundo clique, é para criação do pacote OCS, onde um profissional de operações (ops), executa um script shell, que extrai o artifato do Nexus e disponibiliza o pacote pronto para deploy no banco de dados do OCS.

Para o terceiro clique, no contexto da empresa, este último passo é considerado um passo funcional, e não existe razão de ser automático. Quem decide quais máquinas irão receber os pacotes, são os profissionais de operações, através do OCS. Os desenvolvedores tem o mesmo acesso, porém, para fazer o deploy em ambiente de testes.

Para assegurar que tudo ocorreu corretamente, operações utiliza duas ferramentas para feedback, que são o próprio OCS e Zabbix, e um usuário fake. Este usuário fake, é responsável por efetuar o download dos pacotes nas máquinas destino, e verificar se tudo ocorreu conforme o esperado.

A figura a seguir, descreve os softwares e ações realizadas durante o fluxo de implantação.

Um dos fatores imprescendíveis para o sucesso da Implantação Contínua, foi a abordagem DevOps dada ao projeto. Esta abordagem abriu a oportunidade para um compartilhamento das necessidades e visão entre os times de Desenvolvimento e Operações.

Pois com a responsabilidade do deployment a cargo do time de desenvolvimento, ao invés do time de operações, talvez eles nunca teriam a real noção do trabalho realizado.

E você, tem alguma estória de sucesso sobre implementações de Continuous Delivery e DevOps? Comente, discuta, colabore!

Nota: O artigo que o texto destaca é um pouco antigo, mas como esse post era para ser uma notícia na InfoQ Brasil no ano passado, mas como não foi aprovado então resolvi publicar aqui. Espero que curtam! Pois o case foi bem interessante, por se tratar de um case de Continuous Delivery para um aplicativo .NET, utilizando ferramentas open source Java.

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

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!

Introdução a Portais Corporativos

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. 

Evento InfoQ Brasil

No dia 01/11/2008 rolou o evento de inauguração do Portal InfoQ Brasil, nas palavras do meu amigo Manoel Pimentel,

"Agora a comunidade Brasileira de desenvolvimento de software, possui um importante aliado de nível internacional, pois já está no ar, a versão Brasileira do portal InfoQ, que trata com maestria de assuntos como Java, .NET, Ruby, SOA, Agile e Arquitetura.

Com o nome de InfoQ Brasil, este projeto está sendo possível através da empresa Fratech It e com uma enorme participação da comunidade Brasileira, pois através de um mega projeto com equipes distribuídas, reunimos vários autores e editores do portal, com a meta de traduzir vários artigos, notícias e um importante livro sobre Scrum e XP para o português.

Como marco desse acontecimento histórico para o Brasil, no sábado passado, dia 01 de novembro de 2008, realizamos o InfoQ Launch Meeting (Encontro de Lançamento), no auditório da Faculdade Anhembi Morumbi em São Paulo(SP), com o importante patrocínio da Locaweb e do JCP (Java Community Process) e com o apoio da empresa Teamware, DeveloperWorks e claro, com uma grande participação da comunidade Brasileira.

O evento contou com dois palestrantes internacionais de peso, pois tivemos o Max Lanfranconi, Gerente de Marketing do JCP e Floyd Marinesco, CEO e fundador da InfoQ internacional.

Também tivemos ótimas palestras, feitas por grandes nomes de nossa comunidade nacional como Giovanni Bassi, Fábio Akita, Henry Conceição, Vinícius Senger, Alexandre Gomes, Felipe Rodrigues, Yara Senger, Victor Hugo, Rodrigo Yoshima, Hugo Corbucci, Wagner Santos e Manoel Pimentel, onde cada um deles, dentro de sua especialidade, falou sobre Java, .NET, Ruby, SOA, Agile e Arquitetura.

E no melhor estilo de uma QCon, tivemos dois grandes painéis, um sobre Plataformas distribuídas e outro sobre Agilidade no dia a dia, que fizeram com que todo o público participasse de maneira ativa de ótimas discussões sobre esses dois temas."

Na minha palestra falei sobre arquitetura, explicando as suas origens, e o papel do arquiteto nos dias de hoje, as palestras tiveram uma duração de 30 minutos (algumas passaram o tempo, claro =) , e alguém perguntou,
"Como falar de Arquitetura em 30 minutos ?", bom, para quem falou de EJB 3.1 e apresentou ainda uma DEMO em 5 minutos no Lightining Talk do Sun Tech Days 2008 (Foto ao lado), 30 minutos é luxo.. =)





Segue abaixo minha apresentação, o upload foi feito gentilmente pelo Manoel,

InfoQ Brasil - Arquitetando o Futuro da TI - Por Wagner Santos

View SlideShare presentation or Upload your own. (tags: arquitetura tendênias)

E algumas fotos..



O evento fui muito bom, encontrei os editores, amigos, conheci novas pessoas, tive o prazer de conhecer Felipe Rodrigues, da Fratech, o simpático Max Lanfranconi , gerente de marketing JCP e o próprio Floyd Marinescu =)..

Diversão Garantida !!!

[Resumo Executivo] Evento Smart SOA 2008 IBM

Na semana passada, no dia 08 estive presente no evento Smart SOA da IBM, uma iniciativa da IBM que levou para 100 cidades ao redor do mundo as novidades em Smart SOA e o lançamento da nova linha de produtos WebSphere, e preparei um resumo executivo do que vi.

O evento foi focado na nova linha produtos Websphere da IBM para suporte a implantação de SOA e foi demonstrado um case de sucesso, da empresa OJC - Organizações Jaime Câmara (TV Anhanguera). Que adotaram a linha de produtos da IBM para implantar os seus processos.

Na primeira apresentação, o vice-presidente de marketing de produto WebSphere Paul Brunet, deu uma introdução ao conceito de SOA e em BPM, neste último tópico, ressaltou a importância da área de negócio mapear os seus processos com BPM.

Afirmou que uma implantação de SOA, requer mudanças nos planos de negócio, e demonstrou alguns números interessantes, como por exemplo, que no mundo dos negócios, 83% dos CIOs esperam mudanças reais em seus processos de negócio, e que 98% dos planos de negócio mudam em decorrência da estratégia corporativo, que por sua vez buscam mais performance e agilidade em seus processos de negócio.

Citou também as prioridades TOP dos CIOs que são:

• Tornar os processos locais (departamentais) em processos globais (corporativos).
  
• Tornar os processos que são automáticos e visíveis em processos dinâmicos, de fácil adaptação e baixo tempo de resposta.

Foi proposto que BPM possibilita a mudança do negócio, sendo SOA o Core (Núcleo) do BPM. Após a apresentação dos conceitos, foi dada uma visão geral do ferramental, entre seus produtos podemos destacar:

WebSphere Process Server para gerenciamento de tarefas humanas e orquestração de processos. O produto oferece visibilidade dos processos em real time de forma consolidada e customizada.

Monitoração dos processos chaves (KPI) e configuração para recebimento de email de acordo com índice.

WebSphere Business Modeler que é uma ferramenta gráfica para gerar os diagramas do BPM, e que é possível gerar os processos executáveis (geração de código). É possível importar modelos criados no Visio e PowerPoint para esta ferramenta.

WebSphere Business Monitor monitoração dos processos e eventos de negócio.

WebSphere Business Events que é um módulo para a parametrização de eventos do sistemas, onde foi explanado o conceito de BEP - Business Event Process, integrado com o módulo WebSphere Business Monitor,

E finalmente foi apresentado o IBM BPM Suite, que é a suíte de ferramentas para SOA da IBM, que fornece em seus módulos o gerenciamento dos eventos de negócio, o controle do conteúdo ativo, relatórios analíticos que dão uma visão real-time das vendas, um engine de regras, seleção de serviços e policies.

Na apresentação de Takeshi Kamimura, ele explicou a importância do alinhamento entre TI e da área de negócio para a implantação de SOA, sem este alinhamento não é possível montar uma arquitetura orientada a serviços. Apresentou estudos que provam que quando existe um alinhamento entre TI e negócios os ganhos de produtividade DUPLICAM.

E apresentou em um quadro padrão das fases de implantação de SOA por abordagem, o percentual em que as empresas brasileiras hoje se encontram.

Como criar o alinhamento entre TI e as áreas de negócio:

• Desenvolver uma linguagem compartilhada, que TI e negócio entendam.
• Deixar claro as prioridades (compartilhada).
• Estabelecer equipe para tomada de decisões conjunta.
• Utilizar uma linguagem de mercado.
• Fazer referência à validação externa. (O que existe de melhores práticas no mercado)

Na apresentação do case de sucesso da OJC, Júlio de Oliveira o atual gerente de TI explicou o que os motivou a adotar SOA e a escolha da IBM como parceira. Foram feitas Provas de Conceito, RFP, RFI que apontaram a necessidade de mudança para SOA. Este estudo revelou a IBM como a empresa que atende o negócio. Após escolher a IBM como fornecedora e com base nestas informações montaram uma matriz SWOT para implantação de SOA, que foi aberta para o público, conforme segue:

Para as fraquezas foi montado um plano de ação conforme segue:

• Reestruturação da equipe.
• Fixação dos conceitos SOA.
• Treinamentos contínuos em Java.
• Workshops sobre as ferramentas.
• Hands-On.
• Envolvimento dos consultores do ERP.
• Foco nas especificações de regras de negócio e na integração.
• Treinamento Oficiais IBM.
• Mentoring por Terceiros.
• Migrar de forma gradual.

Plano de Ação para as Oportunidades.

• Apresentar conceitos macros, as oportunidades imediatas e as possibilidades em longo prazo (Planejamento Estratégico).
• Exposição dos resultados parciais. (Quick Wins).
• Pulso Firme:
• Equipe
• Parceiros
• Clientes Internos.

E por fim, eles apresentaram o case selecionado (Faturamento) para implantação, os fatores que o levaram a escolher este case foram a Relevância, a Rastreabilidade, o Monitoramento e o Risco agregado, tudo isso alinhado aos objetivos do negócio. Com base nestas informações eles selecionaram o sistema de Faturamento.

É importante frisar que em dois anos de implantação de SOA, hoje eles estão em transição para a fase de Transformação (vide quadro acima), e que eles fizeram esta migração para SOA de forma gradativa, e que somente HOJE estão estruturando uma área de Governança em TI, que até então não existia.

Algo que para ser sincero eu nunca teria pensado, até ver a palestra, para mim era inconcebível implantar SOA sem governança. Vivendo e aprendendo !!!