6. Clientes Flex para o Serviço de Marcação de Consultas JEE
Apresentamos agora dois clientes Flex para o serviço web JEE de marcação de consultas. O IDE utilizado é o Flex Builder 3. Uma versão de demonstração deste produto pode ser descarregada a partir do 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 é compatível. O navegador que exibe o cliente Flex deve ter o Flash Player versão 9 ou superior instalado.
As aplicações Flex são únicas, na medida em que são executadas no plugin Flash Player do navegador. Nesse aspeto, são semelhantes às aplicações Ajax, que incorporam scripts JavaScript nas páginas enviadas para o navegador, os quais são depois executados no próprio navegador. Uma aplicação Flex não é uma aplicação web no sentido habitual: é uma aplicação cliente para serviços fornecidos por servidores web. Nesse sentido, é análoga a uma aplicação de ambiente de trabalho que atua como cliente para esses mesmos serviços. Difere, no entanto, num aspeto: é inicialmente descarregada de um servidor web para um navegador equipado com o plugin Flash Player capaz de a executar.
Tal como uma aplicação de ambiente de trabalho, uma aplicação Flex consiste principalmente em dois elementos:
- uma camada de apresentação: as vistas exibidas no navegador. Estas vistas oferecem a mesma riqueza que as janelas de aplicações de ambiente de trabalho. Uma vista é descrita utilizando uma linguagem de marcação chamada MXML.
- um componente de código que lida principalmente com eventos desencadeados por ações do utilizador na vista. Este código também pode ser escrito em MXML ou numa linguagem orientada para objetos chamada ActionScript. É necessário distinguir dois tipos de eventos:
- eventos que requerem comunicação com o servidor web: preencher uma lista com dados fornecidos por uma aplicação web, enviar dados de formulário para o servidor, etc. O Flex fornece vários métodos para comunicar com o servidor de uma forma transparente para o programador. Estes métodos são assíncronos por predefinição: o utilizador pode continuar a interagir com a vista enquanto o pedido ao servidor está em curso.
- eventos que modificam a vista apresentada sem trocar dados com o servidor, como arrastar um item de uma árvore e soltá-lo numa lista. Este tipo de evento é tratado inteiramente a nível local, dentro do navegador.
Uma aplicação Flex é frequentemente executada da seguinte forma:
 |
- em [1], é solicitada uma página HTML
- Em [2], esta é enviada. Inclui um ficheiro binário SWF (ShockWave Flash) que contém toda a aplicação Flex: todas as vistas e o seu código de tratamento de eventos. Este ficheiro será executado pelo plugin Flash Player do navegador.
 |
- O cliente Flex é executado localmente no navegador, exceto quando necessita de dados externos. Nesse caso, solicita-os ao servidor [3]. Recebe-os em [4] em vários formatos: XML ou binário. A aplicação consultada no servidor web pode ser escrita em qualquer linguagem. Apenas o formato da resposta é relevante.
Descrevemos a arquitetura de execução de uma aplicação Flex para que o leitor possa compreender claramente a diferença entre esta e a de uma aplicação web tradicional, 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 as envia para o navegador.
Nas secções seguintes, apresentamos dois exemplos de clientes Flex com o único objetivo de demonstrar a diversidade de clientes para um serviço web. Uma vez que o próprio autor é um principiante em Flex, alguns pontos podem não ser explicados com o detalhe que mereceriam.
6.1. Um primeiro cliente Flex
Vamos agora criar um primeiro cliente Flex para apresentar a lista de clientes. A arquitetura cliente/servidor que iremos implementar é 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 para o serviço web remoto
Estamos a desenvolver o cliente Flex utilizando o IDE Flex Builder 3:
 |
- No Flex Builder 3, crie um novo projeto em [1]
- damos-lhe um nome em [2] e especificamos em [3] em que pasta o queremos gerar
 |
