SOA Suite 11g Essential Concepts - Volume 1

8/16/2019 SOA Suite 11g Essential Concepts - Volume 1

1/403

Oracle SOA Suite 11g : Essential

Concepts

Volume I - Student Guide

D58786GC10

Edition 1.0

September 2010

D61580


2/403

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

Disclaimer

This document contains proprietary information and is protected by copyright and

other intellectual property laws. You may copy and print this document solely for your

own use in an Oracle training course. The document may not be modified or altered in

any way. Except where your use constitutes "fair use" under copyright law, you may

not use, share, download, upload, copy, print, display, perform, reproduce, publish,

license, post, transmit, or distribute this document in whole or in part without the

express authorization of Oracle.

The information contained in this document is subject to change without notice. If you

find any problems in the document, please report them in writing to: Oracle University,

500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not

warranted to be error-free.

Restricted Rights Notice

If this documentation is delivered to the United States Government or anyone using

the documentation on behalf of the United States Government, the following notice is

applicable:

U.S. GOVERNMENT RIGHTS

The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or

disclose these training materials are restricted by the terms of the applicable Oracle

license agreement and/or the applicable U.S. Government contract.

Trademark Notice

Oracle and Java are registered trademarks of Oracle Corporation and/or its affiliates.

Other names may be trademarks of their respective owners.

Authors

Bijoy Choudhury

Swarnapriya Shridhar

Technical Contributors

and Reviewers

Cathy Lippert

Dave Berry

Holger Dindler Rasmussen

Heidi Buelow

Demed L'Her

Prasen Palvankar

Tom Hardy

David Shaffer

James MillsJai Kasi

Magnus Kling

Mathias Kullberg

Matthew Slingsby

Vasiliy Strelnikov

Vikas Jain

Glenn Stokol

Pete Laseau

Nagavalli Pataballa

William Prewitt

Editors

Vijayalakshmi Narasimhan

Daniel Milne

Arijit Ghosh

Graphic Designers

Rajiv ChandrabhanuSatish Bettegowda

Publishers

Giri Venugopal

Michael Sebastian Almeida

Jobi Varghese


3/403

iii

Contents

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

1 Service-Oriented Architecture ConceptsCourse Road Map 1-2Objectives 1-3Definition: Service-Oriented Architecture (SOA) 1-4Why SOA? 1-5

Enterprise Challenge 1-7Point-to-Point Integration 1-8Enterprise Application Integration 1-9Example of Application-Centric Integration 1-10Integrating Solutions and Benefits with SOA 1-11SOA Further Defined 1-12Moving Toward Service-Centric Integration 1-13SOA: A Paradigm Shift 1-14The Eight-Domain Model Approach for SOA 1-15Quiz 1-17Building an SOA Reference Architecture: From Architecture Drivers to a Roadmap 1-18SOA Reference Architecture 1-19

SOA Reference Architecture: Service Consumers 1-21SOA Reference Architecture: Service Classification 1-22SOA Reference Architecture: Service Providers 1-23Reference Architecture: Example 1-24Standards That Enable SOA 1-25Quiz 1-27Service and Web Service 1-28Types of Service Access and Implementation 1-29Ways to Integrate Services 1-30Designing with an SOA Approach 1-31Creating Service Portfolios 1-32SOA Workflow and Orchestration 1-33

Implementing SOA: General Concepts 1-34Quiz 1-35Define SOA Governance 1-36Identifying the Need of SOA Governance 1-37SOA Governance Framework 1-38Quiz 1-39Course Practice Scenario: Purchase Order Processing 1-40Summary 1-41Practice 1 Overview: Preparing the Business Flow Diagram 1-42


4/403

iv

2 Implementing SOA with Oracle SOA Suite

Course Roadmap 2-2Objectives 2-3Basic Components of an SOA Infrastructure 2-4Oracle SOA Suite 11g Components 2-5

Introduction to Service Infrastructure 2-7Introducing SCA in Oracle SOA Suite 11g 2-8Defining a Composite Application 2-9Introducing Oracle Mediator Component 2-11Describing the Features of Oracle Mediator Component 2-12Introducing Oracle BPEL Process Component 2-13Introducing Business Rules Component 2-14Introducing Human Task Component 2-15Quiz 2-16Introduction to Business Activity Monitoring 2-17Monitoring Services with BPEL and BAM 2-18Oracle Enterprise Manager 2-19

Oracle WebLogic Server 10.3 2-21WebLogic Server Domain 2-22WebLogic Server Servers 2-24 Administration Server 2-25Managed Server 2-26WebLogic Server Machines 2-27SOA Development with Oracle JDeveloper 2-28Creating Connections in Oracle JDeveloper 2-29Creating an Application Server Connection in Oracle JDeveloper 2-31Goals of Implementing SOA Application with Oracle SOA Suite 11g 2-33Quiz 2-34Summary 2-36

Practice 2 Overview: Creating Connections in JDeveloper 2-37

3 SOA Governance and ServiceLife-Cycle Management Course Roadmap 3-2Objectives 3-3Define Service Life-Cycle Management 3-4Phases of Service Life Cycle 3-5The Need for Service Life-Cycle Management 3-6Define SOA Governance 3-7Relationship of Governance Disciplines 3-8The Need for SOA Governance 3-9Benefits of SOA Governance 3-10

Center of Excellence: Key to SOA Success 3-11Example of Governance Organizational Structure 3-12Quiz 3-13Service Life-Cycle Governance 3-14Service Management 3-16Service Portfolio 3-17Policy Manager 3-18Service Routing 3-19Service Versioning 3-20


5/403

v

SLA Management 3-21Quiz 3-22Constituents of SOA Governance Model 3-23End-to-End SOA Governance 3-25End-to-End SOA Governance: SOA Asset Management 3-26End-to-End SOA Governance: Policy Management and Enforcement 3-27

End-to-End SOA Governance: Consumer Management 3-28End-to-End SOA Governance: SOA Monitoring and Management 3-29SOA Governance Solution 3-30Oracle SOA Governance Solution 3-31Quiz 3-32Summary 3-33Practice 3 Overview: Defining Policies for a Group of Services 3-34

4 Designing Services for SOA ImplementationsCourse Roadmap 4-2Objectives 4-3Defining Services 4-4

Services Are SOA Building Blocks 4-5Service Contract 4-6Service Design 4-8Service Granularity 4-9Service Design Principles 4-10Designing Coarse-Grained Interfaces 4-12Quiz 4-13Service Classifications 4-14Connectivity Services 4-15Data Services 4-16Business Services 4-17Business Process Services 4-18

Presentation Services 4-19Service Infrastructure 4-20Quiz 4-21Basic Service Interaction Patterns 4-22Synchronous Interactions 4-23 Asynchronous Interactions 4-24Choosing Service Implementation Styles 4-25Fundamentals for Creating a Service 4-27Building a Portfolio of Services 4-28Describing a Web Service 4-29Web Service Standards 4-30Web Service Architecture 4-31

Service Artifacts 4-33XML Schema Definitions 4-34Defining Messages in XML Schemas 4-35Web Services Description Language 4-36WSDL Model 4-37Defining Service Interfaces in WSDL 4-38Quiz 4-39 Adapter Services 4-40Describing Technology Adapters 4-41


