Oracle E-Business Suite Integrated SOA Gateway Overview

This chapter covers the following topics:

Oracle E-Business Suite Integrated SOA Gateway Overview

Building on top of Oracle Fusion Middleware and service-oriented architecture (SOA) technology, Oracle E-Business Suite Integrated SOA Gateway (ISG) is a complete set of service infrastructure to provide, consume, and administer Oracle E-Business Suite Web services.

With service enablement feature, integration interfaces published in the Oracle Integration Repository can be transformed into SOAP and REST based Web services.

SOAP-based services are described in WSDLs and are deployed to the application server for service consumption. REST services described in WADLs are used for user-driven applications such as Oracle E-Business Suite mobile applications.

Oracle E-Business Suite Integrated SOA Gateway provides Service Invocation Framework to invoke and consume Web services provided by other applications.

For more information about each integration interface and service, see the Oracle E-Business Suite Integrated SOA Gateway User's Guide; for more information about Web service invocation and performing service integration activities, see the Oracle E-Business Suite Integrated SOA Gateway Developer's Guide.

Major Features

Oracle E-Business Suite Integrated SOA Gateway contains the following features:

Major Components Features and Definitions

The better understand Oracle E-Business Suite Integrated SOA Gateway and its key components, this section describes some key features and the definition of each component.

Native Service Enablement

Service enablement is the key feature within Oracle E-Business Suite Integrated SOA Gateway. It provides a mechanism that allows native packaged integration interface definitions residing in Oracle Integration Repository to be further transformed into Web services that comply with Web standards. Additionally, these services can be deployed from the Integration Repository to the application server allowing more consumptions over the Web.

To understand the basic concept of Web services and how the service works, the following diagram illustrates the essential components for service enablement:

Major Components for Service Enablement

the picture is described in the document text

A Service Provider is the primary engine underlying the Web services. It facilitates the service enablement for various types of interfaces.

A Service Consumer (Web service client) is the party that uses or consumes the services provided by the Service Provider.

A Service Broker (Service Registry) describes the service's location and contract to ensure service information is available to any potential service consumer.

Composite Services

Composite services use the native service as building blocks to construct the sequence of business flows. Basically, this interface type orchestrates the invocation sequence of discrete Web services into a meaningful end-to-end business process through a Web service composition language BPEL (business process execution language).

For example, use Oracle BPEL Process Manager (BPEL PM) to integrate the Order-to-Receipt business process that contains sales order entry, item availability check, pack and ship, and invoice to Accounts Receivable sub processes handled by various applications. This approach effectively tightens up the control of each individual process and makes the entire business flow more efficiently.

Oracle Integration Repository and Service Enablement

Oracle Integration Repository, an integral part of Oracle E-Business Suite, is the centralized repository that contains numerous interface endpoints exposed by applications within the Oracle E-Business Suite.

To effectively manage all integration interfaces and services incurred within the Oracle E-Business Suite, Oracle E-Business Suite Integrated SOA Gateway now supports complex business processes or composite services, Web service generation and deployment, as well as business event subscriptions through the centralized Integration Repository.

You can browse these interface definitions and services through the Oracle Integration Repository user interfaces. Users with administrator privileges can further perform administrative tasks through the same interfaces.

Oracle Integration Repository supports the following interface types:

Please note that not all the interface types resided in the Integration Repository can be service enabled. The supported interface types for service enablement are XML Gateway, PL/SQL, Concurrent Program, Business Service Object, Application Module Services, Java Bean Services, Open Interface Tables, and Open Interface Views.

As mentioned earlier, security services are pregenerated REST services from Oracle Application Object Library. Therefore, there is no need to enable the security services from the repository as required by other supported interface types.

Manage Security

To protect application data from unauthorized access, Oracle E-Business Suite integrated SOA Gateway enforces the security rules through subject authentication and authorization:

SOA Monitor

SOA Monitor is a centralized, light-weight service execution monitoring and management tool. It not only monitors all the SOAP requests that SOA Provider and Web Service Provider process, but also provides auditing feature for the SOAP messages if the auditing feature is enabled.

With SOA Monitor, the integration repository administrator can effectively manage and identify errors incurred during the service deployment life cycle and take necessary actions to expedite the interaction between services.

Service Invocation Framework

To invoke all integration services from Oracle E-Business Suite, Oracle E-Business Suite Integrated SOA Gateway uses the Service Invocation Framework (SIF) that leverages Oracle Workflow Java Business Event System (JBES) and a seeded Java rule function to allow any WSDL-described service to be invoked.

By using this service invocation framework, developers or implementors can interact with Web services through WSDL descriptions instead of working directly with SOAP APIs, the usual programming model. This approach lets you use WSDL as a normalized description of disparate software, and allows you to access this software in a manner that is independent of protocol or location.

Since this feature is the major development framework in invoking Web services within the entire Oracle E-Business Suite, detailed implementation information is described in a separate chapter in this book.

See Implementing Service Invocation Framework.

Native Service Enablement Architecture Overview

Oracle E-Business Suite Integrated SOA Gateway employs essential key components that enable native service integration at design time and runtime, and ease the service management throughout the entire service integration and deployment life cycle.

The following diagram illustrates the integration architecture flow between each SOA component:

Native Service Enablement Architecture Flow Diagram

the picture is described in the document text

All the native packaged public integration interfaces are published in the Oracle Integration Repository by default. Users who have the Integration Repository Administrator role can then transform these native integration interfaces into web services by service generator. Service loader uploads service artifacts to Oracle Integration Repository. Service deployer deploys service artifacts from the Integration Repository to the application server where services can be exposed to customers through service provider.

Service provider identifies and processes inbound SOAP requests from service consumers or web service clients, reinforces function security and web service security, as well as passes all SOAP request and response messages to SOA Monitor (if the monitoring feature is enabled) for further monitoring to ensure the seamless service invocations throughout the entire service life cycle.

Service provider is the primary engine enabling the Oracle E-Business Suite services. It is the engine that performs the actual service generation and deployment behind the scene for both SOAP and REST services.

SOAP Service Enablement at Design Time

All the native packaged public integration interfaces are published in Oracle Integration Repository by default.

At design time, an integration repository administrator performs the web service generation task through the Integration Repository user interface. This sends a request for service generation and invokes the Service Generator to create service artifacts and stores them in the application server file system. Service loader then uploads these artifacts to Oracle Integration Repository.

These tasks are completed through the Oracle Integration Repository user interfaces and they are actually executed by SOA Provider behind the scenes.

Important: XML Gateway maps can be supported by both Web Service Provider in Release 12.0 and by SOA Provider in this release. For backward compatibility in supporting the XML Gateway Map service enablement, a profile option FND: XML Gateway Map Service Provider (FND_SOA_SERVICE_PROVIDER) is used to let you select an appropriate service provider in enabling services for XML Gateway Map interfaces. Based on the selected profile value, you may find the Web Service - SOA Provider region, or Web Service - Web Service Provider region, or both regions displayed in the XML Gateway Interface Details Page. See XML Gateway Map Web Service Region, Oracle E-Business Suite Integrated SOA Gateway User's Guide.

The following diagram illustrates the service generation function flows at design time:

the picture is described in the document text

  1. Integration Repository UI sends a request for a service generation to SOA Provider.

  2. SOA Provider passes the request to Service Generator.

  3. Service Generator generates the service artifact.

    Note: Service artifacts are generated in the application server file system at location specified by system property SOA_SERVER_TEMP_DIRECTORY_LOCATION.

    These artifacts are located in oc4j.property of OAFM container. The file system storage structure on server (may use System.getProperty (APPLRGF)) can be as follows:

    TEMP_LOCATION
      |_Type (such as PL/SQL, concurrent program, etc.)
             |_ClassID
                        (contains all SQL Wrapper packages)

  4. Service Loader uploads the service artifact to Oracle Integration Repository.

Integration repository administrators as defined by the Integration Repository Administrator role can further deploy the services from Oracle Integration Repository to the application server where services can be exposed to customers through service provider.

Note: For information about the Integration Repository Administrator role, see Role-Based Access Control (RBAC) Security for Oracle E-Business Suite Integrated SOA Gateway.

REST Service at Design Time

REST services are developed based on Oracle E-Business Suite technology infrastructure. At design time, an integration repository administrator can deploy a selected interface as a REST service. Additionally, the administrator can undeploy the service if needed.

SOAP Service Enablement Runtime

At runtime, a service consumer or web service client sends a SOAP request message. SOA Provider receives the request message and references integration services and data from Oracle Integration Repository in processing the request that invokes web service. Function security is enforced at this time to secure the web service content from unauthorized access. After passing security checks on the inbound request, SOA Provider then sends the SOAP response message out back to the web service client.

The following diagram illustrates the web service process flows between a web service client and Oracle E-Business Suite through SOA Provider at runtime:

the picture is described in the document text

  1. Web service client sends a SOAP request to WSDL URL that is redirected to SOA Provider Servlet.

  2. The inbound SOAP message is passed to OC4J Web Service Framework.

  3. The OC4J Web Service Framework authenticates the SOAP message based on the wsse:security headers. To validate username and password, the Framework calls Application Security Handler.

  4. On authentication of the SOAP message user, the Framework hands over the message along with its context to SOA Provider.

  5. SOA Provider hands over the request to Service Handler.

  6. Service Handler calls the Function Security Handler to decide whether the user is authorized to execute the particular interface.

  7. After passing authorization check, the request is passed on to Service Run Time Engine.

  8. Service Run Time Engine executes the interface on Oracle E-Business Suite.

  9. Response is returned back to the Service Run Time Engine.

  10. Response is converted to a SOAP response and returned back to Service Handler.

  11. Service Handler returns the SOAP response back to SOA Provider.

  12. SOA Provider returns the SOAP response back to SOA Provider Servlet.

  13. SOA Provider Servlet returns the SOAP response back to web service client.

Web Service Clients

To enable integration interfaces become web services, Oracle E-Business Suite Integrated SOA Gateway uses the following technologies or tools for web service enablement: