Aufgabe: Nicht funktionale Servicevoraussetzungen dokumentieren
Diese Aufgabe definiert die Services und Struktur einer serviceorientierten Lösung in Bezug auf die Kollaboration der enthaltenen Designelemente und externen Subsysteme/Schnittstellen.
Zweck
  • Die Services und Struktur einer serviceorientierten Lösung in Bezug auf die Kollaboration der enthaltenen Designelemente und externen Subsysteme/Schnittstellen definieren.
  • Den Service auf Gemeinsamkeiten und Unterschiede analysieren (siehe Richtlinie Variabilitätsanalyse).
  • Die Spezifikation von Services dokumentieren.
  • Die Abhängigkeiten und die Kommunikation zwischen Services bestimmen.
Beziehungen
RollenHauptrollen: Zusätzliche Rollen: Unterstützende Rollen:
EingabenVerbindlich: Optional: Extern:
  • Ohne
Ausgaben
Hauptbeschreibung
Diese Aufgabe entwickelt die Servicespezifikationen weiter, die während der Aktivität Services identifizieren identifiziert und qualifiziert wurden, vervollständigt die Struktur der Spezifikationen und stellt weitere Details bereit. Zu diesen Details auf Designebene gehören die Schnittstelle, Nachrichten und Komposition von Services und die Zuordnung von Services zu Providern.
Schritte
Nicht funktionale Anforderungen dokumentieren

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?)
Eigenschaften
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar
Weitere Informationen