NetFeijão Brazil

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

2012-02-01T13:58:00.000-02:00

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

2012-01-19T10:25:00.002-02:00

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

2012-01-16T11:16:00.002-02:00

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

2012-01-13T17:41:00.002-02:00

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?

2012-01-09T16:14:00.000-02:00

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

2011-10-13T00:45:00.000-03:00

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

2011-10-12T19:16:00.004-03:00

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.


version="1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd
http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd">
    
        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!!!

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

2011-10-12T17:51:00.001-03:00

Em Janeiro, saiu a terceira e última parte do meu artigo Princípios, Padrões e Práticas para um Design Ágil na revista Java Magazine edição 86.
Na primeira e segunda parte desta série de artigos, publicados nas Edições 80 e 81, abordamos sobre fundamentos de arquitetura de software, padrões de projetos em uma arquitetura distribuída, analisamos como identificar sintomas de um software mal planejado, e como refatorar a sua aplicação para utilizar boas práticas de desenvolvimento OO.

Na última parte desta série, vamos analisar a fundo como funciona um Projeto XP, passando por todas as suas fases, e veremos também como adotar as práticas de engenharia da Extreme Programming para construir um software aplicando as melhores práticas de desenvolvimento OO

utilizando TDD e testes de aceitação.

Abordaremos os valores destas metodologias através do Manifesto Ágil, apresentando de maneira

clara como estes valores estão presentes na Extreme Programming. Analisaremos também, como a Arquitetura do Software é tratada em um projeto ágil e como algumas práticas do XP auxiliam na criação e evolução da Arquitetura.

Por fim, é apresentado um estudo de caso onde implementaremos uma funcionalidade em um sistema fictício, mostrando desde a escrita da estória pelo cliente até sua implementação utilizando testes de aceite com o framework FitNesse e TDD.

Yahoo OpenHack 2010 - YQL Console for Netbeans

2011-10-11T18:25:00.000-03:00

Depois de muito tempo sem blogar, resolvi atualizar um pouco as coisas aqui.
O ano passado, teve o Yahoo Open Hack, onde mais uma vez, tive a oportunidade de participar. Para o evento, meu hack foi o YQL! Console for NetBeans and Meme Robot.
Apesar de não ter levado o prêmio, gostei muito do trabalho realizado, pois foi um verdadeiro hack, pois todas queries executadas pelo YQL Console no Netbeans, foram utilizando uma página do Yahoo, que descobri utilizando Wireshark.
O plugin chamou a atenção de Geertjan wielenga, que me convidou a escrever um artigo para a DZone.

Segue abaixo o texto, para acessar o artigo original, clique aqui, que foi copiado do DZONE,

Recently, Yahoo provided a nice API called YQL, which stands for "Yahoo! Query Language". It's an API that exposes an SQL-like syntax (from SHOW and DESC to INSERT and DELETE commands) that is very familiar to developers. It lets you make great things: with this language, developers can use a single language to query, filter, and join data across web services. You can even create your own open data table (see http://datatables.org) that can make your data YQL-accessible.

To test your queries and data tables, Yahoo created the YQL Console to help developers test their own queries and funcionalities, it's quite useful for YQL Developers.

This year (in March), Yahoo sponsored a contest called 'Yahoo Hack Day', an open contest for developers to create hacks using these Yahoo APIs. My contribution to this contest was the plugin "YQL Console for NetBeans", which is the YQL Console embedded into NetBeans IDE:

To make it work, I used wireshark to sniff the network to see what was happening. In that way, I was able to hack some Yahoo PHP pages that let me "clone" the console inside NetBeans IDE. I'm using some APIs like Bean Bindings and Swing Application Framework for the UI, Jakarta Commons HttpClient for accessing resources via HTTP, as well as RESTClient to format XML and JSon code, and a couple of NetBeans APIs, such as the Window System, Utilities, UI Utilities and Settings.

Bem, e isso ai, para download do plugin, conforme citado acima, acesse o link

http://plugins.netbeans.org/plugin/27552/yql-console-for-netbeans

Diversão Garantida!!!

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

2010-10-16T13:29:00.007-03:00

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

Trabalhando com os recursos

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

@Path("/repositorio/{id}")
public class Repositorio { ... }

Listagem 01 - Mapeando uma URI para uma classe com @Path.

A especificação define que no ciclo de vida de um recurso, por padrão, sempre que for feito uma requisição a um recurso, será criada uma nova instância de uma classe REST. Primeiro o construtor é chamado pelo contêiner, por conta disto, o construtor da classe deve ser público. Após este primeiro passo, o contêiner efetua as injeções de dependência nos devidos métodos e o método designado para aquele recurso é invocado. E finalmente após a chamada ao método o objeto fica disponível para o garbage collector.
Geralmente a anotação @Path é incluída na declaração de um método quando queremos atribuir um caminho mais específico para um recurso, de forma a especializar nosso método, como na Listagem 02. Note no exemplo como a URI é mapeada com a classe e o método.

@Path("/vendas/")
public class Repositorio {
  @GET
  @Produces("application/xml")
  @Path("/pedidos/{numPedido}/")
  public PedidoAsXML getPedido(@PathParam("numPedido") Integer id){
    // retorna Pedido em formato XML.
  }
}

Listagem 02 - Mapeando uma URI para uma classe com @Path.

Acessando os Recursos

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

@HttpMethod("PUT").

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@HttpMethod("MKCOL")
public @interface MKCOL {
}

Listagem 03: Utilizando a anotação HttpMethod para criar uma anotação customizada.

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

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

@GET
@Produces({"application/xml", "application/json"})
public PessoaConverter getPessoa(@QueryParam("CPF") String numCPF) {
  // Retorna representação em XML ou JSON
}

Listagem 04 - Declarando o tipo de retorno com a anotação @Produces.

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

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

Com a anotação @Consumes por outro lado, podemos definir os tipos de mídia que um recurso em particular consome. Como o exemplo da Listagem 05, onde estamos declarando que o método consome apenas formatos do tipo XML e JSON:

@PUT
@Consumes("application/xml","application/json")
@Path("/autores/")
public Response putPessoa(PessoaBinding pessoa) {}

Listagem 05: Uso da anotação @Consumes.

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

JAX-RS fornece algumas anotações para extrair informações de uma requisição. Existem seis tipos de parâmetros (ver Tabela 01) que podemos extrair para utilizar em nossa classe recurso. Para os parâmetros de query utilizamos a anotação @QueryParam. Para os parâmetros de URI(path) existe a anotação @PathParam.
Para os parâmetros de formulário existe @FormParam. Já para parâmetros de cookie existe @CookieParam.
Para os parâmetros de header existe @HeaderParam e, finalmente, para os parâmetros de matriz existe a anotação @MatrixParam.
Estas anotações podem ser aplicadas diretamente a parâmetros de um método. Desta forma vinculamos o valor do parâmetro de uma URI a algum parâmetro de entrada de um método. Para contextualizar, veja um exemplo na Listagem 06:

@Path("/editora/")
public class EditoraResource {
  @GET
  @Produces("application/xml")
  @Path("/autores/{nomeAutor}/")
  public PessoaBinding getPessoa(@PathParam("nomeAutor") String name,
                       @QueryParam("idade") int idade,
                       @HeaderParam("CPF") String numCPF,
                       @MatrixParam("statusCivil") String statusCivil) {
     return new PessoaBinding(name, idade, numCPF, statusCivil);
  }
}

Listagem 06 – Mapeando os parâmetros de uma URI para os parâmetros de um método.

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

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

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

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

Nome: 
  Idade:

@Path("/editora/")
public class EditoraResource {
  @GET
  @Path("/autores/")
  public PessoaBinding getPessoa(@FormParam("nomeAutor") String name,
                       @FormParam("idade") int idade) {
    return new PessoaBinding(name, idade);
  }
}

Listagem 07 - Uso da anotação FormParam.

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

Dados de Contexto

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

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

Tratando o retorno dos métodos ao Cliente.

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

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

Listagem 08 – Tratando a Response do cliente.

Entity Providers

Entity providers fornecem serviços de mapeamento entre representações e seus tipos associados Java. Existem dois tipos de entity providers, MessageBodyReader e MessageBodyWriter.

A especificação JAX-RS define que para alguns tipos, o contêiner pode automaticamente serializar (marshal) e deserealizar (unmarshal) o corpo de diferentes tipos de mensagens, listados na tabela 03.

Tabela 03: Tipos de Mídia e seus tipos Java correspondentes.

Para requisições HTTP, podemos mapear o corpo da entidade para um parâmetro de método com uso da interface MessageBodyReader, para o tratamento das responses, o valor de retorno é mapeado para o corpo da entidade de um método HTTP com uso da interface MessageBodyWriter.

Pode ser que no desenvolvimento de nossas aplicações, estes tipos padrões não atendam a necessidade de negócio e tenhamos que lidar com tipos que não sejam suportados pelos tipos default, para contornar esta limitação, a API JAX-RS permite que a criação de Providers para Message Body customizáveis, com métodos para conversão de InputStream/OutputStream para objetos Java do tipo T.

Para criar nosso próprio provider customizado, a especificação disponibiliza a anotação @Provider, que ao ser aplicado sobre uma classe, estamos automaticamente registrando este classe junto ao contêiner.

Porém, é importante ressaltar, que esta funcionalidade apesar de muito útil, pode ser tornar um problema em grandes projetos, que podem utilizar providers com o mesmo nome em diferentes bibliotecas, podendo ocasionar conflitos.

Caso a aplicação necessite de informações adicionais, como HTTP Headers ou um código de status diferente, o método pode retornar o objeto Response que encapsule a entidade.

Veja um exemplo extraído de um sample da implementação de referência da Sun, o Jersey, na listagem 09, esta classe implementa um MessageBodyWriter para uma classe Properties.

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

Listagem 09: Uso da tag @Provider.

Tratando Exceções

Para tratamento de exceções, a especificação JAX-RS define a exceção WebApplicationException que estende RuntimeExcetion, que pode ser lançada por um método de recurso, por um provider ou por uma implementação de StreamingOutput. Esta exceção permite que abortemos a execução de um serviço JAX-RS.

Como parâmetro de construtor, podemos utilizar um código de status HTTP ou até um objeto Response. Veja um exemplo na listagem 10:

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

Listagem 10: Uso de exceção com WebApplicationException.

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

@Provider
public class IdadeInvalidaExceptionMapper implements ExceptionMapper{
  public Response toResponse(IdadeInvalidaException ex) {
    return Response.status(412).entity(ex.getMessage()).build();
  }
}

Listagem 11: Mapeando uma exceção Java para uma Response.

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

@GET
@Produces("application/xml")
@Path("/autores/{personName}/{idade: [0-9]+}/")
public PessoaBinding getPessoa(@PathParam("personName") String name, @PathParam("idade")
int idade, @HeaderParam("CPF") String numCPF) throws IdadeInvalidaException {
    if (idade <= 0 || idade > 120)
       throw new IdadeInvalidaException("Idade Inválida!");
    return new PessoaBinding(name, idade, numCPF);
}

Listagem 12: Uso de exceção de negócio, que é mapeada para Response.

Assim como toda nova tecnologia, JAX-RS não é uma bala de prata, mas sabendo o momento de usá-la se torna uma ferramenta poderosa de integração, em termos de facilidade no desenvolvimento e requerer uma

infraestrutura mais leve, dispensando o uso de um middleware WS-*.

Use e abuse! Diversão garantida!

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

2010-08-19T12:53:00.000-03:00

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

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

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

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

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

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

Diversão Garantida!

Introdução a Portais Corporativos

2010-08-13T22:31:00.000-03:00

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

Figura 1. Arquitetura de um portal

Durante muito tempo as ferramentas de portal foram ignoradas e até mesmo discriminadas por muitos programadores que achavam que elas eram de uso exclusivo para web designers. Mas com o surgimento da arquitetura orientada a serviços e a busca frenética das empresas em disponibilizar soluções mais baratas e produtivas, com o intuito de reduzir o Time-to-Marketing, esse tipo de ferramenta voltou com toda a força para fazer o que sempre fez: facilitar a vida de todos. A partir desta análise, mostraremos nesse artigo as vantagens do uso de uma ferramenta de portal, e qual o papel do programador neste contexto.

Segurança

A etapa mais cansativa e torturante para um desenvolvedor é ter que gastar seu tempo desenvolvendo módulos de segurança de uma aplicação, sendo que esses módulos geralmente são constituídos por telas de autenticação, tratamentos de usuários e grupos de usuário, utilização de repositórios LDAP, e em algumas vezes a integração com um autenticador para desfrutar do tão desejável Single Sign On .

Além de ter todas essas características, muitas vezes é necessário desenvolver soluções “self-service”, para que o administrador do ambiente de Portal tenha autonomia para gerenciar o repositório de usuários e dar permissões de uso para as funcionalidades da ferramenta.

Praticamente todas as soluções de portal possuem todo esse mecanismo pronto, possibilitando ao programador se dedicar somente no desenvolvimento das aplicações de automatização do negócio.

Conteúdo

No desenvolvimento completo de uma solução como uma “Intranet”, é comum ver que todo o tempo de desenvolvimento é gasto na criação de aplicações para gerenciamento de conteúdo, como funcionalidades de notícias, biblioteca de documentos, áreas institucionais e qualquer outra seção que necessita de um gerenciamento de informações por parte do usuário do sistema. Em um projeto deste tipo, também é comum que todas essas funcionalidades passem por uma governança editorial, e que inevitavelmente necessitem de um mecanismo de workflow. Essas são funcionalidades típicas nas ferramentas de portal, o que fez com que todos achassem que esse tipo de ferramenta só proporcionava esse benefício.

Há empresas que buscam outras soluções que vão além de um simples gerenciamento de conteúdo, indicando que elas devem ser mais robustas e possuir módulos de digitalização, transformação e busca de conteúdo. Esses sistemas, chamados ECM (Enterprise Content Management), muitas vezes dependem de uma ferramenta de portal para disponibilizar o conteúdo trabalhado. Este é só um exemplo de ferramenta que necessita de um portal como camada de visão. E a forma com a qual esse e outros tipos de ferramentas mostram suas funcionalidades é através dos chamados portlets.

Portlet

A internet fornece um conjunto de informações quase que ilimitado para diversos tipos de dispositivos. Com o advento da web foi criado um universo de padrões e protocolos de comunicação, recursos, e uma linguagem de marcação utilizada para apresentação (HTML). Mas a web e seus protocolos foram projetados para atender ao conceito de uma página como um pedaço estático único de informação, apresentado em um navegador, como uma entidade completa e inalterável. Para visualizar outra página, o usuário tem que chamar outra página.

Até o momento, diversos esforços têm sido feitos para superar esta limitação com o uso extensivo de código, como JavaScript/Ajax, ou alguma solução DHTML para trazer ao usuário uma experiência similar e até mesmo superior ao uso de uma aplicação desktop.

Portlet é uma maneira de superar a natureza “tudo ou nada” de uma página HTML. Para defini-los podemos dizer que os portlets são o núcleo dos serviços de um portal, onde uma ferramenta de portal utiliza os portlets como uma interface de apresentação plugável, ou seja, aplicações que podem ser adicionadas em qualquer página em um ambiente de portal, com o objetivo de fornecer qualquer tipo de informação na camada de apresentação.

O conteúdo gerado por um portlet é chamado de fragmento, que na verdade é um pedaço de marcação (ex: HTML, XHTML, etc.) aderente a certas regras, de forma que possamos agregar pedaços de vários fragmentos para gerar um documento.

A página de um portal é composta por um ou mais portlets, que são normalmente agregados com o conteúdo de outros portlets para formar uma página. O ciclo de vida de um portlet é gerenciado pelo contêiner de portlet, conforme veremos logo a seguir. Na Figura 2 apresentamos uma página de exemplo do portal open source Liferay, com a disposição de vários portlets.

Figura 2. Exemplo de uma página de portal

Se olharmos atentamente o conteúdo do navegador na Figura 2, veremos que a página é formada por diferentes janelas. Temos uma janela para um dicionário, outra para um RSS, uma terceira para um calendário, e por último uma para o Google Maps. Cada uma destas janelas representa um portlet. Ao analisarmos o detalhe de cada janela, vamos perceber que cada uma delas contém uma barra de título e alguns botões, incluindo os botões de maximizar e minimizar.

Na verdade, estas janelas são aplicações diferentes, desenvolvidas independentemente uma das outras. O programador desenvolve o portlet como uma aplicação web e empacota em um arquivo .war, e o administrador do portal efetua o deploy deste arquivo .war no servidor de portal e adiciona o portlet recém instalado em uma ou mais páginas do portal.

Pelo fato de você poder colocar o portlet em qualquer página, faz com que você possa reutilizá-lo a todo o momento no portal, até mesmo em uma mesma página. No caso da Figura 3, apresentamos uma página com várias instâncias de um mesmo portlet (Locadora).

Figura 3. Várias instâncias do mesmo portlet em uma página

Repare nesta figura que temos um mesmo portlet na página, mas com instâncias diferentes. A ferramenta de portal tem a responsabilidade de garantir sessões independentes da aplicação, mesmo estando todos na mesma página.

Contêiner

Portlets são executados em um contêiner de portlets. O contêiner fornece aos portlets o ambiente necessário para sua execução e gerenciam o seu ciclo de vida.

O contêiner de portlets recebe as requisições oriundas do portal para executar ações nos portlets em seu ambiente. É importante entender que contêiner de portlets não é responsável por agregar o conteúdo produzido pelo portlet que ele está hospedando, quem faz esta agregação é o próprio portal.

Figura 4. Fluxo de criação de uma página de portal

A Figura 4 acima, apresenta como funciona a construção da página de um portal. Podemos notar que os portlets rodam dentro do contêiner, que recebe o conteúdo gerado pelos portlets. Na seqüência, vemos que o contêiner retorna o conteúdo do portlet para o portal. Por último, o servidor de portal cria a página com o conteúdo gerado pelos portlets e envia para o dispositivo cliente, onde é renderizada (por exemplo, um navegador).

Contêiners de Portlet e Contêiners de Servlets

Os portlets possuem várias similaridades com os servlets, como ambos serem componentes gerenciados por um contêiner especializado, ambos gerarem conteúdo dinâmico, por ambos interagirem com um cliente web através de request/response HTTP. Entretanto, os portlets não podem ser tratados como servlets por conta dos seguintes fatores:

Geram somente fragmentos de página no método de renderização, e não documentos completos;
Podem somente ser invocados através de URLs construídas através da API de portlet;
Clientes web interagem com os portlets através do sistema de portal;
Possuem modos pré-definidos de portlet e estados de janela que indicam a função que o portlet está executando;
Possuem um tratamento de requisição refinado para action, eventos, requisições de renderização e requisições a recursos;
Não possuem acesso a certas funcionalidades fornecidas pelos servlets, como a URL de requisição do cliente ao Portal, ou atribuir o encoding de caracteres para a resposta ao cliente.

Por conta destas diferenças, o JCP decidiu criar para portlets um novo tipo de componente. Porém, ao formular a especificação de Portlets, o JCP procurou sempre que possível, potencializar o uso das funcionalidades fornecidas pela especificação de Servlets. Isto inclui deployment, classloading, aplicações web, gerenciamento de sessão e request dispatching. Por isso, diversos conceitos e partes da API de Portlets foram modelados a partir da API de Servlet.

Os objetos criados em uma aplicação de portal, como portlets, servlets e JSPs são empacotados como uma aplicação web comum (.war), e irão compartilhar o mesmo classloader, contexto de aplicação e sessão no ambiente de execução.

No próximo artigo sobre o assunto, vou falar sobre as JSRs 168 / 286 sobre a criação de Portlets.

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

2010-08-13T21:36:00.004-03:00

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

Diversão Garantida!

Academia Agile - Do Coaching ao Kanban

2010-03-17T20:58:00.006-03:00

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

Código	Nome do curso	Carga Horária	Apostila Demo
AG1	Implantando e liderando equipes Ágeis	12 hs
AG2	Criação de produtos com Requisitos Ágeis	12 hs
AG3	Otimizando a Comunicação através de DDD	12 hs
AG4	Modelagem Ágil de Software	12 hs
AG5	Práticas Ágeis de Engenharia de Software com XP	24 hs
AG6	Gestão de projetos com Scrum	12 hs
AG7	Gestão de processos com Kanban e Lean	12 hs
AG8	Estratégia Ágil para Governança em TI	12 hs
	Resumo da carreira Academia do Agile	108 hs

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

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

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

AG1- Implantando e liderando equipes Ágeis

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

AG2 - Criação de produtos com Requisitos Ágeis

Definição de escopo

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

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

Introdução ao Domain Driven Design

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

AG4 - Modelagem Ágil de Software

Introdução à Modelagem de software

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

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

Introdução ao Extreme Programming

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

AG6 - Gestão de projetos com Scrum

Abordagens Ágeis

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

AG7 - Gestão de processos com Kanban e Lean

Cultura e Filosofia Lean

O que é Lean
Pensamento Enxuto
Impactos econômicos do pensamento enxuto
Tipos de cenários para o pensamento Lean
Perspectiva de Consumo
Geração de Valor
Eliminação das Perdas
Respeito e Desenvolvimento de Pessoas

Ferramentas Lean

Hansei e Kaizen para melhoria contínua
Poka-Yoke e Jidoka para ajudar a qualidade
Andon e Kanban como meio de comunicação

Gestão Lean

Planejamento e Gestão com pensamento A3
WIP (Work-In-Process)
Pull System
Visualizando o VSM - Value Stream Map
O que é Lead Time?
Identificando Restrições
Resolução de Problemas com The Five Whys
Aplicando o clico PDCA
Definindo demanda
Definindo tamanho
Definindo capacidade
Usando o sistema Kanban

Adoção

Aplicação em equipes de projetos
Aplicações de equipes de sustentação
Lean/Kanban com Scrum

AG8 - Estratégia Ágil para Governança em TI

Visão Geral do Ecossistema

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

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

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

Diversão Garantida!!!

Consumindo e Testando Clientes REST

2009-12-29T13:44:00.011-02:00

A especificação JAX-RS é uma ótima opção para criar web services REST e fornece meios de desenvolver componentes server-side, mas não descreve como os desenvolvedores devem desenvolver seus componentes client-side em Java, e essa já é uma das promessas para a próxima release do JAX-RS.

Pelo fato de nossos serviços RESTful serem URIs e a forma de acesso a estes serviços serem os próprios métodos HTTP, podemos trabalhar diretamente com requisições HTTP ou utilizar bibliotecas para facilitar este trabalho. Felizmente é relativamente fácil trabalhar diretamente com requests e responses HTTP, e as linguagens mais populares de programação possuem métodos/bibliotecas HTTP, como por exemplo, urllib2 e httplib em Python, libcurl em PHP, HTTPWebRequest em C#, open-uri em Ruby, e o pacote java.net.* e o projeto HttpClient da Apache para Java, entre outros. Mas para qualquer linguagem que seja feito a requisição ao serviço RESTful, temos que passar por alguns passos, conforme segue:

Montar os dados que irão trafegar pelo requisição HTTP, como a URI, HTTP header (se houver), e o método HTTP desejado.
Formatar estes dados como uma requisição HTTP, e enviá-lo para um servidor HTTP apropriado.
Efetuar o parsing dos dados retornados (XML, JSON, etc..) para as estruturas de dados que o seu programa precisa.

Para facilitar a pesquisa, montamos um pequeno guia, para os desenvolvedores e estudiosos que querem aprender um pouco mais sobre REST, onde iremos apresentar algumas bibliotecas para teste e consumo de serviços RESTful.

cURL

Se o intuito for apenas testar os serviços REST desenvolvidos e validar o retorno, o mais simples é utilizar ferramentas existentes na web como é o caso da biblioteca cURL, que é uma ferramenta de transferência de arquivos entre cliente-servidor desenvolvida em C, e suporta protocolos como HTTP, HTTPS, FTP, FTPS, etc.
A listagem 1 apresenta alguns exemplos de como fazer uma requisição GET e POST com uso da biblioteca cURL, como podemos ver, ela não possui uma interface gráfica, sendo uma ferramenta de linha de comando.
Fazendo uma requisição (GET), passando como parâmetro de headerv tipo de conteúdo json, (-H "Accept:application/json")

// Fazendo uma requisição POST, passando como query parameter name = JumboComLtda
$ curl -d name=JumboComLtda http://localhost:8080/Contatos/resources/customers/2/cliente/

// Excluindo um registro com DELETE, pelo parâmetro –X
$ curl -v –X DELETE http://localhost:8080/Contatos/resources/customers/99/

Registro excluído com sucesso !

Listagem 1: Uso da biblioteca cURL.

Referências:

cURL - Site Oficial http://curl.haxx.se/
Artigo Testing RESTful WebServices Made Easy (em inglês), publicado na revista Linux 4You em Maio de 2009.
RESTClient Cookbook, vários receitas e demonstrações de como extender o RESTClient.

RESTClient

RESTClient é uma aplicação Java própria para auxiliar nos testes de serviços RESTful, complementar a isto, ela pode ser utilizada para testar Web Services POX (Plain Old XML) sobre HTTP. Para utilizar, basta efetuar o download do arquivo jar (com dependências) da ultima versão, no momento que escrevo este artigo, a versão mais recente é a versão 2.3, e vem com duas opções.

RESTClient 2.3 GUI: restclient-ui-2.3-jar-with-dependencies.jar
RESTClient 2.3 Command-line: restclient-cli-2.3-jar-with-dependencies.jar

A versão GUI, é uma aplicação Swing com diversas opções, e bem conhecida de quem trabalha com o RESTClient desde suas primeiras versões, e a outra versão "cli" é para execução batch de arquivos .rcq. Para começar utilizar a versão em Swing, basta digitar o seguinte comando (A aplicação requer Java 6 para rodar):

$java -jar restclient-ui-2.3-jar-with-dependencies.jar

Após executar a aplicação, deverá ser apresentado a tela conforme ilustra a Figura 1.

Figura 01 - Interface Swing do RESTClient.

Pela aparência da interface gráfica, podemos deduzir facilmente o modo de utiliza-lá, basta digitar no campo URL o caminho desejado, selecionar algum método HTTP na aba Method, e executar a consulta clicando no botão [>>]. O resultado será apresentando no bloco HTTP Response.

Funcionalidades

Com RESTClient, podemos fazer qualquer tipo de requisição HTTP (GET, PUT, POST, DELETE, HEAD, OPTIONS, TRACE), ainda existe o suporte a SSL e a possibilidade de adicionar parâmetros de Header adicionais.
É possível salvar as requests, responses, e o Response Body (atráves do menu File > Save Request, ou Save Response, Save Response Body), o que é útil para testes de regressão, que podemos utiliza-los posteriormente na versão de linha de comando.
RESTClient ainda vem com o Conteiner Jetty embutido, que possui um Servlet que imprime os detalhes das requisições submetidas a ele. Para iniciar o servidor basta acessar o menu Tools > Opção Start Trace Server (subirá na porta 10101).

E por fim, uma das funcionalidades mais interessantes é o seu suporte integrado para testes, que podem inclusive ser escritos em Groovy, o suporte a testes é baseado no JUnit 3.x e os tests são atachados a cada requisição. Para iniciar os testes, na aba "Test Script", clique o no botão Insert Template, RESTClient irá criar o código para você, conforme mostra a Listagem 02:

// The test class name should end with `Test'--this is a convention:
public class TemplateClassTest 
    extends org.wiztools.restclient.RESTTestCase{

  // Test method names should start with `test':
  public void testStatus(){
    if(response.getStatusCode() != 200){
      fail("This will fail the test!");
    }
  }
}

Listagem 2: Template de Test gerado pelo RESTClient.

A partir da versão 2.3, RESTClient possui uma versão em linha de comando, está versão é utilizada para executar requisições de forma batch e armazenar o resultado dos testes. Para executar está versão, basta na linha de comando executar:

$java -jar restclient-cli-2.3-jar-with-dependencies.jar -o /temp/diretorioResponse *.rcq

Esse comando, irá executar todos as requisições contidas nos arquivos de extensão (.rcq) no diretório de execução atual, e irá salvar as responses (na extensão .rcs) no diretório /temp/diretorioResponse. E por fim, o RESTClient, imprime um resumo da execução dos testes.

Referências:

Artigo RESTFul Web Services e a API JAX-RS na revista Mundo Java edição 35
Artigo Testing RESTful WebServices Made Easy (em inglês), publicado na revista Linux 4You em Maio de 2009.
RESTClient Cookbook, vários receitas e demonstrações de como extender o RESTClient.

Testando Web Services RESTful no NetBeans.

Para quem é usuário do NetBeans, uma outra opção para testar Web Services RESTful é utilizar o suporte do próprio IDE, com um projeto Web criado e os serviços RESTful devidamente configurados, é possível testá-los clicando com o botão direito do mouse em cima do projeto e selecionar a opção “Test RESTful Web Services” (Figura 02), lembrando que está opção só estará disponível, se o projeto WEB possuir serviços WEB.

Figura 02 -Suporte a REST no NetBeans.

Ao selecionar esta opção, será feito o build e o deploy da aplicação web, e ao final do processo será disponibilizado uma página de testes web, como mostra a Figura 03.

Figura 03 - Tela de testes de Web Services RESTful

Na página apresentada é possível testar todos os serviços disponíveis, criar novos parâmetros para a requisição (botão “Add Parameter”), e também é possível selecionar o tipo de método HTTP para teste e o tipo MIME de retorno.

Para iniciar o teste, basta clicar no botão “Test”, após a execução, dentro da seção Response, podemos analisar os dados de retorno, os dados do cabeçalho e o status da chamada.

Além disso, de acordo com os serviços criados, o NetBeans ainda gera o arquivo WADL, visível no canto superior esquerdo da Figura 03.

Referências:

NetBeans - Site Oficial: http://netbeans.org/
Creating a RESTFul Web Service Using NetBeans - Tutorial do site da Sun.

JAXB

JAXB (Java Architecture for XML Binding) fornece a API, as ferramentas e um framework que automatiza o mapeamento entre documentos XML e objetos Java. Ou seja, fornece compiladores que compilam Schemas XML para objetos Java. Em tempo de execução podemos deserializar (unmarshal) o conteúdo de um arquivo XML para representações Java.

Além disso, podemos acessar, alterar e validar a representação Java contra regras de um Schema e por fim, podemos serializar (marshal) o conteúdo de um objeto Java em conteúdo XML. Veja sua arquitetura na Figura 04:

Figura 04 - Overview do JAXB.

Esta fora deste artigo um estudo mais aprofundado sobre o JAXB, mas apenas para conhecimento, a API JAXB acabou se tornando a forma padrão de mapeamento entre Java e XML, com JAXB temos anotações que nos permitem criar uma representação em Java de um Schema XML, estas anotações estão presentes no pacote javax.xml.bind.annotations, e possuem anotações associadas a pacotes Java (@XmlSchema, @XmlSchemaType, etc..), a classes Java (@XmlType, @XmlRootElement), a propriedades e campos (@XmlElement, @XmlAttribute), entre outras anotaçõe.

Para exemplificar, considere o exemplo da listagem 3, esta é uma classe POJO representando uma pessoa, com anotações JAXB. Ao fazer um marshalling de uma instância da classe PessoaBinding para XML, teremos o resultado apresentado na listagem 04.

@XmlRootElement(name="pessoa")
@XmlType(name="", propOrder={"nome","idade","statusCivil"})
public class PessoaBinding {
/* Construtores e Setters omitidos */
    private String nome;
    private int idade;
    private String statusCivil;
    private String cpf;

    @XmlElement
    public String getNome() {
        return nome;
    }
    @XmlElement
    public int getIdade() {
        return idade;
    }
    @XmlAttribute(name="num_cpf")
    public String getCpf() {
        return cpf;
    }
    @XmlElement
    public String getStatusCivil() {
        return statusCivil;
    }
}

Listagem 03 - Classe PessoaBinding com anotações JAXB.

   
       Wagner
       29
       Casado

Listagem 04 - XML Gerado após marshalling de classe JAXB PessoaBinding.

A especificação do JAX-RS fornece alguns Entity Providers padrões, entre eles, provedores para JAXB, para quando o tipo de conteúdo trafegado for do tipo xml (application/xml, text/xml e application/*+xml), de modo que o programador não precisa criar código para converter um objeto Java em código XML e vice versa, facilitando muito nossa vida.

Ainda na classe PessoaBinding da listagem 03, poderíamos então, no nosso exemplo, criar um serviço RESTful cujo retorno seja a classe JAXB PessoaBinding , neste caso a declaração do serviço seria similar ao método da listagem 05.

    @GET
    @Produces("application/xml")
    @Path("/NetFeijao/autor/{idPessoa}/")
    public PessoaBinding getPessoa(@PathParam("idPessoa") Integer id) {
         return dao.getPessoaAsBinding(id); // Retorna uma entidade Pessoa como PessoaBinding
    }

Listagem 05 - Serviço RESTful cujo retorno é uma classe JAXB.

Ao fazermos o consumo deste serviço RESTful, vamos perceber que a conversão é feita automaticamente pelo entity provider padrão para XML (veja o teste na Figura 05, utilizando a ferramenta RESTClient). De maneira inversa poderíamos criar um serviço RESTful para receber requisições PUT e receber como parâmetro de entrada do método a classe PessoaBinding via HTTP Body. Conforme apresenta a listagem 06:

Figura 05 - Retorno do serviço RESTful cujo retorno é uma classe JAXB.

    @PUT
    @Consumes("application/xml")
    @Path("/NetFeijao/")
    public void putPessoa(PessoaBinding pessoa) {
        // Operação de update
    }

Listagem 06 - Convertendo código XML para objeto JAXB em chamada PUT com REST.

Referências:

Site Oficial no java.net. - https://jaxb.dev.java.net/
Java Architectura for XML Binding - Tutorial do site da Sun.

JAKARTA COMMONS - HTTP CLIENT

HttpClient é um subprojeto open source da Jakarta Commons que se tornou independente em 2007, e que foi concebido para facilitar o desenvolvimento de aplicações que utilizam o protocolo HTTP.
Ele é um projeto escrito totalmente em Java, e implementa todos os métodos HTTP (GET, POST, PUT, DELETE, HEAD, OPTIONS e TRACE).

Possui suporte ao protocolo HTTPS, suporte ao gerenciamento de conexões para uso em aplicações multi-thread, suporte a cookie, possui mecanismos de autenticação Basic, Digest e criptografia NTLM.

Na listagem 07, demonstramos o uso da biblioteca HttpClient, onde consumimos dois serviços RESTful, um com uma chamada GET e outra com uma chamada PUT.

     public void testHTTPClient() {
        try {
            HttpClient client = new HttpClient(new MultiThreadedHttpConnectionManager());
            client.getHttpConnectionManager().getParams().setConnectionTimeout(30000);
            final String CONTENT_TYPE = "application/xml";
            final String CHARSET = "UTF8";

           /* Executando chamada com método HTTP GET */
        String getURI = "http://localhost:8080/ProjetoREST/NetFeijao/autores/Wagner/?idade=29";
        GetMethod get = new GetMethod(getURI);
        Header meuHeader = new Header("CPF","123456789");
        get.setRequestHeader(meuHeader);
        int statusCodeGET = client.executeMethod(get);
        String responseBody = get.getResponseBodyAsString();
        System.out.println("Chamada GET");
        System.out.println(" Status Code: "+statusCodeGET+" \nResponse Body:\n"+responseBody);

         /* Executando chamada com método HTTP PUT */
       String putURI = "http://localhost:8080/ProjetoREST/NetFeijao/autores/update/";
       PutMethod put = new PutMethod(putURI);
    StringRequestEntity requestEntity = new StringRequestEntity(responseBody, CONTENT_TYPE, CHARSET);
        put.setRequestEntity(requestEntity);
        int statusCodePUT = client.executeMethod(put);
        responseBody = put.getResponseBodyAsString();
        System.out.println("Chamada PUT");
        System.out.println(" Status Code: "+statusCodePUT+" \nResponse Body:\n"+responseBody);
    } catch (Exception ex) {/* OMITIDO */}
}

Retorno da chamada ao método.
Chamada GET
Status Code: 200
Response Body:


       Wagner
       29
       Casado


Chamada PUT
Status Code: 202
Response Body:

Bem vindo Wagner

Listagem 07: Consumindo serviços REST via GET e PUT com HTTPClient.

Primeiro, na linha 3 instanciamos a classe HttpClient que é o nosso agente HTTP que irá conter os atributos de persistência com cookies, e credenciais de autenticação através da classe HttpState. E também onde será armazenado uma ou mais conexões HTTP, cujo qual faremos chamadas aos métodos HTTP.

Na linha 4 atribuímos um timeout para a conexão de 30 segundos. Depois nas linhas 5, 6 e 9 declaramos as variáveis quer irão determinar o tipo de conteúdo, o character set e a URI de acesso ao serviço REST.

Na linha 10, instanciamos a classe GetMethod, que como o próprio nome indica representa o método GET, passando como parâmetro a URL do nosso serviço RESTful (getURI). Na linha 11 criamos um objeto Header, passando como parâmetro no construtor a chave e o valor que representam o parâmetro e o valor do cabeçalho, no nosso exemplo, passamos um número fictício de CPF. Na linha 12 atribuímos o objeto header para o objeto GetMethod.

Na linha 13, fazemos a chamada ao serviço RESTful via HTTP GET, e armazenamos o código de status do retorno na variável statusCodeGET, na linha 14 extraímos os dados da Response como String para a variável responseBody. Pelo fato do retorno ser em XML, poderíamos facilmente utilizar JAXB para trabalhar o retorno como um objeto Java. Finalmente nas linhas 15 e 16 imprimimos no console o retorno da chamada a estes métodos.

A partir da linha 18, iniciamos o mesmo processo, mas agora para efetuar uma chamada via método PUT, as únicas diferenças, são o uso do método PutMethod, que implementa o método HTTP PUT e o uso da classe StringRequestEntity na linha 21, com esta classe atribuímos uma entidade como String ao método PUT que será enviado junto a requisição.

Nas linhas 25 e 26 imprimimos o retorno da requisição PUT.

JavaScript:

Graças ao objeto XMLHttpRequest conseguimos nos comunicar com servidores de forma assíncrona, desde então temos todas as vantagens do AJAX ao nosso dispor. Para quem desenvolve interfaces WEB, este recurso resolveu grandes problemas no lado do cliente, mas vale lembrar que JavaScript não é Java, não possui threads, nem tipos, e possui uma grande gama de frameworks Ajax, como por exemplo Prototype, JQuery, Dojo, Script.aculo.us, Ext-JS, entre outros.

Na listagem 08, temos um exemplo de uma função em JavaScript que consume um serviço RESTful cujo retorno é um XML.

var xmlHttp;
function showCustomer(str){ 
    xmlHttp=GetXmlHttpObject(); // omitido código do método0
    if (xmlHttp==null) {
        alert ("Your browser does not support AJAX!");
        return;
    }
    var url='http://localhost:8080/Contatos/resources/customers/58/';
    xmlHttp.onreadystatechange=stateChanged;
    xmlHttp.open('GET',url,true);
    xmlHttp.send(null);
}

function stateChanged() { 
    if (xmlHttp.readyState==4){
        var xmlDoc=xmlHttp.responseXML.documentElement;
        document.getElementById("nome").innerHTML= 
        xmlDoc.getElementsByTagName("name")[0].childNodes[0].nodeValue;
    }
}

Listagem 08 - Consumindo um serviço RESTful (retorno XML) com Ajax.

Na listagem 08, vimos um exemplo de um serviço que retorna XML, mas uma das grandes vantagens dos serviços REST, é que podemos trabalhar com diversos formatos para troca de informação de um mesmo recurso. Entre eles JSON.

jQuery

JQuery é uma biblioteca JavaScript que vem chamando atenção por conta de sua facilidade de desenvolvimento, ela simplifica muito a manipulação dos elementos de um documento HTML, o tratamento de eventos e as interações Ajax para prover um desenvolvimento rápido de aplicações web, livrando o desenvolvedor de preocupações relacionadas a compatibilidade de navegadores e aderência a CSS.

A biblioteca jQuery fornece algumas funções para tratamento de requisições Ajax, ideais para o consumo de serviços REST, que reduzem muito a complexidade e a quantidade de linhas necessárias para consumir um serviço REST. Com a função $.ajax() do jQuery, conseguimos um alto nível de controle nas requisições ajax.

A sintaxe do comando é $.ajax(options), onde o parâmetro options são as propriedades que passamos para controlar como a requisição é feita e retorno da chamada.
Na listagem 09, demonstramos o uso das funções $.ajax().

$.ajax({
    type: ‘DELETE’,
    url: "http://localhost:8080/ProjetREST/NetFeijao/autores/"+idAutor+"/",
    success: function(msg){
        $("#alert").html(msg);
    }
});

Listagem 09 - Consumindo um serviço REST com a função $.ajax().

Na listagem 09, usamos dois parâmetros na função $.ajax(), o parâmetro type para indicar o método HTTP que queremos executar e a url de chamada.

Para tratar tipos de retorno JSON, o jQuery oferece a função $.getJSON(), utilizada para carregar dados JSON mediante uma requisição HTTP GET.

Na listagem 10 mostramos um exemplo de uso da função $.getJSON() em um serviço REST do Flickr, nós fazemos uma chamada ao serviço REST e passamos o retorno da chamada ao método de callback. Dentro da função de callback criamos a tag passando como valor o endereço da foto retornada pelo serviço REST e a incluímos na div #foto. Note que a variável data, é um map chave-valor dos dados retornados pela função REST.

$.getJSON("http://api.flickr.com/services/rest/?method=flickr.photosets.getPhotos& photoset_id=72157614488723406&format=json&jsoncallback=?",
function(data){
    $.each(data.photoset.photo, function(i,item){
        if (item.title == foto){
            $("").attr("src", "http://farm"+item.farm+".static.flickr.com/"+item.server+"/"+item.id+"_"+item.secret+"_m.jpg").appendTo("#foto");
        }
    });
});

Listagem 10 - Uso da função $.getJSON para consumo de dados no formato JSON.

É isso aí, consumir serviços REST é diversão garantida !!! E a todos um Feliz Ano Novo repleto de código \o/ !!!

Java Magazine 73 - Portais Corporativos

2009-12-21T13:10:00.004-02:00

No mês de Novembro, publiquei um artigo na revista Java Magazine, fazia um tempo que não escrevia por conta de um projeto que estou tocando.

O tema do artigo é "Portais Corporativos", Neste artigo é apresentado na teoria e na prática os fundamentos do desenvolvimento de portlets em portais corporativos e a importância de Portais no contexto de SOA (com a colaboração de meu amigo Marcelo Zanatto, que falou sobre SOA e Integração com Portais). Como é de costume, o artigo é bem longo e entra a fundo nas tecnologias envolvidas na construção de um grande portal, como as JSRs 168/286, que contemplam a criação e o ciclo de vida de um portlet. É explicado também como definir WSRPs, que são os web services para portlets remotos, e como converter uma aplicação JSF para um portlet com o uso do Portlet Bridge.

Como demo, utilizei o NetBeans para montar e configurar um ambiente para o desenvolvimento de portlets utilizando o Contêiner de Portlets, o pacote WSRP, e a biblioteca JSF/Portlet Bridge do projeto livre OpenPortal junto ao servidor de aplicações Glassfish V2.

Nesta edição, ainda são apresentados os seguintes artigos.

JavaOne 2009: Java + Community = Powerful
Desenvolvendo com JavaServer Faces
Portais Corporativos
Desenvolvendo com Hibernate
Spring-WS de ponta a ponta
O diferencial Scrum

Diversão Garantida!!

Perguntas Frequentes sobre Agilidade

2009-10-14T17:53:00.002-03:00

Em Julho deste ano, após o mini-curso que dei na Globalcode sobre Scrum + XP, uma das pessoas presentes, meu amigo Orlando, anotou diversas perguntas sobre Agilidade no formato de entrevista e pediu que eu respondesse por email.
Segue abaixo algumas perguntas que achei interessante, e resolvi publicá-las aqui no blog.

O que é ser ágil nos dias de hoje?

Acho que ser ágil nos dias de hoje é saber aproveitar as oportunidades de inovação no seu ambiente de trabalho, percebo que a maioria das pessoas acabam ficando acostumadas com a rotina de seus afazeres e perdem chances de inovar.
Quando digo inovar, digo que existem várias maneiras de você introduzir no seu dia a dia práticas ágeis. Outro ponto importante em ambiente ágeis é a comunicação, para ser ágil a pessoa saber lidar com pessoas, com o cliente, e ter um relacionamento de parceria, não pode ter medo de se expor e ser comprometido.
Comprometido não é trabalhar 250 horas por mês no projeto, é saber assumir responsabilidades e saber responder por elas, não ter vergonha de pedir ajuda na hora de uma dificuldade. É velha a história do porco e da galinha =).

Quais os pontos fracos das metodologias ágeis?

O que vejo como um ponto fraco em metodologias ágeis, pela sua própria natureza lean, ou seja, enxuta. É que fica um pouco difícil a sua adoção em ambientes que haja modelos de governança de TI como o Cobit, por exemplo. É difícil em um ambiente de Governança "certificado", você justificar para o gerenciamento de projeto o uso apenas de quadros e post-its, entende? Isso eu digo principalmente com Scrum e XP.
Neste tipo de cenário, a empresa tende a escolher modelos híbridos baseados no PMBook e RUP. O que no final acabam se tornando processos altamente burocráticos em cascata.
Por isso, que acho que esse é um campo que tem muito a ser explorado, trabalhei cerca de 2 a 3 com RUP, e uma escolha mal feita nos artefatos de projeto acaba comprometendo e muito o rendimento da equipe
Outro ponto fraco é o próprio agilista, que tende a pensar que é o dono da razão, pois a verdade é que Barry Boehm já falava da importância dos métodos iterativos ( que vieram bem antes do movimento ágil ).

Quando não usar?

Bem, independente do lugar que você esteja é muito importante praticar, aplicar os valores do Manifesto Ágil.
Eu não consigo enxergar o uso de métodos ágeis em projetos de implantação de ERP (pacote comprado), principalmente quando a implantação é feita em grandes empresas com diversas filiais. Geralmente, as empresas fornecedoras deste tipo de software já possuem métodos próprios.
Outra ponto, é se a sua empresa desenvolve software e seu cliente esta feliz, o desenvolvedor esta feliz, os projetos estão sendo entregues no prazo, o ROI esta dentro das expectativas, o Time-to-market do seu produto é baixo e a equipe é produtiva, se neste cenário você já não estiver usando ágil, fique onde está.
Se o seu processo de desenvolvimento esta atendendo plenamente você e seus clientes, então não mude. Você já esta no caminho certo.

O que mais dificulta a implantação de uma metodologia ágil numa empresa atualmente?

Com certeza o que dificulta a implantação de métodos ágeis nas empresas é a própria filosofia de desenvolvimento da empresa. Por requerer uma mudança radical na forma de lidar com o desenvolvimento de software, é difícil alcançar uma plenitude na implementação de métodos ágeis e isto pode afetar sua adoção, é difícil as pessoas envolvidas na definição de processos da empresa admitirem que estavam fazendo algo que é não muito produtivo, e que a maneira que elas desenvolvendo software não é a melhor.
Outros pontos que dificultam a implantação de métodos ágeis, ainda alinhado ao primeiro item é a falta de um sponsor, como um diretor, ou outro cargo executivo, se agile não está "vendido" para a alta cúpula da empresa, então pode haver muita resistência por conta da própria TI.
E por fim, a falta de comprometimento da equipe e a falta de conhecimento em métodos ágeis podem dificultar também a implantação.

Só serve para projetos? E a manutenção do sistema?

Agile proporciona um leque bem variado de métodos, entre eles FDD, Scrum, XP, Lean, Crystal, entre outros. Eu diria que os dois caminham juntos, a questão gira em torno de como você irá administrar e classificar os itens em seu backlog.
A partir do momento que um release do seu produto entra em produção, é natural que novas demandas e até bugs apareçam. Tem empresas que separam equipes para atuar somente em projetos de manutenção e outras equipes para trabalhar somente em projetos de evolução, depende tudo de como o trabalho é priorizado.
Para áreas de serviço, como Infraestrutura, onde a atuação das equipes geralmente é feita sob demanda, é recomendado o uso de quadros Kanban, inclusive atualmente estou fazendo um trabalho neste sentido (Quadros Kanban para áreas de Infraestrutura).

E a arquitetura do sistema, como fica?

Essa é uma questão polêmica e que gera muitas dúvidas para quem está iniciando no mundo ágil, principalmente para as pessoas que estão em transição de um método como o Waterfall para o Ágil.
Quando o time de desenvolvimento vem do Waterfall ou até mesmo do RUP, que é um método que descreve os artefatos necessários para se documentar a arquitetura do projeto e propõe um modelo "big design up front", ou seja, força o time tentar imaginar e fechar todos os modelos no inicio da execução do projeto.
Em processos ágeis isso acontece de forma natural e evolutiva, uma das práticas do XP, o "Simple Design" ou "Design Simples" nos diz para mantermos o nosso design o mais limpo e simples possível, e não tentar imaginar funcionalidades que o sistema possa vir a ter, e preparar o sistema para estes prováveis cenários. Isso foge completamente do modelo ágil de gerir projetos.
Independente do modelo que você segue, o seu sistema obviamente será construída baseada em uma arquitetura, e em toda metodologia é muito importante você fazer o planejamento da sua arquitetura, a diferença é que em métodos ágeis devemos sempre respeitar a maturidade atual do projeto de modo que quando houver mudanças ou adição de novos requisitos do negócio, fique fácil refatorar o sistema, levando sempre em consideração os requisitos de qualidade de serviço (QoS) conhecidos por todo arquiteto,

Como fica o contrato? Não há prejuízos para a produtora, uma vez que o cliente altere constantemente o que foi inicialmente solicitado?

Acredito que não, um dos valores do manifesto ágil diz que a colaboração com o cliente é mais importante do que a negociação de contratos, por que isso? Se olharmos para a maneira como as empresas negociam os contratos de software com as consultorias, veremos que esta é uma eterna luta. Porque as empresas adotam o modelo de "Preço Fixo" e para uma consultoria entrar em uma empresa, ao formular uma RFP ela acaba colocando valores que muitas vezes ela mesma sabe que pode tomar um prejuízo, mas o faz para ganhar o cliente.
Este tipo de contrato é ruim, pois passa a maior parte do risco para o desenvolvedor, se o projeto atrasa, o consultor arca com os custos, o que dificulta (e muito) mudanças de escopo.
Um modelo de contrato que achei muito interessante é o modelo "Money for Nothing, Changes for free" proposto por Peter Stevens em http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts#MFN-cff.

Qual o maior benefício (a longo ou curto prazo) que um funcionário (desenvolvedor, tester, analista, etc.) obtém quando se compromete a seguir uma proposta ágil?

Desenvolvedores geralmente gostam de agile, porque os métodos são voltados para times auto-gerenciáveis. Modelos ágeis dão uma liberdade maior aos membros do time, então acho que o maior benefício é o próprio bem-estar do time. Sem falar dos ganhos da empresa como a melhoria contínua da qualidade, redução do risco de entrega e do time to market, aumento da visibilidade do projeto, entre outros.

Como ser um Scrum Master?

Na minha visão, para ser um Scrum Master é preciso antes de tudo saber lidar com pessoas, isso é fundamental, além disso, precisa ser uma pessoa comprometida e responsável, que entenda os requisitos do negócio e as necessidades do time.
Tem que ser uma pessoa humilde, e que saiba influenciar a equipe de maneira positiva, com uma cultura de colaboração.

Como as empresas do Brasil estão aceitando a XP?

Hoje em dia é moda falar de Agilidade no Brasil, principalmente no meio dos desenvolvedores. O que vejo é que é um assunto muito falado, mas pouco aplicado.
XP tem sido assunto em roda de conversa de desenvolvedores durante muitos anos, e o que acaba sendo feito neste sentido são movimentos individuais de desenvolvedores que aplicam algumas práticas do XP de maneira isolada, principalmente TDD.
Com o advento e a popularidade do SCRUM, pessoas de outras esferas nas empresas estão começando a olhar agile de maneira diferente, e tem havido uma grande aceitação neste sentido, então acho que isso tem sido bom para XP também.

Dê algumas dicas de boas práticas àqueles que estão iniciando (estagiários e estudantes).

A melhor dica que posso dar é a mesma que dou em minhas apresentações quando sou indagado. Que é estudar, e tentar se manter bem informado sobre o que está acontecendo no mercado. É impressionante o que você consegue fazer com os feeds dos websites, busque os melhores sites e agregue-os em ferramentas como o Google Reader ou outro leitor de feed qualquer, isso potencializa muito o conhecimento.
Participe de lista de discussões, veja cases de implantação tanto de sucesso quando de insucesso e buscar ler o máximo que puder sobre o assunto.

Finalize com uma mensagem para aqueles que estão interessados, mas ainda são céticos.

