Im Folgenden werden Teile der diesem Beispiel entsprechenden XML-Eintragungen vorgestellt und beschrieben.
Die Grundidee ist, daß man primär Kunden und Services benennen muß. Diese werden dann um spezielle Policy-Regeln erweitert oder in Gruppen zusammengefaßt.
Beispielkonfiguration für Services:
<service name="drucker-papier" system="testhotel" type="printer" protocol="lp" area="network" server="lpr1" domain="hotel.de" alt="lokaler Printserver fuer Papierdrucke"> <INFO>Postscript</INFO> <INFO>3. Stock</INFO> <INFO>Zimmer 310</INFO> </service> |
Dies ist der einfache Papierdrucker. Er steht im Hotel, welches mit
"testhotel" bezeichnet wurde, gehört in die Kategorie
"printer" und ist
über das lineprotocol (lp) ansprechbar. Der Drucker ist ein
Netzwerkdrucker, dessen Name lpr1 ist mit der Domain
hotel.de. Es handelt
sich um einen lokalen Druckservice für Papierdrucke. Als
Zusatzinformationen zu diesem Service werden angeboten:
|
|---|---|
<service name="fax" system="testhotel" type="fax" area="network" server="fax" domain="hotel.de" alt="Allgemeiner Fax-Service"> </service> |
Das Fax ist ebenfalls ein netzweiter Dienst. Er ist abfragbar über den
Server fax.hotel.de. Eine Nummer, unter der man diesem Fax eine Nachricht
senden kann, könnte wahlweise als <INFO> oder im Bereich für die Option
gw, incomingip oder outgoingip angegeben werden. Ein
<INFO>-Eintrag wäre
die sinnvollste Möglichkeit, da es denkbar ist, daß mehrere Telefonnummern
auf diesen Faxserver umgeleitet werden, aber nur ein Eintrag in den
alternativ verwendbaren Attributen vorgesehen ist. |
<service name="mail" system="testhotel" type="email" protocol="POP3" area="network" server="mail" domain="hotel.de" alt="lokaler Mailserver"> </service> |
Der Email-Service wird analog den anderen Services definiert. |
Bei der Beschreibung der Services wurde das allgemeine Klassenmodell etwas vereinfacht. In der Service-Beschreibung wird direkt die Server-Beschreibung integriert. Diese Maßnahme vereinfacht das Erstellen des Konfigurationsfiles und erleichtert somit die Lesbarkeit. Eine Zuordnung Service zu Server ist weiterhin möglich. Allerdings nur indirekt über die Auswertung des Attributes type.
Die folgende Tabelle kommentiert Beispiele für Service-Gruppen. Zu Gruppen kann man nur Services zusammenfassen, welche definiert wurden.
<group name="standard"> <insert name="drucker-papier" type="service"> <insert name="fax" type="service"> </group> |
Dies ist die Service-Gruppe Standard, ihr werden die bereits definierten Services Fax und Papierdruck zugeordnet. Ein Nutzer, dem diese Gruppe zugeordnet wird, kann die hier angegebenen Services nutzen. |
<group name="multimedia"> <insert name="mail" type="service"> <insert name="news" type="service"> <insert name="internet" type="service"> </group> |
Der Gruppe Multimedia werden die Services mail, news und internet zugeordnet. |
In <INSERT> muß in diesem Fall type="service"
angegeben werden. Dies
zeigt an, welcher Art diese Gruppe ist. Ebenfalls zulässige Gruppierungen
können <CLIENT> betreffen sowie in sich wieder <GROUP>
und <POLICY>.
An dieser Stelle könnte man zusätzliche Policy-Definitionen den einzelnen Services zuweisen. Eine solche Policy-Anweisung könnte beispielsweise wie folgt aussehen:
<POLICY name="nacht" alt="testpolicy für Nachtbetrieb" descr="Verbot zur Nutzung des Druckservices zwischen 22:30 Uhr und 6:00 Uhr" keywords="USAGE"> <PR name="nachtruhe" ena="TRUE"> <PC value="between 22:30 and 6:00"> <PA value="deny drucker-papier"> </PR> </POLICY> |
Dabei ist die Syntax der Attribute value in <PC> und <PA> frei
erfunden. Eine Verwendung von <TIME> könnte die Gültigkeit dieser Regel
weiter einschränken, z.B. ausschließlich auf Wochenenden. |
Die letzte Tabelle zeigt Beispiele für Kundenkonfigurationen. Dabei wird ein Kunde als Client aufgefaßt, der keine eigenen Services anbietet.
<client username="u1" passwd="02oawyZdjhhpg" hostname="kunde1" hostIP="dynamic" group="" alt="User Eins vom Testhotel"> <time time="19990101000000:19991231235959" moym="110011100011" dowm="1111100" todm="090000:180000" alt=""> <qos sname="#drucker-papier" free="10"> <insert name="#multimedia" type="group"> </client> |
Ein Kunde benötigt allgemein seine Zugangsinformationen wie Username und
Passwort. Weiterhin kann er einen festen Hostnamen zugewiesen bekommen.
Die Angabe in hostIP gibt an, ob er seine IP-Adresse dynamisch zugewiesen
bekommt.
Ist dies nicht der Fall steht die zu vergebende Adresse an dieser Stelle.
Die Gültigkeitsdauer dieser Nutzer-Definition wird mit time angegeben. Hat
der Nutzer spezielle Service-Vereinbarungen, wird dies in <QOS>
vermittelt. Erlaubte Services können entweder direkt als
<INSERT name="#Servicename" type="service">angegeben werden oder als Service-Gruppe mit: <INSERT name="#Service-Gruppe" type="group"> |
<client username="u3" hostname="kunde3" hostIP="192.168.1.100" group="Konferenz" alt="User drei vom Testhotel"> <time time="19991101:20000229" moym="110000000011" alt=""> <insert name="#standard" type="group"> </client> |
Nebenstehend das Beispiel für einen Nutzer, der eine feste IP-Adresse erhält. |
Auf diese Art und Weise kann man alle wichtigen Informationen für das Managementsystem codieren. Der Vorteil besteht darin, daß diese Form der Codierung menschen- und maschinenlesbar ist. Der Administrator ist nicht auf grafische Anzeige- und Erfassungs-Programme angewiesen und die Sprache ist verhältnismäßig einfach zu erlernen.
Die Korrektheit der Eintragungen kann man von Programmen - sogenannten Validators - automatisch prüfen lassen.
Soll diese Technik in einem nicht-technischen Umfeld eingesetzt werden, kann man zusätzlich ein grafisches Interface mit vorgefertigten Eingabefeldern und automatischer Prüfung auf Korrektheit der Eingaben anbieten. Dies würde dann auch sicherstellen, daß die Eingaben korrekt sind und eine zusätzliche Überprüfung könnte entfallen.