Neste post eu farei uma rápida revisão do artigo da JavaWorld.com http://www.javaworld.com/javaworld/jw-04-2009/jw-04-lean-soa-with-javaee6.html que discute algumas boas práticas da arquitetura baseada em serviços, utilizando o JEE 6. Pretendo apenas ressaltar alguns pontos específicos, deixando toda a parte de implementação para o texto original.
Começarei por uma frase que me chamou a atenção logo de cara:"Component contracts are comparable to SOA's services, except for their heavier dependence on particular technology and general lack of operations-related metadata..."
Agora em "Plain Old Portuguese Words": "Os contratos definidos pelos componentes de software são comparados aos serviços do SOA, excetuando-se o fato de que aqueles são pesadamente dependentes de uma determinada tecnologia e uma relativa falta de metadados relativos às operações disponibilizadas...". O que gosto desta frase é que mostra o caráter evolucionista e não revolucionário da arquitetura baseada em serviços.
A arquitetura exposta pelo autor é voltada à camada lógica e suas 3 estruturas internas:
- Facade (ou Boundary): único ponto de acesso da camada cliente; exporta funcionalidades de nível de negócio; e coordena os serviços internos mantendo inclusive controle transacional.
- Service (ou Control): serviços de "nível programacional", ou seja, que mantêm os princípios de componentes como alta coesão e baixo acoplamento.
- Domain (ou Entity): encapsula entidades com estado persistente.
- O anti-pattern "Objetos anêmicos" é praticamente sugerido como padrão para SOA, pois: podem aumentar a produtividade dado que são facilmente geráveis de forma automática; entidades persistentes podem ser exportadas para o cliente sem correr o risco de se disponibilizar lógica de negócio.
- O padrão DAO é posto em xeque, chegando-se a conclusão de que a forma original de definição do mesmo é irreal para grande parte dos componentes SOA; o autor sugere então a utilização de Generics para a implementação de um CRUDService... (isso eu já sabia, né Ed?).
