CORBA (Common Object Request Broker Architecture)

CORBA

(Common Object Request Broker Architecture)

Sistemas Distribuídos

Desafios para a realização de sistemas Distribuídos

Exemplos de Sistemas Distribuídos CORBA

Evolução Histórica

OMA (Object Management Architecture) Modelo de referência OMA

CORBA RMI

Arquitectura CORBA

Linguagem de especificação de interfaces Referências para objectos remotos

Operações sobre referências para objectos Serviços CORBA

serviço de nomes serviço de trading serviço de eventos

Sistemas Distribuídos

Um sistema distribuído é aquele onde componentes localizados em computadores ligados em rede comunicam e coordenam as suas acções apenas através da troca de mensagens.

O conceito é semelhante a "Rede de Computadores". A diferença está no uso transparente da rede.

Numa rede de computadores o utilizador usa explicitamente as aplicações em cada máquina.

Um sistema distribuído é um caso especial de uma rede de computadores, onde o software dá um nível elevado de coesão e transparência.

Middleware

Camada de software que fornece um abstracção para a programação de aplicações em rede.

Desafios para a realização de sistemas distribuídos

Heterogeneidade

Existe heterogeneidade a vários níveis num sistema distribuído: • Rede • Hardware • Sistema Operativo • Linguagem de programação • Diferentes programadores

A utilização de protocolos normalizados nos vários níveis de abstracção permite lidar com a heterogeneidade.

A camada de software designada de Middleware fornece uma abstracção para a programação de aplicações em rede, mascarando a heterogeneidade nos vários níveis do sistema. Considerando o modelo de referência OSI, a camada Middleware inclui funcionalidades do nível Sessão, nível Apresentação e do nível Aplicação.

Abertura

Um sistema deve ser extensível. Um sistema aberto:

• usa mecanismos de comunicação uniforme e publicita interfaces para acesso a recursos partilhados;

• permite a integração de componentes de software e hardware de várias origens.

Desafios para a realização de sistemas distribuídos (2)

A presença de múltiplos utilizadores num sistema distribuído pode originar pedidos concorrentes aos recursos.

É necessário sincronizar o acesso a dados partilhados para manter a coerência (ex. semáforos, etc.)

Escalabilidade

O custo de adicionar um utilizador deve ser constante em termos de recursos adicionais. O algoritmo para aceder a dados partilhados deve evitar a concentração de pedidos num único objecto.

Para melhorar a escalabilidade de aplicações pode-se replicar dados.

Tratamento de falhas

Qualquer processo, computador ou rede pode falhar numa rede.

Cada componente deve estar preparado detectar falhas e eventualmente mascarar falhas (ex. replicação activa).

Segurança

Um sistema distribuído deve assegurar a segurança da informação na rede utilizando métodos de cifra.

Desafios para a realização de sistemas distribuídos (3)

Define-se como o esconder a separação dos componentes e da sua distribuição num sistema distribuído do utilizador e do programador de aplicações, de maneira a visualizar o sistema como um todo em vez de uma colecção de componentes independentes.

A transparência pode-se definir a vários níveis:

• acesso. Permitir o acesso a recursos locais e remotos utilizando as mesmas operações;

• localização. Permitir o acesso a recursos sem ter conhecimento da sua localização;

• concorrência. Permitir que vários processos operem concorrentemente sobre recursos partilhados sem que haja interferência entre eles;

• replicação. Permitir a utilização de múltiplas instâncias de recursos para melhorar a fiabilidade e o desempenho sem que os utilizadores ou programadores tenham conhecimento;

• falha. Permitir o esconder de falhas de hardware ou software (ex. reenvio de pedidos para outro servidor);

• de mobilidade. Permitir a mobilidade de recursos e clientes num sistema sem afectar o funcionamento dos programas;

• de desempenho. Permitir a reconfiguração de um sistema para melhorar o desempenho com a variação da carga;

• de escalabilidade. Permitir a expansibilidade da escala de um sistema ou aplicação sem modificar a estrutura do sistema ou os algoritmos das aplicações.

Exemplos de Sistemas Distribuídos

Existem três grandes arquitecturas de sistemas distribuídos que satisfazem parcialmente os desafios enumerados.

Todas se baseiam em modelos orientados a objectos, onde as interfaces são declaradas por uma IDL (Interface Definition Language) específica.

Todas oferecem transparência de acesso e localização.

Várias ferramentas de desenvolvimento para qualquer destas arquitecturas.

CORBA (OMG)

