Aufgabe: Servicespezifikation
Diese Aufgabe definiert die Services und Struktur einer serviceorientierten Lösung in Bezug auf die Kollaboration der enthaltenen Designelemente und externen Subsysteme/Schnittstellen.
Disziplinen: Analyse und Design
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
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
Unternehmensserviceportfolio wiederverwenden

Ein Vorteil, der für die serviceorientierte Architektur (SOA) häufig angeführt wird, ist, dass Services wiederverwendbare Assets im gesamten Unternehmen und nicht nur die Entwicklung von Komponenten im Bereich einer Einzelanwendung darstellen können. Diese Unternehmenssicht ist wichtig, da ihr die Vorstellung zugrunde liegt, dass eine wirklich serviceorientierte Architektur für IT alle Infrastruktur- und Geschäftsfunktionen als Services beinhaltet und dass die vom Unternehmen entwickelten Anwendungen Funktionen aus dem Portfolio der Services wiederverwenden.

Beim Beginn eines Projekts ist es also wichtig, zu wissen, ob Sie Services als Bestandteil des Portfolios oder als Anwendungsfunktionen, die diese Services verwenden, entwickeln möchten. Beispielsweise ist die Entwicklung einer Portalsite für Kunden, die den Zugriff auf Accountinformationen ermöglicht, ein Anwendungsentwicklungsprojekt, das Services im Portfolio für Kundeninformationen, Accountinformationen, Angebote usw. verwendet. In jedem Fall hat die Verwendung des Portfolios verschiedene Auswirkungen. Der Servicedesigner beschreibt die entsprechende Servicespezifikation und veröffentlicht sie als Teil des Portfolios. Diese Spezifikation ermöglicht Anwendungsentwicklern, die Interaktionsanforderungen für den Service zu verstehen. Der Serviceimplementierer kann jetzt dieselbe Servicespezifikation verwenden, um eine oder mehrere Implementierungen des Service zu entwickeln, wobei er sicherstellt, dass die Implementierung mit der Spezifikation übereinstimmt. In der folgenden Abbildung ist die Beziehung zwischen dem unternehmensweiten Serviceportfolio und dem Projektportfolio dargestellt.

Weitere Informationen finden Sie im Konzept Serviceportfolio.

Designmuster und -mechanismen verwenden

Verwenden Sie Designmuster und -mechanismen, die für den zu entwerfenden Service geeignet sind und den Designrichtlinien für das Projekt entsprechen. Durch die Integration eines Musters und/oder Mechanismus werden viele der nachfolgend in dieser Aufgabe beschriebenen Schritte effektiv und in Übereinstimmung mit den im Muster bzw. Mechanismus definierten Regeln ausgeführt.

Beachten Sie, dass Muster und Mechanismen gewöhnlich während der Weiterentwicklung des Designs und nicht im ersten Schritt dieser Aufgabe integriert werden. Sie werden außerdem häufig auf mehrere Modellelemente und nicht nur auf ein einzelnes Element angewendet.

Bei der Umsetzung eines Service bis hin zu seiner Realisierung werden oft eine Reihe von Mustern verwendet, von denen einige in der Richtlinie Servicekomponentenmuster beschrieben sind.

Logische Organisation der Lösung beschreiben

Es macht oft Sinn, von verschiedenen Systemsichten auszugehen und zu berücksichtigen, wie die Services, die Sie entwickeln, in diese Sichten hineinpassen. Bei der Definition der logischen Organisationssichten ist wichtig, dass die Zuordnung eines Service zu einer Sicht nicht zwangsläufig die Bindung an eine UML-Prüfung oder einen UML-Einschluss (Unified Modeling Language) bedeutet, d. h., ein Service muss an vielen logischen Sichten teilnehmen können. Es lohnt sich, die Organisationssichten im Modell vor der Serviceentwicklung oder zumindest vor der ersten Iteration dieser Sichten zu entwerfen, damit Services Sichten laut Identifikation zugeordnet werden können. Im Servicemodell wird das Modellelement Servicepartition verwendet, um einen Aspekt in einer Sicht darzustellen. Diese Partitionen können verwendet werden, um eine Reihe verschiedener Perspektiven der Lösung darzustellen, implizieren jedoch nicht, dass sie Eigner der ihnen zugeordneten Services sind. Weitere Informationen finden Sie im Konzept Lösungspartitionierung.

