Skip Headers
Oracle® Fusion Middleware Developer's Guide for Oracle SOA Suite
11g Release 1 (11.1.1)
  Go To Table Of Contents
Go To Index


1 Introduction to Building Applications with Oracle SOA Suite

This chapter describes the architecture and key functionality of Oracle SOA Suite.

This chapter includes the following sections:

1.1 Introduction to Service-Oriented Architecture

Changing markets, increasing competitive pressures, and evolving customer needs are placing greater pressure on IT to deliver greater flexibility and speed. Today, every organization is faced with predicting change in a global business environment, to rapidly respond to competitors, and to best exploit organizational assets for growth. In response to these challenges, leading companies are adopting service-oriented architecture (SOA) to deliver on these requirements by overcoming the complexity of their application and IT environments.

SOA provides an enterprise architecture that supports building connected enterprise applications to provide solutions to business problems. SOA facilitates the development of enterprise applications as modular business web services that can be easily integrated and reused, creating a truly flexible, adaptable IT infrastructure.

1.2 Introduction to Services

SOA separates business functions into distinct units, or services. A SOA application reuses services to automate a business process.

A standard interface and message structure define services. The most widely used mechanism are web services standards. These standards include the Web Service Description Language (WSDL) file for service interface definition and XML Schema Documents (XSD) for message structure definition. These XML standards are easily exchanged using standard protocols. Because standards for web services use a standard document structure, they enable existing systems to interoperate regardless of the choice of operating system and computer language used for service implementation.

When designing a SOA approach, you create a service portfolio plan to identify common functionality to use as a service within the business process. By creating and maintaining a plan, you ensure that existing services and applications are reused or repurposed whenever possible. This plan also reduces the time spent in creating needed functionality for the application.

1.3 Introduction to Oracle SOA Suite

Oracle SOA Suite provides a complete set of service infrastructure components for designing, deploying, and managing composite applications. Oracle SOA Suite enables services to be created, managed, and orchestrated into composite applications and business processes. Composites enable you to easily assemble multiple technology components into one SOA composite application. Oracle SOA Suite plugs into heterogeneous IT infrastructures and enables enterprises to incrementally adopt SOA.

The components of Oracle SOA Suite benefit from common capabilities, including a single deployment, management, and tooling model, end-to-end security, and unified metadata management. Oracle SOA Suite is unique in that it provides the following set of integrated capabilities:

1.4 Standards Used by Oracle SOA Suite to Enable SOA

Oracle SOA Suite puts a strong emphasis on standards and interoperability. Among the standards it leverages are:

1.5 Service Component Architecture within SOA Composite Applications

Oracle SOA Suite uses the SCA standard as a way to assemble service components into a SOA composite application. SCA provides a programming model for the following:

SCA provides a model for assembling distributed groups of service components into an application, enabling you to describe the details of a service and how services and service components interact. Composites are used to group service components and wires are used to connect service components. SCA helps to remove middleware concerns from the programming code by applying infrastructure declaratively to composites, including security and transactions.

The key benefits of SCA include the following:

A SOA composite is an assembly of services, service components, and references designed and deployed in a single application. Wiring between the services, service components, and references enable message communication. The details for a composite are stored in the composite.xml file.

Figure 1-1 provides an example of a composite that includes an inbound service binding component, a BPEL process service component (named Account), a business rules service component (named AccountRule), and two outbound reference binding components.

Figure 1-1 Simple SOA Composite Architecture

Description of "Figure 1-1 Simple SOA Composite Architecture"

1.5.1 Service Components

Service components are the building blocks that you use to construct a SOA composite application.

The following service components are available. There is a corresponding service engine of the same name for each service component. All service engines can interact in a single composite.

  • BPEL processes provide process orchestration and storage of synchronous or asynchronous process. You design a business process that integrates a series of business activities and services into an end-to-end process flow.

  • Business rules enable you to design a business decision based on rules.

  • Human tasks provide workflow modeling that describes the tasks for users or groups to perform as part of an end-to-end business process flow.

  • Mediators route events (messages) between different components

1.5.2 Binding Components

Binding components establish a connection between a SOA composite and the external world. There are two types of binding components:

  • Services provide the outside world with an entry point to the SOA composite application. The WSDL file of the service advertises its capabilities to external applications. These capabilities are used for contacting the SOA composite application components. The binding connectivity of the service describes the protocols that can communicate with the service, for example, SOAP/HTTP or a JCA adapter.

  • References enable messages to be sent from the SOA composite application to external services in the outside world.

Table 1-1 lists and describes the binding components provided by Oracle SOA Suite.

Table 1-1 Binding Components Provided by Oracle SOA Suite

Binding Components Description


Use for connecting to standards-based services using SOAP over HTTP.

JCA Adapters

Use for integrating services and references with technologies (for example, databases, file systems, FTP servers, messaging: JMS, IBM WebSphere MQ, and so on) and applications (Oracle E-Business Suite, PeopleSoft, and so on). This includes AQ Adapter, Database Adapter, File Adapter, FTP Adapter, JMS Adapter, MQ Adapter, and Socket Adapter.

