Enabling Enterprise Services 

From Data-Model-Oriented to Service-Oriented Development

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 service-oriented paradigm: Rather than reaccessing database structures for each new development, the idea is to use services that encapsulate this access, so that the flexibility of the software development can be increased and the reusability improved. Due to the growing heterogeneity, it is also becoming more and more important to homogenize development tools and modeling techniques at various levels of abstraction. This makes it possible to clearly represent and better control those processes of a company that are automated using software. Services that are essential for the execution and understanding of these processes are referred to as Enterprise Services. The term Enterprise Service-Oriented Architecture (Enterprise SOA) covers all concepts around which this new software development is oriented. SAP NetWeaver is the platform that provides increasingly more functions to technically support these concepts.

Service-Oriented Variants in SAP NetWeaver 7.0

SAP NetWeaver 7.0 already supports the first Enterprise SOA concepts, and focuses mainly on cross-application communication (company-internal and cross-company) based on open standards. The development or publication of services based on Web Service Description Language (WSDL) is an important milestone in this area. There are generally two different development approaches:

●      Inside-Out Development
Existing functions that software developers have developed in ABAP or Java in a system are made accessible using a Web service. For this purpose, the WSDL description of this Web service is published to the 'outside world' (on a UDDI server, for example). Consumers of a Web service can use this description to include a call in their program code. If ABAP or Java developers want to call a Web service, they create client proxies in the application system by using the ABAP Workbench or SAP NetWeaver Developer Studio.

●      Outside-In Development
Development is not begun in a system that restricts the software developer to a particular platform and programming language, but is begun outside such a system, in the Integration Builder. Using this development tool, the developer specifies the WSDL description in a central Integration Repository independent of the programming language. From this description, the actual function can be implemented in the application system (as a server proxy). The call to this function can also be implemented (using a client proxy).

The publication of Web services (inside-out development) is intended for point-to-point communication. The central development of interfaces in the Integration Repository (outside-in development) is part of SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI) and is intended for communication using the Integration Server. These scenario variants are summarized in the following table:

Scenario Variants for Enabling Enterprise Services

Scenario Variant	Development Approach	More Information
Service-Based Integration (Point-to-Point)	Inside-Out	Web Services
Brokered Service-Based Integration	Outside-In and Inside-Out	Enabling Application-to-Application Processes in the SAP NetWeaver Developer’s Guide

In the second scenario variant, the development approaches are combined, since the Integration Builder also supports the import of interface descriptions into the Integration Repository to facilitate communication between SAP and non-SAP systems. The first scenario variant is generally intended for simple, synchronous, cross-application communication, whereas additional integration services of the Integration Server (such as routing and mapping) can be used in the second scenario variant. The advantage of the first variant is that it involves a relatively short adjustment period compared to the second variant.

Development Environment and Programming Model

Outside-in and inside-out development both use a WSDL description to represent the interface of a service language-independently. This common feature is already used in the ABAP environment in SAP NetWeaver 7.0 to make it possible to select between the scenario variants outlined above, independent of the original outside-in development approach. If synchronous communication using the Integration Server does not use integration services or protocols that are specific to SAP NetWeaver XI, developers can switch to point-to-point communication using Web services. (See also ABAP Proxy Runtime). In ABAP, developers work with the ABAP Workbench for both scenario variants. The common features of the scenarios are summarized in the following table:

Approach	Development Tools	Application
Inside-Out	SAP NetWeaver Developer Studio (Creation of Java proxies)	Creation of client proxies for calling Web services (point-to-point). Communication using the Integration Server is possible using the SOAP adapter.
	ABAP Workbench (Creation of ABAP proxies)
Outside-In		Creation of client and server proxies for direct communication using the Integration Server or point-to-point communication.
	Integration Builder (Creation of Java proxies)	Creation of client and server proxies for direct communication using the Integration Server.

In ABAP, the programming model for the communication between client and server proxies is independent of whether or not the communication is made using the Integration Server. This does not yet apply to Java in SAP NetWeaver 7.0.