6/403

vi

Packaged Application and Legacy Adapters 4-42Quiz 4-43Summary 4-44Practice 4: Overview Designing Services for SOA Implementations 4-45

5 Creating a Composite Application

Course Roadmap 5-2Objectives 5-3Service Component Architecture 5-4Components and Composites 5-6SCA Components 5-7SCA Composite 5-8SCA Bindings 5-9SCA Policy Framework 5-10Quiz 5-11Service Data Objects (SDO) 5-12SDO Data Architecture 5-13SCA and SDO 5-14

Creating an SOA Composite in JDeveloper 11g 5-15Describing the SOA Composite Editor 5-16Creating Exposed Services 5-18Creating SOA Components 5-19Examining the SCA Descriptor 5-20Quiz 5-21 Adding a Mediator Component 5-22 Adding a BPEL Process Component 5-23Comparing BPEL and Mediator 5-24Examining the JDeveloper Workspace, Projects, and File Structure 5-25Editing a Component in a Composite 5-26Creating External References 5-27

Creating Wires 5-28Creating Wires Modifies Connected Elements 5-29Exposing Components as an External Service 5-30Quiz 5-31Deploying an SOA Composite Application 5-32Summary 5-33Practice 5: Overview Creating an SOA Composite Application 5-34

6 Managing and Monitoring SOA Composite ApplicationsCourse Roadmap 6-2Objectives 6-3Overview of Managing SOA Applications 6-4

Managing with Oracle Enterprise Manager 6-5Oracle Enterprise Manager Fusion Middleware Control 6-6 Accessing the SOA Infrastructure Home Page 6-7 Accessing a Composite Application Home Page 6-8Example Composite Application Home Page 6-9Deploying a Composite Application 6-10Deploying SOA Composite Applications 6-11Initiating an SOA Composite Application Test Instance 6-12Tracking Message Flow 6-13


7/403

vii

Working with the Flow Trace 6-14Working with the Component Audit Trail Page 6-15Quiz 6-16Managing the State of Deployed SOA Composite Applications 6-17Monitoring and Deleting Specific SOA Composite Application Instances 6-18Recovering from SOA Composite Application Faults 6-19

Undeploying a Composite Application 6-21Quiz 6-22Summary 6-23Practice 6: Overview Managing and Monitoring Composite Applications 6-24

7 Working with Mediator ComponentsCourse Roadmap 7-2Objectives 7-3Introducing Oracle Mediator 7-4Oracle Enterprise Service Bus and Mediator 7-5Oracle Mediator Features 7-6Event Delivery Network 7-7

Introducing Business Events 7-8Event Handling 7-10Content-Based and Header-Based Routing 7-11Synchronous/Asynchronous Interactions 7-12Service Virtualization 7-13Validations 7-14Error Handling 7-15Transformations 7-16Quiz 7-17Creating an Oracle Mediator Component 7-18Mediator Component Creation Options 7-19Define Interface Later 7-20

Viewing the Mediator Source Code 7-22Modifying a Mediator Component 7-23Deleting a Mediator Component 7-24Specifying Mediator Component Routing Rules 7-25Introducing Routing Rules 7-26 Accessing Mediator Routing Rules 7-28Defining Mediator Routing Rules 7-29Specifying a Target Service: Example 7-31 Adding a Transformation to a Mediator Component 7-32Filtering Messages 7-33Specifying Sequential or Parallel Execution 7-35Quiz 7-36

When to Use Business Events? When to Invoke a Service? 7-37Summary 7-38Practice 7: Overview Creating a Mediator Service Component 7-39


8/403

viii

8 Orchestrating Services with a BPEL ComponentCourse Roadmap 8-2Objectives 8-3Process Orchestration Concepts 8-4Introducing Business Process Execution Language (BPEL) 8-5Creating a BPEL Process 8-7

Oracle BPEL Process Designer 8-8Designing the BPEL Process 8-9Quiz 8-10Developing a BPEL Process 8-11BPEL Activity Types 8-12Grouping Activities by Using a BPEL Scope 8-14 Adding Activities to a Scope 8-15Communicating Data with a BPEL Process 8-16BPEL Variables 8-17Choosing Global or Local Variables 8-19The Assign Activity 8-21Creating Assign Operations 8-22

Copying Data from Source to Target 8-23Using the XPath Expression Builder 8-24Quiz 8-25Partner Links and Service Invocation 8-26Partner Links, Partner Link Types, and Roles 8-27Synchronous Services 8-28Synchronous Process Structure: HelloWorld Example 8-29 Asynchronous Service 8-30 Asynchronous BPEL Process Structure 8-31Creating a Partner Link 8-32Configuring a Partner Link 8-33Invoking a Synchronous Service 8-34

Conditionally Branching with a Switch Activity 8-35 Adding a Switch Activity 8-36Configuring Branches of a Switch Activity 8-37Summary 8-38Practice 8: Overview Creating a BPEL Service Component 8-39

9 Working with the Human Task ComponentCourse Roadmap 9-2Objectives 9-3What Is a Human Task? 9-4Human Workflow Diagram 9-5Introduction to Human Workflow Concepts 9-7

Implementing Human Workflow Services 9-8Exploring Workflow Exchange Patterns 9-9Describing a Workflow as a Service 9-10Quiz 9-11 Adding a Human Task Component to an SOA Composite 9-12The Human Task Editor 9-13Working with Human Workflow in BPEL 9-14Creating a Human Task in BPEL 9-15Configuring the Human Task 9-16


9/403

ix

Adding Task Parameters 9-17Setting the Task Parameter Values 9-18Generating a Task Form for the Worklist 9-19 Accessing the Worklist Application 9-20Viewing Task Information 9-21Managing Task Assignments 9-22

Summary 9-23Practice 9: Overview Creating a Human Task to Approve Orders 9-24

10 Implementing a Business Rules ComponentCourse Roadmap 10-2Objectives 10-3Introducing Business Rules Technology 10-4Declarative Rule Concepts 10-5Rule Inference Concepts 10-6Reasons for Using Rules Technology 10-7Guidelines for Selecting Rules Use Cases 10-8Introducing Oracle Business Rules 10-9

Introducing Oracle Business Rules Concepts 10-11Developing a Rule-Enabled Application 10-12Defining Oracle Business Rules Development Concepts 10-13Quiz 10-14Creating a Dictionary for Rule Definitions 10-15Working with the Rules Editor in JDeveloper 10-16Creating XMLFact Entries 10-18Working with Bucketsets 10-19Creating a Bucketset 10-20Creating Oracle Business Rules Globals 10-21Creating a Ruleset 10-22Identifying the Structure of a Rule 10-23

Creating a Rule 10-24Creating a Rule Test 10-25Creating a Rule Action 10-26Working with Decision Tables 10-27Creating Conditions and Rules in Decision Tables 10-29Creating Actions in Decision Tables 10-31Working with Decision Functions 10-33Integrating Rules with a BPEL Process 10-34 Adding a Business Rule Activity 10-35Summary 10-38Practice 10: Overview Implementing a Business Rule 10-39

