Visão geral do OPENBUS 2.1.0
O OPENBUS [4] é 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 [3] é 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 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 a 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 e 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.1.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.
O OPENBUS é um middleware para a 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 precisem trocar dados é por meio da troca de arquivos num formato adotado por ambos os 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 a 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 o 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
|
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 do 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 a 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 através de autenticação por senha.
- 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 à revelia da aplicação.
Neste caso, uma nova autenticação deve ser realizada para a 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 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:
- Campos A e B significam a versão da IDL e deve ser igual em todos os pacotes que são compatíveis: versão IDL, barramento e bibliotecas de acesso.
- Campo C é incrementado quando ocorre alguma modificação que não altera a IDL do núcleo do barramento.
- Campo D representa uma versão apenas com correções de falhas.
Sendo assim, o barramento 2.1.x permite a realização de acesso utilizando as bibliotecas de acesso de versão 2.0.x, onde x pode assumir qualquer valor de C.D.
É importante notar que uma das novas funcionalidades do OPENBUS 2.1.x é o suporte a comunicações CORBA sobre SSL. Quando um sistema baseado na versão 2.1.x se comunicar com um sistema baseado na versão 2.0.x, pode não ser possível utilizar essa funcionalidade.
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 de 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:
- login com que a oferta foi registrada.
- nome da entidade que registrou a oferta.
- momento do registro da oferta.
- nome e versão do componente SCS que implementa o serviço.
- facetas e interfaces do component SCS que implementa o serviço.
Entre outras propriedade automáticas. 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)
A versão atual do OPENBUS oferece um serviço extra denominado Serviço de Colaboração.
Esse serviço tem como principais funcionalidades:
- Criar e compartilhar uma sessão de colaboração.
- Oferecer um canal de comunicação para enviar eventos para todos os membros da sessão.
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 [5].
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:
- Autenticação de entidades;
- Obtenção de logins;
- Renovação automática de lease de logins;
- Receber notificação sobre o login se tornar inválido;
- Realizar chamadas utilizando diferentes logins;
- Identificar os logins e as entidades que originaram cada chamada recebida.
A biblioteca de acesso do OPENBUS tem implementações nas quatro diferentes linguagens de programação suportadas oficialmente pelo OPENBUS, em particular, Java [10], C# [8], C++ [9] e Lua [11].
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árias caches internas 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:
- Primeiramente, o desempenho da comunicação entre dois sistemas só depende da qualidade da rede de comunicação entre esses dois sistemas.
- Além disso, mesmo que a infraestrutura do barramento fique indisponível por alguma falha inesperada, a comunicação entre os serviços pode continuar, mesmo que com um nível de qualidade limitado.
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.
O papel do administrador de sistema é gerenciar a execução do barramento. 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. Para maiores detalhes sobre a execução do busservices, consulte [7].
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.
Vamos agora apresentar alguns conceitos importantes de governança dentro do OPENBUS. Eles são:
- 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 informações sobre como utilizar a ferramenta, consulte [6].
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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Validadores LDAP
- São utilizados para autenticar usuários em serviços de diretório que utilizam o protocolo LDAP.
- 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
-
Object Management Group.
The Common Object Request Broker Architecture (CORBA)
Specification - Version 3.1, January 2008.
document: formal/2008-01-04.
- 4
-
TecGraf.
OpenBus - Enterprise Integration Application Middleware.
http://www.tecgraf.puc-rio.br/openbus, 2006.
- 5
-
TecGraf.
Documentação do Serviço de Colaboração 1.0.
https://jira.tecgraf.puc-rio.br/confluence/x/XYEHB, 2013.
- 6
-
TecGraf.
Manual do busadmin 2.1.0.
https://jira.tecgraf.puc-rio.br/confluence/x/UoEHB, 2015.
- 7
-
TecGraf.
Manual do openbus 2.1.0.
https://jira.tecgraf.puc-rio.br/confluence/x/UoEHB, 2015.
- 8
-
TecGraf.
Tutorial do sdk c# 2.1.0.
https://jira.tecgraf.puc-rio.br/confluence/x/UoEHB, 2015.
- 9
-
TecGraf.
Tutorial do sdk c++ 2.1.0.
https://jira.tecgraf.puc-rio.br/confluence/x/UoEHB, 2015.
- 10
-
TecGraf.
Tutorial do sdk java 2.1.0.
https://jira.tecgraf.puc-rio.br/confluence/x/UoEHB, 2015.
- 11
-
TecGraf.
Tutorial do sdk lua 2.1.0.
https://jira.tecgraf.puc-rio.br/confluence/x/UoEHB, 2015.
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.
