Posts

Showing posts with the label arquiteturta

Refactoring como meio e Design como Fim

Image
Ainda é muito comum discussões sobre refactoring . Mas sinceramente acredito que boa parte delas perderam o ponto a muito tempo. Refactoring como o próprio Fowler disse é uma técnica sistemática para reestruturar código sem mudar o seu comportamento. Sempre que escolhemos uma abordagem de design como por exemplo: DBC , TDD , RDD , DDD, etc.. estamos levando a solução através modelos consolidados. Esses modelos tem prós e contras e dependendo da situação um vai ser melhor do que o outro. Eu partircularmente gosto muito do modelo do RDD . Mas como chegamos a um modelo solido e eficaz? O design não nasce pronto, deve ser feito de forma incremental utilizando refactoring por exemplo, mas o refactoring não deveria mudar a semantica, logo precisamos de algo mais que refactoring, nesse caso estamos falando de design incremental. Como fazer um bom Design? Para fazer um bom design é necessário conhecimento do dominio! Sem conhecimento do dominio é impossível fazer um design robusto e sustentáv...

Swing Fácil com Groovy: Como criar seus próprios componentes

Não tenho dúvidas que o desenvolvimento de aplicações desktop com Java tem seu problemas. Não digo apenas pela estrutura de composite do Swing, ou de classes gigantes com muitas responsabilidades como o JFrame. Mas mesmo com todos esses problemas vejo o desenvolvimento de aplicações Swing para Java ainda com viabilidade. Hoje é dia é comodismo desenvolver aplicações para Web. O que acontece é que nem todos os sistemas ou nem todas as funcionalidades dos sistemas podem ser feitas na web, por que? Complexidade do desenvolvimento com JavaScript Consumo de memória do cliente(Browser) Complexidade de tecnologias Ajax VS problemas de uso de Arquiteturas Commet. Falta de bons IDEs e Debuggers para JavaScript Pouca performance na execução de JS devido a sua arvore DOM. Tempo de desenvolvimento e custo de manutenção Quando desenvolvemos com Swing puro por mais nojento que possa ser ainda assim nos livramos de muitos problemas. Vejam que eu não sou contra o desenvolvimento para web, m...

O Papel do Arquiteto de Software

Quando falamos de um projeto desenvolvimento de software que se utilize Java como linguagem de programação é comum ouvir de alguém que você precisa de um arquiteto de software. Na verdade esta necessidade não é única de projeto Java, independente da tecnologia de implementação dependendo da magnitudede seu projeto você vai precisar tanto de um arquitetocomo você precisaria de um analista ou gerente de projetos. Diferente do que muitos pensam arquitetura não significa escolher frameworks, a arquitetura de software vai muito além do que meramente decidir se no projeto vão utilizar Spring ou Hibernate, Struts ou JSF. Mas qual o papel do Arquiteto de Software? Em poucas palavras é dar suporte e participar de todas as decisões técnicas significativas em termos de design e implementação. Em outros termos estamos falando de riscos, a arquitetura serve para mitigar os principais riscos técnicos de um projeto, veja que eu disse os principais ao invés de todos. Se você trabalha com riscos no s...

WebService REST fácil com Groovy e Jersey

Como já disse o Jim Webber o WSDL deve morrer! Não tenho dúvidas de que em termos de produtividade e simplicidade utilizar WS-REST é a melhor solução do que utilizar WS-* . Em 2007 já tinham surgido soluções em Java para implementação de WS-REST como o RESTLet . Hoje após a criação da JSR-311 , que dita como criar um WebService REST em Java existem já alguns frameworks que podemos utilizar além do RESTLet como o Jersey . O Jersey é um framework Java que implementa a JSR-311 além de ser a implementação de referência para essa JSR. Com ele podemos escrever WebServices REST de maneira fácil e rápida utilizando um conjunto de anotações. Você pode publicar um WS-REST utilizando qualquer container como o Glassfish, JBoss, Oracle IAS, ou até mesmo o Tomcat. Mas existe um pequeno servidor chamado de Grizzly . Esse servidor é escrito em Java e prove acesso via HTTP e de forma parcial a API de servlets, mas isso é mais do que suficiente para a escrite e disponibilização de um WS-REST. Vou...