11 Securing Services and Composite ApplicationsCourse Roadmap 11-2Objectives 11-3Introduction to Web Services Security 11-4Need for Web Services Security 11-5Web Services Security Approaches 11-6WS-Security 11-8WS-Security Fundamentals 11-9Quiz 11-11


10/403

x

Oracle Web Service Manager 11-12Components of Oracle Web Services Manager Architecture 11-13Oracle Web Services Manager Policy Framework 11-14Introduction to Policies 11-15Policy Interceptor Pipeline 11-16Policy Assertions 11-17

Quiz 11-18Managing SOA Composite Application Policies 11-19 Attaching Security Policy to a Service 11-20Quiz 11-21Summary 11-22Practice 11 Overview: Attaching Policies to Web Services 11-23

Appendix A: Practices and Solutions

Appendix B: Introduction to LinuxWhat Is Linux? B-2What Is Oracle’s Strategy for Linux? B-3

File System and Basic Directory Structure B-4Shell Commands B-6Environment-Based Commands B-7Information-Based Commands B-9File System Commands B-11Common vi Editing Commands B-13Common FTP Communication Commands B-15 Archive Utilities B-17Shortcuts and Tips B-19

Appendix C: Perform Common Tasks with Oracle JDeveloperObjectives C-2

Create a Database Connection C-3Create an Application Server Connection C-4Create an Application C-6Create an Empty Project C-8Create an SOA Project C-9Create a Project from Existing Sources C-10Deploy an SOA Composite Application C-13Summary C-15

Appendix D: SOA Adoption Planning PrinciplesObjectives D-2SOA Adoption D-3

SOA Adoption Planning Activities D-4SOA Adoption Planning Activities: Completing the Stakeholder Community D-5SOA Adoption Planning Activities: Moving Through the Change Curve D-6SOA Adoption Planning Activities: Establishing "Line-of-Sight" Goals D-7SOA Adoption Planning Activities: Establish a Milestone Delivery Plan D-8SOA Adoption Planning Activities: Usage of Metrics D-9SOA Adoption Planning Activities: Enabling Business Innovation D-10SOA Adoption Planning Activities: Usage of Tools and Processes D-11The Need for an SOA Reference Architecture D-12


11/403

xi

Developing the SOA Reference Architecture D-13Developing the SOA Reference Architecture: Align IT with Business D-14Developing the SOA Reference Architecture: Develop a Baseline D-15Developing the SOA Reference Architecture: Create SOA Reference Architecture D-16Developing the SOA Reference Architecture: Create SOA Infrastructure Roadmap D-17SOA Governance Model D-18

Example of an SOA Governance Model D-19Summary D-20

Glossary


12/403


13/403

Copyright © 2009, Oracle. All rights reserved.

Introduction


14/403Oracle SOA Suite 11g : Essential Concepts I - 2


Course Objectives

After completing this course, you should be able to:

• Explain Service-Oriented Architecture (SOA) concepts andrelated technology

• Explain the standards and specifications that enable aService-Oriented Architecture (SOA) approach

• Describe the SOA reference architecture

• Understand the Oracle SOA Suite 11g product

• Understand the Service design considerations

• Explain composite application concepts

• Understand the working of the different servicecomponents

• Monitor and securing services and composite applications

Course ObjectivesThis course introduces Service-Oriented Architecture (SOA) concepts, standards that enable an SOA

approach, and the Oracle Fusion Middleware 11 g 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 11 g components, you explore, modify,

execute, and monitor a purchase order processing composite application implemented using an SOA

approach for managing the business process.




Course Agenda: Day 1

Service-Oriented

Architecture Concepts

Implementing SOA with

Oracle SOA Suite

SOA Governance andService Life-Cycle

Management

Designing Services for

SOA Implementations

S O A

1 2 3 4

Course Agenda: Day 1The following is the course agenda for day 1:

• Introduction to the course and lessons.

• Lesson 1: Service-Oriented Architecture Concepts: This lesson discusses the system

integration challenges and problems faced by enterprises, and explores what needs to be

considered before embarking on an SOA style implementation.

• Lesson 2: Implementing SOA with Oracle SOA Suite: This lesson describes Oracle SOA

Suite 11 g products and components. Oracle SOA Suite 11 g architecture and its components are

discussed at an introductory level.

• Lesson 3: SOA Governance and Service Life-Cycle Management: The aim of this lesson is

to discuss the need for service life-cycle management to enable effective management ofservices, and to ensure the delivery of highest possible business value over time.

• Lesson 4: Designing Services for SOA Implementations: The aim of this lesson is to identify

common design decisions when creating service and composite applications, and to review the

key standards that enable SOA to work better, such as XSD, WSDL, and XSLT





Creating a Composite

Application

Managing and Monitoring

SOA Composite

Applications

Working with Mediator

Components

Orchestrating Services

with a BPEL

Component

5 6 7 8


• Lesson 5: Creating a Composite Application: This lesson introduces the composite

application as an assembly and deployment model for SOA services in Oracle SOA Suite 11 g .

The concepts are described through the introduction of the SCA specifications.

• Lesson 6: Managing and Monitoring SOA Composite Applications: This lesson provides an

early and basic introduction to simple administrative or management tasks related to SOA

composite applications. These tasks are accomplished by using the Enterprise Manager Web

interface.

• Lesson 7: Working with Mediator Components: This lesson introduces the basic features—

such as creating routing rules, simple filters, and transformations—of the Mediator servicecomponent inside an SOA composite application,.

• Lesson 8: Orchestrating Services with a BPEL Component: The aim of this lesson is to

introduce simple BPEL process concepts to enable you to invoke a service, such as the credit

card validation service. You also learn about the Scope, Assign, and Invoke BPEL activities.





Working with the

Human Task Component

Implementing a Business

Rules Component

Securing Services and

Composite Applications

9 10 11


• Lesson 9: Working with the Human Task Component: This lesson introduces the basic

features of the Human Task service component, and how to execute it from a BPEL process. In

addition, you are introduced to the Worklist application to perform the task assignment.

• Lesson 10: Implementing a Business Rules Component: This lesson provides an early and

basic introduction to Oracle Business Rules and its implementation in the SOA composite

application, by using a business rules service component.

• Lesson 11: Securing Services and Composite Applications: The aim of this lesson is to

introduce the basic security concepts and Oracle Web Services Manager security feature in

securing an SOA composite application.




Summary

After completing this lesson, you should understand the:

• Learning objectives of this course

• Structure and organization of this course


19/403


Service-Oriented Architecture Concepts


20/403Oracle SOA Suite 11g : Essential Concepts 1 - 2


Course Road Map

In this “Service-Oriented Architecture Concepts” lesson you will be introduced

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

Course Road MapThe “Service-Oriented Architecture Concepts” lesson introduces the challenges faced by enterprises

in integrating application and how Service-Oriented Architecture can provide a solution to the same.

You will also be familiarized with the various drivers that enable you to build a reference

architecture, which is the first step toward embarking into a Service-Oriented Architecture.




Objectives