Faça uma prova de conceito, e se possível procure implementar ao menos uma prática ágil. Uma dica que dou é sempre que possível, traga o cliente para o lado do desenvolvimento, se você puder fazer com que seu cliente avalie o produto que você está desenvolvendo semanalmente ou até de 15 em 15 dias, você irá começar a ver os ganhos do desenvolvimento ágil.
Ou ainda, vou ir totalmente contra o que acabei de falar, sempre que olhar para o seu processo atual de desenvolvimento, antes de tentar adicionar qualquer prática ou passo novo (menos a que citei sobre o cliente), exclua uma etapa do seu processo. Monte um gráfico de cadeia de valor dos seus processos, e analise o que você pode excluir de passos do seu processo. Se você fizer isso, você já está no caminho de se tornar um grande agilista!

The Developers Conference 2009 - Here we Go !!!

2009-10-13T14:14:00.005-03:00

Está chegando mais uma edição do The Developers Conference 2009, que promete ser um dos eventos mais importantes de Java do Brasil. O evento é organizado pela Globalcode.
Afinal, não é todo os dias que temos a oportunidade de conhecer caras importantes como Rod Johnson, certo !!

A programação do evento já foi liberada, com uma novidade bem agradável, que são as Lightning Talks.

Nos encontramos lá !!!

A 3ª edição do The Developer’s Conference 2009, maior evento Java do país, contará com a participação de Chris Schalk, Developer Advocate do Google, trabalha atualmente no time de Google App Engine, plataforma de Computação em Nuvem do Google, além dos principais nomes da comunidade Java mundial: Ed Burns, Rod Johnson e Mike Keith. O evento acontecerá nas cidades de São Paulo (SP), nos dias 6 e 7 de novembro, em Florianópolis (SC) no dia 09 de novembro e no Rio de Janeiro (RJ) em 11 de novembro.

Haverá tradução simultânea em todas as etapas do evento;
Serão emitidos certificados de participação;
Inscrições antecipadas com desconto especial;
Inscrições corporativas e caravanas.

Diversão Garantida!!!

[Just Java 2009] De Web Services RESTful a aplicações Mashup

2009-10-05T18:41:00.003-03:00

Nos dias 15 a 17 de Outubro, aconteceu no Centro de Convenções do Senac de Santo Amaro, mais uma edição do Just Java. E como sempre, esta foi uma ótima oportunidade para aprender novas tecnologias e fazer aquele Network.

Apresentei no auditório principal, a palestra "De Web Services RESTFul a aplicações Mashups", onde pude abordar os conceitos de REST proposto pelo Dr. Roy Fielding, passando pela especificação JAX-RS, que define API para criação de Web Services, demonstrando várias maneiras de consumir e testar serviços REST, até chegar ao mundo dos Mashups, apresentando várias ferramentas com exemplos de uso .

Por fim foi apresentado uma demo, que infelizmente por falta de acesso a internet, não pude apresentar em sua plenitude =(.

Para ver o restante da programação e baixar as apresentações que rolaram no evento, acesse este link.

Congresso JustJava 2009 - 15 a 17 de Setembro - Apresentações

Fotos: Crédito de Eduardo Quagliato -Link: JustJava 2009 no Flickr – Compartilhamento de fotos!

Segue abaixo a apresentação.

De Web Services RESTful a Aplicações Mashup

View more documents from wrsantos.

Diversão Garantida !!!

Widget SOUJava

2009-09-10T11:38:00.004-03:00

Já faz um tempo, que venho colaborando com o SOUJava, um dos maiores grupos de usuários Java no mundo, sem fins lucrativos. Após pequenas contribuições apresentando algumas palestras (localização, NetBeans Platform), nos últimos tempos tenho tido o privilégio de participar mais efetivamente com o grupo, que conta com a presença de pessoas como Bruno Souza, Mauricio Leal, Yara Senger, Mr. M, Fabio Velloso entre outros.

E uma das contribuições, junto com o grupo foi justamente na criação de um widget web para divulgação de eventos, notícias, reuniões para o SOUJava.

Esse widget foi desenvolvido utilizando o Zembly, para quem não conhece, o Zembly é um ambiente de desenvolvimento no Browser criado pela Sun Microsystems, que permite um conceito novo chamado de programação social, muito similar a um Wiki. Com Zembly podemos criar aplicações para redes sociais como Facebook, Meebo, OpenSocial, aplicações web para o iPhone e outras plataformas sociais. E claro, permite criar web widgets.

O widget que criamos (vide abaixo) é separado em cinco tabs, onde dispomos informações referentes aos eventos, reuniões, uma das abas (Notícias) é uma integração com o nosso feed. Periodicamente vamos atualizar o conteúdo do widget, sempre que surgir novidades.

O melhor disso tudo, é que VOCÊ desenvolvedor brasileiro, que possui algum site ou blog de tecnologia agora pode nos ajudar a divulgar os eventos promovidos pelo SOUJava e notícias do mundo Java, embutindo o widget em seu site, blog ou fórum.

Para divulgar nossos eventos é muito fácil, apenas copie o código javascript abaixo e inclua em seu blog ou site.

Segue abaixo, o widget em ação.

Diversão Garantida!!!

Entrevista para a Globalcode

2009-09-10T11:38:00.003-03:00

No mês de Junho, foi publicado uma entrevista minha para meus caros amigos da Globalcode, sobre carreira e oportunidades, para quem não viu vale a pena conferir. Segue abaixo as perguntas que estão disponíveis no próprio site da Globalcode. Para quiser ver o link da entrevista, clique aqui.

1. Poderia nos contar como começou a desenvolver plugins para o Netbeans ?

Comecei a desenvolver plugins através do "Desafio NetBeans", um campeonato de desenvolvimento de plugins para o NetBeans patrocinado pela Globalcode, Sun e o SOUJava, me lembro que antes de iniciar o campeonato participei de alguns minicursos gratuitos promovido pela Globalcode, contando inclusive com a participação de dois desenvolvedores do NetBeans (Tim Boudreau e Charlie Hunt).
Neste campeonato desenvolvi meu primeiro plugin para o Netbeans, mais especificamente um plugin para o Hibernate, onde a partir de tabelas selecionadas de um Banco de Dados, o plugin gera as entidades de persistência, o arquivo de configuração, com suporte a xDoclet (na época não havia annotations). Neste primeiro contato com a plataforma NetBeans tive a oportunidade de aprender várias coisas legais que me motivaram a continuar o aprendizado.

2. Desde então, quais plugins você já desenvolveu?

O segundo plugin que desenvolvi foi o módulo CodeGen, um plugin para sobrescrever os métodos equals() e hashcode() que na época (NetBeans 5.0) não existia no NetBeans, e existia no Eclipse. Existe até uma história engraçada por trás disso, me lembro de estar em um minicurso em que o Vinicius comentou que abria o Eclipse apenas para utilizar a função do equals e hashcode, o que me motivou a criar este projeto =D.
Depois desenvolvi alguns plugins corporativos, e depois de um tempo, a pedido do meu amigo Renato Bellia, criei o plugin Diamond Powder for NetBeans. No evento Yahoo Open Hack Day desenvolvi junto com o time Globalcode o plugin Blueprints Yahoo!, e mais recentemente estou colaborando na criação de um plugin para o framework SuperCRUD para o meu amigo Vinicius Senger.

3.Poderia comentar um pouco sobre o plugin que você desenvolveu no Yahoo Open Hack Day onde participou da equipe que ganhou o prêmio Bridging the Gap ?

Para mim foi uma grande alegria e honra participar do time Globalcode, onde ao todo foram desenvolvidos 4 hacks. Sobre o plugin desenvolvido para o Yahoo Open Hack Day, é um módulo que permite a criação de projetos (através de templates) com suporte ao Yahoo! Blueprint, uma tecnologia desenvolvida pela Yahoo que permite a criação de web sites para celulares com uso apenas de XML. O plugin oferece a criação de um esqueleto para um projeto Yahoo, criando os arquivos necessários para seu funcionamento (gallery.xml e config.xml). Além disso, o plugin vem com alguns samples (desenvolvidos pela Globalcode) dentro do NetBeans para os desenvolvedores que querem entender como funciona um projeto Blueprint. E possui suporte a Update Center, Help, e a inclusão do guia do Desenvolvedor em pdf no NetBeans.

4. Quais os conhecimentos necessários para um programador começar a criar módulos para o NetBeans ?

Além de ter conhecimentos sólidos de Java Standard Edition, para o programador iniciar a criação de módulos para o NetBeans, é importante entender como funciona o NetBeans e a sua arquitetura. Procurar enxergar além do IDE, rs.. o IDE NetBeans é construído sobre a Plataforma NetBeans, assim como vários outros produtos, como por exemplo a ferramenta VisualVM, quem utiliza nota a grande semelhança com o NetBeans.
Ao iniciar o desenvolvimento na plataforma NetBeans, já temos disponíveis várias funcionalidades / componentes prontos para o uso e toda esta infraestrutura pode ser manipulada via código através das APIs da Plataforma NetBeans. A plataforma dispõe de APIs para trabalhar com diversos tipos de categorias entre os quais podemos destacar como as Ações do Sistema (Actions), Ant, Paleta de objetos, Debug, Dialogs (para notificação), Sistema de Janelas, Sistema de Arquivos, Editores, Navegação, Loaders, entre outros.
O programador precisa somente entender como manipular estas APIs que ele pode praticamente fazer o que quiser com o NetBeans.

5. Sabemos que você andou fazendo testes com Zembly, poderia comentar um pouco sobre o que é Zembly e para que serve ?

A ideia do Zembly, é criar uma espécie de Wiki para aplicações sociais como o Facebook, ele fornece o ambiente no próprio site do Zembly para criação e edição de aplicações sociais, essa aplicação fica hospedada em uma nuvem do Zembly de maneira que podemos compartilhar nossa aplicação entre diversos sites, como se fossem widgets.
É algo extremamente interessante, pois no Zembly, temos um editor para o código HTML/XHTML para UI, um editor CSS para aplicar os estilos da aplicação e um editor JavaScript para a lógica do negócio, que pode ser utilizado bibliotecas JavaScript como jQuery, Prototype e podemos fazer inclusive integração com diversas APIs como FlickR, Yahoo API, Google Maps, entre outros.
Atualmente estou trabalhando no SOUJava para criar uma aplicação que seja compartilhada pelos sites de tecnologia, fóruns, blogs, de maneira que o SOUJava possa divulgar suas atividades de uma maneira muito mais ampla, pois estes sites deverão apenas incluir um pequeno trecho de código JavaScript em seus sites.

6. Poderia comentar um pouco sobre o Plugin que desenvolveu como colaboração para o SuperCRUD ?

Na verdade, este foi um trabalho relâmpago que montamos para o SuperCRUD e está em evolução, atualmente o plugin permite a criação de qualquer tipo de projeto (web, desktop, maven) com fontes existentes a partir de um servidor remoto, onde o desenvolvedor precisa informar a URL para o projeto (zipado).
Pelo que sei, o desenvolvedor cria um projeto no SuperCRUD, e ao final o próprio SuperCRUD gera uma bookmarkable URL que o programador cola e copia no NetBeans (no plugin), que por sua vez abre o projeto remotamente. Mas claro, sobre esta parte do SuperCRUD o Vinicius poderia dar maiores detalhes =D.

7. Poderia comentar um pouco sobre o Plugin que fez para o projeto Diamond Powder junto com o Renato Bellia?

O Diamond Powder é um framework open source para Java ME desenvolvido pelo Bellia, que acelera a criação de coletores de dados em aplicações MIDP. O framework permite a criação dos formulários, fields (datafield, stringitem, textfield, choicegroup, filter, etc..), definição do fluxo de navegação das páginas e as páginas de help de maneira declarativa, baseada em definições de pares de chave-valor com uso de um Hashtable, que descreve toda a sua organização por um objeto chamado Schema.
O "Schema" é o coração do framework, mas conforme a sua aplicação cresce, fica cada vez mais difícil dar manutenção no seu Schema, como adicionar novas páginas e campos, e é onde o plugin entra, ele facilita muito a criação e a manutenção do código do Schema (com refactoring ou criação de uma nova classe) através de um wizard e evita a digitação errada dos nomes das váriaveis, campos.
Tem a possibilidade de gravar os dados criados (páginas, campos, etc...) em um arquivo properties e reutilizá-los em outros projetos.

8. Você realmente achou um nicho de mercado muito interessante, onde pode colaborar com praticamente qualquer projeto Open Source, quais as dicas que você poderia dar para as pessoas que estão iniciando?

A melhor dica que posso dar é estudar, estudar e estudar. Porém, se você ficar cansado de estudar, estude mais um pouco, faça cursos de java, visite sites de tecnologia como InfoQ, TheServerSide, execute os samples disponíveis no NetBeans e analise o código fonte, participe das listas de discussão. Participe dos eventos, dos minicursos, inscreva-se em todos os feeds possíveis sobre tecnologia, blogs, participe de grupos de discussão, tire certificações e o mais importante, participe de projetos open source, além de aprender com profissionais renomados e compartilhar conhecimento, você estará fazendo networking, sem falar da possibilidade do seu trabalho ficar conhecido no mundo todo.

9. Poderia citar algumas referências para quem quer começar a desenvolver plugins para NetBeans ?

Para as pessoas que estão iniciando, recomendo o próprio site do NetBeans Platform que possui diversos tutoriais, screencasts, wikis, samples que demonstram como criar módulos para o NetBeans, recomendo também o blog do Geertjan, um dos desenvolvedores e evangelista do NetBeans, e existe um livro excelente chamado Plugging into the NetBeans Platform, que apesar de ser de 2007 demonstra em detalhes a criação de módulos para o NetBeans e o uso correto das APIs. E também recomendo meu artigo que foi publicado na edição 29 da revista Mundo Java sobre a Plataforma NetBeans ;).

10. Poderia citar algumas referências para quem quer começar a estudar Zembly?

Para começar a estudar Zembly, o mais importante é conhecer bem JavaScript, (X)HTML e CSS, o resto é entender como funciona o ambiente do Zembly.
Uma ótima referência é o wiki do site, que possui diversos tutoriais de como criar aplicações a partir de templates, criação de aplicações para o Facebook, iPhone, Meebo, entre outros.

Oracle - Sun no fantástico mundo de Hardware

2009-09-10T09:53:00.001-03:00

Para quem pensava que a Oracle não iria investir em Hardware, saiu hoje no site da Oracle um comunicado aos cliente da Sun sobre alguns de seus planos, mais especificamente na parte de hardware, observe que final ainda tem um aviso para IBM,

Nós estamos nesta para ganhar.
IBM prepare-se, nós estamos nos preparando para competir com vocês no negócio de Hardware.

Larry Elisson

É esperar para ver !!! =)
Diversão garantida !

Just Java 2009 - O principal evento da comunidade Java Brasileira

2009-09-09T16:25:00.002-03:00

Nos dias 15, 16 e 17 de Setembro acontece em São Paulo o Just Java 2009. Será a 8a. edição do principal evento da Comunidade Java Brasileira.
A grade do evento já está disponível no site http://grade.justjava.com.br/
Esse ano vou apresentar a palestra "De Web Services RESTFul a aplicações Mashups: Como chegar lá".
Onde vou apresentar o conceitos de REST, falar sobre especificação da JSR-311 que define o JAX-RS , falar sobre frameworks de teste, como consumir serviços REST e finalmente falar sobre Mashups, e a importância de REST neste contexto.
Para se inscrever, acesse o site do evento aqui.

Diversão Garantida!!!

Scrum + XP = Agilidade eXtrema

2009-08-12T11:07:00.010-03:00

Nos dias 07 e 28 de Julho foi realizado no auditório da Globalcode o minicurso Scrum + XP = Agilidade eXtrema, gostaria de agradecer a Globalcode pelo espaço concedido e pela força e também a todos que compareceram, pelo ótimo feedback que recebi.

Para maiores detalhes de como foi o mini-curso acesse o seguinte link no site da Globalcode.

Na apresentação, o intuito foi dar um enfoque teórico e prático de como funciona o Gerenciamento de Projetos Ágeis utilizando XP e Scrum, e no final uma explicação de como combinar as duas.

O que acabou agregando bastante a apresentação foi o próprio público, que iteragiu bastante, com perguntas sobre planejamento e estimativas em projetos ágeis. Foi apresentado alguns técnicas para "vender" Agile em um ambiente corporativo. Conversamos bastante sobre o papel de uma equipe de testes, como escrever os testes de aceite e unitário dentro do TDD, Refactoring, Integração Contínua, priorização dos itens de backlog, User Stories, Débito Técnico, enfim.. três horas pareceu pouco =)

Conforme solicitado pelos colegas, segue a apresentação.

Scrum + XP na prática

Ainda durante a apresentação, demonstrei um vídeo bem engraçado intitulado "O Alpinista", onde fiz uma analogia de um alpinista com gerentes de projeto.. momento bacana para quebrar um pouco o gelo. Segue abaixo o vídeo.

Bom, é isso aí pessoal, obrigado mais uma vez !!!

Scrum + XP = Diversão Garantida !!!

Introdução ao Google Wave - Tutorial e Primeiras Impressões

2009-07-22T16:39:00.014-03:00

Como muitos devem saber, a Google está lançando um novo produto chamado Google Wave, que a alguns meses está disponível para beta-testers em um sandbox para desenvolvimento. Se a Google revolucionou a forma como utilizamos a web, agora com Wave eles querem reinventar o email. Tenho testado a ferramenta, e com o uso fui compilando o material que encontrei sobre o wave que irei disponibilizar neste artigo.
Para este post, adaptei grande parte do conteúdo do artigo Google Wave: A Complete Guide do Site Mashable.com com as minhas impressões. O site ainda possui diversos artigos interessantes sobre o Wave.

Para iniciar veja na Figura 1, a aparência do Google Wave.

Figura 1: Aparência do Google Wave.

O Google Wave possui uma interface rica e intuitiva, onde começando da esquerda para a direita, temos a caixa de navegação com a Caixa de Entrada (Inbox), a opção Active apresenta as ondas que estão ativas, a opção All apresenta todas as ondas disponíveis, e assim por diante. Na caixa Contacts, temos a nossa lista de contatos. A coluna do meio (Inbox) apresenta a nossa caixa de entrada, ou a visão que estamos enxergando no momento, similar ao Gmail, que demonstra as mensagens de acordo com o filtro (se houver) estabelecido.
Na terceira coluna, vemos uma onda aberta similar a uma seção de chat.

Mas o que é o Google Wave?

Para resumir, o Google Wave é uma plataforma de comunicação em real-time, que combina diversos aspectos da Web 2.0 que utilizamos atualmente como mensagens instantâneas, blogs, wikis, redes social, sem falar de email =) tudo isso em seu browser.
Pode ser utilizado em diversas finalidades, para gerenciamento de projetos (ferramenta de colaboração), para compartilhar arquivos ou simplesmente iniciar uma conversa, ops , onda. As pessoas podem se comunicar e trabalhar em conjunto formatação de texto rich-text, fotos, vídeos, mapas, e muito mais.

Entre as diversas funcionalidades inovadoras, segue o resumo de algumas disponíveis:

Colaboração em Tempo Real: Tecnologia concorrente que permite que as pessoas em uma onda editem conteúdo de mídia ao mesmo tempo. (É possível ver o que a pessoa está escrevendo em tempo real.)
Ferramentas de Linguagem Nativa: Google Wave automaticamente corrige palavras escritas erroneamente, e o que achei mais impressionante, ele corrige erros de concordância.
Embutível: É possível embutir ondas em qualquer blog ou site. No GDD foi apresentado como publicar uma onda no blogspot, bem legal.
Aplicações e Extensões: Assim como o Facebook ou o iGoogle é possível criar aplicações para o wave, desde de robôs até complexas aplicações, gadgets. (Tanto em Java como em Python).
Suporte a Drag and Drop: É possível fazer drag and drop de documentos, fotos para a onda, no more attachments ;-)
Playback: Uma funcionalidade interessante, uma vez que a onde fica muito grande, se alguém entrar no meio da onda, pode ficar sem entender o histórico, para isso foi disponibilizado um botão (Playback), que é possível ver o que foi dito em qualquer parte da onda. E o melhor, o projeto é open source \o/

Terminologia

Para entrar na onda, é preciso entender o linguajar do Google Wave, que ajuda a definir e contextualizar essa nova plataforma de comunicação. Entender estes termos irá ajudar a compreender mais este novo projeto. Veja a Figura 2, que apresenta estes conceitos de maneira visual.

Figura 2: Entendendo os termos de uma Wave

Wave: A onda refere-se a uma thread especifica de uma conversação. Pode serincluída apenas uma pessoa, um grupo de usuários ou mesmo robôs. Que seria todo o histórico de conversação de um email.
Wavelet: Um wavelet é também uma thread de conversação, mas somente um subconjunto de uma grande conversação (ou uma onda).
Blip: Ainda menor que uma Wavelet, um Blip é uma única, mensagem individual. Blips podem conter outros blips anexados a ele. Para saber mais sobre Blips, acesse http://www.blippr.com/apps/337306-BLIP.
Documento: Refere-se ao conteúdo dentro de um blip. Podemos ser simples caracteres ou arquivos associados ao blip.
Extensões: Um extensão é uma mini-aplicação que opera dentro de uma onda. Existem dois tipos de extensão, os Gadgets e os Robots
Gadgets: Um gadget é uma aplicação onde os usuários podem utilizar em conjunto, a maioria é construída sobre a plataforma OpenSocial (da Google), podemos fazer uma comparação com os gadgets do iGoogle ou as aplicações do Facebook. Veja a Figura 3, para alguns exemplos de gadgets (Google Maps, Polls de pesquisa, um jogo de xadrez, entre outros).

Figura 3: Gadgets para o Google Wave.

Robots: Robots são aplicações (robots) que participam de uma onda. Eles podem interagir com os usuários de uma onda, podem fornecer informações de fontes externas como o Twitter, ou podem tomar ações baseadas no conteúdo digitado pelos participantes de uma onda, um exemplo muito interessante é o robô Rosy Etta, que em tempo real traduz o conteúdo de uma onda para participantes de linguagens diferentes (ex: Japonês x Inglês) =) ,, na apresentação do GDD este ano, este foi um dos pontos altos da apresentação \o/. Veja na Figura 4 alguns robôs em ação.

Figura 4: Robôs em ação em uma onda.

Ondas Embutidas: Uma onda embutida é uma maneira de levar uma conversação de uma Wave para dentro de seu site ou blog. Sendo possível utilizar a mesma como chat ou uma maneira de se comunicar com você.

Figura 5: Exemplo de Ondas embutidas

É isso aí, esse é apenas um aperitivo que vem por aí, lembrando que o Google Wave não está disponível ainda para o grande público, se a ansiedade for grande demais =) , solicite acesso ao acesso Dev Preview, e torça para ganhar um convite.

No próximo vou demonstrar como criar um robô passo a passo para o Wave.

Diversão Garantida!!!

RESTful Web Services e a API JAX-RS na revista Mundo Java, nº 35

2009-06-09T18:25:00.007-03:00

No mês de Maio foi publicado mais um artigo meu na revista Mundo Java, sobre a REST desde o conceito proposto pelo Dr. Roy Fielding até a implementação JAX-RS em Java, com diversos exemplos práticos no Jersey.

Graças a Deus tenho recebido um bom feedback das pessoas, no artigo procurei demonstrar as tecnologias por trás de um serviço REST, onde fiz primeiro uma introdução ao HTTP, para auxiliar aos leitores que estão iniciando a compreender a dinâmica do serviço.

Ainda no artigo, apresentei um artigo bem completo sobre a API JAX-RS, e mostrando na prática com diversos códigos como se trabalhar com os recursos, tratamento de exceções, extração de parâmetros e valores da URI na requisição.
Como trabalhar o retorno dos métodos ao Cliente, dando uma visão geral dos Providers.

E por fim, apresentei um guia de ferramentas para teste, e como consumir serviços REST, utilizando a API JAXB para conversão dos dados em objetos, uso prático da biblioteca Jakarta Commons HTTP Client, o uso de bibliotecas JavaScript como o jQuery, e o uso de JavaScript / AJAX..

Sem dúvida, uma ótima pedida para quem esta iniciando o desenvolvimento de serviços REST.

Além do artigo, tem vários destaques na revista deste mês, conforme segue:

Projeto da Certificação SCEA 5
Um exemplo fictício de projeto para a segunda fase da cobiçada certificação de arquiteto Java EE.
Autores: Márcio Varchawski

Conhecendo a Plataforma JavaFX Mobile
Através deste artigo crie e compreenda seus primeiros aplicativos utilizando a plataforma Java- FX Mobile.
Autores: Ricardo da Silva Ogliari

Mundo OO: Padrões de Projeto com Generics
Aprenda como tirar vantagem de Generics na implementação de Padrões de Projeto em suas aplicações Java.
Autor: Alexandre Gazola, Alex Marques Campos

RESTful Web Services e a API JAX-RS
Conheça o poder dos serviços REST e a implementação de Referência da Sun, o Jersey.
Autor: Wagner Roberto dos Santos

ProfessorJ: Conhecendo os parâmetros de configuração mais utilizados da JVM
Aprenda como configurar a Máquina Virtual JAVA para evitar os indesejados estouros de memória.
Autores: Rodrigo de Azevedo

Tendências em Foco: Adotando o Open Source no Ensino da Computação
Entenda a estratégia de adoção do Open Source no ensino da computação e programação Java.
Autor: Cezar Taurion

SOA na Prática: Governança em SOA - Versionamento de Serviços
Aprendendo a lidar com questões de versionamento de serviços dentro de uma arquitetura SOA.
Autor: Ricardo Ferreira

Made in Brazil: JColtrane - Parser XML com SAX + Anotações
Conheça essa alternativa nacional para processesar arquivos XML sem comprometer memória e a clareza do código.
Autor: Renzo Nuccitelli, Eduardo Guerra

Diversão Garantida !!!

Web Services WS-* vs REST.

2009-05-14T17:03:00.032-03:00

Muitos sites, blogs e fóruns têm colocado seus pontos de vista em relação ao uso de web services REST e SOAP, gerando muitas vezes calorosas discussões.

Na verdade, não existe uma disputa entre eles, pois cada um possui uma proposta bem diferente. Vários estilos diferentes de aplicações tem sido utilizadas para integrar sistemas de informação corporativos, entre as opções, existem os banco de dados compartilhados, transferência de arquivos (EDI ), remote procedure call (RPC), ou troca de mensagens assíncronas via uma sistema de mensageria. Ao fazermos uma comparação entre REST e WS-* (pronucia-se ws-star), precisamos fazer uma comparação quantitativa baseado em princípios arquiteturais que envolvem questões relacionadas a cenário, tecnologia, métodos, formato dos dados trafegados, segurança, transação, entre outros fatores da sua aplicação. Devemos lembrar que estas tecnologias surgiram para suprir estes problemas recorrentes na maioria dos projetos de software, que é a interoperabilidade.

Foi quando começaram a surgir esforços da comunidade de buscar dos grandes players interoperabilidade entre suas plataformas, aplicações, e linguagens de programação. Foi quando surgiram as especificações WS-*, que atendem tanto ao estilo RPC quanto mensageria. A especificação SOAP não define como deve ser um message header, ou elementos do corpo do envelope, dessa maneira podemos ter aplicações que customizem o tipo de header que ela aceita, e o tipo de informação que deve estar vinculado ao body para uma operação em particular, sem falar que algumas dessas informações podem ser compartilhadas por diferentes aplicações, sem falar em questões de segurança, roteamento de mensagens, entre outros fatores.

As especificações WS-* definem padrões para mensagem, troca de metadados, segurança, entre outros. No mundo Java, para implementar este mundo de especificações, foi aberto o projeto WSIT (antigo projeto Tango) como parte do projeto Metro, que por sua vez faz parte do projeto Glassfish, veja a Figura 01 os padrões (em verde) utilizado no projeto WSIT.

Figura 1: Padrões de Web Services utilizados no WSIT.

É claro que para a maioria dos projetos, um web service simples resolveria, mas se começarmos a entrar mais a fundo no mundo orientado a serviços, começa a surgir a necessidade de integração com diversos sistemas, naturalmente teremos que utilizar estes padrões. É somente olhar para a figura 01 que já causa calafrios em muitos desenvolvedores, mesmo com suporte eficiente nos IDEs existentes.

Com isto, vemos claramente que a arquitetura de web services baseadas nas especificações WS-* é muito bem definida, com regras para trocas de dados, segurança, o que por conta de seu excesso de padrões acabou se tornando uma solução muito complexa.

Mesmo com toda a complexidade, serviços WS-* têm tomado cada vez mais espaço no mercado, graças aos projetos SOA que tem adotado largamente serviços WS-* por sua independência e transparência de protocolo. Por outro lado, REST é muito mais simples, como uma resposta para todos estes padrões e especificações, para utilizar REST basta ter um conhecimento razoável sobre HTTP e seus métodos.

Enquanto web services WS-* são orientados a atividade/serviço, serviços REST são orientados a recurso. Quando falamos em desenvolver serviços SOAP, estamos falando em criar APIs, contratos (WSDL), onde o WSDL descreve os detalhes de implementação, como as operações e os tipos de dados trafegados. REST por outro lado, conforme explicado no inicio diz respeito a utilizar o protocolo HTTP para manipular o estado de um recurso. Fazendo uma analogia, podemos dizer que assim como a linguagem de manipulação de dados (DML) do SQL é utilizada para manipular as informações de um banco de dados transacional, REST utiliza os métodos (verbos) do protocolo HTTP para manipular o estado de uma informação. Com estes verbos, podemos fazer praticamente tudo o que quisermos com os dados, independente se usarmos SQL ou HTTP.
Ao mapear os métodos HTTP (POST, DELETE, GET E PUT) com operações DML de um banco de dados temos a seguinte estrutura, conforme ilustra a tabela 01.

Métodos HTTP / Operações CRUD
GET -> SELECT
POST -> INSERT, UPDATE
PUT -> INSERT, UPDATE
DELETE ->DELETE

Tabela 01. Associação dos métodos HTTP com operações CRUD.

Na tabela podemos notar que podemos ter mais de uma operação relacionada a um verbo HTTP, como por exemplo, o método POST, que pode ser utilizado para diversas ações. O método PUT nos dá a possibilidade de criar um novo recurso, ou substituir por outro mais atualizado. Apesar dos diversos tutoriais e exemplos que encontramos na internet sobre REST que envolvem operações CRUD, isso não quer dizer que temos que ficar presos somente a estes tipos de operações. Por conta de sua própria natureza, REST é mais fácil e funciona muito bem com CRUDs, mas podemos em nosso design criar serviços REST. Web Services RESTful.

Pontos Positivos		Pontos Negativos
Linguagem e plataforma agnóstica. Simplicidade, interface imutável. Interação assíncrona, não possui estado. Facilidade de adoção, pois não requer uma grande infra-estrutura, muito menos um middleware para WS-* ou camada intermediária adicional. Utiliza a própria web como meio de transporte, sendo assim uma carga baixa para a rede. Utilizada por grande parte das aplicações Web 2.0. (Google, Flickr, Amazon, etc..). Portanto, ótimo para mashups. Curva de aprendizagem baixa.		Faltam padrões. Falta de segurança (dados sigilosos não deveriam ser enviados como parâmetros na URI). Não é indicado para trafegar grandes volumes de parâmetros via URI, no caso de PUT/POST para inclusão de dados, por exemplo. Em muitas empresas apenas os métodos GET e POST do HTTP são liberados em proxies e firewalls. Dentro desta limitação, muitos preferem utilizar os métodos GET para requisições de consulta e POST para todo o resto. Não há mecanismos de transação (Do it yourself) Não existe um padrão como UDDI para service discovery.

Tabela 02: Pontos positivos e negativos de REST

SOAP

Pontos Positivos

Pontos Negativos

Diversas ferramentas de desenvolvimento.
Tipagem forte e um vocabulário bem definido.
Quando utilizado sobre HTTP, dificilmente é bloqueado por proxies e firewalls.
Permite o uso de diferentes tipos de protocolos.
Plataforma independente.
Linguagem independente.

Diversos padrões.
Complexidade dos padrões.
Performance.
Mensagens podem ficar muito extensas, por serem codificadas com XML

Tabela 03: Pontos positivos e negativos com SOAP.

Fazendo esta pequena análise, chegamos á conclusão de que ambas as soluções são úteis, e a utilização de cada uma depende do contexto em que será aplicada.

Referências (Links):

[Parley] A Little REST and Relaxation: http://tinyurl.com/cm33t2
Estilo SOAP vs Estilo REST: http://www.ibm.com/developerworks/webservices/library/ws-restvsoap/
Descrevendo Serviços REST com WSDL 2.0: http://www.ibm.com/developerworks/webservices/library/ws-restwsdl/
Bruno Pereira: http://brunopereira.org/2008/05/14/precisamos-de-um-descritor-de-servicos-rest/

XP - Extreme Programming - Embrace Change Summary

2009-04-17T23:52:00.009-03:00

As you may already know, XP is a lightweight methodology created by Kent Beck, for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements.

To help the understand of the basis, i'm providing a summary and a mind map of the book eXtreme Programming - Embrace Change, by Kent Beck, as you can see below. Enjoy it!

Figure 1: Extreme Programming Mind Map

XP - Embrace Change is a small book, quite fast and easy to read, it took me only two days to finish it.
As Kent Beck said "XP is a philosophy of software development based on the values of communication, feedback, simplicity, courage, and respect."

The Basic Problem

Software development fails to deliver, and fails to deliver value. This failure behind software development has a huge economic and human impact. So it was the reason to find ways to develop software.

First recognize risks and try to address it applying some XP practices, like short release cycles to limit scope, one to four week iterations of features requests from customer, it will give you a fine-grained feedback about progress.
Economics of Software Development

Create a strategy for maximizing the economic value of the project, spending less, earning more (depends strategy), spending later and earning sooner, increase probability that the project will stay alive.

In projects we have to control five variables: cost, time, quality and scope, like PMBoK scope is the best way to achieve control. KEEP FOCUS ON SCOPE.
Cost of Change

The cost of changing a program rises exponentially over time. Figura 2 shows that the longer it takes you to find a defect then on average the more expensive it is to address.

Figure 2 - Cost of Change [Scott W. Ambler, 2006]

To overtake problems related to cost of change, after years of production some factors became clear like a simple design, intensive use of automated tests, refactoring code and design, incremental design, continuous integration.
Learning to drive.

Everything in software changes. requirements, design, business, technology, team members change. The problem
isn't change, the problem, rather, is the inability to cope with change when it comes.

Learn to control the development of software by making many small adjustments, not by making a few large adjustments, kind of like driving a car.

The driver of a software project is the customer. If the software doesn't do what they want it to do,
you have failed. Of course, they don't know exactly what the software should do. That's why
software development is like steering, not like getting the car pointed straight down the road. Our
job as programmers is to give the customer a steering wheel and give them feedback about
exactly where we are on the road.

XP Values

Communication: Ensured an effective comunication of your team and your organization core values.
Simplicity: Search for simple solutions.
Feedback: Work with your customers at your side, seat the team together.
Courage: Throw code possible whenever itŽs possible (keeping your code simple). Courage to change, to assume your faults.

PUT ALL THESE VALUES IN PRACTICE.

The Four Basic Activities

Coding: Code is the one artifact that development absolutely cannot live without, it gives you a chance to communicate clearly and concisely.
Testing: Writing every test you can imagine.
Listening: Learn to listen your customer, he knows about the business not you.
Designing: Good design ensures that every piece of logic in the system has one and only one home.

