CORBA - Sistemas Distribuídos

Prévia do material em texto

FACULDADE PITAGORAS 
CIÊNCIA DA COMPUTAÇÃO 
 
 
 
ANDRÉ VINICIUS REIS PEREIRA 
ANTÔNIO MASCARENHAS 
ELVISLENNO VERAS NUNES 
GILSON MIGUEL TELES NETO 
IVALDO BEZERRA 
JOÃO PEDRO MONTELES 
 
 
 
 
 
 
 
 
 
 
 
 
São Luís 
2016 
 
 
ANDRÉ VINICIUS REIS PEREIRA 
ANTÔNIO MASCARENHAS 
ELVISLENNO VERAS NUNES 
GILSON MIGUEL TELES NETO 
IVALDO BEZERRA 
JOÃO PEDRO MONTELES 
 
 
 
 
 
 
SISTEMAS DISTRIBUIDOS - CORBA 
 Trabalho apresentado à disciplina Sistemas 
 distribuidos do Curso Ciência da Computação 
 da Faculdade Pitágoras, como requisito para 
 obtenção de nota 
 Prof.:Edil 
 
 
 
São Luís 
2016 
 
 
 
 
CORBA 
 Conceito: 
Common Object Request Broker Architecture (CORBA), ​é um padrão criado pela OMG (Object 
Management Group - Grupo de Gerenciamento de Objetos) para permitir a interação entre 
aplicações heterogêneas em ambientes também heterogêneos, para a troca de informações 
completamente distribuídas sendo executado em qualquer parte da rede ou Internet. 
A OMG é uma organização internacional da indústria de software, que estabeleceu uma estrutura 
comum para o gerenciamento de objetos distribuídos, conhecida como Object Manager 
Architecture (OMA). ​É formada por empresas dos diferentes ramos da informática (venda, 
desenvolvimento, produção). Algumas empresas que participam da OMG são: AT & T, Cisco, 
Cannon, IBM, Apple, e outras. Essas empresas trabalham sem fins lucrativos, para promover a 
criação e elaboração de modelos e padrões que proporcionem a interoperabilidade entre 
aplicações que usam tecnologia orientada a objeto. 
 Componentes: 
O CORBA possui dois tipos de componentes: 
• Orientados ao Sistema: ORB, Objetos de Serviços 
• Orientados a Aplicação: Objetos de Aplicação, Facilidades Comuns. 
 
• ORB (Object Request Broker): 
É o núcleo do CORBA, e exerce o papel de middleware entre os componentes, é um componente 
intermediário da arquitetura do CORBA que facilita a comunicação entre o cliente e os objetos 
que implementam as funcionalidades que o cliente irá utilizar. 
ORB é responsável por toda comunicação e interação entre os objetos, ele intercepta a chamada e 
fica responsável em encontrar um objeto que atenda as necessidades do pedido, encontrando o 
objeto, o ORB passa os parâmetros para o mesmo, invoca os métodos necessários dele, e retorna 
para o objeto que solicitou o pedido, os resultados de todo esse procedimento. Dessa maneira, o 
usuário não precisa se preocupar onde tal objeto está localizado, em que sistema operacional ele 
roda ou qual programa foi usado para desenvolvê-lo. 
 
• Objetos de Serviços (Object Services): 
É uma coleção de serviços (interfaces) que abrangem funções básicas que poderão ser usadas 
para a implementação e gerenciamento dos objetos. Exemplo: serviço de nomes, eventos, tempo, 
segurança, etc. 
• Facilidades Comuns (Common Facilites): 
Assim como os objetos de serviços, as "facilidades comuns" também apresentam-se como uma 
coleção de serviços (interfaces), os quais estão mais diretamente relacionados com o usuário 
final, como a manipulação de dados e armazenamento. 
• Objetos de Aplicação (Application Objects): 
São os objetos que podem ser considerados visíveis ao nível de aplicação, são componentes 
desenvolvidos especificamente para aplicações do usuário final. 
 
 Evolução das especificações do CORBA: 
1991 - 1993: CORBA 1.0 – 1.2 
 
• Introduziu o CORBA Object Model, núcleo básico de APIs, IDL; 
• Mapeamento apenas para a linguagem C. 
 
