6. Clientes Flex do serviço JEE de compromissos
Apresentamos agora dois clientes Flex do serviço web JEE de compromissos. O IDE utilizado é o Flex Builder 3. Uma versão de demonstração deste produto pode ser descarregada na URL [https://www.adobe.com/cfusion/tdrc/index.cfm?loc=fr_fr&product=flex]. O Flex Builder 3 é um IDE Eclipse. Além disso, para executar o cliente Flex, utilizamos um servidor web Apache da ferramenta Wamp [http://www.wampserver.com/]. Qualquer servidor Apache serve. O navegador que apresenta o cliente Flex deve dispor do plugin Flash Player, na versão 9, no mínimo.
As aplicações Flex têm a particularidade de serem executadas no plugin Flash Player do navegador. Nesse aspeto, assemelham-se às aplicações Ajax, que incorporam nas páginas enviadas ao navegador scripts JavaScript que são posteriormente executados no próprio navegador. Uma aplicação Flex não é uma aplicação web no sentido em que normalmente se entende: é uma aplicação cliente de serviços fornecidos por servidores web. Nesse aspeto, é análoga a uma aplicação de secretária que fosse cliente desses mesmos serviços. Difere, no entanto, num ponto: é inicialmente descarregada de um servidor web para um navegador que disponha do plugin Flash Player capaz de a executar.
Tal como uma aplicação de secretária, uma aplicação Flex é composta principalmente por dois elementos:
- uma parte de apresentação: as vistas exibidas no navegador. Estas vistas têm a riqueza das janelas das aplicações de secretária. Uma vista é descrita através de uma linguagem de marcadores chamada MXML.
- uma parte de código que gere principalmente os eventos provocados pelas ações do utilizador na vista. Este código pode ser escrito também em MXML ou numa linguagem orientada para objetos chamada ActionScript. É necessário distinguir dois tipos de eventos:
- o evento que requer uma interação com o servidor web: preenchimento de uma lista com dados fornecidos por uma aplicação web, envio dos dados de um formulário para o servidor, etc. O Flex disponibiliza vários métodos para comunicar com o servidor de forma transparente para o programador. Por predefinição, estes métodos são assíncronos: o utilizador pode continuar a interagir com a vista durante a solicitação ao servidor.
- o evento que altera a vista apresentada sem troca de dados com o servidor, por exemplo, arrastar um elemento de uma árvore para o colocar numa lista. Este tipo de evento é tratado inteiramente a nível local, no navegador.
Uma aplicação Flex é frequentemente executada da seguinte forma:
 |
- em [1], é solicitada uma página HTML
- em [2], esta é enviada. Ela inclui um ficheiro binário SWF (ShockWave Flash) que contém a aplicação Flex na íntegra: todas as vistas e o código de gestão dos respetivos eventos. Este ficheiro será executado pelo plugin FlashPlayer do navegador.
 |
- A execução do cliente Flex ocorre localmente no navegador, exceto quando necessita de dados externos. Nesse caso, solicita-os ao servidor [3]. Recebe-os no [4] em diversos formatos: XML ou binário. A aplicação consultada no servidor web pode ser escrita em qualquer linguagem de programação. O que importa é apenas o formato da resposta.
Descrevemos a arquitetura de execução de uma aplicação Flex para que o leitor compreenda bem a diferença entre esta e a de uma aplicação Web clássica, sem Ajax, como a aplicação Asp.Net descrita anteriormente. Nesta última, o navegador é passivo: limita-se a apresentar páginas HTML criadas no servidor Web que lhas envia.
A seguir, apresentamos dois exemplos de clientes Flex com o único objetivo de mostrar a diversidade de clientes de um serviço Web. Sendo o próprio autor um principiante em Flex, alguns pontos poderão não ser abordados com o detalhe que mereceriam.
6.1. Um primeiro cliente Flex
Vamos agora escrever um primeiro cliente Flex para apresentar a lista de clientes. A arquitetura cliente/servidor implementada será a seguinte:
 |
Nesta arquitetura, existem dois servidores web:
- o servidor Glassfish, que executa o serviço web remoto
- o servidor Apache, que executa o cliente Flex do serviço web remoto
Vamos criar o cliente Flex com o IDE Flex Builder 3:
 |
- no Flex Builder 3, criamos um novo projeto em [1]
- atribuímos-lhe um nome em [2] e especificamos em [3] em que pasta o gerar
 |
- em [4], atribui-se um nome à aplicação principal (aquela que será executada)
- em [5], o projeto, uma vez gerado
- em [6], o ficheiro principal da aplicação MXML
- um ficheiro MXML contém uma vista e o código de gestão dos eventos dessa vista. O separador [Source] [7] dá acesso ao ficheiro MXML. Nele encontram-se as balizas <mx> que descrevem a vista, bem como o código ActionScript.
- A vista pode ser criada graficamente utilizando o separador [Design] [8]. As balizas MXML que descrevem a vista são então geradas automaticamente no separador [Source]. O inverso também é verdadeiro: as balizas MXML adicionadas diretamente no separador [Source] são refletidas graficamente no separador [Design].
Tal como foi feito com os clientes C# e Asp.Net anteriores, vamos gerar o proxy local C [B] do serviço web remoto S [A]:
 |
Para que o proxy C possa ser gerado, é necessário que o serviço web JEE esteja ativo.
 |
- em [1], selecione a opção Dados / Importar Serviço Web
- no [2], selecione a pasta de geração das classes e interfaces do proxy C.
 |
- em [3], introduza o URI do ficheiro WSDL do serviço web remoto S (ver parágrafo 4.10.2) e, em seguida, avance para o passo seguinte
- em [4] e [5], o serviço web descrito pelo ficheiro WSDL indicado em [3]
- em [6]: a lista dos métodos que serão gerados para o proxy C. Note-se que estes não são os métodos reais do serviço S. Não têm a assinatura correta. Aqui, cada método apresentado tem um único parâmetro, independentemente do número de parâmetros do método real do serviço web. Este único parâmetro é uma instância de classe que encapsula nos seus campos os parâmetros esperados pelo método remoto.
- em [7]: o pacote no qual as classes e interfaces do proxy C serão geradas
- em [8]: o nome da classe local que funcionará como proxy para o serviço web remoto
- em [9]: concluir o assistente.
- em [10]: a lista das classes e interfaces do proxy C gerado.
 |
- em [11]: a classe [WsDaoJpaService] que implementa os métodos do proxy C.
A classe [WsDaoJpaService] gerada implementa a seguinte interface [IWsDaoJpaService]:
/**
* Service.as
* This file was auto-generated from WSDL by the Apache Axis2 generator modified by Adobe
* Any change made to this file will be overwritten when the code is re-generated.
*/
package generated.webservices{
import mx.rpc.AsyncToken;
import flash.utils.ByteArray;
import mx.rpc.soap.types.*;
public interface IWsDaoJpaService
{
//Funções stub para a operação getAllClients
/**
* Call the operation on the server passing in the arguments defined in the WSDL file
* @param getAllClients
* @return An AsyncToken
*/
function getAllClients(getAllClients:GetAllClients):AsyncToken;
....
function getAllClients_send():AsyncToken;
...
function get getAllClients_lastResult():GetAllClientsResponse;
...
function set getAllClients_lastResult(lastResult:GetAllClientsResponse):void;
...
function addgetAllClientsEventListener(listener:Function):void;
...
function get getAllClients_request_var():GetAllClients_request;
...
function set getAllClients_request_var(request:GetAllClients_request):void;
...
}
}
- linha 11: a interface [IWsDaoJpaService] implementada pela classe [WsDaoJpaService]
- linhas 19-31: os diferentes métodos gerados para o método getAllClients() do serviço web remoto. O único que se aproxima do método efetivamente exposto pelo serviço web é o da linha 19. Tem o nome correto, mas não tem a assinatura correta: o método getAllClients() do serviço web remoto não tem parâmetros.
O único parâmetro do método getAllClients do proxy C gerado é do tipo GetAllClients, conforme se segue:
/**
* GetAllClients.as
* This file was auto-generated from WSDL by the Apache Axis2 generator modified by Adobe
* Any change made to this file will be overwritten when the code is re-generated.
*/
package generated.webservices
{
import mx.utils.ObjectProxy;
import flash.utils.ByteArray;
import mx.rpc.soap.types.*;
/**
* Wrapper class for a operation required type
*/
public class GetAllClients
{
/**
* Constructor, initializes the type class
*/
public function GetAllClients() {}
}
}
Trata-se de uma classe vazia. Isto poderá corresponder ao facto de o método de destino getAllClients não aceitar parâmetros.
Vamos agora analisar as classes geradas para as entidades Medecin, Client, Rv e Creneau. Analisemos, por exemplo, a classe Client:
package generated.webservices
{
import mx.utils.ObjectProxy;
import flash.utils.ByteArray;
import mx.rpc.soap.types.*;
public class Client extends generated.webservices.Personne
{
public function Client() {}
}
}
A classe Client também está vazia. Ela deriva (linha 7) da seguinte classe Personne:
package generated.webservices
{
import mx.utils.ObjectProxy;
import flash.utils.ByteArray;
import mx.rpc.soap.types.*;
public class Personne
{
public function Personne() {}
public var id:Number;
public var nom:String;
public var prenom:String;
public var titre:String;
public var version:Number;
}
}
- linhas 11-15: encontram-se os atributos da classe Personne definida no serviço web JEE.
Temos os principais elementos do proxy C. Podemos agora utilizá-lo.
O ficheiro principal [rdvmedecins01.xml] do cliente é o seguinte:
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical" creationComplete="init();">
<mx:Script>
<![CDATA[
import generated.webservices.Client;
...
// dados
private var ws:WsDaoJpaService;
[Bindable]
private var clients:ArrayCollection;
private function init():void{
...
}
private function loadClients():void{
...
}
...
private function displayClient(client:Client):String{
...
}
]]>
</mx:Script>
<mx:Label text="Liste des clients" fontSize="14"/>
<mx:List dataProvider="{clients}" labelFunction="displayClient"></mx:List>
<mx:Button label="Afficher les clients" click="loadClients()"/>
<mx:Text id="txtMsgErreur" width="454" height="75"/>
</mx:Application>
Neste código, é necessário distinguir vários aspetos:
- a definição da aplicação (linha 2)
- a descrição da sua vista (linhas 27-30)
- os gestores de eventos na linguagem ActionScript dentro da baliza <mx:Script> (linhas 3-26).
Comecemos por comentar a definição da própria aplicação e a descrição da sua vista:
- linha 2: define
- o modo de disposição dos componentes no contentor da vista. O atributo layout="vertical" indica que os componentes ficarão uns abaixo dos outros.
- o método a executar quando a vista for instanciada, c.a.d. o momento em que todos os seus componentes tiverem sido instanciados. O atributo creationComplete="init();" indica que é o método init da linha 13 que deve ser executado. creationComplete é um dos eventos que a classe Application pode emitir.
- As linhas 27 a 30 definem os componentes da vista
- linha 27: define um texto
- linha 28: uma lista na qual será inserida a lista de clientes. A baliza dataProvider="{clients}" indica a fonte dos dados que devem preencher a lista. Aqui, a lista será preenchida com o objeto clients definido na linha 11. Para poder escrever dataProvider="{clients}", é necessário que o campo clients tenha o atributo [Bindable] (linha 10). Este atributo permite que uma variável ActionScript seja referenciada fora da baliza <mx:Script>. O campo clients é do tipo ArrayCollection, um tipo ActionScript que permite armazenar listas de objetos, neste caso uma lista de objetos do tipo Client.
- linha 29: um botão. O seu evento click é gerido. O atributo click="loadClients()" indica que o método loadClients da linha 17 deve ser executado quando se clicar no botão. Será este botão que desencadeará o pedido ao serviço web para obter a lista de clientes.
- linha 30: uma caixa de texto destinada a apresentar uma eventual mensagem de erro que possa ser devolvida pelo servidor em resposta à solicitação anterior.
As linhas 27-30 geram a seguinte visualização no separador [Design]:
 |
- [1]: foi gerado pelo componente Label da linha 27
- [2]: foi gerado pelo componente List da linha 28
- [3]: foi gerado pelo componente Button da linha 29
- [4]: foi gerado pelo componente Text da linha 30
- [5]: um exemplo de execução
Vamos agora analisar o código ActionScript da página. Este código gere os eventos da vista.
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical" creationComplete="init();">
<mx:Script>
<![CDATA[
import generated.webservices.Client;
...
// dados
private var ws:WsDaoJpaService;
[Bindable]
private var clients:ArrayCollection;
private function init():void{
// instancia-se o proxy do serviço web
ws=new WsDaoJpaService();
// configura-se os gestores de eventos
ws.addgetAllClientsEventListener(loadClientsCompleted);
ws.addEventListener(FaultEvent.FAULT,loadClientsFault);
}
private function loadClients():void{
// solicita-se a lista de clientes
ws.getAllClients(new GetAllClients());
}
private function loadClientsCompleted(event:GetAllClientsResultEvent):void{
// recuperam-se os clientes no resultado enviado
clients=event.result as ArrayCollection;
}
private function loadClientsFault(event:FaultEvent):void{
// exibe-se a mensagem de erro
txtMsgErreur.text=event.fault.message;
}
private function displayClient(client:Client):String{
// exibe-se um cliente
return client.nom + " " + client.prenom;
}
]]>
</mx:Script>
<mx:Label text="Liste des clients" fontSize="14"/>
<mx:List dataProvider="{clients}" labelFunction="displayClient"></mx:List>
<mx:Button label="Afficher les clients" click="loadClients()"/>
<mx:Text id="txtMsgErreur" width="454" height="75"/>
- linha 9: ws irá designar o proxy C do tipo WsDaoJpaService, a classe gerada anteriormente que implementa os métodos de acesso ao serviço web remoto.
- linha 13: o método init executado quando a vista foi instanciada (linha 1)
- linha 15: é criada uma instância do proxy C
- linha 17: é associado um gestor de eventos ao evento «o método assíncrono GetAllClients foi concluído com sucesso». Para qualquer método m do serviço web remoto, o proxy C implementa um método addmEventListener que permite associar um gestor ao evento «o método assíncrono m foi concluído com sucesso». Aqui, a linha 17 indica que o método loadClientsCompleted da linha 26 deve ser executado quando o cliente Flex tiver recebido a lista de clientes.
- linha 18: um manipulador de eventos está associado ao evento «um método assíncrono do proxy C terminou com falha». Aqui, a linha 18 indica que o método loadClientsFault da linha 31 deve ser executado sempre que uma solicitação assíncrona do proxy C para o serviço web S falhar. Neste caso, a única solicitação que será efetuada é a que pede a lista de clientes.
- Por fim, o método init da linha 13 instanciou o proxy C e definiu gestores de eventos para a solicitação assíncrona que será efetuada posteriormente.
- linha 21: o método executado ao clicar no botão [Afficher les clients] (linha 44)
- linha 23: o método assíncrono getAllClients do proxy C é executado. É-lhe passada uma instância GetAllClients encarregada de encapsular os parâmetros do método remoto chamado. Aqui, não há nenhum parâmetro. É criada uma instância vazia. O método getAllClients é assíncrono. A execução prossegue sem aguardar os dados devolvidos pelo servidor. O utilizador pode, nomeadamente, continuar a interagir com a vista. Os eventos por ele provocados continuarão a ser geridos. Graças ao método init, sabemos que:
- o método loadClientsCompleted (linha 26) será executado quando o cliente Flex tiver recebido a lista de clientes
- o método loadClientsFault (linha 31) será executado se a solicitação terminar com um erro.
- linha 28: a lista de clientes é recuperada no evento. Sabemos que o método getAllClients do serviço web remoto devolve uma lista. Colocamos essa lista no campo clients da linha 11. É necessária uma conversão de tipo. Como a lista da linha 43 está associada (Bindable) ao campo «clientes», é notificada de que os seus dados foram alterados. Em seguida, apresenta a lista de clientes. Irá apresentar cada elemento da lista clients utilizando o método displayClient (linha 43).
- linha 36: o método displayClient recebe um tipo Client. Deve devolver a cadeia de caracteres que a lista deve apresentar para este cliente. Neste caso, o nome e o apelido (linha 38).
- linha 31: o método executado quando uma solicitação ao serviço web falha. Recebe um parâmetro do tipo FaultEvent. Esta classe possui um campo fault que encapsula o erro devolvido pelo servidor. fault.message é a mensagem que acompanha o erro.
- linha 33: a mensagem de erro é apresentada na caixa de texto destinada a esse efeito.
Quando a aplicação foi compilada, o seu código executável encontra-se na pasta [bin-debug] do projeto Flex:
 |
Acima,
- o ficheiro [rdvmedecins01.html] representa o ficheiro HTML que será solicitado pelo navegador ao servidor web para obter o cliente Flex
- o ficheiro [rdvmedecins01.swf] é o binário do cliente Flex que será encapsulado na página HTML enviada ao navegador e, posteriormente, executado pelo plugin Flash Player deste.
Estamos prontos para executar o cliente Flex. Antes disso, temos de configurar o ambiente de execução necessário para o mesmo. Voltemos à arquitetura cliente/servidor testada:
 |
Do lado do servidor:
- inicie o SGBD MySQL
- iniciar o servidor Glassfish
- implementar o serviço web JEE de compromissos, caso ainda não esteja implementado
- se necessário, testar um dos clientes anteriores para verificar se tudo está a funcionar corretamente no lado do servidor.
Do lado do cliente:
Iniciar o servidor Apache ao qual será solicitada a aplicação Flex. Aqui, utilizamos a ferramenta Wamp. Com esta ferramenta, podemos associar um alias à pasta [bin-debug] do projeto Flex.
 |
- o ícone do Wamp encontra-se na parte inferior do ecrã [1]
- com um clique do botão esquerdo no ícone Wamp, selecione a opção Apache [2] / Alias Directories [3, 4]
- selecione a opção [5]: Adicionar um alias
 |
- em [6], atribuir um alias (qualquer nome) à aplicação web que vai ser executada
- em [7], indicar a raiz da aplicação web que terá esse alias: trata-se da pasta [bin-debug] do projeto Flex que acabámos de criar.
Recorde-se a estrutura da pasta [bin-debug] do projeto Flex:
 |
O ficheiro [rdvmedecins01.html] é o ficheiro HTML da aplicação Flex. Graças ao alias que acabámos de criar na pasta [bin-debug], este ficheiro poderá ser acedido através do URL [http://localhost/rdvmedecins/rdvmedecins01.html]. Acedemos a esta URL num navegador que tenha instalado o plugin Flash Player versão 9 ou superior:
 |
- em [1], a URL da aplicação Flex
- em [2], solicitamos a lista de clientes
- em [3], o resultado obtido quando tudo corre bem
- em [4], o resultado obtido quando solicitamos a exibição dos clientes, embora o serviço web tenha sido interrompido.
Talvez tenha curiosidade em ver o código-fonte da página HTML recebida
O corpo da página começa na linha 39. Não contém HTML clássico, mas sim um objeto (linha 47) do tipo «application/x-shockwave-flash» (linha 60). Trata-se do ficheiro [rdvmedecins01.swf] (linha 54), que pode ser visto na pasta [bin-debug] do projeto Flex. É um ficheiro de tamanho considerável: cerca de 600 K para este exemplo simples.
6.2. Um segundo cliente Flex
O segundo cliente Flex não irá utilizar o proxy C gerado para o primeiro. Pretendemos demonstrar que esta etapa não é indispensável, embora apresente vantagens em relação à que será apresentada aqui.
O projeto evolui da seguinte forma:
 |
- em [1], a nova aplicação Flex
- em [2], os executáveis que lhe estão associados
- em [3], a nova vista: vamos apresentar a lista de médicos.
O código MXML da aplicação [rdvmedecins02.mxml] é o seguinte:
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical">
<mx:Script>
<![CDATA[
import mx.rpc.events.ResultEvent;
import mx.rpc.events.FaultEvent;
import mx.collections.ArrayCollection;
// dados
[Bindable]
private var medecins:ArrayCollection;
private function loadMedecins():void{
// Solicita-se a lista de médicos
wsrdvmedecins.getAllMedecins.send();
}
private function loadMedecinsCompleted(event:ResultEvent):void{
// Recuperam-se os médicos
medecins=event.result as ArrayCollection;
}
private function loadMedecinsFault(event:FaultEvent):void{
// exibe a mensagem de erro
txtMsgErreur.text=event.fault.message;
}
// exibição de um médico
private function displayMedecin(medecin:Object):String{
return medecin.nom + " " + medecin.prenom;
}
]]>
</mx:Script>
<mx:WebService id="wsrdvmedecins"
wsdl="http://localhost:8080/serveur-webservice-ejb-dao-jpa-hibernate/WsDaoJpaService?wsdl">
<mx:operation name="getAllMedecins"
result="loadMedecinsCompleted(event)" fault="loadMedecinsFault(event);">
<mx:request/>
</mx:operation>
</mx:WebService>
<mx:Label text="Liste des médecins" fontSize="14"/>
<mx:List dataProvider="{medecins}" labelFunction="displayMedecin"></mx:List>
<mx:Button label="Afficher les médecins" click="loadMedecins()"/>
<mx:Text id="txtMsgErreur" width="300" height="113"/>
</mx:Application>
Iremos comentar apenas as novidades:
- linhas 42 - 45: a nova vista. É idêntica à anterior, exceto pelo facto de ter sido adaptada para apresentar os médicos em vez dos clientes.
- linhas 35-41: o serviço web é aqui descrito por uma baliza <mx:WebService> (linha 35). O proxy C utilizado na versão anterior já não é utilizado aqui.
- linha 35: o atributo id atribui um nome ao serviço web.
- linha 36: o atributo wsdl indica a URI do ficheiro WSDL do serviço web. Trata-se da mesma URI utilizada pelo cliente anterior e definida no parágrafo 4.10.2.
- linhas 37-40: definem um método do serviço web remoto através da baliza <mx:operation>
- linha 37: o método referenciado é definido pelo atributo name. Aqui, referenciamos o método remoto getAllMedecins.
- linha 38: definem-se os métodos a executar em caso de sucesso da operação (atributo result) e em caso de falha (atributo fault).
- linha 39: a baliza <mx:request> serve para definir os parâmetros da operação. Neste caso, o método remoto getAllMedecins não tem parâmetros, pelo que não indicamos nada. Para um método que admita os parâmetros param1 e param2, escrever-se-ia:
onde param1 e param2 seriam variáveis declaradas e inicializadas na baliza <mx:Script>
Na baliza <mx:Script> encontra-se código ActionScript semelhante ao analisado no cliente anterior. A única diferença reside no método loadMedecins, nas linhas 13 a 16. O que difere é o modo de chamada do método remoto [getAllMedecins]:
- linha 15: utiliza-se o serviço web [wsrdvmedecins] definido na linha 35 e a sua operação [getAllMedecins] definida na linha 37. Para executar esta operação, utiliza-se o método send. É este método que inicia a chamada assíncrona do método getAllMedecins do serviço web definido na linha 35. O método send efetuará a chamada com os parâmetros definidos pela baliza <mx:request> da linha 39. Neste caso, não há parâmetros. Se o método tivesse os parâmetros param1 e param2, o script loadMedecins teria atribuído valores a esses parâmetros antes de chamar o método send.
Resta-nos apenas testar esta nova aplicação:
 |