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.
- Web-Services sind mehr als nur SOAP-Services.
- Einschränkungen für die Verwendung von Clientcode in einer bestimmten Protokollimplementierung.
- Schwierigkeiten bei der Integration neuer Bindungen in Clientcode.
- Flexible Verwendung mehrerer Bindungen.
- Unterstützung von Zwischenstationen in der flexibleren Web-Service-Umgebung.
Die Ziele des Web Services Invocation Framework (WSIF) sind deshalb:
- Bereitstellen eines bindungsunabhängigen Mechanismus für den Aufruf von Web-Services
- Befreien des Clientcodes von der Komplexität eines jeden Protokolls, das für den Zugriff auf einen Web-Service verwendet wird.
- Dynamische Wahl zwischen mehreren Bindungen für einen Web-Service.
- Hilfe bei der Entwicklung von Zwischenstationen für Web-Services.
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.