Vous êtes sur la page 1sur 404

Oracle SOA Suite 11g:

Essential Concepts

Volume 1 - Student Guide

D58786GC10
Edition 1.0
August 2009
D61580
Authors Copyright © 2009, Oracle. 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
Technical Contributors any way. Except where your use constitutes "fair use" under copyright law, you may
and Reviewers 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
Cathy Lippert express authorization of Oracle.

Dave Berry 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,
Holger Dindler Rasmussen 500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not
warranted to be error-free.
Heidi Buelow
Restricted Rights Notice
Demed L'Her
If this documentation is delivered to the United States Government or anyone using
Prasen Palvankar the documentation on behalf of the United States Government, the following notice is
applicable:
Tom Hardy
U.S. GOVERNMENT RIGHTS
David Shaffer The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or
disclose these training materials are restricted by the terms of the applicable Oracle
James Mills
license agreement and/or the applicable U.S. Government contract.
Jai Kasi
Trademark Notice
Magnus Kling
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other
Mathias Kullberg names may be trademarks of their respective owners.

Matthew Slingsby
Vasiliy Strelnikov
Vikas Jain
Glenn Stokol
Pete Laseau
Nagavalli Pataballa
William Prewitt

Editors
Vijayalakshmi Narasimhan
Daniel Milne
Arijit Ghosh

Graphic Designer
Rajiv Chandrabhanu
Satish Bettegowda

Publishers
Giri Venugopal
Michael Sebastian Almeida
Jobi Varghese
Contents

I Introduction
Course Objectives I-2
Course Agenda: Day 1 I-3
Course Agenda: Day 2 I-4
Course Agenda: Day 3 I-5
Summary I-6

1 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
2 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

3 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
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

4 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
Packaged Application and Legacy Adapters 4-42
Quiz 4-43
Summary 4-44
Practice 4: Overview Designing Services for SOA Implementations 4-45

5 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

6 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
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

7 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
8 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

9 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
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

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
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

Appendix A: Practices and Solutions

Appendix B: Introduction to Linux


What Is Linux? B-2
What Is Oracle’s 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
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

Glossary

xi
Introduction

Copyright © 2009, Oracle. All rights reserved.


Course Objectives

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

Copyright © 2009, Oracle. All rights reserved.

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 Agenda: Day 1

O A
S
Service-Oriented Implementing SOA with SOA Governance and Designing Services for
Architecture Concepts Oracle SOA Suite Service Life-Cycle SOA Implementations
Management

1 2 3 4

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts I - 3


Course Agenda: Day 2

Creating a Composite Managing and Monitoring Working with Mediator Orchestrating Services
Application SOA Composite Components with a BPEL
Applications Component

5 6 7 8

Copyright © 2009, Oracle. All rights reserved.

Course Agenda: Day 2


The following is the course agenda for day 2:
• 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 transformations—of 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.

Oracle SOA Suite 11g: Essential Concepts I - 4


Course Agenda: Day 3

Working with the Implementing a Business Securing Services and


Human Task Component Rules Component Composite Applications

9 10 11

Copyright © 2009, Oracle. All rights reserved.

Course Agenda: Day 3


The following is the course agenda for day 3:
• 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.

Oracle SOA Suite 11g: Essential Concepts I - 5


Summary

After completing this lesson, you should understand the:


• Learning objectives of this course
• Structure and organization of this course

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts I - 6


Service-Oriented Architecture Concepts

Copyright © 2009, Oracle. All rights reserved.


Course Road Map

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.

Copyright © 2009, Oracle. All rights reserved.

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


Objectives

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

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 1 - 3


Definition: Service-Oriented Architecture (SOA)

Service-Oriented Architecture is an IT strategy that organizes


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

Business IT
Strategy SOA Strategy

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 1 - 4


Why SOA?

SOA enables:
• Reusability
– Business services
• Interoperability
– Loosely coupled services
• Scalability and flexibility
– Coarse-grained
– Document-oriented
– Asynchronous services
• Cost efficiency
– Standards-based approach

Copyright © 2009, Oracle. All rights reserved.

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
easily—certainly 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.

Oracle SOA Suite 11g: Essential Concepts 1 - 5


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.

Oracle SOA Suite 11g: Essential Concepts 1 - 6


Enterprise Challenge

• Application development and integration issues


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

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 1 - 7


Point-to-Point Integration

«EAI» Custom «Packaged CRM» Custom «Client Tier»


API API
CRM
Application
«Custom Custom «Packaged ERP» Custom
«Client
Logic» API API Application»
ERP
Application

«Custom Custom «Mainframe» Custom


«Client
Logic» API API Application»
Custom
Application

«Custom Custom «App Server» Custom «Client


Logic» API API Application»
EJB
Application

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 1 - 8


Enterprise Application Integration

«Client Tier»
«VB «Java «Web
Application» Application» Application»

Standard-based interfaces
Standard-based Interfaces Standard-based
Standard-basedinterfaces
Interfaces

Message Bus or Middleware


Custom Custom
«Packaged CRM» API «Packaged ERP» API

CRM ERP
Application Application

JAM API RMI


«Mainframe» «App. Server»
Custom EJB
Application Application

Copyright © 2009, Oracle. All rights reserved.

Enterprise Application Integration


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.

Oracle SOA Suite 11g: Essential Concepts 1 - 9


Example of Application-Centric Integration

Web based Banking Application


Apply for new Credit Card Apply for new Mortgage Loan

Verify Customer
Check Customer Address
Credit Card
Setup
Conduct Account
Setup Fraud
Account Check

Marketing Sales and Risk Corporate Business


System Acquisition System System Unit

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 1 - 10


Integrating Solutions and Benefits with SOA

Offers faster business Improves business


response time agility

Masks underlying Service-Oriented Aligns IT with


technical complexity Architecture business

Benefits

Cost
Reusability Interoperability Scalability
Efficiency

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 1 - 11


SOA Further Defined

• 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.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 1 - 12


Moving Toward Service-Centric Integration
Application Centric Integration Service-Centric Integration
Web Phone Branch Systems Trading Partners

Channels

Web UI / Portals/ Portlets

Presentation Service Layer

Service
Bus
Business Process Layer (BPM, Workflow) Mediation

Check Verify Customer Setup Conduct Fraud


Credit Card Address Account Check

Business Service

Integration Tier (Connectivity Service)


SOA
Assets /Systems Governance

Copyright © 2009, Oracle. All rights reserved.

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 interface–related services.
The service-centric integration approach provides a shared service and infrastructure platform that
encourages reusability and flexibility.

Oracle SOA Suite 11g: Essential Concepts 1 - 13


SOA: A Paradigm Shift

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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 1 - 14


The Eight-Domain Model Approach for SOA

Technology Dominated Organizational Disciplines

Architecture Business and Strategy

Infrastructure Organization

Information Governance

Operations, Project,
Administration, and Management Portfolios, and Services

Copyright © 2009, Oracle. All rights reserved.

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
Oracle SOA Suite 11g: Essential Concepts 1 - 15
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.
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.

Oracle SOA Suite 11g: Essential Concepts 1 - 16


Quiz

Which one does not belong to the Eight-Domain model?


1. Business and Strategy
2. Governance
3. Architecture
4. Installation

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 1 - 17


Building an SOA Reference Architecture:
From Architecture Drivers to a Roadmap
Identify the
stakeholders’ viewpoints
Determine business
or concerns, prioritize Design an incremental
scope and motivation.
SOA benefits, and plan to achieve the
examine the current future vision.
reality.

Best Practices

IT Objectives SOA Strategy Future Vision Roadmap


Business
Business Drivers
Drivers
SOA Reference Architecture

Current Reality
SOA reference
architecture should
include definitions,
Determine IT drivers. standards, rules,
principles, and
guidelines, and
architecture views.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 1 - 18


SOA Reference Architecture

• 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 organization’s architects to make architecture and
design decisions on their projects
– Is a key component of an effective strategy to deliver the
benefits of SOA

Copyright © 2009, Oracle. All rights reserved.

SOA Reference Architecture


An SOA reference architecture promotes consistency and interoperability by defining enterprise-
wide 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 2–3 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

Oracle SOA Suite 11g: Essential Concepts 1 - 19


SOA Reference Architecture

Employees Customers Partners Client Partner


Service Consumers and Apps Apps

Delivery Channels

Composite Applications Web Apps Portals Mashups BPM Process Clients

Shared Services and Infrastructure


Service Registry
Presentation Services Shared Portlets Multichannel Delivery
Service
Service Repository
Bus
Business Processes System-Centric Workflow Human-Centric Workflow
SOA Security
Infrastructure
Business Services Enrichment Custom/Atomic Business Services
Mediation
SOA Monitor and
Data Services Logical Data Model Data Aggregation/Synchronization Event Manager

Infrastructure
Connectivity Services System/Data Access Messaging Partner Integration Services

Messaging Adapters Custom APIs JDBC file://

Non-Service Enabled Assets Service-Enabled Assets

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 1 - 20


SOA Reference Architecture:
Service Consumers
Employees Customers Partners Client Partner
Service Consumers and Apps Apps

