So funktionieren Web Services 
Die zentralen Konzepte
Der SAP NW Application Server unterstützt das Anbieten und das Konsumieren von Web Services gleichermaßen. Er tut dies auf der Grundlage der Standards für Web Services: XML, SOAP, die Web Service-Definition Language (WSDL) und Universal Description, Discovery, and Integration (UDDI).
SOAP ist ein allgemeines Format für XML-Nachrichten, unter dem unterschiedliche Transportprotokolle liegen können. Mit WSDL beschreiben Sie die konkrete Schnittstelle Ihres Web Services, die aus Methodennamen sowie den Ein- und Ausgabenachrichten besteht. Zur Laufzeit werden die Nachrichten mit SOAP verpackt und in dieser Form übertragen.
UDDI ist eine Art Adressdienst für Web Services. Sie finden dort die grundlegenden Daten publiziert, die Sie benötigen, um einen Web Service aufzurufen. Als Web Service Anbieter können Sie Ihre Services dort publizieren.
Funktionalität als Web Service anbieten und konsumieren
Wenn Sie eine bestimmte in ABAP geschriebene Funktionalität als Web Service anbieten möchten, können Sie diese über einen Web Service verschalen. Dies ist der so genannte Inside-Out-Ansatz, bei dem Sie mit Hilfe von Tools und Wizards eine bestehende Standard-Schnittstelle (z.B. einen Funktionsbaustein) als Web Service zugänglich machen können.
Wenn Sie von einem ABAP-Programm aus einen Web Service aufrufen möchten, so können Sie sich ebenfalls mit Toolunterstützung auf der Basis der WSDL-Beschreibung des betreffenden Web Services eine Proxy-Klasse erzeugen lassen. Dabei ist es unerheblich, wie der Web Service auf der Server-Seite implementiert wurde. Der Client Proxy kümmert sich um die technischen Abläufe - wie das Erzeugen einer SOAP Nachricht, die Transportschicht oder um Security Einstellungen. Er kapselt also die Kommunikation. Der Entwickler der Client-Applikation kann sich somit auf die Erstellung betriebswirtschaftlicher Funktionen konzentrieren.
Dabei können Sie ein- und dieselbe Funktion in unterschiedlichen Web Services zur Verfügung stellen: Web Services bieten über das Konzept der Virtual Interfaces eine Abstraktion von der Implementierung an. Das bedeutet, Sie können beispielsweise für einen Web Service bestimmte Eingabeparameter einer Funktion mit Default-Werten füllen und in einem anderen Web Service dieselbe Funktion mit all Ihren Parametern zur Verfügung stellen. Beispielsweise möchte der End-Kunde des Web-Shops eines Textilherstellers nicht mit internen Buchungsdetails seiner Bestellung belastet werden. Die Lösung per Web Service besteht in einem solchen Fall darin, bestimmte Parameter, wie beispielsweise den Buchungskreis, bereits auf der Web Service Anbieter-Seite mit Defaultwerten zu füllen und dem Web Service Client nur die Parameter anzubieten, die er tatsächlich sinnvoll angeben kann. Ein Warenhaus möchte dagegen seiner Bestellung beim selben Hersteller eine breitere Palette an betriebswirtschaftlichen Buchungsdaten mitgeben. Für sie ist der Web Service mit allen Eingabewerten der dahinter liegenden Funktion gedacht.