Soa 11

These eKit materials are to be used ONLY by you for the express purpose SELF STUDY.
SHARING THE FILE IS STRICTLY PROHIBITED.
D73588
Edition 2.0
August 2011
D58786GC20
Student Guide
Concepts
Oracle SOA Suite 11g: Essential
Oracle University and (Oracle Corporation) use only.

Author Copyright © 2011, Oracle and/or it affiliates. All rights reserved.
Iris Li Disclaimer
This document contains proprietary information and is protected by copyright and

These eKit materials are to be used ONLY by you for the express purpose SELF STUDY. SHARING THE FILE IS STRICTLY PROHIBITED.
Technical Contributors other intellectual property laws. You may copy and print this document solely for your
own use in an Oracle training course. The document may not be modified or altered
and Reviewers in any way. Except where your use constitutes "fair use" under copyright law, you
Gary Barg may not use, share, download, upload, copy, print, display, perform, reproduce,
publish, license, post, transmit, or distribute this document in whole or in part without
Pete Daly the express authorization of Oracle.
Joe Greenwald
The information contained in this document is subject to change without notice. If you
David Mills find any problems in the document, please report them in writing to: Oracle University,
500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not
David Shaffer warranted to be error-free.
Madhavi Siddireddy
Restricted Rights Notice
Heidi Buelow

Jeff Davies If this documentation is delivered to the United States Government or anyone using
the documentation on behalf of the United States Government, the following notice is
Ted Witiuk applicable:
Soleiman Pello
U.S. GOVERNMENT RIGHTS
The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or
Editors disclose these training materials are restricted by the terms of the applicable Oracle
license agreement and/or the applicable U.S. Government contract.
Raj Kumar
Trademark Notice
Smita Kommini
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names
may be trademarks of their respective owners.
Graphic Designer
Rajiv Chandrabhanu
Publishers
Revathi Ramamoorthy
Srividya Rameshkumar
Contents
1 Introduction
Goals 1-2
Audience 1-3
Prerequisites 1-4
Class Introductions 1-5

Course Objectives 1-6
Course Schedule 1-7
Course Environment 1-8
How Can I Learn More? 1-9
2 Introducing Service-Oriented Architecture Concepts

Objectives 2-2
Roadmap 2-3
Definition: Service-Oriented Architecture (SOA) 2-4
Services 2-5
Web Services 2-6
SOA and Web Services 2-7
Quiz 2-8
Roadmap 2-9
Enterprise Challenge 2-10
Example of Application-Centric Integration 2-11
A Service-Centric Integration 2-12
Why We Need SOA 2-13
Roadmap 2-15
Adopting SOA 2-16
SOA Implementation Approaches 2-17
Service-Oriented Design 2-18
SOA Governance 2-19
Roadmap 2-20
Standards in SOA 2-21
Composite Applications and SOA 2-22
Service Component Architecture (SCA) 2-24
Comparing SOA and SCA 2-25
Service Component Architecture (SCA) Applications 2-26
Quiz 2-27
iii
Summary 2-28
Practice 2 Overview: Preparing the Business Flow Diagram 2-29
3 Getting Started with Oracle SOA Suite 11g

Objectives 3-2
Organization Roles and Responsibility in a SOA Initiative 3-3
Organization Roles and Responsibility in a SOA Project 3-4
Oracle SOA Platform 3-5
Roadmap 3-7
Key Components of Oracle SOA Composite Application 3-8
Orchestrating Services with BPEL Process Components 3-10

Routing and Filtering with Mediator Components 3-11
Encapsulating Business Logic with Business Rules Components 3-12
Implementing Human Activities with Human Task Components 3-13
Creating Business-Driven Processes with BPMN Service Components 3-14
Spring Service Components 3-15
Adapter Services 3-16
Quiz 3-17
Roadmap 3-18
Oracle SOA Suite 11g Architecture 3-19
Metadata Services (MDS) 3-21
Event-Delivery Network 3-22
Monitoring Services with Oracle BAM 3-23
Quiz 3-24
Roadmap 3-25
Enterprise Integration with Oracle Service Bus 3-26
Oracle Service Bus and Oracle SOA Suite 3-27
Service Portfolios 3-28
Oracle Governance Solution 3-29
Roadmap 3-31
WebLogic Server Domain 3-32
WebLogic Domain Configuration for Oracle SOA Suite 3-33
Roadmap 3-35
Introducing Oracle SOA Suite Management Tools 3-36
Oracle Enterprise Manager Fusion Middleware Control 3-38
Initiating Composite Application Instances 3-41
Initiating a Test in Enterprise Manager 3-42
Tracking Message Flow 3-43
Working with a Component Audit Trail Page 3-45
Summary 3-46
Practice 3 Overview: Initiating a SOA Composite Instance 3-47
iv
4 Building SOA Composite Applications
Objectives 4-2
Roadmap 4-3
What Are Services? 4-4
Basics of XML 4-5
XML Concepts 4-7
Web Services Description Language (WSDL) 4-9
WSDL Model 4-10
An Example of WSDL Document 4-11
Defining Service Interfaces with WSDL 4-13
Defining Service Interfaces in WSDL Editor 4-14

Defining Message Structure with XML Schema 4-15
Defining Message Structure in XSD Editor 4-16
Quiz 4-17
Roadmap 4-18
Types of Service Access and Implementation 4-19
Service Design Principles 4-20
Designing Coarse-Grained Interfaces 4-22
Roadmap 4-23
Service Component Architecture (SCA) 4-24
Elements of an SCA 4-25
Components and Composites 4-27
SCA Components 4-28
SCA Composite 4-29
SCA Bindings 4-30
SCA Policy Framework 4-31
Roadmap 4-32
Understanding Binding Components 4-33
Overview of Adapter Services 4-34
Oracle Technology Adapters 4-36
Packaged Application and Legacy Adapters 4-38
Quiz 4-39
Roadmap 4-40
Service Data Objects (SDO) 4-41
SDO Data Architecture 4-42
SCA and SDO 4-43
Roadmap 4-44
Developing SOA Composites with JDeveloper 4-45
Creating Connections in JDeveloper 4-46
SOA Composite Editor 4-48
Creating SOA Components 4-50
v
Creating Exposed Services 4-51
Creating External References 4-52
Creating Wires 4-53

Creating Wires Modifies Connected Elements 4-54
Examining the JDeveloper Workspace, Projects, and File Structure 4-55
Course Practice Scenario: Purchase Order Processing 4-56
Summary 4-57
Practice 4 Overview: Examining the Composite Application in JDeveloper 4-58
5 Orchestrating Services with BPEL Process Components

Objectives 5-2

Roadmap 5-3
Process Orchestration Concepts 5-4
What Is BPEL? 5-5
BPEL Process Features 5-6
Synchronous Services 5-8
Asynchronous Services 5-9
Main Usage Patterns for BPEL Components 5-10
Quiz 5-11
Roadmap 5-12
Basic Programming Constructs of a BPEL Process 5-13
XML Structure of a BPEL Process 5-14
BPEL Partner 5-15
Classification of BPEL Activity Types 5-16
Exploring BPEL Process in JDeveloper 5-18
Constructing a BPEL Process in BPEL Process Editor 5-20
Grouping Activities by Using a BPEL Scope 5-21
Roadmap 5-22
Communicating Data with a BPEL Process 5-23
BPEL Variables 5-24
Assigning or Copying Data to Variables 5-26
Transforming Data in a BPEL Process 5-28
The Assign Activity 5-29
Creating Expressions with the XPath Expression Builder 5-30
Quiz 5-32
Roadmap 5-33
Developing a BPEL Process 5-34
BPEL Process Templates 5-35
Synchronous Process Structure: HelloWorld Example 5-37
Asynchronous BPEL Process Structure 5-38
Summary 5-39
vi
Practice 5 Overview: Implementing a BPEL Process 5-40
6 Mediating Messages with Mediator Components

Objectives 6-2
Roadmap 6-3
Introducing Mediator Components 6-4
How Mediator Is Used in a Composite 6-5
Features of Mediator Components 6-6
Routing Rules 6-7
Content-Based and Header-Based Routing 6-8
Synchronous and Asynchronous Interactions 6-9

Transformations 6-10
Validations 6-11
Error Management 6-12
Event Handling 6-13
Mediating Services and Events 6-14
Service Virtualization 6-15
Quiz 6-16
Roadmap 6-17
Best Practices of Using Mediator 6-18
Comparing BPEL and Mediator 6-19
Quiz 6-20
Roadmap 6-21
Mediator Component Creation Options 6-22
Effects of Creating a Mediator Component 6-23
Editing a Mediator Component 6-24
Types of Mediator Routing Rules 6-25
Configuring Routing Rules 6-27
Specifying a Target Service 6-28
When to Invoke a Service and When to Use Business Events 6-29
Configuring Message Filters 6-30
Configuring Transformations 6-31
Specifying Sequential or Parallel Execution 6-32
Configuring Validation 6-33
Handling Synchronous and Asynchronous Responses and Faults 6-34
Summary 6-35
Practice 6 Overview: Creating a Mediator Service Component 6-36
vii
7 Encapsulating Business Logic with Business Rules Components
Objectives 7-2
Roadmap 7-3
Introducing Business Rules 7-4
Declarative Rule Concepts 7-5
Reasons for Using Business Rules 7-6
Guidelines for Using Business Rules 7-7
Roadmap 7-8
Artifacts of Business Rules 7-9
Defining a Ruleset 7-11
Example of a Ruleset Containing IF-THEN Rules 7-12

Example of a Ruleset Containing a Decision Table 7-13
Working with Decision Functions 7-14
Quiz 7-15
Roadmap 7-16
Business Rules Service Components in SOA Composite 7-17
Main Usage Patterns for Business Rules Service Components 7-18
Integrating the Business Rule Service Component in the BPEL Process 7-19
Quiz 7-20
Roadmap 7-21
Introducing SOA Composer 7-22
Editing Business Rules in SOA Composer 7-23
Summary 7-24
Practice 7 Overview: Implementing a Business Rule 7-25
8 Implementing Human Activities with Human Task Components

Objectives 8-2
Roadmap 8-3
Introducing the Human Task Service 8-4
Human Task Service in a Composite Application 8-5
Human Task Features 8-6
Quiz 8-7
Roadmap 8-8
Human Workflow Architecture 8-9
Identity Service 8-11
Notification Service 8-12
Worklist Application and Task Display Forms 8-13
Viewing and Acting on a Task in Oracle BPM Worklist 8-14
Quiz 8-16
Roadmap 8-17
Creating a Human Task Service Component in JDeveloper 8-18
viii
Defining Human Tasks 8-19
Configuring Task Parameters 8-20
Roadmap 8-21
Integrating the Human Task Component in the BPEL Process 8-22
Inspecting the Human Task Scope Activity 8-23
Processing the Task Outcomes 8-24
Summary 8-25
Practice 8 Overview: Working with Human Task Components 8-26
9 Creating Business-Driven Processes with BPMN

Objectives 9-2

Roadmap 9-3
Definition: Business Process 9-4
SOA Approach to Business Process Optimization and Automation 9-5
Business Process Modeling Notation (BPMN) 9-7
Relationship Between BPMN and BPEL 9-9
Modeling Processes by Using BPMN 9-10
Sample BPMN Process Model 9-12
Quiz 9-13
Roadmap 9-14
BPM Life Cycle 9-15
Oracle Tools Facilitate BPM 9-17
Three Modeling Tools 9-18
Oracle BPM Suite 9-19
Modeling with Business Process Composer 9-20
Modeling and Implementing with BPM Studio 9-21
Modeling and Implementation: An Iterative Process 9-22
Modeling, Simulating, and Implementing Using BPM Studio 9-23
Modeling in Business Process Composer; Simulating and Implementing in
BPM Studio 9-24
BPM Metadata Service (MDS) Repository 9-26
Oracle BPM Run Time 9-27
Business Process Workspace 9-29
Quiz 9-30
Roadmap 9-31
Modeling a Process in Oracle Business Process Composer 9-32
Editing a Process in BPM Studio 9-33
Configuring a Connection to MDS Repository 9-34
Checking Out the Project by Using BPM MDS Navigator 9-35
Accessing Project Components in BPM Project Navigator 9-36
Editing the Process in BPMN Process Editor 9-37
ix
Implementing the Process 9-38
Summary 9-39
Practice 9 Overview: Modeling and Editing a BPM Process 9-40
10 Managing and Monitoring Composite Applications

Objectives 10-2
Roadmap 10-3
Roles and Tasks in Composite Applications Management 10-4
Overview of Managing SOA Applications 10-5
Roadmap 10-6
Packaging a Composite Application 10-7

Deploying a Composite Application 10-8
Deploying Through Oracle Enterprise Manager Console 10-9
SOA Composite Applications Versioning 10-10
Managing Composite Application State 10-11
Testing a Composite Application 10-12
Quiz 10-13
Roadmap 10-14
Monitoring Composite Instances 10-15
Tracking Message Flow Trace 10-16
Monitoring Service Component Instance Statistics 10-17
Monitoring SOA Composite Application Performance 10-18
Roadmap 10-19
Exception Handling in Composite Execution 10-20
Recovering a Faulted Instance 10-21
Quiz 10-22
Summary 10-23
Practice 10 Overview: Managing SOA Composite Applications 10-24
11 Enterprise Integration Using Oracle Service Bus

Objectives 11-2
Roadmap 11-3
Introduction to Enterprise Service Bus 11-4
Enterprise Service Bus Capabilities 11-5
Enterprise Service Bus Technologies 11-7
Quiz 11-8
Roadmap 11-9
Introducing Oracle Service Bus 11-10
SOA Service Infrastructure and OSB 11-11
Comparing Mediator and Oracle Service Bus 11-12
OSB and SOA Suite Product Architecture 11-13
x
Roadmap 11-14
Inside Oracle Service Bus 11-15
Example of Virtualizing Service 11-16

OSB as a Message Broker 11-17
Processing Messages 11-19
Dynamic Routing 11-20
Transformations 11-21
Service Composition 11-22
Message Enrichment 11-23
Service-Level Agreements 11-24
Security 11-25

Quiz 11-26
Roadmap 11-27
OSB Console 11-28
Creating and Configuring Services Using OSB Console 11-30
Demo Overview: Creating a CCValidation Service in OSB Console 11-31
Summary 11-32
12 Exploring SOA Governance

Objectives 12-2
Roadmap 12-3
SOA Challenges 12-4
Defining SOA Governance 12-5
Governance Objectives 12-6
Governance Roles 12-7
Roadmap 12-8
Enterprise Assets 12-9
Assets to Support Design and Development 12-10
Assets to Support Run Time 12-11
Asset Harvesting 12-12
Roadmap 12-13
Managing Shared SOA Assets 12-14
Oracle Metadata Service (MDS) 12-15
Connecting JDeveloper to MDS Repository 12-16
Oracle Governance Solution 12-17
Project-Level Governance Leveraging OER 12-19
Integrating with SOA Suite and OSB 12-20
Quiz 12-21
Demo Overview: Connecting and Exploring MDS Repository 12-22
Summary 12-23
xi

Introduction
Copyright © 2011, Oracle and/or its affiliates. All rights reserved.

Goals
The main goal of this course is to:

• Get familiar with the key concepts of SOA
• Understand how SOA composite applications are
implemented in Oracle SOA Suite 11g

Goals
After completion of the course, you have the basic information and technical understanding of
the SOA concepts, SOA implementation, and how SOA helps to solve the business and IT
challenges in your organization.
Oracle SOA Suite 11g: Essential Concepts 1 - 2

Audience
The target audience includes:

• Application architect
• Business analyst
• IT Manager
• SOA project manager

• Any technical personnel who are interested in using the
SOA platform
Audience
This course is primarily targeted at the application architect, business analyst, IT manager
and SOA project manager. In addition, technical personnel who are interested in using the
SOA platform will find this course useful for explaining basic concepts and introducing the
Oracle SOA product suite. SOA administrators and developers who are new to the product
set can also benefit from this course; it explains basic SOA concepts and introduces the SOA
product set. However, it does not teach how to develop production-level composite
applications nor how to administer SOA deployments.

Prerequisites
To successfully complete this course, you should meet the

following requirements:
• Oracle University course: Oracle 10g: XML Fundamentals
or later version of the course or equivalent knowledge on
XML. This is to help understand XML documents, XPath,
XML schema, and XML Namespace principles.

• Understanding of Web Service concepts such as WSDL,
SOAP, and UDDI or equivalent
Prerequisites
Students who have some knowledge of the concepts listed in the slide will benefit from most
of the course’s content.

Class Introductions
Briefly introduce yourself:

• Name
• Title/position
• Company
• XML and web services knowledge

• Reasons for attending

Course Objectives
After completing this course, you should be able to:

• Describe the business and technical challenges when adopting
SOA in your organization
• Evaluate the Oracle SOA Suite for use in your organization
• Explain SOA concepts
• Describe the SOA approach for integrating business services

• Describes the functionality and features of core service
components in Oracle SOA Suite 11g
• Explain the context of using each core service component, and
business challenges they address
• Explore a SOA composite application in JDeveloper
• Explain how Oracle Service Bus mediates between services
• Describe the role of SOA governance in a SOA project, and
high-level approaches

Course Schedule
Session Module
1: Introduction
A.M.
Day 2: Introducing Service-Oriented Architecture Concepts
1 3: Getting Started with Oracle SOA Suite 11g
P.M.
4: Building SOA Composite Applications
5: Orchestrating Services with BPEL Process Components
A.M.
Day

6: Mediating Messages with Mediator Components
2 7: Encapsulating Business Logic with Business Rules Components
P.M.
8: Implementing Human Activities with Human Task Components
9: Creating Business-Driven Processes with BPMN Components
A.M.
Day 10: Managing, Monitoring, and Securing Composite Applications
3 11: Enterprise Integration Using Oracle Service Bus
P.M.
12: Exploring SOA Governance

Course Environment
Classroom PC
Web Browser Oracle WebLogic Server Domain

Oracle SOA Suite 11g
(SOA and BPM)
Enterprise Managed Server

Manager Admin Server soa_server1 [8001]
Console
WebLogic [7001]
Console Managed Server
bam_server1 [9001]
SOA Suite 11g

schemas
Oracle Database 10g XE

How Can I Learn More?
Topic Website
Education and Training http://education.oracle.com
Product Documentation http://www.oracle.com/technology/documentation
Product Downloads http://www.oracle.com/technology/software
Product Articles http://www.oracle.com/technology/pub/articles
Product Support http://www.oracle.com/support

Product Forums http://forums.oracle.com
Product Tutorials http://www.otn.oracle.com/obe
Sample Code http://www.samplecode.oracle.com/


Concepts

Introducing Service-Oriented Architecture

Objectives
After completing this lesson, you should be able to:

• Define Service-Oriented Architecture (SOA)
• Explain why we need SOA
• Describe the changes in the development approach,
required by SOA
• Identify the standards and technologies that enable SOA


Roadmap
• What is SOA?
• Why we need SOA
• How to adopt SOA
• Technical introduction to SOA


Definition: Service-Oriented Architecture (SOA)
Service-Oriented Architecture is an IT strategy that organizes

the discrete functions contained in enterprise applications into
interoperable, standards-based services that can be combined
and reused quickly to meet business needs.

IT
Business
Strategy SOA Strategy
Definition: Services-Oriented Architecture (SOA)

In computing terms, SOA provides methods for systems development and integration where
systems group functionality around business processes and package these as interoperable
services. A SOA infrastructure allows different applications to exchange data with one another
as they participate in business processes.
SOA is a system integration process, based on using services developed according to
standards that make the process integration easier. The idea of SOA does not prescribe a
specific technological implementation. However, industry has embraced the standards,
flexibility, and reusability of Web Service–style technology implementations.
A SOA approach provides guidelines around structuring software systems, based on the idea
of a service as the building block. Services provide discrete, decoupled business functionality
to be assembled and reused to create applications that support changing business processes.
SOA enables:
• A consumer of the service to be decoupled from the service provided (producer)
• A business process to be decomposed into discrete, reusable functional components (or
services)
The graphic depicts SOA that enables IT and business alignment.

Services
• Services are:
– IT’s representation of business functionality
– Described by a well-defined interface
– Abstracted from the implementation
– Accessed using standard protocols (the glue) to enable
interoperability from decoupled functions

• Services are SOA building blocks.
Interactions
Client Service A Service B
Services
A service is a piece of self-contained business functionality. The functionality could be as
simple as storing customer data, or as complex as processing a customer’s order. Services
form the basic building block for a SOA implementation. They perform work based on
business interactions and requirements. Because services concentrate on the business value
of an interface, they bridge the business/IT gap. Services interact by exchanging messages
with other clients and other services.
Service functionality must be described by using standard interface and message structures
to make them highly accessible and reusable. Although the IT industry has created many
ways to do this, each of which is a viable means to accomplish a SOA approach, the most
widely embraced are the Web services standards.
Services are SOA building blocks. SOA applications can be thought of as functionality that
aggregates a collection of related services, by reusing other services to complete automation
of a business process.
Independence is a fundamental aspect of services and SOA as a whole. Service loose
coupling frees a service from immediate ties to others. This makes it much easier to realize
reuse. In addition, when there are fewer dependencies, modification to, or faults in, one
system will have fewer effects on other systems.

Web Services
Web services:
• Provide a simple and interoperable messaging framework
• Rely on common standards that include:
– SOAP: A standard format for messaging over a network
– Web Service Description Language (WSDL): The language
that provides a description for Web services

– Universal Description, Discovery, and Integration (UDDI): A
web-based distributed directory to publish and locate
information about Web services
• Include additional specifications (WS-*) to define
functionality for Web services discovery, security,
reliability, transactions, and management
Web Services
Using a service-oriented design approach does not require Web services; however, as
previously mentioned, Web services is the most common way to implement SOA. Web
services are based on a core set of communication standards:
• SOAP (to communicate) defines an XML-based structure for passing information, such
as messages and data, between Web services and applications.
• WSDL (to describe) is an XML-based language for modeling Web services. A WSDL
document describes the service interface, message format, and the service instance
location.
• UDDI (to advertise and syndicate) allows organizations to register their Web services in
a uniform manner within a directory, so clients can locate their Web services and learn
how to access them.
The benefit of using Web Services artifacts such as WSDL and XSD is that they are
“accepted standards.” These XML document structures are easily exchanged using the
standard Internet (Web Services) protocols such as Hypertext Transfer Protocol (HTTP)
among others.
SOAP, WSDL , and UDDI are standards at the core of Web services, and they are followed
by many additional specifications that define reliability, security, metadata management,
transactions to meet requirements for enterprise features and qualities of service. These
specifications are collectively referred to as the WS-*.

SOA and Web Services
SOA is an architectural approach to composition and

integration.
Web services is the most common way to implement SOA.
They:
• Address the low-level interactions between services
• Help up to a certain level of complexity in the infrastructure

SOA and Web Services

SOA is not a single technology. It is an approach to software design that involves assembling
systems from reusable components or services that may have originated from different
sources and underlying technology environments. SOA focuses on loosely coupled services,
automated end-to-end business processes, and reusing existing IT systems resources based
on open standards. At this level, SOA is often associated with Web services. However, Web
services only address the low-level interactions between services. They don’t address the
architectural and design philosophy. SOA is about much more than just Web services. Most
SOA is implemented by applying service-orientation principles to Web services technology.
We can think of SOA as an approach to service integration or, at a higher business level, an
approach to application or system integration across organizational boundaries. Web services
are essential, like building blocks that can be used (or reused) to enable a SOA application to
be created to meet some business requirements.
From a broader IT perspective, SOA suggests fundamental shifts in how the organization
implements business systems with attendant changes in technology, methodology, and
organizational structure.
Note: Web services are but one of the possible building blocks. An organization could build
out an entire SOA using, for example, Representational State Transfer (REST) services. Or,
they may mix Web services and RESTful services, using each where appropriate.

Quiz
Which of the following form the basic building block for a SOA
implementation?
a. Composite applications
b. Services
c. Business processes
d. Data

Answer: b
A service is a piece of self-contained business functionality. Services can be reused and
combined to create applications and made available throughout an organization.

Roadmap
• What is SOA?
• Why we need SOA


Enterprise Challenge
• Application development and integration issues

– Lack of flexibility
– Not standards-based
– Project costs and long duration
• Traditional methodologies
– Point-to-point

– Enterprise Application Integration
Enterprise Challenge
Enterprises use many different custom-built and off-the-shelf packaged applications to run
their business processes. Applications are integrated to share information among themselves
and to incorporate information from existing applications. Traditional application development
and integration approaches have neither been flexible nor standards-based to facilitate an
agile enterprise IT environment.
In large enterprises, application development means interacting with business data from one
or more sources or other applications. Application integration could not be implemented
without application development tasks that included developing, assembling, and connecting
components to back-end systems, process flow and workflow implementation, user interface
development, testing, and debugging.
Two of the most common application integration methodologies were:
• Point-to-point integration methodologies using APIs, proprietary messages, and custom
integration links
• Enterprise Application Integration (EAI) based on message bus (message bus
specializes in transporting messages between applications) or middleware

Example of Application-Centric Integration
Web-based Banking Application

Apply for new credit card Apply for new mortgage loan
Verify Customer
Check Customer Address
Credit Card
Set up
Conduct Account

Set up Fraud
Account Check
Marketing Sales and Risk Corporate Business

System Acquisition System System Unit
Example of Application-Centric Integration

Because of the Internet boom and the need for quick software, so much proprietary software
has been developed that it’s becoming hard and costly to manage and maintain this software
over time.
The slide shows a web-based Banking Application using point-to-point integration. Here, in
order to process a new credit card:
• Each application takes care of a particular functionality, such as conducting verification
of customer background, which results in tight coupling of the application
• Applications such as Risk System, Business Unit, and so on use individual lines of
communication, resulting in a complex architecture
To integrate, you need to do the plumbing yourself and search for dependencies within these
different siloed applications. In addition, the lack of agility and usage of customer integration
links results in inflexibility.

A Service-Centric Integration
Application-centric integration Service-centric integration

Web based Banking Application Web Phone Branch Systems Trading Partners
Apply for new credit card Apply for new mortgage loan
Check Customer
Verify Customer
Address
Channels
Credit Card Setup
Conduct Account
Setup
Account
Fraud
Check
Web UI / Portals / Portlets
Presentation Service Layer
Service

Marketing Sales and Risk Corporate Business
System Acquisition System System Unit Bus
Business Process Layer (BPM, Workflow) Mediation
Check Verify Customer Setup Conduct Fraud

Credit Card Address Account Check
Business Service
Integration Tier (Connectivity Service)

SOA
Assets/Systems Governance
A Service-Centric Integration
SOA gives you the ability to integrate services without the hassle of doing the plumbing
yourself and without needing to search for dependencies within these different siloed
applications.
The slide depicts how a web-based banking application using point-to point integration can be
migrated to service-centric integration by using Service-Oriented Architecture (SOA).
Here, each of the business functionalities has been mapped to the appropriate service layer.
For example:
• The Connectivity Service layer provides the functionality to connect to the various
systems/assets.
• The Business Service layer includes the different business functionalities such as
Checking Credit Card, Verifying Customer Address, Conducting Fraud Check, and so
on.
• The Business Process layer includes the nuances related to business workflow.
• The Presentation Service layer provides the user interface–related services.
The service-centric integration approach provides a shared service and infrastructure platform
that encourages reusability and flexibility.

Why We Need SOA
The SOA approach to software systems structured around the

concept of services enables:
• A consumer of the service to be decoupled from the
service provided (producer)
• A business process to be decomposed into discrete,
reusable functional components (or services)

• The following benefits:
– Improved business agility
— Align IT with the business.
— Remove barriers between business units and business partners.
– Lower cost of maintaining IT systems
— Speed up delivery of applications to meet business demands.
— Protect IT investments by reusing the existing infrastructure.
Why We Need SOA

A SOA approach provides guidelines around structuring software systems, based on the idea
of a service as the building block. Services provide discrete, decoupled business functionality
to be assembled and reused to create applications that support changing business processes.
Aligning IT with discrete business functions can result in rapid development and more reliable
delivery of business services. Other benefits of SOA are:
• Reusability: Existing business functionality in an application can be reused to meet new
business requirements. One of the goals of a SOA approach is to design new services
with reusability in mind as determined by its usage patterns within and outside the
business domain. However, not all services, such as a large-grained application, are
required to be reusable, nor should they be, depending on the business requirements.
• Interoperability: Communication between services and the business process is not
dependent on the platform and is standards-enabled. The services are not tightly
coupled to the application.

• Scalability: Because services in a SOA are loosely coupled, applications that use these
services tend to scale easily; certainly more easily than applications in a more tightly
coupled environment. That is because there are few dependencies between the
requesting applications and the services they use, which typically make them more
flexible than more tightly coupled applications.

• Cost efficiency: This is highly cost-efficient because integrating the business resources
is standards-based.

Roadmap
• What is SOA?
• Why we need SOA


Adopting SOA
When embarking on a SOA project, we need to:

• Focus on content, not technology
• Take an approach that merges top-down and bottom-up
approaches
• Design everything from a service perspective
• Change the way we manage software life cycle

– Requires support from various levels in the organization
– Needs proper governance
Adopting SOA
SOA is not a middleware product or an IT-only initiative, it’s about facilitating business. When
designing systems with a SOA-style implementation, the focus is always to align IT resources
with business goals and requirements. This is because businesses redefine and change their
processes as needed to deal with changes in their industries. Therefore, IT must be agile
enough to change as the business requires.
You also need to design everything from a service perspective. Service is the major construct
for publishing and should be used at the point of each significant interface.
The SOA approach also has big implications for how you manage the software life cycle; right
from business requirements’ specification for services to the design of services, development
of services, asset management of services, and so on.
Adopting SOA in an organization is a serious challenge that will require major efforts at
various levels, from business to IT infrastructure. Critical to the success of SOA adoption are
sometimes intangible elements, including mindset, collaboration across departments and
lines of business, communication, and business analysis—in terms of interfaces and
contracts—with focus on reuse and loose coupling and the implementation of proper
governance.

SOA Implementation Approaches
Three approaches are commonly pursued for implementing

SOA:
• Top-down: Business-centric approach
• Bottom-up: Technical-centric approach
• Middle-out: Merges top-down and bottom-up appraches

SOA Implementation Approaches

The top-down approach starts with the enterprise looking at business requirements and
processes, and then drilling down into the actual implementation, the underlying technical
services that must be provided by its systems. This approach refers to the business-centric
domain, which focuses on solving business problems and flexibly creating and delivering
solutions. This approach demands more of an initial investment. The analysis phase is quite
lengthy. By the time the project is complete, the solution no longer maps to business needs.
The bottom-up approach refers to the technical-centric domain, which is usually engineer-
driven. It focuses on common code parts, sharing components, and best-of-breed
development practices. The SOA is built for the sake of SOA, without reference to the
business context. The result is an implementation without organizing principles and guidance
that has no business relevance.
Both top-down and bottom-up approaches have possible pitfalls that can prevent success. So
for SOA implementation, an approach that merges top-down and bottom-up may be best. This
approach is called middle-out, also known as meet-in-the-middle, which starts with a focused
understanding of business problems, enables organizations to align their IT assets with
changing business needs, and to deliver on business goals one need at a time.

Service-Oriented Design
Services in SOA should:

• Provide business value
• Hide implementation details
• Be autonomous
When designing services, you:

• Start with the service interface (contract)
• Then select choice of service implementation
– Java Web Services and J2CA Adapters
– BPEL
– SCA composite applications
– .NET, among others
Service-Oriented Design
Services in SOA must provide business value. This differs considerably from technology-
oriented functionalities such as retrieving data from a table in a database.
When designing a service, the service should be evaluated in terms of its role in the business
and how it can be reused (if at all) subject to changes in the business requirements.
Note: Some services, by their nature, may not be reusable and would have to be maintained
and changed to stay aligned with the business requirements.
Service design begins with the service interface, and proceeds with the consumer and reuse
in mind. Service interface is a contract between the service provider and the service
consumer. When completed, the service design and interface represent the outputs from the
process.
Service design differs significantly from traditional application design. The focus is not on how
the service is constructed, but how the consumers access and interact with the service. The
implementation behind a service may change several times without impacting the service
design, which is highly unlikely in the case of an application. When a service design is
changed, the impacts are typically significantly larger than in the application case.

SOA Governance
SOA governance is the process of:

• Setting a desired outcome for your efforts
• Leveraging people, policies, and processes to make that
outcome a reality
Governance cannot be solved by technology alone.

People Process
Technology
Service
SOA Governance
SOA governance is the key to a successful adoption of SOA. Governance is about ensuring
that business is conducted properly. It is less about control and strict adherence to rules, and
more about guidance and the effective and equitable use of resources to ensure sustainability
of an organization’s strategic objectives. Governance is a process that is influenced through
organizational behavior and the establishment of structured processes. Technology is there to
help automate the governance process as much as possible. That is, it is a framework for
managing SOA assets in compliance with a company’s standards, policies, and business
strategies specifically focused on the life cycle of services, policies, practices, metadata, and
composite applications.
The implementation of any type of governance should be centered on the four pillars of an
enterprise architecture: people, processes, technology, and services.
One mechanism to implement enterprise IT and SOA governance is by enabling a shared
resource and capability center to function as a resource pool as new business application
needs arise. A governance implementation also needs to be supported by a hierarchical
organizational reporting structure.

Roadmap
• What is SOA?
• Why we need SOA


Standards in SOA
Current and Emerging Standards Category

Assembly
Service Component Architecture (SCA)
model
Business
Orchestration: BPEL4WS
processes
Service Data Objects (SDO) Data access
Quality of

Management WS-ReliableMessaging WS-Security
WS-Policy service
WS-Security UDDI Discovery
WSDL Description
SOAP
Message
XML
HTTP(S), IIOP, JMS, SMTP Transport
Standards in SOA
SOA is a form of software integration based on standards, where the application
implementation is exposed as a service.
This graphic illustrates the many existing W3C standards and emerging specifications (SCA
and SDO) that work together to build on simple, stand-alone standards (such as XML and
XPath) to enable a SOA approach, that is, using the Web service foundations of SOAP, Web
Services Description Language (WSDL), and Universal Description, Discovery, and
Integration (UDDI). The notion of Service-Oriented Architecture is elevated to a higher level
through message orchestration and process integration, and more recently with the Service
Component Architecture that enables the assembly of components to create a composite
service.
Note: A key benefit of using the standards on which a SOA implementation is based is
independence of hardware and operating systems used to implement the service functionality.

Composite Applications and SOA
A composite application is:

• An implementation of business functionality that manages
information flow between varied information sources
• An end-product of a SOA implementation approach
• A coarsely grained service designed for a specific
business purpose that may be decomposed into (finer-

grained) shared services
Composite Applications and SOA

A composite application is a software implementation of business functionality that manages
the flow of information between varied information sources. A composite application is
designed to support a company’s business processes and map them to underlying
information resources, which could include databases and Enterprise Information Systems
(EIS), among other sources of functionality. Composite applications are the end-products of a
SOA implementation strategy. Whether the composite application is designed for internal or
external use, it represents how a company can map business needs and processes to
information assets by using SOA principles.
A composite application is a service that may be composed of one or more components that
may utilize other shared services. A composite application represents a coarsely grained
service, which may need to be decomposed into smaller (finely grained) reusable shared
services. Consumers of a composite application are other applications that require the
functionality implemented by the composite application. Common examples of service
decomposition include:
• Business Process Management (BPM) processes, which are decomposed into business
activities that may be developed as shared services

• Enterprise portals, which are composed of existing shared portlets (Presentation
Services). Each portlet may request and obtain data from composite applications (or
other services) for presentation.
As a type of coarsely grained service, the SOA composite application’s functionality can be
exposed as a service through service entry points.

Note: The granularity of the service’s functional scope, as determined by its functional
context, is referred to as service granularity. A coarse-grained service usually has a broad
functional context. More of service granularity is discussed in Lesson 4 titled “Building SOA
Composite Applications”.

Service Component Architecture is a set of specifications that:

• Defines an assembly model for a composite service
• Provides a programming model for building applications
and systems based on the SOA approach
• Extends and complements existing approaches to
implementing services

• Builds on Web services and other open standards
Composite
application
Assembly model

The SCA specifications provide a programming model for building applications and systems
based on a SOA approach. SCA is based on the concept that a business function is provided
as a series of services. The service components are assembled together to form a composite
application that creates a solution that addresses a specific business requirement. These
composite applications may contain new services (specifically for the application) and
business functions from existing systems and applications (reused within composition). SCA
provides a model for both:
• The composition of services
• The creation of service components, including reuse of existing application functions
Remember, SOA is an idea representing how one approaches implementing service-oriented
applications. SCA provides SOA-style implementations with a way to assemble service
components into a complete application, called a composite application.
The graphic depicts how service components can be assembled into a composite application.

Comparing SOA and SCA
• SOA is:
– An architectural style enabled by standards
– A definition of an architecture for integrating loosely coupled
services
• SCA is:
– An assembly model described by a set of specifications that

define how to compose applications from components
– A definition of a design and deployment model for composite
services
SOA is an architectural style or approach.
SCA is an assembly model for SOA-style applications.
Note: SCA does not provide portability of composite applications
between SCA containers.
Comparing SOA and SCA

The promise of SCA is that developers can use various languages running on different
runtime engines to implement various parts of the application, for example, BPEL, Java,
another SCA composite application, a rule engine, a workflow engine, and technology
adapters to work with databases, queues, and file systems. Each such part of the application
is called a (service) component.
Each service component publishes a contract that describes its interface through a WSDL
document. The developers specify the functional link between these different parts of the
application, and it is up to the SCA container or runtime engine to facilitate communication
between the components in the most efficient way, usually through a native, binary
communication protocol.
Note: Though SCA is a widely accepted industry standard, it does not provide portability of
composite applications between SCA containers.

Applications
An SCA application, also known as SOA composite application,

is a reusable functional unit that is:
• Composed of several cooperating service components to
meet a business process requirement
• Deployed as a single composite application, including the
component implementations

Service Component Architecture (SCA) Applications

Service Component Architecture (SCA) is a set of specifications that prescribes the approach
for assembling SOA composite applications (also known as the SCA Composite/Application
or SOA Composite) from service components. The composite applications provide meaningful
business functionality. The service components are pieces of business logic that are used as
building blocks when composite applications are assembled. An SCA Composite may contain
one or more cooperating component types such as BPEL process service components,
Mediator components, and so on.
The SCA Composite is developed and deployed as a single service that includes all the
components it assembles to form the application implementation. Components cannot exist
on their own, or at least not in the SCA runtime environment. They need to be part of a
service composite (application) because that is the unit of deployment and execution. When
assembled together into a composite application, they are managed, maintained, and
deployed together.

Quiz
Service Component Architecture (SCA) defines a common

assembly mechanism to specify how components are
combined into applications.
a. True
b. False

Answer: a
Explanation: The SCA specifications define an assembly model for building composite
applications based on the SOA approach. The composite applications may contain new
services and business functions from existing systems and applications (reused within
composition).

Summary
In this lesson, you should have learned how to:

• Define Service-Oriented Architecture (SOA)
• Explain why we need SOA
• Describe the changes in the development approach,
required by SOA
• Identify the standards and technologies that enable SOA


Practice 2 Overview:
Preparing the Business Flow Diagram
This practice covers designing a business flow diagram for

purchase order processing.

Practice 2 Overview: Preparing the Business Flow Diagram

In this practice, you will fill the missing parts of a purchase order processing business process
workflow diagram. The subsequent labs are based on this purchase order use case.



Getting Started with Oracle SOA Suite 11g

Objectives
After completing this lesson, you should be able to:

• Describe the core service components of Oracle SOA
Suite 11g
• Describe Oracle SOA Suite 11g architecture and key
features
• Explain how Oracle SOA Suite interacts with other

products, Oracle Service Bus (OSB), and SOA
Governance Suite
• Describe WebLogic domain configuration for Oracle SOA
Suite
• Get familiar with management tools of Oracle SOA Suite
11g
Objectives
This lesson discuss the Oracle product portfolio for implementing SOA.

Organization Roles and Responsibility in
a SOA Initiative
Integration Specialists
Security Specialists
Business & Business Solution Technical Service

Analysts & Architect & Architect & Developers
IT leadership
Domain Service Technical
Experts Designers Designers
Tasks: Tasks: Tasks: Tasks: Tasks:

• Review and • Validate and • Deliver business • Decide standards, • Develop
approve business select the value of SOA. technology, components that

initiatives, plans, business • Design the platform & product. form part of an
roadmap, budgets. services. structure of the • Design the overall service.
• Develop initial • Justify the overall solution & technical process • Design smaller
vision, strategy, service existence. its components. flows that support subcomponents
governance • Analyze and • Oversee service given business within a given
model. model an landscape. processes. technology.
• Lead the initial enterprise. • Design services.
services rollout &
promote ongoing
SOA efforts.
Oracle SOA • BPM Studio • JDeveloper JDeveloper JDeveloper- SOA

Governance • Process • Oracle SOA Composite editor
Composer Governance
Organization Roles and Responsibility in a SOA Initiative

Oracle has a comprehensive SOA offering that provides developers, architects, and IT
professionals with the tools, technologies, framework, and guidance for building and
maintaining SOA solutions.
Let’s explore a potential set of roles in a SOA initiative. SOA projects involve many familiar
project roles: CIO, IT manager, business analyst, architect, developer, security specialist,
integration specialist, and system administrator. These roles were created for different
purposes and might have different inherent meanings based on the organization’s viewpoint.
Note that the tasks and potential roles shown in the diagram can be mapped to an
organization’s existing roles, and sometimes there’s a need to introduce new ones in your
SOA initiative.

Organization Roles and Responsibility in
a SOA Project
System Business Business

Admin & End Users Owner
Service
Deployer
Tasks: Tasks: Tasks:

• Build technical • Use the SOA • Use business
infrastructure. application. dashboards and
• Provide ongoing • Participate in historical data to
maintenance. process flow. monitor and
analyze business
• Install service into

trend.
the runtime
environment.
• Complete
technical deploy
plans.
EM
BPM Worklist BAM
/WLS Admin
Console

Oracle SOA Platform
MANAGE PATTERN BUSINESS

DESIGN SECURE MONITOR DETECTION VISIBILITY
POLICY
JDEV MANAGER EM CEP BAM
BPEL PROCESS MGR

BUSINESS RULES

HUMAN WORKFLOW
REPOSITORY
SERVICE BUS
DATA INTEGRATOR
ERP MAINFRAME SERVICES DB PARTNERS EVENTS
Adapters & B2B
Oracle SOA Platform

This graphic depicts the Oracle SOA platform. It shows the different layers, with the core SOA
components shown in red in the middle, and various SOA products shown at the top.
Regardless of whether you’re taking a bottom-up or top-down approach to SOA, there is a
clear set of functionalities that you will need, and the Oracle SOA Suite provides all of these.
Let’s start from the bottom here.
You seldom start SOA from the beginning; you want to reuse existing assets, be it legacy
services, COTS (Commercial Off-The-Shelf software), and so on, or interaction with your
business partners. The first thing you need to do is to normalize these heterogeneous sources
via adapters or, in the case of the external partners, a B2B gateway that provides all the
security and framework required to extend your SOA beyond the boundaries of your
enterprise. On the bottom, you have the entities that can be integrated using FMW tools and
products.
After you have this normalization, you need to enable data flows in a reliable and flexible
fashion. Among other things, you want to virtualize all these data sources to ensure loose
coupling and maximum flexibility as you move forward.

Now that you have the necessary foundation, you can start building new value, declaratively
through orchestration of these assets. For example, you could start building a brand new
employee on-boarding application that would leverage your existing PeopleSoft HR coupled
with BMC Remedy and additional homegrown systems that used to be disconnected. And
then you have a set of cross-functional requirements:

• You need to manage the assets developed along the way, and understand the
relationships between these various components.
• You need to secure these highly distributed applications.
• You need, of course, to configure, manage, and monitor these applications.
• And then come the visibility aspects:
- First, there is less and less value in looking at individual events or occurrences.
The true value and intelligence lie in the ability to correlate and make sense of the
various patterns of occurrences.

- Second, you need the graphical tools to not only display real-time information but
also react to specified conditions when the business data transits through your
applications.
- Finally, what are the tools to design and build these? You really have two types of
users here: business analysts and developers, both with their own skills and
requirements.
On the top, we have tools that Oracle offers that can be used in conjunction with SOA
technology.
The top red layer is the orchestration layer using BPEL. BPEL Manager and BPS Suite are
used by customers to define and orchestrate business flows, and Service Bus and ODI are
required to implement actual integration.
The lower red layer is the integration and virtualization layer.

Roadmap
• Core service components in Oracle SOA Suite 11g

• Oracle SOA Suite 11g architecture and key features
• Oracle SOA Suite related products: Oracle Service Bus
(OSB) and SOA Governance Suite
• WebLogic Server domain for Oracle SOA Suite
• Management tools of Oracle SOA Suite 11g


Key Components of Oracle SOA Composite
Application
Oracle SOA Suite 11g supports the following components in a

composite application:
• BPEL process components • Business Events
• Mediator components • Spring Service
• Business Rule components components
• Human Task components • Adapter Services

• BPMN Process components
Composite Application
Business Mediator Human Task

Event Business Rule
Spring Service
BPEL components
Adapter
Key Components of Oracle SOA Composite Application

SCA is the guiding principle, according to which Oracle built the SOA container, and thus the
framework for development of SOA applications. The key components you use to build Oracle
SOA composite applications include:
• BPEL process components for service orchestration to manage more complex service
interactions
• Mediator components for message routing within the composite, transformation, and
filtering capabilities
• Business Rule components to enable specification of rules that are executed external to
a process context and used to influence a process flow and its outcomes
• Human Task components to implement human workflow capabilities
• BPMN process components for modeling business process
• Spring Service components for integrating Java interfaces into SOA composite
applications

• Adapter services for composite applications to communicate to external technology
platforms, such as file system, database, and message queues
The diagram represents a collection of cooperating components that can make up a
composite application, which may expose multiple entry points. Subsequent pages in the
lesson provide more information about each of these components.

Orchestrating Services
with BPEL Process Components
Business Process Execution Language (BPEL) components:

• Orchestrate services by combining external services
and internal logic
BPEL
• Handle specific requirements of business processes, process
such as support for long-running processes, complex
dependencies, OnlineStore

service
and so on
Inventory
Payment
External ?
client
Shipping
Orchestrating Services with BPEL Components

BPEL is a markup language for orchestrating services into an end-to-end process flow. The
diagram shows an example of a coarse-grained business service, OnlineStore service, that
takes a combination of flow logic, calls to other services, and logic to process the results of
those calls.
BPEL is the de facto standard for developing executable business processes. It has features
for the specific requirements of business processes, such as support for multiple process
instances, asynchronous invocations, long-running processes, fault handling, correlation,
complex dependencies, and so on.
A BPEL process receives messages and orchestrates, through different invocation patterns,
one or more services that contribute to completing a business process flow.
Note: When Business Process Execution Language (BPEL) was released as an accepted
standard for business processes, it was called “BPEL for Web Services,” which caused the
acronym BPEL4WS to be used. The acronym BPEL4WS now refers to the BPEL V1.1
standard. More recently (circa 2007) the BPEL standard has been updated and named “BPEL
Process Execution Language Version 2.0,” which is referenced by the acronym WS-BPEL.

Routing and Filtering with Mediator Components
Mediator component:
• Facilitates the XML messages’ flows in composite
applications Mediator
• Defines one or more routing rules that can:
– Filter data
– Transform data

Service
– Validate data
• Manages events as a subscriber
and publisher
Service
Routing and Filtering with Mediator Components

The Mediator component, which is executed by the Mediator service engine, is responsible for
routing data from one place to another. It supports several routing patterns, and supports
header-based and content-based filtering. In addition, Mediator components, which define the
routing rules, can transform data by using XSL Transformations, and perform syntactic and
semantic validation of message structures.
To facilitate the integration between message providers and consumers, Oracle Mediator
includes the following features:
• Event handling
• Content-based and header-based routing
• Synchronous/asynchronous interactions
• Service virtualization
• Validations
• Transformations
• Error handling

Encapsulating Business Logic
with Business Rules Components
Oracle Business Rule components:

• Provide evaluation of dynamic decisions at run time
• Support automation of policies, computations, and Business
reasoning, separate from application code Rule
• Implement conditions as IF-THEN structures or as
Decision Tables

Rules engine
Business Rule Component
Rules
Rules Evaluated in
Decision
tables IF condition THEN action Inference
engine
Encapsulating Business Logic with Business Rules Components

Using Oracle Business Rules, the process of modifying business rules and policies can be
simplified, because separating business rules from the application provides business users
with the ability to easily change rules without the software development life cycle implications.
Oracle Business Rules provides a way for a business analyst to change policies that are
expressed as business rules, with little or no assistance from a programmer.
Examples for using business rules can include:
• Dynamic processing: Rules can determine intelligent routing paths within a business
process based on service-level agreements or other guidelines.
• Externalizing business rules in the process: Rule conditions evaluated as part of a
business where parameters can be changed are best implemented separately from the
process.
• Data validation and constraint checks: Rules can validate input documents or apply
additional constraints on requests.
• Human task routing: Rules can be used to perform:
- Policy-based task assignments dispatch tasks to specific roles or users
- Load-balancing of tasks among users to control the task assignment load

Implementing Human Activities
with Human Task Components
The Human Task component provides automated

processes to:
• Integrate interactions with people
Human
• Assign and route tasks to the correct Task
users or groups

Create task Assign task
Complete task Complete task
Assignee
Task Service
View and act

on tasks
Worklist application
Implementing Human Activities with Human Task Components

The Human Task component provides workflow capabilities to integrate manual interactions
with automated processes. A task service is provided to manage assignment and routing of
tasks to designated users or groups. When a task assignment is completed, the task service
returns task information to the automated process for additional processing.
Human tasks can be added to a composite application in the following two ways:
• A stand-alone human task, where it is created as a component in the SOA Composite
editor and not associated with a BPEL process. A stand-alone human task component is
useful when the client application creates the task itself by interacting with the
operations exposed from the human task component.
• A human task associated with a BPEL process, where the human task is created in the
composite application and wired to a BPEL process and integrated as part of business
process flow, such as getting human approval for expenses exceeding a given amount.
Assignees are authorized users of a Worklist application that is used to view and act on task
assignments. The Worklist application is part of Oracle SOA Suite 11g, and is developed with
Oracle Application Developer Framework (ADF) technology.

Creating Business-Driven Processes
with BPMN Service Components
Business Process Modeling Notation (BPMN):

• Is an industry standard for modeling and visualizing
business processes
• Aligns both business processes and technical
implementation
• Provides a mechanism to generate an executable BPEL

model from the process model
Business Process
Analyst Developer
Business
User
Creating Business-Driven Processes with BPMN Components

BPMN is a graphical notation used for business process modeling. The notation allows a user
to represent process flows, roles, and related documents graphically, which is easily
comprehensible, and provides a consistent representation of the organization’s business
processes.
BPMN allows the business users to document, analyze, and improve the business processes,
and then have the technical teams implement these processes by using the IT capabilities
and infrastructure available. BPMN is intended to improve collaboration with a wide variety of
stakeholders in the process. BPMN can be used by both technical staff and business users.
One of the main reasons for using BPMN in addition to or even instead of BPEL processes is
because business analysts and even end users can typically understand, help maintain, or
even own definitions of business processes, as opposed to BPEL, which is mostly unreadable
for business users.
The business process modeled in BPMN can be mapped into the executable BPEL code and
executed directly on the SOA platform.

Spring Service Components
Spring Service component:

• Can be used to expose Java logic as component-
level services in the composite application
• Can be
– Invoked by other components and other service components
– Injected into the Java beans to satisfy their dependencies

Spring Service Components

The Spring Service component makes it possible to create service components that execute
Java-based logic exposed through Spring Beans. Java classes—instead of being deployed in
a stand-alone application, exposed as JAX-WS Web Services—can be included in the SOA
composite application and integrated more directly and more privately as a Spring Service
component.
In SCA terms, a spring framework SCA application is a collection of Plain Old Java Objects
(POJOs) plus a spring SCA context file that wires the classes together with SCA services and
references. With Oracle SOA Suite, you can use the spring framework to integrate
components that use Java interfaces into SOA composite applications.
Spring Service components can be reused within the composite, invoked by various other
components, for example, a Mediator or BPEL process, and even exposed outside the
composite, either as an EJB or as a Web Service. Additionally, the Java beans in the Spring
Context component can call services exposed by other Service components, for example, a
Java bean can retrieve records from a database table by using a Database Adapter service.

Adapter Services
Adapters provide a service interface that:

• Exposes external application functionality in a form that
can be used by SOA composite application components
• Converts requests and responses into a form suitable for
other (external) systems
• Implements interfaces by using the Java Connector

Architecture (JCA) API standards
Native
interaction
External
SOA composite
Adapter application
application
system
Oracle SOA Suite Run Time
Deployed as a Resource Archive
(RAR) file, using JCA standards
Adapter Services
The role of adapters is to expose operations of external systems in a standard way, through
WSDL, so that a SOA composite application can communicate with the external application
easily. Adapters, based on the JCA API standard, provide custom implementations for
exposing existing functionality in the form of a service, such that investment in existing
applications can be preserved and reused in a SOA environment.
Oracle SOA Suite 11g is shipped with a variety of adapters commonly used to access
functionality that is not normally available in a service-oriented context, such as:
• File and FTP Adapters for reading, writing, and transferring files
• Database Adapter for interacting with relational database data
• JMS Adapter for communicating asynchronously with other applications through
message-oriented middleware (MOM) services, such as Oracle Advanced Queuing and
IBM Message Queue, among others
• Custom Adapters that expose a variety of functionality as service operations
Adapters support the ability to create a custom implementation that exposes existing
application functionality not usually available to a SOA application context. Adapters are an
integration technology that extend the reach of SOA composite application.

Quiz
The _________ is a component that uses the concept of

Process Orchestration.
a. Mediator
b. Human Task
c. BPEL
d. Business Rule

Answer: c
Explanation: The BPEL component uses the concept of orchestration, wherein services are
coordinated in a business process from a single runtime environment.

Roadmap
• Core service components in Oracle SOA Suite 11g

• Oracle SOA Suite 11g architecture and key features
• Oracle SOA Suite related products: Oracle Service Bus
(OSB) and SOA Governance Suite
• WebLogic Server domain for Oracle SOA Suite
• Management tools of Oracle SOA Suite 11g


Soa 11

Uploaded by

Copyright:

Available Formats

You might also like

Soa 11

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Soa 11

Uploaded by

Copyright:

Available Formats

These eKit materials are to be used ONLY by you for the express purpose SELF STUDY.

SHARING THE FILE IS STRICTLY PROHIBITED.

Oracle University and (Oracle Corporation) use only.

This document contains proprietary information and is protected by copyright and

Oracle University and (Oracle Corporation) use only.

Oracle University and (Oracle Corporation) use only.

2 Introducing Service-Oriented Architecture Concepts

3 Getting Started with Oracle SOA Suite 11g

Oracle University and (Oracle Corporation) use only.

Oracle University and (Oracle Corporation) use only.

Creating Wires 4-53

5 Orchestrating Services with BPEL Process Components

Oracle University and (Oracle Corporation) use only.

6 Mediating Messages with Mediator Components

Oracle University and (Oracle Corporation) use only.

Oracle University and (Oracle Corporation) use only.

8 Implementing Human Activities with Human Task Components

9 Creating Business-Driven Processes with BPMN

Oracle University and (Oracle Corporation) use only.

Practice 9 Overview: Modeling and Editing a BPM Process 9-40

10 Managing and Monitoring Composite Applications

Oracle University and (Oracle Corporation) use only.

11 Enterprise Integration Using Oracle Service Bus

Example of Virtualizing Service 11-16

Oracle University and (Oracle Corporation) use only.

12 Exploring SOA Governance

Oracle University and (Oracle Corporation) use only.

Copyright © 2011, Oracle and/or its affiliates. All rights reserved.

Oracle University and (Oracle Corporation) use only.

The main goal of this course is to:

Oracle University and (Oracle Corporation) use only.

Oracle SOA Suite 11g: Essential Concepts 1 - 2

The target audience includes:

Oracle University and (Oracle Corporation) use only.

Copyright © 2011, Oracle and/or its affiliates. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 1 - 3

To successfully complete this course, you should meet the

Oracle University and (Oracle Corporation) use only.

Copyright © 2011, Oracle and/or its affiliates. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 1 - 4

Briefly introduce yourself:

Oracle University and (Oracle Corporation) use only.

Copyright © 2011, Oracle and/or its affiliates. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 1 - 5

After completing this course, you should be able to:

Oracle University and (Oracle Corporation) use only.

Copyright © 2011, Oracle and/or its affiliates. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 1 - 6

Oracle University and (Oracle Corporation) use only.

Copyright © 2011, Oracle and/or its affiliates. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 1 - 7

Web Browser Oracle WebLogic Server Domain

Oracle University and (Oracle Corporation) use only.

SOA Suite 11g

Oracle Database 10g XE

Copyright © 2011, Oracle and/or its affiliates. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 1 - 8

Oracle University and (Oracle Corporation) use only.