Flex e Java Trocando Experiências

Flex e JavaTrocando 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 • SOAP • 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!

Flex e Java Trocando Experiências