Uma Aplicação Java EE Completa: Escalabilidade e Flexibilidade com EJB 3.0

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Aprenda os fundamentos do desenvolvimento de componentes de negócio EJB 3.0, com técnicas de programação e design patterns que aumentam o reaproveitamento dos componentes em diversas arquiteturas.

Esse artigo faz parte da revista Java Magazine edição 47. Clique aqui para ler todos os artigos desta edição

Uma Aplicação Java EE Completa

Parte 4: Escalabilidade e Flexibilidade com EJB 3.0

Aprenda os fundamentos do desenvolvimento de componentes de negócio EJB 3.0, com técnicas de programação e design patterns que aumentam o reaproveitamento dos componentes em diversas arquiteturas

Neste último artigo da série de desenvolvimento com Java EE, vamos concluir a aplicação de controle de matrículas que temos construído nas últimas três edições. Até o momento, desenvolvemos a camada de negócios e de persistência com JPA, criamos a camada de componentes web com JSF e incrementamos a interface web com AJAX.

Agora introduziremos a tecnologia EJB 3 para fornecer mais robustez à aplicação. Os requisitos não-funcionais do projeto deixam claro que não deve existir uma dependência forte com essa tecnologia, para que possamos executar a aplicação em duas arquiteturas. Relembramos aqui os requisitos relevantes para esta parte:

§         A aplicação deverá ser facilmente escalável, para que depois possa acomodar os componentes de negócio em um container à parte.

§         No futuro, a aplicação poderá ser fornecida como um framework a diversas instituições educacionais, que podem ou não utilizar um container de componentes de negócio em sua infra-estrutura.

 

Ao adaptar a aplicação ao uso do EJB 3.0, vamos considerar estratégias de desenvolvimento para um alto nível de reaproveitamento de código. Aplicaremos também alguns design patterns que promoverão a independência solicitada.

Decisões de projeto

Vamos começar discutindo algumas alternativas de projetos para atender os requisitos restantes.

Escalabilidade

A escalabilidade é a capacidade de um sistema de atender um volume crescente de carga de processamento sem comprometer seriamente a performance ou o tempo de resposta para os usuários. A versão atual da nossa aplicação funciona em um container web, conforme a Figura 1. Essa arquitetura é totalmente funcional, mas atualmente concentra todo o processamento em uma única JVM. Se o volume de trabalho sobre o servidor aumentar e quisermos manter um tempo de resposta aceitável para os usuários, temos algumas possibilidades:

·         Aumentar a capacidade do servidor, adicionando mais memória e mais processadores. Neste caso, estaríamos limitados às possibilidades de expansão do servidor.

·         Criar um cluster de containers web coordenado por um balanceador de carga (por exemplo, utilizando três servidores, teríamos um balanceador de carga e dois servidores para os containers web). Com essa solução, no entanto, acabaríamos prendendo a arquitetura a algum produto específico, pois o balanceamento de carga de containers web ainda não é padronizado pela especificação Java EE.

·         Distribuir o processamento em camadas físicas de responsabilidade. Uma abordagem totalmente coerente com a especificação Java EE é alocar um container para processamento web e um segundo container para o processamento de regras de negócio. Vamos seguir esta direção para proporcionar mais escalabilidade à aplicação.

 

Figura 1. Arquitetura 1: implementação em container web com classes comuns e JPA.

Queremos poder distribuir uma parte da carga de processamento para um container de componentes de negócio, que funciona numa outra JVM em outro servidor corporativo. Há muito tempo, a especificação Java EE propõe a utilização de componentes de negócio distribuídos, capazes de funcionar em containers especializados e independentes da tecnologia de apresentação utilizada. Esses são os conhecidos componentes EJB ou Enterprise JavaBeans.

Um componente EJB pode oferecer uma interface de acesso remoto, através da qual clientes da rede local invocam os métodos de negócio disponíveis no componente, externamente ao servidor. O uso de EJBs com interface remota nos permitirá implantar a arquitetura da Figura 2.

 

Figura 2. Arquitetura 2: componentes web + componentes EJB 3 + JPA.

Mas não é só a questão da distribuição de processamento que deve ser levada em conta para adotar o uso de EJBs. No quadro “EJBs de sessão” apresentamos conceitos básicos e discutimos outras vantagens dessa tecnologia.

Equivalência de regras de negócio

Os requisitos da nossa aplicação exigiram que começássemos criando uma versão web e que só depois criássemos uma versão mais escalável (baseada em containers de negócio). Isso nos leva a conviver com as duas arquiteturas mostradas nas Figuras 1 e 2.

Os componentes de negócio devem ser equivalentes em ambas as arquiteturas. Ou seja, as regras de negócio implementadas nas classes comuns do pacote jm.matriculas.business.impl.comum devem ser implementadas de modo equivalente nos Session Beans que iremos criar. Vamos estudar três abordagens para resolver a questão da equivalência das regras de negócio entre as duas arquiteturas.

Abordagem 1: Famílias paralelas de componentes

A Figura 3 ilustra uma primeira abordagem, que consiste em manter (trabalhosamente) duas famílias de componentes, uma para cada arquitetura. Neste caso, qualquer alteração de regras de negócio vai exigir esforço duplicado de manutenção e de testes nas duas famílias de componentes.

Essa abordagem é frágil e não reaproveita os componentes criados até aqui (ou seja, os da Arquitetura 1). Deveria ser considerada no caso de não existir controle sobre o código-fonte das classes comuns de negócio. Também seria uma abordagem válida se essas classes realizassem operações proibidas dentro de um container EJB, ou se usassem recursos transacionais (como conexões com bancos de dados) de maneira inadequada.

Figura 3. Famílias de componentes paralelas e independentes.

Abordagem 2: Reutilização por dependência

Numa segunda abordagem, poderíamos criar componentes EJB de sessão encapsulando as classes da Arquitetura 1, como mostrado na Figura 4. Basicamente, os métodos de negócio das classes comuns seriam invocados pelos métodos disponibilizados pelos Session Beans através de suas interfaces remotas de acesso.

 

Figura 4. Reutilização por dependência (pattern Session Façade).

Com essa abordagem, uma alteração nas regras de negócio iria concentrar o esforço de manutenção nos componentes da Arquitetura 1. Note que estamos utilizando o design pattern Java EE conhecido como Session Façade. Seguindo este pattern, os Session Beans funcionam como uma fachada (façade) baseada na tecnologia EJB, que coordena o acesso aos verdadeiros componentes de negócio.

Abordagem 3: Reutilização por herança

É possível utilizar herança para propagar os comportamentos dos componentes comuns da Arquitetura 1 para os componentes EJB da Arquitetura 2, conforme vemos na Figura 5. Como acontece na abordagem anterior, alterações nas regras de negócio implicam manutenção concentrada nas classes comuns da Arquitetura 1.

Figura 5. Reutilização por herança.

Esta é a abordagem que exige menos esforço, mas ela só deve ser considerada quando temos controle sobre o código-fonte das classes comuns de negócio. Isso porque precisamos garantir que todos os parâmetros e retornos dos métodos sejam compatíveis com uma interface remota (mais especificamente, eles devem ser serializáveis). Vamos adotar essa terceira abordagem em nosso projeto.

Componentes multi-arquitetura

No intuito de conviver com os dois cenários (com e sem componentes EJB), o ideal é que os componentes web desenvolvidos sejam reutilizados sem modificação de código-fonte, quando alternarmos entre as Arquiteturas 1 e 2. Para que isso seja possível, os detalhes de comunicação remota com os EJBs de sessão da Arquitetura 2 devem ser resolvidos fora dos componentes web.

Business Delegate

A solução mais praticada nessa situação é proposta pelo design pattern Java EE Business Delegate. Dentre outros benefícios, um Business Delegate encapsula os detalhes de utilização dos componentes de negócio, desacoplando os clientes (no caso, os componentes web) das APIs e exceções típicas na manipulação de EJBs ou de outras tecnologias.

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?