Skip to content

6. Clientes Flex do serviço JEE de agendamentos

Apresentamos agora dois clientes Flex do serviço web JEE de agendamentos. O IDE utilizado é o Flex Builder 3. Uma versão de demonstração desse produto pode ser baixada no 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 para esse fim. O navegador que exibe o cliente Flex deve ter o plugin Flash Player, versão 9 no mínimo.

As aplicações Flex têm a particularidade de serem executadas dentro do plug-in Flash Player do navegador. Nesse aspecto, elas se assemelham às aplicações Ajax, que incorporam nas páginas enviadas ao navegador scripts JavaScript que são, em seguida, executados dentro do 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 aspecto, ela é análoga a uma aplicação de desktop que seria cliente desses mesmos serviços. No entanto, ela difere em um ponto: é baixada inicialmente de um servidor web para um navegador que possua o plug-in Flash Player capaz de executá-la.

Assim como um aplicativo de desktop, um aplicativo Flex é composto principalmente por dois elementos:

  • uma parte de apresentação: as visualizações exibidas no navegador. Essas visualizações possuem a riqueza das janelas dos aplicativos de desktop. Uma visualização é descrita por meio de uma linguagem de marcação chamada MXML.
  • uma parte de código que gerencia principalmente os eventos provocados pelas ações do usuário na visualização. Esse código também pode ser escrito em MXML ou em uma linguagem orientada a objetos chamada ActionScript. É preciso distinguir dois tipos de eventos:
  • o evento que requer uma interação com o servidor web: preenchimento de uma lista com dados fornecidos por um aplicativo web, envio dos dados de um formulário ao servidor, etc. O Flex oferece vários métodos para se comunicar com o servidor de forma transparente para o desenvolvedor. Esses métodos são, por padrão, assíncronos: o usuário pode continuar interagindo com a visualização durante a solicitação ao servidor.
  • o evento que altera a visualização exibida sem troca de dados com o servidor, por exemplo, arrastar um elemento de uma árvore para soltá-lo em uma lista. Esse tipo de evento é totalmente processado localmente no navegador.

Um aplicativo Flex é frequentemente executado da seguinte maneira:

  • em [1], uma página HTML é solicitada
  • em [2], ela é enviada. Ela traz consigo um arquivo binário SWF (ShockWave Flash) contendo a aplicação Flex na íntegra: todas as visualizações e o código de gerenciamento de eventos delas. Esse arquivo será executado pelo plug-in FlashPlayer do navegador.
  • A execução do cliente Flex ocorre localmente no navegador, exceto quando ele precisa de dados externos. Nesse caso, ele os solicita ao servidor [3]. Ele os recebe no [4] em diversos formatos: XML ou binário. O aplicativo consultado no servidor web pode ser escrito em qualquer linguagem. O que importa é apenas o formato da resposta.

Descrevemos a arquitetura de execução de um aplicativo Flex para que o leitor compreenda bem a diferença entre ela e a de um aplicativo web clássico, sem Ajax, como o aplicativo Asp.Net descrito anteriormente. Neste último, o navegador é passivo: ele simplesmente exibe páginas HTML criadas no servidor web, que as envia para ele.

A seguir, apresentamos dois exemplos de clientes Flex com o único objetivo de mostrar a diversidade de clientes de um serviço web. Como o autor também é iniciante em Flex, alguns pontos talvez não sejam detalhados como deveriam.

6.1. Um primeiro cliente Flex

Vamos agora escrever um primeiro cliente Flex para exibir a lista de clientes. A arquitetura cliente/servidor implementada será a seguinte:

Nessa arquitetura, há 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 Flex Builder 3 (IDE):

  • no Flex Builder 3, criamos um novo projeto em [1]
  • atribuímos um nome a ele em [2] e especificamos em [3] em qual pasta ele deve ser gerado
  • em [4], atribui-se um nome ao aplicativo principal (aquele que será executado)
  • em [5], o projeto, uma vez gerado
  • em [6], o arquivo principal da aplicação MXML
  • um arquivo MXML contém uma visualização e o código de gerenciamento de eventos dessa visualização. A aba [Source] [7] dá acesso ao arquivo MXML. Nela, encontram-se as tags <mx> que descrevem a visualização, bem como o código ActionScript.
  • A visualização pode ser criada graficamente usando a guia [Design] [8]. As tags MXML que descrevem a visualização são, então, geradas automaticamente na guia [Source]. O inverso também é verdadeiro: as tags MXML adicionadas diretamente na guia [Source] são refletidas graficamente na guia [Design].

