Introduction to Service Development 

A service provides a solution for predefined tasks and is implemented in a system. The service is provided by a provider and is implemented in a provider system. The service is in turn consumed by a consumer in a consumer system. Apart from the technical implementation, there are also many questions and requirements surrounding the development of services. Here are some examples to illustrate this:

·        Where is the service provided and where is it required?

·        Does the service already exist or does it need to be developed first?

·        What kind of character does the service have? Is it a company-internal service (A2A) or a cross-company service (B2B)? Is the service essential for the execution of the overall process or is it an isolated service? Is it a finely-granulated service, or does it comprise other services?

·        How many consumers will access the service? Is the execution time of critical importance in the scenario?

·        Does the service data need to be displayed on the user interface?

The answers to questions such as these determine which methods you use to implement a service and make it accessible to consumers.

The following section introduces a few methods and technologies to differentiate the development of services in the Enterprise Services Repository from other scenarios.

Outside-In Versus Inside-Out:

It is possible to call services independently of the interface technology used. To do so, the consumer simply requires a service description. There are two ways that the consumer can get hold of this description:

·        If the service already exists in the system, you can use the service signature in the system to generate a service description. The service can be published externally, for example on a central server. This is known as the inside-out development approach.

·        If no service exists in the system, you can initially describe it outside of the system. The advantage of this method is that you can apply the description together with the services of associated objects during the development process; furthermore, you can do so independently of the implementation for other programmers' developments. You can generate development objects in the relevant development system to enable you to implement and call the service (for the consumer and provider). This is known as the outside-in development approach.

SAP NetWeaver uses XML technology for the service descriptions. Since in the outside-in approach you create non-language-specific service descriptions and not classic development objects, this phase is known as the design phase.

Which development approach you decide to use largely depends on whether the service already exists or not. The next section looks in more detail at a further dimension of service development, namely how the call is realized on a technical.

Web Services Versus Enhanced Scenarios (Integration Server)

SAP NetWeaver offers two development variants for cross-system service calls:

·        Service called directly by using Web service technology (point-to-point).

·        Service called by using the Integration Server, which in turn forwards the call.

In both variants you have the option of developing the services according to either the outside-in or inside-out approach.

Development Approaches

Variant	Approach	Basic Procedure
Point-to-Point	Inside-Out	You create a WSDL document for an existing function in the application system (that you can then publish on a UDDI server, for example). The caller generates a consumer proxy from the WSDL document; the application on the consumer side then uses this proxy to call the service at the provider.
	Outside-In	Development begins in the Enterprise Services Repository with the design of service interfaces which can be called directly as a WSDL document. Based on the service interfaces, developers generate proxies for both the provider and the consumer. However, the WSDL document does not contain any information about how the provider of the service can be addressed. Which method is used to complete this information depends on the development variant (point-to-point or using the Integration Server).
Integration Server
	Inside-Out	You import an XML description for an existing function to the Enterprise Services Repository. The XML description can be used by any number of callers for communication using the Integration Server.

The documentation on the Enterprise Services Repository concentrates on details about the relevant objects editors in the Enterprise Services Builder. Any special details about the relevant development variant are only mentioned briefly.