Академический Документы
Профессиональный Документы
Культура Документы
Essential Concepts
D58786GC10
Edition 1.0
August 2009
D61580
Authors Copyright © 2009, Oracle. All rights reserved.
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
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
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
v
Packaged Application and Legacy Adapters 4-42
Quiz 4-43
Summary 4-44
Practice 4: Overview Designing Services for SOA Implementations 4-45
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
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
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
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
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
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.
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
Creating a Composite Managing and Monitoring Working with Mediator Orchestrating Services
Application SOA Composite Components with a BPEL
Applications Component
5 6 7 8
9 10 11
Business IT
Strategy SOA Strategy
SOA enables:
• Reusability
– Business services
• Interoperability
– Loosely coupled services
• Scalability and flexibility
– Coarse-grained
– Document-oriented
– Asynchronous services
• Cost efficiency
– Standards-based approach
Why SOA?
What drives the move to SOA is reuse of business services. Developers within an enterprise and
across enterprises (particularly, in business partnerships) can take the code developed for existing
business applications, expose it as Web services, and then reuse it to meet new business
requirements.
The SOA vision of interaction between clients and loosely coupled services means widespread
interoperability. In other words, the objective is for clients and services to communicate and
understand each other no matter what platform they run on.
Because services in an SOA are loosely coupled, applications that use these services tend to scale
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.
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
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.
«Client Tier»
«VB «Java «Web
Application» Application» Application»
Standard-based interfaces
Standard-based Interfaces Standard-based
Standard-basedinterfaces
Interfaces
CRM ERP
Application Application
Verify Customer
Check Customer Address
Credit Card
Setup
Conduct Account
Setup Fraud
Account Check
Benefits
Cost
Reusability Interoperability Scalability
Efficiency
Channels
Service
Bus
Business Process Layer (BPM, Workflow) Mediation
Business Service
Functionality-oriented Process-oriented
Object-oriented Message-oriented
Infrastructure Organization
Information Governance
Operations, Project,
Administration, and Management Portfolios, and Services
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
Best Practices
Current Reality
SOA reference
architecture should
include definitions,
Determine IT drivers. standards, rules,
principles, and
guidelines, and
architecture views.
Delivery Channels
Infrastructure
Connectivity Services System/Data Access Messaging Partner Integration Services
Delivery Channels
Infrastructure
Connectivity Services System/Data Access Messaging Partner Integration Services
Infrastructure
Connectivity Services System/Data Access Messaging Partner Integration Services
Business
Process
Calculate Shopping Cart Import Order
Services
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
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.
• 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
Mediator
Service
Java .Net Adapter
UDDI Registry Portfolio
Answer: 1
Explanation: Services can be implemented using existing functionality by exposing existing
functionality as services or by using adapters.
Decisions Processes
(Who) (How)
• Business value
• Alignment
• Business agility
• Risk reduction
• Cost savings
Service Technology
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.
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.
SOA
In this “Implementing SOA with Oracle SOA Suite" lesson, you will be
introduced to the installable components that come as a part of Oracle SOA
Suite 11g, the different service components, and the role of Enterprise Manager
in performing the basic administrative tasks related to the SOA environment.
Course Roadmap
In the “Service-Oriented Architecture Concepts” lesson you were familiarized with the 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.
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.
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
Message
Mediator
Event
Route
Transformation
Filter
Enforcement
point policies SOAP
Service JCA
infrastructure Other (adapters)
UDDI bindings
registry
Metadata
store
Mediator component
created in the SOA
composite application
Editor
BPEL Process
component created in
the SOA composite
application Editor
Business Rules
component created in
the SOA composite
application Editor
Human Task
component created in
the SOA composite
application Editor
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.
Other
Technologies
Oracle DB Real-time dashboard reports
repository
Sensor
Monitor
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
Runs the
Admin console
LOGS
Configuration
Administration repository
Critical domain (config.xml)
notifications server
(logs)
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.
A managed server:
• Is an instance of WebLogic Server
• Loads its configuration remotely from an administration
server
MyDomain
Managed server
Managed server
Administration
server
Managed server
Managed Server
A managed server is a single server that boots on a remote, or perhaps the same, physical machine
and loads its configuration from a specified administration server. Managed servers get all of their
configuration information from the remote administration server and need only know the domain and
server they represent in a domain.
• 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
SOA Composite
Editor
Step 2 of 7: Type
Step 3 of 7: Authentication
Step 6 of 7: Completion
Step 7 of 7: View
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
The Oracle JDeveloper IDE provides design and edit tools that
enable the creation of SOA composite applications.
1. True
2. False
Answer: 1
Explanation: JDeveloper provides tools to package and deploy your SOA composite applications as
applications to a target run-time environment.
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.
SOA
In this “SOA Governance and Service Life-Cycle Management” lesson, the need
for governance in a Service-Oriented Architecture environment is highlighted.
The different characteristics related to service management are also introduced.
Course Roadmap
In the “Implementing SOA with Oracle SOA Suite” lesson you were familiarized with Oracle SOA
Suite 11g architecture and the various service components.
The “SOA Governance and Service Life-Cycle Management” lesson, the need of governance in a
Service-Oriented Architecture environment is highlighted.
Service
Service
development Infrastructure and
life-cycle
and management
delivery management
management
Automation
Decisions Processes
(who) (how)
Corporate governance
Supports Supports
Aligns
IT governance EA governance
Extends Extends
SOA governance
• Business value
• Alignment
• Business agility
• Risk reduction
• Cost savings
Business Governance
Steering Committee
Initiative Initiative
Team Team
Project Project
Team Team
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.
Service
Build
definition Deploy
Requirements, and compose
and design and secure
identification,
and discovery
Publish
and provision
Operate
and manage
Evaluate
and evolve
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.
Consumer1
Service directory
Servicea Serviceb Servicec
Connectivity service
Organizationb
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.
Business service
Service directory
Servicea Serviceb Servicec
Connectivity service
Service1
policy
Policy Manager
Service policies specifies:
• Authentication
• Authorization
• Encryption
• Message level security
The policy directory is generally platform-independent and integrates with the existing security
infrastructure. Management solutions that manage security policies must be integrated with the
security infrastructure so that policies can be propagated to the point of enforcement.
Service manager
Connectivity
service Client
Orchestration
service Client
Security
SLA
Availability
Service Routing
Service management is not limited to directory-based requests. It also provides routing services
through the service manager. Routing involves the mediation of service request between the service
consumer (client) and the service provider.
Oracle Service Bus (a stand-alone service bus) that plays an integral part in the service life-cycle run-
time phase, is a key enabler in service routing.
Business service
Service directory
Servicea.2 Serviceb.2 Servicec.2
Connectivity service
Service1
policy
Service Versioning
New service releases should attempt to leverage the same interface when possible. Multiple versions
of a service with differing implementations may be active at any given time. A long-running service
may cross the boundaries of service release cycles. A service policy may bind users to versions of
services.
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.
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.
SOA governance
SOA solution
SOA portfolio Service life-cycle SOA organization SOA vitality
life-cycle
governance governance governance governance
governance
• Provides structure
Policy management and contract between service
consumer and provider
enforcement • Enforces contracts via
business, SLA, and
security policies
Consumer management
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
Answer: 1
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.
SOA
In the “Designing Services for SOA Implementation” lesson, you are introduced
to the concepts that enable defining and implementing a service. This is an
important aspect of designing an SOA system, because you can map
appropriate business functionality to the appropriate service type.
Course Roadmap
In the “SOA Governance and Service Life-Cycle Management” lesson, the need of governance
in a Service-Oriented Architecture environment was highlighted.
The “Designing Services for SOA Implementation” lesson introduces the various service
artifacts and service classification.
A service:
• Provides a unit of work as part of a business process
• Is a software component that is made up of the following:
– Contract
– Interface
– Implementation:
— Business logic
— Data
Defining Services
Services are software component building blocks of distinctive functional meaning and
granularity that encapsulate a concept. Services consist of several parts.
A service contract provides abstraction and independence of technology between the service
consumer and the service producer. It can describe detailed semantics on the functionality and
parameters of the service. The contract is essentially a set of metadata on a higher level than the
service interface.
The service interface, such as Web Services Description Language (WSDL) or Interface
Definition Language (IDL), exposes the functionality of the service to its clients. It is linked to
the metadata-driven contract, but has a physical implementation such as WSDL-based 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
Interactions
Service
Service
WSDL
Service
Service Contract
The service contract document is a specification that describes the behavior of the service, its
functional and non-functional requirements, and constraints. The following should be a part of
the service contract document:
• Service name: Specifies the unique name for the service defined by the contract.
• Status: Indicates the current state of the service contract. States include In Progress,
Defined (the service contract has been completed), and Operational (the service has been
deployed into production).
• Scope: Defines the relevant area within the enterprise for which the service is applicable.
• Category: Indicates the type of service defined by this contract. The set of values for the
category of services is customizable to the enterprise.
• Usage terms: Describe any usage restriction for the service as well as conditions for use.
For example, this field may specify that the service may only be used by consumers from a
particular line of business (LOB) between 7 PM and 5 AM.
• Description: Provides a high-level description covering the purpose for the service,
business value, objectives, and a high-level description of the function(s) provided by the
service.
• Functional Requirements: Provide a detailed list of functional requirements for the
service.
Service Design
Service design begins with the service contract and proceeds with the consumer and reuse in
mind. When completed, the service design and interface represent the outputs from the process.
Service design differs significantly from traditional application design. The focus is not on how
the service is constructed, but how the consumers access and interact with the service. The
implementation behind a service may change several times without impacting the service design,
which is highly unlikely in the case of an application. When a service design is changed, the
impacts are typically significantly larger than in the application case.
Service 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.
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
Fine-grained Coarse-grained
interfaces interfaces
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.
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.
Characteristics:
• Fine-grained
• No business logic or
aggregation
Shared services
• High reuse
• Stateless
Connectivity System access Messaging Data access Partner integration
services
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.
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
Data Services
The data services layer contains the services that provide access to data obtained by the data
sources. Access can be in the form of read and write capabilities (all create, read, update, and
delete functions). It may contain processing logic required to handle more complex write
operations. For example, an update may involve data sources that only support asynchronous
write operations. Also, error handling logic may be required if a data source is not available
when a request occurs.
Because this service class is responsible for decoupling data consumers from data providers, the
upstream consumers can legitimately assume a standardized information model and request data
without the need for knowledge of the underlying data sources.
After the data services are isolated, the architectural principles, such as “Data is owned by the
enterprise,” are better supported, enabling accountability and stewardship across the enterprise.
Characteristics:
• 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
Business Services
As the enterprise begins to standardize and encapsulate the functionality of enterprise
information systems in services, opportunities begin to emerge to apply the same kinds of
concepts to core, discrete business functionality that is not necessarily tied to a given
information system. This functionality might include business functions, such as rating and
billing, inventory availability, and employee scheduling. This functionality is fine-grained and
would benefit the enterprise by being available in a standard way for use by people and
applications. In many respects, this is the simplest form of integration need for the enterprises.
Accordingly, this functionality meets the definition of a service and is classified as the shared
business services layer. This classification supports the common architectural principle for
“creating a clear and distinct separation between the way data and legacy systems are accessed
and the way they are processed.”
Characteristics:
• 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
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
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).
Service
Presentation services
Shared services registry
Service
Business process services
repository
Service Bus
Business services Security
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
Answer: 1
Explanation: Business Process automation is an example of services orchestration. Orchestration
involves the preservation of the state and several physical transactions.
Client Service
Synchronous
Request
Response
Synchronous Interactions
Synchronous designs are traditionally simpler to understand and implement.
With remote invocations, synchronous systems are vulnerable to network interruptions if the
operation execution is lengthy. That is, a network interruption can abort an otherwise successful
(and expensive) operation.
From a scalability perspective, synchronous designs demand that the service execute the
operations immediately. Consequently, during peak demand, the service may not provide
enough availability for all clients.
Client Service
Asynchronous Request
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.
Atomic service
Composite service
Service cluster
Request
Response
Application Web service
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
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.
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
Input
type
Output
type
Services
Service interface
Input
message
Address
Element
Output location
name message
type
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.
WSDL interface
operations and messages
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.
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.
JDeveloper
Adapter Wizard
JCA Adapters
Technology Adapters
Files/FTP
Java EE
Application
JMS/AQ
Oracle
Applications Mediator
Socket
Oracle WebLogic
Server
SAP
BSE BPEL
SOAP
PeopleSoft Mediator
J.D.Edwards
CICS
Java EE
Application
Tuxedo
Oracle WebLogic Server
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.
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.
SOA
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.
Domain
Composite 2
Service Reference
Implementation
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
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.
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
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.
Domain 1
Default binding
Composite W Composite Y
Composite X
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.
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
XML / HTTP
Web service
SDO Data access
service
RMI / IIOP
Application EJB
XQuery / XPath
XML DB
Read / Update
Database
Read / Update
Web service
Data access
service
Read / Update
Application EJB
client
Read / Update
XML DB
Change
summary
Application SCA
client
Composite SDO
B
Database
SDO Composite
A
Composite SDO
Web browser
C
Web service
Mobile devices
Recommended
practice:
Deselect this
option while
Creates a service interface
creating a
BPEL process.
(entry point)
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.
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
4
1
Create a reference.
Creating Wires
Creating wires in the Composite Editor:
• Defines the interactions between service entry points, components, and references
• Represents connections between SCA elements, such as:
- An exposed service wired to a component interface
- A component wired to an external reference
- A component wired to another component interface
• Connects a reference icon with a compatible service interface defined by an internal
component, or external reference
Note: Wires can also be created when you are creating links to services within component
implementations.
The slide shows an example of an exposed service wired to a BPEL component, whose Create
Reference icon is dragged to the File Adapter external reference interface to wire them together.
The BPEL Process component is already wired to a Mediator component, completing an end-to-
end composite implementation example.
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
Answer: 3
The .componentType file extension is referenced by the SCA descriptor and the .bpel file
extension for the BPEL process implementation
2
3
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.
SOA
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.
Hierarchical
navigation bar SOA server
with access to components
SOA Suite
components
Deployed composite
applications
Deployments
composite application
links
Recent Instances
Component Metrics
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
1 2
Invocation in Tree
view mode
Click a component to
view an audit trail of
the message flow
within the component.
Locator links
Activity details
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.
2
1
Answer: 1
Explanation: Once you undeploy the selected composite application revision you can no longer
configure and monitor this revision of the composite application.
Summary
In this lesson you have identified the basic administrative tasks that can be performed by using the
Enterprise Manager Web interface.
In the next couple of lessons you will be using the Enterprise Manager console to deploy your
composite application. You will also be introduced to the different service components such as the
Mediator, BPEL, Human Task, and Business Rule. The functionality of these components will also
be dealt with in detail.
SOA
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 Enterprise
Service Bus Mediator
(OESB)10g
Service Infrastructure
New
order Event Delivery
Network
Service
New composite
customer application
Reply
received
Event
raised
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.
Reply
received
France
Data store
Event
raised
Tracking data
based on
postal code
Customer
places
order.
Validate Order
credit card. fulfilled
Synchronous
Asynchronous
Synchronous/Asynchronous Interactions
Oracle Mediator provides support for synchronous as well as asynchronous request response
interactions. In a synchronous interaction, the client requests a service and then waits for a
response to the request. In an asynchronous interaction, the client invokes the service but does
not wait for the response before continuing. The response may come at a later time, or not at all.
You can specify a timeout period for an asynchronous interaction, which can be used to perform
some action such as raise an event or initiate a process.
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
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.
Validate Result
Validations
Oracle Mediator provides support for validating the incoming message payload by using a
schematron or an XSD file. You can specify schematron files for each inbound message part and
Oracle Mediator can execute schematron validations for those parts.
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.
XSL
Input XML processor Output XML
document document
XSL
Mapper
Transformations
Oracle Mediator supports data transformation from one XML schema to another. This enables
data interchange among applications using different schemas. For example, the initial XML
schema may have last name and first name as separate values. The other XML schema may have
the full name (both first and last) stored as one value. Through transformations, you can
concatenate the first and last name from the initial schema before it reaches the resultant XML
document.
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
Mediator editor
window
Double-click the
Mediator component at
a later time, when you
are ready, to define the
service.
1 3
View the Source code for the Mediator component from the
Source tabbed page.
Service Service
consumer provider
Routing rules
Double-click the
Mediator component.
2
XSLT Mapper tool
Source Destination
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.
Sequential:
Parallel:
Routing rule #1
Message Routing rule #2 Outcome
Routing rule #3
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.
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.
SOA
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.
Check credit
Process order
Client Business process
expressed in BPEL
SM <invoke> RD
service service
<receive>
Receive Receive
quote </flow> quote
<partnerLink> <partnerLink>
<switch> Select
lowest
</process> 3 p.m.
End quote
2
1
Process
template
types
1 3 4
2 5 6
WSDL interface
for BPEL client
Swim lanes
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
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
2
1
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
Local Nested
Tables in variables scope
BPEL
schema Dehydrate
Wait
Dehydration Store
(Database)
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)
inputVariable
Assign outputVariable
XML expression
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
Partner Links
Service
Service lookup
description
explorer (WSDL)
JDeveloper
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
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.
1 Receive
Request:
<input>Name</input>
Client
2 Assign
Concatenate
Response:
<result>Hello Name</result> "Hello " + Name
3 Reply
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)
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
1 Receive
Long-running
process
Client
2 Invoke
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.
1 Select and
Configure branches,
drag 4 conditions, and activities.
2 Rename
3 Expand
View Condition
Expression
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.
SOA
The “Working with the Human Task Component” lesson introduces the Human
workflow task and related concepts. You will also learn how to create a Human
Task component in an SOA composite and access it from a BPEL process.
Course Roadmap
The “Orchestrating Services with a BPEL Component” lesson introduced process orchestration
concepts and using the BPEL component.
The “Working with the Human Task Component” lesson introduces the Human Workflow task
component and its functionality.
Purchase Approver
order
Approved 4 4 Denied
No
Order Order
approved canceled
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)
• 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
BPEL Task
process Management User Metadata
service service
Portal
Task Assignment
Task
History/Audit
Routing Task Query
service Worklist
Human Task service
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
WSDL
(Contract)
Human
BPEL Task scope
process
TaskService Update
1
(workflow) task
Assign
task
Worklist
2 application
Human Task Complete
task
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.
Task Service
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
2
Populated with modified 3
values (if enabled)
1 2
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.
SOA
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.
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
• Agility:
– Rules are easier to change.
– Rules are more responsive.
• Transparency:
– Rules are accessible.
– Rules are consistently applied.
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
• 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
Rules-enabled application
Facts Rules
Results engine
Rules enabled
Application Rule
run-timeapplication
logic dictionary
Create or import
1
Dictionary
2
3
Globals Facts Rules Designer
Generates
3
Data model using JAXB
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.
1 2
Creating a Bucketset
To create a bucketset, execute the following steps:
1. In the Rules Designer, select the Bucketsets navigation tab. Click the Create Bucketset
icon, and select “List of Ranges.”
2. Double-click the bucket icon for the bucket. The Edit Bucketset dialog box opens.
3. In the Edit Bucketset dialog box, enter the bucketset name and select the appropriate data
type. Click the Add Bucket icon repeatedly to add the number of buckets you need in the
bucketset.
Creating a 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.
Rule name
Rule action
2
Left-side
<operand>
Right-side
<operand>
Creating a Rule
Rules define your business policies. For example, manual approval is required for orders with an
amount greater than $1,000; otherwise, the order should be automatically approved. Having
created the order facts and the ruleset for the rules, you can now create the manual order
approval business rule by performing the following steps:
1. Click the ruleset that you want to work with, and then click the green plus (+) icon for that
ruleset (shown in the slide).
2. A new rule is created. Change the name of the rule by clicking the existing name to enter
edit mode.
3. The IF area displays the rule pattern tests. At run time, when this rule is processed, the
Rules Engine checks the facts against rule pattern tests that you define to find matching
facts. The IF area of a rule includes a left-side <operand> and a right-side <operand>.
The left-side <operand> enables you to select the fact. The right-side <operand>
enables you to select the value to match with the fact for pattern test matching in the rule.
4. The THEN area displays the action associated with a pattern test match in a rule. At run
time, when the IF portion of a rule matches, the Rules Engine activates the THEN portion
and prepares to run the action. For example, in OrderApprovalRule, when the
Order.price fact matches (equals or exceeds $1000), the Rules Engine asserts that a
manual approval is required.
1 4
1 2
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
5 6
1 2
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
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.
SOA
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.
Allow (Y/N)?
Authentication:
Authenticate and authorize
Who?
Request Policy
enforcement
point
Response
Endpoint
WS-Security:
• Is a standard framework for secure Web services, based
on SOAP
• Is intended to specify a flexible set of mechanisms that can
be used to construct a range of security protocols
• Provides quality of protection through message integrity
and message confidentiality
• Provides a general-purpose mechanism for associating
security tokens with messages
WS-Security
WS-Security is a standard framework for secure Web services, based on SOAP. With 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)
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.
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.
Policy Interceptors
Metadata
Store
(MDS)
Oracle
Fusion
Middleware
Database
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
Web
Service
Request
Policy
Assertion 1 Assertion 2 Assertion n
Response
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.
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.
Policies page
Specifying the
component to
which the policy is
to be attached
Attaching the
policy
Executing the
Validation test
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.
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.