BR112012013808B1

BR112012013808B1 - sistema de rede para rede transparente

Info

Publication number: BR112012013808B1
Application number: BR112012013808-1A
Authority: BR
Inventors: Kevin Stallard
Original assignee: Aerial Robotics, Inc.
Priority date: 2009-12-11
Filing date: 2010-12-13
Publication date: 2021-02-09
Also published as: BR112012013808A2; US20160077813A1; WO2011071543A2; CA2783829C; US9672014B2; US9135055B2; WO2011071543A3; US20120323994A1; CA2783829A1

Abstract

SISTEMA DE SUBSTRATO DE REDE TRANSPARENTE. A presente invenção refere-se a um sistema de substrato de rede transparente, que inclui pelo menos um módulo de servidor e pelo menos um módulo de cliente. O módulo de servidor provê uma funcionalidade selecionada, tal como mover um atuador, realizar uma operação matemática e receber dados de um sensor. Mediante uma execução, o código de máquina de módulo de servidor escreve uma informação necessária para a descrição da funcionalidade selecionada na memória. A informação escrita na memória inclui uma informação necessária para invocar a funcionalidade de módulo de servidor, e pode incluir tipos, membros e parâmetros. O módulo de cliente busca na memória pela funcionalidade selecionada; requisita uma informação a partir do módulo de servidor; e invoca a funcionalidade do módulo de servidor. Uma vez invocada pelo cliente, o módulo de servidor usa a informação na memória para a criação de chamadas de função dinâmicas.

Description

[0001] A presente invenção refere-se a um sistema de substrato de rede transparente.

REFERÊNCIA CRUZADA A PEDIDOS RELACIONADOS

[0002] O presente pedido reivindica o benefício do Pedido Provisório U.S. N° 61/285.905, depositado em 11 de dezembro de 2009, cuja exposição é desse modo incorporada como referência em sua totalidade.

APÊNDICE COM LISTAGEM DE PROGRAMA DE COMPUTADOR

[0003] Um apêndice de listagem de programa de computador é submetido com este em um disco compacto. O material no disco compacto desse modo é incorporado como referência em sua totalidade. Um disco é incluído com o presente pedido, e o referido disco inclui:

[0004] TNSmacros.hpp, criado em 10 de dezembro de 2010, tamanho de arquivo de 28 kb. O apêndice de listagem de programa de computador incorporado acima é referido aqui como o APÊNDICE A. ANTECEDENTES

[0005] Fazer com que entidades (processos) de execução em separado interajam com cada outra é um traço desejável de sistemas distribuídos complexos. Permite a execução separadamente de entidades para se tirar vantagem de cada outra funcionalidade, sem incluir especificamente aquela funcionalidade na entidade.

[0006] Há várias tecnologias que existem atualmente, que proveem este tipo de comunicação de processo cruzado. A Microsoft tem COM (modelo de objeto componente) e DCOM (modelo de objeto componente distribuído), os sistemas UNIX têm CORBA (arquitetura de intermediário de requisição de objeto comum). Estes sistemas de fato proveem seu acesso cruzado binário / de processo / de recurso executável, embora eles sejam complexos pelo fato de haver numerosos detalhes que precisam ser considerados por um desenvolvedor usando estas tecnologias. Isto torna o uso destes recursos difícil e, quando instalados em sistemas, requerem uma grande quantidade de manutenção, e são frágeis (eles nem sempre funcionam corretamente), já que eles requerem numerosos arquivos e regulagens de configuração para existirem e estarem corretos. Um disco rígido corrompido ou um apagamento acidental de apenas um destes arquivos pode fazer com que o sistema pare.

[0007] Linguagens de computador mais novas simplificaram este processo. Contudo, estas linguagens mais novas mais frequentemente são encontradas em uma faixa estreita de plataformas de sistema operacional (Microsoft Windows, por exemplo) e não estão disponíveis em sistemas em tempo real e críticos quanto à segurança. Mais ainda, estas linguagens proveem dificuldade para desenvolvedores de sistemas com segurança crítica, já que eles às vezes realizarão operações e exibirão um comportamento que é incompatível com as exigências de validação para esses sistemas. Por exemplo, algumas linguagens executam operações automáticas (e, às vezes, imprevisíveis e ilimitadas) que não foram especificamente requisitadas pelo programador. Embora estas sejam consideradas úteis na garantia de qualidade de aplicativos de finalidade geral, elas podem ser prejudiciais para sistemas especializados. A coleta de lixo é um exemplo, isto é onde uma execução de programa é interrompida enquanto uma memória que é julgada não usada é retornada para o grupo de memória usável. Esta operação é considerada útil para sistemas de finalidade geral, mas, por causa de sua imprevisibilidade em termos de quando é rodada e quanto tempo leva, é problemática em sistemas de tempo real. Estas linguagens de computador mais novas ainda requerem instalações complexas e numerosos arquivos e regulagens de configuração que tornam o sistema vulnerável a uma falha inexplicável.

[0008] Uma implementação bem-sucedida de um sistema baseado em COM / DCOM ou CORBA requer interfaces estáticas e rígidas para uma funcionalidade exportada. Se o acesso a uma interface exposta for tentado sem o entendimento correto desta estrutura, erros ocorrerão, nos quais a funcionalidade por trás da interface exposta usualmente interromperá a operação completamente e, às vezes, de forma catastrófica. Estas definições de interface existem separadamente do executável. Se estas definições de interface se tornarem corrompidas ou se elas não combinarem com o executável, então, o sistema falhará de formas inexplicáveis.

[0009] COM / DCOM e CORBA têm que usar uma etapa de compilação adicional para a exposição correta das interfaces contidas ali, por exemplo, um programa em C/C++. A construção de programas em C/C++ requer duas etapas conhecidas como a etapa pré- processador (preparação do código para o compilador) e a etapa de compilador (conversão de código C/C++ em linguagem de máquina). Ambas estas operações são realizadas pelo executável compilador em si. Se COM / DCOM ou CORBA precisarem ser usados, um arquivo em separado contendo a interface exposta desejada denominada uma linguagem de definição de interface (IDL) deverá ser preparada e rodada através de um compilador em separado que entenda esta IDL. A etapa de compilador de IDL resulta em um arquivo que é separado do binário contendo uma informação descritiva sobre a interface, bem como outros artefatos. Estes não são incluídos no binário e, portanto, são vulneráveis a se tornarem fora de sincronização com o binário. SUMÁRIO

[00010] Um Substrato de Rede Transparente (TNS) é um sistema que abandona muito da complexidade dos sistemas descritos acima. O TNS é capaz de: 1. Proporcionar acesso de entidades de execução em separado a recursos de cada outra, sem o tempo de processamento de um subsistema instalado separadamente. 2. É capaz de prover este acesso por muitas topologias de formação de rede e tecnologias de comunicação sem emendas. 3. Não realiza operações de fundo que podem ter impacto sobre validação e determinismo em tempo real. Todas as operações de um sistema de TNS são previsíveis e determinísticas. 4. Permite um compartilhamento executável cruzado de recursos em uma faixa mais ampla de sistemas operacionais e plataformas. 5. Definições de interface são criadas dinamicamente, e são parte do executável, isto removendo a chance de ser corrompido ou sair de sincronização com um software atualmente instalado. Ao invés de ter que instalar vários arquivos e regulagens de configuração, apenas um executável é necessário para rodar no sistema alvo. 6. Entidades executáveis (clientes) que requerem uma funcionalidade a partir das entidades executáveis habilitadas para TNS (servidores) podem aprender a interface de servidor no tempo de rodada a partir do processo de servidor. Isto abre a porta para uma descoberta de interface inteligente e aumenta o potencial de um sistema para uma modificação de autocomportamento verdadeiramente dinâmica. 7. Os clientes podem decidir dinamicamente se a interface pode ser chamada ou fazer ajustes nos dados enviados para combinação com a interface. 8. Nenhum outro arquivo é requerido, apenas o binário contendo o código executável é requerido. Nenhuma outra ‘camada’ de software precisa ser instalada no computador usando TNS. 9. Os desenvolvedores podem usar compiladores nativos, tal como C/C++, e não são travados em um conjunto específico de vendedor de ferramentas complexas e funcionalidade complexa.

[00011] Todos os mecanismos conhecidos no mercado hoje em dia requerem muita infraestrutura, de modo a terem unidades em execução separadamente se comunicando e usando uma funcionalidade de cada outra. O TNS provê vários benefícios não encontrados nos sistemas do estado da técnica atual. Eles são: 1. Combina toda a funcionalidade necessária em um único binário. 2. Elimina exigências de configuração de sistema extensivas. 3. Elimina a necessidade de quaisquer ferramentas adicionais necessárias durante a construção e o processo de desenvolvimento. Um compilador moderno, tal como um compilador de C/C++, é tudo que é necessário. 4. O desenvolvedor não precisa levar em consideração que sua funcionalidade pode ser usada com TNS. 5. O TNS provê o código fonte específico de compilador para o compilador gerar um código fonte e o código de máquina necessário para executar as operações complexas necessárias para se tornar possível uma invocação de uma funcionalidade remota. 6. Elimina a necessidade de todo detalhe da estrutura de interface ser conhecido antes de um cliente tentar se comunicar com um servidor. 7. Elimina a necessidade de a interface ser um contrato imutável (não modificável) entre cliente e servidor através de uma resolução de conflito de interface. 8. Provê aos desenvolvedores, usando uma faixa mais ampla de sistemas operacionais e que estão desenvolvendo para sistemas com recursos limitados, uma ferramenta para permitir uma implementação de um sistema distribuído com baixo tempo de processamento em termos de potência de processamento necessário e armazenamento não volátil.

[00012] Em uma modalidade, o sistema de TNS é implementado em um meio de armazenamento que pode ser lido em máquina não transitório que inclui um código de máquina para instrução de um microprocessador. O código de máquina pode incluir pelo menos um módulo de servidor e pelo menos um módulo de cliente.

[00013] O módulo de servidor inclui um código de máquina de servidor que provê uma funcionalidade selecionada, tal como mover um atuador, realizar uma operação matemática, receber dados de um sensor, e combinações dos mesmos. Mediante a execução, o código de máquina de servidor escreve uma informação necessária para a descrição da funcionalidade selecionada para um dispositivo de memória. A informação escrita na memória inclui uma informação necessária para invocar a funcionalidade de módulo de servidor e pode incluir tipos, membros e parâmetros. O código de máquina de servidor usa a informação na memória para a criação de chamadas de função dinâmica.

[00014] O módulo de cliente inclui um código de máquina de cliente que busca na memória pelo servidor provendo a funcionalidade selecionada; requisita uma informação do módulo de servidor sobre a funcionalidade; e invoca a funcionalidade do módulo de servidor. O módulo de cliente inclui uma funcionalidade de consulta de interface incluindo um código de máquina de cliente para a recuperação de tipos; a recuperação de todos os membros para cada tipo; e a recuperação de todos os parâmetros para cada membro.

[00015] O módulo de cliente inclui uma funcionalidade de serialização de dados que determina se os parâmetros são fixos ou variáveis no comprimento, e captura o comprimento dos parâmetros que são determinados como sendo de comprimento variável. Um parâmetro pode ser acompanhado por um parâmetro de comprimento de dados, e o módulo de cliente é operativo para armazenar um endereço do parâmetro e o parâmetro de comprimento de dados em um vetor de entrada e saída.

[00016] O código de máquina de servidor pode ser gerado por um compilador rodando em um microprocessador a partir do código fonte de servidor. O código fonte de servidor inclui um código fonte para a geração do código de máquina de servidor que provê a funcionalidade selecionada. O código fonte de servidor também inclui um código para a geração de um código de máquina de servidor representativo da informação e para a geração de um código de máquina de servidor que é operativo para escrever o código de máquina representativo da informação a partir do dispositivo móvel.

[00017] O compilador inclui um pré-processador e pelo menos uma porção do código fonte de servidor pode ser criada pelo pré- processador. O pré-processador usa um código fonte na forma de uma macro para a criação da porção do referido código fonte de servidor. Pelo menos uma porção do código fonte de servidor pode ser criada pelo compilador.

BREVE DESCRIÇÃO DOS DESENHOS

[00018] A figura 1 é uma representação esquemática de nível alto da arquitetura de sistema de TNS; a figura 2 é um diagrama que ilustra os limites de responsabilidade atribuídos a Servidores de TNS, bem como a funcionalidade que usa para responder a requisições de Cliente de TNS e gerenciar apropriadamente a comunicação com Clientes de TNS; a figura 3 é um diagrama que ilustra os limites de responsabilidade atribuídos a Clientes de TNS, bem como a funcionalidade de Clientes de TNS a usar para se comunicar apropriadamente com Servidores de TNS; a figura 4 é um diagrama que descreve um sistema de TNS de exemplo em uma forma na qual ele poderia ser usado; a figura 5 é um diagrama que ilustra as etapas que o compilador gasta na construção de um executável habilitado para TNS; a figura 6 um diagrama que descreve amplamente a funcionalidade de consulta de interface de cliente de TNS; a figura 7 é um diagrama que ilustra em maiores detalhes a funcionalidade de consulta de interface de cliente de TNS ilustrada na figura 6; a figura 8 é um diagrama que descreve amplamente o processo de invocação de função de cliente de TNS para servidor de TNS; a figura 9 é um diagrama que ilustra em maiores detalhes o processo de invocação de função de cliente de TNS para servidor de TNS ilustrado na figura 8; a figura 10 é um diagrama que ilustra o processo de serialização de dados; e a figura 11 é um diagrama de blocos funcionais de uma estação de trabalho de exemplo consistente com a tecnologia do presente pedido.

DESCRIÇÃO DETALHADA Estrutura de Sistema

[00019] O sistema de TNS é realizado em duas partes principais. O executável que expõe uma funcionalidade (isto é, a capacidade de mover um atuador, fazer uma operação matemática complexa, ou recuperar dados a partir de um sensor) é denominado um servidor habilitado para TNS, também referido aqui como um servidor de TNS, um servidor ou um módulo de servidor. O executável que usa uma funcionalidade de um Servidor de TNS é denominado um cliente habilitado para TNS, também referido aqui como um cliente de TNS, um cliente ou um módulo de cliente. O termo servidor conforme usado aqui se refere a um programa de computador rodando como um serviço, para servir às necessidades ou requisições de outros programas (referidos neste contexto como “clientes”), os quais podem ou não estar rodando no mesmo computador. Embora as modalidades de exemplo sejam descritas com respeito a C/C++, é contemplado que outras linguagens de programação adequadas podem ser usadas para a implementação do sistema de TNS descrito aqui.

[00020] Com referência, primeiramente, à figura 1, o sistema de TNS amplamente inclui um servidor de TNS 10 e um cliente de TNS 50. Conforme explicado mais plenamente abaixo, mediante a execução, o servidor de TNS escreve 21 uma informação sobre si mesmo para uma memória 5. O cliente 50 recupera 22 a informação na memória 5, de modo a encontrar o servidor e sua funcionalidade, bem como para se comunicar com o servidor 10. Usando a informação, o cliente 50 pode enviar 24 uma mensagem para o servidor 10, de modo a invocar uma funcionalidade do servidor. Uma vez que o servidor 10 receba uma mensagem do cliente, o servidor 10 recupera 26 a informação na memória 5, de modo a criar chamadas de função dinâmica.

[00021] A figura 2 enumera amplamente o processo do servidor de TNS 10 e a funcionalidade fundamental necessária para o gerenciamento de conexões com Clientes de TNS. Esta funcionalidade é na forma de um stub de servidor de TNS 20 que inclui uma funcionalidade de gerenciamento de conexões 32, uma funcionalidade de gerenciamento de instâncias de classe 34, uma funcionalidade de recuperação de classe e de interface de classe 36, e uma execução de chamadas de método requisitadas em instâncias de classe 38. A funcionalidade de gerenciamento de conexões 32 mantém um rastreamento das entidades (clientes) que estão requisitando a funcionalidade de servidor 12. Permite o cumprimento de políticas de segurança e de acesso, bem como provê uma encriptação de dados para links seguros. A funcionalidade de gerenciamento de conexões 32 inclui uma rotina de apagamento de instância de classe 42, a qual é usada para o apagamento das instâncias de funcionalidade criadas e usadas pelo cliente, quando ele desconectar. Estas instâncias às vezes são referidas como ‘instâncias de classe’. O servidor 10 também inclui descrições de gerenciamento de interface de classe 44, as quais permitem que o código gerado em compilador em metadados acumulados e armazenados 48 grave a informação acumulada na partida 14. Também provê meios para a recuperação de descrições de classe e de interface de classe 36 para a recuperação da informação que ele envia para um requisitante (isto é, um Cliente de TNS).

[00022] A figura 3 ilustra um Cliente de TNS 50 e a funcionalidade que ele contém para conexão a e uso de um Servidor de TNS 10. Esta funcionalidade é na forma de um stub de cliente de TNS 60 que inclui encontrar e se conectar a um servidor 62 para a obtenção de descrições de interface de servidor 64, instanciar uma classe de servidor 66, verificar uma compatibilidade de servidor 63, chamar métodos em uma classe 68 e exibir um relatório de compatibilidade 69.