Figure 3 - XP Overview.

The Practices

Primary Practices
------------------------
-Integration

Ten minute build: Automatically build the whole system and run all of the tests in ten minutes.
Continuous integration: Integrate and test changes after no more than a couple of hours.

-Whole Team: Create cross-functional teams. Create a team with all the skills necessary for the project to succeed.
-Programming

Test-First Programming: [TDD] Test -> Code -> Refactor
Incremental Design: Keep the design investment in proportion to the needs of the system.
Pair Programming: Help to:

Keep each other on task.
Brainstorm refinements to the system.
Clarify ideas.
Lower frustration.
Hold each other accountable

-Energized Work: Take care and respect yourself.

-Planning

Weekly Cycle: Plan work a week at a time, have meeting at the beginning of every week. During meetings, review progress, ask your customer to pick some stories to implement and break stories into tasks.
Monthly Cycle: Plan work quarter at a time, Identify bottlenecks, Initiate repairs, Plan the theme, pick the stories.
Stories: Write the stories on index cards and put them on a wall.
Slack: Include some minor tasks that can be dropped if you get behind in your plan.

The Planning Game:

List the items of work that may need to be done.
Estimate the items.
Set a budget for the planning cycle.
Agree on the work that needs to be done within the budget. As you negotiate, don't change the estimates or the budget.

Corollary Practices
--------------------------

-Business Negociated Scope Contract: Try a sequence of short contracts instead of one long one.

Pay-per-use: Charge for every time the system is used.
Daily Deployment: Put new software into production every night.

-Incremental Deployment: Find a little piece of functionality and deploy it.
-Programming

Single Code Base: Keep only one code stream.
Code & Tests: Mantain Code and tests as permanent artifacts.
Shared Code: Anyone on the team can improve any part of the system at any time.

-Root Cause Analysis: Eliminate defect and its cause. To find the Root cause, apply Taiichi Ohno's exercise, called "Five Whys":

Why did we miss this defect?
Why didn't we know?
Why isn't she part of the team?
Why doesn't anyone else know how?
Why isn't it a management priority?

-Real Customer Involvement: Put your customer at your side.
-Team

Team Continuity: Keep effective teams together.
Shrinking Teams: Lean Thinking, reduce the size.

If you like it, buy the book here..

Diamond Powder for NetBeans

2009-03-23T14:45:00.008-03:00

Last year, i have created a NetBeans plugin to an interesting framework, called Diamond Powder, it was developed by a friend of mine, Renato Bellia .
To explain what Diamond Powder is, i´ve extracted a briefly introduction from his blog,

What is it ?

It's a Java ME framework to quickly build data collector forms. Further, it is able to manage the persistence of collected data into RMS records.

Data Collector ?

It is about user input.

Suppose you develop a MIDP application that helps car drivers to maintain records about fuel consume in his/her car: The driver stops by at the gas station and gets his mobile device to take note about odometer value, supplied fuel amount , price of fuel, gas station name, and the current date. Later on the driver needs to recover such data. This is a data collector, and Diamond Powder can help you to do so.

Your MIDP application could go further, doing some math with such data, plotting charts, sending it over the internet and the like, but this is up to you.

How does it work ?

Read this step-by-step and the glossary bellow:

Define a Schema
Create a Collector suppling with a display, a schema and a flow name
Add regular LCDUI commands to the collector

at least an OK Command, and a BACK Command
other Commands can be provided

Swicht the MIDlet display to the Collector
At the end of Colletor´s job you may persist collected data with a StorageManager.

Glossary:

term	definition
Schema	A Hashtable that describes the data collector fields, and its organization. A schema contains a name, a version number, and at least one Flow.
Flow	A sequence pages that the application user can browse through.
Page	A top level field container, to display to the user, as a data collector step. Can be reused among flows. Can be associated with a help screen.
Field	Regular LCDUI items: StringItem, TextField, DateField, ChoiceGroup + Filter : a special component to deal with huge ChoiceGroups
Collector	A collector manages the display of a Flow of Pages, and gathers all user input. It extends LCDUI Form.
StorageManager	It is the Diamond Powder persistence component. It helps to preserve user input data gathered by a Collector into RMS records. It also helps to restore a Collector with previously saved RMS records.

NetBeans Plugin

Now, it´s time to talk about my collaboration in this project, if you get a look at this framework, you will realize that it simplifies a lot the development of a data collector on java me.

On the other hand, the heart of the framework, the "Schema", as stated in the glossary, it is a Hashtable that describes the data collector fields, flow, name and version of your application. Let´s see on listing 1, a snippet of the schema code from the hello world example, extracted from diamond powder blog.

public Hashtable getSchema() {
Hashtable schema = new Hashtable();

//schema declaration: name;version
schema.put("schema", "fuelControl;2");
//flow declaration: page1;page2;...
schema.put("flow.basicRecord", "numbers;extra");
//page declaration: title;field1;field2;...
schema.put("page.numbers", "The Numbers;date;odometer;fuelAmount;fuelPrice");
schema.put("page.extra", "Gas Station;gasStationName;gasStationBrand");
//help for page: help text
schema.put("help.numbers", "Enter the odometer mark, the supplied fuel amount and the fuel price");
schema.put("help.extra", "Enter the gas station name and brand");

//text field declaration: field type;label;size;mask
schema.put("field.odometer","textfield;odometer;6;numeric");
schema.put("field.fuelAmount","textfield;fuel amount;5;decimal");
schema.put("field.fuelPrice","textfield;fuel price;5;decimal");
// dateField;label;{date|time|date_time}"
schema.put("field.date","datefield;when;date_time");
schema.put("field.gasStationName","textfield;gas station;40;initial_caps_word");

//choice gorup declaration: field type;label;list model;mode
schema.put("field.gasStationBrand",
"choicegroup;brand;allBrands;exclusive");
//list model declaration: value1;label1;value2;label2;...
schema.put("listmodel.allBrands",
"999;undefined;1;Atlantic;2;Chevron;3;Esso;4;Texaco");

return schema;
}

Listing 1: Schema method example.

As you can see in the example, it can be a problem if you want a more complex application, as your schema evolves it can became inconvenient and error-prone, as you add more fields, or even new pages.
Diamond Powder for NetBeans it´s a plugin, that comes to fill this gap, and helps to create a Schema code, avoiding spelling error in variable names. Now let´s see how to install it.

Download and Installation
To install Diamond Powder for NetBeans, you can visit plugin Portal on NetBeans website, or you can download it directly from java.net site project. The easiest way to download it, is directly from NetBeans,
To install DP from NetBeans, select "Tools > Plugins", open the Setting category and click Add button, in Name field enter "Diamond Powder", and URL enter "https://diamond-powder.dev.java.net/files/documents/9072/108868/updates.xml", and click OK to create a new Update Center source.

Figure 1: Configuration of Update Centers.

Now, to install the plugin, select "Available Plugins" category and install the Diamond Powder plugin, during instalation it will generate a warning, stating that the module is not signed, but it´s ok..

Generating the Schema
There are two ways to create a schema, creating a new file, selecting "New File > MIDP > Diamond Powder - Schema Generator" from a Java ME Project, or you can invoke Diamond Powder wizard from the source code editor, selecting menu popup "Refactor > Diamond Powder - Schema Generator"..

Figure 2: Creating a new Schema file

Start by creating a Diamond Powder Schema file, as shown in Figure 3. Let´s create the schema defined in listing 1, so name the schema "fuelControl", set version 2 and click next to go the panel shown in Figure 4:

Figure 3: Naming the Schema file.

Here we can define our application fields, , let´s define the odometer, fuelAmount, fuelPrice, date, gasStationName and gasStationBrand. Note, that for gastStationBrand is a choicegroup field, to define our list values, click the Editor button, and create the list model defined in Figure 5.

Figure 4: Fields Configuration

Enter "allBrands" to List Model and click New Button, to include a value to the allBrands list model, select it in the list and click Add button, to cancel an item just click cancel, and to finish it, close the window.

Figure 5: List Model editor.

In the Pages Configuration step, let´s create our pages number and extra adding the related fields and entering the properly information like page name, title and help, like Figure 6.

Figure 6: Pages Configuration.

Click Next to our final step, now we going to define the sequence pages that our application will browse through. Enter basicRecord for Flow Name, and add the two pages created earlier (Figure 7).
Check the "Save to File?" option and click browser, this option will persist all fields created to an user defined file.

Figure 7: Flow Definition.

Note: You can retrieve these values, loading the file in the Fields Configuration step (see Figure 4).

Click Finish to generate the schema class. After generation, you should see the Java class, Schema, in the hello.schema package.

References:
Diamond Powder (java.net): https://diamond-powder.dev.java.net/
Diamond Powder Blog: http://diamond-powder.blogspot.com/
NetBeans Plugin: http://plugins.netbeans.org/PluginPortal/faces/PluginDetailPage.jsp?pluginid=17094
NetBeans: http://www.netbeans.org/

Try it !!

[Profissão Java] Como me dei bem com Java

2009-03-19T23:56:00.007-03:00

No dia 07/03 ocorreu nas instalações da Faculdade Anhembi Morumbi, o evento Profissão Java, promovido pela Globalcode. Tive o prazer de participar deste encontro, ver grandes amigos, e contar um pouco da minha trajetória ..

Como sempre acontece nos eventos da Globalcode, o clima estava super bacana, a platéia estava bem animada, o pessoal bem interessado, percebi que o público, era um público jovem, que estão buscando conhecimento, e isto é muito importante.

Quando fui convidado para participar do quadro "Como me dei bem com Java", a primeira coisa que pensei foi "Puxa, mas será que me dei bem com Java ?", pois logo vem a minha mente os problemas cotidianos, e tal,.. não sei se me dei bem, mas graças a Deus consegui até o presente momento atingir minhas metas e objetivos profissionais. E junto com o crescimento profissional, vem as responsabilidades, e com certeza, para se dar bem em alguma coisa, é preciso ter maturidade e gostar muito do que faz, e nada melhor do que a experiência para alcançar a maturidade.

É assim que aconteceu com as metodologias de desenvolvimento, é assim que aconteceu com as linguagens de programação, é assim que aconteceu com as grandes empresas, com os grandes projetos, enfim, é assim que acontece na nossa vida..

Quando estamos iniciando a nossa carreira, são muitas as dificuldades que encontramos, a principio elas são técnicas, depois percebemos que conforme o tempo passa, não basta apenas o técnico, temos que ter outras habilidades para nos dar bem em uma empresa. Como:

Foco.
Entendimento do negócio.
Domínio das ferramentas.
Bom relacionamento com o cliente, ou entender o cliente (tudo bem, concordo que isto é uma arte).
Comprometimento.
Responsabilidade.
Ser auto-didata.

Na minha palestra, procurei dar várias dicas e orientações para os que estão iniciando e para os mais experientes que que querem progredir seus conhecimentos.

Nos slides abaixo mostro os passos necessários, onde deixei grandes dicas de livros, sites, feeds, etc... tipo um roadmap para o sucesso.

Como me dei bem com Java

View more presentations from wrsantos.

Basicamente, os passos que listei seguem a seguinte ordem, não necessariamente desse jeito, para a apresentação preferi fazer algo do tipo "Como você se dar bem com Java" ;). Então vamos lá:

1º Passo: Treinamentos

Para quem está começando, é super importante fazer treinamentos, por mais auto didata que você seja, o desafio é grande, e a curva se torna menor. Talvez compense mais você pagar por um bom treinamento (no meu caso fiz as 3 academias da Globalcode), do que tentar aprender tudo sozinho.

2º Passo: Certificações

Após fazer os treinamentos, se estes forem focados no core java (Java SE), e o desejo de ingressar no mercado de trabalho é grande, então, recomendo as certificações, invista em certificações, pois o investimento não é alto quanto uma faculdade e o retorno é rápido, é desejável que o estudante esteja cursando nível superior.

3º Passo: Livros Essenciais

Tendo conhecimento em Java e certicação, que tal aumentar o seu conhecimento? Segue uma lista de livros básicos em qualquer acervo de um programador.

Effective Java 2º Edition - Esse é um clássico, todo desenvolvedor tem a obrigação de ler este livro.
Java Concurrency in Practice - Com o advento de super processadores multi core, é conhecimento em Threads é um grande diferencial.
Todos os livros de Padrões de Projeto.
Patterns of Enterprise Application Architecture - Clássico da arquitetura de software, pelo tio Fowler, já ouviu falar de Domain Model, Active Record ?
Design Patterns - Elements of reusable OO Software - GoF, este não precisa de maiores comentários, porém, os exemplos estão em C++, se não for sua praia ou não quiser se arriscar, tente Head First - Design Patterns.
Core J2EE Patterns - Tá certo que grande parte dos padrões perdeu o sentido, pois muitos destes padrões os frameworks de hoje em dia já resolvem, mas ainda assim é uma ótima leitura.
Agile Software Development - Este livro também é um pouco antigo, mas é uma ótima referência, pois Robert C. Martin propõe o uso dos padrões em um ambiente ágil.
The Pragmatic Programmer - Ótimas dicas, para se tornar um ótimo programador.

4º Passo: Eventos:

Sempre que tiver a oportunidade de ir a algum evento, vá !!! Mesmo que te chamem de nerd, nos eventos você conhece novas pessoas, que passam ou passaram pelos mesmos problemas que você.
É uma chance de fazer network, trocar experiências, e conhecer novas tecnologias e tendências.

5º Passo: Por dentro das últimas.

Acesse os sites "quentes" de tecnologia, e seja o primeiro a comentar sobre novas tecnologias na sua turma.

InfoQ - http://www.infoq.com/
The Server Side - http://www.theserverside.com/
DZone Java - http://www.dzone.com/
Java Sun - http://java.sun.com/
java.net - http://www.java.net/
NetFeijão Brazil - http://netfeijao.blogspot.com/

6º Passo: Open Source.

Esse é o mais importante, pois é aqui que você vai colocar em prática tudo o que você aprendeu.
Participe de projetos open, entre no site java.net existem projetos de grande expressão, inclusive o Open JDK, GlassFish, e diversos projetos menores, além de aprender com os melhores desenvolvedores do mercado, é uma ótima chance de fazer Networking.

7º Outras dicas: Conhece outras áreas da sua empresa

Aprenda um pouco a área de infra-estrutura da sua empresa, as vezes ao falarmos de projeto, somente pensamos no bitcode, lembre-se que para suportar tudo isto, existem servidores, load balancing, memória, disco, cpu, etc. .. procure conhecer um pouco áreas como:

Rede
Telecomunicações
Sistemas Operacionais
Banco de Dados
Segurança

Lembre-se que por trás de um grande sistema, existe uma grande infra-estrutura.

8º Outras dicas 2: Super Feeds.

Feeds, Se você conhece Google Reader, ótimo, senão, conheça, e adicione os seguintes feeds na sua lista.

Java Posse: http://feeds.feedburner.com/javaposse
Java Specialists: http://www.javaspecialists.eu/archive/tjsn.rss
O'Reilly News: http://feeds2.feedburner.com/oreilly/java?format=rss2
Core Java: http://blogs.sun.com/CoreJavaTechTips/feed/entries/atom
Martin Fowler: http://martinfowler.com/bliki/bliki.rss
Agile: http://leadinganswers.typepad.com/leading_answers/atom.xml
Artima: http://www.artima.com/spotlight/feeds/spotlight.rss
DZone Java: http://www.dzone.com/links/feed/frontpage/java/rss.xml

Deixo aqui os meus parabéns para a equipe da Globalcode, que vem trabalhando à anos com o projeto Open 4 Education, realizando eventos de altíssima qualidade, mini cursos, treinamentos, projetos, e o melhor, é tudo de GRAÇA!!

Bom, acho que é isso aí, com tudo isso dá para ganhar algumas horinhas..

Diversão garantida !!!!

Yahoo! Hack Day 2008 Brasil - Bridging The Gap

2008-11-11T23:51:00.018-02:00

In this weekend, we have celebrated the first Yahoo! Open Hack in Brazil, it was a great party in fact, the lunch was great, people were taking there time and having fun !!

I can consider myself a luck guy, i was invited to join the Globalcode Team, with my friends Vinicius Senger, Yara Senger, Eder Magalhães, Rafael Nunes, Pedro Germano, and a couple of Globalcode classmates =) ..

Caption: NetBeans plugin presentation

We have divided the work into team groups and as a result we have produced FOUR incredible hacks, yes man, i said four great hacks.. See below:
---------------------------------------------

NetBeans Plugin for Yahoo! Blueprint
JSF Renderkit for Yahoo! Blueprint
Mobile Planning Poker for distributed Teams
Supercrud Mashup for Flickr

Caption: Eder presenting the Planning poker mobile

Obviously, my participation was related to the NetBeans plugin development =), it provides a template for Yahoo Blueprint Web Project, a sample application for Yahoo Blueprint, a JBlueprint librarie that encapsulates the Yahoo! Blueprint' API components (developed by Eder Magalhães), some Help Documents, an Update Center and the Developers Guide pdf file inside NetBeans.. =)

Caption: Award on "Bridging the Gap" Category

Our subject wasn't the prize only, our real intention was to build something useful for Java Developers, and make the work with Yahoo APIs easier with the NetBeans plugin and JSF Renderkit, we are planning open the code on java.net soon and attract new developers to this great platform. so stay tunned for more details !!!

Caption: Globalcode "Super" Team

Caption: Globalcode Team and some friends from São Carlos

Congratulations for all the winners. It’s really amazing to see these great and wonderful work .. you are the best !!

See more details at Yahoo! Developer Network blog by Chris Heilmann

Caption: NetBeans Plugin Presentation

One of the best moments, was the Puff Hacking Video,, see for yourself

Puff Hacking from fczuardi on Vimeo.

Cheers, and we see you again next year !!!!

