Manual do OPENBUS 2.0.0

Tecgraf

24. Janeiro 2017


Sumário

1 Introdução

O OPENBUS [8] é um projeto de um middleware para integração de sistemas computacionais heterogêneos, ou seja, desenvolvidos em diferentes linguagens de programação e plataformas computacionais. O OPENBUS se baseia em duas tecnologias complementares para constituir uma infraestrutura básica de integração de sistemas. São elas:

CORBA
Common Object Requester Broker Architecture [7] é um padrão da indústria que especifica um middleware para sistemas distribuídos heterogêneos orientados a objetos. CORBA define o modelo básico de comunicação usado nas integrações de sistemas feitas com o OPENBUS. CORBA tem suporte para inúmeras linguagens de programação e plataformas computacionais, que nos permite integrar com o OPENBUS uma grande variedade de sistemas.
SCS
Software Component System [1] é um modelo simples e flexível de componentes de software baseado em CORBA que permite estruturar sistemas usando uma arquitetura baseada em componentes. O SCS é usado no OPENBUS tanto como um modelo arquitetural básico para a infraestrutura básica oferecida como também para estruturar a forma como as integrações são feitas.

Em cima dessas duas tecnologias o OPENBUS introduz duas novas extensões, que basicamente definem a infraestrutura especializada para integração de sistemas computacionais:

Barramento de Integração
É o conceito central do OPENBUS. O barramento é o meio através do qual toda interação e comunicação entre os sistemas integrados é feita. O barramento é uma extensão de CORBA com suporte a controle de acesso, que basicamente consiste na autenticação de todo acesso a sistemas através do barramento, permitindo assim identificar de forma segura da origem de toda comunicação (chamadas CORBA) feita através do barramento.
Serviços de Apoio à Integração
Juntamente ao barramento, o OPENBUS também provê suporte para registro e descoberta de serviços ofertados pelos sistemas integrados, comunicação baseada em eventos, entre outras funcionalidades através de uma arquitetura orientada a serviços (Service-Oriented Architecture, ou SOA [2]). O objetivo desses serviços é oferecer funcionalidades básicas e essenciais que visem facilitar e agilizar o desenvolvimento da integração dos diferentes sistemas.

Este documento tem como objetivo apresentar o OPENBUS 2.0.0 e seus conceitos principais. Nesta seção introdutória apresentaremos uma definição do projeto e os motivadores para o seu uso. Na seção 2 apresentamos a arquitetura do sistema, e entramos um pouco mais em detalhes de como ocorre a comunicação dentro do barramento na seção 2.4.1. Em seguida, na seção 3 falamos um pouco mais sobre o projeto de acordo com a visão de cada tipo de usuário, e, por fim, na seção 4 apresentamos um glossário com os conceitos principais do projeto.

1.1 Quando Utilizar o OPENBUS

O OPENBUS é um middleware para integração de sistemas heterogêneos. Contudo, a integração de sistemas pode se dar de diversas formas diferentes e envolver requisitos diversos. Por exemplo, uma forma de integração extremamente simples entre dois sistemas que apenas precisam trocar dados é por meio da troca de arquivos num formato adotado por ambos sistemas. Inclusive esses arquivos podem ser transmitidos pela rede manualmente ou automaticamente.

Em outros cenários, a integração pode também exigir alguma colaboração entre os sistemas, através da execução comandos, por exemplo. Nesse caso, é necessário que os sistemas forneçam alguma forma para receber comandos, que pode ser através de mensagens enviadas por um socket, comandos de um WebService, chamadas a um objeto remoto, etc. Fazer um sistema implementar inúmeras interfaces de acesso para integração com diferentes sistemas é uma solução pouco razoável num cenário em que devam existir vários sistemas a serem integrados. Idealmente, deve-se adotar uma tecnologia de comunicação genérica e eficiente o suficiente para ser adequada ao uso com sistemas com diferentes requisitos.

