overview.tex

%
%  OpenBus 2.1
%
%  Created by Hugo Roenick on 2012-05-22.
%  Copyright (c) 2012 Tecgraf/PUC-Rio. All rights reserved.
%
\documentclass[]{article}

% Use utf-8 encoding for foreign characters
\usepackage[latin1]{inputenc}

\usepackage[brazil]{babel}

% Setup for fullpage use
\usepackage{fullpage}

% Uncomment some of the following if you use the features
%
% Running Headers and footers
%\usepackage{fancyhdr}

% Multipart figures
%\usepackage{subfigure}

% More symbols
%\usepackage{amsmath}
%\usepackage{amssymb}
%\usepackage{latexsym}

\usepackage{hyperref}

% Surround parts of graphics with box
\usepackage{boxedminipage}

% Package for including code in the document
\usepackage{../mwlabinputs2}

\usepackage{html}   %  *always* load this for LaTeX2HTML
\begin{htmlonly}
  \usepackage{verbatim}
  \providecommand{\codeinput}[2]{%
    \textbf{\label{lst:#1}#2}%
    \verbatiminput{src/#1}%
  }%
\end{htmlonly}

% If you want to generate a toc for each chapter (use with book)
\usepackage{minitoc}

% This is now the recommended way for checking for PDFLaTeX:
\usepackage{ifpdf}

\usepackage{listings}

%% Redefines the label 'Listing' for ..
\def\lstlistingname{Código}
\codestyle{colorful}
\imagedir{figs}

% new commands
\newcommand{\foreign}[1]{\textit{#1}}
\newcommand{\term}[1]{\textit{#1}}
\newcommand{\code}[1]{\texttt{#1}}

\newcommand{\openbus}{\textsc{OpenBus}}
\newcommand{\corba}{\textsc{CORBA}}
\newcommand{\orb}{\textsc{ORB}}
\newcommand{\scs}{\textsc{SCS}}
\newcommand{\lua}{\textsc{Lua}}
\newcommand{\oil}{\textsc{OiL}}
\newcommand{\version}{2.1.0}
\newcommand{\idlversion}{2.1.x}
\newcommand{\legacyidlversion}{2.0.x}


%\newif\ifpdf
%\ifx\pdfoutput\undefined
%\pdffalse % we are not running PDFLaTeX
%\else
%\pdfoutput=1 % we are running PDFLaTeX
%\pdftrue
%\fi

\ifpdf
\usepackage[pdftex]{graphicx}
\else
\usepackage{graphicx}
\fi

\title{Visão geral do \openbus{} \version{}}
\author{Tecgraf}

\date{\today}

\begin{document}

\ifpdf
\DeclareGraphicsExtensions{.pdf, .jpg, .tif}
\else
\DeclareGraphicsExtensions{.eps, .jpg}
\fi

\maketitle

\tableofcontents

\section{Introdução}

O \openbus{}~\cite{web:OPENBUS} é 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:
%
\begin{description}
  \item[\corba{}]
  \foreign{Common Object Requester Broker Architecture}~\cite{omg08corbaspec} é 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.
  \item[\scs{}]
  \foreign{Software Component System}~\cite{web:SCS} é 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.
\end{description}

Em cima dessas duas tecnologias o \openbus{} introduz duas novas extensões, que basicamente definem a infraestrutura especializada para integração de sistemas computacionais:
%
\begin{description}
  \item[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.
  \item[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 (\emph{Service-Oriented Architecture}, ou SOA~\cite{erl2005service}).
  O objetivo desses serviços é oferecer funcionalidades básicas e essenciais que visem facilitar e agilizar o desenvolvimento da integração dos diferentes sistemas.
\end{description}

% TODO: review the summary of the text.
Este documento tem como objetivo apresentar o \openbus{} \version{} 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~\ref{sec:architecture} apresentamos a arquitetura do sistema, e entramos um pouco mais em detalhes de como ocorre a comunicação dentro do barramento na seção~\ref{sec:communication}.
Em seguida, na seção~\ref{sec:perspectives} 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~\ref{sec:glossary} apresentamos um glossário com os conceitos principais do projeto.

\subsection{Quando Utilizar o \openbus{}}

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.

\section{Arquitetura}\label{sec:architecture}

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~\ref{fig:architecture}, apresenta a arquitetura do \openbus{} e suas partes principais. 
Entraremos em detalhes sobre as partes principais do \openbus{} nas subseções a seguir.

\begin{figure}
\centering
\includegraphics[width=\textwidth]{figs/architecture}
\caption{Arquitetura do \openbus{}}
\label{fig:architecture}
\end{figure}

\subsection{Barramento}\label{sec: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:

\begin{description}
  \item[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.

  \item[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.

  \item[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.
\end{description}

Tipicamente os logins de acesso ao barramento ficam válidos por um período denominado \term{lease}.
Após o período de \term{lease}, o login deve ser renovado para que possa continuar válido\footnote{Essa tarefa de renovação de login é feita automaticamente pela biblioteca de acesso do \openbus{}.}.
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 barramento\footnote{A identificação de que o login ficou inválido e o restabelecimento do login podem ser feitos através da callback \code{onInvalidLogin} da biblioteca de acesso do \openbus{}.}.
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 \emph{A.B.C.D}, onde:

\begin{itemize}
  \item Campos \textbf{A} e \textbf{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.
  \item Campo \textbf{C} é incrementado quando ocorre alguma modificação que não altera a IDL do núcleo do barramento.
  \item Campo \textbf{D} representa uma versão apenas com correções de falhas.
\end{itemize}

Sendo assim, o barramento \idlversion{} permite a realização de acesso utilizando as bibliotecas de acesso de versão \legacyidlversion{}, onde \emph{x} pode assumir qualquer valor de \emph{C.D}.
É importante notar que uma das novas funcionalidades do \openbus{} \idlversion{} é o suporte a comunicações CORBA sobre SSL. Quando um sistema baseado na versão \idlversion{} se comunicar com um sistema baseado na versão \legacyidlversion{}, pode não ser possível utilizar essa funcionalidade.

\subsection{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{}~\cite{web:SCS} 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:

\begin{itemize}
  \item login com que a oferta foi registrada.
  \item nome da entidade que registrou a oferta.
  \item momento do registro da oferta.
  \item nome e versão do componente \scs{} que implementa o serviço.
  \item facetas e interfaces do component \scs{} que implementa o serviço.
\end{itemize}

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 \ref{sec:library})

\subsection{Serviços Extra}

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

\begin{itemize}
  \item Criar e compartilhar uma sessão de colaboração.
  \item Oferecer um canal de comunicação para enviar eventos para todos os membros da sessão.
\end{itemize} 

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~\cite{web:collaboration1.0}.

\subsection{Biblioteca de Acesso}\label{sec:library}

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:

\begin{itemize}
  \item Autenticação de entidades;
  \item Obtenção de logins;
  \item Renovação automática de \term{lease} de logins;
  \item Receber notificação sobre o login se tornar inválido;
  \item Realizar chamadas utilizando diferentes logins;
  \item Identificar os logins e as entidades que originaram cada chamada recebida.
\end{itemize}

A biblioteca de acesso do \openbus{} tem implementações nas quatro diferentes linguagens de programação suportadas oficialmente pelo \openbus{}, em particular, Java~\cite{sdk2.0.0-java}, C\#~\cite{sdk2.0.0-csharp}, C++~\cite{sdk2.0.0-cpp} e Lua~\cite{sdk2.0.0-lua}.

\subsubsection{Comunicação Através do Barramento}\label{sec:communication}

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:
\begin{itemize}
  \item Primeiramente, o desempenho da comunicação entre dois sistemas só depende da qualidade da rede de comunicação entre esses dois sistemas.
  \item 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.
\end{itemize}

\section{Perspectivas}\label{sec:perspectives}

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:

\begin{description}
  \item[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.
  \item[Gerente do Barramento] Aqueles que irão desempenhar o papel de organizar e acompanhar o que é publicado no barramento.
  \item[Desenvolvedor de Sistemas Integrados] Responsáveis por implementar a integração de seus respectivos serviços e aplicações ao barramento.
\end{description}

\subsection{Administradores de Sistema}

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 \emph{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 \emph{busservices}, consulte~\cite{busservicesmanual}.



\subsection{Gerentes do Barramento}

Para desempenhar o papel de gerente do barramento, disponibilizamos a ferramenta \emph{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:
\begin{description}

  \item[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.

  \item[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.

  \item[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.

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

  \item[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.

\end{description}

Para informações sobre como utilizar a ferramenta, consulte~\cite{busadminmanual}.



\subsection{Desenvolvedores de Sistemas Integrados}

Como informado na seção~\ref{sec:barramento}, 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 \ref{sec:library}).


\include{glossary}

\bibliographystyle{plain}
\bibliography{../references}

\end{document}