Flex e Java Trocando Experiências

Apresentação em tema: "Flex e Java Trocando Experiências"— Transcrição da apresentação:

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

2 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

3 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

4 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

5 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?

6 Vamos por partes...

7 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

8 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)

9 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{ ... }

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

11 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)

12 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...)

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

14 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

15 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

16 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)

17 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

18 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)

19 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)

20 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.

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

22 MVCs Cairngorm Flex itself Swiz

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

24 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

25 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.

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

27 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

28 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

29 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

30 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)

31 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

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

33 Sugestões pra próximos encontros
Vamos discutir!

34 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

35 Demorou mais acabou... Muito Obrigado a todos!