Continuous Integration

Depois de alguns posts sobre assuntos relacionados a Service Oriented Architecture, vou tratar de um assunto muito importante que ultimamente tem recebido atenção, porém ainda é muito negligenciado na maioria das empresas:

Continuous Integration, ou integração contínua, é uma prática de desenvolvimento de software onde os membros da equipe integram seu trabalho frequentemente, geralmente cada desenvolvedor integra ao menos uma vez por dia. Cada integração é verificada por uma ferramenta de build automatizado[1] (incluindo testes) com a finalidade de detectar erros de integração o mais rápido possível, economizando assim o custo de correção nas fases posteriores do projeto, que é muito mais alto.

A partir da definição acima, podemos identificar algumas áreas:

Configuration Management ou Gerência de Configuração;

Software Testing ou Testes de Software;

Build and Integration / Build Management ou Construção e Integração / Gerência de Construção;

(mais…)

Modelo Canônico – Normalização Semântica

Este é o terceiro post sobre Modelo Canônico. A leitura na ordem cronológica é indicada: Mas o que é Modelo Canônico afinal? Parte 1 e Parte 2.

Na Parte 2, foram apresentadas algumas diferenças entre os estilos de modelagem Relacional, Orientada a Objetios e Orientada a Serviços, além de alguns tópicos técnicos e de modelagem do Modelo Canônico. Agora começa a parte mais complexa da modelagem, quando as incompatibilidades técnicas e de padrão de nomenclatura foram resolvidas.

Quanto à semântica, a complexidade começa por esta incompatibilidade não ser facilmente identificada pelos responsáveis pela modelagem. Por exemplo: No sistema A existe a entidade Promoção, no sistema B a entidade Oferta e no sistema C a entidade Campanha. Cada uma tem um conjunto diferente de atributos, porém podem representar o mesmo conceito do ponto de vista do ‘Negócio’. Depois de identificada pode parecer trivial, mas durante o decorrer dos projetos isso normalmente passa desapercebido, principalmente pela ausência de stakeholders.

(mais…)

REST: Padrões e Melhores Práticas

No último JavaOne tive a oportunidade de apresentar, juntamente com o Alessandro Oliveira, alguns padrões do estilo arquitetural REST, que temos aplicado em alguns clientes.

Palestra JavaOne 2012

Nesta palestra apresentamos algumas opções que devem ser consideradas quando se pretende usar este estilo arquitetural, como estratégia de implementação, qual a melhor forma de versionar os recursos, paginação, etc.

Apesar de ser muito importante, o tema Hypermedia não foi abordado, devido à quantidade de conteúdo para uma apresentação de apenas 1 hora.

Criei um tópico sobre a apresentação no SOACloud, fiquem à vontade para discutir o assunto!

Mas o que é Modelo Canônico afinal? – Parte 2

No ultimo post, comentei que o Modelo Canônico seria o modelo de dados universal utilizado pela camada SOA e que sua modelagem difere da modelagem tradicional.

Normalmente primeiro aprendemos a modelar banco de dados relacional, que tem como principal preocupação a normalização dos dados. Mais tarde aprendemos a modelar orientado a objetos, onde a normalização não é tão importante, a  distribuição de responsabilidades, alta coesão e baixo acoplamento são mais importantes. Em SOA, a modelagem muda novamente, agora os dados e comportamento estão separados novamente. Distribuição de responsabilidades, alta coesão e baixo acoplamento continuam importantes, porém a ‘normalização semântica’ dos dados ganha maior força pois o escopo agora é muito maior. Quando falamos de recursos RESTful, a modelagem muda completamente.

Costumo dizer que modelagem é um assunto indigesto, pesado. Digo isso porque leva um tempo para ser digerido, assimilado, e isso só é alcançado através de exercícios, ou seja, só se aprende fazer fazendo! Mas existem algumas ‘dicas’ que podem ajudar a encurtar este caminho.

A parte mais dificil e complexa na modelagem do Modelo Canônico é a ‘normalização semântica’, então vamos deixa-la para o próximo post, começando pela parte técnica:

  • Como estamos falando em SOA e a maioria das implementações utiliza SOAP, a implementação do Modelo Canônico é em XML Schema;
  • Deve ser definida um padrão de nomenclatura. Normalmente é utilizado como em java, UpperCamelCase para os tipos (complexType) e lowerCamelCase para campos (element);
  • Como as entidades do Modelo Canônico são reutilizadas por várias operações, não é possível definir a obrigatoriedade dos campos (elementos). Por este motivo todos os campos devem ser opcionais utilizando o atributo minOccurs="0" e não devem possuir nenhum tipo de restrição, como limite de tamanho;
  • Utilize element para representar os campos, não attributes;
  • Não utilize referência cíclica, mais conhecida como relacionamento bi-direcional. Por exemplo: se a entidade Cliente possui um relacionamento com a entidade ContaCorrente não deve ser criado um relacionamento da entidade ContaCorrente para Cliente. Isso pode gerar problemas de performance e incompatibilidade em alguns clients / ferramentas;

Depois da parte técnica, existem alguns tópicos relacionados a modelagem:

  • Evite criar relacionamentos entre entidades muito independentes. Este tipo de composição pode ser feito na interface do serviço;
  • Eventualmente uma associação é identificada, porém não é necessário que tais informações sejam estruturadas. Neste caso a desnormalização pode ser usada. Por exemplo: a entidade Endereço possui todos os campos do entedereço estruturados, porém para a entidade Nota Fiscal esta normalização não é necessária, podendo ser um único campo texto;
  • Em alguns casos similares ao exemplo acima o tipo de informação de uma determinada entidade muda de acordo com o contexto. Por exemplo para o contexto de faturamento o Cliente possui algumas informações e para o contexto de CRM possui outros. Neste caso a entidade Cliente pode ser ‘quebrada’ de acordo com o domínio;

Modelagem é um assunto complexo e subjetivo. Cada tópico acima pode se extender por vários posts e ainda existem outras considerações a respeito da modelagem de Modelo Canônico que serão tratados no próximo post.

Mas o que é Modelo Canônico afinal?

Nos últimos meses tenho visitado várias empresas atuando como consultor SOA e o Modelo Canônico tem se tornado uma grande fonte de dúvidas e confusões.

Mas antes de falar sobre canônico, vamos voltar em um tópico mais ‘básico’ que acredito ser a origem de parte do problema: a Modelagem. É muito comum encontrar problemas de modelagem mas, tratando-se de serviço, a correção destes problemas torna-se um pouco mais complexa. Tal correção não pode ser encarada como um ‘simples’ refactoring. Ao alterar o contrato de um serviço, todos os seus consumidores podem ser afetados. É aí que outros pontos críticos aparecem:

• são conhecidos todos os consumidores daquele serviço?

› se sim, a informação é confiável?

» se sim, o refactoring cross-sistema é viável técnica e financeiramente?

Como a respostas para as perguntas acima dificilmente são ‘sim’, surgem algumas situações:

• quebra ‘inconsciente’ dos clientes:

› desconhecimento do reaproveitamento do serviço (em vários casos, falta de análise de impacto ou até descaso) desconsideram a alteração de outros clientes;

• aumento na complexidade da lógica:

› cenários não identificados na criação do serviço acabam aumentando drasticamente a complexidade na manutenção e no consumo do serviço, levando a um dos próximos tópicos;

• duplicação da lógica:

› diversos fatores, principalmente o tempo, levam à duplicação do serviço, dificultando a manutenção e o reaproveitamento;

• versionamento do serviço:

› finalmente, o versionamento acaba sendo um último recurso na evolução do serviço. Porém deve ser usado com cuidado e planejamento, pois pode dificultar bastante a manutenção;

Uma vez que a alteração na interface dos serviços é complexa, sua modelagem merece atenção redobrada! Para isso é necessário trabalhar juntamente com a área de negócio, buscando sempre utilizar os mesmos termos para que a nomenclatura dos serviços tenha significado para a área de negócio. O Domain Driven Design proposto por Eric Evans ajuda bastante neste sentido!