Evento InfoQ Brasil

2008-11-09T21:43:00.008-02:00

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 !!!

Parabéns NetBeans !!!!

2008-10-21T23:03:00.004-02:00

Como muitos já sabem o NetBeans está completando 10 anos de vida, e como homenagem, cantamos parabéns em grupo na época do Sun Tech Days.

Segue o mico, quer dizer o vídeo.

No vídeo gravado na churrascaria Jardineira Grill, estão presentes da esquerda para a direita, Renato Bellia e sua esposa, a esposa de um dos meus amigos, logo atrás dela eu e minha esposa, ao lado dela se encontra a minha grande amiga Janice Campbell, atrás dela, Jefferson Prestes e Michel Graciano, no centro Marcelo Castellani (de jaqueta preta), Mauricio "Maltron" Leal, atrás dele Vinicius Senger e Yara Senger, atrás deles, está Greg Sporar, e mais dois gringos da Sun, e logo após a esposa do Bruno com suas lindas filhas, atrás delas se encontra Henrique Meira e seu colega, e por último o JavaMan.

Fonte do Vídeo: http://www.netbeans.tv/on-the-road/Brazilian-Birthday-Song-400/

Outra dessa só daqui a 10 anos... =)

PARABÉNS NETBEANS !!!

Seja Bem Vindo InfoQ Brasil

2008-10-20T23:39:00.006-02:00

Agora está confirmado, e no dia 01 de Novembro já tem uma festa marcada, a Fratech realizará o evento de Lançamento do portal InfoQ Brasil.

Para quem não conhece, o site InfoQ criado e fundado por Floyd Marinescu, o mesmo criador do theserverside, é considerado um dos maiores portais do mundo sobre tecnologia, com diversos artigos técnicos de altíssima qualidade, com material criado por personalidades como Martin Fowler, Joshua Bloch, está chegando ao Brasil com tudo.
E para começar em grande estilo, no dia primeiro será realizado a festa de lançamento no estilo workshop.

Nesse evento teremos profissionais consagrados no mercado falando sobre os tópicos mais importantes abordados no portal. A grade irá abordar assuntos como Java, .NET, SOA, Ruby, Agile e Arquitetura. Todas as palestras terão um formato de painel, expondo o que há de mais recente em cada Queue. No evento irei falar sobre a Queue Architecture.

A vinda da InfoQ não seria possível sem os esforços da Fratech, em especial do Felipe Rodrigues, e o Manoel Pimentel (Visão Ágil), e de todos os editores, de altíssima capacitação técnica, que tem feito o melhor para traduzir o conteúdo do portal para o Português. Sem dúvida para mim é um orgulho participar deste grupo.

Mais informações:

Fratech: http://www.fratech.net/model/event!show.act?event.id=26

Saúde e Sucesso !!!

SCSNI Study Group - Netbeans IDE Certification Exam

2008-10-18T10:28:00.004-03:00

If you don´t know already, and to celebrate 10th NetBeans Birthday yeaahhh, Sun is planning to release a new certification for NetBeans IDE (Beta), if you are interested and would like to know more about it, or you are just looking for material to study, take a look at the SCSNI Study Group, the first study group to this certification, it has a plenty of related stuff.

You can help to increase the group providing mocks, articles, or even changing the site, if you wanna help, please let me know mailling me at wrsconsulting@gmail.com

As a beta tester, you officially test the test and will be able to provide Sun with valuable comments and technical feedback about the Netbeans IDE questions. The Sun beta exam counts towards official Sun Certified Specialist Netbeans IDE (SCSNI) Certification!

Exam Testing Objectives

1.1 Demonstrate the ability to configure the functionality available in the IDE, including using enabling and disabling functionality and using the Plugin Manager.
1.2 Explain the purpose of the user directory and the netbeans.conf file and how these can be used to configure the IDE.
1.3 Demonstrate the ability to work with servers in the IDE, such as registering new server instances and stopping and starting servers.
1.4 Describe how to integrate external libraries in the IDE and use them in coding and debugging your project.
1.5 Demonstrate knowledge of working with databases in the IDE, including registering new database connections and tables running SQL scripts.
1.6 Describe how to integrate and use different versions of the JDK in the IDE for coding, debugging, and viewing Javadoc documentation.

