Point-to-Point-Kommunikation über Web Services 
Sie können für die Entwicklung einer Point-to-Point-Kommunikation über Web Services entweder den Inside-Out- oder den Outside-In-Ansatz verfolgen (weitere Informationen: Einführung in die Service-Entwicklung). Beide Ansätze arbeiten mit dem WSDL-Standard (WSDL: Web Service Description Language), um dem Consumer eines Service alle notwendigen Informationen für den Aufruf des Service zu übermitteln.
Die Entwicklung einer Point-to-Point-Kommunikation über klassische Web Services verfolgt den Inside-Out-Ansatz: Zu einer existierenden Funktion in einem Anwendungssystem wird ein WSDL-Dokument generiert, in dem alle notwendigen Informationen für den Aufruf der Funktion enthalten sind. Consumer können sich mit Hilfe dieses WSDL-Dokuments auf ihrer Plattform einen Laufzeit-Stellvertreter (ein Proxy) generieren, über das die Anwendung des Consumers den Service des Providers aufrufen kann.
Outside-In-Entwicklung
Bei der Outside-In-Entwicklung arbeiten Sie mit Services-Interfaces (Outbound und Inbound), die Sie direkt im ES Repository anlegen. Service-Interfaces sind sprachenunabhängig und basieren auf dem WSDL-Standard. Ausgehend von dieser Beschriebung können Sie sprachenspezifische Proxies in Java oder ABAP generieren, mit deren Hilfe Sie den tatsächlichen Message-Austausch implementieren. Die generierten Proxies sind Teil der Anwendung und leiten Aufrufe an die Web-Service-Laufzeit weiter, die den Message-Austausch Point-to-Point durchführt.
Hinweis
Die Proxies können ebenso für eine erweiterte Kommunikation über den Integration Server eingesetzt werden. Allerdings werden bei der erweiterten Kommunikation nicht alle Protokollvarianten unterstützt, die bei einer Point-to-Point-Kommunikation unterstützt werden und umgekehrt.
Trennung von Design, Implementierung und Konfiguration
Im Vergleich zur Inside-Out-Entwicklung von Web Services existiert zu Beginn der Entwicklung also noch kein implementierter Service beim Provider. Statt dessen wird zunächst sowohl die Beschreibung für den Consumer (Outbound-Service-Interface), als auch die Beschreibung für den Provider (Inbound-Service-Interface) im ES Repository in WSDL spezifiziert (Design-Zeit). Zum Inbound-Service-Interface generieren Sie dann ein Provider-Proxy in das Provider-System, um dort den eigentlichen Service zu implementieren (Implementierungszeit).
Da Sie im ES Repository den Service unabhängig von einem Provider-System beschreiben, können Sie am Inbound-Service-Interface noch keine Informationen darüber hinterlegen, wie der Service beim Provider adressiert werden soll. Dies geschieht erst zur Konfigurations-Zeit.
Beispiel
Die folgende Grafik gibt ein Beispiel für die Outside-In-Entwicklung (ohne Darstellung der Konfiguration). Ausgangspunkt ist ein Outbound-Service-Interface und ein zugehöriges Inbound-Service-Interface im ES Repository. Um diese Schnittstellen zur Laufzeit einzusetzen, generiert die Anwendung zugehörige Proxies für das jeweilige Entwicklungssystem.
Bezüglich der verschiedenen Entwicklungsphasen ist die Generierung von Proxies der Übergang von der Design-Zeit zur Implementation. Im Bild ist skizziert, eine ABAP-Anwendung mit Hilfe des Consumer-Proxy eine Message über die Web-Service-Laufzeit and den Provider schickt. Dies funktioniert nur, wenn Sie die Informationen des WSDL aus dem Enterprise Services Repository zur Konfigurations-Zeit um Adressinformationen zum Provider ergänzt haben.
Das Bild zeigt nur eine Richtung der Kommunikation wie es zum Beispiel bei asynchroner Kommunikation der Fall ist. Die Service-Interfaces im ES Repository haben entsprechende Attribute, die Ihre Verwendung (beispielsweise synchron oder asynchron) kennzeichnen.