Outra necessidade comum na integração de sistemas cooperativos é o controle de acesso e a governança das integrações. Ou seja, quando os sistemas integrados não são abertos ao acesso público e irrestrito, é necessário que a infraestrutura forneça mecanismos que permitam restringir quais serviços podem ser integrados e como essas integrações podem ser feitas.

O OPENBUS oferece uma infraestrutura adequada para implementar integrações entre sistemas tendo essas questões e necessidades em mente. Em particular, o OPENBUS se baseia na tecnologia CORBA para definir uma tecnologia de comunicação genérica e eficiente para integração de sistemas escritos em diferentes linguagens de programação e plataformas computacionais. Além disso, o OPENBUS estende a tecnologia CORBA com suporte a um rigoroso controle de acesso que permite a inspeção e controle das integrações através de um modelo de governança, onde um gerente do barramento pode controlar quais sistemas acessam o barramento e se integram a outros sistemas.


2 Arquitetura

A infraestrutura mínima do OPENBUS é representada pelo seu núcleo principal, que é composto por um barramento de comunicação e serviços essenciais, denominados serviços núcleo. Além do núcleo do barramento, a arquitetura OPENBUS também define um conjunto de elementos adicionais que fornecem outras facilidades importantes, tais como bibliotecas e serviços extras.

A figura 1, apresenta a arquitetura do OPENBUS e suas partes principais. Entraremos em detalhes sobre as partes principais do OPENBUS nas subseções a seguir.

Figura 1: Arquitetura do OPENBUS
Image architecture


2.1 Barramento

O barramento é o meio de comunicação entre os sistemas integrados. Toda comunicação feita pelos sistemas integrados através do barramento consiste de chamadas de objetos distribuídos usando o padrão CORBA. Contudo, ao contrário das chamadas de CORBA comuns, nas chamadas feitas através do barramento, é imposto um rigoroso controle de acesso que só permite chamadas autenticadas por entidades previamente autorizadas a acessar o barramento.

Essas entidades são tipicamente sistemas computacionais e usuários desses sistemas. Cada entidade é identificada por um nome único no barramento a ser definido pelo gerente barramento. Tipicamente, os nomes de entidade são nomes de sistemas computacionais que oferecem serviços no barramento e nomes de contas de usuários numa base de diretórios como o LDAP.

Todo acesso ao barramento é autenticado através de credenciais ocultas nas chamadas de objetos CORBA. Essas credenciais de acesso especificam um login no barramento. Todo login é sempre autenticado em nome de uma entidade, que é responsável por todos os acessos feitos através daquele login. Cada login possui um identificador único que é utilizado para identificar acessos ao barramento feitos através daquele login. Uma mesma entidade pode ter mais de um login para acesso ao barramento simultaneamente. Por exemplo, no caso de um serviço implementado como um sistema distribuído composto por mais de um processo que acessa o barramento simultaneamente, é interessante que cada processo possa utilizar um login próprio para acesso ao barramento.

O OPENBUS define três formas para autenticação de uma entidade no processo de criação de logins de acesso. Essas três formas de autenticação são:

Autenticação por Senha
Neste caso, a autenticação é feita através de uma senha fornecida juntamente com o nome da entidade. A senha é validada por um módulo de validação de senhas especificado pelo gerente do barramento. Tipicamente esse módulo de validação é integrado a alguma base de dados de usuário que fornece informações para validação das senhas. Essa forma de autenticação é geralmente utilizada para incorporar ao barramento um grande número de usuários mantidos num sistema separado. Um exemplo dessa integração é o validador de senhas LDAP fornecido pelo OPENBUS, que permite autenticar nomes de usuários num serviço de diretórios LDAP como entidades para acesso ao barramento. Neste caso, todos os nomes de usuários na base LDAP são automaticamente entidades autorizadas a acessar o barramento.

Autenticação por Certificado
Neste caso, a autenticação é feita através de um certificado previamente cadastrado pelo gerente do barramento em nome de uma entidade particular. Para que a autenticação ocorra, é preciso decodificar um desafio encriptado com a chave pública contida no certificado cadastrado. Para tanto, é necessário ter a chave privada correspondente ao certificado cadastrado. Essa forma de autenticação é geralmente utilizada para autorizar o acesso de sistemas computacionais específicos que fornecem serviços através do barramento. Toda gerência dos certificados de acesso cadastrados no barramento é de responsabilidade do gerente do barramento, que utiliza ferramentas fornecidas pelo OPENBUS para adicionar, remover e consultar os certificados cadastrados.

Autenticação Compartilhada
Neste caso, a autenticação é feita em colaboração com outro sistema que já possua um login no barramento, ou seja, já está autenticado em nome de uma entidade para acessar o barramento. Neste caso, o sistema já autenticado produz um segredo a ser compartilhado com o outro sistema que é utilizado na autenticação desse novo sistema em nome da entidade autenticadora do sistema original. Essa forma de autenticação é geralmente utilizada quando um sistema deseja compartilhar sua forma de autenticação com outro sistema sem fornecer informações privilegiadas como senhas ou chaves privadas.

Tipicamente os logins de acesso ao barramento ficam válidos por um período denominado lease. Após o período de lease, o login deve ser renovado para que possa continuar válido1. Independentemente disso, todo login pode se tornar inválido a revelia da aplicação. Neste caso, uma nova autenticação deve ser realizada para obtenção de um novo login para continuar acessando o barramento2. Uma vez inválido, um login nunca volta a ser válido novamente.

O barramento possui algumas características importantes que devem ser mencionadas. Uma delas, é que o barramento persiste todo o seu estado no diretório de dados. Dessa forma, sempre que ele é iniciado, e o mesmo já possui uma base de dados populada, esses dados serão recarregados e farão parte do estado inicial do barramento.

Outra característica importante é que o barramento mantém compatibilidade com a a versão imediatamente anterior do barramento. Ou seja, mesmo que a versão do barramento evolua, as entidades ainda conseguem acessar o barramento utilizando bibliotecas de acesso de uma versão anterior. O OPENBUS utiliza um esquema de versionamento com quatro números, no formato A.B.C.D, onde:

Sendo assim, o barramento 2.0 permite a realização de acesso utilizando as bibliotecas de acesso de versão 1.5.x, onde x pode assumir qualquer valor de C.D. Porém, é importante deixar claro que a versão 2.0 traz muitas melhorias no quesito de segurança, e essas melhorias não serão usufruídas por clientes que acessam o barramento com versões antigas das bibliotecas de acesso. O barramento permite que clientes 1.5 se comuniquem com clientes 2.0, e vice-e-versa, porém essas comunicações se realizam com o mesmo nível de segurança que existia na versão 1.5 do barramento.

2.2 Serviços Núcleo

O barramento oferece em seu núcleo um serviço essencial denominado Registro de Ofertas. Através dele é possível publicar, buscar e monitorar os demais serviços disponíveis através do barramento.

Todo serviço a ser ofertado através do Registro de Ofertas deve ser implementado como um componente SCS [1] que oferece diferentes facetas através das quais o serviço é acessado. No momento do registro de uma oferta de serviço, deve ser fornecido um conjunto pares nome e valor que devem descrever propriedades particulares do serviço sendo ofertado. Essas propriedades poderão ser utilizadas como critério de filtro no momento de buscar por ofertas de serviço no Registro de Ofertas.

Além das propriedades fornecidas no registro da oferta, o próprio serviço de Registro de Oferta também gera um conjunto de propriedades automáticas que descrevem:

O Registro de Ofertas também disponibiliza um mecanismo de observação de publicação, atualização e remoção de ofertas. Maiores detalhes sobre a especificação e o uso do serviço de Registro de Ofertas podem ser encontrados nos manuais de uso das bibliotecas de acesso (seção 2.4)

2.3 Serviços Extras

A versão atual do OPENBUS oferece um serviço extra denominado Serviço de Colaboração. Esse serviço tem como principais funcionalidades:

Não entraremos em maiores detalhes sobre as funcionalidades e o uso do Serviço de Colaboração neste documento. Para mais informações, consulte a documentação do próprio serviço [14].


2.4 Biblioteca de Acesso

O OPENBUS também disponibiliza uma biblioteca de acesso ao barramento a ser utilizada na implementação da integração de sistemas ao barramento. Essa biblioteca basicamente implementa uma API simplificada para acesso ao barramento, ocultando detalhes do protocolo de comunicação do OPENBUS. Através dessa biblioteca é possível realizar as seguintes operações, dentre outras:

A biblioteca de acesso do OPENBUS tem implementações nas quatro diferentes linguagens de programação suportadas oficialmente pelo OPENBUS, em particular, Java [12], C# [10], C++ [11] e Lua [13].


2.4.1 Comunicação Através do Barramento

O barramento é internamente implementado como uma arquitetura orientada a serviços (SOA). Em princípio, todas as chamadas feitas através do barramento envolvem chamadas a esses serviços internos, em particular, o serviço de Controle de Acesso.

Para evitar a sobrecarga dessas chamadas adicionais a serviços internos do barramento, a biblioteca de acesso implementa otimizações eficientes que permitem reduzir drasticamente essa sobrecarga nos cenários de uso mais comuns. Em particular, a biblioteca de acesso faz uso de vários caches internos para minimizar a necessidade de chamadas adicionais a serviços internos da implementação do barramento.

Em cenários de integração típicos, a maior parte da comunicação através do barramento é feita diretamente entre os sistemas integrados, sem necessidade de acesso à infraestrutura interna do barramento. Essa característica da biblioteca de acesso traz duas vantagens importantes:


3 Perspectivas

Agora que já apresentamos a arquitetura e os conceitos gerais do OPENBUS, iremos falar um pouco sobre algumas características específicas do OPENBUS, que dependem do papel que o usuário tem no barramento. Os papéis abordados são:

Administrador de Sistema
As pessoas que possuem acesso à máquina onde o barramento será executado e são os responsáveis por levantar e parar o barramento.
Gerente do Barramento
Aqueles que irão desempenhar o papel de organizar e acompanhar o que é publicado no barramento.
Desenvolvedor de Sistemas Integrados
Responsáveis por implementar a integração de seus respectivos serviços e aplicações ao barramento.

3.1 Administradores de Sistema

O barramento e os serviços núcleo são distribuídos em um mesmo programa, o busservices. Logo, para disparar o barramento, basta executar o programa passando as suas configurações por linha de comando ou por arquivo de configuração. Se uma configuração não for explicitada, será utilizado o seu valor padrão.

As opções de configuração são:

-host
Endereço de rede usado pelo barramento.
Valor padrão é *, que significa que vai ouvir em todos os IPs da máquina.
-port
Número da porta usada pelo barramento.
Valor padrão é 2089.

-database
Arquivo de dados do barramento.
Valor padrão é openbus.db.
-privatekey
Arquivo com chave privada do barramento.
Valor padrão é openbus.key.

-timeout
Tempo em segundos de espera por respostas nas chamadas realizadas pelo barramento.
Valor padrão é 0 segundos, o que significa que deve esperar indefinidamente.
-leasetime
Tempo em segundos de lease dos logins de acesso.
Valor padrão é 1800 segundos.
-expirationgap
Tempo em segundos que os logins ficam válidos após o lease.
Valor padrão é 10 segundos.
-challengetime
Tempo em segundos de duração do desafio de autenticação por certificado.
Valor padrão é o valor do parâmetro expirationgap.
-sharedauthtime
Tempo em segundos de validade dos segredos de autenticação compartilhada.
Valor padrão é o valor do parâmetro leasetime

-badpasswordpenalty
Tempo em segundos com tentativas de login limitadas após falha de senha.
Após uma falha de autenticação, este é o período em que o número de falhas de autenticação por senha (ver badpasswordtries) provenientes de um mesmo IP ou entidade será limitado.
O valor padrão é 180 segundos.

-badpasswordtries
Número máximo de tentativas durante o período de badpasswordpenalty.
Número máximo de falhas de autenticação por senha de um IP ou entidade.
O valor padrão é 3 tentativas.

-badpasswordlimit
Número máximo de autenticações simultâneas com senha incorreta repassadas para os validadores de senha, ou seja, que ocorram dentro de um tempo curto (menor que 1/badpasswordrate segundos).
Por padrão, o controle de fluxo está desativado.

-badpasswordrate
Frequência máxima de autenticações com senha incorreta repassadas para os validadores de senha em períodos longos (maiores que 2*badpasswordlimit/badpasswordrate segundos).
Por padrão, o controle de fluxo está desativado.

-maxchannels
Número máximo de canais de comunicação com os sistemas.
O valor padrão é 1000, verifique a quantidade máxima de sockets abertos suportada pelo sistema operacional antes de alterar essa configuração.
-maxcachesize
Tamanho máximo das caches LRU de profiles IOR, sessões de entrada e de saída.
O valor padrão é 128 (mesmo valor do campo maxsize da classe loop.collection.LRUCache).

-admin
Usuário com privilégio de administração.
Não é definido um valor padrão.
-validator
Nome de pacote de validação de login.
Não é definido um valor padrão.

-loglevel
Nível de log gerado pelo barramento.
O valor padrão é 3. Os níveis vão de 0 a 5, onde 5 é o nível com mais detalhes, e o 0 desativa o log.
-logfile
Arquivo de log gerado pelo barramento.
Por padrão o log é direcionado para a saída padrão (standard output).
-oilloglevel
Nível de log gerado pelo OIL [6,5] (debug).
O valor padrão é 0. Os níveis vão de 0 a 5, onde 5 é o nível com mais detalhes, e o 0 desativa o log.
-oillogfile
Arquivo de log gerado pelo OIL (debug).
Por padrão o log é direcionado para a saída padrão (standard output).

-noauthorizations
Desativa o suporte à autorizações de oferta.
-nolegacy
Desativa o suporte à versão antiga do barramento.
-logaddress
Exibe o endereço IP do requisitante no log do barramento.

-nodnslookup
Desativa a busca no DNS por apelidos da máquina para compor os endereços de rede contidos nas referências IOR.
Por padrão, todos os apelidos de DNS são adicionados.
-noipaddress
Desativa o uso de endereços IP para compor os endereços de rede contidos nas referências IOR.
Por padrão, os endereços IP são adicionados.
-alternateaddr
Endereço e porta alternativos que devem compor os endereços de rede contidos nas referências IOR.
Essa configuração é útil para a travessia de NAT e firewalls.
Não é definido um valor padrão. O valor deve ser um nome e porta separados pelo caractere : (dois pontos).

-configs
Arquivo de configurações adicionais do barramento.
O valor padrão é openbus.cfg.

As opções admin, validator e alternateaddr podem receber mais de um valor. Quando essas opções são configuradas por linha de comando, basta repetir a opção o número de vezes desejadas. Quando são configuradas através do arquivo de configuração, é necessário informar a lista de valores desejados, no formato de uma tabela LUA [4]. O código 1 apresenta um exemplo de arquivo do configuração.

Exemplo de arquivo de configuração:

validator = {"openbus.test.core.services.TesterUserValidator"}
loglevel = 5 
admin = {"admin1", "admin2"}
leasetime = 30
alternateaddr = {"myserver.mydomain.com:2089", "192.168.0.1:4321"}
Existem duas formas de se definir o arquivo de configuração que o programa irá utilizar: utilizando a opção config por linha de comando, ou definindo um valor para a variável de ambiente OPENBUS_CONFIG. Porém, as opções passadas por linha de comando têm prioridade sobre as opções definidas no arquivo de configuração.

Através da opção validator informa-se o módulo do validador de senhas que será utilizado pelo barramento. Disponibilizamos em openbus.core.services.passwordvalidator.LDAP um validador LDAP, que precisa ser configurado com a lista de servidores utilizados na autenticação. Para maiores informações sobre como configurar o validador LDAP, consulte [9].

Também é possível desabilitar o suporte de compatibilidade com a versão anterior através da opção nolegacy. Ao ativar essa opção, o barramento deixa de permitir que entidades se autentiquem no barramento utilizando as bibliotecas de acesso de versão 1.5.x.

3.2 Gerentes do Barramento

Para desempenhar o papel de gerente do barramento, disponibilizamos a ferramenta busadmin, que permite que se realize atividades de governança (administração) sobre o barramento.

Antes de entrar em detalhes sobre o uso e as funcionalidades do busadmin, vamos agora apresentar alguns conceitos importantes de governança dentro do OPENBUS. Existem os conceitos de:

Categoria
Representa uma categoria de entidades no barramento. Categorias de entidade são agrupamentos usados exclusivamente para facilitar a gerência das diversas entidades cadastradas no barramento pelo administrador.

Entidade
Representa uma entidade do barramento registrada. Entidade é tudo aquilo que pode fazer login no barramento e usufruir dos seus recursos. Em particular, tanto usuários como implantações de sistema são considerados entidades. Entidades podem ou não ser cadastradas no barramento, mas apenas entidades cadastradas podem ser autorizadas a ofertar serviços.

Certificado
Chave pública que pode ser usada para autenticar uma dada entidade no barramento. Ver seção sobre geração de chaves para informações sobre como gerar as chaves pública e privada. É possível adicionar certificados para entidades não cadastradas no barramento.

Interface
Definição de uma interface IDL de um serviço que pode ser ofertado no barramento.

Autorização
Associação de uma interface IDL a uma entidade, indicando que processos conectados como essa entidade podem oferecer serviços que implementem essa interface no Registro de Ofertas do barramento.

Para utilizar a ferramenta, deve-se executar: 

busadmin [opções] --login=<usuário> <comando>

Para adicionar e remover categorias, entidades, certificados, interfaces e autorizações, aconselhamos que se defina um arquivo de script LUA com o formato especificado no código 2. Ele serve de entrada para os comandos script e undo-script da ferramenta busadmin, que, respectivamente, executa e desfaz a execução do lote de comandos especificados pelo arquivo de script.

Exemplo de script para a ferramenta busadmin:

-- Definição de uma categoria
-- * comando: Category
-- * parâmetros:
--   * id = identificador da categoria
--   * name = descrição da categoria
Category {
  id = "TEST_Category",
  name = "Descrição da categoria",
}
-- Definição de uma entidade
-- * comando: Entity
-- * parâmetros:
--   * id = identificador da entidade
--   * category = identificador da categoria que a entidade pertence
--   * name = descrição da entidade
Entity {
  id = "TEST_Entity",
  category = "TEST_Category",
  name = "Descrição da entidade",
}
-- Definição de um certificado
-- * comando: Certificate
-- * parâmetros:
--   * id = identificador da entidade
--   * certificate = caminho para arquivo de certificado associado a entidade
Certificate {
  id = "TEST_Entity",
  certificate = "teste.crt",
}
-- Definição de uma interface
-- * comando: Interface
-- * parâmetros:
--   * id = repID da interface
Interface {
  id = "IDL:script/Test:1.0"
}
-- Conceder autorização
-- * comando: Grant
-- * parâmetros:
--   * id = identificador da entidade a ser autorizada
--   * interfaces = lista de interfaces a serem autorizadas.
Grant {
  id = "TEST_Entity",
  interfaces = {
    "IDL:script/Test:1.0",
  }
}
-- Remover autorização
-- * comando: Revoke
-- * parâmetros:
--   * id = identificador da entidade
--   * interfaces = lista de interfaces a serem desautorizadas.
Revoke {
  id = "TEST_Entity",
  interfaces = {
    "IDL:script/Test:1.0",
  }
}
O busadmin também permite realizar esses cadastros e descadastros manualmente, além de realizar consultas e outras atividades de gerência do barramento. A listagem completa dos comandos disponíveis é apresentada a seguir:

3.3 Geração de chaves

Primeiramente deve-se obter um binário do openssl na versão 1.0.0 ou maior. Para gerar a chave privada, são necessários os seguintes comandos (estamos utilizando comandos do Bash shell [3] no exemplo abaixo): 

  openssl genrsa -out tmp_openssl.key 2048

  openssl pkcs8 -topk8 -nocrypt -in tmp_openssl.key -out \
    <nome do par de chaves>.key -outform DER

  rm -f tmp_openssl.key

Para gerar o certificado, utilize o seguinte código: 

  openssl req -days <validade do certificado em dias> -new -x509 \
    -key <nome do par de chaves>.key -keyform DER \
    -out <nome do par de chaves>.crt -outform DER

Para converter uma chave utilizada em um SDK 1.5 para uma chave que funcione com SDKs 2.0, utilize o seguinte comando: 

  openssl pkcs8 -topk8 -nocrypt -in chave.pem -inform PEM -out chave.der -outform DER

3.4 Desenvolvedores de Sistemas Integrados

Como informado na seção 2.1, oferecemos uma biblioteca de acesso, que implementa o protocolo e exporta uma API de programação, a qual oferece alguns facilitadores e auxilia a interação com o barramento. Para maiores informações, consulte o manual de uso da biblioteca de acesso (seção 2.4).


4 Glossário

A

API
Application Program Interface. Interface de programação oferecida às aplicações que precisam acessar o barramento, seja para fazer ou receber chamadas através do barramento, ou acessar serviços oferecidos pelo barramento.

Autorização
Associação de uma interface IDL a uma entidade, indicando que processos autenticados como essa entidade possam oferecer serviços que implementem essa interface no Registro de Ofertas do barramento.

B

Barramento
Toda infraestrutura oferecida pelo OPENBUS que permite fazer chamadas CORBA com a identificação das entidades com que os processos que originaram a chamada foram autenticados.

Biblioteca de Acesso
Biblioteca de programação que implementa a API do OPENBUS. O projeto OPENBUS oferece implementações dessa biblioteca nas linguagens Lua, Java, C++ e C#.

busadmin
Ferramenta que permite realizar operações de adminstração do barramento (governaça).

busservices
Programa que implementa o barramento e os serviços núcleo do barramento OPENBUS.

C

Categoria
Representa uma categoria de entidades no barramento. Categorias de entidade são agrupamentos usados exclusivamente para facilitar a gerência das diversas entidades cadastradas no barramento pelo administrador.

Certificado
Chave pública que pode ser usado para autenticar uma dada entidade no barramento.

Controle de Acesso
Serve como ponto de entrada do barramento, sendo responsável por autenticar, renovar e gerenciar os logins de serviços e aplicações ao barramento.

CORBA
Common Object Request Broker Architecture. Especificação de um padrão de ORB sobre a qual o OpenBus é definido e implementado. O OPENBUS pode ser visto como uma extensão do padrão CORBA.

E

Entidade
Qualquer coisa que pode ser autorizada a acessar o barramento. Cada entidade possui um identificador único na forma de um nome. Entidades podem ser usuários humanos de sistemas ou mesmo instalações de serviços específicos de aplicações.

I

IDL
Interface Description Language. Linguagem de descrição de tipos e interfaces de CORBA.

Interface
Definição de uma interface IDL de um serviço que pode ser ofertado no barramento.

L

Lease
Período de tempo pelo qual um login no barramento permanecerá válido sem necessidade de renovação. Contudo, um login pode ser invalidado explicitamente por um administrador antes do tempo de lease.

LDAP
Lightweight Directory Access Protocol. É um protocolo de Internet para acessar serviços de diretório distribuídos. É comumente usado para autenticação em redes corporativas.

Login
Representa uma autenticação de uma entidade junto ao barramento para poder acessá-lo.

Logout
Processo no qual o criador de um login o invalida, fazendo com que esse login não possa mais ser usado para acessar o barramento.

O

Oferta de Serviço
Cadastro no Registro de Ofertas de um componente SCS que implementa um conjunto de interfaces autorizadas que representam um dado serviço a ser utilizado através do barramento.

OPENBUS
Nome deste projeto que define um barramento baseado em CORBA para integração de aplicações coorporativas multilinguagem.

P

Propriedades da Oferta
Conjunto de pares nome e valor que descrevem uma oferta de serviço.

Protocolo
Conjunto de regras de comunicação para acesso ao barramento OPENBUS.

R

Registro de Ofertas
Serviço núcleo do barramento que permite registrar e buscar ofertas de serviços no barramento. Esse serviço é disponibilizado através da API.

S

SCS
Software Component System. Modelo de componentes de software distribuído adotado pelo OPENBUS. Todos serviços ofertados no barramento devem ser modelados como componentes SCS.

Serviços Núcleo
Serviços oferecidos pelo próprio barramento, tipicamente acessados através da API.

Serviços Extras
Serviços que acrescentam funcionalidades para auxiliar a integração entre serviços e aplicações, mas que não são parte do núcleo do barramento.

V

Validadores LDAP
São utilizados para autenticar usuários em serviços de diretório que utilizam o protocolo LDAP.

Referências Bibliográficas

1
C. Augusto, E. Fonseca, L. Marques, S. Correa, and R. Cerqueira.
SCS: Software component system.
http://www.tecgraf.puc-rio.br/scs, May 2006.

2
T. Erl.
Service-oriented architecture: concepts, technology, and design.
Prentice Hall PTR, 2005.

3
GNU.
Bash reference manual.
http://www.gnu.org/software/bash/manual/bashref.html, 2010.

4
Roberto Ierusalimschy.
The programming language lua.
http://www.lua.org/, February 2008.

5
Renato Maia.
OiL: An object request broker in the Lua language.
http://www.tecgraf.puc-rio.br/~maia/oil/, 2005.

6
Renato Maia, Renato Cerqueira, and Ricardo Calheiros.
OiL: An object request broker in the Lua language.
In Mauro S. P. Fonseca, editor, Proceedings of SBRC'06 - Salão de Ferramentas, pages 1439-1446, Porto Alegre, Brazil, June 2006. SBC.

7
Object Management Group.
The Common Object Request Broker Architecture (CORBA) Specification - Version 3.1, January 2008.
document: formal/2008-01-04.

8
TecGraf.
OpenBus - Enterprise Integration Application Middleware.
http://www.tecgraf.puc-rio.br/openbus, 2006.

9
TecGraf.
Manual de instalação do OpenBus 2.0.0.
TecGraf, 2012.

10
TecGraf.
Tutorial do SDK C# 2.0.0.
TecGraf, 2012.

11
TecGraf.
Tutorial do SDK C++ 2.0.0.
TecGraf, 2012.

12
TecGraf.
Tutorial do SDK Java 2.0.0.
TecGraf, 2012.

13
TecGraf.
Tutorial do SDK Lua 2.0.0.
TecGraf, 2012.

14
TecGraf.
Documentação do Serviço de Colaboração 1.0.
https://jira.tecgraf.puc-rio.br/confluence/pages/viewpage.action?pageId=52528899, 2013.


Footnotes

... válido1
Essa tarefa de renovação de login é feita automaticamente pela biblioteca de acesso do OPENBUS.
... barramento2
A identificação de que o login ficou inválido e o restabelecimento do login podem ser feitos através da callback onInvalidLogin da biblioteca de acesso do OPENBUS.