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, DataAware)
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!