SOA_Ch3.ppt

Service-Oriented Analysis and Modeling

Xiaoying Bai

Department of Computer Science and TechnologyTsinghua University

March 2007

23/4/12 2

Outline

• Model Driven Architecture

• Service-Oriented Analysis and Modeling: Methods and Process

• CASE tool: IBM WebSphere

• Case study

23/4/12 3

Service-Centered System Development

SOA Project Team

ServiceRegistry

ServiceSubmission

Service Audit

Center Of Excellence

Dep

loym

en

t &

Govern

an

ce

Imp

lem

en

tatio

n &

Com

positio

nA

naly

sis

&

Mod

elin

g

SOA Planning and Governance

SOA Values00

Modeling22

Design33

Development44

Integration55

Deployment &Management66

Monitoring11ServiceReuse

System Reconfiguration

Service Change

Management

23/4/12 4

IBM Foundation Architecture

Model Driven Architecture

23/4/12 6

Modeling Motivations

• Varieties of Platforms– Varieties of Hardware Architecture

• Pentium, PowerPC, PA-RISC, Sparc, 370, …

– Variety of Networks• Ethernet, ATM, IP, SS7, Applealk, USB, Firewire, …

– Variety of Programming Languages• C/C++. Java, VB, C#,…

– Variety of Operating Systems• Unix, Windows, NT/XP. Mainframe, Mobile, …

– Variety of Middlewares• JAVA/CORBA, COM+/.NET, Web Services, ….

23/4/12 7


• Integration challenges– Integration across middleware– System design across middleware

H/W

OS

App.

H/W

OS

App.

H/W

OS

App.

H/W

OS

App.

Middleware

H/W

OS

App.

H/W

OS

App.

H/W

OS

App.

H/W

OS

App.

Middleware

H/W

OS

App.

H/W

OS

App.

H/W

OS

App.

H/W

OS

App.

Middleware

Cross Middleware-Integration-System Design

23/4/12 8


• To allow definition of machine-readable application and data models which allow long-term flexibility of – Implementation

• New implementation infrastructure can be integrated or targeted by existing designs

– Integration• Automate the production of data integration bridges and the

connection to new integration infrastructures

– Maintenance• The design is available in a machine-readable form

– Testing and simulation• The developed models can be validated against requirements, tested

against various infrastructures and can used to directly simulate the behavior of the system being designed.

23/4/12 9

Role of Models

• Capture design information that is usually absent from code and lost during development

• Basis for– System generation– Analysis– Simulation – Test generation– Documentation generation– ….

• Domain-specificity of a modeling language strengthens its capabilities for generation, optimization, early error detection, etc.

23/4/12 10

OMG Modeling Activities

• 1989: OMG established• Standardization of Distributed Object Middleware

– 1995: CORBA 2; 2002: CORBA 3

• Modeling Standardization– 1997: UML (Unfied Modeling Language)– 1997: MOF (Meta Object Facility)– 1999: XMI (XML Metadata Interchange)– 2001: Application-Specific UML Profiles (EDOC, EAI)

• Architecture (Reference Model)– 1990: OMA (Object Management Architecture)– 2001: MDA (Model Driven Architecture)

• 2001-: starting standardization based on MDA

23/4/12 11

OMG Modeling Standards

• UML: Unified Modeling Language– Address the modeling of architecture, objects, interactions betwee

n objects, data modeling aspects as well as the design aspects including construction and assemble.

• XMI: XML Metadata Interchange – A standard interchange mechanism used between various tools, re

positories and middleware.

• MOF: Meta Object Facility– Provides the standard modeling and interchange constructs.

• MDA: Model Driven Architecture– Build upon and leveraging the value of OMG’s established modeli

ng standards– Can be realized using any major open or proprietary platform, incl

uding CORBA, Java, .NET, XMI/XML, and Web-Based platforms.

23/4/12 12

OMG Model-Driven Architecture

• Provides an open, vendor-neutral approach to the challenge of business and technology change.

