1 Introduction and Concepts

This chapter provides a brief introduction to Oracle Fusion Middleware, Oracle Service-Oriented Architecture (SOA) Suite, and administration of Oracle SOA Suite from Oracle Enterprise Manager Fusion Middleware Control Console.

This chapter includes the following topics:

For more information about Oracle Enterprise Manager Fusion Middleware Control Console administrative tasks and Oracle Fusion Middleware concepts, see the following documents:

1.1 What Is Oracle Fusion Middleware?

Oracle Fusion Middleware is a collection of standards-based software products that spans a range of tools and services: from Java EE and developer tools, to integration services, business intelligence, and collaboration. Oracle Fusion Middleware offers complete support for development, deployment, and management.

1.2 What Is Oracle SOA Suite?

Oracle SOA Suite is a middleware component of Oracle Fusion Middleware. Oracle SOA Suite provides a complete set of service infrastructure components for designing, deploying, and managing SOA composite applications. Oracle SOA Suite enables services to be created, managed, and orchestrated into SOA composite applications. 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.

You can administer Oracle SOA Suite from Oracle Enterprise Manager Fusion Middleware Control Console. The following sections provide an overview of the components of Oracle SOA Suite:

For introductory information about Oracle SOA Suite, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

1.2.1 Understanding the SOA Infrastructure Application

The SOA Infrastructure is a Java EE-compliant application running in Oracle WebLogic Server. The application manages composites and their life cycle, service engines, and binding components.

You deploy SOA composite applications designed in Oracle JDeveloper to the SOA Infrastructure. In the example shown in Figure 1-1, many SOA composite applications are deployed to the SOA Infrastructure and are visible in Oracle Enterprise Manager Fusion Middleware Control Console.

From the SOA Infrastructure home page, you can perform administration tasks such as monitoring SOA composite applications, monitoring individual composite instances, and updating the state of SOA composite applications and individual composite instances. You can also perform corrective actions such as fault recovery.

Figure 1-1 SOA Composite Applications Deployed in the SOA Infrastructure

Description of Figure 1-1 follows
Description of "Figure 1-1 SOA Composite Applications Deployed in the SOA Infrastructure"

You can click a specific SOA composite application in the Composite table to access its home page. Figure 1-2 shows the upper part of the home page for the EventMediatorDemo SOA composite application. From the SOA composite application home page, you can perform administration tasks such as monitoring instances, recovering from faults, managing the state of application instances, and attaching policies. You can also perform a limited number of configuration tasks at the SOA composite application level, such as specifying the composite audit level and payload validation.

Figure 1-2 SOA Composite Application Home Page (Upper Part)

Description of Figure 1-2 follows
Description of "Figure 1-2 SOA Composite Application Home Page (Upper Part)"

Figure 1-3 shows the lower part of the home page for the EventMediatorDemo SOA composite application. The service components and service and reference binding components included in the EventMediatorDemo are shown.

Figure 1-3 SOA Composite Application Home Page (Lower Part)

Description of Figure 1-3 follows
Description of "Figure 1-3 SOA Composite Application Home Page (Lower Part)"

For more information, see the following sections:

1.2.2 Understanding SOA Composite Applications

SOA composite applications such as those shown in the Deployed Composites page in Figure 1-1 consist of the following:

  • Service components such as Oracle Mediator for routing, BPEL processes for orchestration, human tasks for workflow approvals, and decision services for working with business rules

  • Binding components (services and references) for connecting SOA composite applications to external services, applications, and technologies

These components are assembled into a single SOA composite application. Having the components assembled into one unit of deployment (the application) greatly simplifies the management and life cycle of SOA applications.

Figure 1-4 provides an example of a SOA composite application in the SOA Composite Editor in Oracle JDeveloper. Service binding components (such as orderprocessor_client_ep) advertise their capabilities to external consumers. The service exposes a public interface of the SOA composite application (OrderBookingComposite) consisting of BPEL process, Oracle Mediator, human task, and decision service components. A wire connects the service to a specific component or reference in the composite. Reference binding components (such as CreditCardAuthorizationService and PartnerSupplierService) enable messages to be sent from the SOA composite application to external services. The service binding components, service components, and reference binding components are wired (connected) for communication.

Figure 1-4 SOA Composite Application

Description of Figure 1-4 follows
Description of "Figure 1-4 SOA Composite Application"

The service components and binding components included in a SOA composite application appear in the lower part of an application home page, as shown in Figure 1-3 and Figure 1-5. The example in Figure 1-5 shows two service components (OrderPublisher and EventMediator) and two binding components (service OrderPublisher_ep and reference OrderLogger). You can click a specific service component or binding component to access its home page.

Figure 1-5 Service Components and Binding Components of a SOA Composite Application

Description of Figure 1-5 follows
Description of "Figure 1-5 Service Components and Binding Components of a SOA Composite Application "

For more information, see the following documentation:

1.2.3 Understanding SOA Composite Application Instances

When a SOA composite application is invoked, a new composite instance is created. This instance is identified by a unique instance ID that displays in pages of Oracle Enterprise Manager Fusion Middleware Control Console. For example, Figure 1-6 shows instance IDs displaying for the AutoLoanComposite, CompositeTest, and EventMediatorDemo SOA composite applications in the Instances page of the SOA Infrastructure. You can click these IDs to access more specific details about the state of SOA composite application instances. From the Instances page, you can also monitor the state of SOA composite application instances.

Instances that you create as unit tests from the Test Runs page are distinguished from those created automatically or manually from the Test Web Service page by a little yellow box. This box displays to the left of the instance ID, as shown in Figure 1-6. This box is visible in both the Instances page and in the Recent Instances table of the Dashboard page of the SOA Infrastructure and SOA composite application.

For some SOA composite applications, conversation IDs are also generated. Conversation IDs provide another method for distinctly identifying a set of generated instances. As shown in Figure 1-6, conversation IDs do not automatically display for all instances. To see a conversation ID generated, perform one of the following tasks:

  • Programatically invoke the service and pass a unique ID through a WS-Addressing header (messageId).

  • Create an instance using the Test Web Service page. The only exception to this is when the Enable Stress Test check box of the Additional Test Options section on the Test Web Service page is selected. In that case, a conversation ID is not created for the instance.

Figure 1-6 SOA Composite Application Instance IDs

Description of Figure 1-6 follows
Description of "Figure 1-6 SOA Composite Application Instance IDs"

For more information, see the following sections:

1.2.4 Understanding Service Components and Service Component Instances

SOA composite applications include service components. Service components are the basic building blocks of SOA composite applications. Service components implement a part of the overall business logic of the SOA composite application.

The following service components can be used in a SOA composite application:

  • BPEL process — For process orchestration of synchronous and asynchronous processes

  • Oracle Mediator — For content transformation and routing events (messages) between service producers and consumers.

  • Human task — For modeling a human task (for example, manual order approval) that describes the tasks for users or groups to perform as part of an end-to-end business process flow

  • Decision service — For making a decision or for processing based on business rules

From the service component home page in Oracle Enterprise Manager Fusion Middleware Control Console, you can perform administration tasks such as monitoring instances, recovering from faults, and attaching policies.

As described in Section 1.2.3, "Understanding SOA Composite Application Instances," each application instance has its own instance ID. Each service component instance included in a SOA composite application instance also has its own instance ID that displays in Oracle Enterprise Manager Fusion Middleware Control Console. Figure 1-7 shows an instance ID (workflow:200000) displaying in the Instance ID column for the VacationRequestTask human task service component of the VacationRequest SOA composite application. You can monitor the state of that service component instance from the Instances page. You can also click this instance to access more specific details about the service component.

Figure 1-7 Service Component Instance IDs

Description of Figure 1-7 follows
Description of "Figure 1-7 Service Component Instance IDs"

For more information about administering service components, see the following sections:

1.2.5 Understanding Binding Components

Binding components connect SOA composite applications to external services, applications, and technologies (such as messaging or databases). Binding components are organized into two groups:

  • 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. The service bindings define how a SOA composite service can be invoked (for example, through SOAP).

  • References — Enable messages to be sent from the SOA composite application to external services (for example, the same functionality that partner links provide for BPEL processes, but at the higher SOA composite application level).

In Oracle Enterprise Manager Fusion Middleware Control Console, you can perform binding component administration tasks such as attaching policies, monitoring rejected messages, and setting binding component properties. Figure 1-8 shows the home page of a service binding component.

Figure 1-8 Binding Components

Description of Figure 1-8 follows
Description of "Figure 1-8 Binding Components"

For more information, see Part XIV, "Administering Binding Components".

1.2.6 Understanding Service Engines

The SOA Infrastructure includes a set of service engines (BPEL process, human workflow, decision service, and Oracle mediator) that execute the business logic of their respective components within the SOA composite application (for example, a BPEL process).

Figure 1-9 provides an example in Oracle Enterprise Manager Fusion Middleware Control Console of the BPEL process service engine. In this engine, the Calling, LoanService, and CreditRatingService BPEL process service components run. Note the multiple instance IDs for LoanService and CreditRatingService. The BPEL process service components are included in two separate SOA composite applications:

  • Calling is included in the Calling SOA composite application.

  • LoanService and CreditRatingService are included in the CompositeTest SOA composite application.

However, each BPEL process service component runs in the same BPEL process service engine. You can click the links on the page to see more details about each BPEL process service component instance, the service component itself, or the SOA composite application in which it is included.

Figure 1-9 Service Components Running in a Service Engine

Description of Figure 1-9 follows
Description of "Figure 1-9 Service Components Running in a Service Engine"

In Oracle Enterprise Manager Fusion Middleware Control Console, you can perform service engine administration tasks such as monitoring instances, recovering from faults, manually recovering (BPEL) failed messages, and configuring properties specific to each service engine. These configuration properties impact all service components that execute in the service engine, no matter which SOA composite application the service components are included in. The service engine pages also include engine-specific statistics and performance metrics.

For more information about administering service engines, see the following sections:

1.2.7 Understanding the Service Infrastructure

The service infrastructure provides the internal message transport infrastructure for connecting components and enabling data flow. The service infrastructure is responsible for routing messages along the wire connections between services, service components, and references.

For more information, see the following sections:

1.2.8 Understanding the Contents of SOA Composite Applications

Your SOA composite application can consist of a variety of service components, binding components, and services that you administer from Oracle Enterprise Manager Fusion Middleware Control Console:

  • BPEL processes

  • Human workflows

  • Oracle Mediator

  • Decision services (Oracle Business Rules)

  • JCA Adapters

  • Oracle BAM

  • Oracle B2B

  • Business events

  • Oracle User Messaging Service

For conceptual information about these service components, binding components, and services, see Oracle Fusion Middleware Getting Started with Oracle SOA Suite.

1.3 Administration of Oracle SOA Suite

You can perform a variety of Oracle SOA Suite administration (configuration, monitoring, and management) tasks from Oracle Enterprise Manager Fusion Middleware Control Console. This section provides an overview of these tasks:

The administrative tasks that you can perform are based on the roles to which you are mapped; each role corresponds to a different set of privileges. Certain users can be mapped to simple monitoring privileges (for instance view-only access), while other users can be granted full access, including the ability to update configurations, restart servers, and so on. For more information about roles in Oracle Enterprise Manager Fusion Middleware Control Console, see Appendix C, "Oracle Enterprise Manager Roles."

1.3.1 Configuration of Oracle SOA Suite

You can perform Oracle SOA Suite configuration tasks in Oracle Enterprise Manager Fusion Middleware Control Console. Configuration tasks consist of setting properties such as audit levels and payload validation for your environment. Properties can be set in the following areas:

  • SOA Infrastructure (impacting all SOA composite applications)

  • Service engines (impacting all service components that execute in the engine, no matter the SOA composite application in which they are included)

  • SOA composite application (impacting all service components that are included in that composite application)

  • Oracle B2B bindings

  • Service and reference binding components message header properties

In terms of order of precedence, inherited SOA composite application property settings (such as audit level settings and payload validation) take the highest precedence, followed by service engine settings, followed by SOA Infrastructure settings. Most properties do not have this type of precedence to consider.

For more information, see the following sections:

1.3.2 Monitoring of Oracle SOA Suite

You can perform Oracle SOA Suite monitoring tasks in Oracle Enterprise Manager Fusion Middleware Control Console, including monitoring the following:

  • Instances, faults, and rejected messages in the SOA Infrastructure, SOA composite applications, service components, service engines, and service and reference binding components

  • Service engine, service infrastructure, and binding component processing request performance

  • Service and reference binding component message processing totals and average processing times

  • Audit trail and process flow behavior in service components

  • Service engine request and thread states in BPEL processes and human workflows

1.3.3 Management of Oracle SOA Suite

You can perform Oracle SOA Suite management tasks in Oracle Enterprise Manager Fusion Middleware Control Console, including managing the following:

  • Startup and shutdown of the SOA Infrastructure application

  • Composite state (activating, retiring, starting, stopping, and setting the default composite version)

  • Deleting and aborting composite instances

  • Deployment, undeployment, and redeployment actions for SOA composite applications

  • Manual initiation of SOA composite application test instances from the Test Web Service page

  • Recovery from faults in SOA composite applications, service components, service engines, and business events

  • Manual recovery of failed messages in BPEL processes

  • Unit testing of SOA composite applications

  • Attachment of policies to SOA composite applications, service components, and binding components

  • Incoming and outgoing notification messages in human workflow

  • Subscriptions to business events and testing of event publications

The following sections provide a more specific overview of several management tasks:

1.3.3.1 Understanding Fault Recovery

You can perform fault recovery actions on BPEL process, Oracle Mediator, human workflow, and business event subscription faults (which include database and component subscription faults) identified as recoverable in Oracle Enterprise Manager Fusion Middleware Control Console. The following types of fault recovery are supported:

  • Recovery from individual faults, where you have access to the most granular recovery options specific to each type of fault

  • Recovery from multiple (bulk) faults, where you select multiple faults for recovery

You can perform individual and bulk recovery actions on recoverable faults at the following levels:

  • Faults occurring in all SOA composite applications in the SOA Infrastructure

  • Faults occurring in an individual SOA composite application

  • Faults occurring in service components

  • Faults occurring in service engines

  • Faults occurring in business events

You perform fault recovery on faults identified as recoverable in Oracle Enterprise Manager Fusion Middleware Control Console. For BPEL process faults to be identified as recoverable, there must be a fault policy defined that is bound to the fault (through the fault-bindings.xml file) and which triggers the action ora-human-intervention. A BPEL component fault can be recovered in only this case. If no fault policy is defined as part of the composite, then a recoverable BPEL process fault is not possible.

You define a fault recovery policy in the fault-policies.xml and fault-bindings.xml files outside of Oracle Enterprise Manager Fusion Middleware Control Console. These files are packaged with the SOA composite application that you deploy to the SOA Infrastructure and administer in Oracle Enterprise Manager Fusion Middleware Control Console.

Oracle Mediator and human workflow faults do not have the same behavior; they can create recoverable faults without any fault policy. For errors in human task service components or human workflow service engines, you perform fault recovery on faults identified as recoverable from the Oracle BPM Worklist.

The following types of faults can be displayed in Oracle Enterprise Manager Fusion Middleware Control Console:

  • Business: Application-specific faults that are generated when there is a problem with the information being processed (for example, a social security number is not found in the database).

  • System: Network errors or other types of errors such as a database server or a Web service being unreachable.

  • Oracle Web Service Manager (OWSM): Errors on policies attached to SOA composite applications, service components, or binding components. Policies apply security to the delivery of messages.

Faults can also be classified as either of the following:

  • Recoverable or nonrecoverable:

    Only certain types of faults are identified as recoverable. Table 1-1 provides examples of several recoverable and nonrecoverable faults.

  • Rejected Messages:

    A fault is classified as a rejected message based on where it occurs. If a fault occurs before entering a SOA composite, without generating a composite instance, it is classified as a rejected message. A system or a policy fault can be identified as a rejected message.

Table 1-1 Faults

Recoverable Faults Nonrecoverable Faults

  • Business faults and some specific system faults

  • Oracle Mediator input file path and output directory mismatch

  • An Oracle BPM Worklist user is not authorized to perform relevant (expected) actions

  • Rejected messages

  • Most system faults

  • Non-existent references

  • Service invocation failures

  • Policy faults

