Documentos de Académico
Documentos de Profesional
Documentos de Cultura
D61580
Edition 1.0
D58786GC10
September 2010
Concepts
Authors Copyright 2009, 2010, Oracle and/or its affiliates. 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
Matthew Slingsby
Vasiliy Strelnikov
Vikas Jain
Glenn Stokol
Pete Laseau
Nagavalli Pataballa
William Prewitt
Editors
Vijayalakshmi Narasimhan
Daniel Milne
Arijit Ghosh
Graphic Designers
Rajiv Chandrabhanu
Satish Bettegowda
Publishers
Giri Venugopal
Michael Sebastian Almeida
Jobi Varghese
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Contents
I Introduction
Course Objectives I-2
Course Agenda: Day 1 I-3
iii
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
iv
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
v
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
vi
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
vii
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
viii
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
ix
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
x
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
xi
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Introduction
Course Objectives
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.
1 2 3 4
5 6 7 8
9 10 11
Summary
Objectives
Business IT
Strategy SOA Strategy
Why SOA?
SOA enables:
Reusability
Business services
Why SOA?
What drives the move to SOA is reuse of business services. Developers within an enterprise and
across enterprises (particularly, in business partnerships) can take the code developed for existing
business applications, expose it as Web services, and then reuse it to meet new business
requirements.
The SOA vision of interaction between clients and loosely coupled services means widespread
interoperability. In other words, the objective is for clients and services to communicate and
understand each other no matter what platform they run on.
Because services in an SOA are loosely coupled, applications that use these services tend to scale
easilycertainly more easily than applications in a more tightly coupled environment. That is
because there are few dependencies between the requesting application and the services it uses,
which typically makes them more flexible than more tightly coupled applications. In a tightly
coupled architecture, the different components of an application are tightly bound to each other,
sharing semantics, libraries, and often sharing state. This makes it difficult to evolve the application
to keep up with changing business requirements. The loosely coupled, document-based,
asynchronous nature of services in an SOA allows applications to be flexible and easy to evolve with
changing requirements.
Enterprise Challenge
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
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
CRM ERP
Application Application
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
Information Governance
Operations, Project,
Administration, and Management Portfolios, and Services
Quiz
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
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
Quiz
Answer: 1
Explanation: The SOA Reference architecture defines the target architecture and the principles to be
used by an organizations architects to make architecture and design decisions on their projects.
A service:
Provides a unit of work as part of a business process
Performs a business function (such as validate credit card)
Request
Response
Mediator
Service
Java .Net Adapter
UDDI Registry Portfolio
Quiz
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
Service Technology
Quiz
Answer: 3
Explanation: The four facets of enterprise architecture that the SOA Governance is centered on are:
Process
Technology
Service
People
These are the deciding factors for designing the SOA Governance Framework.
Summary
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.
Practice 1 Overview:
Preparing the Business Flow Diagram
This practice covers designing a business flow diagram for
purchase order processing
Course Roadmap
SOA
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
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 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
Quiz
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
Monitor
A domain:
Is an administrative unit or boundary
Allows for a single point of administration for a collection of
MyDomain
Server 2
Server 1
Server 3
Machine 1 Machine 2
Administration Server
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.
Managed Server
A managed server:
Is an instance of WebLogic Server
Loads its configuration remotely from an administration
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
Server 2
Server 1
Server 3
Machine 1 Machine 2
Step 3 of 7: Authentication
Step 7 of 7: View
Quiz
Answers: 1, 2, 3
Explanation: The Oracle Enterprise Manager enables the following:
Performing configuration tasks, which consist of setting values to the different properties in the
SOA environment
Monitoring Oracle SOA Suite such as performance of service engine, service infrastructure,
and binding component and Audit trail and process flow behavior in service components
Managing Oracle SOA Suite such as startup and shutdown of the SOA infrastructure
application and recovery from faults in SOA composite applications, service components,
service engines, and business events
Quiz
The Oracle JDeveloper IDE provides design and edit tools that
enable the creation of SOA composite applications.
1. True
Answer: 1
Explanation: JDeveloper provides tools to package and deploy your SOA composite applications as
applications to a target run-time environment.
Summary
Summary
This lesson described the installable components that come as a part of the Oracle SOA Suite 11g,
the different service components, and the role of the Enterprise Manager in performing the basic
administrative tasks related to the SOA environment.
The next lesson shows you how to identify the need for governance in a managing an enterprise
SOA, and explains Oracles SOA Governance solution.
Practice 2 Overview:
Creating Connections in JDeveloper
This practice covers the following topics:
Creating a connection to the Oracle WebLogic Server from
JDeveloper
Course Roadmap
SOA
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.
Objectives
Service
Service
development Infrastructure and
life-cycle
and management
delivery management
management
Automation
Decisions Processes
(who) (how)
Corporate governance
Aligns
IT governance EA governance
Extends Extends
SOA governance
Business value
Alignment
Business agility
Business Governance
Steering Committee
Initiative Initiative
Team Team
Project Project
Team Team
Quiz
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
Operate
and manage
Evaluate
and evolve
Service Management
Service Management
Management is a key ingredient in Service-Oriented Architecture. When enterprises begin to
introduce service interfaces and migrate to SOA, the number of deployed services is small and
management is of less importance. As the number of services grows, it becomes critical to the
success of the SOA initiative to have a management solution in place. Service management
capabilities enable monitoring, controlling, and reporting of service qualities and service usage. Such
service qualities include availability (presence and number of service instances) and performance (for
example, access latency and failure rates), and also accessibility (of endpoints). Facets of service
usage information that may be managed include frequency, duration, scope, functional extent, and
access authorization. Service management needs to have common service semantics that are
understood by both the service consumer as well as the service provider.
Service Portfolio
Consumer1
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.
Policy Manager
Business service
Service directory
Servicea Serviceb Servicec
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 Routing
Service manager
Connectivity
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.
Service Versioning
Business service
Service directory
Servicea.2 Serviceb.2 Servicec.2
Service1
policy
Service Versioning
New service releases should attempt to leverage the same interface when possible. Multiple versions
of a service with differing implementations may be active at any given time. A long-running service
may cross the boundaries of service release cycles. A service policy may bind users to versions of
services.
SLA Management
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.
Quiz
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
JDeveloper
Oracle
Oracle SOA Governance Suite BPEL
Service
Enterprise
Repository
EM SOA Web
Metadata
Management Services
exchange
Pack Manager
Service Registry
UDDI integration
Quiz
Answer: 1
Summary
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.
Practice 3 Overview:
Defining Policies for a Group of Services
This practice comprises paper-based questions covering
service life-cycle management and SOA governance.
Course Roadmap
SOA
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.
Objectives
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:
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
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Client
Interactions
Service
Service
WSDL
Service
Service Contract
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
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
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
Fine-grained Coarse-grained
interfaces interfaces
Quiz
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
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.
Connectivity Services
Characteristics:
Fine-grained
No business logic or
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.
Data Services
Characteristics:
Fine-grained or course-grained
No business logic
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.
Business Services
Characteristics:
Course-grained
Task-oriented
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
Presentation Services
Characteristics:
Course-grained
Process-oriented Presentation Shared portlets Multichannel delivery
services
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 Infrastructure
Service
Presentation services
Shared services registry
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
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Quiz
Answer: 1
Explanation: Business Process automation is an example of services orchestration. Orchestration
involves the preservation of the state and several physical transactions.
Synchronous Interactions
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.
Asynchronous Interactions
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 tradinglimit orders
Travel agent service
Note: Asynchronous interactions can be one-way, such that a response is not returned to the
caller. Asynchronous responses are referred to as a callback. A client may choose to poll for the
asynchronous response. If a client is expecting a response at some point, it will have to wait for
that response.
Atomic service
Service cluster
Request
Response
Application Web service
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
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
Output
type
Services
Service interface
WSDL Model
XML Elements
Definition attributes
targetNamespace
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 operations input and
output parameters. Within a Type, the Schema describes the Messages to be passed
through the interface (as parameters or documents). Messages are data to be exchanged
via the interface Operations (the input and output parameters of the interface). The
PortType is the container for these operations.
How: This section describes the service design and the service invocation pattern.
Where: This section describes the service implementation and the run-time environment.
WSDL interface
operations and messages
Quiz
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
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
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
Quiz
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
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.
Practice 4: Overview
Designing Services for SOA Implementations
This practice covers the following topics:
Modifying an XSD in JDeveloper
Modifying a WSDL in JDeveloper
Course Roadmap
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.
Objectives
Domain
Composite 2
Service Reference
Implementation
SCA Components
A component:
Configures an implementation instance within a composite
Provides services and consumes services (references)
SCA Components
Components hold pieces of a program function within a composite. Components are configured
instances of some implementation, such as BPEL, Java, or other implementation logic. The
implementation code defines the services, references, and properties that are configured by a
component within a composite. More than one component can use the same implementation.
The component interfaces are visible (as WSDL) to internal components to enable them to
interact with each other (and build the assembly model through wires). The interfaces can also
be made visible externally by publishing the component interface in a WSDL form that is shared
with target callers of the composite application
SCA components support implementations of many different technologies, which reflect the
reality of businesses containing mixed systems with different technologies developed over many
years. The flexibility of implementation language enables the selection of technologies better
suited to different types of workfor example, using BPEL for business processes, and Java or
C++ for detailed number crunching.
Each SCA component is identified by a <component> element in the SCA descriptor. The
<component> element identifies the component type and the location of the component
source.
SCA Composite
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.
SCA Bindings
Domain 1
Default binding
Composite W Composite Y
SCA Bindings
Services and references enable a component to communicate with other software. But, it does
not specify how that communication happens. A binding specifies how communication should
be done between an SCA component and any other software component.
A component may not have explicitly specified bindings (depending on what the component is
communicating with). As shown in the slide, a component that communicates with another
component (executing in another process of the same machine or on a different machine) in the
same domain need not have any explicit bindings specified. Instead, what bindings to use are
determined at run time.
To communicate outside its domain (to a non-SCA application or an SCA application running in
some other domain), a components creator (or perhaps the person who deploys the component)
must specify one or more bindings for this communication. Each binding defines a particular
protocol that can be used to communicate with this service or reference. A single service or
reference can have multiple bindings, allowing different software components to communicate
with it.
Quiz
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
Read / Update
Web service
Data access
service
Read / Update
Application EJB
client
Read / Update
XML DB
Change
summary
Application SCA
client
Mobile devices
Recommended
practice:
Deselect this
option while
Creates a service interface
creating a
BPEL process.
(entry point)
Quiz
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
Creating Wires
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.
Quiz
Answer: 3
The .componentType file extension is referenced by the SCA descriptor and the .bpel file
extension for the BPEL process implementation
Summary
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.
Practice 5: Overview
Creating an SOA Composite Application
This practice covers the following topics:
Deploying an SOA composite application to Oracle SOA
Suite 11g
Applications
Course Roadmap
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.
Objectives
Deployed composite
applications
Deployments
composite application
links
Component Metrics
A composite application:
Is deployed as an SOA archive (a SAR file) that includes
all service components in a single application package
Oracle Fusion
SOA project Middleware
Server
SOA archive (SAR)
Fusion Middleware
Deployment profile Control
Click a component to
view an audit trail of
the message flow
within the component.
Locator links
Activity details
Quiz
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
Quiz
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
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.
Practice 6: Overview
Managing and Monitoring Composite
Applications
This practice covers the following topics:
Initiating an instance of the composite application using the
Course Roadmap
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.
Objectives
Oracle Enterprise
Service Bus Mediator
(OESB)10g
New
order Event Delivery
Network
Service
New composite
customer application
Event Handling
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 occursfor example, raise a customer-
created event after completing the customer-creation process.
France
Data store
Event
raised
Synchronous/Asynchronous Interactions
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.
Service Virtualization
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.
Validations
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
Error Handling
Oracle Mediator supports fault policybased error handling. A fault policy consists of conditions
and actions. Conditions specifies the action to be carried out for a particular error condition.
Transformations
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.
Quiz
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
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.
2
XSLT Mapper tool
Source Destination
Filtering Messages
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.
Parallel:
Routing rule #1
Message Routing rule #2 Outcome
Routing rule #3
Quiz
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
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.
Practice 7: Overview
Creating a Mediator Service Component
This practice covers the following topics:
Creating a Mediator service component in an SOA
composite
Component
Course Roadmap
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.
Objectives
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
Process
template
types
2 5 6
Swim lanes
Quiz
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
BPEL Variables
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
inputVariable
Assign outputVariable
XML expression
Quiz
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
Synchronous Services
A synchronous service:
Processes input
Returns an immediate response
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:
Client
2 Assign
Concatenate
Response:
<result>Hello Name</result> "Hello " + Name
3 Reply
Asynchronous Service
Asynchronous services:
Can take time to complete and may not return a response
Are initiated by using a nonblocking Invoke activity
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
3
Roles determine the request and response message structures.
My Role is set for callbacks in an asynchronous interaction.
1 Select and
Configure branches,
2 Rename
3 Expand
View Condition
Expression
Summary
Summary
In this lesson you have learned how to create a BPEL process by using the BPEL Designer.
In the next lesson, you will be introduced to the service component that enables users to interact
in a business flowthe Human Task component.
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
Course Roadmap
SOA
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.
Objectives
Purchase Approver
order
Approved 4 4 Denied
No
Order Order
approved canceled
Task:
Work that needs to be done by a user, role, or group
Participant:
BPEL Task
process Management User Metadata
service service
Portal
Get
Assign approvals
task
Change
routing
Task
Notify
Complete task
manager
Quiz
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 parameters:
Are added in the Parameters section of the .task
Are defined as either simple type or XSD element type
2
Enables user to modify task data in
the Worklist application
2
Populated with modified 3
values (if enabled)
1 2
Summary
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.
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
Course Roadmap
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.
Objectives
A B
If a customer spends > $1,000, make him or her Premium customer.
B C
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.
Components
include:
Rules engine
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-enabled application
Facts Rules
Results engine
Rules enabled
Application Rule
run-timeapplication
logic dictionary
Create or import
1
2
3
Globals Facts Rules Designer
Generates
3
Data model using JAXB
Quiz
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.
Creating a Bucketset
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
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
Creating a Rule
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
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
Summary
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.
Applications
Course Roadmap
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.
Objectives
Allow (Y/N)?
Authentication:
Authenticate and authorize
Who?
Request Policy
enforcement
point
Response
Endpoint
WS-Security
WS-Security:
Is a standard framework for secure Web services, based
on SOAP
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
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.
Quiz
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
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
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Request
Reliable Messaging Management Addressing Security MTOM
Response
Network
Web
Service
Policy Assertions
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.
Quiz
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.
Specifying the
component to
which the policy is
to be attached
Attaching the
policy
Quiz
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
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.
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)