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

Centro de Estudos e Sistemas Avançados do Recife

Desconstruindo EJB

Luiz Borba

Desconstruindo EJB

❑ Motivado pelos problemas que enfrentamos

–

Problemas com EJB

Problemas com EJB

❑ Problemas de produtividade

❑ Custo de desenvolvimento

❑ Custo total para o cliente ❑ Problemas de portabilidade

❑ Problemas de performance

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

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

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

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

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

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

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

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

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

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 ModeloNovo

Simples 2 1,5 1 1

Médio 4 3 2 2

Complexo 7 5 4 4

Muito

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