For more information on performing fault recovery, see the following sections:

1.3.3.2 Understanding Policies

You can attach and detach policies at the following levels in Oracle Enterprise Manager Fusion Middleware Control Console:

  • SOA composite applications

  • Service components

  • Service and reference binding components

Policies apply security to the delivery of messages. Oracle Fusion Middleware uses a policy-based model to manage Web services. The following types of policies are supported:

  • Security — Implements WS-Security 1.0 and 1.1 standards. They enforce authentication and authorization of users, identity propagation, and message protection (message integrity and message confidentiality).

  • Reliable Messaging — Supports the WS-ReliableMessaging protocol, guaranteeing the end-to-end delivery of messages.

  • Message Transmission Optimization Mechanism (MTOM) — Ensures that attachments are in MTOM format, a format for efficiently sending binary data to and from Web services.

  • WS-Addressing — Verifies that SOAP messages include WS-Addressing headers in conformance with the WS-Addressing specification. Transport-level data is included in the XML message rather than relying on the network-level transport to convey this information.

  • Management — Logs request, response, and fault messages to a message log. Management policies can include custom policies.

Policies are part of an enterprise policy framework that allows policies to be centrally created and managed.

For more information, see the following documentation:

1.3.3.2.1 Understanding How Policies are Executed

Policies are executed before a message reaches the component with the attached policy. This causes the error to display in the component preceding the component with the attached policy. For example:

  • A policy attached to an Oracle Mediator service component is executed on the wire before the message is passed to the Oracle Mediator. This causes the fault to display in the service binding component instead of the Oracle Mediator.

  • A policy attached to a human task service component is executed in the preceding BPEL process service component before the message is passed to the human task service component. This causes the fault to display in the BPEL process service component instead of the human task service component.

To see the exact location of the policy error, view the audit trail.

1.3.3.3 Understanding the Life Cycle State of SOA Composite Applications

You can administer the entire life cycle state of deployed SOA composite applications from Oracle Enterprise Manager Fusion Middleware Control Console. An application is automatically activated when you deploy it to the SOA Infrastructure. During deployment, you can specify a specific revision number for the application. A revision is a specific deployed version of the application. You can deploy multiple revisions of an application, enabling all to run at the same time.

This is a key benefit of revisions. For example, you may have an older revision of an application running with one customer that is still valid. You then begin a partnership with a different customer that requires a slight modification to the design of the application. At some point, you plan to migrate the old customer to the newer revision of the application, but for now that is not necessary. Revisions enable you to run both applications.

The revision value is added to the application name in Oracle Enterprise Manager Fusion Middleware Control Console. For example, in Figure 1-1, revision 1.0 is the version for many deployed SOA composite applications. If a new request comes in for a specific composite application revision, that composite application revision is invoked. If a new request comes in without specifying a revision, the default revision is invoked. A small green dot distinguishes the default revision from other revisions.

You can perform the following life cycle administration tasks on a SOA composite application from Oracle Enterprise Manager Fusion Middleware Control Console:

  • Create an instance.

  • Stop and restart application revisions. An application revision is typically started instantly after deployment.

  • Retire and activate application revisions. Application revisions are instantly activated upon deployment.

  • Set an application as the default version.

  • Deploy, undeploy, and redeploy application revisions.

  • Delete specific instances of an application revision.

For more information about administering the life cycle states of a SOA composite application, see the following sections:

1.3.3.4 Understanding SOA Composite Application Testing

You can create, deploy, and run test cases that automate the testing of SOA composite applications. Test cases enable you to simulate the interaction between a SOA composite application and its references before deployment in a production environment. Test suites consist of a logical collection of one or more test cases. Each test case contains a set of commands to perform as the test instance is executed. The execution of a test suite is known as a test run. Each test corresponds to a single SOA composite application instance. Instances generated by the execution of these tests are distinguished as test instances by a little yellow box next to their instance ID, as shown in Figure 1-6.

The test suite framework provides the following features:

  • Uses emulations to simulate the behavior of components with which your SOA composite application interacts during execution. Instead of invoking a specific component, you can specify a response from the component.

  • Uses assertions to validate data during process execution.

For information about designing test cases for SOA composite applications, Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.