Sistemas Distribuídos Middleware - tele1.dee.fct.unl.pttele1.dee.fct.unl.pt/rit2_2007_2008/teo/4_sist_dist.pdf · Geração do stub Exemplos: XDR, ASN.1, NDR e XML RPC assíncrono

Sistemas Distribuídos Middleware Objectivos dos sistemas distribuídos Exemplos de Sistemas Distribuídos

Protocolos Middleware Implementação do RPC Protocolo RPC Exemplos de protocolo RPC SunRPC, DCE e SOAP Passagem de parâmetros Geração do stub Exemplos: XDR, ASN.1, NDR e XML RPC assíncrono

CORBA Evolução Histórica Modelo de objecto Modelo de referência Arquitectura CORBA Serviços CORBA Comunicação Modelos de Invocação de Objectos Serviços de Eventos e de Notificação Serviço de mensagens Interoperabilidade Processos Clientes Servidores Agentes Nomes na arquitectura CORBA Referências para objectos Serviço de nomes Serviço de trading Replicação na arquitectura CORBA Segurança na arquitectura CORBA

SD - 2 Luis Bernardo & Paulo Pinto

Sistemas Distribuídos Um sistema distribuído é uma colecção de computadores

independentes que parecem aos seus utilizadores como um

sistema único e coerente.

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 se estende por várias máquinas fornecendo uma abstracção para a programação de aplicações em rede.


Objectivos dos sistemas distribuídos Ligação entre utilizadores e recursos O principal objectivo de um sistema distribuído é partilhar recursos entre utilizadores espalhados pela rede de uma forma controlada.

e.g. impressoras, computadores, … Uma maior interligação permite uma maior colaboração e troca de informação.

e.g. groupware - edição conjunta, teleconferência, etc. Requisitos fortes de segurança:

• Confidencialidade e autenticação

• Perigo de violação de privacidade Transparência 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. Esconder diferenças na representação dos dados e no método de acesso – permitir o acesso a recursos locais e remotos utilizando as mesmas operações;

Existe heterogeneidade a vários níveis num sistema distribuído:

• Rede • Hardware • Sistema Operativo • Linguagem de programação

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

• localização. Esconder onde o recurso é localizado – permitir o acesso a recursos sem ter conhecimento da sua localização;

Aceder a recursos através de nomes lógicos.

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

• relocação. Permitir a mobilidade de recursos activos num sistema sem afectar o funcionamento dos programas;

• replicação. Esconder a utilização de múltiplas instâncias de recursos para melhorar a fiabilidade e o desempenho;


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

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

• persistência. Esconder se um recurso (software) está em memória ou no disco.

O nível de transparência deve ser adaptado ao problema, e não sacrificar o desempenho.

• A hora, moeda, etc. locais depende da localização;

• O tempo de transmissão e a largura de banda disponíveis para comunicar dependem da localização dos participantes (LAN vs. WAN).

Uma actualização de vários servidores replicados a nível mundial demora um tempo que não pode ser escondido. O mascarar de falhas temporárias no acesso a um servidor pode ser contraproducente – deve-se deixar que o utilizador tome a iniciativa de desistir a meio das várias tentativas.


Abertura Um sistema aberto oferece serviços de acordo com um conjunto de regras normalizadas que descrevem a sintaxe e semântica do serviço. Um serviço é normalmente descrito por interfaces, definidas numa linguagem de especificação (IDL). Esta deve ser completa e neutral.

Interoperabilidade define até que ponto duas realizações de um sistema podem interactuar. Portabilidade define até que ponto uma aplicação desenvolvida numa arquitectura pode correr noutra realização sem ser modificada. O sistema deve ser extensível permitindo acrescentar funcionalidades. Deve ser realizado a partir de vários componentes, com interfaces internas completamente especificadas. Sistemas monolíticos raramente são abertos – não é possível modificar ou estender um componente sem afectar os outros. Para permitir optimizar a sua utilização, deve permitir configurar o mecanismo através de um conjunto de parâmetros.


Escalabilidade A escalabilidade pode ser medida em três dimensões:

1. em relação ao tamanho – pode-se acrescentar mais utilizadores e recursos ao sistema;

2. em relação à distância geográfica – os componentes podem estar distantes geograficamente;

3. em relação à facilidade de administração – o sistema continua gerível mesmo incluindo muitas organizações independentes.

Problemas de escalabilidade 1. em relação ao tamanho

• Servidores centralizados

• Dados centralizados

• Algoritmos centralizados

i. Uma máquina tem informação completa sobre o estado do sistema, ou

ii. As máquinas tomam decisões baseadas em informações de outros nós, ou

iii. Uma falha de um nó pode arruinar o algoritmo, ou

iv. Assume-se que existe um relógio global.

Mas por vezes é inevitável ter centralização (dados confidenciais de bancos, etc.) …


2. em relação à distância geográfica Em LANs é comum usar comunicação síncrona – o cliente envia o pedido e fica bloqueado à espera de uma resposta. Numa WAN:

• a comunicação pode durar três ordens de grandeza mais (centenas de milisegundos);

• a comunicação é pouco fiável – tem de se lidar com erros.

Não se pode usar técnicas de difusão para localizar serviços – é necessário recorrer a serviços de directórios ou de nomes. Se uma aplicação tem componentes centralizados fica também limitada em termos geográficos. 3. em relação à facilidade de administração

Problemas de conciliação de políticas de utilização e pagamento de recursos, administração e segurança. São necessários dois tipos de medidas de segurança quando o sistema distribuído se expande para um novo domínio:

• o sistema tem de se proteger de ataques vindos do novo domínio;

• o domínio tem de se proteger de ataques vindos do sistema distribuído.

Técnicas de certificação e de controlo de acessos.


Técnicas de escalabilidade Três técnicas principais:

1. Esconder latência na comunicação

2. Distribuição

3. Replicação. 1. Esconder latência na comunicação

Usar comunicação assíncrona para evitar bloquear processos à espera de receber respostas.

a) Tratamento de respostas como eventos;

b) Usar várias tarefas em paralelo para continuar processamento.

Passar parte do processamento do servidor para o cliente.

Melhora a escalabilidade geográfica.


2. Distribuição Decompor os componentes em partes mais pequenas, que são distribuídas por todo o sistema distribuído. Exemplos: DNS e Web Vários clientes podem aceder a diferentes partes em paralelo. 3. Replicação

Aumenta a disponibilidade dos serviços e melhora o balanceamento de carga no sistema. Aumenta a disponibilidade do serviço nas zonas da rede onde há réplicas. e.g. Caching é uma forma de replicação controlada pelo cliente. A existência de várias cópias pode levar a problemas de consistência. Se for necessário ter garantias fortes de consistência (e.g. Internet banking) tem de se actualizar as cópias imediatamente após as modificações – se houver duas modificações concorrentes, a actualização tem de ser a mesma em todas as réplicas.

� não escala para grandes redes É necessário relaxar as garantias de consistência para um sistema distribuído escalar para redes (e.g. Web).


Exemplos de Sistemas Distribuídos Existem três grandes arquitecturas de sistemas distribuídos que satisfazem parcialmente os objectivos 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 Distributed 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 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 SOAP= Simple Object Access Protocol = XML + HTTP


Protocolos Middleware O Middleware inclui aplicações que no modelo OSI (5 níveis) pertencem ao nível aplicação, mas que contêm vários protocolos de uso genérico, que podem ser usados para criar outros protocolos de aplicação mais específicos.

Há vários protocolos que pertencem a este grupo:

Alto nível: autenticação, autorização, …

Baixo nível: multicast fiável, RPC, … Nesta disciplina vamos estudar apenas um destes protocolos profundamente:

RPC (Chamada de procedimentos remotos) O RPC define um modelo de interacção assimétrico entre duas entidades, semelhante à invocação de um procedimento.

cliente servidor

Bloqueado

Resposta

Pedido

Bloqueado

BloqueadoActivo


Implementação do RPC Exemplo de implementação contendo 10 passos:

Stubcliente

Transport

Cliente

Transport

Servidor

servidorStub

1

2

3

4

5

6

7

8

9

10

1. Chamada local a um procedimento 2. Construção da mensagem com os parâmetros "marshalling" ou "serialização"

Passagem para o transporte 3. Passagem pela rede (em modo ligação ou não) 4. Envio para o stub servidor, onde é decomposto, "unmarshalled".

5. Chamada (no modo usual) a uma rotina do servidor. 6. A rotina do servidor retoma normalmente. É feita a serialização dos resultados. 7. A mensagem é enviada para o transporte 8. Passa pela Rede. 9. É enviada para o stub cliente. É decomposta, "unmarshalled"

10. e é feito o retorno para o programa chamador. Objectivo do mecanismo.

TRANSPARÊNCIA

entre chamadas remotas e locais


Protocolo RPC O protocolo RPC realiza um conjunto complexo de tarefas, que varia para as várias realizações existentes (e.g. SunRPC, DCE, CORBA IIOP, RMI, etc.) Para ilustrar as características dos protocolos RPC, vai-se realizar o desenho de um protocolo RPC, sobre UDP, descrevendo-o como uma pilha de três protocolos mais simples (vulgarmente designados de microprotocolos):

• BLAST – fragmenta e reconstrói mensagens grandes;

• CHAN – sincroniza mensagens de pedidos e respostas;

• SELECT – despacha mensagens com pedidos para o processo (cliente ou servidor) correcto.

SELECT

CHAN

BLAST

Os protocolos RPC usados em sistemas reais geralmente não têm esta divisão em três microprotocolos (só o v-Kernel). Mas o modelo permite analisar as suas características, de uma forma mais objectiva.


Desenho do protocolo RPC - Microprotocolo BLAST Problema: A rede só permite enviar blocos de um tamanho limitado (e.g. MTU = 1KB). Pretende-se permitir ao utilizador de RPC enviar dados com um tamanho superior mas inferior a um tamanho máximo predefinido (e.g. 32KB). Solução: O microprotocolo BLAST deverá segmentar a mensagem recebida em blocos de dimensão menor ou igual a MTU, recuperando de perdas de pacotes. Aparentemente, não necessitamos do BLAST - bastaria usar o protocolo de Transporte TCP. Mas o TCP é ineficiente numa interacção pedido-resposta, ao requerer pacotes de estabelecimento de ligação e de terminação da ligação. Num protocolo RPC pretende-se minimizar o atraso, mesmo com múltiplos segmentos.

TCP: Emissor Receptor

SYN

Fragmento pedido 1

ACK

SYN, ACK

FIN

FIN, ACK

Fragmento pedido 2

Fragmento resposta 1


ACK

ACK

BLAST: Emissor Receptor

Fragmento pedido 1

SRR

SRR

Fragmento pedido 2




Desenho do protocolo RPC - Algoritmo BLAST A recuperação de perdas é realizada com retransmissão selectiva. O emissor envia a sequência de segmentos da mensagem numerados, memorizando-os para os poder reenviar. O receptor envia um SRR (Selective Retransmission Request) indicando os segmentos não recebidos, após receber último segmento.

Emissor Receptor

Fragmento 1

Fragmento 2

Fragmento 6

Fragmento 4

Fragmento 3

Fragmento 3

Fragmento 5

SRR

Fragmento 5

SRR

E se se perdeu o último segmento? Temporizadores: DONE (emissor):

• ligado após transmitir todos os segmentos; reinicializado após receber um SRR e retransmitir os segmentos pedidos.

• Se disparar o emissor desiste, elimina a cópia das mensagens e retorna um erro.


LAST_FRAG (receptor):

• Conta tempo desde último segmento recebido; ligado após receber primeiro segmento; reinicializado após recepção de novo segmento.

• Se disparar o receptor admite que se perdeu último segmento e envia SRR

RETRY (receptor):

• Armado após envio de SRR (a pedir segmentos), permite recuperar da perda de SRR.

• Se disparar uma ou duas vezes, reenvia SRR; Se disparar três vezes, o receptor desiste da recepção.

O que acontece se todos os segmentos se perderem ? Formato das mensagens: Cada mensagem deverá ter pelo menos os campos:

• Type – tipo de mensagem (Dados ou SRR);

• MID (Message ID) – Identificador de mensagem; e.g. observe-se que MID também tem os problemas identificados no TCP para os números de sequência

• Length – comprimento dos dados do segmento;

• Identificador da posição do segmento na mensagem: e.g. Número total de fragmentos+ Número de fragmento e.g. Bit de último segmento + Número de fragmento

• Máscara de bits com segmentos correctamente recebidos (no pacote SRR)

e.g. com um número igual ao quociente entre o tamanho máximo da mensagem e MTU


Desenho do protocolo RPC - Microprotocolo CHAN NOTA: Existem vários tipos de microprotocolos CHAN, um para cada tipo de semântica ("Uma no máximo", "Pelo menos uma"). Certas operações podem ser executadas muitas vezes (Idempotentes). Outras não

Ex: Ler um byte Ex: Escrever um bloco no final Como existem operações não idempotentes tem de se definir a semântica do RPC. Exactamente um (Impossível)

Nem mais do que um, nem zero.

"Se a máquina for abaixo fica-se sem saber se a operação foi efectuada".

Uma no máximo (at-most-once)

Se não houve falhas é feita uma só invocação. Se houve erro ou falha no servidor ou na rede, pode haver zero ou uma invocação.

Pelo menos uma (at-least-once)

O cliente vai tentando até conseguir uma resposta positiva.

Quando retorna para a aplicação sabe-se que aconteceu uma ou mais invocações.

Ideal para as operações idempotentes.


Problema: Controlar a troca de mensagens pedido-resposta, garantindo uma semântica "at-most-once", usando o microprotocolo BLAST para enviar as mensagens. Solução: O emissor tem de gerar identificadores de invocação remota únicos por invocação; o receptor tem de memorizar as últimas invocações executadas em memória não volátil, permitindo recuperar de falha de máquinas. Algoritmo CHAN O algoritmo básico é simples:

• O emissor envia o pedido, armando um temporizador RETRY que reenvia a mensagem caso não receba o ACK;

• O receptor envia a resposta do mesmo modo. Mas com sequências de pedido-resposta é possível poupar os pacotes de ACK:

Confirmação implícita Cliente Servidor

Pedido

ACK

Resposta

ACK

Cliente Servidor

Pedido 1

Pedido 2

Resposta 1

Resposta 2


Problema 1) Em caso de perda da mensagem com o pedido, o emissor reenvia-o. Para uma semântica "uma no máximo" (at-most-once):

o servidor tem de memorizar os ID e a resposta associada a cada invocação, reenviando a resposta em caso de reenvio de pedido, sem correr a operação.

Para uma semântica "pelo menos uma " (at-least-once):

o servidor pode realizar várias vezes a mesma operação. Problema 2) O servidor pode demorar bastante tempo a calcular a mensagem de resposta, e o cliente necessita de saber se o servidor ainda está vivo. Após receber confirmação da recepção da mensagem "Pedido", o cliente vai enviar periodicamente uma mensagem PROBE a perguntar "Estás vivo?", recebendo um ACK como resposta. Problema 3) Qual o valor a usar nos temporizadores RETRY? Formato das mensagens: Cada mensagem deverá ter pelo menos os campos:

• Tipo – Pedido, Resposta, PROBE, ACK, NACK • BID (Boot ID) – Valor guardado em ficheiro, que é incrementado cada vez que a máquina reinicializa.

• CID (Channel ID) – usado quando se pretende ter mais de uma invocação em paralelo.

• MID (Identifica a invocação remota) – incrementado sequencialmente em cada invocação.

O BID permite lidar com falhas na máquina do cliente.


Desenho do protocolo RPC - Microprotocolo SELECT Problema: Como enviar as mensagens com pedidos para o servidor apropriado. Solução: Cada procedimento é identificado por um número único. O protocolo SELECT realiza a multiplexagem das invocações de vários procedimentos através de um canal UDP, invocando a função apropriada. A multiplexagem é realizada de uma forma síncrona (ao contrário do UDP, que realiza uma função semelhante, com os números de porto). Do lado do cliente, limita-se a invocar o protocolo CHAN, passando uma mensagem com a identificação do procedimento a invocar e os parâmetros de entrada, e a receber os valores retornados. Embora o algoritmo do SELECT seja simples há duas vantagens em o considerar um protocolo separado:

1. Separa a definição da identificação de procedimentos, tornando-a independente dos outros microprotocolos (e.g. Espaço plano de identificadores vs Espaço hierárquico).

2. Proporciona um bom local para se realizar o controlo de concorrência do servidor (e.g. usar um semáforo para garantir que só há uma tarefa a correr um procedimento)


Exemplo de protocolo RPC - SunRPC O SunRPC é protocolo não normalizado definido pela Sun Microsystems, usado no serviço de ficheiros distribuído NFS. Define um único protocolo desenhado para uma rede local que inclui funcionalidades um pouco diferentes das definidas para SELECT/CHAN/BLAST.

A função de segmentação de mensagens (realizada pelo BLAST) não inclui nenhum mecanismo de correcção de erros. É usada a segmentação de pacotes do protocolo IP.

A função de controlo do pedido-resposta (realizado pelo CHAN) realiza uma semântica mais fraca ("Pelo menos uma"), apenas adaptada a invocações idempotentes (e.g. NFS). O servidor não memoriza as MID recebidas anteriormente, podendo executar mais de uma vez um procedimento se o pedido for reenviado.

A função de multiplexagem (realizada pelo SELECT) é distribuída entre o protocolo UDP e SunRPC. Cada procedimento é identificado pelo (IP; porto) do servidor – seleccionado pelo protocolo UDP; e pelo (número de programa; número de procedimento) – usado no protocolo SunRPC para seleccionar a função a invocar. Para determinar qual o porto correspondente a um número de programa, é usado o servidor "Port Mapper", que corre num porto conhecido. Os servidores quando arrancam registam-se no "Port Mapper", criando-se uma base de dados dos serviços locais à máquina.


Exemplo de protocolo RPC - DCE O protocolo DCE-RPC foi definido inicialmente para o ambiente de desenvolvimento de sistemas distribuídos DCE pela OSF (Open Software Foundation – actualmente designada de Open Group). O DCE-RPC apresenta características de fiabilidade semelhantes ao SELECT/CHAN/BLAST, oferecendo uma semântica "Uma no máximo". A função de segmentação de mensagens é mais complicada que a desenhada no BLAST: usa retransmissão selectiva e um algoritmo de controlo de janela de congestão e de controlo de fluxo semelhante ao usado no TCP, tanto no cliente como no servidor. A numeração é feita ao fragmento. Cada fragmento contém o número de fragmento e uma flag indicando se é o último fragmento (last_frag). O emissor envia até o número máximo de fragmentos permitido pelas janelas do receptor e de congestão, recebendo uma confirmação (Fack), indicando qual o último fragmento completamente recebido e uma máscara de bits com os fragmentos recebidos após o número indicado.

Emissor Receptor

Fragmento 1

Fragmento 2

Fragmento 6

Fragmento 4

Fragmento 3

Fragmento 3

Fragmento 5

Fack

Fragmento 5

Fack

Tipo = Fack

Num. Fragmento= 2

Janela= 6

SelAckLen= 1

SelAck[1]=10 1 0 1 0 (0xA)

2+2

2+4


O DCE-RPC suporta mensagens bastante longas, de até 64 K fragmentos (o Num. Fragmento tem 16 bits). A função de controlo do pedido-resposta adopta um protocolo semelhante ao descrito para o CHAN. Cliente Servidor

Request

ACK

Response

Working

Ping

Excepções:

• (>) Quit – (<) Quack

• (>) Request – (<) Reject

• (>) Ping – (<) Nocall

O DCE-RPC suporta várias semânticas, embora seja "Uma no máximo" por defeito. Cada mensagem inclui:

• ServerBoot – identifica o tempo de arranque do servidor (equivalente a BID do CHAN);

• ActivityID – identifica uma ligação, que pode ter várias invocações (equiv. a CID do CHAN);

• SequenceNum – identifica um pedido dentro de uma ligação (equiv. a MID do CHAN ou do SunRPC).

O DCE-RPC memoriza os últimos números recebidos. A função de multiplexagem do DCE-RPC é equivalente à realizada no SunRPC.


Exemplo de protocolo RPC - SOAP O SOAP (Simple Object Access Protocol) foi introduzido pela Microsoft, para permitir suportar a comunicação nos serviços Web através de RPC ou de troca de mensagens. O SOAP usa como protocolos de transporte os protocolos de acesso Web existentes (HTTP, SMTP, etc), realizados sobre o protocolo TCP, que já cria um canal fiável para comunicar. Não existe a necessidade de um protocolo que recupere erros … mas o protocolo introduz um atraso superior aos protocolos RPC baseados no protocolo UDP. O SOAP define o formato das mensagens duma invocação remota. As mensagens são trocadas numa representação geralmente textual, no formato XML (eXtensible Markup

Language). A codificação dos argumentos das funções é realizada usando XSD (XML Schemas), que permitem definir e codificar dados de tipos arbitrários. A descrição de uma interface RPC SOAP é declarada usando a linguagem WSDL (Web Services Description Language), definindo o tipo de mensagens trocadas em cada operação. Nos sistemas RPC anteriores, a definição restringe-se à definição das funções que compõem a interface. A associação entre clientes e servidores de serviço Web é realizada usando um serviço de mapeamento (UDDI – Universal Description, Discovery, and Integration), que aceita registos de servidores, e permite a pesquisa por clientes.