Section 2: Project Setup
- 2.1 Describe the characteristics and uses of a free-form project.
- 2.2 Demonstrate the ability to work with version control systems and the IDE. (Which VCS's are available, which ones you need an external client for, how to pull sources out of a repository, view changes, and check them back in).
- 2.3 Describe the ways in which you can change the build process for a standard project, such as configuring project properties and modifying the project's Ant build script.
- 2.4 Configure your project to compile against and run on a specific version of the JDK.
Section 3: Java SE Development
- 3.1 Demonstrate the ability to create NetBeans projects from the source code of an existing Java SE program.
- 3.2 Describe how to manage the classpath of a Java SE project, including maintaining a separate classpath for compiling and debugging.
- 3.3 Demonstrate the knowledge of the NetBeans GUI Builder and the ability to lay out and hook up basic forms using it.
- 3.4 Demonstrate the ability to package and distribute a built Java Desktop project for use by another user.
Section 4: Java EE Web Development
- 4.1 Describe how to create a NetBeans project from the source code of an existing Web application.
- 4.2 Distinguish between a visual web application and web application.
- 4.3 Demonstrate knowledge of which web frameworks are available in NetBeans IDE and how they are added to and used in a web application.
- 4.4 Describe how to monitor HTTP requests when running a web application.
- 4.5 Demonstrate a knowledge of basic tasks related to building and deploying web applications to a server, such as changing the target server and undeploying an application.
Section 5: Editing
- 5.1 Describe the purpose and uses of refactoring and demonstrate the ability to perform basic refactoring on Java source code.
- 5.2 Describe how to use the Options window to change the default appearance and behavior of the Source Editor.
- 5.3 Describe the ways that the IDE highlights errors in source code and the tools the IDE offers for correcting those errors.
- 5.4 Demonstrate the ability to use editor hints, such as implementing all the methods for an implemented interface.
- 5.5 Demonstrate the ability to use live code templates such as automatic generation of constructors, try/catch loops, and getters and setters.
Section 6: Testing, Profiling, and Debugging
- 6.1 Demonstrate the ability to work with JUnit tests in the IDE, such as creating JUnit tests and interpreting JUnit test output.
- 6.2 Describe how to debug a local (desktop) application, including setting breakpoints and stepping through code.
- 6.3 Describe the difference between local and remote debugging and describe how to debug a remote (web) application.
- 6.4 Describe the purpose of profiling applications and how to profile a local desktop application in the IDE.

References:

Official Site: http://www.sun.com/training/certification/netbeans.html
Study Group: http://sites.google.com/site/netbeansscsni/
NetBeans 10th Birthday: http://www.netbeans.org/birthday/logos.html

NetBeans Rocks, The only IDE you need !!!

[Resumo Executivo] Evento Smart SOA 2008 IBM

2008-10-15T21:34:00.001-03:00

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 !!!

Estimativas Ágeis - Planning Poker

2008-10-01T18:31:00.001-03:00

Em projetos de software tradicionais, (leia-se não ágeis), geralmente fazer estimativa é algo muito chato, e que provavelmente será feito por apenas uma pessoa, que na maioria das vezes essa pessoa é o gerente de projeto, ou o líder da equipe, que utiliza métodos tradicionais para medir uma atividade com análise de ponto de função, ou por linhas de código, etc... mas acontece que quase sempre essa pessoa não conhece a fundo o negócio e as dificuldades técnicas de se implementar uma certa funcionalidade.

O que acaba gerando problemas no decorrer do projeto, pelo fato do analista de negócio (quando tem) não ter previsto uma funcionalidade adicional, ou uma regra de negócio imprescindível para o negócio.

Nesta altura de campeonato, quanto este tipo de situação acontece, geralmente o projeto já esta em um estágio avançado no desenvolvimento, e ATRASADO.. o cliente está puto,,, e sempre quem acaba levando a culpa é o incompetente do desenvolvedor.

Se você já se sentiu familiarizado com este triste relato, pois bem, não fique triste, pois isto já aconteceu comigo e acontece com milhares de pessoas nos dias atuais...

Pois bem, existe solução para este problema?

Sim, existe, se olharmos para alguns dos príncipios ágeis, conforme segue:

"Business people and developers must work together daily throughout the project. "

Traduzindo, quer dizer algo como "Analistas de negócio e desenvolvedores devem trabalhar juntos DIARIAMENTE no decorrer do projeto".

"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. "

Traduzindo este também,

“O método mais eficiente e efetivo de obter informação para o time de desenvolvimento é na conversa cara-a-cara."

"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. "

E por último..

“Mudanças de requisitos são bem vindas, mesmo em um estágio avançado no desenvolvimento. Processos ágeis alinham as mudanças para vantagem competitiva do cliente."

Uma estimativa bem feita durante a fase inicial do projeto, reduz muito as chances de você ter dores de cabeça no futuro.

Ok, você está se perguntando, "Mas isto não respondeu a pergunta !!!", como eu posso melhorar as estimativas no inicio de um projeto ou de uma nova iteração ???

Existe um método ágil para estimativas, chamada de Planning Poker, esse método foi descrito inicialmente por James Grenning em 2002 e depois popularizado por Mike Cohn no seu livro Agile Estimating and Planning,, essa técnica é muito conhecido em XP.

Para "jogar" o Planning Poker precisamos apenas de uma lista de backlog e um baralho. E o baralho, geralmente composto por cartas que possuem uma seqüência fibonaci ou similar (0, ½, 1, 2, 3, 5, 8, 13, 21, 34, 50, 80 ,100, ?) e uma carta opcional com um sinal de interrogação.

Por que utilizar esta seqüência, e não um conjunto de números naturais (0,1,2,3,4,5,6,7,etc...) ?

Boa pergunta, mas vou responder com outra pergunta, você consegue distinguir o número 13 do número 14? Fica mais fácil você ter uma noção de separação de complexidade, quando você trabalha com números em uma seqüência fibonaci, imagine que para cada tarefa, quando você for dar o seu peso, pense que uma tarefa com peso 2, é 2 vezes mais difícil que uma tarefa com peso 1.

Voltando ao PP, para jogar, cada participante, geralmente os membros da equipe de desenvolvimento (programadores, testers, designers, etc..) devem possuir uma seqüência de cartas, e cada funcionalidade da lista de backlog irá corresponder a uma rodada do jogo entre a equipe. Os membros não podem conhecer as cartas uns dos outros até início da rodada.

Para facilitar o entendimento, vou demonstrar um exemplo real, imagine que temos uma lista de backlog conforme a tabela abaixo, apresentada pelo Product Owner, e o mesmo dá explicações relacionadas a cada um dos itens, onde todos os membros discutem para chegar a um entendimento do problema.
Na nossa ambiente, vamo imaginar que temos 5 membros, 3 desenvolvedores (Carlão, Maria, Zeca), um tester (Júlio) e uma designer (Rita) e o Project Manager / SM (Walter). O Product Owner neste momento, já deu uma visão dos itens de backlog e explicou a necessidade do negócio, tirou algumas dúvidas e foi embora..

É importante frizar que os membros do time devem estimar todo o trabalho relacionado ao item do backlog, e não apenas a sua parte especifica.

Antes de iniciar a primeira rodada, o SM inicia a discussão:

Walter (SM): Pessoal, o que vocês acharam dessa user story (100)?, o usuário quer um repositório para armazenas os documentos operacionais da empresa assim, assim, assado, então, vamos votar:

Então, neste momento cada membro da equipe, pega uma carta que acha que corresponde com os Story points e depois que todos escolheram suas cartas, tem inicio a rodada. No nosso exemplo, o resultado foi esse:

Rodada 1:
Perceba que na primeira rodada, tivemos pessoas que votaram 50 (Maria, Julio), duas que votaram 80 (Zeca, Rita), um 21 (Carlão) e um 34 (Walter), neste momento o mediador (geralmente o Scrum Master) questiona os resultados.

Walter (SM): Peraí gente, vamos discutir, esta tendo muita divergência, Rita e Zeca, porque vocês acham que essa atividade tem um peso 80?

Rita (Designer): É por que, fico imaginando o tamanho dessa aplicação, já é uma bagunça hoje a forma que é organizado os documentos, imagina só o trabalho de reclassificar tudo, montar um repositório, modelagem, etc... e chora.. ..

Walter (SM): Huum entendi, e você Zeca.

Zeca (Dev): Concordo com a Maria, imagina a quantidade de trabalho.. e chora mais.. etc..

Walter (SM): Carlão porque você acha que é 21, é tão fácil assim??

Carlão (Dev): Na verdade, olhando na ótica do Zeca e da Rita, o problema me parece ser mais complexo do que pensei,..

Walter (SM): Então, o que vocês acham da gente pesquisar alguma ferramenta open source que nos ajude neste trabalho, como um ECM ??? Estava pensando em algo neste tipo, senão realmente teremos muito trabalho,,,

Júlio (tester): Ok Walter, ótima idéia, mas acho que vamos ter muita customização, e com a estrutura que temos hoje não será nada fácil.. Imagine a quantidade de testes !!!

Walter (SM): Certo, se todos estão de acordo, vamos implantar um ECM, vamos fazer mais uma rodada então...

Nisso, é feito a segunda rodada (Tabela 1), podemos ver que houve um consenso..

Neste exemplo simples, podemos observar que alguns benefícios ficam bem claros:

O Product Owner descreve cada história resumidamente, de forma que todos tem uma idéia do que esta rolando.
A sinergia entre a equipe aumenta, cada for iniciar um Sprint, onde as tarefas estarão bem definidas, os membros do time, terão uma idéia bem definida do que esta sendo feito, do que o seu colega de trabalho esta fazendo.
O risco de erros da estimativa diminui dramaticamente.
As diferenças de opiniões ficam transparentes, de modo que todos passam a discutir estas diferenças.
É possível re-estimar uma user story até que haja um consenso.

Ok, muito legal esta explicação, mas ainda falta algo, qual a relação entre os princípios ágeis citados no início deste artigo com este jogo de cartas?

Bem, respondendo a pergunta, eu diria que tem tudo a ver, quer ver só:

"O método mais eficiente e efetivo de obter informação para o time de desenvolvimento é na conversa cara-a-cara."

Em planning poker todos estão conversando, (quase sempre olho no olho), o que dá transparência ao negócio.

"Analistas de negócio e desenvolvedores devem trabalhar juntos DIARIAMENTE no decorrer do projeto".

Ao fazer o planning poker, estamos discutindo requisitos funcionais e não funcionais, que visam a realização de um desejo do cliente, e geralmente, durate o planning poker está o Product Owner, para tirar todas as dúvidas em relação ao negócio e verificar se está sendo feito o que foi acordado.

E por último..

"Mudanças de requisitos são bem vindas, mesmo em um estágio avançado no desenvolvimento. Processos ágeis alinha as mudanças para vantagem competitiva do cliente."

Isso irá sempre acontecer, sempre haverá novas features/sistemas a serem desenvolvidos, e durante a estimativa podemos discutir de maneira mais técnica, até modelos de arquitetura, pois querendo ou não, a arquitetura/modelo que será desenvolvido o produto tem um forte peso nas user stories. Portanto, a qualidade do código e do modelo é essencial para que as mudanças de requisitos sejam menos "traumáticas".

Estive no Sun Tech Days, e uma palestra que achei interessante foi a "Usando computação social para melhorar a produtividade no seu projeto" da "Java Champion" Fabiane Nardon, onde ela apresentou várias ferramentas para computação social, e uma das ferramentas citadas foi o site "http://www.planningpoker.com/", um site idealizado por Mike Cohn, e propõe uma ferramenta para que time distribuídos façam a estimativa em conjunto, tem algumas coisas a melhorar, mas a idéia é bem bacana..

OBS> Nas fotos acima, a 1º é uma sessão de planning poker no meu ambiente de trabalho, e na segunda foto o PO priorizando e discutindo os itens de Backlog.

Planning poker com certeza é uma ótima prática, e é também uma boa maneira de iniciar no mundo ágil..

Diversão garantida !!!

[JavaEE 6] EJB 3.1 no GlassFish V3 e NetBeans

2008-09-15T15:31:00.011-03:00

Esta semana saiu nas bancas a edição 31 da revista Mundo Java com o título "Futuro do Java Corporativo", com um artigo meu sobre o mesmo tema.
Para quem quer saber o que vai rolar na próxima especificação do Java EE 6, está edição está um prato cheio, portanto compre uma edição e aproveite...
Não vou entrar em muitos detalhes da matéria, mas vou descrever aqui melhor a demo que está na revista, onde apresento uma aplicação utilizando Session Bean da especificação de EJB 3.1 no GlassFish V3.

Instalando o GlassFish V3 e o conteiner EJB

No site do GlassFish baixe o arquivo zip e descompacte em um diretório da sua escolha, a partir deste momento vamos chamar apenas de GLASSFISH_HOME\bin e execute o updatetool (Figura 1).
Na opção available addons, selecione glassfishv3-ejb e clique em Install, esta ação irá instalar o container EJB no Glassfish.

Instalando o plugin GlassFish V3 no NetBeans

Agora inicie o NetBeans (de preferência a versão 6.1 ou 6.5) e instale o plugin do GlassFish V3 para o NetBeans em Ferramentas | Plugins, selecione em plugins disponíveis "Glassfish JavaEE Integration" e clique em instalar.
Após instaldo o plugin, na aba Serviços, adicione um novo servidor, selecione a opção GlassFish V3 e siga os passos apontando o diretório GLASSFISH_HOME de instalação e finalizar.

Vamos explorar agora uma funcionalidade no NetBeans para a criação de CRUD, crie uma nova Aplicação Web na categoria Web e clique em Próximo.
Neste passo digite "DEMO_EJB31" e clique em Próximo, na opção servidores selecione o servidor GlassFish V3 T2 recém instalado e clique em Próximo. No último passo selecione o framework JavaServer Faces e clique em Finalizar.

Agora vamos criar uma aplicação CRUD completa baseada em uma entidade de banco de dados, para isso clique em Arquivo | Novo Arquivo, na categoria Persistence selecione a opção "Classes de entidade do banco de dados" e clique em Próximo.
OBS: Antes de fazer o passo abaixo, inicie o banco de dados Derby na guia Serviços do NetBeans, clique com o botão direito do mouse em Java DB e clique em "Iniciar Servidor".

Neste segundo passo, na lista Fonte de Dados selecione a opção "Nova Fonte de Dados", no campo "Nome JNDI" digite jndi/TesteEJB e na lista "Conexão de banco de dados" selecione o banco "jdbc:derby://localhost:1527/vir" já existente e clique em OK.

Se tudo ocorreu de maneira correta será apresentada uma lista de tabelas disponíveis. Selecione a tabela Employee, clique em Adicionar e em seguida clique em Próximo.

No campo nome do pacote digite br.com.netfeijao.entities e por fim clique no botão "Criar unidade de persistência". Mantenha os valores default clique em Criar e depois clique em Finalizar. Esta ação irá criar a classe persistente Employee no pacote informado.

Agora vamos utilizar um recurso no NetBeans para a criação de um CRUD com páginas JSF baseado em entidades JPA, no caso a classe Employee que acabamos de criar. Acesse o menu Arquivo | Novo Arquivo, na pasta categoria Persistence selecione "Páginas JSF de classes de entidade" e clique em próximo. Adicione a única classe persistente (Employee) existente (ver figura 1), clique em Próximo e a seguir clique em Finalizar.
Execute a aplicação pressionando o botão F6 e faça testes, perceba que o NetBeans criou uma aplicação completa "a lá Ruby on Rails" com apenas alguns cliques.

public class EmployeeController {
private Employee employee = null;
private List employees = null;
@Resource
private UserTransaction utx = null;
@PersistenceUnit(unitName = "DEMO_EJB31PU")
private EntityManagerFactory emf = null;

public EntityManager getEntityManager() {
return emf.createEntityManager();
}
public int batchSize = 5;
private int firstItem = 0;
private int itemCount = -1;

public SelectItem[] getEmployeesAvailableSelectMany() {
return getEmployeesAvailable(false);
}

public SelectItem[] getEmployeesAvailableSelectOne() {
return getEmployeesAvailable(true);
}

private SelectItem[] getEmployeesAvailable(boolean one) {
List allEmployees = getEmployees(true);
int size = one ? allEmployees.size() + 1 : allEmployees.size();
SelectItem[] items = new SelectItem[size];
int i = 0;
if (one) {
items[0] = new SelectItem("", "---");
i++;
}
for (Employee x : allEmployees) {
items[i++] = new SelectItem(x, x.toString());
}
return items;
}

public Employee getEmployee() {
if (employee == null) {
employee = getEmployeeFromRequest();
}
if (employee == null) {
employee = new Employee();
}
return employee;
}

public String listSetup() {
reset(true);
return "employee_list";
}

public String createSetup() {
reset(false);
employee = new Employee();
return "employee_create";
}

public String create() {
EntityManager em = getEntityManager();
try {
utx.begin();
em.persist(employee);
utx.commit();
addSuccessMessage("Employee was successfully created.");
} catch (Exception ex) {
try {
if (findEmployee(employee.getId()) != null) {
addErrorMessage("Employee " + employee + " already exists.");
} else {
ensureAddErrorMessage(ex, "A persistence error occurred.");
}
utx.rollback();
} catch (Exception e) {
ensureAddErrorMessage(e, "An error occurred attempting to roll back the transaction.");
}
return null;
} finally {
em.close();
}
return listSetup();
}

public String detailSetup() {
return scalarSetup("employee_detail");
}

public String editSetup() {
return scalarSetup("employee_edit");
}
..
}

Listagem 1 - Parte da Classe EmployeeController gerado pelo NetBeans

Perceba que o NetBeans gerou o código de persistencia em uma classe controller, vamos melhorar um pouco isto, tirando o código de acesso aos dados e isolando isto em uma classe DAO, depois vamos transformar esta classe em um EJB sem interface,

OBS> Cuidado, o uso de um EJB DAO deve ser restrito, pois dependendo do seu uso, isso pode ser um Anti-Pattern

Vamos criar uma nova classe Java acessando o menu Arquivo | Novo Arquivo. Nomeie a classe como EmployeeDAO no pacote br.com.mundojava.dao. Nesta classe vamos colocar todos os métodos de acesso ao banco utilizados na classe EmployeeController e inclui-los na classe recém criada. Veja parte do código na Listagem 18.

Vamos criar uma nova classe Java acessando o menu Arquivo | Novo Arquivo. Nomeie a classe como EmployeeDAO no pacote br.com.mundojava.dao.
Adicionalmente vamos criar uma classe para tratamento de Exceptions, crie uma classe e nomeie de DatabaseException, na classe DAO vamos encapsular os erros de acesso a banco nesta classe.

Criada a classe DAO, vamos colocar todos os métodos de acesso ao banco utilizados na classe EmployeeController. Feito isto, transforme esta classe EmployeeDAO em um EJB colocando a anotação Stateless em cima da declaração da classe. Veja parte da classe criada na Listagem 2.

@Stateless
public class EmployeeDAO {

public static final int PROCESSADO = 1;
public static final int JA_EXISTE = 2;
public static final int ERRO = 3;

@PersistenceUnit(unitName = "DEMO_EJB31PU")
private EntityManagerFactory emf;

private EntityManager getEntityManager() {
  return emf.createEntityManager();
}

  public Employee getEmployeeFromRequestParam(Object employee) {
    EntityManager em = getEntityManager();
     try{
       Employee o = em.merge((Employee) employee);
       return o;
     } finally {
       em.close();
     }
  } 

  public int create(Employee employee) throws DatabaseException{
    EntityManager em = getEntityManager();
    try {
      em.getTransaction().begin();
      em.persist(employee);
      em.getTransaction().commit();
      return EmployeeDAO.PROCESSADO;
    } catch (Exception ex) {
      try{
       int opt = 0;
       if (getEmployee(employee.getId()) != null) {
         opt = EmployeeDAO.JA_EXISTE;
       } else {
         opt = EmployeeDAO.ERRO;
         throw new DatabaseException("A persistence error occurred.");
       }
       em.getTransaction().rollback();
       return opt;
      }catch(Exception sup){
        throw new DatabaseException("An error occurred attempting to roll back the transaction.");
      } finally {
        em.close();
      }
    }
  }

public void edit(Employee employee) throws DatabaseException {
EntityManager em = getEntityManager();
try {
em.getTransaction().begin();
em.merge(employee);
em.getTransaction().commit();
} catch (Exception ex) {
try {
em.getTransaction().rollback();
throw new DatabaseException(ex.getLocalizedMessage());
} catch (Exception e) {
throw new DatabaseException("An error occurred attempting to roll back the transaction.");
}
} finally {
em.close();
}
}
...
}

Listagem 2 - Parte da classe EmployeeDAO recém criada.

Fica um desafio para o leitor do blog, criar os métodos

public void destroy(Employee employee);
public List getEmployees(boolean all, 
                         int batchSize, 
                         int firstItem); 
public List getEmployees(boolean all,  
                         int batchSize,  
                         int firstItem); 
public Employee getEmployee(Integer id); 
public int getItemCount();

Por fim, na classe EmployeeController vamos fazer algumas alterações para consumir o EJB sem interface. Primeiro declare uma variável do tipo EmployeeDAO, e vamos injetar com a referência do EJB, e troque todas as referências ao código de acesso ao banco para apontar para o nosso EJB DAO, veja como ficou na classe EmployeeController na Listagem 3.

public class EmployeeController {
private Employee employee = null;
private List employees = null;
public int batchSize = 5;
private int firstItem = 0;
private int itemCount = -1;
@EJB
EmployeeDAO dao;

public SelectItem[] getEmployeesAvailableSelectMany() {
return getEmployeesAvailable(false);
}

public SelectItem[] getEmployeesAvailableSelectOne() {
return getEmployeesAvailable(true);
}

private SelectItem[] getEmployeesAvailable(boolean one) {
List allEmployees = getEmployees(true);
int size = one ? allEmployees.size() + 1 : allEmployees.size();
SelectItem[] items = new SelectItem[size];
int i = 0;
if (one) {
items[0] = new SelectItem("", "---");
i++;
}
for (Employee x : allEmployees) {
items[i++] = new SelectItem(x, x.toString());
}
return items;
}

public Employee getEmployee() {
if (employee == null) {
employee = getEmployeeFromRequest();
}
if (employee == null) {
employee = new Employee();
}
return employee;
}

public String listSetup() {
reset(true);
return "employee_list";
}

public String createSetup() {
reset(false);
employee = new Employee();
return "employee_create";
}

public String create() {
int resultado = dao.PROCESSADO;
try {
resultado = dao.create(employee);
if (resultado == dao.PROCESSADO) {
addSuccessMessage("Employee was successfully created.");
} else if (resultado == dao.JA_EXISTE) {
addErrorMessage("Employee " + employee + " already exists.");
}
} catch (Exception ex) {
ensureAddErrorMessage(ex, ex.getLocalizedMessage());
}
return listSetup();
}

public String detailSetup() {
return scalarSetup("employee_detail");
}

public String editSetup() {
return scalarSetup("employee_edit");
}

private String scalarSetup(String destination) {
reset(false);
employee = getEmployeeFromRequest();
if (employee == null) {
String requestEmployeeString = getRequestParameter("jsfcrud.currentEmployee");
addErrorMessage("The employee with id " + requestEmployeeString + " no longer exists.");
String relatedControllerOutcome = relatedControllerOutcome();
if (relatedControllerOutcome != null) {
return relatedControllerOutcome;
}
return listSetup();
}
return destination;
}

public String edit() {
EmployeeConverter converter = new EmployeeConverter();
String employeeString = converter.getAsString(FacesContext.getCurrentInstance(), null, employee);
String currentEmployeeString = getRequestParameter("jsfcrud.currentEmployee");
if (employeeString == null || employeeString.length() == 0 || !employeeString.equals(currentEmployeeString)) {
String outcome = editSetup();
if ("employee_edit".equals(outcome)) {
addErrorMessage("Could not edit employee. Try again.");
}
return outcome;
}
try {
dao.edit(employee);
addSuccessMessage("Employee was successfully updated.");
} catch (DatabaseException ex) {
String msg = ex.getLocalizedMessage();
if (msg != null && msg.length() > 0) {
addErrorMessage(msg);
}else if (getEmployeeFromRequest() == null) {
addErrorMessage("The employee with id " + currentEmployeeString + " no longer exists.");
return listSetup();
} else {
addErrorMessage("A persistence error occurred.");
}
return null;
}
return detailSetup();
}

public String destroy() {
employee = getEmployeeFromRequest();
if (employee == null) {
String currentEmployeeString = getRequestParameter("jsfcrud.currentEmployee");
addErrorMessage("The employee with id " + currentEmployeeString + " no longer exists.");
String relatedControllerOutcome = relatedControllerOutcome();
if (relatedControllerOutcome != null) {
return relatedControllerOutcome;
}
return listSetup();
}
try {
dao.destroy(employee);
addSuccessMessage("Employee was successfully deleted.");
} catch (DatabaseException ex) {
ensureAddErrorMessage(ex, ex.getLocalizedMessage());
return null;
}

String relatedControllerOutcome = relatedControllerOutcome();
if (relatedControllerOutcome != null) {
return relatedControllerOutcome;
}
return listSetup();
}
...
}

Listagem 3 - Classe EmployeeController refatorada para utilizar o EJB DAO sem interface

Perceba que na expressão "@EJB EmployeeDAO dao" estamos referenciando ao EJB, sem interface para atrapalhar, claro que não é possível criar uma instância utilizando a palavra reservada new ainda, na verdade estamos trabalhando com um proxy, mas se quisermos podemos fazer um lookup utilizando JNDI também.
Vou deixar o restante dos métodos para o leitor resolver, é apenas trocar a referencia pela classe dao conforme os métodos acima.

Compile e faça o deploy, rode a aplicação, se tudo deu certo você irá ver a sua aplicação rodando (ver figura 2) com um EJB sem interface, e o melhor, o EJB está dentro de um arquivo .war, já estamos implementando o empacotamento simplificado.

Veja como ficou o empacotamento do nosso projeto na Figura 3.

Para maiores informações sobre o futuro do Java Corporativo, leia a edição 31 da Mundo Java, que ainda traz ótimos artigos como:

EJB 3.1:Conheça as Novidades do Futuro do Java Corporativo.
Autor:Wagner Roberto dos Santos
Grizzly e Comet - Ajax Reverso com Escalabilidade.
Autor: Pedro Cavalero
Usando o Mavem para melhorar a Qualidade dos seus Projetos.
Autor:Márcio Varchavsky
Criando Software mais próximo do Cliente com Domain-Drivgen Design.
Autor:Sérgio Lopes
Setembro: Mês de Java.
Autor:Mauricio Leal
Testes de unidades Avançadas com JMock 2
Autor:Eduardo Guerra
Gerenciamento de Conteúdo Web com OpemCMS -Customização de Sites.
Autor:Rodrigo Cunha de Paiva
Tirando o Máximo dos Interceptors no Struts2.
Autor: José Yoshiriro Ajisaka Ramos
Tendências em Foco:Ganhando com Open Source
Autor:Cezar Taurion
Jogo Rápido
Autor:Charbel Symanski e Rodrigo Barbosa Cesar
Mundo OO: Requisitos Executáveis com FIT
Autor:Rodrigo Yoshima
SOA na Pratica:Iniciando Projetos SOA.
Autor:Ricardo Ferreira

Diversão Garantida !!!

[Just Java 2008] - Considerações

2008-09-14T16:23:00.000-03:00

.
O Just Java, o maior evento independente da comunidade Java no Brasil, rolou nos dias 10, 11 e 12 de Setembro, e mais uma vez tivemos ótimas palestras, eu particularmente participei apenas nos dias 10 e 11, que foram os dias que tive as minhas palestras.

No dia 10 apresentei junto com meu grande amigo e professor Renato Bellia a palestra "Java EE 6/ EJB 3.1 e o Futuro do Java Corporativo", confesso que fiquei bem nervoso durante a apresentação por conta do grande número de pessoas presentes, o auditório estava extremamente lotado, com pessoas de pé e sentadas no chão..

No dia 11 foi dia de apresentar o framework Diamond Powder - Produtividade Open Source para Java ME , desenvolvido pelo Bellia, minha parte na apresentação foi mostrar o plugin que desenvolvi para o NetBeans, onde auxilia a criação do Schema, nesta apresentação fiquei muito mais tranquilo, o público era bem menor (ver foto),, mas o que me deixou muito mais calmo foi o fato de estar atrás de um teclado, mostrando código, as funcionalidades ali, na hora =) ,,,

No mais, foi muito bom conhecer caras como Kohsuke Kawaguchi e Roger Brinkley da Sun, e conheci pessoalmente o Eduardo Guerra da Mundo Java, inclusive tivemos uma ótima conversa com o Kawaguchi sobre o metadados, GlassFish V3, OSGi, entre outras coisas.

E claro, foi ótimo rever os amigos, Mauricio Leal, Bruno Souza, Michel Graciano, Alessandro Lazarotti, Cristian Sanchez, Jefferson Prestes, Carlos Fernando Gonçalves e toda a galera da Globalcode.

O evento como um todo foi muito bom, e mostra a força que tem, parabéns para o Mauricio Leal e o SOUJava que trabalharam muito para trazer a todos um evento com ótimas palestras e uma organização impecável... só mais um comentário, é impressionante ver como a galera ama Java =) heheh,, o evento começou as nove horas da manhã e acabava apenas as oito da noite, só que depois deste horário ainda tinham as muvucas, que acabavam em torno das 21:00 - 21:30, o engraçado foi ver que tinha pessoas tristes por ter acabado a muvuca 21:30, incluvise tem quem sugerisse um happy hour após as muvucas para continuar as discussões.. =) ,,

Brincadeiras a parte, parabéns a todos que fizeram o evento a acontecer, é por essas e outras que a linguagem é a mais utilizada no mundo..

Diversão garantida !!!!

Just Java 2008

2008-08-31T14:53:00.000-03:00

Esta chegando o Just Java 2008, em Setembro no mês do Java a festa do Just Java será em São Paulo nos dias 10, 11 e 12 de Setembro. Será a 7a edição do principal evento da Comunidade Java Brasileira.
Serão 3 dias com várias palestras relacionadas a Java e agora com alguns temas sobre Agile, hora de aprender um pouco mais, rever os amigos e reforçar o Networking.

Eu vou representar no Just Java com duas palestras junto com meu grande amigo Renato Bellia, no dia 10 ás 15:00 hs com a palestra Java EE 6 / EJB 3.1 e o Futuro do Java Corporativo no auditório superior 2, e no dia 11 de Setembro será a vez de falar do framework Diamond Powder - Produtividade OpenSource para JavaME, que é um projeto criado pelo Bellia.

Neste projeto do Diamond Powder, tive a felicidade de participar com o desenvolvimento de um plugin para o NetBeans para facilitar a criação do Schema, que é um Hashtable que descreve o os campos do coletor, as páginas, fluxo de navegação com opção de persistência.
Você que desenvolve aplicativos embarcados vale a pena conhecer este framework!!

Site do Evento: http://www.sucesusp.org.br/justjava2008/
Grade de Palestras: http://soujava.org.br/display/v/Grade+de+Palestras
Diamond Powder no java.net: https://diamond-powder.dev.java.net/
Blog do Diamond Powder: https://diamond-powder.dev.java.net/

Participe, é diversão garantida !