Introdução
Quando me interessei por Rich Internet Applications, já tinha alguns anos de experiência em programação e algum conhecimento de Actionscript e linguagens Web. Mesmo assim não foi fácil entrar no mundo das RIAs, pois nunca encontrei um local que explicasse “Uma RIA consiste nisto, deves usar isto, e aprender como se faz aquilo”. No fundo, tive primeiro que aprender várias tecnologias, deduzir como iria integrá-las, e só então é que se tornou claro para mim como construir uma RIA.
Quer isto dizer que é complicado fazer uma RIA? Não, muito pelo contrário. “RIA” é apenas um conceito, pois na prática não passa da nossa capacidade de integrar diferentes tecnologias e metodologias para implementar uma aplicação semelhante ao software desktop com um interface extremamente usável e “optimizado” em função do utilizador final.
Porém, o que pode ser complicado é o “entrar” neste mundo. Existe uma panóplia de ferramentas espalhadas por aí, 1001 formas de fazer a mesma coisa, cada uma com os seus pontos fortes e fracos. E sem os conselhos adequados é preciso “perder” imenso tempo a investigar até se obter aquilo que a comunidade osflash designa por “workflow”. A utilização deles desta palavra não é a mesma a que estamos habituados no nosso país, mas no fundo designa o conjunto de ferramentas, de técnicas e metodologias que se unem para se atingir um objectivo. Neste caso, construir uma RIA.
Neste tutorial não é pretendido dizer “é assim” que se faz uma RIA, mas sim explicar por alto quais os componentes que a compõem, que tecnologias e soluções podem ser usados, e sugerir alguns workflows usando Flash/Flex.
Estrutura de uma RIA
Uma RIA não passa de uma aplicação distríbuida. Quer isto dizer que haverão pelo menos duas “entidades” envolvidas: um cliente e um servidor. O cliente é o computador do utilizador que acede ao interface gráfico da aplicação. O servidor é um computador que disponibiliza serviços, que escondem por detrás a lógica de negócio e a base dados. A comunicação é sobre HTTP e é conseguida através de várias soluções, como LoadVars, XML ou remoting.
A seguinte figura ilustra o que descrevi anteriormente:
(Curiosidade: o diagrama acima foi feito no Gliffy, que é uma RIA para fazer diagramas).
Isto implica que têm que ser feitas pelo menos 3 escolhas de tecnologias: client-side, comunicação, e server-side.
A escolha entre as tecnologias client-side e server-side seria completamente independente (ou seja, inicialmente pode ser usado actionscript no lado do cliente, e java no do servidor, e mais tarde mudar o java para php sem que seja necessário mudar uma única linha de código no lado do cliente), se não estivesse dependente da escolha do método de comunicação.
Por isso, interessa explicar primeiro quais os métodos mais habituais para a comunicação.
A comunicação
A escolha do método de comunicação deve ter em conta a sua eficiência (i.e. dados comprimidos ou não), o overhead que coloca no servidor e cliente (i.e. processamento necessário para converter o formato dos dados transmitidos para dados manipuláveis), e o trabalho que o programador terá que ter a mais ou a menos durante o desenvolvimento.
Temos as seguintes opções:
- LoadVars
- XML
- Flash Remoting
- Web Services
LoadVars é uma tecnica antiga desaconselhada para aplicações complexas. Consiste em disponibilizar ficheiros de texto com pares variavel = conteudo.
XML é uma das técnicas mais usadas (talvez a mais usada), e consiste em disponibilizar os dados em formato de texto numa estrutura em árvore - equivalente à estrutura dos “objectos” a transmitir. É uma solução bastante boa, com as desvantagens de que é menos eficiente que a solução proposta a seguir, e ainda de que implica mais trabalho da parte do programador.
Flash Remoting consiste em colocar o servidor a disponibilizar objectos (através protocolo AMF0 ou AMF3, - o programador pode fazer uma RIA sem sequer saber o que é AMF!), que são consumidos e convertidos automaticamente para a linguagem do lado do cliente. Esta solução é interessante na medida em que o programador não tem que escrever o código para converter o formato dos dados transmitidos para o formato dos objectos da linguagem em questão (problema que acontece, por exemplo, com o XML). Além disso, ao não existir esse código há menos processamento envolvido=mais eficiência. Outra vantagem, é o facto do protocolo AMF comprimir os dados, isto é, uma mensagem AMF ocupa muito menos que uma mensagem XML=mais “velocidade”. Esta é sem dúvida a solução mais sensata para aplicações complexas.
Web Services Esta solução não é muito diferente da de Flash Remoting na medida em que também existe conversão automática dos objectos. A principal diferença reside no facto dos dados transmitidos não serem comprimidos, pois os Web Services na realidade assentam em XML, apesar de o fazerem transparentemente
Implementações de Flash Remoting
Como se viu anteriormente, o Flash Remoting é a solução de comunicação mais interessante. Existem várias implementações desta solução disponíveis:
- AMFPHP: para PHP. Suporta AMF0 e AMF3. É open-source
- SabreAMF: para PHP. Suporta AMF3. É open-source
- Fluorine: para .NET. É open-source. Suporta AMF0 e AMF3
- ColdFusion: implementação comercial da Adobe, que integra o Flash Remoting com uma linguagem própria para desenvolvimento web (e muitas outras potencialidades). Suporta AMF0, AMF3 e Web-Services.
- openAMF: para JAVA. Open-source. Suporta AMF0
- Red5: Para JAVA. Open-source. Suporta AMF0, e RTMP. Solução para streaming multimédia.
- WebOrb: possuem implementações comerciais para .NET, RoR, e open-source para PHP.
- Flex Data Services 2: é uma solução comercial da Adobe que suporta tudo e faz “tudo” (exceptuando pipocas), tal como data push, data synchronization, e muitas outras potencialidades revolucionárias.
A escolha da implementação do Flash Remoting será feita, obviamente, de acordo com os conhecimentos da equipa de desenvolvimento em certa linguagem e das características específicas dessa mesma linguagem. Por exemplo, se a equipa for expert em PHP, pode escolher entre AMFPHP, SabreAMF ou WebORB. Se perceber de JAVA, poderá optar por openAMF, Red5 (que também pode e deve usado para streaming de dados multimédia), WebORB, ou mesmo ligar código JAVA ao Flex Data Services 2 ou ao Coldfusion.
Do lado do servidor
Programar a lógica de negócio e de acesso a dados (o lado do servidor) é algo que irá fazer com relativa facilidade se já tiver experiência de desenvolvimento. Não há aqui muito a dizer, irá apenas fazer código para manipular dados de uma base de dados e disponibilizá-los na forma de serviços. Essa “disponibilização” é a única novidade, mas não implica quase esforço nenhum por parte do programador: basta na solução de remoting escolhida “designar” quais as classes que estão acessíveis para o exterior.
Obviamente, cabe ao programador escolher qual é o sistema de gestão de base dados (SGBD) que vai usar, sendo que para a web um dos mais habituais é o MySQL.
Lado do cliente
Chega então a altura de escolher a linguagem do lado do cliente, que é onde reside a verdadeira diferença das RIAs. Aqui a escolha será dividida entre as seguintes (se se objectivar uma RIA a correr através do Flash Player):
- Actionscript 2.0
- Actionscript 3.0
O Actionscript 2.0 é a linguagem por defeito do Flash 8. É compatível com todas as versões do Flash Player a partir do 7 e pode ser compilado pelo (lento) compilador da Macromedia ou pelo (rápido) MTASC que, entre outras coisas, é open-source e estimula as boas práticas de desenvolvimento. Optar por desenvolver o seu projecto em Actionscript 2.0 implica escolher entre estes compiladores, e também entre diversos “workflows” (i.e. usar apenas o Flash IDE para fazer o design e o código, usar o Eclipse para programar compilando com o MTASC, etc).
O Actionscript 3.0 foi introduzido com o compilador do Flex 2. É uma linguagem muito mais poderosa que a versão anterior, e o conjunto de bibliotecas (componentes) que acompanha o Flex 2 é fenomenal. Além disso, pode optar por programar em MXML, a linguagem do Flex, que é fantástica por ser tão simples. O compilador é muito rápido, e usando o Flex Builder 2 obtém indices de produtividade muito elevados. As bibliotecas (SDK) e o compilador do FB2 são gratuítos, pelo que só terá que pagar se quiser mesmo comprar o IDE - que compensa!
Em breve será lançada a versão 9 do Flash IDE, que irá suportar Actionscript 3.0. Quer isto dizer que será possível desenvolver projectos usando estas duas ferramentas em conjunto, onde o Flash pode ser usado para as animações e efeitos do interface, e por aí adiante, e o Flex para a programação.
Apesar disto já ser possível entre o Flex 2 e o Flash 8, é desaconselhado pois implica um esforço extra para colocar código AS3 a comunicar com AS2.
Workflows
Posto isto, existem então diversas combinações que se podem obter para construir um workflow de desenvolvimento de Rich Internet Applications.
Optando por Actionscript 3.0, pode fazer as seguintes combinações (por exemplo):
Flex 2+AMFPHP+PHP+SGBD
Flex 2+SabreAMF+PHP+SGBD
Flex 2+ColdFusion+SGBD
Flex 2+Fluorine+.NET
Flex 2+Flex Data Services 2+JAVA+SGBD
Flex 2+Flex Data Services 2+Coldfusion+SGBD
…
Isto, se quiser usar implementações de Flash Remoting que suportem AMF3 - que é mais eficiente que o AMF0, e criado especialmente para ser utilizado com Actionscript 3.0.
Se quiser usar AMF0, terá que usar esta classe e poderá fazer mais combinações, como:
Flex2+openAMF+JAVA+SGBD
Flex2+Red5+JAVA+SGBD
…
Se optar por Actionscript 2.0, pode obter todas as combinações acima (trocando Flex 2 por Flash). Em termos estruturais nada muda, excepto a linguagem do lado do cliente.
Desenvolver em Actionscript 3 implica apenas utilizar o compilador da Adobe, independentemente de utilizar só o SDK ou o próprio Flex Builder 2.
No caso do Actionscript 2.0, a coisa não é tão directa: existe um leque enorme de possibilidades que resultam da integração do Flash 8 IDE com várias ferramentas open-source.
Por exemplo, pode-se optar por:
- Desenhar o interface e programar no proprio Flash 8, compilando com o compilador da Macromedia - extremamente desaconselhado
- Desenhar o interface no Flash 8, programar no Eclipse (usando o plugin ASDT) compilando com o compilador MTASC - a opção mais sensata
- Criar a biblioteca de recursos usando o SWFMill que é open-source, programar no Eclipse+ASDT, e compilar com MTASC, cujo workflow se denomina de AMES- a opção 100% open-source e gratuíta
Para obter mais informações sobre desenvolvimento em Flash usando ferramentas open-source consulte www.osflash.org.
No meio de tantas escolhas, qual é a certa? Bem, não há uma resposta certa: de acordo com as características do projecto, com o dinheiro disponível e com os conhecimentos da equipa deverá ser escolhida a solução que mais se adequar ao caso.
Pessoalmente, eu sou adepto de Flex 2+AMFPHP+PHP, que é uma solução bastante equilibrada, simples e gratuíta, e que funciona em qualquer serviço de hosting.
Neste momento ando a investigar Flex 2+Coldfusion, porque aparentemente ir-me-á aumentar a produtividade.
Mas se tivesse dinheiro, a minha aposta seria sem qualquer dúvida a combinação Flex 2+FDS2+Coldfusion ou JAVA.
Já percebi a lógica… mas estas tecnologias permitem usar boas práticas habituais em J2EE?
Apesar de não ser necessário desenhar uma arquitectura ou framework para desenvolver uma RIA, faz sentido esclarecer este ponto.
Se fôr um adepto de Engenharia de Software sabe perfeitamente que é muito complicado construir projectos de média/larga envergadura sem se basear numa arquitectura robusta, baseada em boas práticas. Portanto, neste caso, a pergunta será algo como “posso aplicar arquitecturas e padrões de desenho comuns noutras linguagens (JAVA) a actionscript?“.
A resposta é sim. O Actionscript, especialmente na versão 3.0 possui uma sintaxe e características muito semelhantes ao JAVA. Migrar de JAVA para Actionscript é algo que não é muito complicado: basta perceber o conceito por detrás das RIAs, e estudar um pouco as bibliotecas do Flex SDK. Quer isto dizer que os padrões de desenho e as arquitecturas são facilmente implementáveis em Actionscript.
Aliás, existem duas implementações em Actionscript 2.0 e 3.0 de frameworks de desenvolvimento baseadas em MVC: Cairngorm e ARP. Se for adepto de boas práticas, pode, portanto, construir a sua RIA usando as melhores metodologias de Engenharia de Software.
Se possui um sistema informático baseado em JAVA (ou .NET… ou até PHP) e quiser criar-lhe um front-end que possa ser executado em qualquer computador com um browser e o Flash Player, e se o seu sistema actual assentar numa arquitectura de camadas, basta incorporar no seu sistema a plataforma de Flash Remoting que optar, e “escolher” os serviços da sua camada de negócio que quer expôr para o exterior. Depois é uma questão de implementar a camada de apresentação usando Actionscript.
Em resumo…
Resumindo, se já sabe uma linguagem que possa usar do lado do servidor, apenas terá que perceber como acrescentar Flash Remoting ao seu código (que é algo extremamente fácil independentemente da implementação que escolher), e aprender Actionscript.
Se é algo tão simples porque é que escrevi tanto, quando podia ter explicado só isto?
Ora bem, esta “simplicidade” é resultado de um processo evolutivo no mercado de desenvolvimento de RIAs. Para essa evolução ter ocorrido, foi necessário irem surgindo diversas implementações do Flash Remoting, e outras ferramentas, resultando em muitas opções e escolhas a fazer. Sem a ajuda necessária, será certamente assustador para quem está a entrar neste mundo deparar-se com 1001 ferramentas sem saber para que servem. “Limitei-me” a apresentar algumas das opções possíveis (há mais!) e sugerir algumas escolhas.
Espero que com esta introdução teórica ao desenvolvimento de RIAs tenha ficado com uma ideia geral dos componentes que necessita de juntar para construir uma RIA, e que a partir daqui seja mais simples tomar as suas opções, concentrando a sua investigação nas tecnologias que escolheu.
This entry was written by and posted on December 28, 2006 at 1:47 pm and filed under Flex, Tutoriais. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
Post a comment or leave a trackback: Trackback URL. 