[00023] A figura 4 ilustra um exemplo de um sistema distribuído usando TNS. O exemplo inclui dois servidores habilitados para TNS 110 e 210. Neste exemplo, o servidor de TNS 110 contém a funcionalidade necessária para a leitura de um sensor (não mostrado) que detecta um movimento rotativo e o servidor de TNS 210 contém a funcionalidade necessária para controle de um servo (não mostrado). Os clientes de TNS 150, 250, 350 e 450 são conectados, cada um, a um ou mais dos servidores de TNS. Cada cliente tem funções especializadas que eles podem realizar e precisam de dados a partir do sensor de movimento ou precisam controlar o servidor ou ambos. Com referência de novo à figura 3, os clientes se conectam aos servidores de TNS usando a funcionalidade de encontrar e conectar a um servidor 62, recuperam a interface de funcionalidade de servidor usando a funcionalidade de obter descrição de interface de servidor 64, criam instâncias de funcionalidade no servidor através da funcionalidade de instanciar 66 e verificam uma funcionalidade de compatibilidade 63, e chamam uma funcionalidade específica naquelas instâncias usando métodos de chamada em uma funcionalidade de classe 68. Se houver não combinações entre o que o cliente espera usar e o que o servidor provê (em termos de uma interface), esta informação será exibida ou reportada usando-se uma funcionalidade exibição de relatório de compatibilidade 69. Coleta de metadados

[00024] Em uma implementação em C++ de TNS, o TNS expõe ou exporta uma funcionalidade de um servidor de TNS para clientes de TNS usando elementos primitivos de compilador (também conhecidos como macros) e modelos. Estes macros e modelos acumulam uma informação ou inserem um código que acumula uma informação de reflexão / metadados no tempo de rodada. Quando o compilador processa o código fonte de Servidor de TNS, o que vem a seguir ocorre: 1. Os modelos são traduzidos em instruções que permitem que as classes sejam instanciadas e os métodos chamados condicionalmente. Em C++, estes são conhecidos comumente como ‘functores’. 2. Cria um código que executa as funções a seguir: 2.1 Capturar os nomes das classes (se houver), os nomes de métodos e funções, e os nomes dos tipos de dados e parâmetros. 2.2 Analisar gramaticalmente listas de parâmetro e parâmetros de marca pretendidos para uma especificação de comprimento de dados de dados de comprimento variável. Associar o parâmetro de comprimento de dados ao parâmetro contendo os dados de comprimento variável. 2.3 Armazenar os tipos de dados capturados e os nomes de símbolo em um banco de dados de memória. 2.4 Fazer com que as classes de modelo instanciadas formem um arranjo de tipos de dados. Este arranjo usa uma classe de base abstrata, as classes de modelo são derivadas a partir daquela classe de base abstrata. Isto permite que os tipos sejam armazenados em um arranjo e permite que operações específicas de tipo ocorram (isto é, criação de uma classe ou invocar um método).

[00025] A figura 5 ilustra o que ocorre quando um compilador processa o código fonte de servidor de TNS 430 em uma implementação em C++ de exemplo. O compilador 440 é compreendido por três partes, um pré-processador 442, um gerador de código 444 e um compilador de código 446. O compilador 440 lê o código a partir de vários arquivos de referência de modo a resolver as instruções encontradas no código fonte de servidor 430. O código fonte de servidor 430 inclui um arquivo ou arquivos que definem o comportamento de servidor que é para ser exportado (isto é, rotinas de controle de servomotor). Os arquivos de referência incluem um arquivo de cabeçalho contendo definições de macro 400, um arquivo de cabeçalho contendo definições de modelo em C++ 410 que proveem meios para a criação, o armazenamento e o acesso a functores em C++, e um arquivo de cabeçalho contendo definições de modelo para a criação, o armazenamento e o acesso à definição de tipo de dados 420.

[00026] O compilador 440 resolve o código fonte de servidor em três passes de pré-processamento. O primeiro passe traduz as declarações de macro 400 para o código de TNS correspondente necessário que criará os metadados discutidos anteriormente. Uma vez que esta substituição tenha sido completada, o segundo passe é a geração de código em que o código de modelo é instanciado conforme necessário. No terceiro passe, o código é passado para o estágio de compilador 446, onde o objeto ou código de máquina 455 é gerado.

[00027] O código de máquina 455 é alimentado para um formador de enlace 495 o qual combina o código de máquina 455 com várias outras bibliotecas de suporte ou arquivos, tais como a biblioteca de TNS 470, as bibliotecas de suporte de os 480 e as bibliotecas para suporte da linguagem C++ 490. Quando o formador de enlace 495 termina, ele extrai o executável de servidor habilitado para TNS 460.

