Aufgabe: Litmustest für Services durchführen
Diese Aufgabe beschreibt die Anforderung, geeignete Services zu qualifizieren, um sicherzustellen, dass die weiterentwickelten Services tatsächlich den Geschäftsbedürfnissen entsprechen.
Beziehungen
RollenHauptrollen: Zusätzliche Rollen: Unterstützende Rollen:
EingabenVerbindlich: Optional: Extern:
  • Ohne
Ausgaben
Hauptbeschreibung

Wenn geeignete Services ausgewählt und im (kategorisierten) Serviceportfolio dokumentiert wurden, muss bestimmt werden, welche dieser Services verfügbar gemacht werden sollten. Theoretisch könnte jeder geeignete Service verfügbar gemacht werden, indem die Serviceschnittstelle als Servicebeschreibung exportiert wird. Es sollte jedoch nicht jeder geeignete Service verfügbar gemacht werden, wenn dies ökonomisch und praktisch (im Sinne von Abstrichen bei den nicht funktionalen Anforderungen) nicht durchführbar ist. Insbesondere die naive Entscheidung "alle Methoden aller Klassen" verfügbar zu machen, würde zu einer überwältigenden und oft nicht verwaltbaren Anzahl von Services führen, die unter der Bezeichnung "Serviceproliferationssyndrom" bekannt ist. Dieses Syndrom erzeugt enorme Probleme im Bereich der Leistung und des Servicemanagements, ganz zu schweigen davon, dass potenziell die Wissensressourcen des Unternehmens preisgegeben werden. Außerdem darf nicht vergessen werden, dass die Verfügbarmachung jedes Service mit Kosten verbunden ist. Dabei sind Finanzierung, Steuerung und zugrunde liegende Infrastruktur des Service und der Komponenten für die Implementierung des Service (sowie die Sicherheit, Leistung und Verwaltung der Infrastruktur) zu berücksichtigen.

Daher sind einige Kriterien notwendig, die die Entscheidung erleichtern, ob ein Service verfügbar gemacht werden sollte, und vor allem, ob die Erstellung der Servicekomponente, die die Funktionalität des Service bereitstellt, sowie die Wartung, Überwachung, Sicherheit, Leistung und die weiteren Service-Level-Agreements für den Service finanziert werden sollten.  

Litmustests für Services

Projekterfahrungen haben gezeigt, dass eine Reihe von Kriterien in Form des Litmustests für Services zum Filtern der geeigneten Services verwendet werden kann und sollte. Mit dieser Metapher werden Tests bezeichnet, mit deren Hilfe sich feststellen lässt, ob ein gegebener Service für eine Verfügbarmachung (mit einer Servicebeschreibung) in Frage kommt. Diese Tests können zusammen angewendet werden, um Antworten auf Fragen wie die folgenden zu finden: Welche der geeigneten Services sollten verfügbar gemacht werden? Welche der verfügbar zu machenden Services sollten wir finanzieren? Welche der Services haben einen geschäftlichen Nutzen?

Im Extremfall könnte jeder Geschäftsanwendungsfall als geeigneter Service angesehen werden. Das andere Extrem wäre, nur ganz wenige Services für eine Verfügbarmachung auszuwählen. Bei Anwendung des Litmustests für Services ergibt sich in der Regel eine Mittellösung zwischen beiden Extremen: eine verwaltbare Gruppe von Services, die das Geschäft verfügbar machen möchte und die später in Kompositionen genutzt werden können.

Geeignete Services, die alle Litmustests für Services bestehen, sollten in der SOA als Services verfügbar gemacht werden. Es könnte geeignete Services geben, die den Litmustest für Services nicht bestanden haben und dennoch implementiert werden. Der Litmustest für Services ist ein Hilfsmittel zur Bestimmung der Services, die verfügbar gemacht werden sollten. Wenn ein Geschäft entscheidet, geeignete Services, die den Litmustest für Services nicht bestanden haben, verfügbar zu machen, nimmt es in Kauf, dass die Vorteile der SOA nicht genutzt werden können.

Geeignete Services, die den Litmustest für Services nicht bestehen, müssen so implementiert werden, dass sie Geschäftsanforderungen erfüllen. Sie könnten als Methoden von Servicekomponenten implementiert werden, so dass weder WSDL noch eine andere Form von Servicedefinition erstellt werden muss. Sie können aber auch als Entitäten verwendet werden, die nicht verfügbar gemacht werden.

Hinweise

Die Anwendung von Litmustests für Services ist ein iterativer Prozess. Für die erste Ausarbeitungsphase sollten ausgehend vom aktuellen Kenntnisstand Entscheidungen getroffen werden. Sobald sich im Verlaufe des Designprozesses weitere Informationen ergeben, sollten die Litmustests für Services nochmals bearbeitet werden.

Litmustests für Services sollten auf jeden geeigneten Service angewendet und mit den entsprechenden Fachleuten oder Stakeholdern geprüft werden.

Die Überprüfung der Ergebnisse der Litmustests für Services ist eine hilfreiche Methode, die Tauglichkeit der Kriterien und die Eignung der Serviceunterteilung festzustellen. Wenn beispielsweise zu viele geeignete Services einen bestimmten Test bestehen, ist die Testdefinition möglicherweise zu allgemein gefasst, oder die Serviceziele sind nicht mit der entsprechenden Detailgenauigkeit angegeben.

Ein Service kann bei einem oder mehreren Litmustest(s) durchfallen und dennoch aufgrund einer projektspezifischen Entscheidung (Geschäft oder IT) verfügbar gemacht werden. Das ist durchaus in Ordnung, denn unabhängig von den Litmustests für Services kann es eine Architektur- oder Geschäftsentscheidung für die Verfügbarmachung eines Services geben.

Schritte
Geschäftsorientierung eines Service sicherstellen

Ein Test muss zunächst auf seine Geschäftsorientierung getestet werden. Wenn sich der Service nicht auf eine Geschäftsaufgabe oder ein Geschäftsziel zurückführen lässt, bringt er möglicherweise nicht die für eine SOA-Implementierung erforderlichen Vorteile. Können alle nachfolgend aufgelisteten Fragen positiv beantwortet werden, ist der Service geschäftsorientiert.

  • Stellt der Service eine geforderte Geschäftsfunktionalität zur Unterstützung von Geschäftsprozessen und -zielen bereit (siehe Aufgabe Analyse von Geschäftsprozessen)?
  • Ist das Geschäft bereit, den Service für die Dauer seines Lebenszyklus (Bereitstellung, Verwaltung, Steuerung und Wartung) zu finanzieren?
  • Ist das Geschäft zu einer internen oder externen gemeinsamen Nutzung des Service mit Kunden oder Geschäftspartnern bereit? Dies könnte beispielsweise zusätzliche Kosten verursachen, Auswirkungen auf Geschäftsgeheimnisse und Sicherheit haben usw.
  • Gibt es gegenwärtig oder künftig Möglichkeiten innerhalb des Unternehmens, den Service wiederzuverwenden?
Kombinierbarkeit eines Service sicherstellen

Die Kombinierbarkeit ist ein Attribut, das die Eignung eines Service für zusammengesetzte Services angibt. Anwendungen können auf beide Kompositionsarten erstellt werden.

  • Hat der Service die erforderlichen QoS-Attribute (Quality of Service), die in den nicht funktionalen Anforderungen der Komposition definiert sind?
  • Ist der Service statusunabhängig (siehe Richtlinie Zustandsmanagement für Services)?
  • Ist der Service unabhängig? Kann der Service unabhängig für die Erreichung eines Geschäftsziels implementiert werden, obwohl er in der Laufzeit möglicherweise mit anderen Services kooperiert, um Geschäftsprozesse auszuführen? Es gibt keine impliziten Abhängigkeiten des Service von anderen eingebetteten Funktionen. Alle Services, von denen andere Services abhängig sind, sind ersetzbar oder autark.
  • Ist die Implementierung des Service technologieneutral? Technologieneutral bedeutet, dass der Service keine Unterstützung unbekannter (vom Standard abweichender) Protokolle oder Einheiten notwendig macht. Dies wäre beispielsweise der Fall, wenn die konstitutive Komponente Eingriffe über eine vom Standard abweichende Anwendungsschnittstelle erfordert.
    Dieser Test ist nur anwendbar, wenn der Test in der Umgebung des Konsumenten implementiert wird. Beispiel: Ein Geschäft stellt seinen Kunden einen Service zum Abrufen von Bildern bereit. Diese Funktionalität kann in Form eines Web-Service für Abonnenten zur Verfügung gestellt werden. Alternativ dazu kann das Geschäft die als Web-Service verfügbar gemachte Abruffunktion für Bilder sowie eine Sammlung von Bildern an den Kunden übergeben. In diesem Fall trägt der Kunde die Verantwortung für die Suche nach der geeigneten Technologie.
Vorhandensein einer externen Servicebeschreibung sicherstellen

Ein Service zeichnet sich in erster Linie dadurch aus, dass ihm eine externalisierte Servicebeschreibung zugeordnet ist. Diese externalisierte Servicebeschreibung kann automatisch mit Tools oder manuell erstellt worden sein.

  • Ist dem Service eine externalisierte Servicebeschreibung zugeordnet, die individuell und von der zugrunde liegenden physischen Implementierung getrennt ist? Ein aktuelles Beispiel hierfür ist WSDL.
  • Kann der Service mit Hilfe der Servicebeschreibung erkannt und gebunden werden?
  • Enthält die Servicebeschreibung Metadaten über sich selbst? Die Servicebeschreibung muss unabhängig sein und alle Informationen enthalten oder referenzieren, die für das Verständnis des Nachrichtenaustausches zwischen dem Konsumenten und dem Provider eines Service notwendig sind.
Wiederverwendbarkeit eines Service sicherstellen

Kann der Geschäfts-Stakeholder diesen Service für alle Prozesse verwenden, für die die Funktion dieses Service erforderlich ist?

Technische Machbarkeit eines Service sicherstellen

Die technische Machbarkeit stellt sicher, dass der Service mit verfügbaren Technologien tatsächlich gemäß den funktionalen und nicht funktionalen Anforderungen realisiert (implementiert) werden kann.

  • Ist der Implementierungs- und Verwaltungsaufwand für den Service angesichts der Anforderungen oder der Infrastruktur der Implementierung angemessen und leistbar?
    Diese Frage wird nach der Untersuchung der technischen Machbarkeit geklärt.
Eigenschaften
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar