Flex e Java Trocando Experiências Floripa Flex Adobe User Group Rafael Mauricio Nami

Motivação Trocar experiências nas possíveis integrações entre Java e Flex Discutir possíveis soluções para problemas recorrentes em RIA em geral com Java Discutir próximos temas de encontros do AUG e iniciativas do grupo

Bio Rafael Nami trabalha em desenvolvimento de sistemas a mais de 6 anos Foco em Metodologias Ágeis, RIA, Java Consultor, Líder técnico e sócio da Extersoft Tecnologia

Integrações Colocar os jars do blazeDS no classpath da aplicação web Configurar o FlexFactory (opcional) Configurar o remoting-config.xml para expor os serviços Configurar os RemoteObjects na view Flex

Problemas de integração – Parte Java ORMs – LazyInitializationException Segurança – Session? JAAS? Spring Security? Como tratar? Expor Domains ou não? Xml, SOAP, JSON ou AMF?

Vamos por partes...

ORM e o Lazy... Este é um problema que não ocorre só no Flex ORMs implementam o padrão Unit of Work ORMs trabalham com manipuladores de bytecode e proxies dinâmicos para melhorarem a performance das operações internas

ORM e o Lazy – Possíveis soluções Configurar todas as associações como eager Inicializar os dados na unit of work apropriada, fazendo um design apropriado da arquitetura da aplicação “Taking drugs” – utilizar frameworks que remediam este problema, como o dpHibernate (Flex Only) e o Gilead (Nasceu para o GWT, mas já é utilizado para Flex também)

ORM e o Lazy – Possíveis soluções Na falta de paciência sempre tem o bom e velho JDBC... try { ... }catch(SQLException e) { ... transaction.rollback(); }finally{ ... }

Segurança Que recursos proteger? Como manter a sessão no flex? Como restringir a criação de componentes/telas? Restrição de URLs

Segurança Flex não é um recurso JavaEE Aplicações RIA são o mais próximo possível do que se pode haver de uma aplicação desktop – como é a segurança de aplicações desktop mesmo??? Alguns conceitos de JavaEE não se aplicam a RIA (Flex é RIA, Data-Aware)

Segurança – Possíveis Soluções “Thread” no flex configurando remoteObjects/httpServices com o token recebido no login SecureComponentFactory – criar os componentes de tela verificando se o token possui permissão para acesso/manipulação do componente Criar o menu dinamicamente pelos perfis do token logado logo no início do startup do sistema SharedObjects para manter um armazenamento no cliente da sessão e/ou preferências Abordagem SOA – Manter uma flag “logado” no banco (feio, porém é muito mais comum do que a gente pensa – e realmente funciona...)

Ainda não existe a Bala de Prata na Segurança de RIA...

Expor Domains ou não? Domain Design é uma técnica onde a modelagem de negócio é toda feita em função de responsabilidade de objetos A modelagem de cada domain deve ser proporcional e dirigida para cada responsabilidade Expor domains fora do contexto de negócio é um problema de segurança

Mas... O que é Domain? NÃO são as entities ORM Arquiteturas CRUD genéricas são transaction scripts, não domain Utiliza Interfaces em profusão Possui estado interno (Não é um javabean) Comunica-se com outros domains por meio de mensagens trocadas

Expor Domains ou não? Solução – Aplicar o pattern VO (Value Object) No caso de utilização de AMF, o VO pode ser “Assemblado” na própria camada de façade da aplicação (que é exposta ao flex) Já utilizando Xml, SOAP ou JSON, o assembly pode ser feito na camada controller (antes do marshalling)

XML, SOAP, JSON ou AMF? Tudo depende de onde você quer mais facilidade Ponto forte – Ferramental excelente para exposição de serviços, padrão de arquitetura SOA, arquitetura flex é mais simples Ponto fraco – Tamanho do Pacote é o maior, performance e latência de rede são as piores*; Arquitetura servidor pode ficar mais complexa

