CORBA Grupo: Sergio Cosme N. C. Filho Tatiana Cardia Petra.

Apresentação em tema: "CORBA Grupo: Sergio Cosme N. C. Filho Tatiana Cardia Petra."— Transcrição da apresentação:

1 CORBA Grupo: Sergio Cosme N. C. Filho Tatiana Cardia Petra

2 O que é CORBA? CORBA é o acrônimo de Common Object Request Broker Architecture. Uma especificação aberta definida pela OMG, de uma arquitetura e infra- estrutura que possibilita a comunicação e interoperabilidade entre aplicações OO distribuídas em uma rede (intranet ou internet).

3 Interoperabilidade Esta interoperabilidade permite que um programa baseado em CORBA escrito em qualquer linguagem de programação rodando em qualquer tipo de computador com qualquer Sistema Operacional interaja através da rede com outra aplicação também baseada em CORBA escrita em outra linguagem de programação rodando em outro tipo de computador com outro Sistema Operacional

4 Como é possível essa Interoperabilidade? Existem duas partes chave na especificação: A IDL (Interface Definition Language) E o protocolo padronizado IIOP

5 IDL – Interface Definition Language

6 É a parte sintática do contrato estabelecido entre o servidor e o cliente que o invoca. É independente da linguagem de programação.

7 IDL – Interface Definition Language Visão simplificada da requisição passando do cliente para a implementação do objeto:

8 IDL – Interface Definition Language Qualquer cliente que quiser invocar uma operação de um objeto, tem que usar esta interface para especificar a operação e enviar seus parâmetros. Quando a requisição atinge o objeto alvo, a mesma interface é usada para receber os parâmetros e executar a operação.

9 IDL – Interface Definition Language Depois que a operação é executada, a interface é usada para enviar os resultados de volta. E usada também no cliente para receber os resultados.

10 IDL – Interface Definition Language Essa separação entre a interface e a implementação é a essência do CORBA, é como ele possibilita a interoperabilidade. O cliente acessa os objetos apenas através dessa interface, invocando apenas as operações nela definidas.

11 IDL – Exemplo simples de sintaxe Esta é a interface para um objeto que calcula a taxa de juros numa loja. O tipo de objeto é taxadevenda, e ele possui uma operação: calcular_taxa. interface taxadevenda { float calcular_taxa(in float qtd_taxada); } O objeto recebe um parâmetro de entrada, qtd_taxada, que é do tipo float. E retorna um valor também float.

12 IDL – Como integrar com minha LP? OMG definiu mapeamentos da IDL para as maiores linguagens de programação: C, C++, Java, Smalltalk, COBOL, Ada, Lisp, PL/1, Python, e IDLscript. Implementações de mapeamentos para outras linguagens são suportados.

13 IDL – Como integrar com minha LP? Um mapeamento relaciona um tipo de variável da linguagem para cada tipo de variável IDL, e traduz o formato de operação IDL para o formato da linguagem. Também mapeia convenções de especificações de uso de memória, e outras convenções que permitam a infra-estrtura CORBA prover serviços para a implementação do objeto.

14 Como funciona a invocação remota?

15 Comunicação entre ORBs através do protocolo IIOP para possibilitar Interoperabilidade entre objetos na rede.

16 Como funciona a invocação remota? Uma vez que o cliente sabe qual operação ele quer invocar, o “client stub” e o “object skeleton” são gerados para a mesma IDL. “client stub” e “skeleton stub” são como proxies para o cliente e o objeto respectivamente.

17 Como funciona a invocação remota? O ORB cliente e o ORB do Objeto têm que usar um protocolo comum de comunicação (IIOP). O cliente não sabe a localização real do objeto, o que garante a transparência de localização, um principio que simplifica o desenho de objetos distribuídos.

18 ORB – Object Request Broker

19 ORB – Uma visão mais detalhada

20 ORB – Object Request Broker O ORB é quem cuida de todos os detalhes envolvendo a passagem de uma requisição do cliente para o objeto, e também da passagem da resposta do objeto para o cliente. É ele quem guarda o IR (Interface Repository), uma base de dados contendo as definições de interfaces IDL.

21 ORB – Object Request Broker O ORB pode rodar em apenas uma máquina ou pode estar distribuído em várias máquinas na rede. Em caso de pequenas aplicações é recomendado que ele fique concentrado em apenas uma máquina por questão de performance e simplicidade.

22 ORB – do lado do cliente Ele provê definições de interfaces a partir do IR, e constrói as invocações para serem usadas pela DII (Dynamic Invocation Interface). Ele também converte as referências dos objetos entre session e string, e converte formatos URL corbaloc e referências corbaname para referências session.

23 ORB – do lado do servidor Embora o CORBA permita que o cliente veja toda referência de objeto válida correspondendo a uma instância na memória, na prática a instância não está na memória. Para conservar os recursos do servidor, o ORB desativa os objetos que não estão sendo usados no momento, e reativa-os quando chega uma requisição.

24 Alguns componentes do ORB

25 DII – Dynamic Invocation Interface

26 Invocações via DII são diferentes de invocações via stub, da mesma forma que scripts diferem de programas. As invocações DII são interpretadas em tempo de execução, e não compiladas previamente.

27 DII – Dynamic Invocation Interface Usando DII, um cliente pode invocar operações de um novo tipo de objeto recém descoberto por ele. Para isso o programador do cliente tem de escrever um código que retorne a definição da interface IDL a partir do IR, e construir uma invocação usando interfaces definidas no ORB. A invocação por si só já é um objeto CORBA com sua própria referência.

28 ORB Interface

