Basiskonzepte von Consumer-Mappings
Beim Arbeiten mit Consumer-Mappings müssen Sie die Eigenschaften des Consumer-Proxy berücksichtigen. Je nach Operationstyp muss das Mapping nur für einen Request oder für ein Request-/Response-Pattern erfolgen und läuft dann entweder im gekoppelten oder entkoppelten Modus.
Mappings für asynchrone und synchrone Operationen
Für jede einzelne Operation des Quell-Consumer-Proxy wird ein Operation-Mapping benötigt. Es gibt zwei allgemeine Arten von Operationen, asynchrone und synchrone.
Bei asynchronen Operationen werden Einwege-Messages generiert. Daher muss bei jeder Operation des Quell-Consumers nur ein Mapping der Request-Message auf ein oder mehrere Request-Messages des Ziel- bzw. der Ziel-Consumer erfolgen. Erfolgt durch asynchrones Mapping eine Abbildung auf mehrere Ziel-Consumer, kommt es zu einem Message-Splitt.
Eine synchrone Operation bezieht sich auf einen Request, eine Response und in einigen Fällen auf eine oder mehrere Fault-Messages. Daher müssen Sie ein Mapping sowohl für Request- als auch für Response-Messages definieren. Wenn Fault-Messages verwendet werden, müssen Sie auch Mappings für die Fault-Operationen definieren. Die Operationen des Ziel-Consumers müssen ebenfalls synchron sein.
Mappings für gekoppelte und entkoppelte Consumer
Ein Consumer-Proxy mit asynchronen Operationen kann so definiert werden, dass es entweder innerhalb des Anwendungsprogrammkontextes (im gekoppelten Modus) oder später in einem separaten Kontext (im entkoppelten Modus, mit asynchroner Grenze) läuft. Das Consumer-Mapping erbt diese Eigenschaft implizit vom Consumer-Proxy. Dies hat folgende Auswirkungen:
Gekoppeltes Mapping
Das gekoppelte Mapping erfolgt im Anwendungsprogrammkontext ohne dazwischen geschaltete asynchrone Grenze. Dadurch wird es möglich, auf die Anwendungsdaten in der Mapping-Implementierung zuzugreifen und sie für die Assembly der Request-Message des Ziel-Consumers zu verwenden, ohne dass die Daten mit Hilfe der Request-Messages des Quell-Consumers an die Mapping-Implementierung übergeben werden müssen. Nötig ist eventuell nur die Übergabe bestimmter IDs oder Handles, damit eine Referenz auf die entsprechenden Daten oder Business-Objekte im Anwendungskontext verfügbar ist. Auch die Fehlerbehandlung erfolgt innerhalb der Anwendung.
Entkoppeltes Mapping
Das entkoppelte Mapping erfolgt in einem eigenen Kontext zu einem späteren Zeitpunkt, mit einer asynchronen Grenze zwischen dem Aufruf des Consumer-Proxy und dem Mapping. Dies bedeutet, dass die Mapping-Implementierung nicht auf die Anwendungsdaten zugreifen kann. Alle erforderlichen Daten für die Assembly der Ziel-Consumer-Request-Message müssen daher mit Hilfe der Request-Message des Quell-Consumers an die Mapping-Implementierung übergeben werden, sofern sie nicht aus anderen globalen Quellen (z.B. einer Datenbank oder einem Shared Memory) abgerufen werden können. Das entkoppelte Mapping ist daher in Bezug auf künftige Erweiterungen des Service-Interface weniger flexibel. Fehler werden ebenfalls separat im Message-Monitor behandelt.
Diese Eigenschaft wirkt sich auf das Design des Consumer-Proxy aus, da z.B. eine Request-Message entweder alle Anwendungsdaten oder nur ein einzelnes Objekt wie eine ID enthält. Im gekoppelten Modus kann der Request-Message-Typ des Quell-Consumers generisch sein, d.h. maximale Flexibilität in Bezug auf Mappings für künftige Erweiterungen des Service-Interface bieten. Im entkoppelten Modus müssen alle Daten, die für den Web-Service-Provider erforderlich sind, an die Mapping-Implementierung übergeben werden.