SOA Suite 11g Essential Concepts - Volume 1

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY.
COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Volume I - Student Guide
D58786GC10
Edition 1.0
September 2010
D61580
Oracle University and Sentra inversiones y servicios LTDA use only
Oracle SOA Suite 11g: Essential

Concepts
Copyright 2009, 2010, Oracle and/or its affiliates. All rights reserved.
Bijoy Choudhury
Disclaimer
Swarnapriya Shridhar
This document contains proprietary information and is protected by copyright and

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 in
any way. Except where your use constitutes "fair use" under copyright law, you 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 the
express authorization of Oracle.
Technical Contributors
and Reviewers
Cathy Lippert
Dave Berry
Holger Dindler Rasmussen
Heidi Buelow
Demed L'Her
Prasen Palvankar
Tom Hardy
David Shaffer
James Mills
Jai Kasi
Magnus Kling
Mathias Kullberg
Matthew Slingsby
Vasiliy Strelnikov
Vikas Jain
Glenn Stokol
Pete Laseau
Nagavalli Pataballa
William Prewitt
Editors
Vijayalakshmi Narasimhan
Daniel Milne
Arijit Ghosh
Graphic Designers
Rajiv Chandrabhanu
Satish Bettegowda
Publishers
Giri Venugopal
Michael Sebastian Almeida
Jobi Varghese
The information contained in this document is subject to change without notice. If you
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
warranted to be error-free.
Restricted Rights Notice
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
applicable:
U.S. GOVERNMENT RIGHTS
The U.S. Governments rights to use, modify, reproduce, release, perform, display, or
disclose these training materials are restricted by the terms of the applicable Oracle
license agreement and/or the applicable U.S. Government contract.
Trademark Notice
Oracle and Java are registered trademarks of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Authors
Introduction
Course Objectives I-2
Course Agenda: Day 1 I-3
Summary I-6
Service-Oriented Architecture Concepts

Course Road Map 1-2
Objectives 1-3
Definition: Service-Oriented Architecture (SOA) 1-4
Why SOA? 1-5
Enterprise Challenge 1-7
Point-to-Point Integration 1-8
Enterprise Application Integration 1-9
Example of Application-Centric Integration 1-10
Integrating Solutions and Benefits with SOA 1-11
SOA Further Defined 1-12
Moving Toward Service-Centric Integration 1-13
SOA: A Paradigm Shift 1-14
The Eight-Domain Model Approach for SOA 1-15
Quiz 1-17
Building an SOA Reference Architecture: From Architecture Drivers to a Roadmap 1-18
SOA Reference Architecture 1-19
SOA Reference Architecture: Service Consumers 1-21
SOA Reference Architecture: Service Classification 1-22
SOA Reference Architecture: Service Providers 1-23
Reference Architecture: Example 1-24
Standards That Enable SOA 1-25
Quiz 1-27
Service and Web Service 1-28
Types of Service Access and Implementation 1-29
Ways to Integrate Services 1-30
Designing with an SOA Approach 1-31
Creating Service Portfolios 1-32
SOA Workflow and Orchestration 1-33
Implementing SOA: General Concepts 1-34
Quiz 1-35
Define SOA Governance 1-36
Identifying the Need of SOA Governance 1-37
SOA Governance Framework 1-38
Quiz 1-39
Course Practice Scenario: Purchase Order Processing 1-40
Summary 1-41
Practice 1 Overview: Preparing the Business Flow Diagram 1-42
iii
Contents
Implementing SOA with Oracle SOA Suite

Course Roadmap 2-2
Objectives 2-3
Basic Components of an SOA Infrastructure 2-4
Oracle SOA Suite 11g Components 2-5
Introduction to Service Infrastructure 2-7
Introducing SCA in Oracle SOA Suite 11g 2-8
Defining a Composite Application 2-9
Introducing Oracle Mediator Component 2-11
Describing the Features of Oracle Mediator Component 2-12
Introducing Oracle BPEL Process Component 2-13
Introducing Business Rules Component 2-14
Introducing Human Task Component 2-15
Quiz 2-16
Introduction to Business Activity Monitoring 2-17
Monitoring Services with BPEL and BAM 2-18
Oracle Enterprise Manager 2-19
Oracle WebLogic Server 10.3 2-21
WebLogic Server Domain 2-22
WebLogic Server Servers 2-24
Administration Server 2-25
Managed Server 2-26
WebLogic Server Machines 2-27
SOA Development with Oracle JDeveloper 2-28
Creating Connections in Oracle JDeveloper 2-29
Creating an Application Server Connection in Oracle JDeveloper 2-31
Goals of Implementing SOA Application with Oracle SOA Suite 11g 2-33
Quiz 2-34
Summary 2-36
Practice 2 Overview: Creating Connections in JDeveloper 2-37
SOA Governance and Service

Life-Cycle Management Course Roadmap 3-2
Objectives 3-3
Define Service Life-Cycle Management 3-4
Phases of Service Life Cycle 3-5
The Need for Service Life-Cycle Management 3-6
Define SOA Governance 3-7
Relationship of Governance Disciplines 3-8
The Need for SOA Governance 3-9
Benefits of SOA Governance 3-10
Center of Excellence: Key to SOA Success 3-11
Example of Governance Organizational Structure 3-12
Quiz 3-13
Service Life-Cycle Governance 3-14
Service Management 3-16
Service Portfolio 3-17
Policy Manager 3-18
Service Routing 3-19
Service Versioning 3-20
iv
Designing Services for SOA Implementations

Course Roadmap 4-2
Objectives 4-3
Defining Services 4-4
Services Are SOA Building Blocks 4-5
Service Contract 4-6
Service Design 4-8
Service Granularity 4-9
Service Design Principles 4-10
Designing Coarse-Grained Interfaces 4-12
Quiz 4-13
Service Classifications 4-14
Connectivity Services 4-15
Data Services 4-16
Business Services 4-17
Business Process Services 4-18
Presentation Services 4-19
Service Infrastructure 4-20
Quiz 4-21
Basic Service Interaction Patterns 4-22
Synchronous Interactions 4-23
Asynchronous Interactions 4-24
Choosing Service Implementation Styles 4-25
Fundamentals for Creating a Service 4-27
Building a Portfolio of Services 4-28
Describing a Web Service 4-29
Web Service Standards 4-30
Web Service Architecture 4-31
Service Artifacts 4-33
XML Schema Definitions 4-34
Defining Messages in XML Schemas 4-35
Web Services Description Language 4-36
WSDL Model 4-37
Defining Service Interfaces in WSDL 4-38
Quiz 4-39
Adapter Services 4-40
Describing Technology Adapters 4-41
v
SLA Management 3-21

Quiz 3-22
Constituents of SOA Governance Model 3-23
End-to-End SOA Governance 3-25
End-to-End SOA Governance: SOA Asset Management 3-26
End-to-End SOA Governance: Policy Management and Enforcement 3-27
End-to-End SOA Governance: Consumer Management 3-28
End-to-End SOA Governance: SOA Monitoring and Management 3-29
SOA Governance Solution 3-30
Oracle SOA Governance Solution 3-31
Quiz 3-32
Summary 3-33
Practice 3 Overview: Defining Policies for a Group of Services 3-34
Creating a Composite Application

Course Roadmap 5-2
Objectives 5-3
Service Component Architecture 5-4
Components and Composites 5-6
SCA Components 5-7
SCA Composite 5-8
SCA Bindings 5-9
SCA Policy Framework 5-10
Quiz 5-11
Service Data Objects (SDO) 5-12
SDO Data Architecture 5-13
SCA and SDO 5-14
Creating an SOA Composite in JDeveloper 11g 5-15
Describing the SOA Composite Editor 5-16
Creating Exposed Services 5-18
Creating SOA Components 5-19
Examining the SCA Descriptor 5-20
Quiz 5-21
Adding a Mediator Component 5-22
Adding a BPEL Process Component 5-23
Comparing BPEL and Mediator 5-24
Examining the JDeveloper Workspace, Projects, and File Structure 5-25
Editing a Component in a Composite 5-26
Creating External References 5-27
Creating Wires 5-28
Creating Wires Modifies Connected Elements 5-29
Exposing Components as an External Service 5-30
Quiz 5-31
Deploying an SOA Composite Application 5-32
Summary 5-33
Practice 5: Overview Creating an SOA Composite Application 5-34
Managing and Monitoring SOA Composite Applications

Course Roadmap 6-2
Objectives 6-3
Overview of Managing SOA Applications 6-4
Managing with Oracle Enterprise Manager 6-5
Oracle Enterprise Manager Fusion Middleware Control 6-6
Accessing the SOA Infrastructure Home Page 6-7
Accessing a Composite Application Home Page 6-8
Example Composite Application Home Page 6-9
Deploying a Composite Application 6-10
Deploying SOA Composite Applications 6-11
Initiating an SOA Composite Application Test Instance 6-12
Tracking Message Flow 6-13
vi
Packaged Application and Legacy Adapters 4-42

Quiz 4-43
Summary 4-44
Practice 4: Overview Designing Services for SOA Implementations 4-45
Working with Mediator Components

Course Roadmap 7-2
Objectives 7-3
Introducing Oracle Mediator 7-4
Oracle Enterprise Service Bus and Mediator 7-5
Oracle Mediator Features 7-6
Event Delivery Network 7-7
Introducing Business Events 7-8
Event Handling 7-10
Content-Based and Header-Based Routing 7-11
Synchronous/Asynchronous Interactions 7-12
Service Virtualization 7-13
Validations 7-14
Error Handling 7-15
Transformations 7-16
Quiz 7-17
Creating an Oracle Mediator Component 7-18
Mediator Component Creation Options 7-19
Define Interface Later 7-20
Viewing the Mediator Source Code 7-22
Modifying a Mediator Component 7-23
Deleting a Mediator Component 7-24
Specifying Mediator Component Routing Rules 7-25
Introducing Routing Rules 7-26
Accessing Mediator Routing Rules 7-28
Defining Mediator Routing Rules 7-29
Specifying a Target Service: Example 7-31
Adding a Transformation to a Mediator Component 7-32
Filtering Messages 7-33
Specifying Sequential or Parallel Execution 7-35
Quiz 7-36
When to Use Business Events? When to Invoke a Service? 7-37
Summary 7-38
Practice 7: Overview Creating a Mediator Service Component 7-39
vii
Working with the Flow Trace 6-14

Working with the Component Audit Trail Page 6-15
Quiz 6-16
Managing the State of Deployed SOA Composite Applications 6-17
Monitoring and Deleting Specific SOA Composite Application Instances 6-18
Recovering from SOA Composite Application Faults 6-19
Undeploying a Composite Application 6-21
Quiz 6-22
Summary 6-23
Practice 6: Overview Managing and Monitoring Composite Applications 6-24
Orchestrating Services with a BPEL Component

Course Roadmap 8-2
Objectives 8-3
Process Orchestration Concepts 8-4
Introducing Business Process Execution Language (BPEL) 8-5
Creating a BPEL Process 8-7
Oracle BPEL Process Designer 8-8
Designing the BPEL Process 8-9
Quiz 8-10
Developing a BPEL Process 8-11
BPEL Activity Types 8-12
Grouping Activities by Using a BPEL Scope 8-14
Adding Activities to a Scope 8-15
Communicating Data with a BPEL Process 8-16
BPEL Variables 8-17
Choosing Global or Local Variables 8-19
The Assign Activity 8-21
Creating Assign Operations 8-22
Copying Data from Source to Target 8-23
Using the XPath Expression Builder 8-24
Quiz 8-25
Partner Links and Service Invocation 8-26
Partner Links, Partner Link Types, and Roles 8-27
Synchronous Services 8-28
Synchronous Process Structure: HelloWorld Example 8-29
Asynchronous Service 8-30
Asynchronous BPEL Process Structure 8-31
Creating a Partner Link 8-32
Configuring a Partner Link 8-33
Invoking a Synchronous Service 8-34
Conditionally Branching with a Switch Activity 8-35
Adding a Switch Activity 8-36
Configuring Branches of a Switch Activity 8-37
Summary 8-38
Practice 8: Overview Creating a BPEL Service Component 8-39
Working with the Human Task Component

Course Roadmap 9-2
Objectives 9-3
What Is a Human Task? 9-4
Human Workflow Diagram 9-5
Introduction to Human Workflow Concepts 9-7
Implementing Human Workflow Services 9-8
Exploring Workflow Exchange Patterns 9-9
Describing a Workflow as a Service 9-10
Quiz 9-11
Adding a Human Task Component to an SOA Composite 9-12
The Human Task Editor 9-13
Working with Human Workflow in BPEL 9-14
Creating a Human Task in BPEL 9-15
Configuring the Human Task 9-16
viii
10 Implementing a Business Rules Component

Course Roadmap 10-2
Objectives 10-3
Introducing Business Rules Technology 10-4
Declarative Rule Concepts 10-5
Rule Inference Concepts 10-6
Reasons for Using Rules Technology 10-7
Guidelines for Selecting Rules Use Cases 10-8
Introducing Oracle Business Rules 10-9
Introducing Oracle Business Rules Concepts 10-11
Developing a Rule-Enabled Application 10-12
Defining Oracle Business Rules Development Concepts 10-13
Quiz 10-14
Creating a Dictionary for Rule Definitions 10-15
Working with the Rules Editor in JDeveloper 10-16
Creating XMLFact Entries 10-18
Working with Bucketsets 10-19
Creating a Bucketset 10-20
Creating Oracle Business Rules Globals 10-21
Creating a Ruleset 10-22
Identifying the Structure of a Rule 10-23
Creating a Rule 10-24
Creating a Rule Test 10-25
Creating a Rule Action 10-26
Working with Decision Tables 10-27
Creating Conditions and Rules in Decision Tables 10-29
Creating Actions in Decision Tables 10-31
Working with Decision Functions 10-33
Integrating Rules with a BPEL Process 10-34
Adding a Business Rule Activity 10-35
Summary 10-38
Practice 10: Overview Implementing a Business Rule 10-39
11 Securing Services and Composite Applications
Course Roadmap 11-2
Objectives 11-3
Introduction to Web Services Security 11-4
Need for Web Services Security 11-5
Web Services Security Approaches 11-6
WS-Security 11-8
WS-Security Fundamentals 11-9
Quiz 11-11
ix
Adding Task Parameters 9-17

Setting the Task Parameter Values 9-18
Generating a Task Form for the Worklist 9-19
Accessing the Worklist Application 9-20
Viewing Task Information 9-21
Managing Task Assignments 9-22
Summary 9-23
Practice 9: Overview Creating a Human Task to Approve Orders 9-24
Appendix A: Practices and Solutions

Appendix B: Introduction to Linux
What Is Linux? B-2
What Is Oracles Strategy for Linux? B-3
File System and Basic Directory Structure B-4
Shell Commands B-6
Environment-Based Commands B-7
Information-Based Commands B-9
File System Commands B-11
Common vi Editing Commands B-13
Common FTP Communication Commands B-15
Archive Utilities B-17
Shortcuts and Tips B-19
Appendix C: Perform Common Tasks with Oracle JDeveloper
Objectives C-2
Create a Database Connection C-3
Create an Application Server Connection C-4
Create an Application C-6
Create an Empty Project C-8
Create an SOA Project C-9
Create a Project from Existing Sources C-10
Deploy an SOA Composite Application C-13
Summary C-15
Appendix D: SOA Adoption Planning Principles
Objectives D-2
SOA Adoption D-3
SOA Adoption Planning Activities D-4
SOA Adoption Planning Activities: Completing the Stakeholder Community D-5
SOA Adoption Planning Activities: Moving Through the Change Curve D-6
SOA Adoption Planning Activities: Establishing "Line-of-Sight" Goals D-7
SOA Adoption Planning Activities: Establish a Milestone Delivery Plan D-8
SOA Adoption Planning Activities: Usage of Metrics D-9
SOA Adoption Planning Activities: Enabling Business Innovation D-10
SOA Adoption Planning Activities: Usage of Tools and Processes D-11
The Need for an SOA Reference Architecture D-12
x
Oracle Web Service Manager 11-12

Components of Oracle Web Services Manager Architecture 11-13
Oracle Web Services Manager Policy Framework 11-14
Introduction to Policies 11-15
Policy Interceptor Pipeline 11-16
Policy Assertions 11-17
Quiz 11-18
Managing SOA Composite Application Policies 11-19
Attaching Security Policy to a Service 11-20
Quiz 11-21
Summary 11-22
Practice 11 Overview: Attaching Policies to Web Services 11-23
Glossary
xi
Developing the SOA Reference Architecture D-13

Developing the SOA Reference Architecture: Align IT with Business D-14
Developing the SOA Reference Architecture: Develop a Baseline D-15
Developing the SOA Reference Architecture: Create SOA Reference Architecture D-16
Developing the SOA Reference Architecture: Create SOA Infrastructure Roadmap D-17
SOA Governance Model D-18
Example of an SOA Governance Model D-19
Summary D-20
Copyright 2009, Oracle. All rights reserved.
Introduction
After completing this course, you should be able to:

Explain Service-Oriented Architecture (SOA) concepts and
related technology
Explain the standards and specifications that enable a
Service-Oriented Architecture (SOA) approach
Describe the SOA reference architecture
Understand the Oracle SOA Suite 11g product
Understand the Service design considerations
Explain composite application concepts
Understand the working of the different service
components
Monitor and securing services and composite applications
Course Objectives
This course introduces Service-Oriented Architecture (SOA) concepts, standards that enable an SOA
approach, and the Oracle Fusion Middleware 11g technology products that support an SOA
implementation.
Using a purchase order management business process as the scenario, you learn how an SOA
approach can be implemented, whether you are starting fresh with new services or reusing existing
services provided by the business. Using Oracle SOA Suite 11g components, you explore, modify,
execute, and monitor a purchase order processing composite application implemented using an SOA
approach for managing the business process.
Oracle SOA Suite 11g: Essential Concepts I - 2
Course Objectives
A
O
S
Service-Oriented
Architecture Concepts
Implementing SOA with

Oracle SOA Suite
SOA Governance and

Service Life-Cycle
Management
Designing Services for

SOA Implementations
Course Agenda: Day 1

The following is the course agenda for day 1:
Introduction to the course and lessons.
Lesson 1: Service-Oriented Architecture Concepts: This lesson discusses the system
integration challenges and problems faced by enterprises, and explores what needs to be
considered before embarking on an SOA style implementation.
Lesson 2: Implementing SOA with Oracle SOA Suite: This lesson describes Oracle SOA
Suite 11g products and components. Oracle SOA Suite 11g architecture and its components are
discussed at an introductory level.
Lesson 3: SOA Governance and Service Life-Cycle Management: The aim of this lesson is
to discuss the need for service life-cycle management to enable effective management of
services, and to ensure the delivery of highest possible business value over time.
Lesson 4: Designing Services for SOA Implementations: The aim of this lesson is to identify
common design decisions when creating service and composite applications, and to review the
key standards that enable SOA to work better, such as XSD, WSDL, and XSLT
Creating a Composite
Application
Managing and Monitoring

SOA Composite
Applications
Working with Mediator

Components
Orchestrating Services
with a BPEL
Component

Lesson 5: Creating a Composite Application: This lesson introduces the composite
application as an assembly and deployment model for SOA services in Oracle SOA Suite 11g.
The concepts are described through the introduction of the SCA specifications.
Lesson 6: Managing and Monitoring SOA Composite Applications: This lesson provides an
early and basic introduction to simple administrative or management tasks related to SOA
composite applications. These tasks are accomplished by using the Enterprise Manager Web
interface.
Lesson 7: Working with Mediator Components: This lesson introduces the basic features
such as creating routing rules, simple filters, and transformationsof the Mediator service
component inside an SOA composite application,.
Lesson 8: Orchestrating Services with a BPEL Component: The aim of this lesson is to
introduce simple BPEL process concepts to enable you to invoke a service, such as the credit
card validation service. You also learn about the Scope, Assign, and Invoke BPEL activities.
Working with the

Human Task Component
Implementing a Business
Rules Component
Securing Services and

Composite Applications
10
11

Lesson 9: Working with the Human Task Component: This lesson introduces the basic
features of the Human Task service component, and how to execute it from a BPEL process. In
addition, you are introduced to the Worklist application to perform the task assignment.
Lesson 10: Implementing a Business Rules Component: This lesson provides an early and
basic introduction to Oracle Business Rules and its implementation in the SOA composite
application, by using a business rules service component.
Lesson 11: Securing Services and Composite Applications: The aim of this lesson is to
introduce the basic security concepts and Oracle Web Services Manager security feature in
securing an SOA composite application.
After completing this lesson, you should understand the:

Learning objectives of this course
Structure and organization of this course
Summary
Service-Oriented Architecture Concepts
In this Service-Oriented Architecture Concepts lesson you will be introduced

to Service-Oriented Architecture (SOA) concepts, the standards that enable
SOA, and the different drivers that help you devise an SOA strategy.
Course Road Map

The Service-Oriented Architecture Concepts lesson introduces the challenges faced by enterprises
in integrating application and how Service-Oriented Architecture can provide a solution to the same.
You will also be familiarized with the various drivers that enable you to build a reference
architecture, which is the first step toward embarking into a Service-Oriented Architecture.
Oracle SOA Suite 11g: Essential Concepts 1 - 2
Course Road Map
After completing this lesson, you should be able to:

Describe the challenges of the integration of enterprise
application systems
Describe the solution for enterprise application integration
Describe the role of Oracle SOA Maturity Model
Describe Service-Oriented Architecture (SOA)
Identify standards that enable SOA
Identify basic design requirements for an SOA approach
Explain the role of SOA governance
Objectives
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.
Business
Strategy
SOA
IT
Strategy
Definition: Services-Oriented Architecture (SOA)

In computing, SOA provides methods for systems development and integration where systems group
functionality around business processes and package these as interoperable services. An SOA
infrastructure allows different applications to exchange data with one another as they participate in
business processes.
Definition: Service-Oriented Architecture (SOA)
SOA enables:
Reusability
Business services
Interoperability
Loosely coupled services
Scalability and flexibility

Coarse-grained
Document-oriented
Asynchronous services
Cost efficiency
Standards-based approach
Why SOA?
What drives the move to SOA is reuse of business services. Developers within an enterprise and
across enterprises (particularly, in business partnerships) can take the code developed for existing
business applications, expose it as Web services, and then reuse it to meet new business
requirements.
The SOA vision of interaction between clients and loosely coupled services means widespread
interoperability. In other words, the objective is for clients and services to communicate and
understand each other no matter what platform they run on.
Because services in an SOA are loosely coupled, applications that use these services tend to scale
easilycertainly more easily than applications in a more tightly coupled environment. That is
because there are few dependencies between the requesting application and the services it uses,
which typically makes them more flexible than more tightly coupled applications. In a tightly
coupled architecture, the different components of an application are tightly bound to each other,
sharing semantics, libraries, and often sharing state. This makes it difficult to evolve the application
to keep up with changing business requirements. The loosely coupled, document-based,
asynchronous nature of services in an SOA allows applications to be flexible and easy to evolve with
changing requirements.
Why SOA?
Why SOA? (continued)

Other approaches that integrate disparate business resources such as legacy systems, business partner
applications, and department-specific solutions are expensive because they tend to tie these
components together in a customized way. Customized solutions are costly to build because they
require extensive analysis, development time, and effort. They are also costly to maintain and extend
because they are typically tightly coupled, so that changes in one component of the integrated
solution require changes in other components. A standards-based SOA approach should result in less
costly solutions because the integration of clients and services does not require the in-depth analysis
and unique code of customized solutions.
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
Enterprise Challenge
EAI
Custom Packaged CRM

API
CRM
Application
Custom
API
Client Tier
Custom
Logic
Custom Packaged ERP Custom

API
API
Client
Application
Custom
Logic
Custom Mainframe
API
Custom
API
Client
Application
Custom
Logic
Custom App Server

API
Custom
API
Client
Application
ERP
Application
Custom
Application
EJB
Application
Point-to-Point Integration
Point-to-point integration involves:
Proprietary messages, APIs
Custom integration links
Duplication of effort
Lack of open standards
Tight coupling of data and implementation
Skill set issues
Projects lasting months
Cost (skill, time, products)
Operational polices embedded in application
Lack of agility
Slow response by IT to business changes
In the point-to-point (or peer-to-peer) integration methodology, applications are integrated with other
applications as needed. The interconnections as shown here could be built with Web services as well.
But that does not mean that the above peer-to-peer implementation is SOA-based; it still is not
loosely coupled and intermediary-based, and it lacks a shared infrastructure.
CRM stands for Customer Relationship Management.
Point-to-Point Integration
Client Tier
VB
Application
Java
Application
Standard-based interfaces
Standard-based
Interfaces
Web
Application
Standard-based
Standard-basedinterfaces
Interfaces
Message Bus or Middleware

Packaged CRM
Custom
API
Custom
API
Packaged ERP
CRM
Application
ERP
Application
JAM API
Mainframe
App. Server
Custom
Application
RMI
EJB
Application

Because point-to-point integration was complex, costly, and difficult to manage, the Enterprise
Application Integration (EAI) method was introduced. EAI was based on message broker or
middleware where the connectivity between each application and the message bus was developed
using proprietary bus APIs and an Application Platform Suite (APS).
The following are the disadvantages of all of these approaches:
Custom or proprietary integration between the message bus and each application was required.
Different proprietary data formats were involved at each integration point.
Each application was still tightly coupled to the message bus.
The applications need to know the inner workings of the other applications they were integrated
with.
The challenge of accessing, integrating, and transforming data (enterprise information integration)
has largely been left to developers to perform using manual coding.
The lack of standards and the architecture limitations in addition to the hefty costs of traditional EAI
projects has resulted in the search for an alternative integration solution that would address the
limitations. JAM stands for Java Application Manager.
Web based Banking Application

Apply for new Credit Card
Verify Customer
Address
Check Customer
Credit Card
Setup
Account
Conduct
Fraud
Check
Setup
Account
Marketing
System
Apply for new Mortgage Loan
Sales and
Acquisition
Risk
System
Corporate
System
Business
Unit
Example of Application-Centric Integration

The slide shows a Web-based Banking Application using point-to-point integration. Here in order to
process a new Credit Card:
Applications are integrated with each other.
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. Here each application needs to create its
own integration.
The lack of agility and usage of customer integration links results in inflexibility.
Example of Application-Centric Integration
Offers faster business

response time
Masks underlying
technical complexity
Improves business
agility
Service-Oriented
Architecture
Aligns IT with
business
Benefits
Reusability
Interoperability
Scalability
Cost
Efficiency
Integrating Solutions and Benefits with SOA

Aligning IT with discrete business functions:
Results in rapid development and more reliable delivery of new and enhanced business services
Improves productivity, agility, and speed for both business and IT
Allows IT to deliver services faster and align closer with business
Allows the business to respond more quickly and deliver optimal user experience
Masks the underlying technical complexity of the IT environment
The benefits of Service-Oriented Architecture are:
Reusability: Existing business functionality in an application can be reused to meet new
business requirements. In addition, new services should be designed with reusability in mind as
determined by their usage patterns within the business domain. However, not all services need
to be reusable or should be depending on the business requirement.
Interoperability: Communication between services and the business process is not dependent
on the platform and are standards-enabled. The services are also not tightly coupled to the
application.
Scalability: Applications are flexible to the changing business requirements.
Cost efficiency: Highly cost efficient as integrating the business resources is standards-based.
Integrating Solutions and Benefits with SOA
SOA can be thought of as:

An enterprise-level design approach
A collection of services on a network that communicate with
one another
A set of services that are loosely coupled, with well-defined,
reusable, platform-independent interfaces
A higher level of application development
Services provide access to data, business processes, and

IT infrastructure, ideally in an asynchronous manner.
SOA leverages standards-based integration (XML and
Web services) to connect heterogeneous systems.
SOA Further Defined

SOA-based application development and integration solves many issues and shortcomings of the
traditional approaches. SOA describes a set of well-established patterns that help a client application
connect to a service. These patterns represent mechanisms used to describe a service, to advertise and
discover a service, and to communicate with a service.
Most communication middleware systems, such as Remote Procedure Call (RPC), Common Object
Requesting Broker Architecture (CORBA), Distributed Component Object Model (DCOM),
Enterprise Java Bean (EJB), and Remote Method Invocation (RMI), rely on similar patterns.
However, there are differences between each implementation and weaknesses among them. The
primary issue has been acceptable standards and interoperability. SOA is built upon these
technologies and has tried to eliminate apparent weaknesses. Each of these technologies has a fixed
granularity, function for RPC, object for CORBA, and so on. Services do not have this fixed
granularity. Instead, a service can be a function, an object, or an application. SOA is, therefore,
adaptable to any existing system and does not force the system to conform to any particular level of
granularity.
Instead of replacing the existing architectures, SOA helps to reuse all existing systems and
applications in the company and transform them into agile services. SOA not only covers information
from packaged, customer, and legacy applications systems, but also the functionality or data from the
IT infrastructure, such as security and content management.
SOA Further Defined
Service-Centric Integration
Application Centric Integration

Web
Phone
Branch Systems
Trading Partners
Channels
Web UI / Portals/ Portlets
Presentation Service Layer
Business Process Layer (BPM, Workflow)

Check
Credit Card
Verify Customer
Address
Setup
Account
Service
Bus
Mediation
Conduct Fraud
Check
Business Service
Integration Tier (Connectivity Service)
Assets /Systems
SOA
Governance
Moving Toward Service-Centric Integration

The slide depicts how a Web-based Banking application using point-to point integration can be
migrated to service-centric integration 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 and
The Presentation Service Layer provides the user interfacerelated services.
The service-centric integration approach provides a shared service and infrastructure platform that
encourages reusability and flexibility.
Moving Toward Service-Centric Integration
Distributed Component Architecture
Service-Oriented Architecture
Functionality-oriented
Process-oriented
Designed to last
Designed to change
Long development cycle
Interactive and
iterative development
Cost-centered
Business-centered
Application block
Services orchestration
Tightly coupled
Agile and adaptive
Homogeneous technology
Heterogeneous technology
Object-oriented
Message-oriented
Known implementation
Abstraction
SOA: A Paradigm Shift

SOA is much more than a new software development model; it is a true paradigm shift. The more
powerful paradigm shift that you are seeing in most organizations is the shift in focus from
functionality and application to process and business. Architects are now specifying the designs for
services with names such as Get_Customer, Open_Order, or Get_Service_History. Then together
with their business partners, they whiteboard entire business processes by assembling these services.
One of the additional benefits of SOA involves the changed relationship between IT and business,
bringing them closer to each other and helping each other. There is more to this paradigm shift. The
development cycles will shrink, or rather, will go to high frequency deployments of smaller chunks
of capability instead of the large, lengthy development.
SOA: A Paradigm Shift
Technology Dominated
Architecture
Organizational Disciplines
Business and Strategy
Infrastructure
Organization
Governance
Information
Operations,
Administration, and Management
Project,
Portfolios, and Services
The Eight-Domain Model Approach for SOA

The Eight Domain Maturity model is used to accelerate SOA adoption by identifying specific
capabilities that are either completely lacking or that are lagging with respect to the other capabilities
necessary for successful SOA adoption.
The SOA Maturity Model uses the concept of domains to classify and organize the related
capabilities. These capabilities provide the detail necessary to truly measure and guide the progress
of an SOA initiative. As depicted in the slide, the Maturity Model has eight domains:
Business and Strategy: Contains capabilities that provide the high-level constructs that allow the
SOA initiative to proceed. This includes business motivation, expected benefits, guiding principles,
expected costs, a funding model, and so on.
Architecture: Contains capabilities concerning the definitions of the overall architecture and
guidelines for various practitioners to ensure adherence to the architecture
Infrastructure: Contains capabilities concerning the service infrastructure and tools that provide the
technical foundation for the SOA initiative
Information: Contains capabilities concerning the information aspects of SOA, for example,
providing Information as a Service (IAAS). This includes shared data models, message formats and
schemas, master data management, content management, and so on.
Projects, Portfolios, and Services: Contains capabilities concerning the planning and building of
services and the service usage guidelines of service consumers
The Eight-Domain Model Approach for SOA
Organization: Contains capabilities concerning the development of corporate competency in regards

to SOA including the organizational structure and skills development
Governance: Contains capabilities concerning the governance structures and processes that support
and guide the SOA efforts. The maturity and adoption of an adequate amount of governance is a
leading indicator of the overall SOA success.
These eight domains, although interrelated, are sufficiently distinct. To succeed at SOA adoption, an
organization must adequately progress in all of these domains.
The Eight-Domain Model Approach for SOA (continued)

Operations, Administration, and Management: Contains capabilities concerning the post
deployment aspects of solutions based on a Service-Oriented Architecture, such as the operations,
administration, and management aspects of SOA.
Which one does not belong to the Eight-Domain model?

1. Business and Strategy
2. Governance
3. Architecture
4. Installation
Answer: 4
Explanation: The Eight Domain Maturity model is used to accelerate SOA adoption by identifying
specific capabilities that are either completely lacking or that are lagging with respect to the other
capabilities necessary for successful SOA adoption. The eight domains are:
1. Business and Strategy
2. Architecture
3. Infrastructure
4. Information
5. Projects, Portfolios, and Services
6. Operations, Administration, and Management
7. Organization
8. Governance
Quiz
Identify the
stakeholders viewpoints
or concerns, prioritize
SOA benefits, and
examine the current
reality.
Determine business
scope and motivation.
Design an incremental
plan to achieve the
future vision.
Best Practices
Business
Business Drivers
Drivers
IT Objectives
SOA Strategy
Future Vision
SOA Reference Architecture
Roadmap
Current Reality
Determine IT drivers.
SOA reference
architecture should
include definitions,
standards, rules,
principles, and
guidelines, and
architecture views.
Building an SOA Reference Architecture: From Architecture Drivers to a Roadmap

An SOA strategy is ideally established enterprise-wide but in many circumstances it may be
incubated within a line of business (LOB), or other subset of the full corporate entity. In these cases,
the limitations and compromises must be recognized at an early stage (such as the reduced value of
shared business services, limiting opportunities for service composition, and so on).
Both business and IT drivers should be collected (separately).
Examples of business drivers might be to:
Improve efficiency in the call center
Grow revenue faster than our peers in a sustainable way
Simplify the assimilation of acquired companies
Expand customer relationships, and so on
IT drivers, on the other hand, might be to:
Move from transaction focus to customer focus
Move from silo LOB focus to process/service focus
Expose loosely coupled business logic to achieve speed and flexibility and so on
Business and IT drivers should be aligned, but clearly use different language and refer to different
issues while leading to the same result. Notice also that drivers such as vision and goals do not
include statements of how to achieve these goals or even when they should be achieved.
Building an SOA Reference Architecture:

From Architecture Drivers to a Roadmap
An SOA reference architecture is a blueprint or guide to

creating an SOA infrastructure implementation for a
business depending on the business needs.
The SOA reference architecture:
Defines the target architecture and the principles to be used
by an organizations architects to make architecture and
design decisions on their projects
Is a key component of an effective strategy to deliver the
benefits of SOA

An SOA reference architecture promotes consistency and interoperability by defining enterprisewide principles, guidelines, and patterns.
An SOA reference architecture is a blueprint to guide the enterprise toward SOA success by:
Establishing a strategy for architecting new SOA projects, leveraging existing projects, and
legacy investments
Building in flexibility, manageability, and planning for change
Simplifying diverse, sometimes incompatible, platforms and applications found within any
large enterprise
Transitioning toward a culture of reuse, team collaboration, and resources sharing
Determining best practices for standards and technology deployment
Migrating toward a 23 year view, achieving true convergence over time
Providing a communication tool for establishing a common understanding of SOA and its core
strategies throughout the enterprise
Service Consumers and

Delivery Channels
Employees
Customers
Web Apps
Partners
Portals
Mashups
Client
Apps
Partner
Apps
BPM Process Clients
Shared Services and Infrastructure

Service Registry
Presentation Services
Shared Portlets
Business Processes
System-Centric Workflow Human-Centric Workflow
Business Services
Enrichment
Data Services
Logical Data Model Data Aggregation/Synchronization
Connectivity Services
System/Data Access
Messaging
Adapters
Multichannel Delivery
Service
Bus
SOA Security
Infrastructure
Custom/Atomic Business Services
Messaging
Custom APIs
Non-Service Enabled Assets
Mediation
SOA Monitor and

Event Manager
Infrastructure
Services
Partner Integration
JDBC
Service Repository
file://
Service-Enabled Assets
SOA Reference Architecture (continued)

The architecture separates the users of enterprise functionality from the systems and applications that
provide that functionality, placing the infrastructure for services and service delivery between them.
The layers of services and their supporting infrastructure are referred to as the innovation layer.
This analogy expresses their role in driving change in the way that IT is delivered. Existing
applications, data, and middleware form the foundation from which services are drawn. Supporting
and formalizing the existing enterprise activities is a service-oriented infrastructure. Standards-based
infrastructure services provide a common basis for the deployment of all other types of service.
Note: The SOA architectural framework for an organization is selected from this reference
architecture based on business requirements. Not all components of the reference architecture are
needed.
Service Consumers and

Delivery Channels
Employees
Customers
Web Apps
Portals
Partners
Mashups
Client
Apps
Partner
Apps
BPM Process Clients
Users of the enterprise functionality
SOA Reference Architecture: Service Consumers

Service consumers include end users as well as applications that are users of SOA, but not
contributors of services. These include :
Applications that belong to another domain, for example, partner applications
Complex event processing systems, that can invoke composite applications and services as a
result of processing decisions
SOA Reference Architecture:

Service Consumers

Shared Portlets
Business Processes
Business Services
Enrichment
Data Services
System/Data Access
Messaging
Service Registry
Service
Bus
Service Repository
SOA Security
Infrastructure
Mediation
SOA Monitor and

Event Manager
Partner Integration
Infrastructure
Services
Service classifications and infrastructure

requirements of Service-Oriented
Architecture
SOA Reference Architecture: Service Classification

Service classification is a logical grouping of types of services that meet specific needs and conform
to different subsets of standards or guidelines. The separate classifications potentially satisfy
different subsets of architectural principles and have their own specific constraints applied.
The different service classifications are:
Connectivity services
Data services
Business services
Business process services
Presentation services
Infrastructure services

Service Classification

Service Registry
Shared Portlets
Business Processes
Business Services
Enrichment
Data Services
System/Data Access
Messaging
Adapters
Service
Bus
SOA Security
Infrastructure
Messaging
Custom APIs
Non-Service Enabled Assets
Mediation
SOA Monitor and

Event Manager
Infrastructure
Services
Partner Integration
JDBC
Service Repository
file://
Service-Enabled Assets
Assets that can be shared and reused

throughout the enterprise
SOA Reference Architecture: Service Providers

Existing functionalities, from other parts of the enterprise or from external applications, can be
accessed securely via the service bus, if the functionalities are exposed as services (service-enabled
assets). In this way business functionality (or data etc.) that was not previously accessible can be
shared and reused across the enterprise. There is no necessity for the connectivity services to
service-enable them. But on the contrary the non-serviceenabled assets standardize the exposure
of their functions to the other service classes using the connectivity services.

Service Providers
Web Application eCommerce Processes

Create New
Quote or Order
Cart
Service
Business
Process
Services
Business
Activity
Services
Convert Quote
to Order
Service Bus
Calculate Shopping Cart
Calc Item Price & Check

Item Availability
Check Order
Status
Check Invoice
History
Order
Service
Invoice
Service
Import Order
Calc Freight
Connectivity Services Oracle Adapter

