Web-Services anbieten und beziehen

Feature | 2. November 2004 von Anne Lanfermann 0

Web-Services wird eine große Zukunft voraus gesagt. Sie gelten als die Bausteine moderner Software-Architekturen. Jeder Web-Service enthält ein Stück Funktionalität und bildet eine in sich geschlossene Softwarekomponente. Diese dient beispielsweise dazu, eine Preisanfrage an einen Anbieter zu richten, die Verfügbarkeit eines Artikels in einem Warenwirtschaftsystem zu prüfen, eine Telefonnummer aufzufinden oder eine Nachbestellung aufzugeben. Ein Web-Service lässt sich über eine Schnittstelle aufrufen. Auf diese Weise können Softwarekomponenten, die auf einem beliebigen Web Server liegen, durch andere Programme genutzt werden. Web-Services sind immer wieder zu verwenden und mit anderen Softwarelösungen zu kombinieren. Sie versetzen etwa industrielle Hersteller in die Lage, Kunden, Partnern und Lieferanten Web-Services zur Implementierung in deren Programmen zur Verfügung zu stellen, um übergreifende Supply-Chain-Lösungen einzurichten.

Wege zum Web-Service

SAP stellt eine einheitliche Architektur und Werkzeuge bereit, um Web-Services zu erstellen, weiter zu verwenden und anzupassen. Dazu zählen die SAP-Entwicklungsumgebungen SAP NetWeaver Developer Studio und die ABAP-Entwicklungsumgebung, die auf die Programmiersprachen Java und ABAP ausgerichtet sind. SAP-Anwender sind somit in der Lage, ohne großen Aufwand Web-Services herzustellen. Bereits existierende RFCs, IDOCs, BAPIs, XI Server Proxies, EJBs und Java-Klassen können zum Einrichten von Web-Services verwendet werden.

Wizard

Wizard

Zwei Verfahren dienen dazu, Web-Services anzufertigen: In wenigen Mausklicks mit dem Web Service Creation Wizard oder mit Hilfe einer schrittweisen Vorgehensweise. Wizards enthalten vordefinierte Profile, mit vorgefertigten Einstellungen zur Sicherheit von Web-Services oder zum verwendeten Transportprotokoll. In der zweiten Vorgehensweise wird ein Web-Service schrittweise von Grund auf konfiguriert. Sie ist im Vergleich zum Wizard aufwändiger, ermöglicht es aber, individuelle Anforderungen umzusetzen.

Marktplätze und Registraturen

SAP unterstützt die Standardisierungsbemühungen des W3C (World Wide Web Consortium). Das W3C ist für die Kerntechnologien innerhalb des Web-Service-Rahmenwerkes zuständig, insbesondere für den Datenaustausch und die Beschreibung der Services. Mit der Web Service Description Language (WSDL) lassen sich Web-Services im XML-Datenformat definieren. WSDL-Dokumente bestehen im Einzelnen aus den Namen der Dienste, Nachrichten, die zu deren Verwendung ausgetauscht werden, Bindungen an bestimmte Transportprotokolle und Adressen, an denen ein Web-Service zur Verfügung steht. Anwender können Web-Services anlegen und gebrauchen, ohne jemals ein WSDL-Dokument angeschaut zu haben. Dennoch ist es ratsam, ein WSDL-Dokument lesen zu können, um zum Beispiel bei einer Fehlersuche nachzusehen, welche Daten zwischen Client und Server übertragen wurden.
Im Web Service Framework kann für jeden frei geschalteten (deployten) Web-Service eine Web Service Homepage aufgerufen werden. Mit der Web Service Homepage lassen sich Web-Services testen, die WSDL-Dokumente des Web-Service können angeschaut (siehe nebenstehendes Bild) und Proxies generiert werden.

WSDL-Styling

WSDL-Styling

