desconstruindo ejb
TRANSCRIPT
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