Es ist auch möglich, diese Partitionen, zumindest diejenigen, die wichtige Blickpunkte darstellen, getrennt von den Services in Modellen anzuordnen und den Partitionsmodellen eine unabhängige Weiterentwicklung zu ermöglichen.

Serviceelemente beschreiben

Wenn man sich mit der Modellierung von Softwaresystemen befasst, stellt man immer fest, dass es bei jedem Modell eine Vielzahl von Einstiegspunkten, unendlich viele verwendbare Darstellungsmöglichkeiten und natürlich viele anwendbare Methoden gibt. In den meisten Fällen lassen sich diese Einstiegspunkte auf bestimmte Problemstellungen, die in Technologie- oder Geschäftsdomänen zu lösen sind, zurückführen. Diese Problemstellungen sind wichtig genug, um als Einstiegspunkte fungieren zu können, denn die Interaktion zwischen ihnen ist kritisch für den Erfolg.

Es wurde beobachtet, dass es eine kleine Anzahl solcher Problemstellungen bei der Entwicklung serviceorientierter Lösungen gibt. Das folgende Diagramm stellt diese primären Problemstellungen als spezifische Designaufgaben dar. Obgleich jede Problemstellung als Einstiegspunkt für das Servicedesign fungieren kann und die einzelnen Ansätze oft für eine bestimmte Serviceklasse optimiert sind, ist es sehr wahrscheinlich, dass ein großes Projekt bei der Identifikation und beim Design von Services eine Kombination verschiedener Ansätze verwendet.

Im Kontext beschriebene Abbildung

Weitere Informationen finden Sie in der Aktivität Analyse vorhandener Assets, die eine Reihe detaillierter Verfahren zur Unterstützung dieser Strategien umfasst.

Nachrichtendesign

Bei diesem Ansatz liegt der Fokus auf der Servicedomäne. Verfahren wie das Domänen-Engineering bzw. die objektorientierte Analyse und das objektorientierte Design bieten einen tiefen Einblick in die Entwicklung abstrakter Domänenmodelle. Mit diesem Ansatz werden Modelle für das Nachrichtenschema erstellt, die in hohem Maße wiederverwendbar sind. Das Servicedesign ist normalerweise eine sekundäre Aktivität, obwohl es manchmal parallel erstellt wird. Bei Electronic Data Interchange (EDI) gibt es z. B. kein echtes Konzept einer Serviceschnittstelle, weil EDI-Systeme normalerweise einen einzelnen globalen Ein- und Ausgang für Nachrichten haben.

Ein Beispiel für einen solchen Ansatz sind die traditionellen Beziehungen von Geschäft zu Geschäft, typisiert durch EDI-Standardisierung. In diesem Fall liegt der Fokus der Designaktivität auf der Entwicklung eines branchenweit oder anderweitig vereinbarten Nachrichtenschemas, das repräsentativ für das Schema einer Nachrichtenklasse ist, und Industriestandards wie ACORD, SWIFT und RosettaNet (siehe Aufgabe Nachrichtendesign).

Servicedesign

Bei diesem Ansatz befasst sich der Designer damit, Funktionalität, die vom Geschäft oder von der Anwendung erwartet wird, als Service bzw. Servicegruppe zugänglich zu machen. In diesem Fall ist nicht unbedingt bekannt, was der Serviceclient mit dem Service tun will, aber es ist sehr wohl bekannt, welche Arten von Interaktionen solche Clients erwarten. Daher sind Nachrichten oft sekundär und werden als Antwort auf die Anforderungen einer Operation entwickelt.

Ein Beispiel für diesen Ansatz sind die Web-Services-APIs, die von Unternehmen wie Amazon und eBay präsentiert werden. Solche Serviceschnittstellen erlegen dem Client keinen Geschäftsprozess auf. In den meisten Fällen geben Sie dem Client nicht einmal Schnittstellen vor, sie machen die Operationen ihrer entsprechenden Serviceprovider auf klare und intuitive Weise Entwicklern Dritter zugänglich.

Wie oben erwähnt, eignet sich die servicezentrierte Modellierung oft gut für einen anwendungsfallgesteuerten Ansatz, da sie die Bedürfnisse von Akteuren und die externen Clients von Services erfasst und Operationen zur Unterstützung dieser Anforderungen, wie z. B. das Durchblättern von Katalogen, das Hinzufügen von Elementen zu einem elektronischen Warenkorb, das Auschecken usw.

Gestaltung der Kollaboration

Beim Kollaborationsdesign liegt der Fokus auf der Kollaboration von zwei oder mehr Services. Dabei handelt es sich weitgehend um eine Prozesssicht der Services, die eher einer traditionelleren Geschäftsmodellierung als einer Softwareentwicklungsaktivität zugeordnet ist. Bei diesem Ansatz übernehmen Services Rollen bei der Kollaboration, und die Servicespezifikation ist daher eine Gruppe von Zuständigkeiten, die für die Rolle in einer oder mehreren Kollaborationen definiert werden.

Ein solcher Ansatz kann von Personen, die an der Entwicklung von RosettaNet Partner Interchange Processes (PIPs) oder an der Entwicklung der OAGIS-Standards beteiligt waren, erkannt werden, obwohl die Kollaborationen in diesen Fällen keinesfalls vollständig sind. Der Ansatz wäre üblich bei einem Geschäft hinsichtlich des Designs der Geschäftsprozesse oder bei Aktivitäten zur Geschäftsintegration, wenn die Komponenten eines IT-Systems als Services zugänglich gemacht werden.

In diesem Fall kann die Servicespezifikation normalerweise direkt von der Kollaboration abgeleitet werden, aber dieser Ansatz konzentriert sich oft weniger auf Nachrichteninhalte, was dazu führt, das zwecks Vollständigkeit ein Hybridansatz verwendet werden muss.

Richtlinienidentifikation und -erfassung

"Richtlinie" ist ein weiter Begriff, der hier verwendet wird, um Anweisungen oder Einschränkungen, die als nicht funktionale Anforderungen betrachtet werden können, abzudecken. Auf der Ebene dieses Modells ist es unumgänglich, zur Kenntnis zu nehmen, dass es keinen Sinn macht, das Modell mit detaillierten Anweisungen zu technischen Informationen zu füllen, sondern dass vielmehr die Zielsetzung des Systems hinsichtlich dieser Anforderungen erfasst werden muss. Eventuell ist bekannt, dass eine bestimmte Nachricht übertragen und vertraulich gehandhabt werden muss, da sie persönliche Kundendaten enthält. Es wird also die Zielsetzung, die Nachricht vertraulich zu behandeln, erfasst und nicht die Anweisung zur Verwendung der AES-128-Bit-Verschlüsselung über eine kanonische XML-Datengruppe mit X.509-Zertifikaten für Verschlüsselung öffentlicher Schlüssel, hauptsächlich deswegen, weil sehr wenige Leute wissen, was das überhaupt bedeutet, ganz zu schweigen davon, dass es keinen Sinn macht, eine solche Anweisung auf dieser Abstraktionsebene in einem Modell anzugeben (siehe Aufgabe Sicherheitsmuster identifizieren).

Das folgende Diagramm veranschaulicht die Zuordnung von Richtlinien zu den Elementen des Servicemodells. Beachten Sie, dass die Richtlinieninformationen auch anderen Komponenten als den unten aufgeführten Spezifikationskomponenten zugeordnet werden können, obwohl dies das primäre Interessengebiet ist.

Im Kontext beschriebene Abbildung

Weitere Informationen zur Modellierung der Sicherheitsrichtlinie finden Sie im White Paper Sicherheitsfragen in serviceorientierten Architekturen modellieren.

Serviceabhängigkeiten modellieren

Ein weiterer Schlüsselaspekt des Servicemodells, der während der Spezifikation entwickelt werden muss, ist die Erfassung der wechselseitigen Abhängigkeiten von Services. Verschiedene Abhängigkeiten werden per se als Teil des Servicemodells erfasst. Sie können offensichtlich wie die Beziehung zwischen einem Service und seiner Spezifikation oder aber komplexer sein, wie z. B. die logische Beziehung zwischen zwei unabhängigen Services, da sie beide dieselbe Spezifikation implementieren. Diese (in im Servicemodell und im Bericht Serviceabhängigkeiten beschriebenen) Abhängigkeiten tragen wesentlich dazu bei, die Möglichkeit der Implementierung eines Service als autonome Einheit zu verstehen, und beeinflussen die Entstehung des Service in dem Sinne, dass die Änderungsmöglichkeiten eines Service mit wachsender Zahl von Abhängigkeiten immer geringer werden.

Serviceabhängigkeiten beschreiben die Beziehungen zwischen Services, die sich aus dem größeren Kontext der Verwendung der Services ergeben. Wenn ein Service durch die Komposition anderer Services entsteht, ist er von den Services abhängig, aus denen er sich zusammensetzt. Services, die im Kontext eines Geschäftsprozesses verwendet werden, haben eine prozessbezogene Abhängigkeit, die sich aus der inhärenten Abfolge von Schritten im Geschäftsprozess ergibt. Diese Abfolge diktiert die Reihenfolge, in der Services verwendet werden.

  • Funktionale Abhängigkeiten / Kompositionsabhängigkeit infolge der Komposition mehrerer Services
    • Beispiel: Der Service "Fahrzeug reservieren" hängt funktional von den Services "Preise prüfen" und "Reservierung vornehmen" ab.
  • Zeitliche Abhängigkeit - Bei dieser Abhängigkeit gibt es eine Vor- oder Nachbedingung oder eine Verarbeitungsanforderung, die bei Kompositionen oder Choreographien berücksichtigt werden muss.
    • Abhängigkeit von Vorbedingungen - Bevor mit der Ausführung des aktuellen Aufrufs begonnen werden kann, muss ein anderer Service erfolgreich aufgerufen worden sein.
    • Verarbeitungsabhängigkeit - Für einen erfolgreichen Abschluss des aktuell ausgeführten Service ist der Aufruf eines anderen Service erforderlich.
    • Abhängigkeit von Nachbedingungen - Diese Abhängigkeit tritt auf, wenn ein Service nach seiner Ausrührung den Aufruf eines weiteren Service erfordert.

Diese Abhängigkeiten können oft Bestandteil des Entscheidungsprozesses sein, den ein Serviceclient durchlaufen muss, wenn er einen Service wiederverwenden möchte, insbesondere, wenn mehrere Implementierungen zur Auswahl stehen.

Die wichtigen Abhängigkeiten/Zuordnungen im Servicemodell sind folgende:

  • Die Beziehung zwischen einem Service und den Serviceprovidern, die ihn implementieren.
  • Die Beziehung zwischen einem Service und der Servicespezifikation, die er implementiert.
  • Die Beziehung zwischen einem Service und jeder Servicespezifikation, die er erfordert.
  • Die Beziehung zwischen einem Service und jedem Servicekanal, der ihn mit anderen Services verbindet, mit anderen Worten, mit dem Service am anderen Ende des Kanals.
  • Die Beziehung zwischen einem Service und jeder Servicespezifikation, in der der Service erscheint.