After completing this lesson, you should be able to:

• Describe the challenges of the integration of enterpriseapplication systems

• Describe the solution for enterprise application integration

• Describe the role of Oracle SOA Maturity Model

• Describe Service-Oriented Architecture (SOA)

• Identify standards that enable SOA

• Identify basic design requirements for an SOA approach

• Explain the role of SOA governance




Business

Strategy SOA

Definition: Service-Oriented Architecture (SOA)

Service-Oriented Architecture is an IT strategy that organizes

the discrete functions contained in enterprise applications intointeroperable, standards-based services that can be combined

and reused quickly to meet business needs.

IT

Strategy

Definition: Services-Oriented Architecture (SOA)In computing, SOA provides methods for systems development and integration where systems group

functionality around business processes and package these as interoperable services. An SOA

infrastructure allows different applications to exchange data with one another as they participate in

business processes.




Why SOA?

SOA enables:

• Reusability – Business services

• Interoperability

– Loosely coupled services

• Scalability and flexibility

– Coarse-grained

– Document-oriented

– Asynchronous services• Cost efficiency

– Standards-based approach

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.



Why SOA? (continued)

Other approaches that integrate disparate business resources such as legacy systems, business partner

applications, and department-specific solutions are expensive because they tend to tie these

components together in a customized way. Customized solutions are costly to build because they

require extensive analysis, development time, and effort. They are also costly to maintain and extend

because they are typically tightly coupled, so that changes in one component of the integrated

solution require changes in other components. A standards-based SOA approach should result in less

costly solutions because the integration of clients and services does not require the in-depth analysisand unique code of customized solutions.




Enterprise Challenge

• Application development and integration issues

– Lack of flexibility – Not standards-based

– Project costs and long duration

• Traditional methodologies

– Point-to-point

– Enterprise Application Integration

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

«Packaged CRM»

«Packaged ERP»

«Mainframe»

«App Server»

CRMApplication

ERP

Application

Custom

Application

EJB

Application

«EAI» «Client Tier»

«CustomLogic»

«CustomLogic»

«CustomLogic»

Custom

API

Custom

API

Custom

API

Custom

API

Custom

API

Custom

API

Custom

API

Custom

API

«ClientApplication»



Point-to-Point IntegrationPoint-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.




Enterprise Application Integration

«Packaged CRM» «Packaged ERP»

«Mainframe» «App. Server»

CRM

Application

ERP

Application

Custom

Application

EJB

Application

«Client Tier»

«VBApplication»

«JavaApplication»

«WebApplication»

Custom

API

JAM API RMI

Message Bus or Middleware

Custom

API

Standard-based interfaces Standard-based interfaces

Enterprise Application IntegrationBecause point-to-point integration was complex, costly, and difficult to manage, the Enterprise

Application Integration (EAI) method was introduced. EAI was based on message broker or

middleware where the connectivity between each application and the message bus was developed

using proprietary bus APIs and an Application Platform Suite (APS).

The following are the disadvantages of all of these approaches:

• Custom or proprietary integration between the message bus and each application was required.

• Different proprietary data formats were involved at each integration point.

• Each application was still tightly coupled to the message bus.

• The applications need to know the inner workings of the other applications they were integrated

with.

The challenge of accessing, integrating, and transforming data (enterprise information integration)

has largely been left to developers to perform using manual coding.

The lack of standards and the architecture limitations in addition to the hefty costs of traditional EAI

projects has resulted in the search for an alternative integration solution that would address the

limitations. JAM stands for Java Application Manager.

Standard-based Interfaces Standard-based Interfaces




Example of Application-Centric Integration

Web based Banking Application

Apply for new Credit Card Apply for new Mortgage Loan

Setup

Account

Check Customer

Credit Card

Conduct

Fraud

Check

Verify Customer

Address

Setup

Account

Marketing

System

Sales andAcquisition

RiskSystem

CorporateSystem

BusinessUnit

Example of Application-Centric IntegrationThe slide shows a Web-based Banking Application using point-to-point integration. Here in order to

process a new Credit Card:

• Applications are integrated with each other.

• Each application takes care of a particular functionality such as conducting verification of

customer background, which results in tight coupling of the application

• Applications such as Risk system, Business Unit and so on use individual lines of

communication, resulting in a complex architecture. Here each application needs to create its

own integration.

The lack of agility and usage of customer integration links results in inflexibility.




Integrating Solutions and Benefits with SOA

Service-Oriented

Architecture

Offers faster business

response time

Improves business

agility

Masks underlying

technical complexity

Aligns IT with

business

Benefits

Reusability Interoperability ScalabilityCost

Efficiency

Integrating Solutions and Benefits with SOAAligning IT with discrete business functions:

• Results in rapid development and more reliable delivery of new and enhanced business services

• Improves productivity, agility, and speed for both business and IT

• Allows IT to deliver services faster and align closer with business

• Allows the business to respond more quickly and deliver optimal user experience

• Masks the underlying technical complexity of the IT environment

The benefits of Service-Oriented Architecture are:

• Reusability: Existing business functionality in an application can be reused to meet new

business requirements. In addition, new services should be designed with reusability in mind as

determined by their usage patterns within the business domain. However, not all services needto be reusable or should be depending on the business requirement.

• Interoperability: Communication between services and the business process is not dependent

on the platform and are standards-enabled. The services are also not tightly coupled to the

application.

• Scalability: Applications are flexible to the changing business requirements.

• Cost efficiency: Highly cost efficient as integrating the business resources is standards-based.




SOA Further Defined

• SOA can be thought of as:

– An enterprise-level design approach – A collection of services on a network that communicate with

one another

– A set of services that are loosely coupled, with well-defined,

reusable, platform-independent interfaces

– A higher level of application development

• Services provide access to data, business processes, and

IT infrastructure, ideally in an asynchronous manner.

• SOA leverages standards-based integration (XML and

Web services) to connect heterogeneous systems.

SOA Further DefinedSOA-based application development and integration solves many issues and shortcomings of the

traditional approaches. SOA describes a set of well-established patterns that help a client application

connect to a service. These patterns represent mechanisms used to describe a service, to advertise and

discover a service, and to communicate with a service.

Most communication middleware systems, such as Remote Procedure Call (RPC), Common Object

Requesting Broker Architecture (CORBA), Distributed Component Object Model (DCOM),

Enterprise Java Bean (EJB), and Remote Method Invocation (RMI), rely on similar patterns.

However, there are differences between each implementation and weaknesses among them. The

primary issue has been acceptable standards and interoperability. SOA is built upon these

technologies and has tried to eliminate apparent weaknesses. Each of these technologies has a fixedgranularity, function for RPC, object for CORBA, and so on. Services do not have this fixed

granularity. Instead, a service can be a function, an object, or an application. SOA is, therefore,

adaptable to any existing system and does not force the system to conform to any particular level of

granularity.

Instead of replacing the existing architectures, SOA helps to reuse all existing systems and

applications in the company and transform them into agile services. SOA not only covers information

from packaged, customer, and legacy applications systems, but also the functionality or data from the

IT infrastructure, such as security and content management.




Moving Toward Service-Centric Integration

Web Phone Branch Systems Trading Partners

Channels

Web UI / Portals/ Portlets

Presentation Service Layer

Business Process Layer (BPM, Workflow)

Business Service

CheckCredit Card

Verify Customer Address

SetupAccount

Conduct FraudCheck

Integration Tier (Connectivity Service)

Assets /Systems

SOA

Governance

Service

Bus

Mediation

Application Centric Integration Service-Centric Integration

Moving Toward Service-Centric IntegrationThe slide depicts how a Web-based Banking application using point-to point integration can be

migrated to service-centric integration using Service-Oriented Architecture (SOA).

Here each of the business functionalities has been mapped to the appropriate service layer. For

example:

• The Connectivity Service layer provides the functionality to connect to the various

systems/assets

• The Business Service layer includes the different business functionalities such as Checking

Credit Card, Verifying Customer Address, Conducting Fraud Check and so on.

• The Business Process layer includes the nuances related to business workflow and

• The Presentation Service Layer provides the user interface–related services.

The service-centric integration approach provides a shared service and infrastructure platform that

encourages reusability and flexibility.




SOA: A Paradigm Shift

AbstractionKnown implementation

Message-orientedObject-oriented

Heterogeneous technologyHomogeneous technology

Agile and adaptiveTightly coupled

Services orchestration Application block

Business-centeredCost-centered

Long development cycle

Designed to last

Functionality-oriented

Distributed Component Architecture

Process-oriented

Interactive anditerative development

Designed to change

Service-Oriented Architecture

SOA: A Paradigm ShiftSOA is much more than a new software development model; it is a true paradigm shift. The more

powerful paradigm shift that you are seeing in most organizations is the shift in focus from

functionality and application to process and business. Architects are now specifying the designs for

services with names such as Get_Customer, Open_Order, or Get_Service_History. Then together

with their business partners, they whiteboard entire business processes by assembling these services.

One of the additional benefits of SOA involves the changed relationship between IT and business,

bringing them closer to each other and helping each other. There is more to this paradigm shift. The

development cycles will shrink, or rather, will go to high frequency deployments of smaller chunks

of capability instead of the large, lengthy development.




Architecture

Infrastructure

Information

Operations,

Administration, and Management

Business and Strategy

Organization

Governance

Project,

Portfolios, and Services

Technology Dominated Organizational Disciplines

The Eight-Domain Model Approach for SOA

The Eight-Domain Model Approach for SOAThe Eight Domain Maturity model is used to accelerate SOA adoption by identifying specific

capabilities that are either completely lacking or that are lagging with respect to the other capabilities

necessary for successful SOA adoption.

The SOA Maturity Model uses the concept of domains to classify and organize the related

capabilities. These capabilities provide the detail necessary to truly measure and guide the progress

of an SOA initiative. As depicted in the slide, the Maturity Model has eight domains:

Business and Strategy: Contains capabilities that provide the high-level constructs that allow the

SOA initiative to proceed. This includes business motivation, expected benefits, guiding principles,

expected costs, a funding model, and so on.

Architecture: Contains capabilities concerning the definitions of the overall architecture and

guidelines for various practitioners to ensure adherence to the architecture

Infrastructure: Contains capabilities concerning the service infrastructure and tools that provide the

technical foundation for the SOA initiative

Information: Contains capabilities concerning the information aspects of SOA, for example,

providing Information as a Service (IAAS). This includes shared data models, message formats and

schemas, master data management, content management, and so on.

Projects, Portfolios, and Services: Contains capabilities concerning the planning and building of

services and the service usage guidelines of service consumers



The Eight-Domain Model Approach for SOA (continued)

Operations, Administration, and Management: Contains capabilities concerning the post

deployment aspects of solutions based on a Service-Oriented Architecture, such as the operations,

administration, and management aspects of SOA.

Organization: Contains capabilities concerning the development of corporate competency in regards

to SOA including the organizational structure and skills development

Governance: Contains capabilities concerning the governance structures and processes that supportand guide the SOA efforts. The maturity and adoption of an adequate amount of governance is a

leading indicator of the overall SOA success.

These eight domains, although interrelated, are sufficiently distinct. To succeed at SOA adoption, an

organization must adequately progress in all of these domains.




Quiz

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

1. Business and Strategy2. Governance

3. Architecture

4. Installation

Answer: 4Explanation: 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. Organization8. Governance




Building an SOA Reference Architecture:

From Architecture Drivers to a Roadmap

Business DriversBusiness Drivers IT Objectives SOA StrategyFuture Vision

SOA Reference Architecture

Best Practices

Roadmap

Current Reality

Determine business

scope and motivation.

Determine IT drivers.

SOA reference

architecture should

include definitions,

standards, rules,principles, and

guidelines, and

architecture views.

Design an incremental

plan to achieve the

future vision.

Identify the

stakeholders’ viewpoints

or concerns, prioritize

SOA benefits, andexamine the current

reality.

Building an SOA Reference Architecture: From Architecture Drivers to a RoadmapAn SOA strategy is ideally established enterprise-wide but in many circumstances it may be

incubated within a line of business (LOB), or other subset of the full corporate entity. In these cases,

the limitations and compromises must be recognized at an early stage (such as the reduced value of

“shared business services,” limiting opportunities for “service composition,” and so on).

Both business and IT drivers should be collected (separately).

Examples of business drivers might be to:

• Improve efficiency in the call center

• Grow revenue faster than our peers in a sustainable way

• Simplify the assimilation of acquired companies

• Expand customer relationships, and so on

IT drivers, on the other hand, might be to:

• Move from transaction focus to customer focus

• Move from silo LOB focus to process/service focus

• Expose loosely coupled business logic to achieve speed and flexibility and so on

Business and IT drivers should be aligned, but clearly use different language and refer to different

issues while leading to the same result. Notice also that “drivers” such as “vision” and “goals” do not

include statements of how to achieve these goals or even when they should be achieved.





• An SOA reference architecture is a blueprint or guide to

creating an SOA infrastructure implementation for abusiness depending on the “business needs.”

• The SOA reference architecture:

– Defines the target architecture and the principles to be used

by an organization’s architects to make architecture and

design decisions on their projects

– Is a key component of an effective strategy to deliver the

benefits of SOA

SOA Reference ArchitectureAn SOA reference architecture promotes consistency and interoperability by defining enterprise-

wide principles, guidelines, and patterns.

An SOA reference architecture is a blueprint to guide the enterprise toward SOA success by:

• Establishing a strategy for architecting new SOA projects, leveraging existing projects, and

legacy investments

• Building in flexibility, manageability, and planning for change

• Simplifying diverse, sometimes incompatible, platforms and applications found within any

large enterprise

• Transitioning toward a culture of reuse, team collaboration, and resources sharing

• Determining best practices for standards and technology deployment• Migrating toward a 2–3 year view, achieving true convergence over time

• Providing a communication tool for establishing a common understanding of SOA and its core

strategies throughout the enterprise




Composite Applications Web Apps Portals Mashups BPM Process Clients

Service Consumers and

Delivery Channels

Employees Customers Partners ClientApps

PartnerApps

Presentation Services Shared Portlets Multichannel Delivery

Business Processes System-Centric Workflow Human-Centric Workflow

Business Services Enrichment Custom/Atomic Business Services

Data Services Logical Data Model Data Aggregation/Synchronization

Connectivity Services System/Data Access Messaging Partner Integration

Service

Bus

Mediation

Service Registry

Service Repository

SOA Security

Infrastructure

SOA Monitor and

Event Manager

Infrastructure

Services

Non-Service Enabled Assets Service-Enabled Assets

Messaging Adapters Custom APIs JDBC file://

Shared Services and Infrastructure


SOA Reference Architecture (continued)The architecture separates the users of enterprise functionality from the systems and applications that

provide that functionality, placing the infrastructure for services and service delivery between them.

The layers of services and their supporting infrastructure are referred to as the “innovation layer.”

This analogy expresses their role in driving change in the way that IT is delivered. Existing

applications, data, and middleware form the foundation from which services are drawn. Supporting

and formalizing the existing enterprise activities is a service-oriented infrastructure. Standards-based

infrastructure services provide a common basis for the deployment of all other types of service.

Note: The SOA architectural framework for an organization is selected from this reference

architecture based on business requirements. Not all components of the reference architecture are

needed.




SOA Reference Architecture:

Service Consumers

Users of the enterprise functionality

Composite Applications Web Apps Portals Mashups BPM Process Clients

Service Consumers and

Delivery Channels

Employees Customers Partners ClientApps

PartnerApps

SOA Reference Architecture: Service ConsumersService consumers include end users as well as applications that are users of SOA, but not

contributors of services. These include :

• Applications that belong to another domain, for example, partner applications

• Complex event processing systems, that can invoke composite applications and services as a

result of processing decisions









Service

Bus

Mediation

Service Registry

Service Repository

SOA Security

Infrastructure

SOA Monitor and

Event Manager

Infrastructure

Services



Service Classification

Service classifications and infrastructure

requirements of Service-Oriented

Architecture

SOA Reference Architecture: Service ClassificationService classification is a logical grouping of types of services that meet specific needs and conform

to different subsets of standards or guidelines. The separate classifications potentially satisfy

different subsets of architectural principles and have their own specific constraints applied.

The different service classifications are:

• Connectivity services

• Data services

• Business services

• Business process services

• Presentation services

• Infrastructure services









Service

Bus

Mediation

Service Registry

Service Repository

SOA Security

Infrastructure

SOA Monitor and

Event Manager

Infrastructure

Services

Non-Service Enabled Assets Service-Enabled Assets

Messaging Adapters Custom APIs JDBC file://



Service Providers

Assets that can be shared and reused

throughout the enterprise

SOA Reference Architecture: Service ProvidersExisting functionalities, from other parts of the enterprise or from external applications, can be

accessed securely via the service bus, if the functionalities are exposed as services (service-enabled

assets). In this way business functionality (or data etc.) that was not previously accessible can be

shared and reused across the enterprise. There is no necessity for the connectivity services to

“service-enable” them. But on the contrary the non-service –enabled assets standardize the exposure

of their functions to the other service classes using the connectivity services.




Reference Architecture: Example

Business

Activity

Services

Calc Item Price & CheckItem Availability

Calc Freight

Web Application eCommerce Processes

Create New

Quote or Order Convert Quote

to Order

Check Order

Status

Check Invoice

History

Business

Process

Services

Import Order Calculate Shopping Cart

Cart

Service

Order

ServiceInvoice

ServiceService Bus

Connectivity Services – Oracle Adapter

System Access Data Access

Reference Architecture: ExampleThe slide displays a reference architecture of a Web application e-commerce process. The

application performs the following tasks:

• Allows a customer to search for an item, add the selected item to a shopping cart, and place an

order for it.

• Calculates the shopping cart value based on the availability of the item in the database

• Generates an invoice

• Enables the customer to keep track of the order status

Each of the above mentioned tasks maps to a functionality in the shared service and infrastructure

layer. For example, calculating the item price and freight charges falls under the business services

layer, whereas the accessibility of the database finds its location in the connectivity service.

One of the key ideas is to identify explicit functional capabilities and their location in the reference

architecture.




Standards That Enable SOA

Transport

Message

Description

Discovery

Quality of

service

Business

processes

HTTP(S), IIOP, JMS, SMTP

XML

SOAP

WSDL

UDDI

WS-SecurityWS-ReliableMessaging

Orchestration: BPEL4WS

Management

WS-Policy

WS-Security

CategoryCurrent and Emerging Standards

Service Component Architecture (SCA)

Service Data Objects (SDO) Data access

Assembly

model

Standards That Enable SOAThis graphic illustrates the many existing W3C standards and emerging specifications (SCA and

SDO) that work together to build on simple, stand-alone standards (such as XML and XPath) to

enable an SOA approach, that is, using the Web service foundations of Simple Object Access

Protocol (SOAP), Web Services Description Language (WSDL), and Universal Description,

Discovery and Integration (UDDI). The notion of Service-Oriented Architecture is elevated to a

higher level through message orchestration and process integration, and more recently with the

Service Component Architecture that enables the assembly of components to create a composite

service.

Note: A key benefit of using the standards on which an SOA implementation is based is

independence of hardware and operating systems used to implement the service functionality.



Standards That Enable SOA (continued)

The slide groups the standards listed into the following categories:

• Transport: The various protocol standards that can be used to communicate data

• Message: Structuring and providing message data with XML schema and XML standards

• Description: Exposing service function and data structures through WSDL standards

• Discovery: Locating services in registries based on UDDI standards

• Quality of service: Managing reliability, security, transactions, and coordination in using Web

services standards (WS-* standards)

• Business process: Orchestrating services using the BPEL standard

Here are brief descriptions of the standards listed in the slide:

• BPEL4WS: Is an XML-based language describing the rules for orchestrating a business

process that calls one or more services

• WS-Reliability: Is a SOAP-based specification, managed by the Organization for the

Advancement of Structured Information Standards (OASIS) that fulfills reliable messaging

requirements critical to some applications of Web services

• WS-Security: Is a protocol that provides a way to apply security to Web services

• WS-Transactions: Is a specification that describes coordination types used with the extensible

coordination framework specified by WS-Coordination

• WS-Coordination: Is a Web services specification that describes an extensible framework for

providing protocols that coordinate the actions of distributed applications

• WS-Context: Is a specification to provide a definition of a structuring mechanism and a

software service definition for organizing and sharing context across multiple execution

endpoints. This enables context information such as WS-Addressing information that is

communicated via SOAP headers to be propagated across endpoints.

• WS-Addressing: Specifies a mechanism for Web services to share addressing information

• UDDI: Provides a platform-independent protocol and XML-based registry, which lists business

services and information on the Internet

• WSDL Is an XML format used to publish and describe the operations and messages required tocall a Web service

• SOAP: Is a protocol for exchanging XML-based messages across a network, normally using

HTTP

• XML: Is widely used to describe Web services, describe UDDI registry data, define XML

schema documents, and define message structures for exchanging XML-based data between