DTO fácil com o Doozer

Image
Um dos patterns mais consolidado e utilizando em outras linguagens além do Java é o Pattern , Layer. Muitos devem ter ouvido falar de aplicações em 3 camadas ou em N camadas . Nesse tipo comum de arquitetura existe a camada de apresentação também chamada de UI e existe a camada de negocio, onde ficam as regras e o processamento em si. Neste modelo arquitetural se faz necessário trafegar objeto s entre essas camadas. Existem diversas formas de realizar essa tarefa. Se você desenvolve utilizando POJOS pode utilizar a técnica mais simples que é passar o próprio POJO entre as camadas. Ao passar o POJO entre as camadas podemos estar expondo detalhes que implementação que não desejamos além de se fazer necessário todo o grafo de dependências do objeto. Em aplicações com remotabilidade, leia-se, EJB , WS-*, WS-REST ou qualquer outra forma de comunicação entre camadas e sistemas, você pode utilizar uma técnica um pouco maios apurada que diminui o acoplamento entre as camadas que é o Pat...

Queries em arquivos de texto com o MetaModel

O MetaModel é um engine para execução de queries para diferentes tipos de fontes de dados. Normalmente realizamos queries em um banco de dados relacional, isso também pode ser feito com o MetaModel. O MetaModel vai além disso e possibilita que efetuemos queries em outros tipos de fontes de dados como por exemplo: Arquivo Texto (CSV) Arquivo MS Excel Arquivo OpenOffice Arquivo XML Banco de dados Tudo isso funcionando através de uma DSL-like escrita em java, onde a syntax é compatível com SQL 99. O framework permite trabalhar com a estrutura do "Banco" seja ele um arquivo Excel, CSV ou banco mesmo. Através do schema podemos obter as tabelas, colunas e tipos de dados da fonte dos dados, mesmo ela sendo um simples arquivo CSV. Apenas pela facilidade e simplicidade que o MetaModel faz isso já uma coisa fantástica! Como eu disse antes, o framework é feito com o padrão SQL 99, isto significa que você pode fazer queries SQL, isso através da DSL em java que ele possui. E...

Mapeamento de DN do LDAP com POJOS usando Spring

