4.5.2 Darstellung der Regelsyntax

Um diese Angaben so einfach wie möglich halten zu können, soll eine Sprache verwendet werden, die leicht in maschinell zu verarbeitende Regeln umzusetzen ist. Andererseits soll sie aber auch für den menschlichen Benutzer noch les- und schreibbar sein.

Aus diesen Gründen wurde sich für XML als Grundlage für diese Beschreibungssprache entschieden. XML wurde für die Entwicklung von Sprachen, die Regeln definieren und Zusammenhänge beschreiben, entwickelt und ist deswegen sehr gut für diese Zwecke geeignet. Der Vorteil von XML gegenüber einer eigenen proprietären Entwicklung liegt darin, daß Außenstehende sich nicht mit einer völlig fremden Beschreibung auseinander setzen müssen, sondern das bekannte Regelwerk von XML verwenden können. Somit sind die mit XML erstellten Regeln schneller nachvollziehbar. Weiterhin sind bereits fertige Parser für XML-generierte Sprachsets erhältlich.

Das hier verwendete Prinzip ist bereits von der HTML-Syntax her vertraut. Dabei werden Angaben mit Hilfe von Tag s gemacht. Ein solches Tag hat ein Beginn-Tag sowie meistens ein End-Tag. Allerdings müssen End-Tags nicht immer angegeben werden. Zu manchen Tags existiert auch kein End-Tag. Im Beginn-Tag kann man zusätzlich Attribute angeben. Diese sind von der Form name="Wert".

Beispiel für ein Tag:

Beginn-Tag: <TAG>
End-Tag:   </TAG>
Attribute: <TAG name1="wert1" name2="wert2">

Dabei beschreibt der Begriff TAG, um was es sich handelt, also als was die folgenden Werte vom Leser zu interpretieren sind.

XML benötigt eine allgemeine Definition, diese ist in dieser Arbeit in der Beschreibungssprache DTD abgefaßt. In Zukunft kann man auch UML statt DTD verwenden.

Für den hier zu verwendenden Zweck benötigt man Möglichkeiten, um folgende Angaben in XML vornehmen zu können (siehe auch Abb. 4.15:

• Beschreibung eines Nutzers
• Beschreibung eines Services
• Beschreibung einer Policy
• Gruppenbildung von Nutzern, Services, Policies oder Gruppen.
• Angabe von Gültigkeitszeiträumen
• Angaben von Sondervereinbarungen (QOS)
• Gruppierung von Gültigkeitsbereichen, also abgeschlossenen logischen Systemen

  

Abbildung 4.15: Policy: allgemeines Object-Modell

Aus diesen Anforderungen kann man eine Grammatik entwickeln. Das Objektmodell dieser Entwicklung stellt Abbildung 4.16 grafisch dar.

  

Abbildung 4.16: Object-Modell der DTD

Die Ausgangsklasse ist DOMAIN . Sie besitzt die Unterklassen:

• POLICY  welche selbst als direkte Unterklassen die Klassen PR  (PolicyRule) mit deren Unterklassen PC  (PolicyCondition) und PA  (PolicyAction) besitzt. Instanzen der Klasse Policy kann von den Klassen CLIENT  SERVICE  und GROUP  referenziert werden.
• GROUP  besitzt als direkte Unterklasse die Klasse INSERT  welche ebenfalls von den Klassen CLIENT  und SERVICE  aus referenziert werden kann.
• TIME  besitzt selbst keine weiteren Unterklassen. Dafür werden Instanzen von ihr von den Klassen PR  und CLIENT  referenziert.
• CLIENT  beschreibt das Profil eines speziellen Kunden. CLIENT  hat als direkte Unterklasse die Klasse QOS  in der spezielle Service-Vereinbarungen für diesen Kunden vermerkt werden können. Weiterhin referenziert die Klasse CLIENT  Instanzen der Klassen TIME , INSERT  und POLICY . Damit ist es möglich Vereinbarungen, die von allgemeinen Regeln abweichen direkt beim Kundenprofil zu vermerken.
• SERVICE  hat zwei weitere Unterklassen und sie referenziert Instanzen der Klasse Policies. Damit werden spezielle Zusatzpolicies für genau diesen Service angegeben. Ihre Unterklasse ADMININT  dient der Angabe wie das Administrationsinterface dieses Services angesprochen werden soll. Die Unterklasse INFO  kann zusätzliche Informationen zum Service vermitteln.
• FILE  ist eine Klasse, die es erlaubt, Definitionen, die speichertechnisch in einem anderen File abgelegt sind, quasi an dieser Stelle zu übernehmen. Die Klasse hat somit auch keinerlei Unterklassen.

Ein Nebeneffekt, der bei der Entwicklung des Regelsets aufgetreten ist, ist der, daß viele Policy-Angaben bereits direkt bei der Angabe der jeweiligen Definition enthalten sind. Dies verkürzt die zu erstellende Datenmenge bei der Verwendung sehr einfacher Policy-Regeln erheblich, da die Darstellung einer kompletten Policy-Regel sehr umfangreich ist.