Neste artigo veremos como aplicações Java EE stateful podem escalar bem, para serem utilizadas em ambientes controlados, como é o caso de aplicações corporativas. Para isso, um caso de uso simplificado será implementado de forma stateful e sua carga e utilização de memória serão mensurados.
Em que situação o tema útil:
Aplicações corporativas são geralmente executadas em ambientes com acesso controlado e número de usuários conhecidos. Desta forma, a construção de aplicações regidas pelo domínio será mais simples por envolver mais a equipe de desenvolvimento com os futuros usuários do sistema e conhecedores do domínio.
Aplicações Java EE “stateful”:
Aplicações corporativas construídas na plataforma Java EE geralmente têm a característica de ser stateless. Isto se deve muitas vezes ao estigma que foi criado sobre o Stateful Session Beans. Mas nos esquecemos de que utilizamos outros componentes stateful que podem gerar os mesmos problemas que os Stateful Session Beans em várias partes da plataforma, e às vezes sem tomar conhecimento a respeito. Um exemplo são as sessões web, que se tiverem abuso de utilização, podem gerar problemas maiores que os Beans, já que os objetos nelas são guardados como mapas. Utilizando os padrões de projeto corretos para cada necessidade de uma aplicação, teremos o melhor dos dois mundos, stateless e stateful, sem efeitos colaterais e novos problemas.
No período compreendido entre 1999 e 2004, muitas das práticas da orientação a objetos e da modelagem de domínio foram deixadas de lado pela comunidade de desenvolvimento Java corporativo e web, pelo advento da componentização provida pelo EJB nas suas versões 1 e 2, e pela modelagem baseada em contêineres. Mas felizmente, mudanças nas tecnologias e a troca de experiências entre a comunidade de desenvolvedores, como mostrado no livro “Domain-Driven Design Quickly” de Abel Avram e Floyd Marinescu, possibilitaram a volta da correta aplicação do paradigma orientado a objetos através do Projeto Orientado ao Domínio ou DDD (do inglês, Domain-Driven Design), proposto por Eric Evans em seu livro “Domain-Driven Design”.
Porém, até hoje, a grande maioria das aplicações J2EE, e muitas novas aplicações Java EE, utilizam o paradigma de orientação a objetos apenas no mapeamento objeto-relacional, criando assim entidades anêmicas. Estas só mantêm os seus estados através de atributos de classe, enquanto os seus comportamentos são implementados fora das entidades, espalhados nas camadas de negócio e visão, na maioria das vezes de forma procedural.
A separação entre estado e comportamento presente em entidades anêmicas viola o princípio de encapsulamento da Orientação a Objetos. Esta falta de encapsulamento acarreta na necessidade de acesso global aos estados da entidade, o que por sua vez aumenta o acoplamento entre as classes e camadas de serviços.
Mas, a partir da versão 5 da plataforma Java EE, e de tecnologias como JPA e CDI, a utilização de entidades anêmicas e a implementação de métodos procedurais podem ser facilmente evitadas.
Neste artigo veremos como evitar o uso de entidades anêmicas e camadas de serviços procedurais, implementando um caso de uso de emissão de notas fiscais, utilizando os padrões de projeto Java EE Persistent Domain Object (PDO) e Gateway, apresentados no livro “Real World Java EE Patterns – Rethinking Best Practices”. Além de utilizar os recursos disponíveis na arquitetura Java EE, como JPA, CDI e Stateful Session Beans como facilitadores para construir uma aplicação regida pelo domínio.
Entidades anêmicas vs. Orientação a Objetos
O paradigma de orientação a objetos é a forma mais abrangente de abstração do mundo real para sistemas computacionais. Mas, para que esta abstração funcione como esperado, é necessário seguir ao menos a premissa básica da orientação a objetos de manter estado e comportamento juntos no mesmo objeto. Quando são utilizadas entidades anêmicas, o estado e comportamento das classes estão totalmente separados. O estado é representado pelos atributos de classe na entidade e o comportamento geralmente é implementado em diversos métodos espalhados em classes distintas, que por sua vez podem estar contidas em mais de uma camada de serviços da aplicação.
Além de tornar o entendimento das regras de negócio mais difícil, o uso de entidades anêmicas força a implementação destas regras de forma procedural e trata as entidades de domínio apenas como repositórios de dados e não como objetos reais. Por exemplo, uma entidade que represente uma ...
