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.
Weitere Informationen finden Sie in der Aktivität Analyse vorhandener Assets, die eine Reihe detaillierter Verfahren zur Unterstützung
dieser Strategien umfasst.
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).
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.
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.
"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.
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.
|
|