[00028] O que vem a seguir é uma exportação de TNS de exemplo de uma classe de C++ e seus membros (porção de definição de código fonte 430). São incluídas no Apêndice A as macros de TNS necessárias para a compilação desta classe de exemplo. Wndef _EXAMPLE_H tiinclude <wchar.h> ttiπciude <iostπeam> ^include <ermo.h> ^include <stdint.h> ttiπclude "TNS hpp" include "TNSSymbolDef.hpp" ^include "TNSTypeDef.hpp" ttmclude "TNSMacros-hpp" TNS_BEGIN_CLASS_DEFdVE( Example, ExampleBase ) TNS_CONSTRUGTOR( Example( ) ) TNS_CONSTRUCTOR( Examplef const char *Name) J TNS_DESTRUCTOR( -ExampleQ ) INSISTA TIC_METHOD(GetMainExample, Example ★GetMainExampleQ) TNS_STA TIC_METHOD(SetMaiπExamp)e, void SetMainExampief Example * widget)) TNS_METHOD( Add, int Add( Example ‘widget J ) TNS_METHOD( Remove, int Remove( Example *widget) ) TNS_METHOD( AddVarLenData, int AddVarLeπData( char ‘name, char 'data, int datalen)) TNS_METHOD( AddString, int Add String! char "name, char ‘string)) TNS_METHOD( GetVarLenData, int GetVarLenDataf char ‘name, char ‘data, int &dataleπ)) TNS_METHOD( GetString, int GetStringf char ‘name, char ‘string, int &stringlen)) TNS_METHOD( ToFront, int ToFroπt() ) TNS_METHOD( ToBack, int ToBack()) TNS_METHOD( GetParent, Example *GetParent()) TNS_STARTUPMETHOD() TNS_SHUTDOWNMETHOD() TNS_END_ CEASS( PhWidget); #if 'defined _EXAMPLEJ-I_PASS itdefine _EXAMPLE_H_PASS 1 #include "Example hppH tielif defined_EXAMPLEJ-I_PASS && _EXAMPLEJd_PASS == 1 #uπdef-EXAMPLE-H_PASS itdefine _EXAMPLE_H_PASS ttinclude "Example.hpp" #elif_EXAMPLE_H_PAS$ == 2 #undef_EXAMPLE_H_PASS Itdefine-EXAMPLE-H-PASS 3 ttinclude "Example.hpp1' itelif _EXAMPLE_H_PASS ~ 3 ttundef-EXAMPLE-H-PASS itdefíne _βXA MPLE_H fendif ECLASSDEF_HPP_ 7 itendif//_PTWIDGETH_

[00029] Em primeiro lugar está a declaração de classe usando a macro de TNS TNS_BEGIN_CLASS_DERIVE(). Esta macro indica que a classe de C++ sendo exportada é derivada de uma classe de base. O próximo item é o construtor de classe. Em C++, a área ocupada de tipo de um construtor difere daquela de um método de classe, de modo que o TNS provê uma macro distinta para construtores. O mesmo se aplica a destruidores. Então, há os métodos de classe. C++ pode ter métodos de classe estáticos (globais) e pode ter métodos de classe normais; o TNS contabiliza ambos. Ao fim do arquivo de exemplo acima, há várias condicionais de pré-processador. Estas permitem que o arquivo de definição de classe (arquivo de cabeçalho) tenha múltiplos passes feitos pelo pré-processador de C++ 442, antes de entrar no estágio de compilador 446. Isto permite que as macros sejam redefinidas de formas que são necessárias para a captura da informação contida em parâmetros de macro.

[00030] Opcionalmente, o cliente habilitado para TNS que tem um conhecimento prévio dos métodos que ele invocará usa as instruções de compilador de TNS para fazer as mesmas coisas que ele faz para o servidor nos métodos que ele chamará no servidor (isto é, criar um banco de dados em memória dos tipos que estará usando para interagir com o servidor). Contudo, um cliente de TNS não precisa saber de antemão (quando é compilado e construído) que funcionalidade o servidor contém. Ele pode enumerar a funcionalidade do servidor e invocar qualquer que seja a funcionalidade que desejar.

[00031] Os metadados são usados para: 1. Arbitrar interfaces. 2. Instanciar classes. 3. Chamar métodos e obter valores de retorno

[00032] Quando o binário de servidor começa, o compilador inseriu o código necessário para a coleta de metadados e a informação de tipo das interfaces exportadas. Este código acumula e armazena a informação a seguir: 1. Funções, classes e métodos que foram marcados para exportação pelo desenvolvedor. 2. Uma informação é acumulada pelo compilador em combinação com o código gerado em compilador para descrever plenamente cada um dos símbolos exportados e suas especificações de tipo. A informação acumulada inclui: a. O nome do símbolo. b. Seu tipo. i. Isto não é apenas o nome, mas também o compilador gera um código que é capaz de criar o tipo mediante uma requisição no tempo de rodada. ii. No caso de C++, isto é feito usando-se um código de modelo em C++ e functores. c. Tratos de tipo. i. Um conjunto de variáveis que são preenchidas com uma informação sobre as várias características do tipo. Estas incluem: 1. Alinhamento de byte. 2. Se houver um arranjo, o número de dimensões. 3. Se houver uma função ou um método, o número de argumentos. 4. Tem ou não uma atribuição ou se ele precisa de um operador sobrecarregado real. 5. É de tipo de inteiro ou ponto flutuante? 6. É um arranjo? 7. É de uma classe ou um tipo de agregado (um tipo a partir da combinação de outros tipos). 8. Foi rotulado como um tipo de constante. 9. É um tipo composto (isto é, um ponteiro ou uma referência, etc.). 10. É de um tipo vazio. 11. É uma enumeração. 12. É um ponto flutuante. 13. É um tipo fundamental (isto é, POD (tipo de dados antigos sem formatação)). 14. É o tipo um protótipo de função. 15. É um inteiro. 16. É uma função / ponteiro de membro de função. 17. É um ponteiro para um objeto de classe. 18. É um ponteiro para um membro de uma classe. 19. É o tipo de um construtor ou uma classe. 20. É o tipo de e dados uma estrutura de “dados antigos sem formatação”. 21. É o tipo um ponteiro. 22. É o tipo polimórfico. 23. É o tipo escalar. 24. É sem estado (o objeto tem um construtor trivial e não mantém quaisquer dados). 25. É uma referência. 26. É uma união. 27. É um tipo vazio. d. Se o símbolo fizer parte de um agregado, então, o deslocamento do começo do agregado será gravado. e. Se o símbolo for uma função, então, os argumentos para aquela função serão analisados gramaticalmente e gravados. 1. Se um argumento representar o comprimento de um argumento que referencia dados de comprimento variável, então, o nome do argumento designando o comprimento dos dados será gravado, bem como uma referência ao argumento. Isto permite que o sistema associe o argumento de comprimento de dados com o argumento que referenciará os dados de comprimento variável quando em comunicação com o servidor. f. Se um símbolo de um tipo agregado ou uma classe, uma lista de membros (símbolos e tipos de dados) será gravada. Isto é recursivo até subagregados serem cobertos. 3. A informação acumulada é configurada para inicializar estruturas internas na partida. Quando o programa usando TNS começa, estas estruturas de dados são criadas e inicializadas com a informação acumulada no momento da compilação. Isto permite que o servidor tenha acesso a um banco de dados contendo toda a informação necessária para a descrição de como acessar uma funcionalidade de servidor, bem como a capacidade de instanciar classes e invocar métodos sem o desenvolvedor ter que lidar com o código. Interface de troca de informação

[00033] Os clientes de TNS podem usar a funcionalidade acima, se o cliente for para conter ‘dicas’ quanto ao que o servidor expõe, embora não seja requerido. Os clientes de TNS têm instruções incluídas que consultam os servidores de TNS quanto a suas interfaces expostas. Assim, os clientes de TNS podem ser ‘ignorantes’ em termos do que um servidor contém e quando ele está rodando pode construir dinamicamente uma tabela do que um servidor provê, e pode usá-la para invocar uma funcionalidade de servidor.

[00034] Isto é realizado pelo uso de um mecanismo de comunicação (a comunicação interprocesso de sistema operacional nativo, TCP/IP ou memória compartilhada - o TNS não especifica o mecanismo de comunicação) usado para servidores de TNS e clientes de TNS passarem uma informação para cada outro.

[00035] O cliente de TNS inclui uma funcionalidade de consulta de interface que permite a um cliente consultar um servidor para descobrir sua interface. Com referência às figuras 6 e 7, há uma interface imutável com servidores habilitados para TNS, e isto é para ser capaz de adquirir uma informação de interface adicional. Em outras palavras, não importando qual funcionalidade de servidor é exportada, um servidor habilitado para TNS tem alguma funcionalidade que está sempre ali. Isto é: 1. Obter Tipos Exportados 2. Obter Membros de Classe 3. Obter Parâmetros de Método

[00036] Estes três pedaços de funcionalidade permitem que o servidor descreva completamente a funcionalidade disponível e como acessá-la. Toda a informação acumulada durante a coleta de metadados é provida para o cliente. O processo para recuperação desta informação é conforme se segue: 1. O cliente primeiramente usa Obter Tipos Exportados para recuperar todos os tipos no sistema. 2. Ele itera através de cada um dos tipos e para aqueles que têm submembros (classes e estrutura ou tipos agregados), ele chama Obter Membros de Classe. Isto recupera os tipos e os nomes dos membros da classe ou da estrutura. Ele faz isso de forma recursiva. 3. Então, ele itera através daqueles membros e daqueles que são métodos, ele chama Obter Parâmetros de Método para a recuperação de uma informação sobre cada um dos parâmetros ou argumentos.

[00037] Uma vez que a informação sobre as interfaces seja recuperada, o cliente opcionalmente pode rever aquelas interfaces para garantir que as interfaces estejam para chegar a uma combinação. Caso elas não combinem, o cliente poderá fazer mudanças na forma pela qual chamará a interface ou reportará a não combinação. A decisão quanto a não usar uma interface não combinada não é especificada pela TNS, é papel do arquiteto ou desenvolvedor do sistema. Maiores informações sobre esta resolução de conflito são encontradas abaixo sob a interface de resolução de conflito.

[00038] Se o cliente não souber que funções serão chamadas de antemão (isto é, se o cliente está rodando um script), ele usará esta informação para determinar se o método de requisição ou classe no script pode ser chamado ou instanciado no tempo de rodada. Isto permite que o cliente processe um script sem qualquer pré- processamento. Interface de resolução de conflito

[00039] Se os clientes de TNS forem construídos com uma informação de interface sobre um servidor de TNS, quando o cliente de TNS rodar, ele ainda consultará o servidor quanto a esta mesma informação. Então, ele comparará suas referências internas a esta interface com as referências que ele recuperou a partir do servidor. Se estas interfaces diferirem, o cliente de TNS poderá tentar encontrar uma forma de resolver aquelas diferenças e prover uma forma segura de chamar a interface. Se uma resolução não puder ser encontrada, a interface será desabilitada e um aviso será gerado. Como um exemplo, o cliente pode esperar uma entrada de ponto flutuante, mas por qualquer razão que seja, o servidor a que ele está conectado provê uma interface que requer um inteiro de 16 bits. A resolução para uma diferença como essa de interface é converter o ponto flutuante em um inteiro de 16 bits. Se o cliente encontrar uma interface para a qual nenhuma conversão é possível, então, a interface será desabilitada e nenhuma tentativa de chamada será feita. Estas regras são providas pelo desenvolvedor da funcionalidade de cliente e servidor. Em alguns sistemas, isto seria perigoso e, portanto, não permitido. Quaisquer diferenças de interfaces desabilitarão o cliente e mensagens de erro apropriadas serão exibidas. Invocação de interface e serialização de dados

[00040] Uma vez que o cliente tenha recuperado, validado e resolvido uma interface para um servidor de TNS, ele está pronto para invocar a funcionalidade no servidor. A informação de interface que ele contém agora é convertida em instruções sobre como posicionar os dados em um fluxo de dados que é enviado para o servidor. Isto é denominado serialização. O servidor está esperando os dados em um formato em particular e, subsequentemente, recupera e valida estes dados antes da chamada da funcionalidade atual.

[00041] A função exportada ou o método chamado é um método normal e não tem conhecimento que está sendo usado em um sistema de TNS. Quando a função se completa, o TNS toma os resultados e os posiciona no fluxo de dados que então é enviado de volta para o cliente. O cliente, por causa de seu conhecimento da estrutura de interface, recupera os valores retornados a partir do método invocado no servidor de TNS.

[00042] Com referência às figuras 8 e 9, para invocar um método em um servidor, a informação a seguir é necessária: 1. Uma conexão com o servidor ao qual a requisição de chamada será feita. 2. A ID de tipo da classe ou tipo de estrutura em que o contexto da chamada está sendo feito. 3. A ID de instância da classe que receberá a requisição. 4. Um arranjo de vetores para os parâmetros e valores de retorno da chamada. 5. Acomodação para dados de comprimento variável.

[00043] Para invocar um método, o cliente envia uma mensagem para o servidor que inclui a ID de instância da classe e a ID de método a ser invocado. Quando o servidor recebe uma mensagem, ele usa o ID de tipo para realizar uma consulta do protótipo de método / função. Então, decodifica a mensagem entrando com base na informação encontrada na definição de protótipo de método / função. O servidor decodifica a ID de instância e a traduz em uma instância do objeto que possui o método sendo chamado. O servidor então extrai os dados a partir da mensagem e chama o método. Quando a mensagem retorna, os dados de retorno são acondicionados na mensagem de resposta e o servidor responde ao cliente.

[00044] A serialização de dados é a operação necessária para colocar os dados para transmissão. A serialização de dados é automática no TNS. Além de suportar tipos de dados básicos de tamanho fixo (caracteres, 16, 32, 64 e 128 inteiros de bits, variáveis de ponto flutuante, etc.), ele também suporta dados de tamanho de dados variáveis (strings de caractere e blobs de dados).

[00045] Durante o processo de coleta de metadados e de reflexão do compilador e a inicialização de partida, estruturas de dados de comprimento variável são detectadas. Elas vêm em dois tipos: strings terminadas em NULL e blobs de dados. Os blobs de dados têm que ser associados a um membro ou parâmetro que especificará o comprimento ou o comprimento máximo que poderá ser acomodado.

[00046] Os cordões não precisam de um membro ou parâmetro que especifique o comprimento, se for um parâmetro de entrada. Se uma string estiver indo ser um parâmetro de saída, um comprimento será necessário. O comprimento é especificado pela denominação do parâmetro de comprimento ou membro com o mesmo nome que o parâmetro ou símbolo da string ou do blob de dados com um sufixo ‘len’ adicionado ao nome de símbolo ou parâmetro.

[00047] Por exemplo, (em C++): class foo { char 'foo_name; int foo_namelen; }:

[00048] No exemplo acima, o TNS considerará foo_namelen como contendo o número máximo de caracteres que serão posicionados em foo_name. Int dosomething( char 'devicename, int param2, int param3, int devicenamelen);

[00049] No exemplo acima, o método dosomething () tem um parâmetro que conterá algum dado de comprimento variável (uma string ou um blob de dados). O último parâmetro será interpretado pelo TNS para especificar o comprimento máximo do nome de dispositivo.

[00050] Com referência à figura 10, o serializador de dados leva em conta o parâmetro de comprimento de dados ou o símbolo quando da disposição de dados, de modo que possa ser enviado em uma mensagem. Quando uma chamada é feita para o servidor, o cliente serializa os dados. Uma serialização envolve a localização das localizações de memória dos dados e o armazenamento daquelas localizações e comprimentos em um arranjo que então é usado para a escrita de dados no fluxo de mensagem saindo. Isto permite acesso genérico às localizações de dados sem ter que copiar uma memória.

[00051] A primeira etapa deste processo é capturar diretamente os parâmetros e os endereços destes parâmetros em um arranjo. Isto ordena os parâmetros e evita cópias de memória desnecessárias. Cada parâmetro é gravado neste arranjo (denominado um “vetor io”). Uma vez que isto tenha ocorrido, então, o sistema itera através e cada parâmetro, e aqueles que representam dados de comprimento variável então são processados, de modo que seu comprimento possa ser obtido e adicionado a este vetor io. Um vetor io para envio de dados e um vetor io para a recepção de dados de réplica ou de resposta então são ambos criados. Os dados de comprimento variável e os parâmetros que são ponteiros ou referências são armazenados neste vetor de io de resposta.

[00052] Após uma chamada ter sido feita (uma mensagem enviada para o servidor), os dados de resposta podem conter mudanças na referência e nos dados de comprimento variável. Contudo, os valores de ponteiro nos parâmetros serão inválidos, e terão que ser restaurados para as localizações de memória conforme conhecido pelo cliente. Esta restituição de ponteiros de dados corretos ocorre após a chamada.

[00053] O cliente e o servidor resolvem ponteiros de dados de comprimento variável de formas diferentes. O cliente tem que especificar um buffer com o comprimento correto dos dados a serem retornados antes da feitura da chamada remota. O servidor, por outro lado, sabe quantos dados são transferidos no momento de recepção da mensagem.

[00054] Se um cliente fizer uma chamada remota ou não prover espaço suficiente para a resposta, a chamada será feita no servidor, mas o servidor retornará um erro indicando que o buffer de resposta é insuficiente no comprimento para o armazenamento da resposta. Para dados de comprimento variável, o comprimento requerido é retornado no parâmetro de comprimento de dados correspondente. O cliente então ajustará o comprimento do buffer e fará a chamada de novo.

[00055] Quando dados são retornados, o cliente usa dicas retornadas pelo servidor para saber onde os dados de comprimento variável estão localizados no buffer de resposta. As dicas incluem dados de terminação nula e dados de tamanho fixo que indicam comprimentos de dados. Aquelas dicas são usadas para a atualização das referências ou dos ponteiros na lista de parâmetro. Uma vez que a atualização ocorra, os dados podem ser processados sem serem copiados a partir do buffer de resposta.

[00056] O servidor, por outro lado, não precisa pré-alocar um buffer para a leitura de dados de comprimento variável. Ele pode crescer seu buffer e ler os dados após a mensagem ser recebida. Ele opera de forma similar ao cliente pelo uso de dicas para entendimento de onde os dados de comprimento variável começam e terminam. As dicas usadas pelo servidor são as mesmas que para os clientes. Aquelas dicas são usadas para preenchimento de referências e ponteiros com valores que referenciam diretamente o buffer usado para o recebimento de dados. Comunicação de rede cruzada

[00057] Os clientes e servidores de TNS usam sem emendas o mecanismo de comunicação de rede provido pela plataforma de sistema operacional. Desta forma, clientes e servidores não têm que estar localizados no mesmo computador físico. O TNS não precisa de um protocolo de rede para lidar com a informação trocada entre eles se isto não for desejado. O TNS pode usar qualquer nível de comunicação, de um nível alto para transações ‘de transmissão’.

[00058] Quando um servidor começa e após ter sido inicializado, ele se torna disponível para clientes o encontrarem e se conectarem a ele. Isto pode ser feito de numerosas formas que são bem conhecidas nas técnicas. Quando o cliente começa, a ele pode ser dada uma divisória de compartimento de armazenamento quanto a como contatar o servidor ou pode ser designado para varrer o servidor. De novo, isto pode ser implementado de numerosas formas que são bem conhecidas na técnica e nenhuma implementação específica é requerida para TNS.

[00059] Os servidores baseados em TNS mantém um rastreamento dos clientes que se conectaram a ele. Isto permite que o implementador faça cumprir permissões de acesso e permitir que o servidor ignore requisições de clientes não autorizados. Adicionalmente, os esquemas de encriptação podem ser implementados para a implementação dos dados na chamada. Manter um rastreamento de clientes permite que o TNS opcionalmente associe instâncias de classes com clientes específicos. Isto evita que os clientes acessem e manipulem instâncias de dados possuídas pelos outros clientes. Quando um cliente se desconecta, o servidor de TNS pode opcionalmente limpar as instâncias que ele criou em nome do cliente.

[00060] Com referência, agora, à figura 11, um diagrama de blocos funcionais de uma estação de trabalho típica 500 para a tecnologia do presente pedido é provida. A estação de trabalho 500 pode ser qualquer um dos motores descritos acima, estações de trabalho, servidores ou similares. A estação de trabalho 500 é mostrada como uma unidade única, contida, tal como, por exemplo, um computador de mesa, um laptop, um tablet, um item portátil, um smartphone, um assistente digital pessoal ou um processador móvel, mas a estação de trabalho 500 pode compreender porções que são remotas e conectáveis através de uma conexão de rede, tal como através de uma LAN, uma WAN, uma WLAN, uma rede Wi-Fi, a Internet ou similar. Geralmente, a estação de trabalho 500 inclui um processador 502, uma memória de sistema 504 e um barramento de sistema 506. O barramento de sistema 506, o qual pode seguir qualquer protocolo convencional, tal como, por exemplo, PCI ou PCI-express, acopla os vários componentes de sistema e permite que dados e sinais de controle sejam trocados entre os componentes. A memória de sistema 504 geralmente compreende uma memória de acesso randômico (RAM) 508 e uma memória apenas de leitura (ROM) 510. A ROM 510 geralmente armazena um sistema de informação de operação básica, tal como um sistema de entrada / saída básico (BIOS) 512. A RAM 508 frequentemente contém o sistema operacional básico (OS) 514, o software aplicativo 516 e 518, e dados 520. A memória de sistema 504 contém o código para execução das funções e processamento dos dados, conforme descrito aqui, para permitir que a tecnologia presente do presente pedido funcione conforme descrito. A estação de trabalho 500 geralmente inclui um ou mais dentre uma unidade de disco rígido 522 (o que também inclui unidades flashes, unidades de estado sólido, etc., bem como outras configurações de memória volátil e não volátil), uma unidade de disco magnético 524, ou uma unidade de disco ótico 526. As unidades são conectadas ao barramento 506 através de uma interface de unidade de disco rígido 528, uma interface de unidade de disco magnético 530 e uma interface de unidade de disco ótico 532. Os módulos de aplicativo e de dados podem ser armazenados em um disco, tal como, por exemplo, um disco rígido instalado na unidade de disco rígido (não mostrada). A estação de trabalho 500 tem uma conexão de rede 534 para conexão a uma rede de área local (LAN), uma rede sem fio, uma Ethernet, a Internet, ou similar, bem como uma ou mais interfaces de porta serial 536 para conexão a periféricos, tal como um mouse, um teclado, um microfone, uma tela de toque, caneta de luz, modem ou impressora. A estação de trabalho 500 também pode ter portas USB ou componentes sem fio não mostrados. A estação de trabalho 500 tipicamente tem um visor ou monitor 538 conectado ao barramento 506 através de uma interface apropriada, tal como um adaptador de vídeo 540. O monitor 538 pode ser usado como um mecanismo de entrada usando uma tela de toque, uma caneta de luz ou similar. Na leitura desta exposição, aqueles de conhecimento na técnica reconhecerão que muitos dos componentes discutidos como unidades separadas podem ser combinados em uma unidade e uma unidade individual pode ser dividida em várias unidades diferentes. Ainda, as várias funções poderiam estar contidas em um computador pessoal ou espalhadas por vários computadores pessoais em rede. Os componentes identificados podem ser atualizados e substituídos conforme a tecnologia associada melhorar e avanços forem feitos na tecnologia de computação.

[00061] Aqueles versados ainda prefeririam que os vários blocos lógicos ilustrativos, os módulos, os circuitos e as etapas de algoritmo descritas em relação às modalidades expostas aqui podem ser implementados como um hardware eletrônico, um software de computador ou combinações dos mesmos. Para ilustrar claramente a intercambialidade de hardware e de software, vários componentes ilustrativos, blocos, módulos, circuitos, e etapas foram descritos acima geralmente em termos de sua funcionalidade. Se esta funcionalidade é implementada como um hardware ou um software depende da aplicação em particular e das restrições de projeto impostas ao sistema em geral. Técnicos versados podem implementar a funcionalidade descrita de formas variáveis para cada aplicação em particular, mas essas decisões de implementação não devem ser interpretadas como causando um desvio do escopo da presente invenção. Os componentes e módulos identificados acima podem ser suprimidos por novas tecnologias, conforme avanços na tecnologia de computador continuarem.

[00062] Os vários blocos lógicos ilustrativos, módulos e circuitos descritos em relação às modalidades expostas aqui podem ser implementados ou executados com um processador de finalidade geral, um processador de sinal digital (DSP), um circuito integrado específico de aplicação (ASIC), um arranjo de porta programável de campo (FPGA), ou outro dispositivo lógico programável, gate discreto ou qualquer combinação dos mesmos projetados para a realização das funções descritas aqui. Um processador de finalidade geral pode ser um microprocessador, mas, na alternativa, o processador pode ser qualquer processador convencional, controlador, microcontrolador ou máquina de estado. Um processador também pode ser implementado como uma combinação de dispositivos de computação, por exemplo, uma combinação de um DSP, um microprocessador, uma pluralidade de microprocessadores, um ou mais microprocessadores em conjunto com um núcleo de DSP, ou qualquer outra configuração como essa.

[00063] Assim sendo, o sistema de TNS foi descrito até algum grau de particularidade dirigido às modalidades de exemplo. Deve ser apreciado, contudo, que a presente invenção é definida pelas reivindicações a seguir construídas à luz da técnica anterior, de modo que modificações ou mudanças possam ser feitas nas modalidades de exemplo, sem que se desvie dos conceitos inventivos contidos aqui. APÊNDICE A

* Nome * TNS_REFLECT * Parâmetros T O nome do tipo * Descrição * Esta macro é usada para a descrição de um tipo de dados para o subsistema de reflexão de TNS. Normalmente é * usada para a descrição dos tipos que são escalares e que não têm membros (isto é, int, ou short, etc.). Os tipos de base em C/C++ * já são definidos. * Caveats * Esta macro não funcionará para todos os tipos que sejam sinônimos com um tipo de base. Por exemplo, time_t * resultará em um erro de compilador. Use TNS_REFLECT_VARIANT * para estes tipos.

* Nome TNS_REFLECT_VARIANT * Parâmetros T O nome do tipo * Descrição * Esta macro é usada para a descrição de um tipo de dados para o subsistema de reflexão de TNS. Normalmente é * usada para a descrição dos tipos que são sinônimos com tipos já definidos por TNS_REFLECT. Por exemplo, time_t na * maioria dos sistemas é unsigned int. A definição de time_t usando TNS_REFLECT resultará em um erro de compilador. Use TNS REFLECT VARIANT * para estes tipos.

* Nome * TNS_BEGIN_REFLECT_NESTED_STRUCT * Parâmetros * PARENT O nome da estrutura de origem * NESTED O nome da estrutura sendo definida * Descrição * Esta macro começa a descrição de reflexão de TNS de uma nested struct. Uma nested struct é uma * struct em uma struct. Esta macro é usada para delinear o começo de uma definição de estrutura aninhada. * Usar TNS_REFLECT_STRUCT_MEMBER para descrição de cada membro da struct. * Esta macro deve ser usada apenas com POD structs. O comportamento é indefinido se a struct não for um POD (dado antigo sem formatação) preexistente. * TODO: parece que UpdateName() está sendo chamada múltiplas vezes, por causa de TNSTypeDefHelper e do corpo deste construtor de structs. Veja se duplicatas podem ser eliminadas.

* Nome * TNS_BEGIN_REFLECT_STRUCT * Parâmetros * STRUCT O nome da estrutura sendo descrita. * Descrição * Isto começa uma definição membro a membro de uma struct.

Nome * TNS_BEGIN_REFLECT_STRUCT_DERIVED * Parâmetros * STRUCT O nome da estrutura sendo descrita. * DERIVED O nome da struct de base de STRUCT. * * Descrição * Isto começa uma definição membro a membro de uma struct. *

Nome TNS_BEGIN_REFLECT_CLASS tfdefine TNS_BEGIN_REFLECT_EXPORTED_CLASS( CLASS ) struct

*Nome TNS_REFLECT_STRUCT_MEMBER * Parâmetros * MBR O nome do membro (o nome da variável, sem a informação de tipo). * Descrição * Esta macro define um membro de uma struct. É usada para membros de dados apenas; ela não * pode ser usada em uma struct com funções de membro; ela é para structs de POD apenas.

Nome * TNS_REFLECT_STRUCT_MEMBER_PTR * Parâmetros MBR O nome do membro (o nome da variável, sem a informação de tipo). * LENMBR O nome do membro que contém o comprimento do MBR acima. * *Descrição * Esta macro define um membro de uma struct que é um ponteiro para dados para reflexão de TNS. Ela provê uma forma para * dizer à reflexão de TNS onde encontrar dados de comprimento. Se o ponteiro for terminado NULL, usar, ao invés disso, TNS REFLECT STRUCT MEMBER.

* Nome * TNS_REFLECT_CLASS_CONSTRUCTOR * * Parâmetros * CN Este é o nome da classe. * ID ID atribuída manualmente para o construtor (veja na Descrição porque isso é necessário). * CONST O protótipo completo do construtor (sem o qualificante de nome de classe). * * Esta macro define um construtor para uma classe para fins de reflexão de TNs. A razão * pela qual isto é separado de um método regular é que o endereço de um método é usado para a ID. Isto * assegura uma ID única e simplifica e acelera a execução da chamada real do método. * Os construtores tecnicamente não têm um endereço (embora na realidade o tenham). O compilador não * desistirá desta informação, então, temos que atribuir uma ID manual ao construtor. * Em segundo lugar, o operador typeof() precisa de uma sintaxe diferente quando lidando com tipos de construtores além de * métodos de classe. Como isto captura nomes de parâmetro? *

* Nome TNS_REFLECT_CLASS_METHOD * Parâmetros * CN Este é o nome da classe. * METHOD ID atribuída manualmente para o construtor (veja na Descrição porque isso é necessário). * METHODPRO O protótipo completo do construtor (sem o qualificante de nome de classe).

* Nome * TNS_END_REFLECT_NESTED_STRUCT * Parâmetros * PARENT O nome da estrutura de origem. * NESTED o nome da estrutura sendo definida. * * Descrição Esta macro é necessária para completar a definição de reflexão começada com TNS_BEGIN_REFLECT_NESTED_STRUCT.

Nome * TNS_END_REFLECT_STRUCT * * Parâmetros * STRUCT O nome da estrutura sendo definida. * * Descrição * Esta macro é necessária para completar a definição de reflexão começada com TNS_BEGIN_REFLECT_STRUCT.

Nome * TNS_END_REFLECT_CLASS * CN O nome da estrutura sendo definida. * Descrição * Esta macro é necessária para completar a definição de reflexão começada com TNS_BEGIN_REFLECT_CLASS

Nome * TNS_EXPORT_CLASS * Parâmetros CLASS_NAME O nome da classe que está sendo exportada. * Descrição * Esta macro cria uma instância TNSExportedClassStub< CLASS_NAME >, quando for requerido (TNS_REFLECT_INIT * é definida). Isto proporciona ao TNSServer um gancho a ser capaz de permitir que a classe faça qualquer configuração antes de o servidor começar, * prover um manipulador de mensagem para a classe específica, e permitir que a classe faça qualquer limpeza em uma parada.

Nome * TNS_EXPORT_CLASS_SIMPLE * Parâmetros * CLASS_NAME O nome da classe que está sendo exportada. * Descrição * Esta macro cria uma instância TNSExportedClassSimpleStub< CLASS_NAME >, quando for requerido (TNS_REFLECT_INIT * é definida). Isto proporciona ao TNSServer um manipulador de mensagem para * a classe específica. Nenhuma partida ou parada é chamada. Isto permite que uma classe C++ regular a ser exportada. Assume que a classe não terá necessidades de partida ou * parada.

* As macros a seguir são usadas para exportação de uma classe para uso por um cliente. * * As macros são para: * 1. A definição da Classe Exportada para uso pela implementação no servidor. * 2. A definição da Classe Exportada para uso pelo cliente. * 3. A colocação da classe no subsistema de reflexão de TNS para o cliente e o servidor. * 4. A criação de uma implementação da classe para o cliente (então, nenhuma codificação à mão tem que ser feita). * * A meta destas macros é a definição da Classe Exportada uma vez e ter todas as exigências acima * atendidas. * * Isto é feito ao se fazerem múltiplos passes deste arquivo TNSMacros.hpp em conjunto com a definição de classe: * O Passe 1 cria uma definição C++ da classe, isto é usado por ambos o servidor (stub) e cliente (proxy). * (Isto cuida das exigências 1 e 2 acima) * O Passe 2 cria as entradas de reflexão de TNS. * (Isto cuida da exigência 3 acima) * O Passe 3 é para clientes (proxies) apenas. Cria uma implementação dos métodos da classe, de modo que invoquem aquela funcionalidade no servidor. * * NOTA: estas macros não funcionarão corretamente se elas não forem usadas consecutivamente. Em outras palavras, todos os passes * têm que se completar para uma única classe, antes de se usá-lo para um outro. *

// imediatamente após TNS_EXPORT_PASS == 1 definido em TNSMacros.hpp blah

// imediatamente após TNS_EXPORT_PASS == 2 definido em TNSMacros.hpp «undef TNS. _EXPORT_PASS «undef TNS _BEGIN_CLASS «undef TNS" _BEGIN_CLASS_DERIVE «undef TNS -CONSTRUCTOR «undef TNS. -DESTRUCTOR «undef TNS -METHOD «undef TNS" _STATIC_METHOD «undef TNS" _VIRTUAL_METHOD «undef TNS_ STARTUPMETHOD «undef TNS ^SHUTDOWNMETHOD «undef TNS END CLASS «define TNSEXPORTPASS 3 «define TNS_BEGIN_CLASS( CLASS_NAME ) «define TNSBEGINCLASSDERIVE( CLASSNAME, DERIVED_NAME «define TNS_CONSTRUCTOR( CONPROTO ) «define TNS_DESTRUCTOR( DESCTPROTO ) «define TNSJ4ETHOD( METHOD, METHODPROTO ) «define TNS~STATIC_METHOD( METHOD, METHODPROTO ) «define TNS_VIRTUAL_METHOD( METHOD, METHODPROTO ) «define TNS_STARTUPMETHOD( ) «define TNS_SHUTDOWNMETHOD( ) «define TNS_END_CLASS( CLASS_NAME ) #elif (TNS_EXPORT_PASS - = 3) // imediatamente após TNS_EXPORT_PASS == 3 definido em TNSMacros.hpp «undef TNS_EXPORT_PASS «undef TNS_BEGIN_CLASS «undef TNS^BEGIN^CLASS-DERIVE «undef TNS_CONSTRUCTOR «undef TNS_DESTRUCTOR «undef TNS_METHOD «undef TNS_STATIC_METHOD «undef TNS_VIRTUAL_METHOD «undef TNS_STARTUPMETHOD «undef TNS_SHUTDOWNMETHOD «undef TNS2END_CLASS «define TNS_BEGIN_CLASS( CLASSNAME ) «define TNS_BEGIN_CLASS_DERIVE( CLASS_NAME, DERIVED_NAME ) ■■ - - «define TNS_CONSTRUCTOR( CONPROTO ) «define TNS~DESTRUCTOR( DESCTPROTO ) «define TNS_METHOD( METHOD, METHODPROTO ) «define TNSSTATICMETHOD( METHOD, METHODPROTO ) «define TNS_VIRTUAL_METHOD( METHOD, METHODPROTO ) «define TNS_STARTUPMETHOD( ) «define TNS_SHUTDOWNMETHOD( ) «define TNS_END_CLASS( CLASS_NAME ) «endif /* 'defined TNS_EXPORT_PASS*/ «elif defined (TNS_INCLUDE) «if (defined (TNS EXPORT PASS) // imediatamente após tns_included !defined TNS_EXPORT_PASS em TNSMacros.hpp ttundef TNS_:EXPORT_PASS ttundef TNS_BEGIN_CLASS ffundef TN$_BEGIN_CIIASS_DERIVE ifundef TNS_CONSTRUCTOR ff unde f TN5_DESTRUCT0R ttundef TNS^METHOD ttundef TNS_STATIC_METHOD ttundef TNS_VIRTUAL_WETHOD ttundef TNS_STARTUPMETHOD ttundef TNS_SHUTDOWNMETHOD ttundef TNS_END_CLASS ttdefine NONTNS ttdefine TNS_EXPORT_PASS 1 I ttdefine TNS_BEGIN_CLASS( CLASS_NAME ) class CLASS_NAME { ttdefine TNS_BEGIN_CLASS_DERIVE( CLASS_NAME, DERIVED_NAME ) class CLASS_NAME : public DERIVED_NAME { ttdefine TNS_CONSTRUCTOR( CONPROTO ) public: CONPROTO; ttdefine TNS_DESTRUCTOR( DESCTPROTO ) public: virtual DESCTPROTO; ttdefine TNS_METHOD( METHOD, METHODPROTO ) public: METHODPROTO; ttdefine TNS_STATIC_METHOD( METHOD, METHODPROTO ) public: Static METHODPROTO; ttdefine TNS_VIRTUAL_METHOD( METHOD, METHODPROTO ) public: virtual METHODPROTO; ttdefine TNS_STARTUPMETHOD( ) public: static void StartupHandler( ); ttdefine TNS_SHUTDOWNMETHOD( ) public: static void ShutdownHandler( ); ttdefine TNS_END_CLASS( CLASS_NAME ) ttelif (TNS_EXPORT_PASS ■■ 1) // imediatamente após tns_included TNS_EXPORT_PASS == 1 definido em TNSMacros.hpp «undef TNS_EXPORT_PASS «undef TNS_BEGIN_CLASS «undef TNS_BEGIN_CLASS_DERIVE «undef TNS_CONSTRUCTOR «undef TNS—DESTRUCTOR «undef TNS_METHOD «undef TNS_STATIC_METHOD «undef TNS_VIRTUAL_METHOD «undef TNS_STARTUPMETHOD «undef TNS_SHUTDOWNMETHOD «undef TNS_END_CLASS «undef NONTNS «define TNS_EXPORT_PASS 2 «define TNS_BEGIN_CLASS( CLASS_NAME ) «define TNS_BEGIN_CLASS_DERIVE( CLASS_NAME, DERIVED_NAME ) «define TNS_CONSTRUCTOR( CONPROTO ) «define TNS_DESTRUCTOR( DESCTPROTO ) «define TNS_METHOD( METHOD, METHODPROTO ) «define TNS_STATIC_METHOD( METHOD, METHODPROTO ) «define TNS_VIRTUAL_METHOD( METHOD, METHODPROTO ) «define TNS_STARTUPMETHOD( ) «define TNS_SHUTDOWNMETHOD( ) «define TNS_END_CLASS( CLASS_NAME ) #elif (TNS_EXPOR*r_PASS -w 2) // imediatamente após tns_included TNS_EXPORT_PASS == 2 definido em TNSMacros.hpp tfundef TNS_EXPORT_PASS ffdefine TNS_EXPORT_PASS 3 tfelif (TNS_EXPORT_PASS 3) // imediatamente após tns_included TNS_EXPORT_PASS == 3 definido em TNSMacros.hpp «undef TNS_EXPORT_PASS «endif «else /‘none of the above (not defined TNS_EXPORT nor defined TNS_INCLUDE)*/ «if (defined (TNS_IMPORT_PASS) «undef TNS_BEGIN_CLASS «undef TNS_BEGIN_CLASS_DERIVE «undef TNS^CONSTRUCTOR «undef TNS_DESTRUCTOR «undef TNS_METHOD «undef TNS_STATIC_METHOD «undef TNS_VIRTUAL_METHOD «undef TNS_END_CLASS «undef TNS_IMPORT_PASS «undef TNS_STARTUPMETHOD «undef TNS_SHUTDOWNMETHOD «define NON_TNS «define TNS_BEGIN_CLASS( CLASS_NAME ) class CLASS_NAME { «define TNS_BEGIN_CLASS_DERIVE( CLASS_NAME, DERIVED_NAME ) Class CLASS_NAME ( «define TNS_CONSTRUCTOR( CONPROTO ) public: CONPROTO ~( } ; «define TNS_DESTRUCTOR( DESCTPROTO ) public: virtual DESCTPROTθ{}; «define TNS_METHOD( METHOD, METHODPROTO ) public: METHODPROTO; «define TNS_STATIC_METHOD( METHOD, METHODPROTO ) public: Static METHODPROTO; «define TNS_VIRTUAL_METHOD( METHOD, METHODPROTO ) public: virtual METHODPROTO; «def ine TNS_STARTUPMETHOD() «define TNS_SHUTDOWNMETHOD() «define TNS_END_CLASS( CLASS_NAME ) } «define TNS_IMPORT_PASS 1 «elif (TNS_IMPORT_PASS == 1) «undef TNS. _BEGIN_CLASS «undef TNS _BEGIN_CLASS_DERIVE «undef TNS CONSTRUCTOR «undef TNS" -DESTRUCTOR «undef TNS- 'METHOD «undef TNS STATIC METHOD #undef TNS_VIRTUAL_METHOD ttundef TNS_END_CLASS ttundef TNS_IMPORT_PASS ttundef TNS_STARTUPMETHOD ttundef TNS_SHUTDOWNMETHOD ttundef NON_TNS ttdefine TNS_BEGIN_CLASS( CLASS_NAME ) TNS_BEGIN_REFLECT_STRUCT( CLASS_NAME ) ttdefine TNS_BEGIN_CLASS_DERIVE( CLASS_NAME, DERIVED^NAME ) TNS_BEGIN_REFLECT_STRUCT_DERIVED( CLASS_NAME, DERIVED_NAME ) ~ ttdefine TNS_CONSTRUCTOR( CONPROTO ) TNS_REFLECT_CLASS_CONSTRUCTOR( CONPROTO ) ttdefine TNS_DESTRUCTOR( DESCTPROTO ) ttdefine TNS_METHOD( METHOD, METHODPROTO ) TNS_REFLECT_CLASS_METHOD( METHOD, METHODPROTO ) ttdefine TNS_STATIC_METHOD( METHOD, METHODPROTO ) ttdefine TNS_VIRTUAL_METHOD( METHOD, METHODPROTO ) ttdefine TNS_STARTUPMETHOD() ttdefine TNS_SHUTDOWNMETHOD() ttdefine TNS_END_CLASS( CLASS_NAME ) TNS_END_REFLECT_STRUCT( CLASS_NAME ) ttdefine TNS_IMPORT_PASS 2 ttelif (TNS_IMPORT_PASS == 2) ttundef TNS_BEGIN_CLASS ttundef TNS_BEGIN_CLASS_DERIVE ttundef TNS_CONSTRUCTOR” ttundef TNS_DESTRUCTOR ttundef TNS_METHOD ttundef TNS_STATIC_METHOD ttundef TNS_VIRTUAL_METHOD ttundef TNS_END_CLASS ttundef TNS_IMPORT_PASS ttundef TNS_STARTUPMETHOD ttundef TNS_SHUTDOWNMETHOD . ttdefine TNS_BEGIN_CLASS( CLASSNAME ) ttdefine TNS_BEGIN_CLASS_DERIVE( CLASS_NAME, DERIVED_NAME ) -■ ' - ttdefine TNS_CONSTRUCTOR( CONPROTO ) ttdefine TNS_DESTRUCTOR( DESCTPROTO ) ttdefine TNS_METHOD( METHOD, METHODPROTO ) ttdefine TNSSTATICMETHOD( METHOD, METHODPROTO ) ttdefine TNS_VIRTUAL_METHOD( METHOD, METHODPROTO ) ttdef ine TNS_STARTUPMETHOD() #def ine TNS_SHUTDOWNMETHOD() ttdefine TNSENDCLASS( CLASSNAME ) ttdefine TNS_IMPORT_PASS 3 ttelif (TNS_IMPORT_PASS == 3) ttundef TNS_BEGIN_CLASS ttundef TNS_BEGIN_CLASS_DERIVE ttundef TNS CONSTRUCTOR «undef TNS_DESTRUCTOR #undef TNS_METHOD «undef TNS_STATIC_METHOD «undef TNS_VIRTUAL_METHOD «undef TNS_END_CLASS «undef TNS_IMPORT_PASS «undef TNS_STARTUPMETHOD «undef TNS_SHUTDOWNMETHOD «define TNS_BEGIN_CLASS( CLASSNAME ) «define TNS_BEGIN_CLASS_DERIVE( CLASS_NAME, DERIVED_NAME «define TNS_CONSTRUCTOR( CONPROTO ) «define TNSDESTRUCTOR( DESCTPROTO ) «define TNS_METHOD( METHOD, METHODPROTO ) «define TNS_STATIC_METHOD( METHOD, METHODPROTO ) «define TNS_VIRTUAL_METHOD( METHOD, METHODPROTO ) «define TNS_STARTUPMETHOD() «define TNS_SHUTDOWNMETHOD() «define TNS_END_CLASS( CLASS_NAME ) «endif «endif /«defined TNS_EXPORT*/

Claims

1. Sistema de rede compreendendo: um computador de servidor de rede compreendendo: um microprocessador de rede; um dispositivo de memória (5); e um meio de armazenamento que pode ser lido em máquina não transitório compreendendo: i. pelo menos um módulo de servidor (10) incluindo meios de servidor para instruir o microprocessador de servidor para: i. prover uma funcionalidade selecionada; e ii. escrever (21) uma informação necessária para a descrição da referida funcionalidade selecionada no dispositivo de memória (5); iii. usar a referida informação para a criação de chamadas de função dinâmicas; e um computador de cliente de rede compreendendo: um microprocessador de cliente; ii. pelo menos um módulo de cliente (50) incluindo meios de cliente para instruir o microprocessador de cliente para: iii. buscar no referido dispositivo de memória (5) a referida funcionalidade selecionada; iv. requisitar pelo menos uma porção da referida informação; e v. i. invocar a referida funcionalidade selecionada do referido módulo de servidor (10); caracterizado pelo fato de que os meios de servidor são gerados por um compilador rodando em um microprocessador de servidor a partir de meios de fonte de servidor, os referidos meios de fonte de servidor incluindo: meios de fonte para a geração dos referidos meios de servidor para prover a referida funcionalidade selecionada; meios de fonte para a geração de meios de servidor representativos da referida informação; e meios de fonte para a geração de meios de servidor para escrever (21) a referida informação no referido dispositivo de memória (5).

2. Sistema de rede, de acordo com a reivindicação 1, caracterizado pelo fato de que o referido compilador inclui um pré-processador e pelo menos uma porção dos referidos meios de fonte de servidor é criada pelo referido pré- processador.

3. Sistema de rede, de acordo com a reivindicação 2, caracterizado pelo fato de que o referido pré-processador usa meios de fonte na forma de uma macro para criar pelo menos uma referida porção dos referidos meios de servidor.

4. Sistema de rede, de acordo com a reivindicação 3, caracterizado pelo fato de que pelo menos uma porção dos referidos meios de fonte de servidor é criada pelo referido compilador.

5. Sistema de rede, de acordo com a reivindicação 1, caracterizado pelo fato de que pelo menos uma porção dos referidos meios de fonte de servidor é criada pelo referido compilador.

6. Sistema de rede, de acordo com a reivindicação 1, caracterizado pelo fato de que a referida funcionalidade é selecionada a partir do grupo que consiste em mover um atuador, realizar uma operação matemática, receber dados a partir de um sensor, e combinações dos mesmos.

7. Sistema de rede, de acordo com a reivindicação 1, caracterizado pelo fato de que o referido módulo de servidor (10) escreve (21) a referida informação necessária para descrição da referida funcionalidade selecionada para o referido dispositivo de memória (5) mediante uma execução.

8. Sistema de rede, de acordo com a reivindicação 1, caracterizado pelo fato de que a referida informação inclui uma informação necessária para invocar a referida funcionalidade selecionada.

9. Sistema de rede, de acordo com a reivindicação 8, caracterizado pelo fato de que a referida informação necessária para invocar a referida funcionalidade selecionada inclui tipos, membros e parâmetros.

10. Sistema de rede, de acordo com a reivindicação 9, caracterizado pelo fato de que o referido módulo de cliente (50) inclui uma funcionalidade de questão de interface incluindo meios de cliente para instruir o referido microprocessador de cliente para: recuperar os referidos tipos; recuperar todos os referidos membros para cada referido tipo; e recuperar todos os referidos parâmetros para cada referido membro.

11. Sistema de rede, de acordo com a reivindicação 10, caracterizado pelo fato de que o referido módulo de cliente (50) inclui uma funcionalidade de serialização de dados incluindo meios de cliente para instruir o referido microprocessador de cliente para: determinar se os referidos parâmetros são de comprimento variável; e capturar o comprimento de parâmetros que são determinados como sendo de comprimento variável.

12. Sistema de rede, de acordo com a reivindicação 11, caracterizado pelo fato de que o referido parâmetro é acompanhado por um parâmetro de comprimento de dados e o referido módulo de cliente (50) inclui meios de cliente para instruir o referido microprocessador de cliente para armazenar um endereço do referido parâmetro e o referido parâmetro de comprimento de dados em um vetor de entrada e saída.