testing 01
| From: | Jack | Date: | Thu, 12 Jul 2012 02:10:59 +0000 |
| Subject: | testing 01 | ||
| Groups: | php.test | ||
| Request: | Send a blank email to php-test+get-1092@lists.php.net to get a copy of this message | ||
# Ziele von SOA / Nennen Sie drei Vorteile und drei Nachteile der Serviceorientierung.
- Verbesserte grundlegende Interoperabilität
Gemeinsame Nutzung von Daten(-formaten)
Konsistente Anwendung von Standards
- Verbesserte Föderation
Autonome und selbstständige Services
Ein Segment eines Unternehmens kapseln
- Verbesserte Herstellerunabhängigkeit
Services von verschiedenen Herstellern zusammen nutzbar in einer Anwendung
wenn keine proprietären Services genutzt werden, kann einer ausgetauscht werden, falls notwendig
- Verbesserte Abstimmung von Geschäften und Technologien
Funktionale Abstraktion mit Einrichtung von Service-Ebenen
Angelehnt an bereits vorhandener Geschäftlogik
Experten im Geschäftsbereich definieren konkreten Services
Wenn sich eine Technologie ändert, kann ein Service in dem bestehenden System leicht ausgetauscht werden
- Verbesserter ROI (Return of Investment)
Kosteneffizienz eines Services
Durch Wiederverwendbarkeit
In verschiedenen Kompositionen nutzbar
- Verbesserte Agilität der Organisation
Effizienz, mit der Änderungen durchgeführt werden
Reaktionsfähigkeit eines Unternehmens leidet, wenn zu viel Zeit für Änderungen benötigt wird
Organisation kann durch neues Komponieren von Services schnell geändert werden
- Geringere IT-Belastung
Weniger Redundanz# Web Service
Vorteile
- Einfacher zu Handhaben (im Gegensatz zu Corba/DCOM)
- Vereinfachen die Kommunikation zwischen Firmen mit verschiedenen Infrastrukturen
- Web Services können auch komplexe Workflow Systeme abbilden
- Kommunikation über Internet (HTTP), Firewalls müssen nicht angepasst werden
- Basieren auf anerkannte Standards (Nachrichtenübertragung, Verzeichnisdienste)
- Web Services für fast alle Programmiersprachen vorhanden
Nachteile
- Web Service Anfragen passieren Firewalls, so können auch potentielle Angreifer passieren
- Oft nicht die leistungsfähigste Lösung
# Servicemodelle
- Entity-Services
Entity (en): Datensatz
Z.B.: Kunde, Mitarbeiter, Rechnung, Forderung
Funktionsgrenzen und Kontextauf Entity begrenzt
Hochgradig wiederverwendbar, da meist unabhängig
- Task-Services
Task (en): Aufgabe
Z.B.: Einkommenssteuererkl.
Direkt an einen übergeordneten Service gebunden
Geringeres Wiederverwendungspotenzial
Genutzt als Controller einer Komposition
Interaktion mit mehreren Services
- Utility-Services
Utility (en): Dienstprogramm
Z.B.: Ereignisprotokoll, Benachrichtigungen, Ausnahmebehandlung
Wiederverwendbare, übergreifende Funktionalität
Anwendungsunabhänig
# Serviceinventar:
unabhängige standardisierte und gesteuerte Sammlung sich ergänzender Services
Häufigste Umsetzung von SOA sind Web Services
# Definition Service
Physikalisch unabhängige Softwareprogramme
Haben eigenen funktionalen Kontext und Fähigkeiten Veröffentlichen Servicevertrag
Services können in Kompositionen (auch wiederverwendet) eingebaut werden
# Web Services sollten auf jeden Fall genutzt werden, wenn
Funktionalität über ein verteiltes Netzwerk bereit gestellt werden soll
Komponenten auf heterogenen Umgebungen laufen und von untersch. Organisationen entwickelt werden
ein Geschäftsprozess automatisiert werden soll
ein Geschäftsprozess sich oft ändert
die Systemkomponenten sich oft ändern
ein Geschäftsprozess ausgegliedert werden soll
Daten nicht nur einer Hauptanwendungen bereit gestellt werden sollen
# Webservice erstellen
1. Erstellen eines Web Services
- Welche Parameter werden für eine Anfrage benötigt?
- Welche Protokolle werden unterstützt?
- Welche Informationen werden zu einem Konsument zurück gegeben?
2. Beschreiben des Web Services in einem WSDL Dokument
- Beschreibung wird auf dem eigenen Server platziert und ist vom Konsument zugänglich
- WSDL Dokument kann auch automatisch erzeugt werden
3. Veröffentlichen eines Web Services in einem Verzeichnisdienst (UBR) (optional)
- Kommunikation mittels UDDI
4. Ein Web Service Konsument kann im Verzeichnisdienst den Web Service finden und bekommt Informationen über ihn (optional)
- Kommunikation mittels UDDI
5. Der Konsument kann nun den Web Service ansprechen
# SOAP Implementierung PEAR::SOAP
SERVICE
1.Einbinden von SOAP/Server.php und setzen der Variable PEAR_Error, skiptrace
2.Web Service Klasse implementieren
3.Web Service Klasse ausprägen
4.SOAP Server ausprägen
SOAP_Server SOAP_Server()5.Service mit Namen zuweisen
void SOAP_Server::addObjectMap(
&$obj, string $namespace)
6.Einstellung, dass POST-Daten an den Service weiter gegeben werden
void service(string $data)+CLIENT 1.Einbinden von SOAP/Client.php 2.Client Ausprägen und URI auf Web Service übergeben
SOAP_Client SOAP_Client
(string $endpoint)
3.Methode
mixed SOAP_Client::call
(string $method, &$params,
string $namespace)
aufrufen, um Web Service Methode zu nutzen
# Web-Service mit Parametern erstellen:
In der Klasse muss ein Array __dispatch_map definiert werden.
Im Konstruktor der Klasse wird dieser Array gefüllt, in
dem die Parameter samt Datentyp, gruppiert nach
Ein- und Ausgabeparameter, definiert werden.
Zusätzlich muss eine Methode __dispatch definiert
werden um __dispatch_map zurück zu geben
Der Web Service Methode können einfach die Parameter übergeben werden.
Auf die Reihenfolge ist dabei zu achten.
Der Rückgabewert ist mit return ein Objekt der
Klasse SOAP_Value zurück zu geben
SOAP_Value SOAP_Value (string $name,
mixed $type, mixed $value)
# Web Service mit Parametern konsumieren:
In einem assoziativen Array Parametername und
Parameterwert definieren
Diesen Array als zweiten Parameter der Funktion
call übergeben
mixed SOAP_Client::call
(string $method, &$params,
string $namespace)
# Design Entscheidungen
- Synchrone oder asynchrone Kommunikation
- Zustandlose oder zustandbehaftete Web Services (Sessions)
- Transaktionen (Welche Operationen gehören zusammen, Verifikation wird benötigt)
- Zwischenspeicherung von häufig gestellten Anfragen (Caching)
# SOAP unterstützt NICHT
- Aktivierung eines Web Services
-> Web Service wartet immer auf Anfragen.- Distributed garbage collection
-> Web Service kennt seinen Konsumenten nicht- Gruppierung von Nachrichten
-> Es kann immer nur eine Nachricht an den WS gesendet werden- Referenzierung von Objekten
-> SOAP kann nur ganze Objekte transportieren# SOAP Nachricht enhält - Envelope: Umschlag, der die nächsten beiden Teile enthält - Header (optional): Kopfteil der Nachricht enthält zusätzliche Informationen - Body: Eigentliche Daten (payload) in XML Format
Variablen, Array
Entfernte Methodenaufrufe
# Message Exchange Pattern (MEP)
Beschreiben, wie Nachrichten zwischen zwei SOAP Knoten ausgetauscht werden
- Anzahl der Nachrichten
- Nachrichten Ursprung
Mindestens ein MEP muss unterstützt werden
Request-Response
- Initiale SOAP Anfrage von anfragenden Knoten
- Antwortende Knoten antwortet direkt mittels SOAP
Nachricht auf die Anfrage, anderenfalls sendet er eine SOAP Fehlermeldung
SOAP Response
- Initiale Anfrage ist keine SOAP Nachricht
- Antwortende Knoten antwortet mit einer SOAP Nachricht auf die Anfrage
- Dadurch ist es z.B. möglich, eine HTTP Anfrage mit einer SOAP Nachricht zu beantworten
# SOAP - Zwei Modi zur Kommunikation
- RPC-style
Ruft eine Methode auf einem anderen Computer auf
Nachricht enthält eine Referenz auf die Methode
Parameter werden als Wert übergeben
Zielmethode wird ausgeführt und eine Antwort wird sofort zurück gesendet
Fest gekoppelte synchrone Kommunikation
Nachrichtenaufbau ist abhängig von der aufzurufenden Methode
- Document-style
Wohlgeformte XML Nachrichten werden verschickt
XML-Daten können mittels XML Schemata validiert werden
Synchrone und asynchrone Kommunikation
Gut, wenn bereits existierende Datenmodell genutzt werden sollen
Mit einem eindeutigen Identifizieren können auch Antworten zu Anfragen zugeordnet werden
# SOAP binding
- Beschreibt das mögliche Transportprotokoll zwischen den SOAP Knoten,
- Prinzipiell kann jedes Protokoll genutzt werden
- Beide Seiten müssen ein Protokoll unterstützen
- Am häufigsten wird HTTP benutzt
# HTTP-Header
# Inhaltstype ab SOAP 1.2
# Länge der Nachricht
--------------------------------------------------------------------------------
POST /webservice.php HTTP/1.0
Host: localhost
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 516
# XML-Format
# XML-Header
# Envelope mit verwendeten
# Namensräumen
--------------------------------------------------------------------------------
<?xml version="1.0" encoding="utf8">
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns4="urn:MeinZeitService"
# Definiert RPC-style encoding
--------------------------------------------------------------------------------
SOAP-ENV:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/">
# Body
# Aufzurufende Methode
# Parameter
# Kann auch verschlüsselt werden
--------------------------------------------------------------------------------
<SOAP-ENV:Body>
<ns4:jetzt>
<format xsi:type="xsd:string">H:i:s</format>
</ns4:jetzt>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
# SOAP Fehler
Tritt ein Fehler beim SOAP-Aufruf auf, wird ein <Fault>-Element zurück gegeben
<SOAP-ENV:Fault>
<faultcode xsi:type="xsd:QName">
soap:Client
</faultcode>
<faultstring xsi:type="xsd:string">
Ein Fehler ist aufgetreten
</faultstring>
</SOAP-ENV:Fault>
- Client: Fehler im SOAP-Client
- MustUnderstand: Ein Element im Header mit Attribut mustUnderstand="true" wird nicht verstanden
- Server: Fehler im SOAP-Server
- VersionMismatch: Falsche SOAP Version
In <faultstring> kann eine beliebige
Fehlermeldung ausgegeben werden
# WSDL
Quellcode eines Web Services liegt oftmals nicht vor und so muss beschrieben werden,
wie ein Web Service zu nutzen ist.
Web Services Description Language
Aktuell Version 2.0 (Juni 2007)
Nur Version 1.1 wird von PHP unterstützt
WSDL ist eine XML basierte Sprache, die beschreibt
- Was der Web Service macht
- Wo der Web Service gefunden werden kann
- Wie der Web Service genutzt werden kann
WSDL beinhaltet zwei Hauptelemente
- Funktionale Beschreibungen
Wo müssen die Nachrichten hingeschickt werden?
Wie sieht die Nachrichtensyntax aus?
Welche Netzwerk Protokolle und Encoding-Schemen werden benutzt?
- Nicht funktionale Beschreibungen
Wozu dient der Web Service
Wer ist der Web Service Anbieter
WSDL beschreibt nicht:
Quality-of-Service-Informationen
Taxonomien (Klassifikation, Kategorisierung)
Ontologien (formale Spezifikation – KI)
# Aufbau
WSDL document
<definitions>
- Wurzelelement
<types>
- Definition aller Datentypen
- Definition mit XML Schemas
- Eingebaute Datentypen müssen nicht definiert werden
<message>
<part>
- Struktur der Nachrichten
- Parameter und Rückgabewerte
- Basieren auf der <types> Definition
<portType>
<operation>
- Definiert Operationen
- Basieren auf der <message> Definition
- Ordnet einer Operation Nachrichten zu
<binding>
<operation>
- Nachrichten Encoding und Transport
- Protokoll wird definiert
- Abstrakte Definition wird einer konkreten Implementierung zugeordnet
<service>
<port>
- Definiert die Schnittstelle des Service
- Greift dabei auf die <binding> und <portType> zurück
# Web Services - Sicherheit
- Authentifizierung: Wer ist der Benutzer
- Autorisierung: Wer darf wo zugreifen
- Vertraulich: Keiner darf mitlesen
- Integrität: Nicht modifiziert
- Reputation: Feststellung was gesendet wurde (Online-Handel)
Standards
SSL: Kommunikation über https verlangt keine weiteren Änderungen
XML Encryption (bereits geknackt) / XML Signature: W3C Standard zur Verschlüsselung von XML-Daten
WS-Security: OASIS Standard, Version 1.1
OASIS WS-Security hat sich als Standard durchsetzen
- Web Service Security unterstützt Integrität, Vertraulichkeit und Authentifizierung.
Erweiterungen:
- WSSecutityPolicy
XML Syntax, um für Web Services Sicherheitsrichtlinien zu definieren
- WS-Trust
Protokoll für die Zugriffsregelung und Austausch von security Tokens
- WS-Secure Conversation
Formatbeschreibungen für sichere Kontexte und sichere Kommunikation
- WS-Federation
Definiert wie security Tokens zwischen Sicherheitsbereichen verteilt werden
- WS-Privacy
Definiert Richtlinien für Vertraulichkeit
- WS-Authorization
Definiert wie Zugriffsrichtlinien in WS definiert und verwaltet werden
# REST: Representational State Transfer
Architekturstil mit Fokus auf der Architektur des Webs
Realisierung von Web Services in webgerechter Weise
Ressourcenorientiert – auch als ROA (Resource Oriented Architecture) bezeichnet
# Ressourcen (Eigenschaften)
- Ein Web Service kapselt Ressourcen
- Beispiele für Ressourcen: Bücher, News, Bilder, ...
- Ressourcen werden über einen standardisierten und einheitlichen Mechanismus angesprochen, die URI
Eine Ressource kann seinen Zustand ändern
# Repräsentationen
- Sind die Darstellungen einer Ressource# Methoden
- GET
- fragt die Repräsentation einer Ressource ab
- lesende Operation
- idempotent
- PUT
- Erzeugt eine neue Ressource oder aktualisiert sie
- Idempotent
- POST
- kann einer bestehenden Ressource etwas hinzufügen
- nicht idempotent
- DELETE
- löscht eine Ressource
- idempotent
- HEAD
- Metadaten über eine Ressource holen
- selten genutzt
- idempotent
- OPTIONS
- Rückgabe unterstützter Methoden
- selten genutzt
- idempotent
# Beispiel Bibliothek:
besteht aus einer Reihe von Büchern
neue Bücher können hinzugefügt werden
es gibt Bibliotheksnutzer
Nutzer darf sich 2 Bücher ausleihen
Nutzer kann Bücher zurückbringen
Auflisten von Büchern und Nutzern
- Um Objekte zu finden, wird nach Nomen geschaut
Buch
Nutzer
- alle Geschäftsabläufe werden zu Methoden
neues Buch/Nutzer aufnehmen
Bücher/Buchdaten und Nutzer/Nutzerdaten auflisten
Buchstatus erfassen (Ausleihe/Rückgabe)
Buchdaten ändern
Buch löschen
- Operationen, HTTP Methoden URIs
HTTP Methoden URI Beschreibung
GET /book Bücher auflisten
POST /book Buch aufnehmen
GET /book/42 Buch holen
PUT /book/42 Buchdaten ändern
DELETE /book/42 Buch löschen
URI: /book oder /book/<b_id>
einfache Operationen sind nun möglich
- für komplexere Operationen wie Verleih und
Rückgabe muss die URI erweitert werden
Verleih /user/<u_id>/book/<b_id>
Rückgabe /user/<u_id>/book/<b_id>
URI HTTP Erfasst Operation /book GET book alle Bücher auflisten /book POST book Buch neu aufnehmen /book/<b_id> GET book Buchdaten auflisten /user GET user alle Nutzer auflisten /user POST user neuen Nutzer aufnehmen /user/<u_id> GET user Daten eines Nutzers /user/<u_id>/ GET user zeige Ausleihstatus book diese von Büchern /user/<u_id>/ POST user Leihe Buch ausbook/<b_id> /user/<u_id>/ DELETE user Buch Rückgabe book/<b_id> idempotent # Fehlerbehandlung in RESTful - Im Service
- HTTP-Statuscode werden genutzt
- Wenn Status 200 OK ist, ist keine Aktion notwendig
- Ansonsten Status mit header() setzen
header("HTTP/1.0 501 Not Implemented");
- Im Client
HTTP-Statuscode kann mit curl abgefragt werden
curl_getinfo($ch, CURLINFO_HTTP_CODE);
# Die Zustandsspeicherung ist im SOA Umfeld ein wichtiges Thema. Um die
Zustandsspeicherung zu erleichtern sind „Dreischicht-Anwendungen“ eingeführt worden.
Beschreiben Sie stichpunktartig die Probleme die durch Zustandsspeicherung auftreten und
wie diese durch „Dreischicht-Anwendungen“ gelöst werden.
- Datenhaltungsschicht
Mehrschichtige Systemarchitekturen wie die dreischichtige Architektur sind gut skalierbar,
da die einzelnen Schichten logisch voneinander getrennt sind. So kann z. B. bei verteilten Systemarchitekturen die Datenschicht
auf einem zentralen Datenbank-Server laufen, die Logikschicht auf Workgroup-Servern, und die Präsentationsschicht
befindet sich auf der jeweiligen Workstation des Benutzers.
# Nennen und Beschreiben Sie die 4 Grade der Serviceautonomie. Spezifizieren Sie auch den
Fokus, den Bereich und die Isolation. (8 Punkte)
1. Servicevertrag
- Serviceverträge werden aufeinander abgestimmt, damit
sich die Funktionalität nicht überschneidet
2.Geteilte Autonomie
- Die Logik und Ressourcen der zugrunde liegenden
Serviceimplementierung werden mit anderen Teilen des
Unternehmens gemeinsam genutzt
3. Autonomie der Servicelogik
- Die zugrunde liegende Logik ist isoliert, aber die
Datenressourcen werden mit anderen Teilen des
Unternehmens gemeinsam genutzt
4. Reine Autonomie
- Die zugrunde liegende Logik und die Datenressourcen
sind isoliert und nur dem Service gewidmet
Mehrere Isolationsgrade fallen unter diese Kategorie:
1. Funktionale Isolation
Servicekomponenten und physikalische Datenmodelle sind
dediziert, aber der Service wird mit anderen zusammen auf
einem Server gehostet.
2. Absolute Isolation
Servicekomponenten und physikalische Datenmodelle
liegen auf einem dedizierten Server.
Servicemodelle
1. Entity-Service
Entity-Services sind in der mittlere Ebene
angesiedelt. Sie sind die geborenen Kandidaten für
die “Reine Autonomie”, selbst wenn sie auf die
absolute Isolation verzichten müssen. Ihre
Normalisierung erreicht einen hohen Grad. Sie
vermitteln zwischen Task-Services und Utility-
Services.
2. Utility-Service
Diese Services sind in der untersten Ebene zu finden
und die Quelle der agnostischen Lösungslogik. Sie
werden von der Autonomie unterstützt und sind
ebenso Kandidaten für Kompositionen, wie auch die
Entity-Services. Ihre Umsetzung ist jedoch
schwieriger durch die funktionale Normalisierung
und Autonomie. Die Skalierbarkeit und
Nebenläufikeit sind essentiell, um die höheren
Ebenen nicht zu beeinflussen. Ihre Aufgabe besteht
auch häufig in der Kapselung von Legacy-APIs.
3. Task-Service
Sie bilden die höchste Ebene und sind im
Allgemeinen die Kompositions-Controller. Durch
Erhöhung ihrer Autonomiegrade kann man die
Fähigkeiten verbessern. Meist werden sie in
räumlicher Nähe zu den zu verwaltenden Services
platziert. Es sind Middleware-Produkte für die
Orchestrierung und bewirken eine Steigerung der
Laufzeitautonomie. Ihr Grad hängt von den Graden
der zu verwaltenden Services ab.
# Prinzipien der Serviceorientierung
# Serviceverträge (Standardisierung und Entwurf)
Der Servicevertrag ist ein Kernstück des Services und im gesamten Service-Entwurfsprozess von derart zentraler Bedeutung,
dass ihm ein eigenes Prinzip gewidmet ist. Dieses Kapitel erklärt verschiedene Typen der (notwendigen) Vertragsstandardisierung
und erläutert, auf welchen Ebenen Verträge harmonisiert werden können. Das Kapitel diskutiert die implizit durch Serviceverträge
auftretenden Fragen, wie zum Beispiel Versionierung und Dauerhaftigkeit des Services, und es beschreibt, welche Stellung Verträge
in der Architektur einnehmen, wobei der Schwerpunkt auf Webservices liegt.
# Lose Kopplung von Services (Beziehungen und Abhängigkeit)
In diesem Kapitel werden viele Arten der Kopplung untersucht,
unter anderem die Kopplung des Servicevertrags an die zugrunde
liegenden Details von Technologie und Implementierung und die
Kopplung von Service-Consumern an den Vertrag. Es werden die
Grade der Kopplung und die Implikationen einer mehr oder weniger
intensiven Service-to-Service-Abhängigkeit ausgelotet. Darüber
hinaus wird das Konzept der Entwurfszentralisierung als Mittel
zur Erreichung einer losen Kopplung in Koordination mit anderen
Prinzipien eingeführt.
# Abstraktion von Services (Verbergen von Informationen und Arten der Meta-Abstraktion)
Die Anwendung dieses Prinzips entscheidet darüber,
wie viel von einem Service gegenüber der Außenwelt offengelegt wird.
Einen ausgewogenen Grad an Abstraktion zu erzielen gehört mit zu den
schwierigsten Teilen des Serviceentwurfs. In diesem Kapitel werden die
verschiedenen Formen und Grade der Abstraktion beschrieben und im
Anschluss daran die jeweils damit verbundenen Risiken diskutiert.
Schließlich wird untersucht, welchen Einfluss Abstraktion als
Entwurfsprinzip auf die anderen Prinzipien hat.
# Wiederverwendbarkeit von Services (kommerzieller und agnostischer Entwurf)
Den Wert der Lösungslogik zu steigern,
indem Services als wiederverwendbare IT-Assets positioniert
werden, ist ein charakteristisches Merkmal und Ziel der
Serviceorientierung. Dieses Kapitel diskutiert umfassend das
Prinzip der Wiederverwendbarkeit von Services und seine Folgen,
wobei auch die verschiedenen Grade der Wiederverwendung von Services
sowie die besonderen Einflüsse durch Aspekte kommerziellen Entwurfs
untersucht werden. Die Messung der geplanten und tatsächlichen
Wiederverwendung sowie die Risiken und unternehmensweiten Folgen
der Erstellung und Bereitstellung agnostischer Servicelogik sind
weitere Schwerpunkte dieses Kapitels.
# Autonomie von Services (Grenzen und Steuerung der Verarbeitung)
Die Fähigkeit eines Services, Kontrolle und Herrschaft über seine
eigene Ausführungsumgebung zu übernehmen, ist der Schlüssel zur Erzielung
zuverlässiger, berechenbarer Laufzeit-Performance – ein Aspekt, der
besonders für den Entwurf von Servicekompositionen von Belang ist.
Dieses Kapitel untersucht sowohl die Laufzeit- als auch Entwurfszeitautonomie
und liefert Bemessungsgrundlagen für Autonomiegrade, die auf dem
Grad der Normalisierung und funktionalen Isolation beruhen.
# Zustandslosigkeit von Services (Zustandsverzögerung und zustandsloser Entwurf)
Serviceentwürfe, die in der Lage sind, Zustandsdaten und zur
Zustandsverwaltung gehörige Verarbeitungslast zu verschieben,
maximieren die Verfügbarkeit des implementierten Service – eine
Qualität, die besonders in Umgebungen mit stark nebenläufiger Nutzung
von Bedeutung ist. In Kapitel 11 finden Sie eine detaillierte
Erläuterung der verschiedenen Typen von Zustandsinformationen
und Zustandsverwaltungsfunktionen, gefolgt von den Graden der
Zustandslosigkeit, die Services erreichen können.
# Auffindbarkeit von Services (Interpretierbarkeit und Kommunikation)
Services können nur dann ihr volles Potenzial realisieren, wenn ihre
Existenz, Zielsetzung und Fähigkeiten entweder bekannt oder leicht
zu finden und zu verstehen sind. In diesem Kapitel geht es um die
Entwurfsmerkmale, die zur Auffindbarkeit und Interpretierbarkeit
von Services führen. Den Gesamtzusammenhang bildet der gesamte
Auffindbarkeitsaspekt der serviceorientierten Architektur. Neben
einer Checkliste zur Bemessung der Auffindbarkeit bietet dieses
Kapitel auch Abschnitte über die Risiken und Folgen der Auffindbarkeit
für Servicemodelle und andere Prinzipien.
# Kompositionsfähigkeit von Services (Entwurf von Mitgliedern einer Komposition und komplexe Kompositionen)
Servicekomposition ist ein grundlegender, aber
potenziell komplexer Aspekt des serviceorientierten Entwurfs.
Dieses Prinzip legt Entwurfsanforderungen fest, die
gewährleisten, dass Services auch in größeren
Kompositionskonfigurationen wirkungsvoll eingesetzt
werden können. Weitere Themen sind die Entwicklung und
Erweiterung, die Kompositionen in der Regel in Unternehmen
durchmachen, sowie eine Reihe von Bewertungskriterien, um
die potenzielle Kompositionsfähigkeit von Services
besser bemessen zu können.