Introducing ABAP Web Services

Business processes are divided into a certain number of process steps. You can assign one or more functions to each of these steps and an executing software component to each of these functions. If you look at a typical heterogeneous system landscape in an organization, it is quickly apparent that the necessary functions in a business process are not all implemented using the same technology and the same components. In particular, the integration of an ever increasing number of business partners further complicates this problem. A modern software infrastructure must therefore be capable of integrating functions that are implemented on very different software components into an efficient global process.

Internet technology already provides the basis for communicating with distributed services. Superimposed onto this simple, globally accepted communication standard, XML (eXtensible Markup Language) provides the basis for defining additional necessary standards. Only when we move away from proprietary definitions and toward generally accepted standards can there can be any guarantee of smoothly integrating all the functions and partners involved in the process. The result is web services.

A web service is an independent, modular, self-describing application function or service. Based on XML standards, this application function can be described, made available, located or called using standard internet protocols. Each web service therefore encapsulates a piece of functionality that can be used, for example, to forward a price query to a provider, check the availability of an item in an enterprise resource planning system, locate a telephone number, or even to run credit card checks, convert currencies, or implement payroll functionality.

The definition of a web service according to W3C.org leaves the technical implementation completely open. Neither message nor application protocol are defined. They only have to comply with applicable internet standards.

For example, an XML in a mail would be a valid implementation of the web service definition just like a SOAP message over HTTP. In practice, SOAP (Simple Object Access Protocol) has established itself as the message protocol and HTTP as the application protocol.

SOAP via HTTP was a System2System communication, a further programming paradigm has emerged as an alternative web service implementation with the widespread use of alternative devices such as tablets, etc. REST (Representational State Transfer). REST is a programming paradigm for web applications. There is no explicit norm, therefore the ideas of what REST is diverge. Basically, REST refers to the idea that a URL represents exactly one page content (resource) as the result of a server-side action (such as displaying a hit list after a search). The internet standard HTTP for static content (permalinks) already provides this. For dynamically generated pages, however, this sometimes requires additional effort.

SAP mainly uses REST to access business data via mobile devices, such as tablets, etc.

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.

Based on HTTP, Simple Object Access Protocol (SOAP) is now established as the quasi-standard access protocol. 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 (SR). A Service Registry is a type of yellow pages for web services. An SR 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 SR. However, if the application knows the provider and the call details, it can use the web service without having to access the SR. In a client/server relationship, the service requester is the application client.

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.