Business processes are divided into process steps. You can assign one or more functions to each of these steps and an executing software component to each of these functions. In a typical heterogeneous system landscape in a company, the necessary functions in a global process are not all implemented using the same technology or the same components. The integration of an ever-increasing number of business partners, in particular, complicates this problem further. A modern software infrastructure must therefore be able to integrate functions that are implemented on different software components into an efficient global process.
Internet technology provides the basis for calling and communicating with distributed services. Superimposed onto this simple, globally-accepted communication standard, XML provides the basis for defining additional necessary standards. Only when you move away from proprietary definitions and toward generally accepted standards, is there a 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, 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.
Features of Web Services are:
Web services are application functions and services.
Web services can be used through internet standards.
Web services are self-descriptive.
Web services can be published and traced.
Web Service Paradigm
The figure illustrates the most important web services and internet standards and how they interact.
Service Provider
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.
Service Requestor
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.
