Aufgabe: Nachrichtendesign |
|
 |
Diese Aufgabe beschreibt die erforderlichen Aktionen für die Entwicklung eines umfassenden Nachrichtendesignmodells (Katalog). Dazu gehört auch eine Erläuterung der Nachrichtenaustauschmuster und der Beziehung zwischen Domänenmodell und Nachrichtenmodell. Überlegungen zum Design für die Nachrichtenunterteilung und die Nachrichtenleistung werden ebenfalls angestellt. |
Disziplinen: Analyse und Design |
|
Beziehungen
Rollen | Primärer Ausführender:
| Zusätzliche Ausführende:
|
Eingaben | Verbindlich:
| Optional:
|
Ausgaben |
|
Prozessverwendung |
|
Hauptbeschreibung
Zwischen kommunizierenden Services und Komponenten ausgetauschte Nachrichten sind kritischer Bestandteil einer SOA. Hierzu
gehören neben den Ein- und Ausgabenachrichten eines gegebenen Serviceaufrufs auch das innerhalb des Unternehmens zu
verwendende interne Nachrichtenformat für den Informationsfluss durch die Schichten der Anwendungsarchitektur. In vielen
Fällen ist ein einheitliches Nachrichtenformat zu empfehlen.
Da Services Ein- und Ausgabenachrichten umfassen, hat diese Aufgabe folgende Schwerpunkte:
-
Identifizieren und Spezifizieren von Format und Inhalt der Ein- und Ausgabenachrichten eines Service,
-
der Beziehung des Service zu den zugrunde liegenden Datenmodellen,
-
des internen allgemeinen Nachrichtenformats sowie der Aspekte und
-
Entscheidungen hinsichtlich der Zuordnung dieser Nachrichten zueinander.
Bei der Spezifizierung von Nachrichten für das Servicemodell sollten die Unternehmens-/Anwendungsarchitektur, die
Datenarchitektur sowie die Integrationsarchitektur berücksichtigt werden. Dazu gehören folgende Punkte:
-
auf Unternehmens- oder Anwendungsebene definierte Nachrichtenstandards
-
ein geeignetes Meta- oder Datenmodell, das Teil einer Datenarchitektur ist
-
Nachrichtenkonvertierungsstandards, die Teil einer Integrationsarchitektur sind
Es ist wichtig, dass Sie während der Spezifikation die ggf. vorhandenen Standards einer Organisation in allen drei
Architekturbereichen im Blick haben. Nachrichtenspezifikationen und Datenmodelle sind eng miteinander verknüpft. Das
Datenmodell besteht aus zugrunde liegenden Entitäten und deren Beziehungen, von denen ein Teil im Rahmen einer
Ausgabenachricht gesendet und als Eingabe in Form einer ankommenden Nachricht empfangen werden kann. Die Abbildung der
Nachrichtenformate auf dem zugrunde liegenden Datenmodell bzw. der zugrunde liegenden Datenarchitektur ist daher einer
der architektonischen Schlüsselaspekte. In einigen Fällen kann die Konvertierung (und Weiterleitung) von Nachrichten
durch Muster und ihre Implementierung, z. B. den Enterprise Service Bus, ausgeführt werden. Häufig wird für die
Konvertierung von Nachrichten von Datenmodellen und in Datenmodelle ein expliziter Handler benötigt.
In den meisten objektorientierten Programmiersprachen basiert der Aufruf des Verhaltens entweder auf Methodenaufrufen
oder Paradigmen der Nachrichtenübergabe. Beispielsweise verwendet C++ Tabellen von Funktionszeigern, um die richtige
Methode aufzurufen. Andererseits übergibt Smalltalk Nachrichten, deren Empfänger zur Ausführungszeit bewertet wird.
Serviceorientierte Lösungen sind per se nachrichtenbasiert. Bindungen zu Programmiersprachen können zwar
methodenbasierte Schnittstellen für Clients darstellen, das trifft jedoch nicht auf die Kommunikation mit bzw. zwischen
Services zu. Eine weitere Facette der Servicenachrichten ist, dass immer mehr Services mit asynchronen Schnittstellen
entwickelt werden, im Gegensatz zu der grundsätzlich synchronen Beschaffenheit von Methodenaufrufen.
Im Bereich der Unternehmensintegration wurde eine Technologieklasse mehrere Jahre erfolgreich eingesetzt: Message
Oriented Middleware (oder MOM). Diese Technologiegruppe erscheint in Form von Produkten wie Warteschlangenmanagern und
Nachrichten-Brokern. Sie stellt IT-Abteilungen eine flexible, skalierbare und stabile Methode für die lose Verbindung
von Anwendungen zur Verfügung.
Es wurde bereits erwähnt, dass serviceorientierte Architektur eine Weiterentwicklung der komponentenbasierten
Entwicklung ist. In mancherlei Hinsicht berücksichtigt diese Weiterentwicklung viele Erfahrungen, die mit der
erfolgreichen Nutzung von MOM verbunden sind. Insbesondere geht es darum, wie Systeme effektiv lose gekoppelt werden
können. Die MOM-Infrastruktur bietet folgende Merkmale, die Kommunikationssystemen erlauben, sich unabhängig
weiterzuentwickeln:
-
Nachrichtenwarteschlangen für die zuverlässige Lieferung von Nachrichten selbst bei Netz- oder
Systemausfällen.
-
Nachrichtenweiterleitung, sowohl die Weiterleitung im Netz, um Leistung und Zuverlässigkeit sicherzustellen,
als auch die erweiterte, auf dem Nachrichteninhalt basierende Weiterleitung.
-
Nachrichtenkonvertierung, damit ein aufrufender Service eine Anfrage nach einem "Produkt" übergeben kann,
wenn der empfangende Service in der Lage ist, Anfragen nach "Elementen" zu akzeptieren.
-
Nachrichtenadapter, damit Systeme, die ursprünglich nicht mit MOM-Schnittstellen entwickelt wurden, von
Services, die MOM unterstützen, adressiert werden können.
|
Schritte
Nachrichtenstandards verwenden
Beim Definieren der Nachrichtenspezifikationen für identifizierte Services ist es wichtig, ggf. vorhandene
Nachrichtenstandards eines Unternehmens zu berücksichtigen. Wenn keine Nachrichtenstandards definiert sind, sollten solche
Standards entwickelt werden. Eventuell vorhandene branchenspezifische Nachrichtenschemata sollten genutzt werden.
XML-Spezifikationen wurden beispielsweise für die Finanzwirtschaft, für Regierungsbehörden, für die Reisebranche (OTA XML
[Open Travel Alliance, http://www.opentravel.org/online_schema.cfm]) und für die
Kommunikationsbranche entwickelt. Darüber hinaus gibt es branchenunabhängige Schemata von OAGIS [Open Applications Group,
http://www.openapplications.org/index.htm].
Einheitliches
Nachrichtenformat
Allgemeine Nachrichten sind Nachrichten, die durch die Schichten einer mehrschichtigen Architektur weitergeleitet
werden. Informationen der Benutzerschnittstelle werden in der Regel erfasst, durch eine Controllerschicht gesendet, in
den Geschäfts- oder Anwendungsschichten verarbeitet und dann an eine Persistenzschicht oder zurück an ein herkömmliches
Back-End-System übergeben werden. Während all dieser Übertragungen werden Nachrichten zwischen den Schichten
ausgetauscht, die jeweils verschiedene Formate haben können. Der entscheidende Punkt ist die Vereinbarung eines
Standards für ein einheitliches Nachrichtenformat innerhalb des Unternehmens, um den Aufwand für die Formatumsetzung zu
vermeiden, wenn kein Enterprise Service Bus (ESB) verwendet wird oder als zu teuer für die Formatumsetzung angesehen
wird. Ein ESB kann einen großen Teil dieser Vermittlung, Konvertierung und Weiterleitung ausführen. Dies findet in der
Integrationsschicht des SOA-Schichtenmodells statt.
In einigen Fällen kann eine Einigung auf ein Format für ankommende und abgehende Nachrichten ausreichen. Die Frage
eines einheitlichen Nachrichtenformats ist eine architektonische Schlüsselentscheidung. Sie können können sich für ein
eigenes Format entscheiden, branchenspezifische Modelle wie OTA XML für die Reisebranche übernehmen oder bestimmte
branchenunabhängige Modelle, wie die von OAGIS definierten, einführen. In einigen Fällen wird eine Entscheidung für ein
einheitliches Unternehmensnachrichtenformat fallen, das Felder in der Nachricht aktualisiert und die Nachricht dann zur
weiteren Verarbeitung an die nächste Schicht übergibt. Falls aus politischen Gründen keine Einigung über ein solches
einheitliches Schema möglich ist, können Adapter entworfen werden, die Nachrichten in ein internes einheitliches
Nachrichtenformat umsetzen. Die Adapter können auch als Teil eines ESB
genutzt werden.
Hinweise
zu unabhängigen Softwareanbietern: Nachrichten,
die in Paketen unabhängiger Softwareanbieter realisierte Services aufrufen, müssen unter Umständen mit Datenattributen
erweitert werden, um den Einschränkungen des Datenmodells im Paket des unabhängigen Softwareanbieters gerecht zu
werden. Solche Datenelemente können durch die Analyse des realisierten Service innerhalb der Komponente oder durch eine
Bottom-up-Serviceanalyse für das Paket des unabhängigen Softwareanbieters identifiziert werden. Da diese Attribute erst
identifiziert werden können, wenn der Service realisiert ist, müssen Sie möglicherweise nach der Identifizierung an die
allgemeine Nachricht angepasst werden.
Einheitliches Nachrichtenformat und Datenarchitektur
Services sollten generell keine Angaben zu den zugrunde liegenden
Datenmodellen machen. Sie sollten eher verwendet werden, um die zugrunde liegenden Datenmodelle zu kapseln, deren
Datenspeicher von den Servicekomponenten genutzt werden, die die Services realisieren. Services, die Anzeige-,
Bearbeitungs-, Lösch-, Hinzufüge- und Suchoperationen für eine Datenbank oder andere Datenbankoperationen sind, sind
möglicherweise nicht besonders geeignete Services, können jedoch als Basiskomponentenoperationen verwendet werden, wie
es heute bereits der Fall ist.
Vorhandene Datenarchitekturen, die
konzeptionelle oder physische Datenmodelle definieren, sind für die Definition einheitlicher Nachrichtenformate
notwendige Quellen. Die Definitionen einheitlicher Nachrichtenformate sollten mit Arbeiten an der Datenarchitektur und
an Datenmodellen koordiniert werden. Die Analyse vorhandener Datenarchitekturen und Datenmodelle stellt sicher, dass
geeignete Datenspeicher und Schemata für die Servicekomponenten verfügbar sind, die neue Services realisieren sollen.
Die vorhandene Datenarchitektur wird erweitert, um neue Services aufnehmen zu können, sofern zu den zugrunde liegenden
Systemen neue Daten hinzugefügt werden müssen.
In vielen Unternehmen nehmen sich
vorhandene Systeme oft wie Silos und Dateninseln aus, die über Stapelprozesse kollaborieren. Mit Hilfe von Services ist
eine Migration weg von isolierten Datenspeichern möglich. Die Datenquellen eines Serviceproviders werden während der
Servicerealisierung identifiziert.
Hinweise zu unabhängigen Softwareanbietern:: Das logische Datenmodell muss
Raum für die vordefinierten, oft impliziten Datenmodelle von Paketen unabhängiger Softwareanbieter vorsehen. Das bedeutet, dass zwischen Standardsoftwareanwendungen und den vorhandenen
Datenmodellen ein Nachrichtenaustausch stattfinden muss. Hierfür werden oft von den unabhängigen Softwareanbietern
angebotene APIs verwendet. In einer SOA gewinnen Adapter für diese Datenmodelle unabhängiger Softwareanbieter an
Bedeutung. Dies gilt insbesondere, wenn der unabhängige Softwareanbieter seine zugrunde liegenden Daten und Funktionen
nicht durch Services verfügbar macht.
Beachten Sie, dass in einigen Fällen
das Datenmodell des unabhängigen Softwareanbieters angepasst werden kann, um die erforderlichen Nachrichten zur
Unterstützung der identifizierten Services aufzunehmen. Dazu muss das Datenmodell des Softwareanbieters jedoch
zugänglich sein. Ist das Datenmodell nicht zugänglich, kann der Austausch von Servicenachrichten dagegen durch das
Datenmodell des unabhängigen Softwareanbieters eingeschränkt werden. Zur Verringerung des Problems kann auch ein
Mediationsmechanismus eingesetzt werden. In diesem Kontext kann beispielsweise die durch einen ESB bereitgestellte
Mediation zur Unterstützung der Anbindung an Pakete unabhängiger Softwareanbieter verwendet werden. Das Datenmodell des
unabhängigen Softwareanbieters kann auch weitere Attribute vorschreiben, die zusätzlich zu den für die
Serviceimplementierung erforderlichen Attributen erforderlich sind.
Einheitliches Nachrichtenformat mit
allen relevanten Services
Einheitliche
Nachrichtenformate müssen mit den Ein-/Ausgabenachrichten einzelner Services abgestimmt werden. Die Beziehung und
Zuordnung zwischen Nachrichtenformaten und den Nachrichten der Services muss so erfolgen, dass entsprechende Services
für ihre Verwendung und Aktualisierung verwendet werden können. Unter Umständen müssen Services Informationen aus dem
einheitlichen Unternehmensnachrichtenformat extrahieren oder Ausgaben dieses Formats empfangen. Diese sind in der Vorlage "Einheitliches Nachrichtenformat für Services"
dokumentiert.
|
Domänenmodell wiederverwenden
Im Abschnitt zum Konzept Domänendesign
wurde analog zum Begriff eines Analysemodells bzw. Geschäftsanalysemodells der Begriff der Domänenmodellierung zur
technologieunabhängigen Darstellung von Kernkonzepten der Geschäftsdomäne umrissen. Die von Services verwendeten
Nachrichten sind ebenso technologieabhängig (wenn nicht gar technologiespezifisch, wie es beim XML-Schema für
Web-Services der Fall ist), wie das zum Speichern der Domänendaten innerhalb des Service verwendete Datenbankschema
technologiespezifisch ist. Es kann von folgender Beziehung ausgegangen werden:
Die folgende Abbildung veranschaulicht die Beziehung zwischen dem Domänenmodell, das zur Ermittlung der
Schlüsselelemente der Domäne verwendet wird, und dem Nachrichtenmodell als Realisierung des Domänenmodells, d. h. als
Gruppe von Elementen, die an Services übergeben und von diesen zurückgegeben werden.
Es folgt ein typisches Java-Komponentenmodell, in dem die Trennung der Schnittstelle von der Klasse und die Aufnahme
von Zugriffsfunktionen für das Abrufen und Setzen des Wertes der Zustandsvariablen dargestellt ist. Das ist ein
allgemein üblicher Ansatz, der jedoch den Nachteil hat, dass, wenn der Konsument und die Komponente sich in
verschiedenen Adressbereichen oder auf verschiedenen Maschinen befinden, der Aufwand für die Kommunikation der
einzelnen Aufrufe hoch ist in dem Sinne, dass der Gesamtzustand der Komponente abgerufen werden muss.
Ein anderes Problem sind die Beziehungen zwischen Komponenten. Das Konzept eines Account, der eine Gruppe von Kunden
hat, ist in diesem Stil schwierig zu entwickeln. Schließlich werden meist Listen von Kennungen zum Abrufen einzelner
Objekts verwaltet.
Bei der Entwicklung eines Servicemodells kann über einen Ansatz mit einer datengesteuerten Serviceidentifikation ein Service AccountMgr und ein
Service MeetingMgr spezifiziert werden. Die erste Servicespezifikation fungiert als zentraler Punkt für die Verwaltung
aller Accounts und Kontakte. Tatsächlich wurde das Kerndatenmodell für die CRM-Lösungen (Customer Relationship
Management) mit diesem und anderen Services erstellt. Der zweite Service wurde abgetrennt, da er von den CRM-Lösungen
und anderen Lösungen für Buchungsbesprechungen genutzt werden kann und eine Schnittstelle mit den Groupwareanwendungen
des Unternehmens bildet.
Das folgende Beispiel aus dem Modell veranschaulicht die Servicespezifikationen. Die Nachrichten können vom oben
dargestellten Domänenmodell übernommen werden.
|
Nachrichtenaustauschmuster verstehen
Nachrichten werden oft lediglich als Parameter für Operationen betrachtet. Das ist umso mehr der Fall, als die
UML-Darstellung von Services Operationen mit Parametern umfasst und Web Services Description Language (WSDL 1.1) einen
ähnlichen Ansatz verwendet. Im Kontext von Services und Servicespezifikationen ist es jedoch sinnvoller, Nachrichten
als wiederverwendbare Elemente zu betrachten, die von einer Serviceoperation verwendet bzw. konsumiert werden. Im
Kontext der Services wird die Operation einfach zu einem Nachrichtenaustausch, obwohl ein benannter Austausch
für einen Service, der sich von einem anderen Austausch unterscheidet, möglicherweise dieselben Ein- und
Ausgabenachrichten verwendet.
Der Begriff der Nachrichtenaustauschmuster ist im Bereich der Web-Services-Standards von Interesse, wenn es
darum geht, die Verwendung von Services bei der Entwicklung von Standards, mit denen ihre Spezifikation unterstützt
werden soll, zu analysieren. Ein Nachrichtenaustauschmuster benennt eine bestimmte Kombination aus erstellten,
verwendeten oder konsumierten Nachrichten, die es zwischen zwei Services (oder zwischen einem Service und einem
Konsumenten) gibt, und stellt Servicedesignern ein allgemeines Vokabular bereit, das zum Beschreiben von Operationen
für Servicespezifikationen verwendet werden kann.
Im Folgenden sind allgemeine Austauschmuster aufgeführt, die in der Definition von Servicespezifikationen verwendet
werden können. Solche Muster werden normalerweise bei der Modellierung von Servicekollaborationen gefunden.
Synchrone Anfrage/Antwort: Das ist tatsächlich ein traditioneller Methodenaufruf, bei dem der Servicekonsument
eine Nachricht an einen Service sendet und dann blockt, bis er eine Antwort vom Service empfängt.
Einwegnachricht: In diesem Fall sendet der Konsument einfach eine Nachricht an den Service, ohne auf eine
Antwort zu warten bzw. überhaupt eine Antwort zu erwarten. Dieses Muster kann als asynchroner Methodenaufruf ohne
Antwort betrachtet werden, d. h., dass der Servicekonsument nach dem Senden der Nachricht weiter ausgeführt wird und
nicht darauf wartet, dass der Service die Nachricht verarbeitet.
Benachrichtigung: In diesem Fall ist der Service dafür zuständig, Nachrichten an den Konsumenten (normalerweise
einen anderen Service) zurückzuschicken. Dazu muss der Konsument beim Service registriert sein, damit der Service weiß,
wohin er die Benachrichtigung schicken soll.
Asynchrone Anfrage/Antwort: Das ist eine Kombination aus Einwegnachricht und Benachrichtigung. Der
Servicekonsument sendet eine Nachricht einschließlich einer Antwortadresse. Wenn der Service seine Verarbeitung
abschließt, ruft er den Absender zurück. Der Umstand, dass Servicekonsumenten die erste Nachricht asynchron senden,
bedeutet, dass sie alle gesendeten Anfragen überwachen müssen, damit Antworten, wenn sie vom Service empfangen werden,
der ursprünglichen Anfrage zugeordnet werden können.
Publish/Subscribe: Hierbei handelt es sich ebenfalls um eine Kombination. Ein Servicekonsument registriert sich
für ein "Thema" bei einem Veröffentlichungsservice. Andere Services oder Servicekonsumenten veröffentlichen Nachrichten
(senden Nachrichten) im Veröffentlichungsservice und identifizieren das der Nachricht zugeordnete Thema. Wenn das Thema
mit zuvor durchgeführten Registrierungen von Konsumenten übereinstimmt, erhalten diese eine Benachrichtigung zur neuen
Nachricht. In diesem Fall ist es möglich, die teilnehmenden Services sehr lose miteinander zu verbinden. Alle
Konsumenten oder Veröffentlichungskomponenten müssen lediglich die Position des Veröffentlichungsservice kennen, und
neue Konsumenten können ohne großen Aufwand zur Lösung hinzugefügt werden.
|
Nachrichtenunterteilung verwalten
Services haben den Zweck, grob unterteilte Operationen bereitzustellen. Daher ist auch der Nachrichtenfluss in diese
Operationen bzw. aus diesen Operationen oft nicht detailliert. Dieses Problem wurde ursprünglich in der frühen
Deployment-Phase der Web-Services-Lösungen hervorgehoben, als HTTP für den Transport, SOAP als Protokoll und XML als
Sendeformat verwendet wurden, was oft relativ lange Reaktionszeiten und sehr hohe Anforderungen an die Bandbreite zur
Folge hatte. Nehmen Sie beispielsweise an, bei einem Service geht eine Anfrage nach einer Börsennotierung ein. In der
frühen Phase der Web-Services wurde häufig eine einfache Börsennotierung zu Demonstrationszwecken verwendet. Das
Tickersymbol besteht aus vier Zeichen, und die Antwort ist eine Dezimalzahl. In einem Binärprotokoll mit RPC-Stil ist
zu erwarten, dass die Nachrichten-ID zusätzlich 8 Bytes hinzufügt, so dass man von einem Wert von 8 plus 4 Bytes für
die Anfrage und 8 plus 8 (bei einem hochpräzisen Dezimalwert) für die Antwort ausgehen kann. Bei Verwendung von
HTTP/SOAP kann man eine Ausgabe wie etwa folgende erwarten:
Anfrage
|
Antwort
|
SOAPAction: "http://www.webservicex.net/Quote"
User-Agent: MyAgent 1.0
Content-Type: text/xml; charset=UTF-8
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:tns="http://www.webservicex.net/">
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<tns:Quote>
<tns:Symbol>IBM</tns:Symbol>
</tns:Quote>
</soap:Body>
</soap:Envelope>
|
HTTP/1.1 200 OK
X-Powered-By: ASP.NET
Connection: close
Content-Length: 522
X-AspNet-Version: 1.1.4322
Date: Mon, 21 Mar 2005 00:34:21 GMT
Content-Type : text/xml; charset=utf-8
Server : Microsoft-IIS/6.0Cache-Control: private, max-age=0
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<QuoteResponse xmlns="http://www.webservicex.net/">
<Quote><Last>89.28</Last>
</Quote>
</QuoteResponse>
</soap:Body>
</soap:Envelope>
|
Die ersten Anwender der Web-Services-Technologie kamen zu zwei Schlussfolgerungen. Erstens, Services müssen für eine
kleine Anzahl von Operationen, die Daten in Form von Dokumenten bereitstellten, und nicht für die komplexere
Darstellung traditioneller Komponentenmodelle optimiert werden. Das hat den Vorteil, dass der Aufwand, der durch die
Protokolle entsteht, sich für einen größeren Umfang von Nutzdaten bezahlt macht. Zweitens müssen - zumindest zwischen
Services derselben Lösung - kleinere, einfachere Protokollbindungen ausgewählt werden. HTTP/SOAP wird für Situationen
reserviert, in denen es wirklich notwendig ist, z. B. bei Schnittstellen zu Bereichen außerhalb des Unternehmens.
Dieses Konzept ist nicht vollkommen neu. Auch im Bereich der Komponenten existieren Ansätze, den Umfang der
Kommunikation zwischen Client und Server zu reduzieren, z. B. das Muster "Value Object" oder die J2EE Service Facade.
Bei beiden Ansätzen wird eine vollständige Kopie des Komponentenzustands an den Client gesendet, anstatt die
traditionellen Zugriffsfunktionen zu nutzen. Darüber hinaus kann auch der Umstand berücksichtigt werden, dass Services
entwickelt werden, die stärker an Geschäftsmodellen, insbesondere Geschäftsprozessmodellen, ausgerichtet sind. Im
Grunde genommen geben Nachrichten allgemeine Geschäftsdokumente auf dieselbe Weise wieder wie EDI-Transaktionsgruppen
(Electronic Data Interchange) Geschäftsdokumente, z. B. Aufträge, Rechnungen, Lieferpapiere usw.
|
Leistung beim Nachrichtenaustausch verwalten
Im Allgemeinen ist es nützlich, große Nachrichten zu verwenden, um eine bestimmte Kommunikationsleistung
sicherzustellen, obwohl eine große Datennachricht manchmal ein Problem verursachen kann. Beispielsweise war in den oben
dargestellten SOAP-Nachrichten erkennbar, wie die Nachrichtengröße bei Verwendung von HTTP, SOAP und XML den
Datenumfang erheblich vergrößert hat. Das war ein Kritikpunkt bei frühen Systemen, die Web-Services-Technologien
nutzten. Andererseits wurden bei diesen Fehlern auch wertvolle Erfahrungen gemacht, z. B., dass es wichtig ist,
Leistung unter dem Aspekt der Codeleistung, des Nachrichtendesigns und der Protokollauswahl als frühe Designaktivität
zu bewerten.
Ein wichtiger Aspekt ist, dass, wenn große Zustandsabschnitte von Service zu Konsument bzw. von Service zu Service
verschoben werden, diese Nachrichten eigentlich veraltete Momentaufnahmen des Servicezustand darstellen. Eine
Überlegung ist also, diesen Mangel an Aktualität dadurch zu bewältigen, dass man den Zeitraum identifiziert, in dem die
Daten als zuverlässig gelten können, oder sie quasi an den Konsumenten vermietet, so dass sie nach einiger Zeit
verfallen. Weitere Informationen finden Sie im White Paper Serviceorientierte Architektur und komponentenbasierte Entwicklung zum Erstellen von
Web-Services-Anwendungen verwenden.
Ein anderes Thema, das berücksichtigt werden muss, ist das Caching von Inhalt. Das Caching ist normalerweise ein
Problem, das als Leistungsoptimierung für Anwendungen behandelt wird. In einer serviceorientierten Lösung gehen die
Struktur der Verteilung und die nachrichtenbasierte Kommunikation gut mit der Einführung von Caches zwischen
Konsumenten und Services einher. Diese Caches sind nicht die typischen Datenbank-Caches, die für die Optimierung der
Abfragen verwendet werden, sondern eher Caches, die in Webservern und Proxys Verwendung finden. Tatsächlich können
diese Proxys bei Web-Services, die HTTP und SOAP einsetzen, als Caches verwendet werden, um in bestimmten Situationen
Serviceantworten bereitzustellen.
Die eigentlichen Problemstellungen hinsichtlich der Cache-Verwendung bestehen jedoch darin, zu bestimmen, wie der Cache
die Richtlinien für die Bereitstellung von Inhalt aus dem Cache interpretiert und wie ein Service den Cache
invalidieren kann. Die technische Infrastruktur zum Betreiben und Verwalten implementierter Services sollte
Caching-Funktionen bereitstellen. Ein Bereich der Servicerichtlinie, die zukünftig erwartet wird, ist die
Bereitstellung von Informationen für die Cache-Verwaltung.
|
|
Weitere Informationen
© Copyright IBM Corp. 1987, 2006. Alle Rechte vorbehalten.
|
|