Componentes e Serviços.

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.

OK! não acredito que estas estruturas sejam novidade para grande parte dos leitores, mas o interessante do artigo aqui comentado são as reflexões sobre esta arquitetura e sua implementação no JEE, tais como:

• 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?).

É isso... espero ter conseguido ao menos despertar a curiosidade do leitor para a leitura do artigo revisado, e dizer que as dicas são preciosas para se introduzir a idéia de componentes de software no processo de desenvolvimento.