Estrutura de uma mensagem SOAP

<SOAP:Envelope xmlns:SOAP=

“http://schemas.xmlsoap.org/soap/envelope/”> <SOAP:Header>

<!— content of header goes here —> </SOAP:Header> <SOAP:Body>

<!— content of body goes here —> </SOAP:Body>

</SOAP:Envelope>

As mensagens SOAP têm:

• cabeçalho – informações arbitrárias sobre o cliente (e.g. credenciais, versão de XML e SOAP, etc.)

• corpo – nome e parâmetros de mensagem (argumentos de procedimento)

O cabeçalho é opcional. Exemplo de interacção SOAP sobre HTTP Invocação RPC: POST /travelservice SOAPAction: "http://acme-travel.com/flightinfo" Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP:Envelope xmlns:SOAP=

"http://schemas.xmlsoap.org/soap/envelope/"> <SOAP:Body>

<m:GetFlightInfo xmlns:m="http://acme-travel.com/flightinfo" SOAP:encodingStyle=

"http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi=

"http://www.w3.org/2001/XMLSchema-instance"> <airlineName xsi:type="xsd:string">UL </airlineName> <flightNumber xsi:type="xsd:int">506 </flightNumber>

</m:GetFlightInfo> </SOAP:Body>

</SOAP:Envelope>


