Die Verwendung einer serviceorientierten Architektur gibt Ihnen die Möglichkeit, einen Serviceprovider nicht nur nach der von ihm bereitgestellten
Funktionalität, sondern auch nach der von ihm garantierten Servicequalität (QoS) auszuwählen. Einer der Gründe für den
Wechsel eines Serviceproviders hat häufig mit einer Änderung der nicht funktionalen Anforderungen zu tun, die eine
neue, höhere und von einem vorhandenen Provider derzeit nicht unterstützte Servicequalität erforderlich macht. Der
Wechsel kann aber auch darauf zurückzuführen sein, dass die Servicequalität hinter den Erwartungen des
Servicekonsumenten zurückbleibt. Eine serviceorientierte Architektur ermöglicht eine solche Beweglichkeit (der
Geschäftsabläufe) im Allgemeinen zu geringeren Kosten als andere Architekturstile.
Die Servicequalität kann aus zwei Perspektiven betrachtet werden, aus der Perspektive des Providers und der des
Konsumenten. Der Serviceprovider garantiert für jeden seiner Services oder jede seiner Servicegruppen eine bestimmte
kontinuierliche Servicequalität. Der Servicekonsument schaut sich dagegen um, wo er die gewünschte Servicequalität
findet, und wählt ausgehend von der Servicequalität einen Provider aus. In einer kommerziellen Situation, wenn
Konsument und Provider einen gültigen Vertrag über die Verwendung des Service schließen, werden die Zusicherungen
hinsichtlich der Servicequalität sogar in Service-Level-Agreements festgehalten, die häufig Vertragsstrafen vorsehen,
wenn ein Provider seinen vertraglichen Verpflichtungen nicht nachkommt.
Deshalb ist es ausgesprochen wichtig, die nicht funktionalen Anforderungen des Konsumenten an einen Service oder eine
Reihe von Services (z. B. an die Transaktionskosten, die Leistung, die Verfügbarkeit, die Sicherheit usw.) klar und
deutlich zu spezifizieren. In dieser Aufgabe der Servicespezifikation identifizieren wir die nicht funktionalen
Anforderungen an die gewünschte Servicequalität. Die nicht funktionalen Anforderungen bilden die Grundlage für die
Festlegung von Ressourcen für Servicekomponenten, die die Services anbieten, sowie für die Finanzierung der
Realisierung und Wartung von Servicekomponenten, die die kontinuierliche Verfügbarkeit der Servicequalität
sicherstellen. Um zu gewährleisten, dass die angesichts der nicht funktionalen Anforderungen zugesagte Servicequalität
erreicht wird, müssen wichtige Entscheidungen bezüglich der Architektur getroffen werden.
Auf welche Weise nicht funktionale Anforderungen mit der Servicespezifikation verbunden sind, ist in dieser Anleitung nicht
definiert. Ebensowenig werden Grenzen hinsichtlich dessen gesetzt, was eine solche Anforderung ausmacht. Ganz
offensichtlich gehört die Servicequalität dazu, und die Sicherheit wurde ebenfalls schon erwähnt. Hier folgen einige
weitere Beispiele:
-
Verfügbarkeit (d. h. die mittlere Zeit zwischen auftretenden Fehlern)
-
Nutzungszeitfenster (Gibt es eine Zeit, in der keine Nutzung des Service vorgesehen ist?)
-
Antwortzeit (Wie schnell muss der Service auf eine Anfrage reagieren?)
-
Spitzendurchsatz (Wie viele Anfragen an den Service können pro Zeiteinheit eingehen, z. B. pro Sekunde, Minute oder
Stunde?)
|