• Separates the specification of the operation of a system from the details of the way that system uses the capabilities of its platform

• Provides an approach for, and enables tools to– Specify a system independently of the platform that supports it– Specify platforms– Choose a particular platform for the system, and – Transform the system specification into one for a particular

platform• The goals

– Portability, Interoperability, Reusability through Architectural Separation of Concerns

23/4/12 13

MDA in the Context

23/4/12 14

MDA Models

• CIM: Computation Independent Model – A computation independent view of the system– Articulates the requirements, but hides the details of implementation and

system implementation– Bridges the gap between domain experts and technology experts

• PIM: Platform Independent Model– A platform independent view of the system– Exhibits a sufficient degree of independence so as to enable its mapping

to one or more platforms– Achieved by defined a set of services in a way that abstracts technical

details. • PSM: Platform Specific Model

– A platform specific view of the system– Combines the specifications in PIM with the details that specify how that

system uses a particular type of platform

CIMCIM PIMPIM PSMPSM

23/4/12 15

Model Transformation

• Model transformation is the process of converting one model to another model of the same system.– Marking– Metamodel Transformation– Model Transformation– Pattern Application– Model Merging

CIMCIM

PIMPIM

PSMPSM

Tra

nsforma

tion

23/4/12 16

The MDA Story

Platform Independent Model (PIM)

Implementation In EJB

ebXML messageDefinition

Bridge

Platform Specific

Model (PSM)In ebXML

Platform Specific

Model (PSM)In CORBA

23/4/12 17

Impact of MDA on the Development Process

Requirement

Analysis

Desing

Coding

Testing

Deployment

Mostly text

Diagram& text

Diagram& text

code

code

IterativeProcess

Programmer’sshortcut

Traditional Lifecycle Process MDA Lifecycle Process

Requirement

Analysis

Desing

Coding

Testing

Deployment

CIM

PIM

PSM

code

code

MDAProcess

23/4/12 18

Benefits of MDA

• Preserving the investment in knowledge– Independent of implementation platform– Tacit knowledge made explicit

• Speed of development– Most of the implementation is generated

• Quality of implementation– Experts provides transformation templates

• Maintenance and documentation– Design and analysis models are not abandoned after

writing– 100% traceability from specification to implementation

Service-Oriented Analysis and Modeling: Method and Process

23/4/12 20

The SOA Layers

23/4/12 21

The SOA Layers

• Layer 1: Operational systems layer – Existing custom built applications, called legacy systems

• CRM and ERP packaged applications• older object-oriented system implementations, • business intelligence applications.

– To leverage existing systems and integrate them using service-oriented integration techniques.

• Layer 2: Enterprise components layer – Enterprise components that are responsible for realizing functionality and

maintaining the QoS of the exposed services. – Managed, governed set of enterprise assets that are funded at the enterpris

e or the business unit level. – T typically uses container-based technologies such as application servers t

o implement the components, workload management, high-availability, and load balancing.

23/4/12 22

The SOA Layers

• Layer 3: Services layer. – The services the business chooses to fund and expose – Can be discovered or be statically bound and then invoked, or possibly,

choreographed into a composite service. – Mechanism to take enterprise scale components, business unit specific

components, and in some cases, project-specific components, and externalizes a subset of their interfaces in the form of service descriptions.

– Provide service realization at runtime using the functionality provided by their interfaces.

– Exist in isolation or as a composite service.

• Level 4: Business process composition or choreography layer – Services are bundled into a flow through orchestration or choreography,

and thus act together as a single application. – These applications support specific use cases and business processes.

23/4/12 23

The SOA Layers

• Layer 5: Access or presentation layer. – SOA decouples the user interface from the components, the layer provides

an access channel to a service or composition of services.

• Level 6: Integration (ESB). – Enables the integration of services through the introduction of a reliable se

t of capabilities, such as intelligent routing, protocol mediation, and other transformation mechanisms, often described as the ESB.

