WSIF - Ziele

WSIF zielt darauf ab, die Flexibilität der SOAP-Services dahingehend zu erweitern, dass ein allgemeines Modell für den Aufruf von Web-Services entsteht, unabhängig von den zugrunde liegenden Bindungs- oder Zugriffsprotokollen.

SOAP-Bindungen für Web-Services sind Teil der WSDL-Spezifikation. Deshalb denken die meisten Entwickler, wenn sie sich Gedanken über die Verwendung eines Web-Service machen, sofort an die Assemblierung einer SOAP-Nachricht, die dann über eine SOAP-Client-API an den Serviceendpunkt im Netz gesendet wird. Beispiel: Bei der Verwendung von Apache SOAP erstellt und füllt der Client ein Call-Objekt, das den Serviceendpunkt, die Identifikation der aufzurufenden SOAP-Operationen, die zu sendenden Parameter usw. kapselt.

Die Ziele des Web Services Invocation Framework (WSIF) sind deshalb:

Web-Services sind mehr als nur SOAP-Services

Jede Anwendung, die eine WSDL-basierte Beschreibung ihrer funktionalen Aspekte und Zugriffsprotokolle besitzt, kann als Web-Service implementiert werden. Wenn Sie die Java EE-Umgebung verwenden, ist die Anwendung für mehrere Transporte und Protokolle verfügbar.

Beispielsweise können Sie eine in der Datenbank gespeicherte Prozedur als Stateless-Session-Bean bereitstellen und anschließend als SOAP-Service in einem SOAP-Router implementieren. Der eigentliche Service ist in jeder Phase derselbe. Es ändert sich lediglich der Zugriffsmechanismus: von Java DataBase Connectivity (JDBC) in Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) und dann in SOAP.

Die WSDL-Spezifikation definiert eine SOAP-Bindung für Web-Services, aber Sie können der WSDL Bindungserweiterungen hinzufügen. Beispielsweise können Sie mit RMI-IIOP als Zugriffsprotokoll eine Enterprise-Bean als Web-Service anbieten. Selbst einzelne Java-Klassen können als Web-Service verwendet werden. Hierbei werden threadinterne Aufrufe von Java-Methoden als Zugriffsprotokoll verwendet. Bei dieser allgemeineren Definition eines Web-Service benötigen Sie für den Serviceaufruf ein bindungsunabhängiges Verfahren.

Einschränkungen für die Verwendung von Clientcode in einer bestimmten Protokollimplementierung

Wenn Ihr Clientcode fest an eine Clientbibliothek für eine spezielle Protokollimplementierung gebunden ist, ist er möglicherweise schwierig zu pflegen.

Wenn Sie beispielsweise von Apache SOAP zu Java Message Service (JMS) oder Enterprise-Beans wechseln, kann dies sehr viel Zeit und Mühe kosten. Um diese Probleme zu vermeiden, benötigen Sie ein Verfahren für den Serviceaufruf, das unabhängig von der Protokollimplementierung ist.

Schwierigkeiten bei der Integration neuer Bindungen in Clientcode

Wenn Sie eine Anwendung, die ein angepasstes Protokoll verwendet, so erstellen möchten, dass sie wie ein Web-Service arbeitet, können Sie Elemente für Erweiterbarkeit zu WSDL hinzufügen, um die neuen Bindungen zu definieren. Die Anwendung dieser Funktionalität ist jedoch komplex.

Beispielsweise müssen Sie die Client-APIs so entwerfen, dass sie dieses Protokoll verwenden. Wenn Ihre Anwendung nur die abstrakte Schnittstelle des Web-Service verwendet, müssen Sie Tools schreiben, um die Stubs zu generieren, die eine Abstraktionsebene unterstützen. Diese Tasks können enorm viel Zeit und Mühe kosten. Was Sie benötigen, ist ein Mechanismus für Serviceaufruf, der es Ihnen ermöglicht, vorhandene Bindungen zu aktualisieren und neue Bindungen hinzuzufügen.

Flexible Verwendung mehrerer Bindungen

Um die Vorteile von Web-Services mit mehreren Bindungen nutzen zu können, benötigen Sie einen Mechanismus für den Serviceaufruf, der einen Wechsel der verfügbaren Servicebindungen zur Laufzeit unterstützt, ohne dass ein Stub generiert oder erneut kompiliert werden muss.

Stellen Sie sich vor, Sie haben eine Anwendung implementiert, die einen Web-Service mit mehreren Bindungen verwendet. Sie haben beispielsweise eine SOAP-Bindung für den Service und eine lokale Java-Bindung, die es Ihnen ermöglicht, die lokale Serviceimplementierung (eine Java-Klasse) als Web-Service zu behandeln.

Die lokale Java-Bindung für den Service kann nur verwendet werden, wenn der Client in derselben Umgebung wie der Service implementiert ist. In diesem Fall ist es effizienter, über direkte Java-Aufrufe mit dem Service zu kommunizieren, anstatt die SOAP-Bindung zu verwenden.

Wären Ihre Clients in der Lage, basierend auf der Laufzeitinformation die Bindung wechseln zu können, hätten sie die Möglichkeit, in jeder Situation die effizienteste verfügbare Bindung zu wählen.

Unterstützung von Zwischenstationen in der flexibleren Web-Service-Umgebung

Web-Services bieten Anwendungsintegratoren ein lose verbundenes Paradigma. In solchen Umgebungen können Zwischenstationen sehr wirkungsvoll sein.

Zwischenstationen sind Anwendungen, die die Nachrichten abfangen, die zwischen einem Serviceanforderer und einem Ziel-Web-Service übertragen werden, und führen einige Vermittlertasks (z. B. Protokollierung, hohe Verfügbarkeit oder Umsetzung) aus, bevor sie die Nachricht übergeben. Das Web Services Invocation Framework (WSIF) unterstützt und gestaltet das Erstellen von Zwischenstationen einfach. Mit WSIF sind Zwischenstationen in der Lage, einem Serviceaufruf Werte hinzuzufügen, ohne dass eine transportspezifische Programmierung erforderlich ist.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwsf_goals
Dateiname:cwsf_goals.html