CORBA

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. IDL – Interface Definition Language • É 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. Como funciona a invocação remota? 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. DII – Dynamic Invocation Interface • 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. ORB Interface • 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. POA – Portable Object Adapter • É 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 • Orbix - Iona • CorbaPlus - Expersoft • OAK - Camros Corporation • RCP-ORB - Nortel • DAIS - PeerLogic

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 • ORBacus - Object Oriented Concepts

37. Casos de Sucesso Utilizando CORBA

38. Casos de Sucesso - PACS-HC • Empresa: Instituto 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 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. Conclusões • É 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.