overview.tex 22 KB
Newer Older
1
%
2
%  OpenBus 2.1
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
%
%  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
36
\usepackage{../mwlabinputs2}
37

38
39
40
41
42
43
44
45
46
\usepackage{html}   %  *always* load this for LaTeX2HTML
\begin{htmlonly}
  \usepackage{verbatim}
  \providecommand{\codeinput}[2]{%
    \textbf{\label{lst:#1}#2}%
    \verbatiminput{src/#1}%
  }%
\end{htmlonly}

47
48
49
50
51
52
% 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}

53
54
\usepackage{listings}

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

60
% new commands
61
\newcommand{\foreign}[1]{\textit{#1}}
62
63
64
65
66
67
68
\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}}
69
70
\newcommand{\lua}{\textsc{Lua}}
\newcommand{\oil}{\textsc{OiL}}
71
72
73
\newcommand{\version}{2.1.0}
\newcommand{\idlversion}{2.1.x}
\newcommand{\legacyidlversion}{2.0.x}
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89


%\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

90
\title{Visão geral do \openbus{} \version{}}
91
\author{Tecgraf}
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108

\date{\today}

\begin{document}

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

\maketitle

\tableofcontents

\section{Introdução}

109
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.
Hugo Roenick's avatar
Hugo Roenick committed
110
O \openbus{} se baseia em duas tecnologias complementares para constituir uma infraestrutura básica de integração de sistemas.
111
112
113
São elas:
%
\begin{description}
Hugo Roenick's avatar
Hugo Roenick committed
114
  \item[\corba{}]
115
  \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.
Hugo Roenick's avatar
Hugo Roenick committed
116
117
118
119
  \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.
120
  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.
121
122
\end{description}

Hugo Roenick's avatar
Hugo Roenick committed
123
Em cima dessas duas tecnologias o \openbus{} introduz duas novas extensões, que basicamente definem a infraestrutura especializada para integração de sistemas computacionais:
124
125
126
%
\begin{description}
  \item[Barramento de Integração]
Hugo Roenick's avatar
Hugo Roenick committed
127
  É o conceito central do \openbus{}.
128
129
  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.
130
  \item[Serviços de Apoio à Integração]
131
  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}).
132
133
134
135
  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.
136
Este documento tem como objetivo apresentar o \openbus{} \version{} e seus conceitos principais.
137
Nesta seção introdutória apresentaremos uma definição do projeto e os motivadores para o seu uso.
138
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}.
139
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.
140

141
142
\subsection{Quando Utilizar o \openbus{}}

143
O \openbus{} é um middleware para a integração de sistemas heterogêneos.
144
Contudo, a integração de sistemas pode se dar de diversas formas diferentes e envolver requisitos diversos.
145
146
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.
147

148
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.
149
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.
150
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.
151
152
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.

153
Outra necessidade comum na integração de sistemas cooperativos é o controle de acesso e a governança das integrações.
154
155
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.

156
O \openbus{} oferece uma infraestrutura adequada para implementar integrações entre sistemas tendo essas questões e necessidades em mente.
157
158
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.
159
160
161

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

162
163
164
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.

165
166
167
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.

Amadeu Andrade Barbosa Junior's avatar
Amadeu Andrade Barbosa Junior committed
168
169
\begin{figure}
\centering
170
\includegraphics[width=\textwidth]{figs/architecture}
Amadeu Andrade Barbosa Junior's avatar
Amadeu Andrade Barbosa Junior committed
171
172
173
\caption{Arquitetura do \openbus{}}
\label{fig:architecture}
\end{figure}
174

175
\subsection{Barramento}\label{sec:barramento}
176

177
O barramento é o meio de comunicação entre os sistemas integrados.
Hugo Roenick's avatar
Hugo Roenick committed
178
Toda comunicação feita pelos sistemas integrados através do barramento consiste de chamadas de objetos distribuídos usando o padrão \corba{}.
179
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.
180

