3. Die OSI-Anwendungsschichten

3.1. Die Kommunikationssteuerungsschicht (Schicht 5)

Die Kommunikationssteuerungsschicht dient zur Steuerung des Dialogs zwischen den Teilnehmern und der Synchronisation des Datentransfers. Die Schichte 5, 6, 7 bilden das Anwendungssystem. Die allgemeinen Aufgaben der Schicht 5 (session layer) sind

Die Funktionseinheiten und deren Dienstprimitive der S-Schicht zeigt die folgende Tabelle.

Funktionseinheit Diensprimitiv Token
Kernel S-CONNECT
S-DATA
S-RELEASE
S-U-ABORT
S-P-ABORT
 
Halbduplex S-TOKEN-PLEASE
S-TOKEN-GIVE
Data Token
Duplex keine zusätzlichen  
Negoitiated Release S-RELEASE
S-TOKEN-PLEASE
S-TOKEN-GIVE
Release Token
Expedited Data S-EXPEDITED-DATA  
Minor Synchronize S-SYNC-MINOR
S-TOKEN-PLEASE
S-TOKEN-GIVE
Sync-Minor Token
Major Synchronize S-SYNC-MAJOR
S-TOKEN-PLEASE
S-TOKEN-GIVE
Major/Activity Token
Resynchronize S-RESYNCHRONIZE  
Activity Management S-ACTIVITY-START
S-ACTIVITY-RESUME
S-ACTIVITY-INTERRUPT
S-ACTIVITY-DISCARD
S-ACTIVITY-END
S-TOKEN-PLEASE
S-TOKEN-GIVE
Major/Activity Token

Die Funktionseinheiten werden beim Aufbau einer Sitzung ausgehandelt. Zur Vermeidung von Inkompatibilitäten durch Funktionseinheiten, die beim Partner nicht implementiert sind, wurden 3 Teilgruppen eingeführt:

Basic Combined Subset (BCS): kernel, half-duplex, duplex,
Basic Synchronized Subset (BSS): kernel, half-duplex, negotiated release, typed data, minor synchronize, major synchronize, resynchronize
Basic Activity Subset (BAS): kernel, half-duplex, typed data, capability data exchange, minor sychronize, execptions, activity management.

Protokollmechanismen der Session Layer

3.2. Die Darstellungsschicht (Schicht 6)

Die Aufgabe der Darstellungsschicht (Presentation Layer) ist die Gewährleistung einer einheitlichen Interpretation der Daten in den verschiedenen Teilnehmerrechnern.

Der dafür verwendete Mechanismus umfaßt die Schichten 6 und 7.

Lokale Syntax:

Die Daten werden in den Teilnehmerrechnern verschieden dargestellt. Diese Darstellung wird als lokale Syntax bezeichnet.
Die kommunizierenden Anwendungsinstanzen einigen sich zuerst über die zu verwendende abstrakte Transfersyntax (unter Nutzung der P-Dienste).

Abstrakte (Transfer-) Syntax:

Menge aller Datentypdefinitionen die für das Anwendungsprotokoll (A-Prozesse) verwendet werden. (Festlegung in A-Schicht)
Transfersyntax:
eine der lokalen Syntax (1/2) oder allgemeine konkrete Syntax wird zur Übertragung ausgewählt durch die P-Partner
Presentation Context:
Paar aus abstrakter Syntax und Transfersyntax, bestimmt die Übersetzungsregeln für die Encoder/Decoder
ASN.1

Für die Beschreibung der abstrakten Syntax wird bevorzugt die ASN.1-Notation verwendet (ASN.1 - Abstract Syntax Notation One) (ISO IS 8824).

ASN.1 unterteilt Datentypen in UNIVERSAL (elementare bzw. zusammengesetzte vordefinierte Typen als internationaler Standard), APPLICATION (zusammengesetzte selbstdefinierte einiger Orgnisationen) und PRIVATE (zusammengesetzte selbstdefinierte einer Organisation).

