Enterprise/Web Services Interoperability 

This scenario variant shows you how you can develop services based on Web service standards, and how you can apply these services.

Service Concept

The complexity of heterogeneous system landscapes based on different platforms, computer languages, and proprietary APIs makes the integration of processes and applications a difficult task. Using Web services enables you to integrate applications without the need for complicated, expensive development projects. The following concepts are fundamental for the development of these services:

·        A service is a routine that can be called and executed. It hides the implementation and the actual accessing of the data. Unlike proprietary APIs, services have a standardized interface. To make an existing function of a system available to the outside world, you can encapsulate the function as a service.

·        Services are based on the W3C standard WSDL (Web Service Description Language). WSDL is independent of a specific computer language. Consumers of a service use this description to call the service. You can either create a WSDL description for existing functions, or create services directly in WSDL.

·        When you cross-system processes are developed and modeled, it is essential that the description of a service is available centrally, for example on a UDDI server (Universal Description, Discovery, and Integration). However, developers still implement the service in the application systems.

·        Developing according to the service concept is the key to the flexibility of an Enterprise Service Architecture (ESA).

Service Provider and Service Consumer

This scenario variant distinguishes between the service provider that implements and provides services, and the consumer who calls these services:

·        Services are developed based on universal standards, regardless of how the services are used.

·        The way each service can be used is not fixed and there are different variants, which are dependent on the requirements of the application. The variants define the way the service is called and who calls the service.

 

Two approaches are possible:

·        Point-to-point

Business functionality is exposed directly to a Web service consumer.

·        Brokered

A brokered scenario can be used a Web service call results in a more complex scenario requiring additional routing and mapping steps.

SAP NetWeaver allows you to expose existing functionality (for example BAPIs, RFCs, IDocs, EJBs) as Web services (that is, to act as a provider) and allow a third party to consume other compliant Web services (that is, to act as a client).

IBM and Microsoft can be both providers and consumers of Web services provided by SAP NetWeaver.

 

 

Enterprise/Web services interoperability offers the following benefits:

·        Create new value from existing IT assets by exposing existing application functionality as a Web Service, allowing functions to be combined in a single process even if they are implemented in different software components.

·        Flexible implementation either in ABAP or Java by providing the infrastructure that supports both programming languages.

·        Standardization and extensibility of business processes by incorporating security standards and additional protocols in the Web Services framework in the SAP NetWeaver.

Required Usage Types of SAP NetWeaver

·        Process Integration (PI)

·        Application Server (AS)

Additional Information

http://www.ibm.com/developer– contains information related to building Web services in WebSphere.

www.sdn.sap.com - see Web services page - for more information related to building Web services using SAP NetWeaver Developer Studio.

IT Processes of the Scenario Variant

Process	Description
Point-to-Point: Service Call at the User	To execute a service in another system, the application calls a proxy in the application system. The result of the call is that the application system sends a message to the Integration Broker.
Point-to-Point: Service Execution at the Provider	The service provider receives the message and calls the service. If you have synchronous calling, the receiver sends the response message to the Web service client.
Brokered: Service call at the Receiver	To execute a service of another system, the application calls a proxy in the application system. The result of the call is that the application system sends a message to the Integration Broker.
Brokered: Handling Messages	The Integration Broker processes the messages according to a central configuration, which defines the routing and, if applicable, any mappings.
Brokered: Service Execution at Provider	The service provider receives the message and calls the service. The receiver sends the response to the request to the Web service client by using the Integration Broker