Acetatos sobre Sistemas distribuídos

Transcrição

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
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.
SD - 2
 Luis Bernardo & Paulo Pinto
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.
SD - 3
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;
SD - 4
• 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.
SD - 5
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
funcionalidades.
ser
extensível
permitindo
acrescentar
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.
SD - 6
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.) …
SD - 7
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.
SD - 8
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
processamento.
em
paralelo
para
continuar
Passar parte do processamento do servidor para o cliente.
Melhora a escalabilidade geográfica.
SD - 9
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).
SD - 10
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
SD - 11
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
Pedido
Bloqueado
Bloqueado
Activo
Resposta
Bloqueado
SD - 12
Implementação do RPC
Exemplo de implementação contendo 10 passos:
1
Cliente
10
9
5
Stub
cliente
Stub
servidor
2
Servidor
6
7
4
Transport
Transport
3
8
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
SD - 13
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.
SD - 14
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
BLAST:
Emissor
Receptor
Receptor
Fragmento pedido 1
Fragmento pedido 2
SYN
SYN, ACK
SRR
Fragmento resposta 1
Fragmento pedido 1
ACK
Fragmento pedido 2
SRR
ACK
FIN
FIN, ACK
ACK
SD - 15
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 3
Fragmento 4
Fragmento 5
Fragmento 6
SRR
Fragmento 3
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.
SD - 16
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
SD - 17
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
(Idempotentes). Outras não
Ex: Ler um byte
ser
executadas
muitas
vezes
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.
SD - 18
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
Cliente
Servidor
Pedido 1
Pedido
Resposta 1
ACK
Resposta
Pedido 2
ACK
Resposta 2
SD - 19
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.
SD - 20
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)
SD - 21
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.
SD - 22
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 3
Fragmento 4
Fragmento 5
Fragmento 6
Fack
Tipo = Fack
Num. Fragmento= 2
Janela= 6
2+4
2+2
SelAckLen= 1
SelAck[1]=10
1 0 1 0 (0xA)
Fragmento 3
Fragmento 5
Fack
SD - 23
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
Ping
Working
Response
ACK
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.
SD - 24
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.
SD - 25
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
"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>
SD - 26
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://acmetravel.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
<SOAP:Body>
<m:GetFlightInfoResponse
xmlns:m="http://acme-travel.com/flightinfo"
SOAP:encodingStyle=
xmlns:xsi=
<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.
SD - 27
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>
SD - 28
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
DEC 00 00 01 2c
Intel
Big endian
IBM
2c 01 00 00
Motorola, Sun
300 = 00 00 01 2c
Mas, as strings são todas representadas da
esquerda para a direita.
SD - 29
Exemplo:
type cidadão = record
nome
:
bi
:
homem
:
altura
:
part_polit :
array [ 1 .. 20 ] of character;
integer;
boolean;
integer;
array [ 1 .. 12 ] of character;
BE
0
4
8
12
16
20
24
28
32
36
40
LE
M
O
L
A
I
I
V
R
S
A
C6
1
BE
P
I
D
EA
0
0
A
D
O
A
0
0
R
O
I
0
0
0
T
0
4
8
12
16
20
24
28
32
36
40
S
MARIO SILVA
715462
TRUE=1
190
PARTIDO DOIS
0
4
8
12
16
20
24
28
32
36
40
I
I
0
0
0
T
S
M
O
L
A
I
I
V
R
S
A
C6
1
BE
P
I
D
EA
0
0
A
D
O
A
0
0
R
O
I
0
0
0
T
S
MARIO SILVA
3237265152
TRUE=16777216
3187771040
PARTIDO DOIS
R
S
A
A
V
M
O
L
A
0
0
R
O
I
EA
0
0
A
D
O
C6
1
BE
P
I
D
Se se inverter tudo …
IRAMIS O AVL
715462
TRUE=1
190
TRAP ODISIOD
Como é que o receptor sabe onde está o nome ?
SD - 30
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
SD - 31
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.
Call P
Interface
descriptor for
Procedure P
Arguments
Client
stub
Code
Specification
Code
Stub
compiler
Marshalled
arguments
P
Arguments
Server
stub
Marshalled
arguments
RPC
RPC
Message
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.
SD - 32
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.
SD - 33
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
char
*xdrs;
/* ponteiro para “stream” XDR */
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 usamse 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.
SD - 34
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.
type
length
type
length
value
type
length
value
value
SD - 35
Campo tipo
Geralmente 1 octeto, embora possa ter mais octetos.
Class P/C Tag
Nmb
Class P/C 1 1 1 1 1 1 X X X X X X X
Class:
00 = Universal
01 = Application
10 = Context specific
11= Private
P/C:
0 – primitivo
1 – construído
…
0 XXXXXXX
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
Campo comprimento
0
um octeto
comprimento
1
um octeto
K
um octeto
1 0 0 0 0 0 0 0
0 ≤ comprimento ≤ 127
K octetos
comprimento
128 ≤ comprimento ≤ 21008
comprimento indefinido. Termina com EOC
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.
SD - 36
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.
0
4
8
IntegerRep
CharRep
0 big end.
1 little
end.
0 ASCII
1 EBCDIC
16
FloatRep
24
Extension1
32
Extension2
0 IEEE754
1 VAX
2 Cray
3 IBM
O stub é gerado por um compilador:
SD - 37
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.
SD - 38
O XSD/SOAP define um conjunto de tipos de dados básicos:
Tipo
Descrição
Exemplo
xsd:int
xsd:boolean
xsd:string
xsd:float ou
xsd:double
xsd:timeInstant
Inteiro 32 bits
Valor booleano, 1 ou 0
Cadeia de caracteres
Número fraccionário
-12
1
Olá mundo
-12.214
Data/hora
2001-03-27
T00:00:00-08:00
SOAPENC: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.
SD - 39
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).
SD - 40
Exemplo de interacção SOAP
Invocação RPC:
POST /travelservice
SOAPAction: "http://www.myserver.net/bookinfo"
<SOAP:Body>
<m:GetBookInfo
xmlns:m="http://www.myserver.net/bookinfo"
SOAP:encodingStyle=
xmlns:xsi=
<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
<SOAP:Body>
<m:GetBookInfoResponse
xmlns:m="http://www.myserver.net/bookinfo"
SOAP:encodingStyle=
xmlns:xsi=
<bookInfo>
<info xsi:type="m:BOOKTYPE">
<AUTHOR …
…
</info>
</bookInfo>
</m:GetBookInfoResponse>
</SOAP:Body>
</SOAP:Envelope>
SD - 41
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.
SD - 42
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.
SD - 43
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.
SD - 44
Modelo de referência
O modelo de referência CORBA identifica três categorias de
objectos presentes num sistema distribuído CORBA:
Objectos de
Aplicações
Facilidades CORBA
Facilidades verticais
Comércio
Electrónico
Telecomunicações
(p/ Operadoras)
Saúde
…
Facilidades horizontais
Tempo
Agentes
…
Object Request Broker (ORB)
Naming, Trader
Eventos, Notificação
Segurança
Transacções
…
Serviços CORBA
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.
SD - 45
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.
SD - 46
Arquitectura CORBA
Não existe um objecto ORB num sistema real.
A arquitectura CORBA define como
funcionalidade de ORB num sistema real.
é
realizada
a
A figura representa os componentes principais da arquitectura
CORBA
Repositório
Interfaces
Repositório
Implementações
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.
SD - 47
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.
SD - 48
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 "multithreaded" (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.
SD - 49
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.
SD - 50
Serviços CORBA
Serviço
Descrição
Facilidades para agrupar objectos em listas, filas,
Colecção
conjuntos, etc.
Facilidades para pedir colecções de objectos de
Query
uma maneira declarativa
Facilidades para permitir acessos concorrentes a
Concorrência
objectos partilhados
Transacções planas e encadeadas na chamada de
Transacções
métodos sobre múltiplos objectos
Facilidades para comunicação assíncrona através
Eventos
de eventos
Facilidades avançadas para comunicação
Notificação
assíncrona baseada em eventos
Externalização Facilidades para serializar e reconstruir objectos
Facilidades para criar, apagar, copiar e mover
Ciclo de vida
objectos
Licenciamento Facilidades para acrescentar licenças a objectos
Facilidades para nomear objectos a nível de
Nomes
sistema
Facilidades para associar pares atributo - valor a
Propriedades
objectos
Facilidades para publicar e procurar os serviços
Trading
oferecidos por objectos baseado em atributos
Persistência
Facilidades para guardar objectos persistentes
Facilidades para definir relacionamentos entre
Relacionamento
objectos
Mecanismos para canais seguros, autorização e
Segurança
auditoria
Fornece o tempo corrente com a margem de erro
Tempo
especificada.
SD - 51
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 Semântica
RPC de falhas
Descrição
Síncrono At-most- O cliente bloqueia-se até que seja retornada
once
uma resposta ou uma excepção
One-way Melhor
esforço
O cliente continua imediatamente sem
esperar pela resposta do servidor
Síncrono At-most- O cliente continua imediatamente e pode
diferido once
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.
SD - 52
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.
canal eventos
fornecedor
consumidor
notificação
notificação
procurador
consumidor
notificação
procurador
fornecedor
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.
SD - 53
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);
SD - 54
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:
void sendpoll_add(in int i, in int j);
void replypoll_add(out int ret_val, out int k);
SD - 55
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
Request
Reply
Cliente
Servidor
LocateRequest
Cliente
LocateReply
Servidor
CancelRequest
Cliente
CloseConnection Ambos
MessageError
Ambos
Fragment
Ambos
Descrição
Contém um pedido de invocação
Contém a resposta a uma invocação
Contém um pedido sobre a localização
exacta do objecto
Contém informação sobre a localização
de um objecto
Indica que o cliente já não espera a
resposta
Indica que a ligação vai ser fechada
Contém informação sobre um erro
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.
SD - 56
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
SD - 57
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
SD - 58
Exemplo de activação de um objecto CORBA em C++:
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
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.
SD - 59
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.
SD - 60
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:
SD - 61
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
B
ShapeList
C
D
E
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).
contexto nomes inicial
XX
P
R
contexto nomes inicial
V
S
Q
SD - 62
T
U
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.
SD - 63
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.
SD - 64
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).
SD - 65
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.
SD - 66
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.
SD - 67
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.
SD - 68

Acetatos sobre Sistemas distribuídos

Transcrição

Documentos relacionados

O apriorismo kantiano Documento PDF

Ler mais

『代理"香港郵政通函＂服務』申請表

Formulário de desistência

02.001 - SIB - Tópico 2 - AF3 Resolucao

apresentação - VERTI - Mobiliário e Objectos para escritório

Baixe o descritivo do curso

02 Protohistoria PORTUGUÉS

Helena Eira Neves Anexos: Imponãncia: Alta

objecto do ensino da geometria descritiva