29 Provê acesso a todos os serviços do ORB, exceto: Invocações do cliente (que passam pelo DII ou pelos stubs) Ativações e chamadas de objetos (que passam pelo POA)

30 ORB Interface Os serviços que ela provê acesso são: Acesso ao IR, e construção das invocações DII. Operações de referências de objetos, como conversões de formatos, criação de referências duplicadas, e armazenamento. dentre outros serviços de funcionamento do CORBA...

31 POA – Portable Object Adapter

32 É a peça do ORB que gerencia os recursos do lado do servidor. Desativando os objects servants quando eles não estão em uso, e reativando-os quando eles são novamente necessários. Objects Servants são os recursos escalonados para a operação do objeto.

33 As diferentes implementações

34 Comerciais Visibroker – Inprise Visibroker Orbix - Iona Orbix CorbaPlus - Expersoft CorbaPlus OAK - Camros Corporation OAK RCP-ORB - Nortel RCP-ORB DAIS - PeerLogic DAIS

35 Gratuitas JavaORB Engine Room CORBA Jonathan ORBit DynaOrb Arachne TAO fnOrb MICO OmniOrb JacORB Electra DOME

36 Gratuitas para uso não comercial Voyager - ObjectSpace Voyager ORBacus - Object Oriented Concepts ORBacus

37 Casos de Sucesso Utilizando CORBA

38 Casos de Sucesso - PACS-HC Empresa: Instituto do Coração do Hospital das Clínicas da FMUSPInstituto do Coração do Hospital das Clínicas da FMUSP Área de Atuação: Saúde Broker utilizado: Visibroker (Inprise) Projeto: PACS-HC

39 Casos de Sucesso - PACS-HC Ambiente distribuído para transmissão, arquivamento, processamento e visualização de imagens médicas, integrando-as aos sistemas de informações do Hospital das Clínicas (HC) da Faculdade de Medicina da USP e do Instituto do Coração (InCor). Tendo que integrar informações de sistemas distribuídos e heterogêneos, o Instituto do Coração escolheu a tecnologia CORBA como base para a construção deste sistema.

40 Casos de Sucesso - OpenComm Empresa: OpenComm do BrasilOpenComm do Brasil Área de Atuação: Sistemas para Telecomunicações Broker utilizado: OmniORB2r Projeto: A Plataforma MultiServiços - Open Telephony Server O sistema OpenAgent

41 Casos de Sucesso - OpenComm Ambos os produtos foram desenvolvidos em C++, utilizando sempre que possível produtos OpenSource, como o próprio OmniORB. Como resultado, a utilização de CORBA nestes sistemas apresentou um desempenho excelente, comportamento estável, além de permitir a integração de software distribuído entre os diferentes ambientes que faziam parte do projeto (Linux, Solaris, Windows).

42 Casos de Sucesso Muitos outros casos de sucesso foram encontrados nas áreas de: educação, pesquisa e desenvolvimento empresas de computação internet etc...

43 Comparação com o Eiffel

44 CORBA x Eiffel Tendo em vista que o CORBA não é uma linguagem de programação como o Eiffel, e considerando que os dois pontos chaves do Eiffel são: Desenho por Contrato Tratamento de Exceções Apresentaremos como o CORBA trabalha com esses dois pontos.

45 CORBA x Eiffel – Desenho por Contrato O Eiffel trabalha com o conceito de PRÉ e PÓS Condições. Um contrato é basicamente definido pelo estado que objeto deve possuir antes e depois da execução de uma operação. O CORBA trabalha com o conceito de IDL. Aqui o contrato é definido através da provisão de algumas operações para o cliente.

46 CORBA x Eiffel – Tratamento de Exceções O conceito de exceção no Eiffel, como em todas as linguagens de programação modernas, representa uma quebra de contrato, ou um comportamento indesejado de algum objeto no sistema. O Eiffel trata exceções, tentando executar o método que falhou novamente, ou criando um “pânico organizado”.

47 CORBA x Eiffel – Tratamento de Exceções Em CORBA, o conceito mais parecido com o tratamento de exceções, é o de Tolerância a Falhas. Uma falha em CORBA acontece em geral devido a algum problema de hardware, ou da rede.

48 CORBA x Eiffel – Tratamento de Exceções Não existe uma forma padronizada de trabalhar com Tolerância a Falhas em CORBA. Existem muitas propostas formais e com sucesso, mas nenhuma padrão. Em geral, as propostas trabalham com redundância e replicação de dados.

49 Conclusões

50 É um padrão diretamente suportado por empresas em todo o mundo. Não é necessário ficar preso a determinados fornecedores, plataformas ou produtos, como acontece quando são escolhidas soluções proprietárias.

51 Conclusões É possível ter aplicações completamente distribuídas, potencialmente com cada pedaço de software sendo executado em qualquer parte da rede e em qualquer plataforma, sem que: o usuário perceba que isto está acontecendo e sem que o desenvolvedor precise se preocupar em criar soluções que resolvam os problemas de interoperabilidade entre os diferentes pedaços da aplicação.

52 Conclusões Tendo em vista que o CORBA é uma plataforma confiável e com sucesso reconhecido, concluímos que ela engrandeça em muito o desenho de aplicações OO, já que não é necessário se preocupar com limitações de tecnologia, podendo-se desenhar uma aplicação de forma ideal, sem precisar fazer gatilhos e/ou concessões.

53 Bibliografia Grupo de usuários CORBA - www.corba.org.br www.corba.org.br OMG - www.omg.orgwww.omg.org http://www.ic.unicamp.br/~asterio/ftco rba/slide01.htm