Describing Web Services

Objectives

After completing this lesson, you will be able to:
  • Explain the Web service paradigm
  • List the steps to create a Web service using the inside-out approach and synchronous communication

Web Services

A Web service is an independent, modular, and self-describing application function or service. Based on XML standards, these application functions can be described, made available, located, transformed, or called using standard Internet protocols.

Each Web service therefore encapsulates a function, which is used, for example, to forward a price query to a provider, check the availability of an item in a retail system, locate a telephone number, or run credit card checks, convert currencies, or execute payroll functions.

Web Service Paradigm

A service provider provides access to a service. If a service is a Web service, the service provider has a corresponding XML-based description that is a Web Services Description Language (WSDL) document. Any programming language can be used to implement the Web service. In a client/server relationship, the service provider can be regarded as the server.

When publishing a service, the service provider transmits information about itself and a description of the service it offers to the Service Registry. A Service Registry is a type of yellow pages for Web services. It provides, among other things, information about calling the Web service. The Service Registry therefore provides only a description of the Web service. This description forms an abstraction layer, independent of the corresponding implementation. The Web service itself is hosted by the service provider.

A Web service user is referred to as a service requester. A service requester can, for example, be someone who locates a Web service using a Web browser and then uses the service. In most cases, however, the service requester is an application that accesses the Web service. The application can also bind to the service dynamically if required, that is, the application can dynamically create a Web service client proxy at runtime and use this proxy to access the Web service. The application obtains the necessary information for accessing the Web service from the service description.

This information is then stored in the Service Registry. However, if the application knows the provider and the call details, it can use the Web service without having to access the Service Registry. In a client/server relationship, the service requester is the application client.

Standards for Web Service

Web services can exist in any implementation. Therefore, a standardized description is required if Web services are to be called from any application. The WSDL best meets this demand. However, a Web services description in WSDL alone is not sufficient. To find the right business partner and corresponding service quotation, you need a company registry to help you to find the required service.

The Web service provider must also be able to make its offer publicly available as easily as possible. The Universal Description, Discovery and Integration (UDDI) offers a solution. For more information, see http://uddi.xml.org.

The following list explains some standards that are used with Web services:

  • UDDI (Universal Description, Discovery and Integration) Registry: With its UDDI Registry and UDDI specification, UDDI provides the necessary tools for making services public. The specification provides a detailed description of how to locate and register services. The UDDI Registry contains a list of registered Web services in WSDL format. The UDDI Registry does not store documents or specifications, but only references them.

  • SOAP (originally Simple Object Access Protocol): To call Web services based on Internet technologies, a suitable protocol definition is needed. SOAP has created a simple standard that allows Web services to be accessed in decentralized, distributed landscapes. SOAP specifies a package of XML documents for transport via Internet protocols such HTTP(S), SMTP, or FTP. SOAP defines a so-called envelope. In this envelope, you will find the actual XML-based message with a header and a body, as well as further information about how the message should be processed.

  • WSDL (Web Service Description Language): WSDL is an XML-based description language for Web services. The WSDL Service definition includes the description of distributed systems and provides instructions for automating data exchange between applications. The Web Service Description Language is used to describe Web services or electronic services in XML format. A service is defined as a collection of endpoints (ports) and the messages they work with. By using WSDL, a service provider can describe the requirements and features of their Web service so that a potential customer understands them and interacts properly with the service.

Creation of a Web Service Using the Inside-Out Approach and Synchronous Communication

There are two different development approaches for developing ABAP Web Services: Inside-Out and Outside-In.

  • With the Inside-Out approach, independent function modules that have been implemented as RFC-enabled function modules, as function groups, or as BAPIs are provided as a Web service. The Web service can be used across the entire Internet using standard protocols and can easily be added to any development environment.

  • In the Outside-In approach, development of Service Interfaces starts in a platform-independent format, mostly XML. With the Enterprise Services Builder (part of the Object Navigator, transaction SE80), SAP offers a tool that supports the platform-independent development of Service Interfaces. Connected application systems can read these interfaces. Using the ABAP proxy technology, a developer can create an ABAP object that consists of one or more ABAP methods. Since development begins outside the application system, this approach is called Outside-In.

This lesson focuses on the Inside-Out approach.

Creation of a Web Service

Tools

For developing Web services at SAP, some tools are needed:

  • For the implementation of the functions on the provider side and the call of these functions on the consumer side, you need the ABAP Workbench for the development.

  • For the configuration of the Web service on the provider side and on the consumer side, SAP offers transaction SOAMANAGER.

  • For testing Web services, SAP offers the Web Service Navigator (WSNavigator), which is a Web service client, implemented in Java.

For developing Web services, SAP offers the transaction SOAMANAGER in the AS ABAP based back-end system, which allows you to configure Web services based on the proxy technology. You can use SOAMANAGER for the complete configuration of service provider and consumer proxies for a local system.

Screenshot of the initial screen of the SOAMANAGER tool in SAP.

The Service Administration tab (see figure "SOAMANAGER – Initial Screen") offers functionality to set up configuration to support business processes with Web services. This functionality is intended for business administrators who manage business processes across systems in a system landscape.

Additional Information

For more information on ABAP Web services, see the online documentation for SAP S/4HANA (Product Assistance), for example: area Enterprise TechnologyABAP PlatformDeveloping on the ABAP PlatformDevelopment Concepts and ToolsApplication Development on AS ABAPABAP Development Tools – EclipseSAP (On Premise) – ABAP Web Services.