181
Essas entidades são tipicamente sistemas computacionais e usuários desses sistemas.
182
Cada entidade é identificada por um nome único no barramento a ser definido pelo gerente do barramento.
183
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.
184

Hugo Roenick's avatar
Hugo Roenick committed
185
Todo acesso ao barramento é autenticado através de credenciais ocultas nas chamadas de objetos \corba{}.
186
187
188
189
190
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.
191

192
O \openbus{} define três formas para autenticação de uma entidade no processo de criação de logins de acesso.
193
Essas três formas de autenticação são:
194

195
196
197
\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.
198
  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.
199
  Essa forma de autenticação é geralmente utilizada para incorporar ao barramento um grande número de usuários mantidos num sistema separado.
Hugo Roenick's avatar
Hugo Roenick committed
200
  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.
201
  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.
202
203

  \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.
204
  Para que a autenticação ocorra, é preciso decodificar um desafio encriptado com a chave pública contida no certificado cadastrado.
205
  Para tanto, é necessário ter a chave privada correspondente ao certificado cadastrado.
206
  Essa forma de autenticação é geralmente utilizada para autorizar o acesso de sistemas computacionais específicos que fornecem serviços através do barramento.
207
  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.
208
209
210
211
212

  \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}
213

214
Tipicamente os logins de acesso ao barramento ficam válidos por um período denominado \term{lease}.
Hugo Roenick's avatar
Hugo Roenick committed
215
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{}.}.
216
217
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{}.}.
218
Uma vez inválido, um login nunca volta a ser válido novamente.
219

220
221
222
223
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.

224
Outra característica importante é que o barramento mantém compatibilidade com a versão imediatamente anterior do barramento.
225
226
227
228
229
230
231
232
233
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}

234
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}.
235
É 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.
236

237
238
\subsection{Serviços Núcleo}

239
240
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.
241

242
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.
243
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.
244
Essas propriedades poderão ser utilizadas como critério de filtro no momento de buscar por ofertas de serviço no Registro de Ofertas.
245

246
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:
247

248
249
250
251
\begin{itemize}
  \item login com que a oferta foi registrada.
  \item nome da entidade que registrou a oferta.
  \item momento do registro da oferta.
Hugo Roenick's avatar
Hugo Roenick committed
252
253
  \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.
254
\end{itemize}
255

256
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.
257
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})
258

259
\subsection{Serviços Extra}
260

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

\begin{itemize}
265
266
  \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.
267
268
\end{itemize} 

269
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}.
270

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

273
274
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.
275
Através dessa biblioteca é possível realizar as seguintes operações, dentre outras:
276

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

286
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}.
287

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

290
291
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.
292

293
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.
294
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.
295

296
297
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:
298
299
300
301
\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}
302

303
\section{Perspectivas}\label{sec:perspectives}
304
305

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.
306
Os papéis abordados são:
307

308
\begin{description}
309
  \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.
310
311
312
  \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}
313

314
\subsection{Administradores de Sistema}
315

316
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}.
317
318
319



320
\subsection{Gerentes do Barramento}
321

322
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.
323

324
Vamos agora apresentar alguns conceitos importantes de governança dentro do \openbus{}. Eles são:
325
326
327
328
329
330
\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.
331
  Entidade é tudo aquilo que pode fazer login no barramento e usufruir dos seus recursos.
332
333
  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.
334

335
  \item[Certificado] Chave pública que pode ser usada para autenticar uma
336
dada entidade no barramento. Ver seção sobre geração de chaves para informações sobre como gerar as chaves pública e privada.
337
338
339
340
  É 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.

341
  \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.
342
343
344

\end{description}

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

347
348


349
\subsection{Desenvolvedores de Sistemas Integrados}
350

351
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.
352
Para maiores informações, consulte o manual de uso da biblioteca de acesso~(seção \ref{sec:library}).
353
354
355
356
357


\include{glossary}

\bibliographystyle{plain}
358
\bibliography{../references}
359
360

\end{document}