Concepts of Enterprise Services 
The architecture of the established SAP R/3 system provides a good scalability of the overall system. This is reflected in the three tiers of the front end (GUI), the application server, and the database. The programming on the ABAP application server based itself on the structures defined by the database model.
With the growing heterogeneity of the systems and programming languages, the need to extend this architecture has also grown. In extending the architecture, the aim is to develop software according to a paradigm that can better support the reusability of program code, the transparency of the software architecture, and the openness to use it in a homogenous development environment. The platform to realize this paradigm must have the following characteristics:
A development environment that is programming-language-independent, and that is model-driven and based on open standards.
A development based on services that encapsulate the access to required data. New software can thus be enhanced based on existing services.
Irrespective of which platforms the paradigm supports, the term used to describe the general philosophy of this approach is “SOA” (“Service-Oriented Architecture”). The Enterprise Services Repository concentrates on facilitating a model-driven development within SOA.
From Web Services to Enterprise Services and the Outside-In Approach
The “Web Services” technology enables a company to act as a “provider” that can provide services within and beyond the company. The problem posed by the use of different programming languages is overcome by encapsulating an existing function in a system (such as a function module or a method of a class) using a Web service. The Web service definition contains the signature for the function and other information required to call it (such as the address of the server on which the function can be called). To provide this information to a consumer, you publish the Web service as a WSDL document (WSDL = Web Service Description Language). Using this XML standard, consumers of the services can generate a proxy in their application systems, with which they can then use the SOAP protocol to call the Web service. Thus, this involves passing a programming-language-independent description of a function in a system to another outside application. Hence the use of the term“ inside-out development”.
More is demanded of an “enterprise service” than is of a Web service; from a technical perspective, an enterprise service is a link in the chain of services to be executed within the overall process of a company. This process can also involve various applications. The connection between the enterprise service and other services is vital for the understanding of the overall process. Unlike Web services, you can regard enterprise services as being more integrated in an overall process, rather than as an independent service. It is therefore important that enterprise services be developed based on a model that documents the use of the service. The language used to develop the enterprise service is of less significance. In technically implementing these requirements, SAP NetWeaver adopts the outside-in approach, which basically involves two steps:
Development of the service starts in the Enterprise Services Builder (ES Builder). In contrast to inside-out development (whereby a WSDL document is generated on the basis of an existing function and then published), the ES Builder creates the service implicitly as a WSDL document in the Enterprise Service Repository (ES Repository).
To implement or call a service, developers generate proxies in the relevant application system for the service from the ES Repository. Developments therefore begins outside the application system and is then continued in the application system (hence the term outside-in).
Since the ES Repository is a central storage for services from various applications and systems, modeling editors within the ES Builder can reference the relevant objects directly, without the need to log on to an application system first.
The outside-in approach is a prerequisite for the development of enterprise services. Nevertheless, there is sometimes some overlap with inside-out development. In such cases, references are made to the relevant sections.
Note
Instead of “outside-in” and “inside-out”, the SOA world commonly uses the following terms as well: “contract first” and “code first”; “top-down” and “bottom-up”.