services

• HTTP: Is a method for transferring data across the World Wide Web. HTTP is widely used to

access and retrieve HTML pages.

• IIOP (Internet Inter-ORB Protocol): Is the implementation of the General Inter-ORB

Protocol (GIOP). GIOP is the abstract protocol by which object request brokers (ORBs)communicate based on standards maintained by the Object Management Group (OMG).

• JMS: (Java Messaging Service) Provides a Java message-oriented middleware (MOM) API to

asynchronously communicate messages between multiple clients

• SMTP (Simple Mail Transfer Protocol (SMTP): Is the default standard for sending emails

across the Internet




Quiz

An SOA reference architecture is a blueprint to guide the

enterprise toward SOA success.1. True

2. False

Answer: 1Explanation: 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.




Service and Web Service

• A service:

– Provides a unit of work as part of a business process – Performs a business function (such as validate credit card)

• A Web service:

– Is a software system or self-describing business function

– Is designed to support interoperable machine-to-machine

interaction over a network

– Communicates with clients through standard protocols and

technologies

Request

Response

Service Requester Service Provider

Service and Web ServiceA service can be defined as a well-defined, self-contained business function that:

• Operates independently from the context or state of other services

• Represents a unit of work performed by a component or part of an automated subprocess

A service is essentially a process that performs a specific business function, such as validating a

credit card submitted with a customer order. Business functions that are a subset of an existing

Enterprise Information System (EIS) (such as part of an Enterprise Resource Planning (ERP) system

and other application modules) can be represented as a service through adapters.

A suitable granular (modular) service design can enable a service to support many applications in an

enterprise that spans platforms and organizational components. For example, to find the number of

units sold for a particular product, the business function might need to query a sales management, a

sales order, and a product inventory system within an organization.

A Web service is a service that performs discrete business functions. Interaction with a Web service

is based on a set of standard protocols and technologies. Web services:

• Make use of standard set of platform-independent messaging protocols (SOAP, HTTP, JMS)

• Using standard protocols enable connections between services from any Web-connected device

• Exchange data and functionality in XML format




Types of Service Access and Implementation

Types of Service Access and Implementation

Created

from existing

functionality

Created as

new

functionality

Can be achieved

either by exposingexisting functionality

as Web services or

by using adapters

Can be developed by

using service buscomponents, BPEL

processes, or Web

services implemented

with Java or Java EE

Invoked

through

protocols and

methods

Services can be

invoked by usingSOAP over HTTP,

JMS adapters, or

WSIF.

Service

access

Service

access

Types of Service Access and ImplementationBefore embarking on an SOA implementation, business requirements should be identified before you

can design, identify, or locate services that can support the business need. After the identification

task is complete, services and their operations and messages can be specified, thereby creating a

“portfolio of services” needed to meet the business requirements.

The implementation for the “portfolio of services” can be chosen from:

• Existing functionality, provided by in-house applications already available for use. Existing

application functionality can be exposed through new interfaces and repurposed for an SOA

environment.

• Enterprise Information Systems (EIS), and legacy applications, which have many custom

adapter interfaces that expose their functionality as services for integration purposes• New applications, which can be developed in languages that support Web service standards,

such as Application Development Framework Business Components (ADF BC), Java, and Java

EE, among others. New services can be developed if existing services do not meet identified

requirements.

Invocation of services, whether developed as a Web service or exposed through adapters (using Java

Connector Architecture standards) can be invoked using SOAP, Representational State Transfer

(REST), and Web Services Invocation Framework (WSIF) and potentially other ways.




Ways to Integrate Services

Process and service integration can be done many ways:

• Proprietary implementations: Typically integrate isolatedsystems with a point-to-point approach

• Vendor-specific implementations: Technology such as

Tuxedo enable integration using a consistent approach

• Common Object Request Broker Architecture, (CORBA)

implementations: Programmatically intensive, widely

supported, and not widely used due to implementation cost

• Web Service and, now, SCA style implementations: UsingXML and Web standards to integrate systems

Note: Not everyone agrees on the way to do SOA-enabled

implementations

Ways to Integrate ServicesThe points stated in the slide illustrate that integration can be done in many ways and forms, some of

which are proprietary approaches that have enabled silo (stand-alone) systems to be integrated,

typically in a point-to-point manner. This approach is less flexible and hard to maintain over time.

Technologies such as Tuxedo, a vendor-specific integration technology, enable systems to

standardize the way that they integrate their systems. Tuxedo until recently did not support Web

service standards, keeping the technology contained within an organization that embraced it. The

computing industry worked to create a standardized protocol and software integration method called

Common Object Request Broker (CORBA), that enabled systems to integrate by using a standard

(non XML-based) interface definition language for generating code templates that could be

distributed. Although it is entirely possible to apply an SOA approach with CORBA, the lack of itswide use and accessibility, in addition to its remote procedure call mechanisms, make it costly to

implement and less friendly to use across an intranet or Internet. With the advent of Web services

and the common use of XML, WSDL, and XSD standards, SOA-based approaches have naturally

embraced these standards that enable easier interoperability across intranet and Internet networks.

Keep in mind that not every one agrees on the same implementation styles for Web services–style

SOA implementations. For example, not all Enterprise Service Bus implementations are alike, nor

does everyone chose to implement BPEL for process orchestration. However, as we already know,

time changes many things.




Designing with an SOA Approach

Designing with an SOA approach involves:

• Aligning IT with the business needs—design needs to bedriven by business process

• Identifying services that performs functionality as part of a

business process—building a service portfolio

– Designing standard message structures in XML format using

XML Schema Documents (XSD)

– Specifying service interfaces in Web Services Definition

Language (WSDL) format

– Selecting choice of service implementation

— Java Web Services and J2CA Adapters

— BPEL

— SCA composite applications

— .NET, among others

Designing with an SOA ApproachWhen designing systems integration approaches with an SOA-style implementation the focus is

always to be aligned with the business requirements. This is because businesses redefine and change

their processes as needed to deal with changes in their industries. Therefore IT must be agile enough

to change as the business requires.

When designing a service, the service should be evaluated in terms of its role in the business and how

it can be reused (if at all) subject to changes in the business requirements.

Note: Some services, by their nature, may not be reusable and would have to maintained and

changed to stay aligned with the business requirements.

After the business process flow and requirements are understood, when it comes to designing eachservice, the key artifacts that require careful design are:

• Service message structures that need to be exchange between service consumer and clients.

Design of message structures is a form of data modeling with respect to identifying what

information is needed by a service to perform its function.

• Service interface definition, that is, the WSDL that describes the function that the service will

offer and associates the input and optional output message structures to each exposed function.

Designing a WSDL interface depends on understanding interactions, that is, how the service

will be used and if communicates synchronously or asynchronously.

• Service functionality can be designed based on choice of implementation language or type.




Creating Service Portfolios

Created with reusability in mind, a service portfolio:

• Is identified from a set of services needed for implementingone or more business processes within a business domain

• Can be stored in an enterprise repository for design-time

and governance purposes

• Can be accessed from a service registry at design time

and run time for location-independence and governance

• Can be realized by:

– Reusing functionality by wrapping as services, and usingadapter technology

– Creating new services with SOA-enabled technology, such

as Web services, SCA composite applications, BPEL, and

service bus

Creating Service PortfoliosWhen embarking on a Service-Oriented Architecture approach to systems integration, systems

integrators begin by examining business process requirements and the business domain to identify

functionality that can be used as a “service” unit of work to help complete a business process. The

aim of building a system portfolio is to identify common functionality that can be decoupled and

exposed or used as a service within a business domain. While the business process drives the

identification of services, the analysts should always keep the goal of reusability in mind within the

business domain.

Note: Not all services or service-enabled applications should be reusable. Experience helps to find

the right balance.

After a collection of services has been identified to serve the business process and can be applied to a

business domain, the recommended practice is to store information about the services—their

interfaces and message structure—in a common location such as an enterprise repository. This

facilitates and promotes sharing and reusability from the design phase through to production.

Coupled with a service registry, an enterprise repository can migrate service run-time information

into development, test, and production/operational environments. Coupling an enterprise repository

and service registry enable an organization to implement strong SOA governance strategies for

services throughout a service life cycle from design time to run time. A service registry enables

applications to look up a service by using a service key, for location independence.




SOA Workflow and Orchestration

• Basic data access and discrete

business logic services areconsumed within orchestration

layer services.

• Agility is achieved by separating

core business logic and control

logic.

• Business process management

systems provide the modeling

tools and execution environmentfor creating these services.

Service A

Service B

Service C

SOA Workflow and OrchestrationA mature SOA leverages a service orchestration layer that is focused on delivering new services byorchestrating the basic services provided by basic data access and business logic services. The keyarchitectural focus of this layer is agility. Agility is achieved by properly applying data aggregation, process definition and workflow tools to create the desired services. Designing and developingorchestration services requires domain expertise in integration processes and rules.

This layer is where the business logic is implemented and published as an enriched service.

In order to deliver on the promises of agility, it is essential to separate services into core businesslogic and control logic. If the separation is thorough, changes to existing processes and theintroduction of new processes should happen smoothly because the impact can be minimized.,

helping to reduce redundancies and inconsistencies.A business process management (BPM) system offers the necessary step-by-step executionapproaches and modeling techniques to implement the business logic of the newly composedservices. This implementation can cover complex business use cases that require maintaining stateinformation, loops, tests, and parallel execution. And these new services become in turn, reusablecomponents for building other services. So there is a very good fit between the BPM vision and SOA,and both aim at increased flexibility for the enterprise IT.

With the powerful combination including service bus and BPM solutions, is possible to create more powerful SOA solutions within organizations and across organizational boundaries to react morequickly to frequently changing business requirements.




Implementing SOA: General Concepts

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

• Register and publish services (UDDI).• Decouple services through virtualization

and routing (mediator).

• Orchestrate services (BPEL).

• Create user interfaces to initiate

and interact with services.

Mediator

UDDI Registry

Web

application

Orchestration

(process flow)

Service

PortfolioJava .Net Adapter

Implementing SOA: General ConceptsThis graphic represents the conceptual goal of an SOA implementation. The principles of

implementing an SOA approach include:

• Creating a portfolio of services. The basic building block of an Oracle SOA strategy is a

service. Services must be visible and accessible.

• Publishing services in a UDDI registry. Services can be registered in a UDDI registry so that

they can be discovered and located across the Internet and intranet.

• Virtualizing services by using mediators to further decouple (minimize dependences) between

service consumers from the service provider. The mediator can also manage the process of

moving, transforming, and filtering data transferred between service endpoints, thereby creating

a foundation layer (plumbing or glue) between services.• Orchestrating services with BPEL. BPEL enables the implementation of complex business

process flows that require short- and long-term interaction between services. Orchestrating

business processes may involve accessing services, published in the UDDI registry, or directly

from their endpoints. In addition, a BPEL process becomes a service.

• Developing rich client applications to invoke or interact with services based on using the latest

Web technology and Web services standards




Quiz

Services can be implemented using existing functionality.

1. True2. False

Answer: 1Explanation: Services can be implemented using existing functionality by exposing existing

functionality as services or by using adapters.




Define SOA Governance

SOA governance can be defined as:

• A set of solutions, policies, and practices that enableorganizations to implement and manage an enterprise

SOA

• An application of IT governance specifically focused on the

life cycle of services and composite applications in an

organization’s service-oriented architecture

Policies

(What)

Processes

(How)

Decisions

(Who)

Define SOA GovernanceGovernance is about ensuring that business is conducted properly. It is less about control and strict

adherence to rules, and more about guidance and the effective and equitable use of resources to

ensure sustainability of an organization’s strategic objectives. Governance is a process that is

influenced through organizational behavior and the establishment of structured processes.

Technology is there to help automate the governance process as much as possible. In other words, it

is a framework for managing SOA assets in compliance with a company’s standards, policies, and

business strategies specifically focused on the life cycle of services, policies, practices, metadata, and

composite applications.




Identifying the Need of SOA Governance

• Business value

• Alignment• Business agility

• Risk reduction

• Cost savings

Identifying the Need of SOA GovernanceSOA governance offers the following benefits:

• Business value: Ensures that project investments yield business value

• Alignment: Keeps SOA aligned with the business and architecture and in compliance with

business and IT policies

• Business agility: Gains visibility into your SOA for more rapid decision making

• Risk reduction: Controls dependencies, manages the impact of change, enforces policies

• Cost savings: Promotes consolidation, standardization, and reuse




• The SOA governance framework is centered on the four

facets of enterprise architecture: – People

– Process

– Service

– TechnologyProcess

SOA Governance Framework

People

Service Technology

SOA Governance FrameworkThe implementation of any type of governance should be centered on the four pillars of an enterprise

architecture: people, processes, technology, and services.

One mechanism to implement an enterprise IT and SOA governance is by enabling a shared resource

and capability center to function as a resource pool as new business application needs arise.

A governance implementation also needs to be supported by a hierarchical organizational reporting

structure.




Quiz

The SOA governance framework is centered on _________,

process, technology, and service.1. Strategy

2. Risk

3. People

4. Value

Answer: 3Explanation: 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.




Course Practice Scenario:

Purchase Order Processing

Course Case Scenario: Purchase Order ProcessingPurchase order processing is an SOA composite application that implements the following:

• Purchase order processing and approval

• Details for the purchase order are received from multiple sources.

• Large order quantities (quantities greater than or equal to 10 units) pass through a validation

and approval process (where the customer's credit card status is validated)

• Approved order details having the status of Approved are written into a text file. An

unapproved order will have the status “Rejected/Invalid” written into the text file.




Summary

In this lesson, you should have learned how to:

• Explain the need to implement service-orientedarchitectures

• Describe SOA

• Identify standards that enable SOA

• Describe the SOA Maturity Model

• Describe basic interaction patterns

• Explain the role of SOA governance

SummaryIn 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


61/403


Implementing SOA with Oracle SOA Suite




Course Roadmap

SOA

In this “Implementing SOA with Oracle SOA Suite" lesson, you will be

introduced