Student Guide - Oracle SOA Suite 11g Essential Concepts Volume 1 _ www.bit.ly/taiho123

Contents I Introduction Course Objectives I-2 Course Agenda: Day 1 I-3 Course Agenda: Day 2 I-4 Course Agenda: Day 3 I-5 Summary I-6 1 Service-Oriented Architecture Concepts Cours

Trang 1

Oracle SOA Suite 11g:

Trang 2

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

Trang 3

Contents

I Introduction

Course Objectives I-2

Course Agenda: Day 1 I-3

Summary I-6

1 Service-Oriented Architecture Concepts

Course Road Map 1-2

Enterprise Application Integration 1-9

Example of Application-Centric Integration 1-10

Integrating Solutions and Benefits with SOA 1-11

SOA Further Defined 1-12

Moving Toward Service-Centric Integration 1-13

SOA: A Paradigm Shift 1-14

The Eight-Domain Model Approach for SOA 1-15

Quiz 1-17

Building an SOA Reference Architecture: From Architecture Drivers to a Roadmap 1-18 SOA Reference Architecture 1-19

SOA Reference Architecture: Service Consumers 1-21

SOA Reference Architecture: Service Classification 1-22

SOA Reference Architecture: Service Providers 1-23

Reference Architecture: Example 1-24

Standards That Enable SOA 1-25

Quiz 1-27

Service and Web Service 1-28

Types of Service Access and Implementation 1-29

Ways to Integrate Services 1-30

Designing with an SOA Approach 1-31

Creating Service Portfolios 1-32

SOA Workflow and Orchestration 1-33

Implementing SOA: General Concepts 1-34

Quiz 1-35

Define SOA Governance 1-36

Identifying the Need of SOA Governance 1-37

SOA Governance Framework 1-38

Trang 4

2 Implementing SOA with Oracle SOA Suite

Course Roadmap 2-2

Objectives 2-3

Basic Components of an SOA Infrastructure 2-4

Oracle SOA Suite 11g Components 2-5

Introduction to Service Infrastructure 2-7

Introducing SCA in Oracle SOA Suite 11g 2-8

Defining a Composite Application 2-9

Introducing Oracle Mediator Component 2-11

Describing the Features of Oracle Mediator Component 2-12

Introducing Oracle BPEL Process Component 2-13

Introducing Business Rules Component 2-14

Introducing Human Task Component 2-15

Quiz 2-16

Introduction to Business Activity Monitoring 2-17

Monitoring Services with BPEL and BAM 2-18

Oracle Enterprise Manager 2-19

Oracle WebLogic Server 10.3 2-21

WebLogic Server Domain 2-22

WebLogic Server Servers 2-24

Administration Server 2-25

Managed Server 2-26

WebLogic Server Machines 2-27

SOA Development with Oracle JDeveloper 2-28

Creating Connections in Oracle JDeveloper 2-29

Creating an Application Server Connection in Oracle JDeveloper 2-31 Goals of Implementing SOA Application with Oracle SOA Suite 11g 2-33 Quiz 2-34

Summary 2-36

Practice 2 Overview: Creating Connections in JDeveloper 2-37

3 SOA Governance and Service

Life-Cycle Management Course Roadmap 3-2

Objectives 3-3

Define Service Life-Cycle Management 3-4

Phases of Service Life Cycle 3-5

The Need for Service Life-Cycle Management 3-6

Define SOA Governance 3-7

Relationship of Governance Disciplines 3-8

The Need for SOA Governance 3-9

Benefits of SOA Governance 3-10

Center of Excellence: Key to SOA Success 3-11

Example of Governance Organizational Structure 3-12

Quiz 3-13

Service Life-Cycle Governance 3-14

Service Management 3-16

Trang 5

SLA Management 3-21

Quiz 3-22

Constituents of SOA Governance Model 3-23

End-to-End SOA Governance 3-25

End-to-End SOA Governance: SOA Asset Management 3-26

End-to-End SOA Governance: Policy Management and Enforcement 3-27 End-to-End SOA Governance: Consumer Management 3-28

End-to-End SOA Governance: SOA Monitoring and Management 3-29 SOA Governance Solution 3-30

Oracle SOA Governance Solution 3-31

Quiz 3-32

Summary 3-33

Practice 3 Overview: Defining Policies for a Group of Services 3-34

4 Designing Services for SOA Implementations

Service Design Principles 4-10

Designing Coarse-Grained Interfaces 4-12

Choosing Service Implementation Styles 4-25

Fundamentals for Creating a Service 4-27

Building a Portfolio of Services 4-28

Describing a Web Service 4-29

Web Service Standards 4-30

Web Service Architecture 4-31

Service Artifacts 4-33

XML Schema Definitions 4-34

Defining Messages in XML Schemas 4-35

Web Services Description Language 4-36

Trang 6

Packaged Application and Legacy Adapters 4-42

Quiz 4-43

Summary 4-44

Practice 4: Overview Designing Services for SOA Implementations 4-45

5 Creating a Composite Application

Course Roadmap 5-2

Objectives 5-3

Service Component Architecture 5-4

Components and Composites 5-6

Service Data Objects (SDO) 5-12

SDO Data Architecture 5-13

SCA and SDO 5-14

Creating an SOA Composite in JDeveloper 11g 5-15

Describing the SOA Composite Editor 5-16

Creating Exposed Services 5-18

Creating SOA Components 5-19

Examining the SCA Descriptor 5-20

Quiz 5-21

Adding a Mediator Component 5-22

Adding a BPEL Process Component 5-23

Comparing BPEL and Mediator 5-24

Examining the JDeveloper Workspace, Projects, and File Structure 5-25 Editing a Component in a Composite 5-26

Creating External References 5-27

Creating Wires 5-28

Creating Wires Modifies Connected Elements 5-29

Exposing Components as an External Service 5-30

Quiz 5-31

Deploying an SOA Composite Application 5-32

Summary 5-33

Practice 5: Overview Creating an SOA Composite Application 5-34

6 Managing and Monitoring SOA Composite Applications

Course Roadmap 6-2

Objectives 6-3

Overview of Managing SOA Applications 6-4

Managing with Oracle Enterprise Manager 6-5

Oracle Enterprise Manager Fusion Middleware Control 6-6

Accessing the SOA Infrastructure Home Page 6-7

Accessing a Composite Application Home Page 6-8

Example Composite Application Home Page 6-9

Trang 7

Working with the Flow Trace 6-14

Working with the Component Audit Trail Page 6-15

Quiz 6-16

Managing the State of Deployed SOA Composite Applications 6-17

Monitoring and Deleting Specific SOA Composite Application Instances 6-18 Recovering from SOA Composite Application Faults 6-19

Undeploying a Composite Application 6-21

Quiz 6-22

Summary 6-23

Practice 6: Overview Managing and Monitoring Composite Applications 6-24

7 Working with Mediator Components

Course Roadmap 7-2

Objectives 7-3

Introducing Oracle Mediator 7-4

Oracle Enterprise Service Bus and Mediator 7-5

Oracle Mediator Features 7-6

Event Delivery Network 7-7

Introducing Business Events 7-8

Creating an Oracle Mediator Component 7-18

Mediator Component Creation Options 7-19

Define Interface Later 7-20

Viewing the Mediator Source Code 7-22

Modifying a Mediator Component 7-23

Deleting a Mediator Component 7-24

Specifying Mediator Component Routing Rules 7-25

Introducing Routing Rules 7-26

Accessing Mediator Routing Rules 7-28

Defining Mediator Routing Rules 7-29

Specifying a Target Service: Example 7-31

Adding a Transformation to a Mediator Component 7-32

Trang 8

8 Orchestrating Services with a BPEL Component

Course Roadmap 8-2

Objectives 8-3

Process Orchestration Concepts 8-4

Introducing Business Process Execution Language (BPEL) 8-5 Creating a BPEL Process 8-7

Oracle BPEL Process Designer 8-8

Designing the BPEL Process 8-9

Quiz 8-10

Developing a BPEL Process 8-11

BPEL Activity Types 8-12

Grouping Activities by Using a BPEL Scope 8-14

Adding Activities to a Scope 8-15

Communicating Data with a BPEL Process 8-16

BPEL Variables 8-17

Choosing Global or Local Variables 8-19

The Assign Activity 8-21

Creating Assign Operations 8-22

Copying Data from Source to Target 8-23

Using the XPath Expression Builder 8-24

Quiz 8-25

Partner Links and Service Invocation 8-26

Partner Links, Partner Link Types, and Roles 8-27

Synchronous Services 8-28

Synchronous Process Structure: HelloWorld Example 8-29 Asynchronous Service 8-30

Asynchronous BPEL Process Structure 8-31

Creating a Partner Link 8-32

Configuring a Partner Link 8-33

Invoking a Synchronous Service 8-34

Conditionally Branching with a Switch Activity 8-35

Adding a Switch Activity 8-36

Configuring Branches of a Switch Activity 8-37

Summary 8-38

Practice 8: Overview Creating a BPEL Service Component 8-39

9 Working with the Human Task Component

Course Roadmap 9-2

Objectives 9-3

What Is a Human Task? 9-4

Human Workflow Diagram 9-5

Introduction to Human Workflow Concepts 9-7

Implementing Human Workflow Services 9-8

Exploring Workflow Exchange Patterns 9-9

Describing a Workflow as a Service 9-10

Quiz 9-11

Adding a Human Task Component to an SOA Composite 9-12

Trang 9

Adding Task Parameters 9-17

Setting the Task Parameter Values 9-18

Generating a Task Form for the Worklist 9-19

Accessing the Worklist Application 9-20

Viewing Task Information 9-21

Managing Task Assignments 9-22

Summary 9-23

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

10 Implementing a Business Rules Component

Course Roadmap 10-2

Objectives 10-3

Introducing Business Rules Technology 10-4

Declarative Rule Concepts 10-5

Rule Inference Concepts 10-6

Reasons for Using Rules Technology 10-7

Guidelines for Selecting Rules Use Cases 10-8

Introducing Oracle Business Rules 10-9

Introducing Oracle Business Rules Concepts 10-11

Developing a Rule-Enabled Application 10-12

Defining Oracle Business Rules Development Concepts 10-13

Quiz 10-14

Creating a Dictionary for Rule Definitions 10-15

Working with the Rules Editor in JDeveloper 10-16

Creating XMLFact Entries 10-18

Working with Bucketsets 10-19

Creating a Rule Test 10-25

Creating a Rule Action 10-26

Working with Decision Tables 10-27

Creating Conditions and Rules in Decision Tables 10-29

Creating Actions in Decision Tables 10-31

Working with Decision Functions 10-33

Integrating Rules with a BPEL Process 10-34

Adding a Business Rule Activity 10-35

Summary 10-38

Practice 10: Overview Implementing a Business Rule 10-39

11 Securing Services and Composite Applications

Course Roadmap 11-2

Objectives 11-3

Introduction to Web Services Security 11-4

Need for Web Services Security 11-5

Web Services Security Approaches 11-6

WS-Security 11-8

WS-Security Fundamentals 11-9

Quiz 11-11

Trang 10

Oracle Web Service Manager 11-12

Components of Oracle Web Services Manager Architecture 11-13

Oracle Web Services Manager Policy Framework 11-14

Introduction to Policies 11-15

Policy Interceptor Pipeline 11-16

Policy Assertions 11-17

Quiz 11-18

Managing SOA Composite Application Policies 11-19

Attaching Security Policy to a Service 11-20

Quiz 11-21

Summary 11-22

Practice 11 Overview: Attaching Policies to Web Services 11-23

Appendix A: Practices and Solutions

Appendix B: Introduction to Linux

What Is Linux? B-2

What Is Oracle’s Strategy for Linux? B-3

File System and Basic Directory Structure B-4

Shell Commands B-6

Environment-Based Commands B-7

Information-Based Commands B-9

File System Commands B-11

Common vi Editing Commands B-13

Common FTP Communication Commands B-15

Archive Utilities B-17

Shortcuts and Tips B-19

Appendix C: Perform Common Tasks with Oracle JDeveloper

Objectives C-2

Create a Database Connection C-3

Create an Application Server Connection C-4

Create an Application C-6

Create an Empty Project C-8

Create an SOA Project C-9

Create a Project from Existing Sources C-10

Deploy an SOA Composite Application C-13

Summary C-15

Appendix D: SOA Adoption Planning Principles

Objectives D-2

SOA Adoption D-3

SOA Adoption Planning Activities D-4

SOA Adoption Planning Activities: Completing the Stakeholder Community D-5 SOA Adoption Planning Activities: Moving Through the Change Curve D-6 SOA Adoption Planning Activities: Establishing "Line-of-Sight" Goals D-7 SOA Adoption Planning Activities: Establish a Milestone Delivery Plan D-8

Trang 11

Developing the SOA Reference Architecture D-13

Developing the SOA Reference Architecture: Align IT with Business D-14

Developing the SOA Reference Architecture: Develop a Baseline D-15

Developing the SOA Reference Architecture: Create SOA Reference Architecture D-16 Developing the SOA Reference Architecture: Create SOA Infrastructure Roadmap D-17 SOA Governance Model D-18

Example of an SOA Governance Model D-19

Summary D-20

Glossary

Trang 13

Introduction

Trang 14

Course Objectives

After completing this course, you should be able to:

related technology

Service-Oriented Architecture (SOA) approach

components

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

Trang 15

Course Agenda: Day 1

Designing Services for SOA Implementations

SO A

The following is the course agenda for day 1:

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

considered before embarking on an SOA style implementation

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

discussed at an introductory level

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

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

Trang 16

Creating a Composite

Application

Managing and Monitoring SOA Composite Applications

Working with Mediator Components

Orchestrating Services with a BPEL Component

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

The concepts are described through the introduction of the SCA specifications

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

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

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

Trang 17

Working with the Human Task Component

Implementing a Business Rules Component

Securing Services and Composite Applications

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

basic introduction to Oracle Business Rules and its implementation in the SOA composite application, by using a business rules service component

introduce the basic security concepts and Oracle Web Services Manager security feature in securing an SOA composite application

Trang 18

Summary

After completing this lesson, you should understand the:

Trang 19

Service-Oriented Architecture Concepts

Trang 20

Course Road Map

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

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

Course Road Map

The “Service-Oriented Architecture Concepts” lesson introduces the challenges faced by enterprises

in integrating application and how Service-Oriented Architecture can provide a solution to the same You will also be familiarized with the various drivers that enable you to build a reference

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

Trang 21

Objectives

After completing this lesson, you should be able to:

application systems

Trang 22

Business

Definition: Service-Oriented Architecture (SOA)

Service-Oriented Architecture is an IT strategy that organizes

the discrete functions contained in enterprise applications into

interoperable, standards-based services that can be combined

and reused quickly to meet business needs.

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

Trang 23

– Loosely coupled services

– Coarse-grained – Document-oriented – Asynchronous services

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

Trang 24

Why SOA? (continued)

Other approaches that integrate disparate business resources such as legacy systems, business partner applications, and department-specific solutions are expensive because they tend to tie these

components together in a customized way Customized solutions are costly to build because they require extensive analysis, development time, and effort They are also costly to maintain and extend because they are typically tightly coupled, so that changes in one component of the integrated

solution require changes in other components A standards-based SOA approach should result in less costly solutions because the integration of clients and services does not require the in-depth analysis and unique code of customized solutions

Trang 25

Enterprise Challenge

– Lack of flexibility – Not standards-based – Project costs and long duration

– Point-to-point – Enterprise Application Integration

Enterprise Challenge

Enterprises use many different custom-built and off-the-shelf packaged applications to run their business processes Applications are integrated to share information among themselves and to

incorporate information from existing applications Traditional application development and

integration approaches have neither been flexible nor standards-based to facilitate an agile enterprise

IT environment

In large enterprises, application development means interacting with business data from one or more sources or other applications Application integration could not be implemented without application development tasks that included developing, assembling, and connecting components to back-end systems, process flow and workflow implementation, user interface development, testing, and

debugging

Two of the most common application integration methodologies were:

• Point-to-point integration methodologies using APIs, proprietary messages, and custom

integration links

• Enterprise Application Integration (EAI) based on message bus (message bus specializes in transporting messages between applications) or middleware

Trang 26

ERP Application

Custom Application

EJB Application

Custom API

«Client Application»

Point-to-Point Integration

Point-to-point integration involves:

• Proprietary messages, APIs

• Custom integration links

• Duplication of effort

• Lack of open standards

• Tight coupling of data and implementation

• Skill set issues

• Projects lasting months

• Cost (skill, time, products)

• Operational polices embedded in application

• Lack of agility

• Slow response by IT to business changes

In the point-to-point (or peer-to-peer) integration methodology, applications are integrated with other

Trang 27

Enterprise Application Integration

«Packaged CRM» «Packaged ERP»

«Mainframe» «App Server»

CRM Application

ERP Application

Custom Application

EJB Application

«Client Tier»

«VB

Application» «Java Application» «Web Application»

Custom API

Message Bus or Middleware

Custom API Standard-based interfaces Standard-based interfaces

Enterprise Application Integration

Because point-to-point integration was complex, costly, and difficult to manage, the Enterprise Application Integration (EAI) method was introduced EAI was based on message broker or

middleware where the connectivity between each application and the message bus was developed using proprietary bus APIs and an Application Platform Suite (APS)

The following are the disadvantages of all of these approaches:

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

• Different proprietary data formats were involved at each integration point

• Each application was still tightly coupled to the message bus

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

The challenge of accessing, integrating, and transforming data (enterprise information integration) has largely been left to developers to perform using manual coding

The lack of standards and the architecture limitations in addition to the hefty costs of traditional EAI projects has resulted in the search for an alternative integration solution that would address the

limitations JAM stands for Java Application Manager

Standard-based Interfaces Standard-based Interfaces

Trang 28

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 and Acquisition System Risk Corporate System Business Unit

Example of Application-Centric Integration

The slide shows a Web-based Banking Application using point-to-point integration Here in order to process a new Credit Card:

• Applications are integrated with each other

• Each application takes care of a particular functionality such as conducting verification of customer background, which results in tight coupling of the application

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

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

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

Trang 29

Integrating Solutions and Benefits with SOA

Service-Oriented Architecture

Offers faster business response time

Benefits

Reusability Interoperability Scalability Efficiency Cost

Integrating Solutions and Benefits with SOA

Aligning IT with discrete business functions:

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

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

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

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

• Masks the underlying technical complexity of the IT environment

The benefits of Service-Oriented Architecture are:

business requirements In addition, new services should be designed with reusability in mind as determined by their usage patterns within the business domain However, not all services need

to be reusable or should be depending on the business requirement

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

Trang 30

SOA Further Defined

– 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

IT infrastructure, ideally in an asynchronous manner.

Web services) to connect heterogeneous systems.

SOA Further Defined

SOA-based application development and integration solves many issues and shortcomings of the traditional approaches SOA describes a set of well-established patterns that help a client application connect to a service These patterns represent mechanisms used to describe a service, to advertise and discover a service, and to communicate with a service

Most communication middleware systems, such as Remote Procedure Call (RPC), Common Object Requesting Broker Architecture (CORBA), Distributed Component Object Model (DCOM),

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

However, there are differences between each implementation and weaknesses among them The primary issue has been acceptable standards and interoperability SOA is built upon these

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

granularity Instead, a service can be a function, an object, or an application SOA is, therefore, adaptable to any existing system and does not force the system to conform to any particular level of

Trang 31

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

Check Credit Card Verify Customer Address Account Setup Conduct Fraud Check

Integration Tier (Connectivity Service)

Assets /Systems

SOA Governance

Service Bus Mediation Application Centric Integration Service-Centric Integration

Moving Toward Service-Centric Integration

The slide depicts how a Web-based Banking application using point-to point integration can be migrated to service-centric integration using Service-Oriented Architecture (SOA)

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

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

systems/assets

• The Business Service layer includes the different business functionalities such as Checking Credit Card, Verifying Customer Address, Conducting Fraud Check and so on

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

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

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

Trang 32

SOA: A Paradigm Shift

Abstraction Known implementation

Message-oriented Object-oriented

Heterogeneous technology Homogeneous technology

Agile and adaptive Tightly coupled

Services orchestration Application block

Business-centered Cost-centered

Long development cycle

Service-Oriented Architecture

SOA: A Paradigm Shift

SOA is much more than a new software development model; it is a true paradigm shift The more powerful paradigm shift that you are seeing in most organizations is the shift in focus from

functionality and application to process and business Architects are now specifying the designs for services with names such as Get_Customer, Open_Order, or Get_Service_History Then together with their business partners, they whiteboard entire business processes by assembling these services One of the additional benefits of SOA involves the changed relationship between IT and business, bringing them closer to each other and helping each other There is more to this paradigm shift The development cycles will shrink, or rather, will go to high frequency deployments of smaller chunks

of capability instead of the large, lengthy development

Trang 33

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

Trang 34

The Eight-Domain Model Approach for SOA (continued)

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

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

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

to SOA including the organizational structure and skills development

Governance: Contains capabilities concerning the governance structures and processes that support

and guide the SOA efforts The maturity and adoption of an adequate amount of governance is a

leading indicator of the overall SOA success.

These eight domains, although interrelated, are sufficiently distinct To succeed at SOA adoption, an organization must adequately progress in all of these domains

Trang 35

Quiz

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

1 Business and Strategy

2 Architecture

3 Infrastructure

4 Information

5 Projects, Portfolios, and Services

6 Operations, Administration, and Management

7 Organization

8 Governance

Trang 36

Building an SOA Reference Architecture:

From Architecture Drivers to a Roadmap

Design an incremental plan to achieve the future vision.

Identify the stakeholders’ viewpoints

or concerns, prioritize SOA benefits, and examine the current reality.

Building an SOA Reference Architecture: From Architecture Drivers to a Roadmap

An SOA strategy is ideally established enterprise-wide but in many circumstances it may be

incubated within a line of business (LOB), or other subset of the full corporate entity In these cases, the limitations and compromises must be recognized at an early stage (such as the reduced value of

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

Both business and IT drivers should be collected (separately)

Examples of business drivers might be to:

• Improve efficiency in the call center

• Grow revenue faster than our peers in a sustainable way

• Simplify the assimilation of acquired companies

• Expand customer relationships, and so on

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

• Move from transaction focus to customer focus

• Move from silo LOB focus to process/service focus

Trang 37

SOA Reference Architecture

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

– 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

An SOA reference architecture promotes consistency and interoperability by defining wide principles, guidelines, and patterns

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

Trang 38

Composite Applications Web Apps Portals Mashups BPM Process Clients

Service Consumers and

Delivery Channels

Employees Customers Partners Client

Apps Partner Apps

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

Trang 39

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 Client

Apps Partner Apps

SOA Reference Architecture: Service Consumers

Service consumers include end users as well as applications that are users of SOA, but not

contributors of services These include :

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

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

Trang 40

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

Shared Services and Infrastructure

SOA Reference Architecture:

Service Classification

Service classifications and infrastructure requirements of Service-Oriented

Architecture

SOA Reference Architecture: Service Classification

Service classification is a logical grouping of types of services that meet specific needs and conform

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

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

The different service classifications are:

Định dạng
Số trang	404
Dung lượng	6,67 MB