Os primeiros campos da invocação incluem a invocação HTTP do método POST (envio de mensagem para o serviço travelService) e um conjunto de símbolos transmitidos por HTTP com a interface invocada (http://acme-travel.com/flightinfo) e a definição do tipo dos dados HTTP. Dentro do corpo da mensagem está o envio da mensagem GetFlightInfo com os parâmetros airlineName e flightNumber. Resposta RPC: HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP:Envelope xmlns:SOAP=

"http://schemas.xmlsoap.org/soap/envelope/"> <SOAP:Body>

<m:GetFlightInfoResponse xmlns:m="http://acme-travel.com/flightinfo" SOAP:encodingStyle=

"http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi=

"http://www.w3.org/2001/XMLSchema-instance"> <flightInfo>

<gate xsi:type="xsd:int">10</gate> <status xsi:type="xsd:string">ON TIME</status>

</flightInfo> </m:GetFlightInfoResponse>

</SOAP:Body> </SOAP:Envelope>

Os primeiros campos da mensagem incluem a resposta HTTP (caso houvesse erro na invocação remota teria aparecido "HTTP:/1.1 500 Server Error"), e a definição do tipo dos dados HTTP. O corpo da mensagem SOAP contém a mensagem GetFlightInfoResponse, com o parâmetro flightInfo.


O WSDL é usado para definir interfaces em dois passos:

• define a sintaxe abstracta da uma interface (portType), com a declaração das operações e das mensagens.

<message name="GetFlightInfoInput"> <part name="airlineName" type="xsd:string"/> <part name="flightNumber" type="xsd:int"/>

</message> <message name="GetFlightInfoOutput"> <part name="flightInfo" type="fixsd:FlightInfoType"/>

</message> <portType name="AirportServicePortType"> <operation name="GetFlightInfo">

<input message="tns:GetFlightInfoInput"/> <output message="tns:GetFlightInfoOutput"/>

</operation> </portType>

• associa um nome de serviço a uma interface, descrevendo o tipo de protocolo de comunicação (RPC), e as regras de codificação das mensagens.

<binding name="AirportServiceSoapBinding" type="tns:AirportServicePortType"> <soap:binding transport=

"http://schemas.xmlsoap.org/soap/http"/> <operation name="GetFlightInfo"> <soap:operation style="rpc"

soapAction="http://acme-travel.com/flightinfo"/> <input> <soap:body use="encoded"

namespace="http://acme-travel.com/flightinfo" encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/"/> </input>

<output> <soap:body use="encoded" namespace="http://acme-travel.com/flightinfo" encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/"/> </output> </operation>

</binding> <service name="travelservice"> <port name="travelservicePort"

binding="tns:AirportServiceSoapBinding"> <soap:address location= "http://acm-travel.com/travelservice"/> </port> </service>


Passagem de parâmetros A função do stub é mais complicada do que parece. Passagem por valor parece fácil - basta copiar as variáveis para a mensagem. Passagem por referência (seria passado o ponteiro se fosse local). Normalmente este tipo de passagem é substituído por copy / restore

O stub vai localizar a referência, copia-a e envia-a para o outro lado. Lá, é criada uma variável auxiliar e no retorno o valor final é copiado para a referência. Falha com: - Variáveis referenciadas por vários ponteiros - Referências para procedimentos O servidor pode ler a variável a partir do cliente desde que se enviem referências para os objectos. Problemas a resolver:

•••• Ordem do envio dos argumentos numa invocação de uma função (em "C" e "Pascal" é diferente).

•••• Alinhamento das estruturas (geralmente, é feita ao

número de bits do processador).

•••• Representação em complemento para um vs complemento para dois.

•••• EBCDIC vs ASCII vs UNICODE

•••• Little endian vs Big endian

DEC 00 00 01 2c IBM 2c 01 00 00 Intel Motorola, Sun

300 = 00 00 01 2c

Mas, as strings são todas representadas da esquerda para a direita.


Exemplo:

type cidadão = record nome : array [ 1 .. 20 ] of character; bi : integer; homem : boolean; altura : integer; part_polit : array [ 1 .. 12 ] of character;

BE LE

0 M A R I 0 M A R I 4 O S I 4 O S I 8 L V A 8 L V A 12 12 16 16 20 C6 EA A 0 20 C6 EA A 0 24 1 0 0 0 24 1 0 0 0 28 BE 0 0 0 28 BE 0 0 0 32 P A R T 32 P A R T 36 I D O 36 I D O 40 D O I S 40 D O I S

MARIO SILVA 715462 TRUE=1 190

PARTIDO DOIS

MARIO SILVA 3237265152

TRUE=16777216 3187771040

PARTIDO DOIS

Se se inverter tudo …

Como é que o receptor sabe onde está o nome ?

0 I R A M 4 I S O 8 A V L 12 16 20 0 A EA C6 24 0 0 0 1 28 0 0 0 BE 32 T R A P 36 O D I 40 S I O D

IRAMIS O AVL 715462 TRUE=1 190 TRAP ODISIOD


Taxonomia

Os sistemas de serialização de argumentos (realizados nos stubs) podem classificar-se em três categorias:

• Tipos de dados • Estratégia de conversão • Etiquetas

Tipos de dados

• Dados básicos (inteiros, strings, etc.) • Dados planos (estruturas e arrays) • Dados complexos (listas, etc.)

Estratégia de conversão Vários formatos

Formato standard

•••• Só existe uma conversão

•••• n(n-1) conversores •••• Pode não haver conversões

•••• Existem duas conversões

•••• 2n conversores •••• Normalmente há sempre conversões

Etiquetas

• Etiquetas para definir tipo dos dados, comprimento, arquitectura da representação dos dados

• Sem etiqueta – o receptor "sabe" o que foi enviado


Geração do stub Embora as regras de codificação de valores básicos e os protocolos sejam normalizados, cada interface vai ter uma lista específica de funções, cada uma com uma lista específica de parâmetros. O stub vai usar as regras de codificação genéricas para codificar os parâmetros específicos de cada função. Muitas vezes o stub é gerado automaticamente a partir de uma especificação formal da interface, numa IDL.

Exemplo do XDR (eXternal Data Representation) O XDR é o formato de rede usado em SunRPC;

• Suporta todos os tipos C excepto ponteiros para funções;

• Define uma forma canónica intermédia;

• Não usa etiquetas (excepto para comprimento de arrays);

• Usa stubs compilados.

Call P

Client stub

RPC

Arguments

Marshalled arguments

Interface descriptor for Procedure P

Stub compiler

Message

Specification

P

Server stub

RPC

Arguments

Marshalled arguments

Code Code


No modelo de referência TCP/IP, o problema da representação de dados foi resolvido ao nível dos protocolos TCP, UDP, IP, etc. somente para os inteiros:

ordem de octetos na rede

ordem de octetos nativa na máquina O XDR foi introduzido pela Sun Microsystems Inc., e ficou como uma norma de facto, para a codificação de parâmetros no SunRPC. Usa o formato big endian para inteiros. Qualquer tipo de dados tem 32 bits ou mais. Se duas máquinas quiserem transmitir um inteiro de 2 bytes, têm de convertê-lo para 4 bytes. A codificação contém apenas o valor do dado sem nenhuma informação sobre os tipos (códigos de tipos, comprimentos). A excepção é o tipo string, que é transmitido precedido do comprimento. Ambas as partes que trocam informação têm de concordar no formato exacto das mensagens que trocam. As mensagens não podem ser interpretadas. Tem de se saber o formato exacto e os tipos de todos os campos de dados.


Rotinas de biblioteca para fazer a conversão usa o paradigma do buffer O programa reserva um buffer suficientemente grande e vai chamando rotinas para colocar as conversões na parte final do buffer. #include <rpc/xdr.h> #define BUFSIZE 4000 XDR *xdrs; /* ponteiro para “stream” XDR */ char buf [BUFSIZE]; /* area de memoria */ xdrmem_create (xdrs, buf, BUFSIZE, XDR_ENCODE);

Aloca o buffer, inicializa-o, e indica que é para representação externa. XDR stream A biblioteca mantém um ponteiro interno para o local onde vai pôr o próximo dado. No início é no princípio do buffer. Por cada chamada de codificação, o valor é posto no sítio do ponteiro, e o ponteiro interno é actualizado. int i; … i = 260; xdr_int (xdrs, &i);

Na recepção, chama-se xdrmem_create com a opção XDR_DECODE. Os dados que recebeu formam o buffer, e usam-se as mesmas rotinas para conversão interna. A biblioteca gere um ponteiro interno para saber onde se está no buffer. int i; … xdr_int (xdrs, &i);

As rotinas de codificação e descodificação dos tipos básicos (xdr_int, xdr_char, etc.) são compostas para realizar a serialização de tipos complexos genéricos.


ASN.1 (Abstract Syntax Notation 1) ASN.1 – linguagem formal para definição de estruturas de dados especificada pelo ISO. Utilidade:

• definição de sintaxes abstractas dos dados de aplicação

• definição das estruturas das PDU

• definição da informação de gestão dos sistemas OSI e SNMP

A parte específica da representação de informação designa-se de BER (Basic Encoding Rules).

• Suporta todos os tipos C excepto ponteiros para funções;

• Define uma forma canónica intermédia;

• Usa etiquetas com os tipos;

• Usa stubs compilados ou interpretados. Cada valor de ASN.1 é codificado numa tripla: tipo: indica o tipo, a classe do tipo, e se ele é

primitivo ou construído comprimento: indica o comprimento da representação valor: representa o valor do tipo respectivo usando

uma cadeia de octetos Estruturas complexas são obtidas aplicando recursivamente a estrutura.

value

type type length value length type value length


Campo tipo Geralmente 1 octeto, embora possa ter mais octetos.

Campo comprimento

Comparação:

• Usa mais bytes que XDR;

• Requer mais processamento que XDR na codificação e descodificação;

• Permite a utilização de analisadores de protocolos.

comprimento

K octetos

0 ≤ comprimento ≤ 127

um octeto

0 comprimento

um octeto

1 K

um octeto

1 0 0 0 0 0 0 0 comprimento indefinido. Termina com EOC

128 ≤ comprimento ≤ 21008

Class P/C Tag Nmb

1 X X X X X X X Class P/C 1 1 1 1 1 0 X X X X X X X

P/C: 0 – primitivo 1 – construído

… Class: 00 = Universal 01 = Application 10 = Context specific 11= Private

Tag Number: 1 = Boolean 2 = Integer 3 = Bitstring 4 = Octetstring 5 = Null 6 = Object identifier 9 = Real 10 = Enumerated 16 = Sequence e Sequence-of 17 = Set e Set-of 18-22, 25-27 = Character string 23-24 = Tempo > 30: XX…X =Tag number


NDR (Network Data Representation) É o formato de representação dos dados no sistema DCE (DCE-RPC). Ao contrário do ASN.1 e do XDR, o NDR não usa um formato standard para representar a informação. O NDR envia uma etiqueta (tag) juntamente com a informação no formato da arquitectura da máquina, indicando o tipo de arquitectura. O receptor converte a representação da informação, caso esteja numa arquitectura distinta.

O stub é gerado por um compilador:

IntegerRep CharRep FloatRep Extension1 Extension2

0 ASCII 1 EBCDIC

0 big end. 1 little end.

0 IEEE754 1 VAX 2 Cray 3 IBM

4 0 8 16 24 32


XML (eXtensible Markup Language) O XML é uma linguagem que permite definir uma estrutura para documentos, anotando o texto com etiquetas. Tanto o XML como o HTML (HyperText Markup Language) são linguagens derivadas do SGML (Standard Generalized

Markup Language). No entanto, o XML permite usar conjuntos dinâmicos de etiquetas, atribuindo-lhes significados semânticos. O HTML está limitado a um conjunto fixo de etiquetas. Quando são usadas as etiquetas definidas no protocolo SOAP, o XML pode ser usado para definir a sintaxe e a semântica na interacção entre objectos. A sintaxe do XML permite definir tipos de documentos usando dois tipos de declarações:

• DTD (Document Type Definitions) – foi a primeira a ser introduzida (herdada do SGML), permite a declaração da estrutura de blocos e das etiquetas presentes em cada bloco;

• XSD (XML Schema Definition) – introduzida recentemente, permite definir tipos de dados arbitrários e suportar a sua codificação.

O protocolo SOAP (Simple Object Access Protocol) usa a facilidade do XSD para descrever tipos de dados, argumentos de procedimentos, e usa um tipo de documentos SOAP para descrever as interfaces de objectos e as mensagens trocadas na interacção entre objectos.


O XSD/SOAP define um conjunto de tipos de dados básicos: Tipo Descrição Exemplo xsd:int Inteiro 32 bits -12

xsd:boolean Valor booleano, 1 ou 0 1

xsd:string Cadeia de caracteres Olá mundo

xsd:float ou

xsd:double

Número fraccionário -12.214

xsd:timeInstant Data/hora 2001-03-27

T00:00:00-08:00

SOAP-

ENC:base64

Dados binários EW911G…

Adicionalmente, suporta tipos estruturados:

• Estruturas <param>

<campoUm xsi:type="xsd:int">18</campoUm>

<campoDois xsi:type="xsd:int">45</campoDois>

</param>

• Arrays <param SOAP-ENC:arrayType= xsd:ur-type[4]"

xsi:type="SOAP-ENC:Array">

<item xsi:type= "xsd:int">18</item>

<item xsi:type= "xsd:string">Portugal</item>

<item xsi:type= "xsd:boolean">0</item>

<item xsi:type= "xsd:int">-2</item>

</param>

Os Esquemas XML (XSD) permitem subdividir o espaço de nomes em vários grupos, para evitar a utilização da mesma etiqueta em contextos diferentes. Um espaço de nomes é declarado com o prefixo xmlns.


Exemplo da definição de um tipo complexo num espaço de nomes <xsd:schema xmlns:xsd= "http://www.myserver.net/bookinfo">

<xsd:element name="BOOK" type="BOOKTYPE"/>

<xsd:complexType name="BOOKTYPE" >

<xsd:element name="AUTHOR" type="xsd:string"

minOccurs="1" maxOccurs="unbounded"/>

<xsd:element name="TITLE" type="xsd:string"/>

<xsd:element name="PUBLISHER" type="xsd:string"

minOccurs="0" maxOccurs="1"/>

<xsd:element name="YEAR" type="xsd:decimal"

minOccurs="0" maxOccurs="1"/>

<xsd:attribute name="isbn" type="xsd:string"/>

<xsd:attribute name="nickname" type="xsd:string"/>

</xsd:complexType>

</xsd:schema>

Para usar este espaço de nomes seria necessário incluir a definição do tipo

<… xmlns:mylib="http://www.myserver.net/bookinfo">

O prefixo "mylib:" está associado ao espaço de nomes "http://www.myserver.net/bookinfo".

Observe-se que o XML, tal como o ASN.1, realiza tanto a definição da sintaxe abstracta, como a codificação dos dados. O XML permite usar diferentes tipos de codificação (incluindo uma forma compatível com ASN.1), mas geralmente codifica os dados para texto (utf-8 = ASCII), tornando-os compatíveis com HTTP (Web).


Exemplo de interacção SOAP Invocação RPC: POST /travelservice

SOAPAction: "http://www.myserver.net/bookinfo"

Content-Type: text/xml; charset="utf-8"

Content-Length: nnnn


"http://schemas.xmlsoap.org/soap/envelope/">

<SOAP:Body>

<m:GetBookInfo

xmlns:m="http://www.myserver.net/bookinfo"

SOAP:encodingStyle=

"http://schemas.xmlsoap.org/soap/encoding/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi=

"http://www.w3.org/2001/XMLSchema-instance">

<bookName xsi:type="xsd:string">Computer networks

</bookName>

<bookYear xsi:type="xsd:int">2002

</bookYear>

</m:GetBookInfo>

</SOAP:Body>

</SOAP:Envelope>

Resposta RPC: HTTP/1.1 200 OK

Content-Type: text/xml; charset="utf-8"

Content-Length: nnnn


"http://schemas.xmlsoap.org/soap/envelope/">

<SOAP:Body>

<m:GetBookInfoResponse

xmlns:m="http://www.myserver.net/bookinfo"

SOAP:encodingStyle=

"http://schemas.xmlsoap.org/soap/encoding/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi=

"http://www.w3.org/2001/XMLSchema-instance">

<bookInfo>

<info xsi:type="m:BOOKTYPE">

<AUTHOR …

…

</info>

</bookInfo>

</m:GetBookInfoResponse>

</SOAP:Body>

</SOAP:Envelope>


RPC assíncrono Existem variantes de RPC onde o cliente não fica bloqueado à espera da resposta ao pedido.

Quando uma operação não devolve um valor é possível não esperar pelo fim do processamento do pedido: RPC síncrono RPC assíncrono

ou RPC one-way – o cliente envia o pacote de pedido e não testa se o servidor o recebeu – não fiável

Caso seja necessário enviar uma resposta, então pode-se usar um RPC síncrono diferido:

• O cliente lança o processamento do pedido e continua o processamento;

• A resposta é recebida numa rotina assíncrona invocada após a recepção da mensagem, ou após o cliente invocar uma operação de espera explícita da resposta.


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 3.0, em Dezembro 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. Uma grande parte dos ORBs disponíveis em 2003 apenas é compatível com a norma CORBA 2.4.


Modelo de objecto Os objectos encapsulam dados, designados de estado (state), e operações sobre esses dados, designadas de métodos (method). Os métodos estão acessíveis através de uma interface, independente da realização do objecto. Quando o cliente se associa ao servidor, é carregada a realização da interface, designada de procurador (proxy), e depois usada para invocar métodos no objecto. O servidor recebe o pedido através do Skeleton, que invoca o objecto local.

Este modelo é semelhante a um RPC - os Proxy e Skeleton realizam a serialização de parâmetros e correm um protocolo de interacção, vulgarmente RPC. A diferença principal está na vida de um objecto – em CORBA um objecto pode ser acedido mesmo que não esteja a correr na máquina servidora – o sistema encarrega-se de o lançar automaticamente quando recebe um pedido de um cliente. Numa RPC o servidor está acessível enquanto estiver a correr.


Modelo de referência O modelo de referência CORBA 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 deAplicaçõ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 de eventos;

• etc.


Modelo de referência (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 escondendo aspectos relacionados com a distribuição e heterogeneidade. Ele localiza um objecto (activa-o se necessário), e trata da troca de mensagens entre o cliente e o objecto. Todas as interfaces são definidas na linguagem de especificação de interfaces CORBA (CORBA IDL).

Define a sintaxe (que parâmetros, que métodos), não define a semântica (acções associadas aos métodos).

A norma CORBA define como é que uma especificação IDL é realizada em várias linguagens de programação:

Java, C, C++, Smalltalk, Ada e COBOL.


Arquitectura CORBA Não existe um objecto ORB num sistema real. A arquitectura CORBA define como é realizada a funcionalidade de ORB num sistema real. A figura representa os componentes principais da arquitectura CORBA

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

• Adaptador de Objectos (no servidor)

• Repositório de interfaces

• Repositório de implementações Estes componentes criam a ilusão de transparência oferecida pela arquitectura CORBA.

Repositório Implementações

Repositório Interfaces


Arquitectura CORBA (2) Núcleo ORB (Client ORB e Server 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. 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 localizar serviços disponíveis no ORB; • operações para manipular referências para objectos; • operações para criar listas de argumentos para invocações dinâmicas.

stubs e skeletons Os stubs IDL estáticos 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. A DII (Dynamic Invocation Interface) e DSI (Dynamic Skeleton

Interface) permitem realizar a serialização e reconstrução de parâmetros em tempo-real para interfaces desconhecidas na altura da compilação. e.g. gateway entre objectos CORBA e DCOM A DII oferece um método para invocar operações genéricas (invoke) que recebe como argumento uma referência para o objecto, um identificador de método, e um buffer com os parâmetros de entrada e devolve os parâmetros de saída.


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 tem também 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 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.


Serviços CORBA

Serviço Descrição

Colecção Facilidades para agrupar objectos em listas, filas, conjuntos, etc.

Query Facilidades para pedir colecções de objectos de uma maneira declarativa

Concorrência Facilidades para permitir acessos concorrentes a objectos partilhados

Transacções Transacções planas e encadeadas na chamada de métodos sobre múltiplos objectos

Eventos Facilidades para comunicação assíncrona através de eventos

Notificação Facilidades avançadas para comunicação assíncrona baseada em eventos

Externalização Facilidades para serializar e reconstruir objectos

Ciclo de vida Facilidades para criar, apagar, copiar e mover objectos

Licenciamento Facilidades para acrescentar licenças a objectos

Nomes Facilidades para nomear objectos a nível de sistema

Propriedades Facilidades para associar pares atributo - valor a objectos

Trading Facilidades para publicar e procurar os serviços oferecidos por objectos baseado em atributos

Persistência Facilidades para guardar objectos persistentes

Relacionamento Facilidades para definir relacionamentos entre objectos

Segurança Mecanismos para canais seguros, autorização e auditoria

Tempo Fornece o tempo corrente com a margem de erro especificada.


Comunicação Modelos de Invocação de Objectos A arquitectura CORBA suporta três modelos de invocação de objectos (tipos de RPC):

Tipo de RPC

Semântica de falhas

Descrição

Síncrono At-most-

once

O cliente bloqueia-se até que seja retornada uma resposta ou uma excepção

One-way Melhor esforço

O cliente continua imediatamente sem esperar pela resposta do servidor

Síncrono diferido

At-most-

once

O cliente continua imediatamente e pode mais tarde bloquear-se à espera da resposta

Até à norma CORBA 2.3, o modelo síncrono diferido apenas foi suportado para invocação dinâmica de interfaces (DII). 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. A partir da norma CORBA 2.4 foi introduzida a invocação assíncrona de interfaces, utilizando-se o serviço de mensagens.


Serviços de Eventos e de Notificação 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 um RPC síncrono sobre os procuradores existentes no canal de eventos.

consumidorfornecedor

procuradorconsumidor

notificação

procuradorfornecedor

canal eventos

notificaçãonotificaçã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.


O serviço de eventos não suporta eventos persistentes – se um consumidor se ligar após o evento ter sido enviado, já não o recebe. A propagação de eventos não é fiável. Tem limitações no número de membros dos grupos:

É possível criar cadeias de canais de eventos, de forma a melhorar a escalabilidade do sistema.

O serviço de notificação 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"). Caso não haja consumidores interessados, o serviço oferece facilidades para evitar a propagação de eventos. Serviço de mensagens O serviço de mensagens oferece o único modelo de comunicação verdadeiramente assíncrona entre objectos – o serviço guarda as mensagens entregando-as quando os receptores ficarem activos. Suporta a invocação assíncrona de métodos na interface de objectos, onde apenas o cliente é modificado – o servidor recebe uma invocação normal num método. Pode ser usado com interfaces definidas através de um IDL, com stubs e skeletons gerados automaticamente. e.g. int add(in int i, in int j, out int k);


Pode funcionar num de dois modelos: Modelo callback:

O cliente cria um novo objecto para receber a callback. e.g. a interface do cliente é substituída por:

// Chamado pelo cliente void sendcb_add(in int i, in int j); // Chamado pelo ORB do cliente

void replycb_add(in int ret_val, in int k);

Modelo Polling:

e.g. a interface do cliente é substituída por:

// Chamado pelo cliente void sendpoll_add(in int i, in int j); // Chamado pelo cliente

void replypoll_add(out int ret_val, out int k);


Interoperabilidade A norma CORBA 2.0 (em 1996) veio resolver os problemas de inter-operação entre ORB de diferentes empresas ao definir um protocolo standard completamente especificado para a comunicação entre ORBs e uma forma uniforme para referênciar objectos. A norma define o GIOP (General Inter-ORB Protocol), uma estrutura para a definição de um protocolo sobre um nível transporte fiável, e uma realização de GIOP sobre TCP – designada de IIOP (Internet Inter-ORB Protocol). O GIOP (logo o IIOP e qualquer outra realização de GIOP) define oito tipos diferentes de mensagens:

Tipo mensagem

Originador Descrição

Request Cliente Contém um pedido de invocação

Reply Servidor Contém a resposta a uma invocação

LocateRequest Cliente Contém um pedido sobre a localização

exacta do objecto

LocateReply Servidor Contém informação sobre a localização

de um objecto

CancelRequest Cliente Indica que o cliente já não espera a

resposta

CloseConnection Ambos Indica que a ligação vai ser fechada

MessageError Ambos Contém informação sobre um erro

Fragment Ambos Parte (fragmento) de uma mensagem

maior

O par Request - Reply realiza a invocação de objectos: cada invocação é identificada por um identificador de pedido único. O par LocateRequest - LocateReply é usado para aceder ao repositório de implementações.


Processos A arquitectura CORBA distingue dois tipos de processos:

• Clientes – de simples utilização; • Servidores – recebem suporte do adaptador de objectos.

Clientes A parte cliente é mantida num nível mínimo – um procurador liga o cliente ao ORB serializando e reconstruindo parâmetros a partir de mensagens IIOP. Alternativamente, o programador pode usar DII para aceder directamente ao ORB. O CORBA define dois tipos de interceptores para estender estes mecanismos de interacção (e.g. para realizar caching):

• Ao nível do pedido o No cliente pode modificar o pedido antes de ser enviado para o núcleo ORB. No servidor está entre o ORB e o adaptador de objectos.

• Ao nível da mensagem – trata mensagens GIOP o Processa uma mensagem antes de a enviar para a rede, ou após a receber

o e.g. segmentação de mensagens


Servidores O adaptador de objectos “transforma” o código do servidor num objecto CORBA. O adaptador de objectos adoptado na arquitectura CORBA (a partir da norma 2.2) é o POA (Portable Object Adapter). Um objecto CORBA é realizado parcialmente através de um servente (servent) – a parte do objecto que realiza os métodos que os clientes podem invocar. O POA oferece uma operação para registar serventes: ObjectId activate_object(in Servant p_servant);

O POA mantém a tabela de objectos activos no POA com ponteiros para os serventes associados a cada objecto – o mapa de objectos activos

Pode existir um servente por objecto ou vários objectos por servente, e o objecto pode ser persistente ou transitório – depende da política associada ao POA. O identificador global do objecto CORBA inclui:

identificação do POA + OID


Exemplo de activação de um objecto CORBA em C++:

Agentes Agentes são objectos autónomos, que podem migrar entre locais distintos da rede. A arquitectura CORBA oferece um suporte básico para permitir a cooperação entre diferentes tipos de sistemas de agentes.

• Define um conjunto de interfaces para que os sistemas de agentes possam comunicar entre si, atribuindo nomes a agentes, criando e destruindo agentes, listando lugares onde o agente pode correr, e suspendendo e resumindo agentes;

• Cada região oferece um localizador (finder) que permite procurar agentes, lugares e sistemas de agentes.

A norma CORBA não define a inter-operação entre agentes, apenas entre plataformas de agentes:

Cada agente apenas pode correr nas suas plataformas; se quiser comunicar com outro agente de outro tipo apenas o pode fazer através da invocação de métodos na sua interface.

My_servant *my_object; // Declara referência para

Objecto C++

CORBA::Objectid_var oid; // Declara identificador

my_object = new MyServant; // Cria novo objecto C++

oid = poa ->activate_object (my_object); // Regista objecto

C++ como objecto CORBA


Nomes na arquitectura CORBA A arquitectura CORBA suporta diferentes tipos de nomes:

• As referências para objectos, que podem ser convertidas numa cadeia de caracteres.

• Nomes suportados pelos serviços de nomes e de trading. Referências para objectos Num programa, uma referência para um objecto inclui ponteiros para um objecto activo na linguagem de programação local, que apenas tem significado dentro do ORB local. Para permitir passar esta referência para outros ORBs, a partir da norma CORBA 2.0, especificou-se o formato de uma referência para um objecto, designada de Interoperable Object Reference (IOR)

O campo Repository identifier 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.


Para cada protocolo de acesso ao objecto é criado um perfil. Cada perfil define: a versão de protocolo IIOP e a localização na rede (endereço e porto), a chave do objecto, e componentes adicionais (e.g. informação de segurança). A chave do objecto identifica o adaptador de objectos e o identificador de objecto dentro desse adaptador de objectos. 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 Alternativamente, para objectos activados dinamicamente definem-se IOR persistentes. O IOR contém a referência para um repositório de implementações, permanecendo válido entre várias invocações do objecto. Neste caso, o objecto servidor é activado pelo repositório de implementações de forma transparente para o cliente:


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

CD 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

contexto nomes inicial


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ç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.


Replicação na arquitectura CORBA A arquitectura CORBA não oferece suporte para caching ou replicação de objectos genérica. Apenas oferece suporte de replicação para tolerância a falhas. A norma CORBA 2.5 introduziu o suporte de grupos de objectos – constituído por uma ou mais réplicas de um objecto. O grupo oferece a mesma interface que cada objecto, sendo usado transparentemente pelos clientes. Fornece várias estratégias para gestão de coerência entre réplicas: replicação primário-backup; replicação activa; replica baseada em quórum, etc. O grupo de objectos é identificado por um tipo especial de IOR, o IOGR (Interoperable Object Group Reference):

O ORB vai tentar sucessivamente associar-se aos vários objectos referenciados no IOGR, até ter sucesso com um dos objectos.


Para oferecer um nível superior de tolerância a falhas torna-se necessário acrescentar componentes à arquitectura. O sistema Eternal acrescentou:

• um gestor de replicação, que transparentemente cria replicas quando se cria um objecto;

• Um interceptor de mensagens, que difunde as mensagens para o grupo de réplicas de forma a todas verem a mesma sequência de mensagens.

Noutros casos de replicação mais genéricos, novamente é necessário recorrer a componentes externos à arquitectura CORBA, que recorrem a interceptores para modificar o tratamento dos pedidos. Um exemplo é o sistema CASCADE, que definiu um novo serviço – o serviço de replicação – que permite que qualquer objecto CORBA seja guardado em cache. O serviço de replicação é realizado por um grupo de DCS (Domain Caching Servers), distribuído por toda a rede (e.g. Internet).


O dono do objecto pode registá-lo no DCS local – DCSs. Define a politica de consistência de réplicas, que será gerida transparente pelo serviço de replicação. Um cliente pode pedir junto do seu DCS – DCSc (possivelmente noutra zona) – para criar em cache uma réplica local do objecto. O DCSc liga-se ao DCSs através de um conjunto de ligações em árvore (definindo uma hierarquia) que pode atravessar diversos DCS. A cache contém o estado do objecto e o código dos métodos. Durante a invocação ao objecto, um interceptor de pedido no ORB desvia o pedido para o DCSc que vai processar o pedido de acordo com as regras de coerência definidas.

Sincronização de objectos na arquitectura CORBA É baseada na utilização de dois serviços: O serviço de controlo de concorrência realiza um gestor centralizado de semáforos (locks). Os objectos podem bloquear ou abrir o acesso a outros objectos (modo leitura ou escrita). O serviço de transacções suporta um protocolo de comprometimento de actualização de duas fases (begin >> commit ou rollback), baseado em semáforos.


Segurança na arquitectura CORBA O serviço de segurança CORBA foi completamente definido apenas na norma CORBA 2.4. O serviço oferece um conjunto de mecanismos que podem ser usados para realizar diferentes políticas de segurança na invocação de um objecto. Suporta quatro funcionalidades principais:

• autenticação de utilizadores e servidores;

• controlo de acesso para objectos CORBA;

• auditoria de invocações remotas de objectos;

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

Quando um cliente se associa a um objecto, pode especificar quais são as políticas de segurança que pretende usar. Na criação de um objecto também se especifica quais são as políticas de acesso. Estas opções são combinadas com as configurações dos ORB locais, seleccionando-se que componentes de segurança são usados.


Os serviços de segurança são vulgarmente realizados utilizando interceptores a vários níveis:

Os interceptores de controlo de acesso actuam ao nível do pedido, e verificam se o cliente tem direitos de acesso ao objecto. Os interceptores de invocação segura realizam a protecção das mensagens – criam um canal seguro entre o cliente e o objecto. O canal seguro é suportado por um contexto de segurança, que contém os métodos de cifra usados, as credenciais, etc. Esta informação é mantida num objecto cofre, um objecto do ORB que “não pode” ser modificável directamente pelo código cliente ou servidor. Após a troca inicial de mensagens, o cliente fica associado ao objecto através de uma associação segura. A partir dai, os interceptores protegem as mensagens trocadas.

Sistemas Distribuídos Middleware - tele1.dee.fct.unl.pttele1.dee.fct.unl.pt/rit2_2007_2008/teo/4_sist_dist.pdf · Geração do stub Exemplos: XDR, ASN.1, NDR e XML RPC assíncrono

Documents