O documento analisa os problemas e limitações do uso de Enterprise JavaBeans (EJB), incluindo questões de produtividade, custo de desenvolvimento, portabilidade e performance. São apresentados desafios enfrentados nas implementações, como a necessidade de ferramentas caras e falta de mão de obra especializada, além de alternativas propostas para contornar esses problemas. Conclui-se que o EJB não é a solução ideal, sugerindo a exploração de novas arquiteturas que melhorem a produtividade e escalabilidade.

1. Centro de Estudos e Sistemas Avançados do Recife
Desconstruindo EJB
Luiz Borba
Luiz Eugênio (left)

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

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

4. 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

5. 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

6. 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

7. 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

8. 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)

9. 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

10. 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

11. 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)

12. 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...

13. 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

14. 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)

15. 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.

16. 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

17. 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

18. 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)

19. 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

20. 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)

21. 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

22. 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

23. 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;
}
}

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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