• Várias linguagens de programação (C, C++, Java, Smalltalk, COBOL, Lisp, Python)

• Corre sobre qualquer arquitectura

• Comunicação: IIOP mas suporta RMI-IIOP, COM, SOAP

Enterprise Javabeans (Sun)

• Linguagem de programação: Java

• Corre em qualquer arquitectura que suporte uma máquina virtual Java

• Comunicação: IIOP/RMI mas suporta RMI-IIOP, SOAP

COM+ (Microsoft)

• Só corre sobre sistemas operativos Microsoft, existindo apenas implementações da Microsoft

• Várias linguagens de programação

• Comunicação: DCE/SOAP mas suporta IIOP, SOAP

CORBA

A arquitectura CORBA está a ser desenvolvida pela OMG (Object Management Group).

www.omg.org

A OMG foi fundada em 1989 por oito membros fundadores (3Com, American Airlines, Canon, Data General, HP, Philips, Sun e Unisys).

No ano 2000 tinha mais de 800 membros, incluindo IBM e Microsoft (apenas como observadora).

Evolução histórica

A primeira especificação da arquitectura CORBA (1.0) foi proposta em 1991, tendo introduzido o acrónimo ORB (Object Request Broker).

Em 1996 foi proposta a segunda especificação da arquitectura (CORBA 2.0). A grande evolução foi a definição de protocolos para permitir a comunicação entre ORBs.

Desde 1996 várias versões intermédias da norma têm sido lançadas. A mais recente foi a norma CORBA 2.6.1, em Maio do ano 2002. A evolução visou a interoperação da arquitectura CORBA com outros sistemas distribuídos, suporte de interacção assíncrona entre objectos, mobilidade de objectos, interacção com grupos de objectos, interacção em tempo real, etc.

OMA (Object Management Architecture)

O modelo de objectos adoptado pela OMG para a arquitectura CORBA é descrito na OMA (Object Management Architecture).

Os objectos oferecem uma colecção de operações definida pelo tipo de interface.

Podem-se definir relações de herança entre tipos de interfaces de objectos. Todas as interfaces herdam do tipo abstracto Object.

Os objectos são acedidos através de referências para objectos, que identificam de uma forma uniforme objectos locais ou objectos remotos.

Cada aplicação é realizada por um ou mais objectos "servidores".

Modelo de referência OMA

O modelo de referência OMA identifica três categorias de objectos presentes num sistema distribuído CORBA:

Naming, Trader

Eventos, Notificação Transacções

Segurança … Agentes Comércio Electrónico Serviços CORBA Facilidades CORBA Facilidades verticais Objectos de Aplicações Saúde _… Telecomunicações (p/ Operadoras) Facilidades horizontais … Tempo

Object Request Broker (ORB)

Os objectos dos serviços CORBA e das facilidades CORBA fornecem um conjunto de funcionalidades normalizadas para os objectos de aplicação, simplificando o desenvolvimento destas.

Os serviços CORBA definem interfaces genéricas, de uso comum em aplicações distribuídas:

• Naming e trader: localização de objectos baseados no nome ou em conjuntos de propriedades;

• Eventos e notificação: troca assíncrona de mensagens;

Modelo de referência OMA (2)

As facilidades horizontais CORBA definem interfaces orientadas para grupos de aplicações específicos, de uso mais restrito:

• Agentes: aplicações baseadas em agentes móveis;

• etc.

As facilidades verticais CORBA definem interfaces orientadas para aplicações específicas:

• Comércio electrónico;

• Administração de redes de operadoras de telecomunicações;

• etc.

Os objectos de aplicação têm interfaces proprietárias, podendo usar os serviços e facilidades disponíveis no sistema distribuído para realizar as suas funções.

O ORB interliga os vários objectos no sistema, ajudando os clientes a invocar métodos noutro objecto. Ele localiza um objecto (activa-o se necessário), e trata da troca de mensagens entre o cliente e o objecto.

CORBA RMI

Um dos principais elementos normalizados na arquitectura CORBA é a invocação remota de procedimentos.

Esta especificação do CORBA RMI tem quatro componentes principais:

• A arquitectura do ORB;

• A linguagem de especificação de interfaces (IDL);

• A representação externa (serialização) dos dados (definida no GIOP - General Inter-ORB Protocol);

• formato das referências para objectos.

Para além disso, a especificação do CORBA RMI define a utilização dos serviços CORBA na interacção entre objectos de aplicação.

Arquitectura CORBA

A arquitectura CORBA define como é realizada a funcionalidade de ORB num sistema real.

A figura representa os componentes principais da arquitectura CORBA Repositório Implementações Repositório Interfaces programa cliente stub de A núcleo ORB cliente núcleo ORB adaptador objectos servidor A skeleton servidor Pedido Resposta ou invocação dinâmica ou skeleton dinâmico

Em relação ao modelo de RPC estudado anteriormente, a arquitectura CORBA acrescenta:

• Adaptador de Objectos

• Repositório de interfaces

• Repositório de implementações

Estes componentes criam a ilusão de transparência oferecida pelo CORBA.

Arquitectura CORBA (2)

Núcleo ORB

Os dois núcleos de ORB cooperantes realizam o protocolo de RPC, que realiza a transmissão de mensagens de pedido e de resposta entre o cliente e o servidor.

Suporta uma semântica de invocação "at-most-once"

No servidor, o núcleo ORB passa para o adaptador de objecto a classe de objecto e a identidade do objecto a invocar.

Para além disso fornece uma interface que inclui:

• operações para arrancar e parar o ORB;

• operações para converter entre referências para objectos e strings;

• operações para criar listas de argumentos para invocações utilizando invocação dinâmicas.

stubs e skeletons

Os stubs e skeletons são classes na linguagem de programação do cliente e do servidor geradas pelo compilador de IDL, que realizam a serialização (marshalling) e a reconstrução (unmarshalling) dos parâmetros de invocação dos pedidos e da resposta do servidor.

Arquitectura CORBA (3)

Adaptador de objectos

O adaptador de objectos tem as seguintes funções:

• cria referências remotas para objectos CORBA;

• despacha cada invocação remota através de um skeleton para o objecto servidor local apropriado;

• activa objectos.

O adaptador de objectos dá a cada objecto CORBA um "nome" de objecto único, que faz parte da referência remota, mantendo uma tabela que associa o "nome" ao "objecto servidor" que o realiza.

O "nome" mantém-se fixo mesmo que o objecto seja desactivado e reactivado.

Cada adaptador de objectos também tem um "nome" único, que também faz parte da referência remota de todos os objectos CORBA geridos localmente.

Os objectos podem ser activados num modo "single-threaded" (apenas uma operação corre sobre o objecto) ou "multi-threaded" (pode haver várias operações a correr sobre o mesmo objecto em paralelo).

Até à norma CORBA 2.1, foi usado adaptador de objectos designado de "Basic Object Adapter" (BOA).

A partir da norma CORBA 2.2, o BOA foi substituído pelo POA (Portable Object Adapter), com uma definição mais completa das interfaces, que torna a realização de aplicações e de "objectos servidores" transportável entre diferentes ORBs.

Arquitectura CORBA (4)

Repositório de implementações

Suporta um modo de registo de objectos passivo no adaptador de objectos, que apenas arranca com os objectos quando são recebidas invocações.

É responsável por activar objectos registados e por localizar servidores que estão a correr.

O repositório de implementações guarda entradas com a estrutura: Nome Adaptador Objectos "pathname" implementação objecto Endereço IP e porto do objecto "servidor" O endereço IP e o nº porto só são preenchidos quando o objecto é activado.

O repositório de implementações permite a replicação de "objectos servidores", ao controlar o número de réplicas de objectos servidores que são arrancados para cada objecto.

Repositório de interfaces

Mantém uma base de dados com todos os tipos de IDLs registados: pode fornecer nomes dos métodos e argumentos de cada método.

O compilador de IDLs atribui para cada tipo de IDL um identificador único, passado nas invocações remotas e nas referências para objectos.

Arquitectura CORBA (5)

Invocação dinâmica de interfaces

Utilizando o repositório de interfaces é possível realizar clientes que invocam operações sobre tipos de interfaces desconhecidos na altura da compilação dos clientes.

Não é usado uma stub, mas funções no núcleo do ORB que concatenam os vários argumentos numa mensagem.

Do lado do servidor existe uma funcionalidade semelhante designada de skeleton dinâmico, que constrói a invocação no objecto servidor a partir da informação na mensagem e do repositório de interfaces.

As invocações dinâmicas de interfaces têm a vantagem de poderem ter uma semântica assíncrona:

O cliente envia uma (ou mais) mensagem de pedido de invocação, continuando o processamento local normal até realizar uma invocação explícita de recepção das mensagens de resposta.

Utilizando stubs e skeleton, até à norma CORBA 2.3 apenas foi suportada a invocação síncrona de operações:

O cliente fica bloqueado durante a invocação da operação remota.

A partir da norma CORBA 2.4 já foi introduzida a invocação assíncrona de interfaces, embora a maior parte dos ORBs disponíveis em 2001 ainda não o suporte.

Linguagem de especificação de interfaces (IDL)

A IDL é uma linguagem declarativa independente de qualquer linguagem de programação, para especificar interfaces para objectos CORBA.

A sintaxe da IDL é semelhante a C++, embora use palavras-chave diferentes.

Permite a declaração de:

• constantes – para auxiliar a definição de tipos;

• declarações de tipos de dados – para definir parâmetros;

• operações – que definem parâmetros e valores retornados;

• atributos – variáveis de um tipo;

• interfaces – agrupam tipos de dados, atributos e declaração de operações;

• módulos – para dividir o espaço de nomes.

Constantes

As constantes são declaradas usando a palavra-chave "const".

Tipos

A IDL define 15 tipos primitivos de dados que incluem: short (16 bits), long (32 bits), unsigned short, unsigned long, float (32 bits), double (64 bits), char, boolean (TRUE, FALSE), octet (8 bits) e any.

O tipo any pode representar qualquer tipo (primitivo ou estruturado).

Linguagem de especificação de interfaces (IDL) (2)

Podem-se construir tipos de dados estruturados utilizando vários construtores:

• array de tamanho fixo:

typedef tipo nome[20]; typedef tipo nome[20][30];

• array de tamanho variável:

typedef sequence <tipo> nome; typedef sequence <tipo, 20> nome;

• sequência de caracteres delimitada por '\0' (strings de C):

string nome;

typedef string <20> nome;

• estrutura:

struct nome { … };

• tipo enumerado:

enum nome { Const1, …, Constn };

• união (a variável var selecciona o tipo da variável):

union nome switch (var) { case Const1: tipo1 var1; …

case Constn: tipon varn; };

Métodos

A declaração de métodos obedece à forma genérica:

[oneway] <return_type> <nome_método> (parameter1, … , parameterL) [raises (except1, …, exceptN)]

Os parâmetros têm qualificadores in_, out_, inout _que

Linguagem de especificação de interfaces (IDL) (3)

A expressão opcional oneway indica um método com uma semântica "melhor-esforço", onde o cliente não fica bloqueado enquanto o servidor processa o pedido.

Por defeito, todos os métodos são fiáveis com uma semântica "at-most-once".

Para além das excepções geradas pelo ORB por erros na comunicação, a palavra-chave raises permite os métodos terminarem com a geração de uma excepção de utilizador.

Atributos

Tal como as variáveis numa classe em C++ ou Java, os atributos definem variáveis de interfaces.

[readonly] attribute tipo nome;

Interfaces

São declaradas com a palavra-chave 'interface'

Definem o conjunto de operações suportadas por um objecto. Pode-se definir relações de herança entre tipos de interface. Módulos

São declarados com a palavra-chave 'module'

Os módulos permitem separar o espaço de nomes, facilitando a atribuição unívoca de nomes a tipos e a interfaces.

Referências para objectos remotos

A norma CORBA 2.0 especificou o formato de uma referência para um objecto, designada de

Interoperable Object Reference (IOR)

Nome tipo interface IDL

Protocolo e

endereço Chave de objecto Id. Repositório

interfaces IIOP IP porto

nome adaptador

nome objecto O primeiro campo define o nome do tipo de interface do objecto. Caso exista um repositório de interfaces activo, é possível obter a definição da interface.

O segundo campo define o tipo de protocolo de transporte e o endereço. O mais comum é o "Internet Inter-ORB Protocol" (IIOP), onde o endereço inclui o endereço IP e o nº de porto. O terceiro campo identifica o adaptador de objectos no executável e o objecto dentro desse adaptador de objecto.

Esta estrutura pode ser guardada numa sequência de caracteres, podendo ser lida por qualquer realização de ORB.

O IOR pode conter a referência (IP, porto) para um objecto activo, deixando de ser válido quando o processo terminar – IOR transitório

Para objectos activados dinamicamente por invocação definem-se IOR persistentes. O IOR contém a referência para repositório de implementações, permanecendo válido entre várias invocações do objecto.

Operações sobre referências para objectos

O núcleo ORB fornece um conjunto de métodos na interface

CORBA::Object, herdada por todos os objectos.

• is_nil

Testa de a referência não identifica nenhum objecto

• is_a

Testa se dois tipos de interface são compatíveis

• is_equivalent

Testa se duas referências identificam o mesmo objecto.

• duplicate

• release

São usadas em linguagens de programação que não libertam memória automaticamente (ex. C, C++).

A partir do CORBA 2.2, cada ORB mantém contador de procuradores remotos para um objecto. Cada procurador mantém contador de referências para o objecto.

Cliente Servidor objecto 2 proxy 1 OR

Uma cópia de uma referência não incrementa o contador de referências no procurador (ex. nomeInterface_var). Deve ser usado o método duplicate.

Não deve ser usado o delete da linguagem de programação, mas o método release. O delete não actualiza o contador de procuradores no objecto.

Serviços CORBA: serviço de nomes

Realiza a associação entre "nomes" definidos pelo utilizador e referências para objectos.

O espaço de nomes está organizado de uma forma hierárquica, podendo existir vários contextos onde se podem registar interfaces.

Os contextos estão organizados num grafo, com uma raiz, o contexto de nomes inicial.

Contexto nomes inicial

ShapeList

C

D

E

B

Cada ORB tem uma raiz do espaço de nomes diferente. Numa rede de grande escala é possível interligar o serviço de nomes de vários ORB através de ligações de federação (ex.: XX).

P

R

S

T

V

Q

_U

contexto nomes inicial

XX

Serviços CORBA: serviço de nomes (2)

Os nomes usados no serviço de nomes para identificar objectos e contextos têm dois componentes: id e kind

Algumas das operações disponíveis na interface do serviço de nomes (CosNaming::NamingContext) são:

• bind, rebind – registo de nomes;

• unbind – cancelamento de nomes;

• resolve – pesquisa de nomes;

• list – retorna todos os nomes registados num contexto;

• bind_new_context – cria um novo contexto e associa-o a

um novo nome no contexto corrente.

Serviços CORBA: serviço de trading

Realiza um serviço de directórios para objectos CORBA que permite pesquisar objectos através de um conjunto de atributos.

Associa um tipo de serviço (nome) com um conjunto de atributos (par nome-valor) a referências para objectos.

O cliente define um conjunto de equações de pesquisa em função dos atributos para um tipo de serviço.

min Preço && País == "Portugal"

Cada ORB tem um trader local, mas é possível interligar traders de vários ORB através de ligações de federação.

Os registos são feitos no trader local. As pesquisas atravessam as ligações de federação.

A delimitação da pesquisa é feita através de limitação no número de ligações de federação atravessadas.

Serviços CORBA: serviço de eventos

O serviço de eventos suporta um método de comunicação anónimo e assíncrono entre objectos.

Suporta o envio de mensagens de tipo genérico (any) a partir de um ou mais fornecedores para um ou mais consumidores. A comunicação é realizada através da invocação de RPC síncrono sobre os procuradores existentes no canal de eventos.

consumidor fornecedor procurador consumidor notificação procurador fornecedor canal eventos notificação notificação

Há dois modelos de interacção:

• push (empurrar)

1. os consumidores registam uma interface PushConsumer

no canal de eventos;

2. o fornecedor invoca o método "push" sobre o procurador de consumidor. O canal de eventos invoca o mesmo método sobre os consumidores.

• pull (puxar)

1. os fornecedores registam uma interface PullSupplier

no canal de eventos;

2. os consumidores invocam o método "pull" sobre o procurador de fornecedor. O canal de eventos invoca o mesmo método sobre os fornecedores ou usa mensagens recebidas anteriormente.

Podem-se misturar os dois modelos – interacção assíncrona. É possível criar cadeias de canais de eventos, de forma a melhorar a escalabilidade do sistema.

Serviços CORBA: outros serviços

Estende o serviço de eventos, acrescentando mecanismos de filtragem na recepção de eventos e de controlo da qualidade de serviço (por defeito, é do tipo "melhor-esforço").

Serviço de segurança

Suporta quatro funcionalidades principais:

• autenticação de utilizadores e servidores, com geração de credenciais;

• controlo de acesso para objectos CORBA (ACL - Access Control Lists);

• auditoria de invocações remotas de objectos;

• facilidades para não repúdio – guarda credenciais de clientes nos servidores como prova de invocação.

Serviço de transacções e controlo de concorrência

Suporta protocolo de comprometimento de actualização de duas fases (begin >> commit ou rollback), baseado em semáforos.

Serviço de persistência de objectos

Embora o repositório de implementações suporte o arranque de objectos dinâmico, ele não guarda o estado do objecto entre invocações de operações.

O serviço de persistência de objectos fornece uma interface para os objectos guardarem o estado antes de serem desactivados e o recuperarem depois de serem reactivados.