Alma Mater Studiorum - Universita' di Bologna
Sede di Cesena
Reti di Calcolatori
Applicazioni distribuite OSI
Vedi:
• M.T. Rose, The open book, Prentice Hall, sez. 10 (intro e 10.4),
pagg. 379-380 e 420-440.
• ITU-T, Rec. X.219 - Remote Operations: Model, Notation and
Service Definition.
Copyright © 2006-2014 by Claudio Salati
Lez. 6
1
OSI Upper Layers Infrastructure
• Composta di 3 livelli (del modello di riferimento OSI):
•
Livello 5 - Sessione
•
Livello 6 - Presentazione
•
Livello 7 - Applicazione
• Per quanto ci riguarda il livello di Sessione fornisce un servizio
sostanzialmente equivalente a quello fornito da TCP di Internet:
•
Trasferimento affidabile e trasparente di byte end-to-end tra due
processi ovunque localizzati sulla rete.
•
Setup di un’unica connessione a fronte di due richieste di
apertura di connessione incrociate.
•
Gestione "ben educata" della connessione, ed in particolare
della fase di disconnessione (disconnessione ordinata).
 N.B.: in realta’ il Servizio di Sessione OSI CO e’ a messaggi!
2
Livello di Presentazione
• Il servizio di presentazione fornisce gli strumenti per scambiare
informazione tra due moduli di una applicazione distribuita in modo tale
che il suo significato sia conservato inalterato indipendentemente
• dalla codifica utilizzata per rappresentare l’informazione durante il
trasferimento
• dalla codifica utilizzata per rappresentare localmente l’informazione
sui due moduli / End-System
(per i quali possono essere diversi piattaforma HW, sistema
operativo, linguaggio e sistema di programmazione)
• Problemi elementari di rappresentazione dell’informazione:
• Elaboratori big-endian vs. elaboratori little-endian
• Diversi linguaggi/sistemi di programmazione utilizzano diverse
strutture dati per rappresentare lo stesso tipo di informazione
(e.g. anche i numeri interi!)
• Il valore di sizeof(int) puo’ differire anche in diversi sistemi di
programmazione per uno stesso linguaggio
• Regole di allineamento in memoria delle strutture dati diverse in 3
diversi sistemi di programmazione per uno stesso linguaggio
Informazione vs. sua encodifica concreta
• Interi rappresentati con 4 byte
• Trascuriamo la differenza big-endian vs. little-endian
• Rappresentazione concreta del numero intero senza segno 1093:
• binaria:
0000 0000 0000 0000 0000 0100 0100 0101
• BCD:
0000 0000 0000 0000 0001 0000 1001 0011
• Rappresentazione concreta del numero intero con segno -1093:
• complemento a 2:
1111 1111 1111 1111 1111 1011 1011 1011
• complemento a 1:
1111 1111 1111 1111 1111 1011 1011 1010
• segno+BCD:
1000 0000 0000 0000 0001 0000 1001 0011
• Rappresentazione concreta del numero intero con segno 1:
• complemento a 2:
0000 0000 0000 0000 0000 0000 0000 0001
• complemento a 1:
0000 0000 0000 0000 0000 0000 0000 0001
• Rappresentazione concreta del numero intero con segno - 1:
• complemento a 2:
1111 1111 1111 1111 1111 1111 1111 1111
• complemento a 1:
1111 1111 1111 1111 1111 1111 1111 1110
4
Informazione vs. sua encodifica concreta
• Booleani rappresentati
• alla C, come un intero (su 4 byte)
• tutti a 0, se FALSE
• almeno 1 bit !=0 se TRUE
• alla Pascal, come 1 byte
• 0000 0000 se FALSE
• 0000 0001 se TRUE
5
Sintassi Astratta
• Un dialogo applicativo coinvolge strutture dati (informazioni)
arbitrariamente complesse (e che evolvono nel tempo: e.g. Mail)
message { envelope { source address { sender id, mail address, ... },
list of destination addresses { ... },
cc { ... }, bcc { ... },
date of submissal { ... },
message priority, acknowledge request }
content { date of compilation { ... },
subject { ... },
text { ... } }
attachments { ... }
... }
• Insieme dei tipi di strutture dati coinvolti nel dialogo applicativo tra due
moduli di una applicazione distribuita ::= sintassi astratta
1. Come definire in modo non ambiguo e condiviso una sintassi
astratta?
2. Come trasferire sulla rete una istanza di un tipo di struttura dati
della sintassi astratta (un valore tipizzato) senza perdere
6
informazione?
Risposta 1: Abstract Syntax Notation (ASN)
• Un linguaggio capace di descrivere
• una sintassi astratta
• valori tipizzati appartenenti alla sintassi astratta
(purtroppo, non sempre le ASN supportano questa funzione)
senza introdurre o considerare alcun vincolo machine-dependent e/o
di rappresentazione.
• "A level of indirection is placed between the application protocol and
how a particular (virtual) machine might represent the data exchanged
by that protocol.
A protocol specified using an abstract syntax notation is machine
independent." (Rose)
• In OSI e’ definita un’unica abstract syntax notation: ASN.1.
Nel mondo Internet esistono diversi linguaggi (piu’ o meno) analoghi:
XDR, Corba IDL, XML schema, . . .
• N.B. Java si basa su un principio diverso: tutte le macchine virtuali
Java utilizzano la stessa rappresentazione concreta delle informazioni.
Ma l’approccio Java funziona solo stando all’interno del mondo Java!
7
“Senza vincoli machine-dependent o di rappresentazione”
• Approccio OSI (e un po’ anche C)
• Il range degli interi varia (in matematica e considerando tutti i possibili
linguaggi di programmazione, attuali e futuri) da - a +, e quindi i valori
interi che dobbiamo poter trasferire in rete devono poter essere di lunghezza
variabile.
• Questo ci rende indipendenti dalla sizeof(int) di ogni particolare sistema di
programmazione, ma cosa succede se dobbiamo trattare un valore intero di
dimensione maggiore di quella supportata dal nostro particolare sistema di
programmazione?
•
Approccio Java/XDR
• Anziche’ considerare un solo tipo intero, consideriamo una famiglia (finita) di
tipi interi, ciascuno corrispondente ad un sub-range diverso degli interi della
matematica: ogni applicazione sceglie di utilizzare i particolari elementi della
famiglia che meglio si adattano ai suoi requisiti.
• Ogni tipo avra’ sizeof() diversa ma fissa, e sceglieremo dei subrange
corrispondenti a sizeof() effettivamente significative nei sistemi di
programmazione reale, e.g. sizeof()=1, 2, 4, 8.
• Diversi sistemi di programmazione dovranno attrezzarsi per gestire tutti
questi diversi sottotipi.
• Anche questa strategia ci rende indipendenti dalla sizeof(int) dei
8
particolari sistemi di programmazione ed e’ piu’ semplice ed efficiente.
Risposta 2: Transfer Syntax Notation
• Lo scopo di una transfer syntax notation e’ di rappresentare in
modo non ambiguo i valori dei tipi di strutture dati definiti in una
sintassi astratta quando essi sono trasferiti sulla rete.
• Applicare una sintassi di trasferimento consiste in:
1. Prendere una struttura dati locale che in qualche modo
(rappresentazione concreta locale dell’informazione)
rappresenta un valore di un tipo di struttura informativa definito
nella sintassi astratta.
2. Serializzare l'informazione tipizzata (tipo e valore? E’ veramente
necessario trasferire esplicitamente l’informazione di tipo?) in
una stringa contigua di ottetti (secondo una particolare regola di
codifica, la sintassi di trasferimento).
3. Trasmettere in rete al pari remoto la stringa di ottetti (encodifica)
utilizzando i servizi del livello di Sessione/Trasporto.
(e fare il percorso inverso al momento della ricezione di una stringa
contigua di otteti dal livello di Sessione/Trasporto)
9
Transfer Syntax Notation
• Il risultato dell’applicazione della sintassi di trasferimento e’ una
rappresentazione concreta (di rete), che implica convenzioni su:
• Bit e byte order
• Lunghezza dei campi
• Encodifica di quanti di informazione
• ...
• In OSI sono definite diverse transfer syntax notation, ma una sola e’
rilevante, BER (Basic Encoding Rules).
• BER utilizza un approccio TLV. Un valore tipizzato e’ codificato come
una tripla
[ Tag, Length, Value ]
Dove il campo Tag identifica esplicitamente il tipo di struttura dati di
cui si rappresenta una istanza.
• XDR definisce sia una abstract syntax notation che una transfer
syntax notation (quest’ultima non e’ TLV: in particolare non trasmette
mai esplicitamente sulla rete l’informazione di tipo).
10
PDU TCP (segmento)
11
Informazione esplicita di tipo? Esempio TCP
• Tutti i diversi PDU TCP sono varianti di un’unica struttura dati.
 In ricezione la protocol entity TCP conosce a priori la struttura
dell’informazione che riceve.
• Come facciamo a sapere che una certa coppia di byte del segmento
TCP rappresenta un valore di tipo “numero di porta”?
 Lo devo sapere a priori
 In un segmento TCP le prime due coppie di byte rappresentano
la porta mittente e quella destinazione
• Quale e’ la rappresentazione concreta di rete di un numero di porta
nel protocollo TCP?
• Binaria (unsigned)
• 16 bit (2 byte)
• Big-endian
 La devo conoscere a priori
• Anche XDR si basa sull’ipotesi che i tipi di dato atomici come interi e
12
reali abbiano una sintassi di trasferimento di lunghezza fissa.
XDR: Problema (finto)
•
XDR definisce sia una abstract syntax notation che una sintassi di
trasferimento.
•
La transfer syntax notation XDR non e' di tipo TLV.
• Non contiene l'indicazione esplicita del tipo del valore.
• Non contiene l'indicazione esplicita della lunghezza dell'encodifica
(quando cio’ e’ possibile).
• Contiene solo la parte content (V) di una codifica TLV.
•
Ricevendo la stringa di bit
•
0000 0000 0000 0000 0000 0000 0000 0001
come fa il ricevente a discriminare se ha ricevuto il valore intero 1
(con o senza segno?) oppure il valore booleano TRUE?
 In XDR bisogna che il ricevitore conosca a priori il tipo del valore
