Vou começar dando uma breve explicação de porque decidi juntar todas estas tecnologias.
- PostgreSQL - Um banco de dados bastante maduro no mercado, amplamente utilizado na comunidade open source, adotado fortemente em setores do governo brasileiro e com muitos recursos que lembram o Oracle.
- JBoss 7.1.3 - Um servidor de aplicações largamente utilizado, maduro e bem consolidado no mercado. Mantido pela respeitada Red Hat. É free e open source apesar de possuir uma versão EAP que pode ser licenciada para aquisição de suporte e atualização. Infelizmente não faz parte deste artigo cobrir todas as capacidades do jboss, mas você pode encontrar excelentes informações nos sites http://jbossdivers.wordpress.com/, http://middlewaremagic.com/jboss/, http://www.mastertheboss.com/ entre outros.
- Maven 3 - Um gerenciador de dependências, organizador de projetos, automatizador de builds e testes e muito mais. O maven realmente ajuda bastante no processo de desenvolvimento de softwares. Também não está no escopo deste artigo cobrir mais detalhes sobre o maven.
- JEE 6 - A idéia é desenvolver uma aplicação utilizando apenas as bibliotecas do JEE 6 para funcionalidades como injeção de dependência, inversão de controle, interceptação, controle transacional, datasource através de JNDI, JPA, segurança, mensagens. Buscarei ao máximo demonstrar o uso da especificação JEE 6 para satisfazer nossas necessidades e farei uso ao máximo que puder do middleware.
- Arquillian - Ou JBoss Arquillian é uma excelente ferramenta para testes em ambientes de integração como servidores de aplicação por exemplo. O arquillian auxilia em muito concentrar os testes onde queremos focar e permite executar nosso código dentro de um container real. Não está no escopo deste artigo demonstrar todas as funcionalidades do arquillian mas você pode obter excelente informação no site http://arquillian.org/.
- Flex 3 - Este talvez seja o ponto mais polêmico das escolhas. Aqui vale a pena contar uma breve historinha. Se você é ligado ao mundo de desenvolvimento mobile deve ter ouvido falar que em algum momento um engenheiro da adobe publicou num blog que a adobe abandonaria o flash player para os browsers de dispositivos móveis. Bem, esta foi uma gota que caiu no meio do oceano e chegou até a praia como um verdadeiro tsunami. Choveram informações desencontradas e afirmações sem base que contaram com a falta de esclarecimento da adobe... enfim, o que muitos deram como certo foi que a adobe iria descontinuar o flash e consequentemente o framework flex. Infelizmente muita gente abandonou o framework e algumas empresas voltaram atrás com projetos. Pois bem, logo em seguida a adobe concretizou a doação para a fundação apache do projeto flex sdk para que esta o evolua, ainda que a adobe mantenha engenheiros seus focados no projeto. Hoje o projeto está sendo tocado pela fundação apache. No site http://flex.apache.org/ você pode se atualizar. Em resumo, mais de um ano depois que se espalhou na net que o flash/flex havia acabado o projeto continua firme e forte e os sistemas desenvolvidos nesta plataforma continuam funcionais e fazendo uso das atualizações do flash player. Hoje eu não só utilizo em projetos novos como também evoluo projetos antigos que sinceramente não vejo o menor motivo para trocar. A tecnologia se encaixa perfeitamente ao ambiente de meus clientes, não há qualquer impedimento técnico para execução do sistema web, o cliente está satisfeito e seus requisitos devidamente atendidos e tenho domínio da tecnologia. Ha sim, e a escolha pelo 3 ao invés do 4 é pura e simplesmente didática. Considero o flex 3 mais maduro e mais fácil de entender que o flex 4.
- Graniteds 3 - Bem, este aqui é outro cara que também merece um pouco de explicação. Lembro-me perfeitamente que quando comecei a trabalhar com flex por meados de 2008~2009 haviam poucas informações e opções de RPC para flex e java. Já existia o blazeds e um concorrente próximo era o graniteds. Na época em que tentei usar o granite não tive sucesso e seus recursos eram mais fracos que o oferecido pelo blazeds, sem mencionar que o blazeds era mantido pela própria adobe como amostra gratis de seu caríssimo life cycle data service. Pois bem, o tempo foi passando e com o uso constante do blazeds muitas mazelas foram aparecendo e tivemos que recorrer a tratamentos caseiros como o Number -> Double zero, problemas de serialização, lazyloading do hibernate entre outros pequenos e contornáveis problemas. A questão mais importante é que o projeto blazeds parou no tempo enquanto o granite se reinventou. O pessoal da http://www.graniteds.org fez um trabalho formidável na restruturação do framework e vem mantendo-o desde então. Confesso que fiquei impressionado com a quantidade de recursos presentes no framework e como ele resolveu muitos dos problemas que tinhamos. No momento da escrita deste artigo a ultima versão disponibilizada é a 3.0.0.M2.
Bem, tecnologias explicadas a parte podemos começar nossa aventura. A intenção desta série de artigos é construir uma aplicação que gerencie eventos. O sistema deve ser capaz de cadastrar participantes e trabalhadores dos eventos, bem como guardar as atividades de cada trabalhador, alocar os participantes em quartos e permitir consultas em base histórica.
Vamos primeiramente configurar o básico de nossa base de dados, deixaremos que a nossa implementação de persistência crie as tabelas para nós. Em seguida vamos configurar nosso servidor de aplicação, afinal, temos que ter em mente que estamos desenvolvendo nossa aplicação para ser executada sobre um servidor de aplicação então, nada mais natural que entendermos e fazermos uso de seus recursos. Depois configuraremos nossas entidades, pretendo usar o modelo tradicional ainda que bastante controverso e também apelidado de "entidade anêmica". Para não ficarem tão "anêmicas" anotaremos nossas classes com validações de integridade. Não pretendo tratar de questões como DDD nestes artigos. Com o avançar do projeto aplicaremos a divisão de camadas em nosso projeto separando interesses como persistência, regras de negócio com o uso de serviços, controladores para tratamento de requisições externas e a camada visual modular utilizando recursos do flex enriquecido pelo graniteds.
Para podermos desenvolver este projeto precisaremos de:
- Oracle JDK 1.7
- eclipse indigo (ou superior) com os plugins
- maven
- graniteds
- jboss tools
- Flash Builder IDE - aqui é a parte desfavorável do flex, para ser produtivo você tem que contar com a ide do flash builder que é paga. Para estudantes e profissionais liberais isso se torna um custo difícil de retorno, por outro lado para empresas não se trata de um custo tão significativo. Felizmente a adobe concede a estudantes licenças de uso com algumas limitações. Por outro lado é possível desenvolver sem a necessidade do flash builder ide, você pode escrever todo seu código e compilar com a sdk do flex através de linha de comando ou scripts ant. Nos exemplos estarei usando o flash builder IDE.
- JBoss Application Server 7.1.3
- Postgres 9.2
- Apache Maven 3.0.5
- Apache Ant 1.8.4
Vamos sempre usar a política de nunca reinventar a roda, a não ser por dois motivos:
- A roda que existe não rola e é meio quadrada.
- Não temos conhecimento da roda.
Assim sendo, não iremos relacionar aqui tópicos como:
- Como instalar e configurar o postgres
- Como instalar jdk
- como instalar e configurar o eclipse
- como instalar o maven
- como instalar o ant
Certamente trataremos de tópicos relevantes para nossos artigos, todos os demais podem facilmente ser obtidos na net onde encontrarão materiais com bastante qualidade em sua grande maioria na língua inglesa mais também há excelentes artigos escritos no idioma português.
Vamos começar a brincadeira?