B2B binding component

Use for browsing B2B metadata in the MDS repository and selecting document definitions.

ADF-BC Service

Use for connecting Oracle Application Development Framework (ADF) applications using SDO with the SOA platform.

Oracle Applications

Use for integrating Oracle Application Adapter with Oracle Applications.

BAM Adapter

Use for integrating Java EE applications with Oracle BAM Server to send data and also used as a reference binding component in a SOA composite application.

EJB Service

Use for integrating SDO parameters with Enterprise JavaBeans.

Direct Binding Service

Use to invoke a SOA composite application and exchange messages over a remote method invocation (RMI)

1.5.3 Wires

Wires enable you to graphically connect the following components in a single SOA composite application for message communication:

  • Services to service components

  • Service components to other service components

  • Service components to references

1.6 Runtime Behavior of a SOA Composite Application

Figure 1-2 shows the operability of a SOA composite application using SCA technology. In this example, an external application (.NET payment calculator) initiates contact with the SOA composite application.

For more information about descriptions of the tasks that services, references, service components, and wires perform in an application, see Section 1.5, "Service Component Architecture within SOA Composite Applications."

Figure 1-2 Runtime Behavior of SOA Composite Application

Introduction to SOA Composite Application
Description of "Figure 1-2 Runtime Behavior of SOA Composite Application"

The .NET payment calculator is an external application that sends a SOAP message to the SOA application to initiate contact. The Service Infrastructure picks up the SOAP message from the binding component and determines the intended component target. The BPEL service engine receives the message from the Service Infrastructure for processing by the BPEL Loan Process application and posts the message back to the Service Infrastructure after completing the processing.

Table 1-2 describes the operability of the SOA composite application shown in Figure 1-1.

Table 1-2 Introduction to a SOA Composite Application Using SCA Technologies

Part Description Example of Use in Figure 1-1 See Section

Binding Components

Establishes the connectivity between a SOA composite and the external world. There are two types:

  • Service binding components provide an entry point to the SOA composite application.

  • Reference binding components enable messages to be sent from the SOA composite application to external services.

The SOAP binding component service:

  • Advertises its capabilities in the WSDL file.

  • Receives the SOAP message from the .NET application.

  • Sends the message through the policy infrastructure for security checking.

  • Translates the message to a normalized message (an internal representation of the service's WSDL contract in XML format).

  • Posts the message to the Service Infrastructure.

An example of a binding component reference in Figure 1-2 is the Loan Process application.

Section 1.5.1, "Service Components"

Service Infrastructure

Provides internal message transport

The Service Infrastructure:

  • Receives the message from the SOAP binding component service.

  • Posts the message for processing to the BPEL process service engine first and the human task service engine second.

Section 1.6.1, "Service Infrastructure"

Service Engines (containers hosting service components)

Host the business logic or processing rules of the service components. Each service component has its own service engine.

The BPEL service engine:

  • Receives the message from the Service Infrastructure for processing by the BPEL Loan Process application.

  • Posts the message to the Service Infrastructure after completing the processing.

Section 1.6.2, "Service Engines"


The MDS (Metadata Service) repository stores descriptions of available services. The UDDI advertises these services, and enables discovery and dynamic binding at runtime.

The SOAP service used in this composite application is stored in the MDS and can also be published to UDDI.

Oracle Fusion Middleware Getting Started with Oracle SOA Suite

SOA Archive: Composite

(deployment unit)

The deployment unit that describes the composite application.

The SOA archive (SAR) of the composite application is deployed to the Service Infrastructure.

Section 1.6.3, "Deployed Service Archives"

1.6.1 Service Infrastructure

The Service Infrastructure provides the following internal message routing infrastructure capabilities for connecting components and enabling data flow:

  • Receives messages from the service providers or external partners through SOAP services or adapters

  • Sends the message to the appropriate service engine

  • Receives the message back from the service engine and sends it to any additional service engines in the composite or to a reference binding component based on the wiring

1.6.2 Service Engines

Service engines are containers that host the business logic or processing rules of these service components. Service engines process the message information received from the Service Infrastructure.

There is a corresponding service engine of the same name for each service component. All service engines can interact in a single composite.

For more information, see Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite.

1.6.3 Deployed Service Archives

The SAR is a SOA archive deployment unit. A SAR file is a special JAR file that requires a prefix of sca_. (for example, sca_OrderBookingComposite_rev1.0.jar). The SAR file is deployed to the Service Infrastructure. The SAR packages service components, such as BPEL processes, business rules, human tasks, and mediator routing services into a single application. The SAR file is analogous to the BPEL suitcase archive of previous releases, but at the higher composite level and with any additional service components that your application includes (for example, human tasks, business rules, and mediator routing services).

For more information, see Chapter 38, "Deploying SOA Composite Applications."

1.7 Approaches for Designing SOA Composite Applications

When creating a SOA composite application, you have a choice of approaches for building it:

1.8 Learning Oracle SOA Suite

In addition to this developer's guide, Oracle also offers the following resources to help you learn how you can best use Oracle SOA Suite in your applications: