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

Transcrição

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 U$ 12k / CPU IBM Websphere Enterprise 4.1 U$ 35k / CPU OAS 9i Enterprise U$ 20k / CPU OAS X ORION (fonte: 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 Fachada Controlador A Controlador A Cadastros Repositórios Fachada Controlador B Controlador B Cadastro Repositório

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 Fachada Controlador A Controlador A 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 Complexo Muito Complexo ,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