Objetos Distribuídos e
Invocação Remota
Ênfase em CORBA (Common Object Request Broker
Architecture)
Introdução
Objetos ou aplicativos distribuídos são aqueles aplicativos compostos de
programas que estão em cooperação, executados em vários processos
diferentes. Tais aplicativos precisam executar ( invocar ) operações em outros processos,
frequentemente sendo executados em diferentes computadores. Para se conseguir isso, alguns
modelos de programação foram estendidos para
aplicações em programas distribuídos.
Middleware, o que é?
Do ponto de vista etimológico, middle em inglês significa meio e o sufixo ware é
usado para denotar conjunto ou para transformar a palavra na forma coletiva.
Desta forma, em uma tradução simplificada, middleware denota as tecnologias
intermediárias.
O termo Middleware é usado para agrupar todas as tecnologias em software que
estão entre a aplicação final e os fornecedores de dados para esta aplicação final.
Assim, uma solução de Middleware fica entre a aplicação que o usuário enxerga e
as fontes de informações. A solução de Middleware intermedia a interação entre a
aplicação final e as fontes de informações.
Estas fontes de informações podem ou não estar na mesma máquina do servidor
de aplicações, podendo inclusive, estar fora do ambiente físico desta máquina.
Além disso, as fontes de informações podem estar em plataformas diferentes
com sistemas operacionais diferentes.
Porque é necessário?
Porque precisamos de uma infraestrutura capaz de fornecer para as aplicações
caminhos para interagir com as várias plataformas, sistemas e fontes de dados.
Para integração em ambientes heterogêneos e distribuídos, são necessárias
camadas de software que possibilitam:
•Comunicação entre plataformas e aplicações;
•Uso de protocolos bem definidos e abertos;
•Ser utilizadas em múltiplas plataformas;
•Manter separação de camadas para segurança e portabilidade;
•Recuperar dados e consolidar a partir de múltiplas fontes;
•Fornecer acesso a tecnologias distintas.
Camadas de Middleware
Objetos Distribuídos
Um sistema de objetos distribuídos é aquele que permite a operação com objetos remotos. Dessa
forma é possível, a partir de uma aplicação cliente orientada a objetos, obter uma referência para um
objeto que oferece o serviço desejado e, através dessa referência, invocar métodos desse objeto,
mesmo que a instância desse objeto esteja em uma máquina diferente daquela do objeto cliente.
Na plataforma Java, dois mecanismos são oferecidos para o desenvolvimento de aplicações usando o
conceito de objetos distribuídos: Java RMI e Java IDL. RMI (invocação remota de métodos) é um
mecanismo para desenvolver aplicações com objetos distribuídos que opera exclusivamente com
objetos Java. Java IDL utiliza a arquitetura padrão CORBA para integração de aplicações Java a
aplicações desenvolvidas em outras linguagens.
RPC
O RPC (Remote Procedure Call) define um protocolo para execução remota de
procedures em computadores ligados em rede. O protocolo RPC pode ser
implementado sobre diferentes protocolos de transporte. Não cabe ao RPC
especificar como a mensagem é enviada de um processo para outro, mas
somente especificá-la e interpretá-la. A sua implementação depende,
portanto, de sobre qual protocolo de transporte vai operar.
Uma mensagem RPC tem três campos inteiros:
•Remote Program Number;
•Remote Program Version Number;
•Remote Procedure Number.
Além, é claro, dos parâmetros específicos à chamada. A operação do RPC
pode ser descrita nos seguintes passos:
•Coleta os dados dos parâmetros;
•Forma a mensagem;
•Envia a mensagem;
•Espera a resposta;
•Devolve a resposta através dos parâmetros.
RPC
Tipos de RPC
•CORBA — padrão RPC independente de plataforma
•Sun RPC — RPC para as plataformas Unix e Linux
•DCOM — RPC para Windows
•RMI — RPC para Java
•SOAP — padrão RPC para web service
•JRES - Java Remote Execution Service é um protocolo RPC que usa um
mecanismo de codificação estilo SSL para codificar suas chamadas e HTTP
puro como mecanismo de transporte.
CORBA
CORBA, da sigla Common Object Request Broker Architecture, é a especificação
de um Middleware para comunicação entre objetos distribuídos desenvolvidos
utilizando linguagens heterogêneas (ou homogêneas) que tem por objetivo a
interoperabilidade entre diferentes sistemas computacionais e linguagens de
programação através de ORB’s, que são estruturas que permitem que os
programadores façam chamadas de um computador a outro através de uma
rede. O CORBA é definido e padronizado pela OMG.
Onde e quando surgiu?
OMG – Object Management Group
•Organização sem fins lucrativos com sede nos EUA e
representações em vários países;
•Fundada em abril de 1989;
•Mais de 800 membros;
•Dedicada à criação e popularização de padrões industriais de
orientação a objetos para integração de aplicações, por exemplo:
•CORBA;
•UML;
Versões CORBA
•CORBA 1.0 (October 1991)
•CORBA 1.1 (February 1992)
•CORBA 1.2 (December 1993)
•CORBA 2.0 (August 1996)
•CORBA 2.1 (August 1997)
•CORBA 2.2 (February 1998)
•CORBA 2.3 (June 1999)
•CORBA 2.4 (October 2000)
•CORBA 2.5 (September 2001)
•CORBA 2.6 (December 2001)
•CORBA 3.0 (July 2002)
•CORBA 3.0.1 (November 2002)
•CORBA 3.0.2 (December 2002)
Necessidade...
•Oferecer suporte para requisições de objetos em ambientes distribuídos e heterogêneos de forma
transparente para usuários e programadores de aplicações
•Facilitar a integração de novos componentes com componentes legados
•Padrão aberto e de livre acesso
•Baseado em amplo consenso na indústria
•Necessidade de compartilhamento de informações entre empresas e usuários em geral promovendo
a integração de hardware e software de plataformas diversas de forma a resolver problemas presentes
e futuros;
Funcionamento...
Etapa 1
O componente fundamental para o CORBA é o ORB que tem a tarefa de
facilitar a comunicação dos objetos.
Provendo o IOR (Interoperable Object Reference), o ORB consegue localizar
os objetos destinos e transmitir informação para ou das invocações de
métodos remotos.
A interface para objetos CORBA é especificado pela Interface Definition
Language (IDL). Um compilador traduz a definição IDL em uma linguagem de
programação (C++,Java) gerando IDL Stubs e skeletons que provêm
respectivamente um framework para o lado do cliente e um proxy para o lado
do servidor.
Funcionamento...
Etapa 2
Requisições e respostas entre objetos são entregues através de um formato
padrão definido pelo IIOP(Internet Inter-ORB Protocol).
Funcionamento...
Etapa 3
O Dynamic Invocation Interface (DII) e o Dynamic Skeleton Interface (DSI)
permitem que os objetos sejam criados sem um conhecimento prévio da
interface IDL.
Funcionamento...
Etapa 4
Requisições são empacotadas em um formato de plataforma independente,
através do cliente stub (ou no DII) e desempacotadas no lado servidor em um
formato especifico definido pelo IDL skeleton (ou no DSI) e pelo objeto
adaptador, que serve como um mediador entre a implementação do objeto , o
servidor, e o seu ORB, através disso desacoplando o código usuário do
processo ORB.
Funcionamento...
Etapa 5
Vantagem...
Diferente da RMI, CORBA é independente da linguagem, de modo que
aplicações escritas em linguagens de programação diferentes podem operar
entre si pelo acesso a um núcleo CORBA comum.
Desvantagem...
Corba embasou muitas das atuais tecnologias, mas seu uso não se tornou
popular devido à complexidade da utilização de IDL (linguagem de definição
das interfaces dos objetos distribuídos), além de exposição em fina
granularidade dos objetos, o que dificulta a reutilização.
Onde foi usada a arquitetura CORBA?
•ChorusORB (Sun)
•Component Broker/DSOM (IBM)
•ILU (Xerox Parc)
•Netscape Internet Service Broker (Netscape)
•Object Director (Fujitsu)
•omniORB2 (AT&T Laboratories)
•ORB Plus (HP)
•RPC-ORB (Nortel)
•VisiBroker (Borland)
Referências
•http://penta.ufrgs.br/rc952/trab1/rpc.html
•http://pt.wikipedia.org/wiki/Chamada_de_procedimento_remoto
•http://www.dca.fee.unicamp.br/courses/PooJava/objdist/index.html
•http://www.cin.ufpe.br/~locb/SemRedes/Semin%E1rio_de_redes_e_sistemas_distribu
%EDdos.pptx
•http://www.4linux.com.br/o-que-e-middleware
•http://www.inf.ufrgs.br/~johann/sisop2/GVGOgrupo2.htm
•http://www.omg.org/gettingstarted/history_of_corba.htm
•http://www.timaster.com.br/revista/artigos/main_artigo.asp?codigo=1123&pag=2

Objetos distribuídos e invocação remota - CORBA

  • 1.
    Objetos Distribuídos e InvocaçãoRemota Ênfase em CORBA (Common Object Request Broker Architecture)
  • 2.
    Introdução Objetos ou aplicativosdistribuídos são aqueles aplicativos compostos de programas que estão em cooperação, executados em vários processos diferentes. Tais aplicativos precisam executar ( invocar ) operações em outros processos, frequentemente sendo executados em diferentes computadores. Para se conseguir isso, alguns modelos de programação foram estendidos para aplicações em programas distribuídos.
  • 4.
    Middleware, o queé? Do ponto de vista etimológico, middle em inglês significa meio e o sufixo ware é usado para denotar conjunto ou para transformar a palavra na forma coletiva. Desta forma, em uma tradução simplificada, middleware denota as tecnologias intermediárias. O termo Middleware é usado para agrupar todas as tecnologias em software que estão entre a aplicação final e os fornecedores de dados para esta aplicação final. Assim, uma solução de Middleware fica entre a aplicação que o usuário enxerga e as fontes de informações. A solução de Middleware intermedia a interação entre a aplicação final e as fontes de informações. Estas fontes de informações podem ou não estar na mesma máquina do servidor de aplicações, podendo inclusive, estar fora do ambiente físico desta máquina. Além disso, as fontes de informações podem estar em plataformas diferentes com sistemas operacionais diferentes.
  • 5.
    Porque é necessário? Porqueprecisamos de uma infraestrutura capaz de fornecer para as aplicações caminhos para interagir com as várias plataformas, sistemas e fontes de dados. Para integração em ambientes heterogêneos e distribuídos, são necessárias camadas de software que possibilitam: •Comunicação entre plataformas e aplicações; •Uso de protocolos bem definidos e abertos; •Ser utilizadas em múltiplas plataformas; •Manter separação de camadas para segurança e portabilidade; •Recuperar dados e consolidar a partir de múltiplas fontes; •Fornecer acesso a tecnologias distintas.
  • 7.
  • 8.
    Objetos Distribuídos Um sistemade objetos distribuídos é aquele que permite a operação com objetos remotos. Dessa forma é possível, a partir de uma aplicação cliente orientada a objetos, obter uma referência para um objeto que oferece o serviço desejado e, através dessa referência, invocar métodos desse objeto, mesmo que a instância desse objeto esteja em uma máquina diferente daquela do objeto cliente. Na plataforma Java, dois mecanismos são oferecidos para o desenvolvimento de aplicações usando o conceito de objetos distribuídos: Java RMI e Java IDL. RMI (invocação remota de métodos) é um mecanismo para desenvolver aplicações com objetos distribuídos que opera exclusivamente com objetos Java. Java IDL utiliza a arquitetura padrão CORBA para integração de aplicações Java a aplicações desenvolvidas em outras linguagens.
  • 9.
    RPC O RPC (RemoteProcedure Call) define um protocolo para execução remota de procedures em computadores ligados em rede. O protocolo RPC pode ser implementado sobre diferentes protocolos de transporte. Não cabe ao RPC especificar como a mensagem é enviada de um processo para outro, mas somente especificá-la e interpretá-la. A sua implementação depende, portanto, de sobre qual protocolo de transporte vai operar.
  • 10.
    Uma mensagem RPCtem três campos inteiros: •Remote Program Number; •Remote Program Version Number; •Remote Procedure Number. Além, é claro, dos parâmetros específicos à chamada. A operação do RPC pode ser descrita nos seguintes passos: •Coleta os dados dos parâmetros; •Forma a mensagem; •Envia a mensagem; •Espera a resposta; •Devolve a resposta através dos parâmetros. RPC
  • 12.
    Tipos de RPC •CORBA— padrão RPC independente de plataforma •Sun RPC — RPC para as plataformas Unix e Linux •DCOM — RPC para Windows •RMI — RPC para Java •SOAP — padrão RPC para web service •JRES - Java Remote Execution Service é um protocolo RPC que usa um mecanismo de codificação estilo SSL para codificar suas chamadas e HTTP puro como mecanismo de transporte.
  • 13.
    CORBA CORBA, da siglaCommon Object Request Broker Architecture, é a especificação de um Middleware para comunicação entre objetos distribuídos desenvolvidos utilizando linguagens heterogêneas (ou homogêneas) que tem por objetivo a interoperabilidade entre diferentes sistemas computacionais e linguagens de programação através de ORB’s, que são estruturas que permitem que os programadores façam chamadas de um computador a outro através de uma rede. O CORBA é definido e padronizado pela OMG.
  • 14.
    Onde e quandosurgiu? OMG – Object Management Group •Organização sem fins lucrativos com sede nos EUA e representações em vários países; •Fundada em abril de 1989; •Mais de 800 membros; •Dedicada à criação e popularização de padrões industriais de orientação a objetos para integração de aplicações, por exemplo: •CORBA; •UML;
  • 15.
    Versões CORBA •CORBA 1.0(October 1991) •CORBA 1.1 (February 1992) •CORBA 1.2 (December 1993) •CORBA 2.0 (August 1996) •CORBA 2.1 (August 1997) •CORBA 2.2 (February 1998) •CORBA 2.3 (June 1999) •CORBA 2.4 (October 2000) •CORBA 2.5 (September 2001) •CORBA 2.6 (December 2001) •CORBA 3.0 (July 2002) •CORBA 3.0.1 (November 2002) •CORBA 3.0.2 (December 2002)
  • 16.
    Necessidade... •Oferecer suporte pararequisições de objetos em ambientes distribuídos e heterogêneos de forma transparente para usuários e programadores de aplicações •Facilitar a integração de novos componentes com componentes legados •Padrão aberto e de livre acesso •Baseado em amplo consenso na indústria •Necessidade de compartilhamento de informações entre empresas e usuários em geral promovendo a integração de hardware e software de plataformas diversas de forma a resolver problemas presentes e futuros;
  • 17.
    Funcionamento... Etapa 1 O componentefundamental para o CORBA é o ORB que tem a tarefa de facilitar a comunicação dos objetos. Provendo o IOR (Interoperable Object Reference), o ORB consegue localizar os objetos destinos e transmitir informação para ou das invocações de métodos remotos.
  • 18.
    A interface paraobjetos CORBA é especificado pela Interface Definition Language (IDL). Um compilador traduz a definição IDL em uma linguagem de programação (C++,Java) gerando IDL Stubs e skeletons que provêm respectivamente um framework para o lado do cliente e um proxy para o lado do servidor. Funcionamento... Etapa 2
  • 19.
    Requisições e respostasentre objetos são entregues através de um formato padrão definido pelo IIOP(Internet Inter-ORB Protocol). Funcionamento... Etapa 3
  • 20.
    O Dynamic InvocationInterface (DII) e o Dynamic Skeleton Interface (DSI) permitem que os objetos sejam criados sem um conhecimento prévio da interface IDL. Funcionamento... Etapa 4
  • 21.
    Requisições são empacotadasem um formato de plataforma independente, através do cliente stub (ou no DII) e desempacotadas no lado servidor em um formato especifico definido pelo IDL skeleton (ou no DSI) e pelo objeto adaptador, que serve como um mediador entre a implementação do objeto , o servidor, e o seu ORB, através disso desacoplando o código usuário do processo ORB. Funcionamento... Etapa 5
  • 23.
    Vantagem... Diferente da RMI,CORBA é independente da linguagem, de modo que aplicações escritas em linguagens de programação diferentes podem operar entre si pelo acesso a um núcleo CORBA comum.
  • 24.
    Desvantagem... Corba embasou muitasdas atuais tecnologias, mas seu uso não se tornou popular devido à complexidade da utilização de IDL (linguagem de definição das interfaces dos objetos distribuídos), além de exposição em fina granularidade dos objetos, o que dificulta a reutilização.
  • 25.
    Onde foi usadaa arquitetura CORBA? •ChorusORB (Sun) •Component Broker/DSOM (IBM) •ILU (Xerox Parc) •Netscape Internet Service Broker (Netscape) •Object Director (Fujitsu) •omniORB2 (AT&T Laboratories) •ORB Plus (HP) •RPC-ORB (Nortel) •VisiBroker (Borland)
  • 26.