Assim 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 em C possa ser gerado, é necessário que o serviço web JEE esteja ativo.

  • no [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.
  • no [3], insira a URI do arquivo WSDL do serviço web remoto S (consulte o parágrafo 4.10.2) e, em seguida, passe para a etapa seguinte
  • em [4] e [5], o serviço web descrito pelo arquivo WSDL indicado em [3]
  • em [6]: a lista de métodos que serão gerados para o proxy C. Observe-se que esses não são os métodos reais do serviço S. Eles não possuem a assinatura correta. Aqui, cada método apresentado possui um único parâmetro, independentemente do número de parâmetros do método real do serviço web. Esse único parâmetro é uma instância de classe que encapsula, em 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 atuará 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 diversos métodos gerados para o método getAllClients() do serviço web remoto. O único que se aproxima daquele realmente exposto pelo serviço web é o da linha 19. Ele tem o nome correto, mas não possui a assinatura correta: o método getAllClients() do serviço web remoto não possui parâmetros.

O único parâmetro do método getAllClients do proxy C gerado é do tipo GetAllClients, conforme 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. Isso pode corresponder ao fato de que o método de destino getAllClients não aceita parâmetros.

Agora, vamos examinar as classes geradas para as entidades Medecin, Client, Rv e Creneau. 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 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: encontramos os atributos da classe Personne definida no serviço web JEE.

Temos os principais elementos do proxy C. Agora podemos utilizá-lo.

O arquivo 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>

Nesse código, é preciso distinguir vários elementos:

  • a definição do aplicativo (linha 2)
  • a descrição da visualização da aplicação (linhas 27-30)
  • os manipuladores de eventos na linguagem ActionScript dentro da tag <mx:Script> (linhas 3 a 26).

Vamos começar comentando a definição da própria aplicação e a descrição de sua visualização:

  • linha 2: define
    • o modo de disposição dos componentes no contêiner da visualização. O atributo layout="vertical" indica que os componentes ficarão uns abaixo dos outros.
    • o método a ser executado quando a visualização 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 deve ser executado. creationComplete é um dos eventos que a classe Application pode emitir.
  • As linhas 27 a 30 definem os componentes da visualização
  • linha 27: define um texto
  • linha 28: uma lista na qual será inserida a lista de clientes. A tag 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). Esse 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. Seu evento click é gerenciado. O atributo click="loadClients()" indica que o método loadClients da linha 17 deve ser executado ao clicar no botão. Será esse botão que acionará a solicitação ao serviço web para obter a lista de clientes.
  • linha 30: um campo de texto destinado a exibir uma eventual mensagem de erro que possa ser retornada pelo servidor em resposta à solicitação anterior.

As linhas 27 a 30 geram a seguinte visualização na guia [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 examinar o código ActionScript da página. Esse código gerencia os eventos da visualização.


<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 gerenciadores 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 a mensagem de erro
                txtMsgErreur.text=event.fault.message;
            }
            
            private function displayClient(client:Client):String{
                // exibe 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 visualização é 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 associar um manipulador 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 receber a lista de clientes.
  • linha 18: um manipulador de evento 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 da 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 é aquela que solicita a lista de clientes.
  • Por fim, o método init da 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 ao clicar no botão [Afficher les clients] (linha 44)
  • linha 23: o método assíncrono getAllClients do proxy C é executado. É passada a ele 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 retornados pelo servidor. O usuário pode, portanto, continuar a interagir com a visualização. Os eventos por ele provocados continuarão a ser gerenciados. Graças ao método init, sabemos que:
    • o método loadClientsCompleted (linha 26) será executado quando o cliente Flex receber 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 retorna 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á vinculada (Bindable) ao campo “clientes”, ela é notificada de que seus dados foram alterados. Em seguida, ela exibe a lista de clientes. Ela exibirá cada elemento da lista clients utilizando o método displayClient (linha 43).
  • linha 36: o método displayClient recebe um tipo Client. Ele deve retornar a sequência de caracteres que a lista deve exibir para esse cliente. Neste caso, o nome e o sobrenome (linha 38).
  • linha 31: o método executado quando uma solicitação ao serviço web falha. Ele recebe um parâmetro do tipo FaultEvent. Essa classe possui um campo fault que encapsula o erro retornado pelo servidor. fault.message é a mensagem que acompanha o erro.
  • linha 33: a mensagem de erro é exibida na área de texto destinada a esse fim.

Quando o aplicativo foi compilado, seu código executável fica na pasta [bin-debug] do projeto Flex:

Acima,

  • o arquivo [rdvmedecins01.html] representa o arquivo HTML que será solicitado pelo navegador ao servidor web para obter o cliente Flex
  • o arquivo [rdvmedecins01.swf] é o binário do cliente Flex que será encapsulado na página HTML enviada ao navegador e, em seguida, executado pelo plug-in Flash Player deste.

Estamos prontos para executar o cliente Flex. Antes disso, precisamos configurar o ambiente de execução necessário para ele. Voltemos à arquitetura cliente/servidor testada:

Lado do servidor:

  • inicie o SGBD MySQL
  • inicie o servidor Glassfish
  • implantar o serviço web JEE de agendamentos, caso ainda não esteja implantado
  • se necessário, testar um dos clientes anteriores para verificar se tudo está funcionando corretamente no lado do servidor.

Do lado do cliente:

Inicie o servidor Apache ao qual será solicitada a aplicação Flex. Aqui, utilizamos a ferramenta Wamp. Com essa ferramenta, podemos associar um alias à pasta [bin-debug] do projeto Flex.

  • o ícone do Wamp fica na parte inferior da tela [1]
  • clicando com o botão esquerdo do mouse no ícone Wamp, selecione a opção Apache [2] / Alias Directories [3, 4]
  • selecione a opção [5]: Adicionar um alias
  • em [6], atribua um alias (qualquer nome) ao aplicativo web que será executado
  • em [7], indique a raiz do aplicativo web que terá esse alias: trata-se da pasta [bin-debug] do projeto Flex que acabamos de criar.

Vamos relembrar a estrutura da pasta [bin-debug] do projeto Flex:

O arquivo [rdvmedecins01.html] é o arquivo HTML do aplicativo Flex. Graças ao alias que acabamos de criar na pasta [bin-debug], esse arquivo poderá ser acessado pela URL [http://localhost/rdvmedecins/rdvmedecins01.html]. Acessamos essa URL em um navegador que possua o plugin Flash Player versão 9 ou superior:

  • em [1], a URL do aplicativo 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 exibição dos clientes, embora o serviço web tenha sido interrompido.

Talvez você tenha curiosidade em visualizar o código-fonte da página HTML recebida 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
<!-- salvo da URL=(0014)about:internet -->
<html lang="en">

<!-- 
Smart developers always View Source. 

This application was built using Adobe Flex, an open source framework
for building rich Internet applications that get delivered via the
Flash Player or to desktops via Adobe AIR. 

Learn more about Flex at http://flex.org 
// -->

<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<!--   BEGIN Seção “Histórico do navegador” obrigatória -->
<link rel="stylesheet" type="text/css" href="history/history.css" />
<!--   END Seção que requer histórico do navegador -->

<title></title>
<script src="AC_OETags.js" language="javascript"></script>
...
<script language="JavaScript" type="text/javascript">
<!--
// -----------------------------------------------------------------------------
// Globais
// É necessária uma versão principal do Flash
var requiredMajorVersion = 9;
// Versão secundária do Flash necessária
var requiredMinorVersion = 0;
// Versão secundária do Flash necessária
var requiredRevision = 124;
// -----------------------------------------------------------------------------
// -->
</script>
</head>

<body scroll="no">
<script language="JavaScript" type="text/javascript">
<!--
// Verificação da versão do Flash Player capaz de iniciar a instalação do produto (6.0r65)
....
// -->
</script>
<noscript>
        <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
                        id="rdvmedecins01" width="100%" height="100%"
                        codebase="http://fpdownload.macromedia.com/get/flashplayer/current/swflash.cab">
                        <param name="movie" value="rdvmedecins01.swf" />
                        <param name="quality" value="high" />
                        <param name="bgcolor" value="#869ca7" />
                        <param name="allowScriptAccess" value="sameDomain" />
                        <embed src="rdvmedecins01.swf" quality="high" bgcolor="#869ca7"
                                width="100%" height="100%" name="rdvmedecins01" align="middle"
                                play="true"
                                loop="false"
                                quality="high"
                                allowScriptAccess="sameDomain"
                                type="application/x-shockwave-flash"
                                pluginspage="http://www.adobe.com/go/getflashplayer">
                        </embed>
        </object>
</noscript>
</body>
</html>

O corpo da página começa na linha 39. Ele não contém HTML clássico, mas um objeto (linha 47) do tipo “application/x-shockwave-flash” (linha 60). Trata-se do arquivo [rdvmedecins01.swf] (linha 54), que pode ser visto na pasta [bin-debug] do projeto Flex. É um arquivo de tamanho considerável: cerca de 600 K para este exemplo simples.

6.2. Um segundo cliente Flex

O segundo cliente Flex não utilizará o proxy em C gerado para o primeiro. Queremos mostrar que essa etapa não é indispensável, mesmo que apresente vantagens em relação à que será apresentada aqui.

O projeto evolui da seguinte maneira:

  • em [1], o novo aplicativo Flex
  • em [2], os executáveis associados a ela
  • em [3], a nova visualização: vamos exibir a lista de médicos.

O código MXML do aplicativo [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ção da lista de médicos
                wsrdvmedecins.getAllMedecins.send();
            }
            
            private function loadMedecinsCompleted(event:ResultEvent):void{
                // os médicos são recuperados
                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>

Comentaremos apenas as novidades:

  • linhas 42–45: a nova visualização. Ela é idêntica à anterior, exceto pelo fato de ter sido adaptada para exibir os médicos em vez dos 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 não é mais utilizado aqui.
  • linha 35: o atributo id atribui um nome ao serviço web.
  • linha 36: o atributo wsdl fornece a URI do arquivo WSDL do serviço web. É a 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 por meio da tag <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 serem executados em caso de sucesso da operação (atributo result) e em caso de falha (atributo fault).
  • linha 39: a tag <mx:request> serve para definir os parâmetros da operação. Aqui, o método remoto getAllMedecins não possui parâmetros, portanto não inserimos nada. Para um método que admita os parâmetros param1 e param2, escreveríamos: 
<mx:Request>
    <param1>{param1}</param1>
    <param1>{param1}</param1>
</mx:Request>

onde param1 e param2 seriam variáveis declaradas e inicializadas na tag <mx:Script>

[Bindable]
private var param1:Type1;
[Bindable]
private var param2:Type2;

Na tag <mx:Script>, encontramos código ActionScript semelhante ao analisado no cliente anterior. A única diferença está no método loadMedecins, nas linhas 13 a 16. O que difere é a forma de chamada do método remoto [getAllMedecins]:

  • linha 15: utiliza-se o serviço web [wsrdvmedecins], definido na linha 35, e sua operação [getAllMedecins], definida na linha 37. Para executar essa operação, utiliza-se o método send. É ela que inicia a chamada assíncrona do método getAllMedecins do serviço web definido na linha 35. O método send fará a chamada com os parâmetros definidos pela tag <mx:request> da linha 39. Aqui não há nenhum parâmetro. 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.

Agora só nos resta testar essa nova aplicação:

 
https://stahe.github.io
Este tutorial do curso, escrito por Serge Tahé, é disponibilizado ao público sob os termos da Creative Commons Atribuição – Sem uso comercial – Compartilhamento igual 3.0 inalterado.