- em [4], nomeamos a aplicação principal (aquela que será executada)
- em [5], o projeto uma vez gerado
- em [6], o ficheiro MXML principal da aplicação
- Um ficheiro MXML contém uma vista e o código de tratamento de eventos para essa vista. O separador [Source] [7] dá acesso ao ficheiro MXML. Aí encontrará tags <mx> que descrevem a vista, bem como código ActionScript.
- A vista pode ser criada graficamente utilizando o separador [Design] [8]. As tags MXML que descrevem a vista são então geradas automaticamente no separador [Source]. O inverso também é verdadeiro: as tags 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, iremos gerar o proxy C local [B] para o serviço web remoto S [A]:
 |
Para que o proxy C seja gerado, o serviço web JEE deve estar ativo.
 |
- Em [1], selecione a opção Dados / Importar Serviço Web
- Em [2], selecione a pasta para gerar as classes e interfaces proxy C.
 |
- Em [3], introduza o URI do ficheiro WSDL para o serviço web remoto S (ver secção 4.10.2) e, em seguida, avance para o passo seguinte
- Em [4] e [5], o serviço web descrito pelo ficheiro WSDL especificado em [3]
- Em [6]: a lista de métodos que serão gerados para o proxy C. Note que estes não são os métodos reais do serviço S. Eles não têm a assinatura correta. Aqui, cada método listado tem um único parâmetro, independentemente do número de parâmetros no método real do serviço web. Este único parâmetro é uma instância de classe que encapsula os parâmetros esperados pelo método remoto nos seus campos.
- em [7]: o pacote no qual as classes e interfaces do proxy C serão geradas
- em [8]: o nome da classe local que atuará como proxy para o serviço web remoto
- em [9]: conclua o assistente.
- em [10]: a lista de 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
{
//Stub functions for the getAllClients operation
/**
* 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 vários métodos gerados para o método getAllClients() do serviço web remoto. O único que corresponde de perto ao método efetivamente exposto pelo serviço web é o da linha 19. Tem o nome correto, mas não 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 no proxy C gerado é do seguinte tipo GetAllClients:
/**
* 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() {}
}
}
Esta é uma classe vazia. Isso pode dever-se ao facto de o método de destino getAllClients não aceitar quaisquer parâmetros.
Agora, vamos examinar as classes geradas para as entidades Doctor, Client, Appointment e Time Slot. Vejamos, 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 Person:
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: Estes são os atributos da classe Person definidos no serviço web JEE.
Agora temos os principais elementos do proxy C. Podemos agora utilizá-lo.
O ficheiro principal do cliente [rdvmedecins01.xml] é 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;
...
// données
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, devem ser distinguidos vários elementos:
- a definição da aplicação (linha 2)
- a descrição da sua vista (linhas 27–30)
- os manipuladores de eventos ActionScript dentro da tag <mx:Script> (linhas 3–26).
Comecemos por discutir a definição da própria aplicação e a descrição da sua visualização:
- linha 2: define
- o layout dos componentes dentro do contêiner da visualização. O atributo layout="vertical" indica que os componentes serão dispostos um abaixo do outro.
- o método a ser executado quando a vista tiver sido instanciada, ou seja, quando todos os seus componentes tiverem sido instanciados. O atributo creationComplete="init();" indica que o método init na linha 13 deve ser executado. creationComplete é um dos eventos que a classe Application pode emitir.
- As linhas 27–30 definem os componentes da vista
- Linha 27: define um texto
- Linha 28: uma lista que irá conter a lista de clientes. A tag dataProvider="{clients}" especifica a fonte de dados que irá preencher a lista. Aqui, a lista será preenchida com o objeto clients definido na linha 11. Para poder escrever dataProvider="{clients}", o campo clients deve ter o atributo [Bindable] (linha 10). Este atributo permite que uma variável ActionScript seja referenciada fora da tag <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 é tratado. O atributo click="loadClients()" indica que o método loadClients na linha 17 deve ser executado quando o botão for clicado. Este botão irá desencadear o pedido ao serviço web para a lista de clientes.
- Linha 30: uma caixa de texto destinada a exibir qualquer mensagem de erro que possa ser devolvida pelo servidor em resposta ao pedido anterior.
As linhas 27–30 geram a seguinte vista no separador [Design]:
 |
- [1]: gerado pelo componente Label na linha 27
- [2]: gerado pelo componente List na linha 28
- [3]: gerado pelo componente Button na linha 29
- [4]: gerado pelo componente Text na linha 30
- [5]: um exemplo de execução
Vamos agora examinar o código ActionScript da página. Este código trata dos eventos da vista.
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical" creationComplete="init();">
<mx:Script>
<![CDATA[
import generated.webservices.Client;
...
// données
private var ws:WsDaoJpaService;
[Bindable]
private var clients:ArrayCollection;
private function init():void{
// on instancie le proxy du service web
ws=new WsDaoJpaService();
// on configure les gestionnaires d'évts
ws.addgetAllClientsEventListener(loadClientsCompleted);
ws.addEventListener(FaultEvent.FAULT,loadClientsFault);
}
private function loadClients():void{
// on demande la liste des clients
ws.getAllClients(new GetAllClients());
}
private function loadClientsCompleted(event:GetAllClientsResultEvent):void{
// on récupère les clients dans le résultat envoyé
clients=event.result as ArrayCollection;
}
private function loadClientsFault(event:FaultEvent):void{
// on affiche le msg d'erreur
txtMsgErreur.text=event.fault.message;
}
private function displayClient(client:Client):String{
// on affiche un client
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 refere-se ao proxy C do tipo WsDaoJpaService, a classe gerada anteriormente que implementa os métodos para aceder ao serviço web remoto.
- linha 13: o método init é executado quando a vista é instanciada (linha 1)
- linha 15: é criada uma instância do proxy C
- linha 17: um manipulador de eventos é associado 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 que um manipulador de eventos seja associado ao evento «o método assíncrono m foi concluído com sucesso». Aqui, a linha 17 indica que o método loadClientsCompleted na 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 foi concluído com falha». Aqui, a linha 18 indica que o método loadClientsFault na linha 31 deve ser executado sempre que uma solicitação assíncrona do proxy C para o serviço web S falhar. Aqui, a única solicitação que será feita é a que solicita a lista de clientes.
- Por fim, o método init na linha 13 instanciou o proxy C e definiu manipuladores de eventos para a solicitação assíncrona que será feita posteriormente.
- Linha 21: O método executado quando o botão [Exibir Clientes] (linha 44) é clicado
- Linha 23: O método assíncrono getAllClients do proxy C é executado. É-lhe passada uma instância GetAllClients responsável por encapsular os parâmetros do método remoto chamado. Aqui, não há parâmetros. É criada uma instância vazia. O método getAllClients é assíncrono. A execução continua sem esperar pelos dados devolvidos pelo servidor. Em particular, o utilizador pode continuar a interagir com a vista. Os eventos acionados pelo utilizador continuarão a ser tratados. 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 em erro.
- Linha 28: A lista de clientes é recuperada do evento. Sabemos que o método getAllClients do serviço web remoto devolve uma lista. Colocamos esta lista no campo clients na linha 11. É necessária uma conversão de tipo. Uma vez que a lista na linha 43 está ligada ao campo clients, este é notificado de que os seus dados foram alterados. Em seguida, apresenta a lista de clientes. Apresentará cada item da lista de clientes utilizando o método displayClient (linha 43).
- Linha 36: O método displayClient aceita um tipo Client. Deve devolver a cadeia de caracteres que a lista deve apresentar para este cliente. Aqui, 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 é exibida na caixa de texto prevista para esse efeito.
Depois de a aplicação ter sido 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 o navegador irá solicitar ao servidor web para obter o cliente Flex
- o ficheiro [rdvmedecins01.swf] é o binário do cliente Flex que será incorporado na página HTML enviada ao navegador e, em seguida, executado pelo plugin Flash Player do navegador.
Estamos prontos para executar o cliente Flex. Primeiro, precisamos de configurar o ambiente de execução necessário para o mesmo. Voltemos à arquitetura cliente/servidor que testámos:
 |
Lado do servidor:
- Inicie o SGBD MySQL
- Inicie o servidor GlassFish
- Implemente o serviço web JEE para marcações, caso ainda não esteja implementado
- Opcionalmente, teste um dos clientes anteriores para verificar se tudo está a funcionar corretamente no lado do servidor.
Lado do cliente:
Inicie o servidor Apache que irá hospedar a aplicação Flex. Aqui estamos a utilizar a ferramenta Wamp. Com esta ferramenta, podemos atribuir um alias à pasta [bin-debug] do projeto Flex.
 |
- O ícone do Wamp encontra-se na parte inferior do ecrã [1]
- Clique com o botão esquerdo do rato no ícone do Wamp, selecione a opção Apache [2] / Diretórios de alias [3, 4]
- Selecione a opção [5]: Adicionar um alias
 |
- Em [6], atribua um alias (qualquer nome) à aplicação web que será executada
- Em [7], especifique a raiz da aplicação web que utilizará este alias: trata-se da pasta [bin-debug] do projeto Flex que acabámos de compilar.
Vamos rever a estrutura da pasta [bin-debug] no projeto Flex:
 |
O ficheiro [rdvmedecins01.html] é o ficheiro HTML da aplicação Flex. Graças ao alias que acabámos de criar para a pasta [bin-debug], este ficheiro pode ser acedido através do URL [http://localhost/rdvmedecins/rdvmedecins01.html]. Acedemos a este URL num navegador com 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 funciona corretamente
- em [4], o resultado obtido quando solicitamos a lista de clientes, mesmo que o serviço web tenha sido interrompido.
Talvez esteja curioso para 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 padrão, mas sim um objeto (linha 47) do tipo "application/x-shockwave-flash" (linha 60). Este é o ficheiro [rdvmedecins01.swf] (linha 54) que se encontra na pasta [bin-debug] do projeto Flex. É um ficheiro de grande dimensão: aproximadamente 600 KB para este exemplo simples.
6.2. Um segundo cliente Flex
O segundo cliente Flex não utilizará o proxy C gerado para o primeiro. Pretendemos demonstrar que este passo não é essencial, apesar de oferecer vantagens em relação à abordagem que iremos apresentar aqui.
O projeto evolui da seguinte forma:
 |
- em [1] a nova aplicação Flex
- em [2] os executáveis associados
- em [3] a nova vista: iremos apresentar a lista de médicos.
O código MXML para a 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;
// données
[Bindable]
private var medecins:ArrayCollection;
private function loadMedecins():void{
// on demande la liste des médecins
wsrdvmedecins.getAllMedecins.send();
}
private function loadMedecinsCompleted(event:ResultEvent):void{
// on récupère les médecins
medecins=event.result as ArrayCollection;
}
private function loadMedecinsFault(event:FaultEvent):void{
// on affiche le msg d'erreur
txtMsgErreur.text=event.fault.message;
}
// affichage d'un médecin
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 novas funcionalidades:
- linhas 42–45: a nova vista. É idêntica à anterior, exceto pelo facto de ter sido adaptada para apresentar médicos em vez de clientes.
- linhas 35–41: O serviço web é descrito aqui por uma tag <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 especifica o URI do ficheiro WSDL do serviço web. Este é o mesmo URI utilizado pelo cliente anterior e definido na secção 4.10.2.
- Linhas 37–40: definem um método do serviço web remoto utilizando a tag <mx:operation>
- Linha 37: O método referenciado é definido pelo atributo name. Aqui referenciamos o método remoto getAllMedecins.
- Linha 38: definimos os métodos a serem executados se a operação for bem-sucedida (atributo result) e se falhar (atributo fault).
- Linha 39: a tag <mx:request> é utilizada para definir os parâmetros da operação. Aqui, o método remoto getAllMedecins não tem parâmetros, pelo que o deixamos em branco. Para um método que aceita os parâmetros param1 e param2, escreveríamos:
onde param1 e param2 seriam variáveis declaradas e inicializadas dentro da tag <mx:Script>
Dentro da tag <mx:Script>, existe código ActionScript semelhante ao estudado no cliente anterior. A única diferença é o método loadMedecins nas linhas 13–16. É a forma como o método remoto [getAllMedecins] é chamado que difere:
- linha 15: utilizamos 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 inicia a chamada assíncrona ao método getAllMedecins do serviço web definido na linha 35. O método send efetuará a chamada com os parâmetros definidos pela tag <mx:request> na linha 39. Aqui, 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 apenas testar esta nova aplicação:
 |