(il tipo dell’informazione) di cui riceve la encodifica di rete!
• Se so che mi sto aspettando un valore booleano allora so
decodificare il valore ricevuto come TRUE.
13
Accordi a priori
• Detti anche: shared knowledge.
• Non c’e’ niente di strano nel fatto che una protocol entity ricevente
conosca a priori la struttura dell’informazione che deve ricevere.
•
TCP sa che deve ricevere un segmento TCP, di cui conosce a
priori la struttura.
•
UDP sa che deve ricevere un datagram UDP, di cui conosce a
priori la struttura.
•
IP sa che deve ricevere un datagram IP, di cui conosce a priori la
struttura.
• Consentono di semplificare i programmi di rete perche’ riducono le
informazioni che devono essere scambiate e gli accordi che devono
essere presi esplicitamente (dinamicamente).
 Controesempio: quale dei 5 protocolli devono utilizzare due
protocol entity di trasporto connection oriented OSI?
Forse che e’ anche per questo che l’OSI e’ stato un fallimento?
14
Transfer Syntax Notation: esempi
• Valore booleano TRUE
• in BER
e' rappresentato come un (content) byte !=0
tag: BOOLEAN
00
0
1
length
1
content
1
• in XDR:
N.B.: tipo e lunghezza non sono trasportati esplicitamente
0000 0000 0000 0000 0000 0000 0000 0001
• Valore booleano FALSE
• in BER
e' rappresentato come un (content) byte ==0
tag: BOOLEAN
00
0
1
length
1
content
0
• in XDR:
0000 0000 0000 0000 0000 0000 0000 0000
15
Transfer Syntax Notation: esempi
• Valore intero con segno 263
• in BER
tag: INTEGER
00
0
2
length
2
-------- content -------
0000 0001
0000 0111
• in XDR:
Consideriamo il tipo int su 32 bit:
0000 0000 0000 0000 0000 0001 0000 0111
• Valore intero con segno -1
• in BER
tag: INTEGER
00
0
2
length
content
1
1111 1111
• in XDR:
1111 1111 1111 1111 1111 1111 1111 1111
16
Servizi del Livello di Presentazione OSI
• Il Livello di Presentazione combina
•
La capacita' di convertire informazione in stringhe di ottetti (e
viceversa)
•
Con il servizio di tasferimento affidabile di byte offerto dal Livello
di Sessione
per offrire un servizio di trasferimento affidabile di informazione
• La funzionalita’ di conversione dell’informazione da/verso stringhe di
ottetti si articola in:
1. Context Management
in internet non esiste, quando necessario e’ implementato a
Livello 7 o addirittura a Livello Utente
2. Syntax Matching
esiste anche in internet, vedi XDR, IDL, XML Schema, …
•
In realta’ il Servizio di Presentazione puo’ appoggiarsi anche al
Servizio di Trasporto connectionless.
17
Livello di Presentazione OSI: Context Management
•
Nel colloquio tra due moduli di una applicazione distribuita possono
essere utilizzate simultaneamente diverse sintassi astratte
•
Ogni sintassi astratta descrive infatti i PDU di un particolare
protocollo applicativo
•
Ad ogni sintassi astratta possiamo poi appicare (in teoria) una
diversa sintassi di trasferimento
•
Lo scopo del Context Management e' di gestire:
1. Quali sintassi astratte sono usate in un colloquio applicativo
2. Quale sintassi di trasferimento e' associata a ciascuna sintassi
astratta
Ciascuna coppia [1 + 2] e' identificata nel Livello di Presentazione
da un Presentation Context
•
Ogni P-SDU e' associata ad un Presentation Context che identifica
univocamento quale e' il protocollo applicativo cui essa e' relativa.
18
Livello di Presentazione: Syntax Matching
Lo scopo del servizio di Syntax Matching e’ di mappare avanti/indietro
• tra la rappresentazione concreta locale (potenzialmente diversa per
ciascun modulo dell’applicazione distribuita) di un valore della
sintassi astratta e
• la sua rappresentazione concreta sulla rete (comune per tutti i
moduli, e detta quindi "canonica")
internal form
this mapping is strictly a local matter
abstract syntax
this mapping consists of consulting
the presentation context
for the data type and
applying the associated
transfer syntax
transfer syntax
19
Syntax Matching e Sistemi di Programmazione ASN.1
L'utilizzo di una abstract syntax notation formale consente di
automatizzare i due processi di mapping impliciti nel servizio di syntax
matching
Fase 1, off line: ASN.1 compiler
(definisce il mapping internal form  abstract syntax)
input: un modulo ASN.1 che definisce una sintassi astratta
output:
1. La definizione dei tipi di strutture dati locali (e.g. tramite
typedef del C) che devono essere usate per
rappresentare i tipi di strutture dati definiti nella sintassi
astratta
2. Una descrizione tabellare dei tipi di strutture dati della
sintassi astratta e delle corrispondenti rappresentazioni
locali (e.g. tramite variabili const del C)
20
Syntax Matching e Sistemi di Programmazione ASN.1
Fase 2, on line: ASN.1 run-time system (interprete)
(realizza, valore per valore, il mapping internal form  transfer syntax)
input:
1. La descrizione tabellare dei tipi di strutture dati della
sintassi astratta e delle corrispondenti rappresentazioni
locali (output 2 della fase 1)
2. In caso di encodifica (il caso di decodifica e'
simmetrico):
1. una struttura dati locale (e.g. una variabile C) che
rappresenta un valore della sintassi astratta, e
2. l'identita' del relativo tipo di struttura dati ASN.1
output: In caso di encodifica (il caso di decodifica e' simmetrico):
•
la stringa di ottetti che contiene il PDU applicativo (cioe'
il P-SDU) encodificato secondo BER
21
Sistemi di programmazione ASN.1
ASN.1 definition
module.as
ASN.1 compiler
type info:
internal representation
module_info.c
local data structures
module_defs.h
Application Service Element
Application Process
APDU
octetstring
encoder/
decoder
actual data
structures (values)
22
OSI: Livello Applicativo e Applicazioni Distribuite
AP a
AP b
user protocol
user application
O
S
I
L
a
y
e
r
7
user application
application
service
user element
user element
application
ASE #1 ... ASE #n
AE
ASE #1 ... ASE #n
protocol
AE
presentation service
PSAP
PSAP
presentation provider
23
Livello Applicativo e Applicazioni Distribuite
• Una applicazione distribuita e' costituita da diversi Application
Process (AP) che interagiscono tra loro.
• Tutti gli AP sono eseguiti nell'ambiente OSI, possibilmente su
diversi nodi della rete
• Gli aspetti comunicazionali di un AP sono rappresentati dalla sua
Application Entity (AE), che e' una istanza del Livello Applicativo
• Un AP puo' presentare diversi aspetti comunicazionali, e quindi
includere diverse AE
(noi consideriamo solo il caso di AP con una sola AE)
• Una AE e' composta da un insieme di Application Service
Element (ASE)
• Un ASE e' un modulo che realizza una specifica funzionalita' del
Livello Applicativo OSI, e.g. il supporto RPC
• Ogni ASE e' associato ad una sintassi astratta che definisce il
protocollo con cui l'ASE interagisce con il suo pari remoto
24
ASE
• ASE generici: progettati per essere utilizzabili in diversi application
context
• ACSE, Association Control Service Element
• ROSE, Remote Operations Service Elelment
• CCR, Commitment, Concurrency and Recovery
• …
• ASE specifici: progettati per essere utilizzati in uno specifico
application context, anche se puo' capitare che siano utilizzabili in
contesti diversi
• CMISE, Common Management Information Service Element
• X.400, posta elettronica
• X.500, Name Service
• FTAM, File Transfer, Access and Management
• MMS, Manufacturing Message System
• …
25
AE, ASE, Application Context
• Ciascun ASE ha interazioni remote solo con il proprio ASE
corrispondente
• Ogni ASE dell'AE e' associato ad un diverso Presentation Context,
cosi' che ciascun A-PDU puo' essere de/codificato correttamente e
consegnato all'ASE appropriato
• Due AE che interagiscono tra loro devono essere composte
esattamente con gli stessi ASE
• In realta', per poter interagire tra loro due AE devono essere
istanze di un medesimo Application Context (AC)
• Un AC identifica un insieme di ASE piu' l'insieme di regole che
governano le loro interazioni:
• esso costituisce la ricetta con cui e' strutturato e funziona un AE
che ne e' una istanza
• regola quindi anche il comportamento dello user element
dell'AE, e le sue interazioni con gli ASE e, tramite loro, con lo
user element remoto
• Ogni AC deve essere registrato presso ISO, che gli assegna un 26
identificatore univoco
Application Context
• Quali ASE compongono l'AE
(e quindi quali sintassi astratte vengono utilizzate)
• Significato dello user element
• Discipline di interazione degli ASE tra loro e con lo user element
(e.g. un ASE puo' fare uso o meno dei servizi di un altro ASE)
• Discipline di comportamento degli ASE
(e.g. quali RPC sono chiamabili dall'AE che apre l'associazione e
quali dall'altra)
• Quale e' la sintassi di trasferimento associata a ciascuna sintassi
astratta
 Due AE, per interoperare correttamente, devono avere identico AC,
cioe' devono essere dello stesso tipo
27
Internet: Livello Applicativo e Applicazioni Distribuite
•
La struttura del Layer Applicativo e delle applicazioni distribuite nel
mondo internet e’ simile (ma non uguale!) a quella del mondo OSI.
•
La differenza principale e’ che di norma ogni ASE internet utilizza un
proprio PSAP, e che ogni PSAP e’ mappato su un proprio socket
(TSAP).
•
•
In realta’ il Layer di Presentazione non e’ nemmeno realizzato
come un vero e proprio layer ma solo come un insieme di
funzioni capaci di svolgere il syntax matching per un certo
protocollo applicativo.
•
Non esiste quindi nemmeno un vero e proprio PSAP e un ASE si
affaccia alla rete direttamente su un TSAP.
•
Lato server, e’ quindi un TSAP che identifica un servizio.
Nel caso di AE costituiti da piu’ di un ASE la funzione di context
management e’ svolta da un equivalente del modulo user element.
28
Internet: Livello Applicativo e Applicazioni Distribuite
•
In realta’ molte applicazioni internet sono costruite senza l’utilizzo
esplicito dei servizi dei Layer di Presentazione e di Applicazione.
 Non e’ che le funzionalita’ fornite dai Layer di Presentazione e di
Applicazione non siano presenti.
 E’ solo che le funzionalita’ fornite dai Layer di Presentazione e di
Applicazione sono annegate all’interno dell’applicazione utente.
•
I PDU applicativi sono descritti direttamente in termini di
rappresentazione concreta di rete tramite mappe di byte o come
sequenze di stringhe di caratteri.
 Non ne viene fornita una sintassi astratta, e il Layer di
Presentazione non e’ isolato (se non a livello di
programmazione) dal Layer di Applicazione e dall’applicazione
utente.
•
Vedi per contrasto gli esempi di architettura implementativa
canonica, basata sui principi di layerizzazione OSI, rappresentati
dalle Esercitazioni 2 e 3.
29
Internet: Livello Applicativo e Applicazioni Distribuite
User Application
Application
ASE.1
ASE.2
Presentation
Layer.1
TSAP.1
Layer
Presentation
Layer.2
TSAP.2
ASE.n
...
Presentation
Layer.n
TSAP.n
Transport Layer
30
Esempio: applicazione di network management
• Due AP principali, Manager e Agent
• AE per il dialogo tra Manager-Agent:
• ASE SNMP
• ASE FTP (upload e download di log file, codice eseguibile, …)
• Altri AE/ASE presenti su Manager
• SMTP, per informare gli operatori di problemi rilevati: verso
mail server
• FTP (upload e download di log file, codice eseguibile, …):
verso file server
• HTTP per interfaccia uomo-macchina: verso browser
31
Indirizzamento di un AE
• Ogni AE (e quindi ogni AP) puo' avere un nome (Application
Entity Title, AET)
• Un AET non e' utilizzabile direttamente per indirizzare l'AE
• Per indirizzare una AE (e quindi un AP) si utilizza il suo PSAP: il
PSAP di una AE e' univoco sulla rete OSI
• Un AET puo' essere tradotto nel corrispondente PSAP da un name
server (e.g. X.500)
 Struttura di un PSAP
NSAP
T-SEL
S-SEL
P-SEL
 NSAP  NET + N-SEL
(nel mondo IP equivale sostanzialmente alla coppia IP address
+ transport protocol type)
32
ACSE, Association Control Service Element
• ACSE e' l'ASE responsabile della gestione dell'associazione tra
due AE
• Percio' tutti gli application context OSI devono contenere ACSE
• Una associazione e' una connessione di livello applicativo tra due
AP, che sono indicati come l'initiator e il responder
• Durante la creazione dell'associazione ACSE permette anche di
• Validare l'application context di initiator e responder
• Supportare l'autenticazione delle controparti
• Negoziare i profili utilizzati dagli ASE dell'application context
33
ACSE: servizi e protocollo
servizio
primitive
PDU
P-service
A-ASSOCIATE
req/ind
resp/conf
AARQ
AARE
P-CONNECT
A-RELEASE
req/ind,
resp/conf
RCRQ
RCRE
P-RELEASE
A-ABORT
req/ind
ABRT
P-U-ABORT
A-P-ABORT
ind
P-ABORT
34
ROSE, Remote Operations Service Element
• ROSE fornisce i meccanismi di base per supportare RPC
• Fornisce l'equivalente delle istruzioni CALL (RO-INVOKE) e
RETURN (RO-RESULT) in ambiente distribuito
• Le generalizza in modo analogo a quanto fa Unix per il supporto
della programmazione concorrente con le system call fork() e
exit() / wait()
• Consente quindi di avere
• Procedure non confermate
• Chiamate non bloccanti
• Esecuzione concorrente da parte di un chiamante di piu'
procedure chiamate
(nota che cio' rende necessario potere individuare quale e' la
procedura chiamata che e' terminata:
 ogni chiamata e' battezzata con un invokeID univoco)
• Ritorni differenziati di successo e di errore
35
ROSE
• Semantica RPC supportata da ROSE: exactly-once
• Nei sistemi di programmazione distribuita name binding e type
checking sono effettuati dinamicamente
• Non e' ROSE che e' responsabile di name binding e type checking,
ma il cliente di ROSE, chi usa RO-notation per definire i prototipi
delle RPC che vuole implementare
• RO-notation fornisce un linguaggio per scrivere lo header file di un
modulo distribuito basato sui servizi di ROSE
• La definizione dell'interfaccia di una operazione remota tramite ROnotation e' puramente sintattica (signature)
• La semantica dell'operazione remota (il corpo della procedura che
implementa l'operazione remota) e' de/scritta in linguaggio
convenzionale (e.g. C)
36
ROSE: Remote Operations Model (X.219)
• Operations invoked by one AE (the invoker) are performed by the other
AE (the performer).
• Operations may be classified according to whether the performer of an
operation is expected to report its outcome:
• in case of success or failure
a result reply is returned if the operation is successful, an error reply
is returned if the operation is unsuccessful;
• in case of failure only
no reply is returned if the operation is successful, an error reply is
returned if the operation is unsuccessful;
• in case of success only
a result reply is returned if the operation is successful, no reply is
returned if the operation is unsuccessful;
• not at all
neither a result nor an error reply is returned, whether the operation
37
was successful or not.
ROSE: Remote Operations Model (X.219)
• Operations may also be classified according to two possible operation
modes:
• synchronous, in which the invoker requires a reply from the
performer before invoking another operation;
• asynchronous, in which the invoker may continue to invoke further
operations without awaiting a reply.
• The following Operation Classes are defined:
• Operation Class 1: Synchronous, reporting success or failure (result
or error).
• Operation Class 2: Asynchronous, reporting success or failure
(result or error).
• Operation Class 3: Asynchronous, reporting failure (error) only, if
any.
• Operation Class 4: Asynchronous, reporting success (result) only.
• Operation Class 5: Asynchronous, outcome not reported.
38
ROSE: Remote Operations Model (X.219)
• The Operation Class of each operation has to be agreed between
application entities (e.g. in an Application Protocol Recommendation).
• In some cases it is useful to group operations into a set of linkedoperations which is formed by one parent-operation and one or more
child-operations.
• The performer of the parent-operation may invoke none, one, or
more child-operations during the execution of the parent-operation.
• The invoker of the parent-operation is the performer of the childoperations.
• A child-operation may be a parent-operation of another set of linkedoperations in a recursive manner.
39
ROSE: Linked operations (X.219)
40
ROSE: servizi e protocollo
servizio
primitive
PDU
P-service
RO-INVOKE
req / ind
ROIV
P-DATA
RO-RESULT
req / ind
RORS
P-DATA
RO-ERROR
req / ind
ROER
P-DATA
RO-REJECT-U
req / ind
RORJ
P-DATA
RO-REJECT-P
ind
RORJ
P-DATA
41
ROSE: servizio RO-INVOKE (X.219)
• The RO-INVOKE service is used by one ROSE-user (the invoker)
to cause the invocation of an OPERATION to be performed by the
other ROSE-user (the performer).
• This service is a non-confirmed service.
42
ROSE: servizio RO-INVOKE (X.219)
• Operation-value is the identifier of the operation to be invoked.
• Argument is the argument of the invoked operation.
• Invoke-ID identifies the request of a RO-INVOKE service and is
used to correlate this request with the corresponding replies or the
invocation of linked child-operations.
Parameter name
Request
Indication
Operation-value
M
M (=)
Operation-class
U
Argument
U
C (=)
Invoke-ID
M
M (=)
Linked-ID
U
C (=)
Priority
U
43
ROSE: servizio RO-INVOKE (X.219)
• Operation-class defines whether a synchronous or an
asynchronous reply is expected and the nature of the expected
reply, i.e. result and/or error or none.
• If Linked-ID is present, the invoked operation is a child-operation
and the parameter identifies the invocation of the linked parentoperation.
• The value is that of the Invoke-ID parameter of the RO-INVOKE
indication primitive of the parent-operation.
• Priority defines the priority assigned to the transfer of the
corresponding APDU with respect to the other APDUs to be
exchanged between the AEs.
• The lower the value, the higher the priority.
• If several APDUs with the same priority are awaiting transfer,
they are transferred "first in, first out".
44
ROSE: servizio RO-RESULT (X.219)
• The RO-RESULT service is used by a ROSE-user to reply to a
previous RO-INVOKE indication in the case of a successfully
performed operation.
• This service is a non-confirmed service.
45
ROSE: servizio RO-RESULT (X.219)
• Operation-value is the identifier of an invoked and successfully
performed operation. The value is that of the corresponding ROINVOKE indication primitive. This parameter shall be present only if
the Result parameter is present.
• Result is the result of an invoked and successfully performed
operation.
• Invoke-ID identifies the corresponding invocation. The value is that
of the corresponding RO-INVOKE indication primitive .
Parameter name
Request
Indication
Operation - value
C
C(=)
Result
U
C(=)
Invoke - ID
M
M(=)
Priority
U
46
ROSE: ritorni di errore
• RO-REJECT-P
generato dal provider ROSE in caso di ricezione di un PDU
malformato
• RO-REJECT-U
generato dal cliente ROSE (e.g. CMISE) per indicare che ha
riscontrato un errore di protocollo nella gestione della RPC e
quindi, ad es. non ha potuto mettere in esecuzione la procedura
richiesta. Ad es.
• fallimento nel name binding
• fallimento nel type checking
• RO-ERROR
generato dall'applicazione finale che non e' riuscita a portare a
termine con successo l'esecuzione dell'RPC (perche', ad es., non
e' riuscita ad aprire un file indicato).
La procedura remota e' pero' stata messa correttamente in
47
esecuzione, ed ha eseguito fino al termine
ROSE: servizio RO-ERROR (X.219)
• The RO-ERROR service is used by a ROSE-user to reply to a
previous RO-INVOKE indication in the case of an unsuccessfully
performed operation.
• This service is a non-confirmed service.
48
ROSE: servizio RO-ERROR (X.219)
• Error-value identifies the error that occurred during the execution
of the operation.
• Error-parameter provides additional information about the error .
• Invoke-ID identifies the corresponding invocation. The value is that
of the corresponding RO-INVOKE indication primitive .
Parameter name
Request
Indication
Error-value
M
M(=)
Error-parameter
U
C(=)
Invoke-ID
M
M(=)
Priority
U
49
ROSE: servizio RO-REJECT-U (X.219)
• The RO-REJECT-U service is used by a ROSE-user to reject a
request (RO-INVOKE indication) of the other ROSE-user if it has
detected a problem.
• The RO-REJECT-U service may also be used by a ROSE-user to
reject a reply (RO-RESULT indication, RO-ERROR indication) from
the other ROSE-user.
• This service is a non-confirmed service.
50
ROSE: servizio RO-REJECT-U (X.219)
• Reject-reason specifies the reason for rejection as follows:
• Vedi pagina seguente
• Invoke-ID identifies identifies the corresponding invocation.
• The value is that of the rejected RO-INVOKE indication, RORESULT indication, or RO-ERROR indication primitive.
Parameter name
Request
Indication
Reject-reason
M
M(=)
Invoke-ID
M
M(=)
Priority
U
51
ROSE: servizio RO-REJECT-U (X.219)
• Reject-reason: possibili valori:
• Invoke-problem: user-reject of an RO-INVOKE indication with values:
• duplication-invocation
• unrecognized-operation
• mistyped-argument
• resource-limitation
• initiator-releasing
• unrecognized-linked-ID
• linked-response-unexpected
• Return-result-problem: user-reject of an RO-RESULT indication with
values:
• unrecognized-invocation
• result-response-unexpected
• mistyped-result
• Return-error-problem: user-reject of an RO-ERROR indication with values:
• unrecognized-invocation
• error-response-unexpected
• unrecognized-error
• unexpected-error
• mistyped-parameter
52
ROSE: servizio RO-REJECT-P (X.219)
• The RO-REJECT-P service is used to advise a ROSE-user of a problem
detected by the ROSE-provider. This service is a provider-initiated
service.
• The related service structure consists of a single service-primitive.
53
ROSE: servizio RO-REJECT-P (X.219)
• Invoke-ID identifies the corresponding invocation.
• Returned-parameters contains the parameters of the RO-INVOKE
request, RO-RESULT request, RO-ERROR request or RO-REJECT-U
request primitives, if the corresponding APDU could not be transferred
by the ROSE-provider. This parameter and the parameter Reject-reason
are mutually exclusive.
• Reject-reason specifies the reason for rejection as follows
• General-problem: provider-reject of an APDU with values:
• unrecognized-APDU
• mistyped-APDU
• badly-structured-APDU
Parameter name
Indication
Invoke-ID
O
Returned-parameters
O
Reject-reason
O
54