• Level 7: QoS. – The capabilities required to monitor, manage, and maintain QoS such as s

ecurity, performance, and availability. – A background process through sense-and-respond mechanisms and tools t

hat monitor the health of SOA applications.

23/4/12 24

Service-Oriented Modeling & Analysis

• Modeling, analysis, design techniques and activities to define the foundations of a SOA. – Define the elements in each of the SOA layers

– Make critical architectural decisions at each level.

– Hybrid approach• Top-down: business driven

• Bottom-up: leverage legacy investments

Software

Skills &Support

23/4/12 25

Why OOAD, BPM, EA are not enough

OOAD: Object-Oriented analysis & DesignBPM: Business Process ModelingEA: Enterprise Architecture

Service-Oriented Modeling & Analysis

23/4/12 26


• OOAD– low level of granularity at the class level– low level of abstraction for business service modeling– Strong associations such as inheritance, resulting in tight coupling

(and, consequently, a dependency) between the involved parties • BPM

– a fragmented discipline in which there are many different styles, notations, and assets.

• EA– No business-level process or service view– Generic architecture, and do not reach down to the design domain;

a fundamental gap between enterprise and solution architectures

23/4/12 27


Object-Oriented

ClassLayer

ComponentLayer

Service Layer

Component-Oriented

Service-Oriented

23/4/12 28


VacancyComponent

ApplicationComponent

Emp. RecordComponent

CareerComponent

RecruitmentService

Employee Service

Recruitment Employee

ManageEmployees

Human Resources

FunctionalDomain

SoftwareComponent

BusinessProcess

BusinessServices

SoftwareServices

BusinessLayer

ServiceLayer

ComponentLayer

23/4/12 29

Service-Oriented Modeling & Analysis: Roles & Activities

ServiceIdentification

ServiceCategorization

ServiceExposureDecisions

ChoreographyOr

Composition

Quality of service

CustomerView

ComponentIdentification

ServiceAllocation toComponents

ComponentSpecification

Layering theComponent

Servicerealization

Technical Prototyping

ServiceManagement

Product selection

Standardsimplementation

ArchitecturalDecisions

(state, flow,Dependencies)

ProviderView

23/4/12 30

SOA Design Principles

• Service categorization and aggregation

• Policies and aspects

• Process: meet-in-the-middle

• Broking

23/4/12 31

Service-Oriented Modeling & Analysis: Method & Process

Domain Decomposition

Goal-Service Modeling

Existing System Analysis

Component Flowspecification

Informationspecification

SubsystemAnalysis

Component specification

Service Flowspecification

Message & eventspecification

Service realization decisionsService allocation

to componentsComponent layer

Identification

Specification

Realization

Servicespecification

23/4/12 32

Service Identification

• Identifies services through– Domain decomposition (Top down analysis)

– Existing system analysis (Bottom up analysis)

– Goal service modeling

Identification

Specification

Realization




Service Repository

Top-DownAnalysis

Bottom-UpAnalysis

Align Service withBusiness Goals

23/4/12 33


• Top-down – Blueprint of business use cases provides the specification for

business services

– Domain decomposition: decompose of the business domain into its functional areas and subsystems

• Flow or process decomposition into processes, sub-processes, and high-level business use cases

• Use cases are good candidates for business services– Exposed at the edge of the enterprise

– Within the boundaries of the enterprise across lines of business






SubsystemAnalysis






Identification

Specification

Realization


23/4/12 34


• Bottom-up– Process or existing system analysis

– Existing systems are analyzed and selected as viable candidates for providing lower cost solutions to the implementation of underlying service functionality that supports the business process

– Analyze and leverage API’s, transactions, and modules from legacy and packaged applications.

– Componentization of the legacy systems is needed to re-modularize the existing assets for supporting service functionality






SubsystemAnalysis






Identification

Specification

Realization


23/4/12 35


• Middle-Out – Goal-service modeling

• Identify Goals and Sub-Goals

• Identify Services for Sub-goals

