4.2 Planung und Implementation

Interoperabilität und Offene Systeme

• Interoperabilität (interoperability)

  • Fähigkeit zum Zusammenwirken verschiedener (Software-)Produkte
  • wesentliches Kriterium bei der Auswahl von Software

• Offene Architektur (open architecture)

  • offene Protokolle und Fileformate
  • in frei zugänglichen Foren dokumentiert
  • implementierbar durch beliebige Hersteller
  • interoperabel, integrierbar

• Proprietäre Architektur (proprietary architecture)

  • proprietäre Protokolle und Fileformate sind i.d.R. nicht interoperabel
  • Änderungen werden nicht angekündigt
  • Nutzung kann lizenzpflichtig sein
    die Nutzung offengelegter Verfahren, Protokolle, ... kann auch lizenzpflichtig sein (z.B. auf Grund von Patenten)
  • Ziel: Marktbeherrschung

• Protokolle und Produkte

  • Protokolle sind Texte
    Beschreibung von Datenstrukturen und Abläufen
  • Software-Produkte implementieren Protokolle
    weit verbreiteter Irrtum: ein Produkt steht für ein Protokoll (z.B. OutlookExpress == E-Mail)

• Protokoll-Umsetzer (protocol gateways)

  • Umsetzer zwischen verschiedenen (häufig: proprietären und offenen) Protokollen
  • zusätzliche Dienste: erfordern Planung, Ressourcen; erhöhen Komplexität, Fehleranfälligkeit; beeinflussen Performance, Zuverlässigkeit

  Wenn ein Hersteller protocol gateways für sein Produkt anbietet, ist das ein deutliches Anzeichen für ein proprietäres Protokoll.
• Verbesserte oder erweiterte Standards

  • gibt es nicht
  • Standard wird implementiert und Interoperabilität wird zerstört: Marktbeherrschung

• Auswahlkriterien

  • Kunden: Eigenschaften (features), Komfort
  • SysAdmins: einfach zu administrieren
  • offene Protokolle und Fileformate ermöglichen auf Server- und Klientseite freie Softwareauswahl

Einfachheit

• eines der wichtigsten Entwurfsziele
• KISS-Prinzip: keep it simple, stuipd
• die einfachste Lösung ist i.d.R

  • die zuverlässigste
  • am leichtesten zu pflegen
  • leicht zu erweitern
  • leicht zu integrieren

• Komplexität entsteht durch Wachstum
• Forderungen der Kunden entsprechend beeinflussen

  • Verständnis für das Kriterium Einfachkeit schaffen
  • Nutzbarkeit: einfache Lösungen sind intuitiv zu benutzen

mehr Features == mehr Code == mehr Fehlermöglichkeiten
Konzentrieren auf wichtige Features (unterscheiden: wesentlich/unwesentlich)

Beziehungen zum Hersteller

• Kunde - Händler - Hersteller
• mehrere Hersteller/Händler gegeneinander bieten lassen

  • geforderte Leistungsdaten, Standards etc. spezifizieren (nicht: konkrete Produkte)
  • marktgerechtes Verhalten

• Direktbeziehungen zum Hersteller anstreben (besonders für missionskritische Dienste)

  • Bedeutung des Produkts für den Hersteller
  • Bedeutung des Kunden für den Hersteller
  • Beteiligung an Beta-Tests
  • Weiterentwicklung beeinflussen
  • Open Source Software ermöglicht direkte Kontakte zum Entwickler

• Plattform berücksichtigen
  optimal: Entwicklungsplattform des Herstellers == Betriebsplattform

Unabhängigkeit von konkreten Maschinen (Virtualisierung)

• Abhängigkeiten von konkreten Maschinen vermeiden
• dienstbezogene Namen wählen
  üblich für www.irgendwas.de
• primäre Hostnamen sollten nie funktionsbezogen sein
• dienstbezogene Namen

  • erleichtern Reorganisation
  • sind einprägsam für Kunden
    mail vs. smtp, pop, imap

• für IP-Adressen-abhängige Dienste ggf. "virtuelle" IP-Adressen benutzen (IP Alias)
• bereits bei Planung eines Dienstes an spätere Reorganisationen denken

Security

• Security-Aspekte frühzeitig berücksichtigen
• Fragestellungen:

  • Vertraulichkeit (Schutzwürdigkeit) von Daten
  • Einbindung in bestehene Security-Infrastruktur (Authentisierung)
  • wirksame, adäquate Authorisierungsmechanismen
  • Unterstützung kryptografischer Verfahren
    nicht: "irgendwelche" Verfahren, sondern offene, starke Verfahren

Plattform- und Serverauswahl

• Plattform-Auswahl (HW und SW)
  oftmals bestimmt Verfügbarkeit der Software die Hardware-Auswahl
• voneinander unabhängige Dienste sollten möglichst immer auf eigenen (dedizierten) Maschinen betrieben werden
• komplexe Dienste (bestehend aus mehreren Komponenten)

  • auf einer Maschine unterbringen

    • vermeidet zusätzliche Abhängigkeiten
    • erschwert Upgrade einzelner Komponenten

  • auf mehrere Maschinen verteilen

    • schafft zusätzliche Abhängigkeiten
    • ermöglicht gezieltes Tuning der einzelnen Systeme

• Server Appliances
  z.B. Storage Solutions (Fabric Attached Storage (FAS), Network Attach Storage (NAS), Storage Area Network (SAN)), Router, Firewall-Systeme
• Entscheidung muß ausgewogen sein hinsichtlich Security, Performance, Zuverlässigkeit und Skalierbarkeit
  Beispiel: Web-Server mit dynamischen Inhalten aus einer Datenbank

+ Effizienz durch Reorganisation/Synergieeffekte

+ effizienterer Mitteleinsatz (Finanzen, Technik, Personal)

+ Konzentration von Know-How, Spezialisierung

+ Erstellung/Einführung von Werkzeugen, standardisierten Verfahren

+ Sicherheitsanforderungen, Stabilität

- weniger Flexibilität

- verstärkt Tendenzen zur Bürokratie

- führt oft zu Frustration und Egoismus

- Änderungen von Strukturen und Zuständigkeiten

• Unterstützung durch zentralen Help-Desk
• einheitliche Dokumentation für Kunden und Help-Desk
• Situation des Kunden muss bekannt sein
  KollegIn X aus Abteilung Y: "Mein Drucker druckt nicht."
• Zentralisierung stößt an regionale (geografische) und organisatorische Grenzen
• Basisdienste (Netzwerk, Mail, Authentication, ...) müssen zentralisiert sein

+ Flexibilität durch Reorganisation/Verkleinerung

+ lokale Kontrolle, direkte Einflussnahme

- mangelnde Kontinuität

- oftmals unklare Kompetenzen

Implementations- und Testumgebung

• abtrennen von Produktionssystemen
• separate Maschinen, ggf. separate Subnetze verwenden
• typische Nutzungsszenarien entwickeln
• Pflege- und Upgradeszenarien berücksichtigen

Frage 4.2.1: In welchen Verhältnis stehen die Begriffe Open Source Software (OSS) und Offene Systeme/Architektur?

Frage 4.2.2: Welche Kriterien sind für die Bewertung eines Produktes hinsichtlich seiner Interoperalität wesentlich? Lässt sich ein allgemeingültiger Maßstab finden und wie könnte der aussehen?

Frage 4.2.3: Welche Aspekte und Konsequenzen sprechen für oder gegen die Zentralisierung/Dezentralisierung eines Dienstes?

Frage 4.2.4: Welche Vor- und Nachteile besitzen Out-of-the-Box-Lösungen für spezielle Dienste, z.B. Firewalls wie SmoothWall [http://www.smoothwall.org/] Trustix Firewall Products [http://www.trustix.com/]

OpenSource.org
[http://www.opensource.org/]

European Communities:
The IDA Open Source Migration Guidelines
netproject Ltd., 2003
http://www.netproject.com/docs/migoss/

Wheeler, D.A.:
Why Open Source Software / Free Software (OSS/FS)?
2003
http://www.dwheeler.com/oss_fs_why.html

Raymond, E.S:
The Luxury of Ignorance: An Open-Source Horror Story
2004
http://www.catb.org/~esr/writings/cups-horror.html

The Internet Engineering Task Force
[http://www.ietf.org/]

RFC 2026 The Internet Standards Process

The IT Infrastructure Library and IT Service Management Directory
[http://www.itil-itsm-world.com/]

Free Standards Group
[http://www.freestandards.org/]
Non-Profit Organisation für die Entwicklung und Verbreitung von Standards für freie und Open Source Software (z.B.: LSB - Linux Standard Base)

The Open Group
[http://www.opengroup.org]
"...the industry's premier certification authority..." (zertifiziert Distributionen, Produkte, Libraries ... z.B. nach LSB, vergibt "Open Brand", z.B. Unix03, CORBA, ...)

Ts'o, T.:
Microsoft "embraces and extends" Kerberos V5
in ;login, The Usenix Magazin, 11/1997
http://www.usenix.org/publications/login/1997-11/embraces.html

Gates, D.:
Microsoft's Kerberos shuck and jive
NetworkWorldFusion, 2000
http://www.nwfusion.com/news/2000/0511kerberos.html

Microsoft: Answers to Frequently Asked Kerberos Questions
[http://support.microsoft.com/support/kb/articles/Q266/0/80.ASP]

Mashey, J. R.:
Small is beautiful - and other thoughts on Programming Strategies
aus "Software Strategy from the 1980 Time Capsule"
in Proceedings der BSDCon02, Usenix Assoc., 2002
http://www.usenix.org/publications/library/proceedings/bsdcon02/mashey_small/

UTF-8 and Unicode FAQ for Unix/Linux
[http://www.cl.cam.ac.uk/~mgk25/unicode.html]