Das folgende Beispiel spezifiziert einen Personaldatensatz in ASN.1.

P.-Stammsatz::= SEQUENCE {
kennungPersonalnummer,
ps-name Name,
adresse Adresse,
familienstand Familienstand,
ehegatte Name OPTIONAL
kinder SEQUENCE OF Kinder-Info DEFAULT { }
}
Kinder-Info ::= SET {
kindname Name,
geboren Datum
}
Name ::= SEQUENCE {
titel VisibleString OPTIONAL,
vornamen SET OF VisibleString,
familienName VisibleString
}
Adresse ::= SEQUENCE {
straße VisibleString,
hausnummer VisibleString,
plz INTEGER,
ort VisibleString,
land VisibleString DEFAULT "D"
}
Personalnummer ::= ANY
Datum ::= IA5String
Familienstand ::= INTEGER {
ledig (0),
verheiratet (1),
geschieden (2),
verwitwet (3)
}

In der P-Schicht haben die Entities die Funktion eines Protokollautomaten (gemäß der gül-tigen Dienstprimitive) mit den Teilkomponenten des Context-Managers und einer Menge von Encoder/Decoder.

3.3. Die Anwendungsschicht (Schicht 7)

Die Aufgabe der Anwendungsschicht (Application Layer) sind die eigentlichen Kommunikationsdienste, die vom Kommunikationssystem im Verbund aller Schichten erbracht werden. Die A-Schicht enthält nicht die End-Nutzer-Anwendung selbst, sondern sie stellt nur Elemente zur Realisierung der Kommunikation bereit.

Eine in diesem Sinne verteilte Anwendung besteht aus einer Kooperation von Anwendungsprozessen. Jeder der A-Prozesse enthält einen individuellen Teil den ALU (Application Layer User) und verwendet Dienste der Schicht 7. Ein A-Prozeß unterteilt sich in ALU (außerhalb von OSI) und eine Anwendungsinstanz (AE) der Schicht 7.

Diese Anwendungsinstanz (application entity, AE) ist der Partner des Anwendungsprozesses in der OSI-Architektur. Sie hat die nachfolgend dargestellte Struktur.

Die Grundelemente der Anwendungsschicht sind die Application Service Elements (ASE), sowie eine Control Function (CF), die das Zusammnewirken der ASE's koordiniert. Das Konglomerat aus ASE's und CF heißt ASO - Application Service Object. Unter den ASE's gibt es eine Reihe von Grunddiensten, die in vielen Anwendungskontexten auftreten. (Diese Dienste werden in früheren Versionen auch als CASE (Common Application Service Elements) bezeichnet.) Dazu gehören:

Das folgende Bild zeigt mögliche ASE-Strukturen:

Höhere Dienstelemente (früher auch als SASE (Special ASE) bezeichnet) sind:

FTAM Filetransfer and Access Method
MHS Message Handling Systems
VTS Virtual Terminal Service
MMS Manufacturing Message Service
TP Transaction Processing
DS Directory Service
Im folgenden wird auf einige dieser Dienste näher eingegangen.

Association Control Service Element (ACSE)

ISO-Standard:
ISO 8649
ISO 8650
Die ACSE ist zuständig für den Auf- und Abbau sowie der Wartung von Verbindungen - sog. Assoziationen - zwischen Anwendungsinstanzen. Eine Assoziation ist eine detailierte Beschreibung der kooperativen Beziehungen zwischen zwei Anwendungsinstanzen in einem Anwendungskontext.

Der Anwendungskontext muß vor der Nutzung von ACSE öffentlich oder privat vereinbart werden. Er muß allen Partnern bekannt sein (Eingeschränkte Verhandlungsmöglichkeiten sind auch in der Aufbauphase möglich). Es ist möglich, innerhalb einer bestehenden Assoziation einen Kontextwechsel vorzunehmen.

Es werden folgende Dienste angeboten (keine Dienstprimitive !!):