• Identify key performance indicators & metrics for sub-goals and services






SubsystemAnalysis






Identification

Specification

Realization


23/4/12 36

Service Specification

• Service categorization

• Service flow specification

• Message and events specification

• Subsystem analysis

• Component specification

Identification

Specification

Realization

23/4/12 37







SubsystemAnalysis




Service realization decisCionsService allocation


Identification

Specification

Realization


• Service Classification or Categorization– Classify services into a service hierarchy, reflecting the composite

or fractal nature of services• Services can and should be composed of finer-grained components

and services. • Classification helps determine composition and layering, as well as

coordinates building of interdependent services based on the hierarchy.

• Alleviate the service proliferation syndrome

23/4/12 38


• Subsystem Analysis – Specify the interdependencies and flow between the

subsystems. – Identify the exposed services on the subsystem

interface based on use cases identified during domain decomposition

– Create subsystem internal design models – Identify the implementation construct of large-grained

components realizing the services






SubsystemAnalysis




Service realization decisCionsService allocation


Identification

Specification

Realization


23/4/12 39


• Component Specification – Specify the details of the component that implement the

services• Data • Rules • Services • Configurable profile • Variations

– Specify and manage the messaging and events






SubsystemAnalysis






Identification

Specification

Realization


23/4/12 40

Service Realization

• Decision making of service realization approach

• Allocation services to components

• Allocation components to SOA layers

Identification

Specification

Realization

23/4/12 41

Service Realization

• Service Allocation – Assign the services to the subsystems that have been identified so

far, which have enterprise components that realize their published functionality.

– Assign the services and the components that realize them to the SOA layers.

• Documentation and resolution of key architectural decisions – The application architecture– The technical operational architecture– Designed and used to support the SOA realization at runtime.






SubsystemAnalysis






Identification

Specification

Realization


23/4/12 42

Service Realization

• Service Realization Decision

– Realize services and components, choose from realization alternatives

• selected from existing library

• custom built

• Integration

• transformation

• subscription and outsourcing

– Other realization decisions for services other than business functionality include: security, management and monitoring of services.






SubsystemAnalysis






Identification

Specification

Realization


CASE Tool: IBM WebSphere

23/4/12 44

IBM WebSphere Integration Reference Architecture

Business Application Services

ProcessServices

Information Services

Development Services

Interaction Services

Partner Services

Connectivity Services

Business Innovation and Optimization Services

Architect Developer Tester Business Analyst

Integration Developer

Dashboards

Portlets Business Processes

Data Models

Partner Profiles App Components Adapters

Application & Information Assets

IT Services Management

WebSphere Business Modeler Rational/WebSphere Tools

23/4/12 45

WebSphere Business Modeler

• A business process modeling tool that– model, design, analyze and generate reports for

business processes– integrate new and revised workflows– define organizations, resources, and business items

• Objectives– Documenting existing procedures – Determining requirements for staff, systems, and

facilities – Planning changes to existing processes and systems – Testing and analyzing existing and proposed processes

23/4/12 46

Business Modeling

• Model, simulate, and measure business processes – Process modeling– Business item modeling– Resource modeling– Organization modeling– Structure modeling– Analysis– Process simulation

23/4/12 47

Business Modeling Modes

• Basic Business Modeling mode– business analyst , high-level view of a business process model. – Create and display sequence flows

• Intermediate Business Modeling mode – More technically focused user– Specify and view additional details of process and data models.

• For example, business rules and logic, data attributes.

• Advanced Business Modeling mode – Most comprehensive level of detail for process models and data

models.– Models that will be used as the basis for software applications.

• For example, invocation characteristics, static fields, instance correlations, and a larger set of simulation parameters.

23/4/12 48

Business Item Modeling

• Any business document, work product, or commodity that is used for a particular business operation.

• Anything that is created, assembled, inspected, tested, modified, or worked upon.

• Business items can also undergo changes as they are passed from one step to the next in the process models. – For example, a customer order could be specified as open,

working, verified, and finally closed as it is passed from task to task in a particular process model.

23/4/12 49

Resource Modeling

• Model each of the company's resources, such as employees, computers, vehicles, or electricity.

• Any person, equipment, or material used to perform a task or a project can be represented and used in the process models.

• Depending on the level of complexity required in the process models, one can also specify roles, costs, and timetables for the resources.

23/4/12 50

Process Modeling

• Business Process Diagram– Processes describe a sequence of tasks and processes linked by connectors.

– A process can contain multiple branching paths based on decisions made

during the process execution. – A process can also contain sub-processes.

• Two modeling modes– The free-form layout: maximum flexibility to arrange the process diagram

s. – The swimlane layout: arranges elements in rows according to characteristi

cs that you specify, such as organization unit, location, resource definition, role or classifier.

23/4/12 51

Business Process Model

Task

Decision

Branches

Merge

Stop

Task Classification

23/4/12 52

ProjectTree

OutlineView

ProcessEditor

AttributeView

WebSphere Business Modeler

Case Study

23/4/12 54

汽车贷款审批流程

汽车销售商信贷经理信贷员申请人保险公司

申请担保

提供担保

申请贷款受理申请

查询用户历史存款记录

查询用户历史房贷记录

查询用户历史车贷记录

评估信用等级

发送拒绝贷款通知

审批

是否发放贷款

接收拒绝通知

核定贷款金额、期限

用户确认贷款金额、期限

发放贷款接受贷款并发货

批准

拒绝

确认购车价格

汽车贷款流程

23/4/12 55

SOA Values

业务目标 SOA 价值现有问题

降低成本

降低欺诈风险

建立集中的企业服务总线，屏蔽具体的服务实现，保持 IT系统的柔性

流程自动化，提供实时的流程监控和管理

客户专员获取客户历史记录，然后人工计算风险等级

由于各地的业务差别，计算风险等级的政策不一致

在申请过程中，客户以及客户代表无法了解申请进度并及时反馈

引入业务规则作为服务实现方式，保证系统灵活性的同时，提高工作效率

23/4/12 56

Busi nessAdmi ni strati on

ProductManagement

Acqui si ti onsCustomer

Portfol i o MgmtCustomer Servi ce

and Sal es

Busi ness Pl anni ng

Busi nessArchi tecture

Sector Marketi ngPl ans

Engi neeri ng Products

Acqui si ti on Pl anni ngand Oversi ght

Customer Porfol i o

Credi t and Ri skManagement

Cust. Servi ce andSal es pl anni ng

Di rect

Control

Busi ness Uni tAdmi ni strati on

Manage Al l i anceRel ati onshi ps

Pol i cy & ProcedureManual s

ER Management

Product Devel opment& Depl oyment

Customer Target Li stAppl i cati onProcessi ng

Customer Behavi orDeci si oni ng

Case Handl i ng

Servi ce / Sal esAdmi ni strati on

Execute

Admi ni sterAl l i ance SLAs

Audi t/ QA/ Legal

Faci l i ti es

Devel op and OperateSystem

Accounti ng and G/L

Marketi ng

Market Research

Product Di rectory

Target Li sts(Prospecti ng)

Campai gn Executi on

Customer Profi l e

Contact / EventHi story

Correspondence

Sal es and Cross-Sel l

Servi ci ng (Di al ogHandl er)

Smart Routi ng

Business Components

Business Goal

BG1 减低成本

PKI1.1 10%销售成本降低

PKI1.2 10%生产成本降低

PKI1.3 85%用户自助服务比率提高到

汽车贷款服务

BG2 降低欺诈风险

PKI2.1 坏账率到3%以下

Business Process

Modeling Inputs

23/4/12 57

1.1存款

0 存贷款流程

1.2汽车贷款

1.2.1申请贷款

1.2.2确认申请

1.2.3评估信用等级

1.2.4核定期限

1.2.5审批

1.2.6担保

1.2.7发放贷款

1.2.3.1获取存款记录

1.2.3.2获取贷款记录

1.2.3.3计算信用等级

1.2.6.1申请担保

1.2.6.2提供担保

Business Process Decomposition

23/4/12 58

Key Performance Indicator Analysis

业务目标关键业务指标相关服务

BG.1 降低成本

BG.2 降低欺诈风险

销售成本降低 10%

坏账率到 3%以下

用户自服务比率提高到 85%

1.2.1 申请贷款

1.2.2 确认申请

1.2.3 评估信用等级

1.2.3.1 获取存款记录

1.2.3.2 获取贷款记录

1.2.3.3 计算信用等级

1.2.4 核定期限

1.2.5 审批

1.2.6 担保

1.2.6.1 申请担保

1.2.6.2 提供担保

1.2.7 发放贷款

BG1 减低成本

PKI1.1 10%销售成本降低

PKI1.2 10%生产成本降低

PKI1.3 85%用户自助服务比率提高到

汽车贷款服务

BG2 降低欺诈风险

PKI2.1 坏账率到3%以下

23/4/12 59


系统编号

系统名称相关服务平台接口类型

APP1 贷款系统获取贷款记录

AIXWAS v5

EJB

APP2 核心系统获取存款记录

CICS/390

Terminal

APP3 保险公司担保系统

提供担保 Windows.NET

Fax/CallWeb Service

APP1 CRM

验证用户资格

汽车贷款服务

APP2 呼叫中心

验证用户资格

APP2 信用查询代理

获取信用记录

23/4/12 60

Service Identification, Composition and Categorization

• 客户服务– 1.2.1 申请贷款– 1.2.2 确认申请– 1.2.3.1 获取存款记录– 1.2.3.2 获取贷款记录– 1.2.4 核定期限– 1.2.5 审批– 1.2.6 担保– 1.2.6.1 申请担保– 1.2.6.2 提供担保– 1.2.7 发放贷款

• 风险管理– 1.2.3 评估信用等级– 1.2.3.3 计算信用等级

客户目录

1.3.1.1 验证客户资格

1.3.1.4 补充申请材料

1.3.1.5 终审

汽车贷款服务

风险管理

1.3.1.3 评估信用等级

客户服务

1.3.1 订货

1.3.1.2 初审

1.3.1.3.1 获取信用记录

1.3.1.3.2 计算信用等级

23/4/12 61

Business Modeling

Business Data Modeling

Business Process Modeling

Organization Modeling

Simulation Report

Business Monitoring

23/4/12 62

Process Simulation

• To find bottleneck before system deployment

• Optimize resource allocation based on the statistical analysis of the sources consumption

Simulation Control

Real Time Simulation Statistics

Simulation Time

Current Process

BottleneckQueue

23/4/12 63

Summary

• Analysis and modeling is a critical process in business-driven, service-centered system development.

• SOA follows the model driven approach, which defines an automated transformation process from computation independent model to platform independent model to platform specific model.

• SOMA identifies the key activities of service identification, specification and realization.

23/4/12 64

Reference

• Frank Truyen, “The Fast Guide to Model Driven Architecture”, Cephas Consulting Corp., 2006.

• OMG, “MDA Guide Version 1.0.1”, 2003.• Krzysztof Czarnecki, “Model Driven Architecture”, 2004.• Olaf Zimmermann, Pal Krogdahl, and Clive Gee, “Elemen

ts of Service-Oriented Analysis and Design”, June 2004.• Ali Arsanjani, “Service-Oriented Modeling and Architectu

re”, Nov. 2004. • Keith Leve and Ali Arsanjani, “A Goal-driven Approach t

o Enterprise Component Identification and Specification”, Communications of the ACM, Oct. 2002.

SOA_Ch3.ppt

Documents

modeling of architecture

middleware hw os app

modeldriven architecture

modeling standardization

platform specific model

middleware system design

standard modeling

mda model driven architecture