Uma vez que os serviços e operações (ou capacidades) foram modelados, os parâmetros das operações precisam ser modelados. Esta modelagem NÃO deve levar em conta a nomenclatura dos sistemas já existentes e sim manter o mesmo critério adotado na modelagem dos serviços*. Neste ponto o Modelo Canônico entra na equação, atuando como uma linguagem universal entre os sistemas envolvidos, facilitando o entendimento dos parâmetros dos serviços.

Respondendo a pergunta do título, uma definição simples de Modelo Canônico seria modelo de dados universal utilizado pela camada SOA.

* Nos próximos posts levantarei pontos que devem ser levados em consideração na modelagem do Modelo Canônico que diferem da modelagem tradicional.

QCon São Paulo 2011

Conforme havia comentado no ultimo post, fui ao QCon São Paulo 2011. Vou comentar um pouco os pontos altos e baixos do evento.

no:sql(br)/v2

Mas antes disso, aproveito para falar de outro evento que está próximo: o nosqlbr, que terá sua segunda edição em um mês, nos dias 21 e 22 de Outubro. Preço promocional até dia 30/set. Maiores informações no site do evento.

Agile Brazil 2012

Agile Brazil 2012

Outro evento que foi divulgado nos últimos dias foi o Agile Brazil, que ano que vem será em São Paulo.

Voltando ao assunto do post; após as boas vindas, o evento começou muito bem com um keynote do Jim Webber onde, de uma forma muito bem humorada, ele comentou sobre um projeto que originalmente utilizaria um middleware e como a Thoughtworks o entregou utilizando uma arquitetura http-centric por uma fração do valor do middleware.

Logo em seguida foi a vez de Sérgio Lopes prender a atenção dos congressistas com seu keynote sobre otimização de sites, mostrando o quão ‘amadores’ nossos sites são com relação à performance. Para isso ele analisou o site de todos os congressistas, os resultados foram alarmantes.

Finalizando os keynotes, Evan Weaver falou algo sobre o twitter que ninguém entendeu/ouviu. Trollagens à parte, este foi o ponto baixo do evento. Não farei críticas não construtivas.

Após o almoço assisti à palestra de Danilo Sato sobre Refatoração. Depois foi a vez da divertida palestra de Scala como alternativa em aplicações puramente java com Alberto Souza e Lucas Cavalcanti. Foi uma palestra básica mostrando o potencial da linguagem Scala para complementar projetos java.

Ainda antes do coffee, assisti uma das melhores palestras do evento (na minha opinião) sobre dívida técnica com Alexandre Freire. Nesta palestra ele explicou a diferença entre débito e dívida técnica e como fazer débitos técnicos planejados para que seu projeto não vá à falência. Gostaria de ter assitido à palestra de Alex Tabor sobre o Peixe Urbano, mas quando eu cheguei ela já estava lotada.

Depois do coffee, assisti à palestra do Jim Webber sobre neo4j, um banco noSQL baseado em grafos ideal para aplicações baseadas em relacionamentos. Mantendo o bom humor da abertura, ele explicou o que são banco de dados noSQL e seus tipos (sem deixar de trollar o pessoal do mongoDB). Para finalizar a parte técnica do dia, Daniel Sobral mostrou exemplos de uso do Akka Framework em java e scala e explicou alguns dos conceitos de utilizados como Actors Model e STM.

Para fechar o primeiro dia, teve uma ‘hora extra’ no bar opção.

Novidades e eventos

Nossa, faz quase um ano que abandonei este blog …

Bom de lá pra cá muita coisa mudou, a mais importante foi que descobri que apesar da resistência no inicio, poucos desenvolvedores java tem facilidade de abandonar as linhas de código, SOA realmente é, e vai ser minha especialidade. Porque? Esse assunto da para um post todo, mas principalmente porque é um assunto que gostei e tem bastante espaço para crescer.

Decidido isso, me aproximei do pessoal da SOA|Expert, assisti muitas aulas, e me tornei instrutor. Foi um grande inicio em um objetivo que tinha desde que sair da faculdade, ministrar aulas.

Além disso, a ultima coisa que havia postado foi que iria ao Encontro Ágil 2010, e acabei não escrevendo nada sobre ele. O Breno Oliveira foi comigo no evento e escreveu um post sobre sua visão.

Depois disso, se não em engano, fui em uma noite ágil na Caelum muito interessante o evento, pena que não pude ir mais vezes.

SOA & Cloud Symposium

SOA & Cloud Symposium

O próximo evento em que fui, foi o 4o SOA & Cloud Symposium, que ocorreu nos dias 27 e 28 de abril de 2011 em Brasilia. Resumindo, foi um evento muito caro e ficou muito abaixo das minhas expectativas.

 The Developers Conference 2011, um evento organizado pela Globalcode

The Developers Conference 2011

Dos dias 6 à 10 de julho ocorreu o TDC2011 em São Paulo, um dos melhores eventos técnicos que já participei e o melhor, a um preço super justo. Não percam o do ano que vem. Para o pessoal de goiânia, o evento esse ano vai ocorrer dia 29 e 30 de Outubro.

Agile Brazil 2011

Agile Brazil 2011

Este ano também ocorreu o Agile Brasil em Fortaleza, não tive a oportunidade de ir, mas assisti a alguns vídeos muito bons do evento!

QConSP 2011

QConSP 2011

Para finalizar, amanha começa o QCon em São Paulo. Falaram muito bem do evento ano passado e este ano comprei na ‘primeira chamada’, economizando assim algumas centenas de reais, sim o evento é bem carinho.

Gerenciando dependências com o Maven

No último post foi criado um projeto a partir do Archetype usando o seguinte comando:

mvn archetype:generate -DinteractiveMode=n -DarchetypeArtifactId=maven-archetype-webapp -Dversion=0.0.1-SNAPSHOT -DgroupId=com.wordpress.felipefirmo -DartifactId=tutorialMaven

Quando este comando for executado pela primeira vez, o Maven fará o download de alguns arquivos necessários para criar seu projeto, dentre eles o jar do JUnit (ver código abaixo). Nas demais vezes em que for executado estes arquivos estarão presentes no repositório local do Maven, não sendo baixados novamente.

Este comando criará dentro da pasta tutorialMaven o arquivo pom.xml e a pasta src. O arquivo pom.xml é o arquivo de configuração do Maven, nele estão configuradas dentre outras coisas as dependências do projeto. A pasta src contém todo o código fonte do projeto, tanto código Java quanto arquivos de configuração.

Para gerenciar as dependências de seu projeto é preciso alterar o arquivo pom.xml, mais especificamente criar ou alterar a tag dependency que fica dentro de dependencies:

<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>

Para cada dependência uma tag dependency será necessária, informando o groupId, artifactId, version e scope da dependência. Creio que o jeito mais fácil de encontrar estas informações seja pelo site http://mvnrepository.com. A titulo de exemplo vamos utilizar o iBatis por ser um caso bem simples.

Pesquisando iBatis no mvnrepository, uma lista de resultados são exibidos. No caso estamos procurando o módulo sqlmap e sabendo que o iBatis é da apache, a dependência correta é: ibatis-sqlmap (foi um dos últimos resultados; essa é a desvantagem deste site, muitos resultados não relacionados são retornados). Clicando na versão desejada, neste caso a ultima versão estável é a 2.3.4.726, a tag dependency do iBatis será exibida, basta copiá-la dentro da tag dependencies.

<dependencies>
...
<dependency>
<groupId>org.apache.ibatis</groupId>
<artifactId>ibatis-sqlmap</artifactId>
<version>2.3.4.726</version>
<scope>compile</scope>
</dependency>
</dependencies>

Depois de copiá-la e utilizar o comando abaixo para compilar, ela será adicionada às dependências do projeto.

mvn clean compile

O parâmetro clean limpará a pasta target e o parâmetro compile criará os arquivos .class na pasta target.

Para finalizar o escopo inicial, falta gerar o portal do projeto. Isso pode ser feito executando o comando abaixo na pasta tutorialMaven:

mvn site

Este comando criará uma pasta site contendo o portal recém gerado dentro da pasta target. A página /tutorialMaven/target/site/dependencies.html por exemplo mostra que o iBatis foi incluído como uma dependência do projeto.

Assim fechamos o escopo inicial proposto mas, como dito anteriormente, este é apenas um guia rápido para quem não conhece o Maven. Vale a pena se aprofundar pois tem muita coisa legal que dá para fazer com ele!

Criando um projeto Maven (usando Archetype)

Bem, já passou da hora de começar a escrever algo aqui. Como disse no primeiro post estou montando toda a estrutura de uma série de projetos JEE e, o Maven é umas das principais ferramentas de apoio para que tudo funcione de maneira mais automatizada e simples para os desenvolvedores.

Não tenho a pretensão de explicar detalhadamente o funcionamento do Maven e sim fazer um guia básico para quem nunca ouviu falar e vai começar um projeto novo. Neste escopo, ele será utilizado para criar o esqueleto do projeto usando Archetype e gerenciar suas dependências, deixando o projeto mais enxuto. Além disso, ele pode ser utilizado para gerar um portal do projeto.

Voltando para a época em que comecei a programar em Java, o Framework padrão para desenvolvimento web era o Struts; já existia o WebWork, mas ainda não era muito aceito pelas empresas. Nessa época, iniciávamos os projetos a partir de um blank_project, que era a estrutura de um projeto Struts já configurado e com todas as dependências. Isso resolvia o problema, mas de uma maneira um tanto quanto amadora.

Além disso, os projetos tendem a ficar desorganizados com o passar do tempo, levando mais de um dia para fazer seu set-up em uma nova máquina, ficando refém de algum desenvolvedor que tenha experiência no projeto e que se lembre do último set-up (que provavelmente foi feito há mais de um ano). Usar corretamente o Maven é o primeiro passo para se evitar isso (em outro post eu falarei sobre integração contínua). Lembrando o que o CV disse no último encontro ágil, se algo é chato, faça-o sempre, assim ele não vai se transformar naquele monstro!

Voltando ao assunto principal, podemos criar um novo projeto através de um Archetype. Considerando que você já instalou e configurou o Maven em sua máquina para criar um projeto web simples basta entrar na pasta em que você deseja criar o projeto e executar o seguinte comando:

mvn archetype:generate -DinteractiveMode=n -DarchetypeArtifactId=maven-archetype-webapp -Dversion=0.0.1-SNAPSHOT -DgroupId=com.wordpress.felipefirmo -DartifactId=tutorialMaven

Onde archetypeArtifactId é o Archetype que você deseja utilizar, groupId é o código do grupo ao qual o projeto pertence, normalmente utilizamos a estrutura de packages (ex.: br.com.empresa) artifactId é o código do projeto, normalmente seu nome e version é a versão do projeto.

Pronto, o Maven fará o download do Archetype, suas dependências e criar o projeto configurado pra você!

Com isso, finalizamos a primeira parte do escopo proposto, que era criar o esqueleto do projeto. Para não ficar muito extenso vou finalizar este post por aqui e, assim que escrever os tutoriais propriamente ditos, posto a referência neste post para facilitar.

Encontro Ágil

Hoje Ontem cedo , foi divulgado pelo twitter oficial do EncontroAgil que o evento será em novembro.

Fui no encontro ano passado e valeu muito a pena, principalmente pelo segundo dia, onde a Jutta Eckstein e Joe Yoder ministraram suas palestras. Este ano o evento vai ter outro formato: vale tudo, menos palestras o.O  … a idéia é deixar o evento mais interativo. Ainda não tem muitos detalhes no site, mas gostaria de ir novamente este ano! Vamos aguardar mais detalhes…

PS.: Eu apareço no filme da home do evento 😛 aos 2:19 min na fila do coffee