A- ASSOCIATE Aufbau einer Assoziation
A- RELEASE Abbau einer Assoziation
A- ABORT Abbruch einer Assoziation
A-P-ABORT Abbruch einer Assoziation durch den Diensterbringer
A-UNIT-DATA Assoziationslose Kommunikation
Bei A-ASSOCIATE werden als Parameter der Anwendungskontext und die Titel der Instanzen bzw. Entities gegeben.

Reliable Transfer Service Element (RTSE)

ISO-Standard:
ISO 9066-1
ISO 9066-2
Der Datenaustausch zwischen Anwendungsinstanzen erfolgt neben der A-UNIT-DATA-Kommunikation durch Nutzung der verbindungsorientierten Datenaustauschmöglichkeiten der Darstellungsschicht. Die Zuverlässigkeit dieser Dienste reicht für viele Anwendungen nicht aus, z.B. elektronische Post. Das führte zur Entwicklung der RTSE. RTSE nutzt ACSE. Es unterstützt den Datentransfer auf einer Assoziation.

Es werden folgende Dienste angeboten:

RT-OPEN Herstellen einer Assoziation zwischen zwei RTSEs
RT-TRANSFER Transfer von APDUs
RT-CLOSE Abbau einer Assoziation
RT-P-ABORT Abbruch der Assoziation durch RTSE-Diensterbringer
RT-U-ABORT Abbruch der Assoziation durch Dienstnutzer
RT-TURN-PLEASE Erbittten oder Sendeberechtigung
RT-TURN-GIVE Weitergabe der Sendeberechtigung

Commitment, Concurrency and Recovery Service Element (CCRSE oder CCR)

ISO-Standard:
ISO 8649
ISO 8650
In verteilten Datenbanken ist die Wahrung der Konsistenz der Datenbestände eine der wichtigsten Aufgaben. Hierzu dient das Transaktionsprinzip. (ACID-Eigenschaft, Atomizität, Consistency, Isolation, Dauerhaftigkeit). Die ASE, die die Durchführung des Transak-tionsprinzips unterstützen, sind das CCRSE (häufig auch nur als CCR bezeichnet) und das TPSE - Transaction Processing TP.

Das CCR nutzt eine 2-Phasen-Commitment-Operation (commitment-Verbindlichkeit):

Remote Operations Service Element RO/ RDA/RPC

Unterstützung und Entwicklung von Client-Server-Applikationen

ISO 9072-1
ISO 9072-2
Die Ausführung von Operationen auf entfernten Rechnern, z.B. Servern, wird durch die ROSE unterstützt. ROSE besitzt keine Transferfunktionen. Hierfür sind andere ASE zu nutzen. ROSE ist kein bestätigter Dienst. ROSE unterscheidet einen synchronen und einen asynchronen Modus.
synchron:
Requestor und Akzeptor verständigen sich, bevor eine Operation ausgeführt werden kann.
asynchron:
Vor der Operationsanforderung ist keine Verständigung zwischen Requestor und Akzeptor erforderlich.
Es werden 5 Operationsklassen unterschieden:
(1) synchron, Rückmeldung im Erfolgs- und Fehlerfall
(2) asynchron, Rückmeldung im Erfolgs- und Fehlerfall
(3) asynchron, Rückmeldung nur im Fehlerfall
(4) asynchron, Rückmeldung nur im Erfolgsfall
(5) asynchron, keine Rückmeldung.
ROSE stellt folgende Dienste zur Verfügung:
RO-INVOKE Initiierung einer Operation
(Parameter:
- Operationsname
- Operationsklasse (1..5)
- Argument
- Invoke-ID
- Linked-ID
- Priorität)
RO-RESULT Übermittlung einer positiven Antwort
RO-ERROR Übermittlung einer negativen Antwort
RO-REJECT-U Abbruch einer Operation durch Benutzer
RO-REJECT-P Abbruch durch Diensterbringer
ROSE kann mit verschiedenen ASEs kombiniert werden, z.B. ROSE und ACSE bzw. ROSE mit RTSE und ACSE. Die Konfigurierung erfolgt über ASN.1-Makros.

RDA (Remote Databank Access) und RPC (Remote Procedure Call) liegen oberhalb von RO, und können RO verwenden

File Transfer Access and Management (FTAM)

ISO-Standard:
ISO 8571
Die Verwaltung von Daten, Datenbasen und Files gehört nicht zum OSI-Kontext, wohl aber der Austausch, der Zugriff und die Verwaltung von Files zwischen kommunizierenden Anwendungen. Hierfür steht die ASE FTAM zur Verfügung. Eine Datei wird in diesem Modell duch folgende Attribute dargestellt: usw. Im folgenden ist das virtuelle Speichermodell dargestellt.

Das virtuelle Datenspeichermodell selbst hat die folgende Struktur.

FTAM-Dienste werden nach dem jeweiligen Anwendungskontext in Regime gegliedert:

Message Handling System (MHS)

CCITT X.400 1984, 1988

MHS ist für den Bereich der elektronischen Post zuständig. Der Nachrichtenaustausch im MHS erfolgt nach dem sogenannten Store-and-Forward-Prinzip (Speichervermittlung). Dem MHS liegt das folgende Modell zugrunde.

UA - User Agent
MTA - Message Transfer Agent
MS - Message Storage
AU - Access Unit

MHS unterscheidet zwei prinzipielle Arten von Nachrichtendiensten für Endnutzer:

Message Transfer (MT):
Nachrichtenaustausch zwischen anwendungsunabhängigen Systemen (UAs). Hier interessiert nur der "Umschlag" der Nachricht (siehe unten) nicht ihr Inhalt.

Interpersonal Messaging (IPM):
Unterstützt die Kommunikation mit bestehenden CCITT- Teletex- und Telematikdiensten. Beim Interpersonal Messaging wird auch die Verantwortung für den Inhalt übernommen. Der IPM nutzt den MT für das Senden und Empfangen der Nachrichten. Der IPM ist der Standarddienst.
MHS unterstützt weiterhin die Arbeit mit Zustellungslisten. Eine Nachricht hat im MHS folgenden festen Aufbau (als Struktur einer IP-Nachricht).

Arten von MHS-Informationen:

Aufgrund des Store-and-Forward-Mechanismus müssen zur Realisierung des MHS die ASE RTSE und ROSE genutzt werden:

Zugangsarten:

Einfachterminalzugang:

PC- bzw. WS-Zugang:

Zugang für lokale Netze (s. u.):

MHS-Management-Domänen:

MHS unterscheidet zwei Domänen-Arten: die öffentlichen und die privaten (siehe Bild oben). Die öffentlichen Domänen werden von einer Organisation der öffentlichen Hand, z.B. der Bundespost betrieben. Sie werden als ADMD (administration management domain) bezeichnet. Die PRMD (private management domain) unterstehen einem privaten Betreiber.

Die Domain-Unterteilung bildet auch die Grundlage für den Aufbau der Adressen, z.B. für die elektronische Post (e-mail). Die X.400-Adresse besteht aus folgenden Komponenten:

c - Country (de für Deutschland),
a - Administration Management Domain (dbp für Deutsche Bundespost),
p - Private Management Domain (uni-magdeburg),
o - Organization (an deutschen Universitäten nicht verwendet),
ou - Organization Unit (Struktureinheit z.B. e-technik),
s - Surname (Name des Briefkastens bzw. Empfängers).
Beispiel:

c=de; a=dbp; p=uni-magdeburg; ou=cs; s=mueller

Domain-Adresse (Internet (s. u.)):

user@hostname[.subdomain[.subdomain]. . . ].domain
Beispiel:
für Universität Magdeburg, Institut für Verteilte Systeme:

name@ivs.cs.uni-magdeburg.de


WWW-Links zu diesem Kapitel: