The Developers Conference 2012

sexta-feira, 8 de junho de 2012


Este ano, vamos marcar presença novamente no evento The Developers Conference 2012
 O evento TDC, é o maior evento de profissionais de TI do Brasil! Mais de 30 trilhas sobre diversas especialidades e  tendências em gestão e tecnologia.



A novidade, é que este ano sou um dos coordenadores das trilhas Arquitetura e Agile
Para a trilha de Arquitetura, estamos buscando criar uma trilha com palestras de alto nível e mais agnóstica. De forma que profissionais de qualquer plataforma possam tirar o máximo de proveito.

Para a trilha Agile, o tema deste ano é "Agile no Mundo Real", seguindo esta linha, estamos trazendo palestras e profissionais para mostrar o que realmente tem acontecido no mercado de agilidade, quais as ferramentas para resolução de problemas utilizados em um projeto de Gestão de Mudança para Agilidade e temas atuais.

Se você quer ser um palestrante, submeta sua proposta no Call4Papers, mas corra, que é o prazo de submissões é até domingo. :)

Nos vemos lá! Diversão garantida!

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

quarta-feira, 1 de fevereiro de 2012

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

quinta-feira, 19 de janeiro de 2012

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é FonsecaViní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á.
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

segunda-feira, 16 de janeiro de 2012


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.


Jez Humble on Continuous Delivery and DevOps

sexta-feira, 13 de janeiro de 2012


In the last year, during the period i have been in France, attending Université du SI, one of the best conferences i've participate in whole life (sponsored by OCTO Technology), i had the privilege of being invited to participate in a very interesting course with Jez Humble,  about Continuous Delivery for DevOps.
After the course, i could make an interview for InfoQ Brazil, but for obvious reasons we translated it to Brazilian Portuguese. And now, here goes the original version. Enjoy!

You wrote a best seller, called Continuous Delivery, What is it all about?

It's about all the stuff that is normally considered somewhat peripheral to software development - configuration, build and deployment management, automated testing, continuous integration, infrastructure and database management. However the discovery that many of us made while working on large agile projects was that this stuff is essential if you want to be able to reliably, repeatably release high quality software.

Actually many of the ideas in the book aren't new. It's really a call to arms to focus on the engineering practices that were always at the heart of agile methodologies, but that somehow got sidelined in many places over the last ten years. Of course several tools like Puppet, Chef, Git and DbDeploy have emerged that didn't exist ten years ago that make much of this stuff much more tractable.

It turns out that the engineering practices - particularly automation of build, test, deployment, and database and infrastructure management - and collaboration between development, testing and operations - are really essential to be able to get high quality software delivered fast. And that, in turn, is central to the ability of organizations to innovate and get new features out of the door quickly and reliably.

What practices do you think are more important?

For developers, you need to start with continuous integration. That doesn't mean installing a CI server and pointing it at your feature branches - it means making sure everyone merges regularly into mainline (and yes, that applies to Git too). In order for CI to be useful, you need automated tests, in particular at the unit and acceptance level. Having a comprehensive, maintainable set of unit tests is almost impossible without doing TDD. Creating maintainable acceptance tests requires close collaboration between developers and testers. Finally, you need to validate every build to ensure it's production ready, which means having the ability to spin up production-like testing environments on demand and run realistic loads against your system. This requires automated provisioning of environments and infrastructure, and automated deployment of your system, including any database changes. All of this needs to be implemented within the context of the deployment pipeline.

These kinds of changes need to be made incrementally, by finding out where the constraints are in your delivery process and removing them one by one. That in turn requires close collaboration between developers, testers and the operations department. More on that later.

We have seen, that some people make some confusion about the term Continuous Delivery, can you explain to us, what's the difference between Continuous Delivery and Continuous Deployment?

Continuous delivery means you can release on demand. I should be able to release the latest good build at the press of a button without having to worry that it's going to break. But when you release is a business decision. Continuous deployment means you actually go ahead and release every good build. Obviously that only really applies in the context of websites or software-as-a-service. But if you can't actually do continuous deployment and release every good build for some reason - say you're working on a user-installed product - you should at the very least be putting every good build into a production-like environment and running realistic acceptance and performance tests against it so that there are no surprises when you come to release it. You can do that on embedded systems, products, pretty much anything that involves software.

Organizations that could in principle do continuous deployment really should aim to. One of the key benefits is organizational. Continuous deployment makes developers care much more about the quality and reliability of what they're doing because if they can push a button to make their changes go live, it connects them with what's going on in production. And it makes the business focus much less on stuffing features into a release when they know they can create some small feature, have it in production in a couple of days' time, and get real feedback on whether it's valuable and whether more effort should be put into it. It is a complete paradigm shift in the way organizations work and they become much more responsive to their customers. Eric Ries writes more about this in his forthcoming book, The Lean Startup

Can you explain to us, the term DevOps, and what that means?

DevOps is kind of an anti-movement, by which I mean it has resisted attempts to pin it down. But fundamentally it's about putting a strong focus on collaboration between everybody involved in software delivery - in particular, developers, testers and operations - and sharing knowledge and techniques between them. Infrastructure-as-code is one example of knowledge sharing - the application of agile techniques such as refactoring and test-driven development to evolving your infrastructure. DevOps is essential to achieve continuous delivery.

Part of the reason people in the movement have resisted (for example) creating a manifesto is to prevent vendors (in particular tool vendors) from appropriating it and trying to own it. Often people are guilty of reaching for tools (even within the movement - myself included) when actually it's the attitude and mindset that makes you successful. That's not to say the tools aren't important - they are. Tools that can't be managed in an automated fashion through an API are especially unpopular within the community.

How do you implement DevOps?

One really good way to start is to get representatives from every part of the organization involved in delivery - development, testing, infrastructure, operations, product management - to get together regularly and have retrospectives to reflect on how to incrementally improve things. In many organizations, you never see people from every department in a meeting together. It just doesn't happen.

Another way to get going is for everyone involved in delivering software celebrate successful releases together. Really implementing DevOps is about change that works up from the people on the ground - it's hard to mandate it. That's one of the reasons senior management has a hard time with it. But it's also the secret sauce - incremental, bottom-up change is usually the most effective and long-lasting.

What skills related to Infrastructure a modern developer should have? And why it is important? Does it make sense, for companies that are not in the cloud?

I think the key element is that infrastructure provisioning and management has to be automated. It should be possible to plug a new server (or workstation) in - power and network - and bring it into the correct state, configure it, and deploy to it in a fully automated fashion. You can do that whether or not you're in the cloud. In fact ThoughtWorks recently did some consulting to automate hardware provisioning and management for one of the cloud vendors. Under the hood, "the cloud" of course runs on real hardware and the same principles apply.


For great companies, that has already an Operation Department, what a developer can do to decrease this gap between devs and ops?

First of all, get to know your operations department. Make friends with them. Invite them along to your retrospectives and showcases. Learn the tools they use. Help them build new ones. Read books like Release It! that talk about how to create production-ready software. Check out the screens they have up that show off production metrics. Get the same screens put up in development rooms (LCD panels are cheap these days). Ask to help out when releases happen. Get involved.


Can you talk about your job at ThoughtWorks?

I'm working on a number of things. On the one hand I am doing a lot of travelling at the moment, going to conferences and talking to our customers. I'm also doing some research and writing, including working on a series of interviews to create some videos about continuous delivery. Finally I'm doing some consulting work to make sure I keep my feet on the ground and stay in touch with the latest developments in the space, and of course to pay my way.

------------------------------------------------

Jez Humble is a Principal at ThoughtWorks Studios, and author of Continuous Delivery, published in Martin Fowler’s Signature Series (Addison Wesley, 2010). He has worked with a variety of platforms and technologies, consulting for non-profits, telecoms, financial services, and online retail companies. His focus is on helping organisations deliver valuable, high-quality software frequently and reliably through implementing effective engineering practices.


[Painel TDC2011] O que vem depois do Agile?

segunda-feira, 9 de janeiro de 2012

No ano passado, tive o privilégio de participar do TDC 2011, um evento super massa concebido pela Globalcode,  que contou com o o apoio de grandes nomese empresas da Indústria de Software.
Participei de um painel bem bacana, mediado pelos meus amigos Felipe Rodrigues da Crafters, e Victor Hugo Germano.
O tema da discussão foi O que vem depois do Agile?
Segue a descrição oficial.

A adoção da agilidade tem crescido muito no mercado brasileiro e cada vez mais grandes empresas tem aderido ao seu uso. Isso aumenta sua visibilidade, mas também vai exigindo adaptações nem sempre fáceis ou bem recebidas pela comunidade.
A grande pergunta que surge é: Qual é o próximo passo? O que vem depois do Agile?
Abaixo segue o vídeo do painel





TDC2011 SP - Painel (O que vem depois do Agile) - Domingo, 10 de Julho from Globalcode on Vimeo.

Distribuição de Dados com Infinispan na Java Magazine 95

quinta-feira, 13 de outubro de 2011

Este mês, foi publicado na revista Java Magazine 95, um artigo meu sobre JBoss Infinispan.
Uma das maneiras mais fáceis de melhorar a performance de uma aplicação é trazer os dados para mais perto dela e manter um formato que seja simples para ela consumir.


A maioria das aplicações escritas em Java, consomem dados que geralmente são armazenados em bancos de dados relacionais, como Oracle, MySQL, entre outros. Isto significa que para a aplicação consumir estes dados, precisa converter as informações que estão armazenadas em tabelas em objetos.
Por conta da natureza tabular destes dados, o processo de conversão de dados para objeto em memória pode ser muito custoso, e nem sempre é fácil. Para remediar estes problemas, ferramentas ORM como Hibernate e EclipseLink utilizam mecanismos de cache para armazenar os objetos internamente. Entretanto, quando a aplicação cresce e é necessário escalá-la para múltiplos servidores, e neste momento, começam a surgir vários problemas de sincronização de dados.
Para ajudar a resolver este problema, podemos utilizar uma plataforma de Data Grid. Dentro desta categoria, existem diversos frameworks e soluções, entre eles: Hazelcast, GigaSpaces, Oracle Coherence, Joafip, GridGain, ExtremeScale e JBoss Infinispan. .
Utilizei o JBoss Infinispan recentemente, em um projeto de grande porte, de uma nova URA inteligente, para uma grande empresa de Telecom da Itália. O sistema, foi distribuído em dois sites diferentes, com clusters com diversas máquinas.
A partir daí, surgiu a idéia de fazer este artigo. Neste artigo abordo além da computação em grid com ênfase na plataforma de datagrid Infinispan, abordo e a importância de seu uso em um ambiente corporativo, que tem necessidades mais específicas do que simplesmente criar um cache de dados.
Apresento os diferentes modos para criar um cache e seus conceitos, como Replicação, Invalidação, Distribuição, L1 Caching e Cache Local, assim como os benefícios de cada uma destas abordagens. E ao final, como transformar o Infinispan em uma solução NoSQL, utilizando Cache Stores com o Módulo REST.
Para concluir, apresento os módulos disponíveis para o desenvolvedor tirar ainda mais proveito desta poderosa plataforma, onde exploro como configurar um Módulo REST para acesso aos objetos no Grid via protocolo HTTP.

Sobre o Infinispan

Infinispan é uma plataforma para grid de dados open source distribuída pela JBoss. Geralmente, data grids são utilizados para reduzir a latência do banco de dados, prover alta disponibilidade e storage elástico dos dados, como soluções NoSQL. Data Grids podem ser utilizados em conjunto com bancos de dados tradicionais ou como cache distribuído, para acesso rápido aos dados.
Ao escolher o Infinispan no lugar de um simples cache, temos as seguintes vantagens:

  • Cluster: Podemos distribuir nosso cache em cluster com apenas algumas configurações;
  • Eviction: Mecanismo automático de eviction para evitar erros de out-of-memory e controle do melhor uso da memória;
  • Cache Loader: É possível configurar cache loaders (ver tópico “Cache Loader”) para persistir o estado dos objetos em um banco de dados ou em um arquivo no disco;
  • Suporte a JTA e compatibilidade com XA: Gerenciamento de transação com qualquer aplicação compatível com JTA;
  • Gerenciamento: É possível gerenciar e monitorar os objetos de uma instância do grid de dados através de componentes JMX ou utilizar um console gráfico com RHQ.