Delivery Channels

Composite Applications Web Apps Portals Mashups BPM Process Clients

Users of the enterprise functionality

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 1 - 21


SOA Reference Architecture:
Service Classification
Shared Services and Infrastructure
Service Registry
Presentation Services Shared Portlets Multichannel Delivery
Service
Service Repository
Bus
Business Processes System-Centric Workflow Human-Centric Workflow
SOA Security
Infrastructure
Business Services Enrichment Custom/Atomic Business Services
Mediation
SOA Monitor and
Data Services Logical Data Model Data Aggregation/Synchronization Event Manager

Infrastructure
Connectivity Services System/Data Access Messaging Partner Integration Services

Service classifications and infrastructure


requirements of Service-Oriented
Architecture

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 1 - 22


SOA Reference Architecture:
Service Providers
Shared Services and Infrastructure
Service Registry
Presentation Services Shared Portlets Multichannel Delivery
Service
Service Repository
Bus
Business Processes System-Centric Workflow Human-Centric Workflow
SOA Security
Infrastructure
Business Services Enrichment Custom/Atomic Business Services
Mediation
SOA Monitor and
Data Services Logical Data Model Data Aggregation/Synchronization Event Manager

Infrastructure
Connectivity Services System/Data Access Messaging Partner Integration Services

Messaging Adapters Custom APIs JDBC file://

Non-Service Enabled Assets Service-Enabled Assets

Assets that can be shared and reused


throughout the enterprise

Copyright © 2009, Oracle. All rights reserved.

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-service–enabled assets standardize the exposure
of their functions to the other service classes using the connectivity services.

Oracle SOA Suite 11g: Essential Concepts 1 - 23


Reference Architecture: Example
Web Application eCommerce Processes
Create New Convert Quote Check Order Check Invoice
Quote or Order to Order Status History

Cart Service Bus Order Invoice


Service Service Service

Business
Process
Calculate Shopping Cart Import Order
Services

Business Calc Item Price & Check Calc Freight


Activity Item Availability
Services

Connectivity Services – Oracle Adapter


System Access Data Access

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 1 - 24


Standards That Enable SOA
Current and Emerging Standards Category
Service Component Architecture (SCA) Assembly
model
Business
Orchestration: BPEL4WS
processes
Service Data Objects (SDO) Data access

Management Quality of
WS-ReliableMessaging WS-Security
WS-Policy service
WS-Security UDDI Discovery
WSDL Description

SOAP
Message
XML
HTTP(S), IIOP, JMS, SMTP Transport

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 1 - 25


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

Oracle SOA Suite 11g: Essential Concepts 1 - 26


Quiz

An SOA reference architecture is a blueprint to guide the


enterprise toward SOA success.
1. True
2. False

Copyright © 2009, Oracle. All rights reserved.

Answer: 1
Explanation: The SOA Reference architecture defines the target architecture and the principles to be
used by an organization’s architects to make architecture and design decisions on their projects.

Oracle SOA Suite 11g: Essential Concepts 1 - 27


Service and Web Service

• 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

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 1 - 28


Types of Service Access and Implementation

Types of Service Access and Implementation

Created Invoked Created as


Service Service
from existing access
through access
new
functionality protocols and functionality
methods

Can be achieved Services can be Can be developed by


either by exposing invoked by using using service bus
existing functionality SOAP over HTTP, components, BPEL
as Web services or JMS adapters, or processes, or Web
by using adapters WSIF. services implemented
with Java or Java EE

Copyright © 2009, Oracle. All rights reserved.

Types of Service Access and Implementation


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.

Oracle SOA Suite 11g: Essential Concepts 1 - 29


Ways to Integrate Services

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

Copyright © 2009, Oracle. All rights reserved.

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 services–style
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.

Oracle SOA Suite 11g: Essential Concepts 1 - 30


Designing with an SOA Approach

Designing with an SOA approach involves:


• Aligning IT with the business needs—design needs to be
driven by business process
• Identifying services that performs functionality as part of a
business process—building 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 1 - 31


Creating Service Portfolios

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

Copyright © 2009, Oracle. All rights reserved.

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 services—their
interfaces and message structure—in 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.

Oracle SOA Suite 11g: Essential Concepts 1 - 32


SOA Workflow and Orchestration

• Basic data access and discrete


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

for creating these services.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 1 - 33


Implementing SOA: General Concepts

• Build a portfolio of services (Web service, .NET, adapters).


• Register and publish services (UDDI).
• Decouple services through virtualization
and routing (mediator). Web
• Orchestrate services (BPEL). application

• Create user interfaces to initiate


and interact with services.
Orchestration
(process flow)

Mediator

Service
Java .Net Adapter
UDDI Registry Portfolio

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 1 - 34


Quiz

Services can be implemented using existing functionality.


1. True
2. False

Copyright © 2009, Oracle. All rights reserved.

Answer: 1
Explanation: Services can be implemented using existing functionality by exposing existing
functionality as services or by using adapters.

Oracle SOA Suite 11g: Essential Concepts 1 - 35


Define SOA Governance

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
organization’s service-oriented architecture
Policies
(What)

Decisions Processes
(Who) (How)

Copyright © 2009, Oracle. All rights reserved.

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 organization’s strategic objectives. Governance is a process that is
influenced through organizational behavior and the establishment of structured processes.
Technology is there to help automate the governance process as much as possible. In other words, it
is a framework for managing SOA assets in compliance with a company’s standards, policies, and
business strategies specifically focused on the life cycle of services, policies, practices, metadata, and
composite applications.

Oracle SOA Suite 11g: Essential Concepts 1 - 36


Identifying the Need of SOA Governance

• Business value
• Alignment
• Business agility
• Risk reduction
• Cost savings

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 1 - 37


SOA Governance Framework

• The SOA governance framework is centered on the four


facets of enterprise architecture:
– People
– Process
– Service
– Technology
People Process

Service Technology

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 1 - 38


Quiz

The SOA governance framework is centered on _________,


process, technology, and service.
1. Strategy
2. Risk
3. People
4. Value

Copyright © 2009, Oracle. All rights reserved.

Answers: 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.

Oracle SOA Suite 11g: Essential Concepts 1 - 39


Course Practice Scenario:
Purchase Order Processing

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 1 - 40


Summary

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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 1 - 41


Practice 1 Overview:
Preparing the Business Flow Diagram
This practice covers designing a business flow diagram for
purchase order processing

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 1 - 42


Implementing SOA with Oracle SOA Suite

Copyright © 2009, Oracle. All rights reserved.


Course Roadmap

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.

Copyright © 2009, Oracle. All rights reserved.

Course Roadmap
In the “Service-Oriented Architecture Concepts” lesson you were familiarized with the Service-
Oriented 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.

Oracle SOA Suite 11g: Essential Concepts 2 - 2


Objectives

After completing this lesson, you should be able to:


• List the Oracle SOA Suite 11g components
• Describe the service components
• Define a composite application
• Explain the role of Enterprise Manager

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 2 - 3


Basic Components of an SOA Infrastructure

ESB B2B

5 BPEL
IF
Adapter
2 1
1
Legacy System
Web Service

IF 6
4
Human Workflow
Rules
Engine

Adapter 7
2
BAM
Web Service
1

Database

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 2 - 4


Oracle SOA Suite 11g Components

Message

Event Business Human


Mediator BPEL
rules workflow
JDeveloper

Event Delivery Network (EDN)

Enforcement points WS Policy


Service infrastructure Manager

SOAP JMS Others EM and SOA


console
B2B BAM MDS Registry

Copyright © 2009, Oracle. All rights reserved.

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: Essential Concepts 2 - 5


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.

Oracle SOA Suite 11g: Essential Concepts 2 - 6


Introduction to Service Infrastructure

This provides the internal message routing infrastructure


capabilities for connecting components and enabling data flow.

Service/Event Delivery API

Mediator
Event
Route

Transformation
Filter
Enforcement
point policies SOAP
Service JCA
infrastructure Other (adapters)
UDDI bindings
registry
Metadata
store

Copyright © 2009, Oracle. All rights reserved.

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)

Oracle SOA Suite 11g: Essential Concepts 2 - 7


Introducing SCA in Oracle SOA Suite 11g

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

Copyright © 2009, Oracle. All rights reserved.

Introducing SCA in Oracle SOA Suite 11g


The Service Component Architecture (SCA) specifications define a new way of assembling SOA-
enabled 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.

Oracle SOA Suite 11g: Essential Concepts 2 - 8


Defining a Composite Application

• 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

Copyright © 2009, Oracle. All rights reserved.

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)

Oracle SOA Suite 11g: Essential Concepts 2 - 9


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 SOA Suite 11g: Essential Concepts 2 - 10


Introducing Oracle Mediator Component

• 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
composite application
Editor

Copyright © 2009, Oracle. All rights reserved.

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 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.

Oracle SOA Suite 11g: Essential Concepts 2 - 11


Describing the Features of 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 2 - 12


Introducing Oracle BPEL Process 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

Copyright © 2009, Oracle. All rights reserved.

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).

Oracle SOA Suite 11g: Essential Concepts 2 - 13


Introducing Business Rules 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
component created in
the SOA composite
application Editor

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 2 - 14


Introducing Human Task 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
component created in
the SOA composite
application Editor

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 2 - 15


Quiz

The _________ is a component that uses the concept of


Process Orchestration.
1. Mediator
2. Human Task
3. BPEL
4. Business Rule

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 2 - 16


Introduction to Business Activity Monitoring

• 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
BPEL PM Oracle BAM

Oracle JMS Interface to


external
Oracle DB technologies

Other
Technologies
Oracle DB Real-time dashboard reports
repository

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 2 - 17


Monitoring Services with BPEL and BAM

Sensor

Monitor

BPEL BAM dashboard

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 2 - 18


Oracle Enterprise Manager

The Oracle Enterprise Manager (EM) Fusion Middleware


Control Console enables you to perform administrative tasks
such as:
• Configuration
• Monitoring
• Management

Copyright © 2009, Oracle. All rights reserved.

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 SOA Suite 11g: Essential Concepts 2 - 19


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

Oracle SOA Suite 11g: Essential Concepts 2 - 20


Oracle WebLogic Server 10.3

• 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

Copyright © 2009, Oracle. All rights reserved.

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 SOA Suite 11g: Essential Concepts 2 - 21


WebLogic Server Domain

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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 2 - 22


WebLogic Server Domain

WebLogic Server domains can be used to separate:


• Development, test, and production applications
• Administration and operational responsibilities
• Organizational or business divisions

Domain1 (Development) Domain2 (Production)

Application 1 Application 2 Application 1 Application 2

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 2 - 23


WebLogic Server Servers

• A server is a WebLogic Server instance executing within a


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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 2 - 24


Administration Server

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

Configuration
Administration repository
Critical domain (config.xml)
notifications server
(logs)

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 2 - 25


Managed 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 2 - 26


WebLogic Server Machines

• 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 2 - 27


SOA Development with Oracle JDeveloper

The Oracle JDeveloper IDE environment provides design and


edit tools that enable the creation of SOA composite
applications. SOA service
components

SOA Composite
Editor

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 2 - 28


Creating Connections in Oracle JDeveloper

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 2 - 29


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.

Oracle SOA Suite 11g: Essential Concepts 2 - 30


Creating an Application Server Connection in
Oracle JDeveloper
Step 1 of 7

Step 2 of 7: Type

Step 3 of 7: Authentication

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 2 - 31


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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 2 - 32


Goals of Implementing SOA Application with
Oracle SOA Suite 11g
• 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

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 2 - 33


Quiz

Oracle Enterprise Manager performs administrative tasks such


as _____________, _______________ and _____________.
1. Configuring
2. Monitoring
3. Managing
4. Orchestrating

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 2 - 34


Quiz

The Oracle JDeveloper IDE provides design and edit tools that
enable the creation of SOA composite applications.
1. True
2. False

Copyright © 2009, Oracle. All rights reserved.

Answer: 1
Explanation: JDeveloper provides tools to package and deploy your SOA composite applications as
applications to a target run-time environment.

Oracle SOA Suite 11g: Essential Concepts 2 - 35


Summary

In this lesson, you should have learned how to:


• List the Oracle SOA Suite 11g components
• Describe the Service components
• Define a composite application
• Explain the role of Enterprise Manager

Copyright © 2009, Oracle. All rights reserved.

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 Oracle’s SOA Governance solution.

Oracle SOA Suite 11g: Essential Concepts 2 - 36


Practice 2 Overview:
Creating Connections in JDeveloper
This practice covers the following topics:
• Creating a connection to the Oracle WebLogic Server from
JDeveloper
• Browsing an existing SOA application from JDeveloper

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 2 - 37


SOA Governance and Service
Life-Cycle Management

Copyright © 2009, Oracle. All rights reserved.


Course Roadmap

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.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 3 - 2


Objectives

After completing this lesson, you should be able to:


• 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

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 3 - 3


Define Service Life-Cycle Management

• 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
Service
development Infrastructure and
life-cycle
and management
delivery management
management

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 3 - 4


Phases of Service Life Cycle

Automation

Design Build Publish Deploy Manage Consume Retire

Copyright © 2009, Oracle. All rights reserved.

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 organization’s 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.

Oracle SOA Suite 11g: Essential Concepts 3 - 5


The Need for Service Life-Cycle Management

• 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.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 3 - 6


Define SOA Governance

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
organization’s Service-Oriented Architecture
Policies
(what)

Decisions Processes
(who) (how)

Copyright © 2009, Oracle. All rights reserved.

Define SOA Governance


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 organization’s 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 company’s 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.

Oracle SOA Suite 11g: Essential Concepts 3 - 7


Relationship of Governance Disciplines

Corporate governance

Supports Supports

Aligns
IT governance EA governance

Extends Extends

SOA governance

Copyright © 2009, Oracle. All rights reserved.

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
company’s standards, policies, and business strategies specifically focused on the life cycle of
services, policies, practices, metadata, and composite applications.

Oracle SOA Suite 11g: Essential Concepts 3 - 8


The Need for SOA Governance

• Business value
• Alignment
• Business agility
• Risk reduction
• Cost savings

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 3 - 9


Benefits of SOA Governance

• Ensures an application’s 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 3 - 10


Center of Excellence: Key to SOA Success

• 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.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 3 - 11


Example of Governance Organizational Structure

Business Governance
Steering Committee

CoE Governance Leadership Team

Initiative Initiative
Team Team

Project Project
Team Team

Copyright © 2009, Oracle. All rights reserved.

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 over-
arching 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.

Oracle SOA Suite 11g: Essential Concepts 3 - 12


Quiz

SOA governance is an extension of ___________ and ______.


1. IT governance
2. Security
3. EA governance
4. Discipline

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 3 - 13


Service Life-Cycle Governance

• Service life-cycle governance complements an enterprise’s


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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 3 - 14


Service Life-Cycle Governance

Service
Build
definition Deploy
Requirements, and compose
and design and secure
identification,
and discovery

Publish
and provision

Operate
and manage
Evaluate
and evolve

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 3 - 15


Service Management

• 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 3 - 16


Service Portfolio

Organizationa Business service

Consumer1
Service directory
Servicea Serviceb Servicec

Connectivity service
Organizationb

Consumer2 Service1 Service2 Service3

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 3 - 17


Policy Manager

Business service

Service directory
Servicea Serviceb Servicec

Connectivity service

Policy manager Service1 Service2 Service3

Service1
policy

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 3 - 18


Service Routing

Service manager
Connectivity
service Client

Orchestration
service Client
Security
SLA
Availability

Copyright © 2009, Oracle. All rights reserved.

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 run-
time phase, is a key enabler in service routing.

Oracle SOA Suite 11g: Essential Concepts 3 - 19


Service Versioning

Business service

Service directory
Servicea.2 Serviceb.2 Servicec.2

Connectivity service

Service policy Service1.2 Service2.2 Service3.2


directory

Service1
policy

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 3 - 20


SLA Management

• 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.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 3 - 21


Quiz

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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 3 - 22


Constituents of SOA Governance Model

SOA governance

SOA solution
SOA portfolio Service life-cycle SOA organization SOA vitality
life-cycle
governance governance governance governance
governance

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 3 - 23


Constituents of SOA Governance Model (continued)
SOA Life-Cycle Governance and SOA Solution Life-Cycle Governance
The SOA life-cycle governance complements an enterprise’s 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.

Oracle SOA Suite 11g: Essential Concepts 3 - 24


End-to-End SOA Governance

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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 3 - 25


End-to-End SOA Governance: SOA Asset
Management

SOA asset management • Manages SOA assets


and associated metadata
• Provides run-time
reference for bindings
and policies

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 3 - 26


End-to-End SOA Governance: Policy Management
and Enforcement

SOA asset management


• Offers centralized
management of policy
artifacts for versioning
and change control
Policy management and
• Ensures policy
enforcement compliance throughout
the life cycle

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 3 - 27


End-to-End SOA Governance: Consumer
Management

SOA asset management

• Provides structure
Policy management and contract between service
consumer and provider
enforcement • Enforces contracts via
business, SLA, and
security policies
Consumer management

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 3 - 28


End-to-End SOA Governance: SOA Monitoring
and Management

SOA asset management

Policy management and


enforcement
• Provides central
management of
Consumer management distributed and
heterogeneous SOA
• Tracks enforcement of
SOA monitoring and service contracts and
quality of service
management

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 3 - 29


SOA Governance Solution

The SOA governance solution must address the following


areas of an enterprise:
• Performance management
• Value delivery
• Strategic alignment
• Risk management
• Resource management

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 3 - 30


Oracle SOA Governance Solution

JDeveloper

Oracle
Oracle SOA Governance Suite BPEL
Service Process
Bus Manager

Enterprise
Repository

EM SOA Web
Metadata
Management Services
exchange
Pack Manager

Service Registry

UDDI integration

Copyright © 2009, Oracle. All rights reserved.

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 Suite 11g: Essential Concepts 3 - 31


Quiz

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

Copyright © 2009, Oracle. All rights reserved.

Answer: 1