Daher ist es wichtig, dass alle Servicespezifikationen vollständig sind, nicht nur im Hinblick auf die Operationen und Nachrichten, die sie bieten, sondern auch hinsichtlich aller Abhängigkeiten, wie z. B. erforderlicher Schnittstellen für Callback-Operationen. Der Bericht Serviceabhängigkeiten enthält eine Übersicht über die wichtigen Abhängigkeiten für das Servicemodell.

Servicekomposition und -abläufe modellieren

Services setzen sich oft aus anderen, bereits vorhandenen Services zusammen. In einigen Fällen kann ein Service durch Technologie, z. B. durch eine Choreographie, sogar ohne expliziten Code als reine Komposition vorhandener Services implementiert werden. Während der Spezifikation können Services, die Elemente aus dem Unternehmensportfolio wiederverwenden und deren Abhängigkeiten von diesen Services bereits dokumentiert sind, als zusammengesetzte Services betrachtet werden, sofern ihre Funktionalität auf die Funktion eines konstituierenden Service angewiesen ist und sie nicht ohne Zugriff auf die konstituierenden Services implementiert werden können.

In einigen SOA-Frameworks gibt es eine Geschäftsprozessschicht, die ausschließlich für die Verwaltung choreographierter zusammengesetzter Services bestimmt ist, wenn komplexe Prozesse als verwaltete Choreographien differenzierterer Services bereitgestellt werden. In einem solchen Fall kann BPEL4WS (Business Process Execution Language for Web Services) als Tool für die Entwicklung von zusammengesetzten Services, Serviceabläufen und Geschäftsprozessschichten verwendet werden.

Somit lassen sich zwei Arten zusammengesetzter Services identifizieren:

  • Fest zusammengesetzte Services - Diese Services zeichnen sich durch eine geringe Flexibilität aus und unterliegen einem vordefinierten Ablauf und einer vordefinierten Steuerung. Ablauf und Steuerung dieser Services sind nicht externalisiert. Diese Art von Services hat attraktive Attribute für die Servicequalität, z. B. die Leistung (performance).
  • Flexibel zusammengesetzte Services - Diese Services zeichnen sich durch eine hohe Flexibilität aus. Die Komposition der Services zu Geschäftsprozessen wird durch die Externalisierung von Ablauf und Steuerung erzielt. Die Ablaufbeschreibung der Komposition ist externalisiert. Bei dieser Art der Komposition werden Modellierungstools, dynamische Variabilität mit Hilfe von Regeln und statische Variabilität durch Modellierung genutzt. Ein Beispiel ist die Komposition mit BPEL.

Weitere Informationen hierzu enthält das Konzept Servicekomposition und -choreographie. Ein projektspezifisches Beispiel finden Sie in der Richtlinie Servicerealisierung - BPEL-Services in einer SOA-Anwendung.

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?)
Anforderungen an das Zustandsmanagement dokumentieren

Auch wenn einzelne Services als statusunabhängig angesehen werden, gibt es bei Kompositionen oft die Anforderung, während des Aufrufs der zusammengesetzten Services Statusinformationen zu verwalten. Häufig ist der Choreograph der Services für das Zustandsmanagement zuständig. Auf der anderen Seite kann es aus Leistungsgründen notwendig sein, dass eine Komponente, die mehrere zusammengehörige Services oder Serviceoperationen implementiert und realisiert, den Status verwaltet.

In der SOA-Umgebung wird das Zustandsmanagement auf drei Hauptkategorien angewendet:

  • Transaktionsstatus - Ein Service hat während eines Dialogs mit einem Client eine offene Transaktion.
  • Sicherheitsstatus - Während eines Dialogs mit einem Client wird ein Sicherheitskontext offen gehalten.
  • Funktionsstatus - Am Dialog mit einem Client sind eine Reihe zusammengehöriger Operationen beteiligt.

Weitere Informationen enthält die Richtlinie Zustandsmanagement für Services.

Weitere Informationen