Caso se interesse por soluções desta natureza, entre em contato conosco!

Desenvolvimento Portlets: JSRs 168 e 286

quarta-feira, 12 de outubro de 2011

Duas JSRs, 168 e 286, atendem à criação de portlets. Em outubro de 2003 o JCP lançou a JSR-168, a primeira especificação que padroniza como os componentes devem ser desenvolvidos para os servidores de portal. Como as outras grandes JSRs, a JSR-168 possui o aval dos maiores fornecedores de portais. Esta especificação atende aos seguintes quesitos:

  • O contrato de contêiner de portlet e o gerenciamento do ciclo de vida do portlet; 
  • A definição dos estados das janelas e os modos do portlet; 
  • Gerenciamento das preferências do Portlet; 
  • Informações do Usuário como nome, endereço, e-mail, que podem ser informadas no arquivo de deployment descriptor e que podem ser recuperadas por um objeto Map através da constante USER_INFO definida na interface PortletRequest
  • Empacotamento e Deployment; 
  • Segurança; 
  • Tags para JSF. 
Mas, quando grandes fornecedores como a Apache, BEA, Borland, Oracle, IBM, SAP entre outros que fazem parte do expert group da JSR-168 começaram a criar as suas soluções de Portal, começaram a surgir também alguns problemas relacionados à limitação da especificação que antes não haviam sido detectados.
Conforme a adoção por soluções de portal baseadas na JSR 168 começou a aumentar, naturalmente o público consumidor destas soluções e o próprio negócio passou a demandar cada vez mais funcionalidades, que não haviam sido contempladas, fazendo com que soluções proprietárias fossem criadas pelos fornecedores. Entre as limitações da primeira versão da especificação de Portlets (JSR-168), podemos citar:
  • Falta de filtros para portlets (similar aos Filtros nos Servlets); 
  • Ausência de funcionalidades para a intercomunicação entre os portlets; 
  • Limitação do Escopo de Sessão do Portlet, onde a sessão do Portlet na JSR 168 se restringe apenas ao ID individual da aplicação e não da sessão do usuário do Portal. 
Essas limitações culminaram no lançamento da JSR 286, que define a segunda versão da API de Portlets. A JSR 286 incluiu novas funcionalidades como tratamento de eventos, envio e recebimento de parâmetros (permitindo a passagem de parâmetros entre os portlets), inclusão de filtros, suporte a Ajax e a disponibilidade de recursos do servidor, com o uso da interface ResourceServingPortlet.

Contrato do Contêiner e Gerenciamento do ciclo de vida do Portlet

A especificação da JSR-286 define um contrato para o contêiner de portlets. O contrato define quais métodos o contêiner deve chamar durante o ciclo de vida do portlet mediante o uso da interface javax.portlet.Portlet. O desenvolvedor pode implementar estes métodos para fornecer a funcionalidade desejada. Dessa forma, todo portlet tem que implementar esta interface, seja implementando-o diretamente ou estendendo uma classe existente que a implemente.
Os métodos do ciclo de vida executados pelo contêiner definidos pela interface javax.portlet.Portlet são apresentados na Tabela 1.

Método
Descrição
init()
Método executado quando o portlet for instanciado no contêiner.
processAction()
Chamado após o usuário submeter requisições ao portlet. É onde processamos os inputs disparados por uma ação do usuário do portlet.
render()
Chamado sempre que o portlet é reconstruído na tela.
destroy()
Executado no momento em que o contêiner destrói o portlet. Útil para liberarmos recursos que não estejam sendo utilizados, por exemplo, conexões com banco de dados.
Tabela 1. Métodos do ciclo de vida de um portlet

A especificação da JSR-286 ainda fornece interfaces opcionais para controle do ciclo de vida que o Portlet pode implementar como EventPortlet, que permite ao Portlet reagir às ações ou mudanças de estado oriundas da interação do usuário com o portlet ou ações originadas por outros portlets e a interface ResourceServingPortlet, utilizada para disponibilizar recursos do servidor no Portlet.

Portlet Modes e Window States

Para cada portlet existem dois itens de estado gerenciado, que são o modo do portlet (portlet mode) e o estado da janela (window state). Cada portlet possui um “portlet mode” corrente que indica a função que o portlet está realizando.
Os modes (ou modos) definidos na especificação são VIEW, EDIT e HELP. Estes modos são utilizados pelo método de renderização render(), conforme vimos na Tabela 1, para decidir qual método de visualização deve ser chamado. Os métodos de renderização chamados são apresentados na Tabela 2.

Método
Descrição
doView()
Método chamado por render() quando o portlet está em modo de visualização (VIEW). Deve conter a lógica que apresenta a página de Visualização para o portlet.
doEdit()
Chamado por render() quando o portlet está em modo de edição (EDIT).
doHelp()
Chamado por render() quando o portlet está em modo de ajuda (HELP) .
Tabela 2. Métodos de renderização do Portlet Mode

A classe PortletMode define constantes para estes portlet modes. A disponibilidade dos modos para o portlet pode ser restrito a roles (papéis) específicos de usuários do portal. Por exemplo, um usuário anônimo pode acessar o portlet apenas nos modos VIEW e HELP, enquanto que a role EDIT pode ser utilizada somente por usuários autenticados.
Outro tipo de estado gerenciado, o estado da janela (window state), apresenta a quantidade de informações que será disponibilizada para o portlet. A especificação define três tipos de estados para cada portlet, que são: normal, maximizado e minimizado. A classe WindowState possui constantes para estes estados da janela.
Para um maior entendimento, a Figura 1 apresenta estes conceitos de portlet mode e window state aplicados a um portlet.
Figura 1. Anatomia de um portlet
Opcionalmente o desenvolvedor pode especificar tipos customizados de modo e estado de janela, alterando o arquivo portlet.xml com uso da tag custom-window-state para estados de janela e custom-portlet-mode para modos.

JSF/Portlet Bridge

Como parte do projeto OpenPortal da Sun, foi criado o projeto JSF/Portlet Bridge, que tem como objetivo fornecer uma biblioteca de integração que permita que aplicações desenvolvidas com JSF possam ser executadas em um ambiente de Portlet.
Para atender à especificação de portlets, o JCP disponibilizou a JSR 301 para definir como um portlet 286 interage com os artefatos do JSF. A especificação foi para votação em Julho de 2006, mas somente em Janeiro de 2009 o draft da proposta final foi disponibilizada para o público.
Portlet Bridge é uma tecnologia utilizada por um portlet para fazer uma ponte (por isso o nome bridge) para um ambiente de execução, onde diferentes abstrações são utilizadas para processar as interações com o usuário ou para renderizar a interface gráfica.
O Portlet Bridge age como um engine tradutor entre o ambiente de portal e o sistema destino, neste caso, uma aplicação desenvolvida com o framework JSF. Ele ainda fornece uma abstração do ambiente de portal para o ambiente do bridge, deixando os desenvolvedores livres para executar aplicações Faces como portlets, sem a necessidade de conhecerem os detalhes das APIs de portlet e seu modelo de desenvolvimento.
A Figura 2 ilustra uma aplicação portlet utilizando o JSF/Portlet Bridge para executar páginas Faces como se fossem fragmentos de um portlet
Figura 2. JSF/Portlet Bridge entre uma aplicação Portlet e uma aplicação JSF.

Transformando sua aplicação JSF em um portlet

Para tornar uma aplicação JSF compatível com a JSR 168/286 é preciso fazer algumas alterações na aplicação antes de executá-la como um portlet.
Primeiro, para utilizar o JSF Portlet/Bridge é preciso efetuar o download da biblioteca jsf-portlet.jar no site java.net (ver ao final, em Referências) e copiá-la para o diretório WEB-INF/lib da aplicação JSF que você deseja executar como portlet.
Uma vez adicionado o arquivo .jar ao classpath da aplicação, é preciso adicionar o arquivo deployment descriptor portlet.xml para o portlet. Neste arquivo vamos informar a classe com.sun.faces.portlet.FacesPortlet para a tag portlet-class. Esta classe é a implementação da interface javax.portlet.Portlet fornecida pela biblioteca do JSF/Portlet Bridge, e é ela que fará o trabalho de converter as páginas JSF para páginas de visualização no Portlet.
É preciso também informar qual página queremos utilizar como página inicial do portlet, informando o parâmetro de portlet com.sun.faces.portlet.INIT_VIEW para a página desejada, conforme mostra a Listagem 1 entre as linhas 08 e 15.


    
        Portlet JSF
        Teste
        Portlet JSF/Portlet Bridge
        
        com.sun.faces.portlet.FacesPortlet
        
        
            Página inicial do Portlet 
            com.sun.faces.portlet.INIT_VIEW
            /index.jsp
        
        
            text/html
            VIEW
            EDIT
            HELP
        
        
            Portlet JSF
            JSF
        
    

Listagem 1. Portlet.xml de uma aplicação JSF
Para incluir a página de edição do portlet, o procedimento é similar. Nos parâmetros iniciais do arquivo portlet.xml, devemos incluir o parâmetro de portlet com.sun.faces.portlet.INIT_EDIT, conforme o trecho da Listagem 2. Essa ação fará com que o contêiner de portlets interprete a página JSF editar.jsp citada na listagem, como modo de visualização EDIT.


  Página de Edição do Portlet
  com.sun.faces.portlet.INIT_EDIT
  /editar.jsp

Listagem 2. Inclusão da página de edição JSF no portlet

O mesmo se aplica para a página HELP, com a inclusão do parâmetro com.sun.faces.portlet.INIT_HELP.
Além disso, se em nossa aplicação houver mais de uma página, podemos atribuir regras de navegação para cada uma destas páginas, e por ser uma aplicação JSF o modelo de navegação é o do próprio JavaServer Faces.

O modelo de navegação do JSF torna fácil o trabalho de definir a regra de navegação das páginas do projeto, com a utilização de apenas algumas linhas no arquivo faces-config.xml da aplicação JSF. Podemos indicar qualquer página do portlet como referência para navegação, conforme demonstra a Listagem 3.

Na Listagem 3, utilizamos o modelo de navegação declarativo do próprio JSF para definir a navegação de um portlet. Como não é o escopo deste artigo, não iremos explicar o funcionamento das regras de navegação do JavaServer Faces, mas apenas para ilustrar, nesta listagem definimos uma regra que ao ser disparada uma ação na página editar.jsp, a aplicação irá navegar desta página para a página index.jsp, se o resultado referenciado pelo componente que disparou a ação de navegação da página editar.jsp for success.

  /editar.jsp
  
    success
    /index.jsp
  

Listagem 3. Navegação entre páginas JSF em um portlet
Por fim, para executar a aplicação é preciso somente efetuar o deploy do arquivo WAR para o seu servidor de portal preferido.
WSRP
WSRP significa Web Services for Remote Portlets, ou web services para portlets remotos. WSRP é uma tecnologia definida pela OASIS, e propõe um padrão para web services visuais que podem ser plugados em ambientes de portal que estejam aderentes à especificação, ou seja, se em um web service padrão nós reutilizamos o serviço com WSRP, reutilizamos toda a interface gráfica.
OASIS: Consórcio global formado por grandes empresas de tecnologia da informação como IBM, SAP, AG, Sun Microsystems, que conduz o desenvolvimento, convergência e adoção de padrões para e-business e web services, produzindo diversas especificações e padrões relacionados a áreas como SOA, web services, processamento de XML, segurança da informação e supply chain. 
Atualmente a API WSRP está na versão 2.0 e possui um fluxo bem simples. O owner do portal ou da aplicação primeiro inclui em seu ambiente de portal um web service de terceiro (WSRP) dentro de um portlet. A partir deste momento, o portlet irá interagir com o conteúdo e com os serviços descritos no documento wsdl do WSRP, conforme veremos em detalhes mais adiante.

Um WSRP define:
  • Uma interface WSDL para invocação dos serviços WSRP; 
  • Como publicar, buscar, e efetuar bind dos serviços WSRP e metadados; 
  • Regras de fragmentação por marcação, para marcações emitidas pelos serviços WSRP. 
WSDL: Significa Web Service Definition Language, é uma linguagem baseada em XML utilizada para descrever web services. Além de descrever o serviço, um documento WSDL especifica os métodos e operações disponíveis e como acessá-los. 

WSRP é útil para o desenvolvimento web pois ele desacopla o deployment da entrega da aplicação, assim como fornece tanto os dados quanto a lógica de apresentação e requer pouca ou nenhuma programação para implementação do serviço. Além disso, WSRP fornece uma série de benefícios adicionais, como interoperabilidade e portabilidade. Normalmente um servidor de portal pode atuar como um produtor ou consumidor de WSRP.
Graças a essa interoperabilidade com o WSRP, podemos então rodar portlets Java remotos em uma ferramenta de portal que não seja em Java, como no Microsoft SharePoint.
Entre as desvantagens, estão a adoção ainda baixa por parte dos fornecedores, e a performance, que tende a ser baixa em grandes aplicações.

Como funciona?

Basicamente, um WSRP envolve dois componentes, além do portlet em si, conforme demonstra a Figura 3. A aplicação remota, conhecida como WSRP Producer, implementa os padrões de web services utilizando a especificação SOAP (Simple Object Access Protocol) sobre HTTP.
O WSRP Producer fornece um conjunto de operações para os consumidores do serviço, onde dependendo da implementação, o Producer pode tanto oferecer apenas um portlet quanto pode fornecer um ambiente para gerenciamento de diversos portlets. Resumindo, o WSRP Producer é um web service verdadeiro, com um WSDL e um conjunto de endpoints. Cada WSRP Producer é descrito utilizando um documento WSDL padrão.
O segundo componente é o WSRP Consumer, que é o cliente do serviço e que age como uma aplicação de portal para consumir o serviço baseado no arquivo WSDL do Producer.
Figura 3. Consumo de um WSRP

Interfaces do WSRP
Conforme explicado, WSRP define um conjunto de interfaces que todo WSRP Producer deve implementar e que todo WSRP Consumer utiliza para interagir com os portlets remotos. O grande benefício de se padronizar estas interfaces é a possibilidade de criar portlets genéricos. Isto garante que todo fornecedor de portal que queira suportar WSRP deve seguir a especificação.
A especificação WSRP propõe as interfaces definidas na Tabela 3.

Interface
Descrição
Obrigatório?
Service Description Interface (Interface de Descrição de Serviço)
Essa interface fornece uma descrição dos serviços fornecidos pelo Producer. Baseado nestas informações, o Consumer é capaz de determinar o que é preciso para executar o portlet, como por exemplo, inicializar um cookie antes que o Consumer interaja com qualquer um dos portlets.
Sim
Mark-up Interface (Interface de Marcação)
A Interface de Marcação permite que o Consumer interaja com o portlet remoto. Por exemplo, o Consumer poderia utilizar esta interface para realizar interações quando um usuário final submete um formulário a partir de uma página de portal. Além disso, o portal pode precisar obter a última marcação baseada no estado atual do portlet (por exemplo, quando um usuário atualiza o navegador ou inicia uma interação com outro portlet na mesma página).
Sim
Registration Interface (Interface de Registro)
Esta Interface permite que o Producer obrigue que os Consumers façam um registro antes de interagir com o serviço através do uso das interfaces de Service Description e Mark-up.
Não
Portlet Management Interface (Interface de Gerenciamento do Portlet)
Esta interface fornece acesso ao ciclo de vida do portlet remoto. Um Consumer poderia customizar o comportamento do portlet ou até mesmo efetuar uma chamada ao método destroy() mediante o uso desta interface.
Não
Tabela 3. Interfaces definidas na especificação WSRP

No mais é isso, 
Diversão Garantida!!!