Desconstruindo EJB

Centro de Estudos e Sistemas Avançados do Recife

Desconstruindo EJB

Luiz Borba Luiz Eugênio (left)

Desconstruindo EJB

❑ Motivado pelos problemas que enfrentamos – Problemas com EJB – Como contornar os problemas

Problemas com EJB

❑ Problemas de produtividade ❑ Custo de desenvolvimento ❑ Custo total para o cliente ❑ Problemas de portabilidade ❑ Problemas de performance ❑ Restrições do EJB

Problemas de produtividade

❑ Para testes unitários, tem que “levantar” um EJB Container

❑ Tempo de compilação excessivo (geração de stubs e skeletons)

❑ Debug remoto é mais lento ❑ Ferramentas são mais complexas e pesadas ❑ Ferramentas ainda são pouco maduras e

apresentam diversos problemas (redeploy do BAS e no BES)

❑ Ainda pouca experiência com desenvolvimento de aplicações distribuidas

Problemas de produtividade

❑ Mapeamento CMP – Não tem herança e pelo jeito, não vai ter nunca – Não mapeia relacionamentos (no EJB2 criaram o

CMR, mas, tem limitações) ❑ Caso SISREG

– Temos sempre que implementar na mão herança e relacionamentos, complicando o uso dos Beans

Custo de desenvolvimento

❑ Equipamento mais caro – Para rodar o container + ferramenta de

desenvolvimento é preciso uma boa máquina – Cesar teve que fazer um upgrade de memória

(256Mb para 768Mb) ❑ Ferramentas caras

– Ferramentas free não possuem bom suporte a EJB (ex. JBuilder Personal, Netbeans e Eclipse versus JBuilder Enterprise, Forte e WSAD)

❑ Dificuldade de encontrar mão de obra especializada ❑ Baixa produtividade

Custo total para o cliente

❑ Custo alto da aplicação (mão de obra especializada, hardware de desenvolvimento mais caro, ferramentas de desenvolvimento mais caras, baixa produtividade)

❑ Custo do servidor de aplicação – BES AppServer Edition 5.0.1 – U$ 12k / CPU – IBM Websphere Enterprise 4.1 – U$ 35k / CPU – OAS 9i Enterprise 9.0.2 – U$ 20k / CPU – OAS X ORION

(fonte: http://www.flashline.com/components/appservermatrix.jsp) ❑ Mão-de-obra especializada (administrador de

sistemas com conhecimento em servidores de aplicação) – raro e caro

Problemas de portabilidade

❑ O mapeamento CMP (Deployment Descriptor) não é portável

❑ Nem sempre existem ferramentas para conversão (aliás, normalmente não existem), e quando existem, não funcionam 100% (tem que fazer uma parte manualmente)

❑ Nem sempre podem ser convertidas sem perda de informação (WebLogic x BAS)

❑ Não garante a portabilidade entre banco de dados diferentes (EJB 1.1)

Problemas de portabilidade

❑ Usando EJB QL (EJB 2.0) poderia ser garantido a portabilidade entre bancos, mas, ainda é muito nova e possui muitas limitações: – order by vai sair no EJB 2.1 – Funções de agregação – Funções de manipulação de datas

❑ DATASUS tenta migrar para outros Servidores de Aplicação e outros Bancos de Dados e o custo é alto

Problemas de performance

❑ Alterações feitas em outros sistemas ou feitas diretamente no banco são refletidas imediatamente pelos beans – Queries precisam ser feitas para validar informações

em cache – Queries tem que ser completas (select * ...), porque

nem todos os bancos possuem um timestamp que guarde o momento da última alteração ou um campo de versão do registro

❑ Atualizações em CMP são sincronizadas no banco no máximo até o fim da transação – Quando em uma mesma transação fazer consultas

sob atualizações feitas antes, a informação pode não ter sido colocada no banco ainda (Rotinas Batch do DATASUS) – solução: atualizações usando DAO

Problemas de performance

❑ Para fazer finds, precisamos de 1+n queries para trazer todos os dados (no caso de CMP, o servidor pode otimizar isso, mas, não acontece sempre)

❑ Fazer chamadas remotas para Entity Beans, é inviável (padrão DTO)

❑ Entity Beans não precisam ser distribuidos (Interfaces Locais - EJB 2)

Restrições EJB

❑ Nada de Threads ❑ Nada de java.io.* ❑ Nada de Sockets ❑ Nada de AWT ❑ Nada de JNI ❑ Nada de (mais um bocado de coisas)... ❑ Ainda tem um monte de restrições com o uso de

classloaders, reflection, atributos estáticos, sincronização, security manager, e por aí vai...

E tem mais...

❑ O Servidor de Aplicação oferece uma série de recursos que a gente não utiliza, não porque não quer, mas, porque não precisa

Estudo de caso (DATASUS – SISREG)

❑ É um sistema que vai ser instalado em vários pontos do país

❑ Projeto de implantação comprometido pelo custo ❑ Alternativas sendo cogitadas

– Reaproveitamento de Hardware (CNS) – Servidores gratuitos (JBOSS) – Bancos de Dados gratuitos (POSTGRESQL) – Mão-de-obra gratuita ? (escravos)

Como contornar os problemas ?

❑ Principais ”vantagens” de Enterprise Java Beans: – Distribuição dos componentes gerenciadas pelo

container – Persistência de componentes gerenciadas pelo

container – Transações gerenciadas pelo container – Portabilidade entre diversos servidores de aplicação.

Distribuição

❑ Nem sempre é necessário distribuir nossas aplicações – Um desenvolvedor implementando um caso de uso

poucas vezes precisa testar de forma distribuída – Alguns sistemas não precisam de distribuição

❑ A arquitetura do CESAR pode auxiliar no isolamento da distribuição

❑ A implementação de uma camada de distribuição pode ser desenvolvida em separado ou substituída sem grandes impactos na aplicação

Distribuição

❑ FachadaControlador é o ponto de distribuição ❑ Somente a FachadaControlador precisa ser um

objeto remoto ❑ As regras de negócio ficam na implementação do

controlador

Controlador B

Cadastro

Fachada Controlador B

Repositório

Cadastro

Repositório

Cadastro

Repositório

Controlador A

Cadastro

Fachada Controlador A

Repositório

Cadastro

Repositório

Cadastros

Repositórios

Distribuição

❑ Podemos ter diversos tipos de implementação para a FachadaControlador (ex. CORBA, RMI, Web Services ou até um Session Bean)

❑ Referência para o controladores obtida através de um ServiceLocator que pode retornar uma referência local ou remota sempre utilizando a interface da FachadaControlador

❑ FachadaControlador completa pode ser facilmente gerada por uma ferramenta (ex. QualitiCoder)

Tecnologias de Distribuição

❑ CORBA (GIOP/IIOP) – Brokers tem custo alto em ambientes legados – Implementação de aplicações necessita de maior

esforço – Independente de linguagem – Independente de plataforma – Serviços básicos, de infra-estrutura e de domínios

específicos padronizados – Solução mais utilizada para integração com legado – Suporta comunicação síncrona/assíncrona

Tecnologias de Distribuição

❑ RMI/IIOP – Comunicação síncrona – Comunicação possível com aplicações não-Java – Dependente de linguagem (Java) – Normalmente utiliza um broker CORBA – Solução utilizada para comunicação entre Enterprise

Java Beans

❑ RMI/JRMP – Comunicação síncrona – Comunicação apenas entre aplicações Java – Dependente de linguagem (Java)

Tecnologias de Distribuição

❑ Web Services (SOAP/HTTP) – Baixo desempenho devido as mensagens XML – Independente de linguagem – Independente de plataforma – Necessita de mais amadurecimento (suporte a

segurança e transações distribuídas) – Utilização de XML como base facilita a integração com

outros sistemas – Suporta comunicação síncrona/assíncrona

Transações

❑ Normalmente precisamos de transações, contudo nem sempre distribuídas

❑ Não precisamos criar dependências de uma tecnologia específica – Mudança do mecanismo não deve afetar a aplicação

❑ Utilizando conceitos da arquitetura CESAR, criamos uma camada de abstração do mecanismo de transações

Transações

❑ Criamos uma API para abstração dos mecanismos ❑ Para cada mecanismo de transação implementamos

um conjunto de interfaces da API ❑ FachadaControlador delimita o início e final das

transações

Controlador A

Cadastro

Fachada Controlador A

Repositório

Cadastro

Repositório

Cadastros

Repositórios

public void aMethod() throws ControladorException { Transaction.begin();

try { ControladorA.getInstance().aMethod();

Transaction.commit(); } catch (ControladorException ex) { Transaction.abort(); throw ex; } }

Tecnologias de Transações

❑ CORBA Object Transaction Service (OTS) – Independência de linguagens – Independência de plataformas – Serviço padronizado – Suporte a transações distribuídas

❑ Java Transaction Architecture/Service – Comunicação possível com aplicações não-Java – Implementa o OTS – Independente de plataformas – Serviço padronizado – Suporte a transações distribuídas

Tecnologias de Transações

❑ Transações baseadas no mecanismos de persistência (ex. JDBC, JDO) – Não suporta distribuição

❑ Transações FIC – Solução CESAR que atendeu a demanda de muitos

sistemas

Persistência

❑ Ponto mais fraco de Enterprise Java Beans – Relacionamentos gerenciados pelo container

extremamente restritivo. No final implementamos os relacionamentos manualmente (EJB 2.0)

– Linguagem de consulta padronizada não atende ao mínimo (ex. falta funções de ordenação, agregação e para manipulação de datas)

– O mapeamento CMP não é portável. – Portabilidade com baixo custo é uma lenda. As

poucas ferramentas que tentam converter sempre perdem informações depois da conversão

❑ Existem diversas soluções maduras para mapeamento objeto/relacional

Tecnologias de persistência

❑ Object/Relational Mapping Tool – Exolab Castor (free) – Hibernate (free) – Jakarta ObJectRelationalBridge (OJB) (free) – ObjectMatter VBSF O/R Mapping Tool – WebGain TopLink – Thought Cocobase

❑ Java Data Objects (JDO) – Pode resolver o problema da falta de um padrão Java

para mapeamento objeto-relacional – Algumas ferramentas de mapeamento já começaram

a se adequar a este padrão

Estimativa de Esforço

❑ Comparativo com Modelo 01 (EJB), Modelo 02 (Arquitetura 1) e Modelo 05 (Reaact – VBSF)

Caso de uso

Modelo 01 EJB

Modelo 02 Arquit. 1

Modelo 05 Reaact

Novo Modelo

Simples 2 1,5 1 1

Médio 4 3 2 2

Complexo 7 5 4 4

Muito Complexo

10 7 5,20 5,20

Conclusão

❑ Enterprise Java Beans não resolve todos os nossos problemas com baixo custo

❑ Com pequenas mudanças podemos: – Não ficar presos a uma tecnologia – Melhorar mais a produtividade – Não comprometer em nada aspectos de

escalabilidade (provavelmente até podemos melhorar nesse aspecto)

❑ Estamos fazendo um esforço no sentido de elaborar uma alternativa ao EJB já para o projeto SIMAC