1996 - 2001: CORBA 2.0 – 2.6 
• GIOP e IIOP; 
• Inclusão de segurança e suporte à transações; 
• Melhorias nos repositórios de interfaces; 
• Mapeamento Java, C++. 
 
2002: CORBA 3.0 
• Melhoria na integração com Java, maior facilidade de programação; 
• Atualmente na versão 3.3 
 
 
 
 
 
 
 
 
 
 
 
CORBA RMI 
 Java Remote Method Invocation (RMI) é o modelo de objetos de distribuição para 
 a linguagem Java que mantem a semântica próximo do modelo de objetos Java. O 
 O sistema combina aspectos do modelo de redes de objetos do modulo-3. Além de incluir novos fatores 
que o Java possibilita[SAN 2002] 
 
Historico do Desenvolvimento da Tecnologia RMI 
O Java RMI baseia-se em uma tecnologia anterior, criada pelo SUN 
Microsystems, a RPC (Remote Procedure Call). Mas diferente do RPC , no RMI, 
A chamada remota de métodos pode conter objetos complexos , pois a própria 
Pois a própria linguagem trata das pendencias e da serealização dos objetos 
Em uma fila de bytes. Alem disso, como o RMI suporte apenas a linguagem 
Java , não é nescessario usar uma linguagem IDL, as próprias Interfaces definidas em Java são utilizadas 
[SAN] 
 
Arquitetura do Modelo RMI 
O RMI execulta métodos de objetos em Maquinas Virtuais Java remotas, 
Podendo passar como parâmetros todas as estruturas de dados aceitas pela 
linguagem Java (objetos array , etc) 
O RMI mantem similaridade com o CORBA , apresentando diferenças 
Principalmente no que se refere a usabilidade. Aplicações desenvolvidas com 
RMI , geralmente, tem um tempo de desenvolvimento mais curto do que as 
Desenvolvidas em CORBA , de forma que o RMI possibilita a criação de 
Aplicações distribuídas sem o peso do CORBA , ao custo da ligação restrita à 
Linguagem Java[ SAN 2002] 
O processo de comunicação de uma chamada RMI passa por diversas 
camadas. Dessa forma, o uso do modelo RMI padrão pode implicar custos no 
desempenho final da aplicação, comparando-se, por exemplo , com aplicações 
que utilizam sistemas de passagem de mensagens [SAN 2002]. 
È muito comum encontrar em comparações a vantagem do coletor de lixo 
(Automatic garbage colllection) do RMI em relação ao CORBA. Na verdade 
Esse coletor é implementado pelo Java. Quando o ORB e implementado sobre 
O Java este também desfruta dessa facilidade. 
 
 
ARQUITETURA CORBA 
Ambientes que visam desenvolver aplicações que precisam de um processamento paralelo e distribuído 
deverão saber lidar com algumas dificuldades. Isto decorre da heterogeneidade de hardware, sistemas 
operacionais, linguagens de programação, protolocos de comunicação, arquiteturas de computadores e 
diferentes formas de se representar dados.[1] 
Para resolver esses problemas, percebeu-se a necessidade de se ter transparência de localização de 
recursos computacionais, suporte universal de representação de dados, interoperabilidade entre 
componentes de uma aplicação distribuída, reutilização de componentes, integração de código.[2] 
O modelo de arquitetura CORBA propõe a interoperabilidade local e/ou remota entre aplicações que têm 
como base a tecnologia orientada a objetos. Com isso, é possível permitir que objetos de sistemas 
distribuídos comuniquem-se de forma transparente, independentemente do local onde se encontram, do 
protocolo que utilizam, da linguagem em que foram implementados, da plataforma e do sistema 
operacional em que estão rodando [2,3,4,5]. 
Para cada sistema de rede o CORBA permite que seja definida uma Linguagem de Definição de Interface 
(IDL). Essas interfaces descrevem os serviços que são oferecidos. Trata-se de uma linguagem puramente 
declarativa, que ao ser compilada irá gerar o stubs e o skeletons (responsável pelacomunicação entre 
objetos) [7]. Desta forma, a aplicação cliente pode acessar facilmente todos os serviços oferecidos. 
Além disso, o CORBA inclui uma estrutura de execução, fornecendo diversas funcionalidades básicas 
importantes como localização e ativação automática de serviços, comunicação, controle de transações e 
segurança [7]. 
Em linhas gerais, a arquitetura CORBA é composta pelos seguintes componentes [5,8]: 
Do lado do cliente, temos os seguintes itens: 
Stubs Clientes - trata-se de uma interface estática gerada através da compilação de uma IDL. Compõe 
uma mensagem que contém uma identificação e protótipos dos métodos invocados a um servidor. 
Interface de Invocação Dinâmica (DII) - permite que o cliente invoque um método no servidor sem que 
tenha conhecimento, em tempo de compilação, de sua interface. 
Repositório de Interfaces - contém uma base de dados com a definição de todas as interfaces de serviços 
conhecidos pelo ORB. 
Do lado do objeto CORBA servidor, temos os seguintes itens: 
Skeletons - interface estática para os serviços (métodos) remotos. É responsável por receber as requisições 
do cliente e repassá-las para o servidor. 
Interface de Skeletons Dinâmica (DSI) - é semelhante ao DII, porém ocorre no lado do servidor. Fornece 
um mecanismo que permite, em tempo de execução, que servidores entreguem requisições de um ORB 
para uma implementação de objeto sem que tenha conhecimento, em tempo de compilação, de sua 
interface; 
Repositório de Implementação - é um repositório, em tempo de execução, para as classes que um servidor 
suporta, os objetos instanciados e suas identificações; 
Adaptador de Objetos (OA) - responsável por: registrar as classes servidoras no repositório de 
implementação; instanciar os objetos chamados em tempo de execução, de acordo com a demanda dos 
clientes; receber as chamadas para os objetos e repassá-las aos mesmos; gerar e gerenciar as referências 
de objetos (ORB). 
Interface ORB - permite o acesso às funcionalidades não oferecidas pelas demais interfaces, pois não 
depende da interface do objeto ou do adaptador do objeto. 
 
 
 
 
 
 
LINGUAGEM DE DEFINIÇÃO E 
INTERFACE 
 
A ESPECIFICAÇÃO CORBA, PUBLICADA PELO OMG,É TANTO UMA ARQUITETURA QUE 
CONTEM UM MODELO DE OBJETO QUANTO UMA ESPECIFICAÇÃO QUE DEFINE ENTRE 
OUTRAS COISAS UMA LINGUAGEM DE DEFINIÇÃO DE INTERFACE(IDL).NO 
CORBA,INTERFACES DE OBJETOS SÃO DESCRITAS ATRAVÉS DA IDL,UMA LINGUAGEM 
DECLARATIVA COM A SINTAXE SEMELHANTE A DO C++,A IDL PERMITE QUE 
INTERFACES PARA OBJETOS SEJAM DEFINIDAS INDEPENDENTEMENTE DAQ 
IMPLEMENTAÇÃO DOS OBJETOS.DEPOIS DE DEFINIR UMA INTERFACE NA IDL, A 
DEFINIÇÃO DA INTERFAE É UTILIZADA COMO ENTRADA PARA UM COMPILADOR IDL 
QUE PRODUZ UMA SAIDA QUE PODE SER COMPILADA E LINKADA COM UMSA 
IMPLEMENTAÇÃO DE UM OBJETO ED SEUS CLIENTES. 
O CORBA SUPORTA CLIENTES(SISTEMAS E/OU INTERFACES​) FAZENDO PEDIDOS A 
OBJETOS.OS PEDIDOS CONSISTEM EM UMA OPERAÇÃO,UM OBJETO ALVO,ZERO OU 
MAIS PARAMETROS E UM CONTEXTO DE PEDIDO OPCIONAL.UM PEDIDO CAUSA UM 
SERVIÇO A SER REALIKZADO A UM CLIENTE E RESULTA NA EXECUÇÃO DO PÉDIDO 
RETORNADA PARA O CLIENTE.SE UMA CONDIÇÃO ANORMAL OCORRER DURANTE A 
EXECUÇÃO É RETORNADA. 
INTERFACES PODEM SER UTILIZADAS ESTÁTICA OU DINAMICAMENTE.UMA INTERFACE 
ESTÁ ESTATICAMENTE LIGADA A UM OBJETO QUANDO O NOME DO OBJETO ACESSADO 
É CONHECIDO EM TEMPO DE COMPILAÇÃO.NESTE CASO,O COMPILADOR IDL GERA A 
SAIDA NECESSÁRIA PARA COMPILAR E LINKAR O OBJETO EM TEMPO DE 
COMPILAÇÃO.ALÉM DISTO,CLIENTES QUE PRECISAM DESCOBRIR UM OBJETO EM 
TEMPO DE EXECUÇÃO E CONSTRUIR O PEDIDO DINAMICAMENTE PODEMAR INTERFACE 
DINVOCAÇÃO(DYNAMIC INVOCATION INTERFACE-DII) O DII É SUPORTADO POR UM 
REPOSITORIO DE INTERFACE QUE É DEFINIDO COMO PARTE DO CORBA.ATRAVÉS DO 
ACESSO A INFORMAÇÃO NO REPOSITORIO DE INTERFACES,UM CLIENTE PODE 
RECUPERAR TODA A INFORMAÇÃO NECESSARIA SOBRE A INTERFACE DE UM OBJETO 
PARA CONSTRUIR E FAZER UM PEDIDO EM TEMPO DE EXECUÇÃO.CCOMO OS PEDIDOS 
ESTÁTICOS E DINÂMICOS SÃO EXPRESSOS SEMANTICAMENTE DA MESMA FORMA NÃO 
HAVERÁ DISTINÇÃO ENTRE ESTES DOIS METODOS DE CHAMAR OPERAÇÕES DE 
OBJETOS. 
HERANÇA E DELEGAÇÃO- O CORBA SUPORTA HERANÇA DE INTERFACE,ISTO SIGNIFICA 
QUE UMA INTERFACE PODE SER DERIVADA EM TERMOS DE OUTRA. UMA INTERFACE 
DERIVADA PODE REFINAR QUALQUER TIPO,CONSTANTE E EXECEÇÃO QUE FORAM 
HERDADOS.HERANÇA MULTIPLA É SUPORTADO,NO SENTIDO QUE UMA INTERFACE 
PODE SER DERIVADA DE UM NUMERO DE INTERFACES BÁSICAS.NÃO EXISTE A NOÇÃO 
DE HERANÇA DE IMPLEMENTAÇÃO. 
 
 
 