Bei der Verwendung von Web-Services ist der Service Provider von einem Service Requestor zu unterschieden. Im einfachen Fall ist davon auszugehen, dass der Service Provider, also derjenige, der Services zur Verfügung stellt, den Service Requestor kennt und diesem mitteilt, wo Services gefunden werden können. Dies widerspricht allerdings der Idee von Web-Services als einer globalen Dienstplattform. Das, was die Verwendung von Web-Services attraktiv macht, ist gerade die Vorstellung, dass Anwendungen aus weltweit verfügbaren Web-Services zusammengebaut werden können. Um Anbietern und Abnehmern möglichst diese umfassenden und globalen Marktplätze für Web-Services zu bieten, gibt es zentrale Verzeichnisdienste. Diese wurden durch die Entwicklung des UDDI-Standards (Universal Description Discovery and Integration) möglich, der vom Standardisierungsgremium OASIS verabschiedet wurde. UDDI ist ein grundlegender Bestandteil des Web Service Frameworks. Viele Firmen bieten öffentliche UDDI Server an. Beispiele hierfür sind: SAP (http://uddi.sap.com/), Microsoft (http://uddi.microsoft.com/) oder IBM (http://uddi.ibm.com/).
UDDI schafft Registraturen, die mit den Gelben Seiten vergleichbar sind. UDDI-Registraturen enthalten Beschreibungen der Services in Form von WSDL-Dokumenten ergänzt um strukturierte Angaben über Anbieter (mit Kontaktinformationen) sowie Branchen und Geschäftskategorien, für die sich die Web-Services im Einzelnen eignen. Web-Services, die im SAP NetWeaver Developer Studio oder in der ABAP Workbench angelegt werden, lassen sich in allen Registern publizieren, die dem UDDI-Standard entsprechen.

UDDI

UDDI

SAP bietet neben der öffentlich zugänglichen UDDI-Business-Registry auch die Möglichkeit, lokale UDDI-Server zum Beispiel in Unternehmen aufzubauen. Letztere sind darauf ausgerichtet, Services nur bestimmten Gruppen autorisierter Benutzer verfügbar zu machen.

Client-Proxies implementieren Web-Services

Voraussetzung für die Implementierung von Web-Services in Anwendungen ist die Generierung eines Client-Proxies. Client-Proxies werden mit Hilfe des WSDL-Dokuments eines Web-Service generiert. Jede standardkonforme WSDL-Beschreibung kann als Eingabe für die Proxygenerierung verwendet werden. WSDL-Dokumente werden entweder im UDDI, mit Hilfe einer URL/HTTP-Destination oder in einer lokalen Datei gefunden.
Über einen weiteren Standard, die Web Service Inspection Language (WSIL), wird angestrebt, Web-Services ohne den Weg über zentrale UDDI-Register direkt auf beliebigen Web-Servern verfügbar zu machen. Damit entfällt die teils aufwändige Verwaltung und Pflege der UDDI-Verzeichnisse. Durch WSIL beschriebene Web-Services werden im Web Service Navigator des SAP NetWeaver Developer Studio angezeigt. Mit Hilfe des Navigators kann der Anwendungsentwickler die Homepage eines Web-Service anzeigen und einen Client-Proxy generieren.
Ein Client-Proxy fungiert als ein Vermittlungsprogramm. Über einen Client Proxy wird eine Verbindung zum Server eines gewünschten Web-Service aufgebaut. Der Entwickler kann sich ganz der Geschäftsanwendung widmen, während der technische Teil, zum Beispiel das automatische Verpacken von Aufrufen zu einer SOAP-Nachricht oder die Auswertung eintreffender Antworten, mit Hilfe des Proxies erledigt wird.

Logische Ports vermeiden Fehler

ABAP Editor

ABAP Editor

Bei der Proxy-Generierung werden alle zum Aufruf eines Web-Service benötigten Objekte angelegt. Dazu gehören auch die so genannten Logischen Ports. Hierbei handelt es sich um ein SAP-spezifisches Konzept zur Konfiguration der Runtime Features für Web-Service-Client-Proxies. Runtime Features sind Eigenschaften, die in der Laufzeitumgebung (Runtime) zum Aktivierungszeitpunkt des Web-Service-Clients konfiguriert werden müssen. Die WSDL-Beschreibung eines Web-Service definiert auch einen Logischen Port. Beispielsweise enthält er die URL-Adresse, wo der Service aufgerufen werden soll. In der Regel wird diese URL direkt in das Proxy-Objekt generiert.
Dazu ein Beispiel: Es treten leicht Probleme auf, wenn der Proxy in einer Systemlandschaft – zum Beispiel vom Testsystem zum Produktivsystem – verschoben wird. Der Proxy würde weiterhin versuchen, den Web-Service auf dem Testserver aufzurufen, obwohl er jetzt das Produktivsystem anwählen sollte. Um das zu vermeiden, müsste er wieder neu generiert oder das Coding manuell angepasst werden. Da diese individuellen Nachbesserungen sehr fehleranfällig sind, werden im SAP Web Service Framework die Konfigurationsdaten von der Implementierung getrennt. Nach dem Transport oder dem Redeployment des Proxies lassen sich über einen einfachen Editor die URL und andere wichtige Parameter anpassen.
Der Aufruf von Java-Proxies kann in standardisierter Weise etwa durch Enterprise Java Beans, Java-Klassen, Java Server Pages oder dem Web Dynpro Model für Web-Services erfolgen. Mit wenigen Zeilen Code ist somit das Einbinden von Web-Services möglich. ABAP-Proxies können einfach per Drag&Drop in den Editor des Programms gezogen werden, in dem sie aufgerufen werden sollen. Dabei wird das benötigte Coding automatisch erzeugt und kann vom Anwendungsprogrammierer direkt verwendet werden.

Potenzial mit ESA

Der Einsatz der Web-Service-Technologie wird sich auf das Design neu anzulegender Anwendungen auswirken. SAP hat deshalb die Enterprise Services Architecture (ESA) entwickelt. Die Enterprise Services Architecture vereinigt SAP-Lösungen mit der offenen Integrations- und Anwendungsplattform SAP NetWeaver, um flexible Geschäftsprozesse durch SAP, durch Partner oder Kunden zu gestalten.
Die Sicherheit im Umgang mit Web-Services bleibt ein vorrangiges Thema. Derzeit wird die Transportsicherheit von Web-Services mit dem Secure Socket Layer Protocol (SSL) gewährleistet. Der Dokumentensicherheit dient der Standard WS-Security. Es ist davon auszugehen, dass weiterhin neue Standards entwickelt werden, die die Sicherheit weiter verbessern und Unternehmen in die Lage versetzen, durch Web-Services Geschäftsprozesse noch schneller und flexibler abzubilden und aufeinander abzustimmen. SAP ist aktiv in Gremien zur Standardisierung der Web-Service-Technologie vertreten. Einerseits, um Erfahrungen der SAP im Unternehmensumfeld einzubringen, andererseits, weil diese zukunftsweisende Technologie weiterhin eine wichtige Rolle in der Softwareentwicklung spielen wird.

Anne Lanfermann

Anne Lanfermann

Tags:

Leave a Reply