REDES INTEGRADAS DE TELECOMUNICAÇÕES II 2002 / 2003

Transcrição

1 UNIVERSIDADE NOVA DE LISBOA Faculdade de Ciências e Tecnologia Departamento de Engenharia Electrotécnica REDES INTEGRADAS DE TELECOMUNICAÇÕES II 2002 / 2003 Licenciatura em Engenharia Electrotécnica e de Computadores 5º ano 9º semestre Introdução ao Visibroker para C++: Desenvolvimento de aplicações CORBA no C++Builder Luis Bernardo

2 ÍNDICE Índice Objectivo A arquitectura CORBA Construção de aplicações Definição de interfaces (IDL) Clientes (invocação de funções) Referências para objectos Operações sobre referências para objectos Realização de um cliente Integração no Borland Builder C Servidores (recepção de invocações) Realização de um servidor Geração de excepções de utilizador Modos de activação de objectos no CORBA Integração no Borland Builder C Passagem de parâmetros em funções IDL Passagem de strings Passagem de estruturas de tamanho variável Passagem de arrays com tamanho fixo Passagem de referências para objectos Serviço de Nomes Serviço de Eventos Ambiente Visibroker para o Borland C++ Builder Aplicação cliente-servidor utilizando o serviço de nomes Cliente Servidor Exercício Aplicação utilizando o serviço de eventos Emissor Receptor Exercício Bibliografia adicional...35

3 1. OBJECTIVO Familiarização com o ambiente CORBA para o Borland C++ Builder 4 (Visibroker) e com o desenvolvimento de aplicações. Este documento descreve o método para a criação de aplicações CORBA e o conjunto de classes e funções disponíveis no ambiente. Adicionalmente, é apresentado o código integral de algumas aplicações que deve ser introduzido seguindo as instruções do enunciado, facilitando a aprendizagem. 2. A ARQUITECTURA CORBA A arquitectura CORBA (Common Object Request Broker Arquitecture) foi desenvolvida para facilitar o desenvolvimento de aplicações distribuídas numa rede heterogénea. A arquitectura CORBA usa uma abordagem orientada para objectos para a criação de software. Cada objecto encapsula os detalhes da sua implementação oferecendo uma interface bem conhecida, descrita por um ficheiro de especificação IDL (Interface Definition Language). O ORB (Object Request Broker) é o componente da arquitectura que liga as aplicações clientes com os objectos que pretendem usar. O programa cliente não precisa de saber se o objecto reside na mesma máquina, ou está localizado noutro computador na rede. O programa cliente só necessita de saber o nome do objecto e de saber usar a interface do objecto. O ORB trata de todos os detalhes de localizar o objecto, enviar os pedidos e receber as respostas. Programa Cliente Invocação bind() do objecto A Objecto A ORB localiza objecto A e liga-o ao cliente ORB Após realizar a associação a um objecto (bind), o cliente pode invocar transparentemente qualquer função da interface do objecto A, pois o ORB vai encarregar-se de codificar os parâmetros de entrada da função numa mensagem, vai enviá-la para a máquina onde se encontra a correr o objecto A, e vai invocar a função sobre o objecto A. O retorno de parâmetros ou valores também é enviado através do ORB. A utilização do ORB oferece uma total transparência na invocação de operações entre objectos, sendo possível interligar objectos realizados em diferentes linguagens (C, C++, Java, Cobol, etc.) ou arquitecturas (ex. Wintel 32 bits, Unix 64 bits, etc.). O ORB não é um processo separado mas uma colecção de bibliotecas que se ligam aos executáveis e de recursos computacionais suportados por aplicações. O Visibroker para C realiza a versão 2.1 da norma CORBA. No Visibroker a aplicação mais relevante na associação a objectos é o Smart Agent, que mantém uma lista dos objectos activos numa máquina ou rede. A arquitectura CORBA vai ser estudada mais aprofundadamente na aula teórica, sendo deixado para essas aulas um estudo aprofundado dos vários serviços e funcionalidades suportados. Neste documento vai-se introduzir apenas os serviços e funcionalidades necessários a para a realização do trabalho prático proposto. 3

4 3. CONSTRUÇÃO DE APLICAÇÕES O primeiro passo no processo de desenvolvimento de aplicações consiste na identificação dos objectos que fazem parte da aplicação (geralmente um cliente e um servidor). Em seguida seguem-se os passos indicados na figura: 1. Escreve-se um ficheiro 'Nome.idl' com a especificação da interface de cada objecto servidor; 2. Usa-se o compilador de IDL do Visibroker (idl2cpp) para gerar o código de acesso de clientes a objectos (designado stub), nos ficheiros 'Nome_c.cpp' e 'Nome_c.hh', e o código de recepção de mensagens e activação de funções do objecto (designado skeleton), nos ficheiros 'Nome_s.cpp' e 'Nome_s.hh'; 3. Programa-se o código do cliente em 'Cliente.cpp'. Para usar o objecto no servidor define-se uma variável do tipo referência para objecto (pode ser 'interf_ptr' ou 'interf_var' para uma interface com o nome 'interf') definido em 'Nome_c.hh'. Após inicializada, a variável permite realizar todas as operações definidas na interface; 4. Programa-se o código do servidor estendendo a classe abstracta pura (com o nome '_sk_interf') definida em 'Nome_s.hh', onde se define a implementação de todas as funções. O objecto só fica activo após se registar no BOA (Basic Object Adapter), o componente do ORB que recebe as invocações; 5. Compila-se os programas cliente e servidor utilizando o compilador de C++; 6. Arranca-se o servidor; 7. Arranca-se o cliente, que utilizando o ORB comunica com o objecto no servidor. 1 Nome.idl idl2cpp 2 Nome_c.cpp Nome_s.cpp 3 Cliente.cpp Servidor.cpp 4 Compilador C++ Compilador C++ Cliente Código Cliente 5 5 Stub IDL Skeleton IDL Código Servidor 7 6 ORB Servidor No ambiente C++ Builder o compilador idl2cpp é invocado transparentemente sempre que é acrescentado um ficheiro IDL a um projecto, estando este passo do desenvolvimento de aplicações integrado no ambiente de desenvolvimento Definição de interfaces (IDL) A norma CORBA define um conjunto de tipos básicos para a definição de interfaces, que inclui os tipos indicados na tabela seguinte com a correspondência para C++: 4

5 Tipo IDL Tipo C++ float CORBA::Float unsigned long CORBA::Ulong boolean CORBA::Boolean string char * Para além dos tipos básicos, o programador pode definir novos tipos a partir de tipos existentes, ou criar novos tipos estruturados. A instrução typedef define um novo tipo (NomeTipo) a partir de Tipo: typedef Tipo NomeTipo; A instrução struct define um tipo estruturado equivalente à struct da linguagem C com o nome NomeTipo, composto por vários campos: struct NomeTipo { TipoCampo_1 NomeCampo_1; ; Os arrays de tamanho fixo são declarados de uma forma equivalente à usada em C++: typedef short NomeTipo[10]; Após compilada, a declaração anterior dá origem a uma declaração de um array em C++, e a um conjunto de funções para manipulação do array: typedef CORBA::Short NomeTipo[10]; // Declaração do tipo typedef CORBA::Short NomeTipo_slice; // Tipo elemento do array NomeTipo_slice *NomeTipo_alloc(); // Aloca o array NomeTipo_slice *NomeTipo_dup(const NomeTipo_slice *); void NomeTipo_copy(NomeTipo_slice *para, const NomeTipo_slice *de); void NomeTipo_free(NomeTipo_slice *); A norma CORBA define um tipo genérico (any), que pode transportar qualquer tipo de dados. Este tipo é particularmente útil no serviço de eventos, permitindo enviar mensagens de qualquer tipo, incluindo tipos definidos pelo utilizador num ficheiro IDL. Neste caso, a compilação do ficheiro IDL com a definição dos tipos deve ser realizada com a opção "typecode information". O tipo any é realizado por uma classe, que memoriza o tipo dos dados, um ponteiro para os dados, e um conjunto de funções para inserir valores ou para os exportar para uma variável: class Any { public: Any(); // Operadores de inserção para tipos simples Boolean operator<<=(corba::any &, Short); Boolean operator<<=(corba::any &,const char *);//duplica string Boolean operator<<=(corba::any &, char *); //passa ponteiro // Operadores de extracção para variáveis de tipos simples Boolean operator>>=(corba::any &, Short &); Boolean operator>>=(corba::any &, char *&); No exemplo da secção 4.2 pode encontrar um exemplo de utilização do tipo any. 5

6 Adicionalmente, norma CORBA define outros tipos de dados estruturados (enumerações, unions, arrays de tamanho variável (designados de sequências), etc.) que não são usados no trabalho prático. A definição de uma interface é realizada numa secção precedida da palavra-chave interface, contendo uma lista de uma ou mais funções que podem ser invocadas num objecto. Cada função define o tipo do valor retornado pela função, ou void caso não retorne nada. Adicionalmente define uma lista de argumentos de tamanho variável. Todas as invocações de funções são fiáveis. No caso de uma função não devolver nada ao cliente pode-se declarar como oneway, tendo nesse caso uma semântica de "melhor-esforço", sem garantias de fiabilidade na invocação. interface NomeInterface { TipoRetorno NomeFunção(lista de argumentos); oneway void NomeFunção(lista de argumentos); ; A lista de argumentos é constituída por um conjunto de argumentos separados por vírgulas precedidos de uma palavra-chave: in TipoArg Nome out TipoArg Nome inout TipoArg Nome A palavra-chave define se o argumento é enviado do cliente para o objecto (in), se é enviado do objecto para o cliente (out), ou se é enviado e depois modificado e recebido no cliente (inout). Os servidores podem ainda notificar os clientes de falhas graves no objecto através do retorno de excepções para os clientes. Neste caso, a interface inclui a definição do nome da excepção e do conjunto de campos (eventualmente vazio) que compõem a excepção (acedidos de forma semelhante aos campos de uma estrutura). Caso se use excepções de utilizador, tem de se definir quais as funções que retornam excepções (raises): interface NomeInterface { exception NomeExcepção {lista de campos; TipoRetorno NomeFunção(lista de argumentos) raises (NomeExcepção); ; Por vezes, quando há várias interfaces que partilham os mesmos tipos, há vantagens em declará-las integradas num único módulo. A sintaxe é a seguinte: module NomeMódulo { definição de uma ou mais interfaces ou de tipos ; Após compilação do IDL, o módulo dá origem a uma classe que contém internamente as declarações de interfaces e de tipos declarados no módulo. Assim, para um módulo de nome Banco com um tipo DadosConta e uma interface Conta são criados respectivamente: um tipo Banco::DadosConta (tipo DadosConta dentro da classe Banco) e uma classe Banco::Conta (interface Conta dentro do módulo Banco). 6

7 3.2. Clientes (invocação de funções) Para cada interface, o compilador de IDL gera uma classe com o mesmo nome da interface, e que realiza um procurador de um objecto. Por exemplo, para o ficheiro 'Conta.idl' seguinte: interface Conta { float saldo(); ; A classe gerada no ficheiro 'Conta_c.h' herda de CORBA::Object, a super-classe de todos os objectos CORBA e inclui os dois métodos representados: class Conta: public virtual CORBA::Object {... public: virtual CORBA::Float saldo(); static Conta_ptr _bind(const char *object_name = NULL,); ; O método saldo é um método que invoca a operação no objecto remoto (vulgarmente designado de stub) através do ORB. O método _bind permite realizar a associação a um objecto procurando pelo identificador com que o objecto se registou ('object_name') no ORB (Smart Agent). No entanto, este método está limitado à rede local, sendo preferível utilizar o serviço de nomes ou o serviço de Trading para realizar a pesquisa numa rede de maior dimensão Referências para objectos Para além da classe procuradora do objecto, o compilador gera dois tipos de referências para objecto: A classe 'Conta_ptr' é um tipo ponteiro para a classe Conta: typedef Conta *Conta_ptr; A classe 'Conta_var' tem internamente uma variável do tipo Conta_ptr, podendo-se usar como o ponteiro para conta, mas adiciona à anterior a gestão de memória: class Conta_var { private: Conta_ptr p; public: Conta_ptr operator->() const; ; A diferença entre utilizar uma referência do tipo 'Conta_ptr' ou 'Conta_var' é que no primeiro caso é necessário libertar a referência para o objecto explicitamente após esta deixar de ser necessário (com 'CORBA::release(ifref)') enquanto no segundo caso, o destrutor da classe Conta_var se encarrega de fazer essa libertação de memória Operações sobre referências para objectos Existe um conjunto de operações que se podem realizar sobre referências para objectos: desde inicializá-las a vazio (_nil()) a transformá-las em strings. Nesta secção são enumeradas 7

8 algumas dessas operações para uma interface de nome Banco::Conta (interface Conta do módulo Banco) e uma variável if_ptr do tipo Banco::Conta_ptr: Inicialização de referência a vazio: if_ptr= Banco::Conta::_nil(); Teste de referência a vazio: if (CORBA::is_nil(if_ptr)) { Criação de duplicado da referência na variável if_ptr2: if_ptr2= Banco::Conta::_duplicate(if_ptr); Libertação de referência para objecto: CORBA::release(if_ptr); Transformação de uma referência do tipo genérico (CORBA::Object_ptr obj_ptr) para o tipo da interface (Banco::Conta_ptr). Esta operação testa se o tipo de interface original é compatível com a classe de destino retornando um ponteiro vazio caso não seja. (NOTA: Esta operação chama internamente a função _duplicate, sendo necessário libertar a referência if_ptr): if_ptr= Banco::Conta::_narrow(obj_ptr); Converte uma referência para objecto numa string no formato IOR (char *IOR). Esta função requer um ponteiro para o ORB (CORBA::ORB_ptr orb) inicializado previamente. Após a string deixar de ser necessária, deve ser libertada com a função (CORBA::string_free(IOR);): IOR= orb->object_to_string(if_ptr); Usa uma string no formato IOR (char *IOR) para inicializar uma referência para objecto. Esta função requer um ponteiro para o ORB (CORBA::ORB_ptr orb) inicializado previamente e um ponteiro do tipo genérico (CORBA::Object_ptr obj). Após a referência para objecto deixar de ser necessária, devem ser libertadas com a função (CORBA::release) as variáveis obj_ptr e if_ptr: obj_ptr= orb->string_to_object(ior); if_ptr= Banco::Conta::_narrow(obj_ptr); CORBA::release(obj_ptr); Com uma variável if_var do tipo Banco::Conta_var seria possível usá-la no lugar de if_ptr, excepto que não seria necessário realizar a libertação das referências para objecto. Por exemplo, se fosse usado um CORBA::Object_var não seria necessária a ultima linha do exemplo apresentado para função string_to_object Realização de um cliente A realização de um cliente que faz uma invocação remota num objecto requer quatro fases: 1. Inicializar o ORB; 2. Inicializar a referência para o objecto; 3. Invocar a operação sobre o objecto; 4. Libertar a referência, se necessário. A inicialização do ORB (CORBA::ORB_ptr orb) é feita com a instrução: 8

9 orb= CORBA::ORB_init(argc, argv); A inicialização da referência para objecto (if_ptr ou if_var) pode ser feita: utilizando a função _bind; recebendo uma string com o IOR do objecto pretendido (ver secção ); ou utilizando o serviço de nomes (ver secção 2.5.). A inicialização com a função _bind pode ser feita não indicando o nome pretendido. Nesse caso é devolvida uma referência para um objecto indefinido com o tipo de interface pretendido, ou uma excepção, caso não exista nenhum objecto servidor registado: if_var= Banco::Conta::_bind("nome"); ou if_var= Banco::Conta::_bind(); catch(const CORBA::Exception& e) { char *erro= e._name(); // Texto com descrição do erro A invocação da operação depósito é feita com a mesma sintaxe que seria num objecto local. No entanto como pode envolver comunicação por rede, é necessário acrescentar o código para apanhar as excepções a informar sobre problemas na invocação da função: saldo= if_var->saldo(); catch(const CORBA::Exception& e) { char *erro= e._name(); // Texto com descrição do erro Neste exemplo não é necessário libertar a memória, pois estamos a usar uma referência para objecto do tipo Banco::Conta_var Integração no Borland Builder C++ A utilização de referências para objectos no ambiente integrado do C++ Builder não tem problemas de maior, excepto a inicialização do ORB. Os parâmetros argc e argv costumam ser recebidos na função main de um programa em C ou C++. No ambiente Builder C++ existem duas variáveis globais que têm os valores da linha de comando ( argc) e ( argv) e que podem ser usadas em qualquer função. Convém fazer a inicialização do ORB em apenas um local do código (por exemplo, no construtor da janela principal do programa, reutilizando a referência para o ORB noutras funções) Servidores (recepção de invocações) Os servidores são realizados como um conjunto de objectos CORBA, cada um associado a uma interface. No trabalho prático da cadeira vai ser usado o Visibroker 3.3 (para Builder C++ 4), um ambiente CORBA compatível com a versão 2.1 da norma. Nesta versão, o BOA (Basic Object Adapter) é o componente do ORB responsável por receber o registo de objectos e posteriormente activá-los, quando são recebidas invocações de funções. Noutros ambientes de desenvolvimento, compatíveis com CORBA 2.3 ou superior, este componente foi substituído pelo POA (Portable Object Adapter), que para os assuntos abordados neste documento, tem uma interface em quase tudo semelhante. Difere apenas na maior configurabilidade e portabilidade entre diferentes realizações CORBA. 9

10 Realização de um servidor Considere-se o ficheiro IDL seguinte (Banco.idl): Module Banco { interface Conta { float saldo(); ; ; A compilação do IDL dá origem à criação de uma classe _sk_banco:_sk_conta no ficheiro Banco_s.h: class _sk_banco { public: class _sk_conta : public Banco::Conta { protected: _sk_conta(const char *_obj_name = (const char *)NULL); public: // Função virtual pura - necessita de se implementada virtual CORBA::Float saldo() = 0; ; ; A construção de um servidor neste caso resume-se à definição de uma classe (Conta_Impl) que estende a classe _sk_banco:_sk_conta, com um construtor, um destrutor e a implementação da função saldo. Observe-se que na definição do construtor é possível inicializar os dados internos do objecto. class ContaImpl : public _sk_banco::_sk_conta { private: CORBA::Float Saldo; Public: ContaImpl(CORBA::Float _Saldo, const char *object_name = (const char *)NULL) : _sk_banco::_sk_conta(object_name) { Saldo= _Saldo; ~ContaImpl() { virtual CORBA::Float saldo() // Implementação função { return Saldo; ; Após codificar a classe com a implementação do objecto é necessário: 1. inicializar o ORB e o BOA; 2. criar uma nova variável do tipo ContaImpl; 3. registar a variável no BOA 4. Chamar a função que prepara o BOA para receber invocações A inicialização do ORB (CORBA::ORB_ptr orb) e do BOA (CORBA::BOA_ptr boa) é feita com as instruções: orb= CORBA::ORB_init(argc, argv); boa= orb->boa_init(argc, argv); A criação de uma nova variável deve ser feita com a instrução new, sendo passado o nome com que o objecto vai ser registado no ORB. Se não se passar nenhum nome, o objecto não é localizável com o método _bind numa referência para objecto: 10

11 ContaImpl *pt= new ContaImpl(1000, "nome"); O registo do objecto no BOA é feito com a instrução: boa->obj_is_ready(pt); Por fim, é necessário arrancar o ciclo principal do BOA. Esta operação é bloqueante, não deixando que nada corra a partir do instante em que é invocada excepto as funções dos objectos registados no BOA. boa->impl_is_ready(); Em qualquer altura é possível desactivar um objecto, cancelando o registo do objecto no BOA e libertando a implementação do objecto: boa->deactivate_obj(pt); delete pt; Se tivesse sido usado o POA, a classe ContaImpl seria gerada de forma semelhante, estendendo uma classe gerada pelo compilador (POA_Banco::Conta) Geração de excepções de utilizador Considere-se o ficheiro IDL anterior modificado de maneira a incluir uma excepção de utilizador: Module Banco { exception ContaInvalida {; // sem parâmetros interface Conta { float saldo() raises (ContaInvalida); ; ; Após compilar o IDL esta modificação só acrescenta a declaração de mais uma classe (ContaInvalida) e modifica a assinatura da função saldo: virtual CORBA::Float ContaImpl::saldo() throw (Banco::Conta::ContaInvalida) { if (conta inválida) // testa se a conta é válida throw (Banco::Conta::ContaInvalida()); // sai da função return Saldo; Modos de activação de objectos no CORBA Existem vários modos como o BOA pode funcionar. O modo descrito na secção é o modo mais simples, onde o programador arranca e pára os objectos explicitamente. No entanto, recorrendo a componentes do CORBA como o repositório de implementação (designado de Object Activation Deamon no Visibroker) é possível registar uma implementação de um objecto no BOA e deixar que seja o BOA a arrancar o objecto quando necessário, podendo-se definir diferentes políticas de activação (um objecto para todas as invocações ou um objecto novo por cada invocação). Noutro modo de activação designado de DII (Dynamic Interface Invocation) / DSI (Dynamic Skeleton Invocation), é usado um serviço de repositório de interfaces para obter as funções e os parâmetros das funções de um tipo de interface, construindo-se dinamicamente os stubs e skeletons de uma forma semelhante à que foi usada para enviar e receber mensagens directamente sobre sockets. 11

12 Integração no Borland Builder C++ É complicado realizar um objecto CORBA num programa com uma interface gráfica pois tanto a recepção de eventos gráficos (toque na tecla do rato, teclas, sockets, etc.) como a recepção de invocações de funções necessitam de ficar à espera numa rotina bloqueante. No caso do ambiente C++ Builder e Visibroker, o WinMain só pode ficar bloqueado numa das funções. A solução para o problema é utilizar threads, tarefas que correm em paralelo dentro do mesmo programa. Por defeito um programa tem apenas uma tarefa. Logo, para poder receber dados gráficos e de sockets no WinMain é necessário criar uma tarefa exclusiva só para receber as invocações nos objectos CORBA. Para facilitar a programação de servidores são fornecidos dois ficheiros (corba_server.h e corba_server.cpp) que facilitam a criação da thread CORBA. Para utilizar estes ficheiros basta incluir o ficheiro corba_server.h, e acrescentar ao projecto a unidade corba_server.cpp. Adicionalmente, devem definir uma função global no vosso código para ecoar as mensagens de erro com a seguinte assinatura: void Log(AnsiString str); Uma realização possível para a função é (se tiver uma variável TMemo): Log(AnsiString str) { Form1->Memo1->Lines->Add(str); O passo 4 da realização de um servidor (boa->impl_is_ready()), indicado na secção anterior é substituído pela invocação da função: StartCORBAServerThread(boa); Esta função recebe como parâmetro uma referência para o BOA (do tipo CORBA::BOA_ptr boa) e retorna true caso tenha arrancado com uma nova thread ou false caso já estivesse a correr. A função seguinte permite testar se a thread CORBA está a correr: if (CORBAServerThreadRunning()) Todas as operações para ligar e desligar objectos continuam válidas, podendo apenas ocorrer problemas de concorrência no acesso ao BOA por duas tarefas distintas a correr em paralelo. No âmbito do trabalho prático devem ignorar estes problemas Passagem de parâmetros em funções IDL A realização de clientes e servidores com passagem de parâmetros de tipos de tamanho fixo (números, caracteres, etc.) é simples. Todos os parâmetros de entrada da função são passados por valor e os parâmetros de saída ou entrada-saída são passados por referência, não existindo alocação de memória. No entanto, para outros tipos mais complexos é necessário gerir a memória de maneira a garantir que não são deixados blocos de memória perdidos na invocação ou no processamento de uma função Passagem de strings O tratamento de strings é ilustrado no exemplo seguinte (s_in, s_inout e s_out ilustram respectivamente o tratamento de parâmetros de entrada, entrada-saída e saída, e ilustrase o retornar de strings numa função): interface Foo { string *string_op(in string s_in, inout string s_inout, out string s_out); ; 12

13 Esta interface é compilada para a seguinte classe no cliente: class Foo : public CORBA::Object { public: char *string_op(const char *s_in, char * &s_inout, CORBA::String_out s_out); ; O código do cliente vai ter de libertar as strings retornadas pela função ou nos parâmetros, utilizando a função CORBA::string_free. Os parâmetros de entrada-saída devem ser alocados com as funções CORBA::string_dup ou CORBA::string_alloc de maneira a poderem ser libertados pelo stub do cliente. A classe CORBA::String_out é compatível com 'char * &'. Um exemplo de código do cliente que chama a função string_op é: Foo_var obj =...; // obtém referência para o objecto char *inout_val= CORBA::string_dup("inout string"); char *out_val, *ret_val; // não é necessário inicializar //chama função ret_val= obj->string_op("in string", inout_val, out_val); // usa valores // Liberta parâmetros CORBA::string_free(inout_val); CORBA::string_free(out_val); CORBA::string_free(ret_val); Outra alternativa seria usar uma variável do tipo CORBA::String_var para out_val. Nesse caso, esta classe faria a libertação da memória automaticamente. O código do servidor terá de alocar todas as strings devolvidas pela função: char *Foo_impl::string_op(const char *s_in, char * &s_inout, CORBA::String_out s_out) { // usa valores de s_in e s_inout // Modifica valor s_inout CORBA::string_free(inout_val); inout_val= CORBA::string_dup("outgoing inout string"); // inicializa outras strings out_val= CORBA::string_dup("out string"); return CORBA::string_dup("return string"); Passagem de estruturas de tamanho variável O tratamento de estruturas de tamanho variável é ilustrado no exemplo seguinte: Struct Vls { long l_mem; string s_mem; ; interface Foo { Vls vls_op(in Vls vls_in, inout Vls vls_inout, out Vls vls_out); ; 13

14 Esta interface é compilada para a seguinte classe no cliente: class Foo : public CORBA::Object { public: Vls *vls_op(const Vls &vls_in, Vls &vls_inout, Vls_out vls_out); ; O código do cliente vai ter de libertar as estruturas retornadas pela função ou pelos parâmetros. Os parâmetros de entrada e entrada-saída podem ser variáveis locais ou variáveis alocadas dinamicamente, mas os campos internos da estrutura de tamanho dinâmico devem ser alocados. A classe Vls_out é criada pelo compilador de IDL e é compatível com 'Vls *&'. Um exemplo de código do cliente que chama a função vls_op é: Foo_var obj =...; // obtém referência para objecto Vls in_val, inout_val; // variáveis locais Vls *out_val, *ret_val; // variáveis dinâmicas // inicializa in_val e inout_val in_val.l_mem= 99; in_val.s_mem= CORBA::string_dup("Hello"); inout_val.l_mem= 5; inout_val.s_mem= CORBA::string_dup("World"); //chama função ret_val= obj->vls_op(in_val, inout_val, out_val); // usa valores // Liberta valores delete out_val; delete ret_val; Outra alternativa seria declarar os parâmetros de saída e de entrada-saída como sendo do tipo Vls_var, criado pelo compilador de IDL. Nesse caso as libertações de memória passam a ser transparentes, obtendo-se o seguinte código: Foo_var obj =...; // obtém referência para objecto Vls in_val Vls_var inout_val= new Vls; // variável dinâmica Vls_var out_val, ret_val; // não inicializadas // inicializa in_val e inout_val in_val.l_mem= 99; in_val.s_mem= CORBA::string_dup("Hello"); inout_val->l_mem= 5; inout_val->s_mem= CORBA::string_dup("World"); //chama função ret_val= obj->vls_op(in_val, inout_val.inout(), out_val.out()); // usa valores // a libertação é feita automaticamente O código do servidor terá de alocar as estruturas devolvidas pela função (excepto os argumentos de entrada-saída): 14

15 Vls *Foo_impl::vls_op(const Vls *vls_in, Vls &vls_inout, Vls_out vls_out) { // usa valores de vls_in e vls_inout // Modifica valor vls_inout vls_inout.l_mem = 33; vls_inout.s_mem = CORBA::string_dup("campo string inout"); // inicializa vls_out vls_out= new Vls; vls_out.l_mem = 35; vls_out.s_mem = CORBA::string_dup("campo string out"); // prepara valor de retorno Vls *res= new Vls; res->l_mem = 99; res->s_mem = CORBA::string_dup("campo string retornada"); return res; Passagem de arrays com tamanho fixo O tratamento de arrays de tamanho fixo é ilustrado no exemplo seguinte: typedef double Arr[3]; interface Foo { Arr arr_op(in Arr arr_in, inout Arr arr_inout, out Arr arr_out); ; Esta interface é compilada para a seguinte classe no cliente: typedef CORBA::Double Arr[2]; typedef CORBA::Double Arr_slice; void Arr_free(Arr_slice *); class Foo : public virtual CORBA::Object { public: Arr_slice *arr_op(const Arr arr_in, Arr_slice *arr_inout, Arr_out arr_out)= 0; ; O código do cliente vai ter de libertar as estruturas retornadas pela função ou pelos parâmetros. Os parâmetros de entrada e entrada-saída podem ser variáveis locais ou variáveis alocadas dinamicamente, mas elementos internos de arrays com tamanho variável devem ser alocados. A classe Arr_out é criada pelo compilador de IDL e é compatível com 'Arr_slice &'. Um exemplo de código do cliente que chama a função arr_op é: Foo_var obj =...; // obtém referência para objecto Arr in_val, inout_val, out_val; // variáveis locais Arr *ret_val; // variáveis dinâmicas // inicializa in_val e inout_val in_val[0]= 1.0; in_val[1]= 2.0; inout_val[0]= 3.0; inout_val[1]= 4.0; //chama função ret_val= obj->vls_op(in_val, inout_val, out_val); // usa valores // Liberta valores Arr_free(ret_val); 15

16 Outra alternativa seria declarar os parâmetros de saída e de entrada-saída como sendo do tipo Arr_var, criado pelo compilador de IDL. Nesse caso as libertações de memória passam a ser transparentes, obtendo-se o seguinte código: Foo_var obj =...; // obtém referência para objecto Arr in_val, inout_val, out_val; // variáveis locais Arr_var ret_val; // tipo var // inicializa in_val e inout_val in_val[0]= 1.0; in_val[1]= 2.0; inout_val[0]= 3.0; inout_val[1]= 4.0; //chama função ret_val= obj->vls_op(in_val, inout_val, out_val); // usa valores // a libertação é feita automaticamente O código do servidor terá de alocar as estruturas devolvidas pela função (excepto os argumentos de entrada-saída): Arr_slice *Foo_impl::arr_op(const Arr vls_in, Arr vls_inout, Arr_out arr_out) { // usa valores de arr_in e arr_inout // Modifica valor arr_inout for (int i= 0; i<2; i++) arr_inout[i] *= 2; // inicializa arr_out for (int j= 0; j<2; j++) arr_out[j] = random()%10; // prepara valor de retorno Arr_slice *res= Arr_alloc(); for (int k= 0; i<k; i++) arr_out[k] = random()%10; return res; Passagem de referências para objectos O tratamento de passagem de referências para objectos é ilustrado no exemplo seguinte: interface Foo { Foo foo_op(in Foo foo_in, inout Foo foo_inout, out Foo foo_out); ; Esta interface é compilada para a seguinte classe no cliente: class Foo : public CORBA::Object { public: Foo_ptr foo_op(foo_ptr ref_in, Foo_ptr &ref_inout, Foo_out ref_out); ; O código do cliente vai ter de libertar as referências para objecto retornadas pela função ou pelos parâmetros. A classe Foo_out é criada pelo compilador de IDLs e é compatível com 'Foo_ptr &'. Um exemplo de código do cliente que chama a função foo_op é: 16

17 Foo_var obj =...; // obtém referência para objecto Foo_ptr in_val=...; // inicializa referência Foo_ptr inout_val=...; // inicializa referência Foo_ptr out_val, ret_val; // não são inicializadas //chama função ret_val= obj->foo_op(in_val, inout_val, out_val); // usa valores // Liberta referências para objecto CORBA::release(in_val); CORBA::release(inout_val); CORBA::release(out_val); CORBA::release(ret_val); Novamente, torna a ser possível usar variáveis do tipo Foo_var para evitar ter de libertar as referências explicitamente: Foo_var obj =...; // obtém referência para objecto Foo_var in_val=...; // inicializa referência Foo_var inout_val=...; // inicializa referência Foo_var out_val, ret_val; // não são inicializadas //chama função ret_val= obj->foo_op(in_val, inout_val, out_val); // usa valores // A libertação das referências para objecto é feita quando as //variáveis são destruídas, ou caso seja atribuído um novo valor O código do servidor terá de alocar as estruturas devolvidas pela função (excepto inout): Foo_ptr *Foo_impl::foo_op(Foo_ptr ref_in, Foo_ptr &ref_inout, Foo_out ref_out) { // usa valores de ref_in e ref_inout e modifica valor ref_inout // Se quiser manter ref_in depois da função tem de duplicar a // referência CORBA::release(ref_inout); ref_inout= _this(); // inicializa ref_out Foo_impl *novo= new Foo_impl; Ref_out= novo->_this(); // devolve referência para 'novo' // prepara valor de retorno return Foo::_nil(); // referência vazia 3.5. Serviço de Nomes O serviço de nomes é o serviço mais simples de todos os serviços CORBA. Permite associar um ou mais nomes do tipo Name a um objecto, possibilitando a sua modificação ao longo do tempo. O nome é constituído por uma sequência de componentes, cada um composto por dois campos (id e kind): 17

18 Module CosNaming { typedef string Istring; struct NameComponent { Istring id; Istring kind; ; // array de tamanho variável typedef Sequence<NameComponent> Name; ; Embora a norma defina dois campos, normalmente deixa-se o campo kind vazio, usandose apenas um nome para cada elemento da sequência (ex. 'unl/dee/rit2/grupo2'). A uma cadeia de nomes está associada uma sequência de servidores de nomes, cada um responsável por cada contexto. A definição de um nome é realizada começando por se definir o número de contextos, seguindo-se o componente do nome em cada contexto: CosNaming::Name name; name.length(2); // define o nº de componentes no pathname name[0].id = CORBA::string_dup("bingo"); // nome constante AnsiString aux= Edit1->Text; // nome obtido a partir de Editbox name[1].id = CORBA::string_dup(aux.c_str()); Antes de usar o serviço de nomes, tem de se obter uma referência para o objecto servidor de nomes no ORB local. Há duas alternativas para obter esta referência. A primeira só funciona no ambiente Visibroker e recorre ao método _bind. CosNaming::NamingContext_var context; context= CosNaming::NamingContext::_bind(); catch(const CORBA::Exception& e) { Log("Excepção na ligação a serviço de nomes : " + AnsiString(e._name())); // trata erro A outra alternativa, mais compatível com outros ORBs, usa uma função do ORB para obter a referência para o servidor de nomes. Neste caso, quando se invoca o executável tem de se acrescentar à linha de comando o parâmetro "-SRVnameroot rootname" definindo o servidor de nomes (contexto) raiz para o ORB local. CosNaming::NamingContext_var context; CORBA::Object_var obj= orb->resolve_initial_references("nameservice"); context= CosNaming::NamingContext::_narrow(obj); if (CORBA::is_nil(context)) { // falhou associação a servidor de nomes catch(const CORBA::Exception& e) { Log("Excepção : " + AnsiString(e._name())); // trata erro A interacção com o serviço usa funções da interface CosNaming::NamingContext para realizar três tipos de acções: registo de nomes; pesquisa de nomes; cancelamento de nomes. 18

19 A associação de um objecto (Conta_ptr obj) a um nome pode ser realizado utilizando a função bind ou a função rebind. A diferença está no que ocorre quando se tenta registar um nome que já existe. No primeiro caso (representado) devolve uma excepção (CosNaming::AlreadyBound) enquanto que com rebind substitui o registo anterior: CosNaming::Name LSname; LSname.length(1); LSname[0].id = CORBA::string_dup("nome"); context->bind(lsname, obj); catch(const CosNaming::NamingContext::AlreadyBound &) { // O nome já está registado catch(const CORBA::Exception& e) { Log("Excepção : " + AnsiString(e._name())); A pesquisa de nomes usa a função resolve para localizar um nome, podendo retornar a excepção CosNaming::NotFound caso o nome não exista: CosNaming::Name LSname; LSname.length(1); LSname[0].id = "nome"; CORBA::Object_var aux; aux= context->resolve(lsname); catch(const CosNaming::NamingContext::NotFound &) { // O nome não existe catch(const CORBA::Exception& e) { Log("Excepção : " + AnsiString(e._name())); Após obter a referência aux, é necessário convertê-la para uma referência para o tipo pretendido utilizando uma mudança explícita de tipo: Tipo_var obj= Tipo::_narrow(aux); ou Tipo_ptr obj= Tipo::_narrow(aux); O cancelamento de nomes usa a função unbind para libertar o nome, podendo retornar a excepção CosNaming::NotFound caso o nome não exista: CosNaming::Name LSname; LSname.length(1); LSname[0].id = "nome"; context->unbind(lsname); catch(const CosNaming::NamingContext::Notfound &) { // O nome não existe catch(const CORBA::Exception& e) { Log("Excepção : " + AnsiString(e._name())); Para além destas funções existem outras que permitem obter a lista de nomes registados no serviço de nomes local. Para colmatar a falta duma ferramenta no Visibroker que dê esta 19

20 informação é distribuído com o trabalho um executável (ListNames.exe) que permite obter a lista de nomes registados em qualquer subcontexto de "rit2" (rit2 /?) Serviço de Eventos O serviço de eventos suporta a comunicação anónima entre objectos. A comunicação é realizada através do envio de mensagens de tipo genérico (any) através de um canal de eventos. Cada canal de eventos está associado a um servidor, identificado por um nome, que oferece interfaces procuradores, tanto para os fornecedores como para os consumidores de eventos. canal eventos fornecedor consumidor notificação procurador consumidor notificação procurador fornecedor notificação O serviço suporta dois modelos de interacção: Push (empurrar): os consumidores registam uma interface PushConsumer no canal de eventos; os fornecedores invocam o método "push" sobre o procurador de consumidor; O canal de eventos invoca o mesmo método sobre os consumidores. Pull (puxar): os fornecedores registam uma interface PullSupplier no canal de eventos; 2. os consumidores invocam o método "pull" sobre o procurador de fornecedor; O canal de eventos invoca o mesmo método sobre os fornecedores ou usa mensagens recebidas anteriormente. No trabalho apenas vai ser usado o modelo Push, sendo usadas as duas seguintes interfaces para o envio e recepção de eventos: module CosEventCom { exception Disconnected {; interface PushConsumer { void push(in any data) raises(disconnected); void disconnected_push_consumer(); ; interface PushSupplier { void disconnected_push_supplier(); ; ; Cada fornecedor oferece uma interface do tipo PushSupplier e cada consumidor uma interface do tipo PushConsumer. Para além do método Push, para enviar eventos, as interfaces oferecem métodos para os fornecedores e consumidores possam ser desligados do canal. Os canais de eventos oferecem uma interface CosEventChannelAdmin que permite obter as referências para os procuradores de consumidores e de fornecedores, e estabelecer as ligações ao canal: 20

21 module CosEventChannelAdmin { exception AlreadyConnected {; exception TypeError {; interface ProxyPushSupplier : CosEventComm::PushSupplier { void connect_push_consumer( in CosEventComm::PushConsumer push_consumer ) raises(alreadyconnected, TypeError); ; interface ProxyPushConsumer : CosEventComm::PushConsumer { void connect_push_supplier( in CosEventComm::PushSupplier push_supplier ) raises(alreadyconnected); ; interface ConsumerAdmin { ProxyPushSupplier obtain_push_supplier(); ; interface SupplierAdmin { ProxyPushConsumer obtain_push_consumer(); ; interface EventChannel { ConsumerAdmin for_consumers(); SupplierAdmin for_suppliers(); ; ; Um consumidor de eventos começa por invocar o método for_consumers de modo a obter uma referência para uma interface de gestão (ConsumerAdmin), onde é possível obter uma referência para a interface de um objecto procurador de fornecedor. Por fim, nesta interface cria uma ligação ao canal com o método connect_push_consumer. Um fornecedor de eventos começa por invocar o método for_suppliers de modo a obter uma referência para uma interface de gestão (SupplierAdmin), onde é possível obter uma referência para a interface de um objecto procurador de consumidor. Por fim, caso pretenda ser conhecido pelo procurador (para ser avisado em caso de desconexão), cria uma ligação ao canal com o método connect_push_supplier. Recomenda-se uma leitura do exemplo 4.2 com um exemplo concreto da utilização destas interfaces. O preenchimento de dados numa variável do tipo any obedece a regras semelhantes ao preenchimento de parâmetros de entrada na invocação de uma função. 4. AMBIENTE VISIBROKER PARA O BORLAND C++ BUILDER 4 O ambiente Borland C++ Builder 4 suporta o desenvolvimento integrado de aplicações CORBA desde que tenha sido instalado o Visibroker. Para utilizar uma interface, o programador apenas tem de acrescentar ao projecto o ficheiro IDL com a sua definição utilizando a opção 'Use CORBA Object ' do menu 'Edit', e de acrescentar as bibliotecas do Visibroker ao projecto. A partir daí, só tem de acrescentar o código dos clientes e dos servidores e mandar compilar os dois programas. 21

22 O ambiente oferece um conjunto de aplicações servidoras. As duas mais relevantes para o trabalho são: Visibroker Smart Agent - servidor de directório usado pelos ORB para pesquisar identificadores de objectos. Este servidor tem de estar activo para que o ORB funcione. NameExtF - servidor do serviço de nomes. Este servidor corre numa janela DOS e tem a seguinte lista de parâmetros: NameExtF [-SVCnameroot <root_name>] factory_name logfile. O valor root_name define o servidor de nomes raiz; factory_name define o nome com que o servidor de nomes é registado no ORB; e logfile define o nome do ficheiro onde o servidor guarda os registos. No trabalho só deve ser usado um único servidor de nomes partilhado por todas as máquinas do laboratório, de maneira a haver um espaço de nomes partilhado por todos os programas na rede local. channel - servidor do serviço de eventos. Este servidor corre numa janela DOS e tem a seguinte lista de parâmetros: channel MyChannel. O valor define o nome com que o objecto canal se vai registar no SmartAgent, permitindo localizá-lo com a operação _bind. No trabalho só deve ser usado um único servidor de eventos partilhado por todas as máquinas do laboratório, de maneira a haver um canal partilhado por todos os programas na rede local. O ambiente Visibroker oferece ainda um conjunto de ferramentas de gestão do sistema. Algumas das relevantes para o trabalho são: osagent - aplicação gráfica para configurar Smart Agents. osfind - aplicação que corre numa janela DOS e devolve uma lista dos Smart Agents activos numa rede e dos objectos registados em cada um deles. Foi desenvolvida a aplicação ListNames para poder ver os objectos registados no serviço de nomes num subcontexto de "rit2" Aplicação cliente-servidor utilizando o serviço de nomes Esta secção ilustra o desenvolvimento de uma aplicação, passo a passo, de forma a se aprender a usar o ambiente C++ Builder para criar aplicações. Pretende-se criar uma aplicação muito simples com um único método, atest, que escreve no écran "Olá mundo ". O primeiro passo é criar um ficheiro Test.idl : module This { interface Is { void atest(); ; ; Cliente Começa-se por criar um projecto vazio (new application) e por acrescentar o ficheiro Test.idl ao projecto (opção 'Use CORBA Object ' do menu 'Edit'). Após esta instrução o Builder compila o ficheiro IDL e acrescenta automaticamente ao projecto os ficheiros Test_c.cpp e Test_s.cpp. Paralelamente corre um Wizard que permite realizar a declaração de referências para o objecto (do tipo This::Is_ref) numa classe ou na função main. Neste exemplo não se vai usar esta facilidade. O programa cliente é simples. A sua form tem (com uma distribuição ao vosso gosto): um botão (Button1) que desencadeia o envio do pedido; uma caixa do tipo TEdit (Edit1) com o nome a pesquisar no serviço de nomes; uma caixa do tipo TMemo (Memo1) para visualizar as mensagens. 22

23 O código do programa cliente é apresentado em seguida. O ORB é declarado na classe TForm1 e é inicializado no construtor da classe TForm1. Cada vez que se prime o botão é feita uma consulta ao serviço de nomes e é invocada a operação atest. Para conseguir compilar o cliente com sucesso só falta incluir no projecto duas bibliotecas: ORB: C:\Inprise\vbroker\lib\orb_br.lib Serviço de nomes: C:\Inprise\vbroker\lib\name_br.lib Conteúdo do ficheiro unitc1.h : #ifndef Unitc1H #define Unitc1H // #include <Classes.hpp> #include <Controls.hpp> #include <StdCtrls.hpp> #include <Forms.hpp> #include "Test_c.hh" // class TForm1 : public TForm { published: // IDE-managed Components TButton *Button1; TEdit *Edit1; TMemo *Memo1; void fastcall Button1Click(TObject *Sender); private: // User declarations public: CORBA::ORB_var orb; // User declarations fastcall TForm1(TComponent* Owner); ; // extern PACKAGE TForm1 *Form1; // #endif Conteúdo do ficheiro unitc1.cpp : // #include <vcl.h> #pragma hdrstop #include "Unitc1.h" #include <CosNaming_c.hh> // #pragma package(smart_init) #pragma resource "*.dfm" TForm1 *Form1; // fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { orb= CORBA::ORB_init( argc, argv); catch(const CORBA::Exception& e) { Log("Exception : " + AnsiString(e._name())); exit(-1); // void fastcall TForm1::Button1Click(TObject *Sender) { 23

24 // Obtém referência para servidor de nomes CosNaming::NamingContext_var context; CORBA::Object_var obj= orb->resolve_initial_references("nameservice"); context= CosNaming::NamingContext::_narrow(obj); catch(const CORBA::Exception& e) { Log("O programa deve ser corrido com opção '-SVCnameroot nome'"); Log("Exception : " + AnsiString(e._name())); return ; if (CORBA::is_nil(context)) { Log("O servidor de nomes não está activo"); return ; Memo1->Lines->Add("Recebeu referência para NameServer"); // Preenche nome CosNaming::Name name; name.length(2); name[0].id = CORBA::string_dup("bingo"); AnsiString id= Edit1->Text; name[1].id = CORBA::string_dup(id.c_str()); This::Is_var test; Memo1->Lines->Add("Procurando Contexto \""+ AnsiString(id) + "\""); CORBA::Object_var obj; obj = context->resolve(name); catch(const CosNaming::NamingContext::NotFound& e) { Memo1->Lines->Add("Excepção na pesquisa do nome : '" + AnsiString(id) + "' não está registado"); return; catch(const CORBA::Exception& e) { Memo1->Lines->Add("Excepção : " + AnsiString(e._name())); return; Memo1->Lines->Add("recebeu resposta do servidor nomes"); test = This::Is::_narrow(obj); // obter informação de descritor if(!corba::is_nil(test)) { test->atest(); catch(const CORBA::Exception& e) { Memo1->Lines->Add("Excepção : " + AnsiString(e._name())); Memo1->Lines->Add("operação invocada"); Servidor A fase inicial do desenvolvimento do servidor é muito semelhante ao cliente. Também se acrescenta o ficheiro Test.idl a um projecto vazio e constrói-se uma janela com: um botão (Button1) com a propriedade Caption = "Arrancar". Este botão permite arrancar ou parar o servidor; uma caixa do tipo TEdit (Edit1) com o nome a registar no serviço de nomes; 24

25 uma caixa do tipo TMemo (Memo1) para visualizar as mensagens. Para realizar o servidor vai-se utilizar o módulo "corba_server.cpp", sendo necessário acrescentá-lo ao projecto e fazer #include de "corba_server.h". O programa servidor inclui: a função Log (necessária para usar o módulo corba_server); a implementação do objecto (classe Is_impl); a rotina de tratamento do botão que arranca ou pára o servidor; e a rotina de tratamento do evento de terminação da janela, para cancelar o registo do objecto no serviço de nomes e terminar a thread CORBA. O código do programa servidor é apresentado em seguida. Também é necessário incluir as duas bibliotecas usadas no cliente: ORB: C:\Inprise\vbroker\lib\orb_br.lib Serviço de nomes: C:\Inprise\vbroker\lib\name_br.lib Conteúdo do ficheiro units1.h : // #ifndef Units1H #define Units1H // #include <Classes.hpp> #include <Controls.hpp> #include <StdCtrls.hpp> #include <Forms.hpp> #include "Test_s.hh" class It_Impl; // Pré-declaração da classe implementação // class TForm1 : public TForm { friend It_Impl; // dá acesso à classe a partir de It_impl published: // IDE-managed Components TMemo *Memo1; TButton *Button1; TEdit *Edit1; void fastcall Button1Click(TObject *Sender); void fastcall FormClose(TObject *Sender, TCloseAction &Action); private: public: // User declarations CORBA::ORB_ptr orb; CORBA::BOA_ptr boa; It_Impl *obj; // User declarations fastcall TForm1(TComponent* Owner); ; // extern PACKAGE TForm1 *Form1; // #endif Conteúdo do ficheiro units1.cpp : // #include <vcl.h> #pragma hdrstop #include "Units1.h" #include <CosNaming_c.hh> // Cliente serviço nomes #include "corba_server.h" // #pragma package(smart_init) 25