Show TOC

Background documentationPoint-to-Point Communication Using Web Services Locate this document in the navigation structure

 

You can either use the inside-out or outside-in approach to develop a point-to-point communication using Web Services (more information: Introduction to Service Development). Introduction to Service Development). Both approaches work with them WSDL standard (WSDL: Web Service Description Language) to transfer all the necessary information for calling the service to the service consumer).

The development of a point-to-point communication using classic Web Services is performed using the inside-out approach: a WSDL document, in which all the necessary information for calling the function is contained, it is generated for a pre-existing function in an application system. Using this WSDL document, consumers can generate a runtime substitute (a proxy) on their platform and in this way the consumer application can call the provider's service.

Outside-In Development

In outside-in development, you work with service interfaces (outbound and inbound), which you create directly in the ES Repository. Service interfaces are language-independent and are based on the WSDL standard. Using this description, you can generate language-specific proxies in Java or ABAP, which you can then use to implement the actual message exchange. The generated proxies are part of the application and forward calls to the Web Service runtime that executes the point-to-point message exchange.

Note Note

The proxies can also be used for an enhanced communication using the Integration Server. However, the enhanced communication does not support all the protocol variants that are supported in point-to-point communication, and the other way round.

End of the note.
Separation of Design, Implementation and Configuration

In comparison to the inside-out development of Web Services, at the beginning of development there is no service implemented at the provider. Instead, firstly the the description for the consumer (outbound service interface) as well as the description for the provider (inbound service interface) are specified in WSDL in the ES Repository (design time). You then generate a provider proxy in the provider system for the inbound service interface to implement the actual service there (implementation time).

Since you can describe the service in the ES Repository independently from a provider system, you cannot store any information about how the service is to be addressed by the provider in the inbound service interface. This happens at configuration time.

Example

The following graphic shows an example of outside-in development (without showing the configuration). You start with an outbound service interface and a corresponding inbound service interface in the ES Repository. To use these interfaces at runtime, the application generates corresponding proxies for each development system.

This graphic is explained in the accompanying text.

As regards the various development phases, proxy generation is the transition from design time to implementation. The graphic shows how an ABAP application sends a message using the Web Service runtime to the provider using the consumer proxy. This only works if you have modified the WSDL information from the Enterprise Services Repository at configuration time with address information about the provider.

The graphic only shows one direction of communication, which is the case with synchronous communication, for example. The service interfaces in the ES Repository have corresponding attributes that indicate how they are used (for example, whether they are synchronous or asynchronous interfaces).