XML, SOAP, JSON ou AMF? XML Ponto forte – Padrão de arquitetura SOA, arquitetura flex é mais simples (E4X) Ponto fraco – Caso utilize atributos, a performance e latência de rede são médias; Arquitetura servidor pode ficar mais complexa (necessita de marshalling/unmarshalling de VOs)

XML, SOAP, JSON ou AMF? JSON Ponto forte – Padrão de arquitetura WOA, arquitetura flex é mais simples (E4X), performance e latência de rede são muito boas. Ponto fraco – Arquitetura servidor pode ficar mais complexa (necessita de marshalling/unmarshalling de VOs)

XML, SOAP, JSON ou AMF? AMF Ponto forte – Arquitetura servidor é bem mais simples, performance, tamanho do pacote e latência de rede são os melhores, arquitetura flex fica OO. Ponto fraco – Arquitetura flex fica um pouco mais complexa.

Mas cadê o Flex desta reunião? Demorou, mas agora sim, vamos falar de Flex...

MVCs Cairngorm Flex itself Swiz

Cairngorm Feito pela Adobe Moldes J2EE “Provê” desacoplamento entre componentes e a microarquitetura Abstrai a complexidade de tratar RemoteObjects, HttpServices

Cairngorm – Fluxo Básico O componente dispara um evento (CairngormEvent) Controller recupera o evento, disparando-o para o Command mapeado O command executa o delegate Após o retorno da execução RPC (remoteObject, HttpService, etc...) modifica o modelLocator, que por utilizar Bind irá modificar o componente visual

Cairngorm – Problemas Cópia do evento (resolvido com o Cairngorm Extensions) Proliferação de Commands, Events e Delegates (resolvido com o Cairngorm Extensions) ModelLocator é um repositório de variáveis (questão de uso consciente) Única situação em flex que o próprio evento de dispacha (para não haver dependência do cairngorm em cada componente visual) Difícil de aplicar testes unitários, por ser um framework intrusivo.

Cairngorm – Pontos Positivos A padronização do código traz muita produtividade É relativamente estável Não possui problemas muito graves quando utilizado racionalmente

Flex itself Pode se escolher utilizar o próprio flex para ser o MVC Necessitaria de algumas classes Interceptador de eventos borbulhados Controller Delegate Model Apenas uma organização de código e a correta utilização de eventos e listeners já basta

Swiz Container IOC para AS3, feito por Chris Scott NÃO É UM MVC Mas provê muita coisa que facilita E MUITO o desenvolvimento Dentre os comentados, demonstra a programação mais limpa e simples

Swiz – Fluxo Básico O componente dispara um evento (Pode ser de qualquer tipo herdado de Event primitivo do Flex) pelo singleton Swiz Este evento é verificado entre as annotations Mediate, e se alguma está configurada para o evento, executa o método configurado O Controller executa o delegate apropriado Após o retorno da execução RPC (remoteObject, HttpService, etc...) modifica o Model injetado, que por utilizar Bind irá modificar o componente visual por estar também injetado no componente

Swiz – Problemas Ainda está na versão 0.5 (mas já é totalmente funcional) Comunidade ainda pequena Ainda polui o componente que dispara o evento com o Swiz.dispatchEvent (há como contornar, colocando um listener no stage para os tipos de eventos que chamam mediate)

Swiz – Pontos Positivos Brutalmente simples Estável A programação fica extremamente mais limpa, e com pouquíssimos artefatos por caso de uso Configurações muito simples de fazer Muito simples de testar unitariamente com um Fluint ou um FlexUnit

Outros... Mate Penne PureMVC Anvil Parsley Prana <mx:FloripaFlexFmk????>

Sugestões pra próximos encontros Vamos discutir!

Iniciativas Colocar no site do AUG links para projetos no googleCode para facilitar o estudo em flex com Java. As pequenas aplicações serão focadas em regras de segurança (módulo de segurança), com casos de uso para manter usuário e perfis de usuário. A aplicação será em 2 versões diferentes - Na parte server, pode ser em jdbc com spring ou JPA/Hibernate Annotations com spring, e na view, Cairngorm ou Swiz Haverá integração com JAAS, JSecurity e Spring Security

Demorou mais acabou... Muito Obrigado a todos!