SERVIÇOS CORBA 
O CORBA inclui especificações de serviços que podem ser exigidos por objetos distribuídos. 
SERVIÇO DE NOMES – ​Oferece atribuição de nomes no CORBA, em particular, realiza o 
mapeamento de nomes em referências de objeto remoto dentro de determinado contexto de atribuição de 
nomes 
SERVIÇO DE NEGÓCIO – ​Enquanto o serviço de nomes permite localizar objetos pelo nome, o 
Tradding Service (serviço de negócio) permite localiza-los pelo atributo; isto é, ele é um serviço de 
diretório. O banco de dados subjacente gerencia um mapeamento dos tipos de serviços e seus atributos 
associados para referências de objeto remoto. 
SERVIÇO DE EVENTO – Definem interfaces que permitem aos objetos de interesse, chamados de 
fornecedores​, comunicarem notificações aos assinantes, chamados de ​consumidores​. Canais de eventos 
são objetos CORBA que podem ser usados para permitir que os fornecedores e os consumidores se 
comuniquem de maneira assíncrona 
SERVIÇO DE NOTIFICAÇÃO – ​Amplia os serviços de evento, com os recursos adicionais. O serviço 
de evento não fornece suporte para filtragem de eventos nem para especificar requisitos de distribuição. 
Sem o uso de filtros, todos os consumidores ligados a um canal têm de receber as mesmas notificações 
que os outros. 
SERVIÇO DE SEGURANÇA – ​Suporta diversos mecanismos de segurança, incluindo autenticação, 
controle de acesso, comunicação segura, auditoria e não-repudio. Em sua forma mais simples, a segurança 
pode ser aplicada de uma maneira transparente para as aplicações. O serviço de segurança permite que os 
usuários adquiram suas credenciais e privilégios individuais, em retorno do fornecimento de dados de 
autenticação, como uma senha. 
SERVIÇO DE CICLO DE VIDA – ​Define convenções para criar, excluir, copiar e mover objetos 
CORBA. Ele especifica como os clientes podem usar fábricas para criar objetos em locais em particular, 
permitindo que seja usado armazenamento persistente.