Em um post anterior eu introduzi o ApacheDS que é uma excelente solução para LDAP. Agora vou mostrar como é possível mapear atributos do LDAP de forma automática usando anotações. Para você realizar isso é necessário todos os requisitos do exemplo anterior . Vou utilizar a mesma arvore LDAP do post anterior . Muito bem vamos aos códigos! Vamos começar por um simples POJO chamado Pessoa. package com.blogspot.diegopacheco.ldap.pojo; import com.blogspot.diegopacheco.ldap.bind.LdapBinding; /** * Pojo Pessoa. * * @author Diego Pacheco * @since 07/12/2008 */ public class Pessoa { @LdapBinding(dn="uid") private String nome; @LdapBinding(dn="cn") private String cargo; public Pessoa() {} public String getNome() { return nome; } public void setNome(String nome) { this.nome = nome; } public String getCargo() { return cargo; } public void setCargo(String cargo) { this.cargo = cargo; } @Override public String toString() { return "nome: " + nome + ...

Realizando pesquisas com o SpringLDAP no ApacheDS

Image
O ApacheDS é uma solução que prove soluções de diretório totalmente escrita em Java. Neste post vamos aprender a instalar e configurar o ApacheDS, o utilizaremos como serviço de diretórios LDAP e após vamos realizar querys no diretório com o Spring LDAP tudo isso no Windows. O ApacheDS é certificado pelo Open Group como um serviço de diretório LDAP v3. As grandes vantagens de se utilizar o ApacheDS é que com ele conseguimos utilizar triggers, views, stored procedures e queues no mundo do LDAP. Além da possibilidade de colocar o ApacheDS embarcado em outras aplicações como fazemos com o banco Derby por exemplo. Para fcilitar a nossa vida como administradores LDAP podemos utilizar o Studio, que é outra solução muito interessante para administrarmos o ApacheDS, o Studio é uma aplicação escrita com o Eclipse RCP, muito fácil de administrar e pode ser utilizada com qualquer servidor LDAP. LDAP V3 O LDAP é um protocolo para serviços de diretórios. Com ele podemos realizar pesquis...

Apresentação sobre JBoss Drools

Nesta terça-feira passada eu e meus colegas Maicon, Jader e Eduardo. O Drools é um sistema de BRMS que proporciona a posibilidade de expressarmos requisitos em forma de regras de produção. A apresentação mostra algumas das excelentes funcionalidades da ferramenta e no final existe um hands-on, neste existe um exemplo simples de um DSL escrita em português. Utilizei o plugin do Drools para o eclipse, então se você quiser rodar o exemplo terá que importar o projeto no eclipse e utilizar o plugin do Drools para o eclipse . Recursos Apresentação Fontes do Hands-on Dependências Eclipse 3.3 Plugin JBoss Drools org.eclipse.jdt.core.manipulation_1.2.0.v20080603-2000.jar org.eclipse.jdt.core_3.4.0.v_874.jar As bibliotecas do eclipse, você deve copiar para a pasta lib da aplicação de exemplo. Você encontra esses jars no caminho: $eclipse_home \plugins , onde $eclipse_home é a pasta onde você instalou o eclipse. J Boss Drools View SlideShare presentation or Upload your own. (tags: jboss engi...

5 Motivos para você usar REST ao invez de WS-*

Image
No dia 25/01/2002 Alguém se lembra o que aconteceu? Foi o dia em que as Atividades com Web Services iniciaram no W3C . De lá pra cá, muitas coisas aconteceram. Quem já não teve que escrever um Web Service? Foi divertido? Se as suas respostas foram SIM e NÃO continue lendo senão sai do post :) O que ocorre é que existe uma quantidade imensa de especificações WS-* que nem foram implementadas ainda. Existem vários problemas relacionados a questões relativamente simples em um sistema *local*, como por exemplo transação. Outro problema é a complexidade. É muito complexo e pouco produtivo trabalhar com Web Services. Ahh beleza vai vir um engraçadinho dizendo: "Ahh mas tudo pode usar Xfire ou até mesmo o AXIS", eu digo: "ok". Mas o que acontece na outra ponta? E a sua outra aplicação em C++ ou Smalltalk como fica? Mesmo com Xfire ainda assim existe muita complexidade por traís das especificações WS-*, sem falar em um outro problema o XML, e o custo de se fazer o parser ...

Implementação não é nada. Design é tudo!

Quando estamos construindo um sistema OO, a base desse sistema é fundamental. Já é bíblica a frase " O Homem que construiu sua casa sobre a areia" . Para termos uma aplicação robusta, modular, escalável precisamos ter uma base muito bem fomentada, para isso o design é essencial. Pois como podemos construir artefatos que atendam essas premissas sobre uma base podre? A resposta é obvia, mas nem sempre o obvio é tão obvio. O Design de uma aplicação é mais importante do que qualquer tecnologia de implementação até mesmo a JEE. Não adianta usarmos Spring, Hibernate, MVC, etc se não temos: Alta coesão Baixo acoplamento A Questão chega a ser fetal, acoplamento gera merda. Quanto mais acoplamento pior, se os artefatos estão todos amarrados é muito difícil modificar o código e conseqüentemente a manutenção é penosa. Mas como podemos diminuir o acoplamento e aumentar a coesão? Utilizando Design Patterns Modelagem UML Divisão de papeis Utilizando Interfaces e Herança Re-utilizando des...