Flex e Java Trocando Experiências
description
Transcript of 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!