System Access
Data Access
Reference Architecture: Example

The slide displays a reference architecture of a Web application e-commerce process. The
application performs the following tasks:
Allows a customer to search for an item, add the selected item to a shopping cart, and place an
order for it.
Calculates the shopping cart value based on the availability of the item in the database
Generates an invoice
Enables the customer to keep track of the order status
Each of the above mentioned tasks maps to a functionality in the shared service and infrastructure
layer. For example, calculating the item price and freight charges falls under the business services
layer, whereas the accessibility of the database finds its location in the connectivity service.
One of the key ideas is to identify explicit functional capabilities and their location in the reference
architecture.
Reference Architecture: Example
Management
WS-Policy
WS-Security
Current and Emerging Standards
Category
Service Component Architecture (SCA)
Assembly
model
Orchestration: BPEL4WS
Business
processes
Service Data Objects (SDO)
Data access
WS-ReliableMessaging
WS-Security
Quality of
service
UDDI
Discovery
WSDL
Description
SOAP
XML
HTTP(S), IIOP, JMS, SMTP
Message
Transport
Standards That Enable SOA

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 an SOA approach, that is, using the Web service foundations of Simple Object Access
Protocol (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 an SOA implementation is based is
independence of hardware and operating systems used to implement the service functionality.
Standards That Enable SOA
Standards That Enable SOA (continued)

The slide groups the standards listed into the following categories:
Transport: The various protocol standards that can be used to communicate data
Message: Structuring and providing message data with XML schema and XML standards
Description: Exposing service function and data structures through WSDL standards
Discovery: Locating services in registries based on UDDI standards
Quality of service: Managing reliability, security, transactions, and coordination in using Web
services standards (WS-* standards)
Business process: Orchestrating services using the BPEL standard
Here are brief descriptions of the standards listed in the slide:
BPEL4WS: Is an XML-based language describing the rules for orchestrating a business
process that calls one or more services
WS-Reliability: Is a SOAP-based specification, managed by the Organization for the
Advancement of Structured Information Standards (OASIS) that fulfills reliable messaging
requirements critical to some applications of Web services
WS-Security: Is a protocol that provides a way to apply security to Web services
WS-Transactions: Is a specification that describes coordination types used with the extensible
coordination framework specified by WS-Coordination
WS-Coordination: Is a Web services specification that describes an extensible framework for
providing protocols that coordinate the actions of distributed applications
WS-Context: Is a specification to provide a definition of a structuring mechanism and a
software service definition for organizing and sharing context across multiple execution
endpoints. This enables context information such as WS-Addressing information that is
communicated via SOAP headers to be propagated across endpoints.
WS-Addressing: Specifies a mechanism for Web services to share addressing information
UDDI: Provides a platform-independent protocol and XML-based registry, which lists business
services and information on the Internet
WSDL Is an XML format used to publish and describe the operations and messages required to
call a Web service
SOAP: Is a protocol for exchanging XML-based messages across a network, normally using
HTTP
XML: Is widely used to describe Web services, describe UDDI registry data, define XML
schema documents, and define message structures for exchanging XML-based data between
services
HTTP: Is a method for transferring data across the World Wide Web. HTTP is widely used to
access and retrieve HTML pages.
IIOP (Internet Inter-ORB Protocol): Is the implementation of the General Inter-ORB
Protocol (GIOP). GIOP is the abstract protocol by which object request brokers (ORBs)
communicate based on standards maintained by the Object Management Group (OMG).
JMS: (Java Messaging Service) Provides a Java message-oriented middleware (MOM) API to
asynchronously communicate messages between multiple clients
SMTP (Simple Mail Transfer Protocol (SMTP): Is the default standard for sending emails
across the Internet
An SOA reference architecture is a blueprint to guide the

enterprise toward SOA success.
1. True
2. False
Answer: 1
Explanation: The SOA Reference architecture defines the target architecture and the principles to be
used by an organizations architects to make architecture and design decisions on their projects.
Quiz
A service:
Provides a unit of work as part of a business process
Performs a business function (such as validate credit card)
A Web service:
Is a software system or self-describing business function
Is designed to support interoperable machine-to-machine
interaction over a network
Communicates with clients through standard protocols and
technologies
Request
Response
Service Requester
Service Provider
Service and Web Service

A service can be defined as a well-defined, self-contained business function that:
Operates independently from the context or state of other services
Represents a unit of work performed by a component or part of an automated subprocess
A service is essentially a process that performs a specific business function, such as validating a
credit card submitted with a customer order. Business functions that are a subset of an existing
Enterprise Information System (EIS) (such as part of an Enterprise Resource Planning (ERP) system
and other application modules) can be represented as a service through adapters.
A suitable granular (modular) service design can enable a service to support many applications in an
enterprise that spans platforms and organizational components. For example, to find the number of
units sold for a particular product, the business function might need to query a sales management, a
sales order, and a product inventory system within an organization.
A Web service is a service that performs discrete business functions. Interaction with a Web service
is based on a set of standard protocols and technologies. Web services:
Make use of standard set of platform-independent messaging protocols (SOAP, HTTP, JMS)
Using standard protocols enable connections between services from any Web-connected device
Exchange data and functionality in XML format
Service and Web Service
Types of Service Access and Implementation
Created
from existing
functionality
Can be achieved
either by exposing
existing functionality
as Web services or
by using adapters
Service
access
Invoked
through
protocols and
methods
Service
access
Services can be
invoked by using
SOAP over HTTP,
JMS adapters, or
WSIF.
Created as
new
functionality
Can be developed by
using service bus
components, BPEL
processes, or Web
services implemented
with Java or Java EE

Before embarking on an SOA implementation, business requirements should be identified before you
can design, identify, or locate services that can support the business need. After the identification
task is complete, services and their operations and messages can be specified, thereby creating a
portfolio of services needed to meet the business requirements.
The implementation for the portfolio of services can be chosen from:
Existing functionality, provided by in-house applications already available for use. Existing
application functionality can be exposed through new interfaces and repurposed for an SOA
environment.
Enterprise Information Systems (EIS), and legacy applications, which have many custom
adapter interfaces that expose their functionality as services for integration purposes
New applications, which can be developed in languages that support Web service standards,
such as Application Development Framework Business Components (ADF BC), Java, and Java
EE, among others. New services can be developed if existing services do not meet identified
requirements.
Invocation of services, whether developed as a Web service or exposed through adapters (using Java
Connector Architecture standards) can be invoked using SOAP, Representational State Transfer
(REST), and Web Services Invocation Framework (WSIF) and potentially other ways.
Process and service integration can be done many ways:

Proprietary implementations: Typically integrate isolated
systems with a point-to-point approach
Vendor-specific implementations: Technology such as
Tuxedo enable integration using a consistent approach
Common Object Request Broker Architecture, (CORBA)
implementations: Programmatically intensive, widely
supported, and not widely used due to implementation cost
Web Service and, now, SCA style implementations: Using
XML and Web standards to integrate systems
Note: Not everyone agrees on the way to do SOA-enabled
implementations
Ways to Integrate Services

The points stated in the slide illustrate that integration can be done in many ways and forms, some of
which are proprietary approaches that have enabled silo (stand-alone) systems to be integrated,
typically in a point-to-point manner. This approach is less flexible and hard to maintain over time.
Technologies such as Tuxedo, a vendor-specific integration technology, enable systems to
standardize the way that they integrate their systems. Tuxedo until recently did not support Web
service standards, keeping the technology contained within an organization that embraced it. The
computing industry worked to create a standardized protocol and software integration method called
Common Object Request Broker (CORBA), that enabled systems to integrate by using a standard
(non XML-based) interface definition language for generating code templates that could be
distributed. Although it is entirely possible to apply an SOA approach with CORBA, the lack of its
wide use and accessibility, in addition to its remote procedure call mechanisms, make it costly to
implement and less friendly to use across an intranet or Internet. With the advent of Web services
and the common use of XML, WSDL, and XSD standards, SOA-based approaches have naturally
embraced these standards that enable easier interoperability across intranet and Internet networks.
Keep in mind that not every one agrees on the same implementation styles for Web servicesstyle
SOA implementations. For example, not all Enterprise Service Bus implementations are alike, nor
does everyone chose to implement BPEL for process orchestration. However, as we already know,
time changes many things.
Ways to Integrate Services
Designing with an SOA approach involves:

Aligning IT with the business needsdesign needs to be
driven by business process
Identifying services that performs functionality as part of a
business processbuilding a service portfolio
Designing standard message structures in XML format using
XML Schema Documents (XSD)
Specifying service interfaces in Web Services Definition
Language (WSDL) format
Selecting choice of service implementation
Java Web Services and J2CA Adapters

BPEL
SCA composite applications
.NET, among others
Designing with an SOA Approach

When designing systems integration approaches with an SOA-style implementation the focus is
always to be aligned with the business 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.
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 maintained and
changed to stay aligned with the business requirements.
After the business process flow and requirements are understood, when it comes to designing each
service, the key artifacts that require careful design are:
Service message structures that need to be exchange between service consumer and clients.
Design of message structures is a form of data modeling with respect to identifying what
information is needed by a service to perform its function.
Service interface definition, that is, the WSDL that describes the function that the service will
offer and associates the input and optional output message structures to each exposed function.
Designing a WSDL interface depends on understanding interactions, that is, how the service
will be used and if communicates synchronously or asynchronously.
Service functionality can be designed based on choice of implementation language or type.
Designing with an SOA Approach
Created with reusability in mind, a service portfolio:

Is identified from a set of services needed for implementing
one or more business processes within a business domain
Can be stored in an enterprise repository for design-time
and governance purposes
Can be accessed from a service registry at design time
and run time for location-independence and governance
Can be realized by:
Reusing functionality by wrapping as services, and using
adapter technology
Creating new services with SOA-enabled technology, such
as Web services, SCA composite applications, BPEL, and
service bus
Creating Service Portfolios

When embarking on a Service-Oriented Architecture approach to systems integration, systems
integrators begin by examining business process requirements and the business domain to identify
functionality that can be used as a service unit of work to help complete a business process. The
aim of building a system portfolio is to identify common functionality that can be decoupled and
exposed or used as a service within a business domain. While the business process drives the
identification of services, the analysts should always keep the goal of reusability in mind within the
business domain.
Note: Not all services or service-enabled applications should be reusable. Experience helps to find
the right balance.
After a collection of services has been identified to serve the business process and can be applied to a
business domain, the recommended practice is to store information about the servicestheir
interfaces and message structurein a common location such as an enterprise repository. This
facilitates and promotes sharing and reusability from the design phase through to production.
Coupled with a service registry, an enterprise repository can migrate service run-time information
into development, test, and production/operational environments. Coupling an enterprise repository
and service registry enable an organization to implement strong SOA governance strategies for
services throughout a service life cycle from design time to run time. A service registry enables
applications to look up a service by using a service key, for location independence.
Creating Service Portfolios
Basic data access and discrete

business logic services are
consumed within orchestration
layer services.
Agility is achieved by separating
core business logic and control
logic.
Business process management
systems provide the modeling
tools and execution environment
for creating these services.
Service A
Service B
Service C
SOA Workflow and Orchestration

A mature SOA leverages a service orchestration layer that is focused on delivering new services by
orchestrating the basic services provided by basic data access and business logic services. The key
architectural focus of this layer is agility. Agility is achieved by properly applying data aggregation,
process definition and workflow tools to create the desired services. Designing and developing
orchestration services requires domain expertise in integration processes and rules.
This layer is where the business logic is implemented and published as an enriched service.
In order to deliver on the promises of agility, it is essential to separate services into core business
logic and control logic. If the separation is thorough, changes to existing processes and the
introduction of new processes should happen smoothly because the impact can be minimized.,
helping to reduce redundancies and inconsistencies.
A business process management (BPM) system offers the necessary step-by-step execution
approaches and modeling techniques to implement the business logic of the newly composed
services. This implementation can cover complex business use cases that require maintaining state
information, loops, tests, and parallel execution. And these new services become in turn, reusable
components for building other services. So there is a very good fit between the BPM vision and SOA,
and both aim at increased flexibility for the enterprise IT.
With the powerful combination including service bus and BPM solutions, is possible to create more
powerful SOA solutions within organizations and across organizational boundaries to react more
quickly to frequently changing business requirements.
SOA Workflow and Orchestration
Build a portfolio of services (Web service, .NET, adapters).

Register and publish services (UDDI).
Decouple services through virtualization
and routing (mediator).
Web
application
Orchestrate services (BPEL).
Create user interfaces to initiate
and interact with services.
Orchestration
(process flow)
Mediator
UDDI Registry
Java
.Net
Adapter
Service
Portfolio
Implementing SOA: General Concepts

This graphic represents the conceptual goal of an SOA implementation. The principles of
implementing an SOA approach include:
Creating a portfolio of services. The basic building block of an Oracle SOA strategy is a
service. Services must be visible and accessible.
Publishing services in a UDDI registry. Services can be registered in a UDDI registry so that
they can be discovered and located across the Internet and intranet.
Virtualizing services by using mediators to further decouple (minimize dependences) between
service consumers from the service provider. The mediator can also manage the process of
moving, transforming, and filtering data transferred between service endpoints, thereby creating
a foundation layer (plumbing or glue) between services.
Orchestrating services with BPEL. BPEL enables the implementation of complex business
process flows that require short- and long-term interaction between services. Orchestrating
business processes may involve accessing services, published in the UDDI registry, or directly
from their endpoints. In addition, a BPEL process becomes a service.
Developing rich client applications to invoke or interact with services based on using the latest
Web technology and Web services standards
Implementing SOA: General Concepts
Services can be implemented using existing functionality.

1. True
2. False
Answer: 1
Explanation: Services can be implemented using existing functionality by exposing existing
functionality as services or by using adapters.
Quiz
SOA governance can be defined as:

A set of solutions, policies, and practices that enable
organizations to implement and manage an enterprise
SOA
An application of IT governance specifically focused on the
life cycle of services and composite applications in an
organizations service-oriented architecture
Policies
(What)
Decisions
(Who)
Processes
(How)
Define SOA Governance

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 organizations 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. In other words, it
is a framework for managing SOA assets in compliance with a companys standards, policies, and
business strategies specifically focused on the life cycle of services, policies, practices, metadata, and
composite applications.
Business value
Alignment
Business agility
Risk reduction
Cost savings
Identifying the Need of SOA Governance

SOA governance offers the following benefits:
Business value: Ensures that project investments yield business value
Alignment: Keeps SOA aligned with the business and architecture and in compliance with
business and IT policies
Business agility: Gains visibility into your SOA for more rapid decision making
Risk reduction: Controls dependencies, manages the impact of change, enforces policies
Cost savings: Promotes consolidation, standardization, and reuse
Identifying the Need of SOA Governance
The SOA governance framework is centered on the four

facets of enterprise architecture:
People
Process
Service
Technology
People
Service
Process
Technology
SOA Governance Framework

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 an 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.
SOA Governance Framework
The SOA governance framework is centered on _________,

process, technology, and service.
1. Strategy
2. Risk
3. People
4. Value
Answer: 3
Explanation: The four facets of enterprise architecture that the SOA Governance is centered on are:
Process
Technology
Service
People
These are the deciding factors for designing the SOA Governance Framework.
Quiz
Course Case Scenario: Purchase Order Processing

Purchase order processing is an SOA composite application that implements the following:
Purchase order processing and approval
Details for the purchase order are received from multiple sources.
Large order quantities (quantities greater than or equal to 10 units) pass through a validation
and approval process (where the customer's credit card status is validated)
Approved order details having the status of Approved are written into a text file. An
unapproved order will have the status Rejected/Invalid written into the text file.
Course Practice Scenario:

Purchase Order Processing
In this lesson, you should have learned how to:

Explain the need to implement service-oriented
architectures
Describe SOA
Identify standards that enable SOA
Describe the SOA Maturity Model
Describe basic interaction patterns
Explain the role of SOA governance
Summary
In this lesson you identified the need for implementing a Service-Oriented Architecture,the various
standards that enable a Service-Oriented Architecture, and the importance of reference architecture.
The next lesson,Implementing SOA with Oracle SOA Suite, discusses Oracle SOA Suite
architecture and its components.
Summary
This practice covers designing a business flow diagram for

purchase order processing
Practice 1 Overview:
Preparing the Business Flow Diagram
Implementing SOA with Oracle SOA Suite
SOA
In this Implementing SOA with Oracle SOA Suite" lesson, you will be
introduced to the installable components that come as a part of Oracle SOA
Suite 11g, the different service components, and the role of Enterprise Manager
in performing the basic administrative tasks related to the SOA environment.
Course Roadmap
In the Service-Oriented Architecture Concepts lesson you were familiarized with the ServiceOriented Architecture (SOA) concepts and the activities that are involved in adopting SOA.
The Implementing SOA with Oracle SOA Suite 11g lesson talks about Oracle SOA Suite 11g
architecture and the various service components that implement the business logic of an enterprise.
Course Roadmap

List the Oracle SOA Suite 11g components
Describe the service components
Define a composite application
Explain the role of Enterprise Manager
Objectives
This lesson introduces the Oracle SOA Suite 11g architecture and its components at an introductory
level. Additional related products such as Oracle BAM are discussed along with Oracle SOA Suite
and they provide a comprehensive solution for SOA implementation.
Objectives
3
ESB
BPEL
B2B
IF
Adapter
2
1
1
Legacy System
Web Service
IF
6
Human Workflow
Rules
Engine
Adapter
2
1
Web Service
BAM
Database
Basic Components of an SOA Infrastructure

The basic components of an SOA infrastructure are:
1. Web services, legacy services, and database services, which contains the business data and the
business logic
2. Adapters to enable legacy services and database services to interact and communicate with the
outside world
3. Enterprise Service Bus (ESB), which provides a common platform for these services to share
data, enrich and transform data, and route data to specific services
4. Rules engine, which enables externalizing business rules and provides agility to the business
5. Business Process Execution Language (BPEL), which enables a workflow design to orchestrate
services to obtain required business goals
6. Human workflow to enable human intervention in a BPEL process
7. Business Activity Monitoring (BAM) to visualize and monitor SOA components
Basic Components of an SOA Infrastructure
Message
Event
Mediator
Business
rules
BPEL
Human
workflow
JDeveloper
Event Delivery Network (EDN)

Enforcement points
WS Policy
Manager
Service infrastructure
SOAP
B2B
BAM
JMS
Others
MDS
Registry
EM and SOA
console
Oracle SOA Suite 11g Components

Oracle SOA Suite 11g is a complete set of service infrastructure components for creating, deploying,
and managing SOA applications. Oracle SOA Suite 11g enables services to be created, managed, and
orchestrated into composite applications and business processes. Oracle SOA Suite 11g runs
primarily on the WebLogic Server.
The components that form a part of the SOA installation are:
Service Infrastructure: This provides the internal message routing infrastructure capabilities
for connecting components and enabling data flow.
Oracle Mediator: This routes data from service providers to external partners. In addition, it
can subscribe to and publish business events.
Oracle Adapter: Oracle Adapters use JCA technology to connect external systems to the
Oracle SOA Suite.
Business Events and Event Delivery Network: Business events are messages sent as the
result of an occurrence or situation, such as a new order or the completion of an order. In
Oracle SOA Suite, the Oracle Mediator service component subscribes or publishes events.
When an event is published, other applications can subscribe to it.
Oracle SOA Suite 11g Components
Oracle SOA Suite 11g Components (continued)

Metadata Service Repository: The Metadata Service Repository stores business events, rule
sets for use by Oracle Business Rules, XSLT files for Oracle Service Bus and Oracle Mediator,
XSD XML schema files for Oracle BPEL Process Manager, WSDL files, and metadata files for
Complex Event Processing.
Oracle Business Rules: Oracle Business Rules, initiated by a BPEL process service
component, enable dynamic decisions at run time allowing you to automate policies,
constraints, computations, and reasoning while separating rule logic from underlying
application code.
Oracle WSM Policy Manager: This provides the infrastructure for enforcing global security
and auditing policies in the Service Infrastructure.
Oracle BPEL Process Manager: This provides the standard for assembling a set of discrete
services into an end-to-end process flow, radically reducing the cost and complexity of process
integration initiatives.
Human Task: Human Task enables users to interact with business processes and perform tasks
needed to complete the process. Workflow services are typically linked to a business process
through Web services. The process assigns a task to a user or role and waits for a response. The
users act on the task using Oracle BPM Worklist.
Oracle BAM: Provides a complete solution for building real-time operational dashboards and
monitoring and alerting applications over the Web.
Oracle User Messaging Service: This provides a common service responsible for sending out
messages from applications to devices as well as routing incoming messages from devices to
applications.
Oracle B2B: This is an e-commerce gateway that enables the secure and reliable exchange of
messages between an enterprise and its trading partners. It is a binding component of the Oracle
SOA Suite, and this platform enables the implementation of complete end-to-end e-commerce
business processes.
Oracle JDeveloper: This is the development component of Oracle SOA Suite. It forms a
comprehensive Integrated Service Environment (ISE) for creating and deploying composite
applications and managing the composite.
Oracle Enterprise Manager: You can configure, monitor, and manage the components of
Oracle SOA Suite from Oracle Enterprise Manager Fusion Middleware Control.
This provides the internal message routing infrastructure

capabilities for connecting components and enabling data flow.
Service/Event Delivery API
Mediator
Event
Route
Filter
Transformation
Enforcement
point policies
Service
infrastructure
Metadata
store
JCA
Other (adapters)
UDDI bindings
registry
SOAP
Introduction to Service Infrastructure

The service infrastructure, which includes the Mediator component, provides:
An optimized internal communication path between service engines (such as BPEL or
Mediator) through a normalized message structure
An event delivery network that supports an event-driven architecture for event-driven
applications
A multi-protocol access layer through binding components (SOAP, JMS, JCA bindings)
Introduction to Service Infrastructure
The SCA application, known as the SCA Composite,

represents a new approach to SOA-style implementations. SCA
Composite applications are:
Introduced as the new way of developing an assembled
SOA-style application in Oracle SOA Suite 11g
Composed of several co-operating components to meet a
business process requirement. SCA components include:
Mediator (previously known as Oracle ESB)

BPEL process
Human Task
Business Rules
Deployed as a single composite application, including the

component implementations
Introducing SCA in Oracle SOA Suite 11g

The Service Component Architecture (SCA) specifications define a new way of assembling SOAenabled applications known as the SCA Composite. The SCA Composite is developed and deployed
as a single service that includes all the components that it assembles to form the application
implementation. In Oracle SOA Suite 11g, an SCA Composite, called an SOA Composite
application, may contain one or more co-operating component types such as:
A Mediator component for message routing within the composite, transformation, and filtering
capabilities
A BPEL process component for service orchestration to manage more complex service
interactions
A Human Task component to implement human workflow capabilities
A Business Rules component to enable specification of rules that are executed external to a
process context and used to influence a process flow and its outcomes
Each of these Oracle SOA Suite 10g components conforms to the SCA component specifications.
When assembled together into a composite application they are managed, maintained, and deployed
together. This approach streamlines and simplifies management of cooperating service components
compared to previous versions of Oracle SOA Suite 10g and other technologies that manage SOA
applications as a set of individual yet cooperating services. The SOA composite application is a type
of coarsely-grained service by virtue of the fact that its functionality can be exposed as a service
through service entry points.
Introducing SCA in Oracle SOA Suite 11g
A composite application is a service that defines an

assembly model that consists of:
Service components that implement the business logic or
processing rules
Bindings components to enable communication between
composites or between the service component and the
external services, application, or technologies
Wiring that connects the components for message
communication
The service components that can be assembled are:
Mediator
Business Process Execution Language (BPEL)
Human Task
Business Rule
Defining a Composite Application

A composite application is defined in terms of the service components implementing the business
logic, including the following binding components:
Services that provide an entry point for messages received from the outside world into the
composite application
References that enable messages to be sent from the composite application to external service
partner links in the outside world
Wires that graphically connect entities in a single composite application for message
communication
Service components that can be assembled include:
BPEL process
Business Rules
Mediator
Human Task
Binding styles include:
SOAP bindings
SDO bindings
JCA Adapters, among others (WSIF)
Defining a Composite Application
Defining a Composite Application (continued)

The composite application is a service in that it is designed and deployed together as a single
application with its own service interface (WSDL). The assembly information is stored in an SCA
Descriptor called composite.xml, which is a language-independent representation of the
composition of services for a business solution.
Oracle Mediator enables routing data between the service

consumer and provider based on routing rules.
The Mediator supports both the synchronous and
asynchronous routing of data.
Mediator component
created in the SOA
Editor
Introducing Oracle Mediator Component

Oracle Mediator enables you to route data synchronously or asynchronously between service
producers and consumers. Oracle Mediator provides a lightweight mediation framework to mediate
between various producers and consumers of services and events. The challenge of integrating data
from disparate sources (including business partners, legacy applications, enterprise applications,
databases, and custom applications) can be met by using Oracle Mediator to deliver appropriate realtime data access to all applications that update or have a common interest in the same data. For
example, an Oracle Mediator service component can accept data contained in a text file from an
application or service, transform it to a format appropriate for updating a database that serves as a
customer repository, and then route and deliver the data to that database.
Oracle Mediator facilitates integration between events and services where service invocations and
events can be mixed and matched. You can use a Mediator component to consume a business event
or to receive a service invocation. A Mediator component can evaluate routing rules, perform
transformations, validate, and either invoke another service or raise another business event. You can
use a Mediator component to handle returned responses, callbacks, faults, and timeouts. In addition,
you can also implement a variety of integration patterns such as service virtualization, publish and
subscribe, fan-in, and fan-out, and various synchronous and asynchronous request response patterns.
Introducing Oracle Mediator Component
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
Describing the Features of Oracle Mediator Component

Oracle Mediator includes the following features that facilitate the integration between message
providers and consumers:
Subscribe to and publish business events
Perform content-based and header-based routing
Support both synchronous and asynchronous interactions
Perform transformations and validations on the message data
Apply filters to the message data
Support error handling
Implement a variety of integration patterns, such as:
- Service virtualization: Virtual services are exposed as interfaces that consumers can
connect to via Web services.
- Integration between services and events: The Mediator component facilitates
integration between events and services where services, invocations, and events can be
mixed and matched. It can be used to consume a business event or to receive a service
invocation. A Mediator component can evaluate routing rules, perform transformations,
validate, and either invoke another service or raise another business event.
- Publish and subscribe: One input channel splits into multiple output channels, one for
each subscriber.
Describing the Features of Oracle Mediator

Component
The Oracle BPEL Process integrates a series of business

processes and services into an end-to-end process flow
using the concept of process orchestration.
Process orchestration orchestrates services in a process
from a single run-time environment.
BPEL Process
component created in
the SOA composite
application Editor
Introducing Oracle BPEL Process Component

The process orchestration concept encompasses the idea of coordinating services in a business
process from a single run-time environment. Orchestration:
Directs and manages an on-demand assembly of multiple services
Results in the creation of a composite application forming a business process
Industry has now converged on using the Business Process Execution Language for Web Services
(BPEL4WS) as the core standard for Web services orchestration, simply known as Business Process
Execution Language (BPEL).
Oracle BPEL Process Manager provides a run-time environment for executing composite
applications developed in BPEL. The BPEL process runs in a specific run-time container to
coordinate one or more services to complete a business process (flow).
Introducing Oracle BPEL Process Component
Oracle Business Rules is a high-performance lightweight

business rules product that delivers agility and enables
businesses to change their key decisions and policies
rapidly and flexibly.
Oracle Business Rules is seamlessly integrated with
Oracle BPEL PM and the rest of the SOA stack.
Business Rules
the SOA composite
application Editor
Introducing Business Rules Component

Business rules technology is designed to automate business rules expressed declaratively as rules and
policies. The rules and policies are extracted from procedural code and logic and created
declaratively as if-then-else constructs or as decision tables. This enables the rules and policies to be
easily created and edited by a business user, not necessarily a technical person.
With an inference-capable business rules engine, such as Oracle Business Rules, declaratively
expressed rules can be executed.
Business rules are:
Extracted from processes and procedural logic
Expressed declaratively
Executed in an inference-capable business rules engine
Edited by business users
Introducing Business Rules Component
Oracle BPEL Process Manager enables human

participation in end-to-end processes.
It allows you to assign a task to a user or a role.
Human Task
the SOA composite
application Editor
Introducing Human Task Component

The Human Task component enables you to assign a task to a user or role. The user acts on the task
by using Oracle Worklist. The business process waits for a response from the assigned user before
processing the activity.
An example of interleaving interactions is a purchase order that may need to go through various
levels of approval, depending on the monetary limits of various approvers.
Introducing Human Task Component
The _________ is a component that uses the concept of

Process Orchestration.
1. Mediator
2. Human Task
3. BPEL
4. Business Rule
Answer: 3
Explanation: The BPEL component uses the concept of orchestration wherein services are
coordinated in a business process from a single run-time environment.
Quiz
Monitors key business metrics in real time, such as key

performance indicators (KPIs) or service-level agreements
(SLAs)
Analyzes real-time data to identify bottlenecks, exceptions,
and solutions to business problems
Acts on current conditions either automatically or manually
from a dashboard in order to meet business needs
Oracle BAM
BPEL PM
Oracle JMS
Oracle DB
Other
Technologies
Interface to
external
technologies
Oracle DB
repository
Real-time dashboard reports
Introduction to Business Activity Monitoring

Oracle Business Activity Monitoring (Oracle BAM) provides facilities to monitor business activities
across an enterprise. Oracle BAM has the ability to collect events from all the following integration
components:
Service infrastructure, from the BPEL and CEP service engines
Web services
Oracle Data Integrator (ODI)
JMS connector
Business insight is delivered though the ability to monitor business activity in business processes.
Oracle Business Activity Monitoring (Oracle BAM) tools enable the real-time reporting capabilities
to deliver the capability of providing real-time business insight.
Using BPEL sensors you can instrument a BPEL process to generate data for consumption by Oracle
BAM. Sensors can be defined on selected business activities for monitoring business performance
data, process data and operations, and faults.
Introduction to Business Activity Monitoring
Sensor
Monitor
BPEL
BAM dashboard
Monitoring Services with BPEL and BAM

Business insight is delivered though the ability to monitor business activity in business processes.
Oracle Business Activity Monitoring (Oracle BAM) tools enable the real-time reporting capabilities
to deliver the capability of providing real-time business insight.
Using BPEL sensors, you can instrument a BPEL process to generate data for consumption by Oracle
BAM. Sensors can be defined on selected business activities for monitoring business performance
data, process data and operations, and faults.
Monitoring Services with BPEL and BAM
The Oracle Enterprise Manager (EM) Fusion Middleware

Control Console enables you to perform administrative tasks
such as:
Configuration
Monitoring
Management
Oracle Enterprise Manager

The Oracle Enterprise Manager enables the following:
Performing configuration tasks, which consist of setting values to the different properties in the
SOA environment. Properties can be set in the following areas:
- SOA infrastructure (impacting all SOA composite application applications)
- Service engines (impacting all service components that execute in the engine, no matter
the SOA composite application application in which they are included)
- SOA composite application application (impacting all service components that are
included in that composite application application)
- Oracle B2B bindings
- The message header properties for service and reference binding components
Monitoring Oracle SOA Suite, which includes:
- Instances, faults, and rejected messages in SOA infrastructure, SOA composite
application applications, service components, service engines, and service and reference
binding components
- Performance of service engine, service infrastructure, and binding component
- The average and total time taken to process requests from the service and reference
binding components
- Audit trail and process flow behavior in service components
- Service engine request and thread states in BPEL processes and human workflows
Oracle Enterprise Manager (continued)

Managing Oracle SOA Suite includes:
- The startup and shutdown of the SOA infrastructure application
- Composite application state (activating, retiring, starting, and stopping, and setting the
default composite application applications version)
- The deleting and aborting of composite application instances
- Deployment, undeployment, and redeployment actions for SOA composite application
applications
- Initiation of SOA composite application application test instances
- Recovery from faults in SOA composite application applications, service components,
service engines, and business events
- Manual recovery of failed messages in BPEL processes
- Unit testing of SOA composite application applications
- Attachment of policies to SOA composite application applications, service components,
and binding components
- Incoming and outgoing notification messages in human workflow
- Subscriptions to business events and testing
Is a Java EE server implementation

Key features:
Implements Java EE 1.5 Specification

Runs on standard JVM
Provides high performance and scalability
Is productive for developers to use
Is simple to manage and deploy
Provides clustering for high availability and failover
Oracle WebLogic Server 10.3

Oracle WebLogic Server (WLS) provides a complete Java EE server implementation. It is written in
Java and executes on the standard JVM. WLS 10.3 is compatible with Sun SDK 1.6 and BEA
JRockit 1.6 JDK versions.
Oracle WebLogic Server 10.3
A domain:
Is an administrative unit or boundary
Allows for a single point of administration for a collection of
servers
MyDomain
Server 2
Server 1
Server 3
Machine 1
Machine 2
WebLogic Server Domain

A domain is simply an administrative unit. Essentially, the scope of a domain is the scope from
which an administration server can see all of its managed servers.
Servers do not have to be assigned to a machine. If a server is not assigned to a machine, it is
assumed to be on a different machine than the other servers.
WebLogic Server domains can be used to separate:

Development, test, and production applications
Administration and operational responsibilities
Organizational or business divisions
Domain1 (Development)
Application 1
Application 2
Domain2 (Production)
Application 1
Application 2
WebLogic Server Domain (continued)

A BEA WebLogic Server domain is an administrative feature. There are no WLS programming
interfaces that refer to domains. All domain-related information is in the configuration files; only an
administrator is aware of domains.
Benefits of Multiple Domains
An enterprise can have different kinds of applications, be geographically dispersed, and be organized
into different areas of responsibility. There might be many separate domains. Each domain is a
separately administered unit. Perhaps it is organized for geographical considerations (all the
machines in a given location) or organized along departmental lines within an enterprise (accounting,
manufacturing, shipping, and so on).
Eventually, an enterprise may want the different applications in those domains to be able to
interoperate. It is often impossible to expand a single domain to encompass the enterprise. However,
the size of an expanded domain in terms of the number of machines and services could be
impractical. Because a single domain must be administered as a whole, the configuration would
rapidly become huge and require more effort in administering than in developing and implementing
applications.
Therefore, to keep a domain relatively compact for administration, there must be a way to separate
applications into multiple domains and still allow applications in one domain to access services in
other domains. This capability for interdomain communication is made possible by the WLS Domain
feature.
A server is a WebLogic Server instance executing within a

JVM.
A server:
Can be associated with at most
one WLS machine
Has a dedicated amount of RAM
Is multithreaded
Server 1
Server 2
WebLogic Server Servers

A WebLogic Server server is simply a JVM that is executing the weblogic.Server class. The
weblogic.Server class is the class that contains the main() method of the WebLogic Server
system. It is the primary controller for the system. Because a server executes within a single virtual
machine, it has a dedicated amount of RAM that is predetermined at system boot time. A server can
be associated with only a single machine, but a machine can be associated with multiple servers.
WebLogic Server Servers
An administration server is:

The central point of control for a domain
The keeper of the XML configuration repository
The central source for logging information
Runs the
Admin console
LOGS
Critical domain
notifications
(logs)
Administration
server
Configuration
repository
(config.xml)
Administration Server
A WebLogic Server running the administration service is called an administration server. The
administration server provides the central point of control for configuring and monitoring an entire
domain. The administration server must be running in order to perform any management operation
on that domain. In a configuration with multiple WebLogic Servers, only one server is the
administration server; the other servers are called managed servers. Each managed server obtains
its configuration at startup from the administration server.
Administration Server
A managed server:
Is an instance of WebLogic Server
Loads its configuration remotely from an administration
server
MyDomain
Managed server
Managed server
Administration
server
Managed server
Managed Server
A managed server is a single server that boots on a remote, or perhaps the same, physical machine
and loads its configuration from a specified administration server. Managed servers get all of their
configuration information from the remote administration server and need only know the domain and
server they represent in a domain.
Managed Server
A machine:
Represents the physical piece of hardware that a server
resides on
Can be a UNIX (Solaris, HP-UX, AIX, Linux) or non-UNIX
type (NT, OS-390, Mainframe)
One or more server instances can reside on a single

machine.
Server 2
Server 1
Server 3
Machine 1
Machine 2
WebLogic Server Machines

A machine is a piece of hardware that can have multiple CPUs and IP addresses. Typically, a
machine is managed by a single operating system that supports all the networking communications
with the hardware. WebLogic Server makes a distinction between UNIX machines and non-UNIX
machines.
WebLogic Server Machines
The Oracle JDeveloper IDE environment provides design and

edit tools that enable the creation of SOA composite
applications.
SOA service
components
SOA Composite
Editor
SOA Development with Oracle JDeveloper

This graphic shows Oracle JDeveloper IDE environment with many design and edit tools that enable
you to create SOA composite applications and SOA component implementations. JDeveloper
provides the following tools to develop services for SOA implementations:
Composite Editor
BPEL Process Designer
Mediator Designer
Rules Designer
Human Task Designer
Java Web service generator
Java coding environment
WSDL Editor
XSD Editor
XSLT Mapper
JDeveloper provides tools to package and deploy your SOA composite applications as applications to
a target run-time environment.
SOA Development with Oracle JDeveloper
Creating Connections in Oracle JDeveloper

In JDeveloper, you can create connections by using wizards for your development and deployment
environments. From the File menu in JDeveloper, select New. The New Gallery dialog box opens.
From the General category, select Connections. The following are the different connections that can
be created:
Application Server Connection: To create a connection to a Standalone OC4j, WebLogic, and
so on. This option is always enabled.
BAM Connection: To create a connection to a BAM server
BPA Server Connection: To create a connection to a BPA server
CVS Connection: To create a connection to a server for CVS Version Control. This connection
can be used for browsing and manipulating files stored in a CVS Repository. This option is
always enabled.
Database Connection: To create a database connection
File System Connection: To create connections to a local file system
SOA-MDS Connection: To create a connection to a file or database MDS server
Creating Connections in Oracle JDeveloper
Create Connections in Oracle JDeveloper (continued)

Subversion Repository Connection: To create a connection to a subversion repository
UDDI Registry Connection: To create a connection to an internal or external UDDI registry.
This connection can be used for browsing Web services.
URL Connection: To create a connection to a URL
WebDAV Connection: To create a repository connection to a Web-based Distributed
Authoring and Versioning-enabled (WebDAV) server. This connection can be used for
browsing and managing files stored on the server.
WSIL Connection: To create a connection to a WSIL file or URL. This connection can be
used to browse for Web services.
Step 1 of 7
Step 2 of 7: Type
Step 3 of 7: Authentication
Creating an Application Server Connection in Oracle JDeveloper

You need to create a connection from JDeveloper to the Oracle WebLogic Server configured for
Oracle SOA Suite in order to deploy from JDeveloper. The application server connection can be
created by performing the following steps:
1. Select New from the File menu. In the New Gallery, in the Categories tree, select General, and
then Connections.
2. Select Application Server Connection.
3. Click OK. The Create Application Server Connection Type page is displayed.
4. Enter WLS_AppserverConnection in the Connection Name field and select WebLogic 10.3
from the Connection Type list.
5. Click Next.
Creating an Application Server Connection in

Oracle JDeveloper
Step 4 of 7: Configuration
Step 5 of 7: Test
Step 6 of 7: Completion
Step 7 of 7: View
Creating an Application Server Connection in Oracle JDeveloper (continued)

The Connection Authentication page is displayed.
6. Enter the Weblogic Server username and password.
7. Click Next. The Configuration Page is displayed. Enter the following values:
Weblogic Hostname (Administration Server): localhost
Port: 7001
WLS Domain: soabam_domain (or the appropriate domain name for the environment)
8. Click Next. The test page is displayed.
9. Click Test Connection.
10. If the status is successful, click Finish.
Note: If the test is unsuccessful, ensure that Oracle WebLogic Server status is running, and retry the
test.
Creating an Application Server Connection in

Oracle JDeveloper
The integration of services to meet business requirements

and needs
An SCA approach to implementing a composite application
Unified design time to model and define composites
Single, unified run time for deployment and management
Single implementation and enterprise-view of business
services
Standardized process and technologies
Standards-based integration
Goals of Implementing SOA Application with Oracle SOA Suite 11g

The benefits of implementing SOA Application using Oracle SOA Suite 11g include:
Unified, simplified data access
Flexible architecture that enables business and IT agility
Single implementation and enterprise-view of business services
Business process standardization
Incremental development and deployment
Goals of Implementing SOA Application with

Oracle SOA Suite 11g
Oracle Enterprise Manager performs administrative tasks such

as _____________, _______________ and _____________.
1. Configuring
2. Monitoring
3. Managing
4. Orchestrating
Answers: 1, 2, 3
Explanation: The Oracle Enterprise Manager enables the following:
Performing configuration tasks, which consist of setting values to the different properties in the
SOA environment
Monitoring Oracle SOA Suite such as performance of service engine, service infrastructure,
and binding component and Audit trail and process flow behavior in service components
Managing Oracle SOA Suite such as startup and shutdown of the SOA infrastructure
application and recovery from faults in SOA composite applications, service components,
service engines, and business events
Quiz
The Oracle JDeveloper IDE provides design and edit tools that
enable the creation of SOA composite applications.
1. True
2. False
Answer: 1
Explanation: JDeveloper provides tools to package and deploy your SOA composite applications as
applications to a target run-time environment.
Quiz

List the Oracle SOA Suite 11g components
Describe the Service components
Explain the role of Enterprise Manager
Summary
This lesson described the installable components that come as a part of the Oracle SOA Suite 11g,
the different service components, and the role of the Enterprise Manager in performing the basic
administrative tasks related to the SOA environment.
The next lesson shows you how to identify the need for governance in a managing an enterprise
SOA, and explains Oracles SOA Governance solution.
Summary
This practice covers the following topics:

Creating a connection to the Oracle WebLogic Server from
JDeveloper
Browsing an existing SOA application from JDeveloper
Creating Connections in JDeveloper
SOA Governance and Service

Life-Cycle Management
SOA
In this SOA Governance and Service Life-Cycle Management lesson, the need
for governance in a Service-Oriented Architecture environment is highlighted.
The different characteristics related to service management are also introduced.
Course Roadmap
In the Implementing SOA with Oracle SOA Suite lesson you were familiarized with Oracle SOA
Suite 11g architecture and the various service components.
The SOA Governance and Service Life-Cycle Management lesson, the need of governance in a
Service-Oriented Architecture environment is highlighted.
Course Roadmap

Define service life-cycle management
Define service management
Identify the characteristics of service management
Describe the need for managing services
Define the need for and benefits of governance
Describe the SOA governance solution
Objectives
Service life-cycle management addresses how services

are developed, deployed, and managed.
It can be broken into two main facets:
Service development and delivery management
Infrastructure and management in support of SOA
Service
development
and
delivery
management
Service
life-cycle
management
Infrastructure and
management
Define Service Life-Cycle Management

Service life-cycle management ensures:
Quality, performance, and proper usage of the services published
Service visibility and reuse
Service versioning and security
The two facets of service life-cycle management are:
Service development and delivery management: It handles change and release management
(when, what, and by whom can services be changed), requirements and quality management,
and process management of services. It ensures that sound design and development principles
are adhered to, services are developed in alignment with business requirements, and functional
and performance compliance is maintained.
Infrastructure and management in support of SOA: It manages service security and access
control across multiple applications and platforms. It consistently enforces security policy for
services.
Define Service Life-Cycle Management
Automation
Design
Build
Publish
Deploy
Manage
Consume
Retire
Phases of Service Life Cycle

The different phases of the service life cycle are:
Design: Services aligned with corporate and IT policies and architectural principles
Build: Services implemented with enforced application policies and design principles
Publish: Services published for broader exposure for reuse; approval workflows applied
ensuring that services comply with design-time policies and categorization
Deploy: Services deployed with policies required for consumption
Manage: Service-level agreement policies enforced for services and their consuming
applications
Consume: Services consumed while routing, security, management, and transformation
policies are enforced. Consuming applications can go back through publish and deploy steps.
Retire: Disables new consumption of services or assets and informs users of life-cycle changes
The phases of the service life cycle can be broadly categorized into a design phase and a run-time
phase. In the design phase the service architecture team identifies an organizations business needs
and models a number of services and application interfaces to support those needs. In other words,
this phase would include identifying business processes, service modeling, and building the service.
In the run-time phase, on the other hand, the services that are modeled are used as a roadmap for
service creation and exposed as run-time offerings to the organization.
Phases of Service Life Cycle
Service life-cycle management ensures the flexible

categorization of services.
It has an automated capture of relationships between
services and business processes that enables impact
assessment.
It enables reporting on key metrics to support planning and
assessment.
The Need for Service Life-Cycle Management

Service life-cycle management enables effective management of services to ensure the delivery of
the highest possible business value over time.
As the number of services increases, identifying the correct service and when and where it is needed
requires flexible categorization, which is possible using effective service life-cycle management.
The Need for Service Life-Cycle Management
SOA governance can be defined as:

A set of solutions, policies, and practices that enable
organizations to implement and manage an enterprise
SOA
An application of IT governance specifically focused on the
life cycle of services and composite applications in an
organizations Service-Oriented Architecture
Policies
(what)
Decisions
(who)
Processes
(how)

Governance is essentially about ensuring that business is conducted properly. It is less about control
and strict adherence to rules, and more about guidance and effective and equitable use of resources to
ensure sustainability of an organizations strategic objectives. Governance is a process that is
influenced by organizational behavior and the establishment of structured processes. Technology is
there to help automate the governance process at much as possible. In other words, it is a framework
for managing SOA assets in compliance with a companys standards, policies, and business strategies
specifically focused on the life cycle of services, policies, practices, metadata, and composite
applications.
An effective governance model must address the following three questions:
What decisions must be made to ensure effective management and use of IT?
Who should make these decisions?
How will these decisions be made and monitored?
Though governance addresses these questions, it is the management that actually implements the
governance.
Corporate governance
Supports
Supports
Aligns
IT governance
EA governance
Extends
Extends
SOA governance
Relationship of Governance Disciplines

SOA governance is a natural extension of existing governance disciplines. It provides a structure for
aligning business and IT goals as SOA evolves. SOA governance is an extension of IT and enterprise
architecture (EA) governance, which in turn supports corporate governance.
Corporate governance is the system by which business corporations are directed and controlled. The
corporate governance structure specifies the distribution of rights and responsibilities among
different participants in the corporation, such as the board, managers, shareholders, and other
stakeholders, and spells out the rules and procedures for making decisions on corporate affairs. By
doing this, it also provides the structure through which the company objectives are set and the means
of both attaining those objectives and monitoring performance.
IT governance helps ensure that IT supports business goals, optimizes business investment in IT, and
appropriately manages IT-related risk and opportunities.
EA governance is more complicated than the IT governance and is concerned with architecture
governance. The focus of governance in a SOA environment is to ensure that the service-oriented
strategy is realized in capabilities, assets, and processes that deliver the required levels of business
and technical adaptability. It provides the framework for managing SOA assets in compliance with a
companys standards, policies, and business strategies specifically focused on the life cycle of
services, policies, practices, metadata, and composite applications.
Relationship of Governance Disciplines
Business value
Alignment
Business agility
Risk reduction
Cost savings
The Need for SOA Governance

Business value: Ensures that project investments yield business value
Alignment: Keeps SOA aligned with the business and architecture and in compliance with
business and IT policies
Business agility: Gains visibility into your SOA for more rapid decision making
Risk reduction: Controls dependencies, manages the impact of change, and enforces policies
Cost savings: Promotes consolidation, standardization, and reuse
The Need for SOA Governance
Ensures an applications adherence to reference

architecture
Offers the proper utilization of services
Ensures quality of services
Focuses on business continuity and measures to protect IT
assets
Controls dependencies, manages the impact of change,
and enforces policies
Promotes consolidation, standardization, and reuse of
assets
Benefits of Service Governance

Governance is also needed for alignment. SOA is after all an architecture used to solve the business
goals and objectives. Getting visibility into the SOA ecosystem will enable an organization to
understand where it is getting the most out of its investments and whether or not it is meeting
organizational objectives.
Business agility is something that SOA promises. This agility is accomplished through reusing or
sharing services to quickly assemble applications to meet new business objectives. Without SOA
governance, you will not have the visibility into what exists, and this lack of visibility makes it
difficult to accomplish the goal of agility.
Risk reduction is one of the biggest needs surround SOA governance. Governance lowers the risk
associated with SOA by ensuring that services are developed in alignment with business and IT
objectives and policies. It then allows you to manage what has been created, along with its
dependencies, and compare that to how it is actually operating in production. This level of visibility
significantly lowers the risk associated with change.
Through all of the preceding benefits, IT becomes more efficient, resulting in cost savings over time.
Benefits of SOA Governance
Successful SOA and SOA governance implementations

focus on organizational change and change management.
Implementation of governance should be centered on
people, process, technology, and services.
One mechanism to implement an enterprise IT and SOA
governance is by establishing a center of excellence
(CoE).
The CoE is a group that enables a shared resource and
capability center to function as a resource pool as new
business application need arises.
Center of Excellence: Key to SOA Success

CoE supports organizational change and change management keeping in lieu with the overall SOA
governance plan. Embarking into SOA creates a new environment for both business and IT, and there
is a need to focus on the impacts of the new environment. The CoE supports the change by
leveraging the assets and best practices developed by the organization.
A governance implementation needs to be supported by a hierarchical organizational reporting
structure.
Center of Excellence: Key to SOA Success
Business Governance
Steering Committee
CoE Governance Leadership Team
Initiative
Team
Initiative
Team
Project
Team
Project
Team
Example of Governance Organizational Structure

A governance organizational structure can be categorized into the following four hierarchies:
Sponsorship level: It essentially consists of stakeholders in the steering committee. The
steering committee articulates the business strategy, goal, and vision for the enterprise.
Members of this level are the key decision makers on how IT investments need to be made and
channeled to specific areas of business need.
Leadership level: The leadership team learns the business strategies and visions from the
sponsorship members and also obtains directives from and reports to the steering committee.
The leadership team creates enterprise IT architecture and SOA principles that stand as overarching rules which any application architecture needs to conform to.
Opportunity management level: Separate teams are formed at this level, each focusing on one
or more (related) business needs. Each team is responsible for developing clear definitions of
business applications that cater to a given enterprise business need. Each initiative team has a
business team lead responsible for gathering and formalizing the business requirements.
Project management level: Teams at this level manage the entire life cycle of a typical
application design and development through the phases of solution definition, solution outline,
macro design, micro design, build, test, and deploy. Each project team is aligned with a given
initiative team. It is very common to have multiple simultaneous projects being run under a
given initiative team.
Example of Governance Organizational Structure
SOA governance is an extension of ___________ and ______.

1. IT governance
2. Security
3. EA governance
4. Discipline
Answers: 1, 3
Explanation: SOA governance is a natural extension of existing governance disciplines. SOA
governance is an extension of IT and enterprise architecture (EA) governance, which in turn supports
corporate governance.
Quiz
Service life-cycle governance complements an enterprises

existing service engineering and operational process by
adding formal control points to monitor and enforce
policies.
It ensures that:
Services are following enterprise standards and guidelines
Services are published and reused, which yields cost
savings and return on investment (ROI)
Service versions are managed
Unexpected service usage is detected
Security requirements such as access control and encryption
are enforced
Service Life-Cycle Governance

The governance of service life cycle is an important aspect of the life cycle of a service as it ensures
defined business and IT objectives are met by providing a basis for enforcing rules of service
delivery. With a clear governance model in place, the standardization of information can be provided
to promote service visibility.
Requirements,
identification,
and discovery
Service
Build
definition
and compose
and design
Deploy
and secure
Publish
and provision
Evaluate
and evolve
Operate
and manage
Service Life-Cycle Governance (continued)

The actions required to establish an effective service life-cycle governance include:
Explicitly determining the level of IT and SOA capabilities and requirements
Working on the service implementation and access method
Agreeing on policies for service reuse across lines of business
Putting funding mechanisms in place to encourage this reuse
Establishing mechanisms to guarantee service levels
Deploying and securing services
Enabling the policy infrastructure
Monitoring compliance with policies and governance arrangements, such as SLAs, reuse levels,
and change policies
Analyzing IT effectiveness metrics
Service management involves managing services through

a set of management capabilities that enable the
monitoring, controlling, and reporting of service qualities
and service usage.
The characteristics of service management are:
Centralized configuration and monitoring

Policy-based routing and security
Service registration, versioning, and discovery
Service-level agreement (SLA) compliance tracking
Load balancing and failover
Service Management
Management is a key ingredient in Service-Oriented Architecture. When enterprises begin to
introduce service interfaces and migrate to SOA, the number of deployed services is small and
management is of less importance. As the number of services grows, it becomes critical to the
success of the SOA initiative to have a management solution in place. Service management
capabilities enable monitoring, controlling, and reporting of service qualities and service usage. Such
service qualities include availability (presence and number of service instances) and performance (for
example, access latency and failure rates), and also accessibility (of endpoints). Facets of service
usage information that may be managed include frequency, duration, scope, functional extent, and
access authorization. Service management needs to have common service semantics that are
understood by both the service consumer as well as the service provider.
Service Management
Organizationa
Consumer1
Organizationb
Consumer2
Business service
Service directory
Servicea
Serviceb
Servicec
Connectivity service
Service1
Service2
Service3
Service Portfolio
It is important to know the existence of a service for it to be used. In order to maximize the reuse of
service, a service must advertise itself. This can be achieved by registering the service in a central
directory that others use to look up service information. In the slide, two enterprises that have each
deployed services and service directories can allow the directories to forward requests between them
so that service clients in one enterprise obtain access to services in the other enterprise.
Service Portfolio
Business service
Service directory
Servicea
Serviceb
Servicec
Policy manager
Service1
Service2
Service3
Service1
policy
Policy Manager
Service policies specifies:
Authentication
Authorization
Encryption
Message level security
The policy directory is generally platform-independent and integrates with the existing security
infrastructure. Management solutions that manage security policies must be integrated with the
security infrastructure so that policies can be propagated to the point of enforcement.
Policy Manager
Service manager
Connectivity
service
Client
Orchestration
service
Client
Security
SLA
Availability
Service Routing
Service management is not limited to directory-based requests. It also provides routing services
through the service manager. Routing involves the mediation of service request between the service
consumer (client) and the service provider.
Oracle Service Bus (a stand-alone service bus) that plays an integral part in the service life-cycle runtime phase, is a key enabler in service routing.
Service Routing
Business service
Service directory
Servicea.2
Serviceb.2
Servicec.2
Service policy
directory
Service1.2
Service2.2
Service3.2
Service1
policy
Service Versioning
New service releases should attempt to leverage the same interface when possible. Multiple versions
of a service with differing implementations may be active at any given time. A long-running service
may cross the boundaries of service release cycles. A service policy may bind users to versions of
services.
Service Versioning
SLAs are client contracts that include:

Response times
Overall transaction times for long-running transactions
Quality of service
A service may have multiple SLA requirements depending

on the consumer of the service.
An organization using Service-Oriented Architecture must
have business mechanisms to agree on and comply with
SLAs.
An SOA system must have mechanisms for monitoring
service activity to guarantee SLA compliance.
SLA Management
SLAs are negotiated agreements between the service provider and service consumer.
The SLA records a common understanding about services, priorities, responsibilities, guarantees, and
warranties. It may specify the levels of availability, serviceability, performance, operation, or other
attributes of the service such as billing.
Service-level agreements can contain numerous service performance metrics with corresponding
service-level objectives.
SLA Management
In order to know the existence of a service you must look up

service information in the ___________.
1. Service version
2. Service directory
3. SLA
4. Service policy
Answer: 2
Explanation: In order to know the existence of a service, it is important to register the service in a
central directory that others use to look up service information.
Quiz
SOA governance
SOA portfolio
governance
Service life-cycle
governance
SOA organization
governance
SOA solution
life-cycle
governance
SOA vitality
governance
Constituents of SOA Governance Model

A SOA governance model is an approach that:
Enables the definition of policies and processes to guide management into making effective
SOA decisions
Enables management of your SOA strategy and roadmap
Aids in minimizing or avoiding potential conflicts of interest and in making decisions that are
fair to all parties
Enables commitment from stakeholders to adhere to processes and authority structures
Enables authorized groups to encourage adherence to SOA architecture and cultural orientation
SOA Portfolio Governance
Identifying which services to build in the context of a backlog of business requirements
Determining the reusability and importance of a service within the overall portfolio of services
Enabling authorized users to publish, search, and view services
SOA Vitality Governance
A key aspect of SOA vitality governance is defining a roadmap that will guide the smooth and
orderly evolution of the architecture over time. Most corporate SOA strategies involve overlaying
and transforming the existing systems architecture in stages, rather than replacing all of the current
infrastructure. Governance is needed to ensure that decisions made along the way align in a
consistent direction and maintain the coherency of the SOA architecture.
Constituents of SOA Governance Model
Constituents of SOA Governance Model (continued)

SOA Life-Cycle Governance and SOA Solution Life-Cycle Governance
The SOA life-cycle governance complements an enterprises service engineering and operational
processes by enforcing control points to monitor and enforce policies. The SOA solution life-cycle
governance ensures the solutions adherence and alignment to the enterprise architecture. It also
monitors the service usage and analyzes the impact of dependencies.
An important aspect of SOA life-cycle governance is the design-time and run-time governance.
Service-level governance applies at the level of individual services and covers a wide range of
requirements. A useful approach is to categorize the activities associated with the life cycle of a
service from its design to its run-time environment.
Design-Time Governance
Ensuring that the strategic design of business services, their interfaces and implementation
conform to established design patterns and other corporate standards and best practices
Establishing the governance standards appropriate for the various services
Understanding the inter-service relationships and dependencies
Performing impact analysis to determine the implications of changing a particular service
within the run-time environment
Run-Time Governance
Governance at run time revolves around the definition and enforcement of policies for
controlling the deployment, utilization, and operation of deployed services. These run-time
policies typically relate to non-functional requirements such as quality of service management
and compliance validation.
Run-time governance involves checking a service against a set of rules before it is deployed
into production (for example, to ensure that only a certain message transport or specific
schemas are used by services).
Run-time governance secures services so that they are accessible only to authorized consumers
possessing the appropriate permissions, and that data is encrypted if required.
Run-time governance relies on an SOA infrastructure that is able to exercise policy
enforcement in a way that is transparent to, and independent of, the service providers and
consumers. This is achieved both through an agent or intermediary that resides between the
provider and consumer, and a registry that addresses both the needs of service discovery as well
as policy enforcement. The intermediary interacts with the registry to find services and their
run-time policies and enforces the policies during the execution of the service.
Run-time governance manages changes to existing policies and SLAs.
In order to implement an end-to-end SOA governance solution

you need to address four areas:
SOA asset management
Policy management and enforcement
Consumer management
SOA monitoring and management
End-to-End SOA Governance

An end-to-end SOA governance solution needs to work toward improving the business agility,
mitigating risk, and ensuring cost savings. In order to reduce risk, enforcing design-time and run-time
policies is essential. A structured service contract needs to be enforced between consumer and
provider ensuring authorized service usage.
End-to-End SOA Governance
Manages SOA assets

and associated metadata
Provides run-time
reference for bindings
and policies
End-to-End SOA Governance: SOA Asset Management

SOA asset management is a key element that:
Offers a single source of truth for the SOA portfolio
Manages SOA assets and associated metadata
Provides dependency tracking and impact analysis
Automates the collection of assets and metadata from multiple sources
Provides run-time reference for bindings and policies
Provides structure and automation to the SOA life cycle
Tracks usage and compliance for visibility into ROI
End-to-End SOA Governance: SOA Asset

Management
Policy management and

enforcement
Offers centralized
management of policy
artifacts for versioning
and change control
Ensures policy
compliance throughout
the life cycle
End-to-End SOA Governance: Policy Management and Enforcement

Policy management and enforcement is a key element that:
Delivers a centralized management of policy artifacts for versioning and change control
Offers a distributed enforcement across the SOA infrastructure
Enables continuous design-time policy validation
Ensures policy compliance throughout the life cycle
Enables direct control over the SOA life cycle
End-to-End SOA Governance: Policy Management

and Enforcement

enforcement
Consumer management
Provides structure
contract between service
consumer and provider
Enforces contracts via
business, SLA, and
security policies
End-to-End SOA Governance: Consumer Management

Consumer management is a key element that:
Provides a structured contract between consumer and provider
Enables policy-based terms of use
Enforces contracts via business, SLA, and security policies
Provides a foundation for a shared services model
Provides notification of life-cycle changes to consumers
End-to-End SOA Governance: Consumer

Management

enforcement
Consumer management
SOA monitoring and
management
Provides central
management of
distributed and
heterogeneous SOA
Tracks enforcement of
service contracts and
quality of service
End-to-End SOA Governance: SOA Monitoring and Management

SOA monitoring and management is a key element that:
Delivers the central management of distributed and heterogeneous SOA
Provides visibility of end-to-end service networks
Monitors, diagnoses, and ensures service levels
Tracks the enforcement of service contracts
Tracks quality of service
Surfaces metrics and analytics for decision support
Collects, aggregates, and publishes metrics back to the asset repository for increased consumer
visibility, reporting, and trust
End-to-End SOA Governance: SOA Monitoring

and Management
The SOA governance solution must address the following

areas of an enterprise:
Performance management
Value delivery
Strategic alignment
Risk management
Resource management
SOA Governance Solution

SOA governance solution addresses the following areas of an enterprise:
Performance management: Focuses mainly on monitoring the services that run in a enterprise
environment
Value delivery: Focuses on how the value of IT can be proved through results like profitability,
expense reduction, error reduction, improved company image, branding, and so on
Risk management: Focuses on business continuity and measures to be taken to protect the IT
assets
Strategic alignment: Focuses on the imperative to align the business vision, goals, and needs
with the IT efforts
Resource management: Focuses on optimizing infrastructure services or other environments
supporting the application services
SOA Governance Solution
JDeveloper
Oracle
Service
Bus
Oracle
BPEL
Process
Manager
SOA Governance Suite
Enterprise
Repository
EM SOA
Management
Pack
Metadata
exchange
Web
Services
Manager
Service Registry
UDDI integration
Oracle SOA Governance Solution

The Oracle SOA governance solution includes:
Enterprise Repository: Provides metadata management for all assets within the SOA ecosystem
(part of the design-time governance) and sophisticated tools for governing those assets
throughout the life cycle and enabling their reuse
Service Registry: Universal Description, Discovery and Integration (UDDI) v3 registry that
provides a standards-based reference for the dynamic discovery and use of services and their
associated policies at run time (part of the run time governance)
Enterprise Manager (EM) SOA Management Pack: Used for the management of production
processes and services
Web Services Manager: Handles run-time governance and provides policy-oriented security
and access control
Oracle SOA governance supports the Oracle SOA Suite in the following ways:
Life-cycle management of Oracle Service Bus (OSB) and BPEL Process Manager (PM)
artifacts in Oracle Registry and Repository
Development stage validation in JDeveloper
Bidirectional run-time integration of Oracle Service Bus with Oracle Service Registry/ UDDI
(publish and subscribe)
Security policy enforcement on processes and services (OSB through Oracle Web Services
Manager (OWSM) Gateway or OSB itself for WS-Security)
Oracle SOA Governance Solution
In order to implement end-to-end SOA governance, you need

to address SOA asset management, consumer management,
policy management, and SOA monitoring and management.
1. True
2. False
Answer: 1
Quiz

Define service life-cycle management
Identify the characteristics of service management
Describe the need for managing services
Define the need for and benefits of governance
Describe the SOA governance solution
Summary
In this lesson you have learned the need for governance and the various facets of service
management.
In the next lesson you will be introduced to the various service layers and their responsibilities. The
importance of the Web Service Definition Language and the different service artifacts will also be
highlighted.
Summary
This practice comprises paper-based questions covering

service life-cycle management and SOA governance.
Defining Policies for a Group of Services
SOA
In the Designing Services for SOA Implementation lesson, you are introduced
to the concepts that enable defining and implementing a service. This is an
important aspect of designing an SOA system, because you can map
appropriate business functionality to the appropriate service type.
Course Roadmap
In the SOA Governance and Service Life-Cycle Management lesson, the need of governance
in a Service-Oriented Architecture environment was highlighted.
The Designing Services for SOA Implementation lesson introduces the various service
artifacts and service classification.
Course Roadmap

Define a service and its artifacts
Describe the various service layers and their
responsibilities
Explain the role of Extensible Markup Language (XML)
schemas
Design service interfaces with Web Services Definition
Language (WSDL)
Identify the role of adapter technology in implementing
services
Objectives
A service:
Provides a unit of work as part of a business process
Is a software component that is made up of the following:
Contract
Interface
Implementation:
Business logic
Data
Defining Services
Services are software component building blocks of distinctive functional meaning and
granularity that encapsulate a concept. Services consist of several parts.
A service contract provides abstraction and independence of technology between the service
consumer and the service producer. It can describe detailed semantics on the functionality and
parameters of the service. The contract is essentially a set of metadata on a higher level than the
service interface.
The service interface, such as Web Services Description Language (WSDL) or Interface
Definition Language (IDL), exposes the functionality of the service to its clients. It is linked to
the metadata-driven contract, but has a physical implementation such as WSDL-based clientgenerated stubs or IDL stubs.
The service implementation provides the required business logic and appropriate data and is the
technical realization that fulfills the contract. Depending on the granularity, the implementation
can be a very complex set of systems or a simple logging function.
Some services are related to or directly represent business logic in their implementation
providing different interaction paradigms. Legacy applications and middleware solutions
provide features that can be mapped to the interfaces. Binding the functionalities to the
interfaces makes them visible at the SOA level.
Data-centric services are an important part of what enterprises are trying to achieve, moving
away from batch programs to a more real-time processing model.
Defining Services
Client
XML messages (defined by an XSD)
WSDL
Interactions
Service
Service
WSDL
Service
Services Are SOA Building Blocks

Services:
Form the basic building block for an SOA implementation
Perform work based on business interactions and requirements
Interact by exchanging messages with other clients and other services
Describe their interface by using WSDL that specifies:
- Operations that may be executed
- Message structures for communicating required data for each operation. Message
structures are based on types expressed in an XML Schema Definition (XSD)
document.
Services Are SOA Building Blocks
Defines the service

Provides information on:
The functions that the service performs

The operating constraints of the service
The security requirements of the service
The service enablement requirements
Service Contract
The service contract document is a specification that describes the behavior of the service, its
functional and non-functional requirements, and constraints. The following should be a part of
the service contract document:
Service name: Specifies the unique name for the service defined by the contract.
Status: Indicates the current state of the service contract. States include In Progress,
Defined (the service contract has been completed), and Operational (the service has been
deployed into production).
Scope: Defines the relevant area within the enterprise for which the service is applicable.
Category: Indicates the type of service defined by this contract. The set of values for the
category of services is customizable to the enterprise.
Usage terms: Describe any usage restriction for the service as well as conditions for use.
For example, this field may specify that the service may only be used by consumers from a
particular line of business (LOB) between 7 PM and 5 AM.
Description: Provides a high-level description covering the purpose for the service,
business value, objectives, and a high-level description of the function(s) provided by the
service.
Functional Requirements: Provide a detailed list of functional requirements for the
service.
Service Contract
Service Contract (continued)

General information: Administrative information for the service, such as the service
owner, contacts, and documentation.
Life-cycle management: Contains data regarding the current status of the service in the
service life cycle, as well as the management policy for the service.
Interactions: Describe the expected methods that consumers use to communicate with the
service.
Quality of service: Provides a definition to represent the non-functional requirements of
the service. Some of the non-functional requirements are:
- Security constraints: Defines who can execute this service in terms of roles or
individual partners
- Transactional: Defines whether the service is capable of acting as part of a larger
transaction and how to control that
Service enablement: Represents the requirements placed on the service infrastructure that
is used to make the service operational, manageable, and accessible.
Defines the service interface including message schemas

Determines the implementation approach
Java
.Net
Determines the underlying resources used by the service

Covers both functional and non-functional requirements
Service Design
Service design begins with the service contract and proceeds with the consumer and reuse in
mind. 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.
Service Design
Is expressed as a coarse-grained or fine-grained service

Is considered as a trade-off between network latency and
usability (of functionality)
(Loosely) defined by size and frequency of the interactions
How much work does the service perform?

How much data is being exchanged?
Example analogy: Do I use SQL or PL/SQL to manage DB

interactions from the application?
Several SQL statements require more network round trips.

SQL packaged in PL/SQL requires fewer network round trips,
and more functionality in the server.
Service Granularity
Deciding between coarse-grained and fine-grained services can also be discussed in the context
of a trade-off between network latency and usability.
Granularity can also be seen as a measure of the interaction between a service consumer and
provider to address the business requirements. A fine-grained service may perform a small
amount of functionality or exchange a small amount of data. A coarse-grained service performs
a larger amount of work within a single interaction.
Note: Ultimately, a good Service-Oriented Architecture (SOA) should expose the right services
that do the right things and be less concerned about granularity.
Service Granularity
A service is designed based on the following service design

principles:
Has a well-chosen level of granularity
Is cohesive and complete
Encapsulates service implementation details
Accommodates multiple service invocation patterns
Service Design Principles

A service is a logical grouping of different service operations published in a standard format.
You can design the service based on some of the following service design principles:
Services should have a well-chosen level of granularity (that is, the number of operations a
service should have). If granularity is too coarse (grouping together a large number of
operations in a single service), it tends to increase the number of consumers for the service.
Any amendments to some aspect of a service result in rereleasing the whole service and
hence potentially impact all the service consumers. Moreover, any extremes in service
granularity (either many services with few methods, or few services with hundreds of
operations) tend to impede the maintainability and consumability of the service.
Service interfaces should be functionally cohesive, which means grouping a set of
operations in terms of their functionality. You can also use the principle of temporal
cohesiveness, which means grouping service operations that are used together in short time
periods. For example, the operations RetrieveCustomerDetails,
CheckCreditRating, CreateLoanFacility, and TransferFunds might well
be seen in succession in a banking business process. However that temporary cohesion
does not imply that these operations should be offered by the same service.
CheckCreditRating and TransferFunds lack functional coherence.
Service Design Principles
Service Design Principles (continued)

The services should also be complete. The issue of completeness is particularly relevant
when creating a service for a known consumer. In this case, the natural tendency is to focus
on meeting the requirements of the consumer. It is important to keep in mind that services
should be reusable, and hence need to consider the needs of future consumers. For
example, suppose a service called MobileService offered operations such as create,
update, query, delete, and deactivate. You can well imagine the need to reactivate a
deactivated mobile phone, and so you should decide whether to offer the symmetric
activate method.
The service interface should encapsulate the service implementation details, such as the
algorithms and resources used, to increase the decoupling between service consumer and
provider and hence enable flexibility.
A service can be invoked by implementing different service invocation patterns, such as:
- A traditional, synchronous invocation using Simple Object Access Protocol (SOAP)
over HTTP
- A asynchronous, message-based invocation using SOAP over Java Message Service
(JMS)
- A local invocation using Java procedure calls
You need to weigh the options of local versus remote service invocation, or whether to
invoke the service synchronously or asynchronously.
Coarse-grained interfaces:
Pass as much useful data as needed for each request
Return as much useful data as needed with each response
Define all message structures using an XML schema to
define complex data types for requests and responses
Limit the number of operations to the fewest possible,
while observing the business requirements and service
contract definition
Object
Fine-grained
interfaces
Components
Web Services
Coarse-grained
interfaces
Designing Coarse-Grained Interfaces

The level of granularity for services depends on their business purpose and interface
requirements. A Web service tends to have a coarser granularity compared to components,
which in turn are coarser than objects. A course-grained service exposes a single business
process.
Coarse-grained interfaces are recommended for externally exposed services, enabling:
Web services to be less chatty
Network overhead and performance to be improved due to fewer invocations
Client design and development to be simplified
Fine-grained services are useful for internal services that support larger services to address
business process requirements.
Note: Useful data means data that may be needed by a client, or what is needed by a service to
perform the tasks defined by business requirements and its contract (interface). Be pragmatic to
find a balance between the amount of data exchanged and the number of operations needed. In
general, the number invocations executed has a higher overhead than the message sizes. It is a
best practice to use XML schema design data types for service operation requests and responses.
Designing Coarse-Grained Interfaces
The service contract describes:

1. Service functionality
2. Service-level agreements (SLAs)
3. Service non-functional requirements
4. Web services policy
Answers: 1, 2, 3, 4
Explanation: The service contract document is a specification that describes the behavior of the
service, its functional and non-functional requirements, and constraints.
Quiz
Services can be broadly classified into:

Data services
Business services
Infrastructure services
Service Classifications
Service classifications are a logical grouping of the types of services that meet specific
requirements. These classifications potentially satisfy different subsets of the SOA architectural
principles and have their own specific constraints applied. Each service type takes on special
responsibilities, insulating the others from unnecessary complexity, and avoiding monolithic
software creation in which every asset is responsible for all the aspects of a software system. For
example, services can be defined to provide interfaces for exception handling, security, UI, and
database interaction.
Service Classifications
Fine-grained
No business logic or
aggregation
High reuse
Stateless
Connectivity System access Messaging Data access Partner integration

services
Messaging
Adapters
Custom APIs
JDBC
Non-service enabled assets
Legacy
Packaged
Database
Partners
Content
The connectivity services layer provides the means to derive information from a diversity of
software suites, custom applications, and data sources deployed across the enterprise.
In general, an enterprise can embrace a long list of retrieval strategies, such as extract,
transform, and load (ETL), message-oriented middleware (MOM), object brokers, and data
integration. The intent of the connectivity services layer is to integrate these different access
strategies into a single access gateway. The adoption curve leans toward a loosely coupled
implementation, which is more scalable and interoperable.
Conceptually, connectivity services are the lowest layer and provide a level of abstraction to all
kinds of data sources. Shared business services interact with connectivity services to pull the
desired content based on the request.
The focus of this layer is to provide a contractual relationship with legacy systems where
throughput, availability, and exception handling are complex. For this reason, one of the specific
roles of the connectivity services is to encapsulate legacy idiosyncrasies and standardize the
exposure of their functions to the other service classes, thus eliminating the complexity for the
other layers.
Characteristics:
Shared services
Fine-grained or course-grained
No business logic
Aggregation and
transformation
Data
High reuse
services
Stateless
Configurable
Logical data model
Messaging
Data aggregation
Adapters
Data synchronization
Custom APIs
JDBC
Legacy
Packaged
Database
Partners
Content
Data Services
The data services layer contains the services that provide access to data obtained by the data
sources. Access can be in the form of read and write capabilities (all create, read, update, and
delete functions). It may contain processing logic required to handle more complex write
operations. For example, an update may involve data sources that only support asynchronous
write operations. Also, error handling logic may be required if a data source is not available
when a request occurs.
Because this service class is responsible for decoupling data consumers from data providers, the
upstream consumers can legitimately assume a standardized information model and request data
without the need for knowledge of the underlying data sources.
After the data services are isolated, the architectural principles, such as Data is owned by the
enterprise, are better supported, enabling accountability and stewardship across the enterprise.
Characteristics:
Shared services
Data Services
Course-grained
Task-oriented
Business
logic content
Simple or
complex operations
Medium level of
reuse
Usually stateless
Business
services
Custom business
services
Enrichment
Messaging
Adapters
Atomic business
services
Custom APIs
JDBC
Legacy
Packaged
Database
Partners
Content
Business Services
As the enterprise begins to standardize and encapsulate the functionality of enterprise
information systems in services, opportunities begin to emerge to apply the same kinds of
concepts to core, discrete business functionality that is not necessarily tied to a given
information system. This functionality might include business functions, such as rating and
billing, inventory availability, and employee scheduling. This functionality is fine-grained and
would benefit the enterprise by being available in a standard way for use by people and
applications. In many respects, this is the simplest form of integration need for the enterprises.
Accordingly, this functionality meets the definition of a service and is classified as the shared
business services layer. This classification supports the common architectural principle for
creating a clear and distinct separation between the way data and legacy systems are accessed
and the way they are processed.
Characteristics:
Shared services
Business Services
Course-grained
Process-oriented
Short or long running
processes
Lower level of reuse
Can be stateless or
stateful
Business process
services
Messaging
System-centric
workflow
Adapters
Human-centric
workflow
Custom APIs
JDBC
Legacy
Packaged
Database
Partners
Content
Business Process Services

Business process automation is an example of orchestration. For example, a service for equity
trade execution would involve orchestration: to place a trade, to wait for it to clear, and to credit
or debit accounts appropriately. Orchestration involves the preservation of the state and several
physical transactions.
Technological constraints necessitate the separation of the business process services. In this
layer, you find a specific focus in the architecture on guidelines and constraints on the use of the
business process techniques, which are not applicable to other layers of the reference
architecture.
Characteristics:
Shared services
Business Process Services
Course-grained
Process-oriented
Short or long running
processes
Lower level of reuse
Can be stateless or
stateful
Presentation
services
Messaging
Shared portlets
Adapters
Multichannel delivery
Custom APIs
JDBC
Legacy
Packaged
Database
Partners
Content
Presentation services provide two general types of service (as shown in the slide). The first
provides information in a standardized form for aggregation by another system before delivery
to an end user (such as portlets and mashups). The second focuses on the transformation of user
data for delivery via different devices (such as mobile phones, Web TV, and games).
Characteristics:
Shared services
Service
repository
Service Bus

Business services
Data services
Security
Monitor/
event manager
Infrastructure
services
Messaging
Adapters
Custom APIs
JDBC
Legacy
Packaged
Database
Partners
Content
Service Infrastructure
The focus of service infrastructure is to provide the foundational components and capabilities
required to address the following enterprise challenges:
Avoiding tight coupling (direct dependency) between services and the clients
Achieving a consistent data format and representation of the enterprise data entities
Discovering what services are available, where they reside, and their capabilities and
semantics
Managing, monitoring, and enforcing quality of service and service-level agreements
Supporting service versioning
Governing the service life cycle
Managing service assets, relationships, and models
Invoking services over heterogeneous transports using different message brokering
capabilities
Managing security policy
Rationalizing entitlements capabilities and management
The service bus acts as the central hub for communication between all participants of the SOA
(service consumer and service producers). This intermediary provides the ability to achieve
loose coupling and a higher level of flexibility, because the integration points between consumer
and provider can be configured at run time rather than hard coded. This technique also isolates
service consumers from minor changes in the service provider.
Service
registry
Shared services
Business process automation is an example of services

orchestration.
1. True
2. False
Answer: 1
Explanation: Business Process automation is an example of services orchestration. Orchestration
involves the preservation of the state and several physical transactions.
Quiz
Services exchange information using the following basic

interaction patterns:
Synchronous (two-way) interaction
Asynchronous
One-way interaction
Two-way interaction
Note: Message structures are used to exchange information as

part of an interaction.
Basic Service Interaction Patterns

In any SOA implementation where services provide functionality for a business process, the
services require input information to perform some processing tasks. Sometimes a service is
required to return response information, and other times a response is not required.
Interaction patterns is the common term used to describe these types of exchanges. The basic
interaction patterns on which SOA implementations are built are:
Synchronous (two-way) interactions, where the service client provides request data to a
service that must respond with response data. Synchronous interactions are always twoway interactions in that a response is required even if the response is an error.
Asynchronous interactions have two basic forms:
- A one-way interaction is when the client sends a request with an operation to be
performed and does not wait for or care for any response. This pattern is used to
initiate some process that uses other forms of notification in the event of completion
or errors.
- A two-way interaction is required when the client needs some response data from
the service invoked. However, the client needs to be able to continue processing
while it waits for a response.
Note: Synchronous interactions involve fast-running operations, and asynchronous interactions
invariably involve operations that may take a long time, such as a human workflow process.
Basic Service Interaction Patterns
With synchronous operations:

Clients wait until the invoked operation completes
Clients are immediately aware of invocation failures
Invocations may be less scalable and more vulnerable
Invocations should provide high-performance execution
Service
Client
Synchronous
Request
Response
Synchronous Interactions
Synchronous designs are traditionally simpler to understand and implement.
With remote invocations, synchronous systems are vulnerable to network interruptions if the
operation execution is lengthy. That is, a network interruption can abort an otherwise successful
(and expensive) operation.
From a scalability perspective, synchronous designs demand that the service execute the
operations immediately. Consequently, during peak demand, the service may not provide
enough availability for all clients.
Synchronous Interactions
With asynchronous operations:

Clients are decoupled from the execution of the operation
Clients may not be directly aware of invocation failures
Invocations can be more scalable and less vulnerable
Invocations may provide lower performance execution
Service
Client
Asynchronous Request
Immediate callback/response
Optional polling
for response
Optional callback/response
Long
processing
tasks
Asynchronous Interactions
Asynchronous service designs are usually essential to robust and scalable Service-Oriented
Architectures.
Asynchronous designs minimize the duration of blocking over the network, thereby mitigating
the vulnerability to network interruptions. Common examples of slow services include working
with external partners and slow legacy applications.
Asynchronous designs leverage queues such that peaks cause requests to be queued, allowing
more availability to receive the requests. Subsequently, the service may process the queued
requests by optimizing resources and supporting higher availability for new requests.
Common examples of asynchronous Web services in everyday life include:
Loan application processing
Stock tickers
Stock tradinglimit orders
Travel agent service
Note: Asynchronous interactions can be one-way, such that a response is not returned to the
caller. Asynchronous responses are referred to as a callback. A client may choose to poll for the
asynchronous response. If a client is expecting a response at some point, it will have to wait for
that response.
Asynchronous Interactions
Services can be:

Supplied from existing functionality:
Internal application systems exposed (wrapped) as Web
services
Enterprise information systems (EIS) through adapters
Created as new functionality developed using:

Enterprise Service Bus (ESB) components
Business Process Execution Language (BPEL) processes
Web services implemented with ADF BC, Java, Java EE
Invoked through different protocols and methods:

Web services (using SOAP)accessed over HTTP
Adapter services such as JMS adapter
Choosing Service Implementation Styles

Before embarking on an SOA implementation, business requirements should be identified before
you can design, identify, or locate services that can support the business need. After the
identification task is complete, services and their operations and messages can be specified,
thereby creating a portfolio of services needed to meet the business requirements.
The implementation for the portfolio of services can be chosen from:
Existing functionality, provided by in-house applications already available for use.
Existing application functionality can be exposed through new interfaces and repurposed
for an SOA environment.
EIS and legacy applications, which have many custom adapter interfaces that expose their
functionality as services for integration purposes
New applications, which can be developed in languages that support Web service
standards, such as Application Development Framework Business Components (ADF BC),
Java, and Java EE among others. New services can be developed if existing services do not
meet identified requirements.
Invocation of services, whether developed as a Web service or exposed through adapters (using
Java Connector Architecture standards) can be invoked using SOAP, Representational State
Transfer (REST), and WSIF, and potentially, other ways.
Atomic service
Composite service
Service cluster
Choosing Service Implementation Styles (continued)

A service can be a provided by either implementing a single task or by processing a set of
multiple sequenced tasks. The service implementation can be broadly classified into the
following three categories:
Atomic service: indivisible software components that are not subject to decomposition analysis
activities, and their business or technological functionality does not justify a breakdown to
smaller components (for example, a customer address service or an account balance checking
service).
Composite service: constitute a hierarchical service formation, characteristically known as a
coarse-grained entity that encompasses more business or technical processes. A composite
service may aggregate atomic or other composite services (for example, a customer service that
aggregates the account validation and saving account services).
Service cluster: comprise several distributed and related services that are gathered because of
their mutual business or technological commonalities. A service cluster both affiliates services
and combines their offerings to solve a business problem. A cluster structure can aggregate
atomic as well as composite formations. For example, a mutual funds service cluster can be
composed of related and distributed mutual funds services. Similarly, a customer support service
cluster might offer automated bill payments, online account statements, and money transfer
capabilities.
Creating services from a design perspective:

The business requirements define:
The functionality (operations)

The data (messages exchanged)
The interaction rules governing when data is exchanged
The results are:
Interface definition
Implementation specification
Interaction pattern
Creating services from a development perspective:

The interface is manifested as WSDL and an associated
XSD.
Implementation is coding the specifications defined to honor
the operations identified by the interface.
Fundamentals for Creating a Service

Services provide a business function exposed as an operation that meets some business need.
Those operations usually require data to process. Therefore, the consumer of the business
function may need to supply data for the function to perform its processing. The business
function may also return data to the consumer as the result or outcome of the processing
performed.
From a designer perspective, identifying services is about translating or decomposing a business
requirement into a process and set of functions that support the process. Each identified function
or operation must specify the message structures that it requires to perform its task and return its
results. The operations and the message structures are used together to create an interface
definition. The implementation specification defines the details of what processing must be
performed and what type of interactions are required.
From a developer (or implementation) perspective, the interface is created as a WSDL
document, supported by one or more XML schema documents describing the message structures
representing the data exchanged. The implementation of the functionality must conform to the
interface requirements that can be realized with a variety of languages or technologies, such as
Java EE, ADF BC components, BPEL, Mediator, and Adapter services, among others.
Fundamentals for Creating a Service
Services can be built from:

Existing functionality
In-house systems (expose and reuse)

EIS (access through adapters)
New functionality developed as Web services
Java and Java EE

.Net, PHP
Services can be accessed using:

SOAP (or Representational State Transfer (REST)) over
HTTP
WSIF
JCA adapters
Building a Portfolio of Services

Before embarking on an SOA implementation, the business processes need to be examined. The
business requirements should be identified before you can design, identify, or locate services
that can support the business need. After you have identified the business processes, the
information that needs to flow between organizations, and the operations that need to be
performed, you can begin creating a portfolio of services to support the business requirements.
A portfolio of services is a set or collection of services and associated artifacts that enable
organizations to integrate and communicate with each other. A portfolio of services can
comprise:
Existing functionality, provided by in-house applications already available for use.
Existing application functionality can be exposed through new interfaces and repurposed
for an SOA environment.
EIS and legacy applications, which have many custom adapter interfaces that expose their
functionality as services for integration
New applications, which can be developed in languages that support Web service
standards by nature, such as Java, Java EE, and .Net components among others. New
services can be developed if existing services do not meet identified requirements.
Invocation of services, whether developed as a Web service or exposed through adapters, can be
performed using SOAP, WSIF, and Java Connector Architecture (JCA) standards.
Building a Portfolio of Services
Is a software system or self-describing business function

Is designed to support interoperable machine-to-machine
interaction over a network
Communicates with clients through standard protocols and
technologies called Web services
Request
Response
Application
Web service
Describing a Web Service

A service is essentially a process that performs a specific business function, such as validating a
credit card submitted with a customer order. Business functions that are a subset of an existing
EIS, (such as part of an Enterprise Resource Planning (ERP) system and other application
modules) can be represented as services through adapters.
A suitable granular (modular) service design can enable a service to support many applications
in an enterprise that spans platforms and organizational components. For example, to find the
number of units sold for a particular product, the business function might need to query a sales
management, a sales order, and a product inventory system within an organization.
A Web service is a service that performs discrete business functions. Interaction with a Web
service is based on a set of standard protocols and technologies called Web services. Web
services:
Refers to a standard set of platform-independent messaging protocols (SOAP, HTTP, JMS)
Allows connections between services from any Web-connected device
Exchanges data and functionality in the XML format
Describing a Web Service
The most common Web service standards are:

SOAP describes the message format communication
between the parties involved in a Web service
WSDL defines mechanisms for describing Web service
operations in a platform-neutral way
Universal Description, Discovery and Integration (UDDI)
facilitates the registration and organization of Web service
descriptions into a searchable hierarchy
Web Service Standards

As already mentioned, the standards for Web services include a SOAP for message format,
WSDL for service description, and UDDI for the registration and location of Web services.
SOAP is an XML-based message format that is an open standard defined by the W3C. It is a
mechanism for invoking operations and exchanging documents between applications as an
envelope protocol that is embedded in other standard protocols.
The WSDL also uses an XML-based format, but it is used for describing the interface of a Web
service. This document includes a description of the endpoint, location, protocol binding,
operations, parameters, and data types of all aspects of a Web service.
UDDI is a set of specifications that defines the format of a standard registry for Web services, as
well as the protocol for messages used to access the registry. It also identifies classifications and
taxonomies for organizing Web services.
Web Service Standards
Find
WSIL Locate
browser
Find
(UDDI)
Register
(UDDI)
1
Web services
directory
Generate
WSDL.
4 Invoke request (SOAP).

Internet
Web service
client application
Send response
(SOAP).
Interface
(WSDL)
Service
implementation
Web service
Web Service Architecture

The diagram shows a conceptual architecture of Web services. The provider of a Web service
performs the following steps to expose a Web service endpoint:
1. Generates the WSDL: The Web service is developed and the XML format describing the
service (the WSDL) is generated.
2. Registers with the Web service registry: The Web service provider registers itself as a
business entity and publishes the WSDL in one or more UDDI registries (for example,
Oracle Service Registry).
The consumer of a Web service performs the following steps to invoke a Web service:
3. Searches the UDDI registry or uses a WSIL browser: The consumer searches the UDDI
registry or uses a Web Services Inspection Language (WSIL) browser to locate the WSDL
for the Web service.
4. Invokes the Web service: The consumer sends a SOAP request to invoke the Web service
by using the information stored in the WSDL. The WSDL information, which is obtained
from the UDDI registry or WSIL browser, includes:
- The URL for the service endpoint to locate the service functions
- The WSDL that defines interface methods and messages provided by the service
5. Communicates the response: The provider responds with a SOAP message that
communicates information to the consumer. The SOAP request and response are typically
transmitted using the simple HTTP request/response protocol.
Web Service Architecture
Web Service Architecture (continued)

WSIL is defined by the WS-Inspection specification as an XML grammar to address the need to
facilitate the aggregation of references to different types of service description documents stored
in the form of WSDL and UDDI registries. The WS-Inspection specification provides a means
by which to inspect sites for service and locate pointers to service description documents.
Note: Java applications can use the WSIF, which is a Java API for invoking Web services.
You can use the WSIL browser to search for WSDL descriptions of services. The WSIL browser
can locate services published in UDDI registries or in local file systems.
The following are the file formats used extensively by Web service standards:
XML: Is a set of rules for defining data markup in a plain text format
XSD: Specifies how to formally describe the elements in an XML document
XSL: Extensible Stylesheet Language (XSL) is a specification (or template) for separating
style from content when creating HTML or XML pages.
XSLT: Extensible Stylesheet Language Transformations (XSLT) is the language used in
XSL style sheets to transform XML documents into other XML documents.
XPath: XML Path (XPath) is a language with a set of syntax rules for defining parts of an
XML document.
Typical artifacts of a service include:

XML schema documents to define the format of the
message structures communicated
Business operations (placeOrder,
validateCreditCard) to define operation names
Process definitions and application interfaces to define

implementations and how to interact with them
WSDL documents, which depend on:
XML schema documents
Business operations
Business requirements and rule documents to ensure that

the artifacts listed above meet the business need
Service Artifacts
To build and expose services for loosely coupled integration in an SOA context, it is vital to
obtain or produce service artifacts. These service artifacts include:
XML schema documents, which ensure that all message formats are understood
Process definitions and application interfaces, which document and describe how to access
key interfaces to systems. This can include Web services or connectors.
Business operations (placeOrder, validateCreditCard), which provide the
functionality to implement the required services. In some cases, mock business processes
can be provided to enable integration testing of an SOA implementation.
WSDL documents
A formal specification with the details listed above would be highly recommended so that
organizations can track, modify, and measure the progress of implementation to ensure that the
business requirements are being met. Naturally, this implies that the business rules must also be
clearly defined.
In addition, if the artifacts need to be constructed, a highly trained development team is valuable
to ensure success.
Any successful implementation is assisted by receptive business users who are willing and ready
to test the implementation.
Service Artifacts
XML schema:
Is an XML language that defines and validates
the structure of XML documents
XSD
Is stored in an XSD document
Defines
Defines elements and types, such as: types
Simple type definitions

Complex type definitions
Element declarations
Attribute declarations
WSDL
Validates
References
Instance
Supports XML namespaces and built-in, simple, and

complex data types
Is used to define message types in WSDL documents
XML Schema Definitions

The W3C XSD language is an XML language (or vocabulary) used in an XSD document for
describing and constraining the content of XML documents. The XSD is used to validate the
structure of an XML document.
An XML document, whose structure is based on the definitions in an XML schema, is called an
instance document of that XML schema. The slide shows an XML Schema Document stored
separately from the XML instance document that it describes and validates.
The introduction of the XML schema allowed XML technology to represent data types in a
standard format. The data types give a precise way of specifying the type of content that can be
held in elements and attributes of an XML document.
In an SOA environment, XSDs are very important to ensure that messages exchanged during
interactions between service consumers and providers are consistent, well-formed, and valid
structures. In fact, WSDL message types are defined in terms of XSD elements and types to
ensure a high degree of consistency and visibility between a service and the client invoking the
service.
XML Schema Definitions
Input
type
Output
type
Defining Messages in XML Schemas

You can create an XML schema by using JDeveloper. You can visually insert or modify the
XML elements (such as complex types and elements) by using the JDeveloper XSD Visual
Editor. You can insert an XML node (such as an element, a complex type, and a simple type) by
right-clicking any existing node and selecting one of the following optionsinsert before
element, insert inside element, or insert after elementand thereby selecting the appropriate
node to insert. You can modify an existing node by double-clicking a specific node and
modifying its value.
For example, the XML schema (CreditService.xsd) is defined with XML complex types
and XML elements. The complex type CreditCard is intended to handle the input operation
type (method parameter), and the elementsvalid and errorare intended to handle the
output operation type (method return type) of the Web service logic (implemented using a Java
method).
Note: The graphic is an example and does not represent the specific implementation used in the
course example, which in fact uses the valid xsd:boolean element to indicate whether the
credit card is valid or not. The XML schema definitions provide elements that you intend to use
as entities or data structures that may be exchanged in interactions with the Web service.
Defining Messages in XML Schemas
A WSDL document is an XML

document that describes:
What the service does
How the service is accessed
Where the service is located
WSDL document
It defines the messages and

the operations of a service
abstractly in XML.
Described by
Types
Messages
Port types
Bindings
Services
Service interface
Web Services Description Language (WSDL)

WSDL provides a standard way to describe Web services. WSDL uses the XML format for
describing Web services. It describes what functionality a Web service offers, how it
communicates, and where it is accessible. Because WSDL is in the standard XML format, the
services developed can easily be made available to thousands of users. Users must invoke the
correct services with the appropriate parameters. WSDL defines an XML grammar to specify the
location of the service and to describe the operations of a service.
A WSDL document contains the service interface definition, the implementation details, the
access protocol, and the contact endpoints information about an operation. The WSDL document
describes a Web service by using these major elements:
<types>: Defines the data types used by the Web service
<portType>: Describes a Web service, the operations that can be performed, and the
messages that are involved
<message>: Describes the messages used by the Web service; defines the data elements
of an operation
<binding>: Defines the communication protocols used by the Web service
<service>: Describes the name and location of the Web service and the context with
which it can be accessed
Web Services Description Language
XML Elements
attributes
Definition
targetNamespace
Type
Message
name
PortType
name
Binding
name
type
Schema
Part
name
Operation
name
SOAPBinding
style
transport
Service
name
Port
name
binding
Input
message
Element
Address
location
Output
message
name
type
What
How
Where
WSDL Model
The slide provides a structural model of the WSDL specification. The different sections in the
WSDL model break down into the following software engineering practices:
What: This section describes the service requirements and its functionality. It describes
the relevant message types and their association with the service operations input and
output parameters. Within a Type, the Schema describes the Messages to be passed
through the interface (as parameters or documents). Messages are data to be exchanged
via the interface Operations (the input and output parameters of the interface). The
PortType is the container for these operations.
How: This section describes the service design and the service invocation pattern.
Where: This section describes the service implementation and the run-time environment.
WSDL Model
WSDL interface
operations and messages
WSDL components that you

can drag and drop in the
WSDL editor to create the
WSDL document
Defining Service Interfaces in WSDL

You can create or modify the WSDL document in JDeveloper by using the WSDL editor tool.
The WSDL editor gives you a design view of the WSDL document that enables you to segregate
the different sections of the WSDL document (such as, services, bindings, and port
types) into a hierarchical structure. You can expand the tree of a specific section and can add,
modify, and delete specific nodes in the WSDL document. You can also change the values of
different nodes by selecting any node to modify its value in the Properties pane.
Defining Service Interfaces in WSDL
Asynchronous operations can be a one-way or a two-way

interaction pattern.
1. True
2. False
Answer: 1
Explanation: Asynchronous interactions can be one-way, such that a response is not returned to
the caller. Asynchronous responses are referred to as a callback. A client may choose to poll for
the asynchronous response. If a client is expecting a response at some point, it will have to wait
for that response.
Quiz
Adapters integrate with existing back-end applications through

Java EE Connector Architecture standards.
Oracle SOA Suite
SCA composite
SOAP
Client
JMS
External
(SOAP)
reference
SOAP
JCA Adapter
reference
JCA
Other
Bindings
Web service
Service infrastructure
EIS/DBMS
Adapter Services
The JCA Binding component represents the core part of the Adapter architecture. The JCA
Binding component is a lightweight implementation that uses Java EE Connector Architecture
(JCA) standards for inbound and outbound communication that:
Provides a way to integrate with existing back-end applications
Enables interoperability with heterogeneous applications, provided by different vendors,
based on different technologies and platforms
An Adapter, deployed as a JCA 1.5 resource adapter in a Java EE container, is described by a
WSDL format and exposed through JCA mechanisms. The JCA binding component allows an
SCA composite application to integrate with a service exposed through the adapter as if it were a
Web service.
Oracle JCA resource adapters support the following types of EIS integration services: JMS,
TopLink/JDBC, PL/SQL, File, FTP, MQSeries, Sockets, Advanced Queuing, Oracle E-Business
Suite, SAP, PeopleSoft, Siebel, JD Edwards, Tuxedo, CICS, VSAM, IMS-TM, IMS-DB, and
many more through the OEM model.
Adapter Services
JDeveloper
Adapter Wizard
Technology Adapters
JCA Adapters
Files/FTP
Java EE
Application
JMS/AQ
Database
JCA
Oracle
Applications
BPEL
Mediator
Socket
Oracle WebLogic
Server
Describing Technology Adapters

The following Technology Adapters are available for Oracle SOA Suite 11g Mediator and BPEL
components:
JMS/AQ Adapter: An inbound or outbound JMS/AQ Adapter transmits an XML message
to or from an Oracle SOA Suite component through a message-oriented service such as
Oracle Advanced Queuing queue and other JMS providers.
Database Adapter: An inbound Database Adapter service sends an XML message to an
Oracle SOA Suite component when a SQL insert, update, or delete operation is performed
against a database. An outbound Database Adapter service transforms the contents of an
XML message into a SQL insert, update, or delete operation on the target database.
File/FTP Adapters: An inbound File or FTP adapter service reads data from a local or
remote file system, transforms the file data into an XML message, and sends it to an Oracle
SOA Suite component when a new text file appears in a local file system. An outbound
File Adapter service transforms the contents of an XML messages to a text file and writes
it to a local or remote file system.
Oracle Applications (OA) Adapter: An inbound OA adapter sends XML messages to
Oracle SOA Suite on receiving messages from an Oracle E-Business Suite interface. An
outbound OA adapter inserts data from Oracle SOA Suite to Oracle Applications using
interface tables, APIs, and concurrent programs.
Socket Adapters: communicate either as a client or server using TCP/IP based protocols.
Describing Technology Adapters
Adapter Application
Explorer
Packaged Adapters
Siebel
SAP
Oracle Studio
Oracle Connect
Mainframe/Legacy
JCA Adapters
BSE
BPEL
SOAP
Mediator
PeopleSoft
J.D.Edwards
Legacy Adapters
BPEL
JCA
VSAM
Mediator
IMS DB/TM
Java EE
Application
CICS
Tuxedo
Oracle WebLogic Server

Packaged Application and Legacy Adapters

Packaged-application adapters integrate Oracle Application Server with various packaged
applications, such as SAP and Siebel. These adapters include OracleAS Adapter for PeopleSoft,
OracleAS Adapter for SAP R/3, OracleAS Adapter for Siebel, and OracleAS Adapter for JD
Edwards. Packaged-application adapters are available as part of the OracleAS Adapters CD.
Packaged-application adapters support WSDL, SOAP, and JCA interfaces. The Application
Explorer is a Java swing-based design-time configuration tool. The Business Services Engine
(BSE), deployed in the Oracle WebLogic Server container, uses SOAP for accepting requests
from clients, interacting with the back-end application, and sending responses from the back-end
application back to clients.
Legacy adapters integrate Oracle Application Server with legacy and mainframe applications.
These adapters include OracleAS Adapter for Tuxedo, OracleAS Adapter for CICS, OracleAS
Adapter for VSAM, OracleAS Adapter for IMS/TM, and OracleAS Adapter for IMS/DB.
Legacy adapters are available as part of the OracleAS Adapters CD. Oracle Connect is a
component that resides on the legacy and mainframe platform that consists of server processes to
handle client requests, native adapters, a daemon, an RPC-based listener, and a repository for
storing configuration information. Oracle Studio is a design-time tool for configuring the Legacy
Adapters for mainframes.
Note: Custom adapters can also be developed by customers or third-party companies.
Packaged Application and Legacy Adapters
WSDL port describes the interfaces exposed by a

Web server
Web service
Web browser
None of these
Answer: 2
Explanation: WSDL provides a standard way to describe Web services. WSDL uses the XML
format for describing Web services. It describes what functionality a Web service offers, how it
communicates, and where it is accessible. Because WSDL is in the standard XML format, the
services developed can easily be made available to thousands of users.
Quiz

Define a service and its artifacts
Describe the various service layers and their
responsibilities
Explain the role of XML schemas
Design service interfaces with WSDL
Identify the role of adapter technology in implementing
services
Summary
In this lesson you have been introduced to the service artifacts, service classifications and their
responsibilities and how pivotal Web service definition language is in defining a service.
In the next lesson, the Service Component Architecture and its importance as an emerging
standard in defining a composite application will be highlighted. In 11g, a SOA application is
described in terms of a composite application that encapsulates all the service components
together. This feature will be dealt with in greater detail in the ensuing lesson.
Summary

Modifying an XSD in JDeveloper
Modifying a WSDL in JDeveloper
Practice 4: Overview
Creating a Composite Application
SOA
This Creating a Composite Application lesson introduces the Service

Component Architecture (SCA) assembly model and how to create a composite
application that encapsulates the various service components as a single runtime unit.
Course Roadmap
In the Designing Services for SOA Implementation lesson, the various service artifacts and
service classification was introduced.
The Creating a Composite Application lesson introduces the Service Component Architecture
(SCA) assembly model and on how to create a composite application.
Course Roadmap

Explain the Service Component Architecture (SCA) and its
components
Discuss components of the SCA
Describe Service Data Objects (SDO)
Create an SOA composite application in JDeveloper
Objectives
Intention: Simplify the creation and integration of business

applications that conform to the principles of ServiceOriented Architecture
Principle: Divide the application into components that
implement (service-oriented) business interfaces
Separation of business logic and communication
management
Use of different technologies to implement business logic
Service Component Architecture (SCA)

An SOA application generally consists of a set of software components working together. All of
these components might be built using the same technology, or they might use different
technologies. Moreover, these software components might reside in the same machine or spread
across an enterprise.
Service Component Architecture (SCA) defines an approach to create software components and
a mechanism for describing how these components work together.
Service Component Architecture
Service Component Architecture is a set of specifications that:

Defines an assembly model for building applications and
systems
Provides a programming model for building applications
and systems based on a Service-Oriented Architecture
Extends and complements existing approaches to
implementing services
Provides a model for:
Composition of services
Creation of new services and reuse of existing systems
Builds on Web services and other open standards

SCA is an assembly model for services.
SOA is an architecture style or approach.
Service Component Architecture (SCA) (continued)

SCA provides a programming model for building applications and systems based on a ServiceOriented Architecture. SCA is based on the concept that a business function is provided as a
series of services. The services 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 the reuse of existing application functions
The benefits of an SCA model are:
Loose coupling is realized as components are integrated with other components without
needing to know the implementation of other components
Flexibility is enabled through the ability to easily replace one component by another
component
Services are easily invoked either synchronously or asynchronously
Compositions of solutions are clearly described visually and in an XML format
Note: All the preceding benefits are key requirements for SOA.
Productivity is realized because the SCA model makes it easier to integrate components to form
a composite application.
Service Component Architecture
Domain
Composite 2
Component
X
Composite 1
Wire
Component
Y
Composite 3
Wire
Wire
Service
Reference
Implementation
BPEL
Java
Others
Components and Composites

The SCA specifications describe an SCA application in terms of components and composites.
Components are the atoms that enable the creation of an SCA application. The SCA components
are an instance of an implementation (the code that provides the components function) that
behaves in consistent ways, and they can be assembled into different configurations. For
example, in a simple application, the components could be Java classes running in a single
process, and their interactions might rely on Java interfaces exposed by those classes. In a
complex application, there might be a few components implemented as Java classes, others
written in C++, and still others defined using BPEL, all spread across a group of machines.
A composite is a logical construct of a group of components. Its components can run in a single
process on a single computer or be distributed across multiple processes on multiple computers.
A complete application might be constructed from just one composite, or it could combine
several different composites.
A service is the entry point to a composite. Components also depend on services provided by
other componentsthese dependencies are called references. Also contained in the composite
are the linkages between references and services, represented by wires.
SCA composites are deployed within an SCA domain. An SCA domain represents a set of
services providing an area of business functionality that is controlled by a single organization. A
single SCA domain defines the boundary of visibility for all SCA mechanisms.
Components and Composites
A component:
Configures an implementation instance within a composite
Provides services and consumes services (references)
Sets implementation properties
Sets references by wiring them to services:
Provided by other components
Provided by references of the composite
Property
Component
Interface
Component
Implementation
BPEL, Java composite
Service components:
BPEL Process
Mediator
Human Task
Business Rules
Creates its source file
and a .componentType
file in the composite
project
References
SCA Components
Components hold pieces of a program function within a composite. Components are configured
instances of some implementation, such as BPEL, Java, or other implementation logic. The
implementation code defines the services, references, and properties that are configured by a
component within a composite. More than one component can use the same implementation.
The component interfaces are visible (as WSDL) to internal components to enable them to
interact with each other (and build the assembly model through wires). The interfaces can also
be made visible externally by publishing the component interface in a WSDL form that is shared
with target callers of the composite application
SCA components support implementations of many different technologies, which reflect the
reality of businesses containing mixed systems with different technologies developed over many
years. The flexibility of implementation language enables the selection of technologies better
suited to different types of workfor example, using BPEL for business processes, and Java or
C++ for detailed number crunching.
Each SCA component is identified by a <component> element in the SCA descriptor. The
<component> element identifies the component type and the location of the component
source.
SCA Components
A composite creates a service that:

Defines an assembly model for service components,
references, wires, bindings, and properties
Processes information described in messages
Enables design and deployment as a single application
Stores assembly information in an SCA descriptor
(composite.xml)
<composite>
Reference
Service
element
<component>
element
Service (entry point)

<service> element
Composite
NewOrder
Mediator
Binding
<interface.wsdl>
element
<binding.ws> element
Wire
<wire>
element
(external services)
<reference>
element
<property>
ProcessOrder
BPEL
<component>
element
Reference
Binding
<interface.wsdl>
element
<binding.ws> element
SCA Composite
A composite is defined in terms of the service components implementing and using services and
the connections that linked them together. A composite defines components and reference
implementation code and describes services and references and the connections (wires) linking
them. Services are a binding type that advertise and provide an entry point for messages received
from the outside world into the composite. References are a binding type that enable messages to
be sent from the composite application to external service partner links in the outside world.
Wires graphically connect entities in a single composite application for message
communication. Service components that can be assembled include:
BPEL process, Business Rules, Mediator, Human Task
SDO service and any Web service
Binding styles include:
SOAP bindings
SDO bindings
JCA adapters, among others (RFID, WSIF)
The composite is a service in that it is designed and deployed together as a single application
with its own service interface (WSDL). The assembly information is stored in an SCA descriptor
called composite.xml, which is a language-independent representation of the composition of
services for a business solution.
SCA Composite
Domain 1
Default binding
Composite W
Composite Y
Composite X
Non-SCA
application
Explicit
binding
Explicit
binding
Domain 2
Composite Z
SCA Bindings
Services and references enable a component to communicate with other software. But, it does
not specify how that communication happens. A binding specifies how communication should
be done between an SCA component and any other software component.
A component may not have explicitly specified bindings (depending on what the component is
communicating with). As shown in the slide, a component that communicates with another
component (executing in another process of the same machine or on a different machine) in the
same domain need not have any explicit bindings specified. Instead, what bindings to use are
determined at run time.
To communicate outside its domain (to a non-SCA application or an SCA application running in
some other domain), a components creator (or perhaps the person who deploys the component)
must specify one or more bindings for this communication. Each binding defines a particular
protocol that can be used to communicate with this service or reference. A single service or
reference can have multiple bindings, allowing different software components to communicate
with it.
SCA Bindings
The framework defines:

Interaction policies:
Specifies the interaction between the components at run time
Applies to bindings
Implementation policies:
Specifies the behavior of the component at run time
Applies to the run-time container
Intents and policySets
SCA Policy Framework

SCA provides the policy framework to support non-functional requirements of a service
definition, such as the specification of constraints, capabilities, and QoS expectations from
component design to concrete deployment. The term policy is used to describe a certain
capability or constraint that can be applied to service components or to the interactions between
service components represented by services and references. For example, there can be a policy
that governs an encrypted exchange of messages between a service client and a service provider.
In SCA, services and references can have policies applied to them that affect the form of the
interaction that takes place at run time. For example, a binding using the https protocol
provides encryption of the messages flowing between a reference and a service. These are called
interaction policies.
Service components can have other policies applied to them, which affect how the components
behave within their run-time container (for example, logging all the messages between a
reference and a service). These are called implementation policies.
The SCA policy framework model is comprised of intents and policySets. Intents are abstract
specifications of requirements independent of the implementation technology or binding. For
example, an intent named integrity may be specified to signify that communications should be
protected from possible tampering. PolicySets contain concrete policies that are applied to SCA
bindings and implementations. They are intent mapped to concrete WS-Policies during the
deployment of the component.
SCA Policy Framework
Which one is NOT a part of Service Component Architecture?

1. The ability to build components in the development
language of your choice
2. Orchestration between the components in a service
3. Mediation between components
4. A run-time environment
Answer: 4
Explanation
SCA provides a model for both:
The composition of services
The creation of service components, including the reuse of existing application functions
Quiz
Simplifies and unifies heterogeneous data access

Is based on the concept of disconnected data graphs
Enables both a static (or strongly typed) and a dynamic (or
loosely typed) programming model
JDBC
Database
XML / HTTP
Web service
SDO
Application
Data access
service
RMI / IIOP
XQuery / XPath
EJB
XML DB

The Service Data Objects (SDO) specification is designed to simplify and unify the way
applications handle data. Using SDO, application programmers can uniformly access and
manipulate data from heterogeneous data sources, including relational databases, XML data
sources, Web services, and enterprise information systems.
SDO is based on the concept of disconnected data graphs. A data graph is a collection of treestructured data objects. A client retrieves a data graph from a data source, modifies the data
graph, and can then apply the data graph changes back to the data source.
The task of connecting applications to data sources is performed by Data Access Service (DAS).
A DAS is a Java class that provides methods to load a data graph from a data store and to save a
data graph back into that data store. For example, an XML file DAS would load and save a data
graph as an XML file, and a JDBC DAS would load and save a data graph using a relational
database.
Client applications query the DAS and get a data graph in response. Client applications send an
updated data graph to the DAS to have the updates applied to the original data source.
DAS typically uses a disconnected data architecture, whereby the client remains disconnected
from the DAS except when reading a data graph or writing back a data graph.
Data graph
Data object
Read / Update
Database
Read / Update
Web service
Data access
service
Application
client
Read / Update
EJB
Read / Update
XML DB
Change
summary
SDO Data Architecture

SDO provides flexible data structures that allow data to be organized as graphs of objects (called
data objects) that are composed of properties. A data object holds a set of named properties, each
of which contains either a simple data-type value or a reference to another data object. A data
object can maintain a change summary of the alterations made to it, providing an efficient
communication of changes and a convenient way to update an original data source.
The data graph provides an envelope for data objects and is the normal unit of transport between
components. Data graphs can track changes made to the graph of data objects. Changes include
inserting data objects, deleting data objects, and modifying data object property values. SDO
permits disconnected data access patterns with an optimistic concurrency control model.
A typical scenario for using a data graph involves the following steps:
1. The caller application sends a request to a DAS to load a data graph.
2. The DAS starts a transaction against the persistent store to retrieve data, creates a data
graph that represents the data, and ends the transaction.
3. The DAS returns the data graph to the caller application.
4. The caller application processes the data graph.
5. The caller application calls the DAS with the modified data graph.
6. The DAS starts a new transaction to update the data in the persistent store based on the
changes that were made by the end user.
SDO Data Architecture
SCA
Application
client
SDO
Web browser
Composite
B
SDO
Composite
C
SDO
Database
Composite
A
Web service
Mobile devices
SCA and SDO

SCA and SDO used together provide a powerful and flexible way of building applications
around a Service-Oriented Architecture.
SCA provide a model for creating and assembling service components into a business solution,
and SDO complements SCA by providing a common means to access many different types of
data.
As shown in the slide, the SCA accesses different data sources in a consistent format by
incorporating the SDO specification. Similarly, SDO enables SCA to cater to different types of
client applications.
SCA and SDO
3
1
Creating an SOA Composite in JDeveloper 11g

The slide illustrates the steps for creating an SOA composite in Oracle JDeveloper 11g.
The name you select for the project is used as the name for the SOA composite application
created within the project. The initial types of SOA composites created are:
Empty Composite: Creates a composite without SOA components (empty SCA
descriptor)
Composite With BPEL: Creates a composite containing a single BPEL component. For
this option, you are provided with another screen to specify the initial details for the BPEL
component type.
Composite With Business Rule: Creates a composite containing a Business Rule
component and the associated rules dictionary file, based on the information you enter in a
Create Business Rule configuration dialog box
Composite With Human Task: Creates a composite with a Human Task that is
configured with information entered in a Create Human Task component dialog box
Composite With Mediator: Creates a composite with a Mediator component type based
on your selection in the Create Mediator component dialog box
To create a new SOA project containing an SOA composite as shown in the slide, perform the
following tasks:
1. Select New Application in the Application Navigator pane and enter the details in the
Create Application dialog box.
2. Select SOA from the project technologies.
3. Select the specific composite template that you want to use for developing the composite
application.
Creating an SOA Composite in JDeveloper 11g
Services are
entry points to
the composite
that advertise
capabilities to
the outside
world.
Components are building

blocks that are wired together
to assemble the application.
References
enable the
composite to
communicate
with the
outside world.
The Source tab shows the XML

source.
Describing the SOA Composite Editor

The SOA Composite Editor enables you to create, edit, and assemble services in a composite
application. These service components are integrated together into one application and
communicate with the outside world through binding components, such as Web services and
JCA adapters. An SOA composite application can consist of multiple projects (for example, an
SOA project, a Web project, and business components project). You deploy the application a
single time into a single run-time environment, instead of deploying components separately to
multiple run-time environments.
The following key elements in the Composite Editor directly map to corresponding SCA
elements:
Exposed services, which are the composite service entry points enabling external clients to
interact with the composite
Components, which form the building blocks of the composite application and provide
business functionality implemented by the component type. Components can be:
- A BPEL process
- Business Rule
- Human Task
- Mediator
Describing the SOA Composite Editor
Describing the SOA Composite Editor (continued)

External references, which identify services that provide functionality for the composite
to use
Wires, not shown in the image, which connect elements together to assemble the
application
Components can be exposed as services to an external client, can interact with each other, and
can reference other services. After creating services, components, and external references, the
Composite Editor enables you to visually wire elements together to assemble the application.
Wiring involves connecting a service entry point to compatible component interfaces, one
component to another component interface within the composite, and components to external
references. The Source tab enables you to see the XML describing the composite assembly.
Exposed services can be created by dragging:

A BPEL, Mediator, or a Human Task service component
into the Components area and selecting the component to
expose it as a service
A service adapter, such as a Web service or a file adapter,
into the left swim lane
Recommended
practice:
Deselect this
option while
creating a
BPEL process.
Creates a service interface

(entry point)
Creating Exposed Services

To create a service interface for the SOA composite, you can perform one of the following:
Expose an SOA component in the composite service WSDL by selecting to expose the
component as a composite service when you create it. This is possible for BPEL, Mediator,
and Human Task components.
Explicitly drag one of the Service Adapter component types into the Exposed Services
swim lane, and define the desired service entry point details in the component wizard
pages. This is the suggested technique to manually construct a service interface for the
composite application.
Note: Application developers should deselect the Expose a Composite Service option when
creating SOA components, and manually create a service interface with a Web Service Adapter
Service component.
Creating Exposed Services
Create SOA components by dragging the desired component type

from the Component Palette into the Components column in the
Composite Editor.
Note: composite.xml is modified accordingly.

Creating SOA Components

The slide shows visual examples of the different types of SOA Service Components that can be
added into the Component area in the Composite Editor. The example shown in the graphic is
not a complete composite sample, although it does show an instance of a BPEL component as
being exposed as a servicethat is, representing the composite service entry point. For each
component dragged into the Components area, the composite.xml file is modified with the
addition of XML elements representing the component and points to an additional file added to
the project folder containing the component type information needed for composite assembly
information.
Note: The slide titled Examining the SCA Descriptor shows the XML elements that make up
the composite.xml file for the preceding example.
Creating SOA Components
<?xml version="1.0" encoding="UTF-8" ?>


<composite name="SOACompositeDemo">
...
<service name="bpelprocess_client_ep" ui:wsdlLocation="BPELProcess.wsdl">
...
</service>
<component name="BPELProcess">
<implementation.bpel src="BPELProcess.bpel"/>
</component>
<component name="BusinessRule">
<implementation.decision src="BusinessRule.decs"/>
</component>
<component name="Humantask">
<implementation.workflow src="Humantask.task"/>
</component>
<component name="Mediator">
<implementation.mediator src="Mediator.mplan"/>
</component>
<wire>
<source.uri>bpelprocess_client_ep</source.uri>
<target.uri>BPELProcess/bpelprocess_client</target.uri>
</wire>
</composite>
Examining the SCA Descriptor

The XML code in the slide has been formatted to make it easier to read. The code example
highlights the following key elements in the composite.xml file:
The <composite> element that encapsulates the entire composite assembly information
The <service> element representing the service exposed by the composite. The service
element contains the <interface.wsdl> and <binding.ws> elements to expose
the service to external clients.
The <component> element representing the BPEL component in the composite and a
link to the source implementation file
Note: A <component> element for each of the other component types should also be
present. For brevity, these have been removed from the preceding example.
The <wire> element, which shows how the composite elements track the assembly
information about which services are connected to components, and so on
Note: The composite would also contain a <reference> element for external services
referenced by components in the composite. The example does not show any <reference>
elements.
Examining the SCA Descriptor
SDO provides a metadata API, which allows applications, tools,

and frameworks to introspect the data model for a data graph.
1. True
2. False
Answer: 1
Explanation: SDO is based on the concept of disconnected data graphs. A data graph is a
collection of tree-structured data objects. A client retrieves a data graph from a data source,
modifies the data graph, and can then apply the data graph changes back to the data source.
Quiz
Dragging a Mediator component into the Components area:

Creates a component based on a template
Creates a <component> element in the SCA descriptor
Results in the following files being added to the project:

A .componentType file, referenced by the SCA descriptor
A .mplan file, for the Mediator implementation
Adding a Mediator Component

When you drag a Mediator component from the Component Palette into the Components area,
you are prompted for the name of the component and a template from the following choices:
Define Interface Later, as shown in the slide, creates a Mediator component without an
interfacethat is, no WSDL file and no wires.
Asynchronous Interface enables you to define an asynchronous Mediator component with
an invoke and callback operation. In this case, a WSDL file is created for the interface and
added to the composite project.
Synchronous Interface enables you to define a synchronous Mediator component with an
invoke operation that returns a result. A WSDL file is also created for the interface and
added to the composite project.
One-Way Interface defines an asynchronous Mediator component without a callback
operation. A WSDL file is created for the interface and added to the composite project.
Interface Definition from WSDL creates an interface to the Mediator based on a WSDL,
which you select. The selected WSDL file is added to the project.
Subscribe to Events defines a Mediator component that subscribes to an event described
by a file in Event Definition Language (EDL) format and an associated XSD file. The EDL
and XSD file for the subscribed event is also added to the project.
All template choices result in the creation of a .componentType file and an .mplan file in
the project. A new Mediator component can also be exposed as a composite service entry point.
Adding a Mediator Component
Dragging a BPEL component into the Components area:

Creates a BPEL component
BPEL is exposed
as a service by
default.
Deselect this option
for creating a
composite
application.
The icon
represents the
interface.
Creates a <component> element in the SCA descriptor
Results in the following files being added to the project:

A .componentType file, referenced by the SCA descriptor
A .bpel file, for the BPEL process implementation
Adding a BPEL Process Component

When you drag a BPEL Process component from the Component Palette into the Components
area, you are prompted for the name, namespace, and a template from the following choices:
Asynchronous BPEL Process defines an asynchronous BPEL process interface with an
invoke and callback operation. A WSDL file is added to the composite project.
Synchronous BPEL Process defines a synchronous BPEL interface with an invoke
operation that returns a result. A WSDL file is added to the composite project.
One-Way BPEL Process defines an asynchronous BPEL interface without a callback
operation. A WSDL file is added to the project.
Base on a WSDL defines a BPEL process based on a selected WSDL file. The selected
WSDL file is added to the project.
Define Interface Later creates a BPEL process without an interface. No WSDL file is
added to the project.
Note: Adding a BPEL component for all template choices results in a .componentType file
and a .bpel file being added to the composite project.
In the slide, the Expose as Composite Service option is actually obscured by the Template
drop-down list. This option is selected by default; it causes the composite to expose the interface
definition stored in the WSDL file for the BPEL component. In addition, a wire is created to link
the composites exposed service entry point with the interface of the BPEL component.
Adding a BPEL Process Component
BPEL and Mediator are complementary components. The table

describes some traditional and new differences, as well as
similarities.
BPEL
Mediator
Process orchestration (process-based)
Message routing (routing-based)
Traditionally for medium to long-running

processes
Usually for short, fast message routing.

However, it supports asynchronous
interactions.
Can enrich data through transformations

Can perform content-based routing
Cannot subscribe to or publish events
Can subscribe to and publish events
Used for simple to complex interactions
Used for simple to medium complex

interaction
Comparing BPEL and Mediator

Since the introduction of the Enterprise Service Bus (ESB) technology in Oracle SOA Suite 10g,
now reinvented as Mediator components in Oracle Fusion Middleware Release 11, many
comparisons have been made between the capabilities of BPEL and Mediator (ESB) technology,
sometimes to the detriment of one or the other.
The slide attempts to address some differences and similarities between BPEL and Mediator
components in Oracle Fusion Middleware Release 11 because there have been some changes to
the two technologies and implementation options.
The key idea to remember is that BPEL and Mediator are complementary technologies that can
be effectively deployed together to realize a range of simple to complex integration and
interaction patterns that can solve many and varied business requirements.
Mediator can be a powerful component for simple to medium style complex interactions and
exchanges. However, for more process-oriented interactions, BPEL is better suited to the task.
BPEL can cover all the capabilities of Mediator. However, Mediator can be far more efficient at
managing more simple interactions that involve routing, filters, and transformations.
In short, it is a matter of choosing the best component for the task. Best practices are often
determined by what best meets the business requirements as well as the integrators experience
with these technologies.
Comparing BPEL and Mediator
An SOA application contains an SOA Content folder that

contains all SOA content. Under this folder is the following
content:
testsuites
xsd (containing the supporting
schema files)
xsl (containing any supporting XSL files)
Other files such as the BPEL source file,
WSDL, the componentType file, and the
composite.xml file
Examining the JDeveloper Workspace, Projects, and File Structure

The slide shows an example of the content and structure within an SOA application. All content
and files related to components, such as BPEL processes, Mediator components, and services,
are grouped in the SOA Content folder. As you modify the application, additional files and
folders may be created, depending on the modifications being made.
The Schemas node contains XML schemas generated for the project or XML schemas imported
into the project.
The Test Suites folder supports the SOA Test features for the unit and system testing of BPEL
processes with or without the actual services in place.
Examining the JDeveloper Workspace, Projects,

and File Structure
Editing existing service components:

Modifies the component source and can modify
composite.xmlfor example, wires and references are
added when creating:
A partner link in a BPEL process component
A routing rule in a Mediator component
Implies source-code control considerations. Related

components should be:
Checked out and checked in together
Implementing the functionality in the same SOA project
To edit a
component, doubleclick its icon.
Component
Source code is
opened in a visual
editor and is typically
stored in XML format.
Editing a Component in a Composite

This slide highlights how to start the editing process and some of the implications of editing
components.
Each SOA component added to the composite needs to be edited to implement its functionality
or rules. Double-clicking the icon representing a component opens the Components Editor in
JDeveloper, in which you can design and implement the component implementation.
Edits done to some components will modify the composite in which the component resides. The
slide lists a couple of examples. In this case, it is important to know that several project files
might be modified, even when you are editing a single component. From the perspective of
source code control, consider the SOA project and all its dependants to be subject to the same
check-out and check-in cycle.
The specific details on creating and editing the component source, such as the Mediator and
BPEL processes, are discussed in detail in subsequent lessons of this course.
Editing a Component in a Composite
References are created in the Composite Editor:

Directly by dragging an Adapter Service item from the
Component Palette into the External References column
Indirectly when creating links to services within
components
2
Services will come from a

service registry.
1
Creating External References

The slide shows some typical steps needed to create an external reference.
1. A Web Service item from the Service Adapter list in the Component Palette is dragged into
the External References column.
2. The Create Web Service wizard page is used to configure the reference details. Note that
Type is set to Reference (the other option is Service).
3. In the Create Web Service wizard page, click the SCA Reference Lookup icon to the right
of the WSDL File field. In the SCA Resource Lookup, search for and select the target
external service being referenced.
4. After completing the creation of the Web Service reference definition, click OK. The
External Reference icon appears in the Composite Editor in the External Reference
column.
Creating External References
Creating wires in the Composite Editor:

Defines the interactions between service entry points,
components, and references
Represents connections between SCA elements, such as:
An exposed service wired to a component interface
A component wired to an external reference
A component wired to another component interface
Connects a reference icon with a compatible service

Interface
interface
Create a reference.
Creating Wires
Creating wires in the Composite Editor:
Defines the interactions between service entry points, components, and references
Represents connections between SCA elements, such as:
- An exposed service wired to a component interface
- A component wired to an external reference
- A component wired to another component interface
Connects a reference icon with a compatible service interface defined by an internal
component, or external reference
Note: Wires can also be created when you are creating links to services within component
implementations.
The slide shows an example of an exposed service wired to a BPEL component, whose Create
Reference icon is dragged to the File Adapter external reference interface to wire them together.
The BPEL Process component is already wired to a Mediator component, completing an end-toend composite implementation example.
Creating Wires
The table shows a subset of changes made to components

when they are connected with a wire.
From
To
Result
Exposed service
Component
The component interface becomes

exposed as a composite WSDL
interface.
Mediator component
Another component
Creates a routing rule in the
An external reference Mediator component
BPEL component
Another component
Creates a partner link in the BPEL
An external reference process
Creating Wires Modifies Connected Elements

The slide table shows some of the implications of wiring a subset of different SCA elements
together. For now, because you have not covered details about each different component
implementation, the key idea expressed is that some changes made in the composite do affect the
source of the associated component.
A wire cannot be made between components that have incompatible interfaces. For example, a
mediator can only have one inbound service. Therefore, it rejects attempts to create a wire to a
second inbound service. Similarly, you cannot connect an inbound Web service configured with
a synchronous WSDL file to an asynchronous BPEL process.
Creating Wires Modifies Connected Elements
To expose a component interface as an external service:

1. Drag a Web service into the
Exposed Services column.
1
2. Select the WSDL file for the
component being exposed.
3. Drag a wire from the Exposed Service element interface to
the component interface.
3
2
Exposing Components as an External Service

The steps shown in the slide represent one technique that can be used to expose a component as
an external service, if it was initially created without exposing it as an external service. The key
to ensuring that the interface of the exposed service is compatible (or the same) as the
component being exposed is to use the WSDL file describing the component interface in the
creation of the exposed service.
Exposing Components as an External Service
What is the file extension of the Mediator component

implementation file in JDeveloper 11g?
1. .componentType
2. .bpel
3. .mplan
4. .decs
Answer: 3
The .componentType file extension is referenced by the SCA descriptor and the .bpel file
extension for the BPEL process implementation
Quiz
2
3
Deploying an SOA Composite Application

To deploy the application containing the SOA project, perform the following steps:
1. In the Application Navigator, select the application from the Application menu and click
Deploy > deployment_profile_name > to > connection_name.
deployment_profile_name is the name of the SOA Bundle deployment profile, and
connection_name is the name of the Application Server Connection you created.
2. For each SOA project in the archive whose Revision ID option in SOA Project deployment
properties was not selected, the Revision ID window is displayed. In the Revision ID
window, enter the revision number for the application deployment. Click OK.
3. Enter the authorization credentials of the application server.
4. In the Deployment Log window, monitor the deployment progress in the Deployments
and SOA tabbed pages.
Deploying an SOA Composite Application

Explain the Service Component Architecture (SCA) and its
components
Discuss components of the SCA
Describe Service Data Objects (SDO)
Create an SOA composite application in JDeveloper
Summary
This lesson described the SCA assembly model and composite applications and their various
components. You should understand the various steps in creating a composite application and
how to deploy the same using JDeveloper.
In the next lesson, you will be introduced to the Enterprise Manager Fusion Middleware Control
for monitoring and managing deployed SOA composite applications.
Summary

Deploying an SOA composite application to Oracle SOA
Suite 11g
Creating an SOA composite application workspace in
Oracle JDeveloper 11g
Creating the service interface and external references for
the SOA composite application
Creating an SOA Composite Application
Managing and Monitoring SOA Composite

Applications
SOA
The Managing and Monitoring SOA Composite Applications lesson introduces

using the Enterprise Manager Fusion Middleware Control to perform basic
administrative and monitoring task related to SOA composite applications.
Course Roadmap
In the Creating a Composite Application lesson, you were introduced to the Service Component
Architecture (SCA) assembly model and how to create a composite application.
The Managing and Monitoring SOA Composite Applications lesson introduces the use of
Enterprise Manager Fusion Middleware Control to perform basic administrative tasks.
Course Roadmap

Understand the basic administrative and monitoring tasks
related to SOA composites
Work with the Enterprise Manager (EM) Web interface
Manage SOA composite applications from the Enterprise
Manager Web interface
Deploy and undeploy SOA composites
Test an SOA composite application
Track message flow through an SOA composite
application
Objectives
Managing and monitoring an SOA application involves using

the Enterprise Manager Fusion Middleware Control for tasks
such as:
Deploying and managing the state of composite
applications
Redeploying or undeploying applications
Testing composite applications and viewing the results
Locating composite application instances
Tracking and monitoring message flow and events in the
system
Perform configuration tasks
Note: Some of these tasks can be done from JDeveloper.
Overview of Managing SOA Applications

The Fusion Middleware Control is a Web browserbased graphical user interface (GUI) used for
monitoring and administering a farm.
A farm can be defined as a collection of components managed by the Fusion Middleware Control. A
farm that is managed by the Fusion Middleware Control contains:
One domain
Oracle Fusion Middleware components that are installed, configured, and running on the
domain
You can manage and monitor SOA composite applications by using the Oracle Enterprise Manager
Web interface. The Oracle Enterprise Manager enables you to:
Perform configuration tasks that consist of setting properties to values that are applicable to the
SOA environment
Monitor Oracle SOA Suite, which consists of handling faults and rejected messages and
monitoring the performance of SOA composite applications, service components, service
engines, and service and reference binding components
Manage Oracle SOA Suite including tasks such as starting up and shutting down the SOA
infrastructure application, deleting and aborting composite application instances, and
performing deployment-related actions for SOA composite applications
Overview of Managing SOA Applications
Oracle Enterprise Manager 11g is used to administer, monitor,

and manage SOA composite applications and SOA service
engines. To access Enterprise Manager via a Web browser:
Enter a URL such as: http://localhost:7001/em
Log in as the administrator user: weblogic
Note: The Web application is subject to a session timeout.
Managing with Oracle Enterprise Manager

Oracle Enterprise Manager 11g Fusion Middleware Control is the primary tool for managing,
monitoring, and configuring the SOA run-time environment and components.
To access the Fusion Middleware Control, use a Web browser and enter a URL such as
http://localhost:7001/em.
Note: Replace the host name and port in the URL with values suitable for your installation.
By default, the administration user name is weblogic, whose password is set when the WebLogic
Server is installed.
By using the Fusion Middleware Control, you can perform tasks such as:
Deploying and undeploying composite applications
Managing the run-time state of composite applications
Shutting down and restarting composite applications
Initiating tests of SOA applications by using a Web-based service testing tool
Tracking and monitoring composite application instances and message flows through a
Examining and managing application fault conditions
Monitoring component engines
Managing with Oracle Enterprise Manager
SOA server status

Application
deployment summary
Hierarchical
navigation bar
with access to
SOA Suite
components
SOA server
components
Deployed composite
applications
Oracle Enterprise Manager Fusion Middleware Control

Oracle SOA Suite is a middleware component of Oracle Fusion Middleware that:
Provides a complete set of service infrastructure components for designing, deploying, and
managing SOA composite applications
Enables services to be created, managed, and orchestrated into SOA composite applications
To administer Oracle SOA Suite, you use the Oracle Enterprise Manager Fusion Middleware
Control. The SOA infrastructure is implemented as a Java EE-compliant application that:
Executes in the Oracle WebLogic Server environment
Manages composites and their life cycles, service engines, and binding components
SOA composite applications designed in Oracle JDeveloper are deployed to the SOA infrastructure.
Deployed composite applications are visible in Oracle Enterprise Manager Fusion Middleware
Control. From the Fusion Middleware Control (SOA infrastructure) home page, you can:
Perform administration tasks, such as monitoring SOA composite applications and monitoring
individual composite instances
Update the state of SOA composite applications and individual composite instances
Perform corrective actions such as fault recovery

Fusion Middleware Control
Click the soa-infra link in the Farm navigation bar or in the

Deployments section of the Fusion Middleware home page.
SOA Infrastructure view

of completed or running
application instances,
deployed composites,
and application faults
Accessing the SOA Infrastructure Home Page

When you click the soa-infra link, either in the Farm navigation bar (as shown in the slide) or
under the Deployments section of the Fusion Middleware home page, the SOA Infrastructure home
page is displayed showing the Dashboard tab containing sections for:
Recent Composite Instances, in which you can view completed composite application instances
and those currently running. You can select the Show Only Running Instances option to view
only in-flight applications. You can click an instance ID link to monitor an applications
progress or to view what happened in a completed application. Clicking one of the composite
links accesses the composite applications home page.
Deployed Composites, in which you can view the list of deployed composite application
versions with their status and mode, and a count of the number of instances that are running and
completed
Recent Faults and Rejected Messages, in which you can locate faults and start troubleshooting
the problem by clicking a log link for each fault or accessing the application instance
information via the links provided
Note: The Deployed Composites, Instances, and Faults and Rejected Messages tabs enable you to
locate more information about each of those items, as well as to search for specific information in
those tab pages. The SOA Infrastructure link contains a menu that enables you to manage different
aspects of the SOA infrastructure, the applications, and their environment.
Accessing the SOA Infrastructure Home Page
In the Fusion Middleware Console, click the composite

application [version] link under the SOA > soa-infra node.
Farm navigation bar

links
Deployments
links
Accessing a Composite Application Home Page

To access a composite application home page, expand the SOA > soa-infra tree in the Farm
navigation bar (or under the Deployments section) and click the name [version] link of the
composite application. As seen on the previous page, you can also access the composite application
page from the SOA infrastructure (soa-infra) home page.
Accessing a Composite Application Home Page
Recent Instances
Faults and Rejected

Messages
Component Metrics
Services and References
Example Composite Application Home Page

The home page for each composite application, such as the Hello World Composite example shown
in the slide, contains a summary of the information about that composite application. Within the
home page, details to track, monitor, and troubleshoot the execution of composite application
instances are organized on tabbed pages.
Each time you initiate a composite application, a new application instance is created to handle the
specific request message or event. Each instance is allocated a unique instance ID, which is shown as
a link in the Dashboard and Instances tabbed pages. If you click the instance ID link for a composite
application, you drill down to the details about the specific execution details for that instance.
Buttons arranged in a toolbar across the top of the composite application page, just above the tabs,
enable you to manage composite applications.
The Retire button enables you to stop further instances of the application and prepare the
application for removal from the system.
The Shut Down button allows existing instances to complete but prevents new instances from
being initiated.
The Test button takes you to a page where you can initiate new instances of the composite
application and examine the results.
The Settings button enables you to change audit level and payload validation settings.
Note: The SOA Composite menu enables you to perform additional functions, such as undeploying
the application and navigating to other SOA infrastructure pages.
Example Composite Application Home Page
A composite application:
Is deployed as an SOA archive (a SAR file) that includes
all service components in a single application package
Can be deployed by using multiple tools, such as:
Oracle JDeveloper through a project profile
Oracle Enterprise Manager 11g Fusion Middleware Control
Command-line tools, such as Ant and WLST
JDeveloper
Command line
Oracle Fusion
Middleware
Server
SOA project
SOA archive (SAR)
Deployment profile
Fusion Middleware
Control
Deploying a Composite Application

An SOA archive (SAR) is a deployment unit that describes and contains the SOA composite
application. The SAR file is a JAR file that packages service components such as BPEL processes,
business rules, Human Tasks, and mediator routing services into a single application.
The slide shows an SOA project and deployment profile created in the JDeveloper development
environment. A project can have one or more deployment profiles, which JDeveloper uses to create
the SOA archive file.
As already experienced, JDeveloper can deploy the SAR file directly to a target Fusion Middleware
server (SOA server) through an application server connection. However, after the SAR file has been
generated by JDeveloper, it can be deployed to an SOA server by using the Fusion Middleware
Control Web application and by using command line tools, such as Ant or the WebLogic Scripting
Tool (WLST).
Deploying a Composite Application
3
4
Deploying SOA Composite Applications

To deploy an application by using the Oracle Enterprise Manager 11g Fusion Middleware Control
console, execute the following steps:
1. In the left pane, you see the domain and a list of folders. Expand the WebLogic Domain >
domain1 folder. You also see a list of servers registered with the domain. Right-click soaserver1 and select SOA Deployment > Deploy from the shortcut menu.
2. On the Select Archive page, click the Browse button in the Archive or Exploded Directory
section and select the application archive. Click Next.
3. On the Select Target page, select the WebLogic server to deploy the composite. Click Next.
4. On the Confirmation page, click Deploy to deploy the application onto the server. If the
deployment is successful, you see the application deployment successful message.
Deploying SOA Composite Applications
Initiating an SOA Composite Application Test Instance

To test a Web service by using the Oracle Enterprise Manager 11g Fusion Middleware Control
1. In the left pane, expand the soa-infra folder and select the deployed composite application
from the list of deployed composite applications. In the right pane, click the Test icon.
2. On the Test Web Service page, scroll down and enter the input arguments (either in tree view or
XML view mode) in the Request pane. Click Test Web Service.
3. View the result in the Response pane.
Initiating an SOA Composite Application Test

Instance
1
Invocation in Tree
view mode
Click Launch Message

Flow Trace to view the
message flow through a
Tracking Message Flow

This slide shows a response from an invocation of an asynchronous service in XML view mode.
Regardless of whether the composite application message is synchronous or asynchronous, the
Launch Message Flow Trace link is always displayed.
Click the Launch Message Flow Trace link to open the Flow Trace page so that you can view the
inner operation and state of the initiated composite application.
Tracking Message Flow
The Flow Trace page:

Presents a tree view of the message flow
Enables drilling down into composite components
Trace with instance

IDs
Click a component to
view an audit trail of
the message flow
within the component.
Working with the Flow Trace

The slide shows an example of the Flow trace for a composite application. The main Flow Page
shows the following information about your composite application:
Faults indicate the faults and error messages in the context of the components in which the
faults occurred.
Sensors report any sensor information written in the SOA infrastructure database, typically
from BPEL process component sensor activity.
The Trace itself is a tree-like structure that provides a visual view of the message flow through
the composite application components.
Within the Trace trees, executed components are displayed as links. If you click the link of any
component, the component-specific Audit Trail page is displayed where you can examine the inner
workings from the request through the response message as processed by that component.
Note: The slide also shows the Trace display when you select the Show Instance IDs option.
Working with the Flow Trace
Locator links
Faults (if any)
Activity details
Working with the Component Audit Trail Page

1. The first screenshot in the slide shows how audit trail information is displayed for a mediator
component present in a composite application. By default, the audit trail shows a sequence of
events that takes place within the component. To view the actual message, you must expand the
appropriate node. The <payload> part of the onMessage event or for the onCase operation
usually has an XSL transformation associated with it.
The component audit trail is a tabbed page with the Instance Details of component-name page
where component-name in this case is the routeData mediator. The top of the page has locator
links (breadcrumbs) that enable you to navigate back to the Flow Trace page.
2. In case of a BPEL component, clicking an activity of the BPEL process instance displays the
activity details in XML format.
Note: If the component has not completed its processing, you can click the Refresh icon to update
the page contents as required.
Working with the Component Audit Trail Page
The Flow Trace represents a ___________ view of the

message flow.
1. Tree
2. XML
Answer: 1
Explanation: Using the Flow Trace page, you can view the inner operation and state of the initiated
composite application in a Tree view.
Quiz
View deployed applications
Manage deployed applications
Managing the State of Deployed SOA Composite Applications

The Dashboard tabbed page displays informationsuch as the recent instances of the application, the
faults, the rejected messages, and the policiesfor the application selected in the navigation pane.
You can manage the state of the deployed SOA composite applications from the Deployed
Composites tabbed page of the SOA infrastructure.
The following management tasks can be performed on the Dashboard and the Deployed Composites
tabbed pages:
Shut Down: Shuts down a running SOA composite application revision
Start Up: Restarts a composite application revision that was shut down
Retire: Retires the selected composite revision
Activate: Activates the retired composite application revision
Set As Default: Sets the selected composite application revision to be the default
Deploy: Deploys a revision. Deployment activates the composite application in the SOA
infrastructure.
Undeploy: Undeploys the selected composite application revision. You can no longer
configure and monitor this revision of the composite application.
Redeploy: Redeploys an existing revision of an SOA composite application. A new version of
a revision of a currently deployed SOA composite application is redeployed (for example, old
version 1.0 is redeployed as new version 1.0).
Managing the State of Deployed SOA Composite

Applications
Monitoring and Deleting Specific SOA Composite Application Instances

To monitor and delete SOA composite application instances at the SOA infrastructure level:
Select soa-infra in the SOA folder.
Click the Instances tab. The Instances tabbed page displays the following details:
- A utility for searching for a specific instance by specifying a criteria and clicking Search..
- All SOA composite application instances in the SOA infrastructure, including instance
and conversation IDs, composite name and revision, SOA composite application instance
state, and instance start time
To delete an instance, select a specific instance by clicking a row in the Instances table. Then
select one of the specific actions to perform:
- Delete Selected: Deletes the selected instance
- Delete With Options: Prompts you to first specify a criteria for deleting the selected
instance directly from the database
- Abort: Aborts the selected instance
In order to show the message flow through the various service components and binding
components, click a specific instance ID.
In the Logs column, click a specific log to access the Log Messages page with filtered
messages specific to that instance.
In the Composite column, click a specific SOA composite application to access its home page.
Monitoring and Deleting Specific SOA Composite

Application Instances
Recovering from SOA Composite Application Faults

To recover from SOA composite application faults at the SOA infrastructure level:
Select soa-infra in the SOA folder.
Click the Faults and Rejected Messages tab.
The Faults and Rejected Messages tabbed page displays the following details for all SOA
composite application faults:
- A utility for searching for a specific fault by specifying a criteria and clicking Search.
Click the Help icon for details.
- Faults and rejected messages, including the error message, whether you can recover from
the fault, the time of the fault, the SOA composite application in which the fault occurred,
the fault location, and the instance ID
Click the row of the fault that has been identified as recoverable.
Select an action from the Recovery Actions list. The actions available under the Recovery
Actions List are:
- Retry: Retries the instance directly
- Abort: Aborts the entire instance
- Replay: Replays the entire scope again in which the fault occurred
- Rethrow: Rethrows the current fault
- Continue: Ignores the fault and continues processing
Recovering from SOA Composite Application

Faults
Additional monitoring tasks that can be performed within the faults table include:
Displaying the fault IDs for the each error message
- From the View list, select Columns > Fault ID to display the fault IDs for each error
message. The fault ID is automatically generated and uniquely identifies a fault. The fault
ID also displays when you click an error message.
Accessing the SOA composite application home page
- In the Composite column, click a specific SOA composite application to access its home
page.
Identifying the fault location
- In the Fault Location column, click a specific location to access the faults page for the
location of the fault. The location can be a service, service component, or reference.
Accessing the flow trace of the instance
- In the Composite Instance ID column, click a specific ID to access the flow trace of the
instance.
Accessing the Log Messages page
- In the Logs column, click a specific log to access the Log Messages page with filtered
messages specific to that instance.
Recovering from SOA Composite Application Faults (continued)

If you want to delete rejected messages, click Delete Rejected Messages. This displays a dialog
for specifying a criteria for deleting rejected messages of all the composites. Specify a criteria
and click Delete.
2
1
Undeploying a Composite Application

To undeploy an application by using the Oracle Enterprise Manager 11g Fusion Middleware Control
1. In the navigation tree, expand the soa-infra in the SOA folder. You see a list of deployed
SOA composite applications. You see a list of servers registered with the domain. Right-click
the SOA composite application that you want to undeploy.
2. Select the SOA Application Deployment > Undeploy option from the shortcut menu.
3. Click Undeploy. The SOA composite application is undeployed.
Undeploying a Composite Application
After you undeploy an SOA composite application revision, you

can no longer configure and monitor this revision of the
1. True
2. False
Answer: 1
Explanation: Once you undeploy the selected composite application revision you can no longer
configure and monitor this revision of the composite application.
Quiz

Work with the Enterprise Manager Web interface
Identify the basic administrative and monitoring tasks
related to SOA composites
Manage SOA composite applications from the Enterprise
Manager Web interface
Deploy and undeploy SOA composites
Test an SOA composite application
Track message flow through an SOA composite
application
Summary
In this lesson you have identified the basic administrative tasks that can be performed by using the
Enterprise Manager Web interface.
In the next couple of lessons you will be using the Enterprise Manager console to deploy your
composite application. You will also be introduced to the different service components such as the
Mediator, BPEL, Human Task, and Business Rule. The functionality of these components will also
be dealt with in detail.
Summary

Initiating an instance of the composite application using the
EM console
Viewing the composite instance information and exploring
the SOA Console interface and environment
Managing and Monitoring Composite
Applications
Working with Mediator Components
SOA
The Working with the Mediator Components lesson introduces Mediator

component and routing functionality, and how to create and configure a
Mediator component.
Course Roadmap
In the Managing and Monitoring SOA Composite Application lesson, you were introduced to
the use of Enterprise Manager Fusion Middleware Control to perform basic administrative tasks
The Working with Mediator Components lesson introduces you to the Mediator component
and its routing functionality.
Course Roadmap

Explain the Mediator component and its features
Define business events and the Event Delivery Network
(EDN)
Create and configure a Mediator service component
Create routing rules
Objectives
Oracle Mediator routes data between service providers and

consumers based on defined rules. This is done either
synchronously or asynchronously, allowing you to implement a
variety of integration patterns.
Introducing Oracle Mediator

Data flowing through Service Component Architecture (SCA) needs to be transformed,
validated, and routed from service producers to service consumers. Oracle Mediator enables you
to route data synchronously or asynchronously between service producers and consumers.
Oracle Mediator provides a lightweight mediation framework to mediate between various
producers and consumers of services and events. The challenge of integrating data from
disparate sources (including business partners, legacy applications, enterprise applications,
databases, and custom applications) can be met by using Oracle Mediator to deliver appropriate
real-time data access to all applications that update or have a common interest in the same data.
For example, an Oracle Mediator service component can accept data contained in a text file
from an application or service, transform it to a format appropriate for updating a database that
serves as a customer repository, and then route and deliver the data to that database.
Oracle Mediator facilitates integration between events and services where service invocations
and events can be mixed and matched. You can use a Mediator component to consume a
business event or to receive a service invocation. A Mediator component can evaluate routing
rules, perform transformations, validate, and either invoke another service or raise another
business event. You can use a Mediator component to handle returned responses, callbacks,
faults, and timeouts. In addition, you can also implement a variety of integration patterns such as
service virtualization, publish and subscribe, fan-in and fan-out, and various synchronous and
asynchronous request response patterns.
Introducing Oracle Mediator

Oracle Enterprise
Service Bus
(OESB)10g
Mediator
OESB 10g
Mediator
Is implemented in a separate ESB runtime container
Is an SCA component implemented as a

part of the common service infrastructure
Is incorporated as an ESB service
Is incorporated as a part of an SOA

Is supported on Oracle SOA Suite 10g
Is supported on Oracle SOA Suite 11g
Oracle Enterprise Service Bus and Mediator

Message-based ESB patterns using adapters, transformation, and routing can be built in a
composite application in SOA Suite 11g. Run-time ESB in not present in SOA Suite 11g.
Instead, there is a modular architecture that consists of a common service infrastructure (shared
with the other components of the SOA Suite) and a routing engine (called the Mediator). The
service infrastructure is the common normalized transport into which are plugged the service
components, such as the BPEL service components or the Mediator service components.
Oracle Enterprise Service Bus and Mediator
To facilitate the integration between message providers and

consumers, Oracle Mediator includes the following features:
Event handling
Validations
Transformations
Error handling
Oracle Mediator Features

Oracle Mediator includes the following features that facilitate the integration between message
providers and consumers:
Can subscribe to and publish business events
Can perform content-based and header-based routing
Can support both synchronous and asynchronous interactions
Can perform transformations and validations on the message data
Can apply filters to the message data
Can support error handling
Can be used to implement a variety of integration patterns, such as:
- Service virtualization: Virtual services are exposed as interfaces that consumers can
connect to via Web services.
- Service aggregation: Services are combined and then exposed as a single interface
that consumers can connect to via Web services.
- Publish and subscribe: One input channel splits into multiple output channels, one
for each subscriber.
Oracle Mediator Features
An Event Delivery Network (EDN):

Is designed for handling asynchronous messaging, arising
from a business or system event
Aligns SOA with Event-Driven Architecture (EDA)
Supports a publish-subscribe declarative model
New
order
Event Delivery
Network
Service
composite
application
New
customer
Event published as XML

described by an XSD
Subscribes to
receive an event
Event Delivery Network

EDAs require an EDN to provide the means to align the delivery of asynchronous messages with
an SOA implementation approach. An EDN:
Enables developers to work with events and not messaging infrastructure.
Provides a declarative way to work with the publish-subscribe model
Offers rich subscription capabilities, such that they can listen for events published with:
- An XML namespace
- A specific events name
- A content-based XPath filter applied
Note: Oracle SOA Suite 11g incorporates an Event Delivery Network into its architecture.
Event-Driven SOA (EDSOA) combines SOAs request-response and EDAs event publishsubscribe paradigms.
Event Delivery Network
Event: A message structure that represents the occurrence of

a business event that must be communicated to other
applications
Business event: Defines the occurrence and structure of an
event when it occurs
Introducing Business Events

An event is a message structure that represents an occurrence of a business event that must be
communicated to other applications. A business event is a name to define the occurrence and
structure of an event when it occurs. Business events consist of message data sent as the result of
an occurrence in a business environment. When a business event is published, other service
components can subscribe to it. Developers declaratively define business events and specify
raise conditions that dictate when the event is raised. As data is changed, these conditions are
evaluated and all events whose raise conditions are met are fired.
You raise business events when a situation of interest occurs. For example, in an order
processing flow scenario, a BPEL process executing an order process can raise a credit-approved
event at the completion of the credit-checking part of the process. Other systems within the
infrastructure of this application can listen for these events and upon receipt of one instance of
an event:
Use the event context to derive business intelligence or dashboard data
Send an email back to the customer to confirm that his or her credit was approved
Invoke another business process
Introducing Business Events
Introducing Business Events (continued)

Business events are a one-way, fire-and-forget, asynchronous way to send a notification of a
business occurrence. The business process does not:
Rely on any service component receiving the business event to complete
Care if any other service components receive the business event
Need to know where subscribers (if any) are and what they do with the data
Oracle Mediator provides support for subscribing to or raising

business events.
Reply
received
Event
raised
New Customer
Creates new profile
Email confirmation sent

to customer
Event Handling
Oracle Mediator provides support for subscribing to business events or raising business events.
You can subscribe to a business event that is raised when a situation of interest occurs. For
example, you can subscribe to an event that is raised when a new customer is created and then
use this event to initiate a business process such as sending a confirmation email. Similarly, you
can raise business events when a situation of interest occursfor example, raise a customercreated event after completing the customer-creation process.
Event Handling
Oracle Mediator provides support for setting rules based on the

message payload or message headers.
Reply
received
France
Data store
Event
raised
Customer updates
profile with new
address.
Routing rule:
What country?
Correct data store is

updated.
Content-Based and Header-Based Routing

Oracle Mediator provides support for setting rules based on the message payload or message
headers. You can select elements or attributes from the message payload or message headers.
Based on the values, you can specify an action. For example, Mediator receives a file from an
application or service containing data about new customers. Based on the country mentioned in
the customers address, you can route and deliver data to the database storing data for that
particular country. Similarly, you can route a message based on the message header.
Content-Based and Header-Based Routing
Oracle Mediator provides support for synchronous as well as

asynchronous request response interaction.
Tracking data
based on
postal code
Customer
places
order.
Validate
credit card.
Order
fulfilled
Synchronous
Asynchronous
Synchronous/Asynchronous Interactions
Oracle Mediator provides support for synchronous as well as asynchronous request response
interactions. In a synchronous interaction, the client requests a service and then waits for a
response to the request. In an asynchronous interaction, the client invokes the service but does
not wait for the response before continuing. The response may come at a later time, or not at all.
You can specify a timeout period for an asynchronous interaction, which can be used to perform
some action such as raise an event or initiate a process.
Synchronous/Asynchronous Interactions
Oracle Mediator provides support for service virtualization

allowing you to separate a service from its physical
implementation.
Initial implementation
Mediator service exposed

through composite WSDL
Service
Composite
Mediator
(exposed)
BPEL
Client
The same Mediator service exposed
through composite WSDL: this means that
the client implementation is not affected.
Service
Modified implementation
Mediator
(exposed)
SOAP
service
Composite
Other
composite
Client
JCA adapter
Service Virtualization
A service definition, in the case of Web services expressed in the form of WSDL, is a contract
between a service provider and a consumer. Often, service providers want to separate a service
from its physical implementation. This usage pattern is referred to as service virtualization. For
example, your Web site exposes its Web services and, in the back end, uses Web services from
other providers. You may want to perform some additional processing or hide the details of the
actual Web service in the back end. In such cases, you can use service virtualization.
Service Virtualization
Oracle Mediator provides support for validating the incoming

message payload using a schematron or XSD file.
Validate
Result
Validations
Oracle Mediator provides support for validating the incoming message payload by using a
schematron or an XSD file. You can specify schematron files for each inbound message part and
Oracle Mediator can execute schematron validations for those parts.
Validations
Oracle Mediator provides support for fault policybased error

handling.
Error condition
raised
Action to
correct
Process
continues
Error Handling
Oracle Mediator supports fault policybased error handling. A fault policy consists of conditions
and actions. Conditions specifies the action to be carried out for a particular error condition.
Error Handling
Oracle Mediator supports data transformation from one XML

schema to another.
Input XML
document
XSL
processor
Output XML
document
XSL
Mapper
Transformations
Oracle Mediator supports data transformation from one XML schema to another. This enables
data interchange among applications using different schemas. For example, the initial XML
schema may have last name and first name as separate values. The other XML schema may have
the full name (both first and last) stored as one value. Through transformations, you can
concatenate the first and last name from the initial schema before it reaches the resultant XML
document.
Transformations
Oracle Mediator includes the following features:

1. Event handling
2. Content-based and header-based routing
3. Process orchestration
4. Error handling
5. Business logic implementation
Answers: 1, 2, 4
Explanation
Oracle Mediator includes the following features:
Event handling
Validations
Transformations
Error handling
Quiz
You can create a Mediator component in an SOA composite

application of Oracle JDeveloper by using one of the following
methods:
By dragging and dropping a Mediator component from the
Component palette
By selecting Composite with Mediator in the Create SOA
Composite dialog box or the Create SOA Project dialog
box
By selecting Service Components from Categories and
Mediator from the Items in the New Gallery dialog box
Creating an Oracle Mediator Component

You can create an Oracle Mediator component any time that you want to consume a business
event or receive a service invocation. Oracle Mediator components can be created in Oracle
JDeveloper by using a service invocation or an event subscription as the entry point.
Creating an Oracle Mediator Component
When you first create the Mediator component, you must

specify a name, and then select one of the following options:
Define Interface Later
Asynchronous Interface
Synchronous Interface
One-Way Interface
Interface Definition
from WSDL
Subscribe to Events
Describing Mediator Component Creation Options

In the dialog box that appears when you first create the Mediator component, you must specify a
name and then select one of the following options:
Define Interface Later: This option enables you to create a Mediator first, and later define
the interface for the services or subscribing to events.
Asynchronous Interface: This option enables you to create a Mediator component for
asynchronous interaction.
Synchronous Interface: This option enables you to create a Mediator component for
synchronous interaction.
One-Way Interface: This option enables you to create a Mediator component for a oneway interaction process. In this case, the client sends a message to the service, and the
service does not need to reply or even acknowledge the receipt of the message.
Interface Definition from WSDL: This option enables you to define services for the
Mediator component from a WSDL file. A WSDL file describes the interface of a
Mediator such as schemas and operations.
Subscribe to Events: This option enables you to subscribe to a business event that is
raised when a situation of interest occurs.
Mediator Component Creation Options
Mediator editor
window
Double-click the
Mediator component at
a later time, when you
are ready, to define the
service.

The Define Interface Later option is useful if the services or events are not known or available at
creation time. When you are ready to define the service for the Mediator, double-click the
Mediator component and adjust the required properties.
To subscribe to an event in a Mediator component that was

created with the Define Interface Later option:
On the Mediator editor page, click the Add Event
Subscription icon.
In Subscribed Events, click the Add (plus sign) icon.
Select the Event Definition Language file (requires an
XSD).
1
Define Interface Later (continued)

The slide shows an overview of the steps required to declaratively subscribe to an event in a
Mediator component after that Mediator component was created with the Define Service Later
option. The steps are performed in the Mediator component editor, which is displayed by
double-clicking a Mediator component in the Composite Editor.
View the Source code for the Mediator component from the
Source tabbed page.
Viewing the Mediator Source Code

To view the source code and see the details of the subscribed event for the Mediator component
that you just created, click the Source tab. An example is shown in the slide.
Viewing the Mediator Source Code
To modify a Mediator component, perform the following steps:

1. Double-click the Mediator component.
2. Edit the information as required.
3. Save your changes.
1
2
Modifying a Mediator Component

To edit a Mediator component, perform the following steps:
1. Double-click the Mediator component on the Design tabbed page or in the Application
Navigator.
2. Edit the component information.
Note: You cannot change the name of the Mediator component.
Modifying a Mediator Component
Delete a Mediator component by one of the following methods:

Right-click the Mediator component and select Delete.
Select the Mediator component and click the Delete

button.
Deleting a Mediator Component

To delete a Mediator component, perform the following steps:
1. Select the Mediator component in the SOA Composite Editor.
2. Click Delete at the top of the SOA Composite Editor tabbed page or right-click the
component and select Delete.
3. Confirm that you want to delete the selected component.
You can also delete multiple components in the SOA Composite Editor. To do this, press Ctrl,
select the components that you want to delete, and then click Delete.
Note: Do not delete Mediator components in the Application Navigator.
Deleting a Mediator Component
Routing rules enable you to route data between service

providers and service consumers, applying transformations and
filters as required.
Service
consumer
Service
provider
Routing rules
Specifying Mediator Component Routing Rules

Oracle Mediator enables you to route data between service consumers and service providers. As
the data flows from service to service, it may need to be transformed. These two tasks, routing
and transformations, are the core responsibilities of Oracle Mediator. The next few pages
provide an overview of Mediator routing rules and describe how to specify routing rules for an
Oracle Mediator component.
Specifying Mediator Component Routing Rules
Routing rules determine how the data in a message being

processed by a Mediator component reaches its next
destination. You can specify the following details when
configuring routing rules:
Target service
Filter expression
Execution type
Schematron-based validations
Transformations
Reply, callback, and fault handlers
Introducing Routing Rules

The routing rules determine how a message processed by a Mediator component reaches its next
destination. Routing rules specify where a Mediator component sends the message, how it sends
it, and what changes should be made to the message structure before sending it to the target
service. You can specify routing rules only if a service or an event has been defined for a
Mediator component. When you configure routing rules, you can specify the following details:
Target service: The service to which the message should be sent
Filter expression: The filter expression to be applied. A filter expression specifies that the
contents (payload) of a message be analyzed before any service is invoked. For example,
you may apply a filter expression that specifies that a service be invoked only if the
message includes a customer ID.
Execution type: The way in which routing rules will be executed. You can specify either
of the following execution types: sequential or parallel.
Schematron-based validations: The schematron files for validating different parts of an
inbound message
Introducing Routing Rules
Introducing Routing Rules (continued)

Transformations: Document transformation to be applied. You can use transformation to
set a value on the target payload. You can perform transformation by using mappings or by
assigning values. The XSLT mapper enables you to transform data from one XML schema
to another, thus enabling data interchange among applications using different schemas.
However, to set the target message properties irrespective of the source properties, payload
part, or constants, you can use the Assign Value feature.
Reply, callback, and fault handlers: How synchronous reply, callback, and fault
messages must be handled
Double-click the Mediator component to create new or modify

existing routing rules.
Double-click the
Mediator component.
Expand Routing Rules to adjust properties.
Accessing Mediator Routing Rules

Double-click the Mediator component in the SOA Composite Editor to access the Mediator
component design window. Expand the Routing Rules section (if not already expanded) to
specify the following properties of an event subscription:
Priority: You can specify the priority of an event. The priority determines the order in
which the events are processed. For example, if two events, to which a Mediator is
subscribing, are raised at the same time, the event with the higher priority is processed
first. The priority value can range from 0 to 9.
Validate Schemas: You can select this option to validate the schemas of event messages.
By default, Validate Schemas is set to false.
Accessing Mediator Routing Rules
Defining Mediator Routing Rules

Routing rules can be defined only for a Mediator component that has a service or an event
defined. Routing rules can be defined by using the Mediator editor in Oracle JDeveloper. To
access the Mediator editor, use either of the following two methods.
From the SOA Composite Editor:
1. Double-click the icon that represents the Mediator component for which you want to
specify the routing rules.
2. Click the Plus (+) icon next to the Routing Rules panel to expand it (if not already
expanded).
From the Applications Navigator:
1. Expand the SOA project, followed by the SOA Content folder.
2. In the SOA Content folder, double-click the name of the Mediator component for which
you want to specify routing rules. The Mediator component file has an mplan extension.
3. Click the Plus (+) icon next to the Routing Rules panel to expand it (if not already
expanded).
When you create a new routing rule, you must specify whether the routing rule will invoke a
service or trigger an event.
Defining Mediator Routing Rules
Defining Mediator Routing Rules (continued)

To specify that the routing rule should invoke a service:
1. Click the Plus (+) icon to expand the Routing Rules panel.
2. Click the Add (green plus) icon. The Target Type dialog box is displayed.
3. Click Service. The Target Services dialog box is displayed.
4. In the Target Services dialog box, navigate to an operation provided by a service, and then
select it.
5. Click OK.
Routing rule for a

single target service
invocation
Specifying a Target Service: Example

A target service specifies the next service to which a Mediator should send the message and the
operation to perform on that message when it reaches the target service.
You can specify multiple routings to one inbound operation or event. Each routing is mapped to
one target service invocation or event. Therefore, if you want to specify multiple service
invocations or raise multiple events, you must specify one routing rule for each target service
operation. For example, based on a message payload, you may want to invoke an operation from
the following operations defined in a service:
insert
update
updated
delete
You would then need to create four routings, one for each operation. Later, you can specify a
filter expression and specify which target service and operation is applied to each message
instance on the basis of the message payload.
Specifying a Target Service: Example
Transformations in Mediator are implemented via routing rules.

The XSLT Mapper tool enables correlation of source schema
elements with target schema elements.
1
2
Source
Destination
XSLT Mapper tool
Adding a Transformation to a Mediator Component

Transformations in Mediator are implemented via routing rules you create for the Mediator
component. The XSLT Mapper tool enables transformations in the routing rules that you create
for a Mediator component. Using the XSLT Mapper tool, perform the following steps to map
source schema elements to target schema elements:
1. Click the Transformation Map icon to the right of the Transformation Map field in the
Routing Rules panel. The Request Transformation Map dialog box is displayed.
2. The Request Transformation Map enables you to select the mapper file for message
transformation. You can choose:
- Use Existing Mapper File: This option enables you to use an existing transformation
file. You can use an existing transformation file when you have the same source
schema and target schema used multiple times in the same scenario. You need to
maintain only one copy of the transformation file instead of having multiple copies of
the same transformation files.
- Create New Mapper File: This option allows you to create a new transformation
file. Use this option if you do not have any existing transformation file defined for
the source schema.
Adding a Transformation to a Mediator

Component
Filtering Messages
Routing rules can also be used to filter messages based on their payload. If the expression filter
for a given message instance evaluates to true, the message is delivered to the target
service/operation pair specified within the routing rule.
For example, you want notices of new product launches from headquarters to be routed to three
different stores: one in New York, one in Houston, and one in San Francisco. However, you only
want notices regarding the product line of the MOBILE type to be sent to the New York store.
To implement this, you must define a routing rule for each component/operation pair that sends
messages to the target stores. In addition, for the routing rule that sends messages to the New
York store, you specify a filter expression.
You can specify a filter expression by using the Expression Builder dialog box. This dialog box
is displayed when you click the icon to the right of the Filter Expression field in the Routing
Rules panel.
The Expression Builder dialog box contains components and controls that assist you in
designing a filter expression. To add a variable or function value from the lists provided, you
either double-click the value or select the value and click Insert Into Expression. Using a
combination of variable elements, functions, and manually entered text, you build an expression
by which you want message payloads to be filtered for a given routing rule.
Filtering Messages
Functions palette: This list enables you to select different functions to include in an expression.
When you select a function, a preview of how that function will appear when added to the
Expression field is presented in the Content Preview field, and a description of the function is
presented in the Description field.
Content Preview: This field indicates how a value selected from the Variables field or
Functions palette will appear when it is inserted into the Expression field.
Description: This field provides a description of a value selected from the Variables field or
Functions palette.
Filtering Messages (continued)

The following list describes each of the fields in the Expression Builder dialog box:
Expression field: You can enter the filter expression either manually or by using the Variables
field and the Functions palette in this field. The icons on the upper right of this field enable you
to undo the last edit made, redo the last edit made, or clear the entire Expression field,
respectively.
Variables field: This field contains the message defined for the Mediator component. Oracle
JDeveloper parses the Mediator component WSDL file and presents the message definition in
the Variables field. The input message is stored in the $in variable. You can use
$in.properties to access the properties of an input message. An input message can consist
of multiple parts. You can use $in.<partname> to access a part of an input message.
Sequential:
Message
Routing rule #1
Routing rule #2
Routing rule #3
Outcome
Parallel:
Routing rule #1
Message
Routing rule #2
Outcome
Routing rule #3
Specifying Sequential or Parallel Execution

You can specify the execution type for a routing rule. A routing rule execution type can be
parallel or sequential. In sequential execution, routings are evaluated and actions are performed
sequentially. The caller is blocked during sequential execution. Sequential routings are evaluated
in the same thread and transaction of the caller. In parallel execution, routings are queued and
evaluated in parallel in different threads. The caller is not blocked during parallel execution.
If an operation or event has both sequential and parallel routing rules, first the sequential routing
rules are evaluated and actions are performed, and then the parallel routings are queued for
parallel execution.
To specify an execution type for a routing rule, perform the following steps:
1. Click the Plus (+) icon to expand the Routing Rules panel. The execution options are
displayed on the right of the Routing Rules panel.
2. Select the Sequential or Parallel execution type.
Specifying Sequential or Parallel Execution
Routing rules can be used to filter messages based on their

payload.
1. True
2. False
Answer: 1
Explanation: Oracle Mediator enables you to route data between service consumers and service
providers. As the data flows from service to service, it may need to be transformed. These two
tasks, routing and transformations, are the core responsibilities of Oracle Mediator.
Quiz
It depends on whether the author of the event depends on the

receiver of the event. Typically, the following is the suggested
best practice:
If the author of the event depends on the receiver of the
event, use service invocation.
If the author of the event does not rely on the receiver of
the event in any way, or does not even care who is
receiving the event, use a business event.
When to Use Business Events? When to Invoke a Service?

These are important distinctions between business events and direct service invocations that rely
on the WSDL file contract (for example, a SOAP service client). If the author of the event
depends on the receiver of the event, messaging typically must be accomplished through service
invocation rather than through a business event. Unlike direct service invocation, the business
event separates the client from the server.
When to Use Business Events?

When to Invoke a Service?

Explain the Mediator component and its features
Define business events and the Event Delivery Network
(EDL)
Create and configure a Mediator service component
Create routing rules
Summary
In this lesson you have been introduced to the Mediator components and its features. Using the
Mediator component you can specify routing rules that enable you to perform transformations,
validate, and either invoke another service or raise another business event.
Now that you know how to create a service and how the information can be routed between the
services, in the next lesson you will be introduced to the component that enables orchestrating
these services, which is the BPEL service component.
Summary

Creating a Mediator service component in an SOA
composite
Defining routing rules by using the Mediator component
Deploying and testing the SOA composite
Creating a Mediator Service Component
Orchestrating Services with a BPEL

Component
SOA
The Orchestrating Services with a BPEL Component lesson introduces

process orchestration concepts and how to use Business Process Execution
Language (BPEL) in implementing process orchestration. Additionally you will
be using the BPEL Designer to create BPEL process.
Course Roadmap
In the Working with the Mediator Components lesson, you were introduced to the Mediator
component and its routing functionality.
In the Orchestrating Services with a BPEL Component lesson, you will be introduced to
process orchestration concepts and using the BPEL component.
Course Roadmap

Describe process orchestration concepts
Define and describe Business Process Execution
Language (BPEL) in relation to implementing process
orchestration
Develop a BPEL process by using the BPEL designer in
JDeveloper 11g
Describe activities, partner links, and service invocation in
a BPEL process
Objectives
Process orchestration coordinates events in a process from a

single environment. Orchestration:
Directs and manages the assembly of multiple services
Creates a composite application for a business process
Relies on BPEL
Check credit
Client
Business process
expressed in BPEL
Process order
Process Orchestration Concepts

The concept process orchestration encompasses the idea of coordinating events in a business
process from a single environment. Orchestration:
Directs and manages the on-demand assembly of multiple services
Results in the creation of a composite application forming a business process
Industry has now converged on using the Business Process Execution Language for Web
Services (BPEL4WS) as the core standard for Web services orchestration, simply known as
Business Process Execution Language (BPEL).
Oracle BPEL Process Manager provides a run-time environment for executing composite
applications developed in BPEL.
Process Orchestration Concepts
Credit
service
<variable>
<process>
Start
BPEL
process
10 a.m.
<invoke>
Handle negative
credit exception
<faultHandlers>
Get rating
<partnerLink>
Send
order
SM
service
<flow>
Send
order
RD
service
<invoke>
<receive>
<partnerLink>
Receive
quote
<switch>
</process>
</flow>
Receive
quote
<partnerLink>
Select
lowest
3 p.m.
End
quote
Introducing Business Process Execution Language (BPEL)

The graphic illustrates a notation for specifying business process behavior and interaction with
services, Web services, or other services exposed through WSDL. The notation used is called
BPEL. BPEL is a markup language for composing a set of discrete services into an end-to-end
process flow and replaces the earlier usage of the XLANG and the Web Services Flow Language
(WSFL) specifications. Processes developed in BPEL export and import functionality by using
service interfaces described by their WSDL.
A business process can be described in two ways. A business process is:
An executable process of the actual behavior of a participant in a business interaction
An abstract process describing a business protocol
BPEL models the behavior of both executable and abstract processes. A business protocol uses
process descriptions that specify the shared message structures exchanged between parties
involved in the protocol, without exposing their internal behavior.
BPEL:
Is a language for the formal specification of business processes and interaction protocols
Extends the Web Services interaction model and enables support for business transactions
Defines an interoperable integration model facilitating the expansion of the automated
process integration of internal and external services
Is graphically modeled to be processed and executed by a BPEL process engine
Introducing Business Process Execution

Language (BPEL)
Introducing Business Process Execution Language (BPEL) (continued)

BPEL Depends on WSDL
BPEL depends on the following XML-based specifications:
WSDL 1.1
XML Schema 1.0
XPath 1.0
WS-Addressing
Among these, WSDL has the most influence on BPEL whose process model is layered on top of
the service model defined by WSDL. The BPEL process model is based on the concept of peerto-peer interaction between services (or partners) described in WSDL.
The BPEL process coordinates interactions between a process instance and its partners. Both the
BPEL process and its partners are modeled as WSDL services. Therefore, the BPEL process
definition:
Interacts with one or more WSDL services
Provides the description of the behavior and interactions of a process instance through
WSDL. That is, the definition of a BPEL business process follows the WSDL model of
separation between the message contents and deployment information (messages and port
type versus binding and address information)
In short, a BPEL process is a Web service.
Process
template
types
Creating a BPEL Process

The slide shows the steps to create a BPEL process as a part of an SOA composite application:
1. Drag the BPEL Process service component from the Component palette to the Components
area in the SOA Composite Editor.
2. On the BPEL Process page, enter the name of the service component (such as
doOrderProcessing), and select one of the following template types:
- Asynchronous BPEL Process: The default, which populates the BPEL process with
an initial Receive and a final Invoke (callback) activity forming the basic structure of
an asynchronous process
- Synchronous BPEL Process: Populates the BPEL process with an initial Receive
and a final Reply activity to form the basic structure of a synchronous process
- One Way BPEL Process: Creates a process with a one-way call interface definition
- Base on a WSDL: Creates a BPEL process with an interface defined by an existing
WSDL file. You must specify the WSDL Uniform Resource Locator (URL), port
type, and callback to use. When you select this option, you are prompted to specify
the WSDL file, port type, and (if necessary) callback port type.
- Define Service Later: Creates an empty BPEL process service component with no
activities
Note: The Namespace forms the XML namespace for this BPEL process as a URL
constructed from the project name appended to the default string: http://xmlns.oracle.com/.
This URL string should be changed to suit your project requirements before you complete
the remaining wizard steps.
Creating a BPEL Process
Oracle BPEL Process Designer

Oracle BPEL Process Designer is included as a feature of Oracle JDeveloper. The graphic shows
the JDeveloper interface components that are involved in the development of a BPEL process.
1. Applications Navigator: Displays the JDeveloper workspace, project, and file hierarchy
structure. This window contains additional tabs to access other JDeveloper components,
such as the Connections Navigator (which is used to create connections to the SOA server),
Oracle database instance, and other services.
2. Structure window: Shows a hierarchical structure of the BPEL process or the source code
for the file being examined in the editor
3. Editor: Shows the BPEL source in one of two representations:
- BPEL Diagram tab for a visual representation of activities in a process flow
- Source tab to view the XML source code representing the BPEL process flow of
activities
- History tab to view the source code changes over time
4. Component palette: Provides icons representing activities that can be dragged to the
BPEL diagram to a desired position in the process flow
5. Message Log: Displays validation errors, log messages, and compilation messages.
The BPEL Messages subtab provides design-time BPEL process information.
6. Property Inspector: Can be used to change property values for items selected in the
Diagram view
Oracle BPEL Process Designer
WSDL interface
for BPEL client
Swim lanes
Designing the BPEL Process

The slide shows the BPEL process diagram (shown in the Design view) in the JDeveloper editor,
which is divided into two different types of swim lanes. The Partner Links swim lanes contain
the Partner Links for services interacting with the BPEL process, and the middle swim lane
contains the BPEL process design flow.
Designing your BPEL process is done graphically by dragging items from the BPEL Activities
and Components list in the Component palette to their appropriate location in the middle swim
lane (BPEL process design flow). Here is an example:
The Assign activity is dragged into the process flow, which is being used to copy XML
data contained in one BPEL variable to another. Data is passed into BPEL processes and
onto partner links in XML format. Data in variables can be shared among process activities
whose scope allows them to see the variables.
A Partner Link (Web Service/Adapter) Service component, which represents a link to a
service, is dragged into one of the Partner Links swim lanes from the BPEL Services list in
the Component palette.
The process diagram graphically represents the business process flow. If you click the Source
tab, you can view and edit the BPEL XML source generated by the graphical design changes
that you make in the Design view.
Designing the BPEL Process
A BPEL process coordinates interactions between a process

instance and its partners.
1. True
2. False
Answer: 1
Explanation
BPEL:
Is a language for the formal specification of business processes and interaction protocols
Extends the Web Services interaction model and enables support for business transactions
Defines an interoperable integration model facilitating the expansion of the automated
process integration of internal and external services
Is graphically modeled to be processed and executed by a BPEL process engine
Quiz
When developing a BPEL process, you need:

Business process requirements
Operations to be performed
Business activity flow diagrams and rules to be implemented
Interaction style: synchronous or asynchronous

XML schema document (XSD) defining message
structures for:
Input values
Output results (if any)
Portfolio of orchestrated services and their WSDL and

associated XSD
Developing a BPEL Process

Before developing a BPEL process, you require various information to ensure that you can
complete the business process flow to meet the target business requirements. The information
needed includes:
Business process requirements that define the operations to be supported and the business
rules to be implemented
Interaction style for clients invoking the BPEL process. If the business requires a longrunning process, such as one involving a human workflow, then an asynchronous style is
preferred to avoid making a client wait for process completion. If the service can execute
in a very short timeframe, a synchronous invocation style may be suitable.
An XML schema document (XSD) that defines all the message structures for the BPEL
process input values and its output results (if any are returned as a response to the client)
Access to a portfolio of services to be orchestrated and access to the WSDLs that define
their interfaces and message structures, which ideally should be specified in associated
XSDs that can be imported into your project (as required)
Services that are being orchestrated should be registered in a sharable service repository, such as
Oracle Service Registry, which can maintain artifacts and references to target services that need
to be orchestrated in a BPEL process.
Developing a BPEL Process
Assign
Java Embedding
SMS
Bind Entity
Pick
Switch
Compensate
Receive
Terminate
Email
Receive Signal
Throw
Empty
Reply
Transform
Flow
Scope
Voice
FlowN
Sequence
Wait
Invoke
Signal
While
BPEL Activity Types

The slide shows the icons presented in the list of BPEL activities in the Oracle BPEL Process
Designer Component palette:
Assign: Provides a way to manipulate data, such as copying the contents of one variable to
another
Bind Entity: Is used to create a key to point to the data in an ADF BC data provider
service (via an Entity Variable)
Compensate: Is used to invoke a compensating sequence of activities as a result of a fault
or compensation handler being executed
Email: Provides a way to send an email notification about an event
Empty: Provides a no-operation activity. This could be useful when you need to insert
specific sensor points for monitoring business activity or when a fault needs to be caught
and suppressed.
Flow: Provides a mechanism to specify one or more sequence of activities to be performed
concurrently
FlowN: In the flow activity, the BPEL code determines the number of parallel branches.
However, often the number of branches required is different depending on the available
information. A FlowN activity creates multiple flows equal to the value of N, which is
defined at run time based on the data available and the logic within the process. An index
variable increments each time a new branch is created, until the index variable reaches the
value of N.
BPEL Activity Types
BPEL Activity Types (continued)

Invoke: Enables you to invoke a service (identified by its partner link) and specify an
operation for this service to perform.
Java Embedding: Enables you to add custom Java code to a BPEL process using the Java
BPEL exec extension
Pick: Provides a way to wait for the occurrence of a set of events, such as a message
arriving or a timeout condition specified by an alarm. Only one of these events will be
acted on by a sequence of activities to handle the event.
Receive: Waits for an asynchronous callback response message from a service
Receive Signal: Waits until it receives the proper notification signal from the other process
(master or detail) before continuing its processing
Reply: Allows the process to send a message in reply to a message that was received
through a Receive activity
Scope: Consists of a collection of nested activities that can have their own local variables,
fault handlers, compensation handlers, and so on.
Sequence: Enables you to define a collection of activities to be performed in sequential
order
Signal: Notifies the other processes (master or detail) to continue processing
SMS: Provides a way to send a short message system (SMS) notification.
Switch: Consists of an ordered list of one or more conditional branches defined in a case
branch, followed optionally by an otherwise branch. The branches are considered in the
order in which they appear.
Terminate: Enables you to end the tasks of an activity (for example, the fault handling
tasks in a catch branch)
Throw: Generates a fault from inside the business process
Transform: Enables you to create a transformation that maps source elements to target
elements (for example, incoming purchase order data into outgoing purchase order
acknowledgment data)
Voice: Provides a way to send a telephone voice notification about an event
Wait: Allows a process to specify a delay for a certain period of time or until a certain
deadline is reached
While: Supports the repeated performance of a specified sequence of activities. The
sequence of activities is repeated until the given while condition is no longer true.
Note: The Receive and Reply activities are used to form the standard request-response pattern.
A Scope activity:
Groups activities into a container
Manages BPEL process complexity
Variables
Partner links
Catch Branch
CatchAll Branch
Message handlers
Alarm handlers
Compensation handlers
Grouping Activities by Using a BPEL Scope

A BPEL Scope activity is an element that contains a group of activities, variables, and various
handlers. A scope is a useful mechanism for hiding and managing complexity in a BPEL
process. A scope can be nested within other scopes. This enables you to control how the BPEL
process manages events that occur within the process. A scope enables you to manage events
within the scope by defining:
Variables (By default, asynchronous and synchronous BPEL projects are created with two
global variables called inputVariable and outputVariable, respectively.)
Partner links
Fault handlers, specific catch handlers, and a catchAll handler
Compensation handlers
Message handlers
Alarm handlers
For example, an exception handled within a scope may not be visible to an enclosing scope if the
handler can manage the error gracefully; otherwise, the scope exception handler can perform
some activities and propagate the exception to its enclosing scope.
The slide shows the creation of a scope, expanding the Scope activity, highlighting the locations
where the variables, partner links, and handler items can be added to the scope, and dragging
new activities from the Component palette to the scope.
Grouping Activities by Using a BPEL Scope
Activities can be added to a scope from:

The Component palette
The BPEL diagram
2
1
Adding Activities to a Scope

The slide shows the steps to add activities to the Scope activity. After dragging a Scope activity
into the BPEL Diagram:
1. Click the plus sign (+) icon to expand the Scope activity.
2. Drag another activity, such as the Assign activity, from the Component palette into the
body of the scope. Alternatively, select and drag existing activities within the BPEL
process diagram to the Scope activity.
Adding Activities to a Scope
Request and response messages:

Have XML message structures
Are defined by XML schema elements
BPEL variables are:

Defined as a message type in a process Scope activity
Used to store XML data shared between activities and
exchanged between services
BPEL process (main scope)
Request
inputVariable
Response
Client
Defines
XML schema
BPEL
process
<assign>
creditCheckVar
Communicating Data with a BPEL Process

A client or service communicating with a BPEL process must agree upon the structure of the
data being exchanged between them. Message structures are defined in WSDL, which derive the
message type from XML elements defined in an XML schema.
When a BPEL process is created, it contains a default Scope activity called main. A BPEL
scope contains a sequence of activities and can have other scope activities nested within it. A
scope may define one or more BPEL variables. The variables store message data that is shared
among BPEL process activities and exchanged with other services. Activities can use a BPEL
variable that is within their own scope or the scope of their parents. Similar to variables in
programming languages, a BPEL variable is defined by a WSDL message type whose structure
is expressed as an XML element from an XML schema. The XML schema may be embedded or
imported in the WSDL defining the message types.
The slide shows a client sending a request message defined by an XML schema element to a
BPEL process and receiving an XML response also defined by an XML schema element. The
BPEL process stores the request message data in a BPEL variable defined with the same
message type. The BPEL process shows an example of sharing XML data inside a BPEL process
by using an Assign activity to copy all or part of the XML data stored in the inputVariable
to another BPEL variable called creditCheckVar. The data can be sent to another service
invoked by the BPEL process.
Communicating Data with a BPEL Process
Communicate data between services and activities used

by BPEL processes
Have a built-in data, element, or message type
Element types are defined as XML schemas.
The message type structure is defined as an XML schema
element type and is defined in WSDL.
BPEL process
XML schema
Process variable
Scope
Data variable
Defined as
<types>
</types>
WSDL
Message type
Defined in
BPEL Variables
A BPEL process may declare process variables, which are visible and global to activities in the
entire BPEL process. A BPEL process may also contain a Scope activity that allows the
declaration of data variables, which are visible only to activities enclosed within the scope. The
BPEL process and data variables:
Are used to store and communicate data between a client or service that initiates the BPEL
process and the services invoked by the BPEL process
Store data that may need to be transformed
If a variable will only be used within the scope you are working with, define that variable as a
local variable within that scope. If the variable needs to be referenced globally, define that
variable as a global variable (which is a variable local to the main process scope).
The BPEL data and process variables have a data type or structure that can be specified as:
A built-in data type, such as string, Boolean, and so on
XML element types, which are defined either directly in the BPEL process, WSDL, or an
XML schema document
A message type, which is defined in a WSDL document
BPEL Variables
BPEL Variables (continued)

Note: Message types are structured from element type specifications defined directly in the
WSDL document located in an imported XML schema. It is more common to import an XML
schema to define element types for message structures because the schema can be shared
between multiple processes and clients who invoke the service.
Performance Note: Defining the variable as local to a scope improves performance during
dehydration. During dehydration, the live variables (which includes global variables as well as
the local variables in the active, nested scope) will be dehydrated. (Dehydration is defined on
the next page.)
The choice of global or local variables is a balance between:

Process requirements
Performance due to dehydration effects
Choose more:
BPEL process (main) scope
Local variables to minimize
Global
dehydration performance
variables
Global variables to maintain
Dehydration
Receive
points
state needed for process life
Local
variables
Tables in
BPEL
schema
Dehydrate
Nested
scope
Wait
Dehydration Store
(Database)
Choosing Global or Local Variables

BPEL variables are allocated memory for the duration of their lifetime, which is determined by
the life of the scope in which they are defined. The current state of a BPEL process is defined as
all variables (and the data they store) that are in scope when a BPEL process encounters a
breakpoint activity, such as a Receive, Pick, or Wait activity.
The BPEL Process Manager engine maintains the application state in the machine and,
therefore, must save the state of long-running processes to guarantee service reliability in the
event that the BPEL Process Manager engine is shut down for maintenance or there is some
environmental failure.
The current state of a long-running BPEL process is maintained by using an internal process
called dehydration, which saves current state information (such as when a process is waiting for
asynchronous callbacks) in a dehydration database.
If the BPEL engine terminates in the middle of process execution, the instance can be recovered
automatically, programmatically, or manually from the dehydrated states. When the BPEL
engine resumes executing a process instance, it resumes from the last dehydration point (the
saved last state of the BPEL process instance).
Note: The task of dehydrating (saving) and hydrating (restoring) process state can take more or
less time depending on the amount of state to be saved and restored. Therefore, the choice
between using a global or local variable is a trade-off that depends on process needs and
performance.
Choosing Global or Local Variables
There are two kinds of processes in BPEL:

Durable has one or more midprocess breakpoint or idempotent activities, causing it to stop
and wait for some event in the middle of the process. Durable processes tend to be longlived.
Transient does not have any midprocess breakpoint and idempotent activities and never
stops and waits for any event in the middle of the process. Transient processes tend to be
short-lived.
To determine the process type: If there are any breakpoint activities, the process is durable;
otherwise, the process is transient.
Dehydration
Dehydration occurs when the BPEL process encounters a breakpoint activity. The three cases
when dehydration would occur are:
When the BPEL instance encounters a midprocess breakpoint activity (excluding the initial
Receive). This only occurs to durable and nontransient processes.
When the BPEL instance encounters a nonidempotent activity (such as Invoke). On
recovery from a crash, the BPEL engine retries only the idempotent activities. Therefore,
dehydration occurs when the engine encounters a nonidempotent activity.
When the BPEL instance finishes, the BPEL engine saves the process instance to the
dehydration store, unless it is configured not to do so. This occurs to durable and transient
processes.
By default, all BPEL processes are dehydrated regardless of whether they are synchronous or
asynchronous. However, for synchronous processes that do not need to be durable, you can turn
off the dehydration mechanism by setting the following properties (in the BPEL process
deployment descriptor):
Set inMemoryOptimization to true.
Set the completionPersistPolicy property to faulted or off.
Asynchronous process invocation messages are always saved to the dehydration store.
Dehydration for asynchronous processes can be turned off, as long as the process is transient.
Durable processes are always dehydrated regardless of the settings of the persistence properties
(such as inMemoryOptimization and completionPersistPolicy).
Choosing Global or Local Variables (continued)

Idempotent Activities
Idempotent activities are those that can be retried, such as the Assign activity.
Nonidempotent activities happen only once, such as an Invoke activity, after which the BPEL
engine saves the instance. All breakpoint activities (Receive, Pick, Wait, onMessage and
onAlarm branches of a Scope) are always nonidempotent. The rest of the activities are
idempotent.
Durable and Transient Processes
An Assign activity:
Copies data from a source to a target defined as:
Variables
Expressions
XML fragments
Contains one or more operations (Copy, Append

Insert-After, and so on)
Represented as the <assign>
element in the BPEL source
inputVariable
Assign
outputVariable
XML expression
The Assign Activity

The Assign activity is one of the techniques you can use to copy data from a source to a target in
a BPEL process. Sources can be:
A BPEL variable, which can supply an entire XML document, an XML fragment, or
specific XML elements to be copied
An XML fragment, which provides a literal XML structure to be copied
A partner link, which supplies the XML data to be copied
Targets can be:
Variables that contain new or different data structures, using basic types or XML structures
A partner link
An Assign activity may contain one or more operations including Copy, Append, Insert-After,
Insert-Before, CopyList, Remove, and Rename. The Copy operation is frequently used to copy
data from a source to a target. An Assign activity enables multiple operations to be performed in
the order in which they are defined.
An Assign activity is useful for small numbers of operations, usually less than 10. For
manipulating larger amounts of data and more complex operations, consider using the BPEL
Transform activity.
The Assign Activity
Creating Assign Operations

By right-clicking the Assign activity and selecting Edit, you can configure the activity and its
operation. By default, double-clicking an activity performs an Edit action on that activity.
To add a Copy Operation, perform the following steps:
1. Right-click the Assign activity and select Edit.
2. Click the Copy Operation tab, click Create, and select one of the following operations:
- Copy Operation for a simple copy or assignment operation
- Append Operation to append the source data to the target
- Insert-After Operation to add data after the target
- Insert-Before Operation to add data before the target
- CopyList Operation to copy a list of elements from the source to the target
- Remove Operation to remove elements from the target
- Rename Operation to rename (restructure) elements in the target
The General tab enables you to alter the name attribute value for the Assign activity element.
Use the Edit and Delete icons to modify or delete an existing copy operation, respectively. By
using the Up or Down icons, you can rearrange the execution order of each copy operation. The
top-most copy operation is executed first.
Creating Assign Operations
Copying Data from Source to Target

This slide shows an example of a Copy Operation to enable copying a source of data to a target.
Use the Create Copy Operation dialog box to select the source of data in the From section,
such as:
Variable
Expression
XML Fragment
Partner Link
The To section defines the target of the copy operation. As shown in the slide, the target is likely
to be another BPEL variable or an XML fragment within a BPEL variable. The target can be a
partner link.
Copying Data from Source to Target
1
3
Using the XPath Expression Builder

This slide shows an example to incorporate a copy operation by using the XPath Expression
Builder. The Hello World example adds an XPath expression that uses the concat() function
to concatenate the literal string "Hello " with the input string element in the
inputVariable that holds the BPEL process request message. The input string is accessed
by using the following XPath query in the payload of the input variable:
/client:HelloWorldProcessRequest/client:input
The XPath expression is passed as a parameter to a built-in function

bpws:getVariableData() that extracts the data from the <input> element contained in
the message payload part of the inputVariable. The bpws:getVariableData()
function and its parameters are supplied as the second parameter to the concat() function.
The result is that the string value in the input is appended to the "Hello " text. In the XPath
Expression Builder, to build the expression, you can combine:
Typing the text as shown in the Expression field
Selecting from the BPEL Variables and Functions fields and clicking Insert Into
Expression
In the example on the slide, you see the following:
1. Add the concat() function by double-clicking the concat entry in the String
Functions list.
2. Select the area between the brackets, and enter "Hello " and a comma.
3. Place the cursor after the comma, select client:input from the inputVariable
tree, and click Insert Into Expression.
Using the XPath Expression Builder
The Assign activity is used to copy data from a source to a

target in a BPEL process.
1. True
2. False
Answer: 1
Explanation: The Assign activity is one of the techniques you can use to copy data from a source
to a target in a BPEL process. Sources can be:
A BPEL variable, which can supply an entire XML document, an XML fragment, or
specific XML elements to be copied
An XML fragment, which provides a literal XML structure to be copied
A partner link, which supplies the XML data to be copied
Targets can be:
Variables that contain new or different data structures, using basic types or XML structures
A partner link
Quiz
Invoking a service in a BPEL process requires:

A <partnerLink> that encapsulates a definition of how
to access a service by using its WSDL
An <invoke> activity to initiate an operation provided by
the service
Receive
BPEL process
Invoke
Client
WSDL
Client
Partner Links
JDeveloper
Service
Service
Service
explorer
WSDL
lookup
Service
description
(WSDL)
Partner Links and Service Invocation

A BPEL processes can be invoked by client applications or services through the WSDL interface
exposed through the client partner link defined in the BPEL process. The main purpose of a
BPEL process is to invoke other services. To execute operations of another service, the BPEL
process must have a reference to the target service. The reference to a service is stored in the
partner link component, which is represented by the <partnerLink> element in the BPEL
source.
A partner link effectively stores the reference to the location of the service endpoint, which is
obtained from the service WSDL.
The client partner link defines a reference to the WSDL document for the BPEL process to
enable clients to invoke the BPEL process.
A service partner link is required for each service that is invoked by the BPEL process. A BPEL
Invoke activity is used to call the external service from a BPEL process. The Invoke activity is
configured with the operation to be executed, where the service operations are determined from
the WSDL referenced by the partner link.
Partner Links and Service Invocation
A partner link describes the roles that a process and

service play by specifying a partner link type.
A partner link type defines a relationship between two
services using roles that define the interaction.
A role specifies the port type for an interaction.
Note: A port type defines the service operation and the
message structure required for that interaction.
Partner link types and
roles are added to the
WSDL source, which
contains the port types.
2
Partner links are defined
in the BPEL source.
Partner Links, Partner Link Types, and Roles

A BPEL process describes a flow of interactions between the process and other services. Each
interaction represents a relationship between the BPEL process and the invoked service through
the role that each plays in the interaction. To identify roles and relationships applicable in an
interaction, a BPEL process uses a partner link and a partner link type.
A partner link, defined in the BPEL source, describes the roles that the BPEL process and the
invoked service play. Each role is associated with a port type (operation defined in the WSDL),
which determines the message data structures that they can manipulate in their respective roles.
A partner link is configured with a name, a partner link type, and two roles for asynchronous
interactions (the first partner link, shown as [1] on the slide) or one role for synchronous
interactions (shown as [2] on the slide).
A partner link type, defined in a WSDL document, describes the possible interactions that a
service can perform, thereby characterizing the conversational relationship between two services
by specifying roles for each type of interaction offer by the service. A partner link type defines
one or two roles.
One role indicates that the service can complete the conversation without a callback.
Two roles indicate that there is a requirement to receive a callback from the service.
A role is associated to a port type, defined in the WSDL of a service, which determines the
operation performed by the role and the message structure received in a request or returned as a
response within the context of the conversation.
Partner Links, Partner Link Types, and Roles
A synchronous service:
Processes input
Returns an immediate response
Is implied by the presence of both input and output
elements in an operation of a portType in the service
WSDL
BPEL process
Service
Request
Invoke
BPEL process waits
for the response.
Both input and output

elements in the operation
implies that it is
synchronous.
Immediate
response
Service
WSDL
Synchronous Services
The diagram illustrates a Web service being invoked synchronously. The synchronous service
returns an immediate response or a fault.
If you examine the WSDL for the service operation being invoked, you will notice it contains:
An input element, with a messages type defining the input structure for the request
An output element, specifying the output format and the response message type
The presence of both the input and output elements in the same operation indicates that it is a
synchronous operation. In this case, the BPEL process, which is the client invoking the service,
waits for the response.
Synchronous Services
Request:
<input>Name</input>
Receive
Client
2
Response:
<result>Hello Name</result>
Assign
Concatenate
"Hello " + Name
Reply
Synchronous Process Structure: HelloWorld Example

The example illustrates the simple design of the HelloWorld BPEL process. The BPEL
process is synchronous. This means the process should be short-lived and should send a response
(or reply) to its invoker as soon as possible.
When you create a synchronous BPEL process, Oracle BPEL Process Designer creates a BPEL
process template with a Receive activity as the first activity and ends with a Reply activity. You
create additional processing tasks between the Receive and Reply activities.
The sequence of activities in the HelloWorld design is the following:
Receive the request XML message, containing a name string, input from the client
(invoker)
Assign the text "Hello " concatenated to the name string received as input to the result
message
Reply with the resultant XML message (output data) that is sent to the client in the
response
Note: The BPEL language is an XML structure and provides XML functions that can perform
operations, such as concatenation, using the built-in concat() string function.
Synchronous Process Structure: HelloWorld

Example
Asynchronous services:
Can take time to complete and may not return a response
Are initiated by using a nonblocking Invoke activity
Implement WS-Addressing to enable a callback for the
BPEL process Receive activity to wait for the response
BPEL Process
Invoke
BPEL process does not

wait for the response.
Initiate port: An invoked operation with

only an input element implies asynchrony.
Request
Delayed
Response
Receive
Service
WSDL
Callback port: Provides asynchronous
response with only an input (operation)
Asynchronous Service
The illustration shows a BPEL process invoking an asynchronous Web service. Asynchronous
services take a long time to perform their processing, sometimes anywhere from a couple of
minutes to days to complete. The BPEL process should not block or wait for a response until it is
required. In some cases, the BPEL process does not wait for a response if the asynchronous
process is a one-way interaction, that is, if no response is expected or returned.
In a BPEL process, interaction with an asynchronous service involves:
An Invoke activity to initiate the asynchronous service with the request data. Because no
immediate response is expected, the Invoke activity does not block and the BPEL process
continues to execute activities.
A Receive activity blocks further processing in the BPEL process to wait for the response
data received through a callback operation from the asynchronously invoked service. If the
initiating operation is for a one-way interaction, a Receive activity is not required.
The callback operation to wait for and receive the response is possible because:
The invoked service provides a callback port
The correlation between the BPEL instance and the service it invoked is performed by the
BPEL Process Manager by using the WS-Addressing standard
Asynchronous Service
An asynchronous BPEL process:

Contains activities that could take some time
Starts with a Receive activity
Ends with an Invoke activity to call back
the client
1
Receive
Long-running
process
Client
Invoke
Asynchronous BPEL Process Structure

The basic structure of an asynchronous BPEL process flow, as created by Oracle JDeveloper
BPEL Process Project Wizard, comprises the following items:
A Receive activity at the start of the flow
An Invoke activity at the end of the flow
Oracle BPEL Process Manager manages the correlation between the clients of the invoked
process through WS-Addressing techniques. This enables a long-running process to invoke the
client when the process is complete. The final invoke operation is named a callback.
The client should not have to wait for an asynchronous process to complete before it responds
and must provide a way for the invoked process to call it back to obtain the result (response)
from the process.
The slide shows an asynchronous process structure and the initial BPEL process flow generated
by Oracle BPEL Process Designer while creating an asynchronous process.
Asynchronous BPEL Process Structure
A partner link is:

Created by dragging a Partner link under Services in the
Component palette to a Services swim lane
Associated with a (Web) service via the WSDL URL
Copy a WSDL URL here.
Creating a Partner Link

A partner link is a BPEL element that represents a reference (or link) to a service (such as a Web
service, Adapter services, and others) external to the BPEL process.
A <partnerLink> BPEL element is added to a BPEL process source by dragging a Partner
Link(Web Service/Adapter) component from the BPEL Services group in the Component palette
to the Partner Links swim lane in the BPEL Design window. This action causes a Create Partner
Link dialog box to be displayed, where you can configure the component by specifying:
A name for the partner link, usually a meaningful name representing the service
The WSDL File, which is the URL for the location of a WSDL that can be entered as a
WSDL URL or a WSDL file name
The remaining fields in the Create Partner Link dialog box may be populated with the
information exposed in the WSDL file.
Note: JDeveloper provides a Service Explorer to locate the WSDL for services deployed to
Oracle SOA Suite.
Creating a Partner Link
Browse WSDL Files

From Local File System
Service
Explorer
Define
Adapter
Service
3
Roles determine the request and response message structures.
My Role is set for callbacks in an asynchronous interaction.
Configuring a Partner Link

The Edit Partner Link dialog box in which you specify the WSDL for the service referenced by
the partner link enables you to obtain the service WSDL from:
A local WSDL file by clicking the Browse WSDL Files From Local File System icon
A WSDL URL from a service located in an SOA server by clicking the Service Explorer
icon
A WSDL file generated from an Adapter service wizard by clicking the Define Adapter
Service icon
The example shows how to select a service from the Service Explorer window for
CreditCardValidationService, which is deployed as a Web service in the local server:
1. After entering a name for the partner link, click the Service Explorer icon.
2. In the Service Explorer window, select a service from the list, for example,
CreditCardValidationService, and click OK to accept the choice from Service
Explorer. This populates the WSDL File and Partner Link Type fields in the Edit Partner
Link (or Create Partner Link) dialog box.
3. Select the value for the Partner Role and (optionally) the My Role fields. Click OK to
create the CreditCardValidationService partner link in the Design view.
Configuring a Partner Link
1
2
4
Invoking a Synchronous Service

A service operation is executed by using a BPEL Invoke activity. The slide shows the following
steps used to create and configure an Invoke activity for a synchronous service:
1. Drag an Invoke activity from the Component palette to the process flow.
2. Double-click the Invoke activity to display the configuration window, in which you:
- Enter a name for the activity, such as InvokeCCV
- Set the Partner Link, Operation, Input Variable, and Output Variable fields
3. To set the Partner Link field with the service name to be invoked, such as
CreditCardValidationService, click the Browse Partner Links icon (on the right
of the field).
4. In the Partner Link Chooser dialog box that appears, expand the nodes to locate the desired
Partner link name, and select the Partner link name. Click OK to close the Partner Link
Chooser dialog box, and then set the Operation field. If the Partner link service has more
than one operation, you can change the Operation field to the desired value by using the
fields drop-down list.
When invoking a synchronous service, you must provide an input variable for the request
message and an output variable for the response message data exchanged with the service.
Note: The output variable is not used when invoking an asynchronous service.
Invoking a Synchronous Service
A conditional branch is implemented with a Switch activity that:

Adds a <switch> element in the BPEL source
Consists of one or more ordered <case> branches:
That specify a condition to be evaluated

That are processed in their order of appearance
That contain activities to handle the condition
Where the first branch encountered with a true condition is
processed
May have an <otherwise> branch, which:

Is processed if all <case> conditions are false
Contains activities for implicit exception handling
Conditionally Branching with a Switch Activity

A conditional branch is a structure used to take different processing paths based on some
condition determined by the data values passed between activities in the process.
BPEL implements conditional branching with the <switch> element, represented by the
Switch activity in the Component palette. A <switch> element can contain:
One or more ordered <case> branches, each with a condition to be evaluated. Only one
branch is executed; that is, the first <case> branch returning a true result is processed,
and no other branch is evaluated.
An optional <otherwise> branch, which is processed if no <case> branch is
processed. This is useful for a generic implicit condition handler.
In JDeveloper, when you drag a Switch activity from the Component palette to the Diagram
view, the following two conditional branches are created:
A <case> branch
An <otherwise> branch
You may add additional <case> branches, as needed. Double-clicking the <case> branch
enables you to specify a comment and a Boolean expression to be evaluated for the branch. All
conditional branches contain a sequence of activities that can be processed when the branch is
selected for execution.
Conditionally Branching with a Switch Activity
Select and
drag
Rename
Expand
Configure branches,
conditions, and activities.
Add one activity.
Adding a Switch Activity

To add a Switch activity, perform the following steps:
1. In the Component palette, drag a Switch component to the process flow.
2. Right-click the Switch activity and select Edit to set the Name property. Alternatively,
right-click and select Rename.
3. Expand the Switch to reveal its initial structure, which contains one <case> branch and
one <otherwise> branch.
4. Configure additional <case> branches, delete branches, configure conditions, and drop
an activity into each branch as appropriate.
Note: Each branch can have only one activity. Therefore, if you require more than one process
step to be executed in a branch, add a Scope or Sequence activity as the first one in the branch.
You can have only one <otherwise> branch, which is optional.
Adding a Switch Activity
Add Switch Case.
Add Switch
Otherwise.
3
1
View Condition
Expression
Configuring Branches of a Switch Activity

The slide highlights the icons that can be used to:
Add a <case> branch to the Switch
Add an <otherwise> branch to the Switch. If an <otherwise> branch already exists,
another will not be added and JDeveloper displays a warning message.
Create a condition expression for a <case> branch to evaluate a condition. To configure a
case condition, do the following:
1. Click the View Condition Expression icon in the <case> branch.
2. Click the XPath Expression Builder in the Condition window.
3. Construct the conditional expression in the Expression Builder.
The example on the slide shows a Switch activity called EvaluateCreditCardStatus that has a
single <case> branch with a condition that evaluates whether the credit card status received
from the CreditCardValidationService is valid. If the condition is true, the assignApproval
activity copies the approval information into a BPEL variable to store the results and process the
order; otherwise the assignInvalidCC activity assigns an Invalid Order message.
Configuring Branches of a Switch Activity

Describe process orchestration concepts
Define and describe Business Process Execution
Language (BPEL) in relation to implementing process
orchestration
Develop a BPEL process by using the BPEL designer in
JDeveloper 11g
Describe activities, partner links, and service invocation in
a BPEL process
Summary
In this lesson you have learned how to create a BPEL process by using the BPEL Designer.
In the next lesson, you will be introduced to the service component that enables users to interact
in a business flowthe Human Task component.
Summary

Creating a BPEL service component in an SOA composite
Wiring the BPEL component and the Mediator component
Creating a BPEL Service Component
Working with the Human Task Component
SOA
The Working with the Human Task Component lesson introduces the Human
workflow task and related concepts. You will also learn how to create a Human
Task component in an SOA composite and access it from a BPEL process.
Course Roadmap
The Orchestrating Services with a BPEL Component lesson introduced process orchestration
concepts and using the BPEL component.
The Working with the Human Task Component lesson introduces the Human Workflow task
component and its functionality.
Course Roadmap

Describe a Human Workflow task and the related concepts
Describe a workflow as a service
Create a Human Task component in an SOA composite
and access it from a BPEL process
Create a task form to enable users to interact with a task
Use a Worklist application to perform actions (such as
approve or reject) on an assigned task
Objectives
Purchase
order
Approver
Approved/ denied
Purchase order >

credit limit?
Yes
Approved
Get
approval
Authorization
No
Order
approved
Denied
Order
canceled
What Is a Human Task?

A Human Task component implements a task done by a person. It represents the involvement of
a person in a business process.
Occasionally, people need to intervene in a business process. For example, a customer wants to
purchase an item that is above his credit limit. A Human Task lets you intervene and override a
business rule that prevents the customer from making the purchase. A Human Task can have
attributes, such as setting the owner of the task, and providing an escalation process in the case
that the specified person is not available. The Human Task component recognizes the reality that
many processes require human intervention for tasks like reviewing, researching, and approving.
What Is a Human Task?
BPEL Process
Manager
Human Task Service Component

Task Definition
Client
Applications
Oracle
BPM
Worklist
Receive
Roles and
Assignments
Portals
Invoke
Service
Interface
Create
Task
Deadlines and
Escalations
Client
Interface
Email &
RSS
Clients
Task
Human
Complete
Task
Presentation
Invoke
Invoke
Identity Directory
(LDAP, for example)
Phone and
Other
Notification
Channels
Human Workflow Diagram

Many end-to-end business processes require human interactions with the process. For example,
humans may be needed for approvals, exception management, or performing activities required
to advance the business process. The Human Workflow component provides the following:
Human interactions with processes, including the assignment and routing of tasks to the
correct users or groups
Deadlines, escalations, notifications, and other features required for ensuring the timely
performance of a task (human activity)
The presentation of tasks to end users through a variety of mechanisms, including a
Worklist application (Oracle BPM Worklist)
Organization, filtering, prioritization, and other features required for end users to
productively perform their tasks
Reports, reassignments, load balancing, and other features required by supervisors and
business owners to manage the performance of tasks
The slide shows a Human Workflow diagram where a BPEL process invokes a special activity
of the Human Task type when it needs a human to perform a task. This creates a task in the
Human Task service component. The BPEL process waits for the task to get completed.
Human Workflow Diagram
Human Workflow Diagram (continued)

The Human Task service component uses an identity directory, such as LDAP, to determine
peoples roles and privileges. The Human Task service component presents tasks to users
through a variety of channels, including the following:
Oracle BPM Worklist, a role-based application that supports the concept of supervisors
and process owners, and provides functionality for finding, organizing, managing, and
performing tasks
Portlets that provide Worklist functionality and that can be exposed in an enterprise portal
Notifications that can be sent to email, phone, SMS, and other channels. Email
notifications can enable users to perform actions on the task from within the email client
without connecting to Oracle BPM Worklist or Oracle WebLogic Server.
Task:
Work that needs to be done by a user, role, or group
Participant:
A user or set of users in the assignment and routing policy
definition
Notification:
An email, voice, instant message, or short message service
(SMS) message that is sent when a user is assigned a task
Human Task Editor:

A tool to specify the task settings
Introduction to Human Workflow Concepts

A task in a Human Workflow is work that needs to be done by a user, role, or group. In some
cases, tasks are also referred to as work items. Human workflow supports the declarative
assignment and routing of tasks. In the simplest case, a task is assigned to a single participant
(user or group). However, there are many situations in which more detailed task assignment and
routing is desired (for example, when a task must be approved by a management chain or
worked and voted on by a set of people).
A participant is a user or set of users in the assignment and routing policy definition. For
example, a vacation request (task) is assigned to a manager (participant). The manager must act
on the request task before the vacation starts. If the manager formally approves or rejects the
request, the employee is notified with the decision. The notification can be an email, voice
message, instant message, or a short message service (SMS) message.
The Human Task Editor tool enables you to specify task settings such as task outcome, payload
structure, task participants, assignment and routing policy, expiration and escalation policy, and
notification settings. The Human Task Editor creates a .task metadata configuration file that
stores the task settings.
Introduction to Human Workflow Concepts
BPEL
process
Task
Management
service
Task Assignment
Task
History/Audit
Human Task
Identity
management
User Metadata
service
Routing
service
Task Query
service
Identity
service
Notification
service
Portal
Worklist
Email client
Notification channels
Email
OID, LDAP
Wireless
Implementing Human Workflow Services

The slide illustrates the key components that make up the configuration of a Human Workflow
task. The components that can be used for configuring a Human Task include:
Task Management service: Handles persistence of the task data, forms, and attachments,
keeps an audit trail, and tracks versions
Task Routing service: Deals with the assignment and dispatching of tasks (that is, to route
tasks to various users based on the selected pattern)
Identity service: Enables authentication of users to look up user properties, roles, and
privileges. Users can integrate their applications with Oracle Identity Management (OIM)
services, which can be implemented with an LDAP service such as Oracle Internet
Directory (OID) for added security and identity management.
Task Query service: Provides a list of tasks in progress and reporting services
Notification service: Sends notifications to users through the following channels: email
and wireless options (such as a pager, SMS, and text messaging). Other notification
services supported include fax and voice channels.
User Metadata service: Manages metadata related to workflow users, such as user work
queues, preferences, vacation, and delegation rules
Implementing Human Workflow Services
Get
approvals
Assign
task
BPEL
process
Change
routing
Task
complete
BPEL
process
Assign tasks to role or group (from

directory)
BPEL
process
All approvals
complete
Flow patterns, routing rules
Escalate
task
List work items
Notify
manager
Complete task
Task
resolved
Get weekly
productivity report
Escalation and delegation rules
Worklist (tasks, forms, attachments,

reports)
Exploring Workflow Exchange Patterns

The graphics show a subset of the following common workflow patterns that can be configured
in Oracle BPEL Process Designer:
Task assignment patterns
Task routing patterns
Task escalation and delegation patterns
Task worklist reporting patterns
The Human Task activity implements these workflow patterns by using a combination of BPEL
activities. Additional services that enable workflow services are identity management for
authentication of task assignees, and notification services to inform assignees of tasks requiring
action. The BPEL Human Task provides a task metadata file for configuring the workflow
patterns, including:
Task details, such as title, payload, and other properties
Routing slip configuration to specify:
- Task flow (simple, sequential, parallel flow, ad hoc workflow, and FYI tasks)
- Assignment and routing policy (assignment of a task to user, group, or role; static or
dynamic assignment; rules based on task outcome or payload content and title)
- Escalation, renewal, and expiration criteria
JDeveloper enables you to generate Java-based task forms to enable customer user-interface
designs to be created that display relevant task data on the Worklist application page.
Exploring Workflow Exchange Patterns
1. Assign tasks to a user or role.

2. Wait for task completion as part of an end-to-end process
flow, and manage the response.
Human
Task scope
BPEL
process
1
Assign
task
WSDL
(Contract)
2
Human Task
Update
task
TaskService
(workflow)
Complete
task
Worklist
application
Describing a Workflow as a Service

Oracle BPEL Process Manager contains workflow services provided by the TaskManager
process and a Worklist application. When you add a Human Task component to the SOA
composite, you can invoke it within the BPEL process by using the Human Task scope activity.
Invoking a Human Task in a BPEL process:
Creates a PartnerLink for the TaskService, which is implemented by the Oracle BPEL
TaskManager process
Assigns task data required by the TaskService
Invokes the TaskService with the task data required for manual processing by users of the
Worklist application
Receives the complete task callback from the TaskService, which contains the outcome
produced by the user action on the task
Creates a Switch activity with one case branch for each response outcome configured
The Worklist application is a Web-based interface that enables assignees to process tasks. When
the tasks are completed, the TaskManager service generates the callback to the BPEL process to
enable processing to continue based on an outcome selected by a user action.
Describing a Workflow as a Service
A BPEL process invokes a special activity of the Human Task

type when it needs a human to perform a task.
1. True
2. False
Answer: 1
Explanation: A Human Task component implements a task done by a person. It represents the
involvement of a person in a business process. Common workflow patterns that can be
configured in Oracle BPEL Process Designer:
Task assignment patterns
Task routing patterns
Task escalation and delegation patterns
Task worklist reporting patterns
The Human Task activity implements these workflow patterns by using a combination of BPEL
activities.
Quiz
Adding a Human Task Component to an SOA Composite

You create a Human Task service component in the SOA Composite Editor. After creation, you
design the component in the Human Task Editor. The method by which you create the Human
Task service component determines whether the component can be associated later with a BPEL
process service component or is a stand-alone component in the SOA Composite Editor.
To create a Human Task service component:
1. Go to the SOA project in which you will create a Human Task service component, and
open the SOA composite application in the SOA Composite Editor.
2. In the Component palette, select SOA.
3. From the list, drag a Human Task. The Create Human Task dialog box appears. In the
Name field, enter a name. The name you enter is added as the .task file name.
4. You can also wire up the Human Task component with the BPEL process component, as
shown in the slide.
Adding a Human Task Component to

an SOA Composite
The Human Task Editor

You can create a Human Task service component in the SOA composite application of Oracle
JDeveloper and then design it by using the Human Task Editor, which is displayed when you
double-click a Human Task in the SOA Composite Editor. The slide shows the Human Task
Editor with its different sections that enable you to design the metadata of a Human Task. The
sections are:
Task Title: This section enables you to specify details such as the task title, description,
task outcomes, task category, task priority, and task owner.
Parameters: This section enables you to define the structure (message elements) of the
task payload (the data in the task) defined in the XSD file.
Assignment and Routing Policy: This section enables you to assign participants to the
task and create a policy for routing the task through the workflow.
Expiration and Escalation Policy: This section enables you to specify the expiration
duration of a task.
Notification Settings: This section enables you to create and send notifications when a
user is assigned a task or informed that the status of the task has changed.
Advanced Settings: This section enables you to specify advanced settings, such as custom
escalation rules, and the dynamic creation of Microsoft Word documents for the purpose of
sending them as email attachments.
Annotations: This section enables you to label different attributes of the task definition.
Annotations are used with Oracle Business Process Analysis. Annotations are used to label
different attributes of the task definition.
The Human Task Editor
Human workflow in BPEL involves:

Design-time actions:
Adding a Human Task into a BPEL process flow
Configuring task parameters, assignments, outcomes, and a
workflow pattern in the .task metadata file
Optionally, generating a task form to customize the task
information displayed in the Worklist application
Run-time actions:
Initiating the BPEL process and waiting for the TaskService
to assign tasks
Logging in to the Worklist application as an authorized user
and performing an action on the assigned task
Working with Human Workflow in BPEL

Working with a Human Workflow service in BPEL involves design-time and run-time actions.
At design-time, the developer of the BPEL process needs to:
Add a Human Task into the process
Configure the Human Task attributes that defined all the features required for the Human
Workflow interaction. This information is stored in a task metadata file that has a.task
extension that is added to the BPEL project.
Optionally, use JDeveloper wizards to generate task-displayed forms to customize what
and how the task information is displayed by the Worklist application at run time.
At run time, when the BPEL process is initiated and executes the Human Task activities, the
users involved in the Human Workflow interaction should ideally be notified that a task has
been assigned to them. In which case, they can log into the Workflow Web application to view
their task assignments and the associated data, and perform a task-based action to enable the
workflow pattern to come to completion.
After the workflow pattern is completed, the BPEL process receives the task outcome from the
TaskService callback interface and takes appropriate flow branches to act on the outcomes
received.
Note: The separation of the task details from the BPEL process into the .task file dramatically
improves and eases the maintenance of task information.
Working with Human Workflow in BPEL
Task Service
.task
Activities in the
Human Task
scope
Creating a Human Task in BPEL

The slide shows the main steps for including a Human Task in BPEL:
1. Drag the Human Task activity into the process flow in the Diagram view.
2. Configure the task assignment attributes, details, and outcome, which are all stored in a
separate XML file with a .task extension that is added to the project folder.
The basic structure and relationship of activities created for the Human Workflow
implementation, as shown in the slide are:
A PartnerLink for the Workflow service (ManualApproval.TaskService
TaskService) that exposes the WSDL for the TaskManager process, which is deployed as a
built-in service with Oracle BPEL Process Manager
A Human Task scope that contains:
- Assign activities, for setting task and system attributes required to initiate the Human
Workflow by using the TaskService
- An Invoke activity to send task information to the TaskService, which makes the
information available to the users of the Worklist application
- A Receive activity to wait for the task response in the callback from the TaskService
when the task requirements are completed
A Switch activity containing a <case> branch for each outcome specified in the .task
file. You can add additional activities into these branches to implement process activities
needed for the management of the outcome returned.
Creating a Human Task in BPEL
Configuring the Human Task

The .task file is used to store the configuration entered in the task details, including:
A title for the task
A priority
A task owner
A comma-separated list of outcome strings, each of which generates a <case> branch in
the task Switch added after receiving the response from the TaskService
Parameters to provide data to display in the Worklist application
Assignment and routing policies (workflow patterns such as single approver, by a group
vote, passed through a chain of management, approved by users in a specific sequence, or
limited by time duration and managed in other ways)
Expiration and escalation policies to set a specific end time for the task and when it should
be escalated up the management chain
Notification settings to configure who gets notified and when on the basis of the task
status, the number of reminders, and actionable notification emails with attachments
Advanced settings to customize various other attributes of the task
Configuring the Human Task
Task parameters:
Are added in the Parameters section of the .task
Are defined as either simple type or XSD element type

Are exchanged with the TaskService in the task payload
1
2
Enables user to modify task data in
the Worklist application
Adding Task Parameters

Task parameters form the structure of information that is passed as the task payload to the
TaskService for processing. Task parameters can be displayed in the Worklist application if you
generated a task form to display the information.
When editing the task metadata file, you can add a task parameter by performing the following
steps:
1. In the Human Task Editor, click the Add Task Parameter icon (+) in the Parameters
section.
2. In the Add Task Parameter dialog box, click the Browse icon to select the parameter type
or element from an XSD to define the parameter data structure, and click OK.
Note: Select the Editable via worklist option to enable a user to modify the task
parameter values displayed in the Worklist application. If the task assignee modifies task
parameter data, then the modified values are returned to the BPEL process in the task
payload along with the task outcome.
Multiple task parameters can be added to a task definition. However, each parameter must be
supplied with values. The above two steps merely define the task parameter data structure
passed as the payload to the TaskService.
Adding Task Parameters
Task parameter values are:

Configured by editing the Human Task scope activity
Obtained from a BPEL variable whose values are stored in
a compatible XML element
1
2
Populated with modified
values (if enabled)
Setting the Task Parameter Values

To supply the actual values for task parameters at run time, you need to configure the Human
Task properties by selecting an XML element, compatible with the task parameter type or
element structure, from a BPEL variable that stores the values. The steps to associate values
with a task parameter are:
1. In the BPEL Diagram window, right-click the Human Task activity icon, and select Edit.
2. In the Human Task property dialog box, click the Browse icon in the BPEL Variable
column for a Task Parameter row.
3. In the Task Parameters dialog box, select the compatible XML element from a BPEL
variable to supply the parameter data.
Note: If the Editable via worklist option was enabled for the task parameter, the selected XML
element in the BPEL variable is populated with the modified values when the task parameters
are returned from the TaskService.
Setting the Task Parameter Values
Task parameters obtained

from task payload definition
Generating a Task Form for the Worklist

If the SOA composite includes a Human Task, then you need a way for users to interact with the
task. The integrated development environment of Oracle SOA Suite includes Oracle Application
Development Framework (Oracle ADF) that enables you to design a task display form that
depicts the Human Task in the SOA composite.
A task form is a Java Server Page XML (.jspx) file that defines how a task payload (from task
parameters) is displayed in the Worklist application. When you create an ADF task flow based
on a Human Task, you must select a task metadata file to generate the data control. This data
control is used to lay out the content on the page and connect to the workflow service engine at
execution time to retrieve task content and act on tasks. A task form can be auto-generated for a
quick, simple interface containing task parameters, or you can generate a custom task form.
The example shows the steps to auto-generate a simple task form:
1. Right-click the Human Task activity in the BPEL workflow, and select Auto Generate Task
Form.
2. Optionally, modify the task form, save any changes, and close the JSP tabbed page.
Generating a Task Form for the Worklist
To access the Worklist application, enter the following

URL:
http://host:port/integration/worklistapp in a Web browser
Log in as an authorized Worklist application user.
Accessing the Worklist Application

The Oracle BPM Worklist application is a Web application that is installed with Oracle SOA
Suite 11g components. To access the Worklist application, enter the URL:
http://host:port/integration/worklist.
The Worklist application login page is displayed. Log in to the application with a username
authorized to use the Worklist application.
Note: Administrators can configure an LDAP server to be used to authenticate Worklist
application users.
Accessing the Worklist Application
After logging into the Worklist application, users can view:

Task assignments
Task parameter information
Viewing Task Information

After users log in to the Worklist application, they can view the task assignments, work queues,
and task parameter information by selecting the specific task. The screenshot in the slide shows
the task form page (generated by JDeveloper and rendered in the bottom right pane of the page)
and any relevant task information required by the assignee to apply an action to the task.
Viewing Task Information
An action can be applied to an assigned task from:

1. The assigned task row in the Task Inbox
2. The task form with task details
1
Managing Task Assignments

A task assignment needs an action to be performed after it is assigned to a user. In the example
shown, the list of actions is determined by the list of outcomes configured in the .task file for
the Human Task. For example, the user can approve or reject the assigned task.
The action for an assigned task can be done either in:
The Worklist application page containing the task information, in a row displayed in the
users Task Inbox
The task form that displays the task parameter details. If the task parameter data was
configured to be modifiable at design time, users can view and save modified values before
they perform a selected action in the page.
Note: Modified values must be saved before the action is applied to be passed back to the BPEL
process.
Managing Task Assignments

Describe a Human Workflow task and the related concepts
Describe a workflow as a service
Create a Human Task component in an SOA composite
and access it from a BPEL process
Create a task form to enable users to interact with a task
Use a Worklist application to perform actions (such as
approve or reject) on an assigned task
Summary
This lesson showed you how to create a Human Task component and access the same from a
BPEL process.
In the next lesson, you will be introduced to the service component that enables incorporating
business rules that can be easily created and edited by a business user, not necessarily a technical
person.
Summary

Creating a Human Task service component in an SOA
composite
Accessing the Human Task component from a BPEL
process
Creating a Human Task to Approve Orders
Implementing a Business Rules Component
SOA
The Implementing a Business Rules Component lesson introduces Oracle

Business Rules and its features and how to develop a rule-based application by
creating and accessing a business rule from a BPEL process.
Course Roadmap
The Working with the Human Task Component lesson introduced Human Task components
and their functionality.
The Implementing a Business Rules Component lesson introduces you to Oracle Business
Rule and its features.
Course Roadmap

Describe the needs for implementing business rules
Define Oracle Business Rules and its features
Create facts, rulesets, and a rule dictionary
Develop a rule-based application by creating a Business
Rule component and integrating it into a BPEL process
Objectives
Business rules technology:

Automates rules and policies
Enables business users to participate in business processes
Business rules are:
Extracted from processes and procedural logic

Expressed declaratively
Executed in an inference-capable business rules engine
Edited by business users
Introducing Business Rules Technology

Business rules technology is designed to automate business rules expressed declaratively as rules
and policies. The rules and policies are extracted from procedural code and logic and created
declaratively as if-then-else constructs. This enables the rules and policies to be easily
created and edited by a business user, not necessarily a technical person.
With an inference-capable business rules engine, such as Oracle Business Rules, declaratively
expressed rules can be executed.
Introducing Business Rules Technology
If a customer is a Premium customer, offer him or her a 10% discount.

If a customer is a Gold customer, offer him or her a 5% discount.
Rule statements are easier to maintain than procedural code

because they:
Declare intent instead of coding logic
Exclude control flow, which is determined by the rules
engine
Relate well to business user drivers
Declarative Rule Concepts

The declarative nature of rules makes them easier to maintain, because rules:
Declare the intent of business drivers
Exclude flow control that is typical of procedural logic
The examples in the slide are declarative statements expressed as conditions that drive business
policies with the intent of providing discounts to loyal customers based on the customer status.
Declarative Rule Concepts
If a customer spends > $1,000, make him or her Premium customer.
If a customer is a Premium customer, offer him or her a 10% discount.
If a customer is a Gold customer, offer him or her a 5% discount.
Customer
spends
$1,500
Premium
customer
Offer 10%
discount
Example of inference: A results in B, and B infers C

Enables powerful and modular declarative assertions
Rule Inference Concepts

The example illustrates that when a customer spends $1,500, which is more than $1,000, it
identifies that customer as a Premium customer, which implies that the customer receives the
10% discount. By inference, all Premium customers spend more than $1,000.
The Merriam-Webster online dictionary defines inference as the act or process of inferring.
Inferring means to derive a conclusion from facts. Inferencing means that one set of true
conditions can imply something else, and then that something else can be used to further
satisfy other conditions, which in turn imply other things.
Inferencing in a Rules Engine means that these chained implications are done automatically as
part of the normal operation of the engine.
The example shows that by using the inferencing principle you decouple the rule that determines
if a customer spends more than $1,000, from the rule that determines if the customer is offered a
discount, resulting in modular declarative assertions.
Rule Inference Concepts
Agility:
Rules are easier to change.
Rules are more responsive.
Transparency:
Rules are accessible.
Rules are consistently applied.
Reasons for Using Rules Technology

The two key benefits of using rules technology are:
Agility
Transparency
An agile application enables it to be more adaptable to change. It is easier to alter rules to meet
the changing needs of the business, enabling the applications to be more responsive to business
requirements.
Transparency enables rules to be accessible throughout an enterprise so that any application can
consistently execute the same rule and polices that have been declaratively expressed and
receive the same outcome for the same set of factual information.
Reasons for Using Rules Technology
Consider implementing rules for the following cases:

Volatility: Rules that are likely to change frequently
Impact: Rules that impact the business the most if not
current
Ownership: Rules owned by particular business parties
Compliance: Rules that express regulatory requirements
Guidelines for Selecting Rules Use Cases

The slide lists some of the common use cases for selecting a rules-based approach under those
circumstances.
Guidelines for Selecting Rules Use Cases
Components
include:
Rules engine
Rule editor
Rule dictionary
Rules SDK
JDeveloper Rule Editor

Rules SDK
Rule dictionary
Partner
Link
BPEL
XML Facts Java Facts

ADF-BC Facts
Rules API
(JSR 94)
Rules Engine
/** @Foo **/

method
Foo(....)
{
Java
application
Introducing Oracle Business Rules

Oracle Business Rules enables:
Applications to be adapted to regulatory and competitive pressures and to support policy
changes
Business analysts and other nontechnical professionals to alter application logic related to
business policies with a graphical user interface, without the aid of programmers
Oracle Business Rules is installed with Oracle SOA Suite and comprises the following:
Rule Editor is a general-purpose application, layered upon the Rules SDK.
- Used by business users to create and edit rules in Oracle JDeveloper 11g
- Implemented as a business dialect rather than a developer language
Rules Engine is an efficient implementation of the industry-standard Rete patternmatching algorithm for implementing rule-based expert systems. Functionality includes:
- Loading rules and asserting or retracting facts into working memory
- Performing inferences and interfaces to expose working memory status
- Executing as a Java-callable library or a stand-alone service. In each case, it
consumes a modest amount of resources (working overhead is less than 2 MB).
- Relying on a rule dictionary
Introducing Oracle Business Rules
Developers can use RL as a full-featured rules programming language, or business analysts can
use Rules Designer and generate RL from the rule dictionary. The Rules Engine has a
command-line interface for interactive RL development and debugging.
JSR 94 is a standard API that defines how to access a Rules Engine from a Java SE or Java EE
client, and it provides API specifications to:
Register and remove rules
Parse rules
Inspect rule metadata
Execute rules, and retrieve and filter results
Note: JSR 94 does not standardize the Rules Engine implementation, including the rule
execution, the language used for rule, and the deployment mechanisms used. For more
information about the JSR 94 API architecture, refer to
http://java.sun.com/developer/technicalArticles/J2SE/JavaRule.html.
Introducing Oracle Business Rules (continued)

Rule dictionary provides persistent storage for rulesets, other metadata (such as the data
model), and rules. The dictionary is a file in the local file system with a .rules
extension.
Rules SDK enables the development of Java GUI or Web applications through which
business users create, edit, and view rules. Rules SDK provides:
- A dictionary API, which allows the developer to define business objects and edit
templates to be made available to the business user
- A general API, which is used for editing, validating, or debugging business rules, and
for generating correct run-time structures
- A run-time API, which is used for loading, executing, monitoring, and auditing
business rules
Note: Rules SDK generates Rule Language for use by the Rules Engine.
Oracle Rule Language (RL), directly executed by the Rules Engine, is interpreted rather than
compiled to enable rules to be changed without rebuilding, redeploying, or even restarting
applications. RL has a Java-like syntax and type-checking and can assert any Java object as a
fact. A rule can reference any object property and invoke any method in its condition and
actions.
As shown in the diagram in the slide, the application interacts with the Rules Engine by creating
a rule session in which it:
Executes RL definitions for rules, functions, and variables
Asserts some business objects as initial facts
Runs an inference cycle, which is a process where facts cause rules to fire, and firing rules
can create more facts, which in turn can fire more rules
Retrieves results and passes them to the application
Facts:
Are data or business objects on which the Rules Engine
evaluates rule conditions
Rules:
Are declared as: If Condition Then Action
Have an action: assign, assert, call a function (or a Java
method)
Ruleset:
Has a collection of rules
Is a unit of execution
May be chained
Dictionary:
Has a collection of fact types, global variables/constants,
functions, and rulesets
Introducing Oracle Business Rules Concepts

Oracle Business Rules are stored in a rule dictionary, which is a file in the file system. A rule
dictionary contains one or more definitions of:
Facts
Constraints
Functions
Rulesets
A ruleset is a collection of one or more related rules that are seen as a unit of execution and can
be chained together to yield an outcome.
Each rule is declared as a conditional expression with an action. The condition evaluates and
compares facts. If the evaluation of facts is true, then one of the following actions is performed:
Assigning values to other facts or results
Asserting values
Calling functions (or Java methods) to execute procedural code
Introducing Oracle Business Rules Concepts
Business logic
Policy and
rules
Other logic
...
<element
name="customerOrder"
>
<complexType>
<sequence>
<element name="Name"
type="string"/>
<element
name="CreditScore"
type="int"/>
...
Facts, actions
Rules Designer
3
4 to
Rules-enabled application
Facts
Results
Rules
engine
Rules enabled
Application
run-timeapplication
logic
Rule
dictionary
Developing a Rule-Enabled Application

The tasks listed in the slide require cooperation between developers (who create the internal
application logic for rules) and business analysts (who describe the rules as business conditions).
The common tasks required to enable an application with business rules are:
1. Separate policy from other logic: Business analysts and developers separate business
policies and rules from other logic. Together, the team develops business-friendly
vocabulary for the definitions of more understandable rules.
2. Define facts and actions, imported with Rules Designer: Facts are the units of
information on which the Rules Engine asserts operations. Facts may be defined as a Java
class, XML schema structures, ADF-BC structures, or an RL class. Developers create facts
and actions and import them with Rules Designer into the dictionary.
3. Define and test rules: Analysts write, customize, and test the rules using the defined
business vocabulary and work with developers to create the desired results.
4. Perform system tests: Integrate rules into the application system and perform system
tests. When system testing is done, tracing can be enabled in the Rules Engine to dump
information about facts, rule activations, and rule firings to a log file.
5. Perform production deployment: After successful system testing, developers deploy
rules and application into a production environment.
6. Update policy: Business analysts maintain policy updates to manage changes with
business requirements.
Developing a Rule-Enabled Application
Create or import
Dictionary
2
Globals
Data model
Generates
using JAXB
Ruleset
Rules
Rules
Rules Designer
Facts
3
Java classes
XML schema
Define business policies
Defining Oracle Business Rules Development Concepts

The slide illustrates key steps, components, and concepts needed to work with Oracle Business
Rules. To create a set of rules that can be evaluated by an application, you need to perform the
following steps:
1. Create or import a dictionary by using JDeveloper Rules Designer.
2. A dictionary is a collection of facts, functions, globals, bucketsets, links, decision
functions, and rulesets. A dictionary is an XML file that stores the rulesets and the data
model for an application. Dictionaries can link to other dictionaries. You can create as
many dictionaries as you need. A dictionary may contain any number of rulesets. Using
Oracle Business Rules, a data model is contained in one or more dictionaries. A data model
contains business data definitions for facts or data objects used in rules, including
XMLFacts based on an XML schema. All the data model elements referenced by the
rulesets must be available in the dictionary. A dictionary is stored in a .rules file.
3. Create one or more facts, which represent data or objects on which expressions are
evaluated. A fact can represent a sales order or a customer credit history. Facts can be
created from an XML data (XMLFact), an XML schema, Java objects, Rule Language
structures, ADF Business Components, and expressions. Creating an XMLFact causes the
Oracle Business Rules Engine to bind the associated XML schema to Java classes by using
Java Architecture for XML Binding (JAXB).
4. Create a ruleset, which is a container for one or more rules.
5. Define business policies using one or more rules based on the data model with the help of
expressions on the facts.
Defining Oracle Business Rules

Development Concepts
A rule dictionary provides persistent storage for rulesets and

rules.
1. True
2. False
Answer: 1
Explanation: Rule dictionary provides persistent storage for rulesets, other metadata (such as the
data model), and rules. The dictionary is a file in the local file system with a .rules extension.
Quiz
Creating a Dictionary for Rule Definitions

The rule dictionary acts as a:
A top-level container of rule definitions
A starting point for working with rules
A dictionary holds rules that are executed by an application. The Rules Designer stores rules and
their associated definitions in the dictionary.
You create a rule dictionary when you first add the Business Rule component to your composite
or add Business Rule components to your BPEL flow. The Create Business Rules dialog box
appears when you drag a Business Rule component into the composite. You enter either a name
for a new dictionary or click the Import Existing Dictionary icon to import an existing rule
dictionary. When you add a Business Rule component to your BPEL flow, you either choose an
existing rule dictionary or click the green plus (+) icon to create a new rule dictionary. Each rule
dictionary appears as a separate Business Rule component in the composite diagram.
Note: When you create or save a dictionary, Rules Designer stores the rules and the data model
associated with the dictionary in a .rules file within your application file hierarchy.
Creating a Dictionary for Rule Definitions
The Rules Editor is invoked when you double-click an existing

Business Rule component in the composite designer.
Working with the Rules Editor in JDeveloper

To invoke the Rules Editor, double-click the Business Rule component within your composite
design diagram. The Rules Editor is where you define the facts involved in the rules, rulesets
(containing the rule definitions), and variables used by the rules. The types of facts currently
supported include:
Java facts, which are based on Java objects or classes
XML facts, which are based on an XML schema
RL facts, which are based on the Rule Language that can use RL functions that you create
ADF Business Components facts, which are based on Oracle ADF Business Components
view objects
Note: An Oracle ADF Business Components view object represents an SQL query. You use the
full power of the familiar SQL language to join, filter, sort, and aggregate data into exactly the
shape required by the end-user task.
You also define the following using the Rules Editor:
A constraint, which can be an enumeration, range, or regular expression
Variables, which are named types that can be based on object, string, or standard
primitives, and can be used to define constants and evaluation expressions
Functions, which are parameterized functions based on the Rule Language syntax
Working with the Rules Editor in JDeveloper
Working with the Rules Editor in JDeveloper (continued)

Bucketsets, which provide the ability to define a list of values or range of values to be used
within your business rules
Links, which enable you to add, edit, delete, or view dictionary links
Decision functions, which enable you to create or edit decision functions
Note: Decision functions provide access to rules from either a Web service or from a Java
program.
Either import a new

schema or choose
from already
imported schemas.
Add an XML schema.
View the XMLFact

entries.
3
Creating XMLFact Entries

To create the XMLFact entries, after clicking Create on the XML Fact Summary page, perform
the following steps:
1. Add an XML schema to generate JAXB classes for XML schema elements. Click the Add
icon (+) to add an XML fact.
2. In the Create XML Fact dialog box, either import a new schema using the green plus (+)
icon or choose from already imported schemas. If you are importing a new schema, you
will need to specify the XML schema name, the JAXB Classes directory, and a package
name for the generated JAXB classes.
Rules Designer processes the XML schema and compiles the generated JAXB classes.
Therefore, depending on the size of the schema, wait for processing to complete. Importing
an XML schema updates the data model to include the types and elements imported. If the
Target Package field is empty, the name is generated from the target namespace of the
XML schema using the default JAXB XML-to-Java mapping rule. For example, the
rules.oracle.com namespace is mapped to com.oracle.rules.
Note: The elements and types are presented in lists used to create and modify rules. On
completion, the Target Classes list is updated to show the Generated JAXB Classes box.
To import the generated JAXB classes into the data model as XMLFact entries for selected
XML elements, select the classes you want from the Target Classes list and click OK.
3. Click the XML Facts node to view the entries.
Creating XMLFact Entries
You define a bucketset to specify a list of values or a list of

value ranges to limit the acceptable set of values for a fact or
for a property of a fact.
Working with Bucketsets

You create a bucketset to define a list of values or a list of value ranges to limit the acceptable
set of values for a fact or a property of a fact in Oracle Business Rules. You can define a
bucketset as a global bucketset that allows reuse, or as a local bucketset that only applies to one
condition expression. You can associate fact type properties with bucketsets. This allows you to
limit the acceptable set of values for a property of a fact.
There are three forms for bucketsets:
LOV: Defined by a list of values.
Range: Defined by a list of value ranges, defined by the range endpoints.
Enum: Defined by a list of enumerated types that is imported from either of:
- XML types
- Java facts
The slide shows a list of value ranges for the OrderAmount bucketset. There are three buckets
containing the following values:
Greater than 1000
Between 500 and 1000, inclusive
Less than 500
Note: Rules Designer added the negative Infinity (-Infinity) bucket.
Working with Bucketsets
Creating a Bucketset
To create a bucketset, execute the following steps:
1. In the Rules Designer, select the Bucketsets navigation tab. Click the Create Bucketset
icon, and select List of Ranges.
2. Double-click the bucket icon for the bucket. The Edit Bucketset dialog box opens.
3. In the Edit Bucketset dialog box, enter the bucketset name and select the appropriate data
type. Click the Add Bucket icon repeatedly to add the number of buckets you need in the
bucketset.
Creating a Bucketset
3
Creating Oracle Business Rules Globals

Oracle Business Rules globals are similar to public static variables in Java. Globals represent
data values or expressions that can be evaluated in rule conditions and expressions. You can use
global definitions to share information among several rules and functions. For example, if a 10%
discount is used in several rules, you can create and use a discount global, so that the
appropriate discount is applied to all the rules using the global.
To add a global, perform the following steps:
1. In the navigation tree, click the Globals node and then click the green plus (+) icon.
2. On the Edit Global page, perform the following actions:
- Enter a value in the Name field (for example, GoodCreditScore).
- In the Type field, select the desired type (for example, int).
- In the Value field, enter a value, select a value from the list, or click the Expression
Builder icon to enter an expression.
3. Click OK.
Creating Oracle Business Rules Globals
2
3
Creating a Ruleset
Rulesets provide a way of organizing your rules. Before rules can be created, you need to create
a ruleset as a container for the rules. To create the ruleset, perform the following steps:
1. In the Rules Designer, click the green plus (+) icon next to Rulesets.
2. In the Create Ruleset dialog box, enter a name for the ruleset (for example, OrderRules)
and, optionally, a value in the Description field. Click OK.
3. Back in the Rules Designer, confirm that the new ruleset has been added.
Creating a Ruleset
Rule name
Rule test condition
Rule action
Identifying the Structure of a Rule

A rule has a specific structure to be meaningfully evaluated. The parts are listed and shown in
the slide. The following is a brief description of each part:
The name identifies a specific rule in the ruleset.
The rule test defines a condition that is evaluated for the matching pattern to limit rule
evaluation for particular instances of the pattern matched type specified.
The rule action is the functionality executed for the matching pattern and test of the rule.
Identifying the Structure of a Rule
2
Left-side
<operand>
Click <add property>

to view the Properties
window
Right-side
<operand>
Creating a Rule
Rules define your business policies. For example, manual approval is required for orders with an
amount greater than $1,000; otherwise, the order should be automatically approved. Having
created the order facts and the ruleset for the rules, you can now create the manual order
approval business rule by performing the following steps:
1. Click the ruleset that you want to work with, and then click the green plus (+) icon for that
ruleset (shown in the slide).
2. A new rule is created. Change the name of the rule by clicking the existing name to enter
edit mode.
3. The IF area displays the rule pattern tests. At run time, when this rule is processed, the
Rules Engine checks the facts against rule pattern tests that you define to find matching
facts. The IF area of a rule includes a left-side <operand> and a right-side <operand>.
The left-side <operand> enables you to select the fact. The right-side <operand>
enables you to select the value to match with the fact for pattern test matching in the rule.
4. The THEN area displays the action associated with a pattern test match in a rule. At run
time, when the IF portion of a rule matches, the Rules Engine activates the THEN portion
and prepares to run the action. For example, in OrderApprovalRule, when the
Order.price fact matches (equals or exceeds $1000), the Rules Engine asserts that a
manual approval is required.
Creating a Rule
2
3
Creating a Rule Test

Creating a test ensures that a matching pattern is applied in the correct context. To create a rule
test, perform the following steps:
1. Click the left operand and choose the desired value from the list provided (for example,
Order.price).
2. Click the comparison operator (initially the type is = =) and choose the operator you want
to use (for example, >= ).
3. Click the right operand and choose the desired value from the list provided, or enter your
own value (for example, 1000).
4. If you need to add more rules tests, click the <insert test> link and repeat steps 13
for this new test.
Creating a Rule Test
Creating a Rule Action

Actions are associated with test pattern matches. When the IF part of a rule is matched by the
Rules Engine, then the THEN part of the rule is used to run the associated actions.
To add the action that assigns values associated with the rule from the previous page, perform
the following steps:
1. Click the <insertAction> link. Select the insert action you want to perform (for
example, assert new).
Other supported action types include:
- Modify, to modify a data value associated with a matched fact
- Retract, to retract a fact from a pattern if you want to remove the fact or to change the
state of the fact
- Call, to call a function to be performed by the action
2. Select <target> to display the option list. For example, select DiscountAndShipping
as shown in the slide.
3. Select <add property> to display the Properties dialog box. In the Properties dialog
box, in the Value column, select or enter the appropriate values for the properties and press
the Enter or Return key to accept the values. Click the Close button in the Properties dialog
box to complete the rule action.
Creating a Rule Action
A decision table:
Displays a set of if-then rules in a single spreadsheetstyle view
Contains a collection of related business rules with
condition rows, rules, and actions
Working with Decision Tables

A decision table enables you to create and use business rules in an easy to understand format that
provides an alternative to the if-then rule format. The decision table format is intuitive for
business analysts who are familiar with spreadsheets. The formal structure of a decision table
makes it easier to author, understand, and change multiple similar rules.
Oracle Business Rules decision tables provide the following features:
Powerful visualization: Compact and structured presentation. This visualization matches
the way real-world business policies that are expressed with many tables, declarative, and
organized into simple steps.
Error prevention: Avoids incompleteness and inconsistency. Because a decision table is
well structured, automated tools can check for conflicts, redundancy, and incompleteness
to speed development of valid, consistent business rules.
Modular knowledge organization: Group rules into a single table. A spreadsheet
metaphor puts groups of rules that work together onto a single viewable pane. For
example, if there are six rules that check an applicants eligibility, it is more convenient to
see all the rules than to view the rules as individual but related rules.
Optimization of rules and performance benefits: Oracle Business Rules decision tables
provide automated features that can reduce the number of required rules, as compared to
the if-then rules (this is called rule coalescing).
Rule validation and verification: Provides capabilities for ensuring the logical
consistency of rules before deployment. Automated tools for checking conflicts,
incompleteness, or gaps, help speed development of valid, consistent business rules.
Working with Decision Tables
if driver.age < 20 and

then driver.eligible =
if driver.age < 20 and
if driver.age >= 20
case)
driver.has training
true
driver.has training = false
false
true (do not care about training for this
The Conditions area in a decision table includes one or more condition rows. Each condition row
has a condition expression and, for each rule, a condition cell. A condition expression applies to
a data model fact (either a Java Fact, an XML Fact, an RL Fact, or an ADF Business
components fact).
Actions are associated with rules in a decision table. At run time, when facts match for condition
cells, the Rules Engine prepares to run the actions associated with the rule.
Working with Decision Tables (continued)

To help understand decision table concepts, consider the example on the slide that presents a set
of if-then rules that determine if a driver is eligible for a license, and an equivalent decision
table. Note if a driver has taken a driver training class then the driver has training certification.
The if-then rules follow:
2
4
Creating Conditions and Rules in Decision Tables

To create a decision table, execute the following steps:
1. In Rules Designer select an existing ruleset. Click the Add icon and from the list select
Create Decision Table option.
2. In the Decision Table area, from the list next to the Add icon select Condition.
3. Each condition row requires a bucketset from which to draw the values for each cell.
Select the global bucketset, as shown in the slide.
4. In the Conditions area, double-click "<edit-condition>" to display the navigator to select or
enter an expression.
Creating Conditions and Rules in Decision Tables (continued)

5. In the R1 (first rule) area, double-click the empty row to display the navigator to select or
enter an expression.
6. In the Decision Table area, from the list next to the Add icon select Rule to add a new rule
7. In the R2 (second rule) area, double-click the empty row to display the navigator to select
or enter an expression.
8. The decision table contains one condition with two rules.
Creating Actions in Decision Tables

To create an action in a decision table, execute the following steps:
1. In the decision table click the Add icon and from the list select Action > Assert New.
2. In the Actions area, double-click assert new ( .
3. In the Action Editor dialog box, in the Facts area select discountAndShipping. In the
Properties table select the Parameterized check box. This specifies that each rule
independently sets the parameter.
Creating Actions in Decision Tables (continued)

4. Specify the parameters for each of the properties. For example, all orders that cost less than
$5000 do not require manual approval, but orders costing more than or equal to $5000
require manual approval.
A decision function:
Provides a Web service interface to Oracle Business Rules
Is invoked from multiple business processes, such as a
Java application or a composite
Business application
Rules Engine
Rulesets
Display
logic
Policy and
rules
Business
process
Web
Service
Rule
dictionary
Working with Decision Functions

A decision function is a mechanism for publishing rules and rulesets as a reusable service that
can be invoked from multiple business processes. The goal is to separate volatile policy logic
from other business logic. The policies are implemented in rules executed on a Rules Engine,
and other business logic is implemented in Java executing in Java Virtual Machines (JVMs).
A decision function is a function that is configured declaratively. A decision function performs
the following operations:
Collects rulesets and other decision functions under a single executable umbrella
Handles the assertion of inputs as rule facts into the Oracle Business Rules Engine working
memory
Collects the consequent actions to be executed
Runs rulesets
Returns results
In a decision function the rules you want to use can be organized into several rulesets, and those
rulesets can be executed in a prescribed order. Facts may flow to the first ruleset, and this ruleset
may assert additional facts that flow to the second and subsequent rulesets until finally facts
flow back to the decision function as decision function output.
Working with Decision Functions
To integrate Oracle Business Rules with BPEL, drag a

Business Rules component to the BPEL flow.
Integrating Rules with a BPEL Process

Integrate rules with your BPEL process by simply dragging a Business Rules activity into your
BPEL flow. For the Business Rule activity, you specify the business rule that you want to use
and assign both input and output facts.
Integrating Rules with a BPEL Process
Adding a Business Rule Activity

The slide shows part of the process of adding a Business Rule activity to your BPEL process.
Drag a Business Rule activity icon from the Component palette into your BPEL process (as
shown in the previous slide). The Business Rule dialog box appears and the first step is to select
an existing rule dictionary or create a new rule dictionary.
Adding a Business Rule Activity (continued)

After the rule dictionary is chosen, the Input and Output Facts need to be identified. For the
Input Fact, click the green plus (+) icon to assign a BPEL variable for this Input Fact. Select the
BPEL variable on the From side, and select the Rule Fact on the To side. Click OK.
Adding a Business Rule Activity (continued)

For the Output Fact, click the Assign Output Facts tab and click the green plus (+) icon to assign
the Output Facts to a BPEL variable. In the Decision Fact Map dialog box, select the Rule Fact
on the From side, and select the BPEL Variable on the To side. Click OK.

Describe the needs for implementing business rules
Define Oracle Business Rules and its features
Create facts, rulesets, and a rule dictionary
Develop a rule-based application by creating a Business
Rule component and integrating it into a BPEL process
Summary
This lesson explained the Business Rule component and its feature and how to include a
Business Rule component in the BPEL process.
Now that you have been introduced to the different service components and how they can be
wired together in composite application, the next lesson will highlight how you can secure you
composite application and the service components that form a part of the composite application.
Summary

Adding a Business Rule service component to the SOA
composite
Accessing the Business Rule component from the BPEL
process

Implementing a Business Rule
Securing Services and Composite

Applications
SOA
The Securing Services and Composite Applications lesson introduces Web

services security and the need to secure services and composite applications.
Additionally you will also be familiarized with using the Enterprise Manager
Fusion Middleware Control to attaching security policies at run time.
Course Roadmap
The Implementing a Business Rules Component lesson introduced Oracle Business Rules and
its features.
The Securing Services and Composite Applications lesson provides an introduction to the
topic of securing services and composite applications.
Course Roadmap

Describe Web services security
Identify the need for security for services
Understand the Oracle Web Service Manager
Describe the components of the Oracle Web Service
Manager architecture
Attach security policies to services
Objectives
Securing Web services is about securing service endpoints and

involves the following:
Authentication and authorization
Ensuring message integrity
Maintaining message confidentiality
Allow (Y/N)?
Authenticate and authorize
Authentication:
Who?
Request
Response
Policy
enforcement
point
Endpoint
Introduction to Web Services Security

Web services security involves:
Authentication, the process of obtaining a username and password that is validated by
using some kind of identity store
Authorization, the process of allowing or disallowing access to some functionality or data,
usually implemented through privileges assigned to roles, or attaching policies to the
environment
Message integrity, which is achieved by ensuring that an authority digitally signs the
message
Confidentiality of data/message is ensured by encrypting the content of the request or
response message using XML encryption standard.
Introduction to Web Services Security
Verify the integrity of a message received

Maintain the confidentiality of a message
Determine the identity of the sender
Determine whether the sender is authorized to perform the
operation requested by the message
Need for Web Services Security

In the Web services context, security means that a message recipient is able to perform any of
the following tasks:
Verifying that the message is not modified during transfer from the source to the
destination
Preserving the confidentiality of a message, so that unauthorized parties cannot access it
Authenticating the sender
Determining whether the sender is authorized to perform the operation requested by the
message
To meet these requirements, two fundamental operations are used: message signing and message
encryption. These two operations are now becoming popular because they not only solve
existing security-related issues but also provide a base on which the entire security infrastructure
is created.
Need for Web Services Security
The standard ways of

securing Web services are:
Protocol based:
Secure sockets layer
(SSL)
Secure HTTP
(S-HTTP)
Message based:
XML digital signature
XML encryption
Security Assertion
Markup Language
(SAML)
Web Services Security Approaches

There are generally two different ways of implementing Web services security. They are called
protocol-based security and message-based security. SSL and S-HTTP are two examples of
protocol-based security.
The Web services security can be implemented by using the SSL protocol that transmits data by
using the Internet. SSL uses both asymmetric and symmetric key encryption technologies.
It uses public key (asymmetric) encryption to share a symmetric key between server and client.
This symmetric key is then used to encrypt and decrypt all data transferred on the SSL
connection. This encryption protects the data from other parties that try to eavesdrop and ensures
that private information, such as credit card numbers, can be transferred securely. Though SSL is
secure, it has some limitations. SSL secures the entire wire protocol rather than just the Simple
Object Access Protocol (SOAP) message sent over the protocol (as shown in the first screenshot
in the slide). As a result, it does not let developers apply different levels of security to different
parts of a document. It provides point-to-point security. Therefore, SSL fails to implement
security in a situation where multiple intermediary nodes exist between the two endpoints.
As compared to SSL, which creates a secured communication channel between the sender and
the recipient of data, S-HTTP is designed to transmit individual messages securely over the
Internet.
Web Services Security Approaches
Web Services Security Approaches (continued)

In case of the message-based security implementation, the client itself creates a secure message
and sends it to the target endpoint (as shown in the second screenshot in the slide). A clear text
message is initially converted into a message digest by using any hashing algorithm, such as
MD5 or SHA. A message digest is a digital signature that is generated from a sequence of bits,
such as a file. For a particular message digest generation algorithm, the same input always
produces the same digest. However, if the input is modified, the same algorithm produces a
different digest. The message digest is then encrypted with a clients private key to convert it
into a secure message.
In this case, the message remains secure irrespective of any number of intermediaries present
between the client and the endpoint. Unless the intermediary or endpoint has the correct security
infrastructure and is trusted, the message remains secure and unreadable and can be forwarded to
the next endpoint.
The three basic message-based security schemes that have been developed to provide a
comprehensive and unified security schemes for the Web services are:
XML digital signature: The XML digital signature specification describes digital
signature processing rules and syntax. XML signatures provide integrity, message
authentication, and signer authentication services for any type of data. XML digital
signature provides a flexible means of signing documents, and supports diverse sets of
Internet transaction models. For example, you can sign individual items or multiple items
of an XML document. The document that you sign can be a local or even a remote object,
as long as that object can be referenced through a Uniform Resource Identifier (URI). You
can sign not only XML data, but also non-XML data. A signature can be either enveloped
or enveloping, which means that the signature can either be embedded in a document being
signed or reside outside the document.
For more information about XML signature, see the specification at the following Web
site:
http://www.w3.org/TR/xmldsig-core
XML encryption: The XML encryption specification describes the process to encrypt data
and to represent the encrypted data in XML. XML encryption allows you to encrypt
different parts of an XML document. The encryption can be done on an entire XML
document, an XML element, or an XML element content. The result of the encrypted data
is an XML element, which contains or identifies (by using a URI reference) the cipher
data.
For more information about XML encryption, see the specification at:
http://www.w3.org/TR/xmlenc-core
Security Assertion Markup Language (SAML): SAML is an XML-based framework for
securely exchanging authentication, attribute, and authorization information between two
parties. This security information is expressed in the form of assertions about subjects,
either human or computer, that have identities in some security domain. One example of a
subject is a person who is identified by his or her e-mail address in a particular Internet
domain name server (DNS) domain. Assertions convey information about authentication
acts performed by subjects and attributes of subjects (such as ones credit line or
citizenship), as well as authorization decisions about whether subjects are allowed to
access certain resources.
WS-Security:
Is a standard framework for secure Web services, based
on SOAP
Is intended to specify a flexible set of mechanisms that can
be used to construct a range of security protocols
Provides quality of protection through message integrity
and message confidentiality
Provides a general-purpose mechanism for associating
security tokens with messages
WS-Security
WS-Security is a standard framework for secure Web services, based on SOAP. With WSSecurity, additional headers can be attached to the SOAP message to implement integrity and
confidentiality in Web service applications. WS-Security also provides a general-purpose
mechanism for associating security token propagation with messages to increase the protection
and confidentiality of messages. These enhancements include:
Securing SOAP messages through XML digital signature
Providing confidentiality through XML encryption
Providing credential propagation through security tokens
No specific type of security token is specified by WS-Security. It is designed to support multiple
security token formats, such as username/password, X.509 certificates, and SAML assertions.
WS-Security also describes how to encode binary security tokens, specifically X.509 certificates
and Kerberos tickets, as well as how to incorporate encrypted keys.
WS-Security can be used in the following scenarios:
Multiple security tokens for authentication or authorization
Multiple trust domains
Multiple encryption technologies
End-to-end message-level security and not just transport-level security (such as, SSL)
WS-Security
Authentication: Incorporated by using security tokens:

Username token
X.509 certificates
SAML assertions
Confidentiality:
Supports the W3C XML encryption standard
Supports standard key exchange mechanisms
Enables encryption to be applied in parts
Integrity:
W3C XML signature standard
Signature can be applied in parts
WS-Security Fundamentals
The basic fundamentals of WS-Security are as follows:
Authentication: Authentication is any process by which you verify and prove certain
information. For example, you may want to verify the origin of a document, the identity of
the sender, and the time and date when a document was sent or signed. Authentication is
incorporated by using security tokens. Oracle Application Server WS-Security supports the
use of the following security tokens:
- Username token: The username token carries basic authentication information.
It propagates username and password information to authenticate the message.
- X.509 certificates: The X.509 is a standard for defining digital certificates. An
X.509 certificate specifies a binding between a public key and a set of attributes that
includes subject name, issuer name, serial number, and validity interval. X.509
certificate may be used to validate a public key that may be used to sign or encrypt a
SOAP message.
- SAML assertions: SAML security tokens are composed of assertions that are used to
exchange security information, including attribute statements, authentication decision
statements, and authorization decision statements. SAML tokens are attached to
SOAP messages by placing assertion elements inside the header.
WS-Security Fundamentals
WS-Security Fundamentals (continued)

Confidentiality: It specifies that the data must be revealed to only those applications for
whom it is meant. It ensures data privacy by encrypting data between endpoints.
Oracle Application Server Web Services incorporates data confidentiality by implementing
the following:
- W3C XML encryption standard: The W3C XML encryption specification
describes a process for encrypting data and representing the result in XML. The data
can be an XML document, an XML element, or the content of an XML element. The
data also contains information that enables an intended recipient to decrypt the data.
The result of encrypting data is an XML encryption element that contains the
encrypted data.
The standard allows only selected parts of an XML document to be encrypted and not
the entire document.
- Standard key exchange mechanisms: The data can be encrypted and decrypted by
using some secret information, referred to as a key. There are two types of encryption
techniques: symmetric encryption and asymmetric encryption. In case of symmetric
encryption, one particular key is used for both encryption and decryption of data. In
the asymmetric encryption technique, each user has a public key and a private key.
The encryption of data is performed with the public key and the decryption is done
with the private key or vice versa.
Integrity: It specifies whether the message is lost, destroyed, or modified in transit, either
accidentally or intentionally. Oracle Application Server Web Services implements integrity
by incorporating the W3C XML signature standard. The XML signature specification
describes digital signature processing rules and syntax to provide message integrity,
message authentication, and signer authentication services for data of any type, whether
located in the XML that includes the signature or elsewhere. An XML signature contains
the basic hash (message digest) of the signed document. It also contains information about
what data was signed and which algorithms were used. An XML signature can be included
within the document to which the signature belongs or in a separate document. An XML
signature can also be applied to specific parts of a document and not the entire document
as a whole.
Authentication can be incorporated using _____________ .

1. Signature
2. Security tokens
3. Encryption
Answer: 2
Explanation : Authentication is the process of obtaining a username and password that is
validated by using some kind of identity store. For example, you may want to verify the origin of
a document, the identity of the sender, and the time and date when a document was sent or
signed. Authentication is incorporated by using security tokens. The security tokens supported
are:
Username token: The username token carries basic authentication information.
It propagates username and password information to authenticate the message.
X.509 certificates: The X.509 is a standard for defining digital certificates. An X.509
certificate specifies a binding between a public key and a set of attributes that includes
subject name, issuer name, serial number, and validity interval. X.509 certificate may be
used to validate a public key that may be used to sign or encrypt a SOAP message.
SAML assertions: SAML security tokens are composed of assertions that are used to
exchange security information, including attribute statements, authentication decision
statements, and authorization decision statements. SAML tokens are attached to SOAP
messages by placing assertion elements inside the header.
Quiz
Oracle Web Service Manager (OWSM) is security and

management system that provides a common security
infrastructure for Web services applications.
The Oracle Web Service Manager (OWSM) is based on
three main operations:
Define
Enforce
Monitor
Oracle Web Service Manager

The Oracle Web Services Manager is designed to define and implement Web services security in
heterogeneous environment. Instead of coding security logic in the application, you can use
Oracle Web Services Manager to implement declarative security and management through
predefined policies. The three main operations on which the Oracle Web Services manager is
based are:
Define consists in attaching security and management policies to the Web services to be
protected.
Enforce is the ability provided by Oracle Web Services Manager to distribute policies
from a central policy manager to policy enforcement points that execute security and
management policies at run time.
Monitor is the tracking of run-time security and management events captured by the
Oracle Web Services Manager.
Oracle Web Service Manager
Oracle WSM Agent

Reliable Messaging
Management
Addressing
Security
MTOM
Policy Interceptors
Fusion Middleware Control
Oracle JDeveloper
Oracle WSM
Policy
Manager
Metadata
Store
(MDS)
Oracle
Fusion
Middleware
Database
Components of Oracle Web Services Manager Architecture

The components of the Oracle Web Services Manager Architecture can be described as follows:
Oracle Enterprise Manager Fusion Middleware Control: Enables administrators to
access Oracle Web Services Managers functionality to manage, secure, and monitor Web
services
Oracle Web Services Manager Policy Manager: Reads and writes policies, including
predefined and custom policies from the metadata store
Oracle WSM Agent: Manages the enforcement of policies via the Policy Interceptor
Pipeline
Policy Interceptors: Enforce policies, including reliable messaging, management,
addressing, security, and Message Transmission Optimization Mechanism (MTOM)
Metadata Store: Used for storing policies. Policies can be stored either as files in the file
system (supported for development) or to the Oracle Fusion Middleware database
(supported for production).
Oracle Fusion Middleware Database: Provides database support for the MDS
Components of Oracle Web Services Manager

Architecture
Oracle Web Service Manager provides a policy framework

to manage and secure Web services consistently.
The policy framework is build using the WS-Policy
standard and leverages the Oracle Platform Security
Service (OPSS) Login Module and Oracle WebLogic
Server authenticator for authentication and authorization.
Oracle Web Services Manager
Policy Enforcement Point
Oracle Platform Security
Login Module
Oracle WebLogic Server
Authenticator
Oracle Web Services Manager Policy Framework

Oracle OWSM can be leveraged from the Oracle Enterprise Manager Fusion Middleware
Control to:
Centrally define policies using the Oracle WSM Policy Manager.
Enforce Oracle WSM security and management polices locally at run time.
You can perform the following tasks from Oracle Enterprise Manager Fusion Middleware
Control:
Handle WS-Security (for example, encryption, decryption, signing, signature validation,
and so on)
Define authentication and authorization policies against an LDAP directory.
Generate standard security tokens (such as SAML tokens) to propagate identities across
multiple Web services used in a single transaction.
Segment policies into different namespaces by creating policies within different folders.
Examine log files.
Oracle Web Services Manager Policy Framework
Policies describe the capabilities and requirements of a Web

service. The different types of policies supported in Oracle
Fusion Middleware 11g are:
WS-ReliableMessaging
Management
WS-Addressing
Security
Message Transmission Optimization Mechanism (MTOM)
Introduction to Policies
The different type of policies available are as follows:
WS-ReliableMessaging: Reliable messaging policies that implement the WSReliableMessaging standard describes a wire-level protocol that allows guaranteed
delivery of SOAP messages, and can maintain the order of sequence in which a set of
messages are delivered.
Management: Management policies that log request, response, and fault messages to a
message log. Management policies may include custom policies.
WS-Addressing: WS-Addressing policies that verify that SOAP messages include WSAddressing 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.
Security: Security policies that implement the WS-Security 1.0 and 1.1 standards. They
enforce message protection (message integrity and message confidentiality), and
authentication and authorization of Web service requesters and providers. The following
token profiles are supported: username token, X.509 certificate, Kerberos ticket, and
Security Assertion Markup Language (SAML) assertion.
Message Transmission Optimization Mechanism: Binary content, such as an image in
JPEG format, can be passed between the client and the Web service. In order to be passed,
the binary content is typically inserted into an XML document.
Introduction to Policies
Request
Reliable Messaging
Management
Addressing
Security
MTOM
Response
Client
Network
MTOM
Security
Addressing
Management
Reliable Messaging
Web
Service
Policy Interceptor Pipeline

The slide depicts Policy Interceptors acting on messages between a client and Web service. The
messaging order can be described as follows:
The client sends a request message to a Web service.
The policy interceptors intercept and execute the policies attached to the client. After the
client policies are successfully executed, the request message is sent to the Web service.
The request message is intercepted by policy interceptors, which then execute any service
policies that are attached to the Web service.
After the service policies are successfully executed, the request message is passed to the
Web service. The Web service executes the request message and returns a response
message.
The response message is intercepted by the policy interceptors, which execute the service
policies attached to the Web service. After the service policies are successfully executed,
the response message is sent to the client.
The response message is intercepted by the policy interceptors, which execute any client
policies attached to the client.
After the client policies are successfully executed, the response message is passed to the
client.
Policy Interceptor Pipeline
Oracle Web Services Manager policies are made of one or

more assertions that exhibit a particular behavior.
Assertions are executed in the order in which they are
listed in the policy.
Policy
Request
Response
Assertion 1
Assertion 2
Assertion n
Policy Assertions
Oracle Web Services Manager policies consists of one or more assertions exhibiting a particular
capability/behavior. For example, a security policy could be made up of two assertions a) Log
assertion b) WS-Security assertion. If this particular security policy is attached, the log assertion
gets executed first, resulting in the request message being logged into a log file. This is followed
by the execution of the WS-Security assertion that authenticates the requestor and decrypts the
message if it is encrypted.
Oracle WSM policy assertions are instances of policy assertion templates that are added to a
policy at policy creation time. There are a set of predefined policy assertion templates that come
as a part of Oracle Web Services Manager. Oracle WSM allows users to define custom policy
assertions that can be executed in a policy along with predefined policy assertions. Custom
policy assertions are used when specific functionality is not provided.
Policy Assertions
Policies are made up of one or more _____________ .

1. Tokens
2. Protocols
3. Assertions
Answer: 3
Explanation : Oracle Web Services Manager policies are made of one or more assertions that
exhibit a particular behavior. Assertions are executed in the order in which they are listed in the
policy. Oracle WSM policy assertions are instances of policy assertion templates that are added
to a policy at policy creation time. There are a set of predefined policy assertion templates that
come as a part of Oracle Web Services Manager.
Quiz
Policies page
Specifying the
component to
which the policy is
to be attached
Managing SOA Composite Application Policies

Policies apply security to the delivery of messages. You can attach or detach security policies to
and from currently deployed SOA composite applications.
To manage SOA composite application policies:
1. Select soa-infra in the SOA folder
2. Select a specific SOA composite application.
3. Click the Policies tab.
The Policies page enables you to attach and detach policies to Web service binding
components and service components of the SOA composite application. The policies table
displays the attached policy name, component to which the policy is attached, policy
reference status (enabled or disabled) that you can toggle, category (Management, Reliable
Messaging, MTOM Attachment, Security, or WS Addressing), violations, and
authentication, authorization, confidentiality, and integrity failures since the SOA
Infrastructure was last restarted.
4. Click Attach To/Detach From.
5. Select the component to which to attach or detach a policy. This invokes a dialog for
attaching or detaching policies.
Managing SOA Composite Application Policies
Attaching the
policy
Executing the
Validation test
Managing SOA Composite Application Policies (continued)

6. Select policies to attach that are appropriate to your environment.
7. Click Attach.
8. Attach additional policies as needed.
9. When you are finished attaching policies, click Validate.
10. If an error message appears, make the necessary corrections until you no longer have any
validation errors.
11. Click OK.
Attaching Security Policy to a Service
Policies apply security to the delivery of messages.

1. True
2. False
Answer: 1
Explanation: Oracle Web Services Manager provides two tools for attaching policies to clients
and services Oracle JDeveloper and Oracle Enterprise Manager. Application developers can
attach Oracle Web Services Manager policies at application design time within JDeveloper.
Whether to attach policies within JDeveloper or Oracle Enterprise Manager is based on whether
you want to empower application developers to apply policies and lock down the application or
you want application developers to concentrate on writing business logic while security
administrator applies policies post-deployment of the application.
Quiz
In this lesson you should have learned how to:

Describe Web services security
Identify the need for security for services
Understand the Oracle Web Service Manager
Describe the components of the Oracle Web Service
Manager architecture
Attach security policies to services
Summary
This lesson introduced the need of securing services, the components of the Oracle Web Service
Manager Architecture, and how to use the Enterprise Manager console to attach security
policies.
Summary

Attach username_security_policy to the receivePO Web
service (entry point in Enterprise Manager)
Attach log_policy to receivePO Web service
Test in Enterprise Manager
Attaching Policies to Web Services

SOA Suite 11g Essential Concepts - Volume 1

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SOA Suite 11g Essential Concepts - Volume 1

Încărcat de

Drepturi de autor:

Formate disponibile

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY.

COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED

Volume I - Student Guide

Oracle University and Sentra inversiones y servicios LTDA use only

Oracle SOA Suite 11g: Essential

This document contains proprietary information and is protected by copyright and

Oracle University and Sentra inversiones y servicios LTDA use only

Service-Oriented Architecture Concepts

Oracle University and Sentra inversiones y servicios LTDA use only

Implementing SOA with Oracle SOA Suite

SOA Governance and Service

Oracle University and Sentra inversiones y servicios LTDA use only

Designing Services for SOA Implementations

Oracle University and Sentra inversiones y servicios LTDA use only

SLA Management 3-21

Creating a Composite Application

Managing and Monitoring SOA Composite Applications

Oracle University and Sentra inversiones y servicios LTDA use only

Packaged Application and Legacy Adapters 4-42

Working with Mediator Components

Oracle University and Sentra inversiones y servicios LTDA use only

Working with the Flow Trace 6-14

Orchestrating Services with a BPEL Component

Working with the Human Task Component

Oracle University and Sentra inversiones y servicios LTDA use only

10 Implementing a Business Rules Component

Oracle University and Sentra inversiones y servicios LTDA use only

Adding Task Parameters 9-17

Appendix A: Practices and Solutions

Oracle University and Sentra inversiones y servicios LTDA use only

Oracle Web Service Manager 11-12

Oracle University and Sentra inversiones y servicios LTDA use only

Developing the SOA Reference Architecture D-13

Oracle University and Sentra inversiones y servicios LTDA use only

Copyright 2009, Oracle. All rights reserved.

Oracle University and Sentra inversiones y servicios LTDA use only

After completing this course, you should be able to:

Copyright 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts I - 2

Oracle University and Sentra inversiones y servicios LTDA use only

Implementing SOA with

SOA Governance and

Designing Services for

Copyright 2009, Oracle. All rights reserved.

Course Agenda: Day 1

Oracle SOA Suite 11g: Essential Concepts I - 3

Oracle University and Sentra inversiones y servicios LTDA use only

Course Agenda: Day 1

Managing and Monitoring

Working with Mediator

Copyright 2009, Oracle. All rights reserved.

Course Agenda: Day 2

Oracle SOA Suite 11g: Essential Concepts I - 4

Oracle University and Sentra inversiones y servicios LTDA use only

Course Agenda: Day 2

Working with the

Securing Services and

Copyright 2009, Oracle. All rights reserved.

Course Agenda: Day 3

Oracle SOA Suite 11g: Essential Concepts I - 5

Oracle University and Sentra inversiones y servicios LTDA use only

Course Agenda: Day 3

After completing this lesson, you should understand the:

Copyright 2009, Oracle. All rights reserved.