Oracle SOA Suite 11g: Essential Concepts 3 - 32


Summary

In this lesson, you should have learned how to:


• 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 3 - 33


Practice 3 Overview:
Defining Policies for a Group of Services
This practice comprises paper-based questions covering
service life-cycle management and SOA governance.

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 3 - 34


Designing Services for SOA Implementations

Copyright © 2009, Oracle. All rights reserved.


Course Roadmap

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.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 2


Objectives

After completing this lesson, you should be able to:


• 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

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 4 - 3


Defining Services

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

Copyright © 2009, Oracle. All rights reserved.

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 client-
generated 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.
Oracle SOA Suite 11g: Essential Concepts 4 - 4
Services Are SOA Building Blocks

Client

XML messages (defined by an XSD) WSDL

Interactions

Service
Service
WSDL

Service

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 5


Service Contract

• 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 6


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.

Oracle SOA Suite 11g: Essential Concepts 4 - 7


Service Design

• 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 8


Service Granularity

• 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.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 9


Service Design Principles

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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 10


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.

Oracle SOA Suite 11g: Essential Concepts 4 - 11


Designing Coarse-Grained Interfaces

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 Components Web Services

Fine-grained Coarse-grained
interfaces interfaces

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 12


Quiz

The service contract describes:


1. Service functionality
2. Service-level agreements (SLAs)
3. Service non-functional requirements
4. Web services policy

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 13


Service Classifications

Services can be broadly classified into:


• Connectivity services
• Data services
• Business services
• Business process services
• Presentation services
• Infrastructure services

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 14


Connectivity Services

Characteristics:
• Fine-grained
• No business logic or
aggregation

Shared services
• 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

Copyright © 2009, Oracle. All rights reserved.

Connectivity Services
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.

Oracle SOA Suite 11g: Essential Concepts 4 - 15


Data Services

Characteristics:
• Fine-grained or course-grained
• No business logic

Shared services
• Aggregation and
transformation
• High reuse Data
Logical data model Data aggregation Data synchronization
services
• Stateless
• Configurable
Messaging Adapters Custom APIs JDBC
Non-service enabled assets

Legacy Packaged Database Partners Content

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 16


Business Services

Characteristics:
• Course-grained
• Task-oriented

Shared services
• Business
logic content Business Enrichment
Custom business Atomic business
services services services
• Simple or
complex operations
• Medium level of
reuse Messaging Adapters Custom APIs JDBC
Non-service enabled assets
• Usually stateless

Legacy Packaged Database Partners Content

Copyright © 2009, Oracle. All rights reserved.

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.”

Oracle SOA Suite 11g: Essential Concepts 4 - 17


Business Process Services

Characteristics:
• Course-grained
• Process-oriented

Shared services
Business process System-centric Human-centric
• Short or long running services workflow workflow
processes
• Lower level of reuse
• Can be stateless or
stateful
Messaging Adapters Custom APIs JDBC
Non-service enabled assets

Legacy Packaged Database Partners Content

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 18


Presentation Services

Characteristics:
• Course-grained
• Process-oriented Presentation Shared portlets Multichannel delivery
services

Shared services
• Short or long running
processes
• Lower level of reuse
• Can be stateless or
stateful
Messaging Adapters Custom APIs JDBC
Non-service enabled assets

Legacy Packaged Database Partners Content

Copyright © 2009, Oracle. All rights reserved.

Presentation Services
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).

Oracle SOA Suite 11g: Essential Concepts 4 - 19


Service Infrastructure

Service
Presentation services
Shared services registry

Service
Business process services
repository

Service Bus
Business services Security

Data services Monitor/


event manager

Connectivity services Infrastructure


services

Messaging Adapters Custom APIs JDBC


Non-service enabled assets

Legacy Packaged Database Partners Content

Copyright © 2009, Oracle. All rights reserved.

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.
Oracle SOA Suite 11g: Essential Concepts 4 - 20
Quiz

Business process automation is an example of services


orchestration.
1. True
2. False

Copyright © 2009, Oracle. All rights reserved.

Answer: 1
Explanation: Business Process automation is an example of services orchestration. Orchestration
involves the preservation of the state and several physical transactions.

Oracle SOA Suite 11g: Essential Concepts 4 - 21


Basic Service Interaction Patterns

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.

Copyright © 2009, Oracle. All rights reserved.

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 two-
way 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.

Oracle SOA Suite 11g: Essential Concepts 4 - 22


Synchronous Interactions

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

Client Service
Synchronous
Request

Response

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 23


Asynchronous 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

Client Service
Asynchronous Request

Immediate callback/response Long


processing
Optional polling Optional callback/response tasks
for response

Copyright © 2009, Oracle. All rights reserved.

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 trading—limit 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.

Oracle SOA Suite 11g: Essential Concepts 4 - 24


Choosing Service Implementation Styles

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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 25


Choosing Service Implementation Styles

Atomic service

Composite service

Service cluster

Copyright © 2009, Oracle. All rights reserved.

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.
Oracle SOA Suite 11g: Essential Concepts 4 - 26
Fundamentals for Creating a Service

• 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.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 27


Building a Portfolio of Services

• 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 28


Describing 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 called Web services

Request

Response
Application Web service

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 4 - 29


Web Service Standards

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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 30


Web Service Architecture

Find WSIL Locate


browser

Find Register
3 (UDDI) 2 (UDDI)

Generate
Web services 1 WSDL.
directory
4 Invoke request (SOAP).
Internet Interface
(WSDL)
5 Send response Service
Web service (SOAP). implementation
client application
Web service

Copyright © 2009, Oracle. All rights reserved.

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.
Oracle SOA Suite 11g: Essential Concepts 4 - 31
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.

Oracle SOA Suite 11g: Essential Concepts 4 - 32


Service Artifacts

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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 33


XML Schema Definitions

XML schema:
• Is an XML language that defines and validates
the structure of XML documents
Validates
• Is stored in an XSD document Defines
XSD
• Defines elements and types, such as: types
– Simple type definitions
– Complex type definitions
– Element declarations WSDL References
– Attribute declarations Instance
• Supports XML namespaces and built-in, simple, and
complex data types
• Is used to define message types in WSDL documents

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 34


Defining Messages in XML Schemas

Input
type

Output
type

Copyright © 2009, Oracle. All rights reserved.

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 options—insert before
element, insert inside element, or insert after element—and 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 elements—valid and error—are 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.

Oracle SOA Suite 11g: Essential Concepts 4 - 35


Web Services Description Language

• A WSDL document is an XML


document that describes: WSDL document
– What the service does
Types
– How the service is accessed
– Where the service is located Messages
• It defines the messages and
the operations of a service Port types
abstractly in XML.
Bindings
Described by

Services

Service interface

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 4 - 36


WSDL Model
XML Elements
Definition attributes
targetNamespace

Type Message PortType Binding Service


name name name name
type

Schema Part Operation SOAPBinding Port


name name style name
transport binding

Input
message
Address
Element
Output location
name message
type

What How Where

Copyright © 2009, Oracle. All rights reserved.

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 operation’s 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.

Oracle SOA Suite 11g: Essential Concepts 4 - 37


Defining Service Interfaces in WSDL

WSDL interface
operations and messages

WSDL components that you


can drag and drop in the
WSDL editor to create the
WSDL document

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 38


Quiz

Asynchronous operations can be a one-way or a two-way


interaction pattern.
1. True
2. False

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 39


Adapter Services

Adapters integrate with existing back-end applications through


Java EE Connector Architecture standards.
Oracle SOA Suite
SCA composite
SOAP External
JCA Adapter
(SOAP)
reference
reference
Client

JMS SOAP JCA Other


Bindings
Service infrastructure
Web service
EIS/DBMS

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 40


Describing Technology Adapters

JDeveloper
Adapter Wizard
JCA Adapters
Technology Adapters

Files/FTP
Java EE
Application
JMS/AQ

Database JCA BPEL

Oracle
Applications Mediator

Socket
Oracle WebLogic
Server

Copyright © 2009, Oracle. All rights reserved.

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.
Oracle SOA Suite 11g: Essential Concepts 4 - 41
Packaged Application and Legacy Adapters

Adapter Application Oracle Studio Oracle Connect


Explorer
Mainframe/Legacy
Packaged Adapters
JCA Adapters
Siebel

SAP
BSE BPEL
SOAP
PeopleSoft Mediator
J.D.Edwards

Legacy Adapters BPEL


JCA
VSAM
Mediator
IMS DB/TM

CICS
Java EE
Application
Tuxedo
Oracle WebLogic Server

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 42


Quiz

WSDL port describes the interfaces exposed by a


• Web server
• Web service
• Web browser
• None of these

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 43


Summary

In this lesson, you should have learned how to:


• 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 4 - 44


Practice 4: Overview
Designing Services for SOA Implementations
This practice covers the following topics:
• Modifying an XSD in JDeveloper
• Modifying a WSDL in JDeveloper

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 4 - 45


Creating a Composite Application

Copyright © 2009, Oracle. All rights reserved.


Course Roadmap

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 run-
time unit.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 5 - 2


Objectives

After completing this lesson, you should be able to:


• Explain the Service Component Architecture (SCA) and its
components
• Define a composite application
• Discuss components of the SCA
• Describe Service Data Objects (SDO)
• Create an SOA composite application in JDeveloper

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 5 - 3


Service Component Architecture

• Intention: Simplify the creation and integration of business


applications that conform to the principles of Service-
Oriented 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 5 - 4


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.

Copyright © 2009, Oracle. All rights reserved.

Service Component Architecture (SCA) (continued)


SCA provides a programming model for building applications and systems based on a Service-
Oriented 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.
Oracle SOA Suite 11g: Essential Concepts 5 - 5
Components and Composites

Domain

Composite 2

Composite 1 Component Component Composite 3


X Y

Wire Wire Wire

Service Reference

Implementation

BPEL Java Others

Copyright © 2009, Oracle. All rights reserved.

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 component’s 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 components—these 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.
Oracle SOA Suite 11g: Essential Concepts 5 - 6
SCA Components

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 Service components:
BPEL Process
Mediator
Property
Human Task
Business Rules
Component
Interface Component Creates its source file
and a .componentType
file in the composite
Implementation project
BPEL, Java composite
References

Copyright © 2009, Oracle. All rights reserved.

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 work—for 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.

Oracle SOA Suite 11g: Essential Concepts 5 - 7


SCA Composite

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
<component> element (external services)
Service (entry point) element <reference>
<service> element element
Composite
<property>

NewOrder ProcessOrder
Service Reference
Mediator BPEL
Binding Binding
<interface.wsdl> Wire <interface.wsdl>
<wire> <component>
element element
element element <binding.ws> element
<binding.ws> element

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 5 - 8


SCA Bindings

Domain 1
Default binding
Composite W Composite Y

Composite X

Explicit Explicit Domain 2


Non-SCA binding binding
application Composite Z

Copyright © 2009, Oracle. All rights reserved.

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 component’s 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.

Oracle SOA Suite 11g: Essential Concepts 5 - 9


SCA Policy Framework

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

Copyright © 2009, Oracle. All rights reserved.

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.
Oracle SOA Suite 11g: Essential Concepts 5 - 10
Quiz

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

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 5 - 11


Service Data Objects (SDO)

• 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 Data access
service
RMI / IIOP
Application EJB

XQuery / XPath
XML DB

Copyright © 2009, Oracle. All rights reserved.

Service Data Objects (SDO)


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 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.
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.

Oracle SOA Suite 11g: Essential Concepts 5 - 12


SDO Data Architecture

Data graph Data object

Read / Update
Database

Read / Update
Web service
Data access
service
Read / Update
Application EJB
client

Read / Update
XML DB

Change
summary

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 5 - 13


SCA and SDO

Application SCA
client
Composite SDO
B
Database
SDO Composite
A
Composite SDO
Web browser
C
Web service

Mobile devices

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 5 - 14


Creating an SOA Composite in JDeveloper 11g

Copyright © 2009, Oracle. All rights reserved.

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.
Oracle SOA Suite 11g: Essential Concepts 5 - 15
Describing the SOA Composite Editor

Components are building


blocks that are wired together
Services are
to assemble the application.
entry points to
the composite
that advertise
capabilities to References
the outside enable the
world. composite to
communicate
with the
outside world.

The Source tab shows the XML


source.

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 5 - 16


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.

Oracle SOA Suite 11g: Essential Concepts 5 - 17


Creating Exposed Services

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
Creates a service interface
creating a
BPEL process.
(entry point)

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 5 - 18


Creating SOA Components

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.

Copyright © 2009, Oracle. All rights reserved.

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 service—that 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.

Oracle SOA Suite 11g: Essential Concepts 5 - 19


Examining the SCA Descriptor

<?xml version="1.0" encoding="UTF-8" ?>


<!-- Generated by Oracle SOA Modeler version 1.0 at ... -->
<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>

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 5 - 20


Quiz

SDO provides a metadata API, which allows applications, tools,


and frameworks to introspect the data model for a data graph.
1. True
2. False

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 5 - 21


Adding a Mediator Component

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

Copyright © 2009, Oracle. All rights reserved.

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
interface—that 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.

Oracle SOA Suite 11g: Essential Concepts 5 - 22


Adding a BPEL Process 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

Copyright © 2009, Oracle. All rights reserved.

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 composite’s exposed service entry point with the interface of the BPEL component.

Oracle SOA Suite 11g: Essential Concepts 5 - 23


Comparing BPEL and Mediator

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 Usually for short, fast message routing.
processes 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

Copyright © 2009, Oracle. All rights reserved.

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 integrator’s experience
with these technologies.

Oracle SOA Suite 11g: Essential Concepts 5 - 24


Examining the JDeveloper Workspace, Projects,
and File Structure
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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 5 - 25


Editing a Component in a Composite

Editing existing service components:


• Modifies the component source and can modify
composite.xml—for 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
Source code is
To edit a Component opened in a visual
component, double- editor and is typically
click its icon. stored in XML format.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 5 - 26


Creating External References

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
Services will come from a
2 service registry.

4
1

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 5 - 27


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 Interface

Create a reference.

Copyright © 2009, Oracle. All rights reserved.

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-to-
end composite implementation example.

Oracle SOA Suite 11g: Essential Concepts 5 - 28


Creating Wires Modifies Connected Elements

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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 5 - 29


Exposing Components as an External Service

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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 5 - 30


Quiz

What is the file extension of the Mediator component


implementation file in JDeveloper 11g?
1. .componentType
2. .bpel
3. .mplan
4. .decs

Copyright © 2009, Oracle. All rights reserved.

Answer: 3
The .componentType file extension is referenced by the SCA descriptor and the .bpel file
extension for the BPEL process implementation

Oracle SOA Suite 11g: Essential Concepts 5 - 31


Deploying an SOA Composite Application

2
3

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 5 - 32


Summary

In this lesson, you should have learned how to:


• Explain the Service Component Architecture (SCA) and its
components
• Define a composite application
• Discuss components of the SCA
• Describe Service Data Objects (SDO)
• Create an SOA composite application in JDeveloper

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 5 - 33


Practice 5: Overview
Creating an SOA Composite Application
This practice covers the following topics:
• 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

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 5 - 34


Managing and Monitoring SOA Composite
Applications

Copyright © 2009, Oracle. All rights reserved.


Course Roadmap

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.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 6 - 2


Objectives

After completing this lesson, you should be able to:


• 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

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 6 - 3


Overview of Managing SOA Applications

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.

Copyright © 2009, Oracle. All rights reserved.

Overview of Managing SOA Applications


The Fusion Middleware Control is a Web browser–based 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

Oracle SOA Suite 11g: Essential Concepts 6 - 4


Managing with Oracle Enterprise Manager

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.

Copyright © 2009, Oracle. All rights reserved.

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
composite application
• Examining and managing application fault conditions
• Monitoring component engines

Oracle SOA Suite 11g: Essential Concepts 6 - 5


Oracle Enterprise Manager
Fusion Middleware Control
SOA server status
Application
deployment summary

Hierarchical
navigation bar SOA server
with access to components
SOA Suite
components

Deployed composite
applications

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 6 - 6


Accessing the SOA Infrastructure Home Page

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

Copyright © 2009, Oracle. All rights reserved.

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 application’s
progress or to view what happened in a completed application. Clicking one of the composite
links accesses the composite application’s 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.

Oracle SOA Suite 11g: Essential Concepts 6 - 7


Accessing a Composite Application Home Page

In the Fusion Middleware Console, click the “composite


application [version]” link under the SOA > “soa-infra” node.

Farm navigation bar


composite application
links

Deployments
composite application
links

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 6 - 8


Example Composite Application Home Page

Recent Instances

Faults and Rejected


Messages

Component Metrics

Services and References

Copyright © 2009, Oracle. All rights reserved.

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.
Oracle SOA Suite 11g: Essential Concepts 6 - 9
Deploying a Composite Application

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
SOA project Middleware
Server
SOA archive (SAR)

Fusion Middleware
Deployment profile Control

Copyright © 2009, Oracle. All rights reserved.

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).

Oracle SOA Suite 11g: Essential Concepts 6 - 10


Deploying SOA Composite Applications

1 2

Copyright © 2009, Oracle. All rights reserved.

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 “soa-
server1” 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.

Oracle SOA Suite 11g: Essential Concepts 6 - 11


Initiating an SOA Composite Application Test
Instance

Copyright © 2009, Oracle. All rights reserved.

Initiating an SOA Composite Application Test Instance


To test a Web service by using the Oracle Enterprise Manager 11g Fusion Middleware Control
console, execute the following steps:
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.

Oracle SOA Suite 11g: Essential Concepts 6 - 12


Tracking Message Flow

Invocation in Tree
view mode

Click Launch Message


Flow Trace to view the
message flow through a 2
composite application.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 6 - 13


Working with the Flow Trace

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.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 6 - 14


Working with the Component Audit Trail Page

Locator links

Faults (if any)


1

Activity details

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 6 - 15


Quiz

The Flow Trace represents a ___________ view of the


message flow.
1. Tree
2. XML

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 6 - 16


Managing the State of Deployed SOA Composite
Applications
View deployed applications

Manage deployed applications

Copyright © 2009, Oracle. All rights reserved.

Managing the State of Deployed SOA Composite Applications


The Dashboard tabbed page displays information—such as the recent instances of the application, the
faults, the rejected messages, and the policies—for 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).

Oracle SOA Suite 11g: Essential Concepts 6 - 17


Monitoring and Deleting Specific SOA Composite
Application Instances

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 6 - 18


Recovering from SOA Composite Application
Faults

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 6 - 19


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.
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.

Oracle SOA Suite 11g: Essential Concepts 6 - 20


Undeploying a Composite Application

2
1

Copyright © 2009, Oracle. All rights reserved.

Undeploying a Composite Application


To undeploy an application by using the Oracle Enterprise Manager 11g Fusion Middleware Control
console, execute the following steps:
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.

Oracle SOA Suite 11g: Essential Concepts 6 - 21


Quiz

After you undeploy an SOA composite application revision, you


can no longer configure and monitor this revision of the
composite application.
1. True
2. False

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 6 - 22


Summary

In this lesson, you should have learned how to:


• 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 6 - 23


Practice 6: Overview
Managing and Monitoring Composite
Applications
This practice covers the following topics:
• Initiating an instance of the composite application using the
EM console
• Viewing the composite instance information and exploring
the SOA Console interface and environment

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 6 - 24


Working with Mediator Components

Copyright © 2009, Oracle. All rights reserved.


Course Roadmap

SOA

The “Working with the Mediator Components” lesson introduces Mediator


component and routing functionality, and how to create and configure a
Mediator component.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 7 - 2


Objectives

After completing this lesson, you should be able to:


• 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

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 7 - 3


Introducing Oracle Mediator

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.

Copyright © 2009, Oracle. All rights reserved.

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.
Oracle SOA Suite 11g: Essential Concepts 7 - 4
Oracle Enterprise Service Bus and Mediator

Oracle SOA Suite 10g Oracle SOA Suite 11g

Oracle Enterprise
Service Bus Mediator
(OESB)10g

Service Infrastructure

OESB 10g Mediator


Is implemented in a separate ESB run- Is an SCA component implemented as a
time container part of the common service infrastructure
Is incorporated as an ESB service Is incorporated as a part of an SOA
composite application
Is supported on Oracle SOA Suite 10g Is supported on Oracle SOA Suite 11g

Copyright © 2009, Oracle. All rights reserved.

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 SOA Suite 11g: Essential Concepts 7 - 5


Oracle Mediator Features

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

Copyright © 2009, Oracle. All rights reserved.

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 SOA Suite 11g: Essential Concepts 7 - 6


Event Delivery Network

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
New composite
customer application

Event published as XML Subscribes to


described by an XSD receive an event

Copyright © 2009, Oracle. All rights reserved.

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 SOA’s request-response and EDA’s event publish-
subscribe paradigms.

Oracle SOA Suite 11g: Essential Concepts 7 - 7


Introducing Business Events

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

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 7 - 8


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 SOA Suite 11g: Essential Concepts 7 - 9


Event Handling

Oracle Mediator provides support for subscribing to or raising


business events.

Reply
received

Event
raised

Email confirmation sent


New Customer Creates new profile to customer

Copyright © 2009, Oracle. All rights reserved.

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 occurs—for example, raise a customer-
created event after completing the customer-creation process.

Oracle SOA Suite 11g: Essential Concepts 7 - 10


Content-Based and Header-Based Routing

Oracle Mediator provides support for setting rules based on the


message payload or message headers.

Reply
received

France
Data store
Event
raised

Customer updates Correct data store is


Routing rule:
profile with new updated.
What country?
address.

Copyright © 2009, Oracle. All rights reserved.

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 customer’s 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.

Oracle SOA Suite 11g: Essential Concepts 7 - 11


Synchronous/Asynchronous Interactions

Oracle Mediator provides support for synchronous as well as


asynchronous request response interaction.

Tracking data
based on
postal code

Customer
places
order.

Validate Order
credit card. fulfilled

Synchronous
Asynchronous

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 7 - 12


Service Virtualization

Oracle Mediator provides support for service virtualization


allowing you to separate a service from its physical
implementation.
Mediator service exposed
Initial implementation
through composite WSDL Composite
Mediator
Service BPEL
(exposed)

Client SOAP
The same Mediator service exposed service
through composite WSDL: this means that Modified implementation
the client implementation is not affected.
Composite
Mediator Other
Service (exposed) composite

Client JCA adapter

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 7 - 13


Validations

Oracle Mediator provides support for validating the incoming


message payload using a schematron or XSD file.

Validate Result

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 7 - 14


Error Handling

Oracle Mediator provides support for fault policy–based error


handling.

Error condition Action to Process


raised correct continues

Copyright © 2009, Oracle. All rights reserved.

Error Handling
Oracle Mediator supports fault policy–based error handling. A fault policy consists of conditions
and actions. Conditions specifies the action to be carried out for a particular error condition.

Oracle SOA Suite 11g: Essential Concepts 7 - 15


Transformations

Oracle Mediator supports data transformation from one XML


schema to another.

XSL
Input XML processor Output XML
document document

XSL
Mapper

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 7 - 16


Quiz

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

Copyright © 2009, Oracle. All rights reserved.

Answers: 1, 2, 4
Explanation
Oracle Mediator includes the following features:
• Event handling
• Content-based and header-based routing
• Synchronous/asynchronous interactions
• Service virtualization
• Validations
• Transformations
• Error handling

Oracle SOA Suite 11g: Essential Concepts 7 - 17


Creating an Oracle Mediator Component

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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 7 - 18


Mediator Component Creation Options

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

Copyright © 2009, Oracle. All rights reserved.

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 one-
way 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.

Oracle SOA Suite 11g: Essential Concepts 7 - 19


Define Interface Later

Mediator editor
window

Double-click the
Mediator component at
a later time, when you
are ready, to define the
service.

Copyright © 2009, Oracle. All rights reserved.

Define Interface Later


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.

Oracle SOA Suite 11g: Essential Concepts 7 - 20


Define Interface Later

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 3

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 7 - 21


Viewing the Mediator Source Code

View the Source code for the Mediator component from the
Source tabbed page.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 7 - 22


Modifying a Mediator Component

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.

Copyright © 2009, Oracle. All rights reserved.

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.
3. Save your changes.
Note: You cannot change the name of the Mediator component.

Oracle SOA Suite 11g: Essential Concepts 7 - 23


Deleting 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.

Copyright © 2009, Oracle. All rights reserved.

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.
4. Save your changes.
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.

Oracle SOA Suite 11g: Essential Concepts 7 - 24


Specifying Mediator Component Routing Rules

Routing rules enable you to route data between service


providers and service consumers, applying transformations and
filters as required.

Service Service
consumer provider
Routing rules

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 7 - 25


Introducing 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

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 7 - 26


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

Oracle SOA Suite 11g: Essential Concepts 7 - 27


Accessing Mediator Routing Rules

Double-click the Mediator component to create new or modify


existing routing rules.

Double-click the
Mediator component.

Expand Routing Rules to adjust properties.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 7 - 28


Defining Mediator Routing Rules

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 7 - 29


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.

Oracle SOA Suite 11g: Essential Concepts 7 - 30


Specifying a Target Service: Example

Routing rule for a


single target service
invocation

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 7 - 31


Adding a Transformation to a Mediator
Component
Transformations in Mediator are implemented via routing rules.
The XSLT Mapper tool enables correlation of source schema
elements with target schema elements.

2
XSLT Mapper tool
Source Destination

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 7 - 32


Filtering Messages

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 7 - 33


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.
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.

Oracle SOA Suite 11g: Essential Concepts 7 - 34


Specifying Sequential or Parallel Execution

Sequential:

Message Routing rule #1 Routing rule #2 Routing rule #3 Outcome

Parallel:

Routing rule #1
Message Routing rule #2 Outcome

Routing rule #3

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 7 - 35


Quiz

Routing rules can be used to filter messages based on their


payload.
1. True
2. False

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 7 - 36


When to Use Business Events?
When to Invoke a Service?
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.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 7 - 37


Summary

In this lesson, you should have learned how to:


• 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 7 - 38


Practice 7: Overview
Creating a Mediator Service Component
This practice covers the following topics:
• Creating a Mediator service component in an SOA
composite
• Defining routing rules by using the Mediator component
• Deploying and testing the SOA composite

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 7 - 39


Orchestrating Services with a BPEL
Component

Copyright © 2009, Oracle. All rights reserved.


Course Roadmap

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.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 8 - 2


Objectives

After completing this lesson, you should be able to:


• 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

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 8 - 3


Process Orchestration Concepts

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

Process order
Client Business process
expressed in BPEL

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 8 - 4


Introducing Business Process Execution
Language (BPEL)
Credit <variable> Start
10 a.m. BPEL
service <process> process Handle negative
credit exception
<invoke> <faultHandlers>
Get rating

<partnerLink> Send <flow> Send


order order

SM <invoke> RD
service service
<receive>

Receive Receive
quote </flow> quote
<partnerLink> <partnerLink>
<switch> Select
lowest
</process> 3 p.m.
End quote

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 8 - 5


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 peer-
to-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.

Oracle SOA Suite 11g: Essential Concepts 8 - 6


Creating a BPEL Process

2
1

Process
template
types

Copyright © 2009, Oracle. All rights reserved.

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.
Oracle SOA Suite 11g: Essential Concepts 8 - 7
Oracle BPEL Process Designer

1 3 4

2 5 6

Copyright © 2009, Oracle. All rights reserved.

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 SOA Suite 11g: Essential Concepts 8 - 8
Designing the BPEL Process

WSDL interface
for BPEL client

Swim lanes

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 8 - 9


Quiz

A BPEL process coordinates interactions between a process


instance and its partners.
1. True
2. False

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 8 - 10


Developing a BPEL Process

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

Copyright © 2009, Oracle. All rights reserved.

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 long-
running 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.

Oracle SOA Suite 11g: Essential Concepts 8 - 11


BPEL Activity Types

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

Copyright © 2009, Oracle. All rights reserved.

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.
Oracle SOA Suite 11g: Essential Concepts 8 - 12
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.

Oracle SOA Suite 11g: Essential Concepts 8 - 13


Grouping Activities by Using a BPEL Scope

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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 8 - 14


Adding Activities to a Scope

Activities can be added to a scope from:


• The Component palette
• The BPEL diagram

2
1

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 8 - 15


Communicating Data with a BPEL Process

• 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 BPEL <assign>


Defines
process creditCheckVar
XML schema

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 8 - 16


BPEL Variables

• 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


Defined as
Process variable <types>

Scope
WSDL </types>
Data variable
Message type
Defined in

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 8 - 17


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.)

Oracle SOA Suite 11g: Essential Concepts 8 - 18


Choosing Global or Local Variables

• 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
state needed for process life Receive points

Local Nested
Tables in variables scope
BPEL
schema Dehydrate
Wait
Dehydration Store
(Database)

Copyright © 2009, Oracle. All rights reserved.

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.
Oracle SOA Suite 11g: Essential Concepts 8 - 19
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
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 long-
lived.
• 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).

Oracle SOA Suite 11g: Essential Concepts 8 - 20


The Assign Activity

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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 8 - 21


Creating Assign Operations

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 8 - 22


Copying Data from Source to Target

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 8 - 23


Using the XPath Expression Builder

Copyright © 2009, Oracle. All rights reserved.

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.
Oracle SOA Suite 11g: Essential Concepts 8 - 24
Quiz

The Assign activity is used to copy data from a source to a


target in a BPEL process.
1. True
2. False

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 8 - 25


Partner Links and Service Invocation

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

Client Invoke Service


WSDL Client Service WSDL

Partner Links
Service
Service lookup
description
explorer (WSDL)
JDeveloper

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 8 - 26


Partner Links, Partner Link Types, and Roles

• 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
1 WSDL source, which
contains the port types.

Partner links are defined


in the BPEL source.

Copyright © 2009, Oracle. All rights reserved.

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.
Oracle SOA Suite 11g: Essential Concepts 8 - 27
Synchronous Services

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
Both input and output
elements in the operation
BPEL process Service implies that it is
Request synchronous.

Immediate
Invoke response

BPEL process waits Service


for the response. WSDL

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 8 - 28


Synchronous Process Structure: HelloWorld
Example

1 Receive
Request:
<input>Name</input>

Client

2 Assign
Concatenate
Response:
<result>Hello Name</result> "Hello " + Name

3 Reply

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 8 - 29


Asynchronous Service

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 does not Initiate port: An invoked operation with
wait for the response. only an input element implies asynchrony.
BPEL Process

Request
Invoke
Delayed
Response
Service
WSDL
Receive Callback port: Provides asynchronous
response with only an input (operation)

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 8 - 30


Asynchronous BPEL Process Structure

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
2 Invoke

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 8 - 31


Creating a Partner Link

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.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 8 - 32


Configuring a Partner Link

Define
Browse WSDL Files Service Adapter
From Local File System Explorer Service

2
1

3
Roles determine the request and response message structures.
My Role is set for callbacks in an asynchronous interaction.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 8 - 33


Invoking a Synchronous Service

Copyright © 2009, Oracle. All rights reserved.

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
field’s 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.

Oracle SOA Suite 11g: Essential Concepts 8 - 34


Conditionally Branching with a Switch Activity

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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 8 - 35


Adding a Switch Activity

1 Select and
Configure branches,
drag 4 conditions, and activities.

2 Rename

3 Expand

Add one activity.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 8 - 36


Configuring Branches of a Switch Activity

Add Switch Case.


2
Add Switch
Otherwise.

View Condition
Expression

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 8 - 37


Summary

In this lesson, you should have learned how to:


• 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

Copyright © 2009, Oracle. All rights reserved.

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 flow—the Human Task component.

Oracle SOA Suite 11g: Essential Concepts 8 - 38


Practice 8: Overview
Creating a BPEL Service Component
This practice covers the following topics:
• Creating a BPEL service component in an SOA composite
• Wiring the BPEL component and the Mediator component
• Deploying and testing the SOA composite

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 8 - 39


Working with the Human Task Component

Copyright © 2009, Oracle. All rights reserved.


Course Roadmap

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.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 9 - 2


Objectives

After completing this lesson, you should be able to:


• 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

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 9 - 3


What Is a Human Task?

Purchase Approver
order

Approved/ denied Get


3 2
approval

Purchase order > Yes Authorization


1
credit limit?

Approved 4 4 Denied
No

Order Order
approved canceled

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 9 - 4


Human Workflow Diagram
BPEL Process Human Task Service Component Client
Manager Task Definition
Applications
Oracle
BPM
Receive Worklist

Roles and
Assignments
Portals
Invoke
Service Client
Interface Interface
Deadlines and Email &
Create
Escalations RSS
Task
Clients
Human Task
Complete
Task
Presentation Phone and
Other
Notification
Identity Directory Channels
Invoke Invoke (LDAP, for example)

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 9 - 5


Human Workflow Diagram (continued)
The Human Task service component uses an identity directory, such as LDAP, to determine
people’s 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.

Oracle SOA Suite 11g: Essential Concepts 9 - 6


Introduction to Human Workflow Concepts

• 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 9 - 7


Implementing Human Workflow Services

BPEL Task
process Management User Metadata
service service
Portal

Task Assignment
Task
History/Audit
Routing Task Query
service Worklist
Human Task service

Identity Notification Email client


service service

Identity Notification channels


management
Email Wireless
OID, LDAP

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 9 - 8


Exploring Workflow Exchange Patterns

Get
Assign approvals
task
Change
routing
Task
complete All approvals
BPEL BPEL complete
process process
Assign tasks to role or group (from Flow patterns, routing rules
directory)
Escalate List work items
task

Notify
Complete task
manager

Task Get weekly


BPEL resolved productivity report
process
Worklist (tasks, forms, attachments,
Escalation and delegation rules reports)

Copyright © 2009, Oracle. All rights reserved.

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.
Oracle SOA Suite 11g: Essential Concepts 9 - 9
Describing a Workflow as a Service

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.

WSDL
(Contract)
Human
BPEL Task scope
process
TaskService Update
1
(workflow) task
Assign
task
Worklist
2 application
Human Task Complete
task

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 9 - 10


Quiz

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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 9 - 11


Adding a Human Task Component to
an SOA Composite

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 9 - 12


The Human Task Editor

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 9 - 13


Working with Human Workflow in BPEL

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

Copyright © 2009, Oracle. All rights reserved.

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.
Oracle SOA Suite 11g: Essential Concepts 9 - 14
Creating a Human Task in BPEL

Task Service

.task Activities in the


Human Task
2 scope

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 9 - 15


Configuring the Human Task

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 9 - 16


Adding Task Parameters

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

2
Enables user to modify task data in
the Worklist application

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 9 - 17


Setting the Task Parameter Values

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

2
Populated with modified 3
values (if enabled)

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 9 - 18


Generating a Task Form for the Worklist

1 2

Task parameters obtained


from task payload definition

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 9 - 19


Accessing the Worklist Application

• 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.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 9 - 20


Viewing Task Information

After logging into the Worklist application, users can view:


• Task assignments
• Task parameter information

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 9 - 21


Managing Task Assignments

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

Copyright © 2009, Oracle. All rights reserved.

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
user’s 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.

Oracle SOA Suite 11g: Essential Concepts 9 - 22


Summary

In this lesson, you should have learned how to:


• 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 9 - 23


Practice 9: Overview
Creating a Human Task to Approve Orders
This practice covers the following topics:
• Creating a Human Task service component in an SOA
composite
• Accessing the Human Task component from a BPEL
process
• Deploying and testing the SOA composite

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 9 - 24


Implementing a Business Rules Component

Copyright © 2009, Oracle. All rights reserved.


Course Roadmap

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.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 2


Objectives

After completing this lesson, you should be able to:


• 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

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 10 - 3


Introducing Business Rules Technology

• 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 4


Declarative Rule Concepts

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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 5


Rule Inference Concepts

A B
If a customer spends > $1,000, make him or her Premium customer.

B C
If a customer is a Premium customer, offer him or her a 10% discount.

D E
If a customer is a Gold customer, offer him or her a 5% discount.

Customer
Premium Offer 10%
spends
customer discount
$1,500

• Example of inference: A results in B, and B infers C


• Enables powerful and modular declarative assertions

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 6


Reasons for Using Rules Technology

• Agility:
– Rules are easier to change.
– Rules are more responsive.
• Transparency:
– Rules are accessible.
– Rules are consistently applied.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 7


Guidelines for Selecting Rules Use Cases

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

Copyright © 2009, Oracle. All rights reserved.

Guidelines for Selecting Rules Use Cases


The slide lists some of the common use cases for selecting a rules-based approach under those
circumstances.

Oracle SOA Suite 11g: Essential Concepts 10 - 8


Introducing Oracle Business Rules

Components
include:
• Rules engine
• Rule editor JDeveloper Rule Editor
• Rule dictionary Rules SDK
• Rules SDK

Rule dictionary
/** @Foo **/
method
Partner XML Facts Java Facts Rules API Foo(....)
Link {
ADF-BC Facts (JSR 94)
Java
BPEL Rules Engine application

Copyright © 2009, Oracle. All rights reserved.

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 pattern-
matching 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

Oracle SOA Suite 11g: Essential Concepts 10 - 9


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
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.

Oracle SOA Suite 11g: Essential Concepts 10 - 10


Introducing Oracle Business Rules Concepts

• 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

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 10 - 11


Developing a Rule-Enabled Application

Business logic ...


<element
name="customerOrder"
Policy and >
rules <complexType>
<sequence>
Other logic <element name="Name"
Rules Designer
type="string"/>
1 <element
name="CreditScore"
type="int"/> 3
2 ...
Facts, actions 4 to 6

Rules-enabled application
Facts Rules
Results engine

Rules enabled
Application Rule
run-timeapplication
logic dictionary

Copyright © 2009, Oracle. All rights reserved.

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.
Oracle SOA Suite 11g: Essential Concepts 10 - 12
Defining Oracle Business Rules
Development Concepts

Create or import
1

Dictionary

2
3
Globals Facts Rules Designer

Generates
3
Data model using JAXB

4 Ruleset XML schema


Java classes
Rules
5 Define business policies
Rules

Copyright © 2009, Oracle. All rights reserved.

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.
Oracle SOA Suite 11g: Essential Concepts 10 - 13
Quiz

A rule dictionary provides persistent storage for rulesets and


rules.
1. True
2. False

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 14


Creating a Dictionary for Rule Definitions

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 15


Working with the Rules Editor in JDeveloper

The Rules Editor is invoked when you double-click an existing


Business Rule component in the composite designer.

Copyright © 2009, Oracle. All rights reserved.

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

Oracle SOA Suite 11g: Essential Concepts 10 - 16


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.

Oracle SOA Suite 11g: Essential Concepts 10 - 17


Creating XMLFact Entries

1 Add an XML schema.

Either import a new


schema or choose
from already
imported schemas. 2

View the XMLFact


entries.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 18


Working with Bucketsets

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.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 19


Creating a Bucketset

1 2

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 20


Creating Oracle Business Rules Globals

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 21


Creating a Ruleset

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 22


Identifying the Structure of a Rule

Rule name

Rule test condition

Rule action

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 23


Creating a Rule

2
Left-side
<operand>

Click <add property>


to view the Properties
3 4 window

Right-side
<operand>

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 24


Creating a Rule Test

1 4

Copyright © 2009, Oracle. All rights reserved.

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 1–3
for this new test.

Oracle SOA Suite 11g: Essential Concepts 10 - 25


Creating a Rule Action

1 2

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 26


Working with Decision Tables

A decision table:
• Displays a set of if-then rules in a single spreadsheet-
style view
• Contains a collection of related business rules with
condition rows, rules, and actions

Copyright © 2009, Oracle. All rights reserved.

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 applicant’s 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.

Oracle SOA Suite 11g: Essential Concepts 10 - 27


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:
• if driver.age < 20 and driver.has training
then driver.eligible = true
• if driver.age < 20 and driver.has training = false
then driver.eligible = false
• if driver.age >= 20
then driver.eligible = true (do not care about training for this
case)
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.

Oracle SOA Suite 11g: Essential Concepts 10 - 28


Creating Conditions and Rules in Decision Tables

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 29


Creating Conditions and Rules in Decision Tables

5 6

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 30


Creating Actions in Decision Tables

1 2

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 31


Creating Actions in Decision Tables

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 32


Working with Decision Functions

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 Business Policy and


logic process rules
Web Rule
Service dictionary

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 33


Integrating Rules with a BPEL Process

To integrate Oracle Business Rules with BPEL, drag a


Business Rules component to the BPEL flow.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 34


Adding a Business Rule Activity

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 35


Adding a Business Rule Activity

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 36


Adding a Business Rule Activity

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 37


Summary

In this lesson, you should have learned how to:


• 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 10 - 38


Practice 10: Overview
Implementing a Business Rule
This practice covers the following topics:
• Adding a Business Rule service component to the SOA
composite
• Accessing the Business Rule component from the BPEL
process
• Deploying and testing the SOA composite

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 10 - 39


Securing Services and Composite
Applications

Copyright © 2009, Oracle. All rights reserved.


Course Roadmap

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.

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 11 - 2


Objectives

After completing this lesson, you should be able 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

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 11 - 3


Introduction to Web Services Security

Securing Web services is about securing service endpoints and


involves the following:
• Authentication and authorization
• Ensuring message integrity
• Maintaining message confidentiality

Allow (Y/N)?
Authentication:
Authenticate and authorize
Who?

Request Policy
enforcement
point
Response
Endpoint

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 11 - 4


Need for 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 11 - 5


Web Services Security Approaches

The standard ways of 1


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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 11 - 6


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 client’s 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 one’s credit line or
citizenship), as well as authorization decisions about whether subjects are allowed to
access certain resources.

Oracle SOA Suite 11g: Essential Concepts 11 - 7


WS-Security

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

Copyright © 2009, Oracle. All rights reserved.

WS-Security
WS-Security is a standard framework for secure Web services, based on SOAP. With WS-
Security, 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)

Oracle SOA Suite 11g: Essential Concepts 11 - 8


WS-Security Fundamentals

• 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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 11 - 9


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.

Oracle SOA Suite 11g: Essential Concepts 11 - 10


Quiz

Authentication can be incorporated using _____________ .


1. Signature
2. Security tokens
3. Encryption

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 11 - 11


Oracle Web Service Manager

• 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

Copyright © 2009, Oracle. All rights reserved.

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 SOA Suite 11g: Essential Concepts 11 - 12


Components of Oracle Web Services Manager
Architecture
Oracle WSM Agent

Reliable Messaging Management Addressing Security MTOM

Policy Interceptors

Oracle Enterprise Manager


Oracle WSM
Fusion Middleware Control
Policy
Manager
Oracle JDeveloper

Metadata
Store
(MDS)

Oracle
Fusion
Middleware
Database

Copyright © 2009, Oracle. All rights reserved.

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 Manager’s 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

Oracle SOA Suite 11g: Essential Concepts 11 - 13


Oracle Web Services Manager Policy Framework

• 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

Copyright © 2009, Oracle. All rights reserved.

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 SOA Suite 11g: Essential Concepts 11 - 14


Introduction to Policies

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)

Copyright © 2009, Oracle. All rights reserved.

Introduction to Policies
The different type of policies available are as follows:
• WS-ReliableMessaging: Reliable messaging policies that implement the WS-
ReliableMessaging 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 WS-
Addressing headers in conformance with the WS-Addressing specification. Transport-level
data is included in the XML message rather than relying on the network-level transport to
convey this information.
• 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.
Oracle SOA Suite 11g: Essential Concepts 11 - 15
Policy Interceptor Pipeline

Request
Reliable Messaging Management Addressing Security MTOM
Response

Client

Network

MTOM Security Addressing Management Reliable Messaging

Web
Service

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 11 - 16


Policy Assertions

• 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.

Request
Policy
Assertion 1 Assertion 2 Assertion n
Response

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 11 - 17


Quiz

Policies are made up of one or more _____________ .


1. Tokens
2. Protocols
3. Assertions

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 11 - 18


Managing SOA Composite Application Policies

Policies page

Specifying the
component to
which the policy is
to be attached

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 11 - 19


Attaching Security Policy to a Service

Attaching the
policy

Executing the
Validation test

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 11 - 20


Quiz

Policies apply security to the delivery of messages.


1. True
2. False

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 11 - 21


Summary

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

Copyright © 2009, Oracle. All rights reserved.

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.

Oracle SOA Suite 11g: Essential Concepts 11 - 22


Practice 11 Overview:
Attaching Policies to Web Services
This practice covers the following topics:
• 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

Copyright © 2009, Oracle. All rights reserved.

Oracle SOA Suite 11g: Essential Concepts 11 - 23