© 2006 ibm corporation building information society with innovation business process...

© 2006 IBM Corporation

Building Information Society with Innovation

Business Process Transformation: Componentization

András Pataricza,Budapest University of Technology and Economics

University Relations

Academic Days | May 9-10, 2006 | Barcelona, Spain

2


University Relations -- Academic Days | May 9-10, 2006 | Barcelona, Spain © 2006 IBM Corporation

Service Oriented Architecture

3



SOA reference architecture

Dev

elo

pm

en

t S

erv

ice

s

Business Innovation and Optimization Services

Interaction Services

Process Services

Information Services

Enterprise Service Bus

IT S

ervi

ce

Man

age

me

nt

Partner Services

Business Application

Services

Ap

pli

cat

ion

sAccess Services

Infrastructure Services

Modeling, composition Deployment/implementation Monitoring

4



SOA lifecycle

Requirement analysismodeling & simulationdesign

design testing

Integrationhumanprocessinformation

Application and service monitoring

Identity managementBusiness indicators

FinancialBusiness/IT harmonizationProcess control

5



Model-Driven Architecture for Classical Approaches

ModelXform.

Code Generation

Source code

PlatformIndependent

Model

PlatformSpecificModel

platformdescription

6



Model-Driven Architecture for SOA

ModelXform.

Service mapping

+deployment

Service invocationBusiness workflow

Configuration

PlatformIndependent

Model


ServiceCatalogue/Standard

(eg. BPEL)



Componentization and requirements

A functionally correct system has to fulfill additional non-functional requirements, as well

8



Requirement classes

9



SOA systems are vulnerable

Dev

elo

pm

en

t S

erv

ice

s

Business Innovation and Optimization Services

Interaction Services

Process Services

Information Services


IT S

ervi

ce

Man

age

me

nt

Partner Services

Business Application

Services

Ap

pli

cat

ion

sAccess Services

Infrastructure Services

Modeling, composition Deployment/implementation Monitoring

ComplexityCompletenessConsistency

PlatformsOutsourcing?

Parasitic interaction

Not ownedAvailabilityReliability

Complexity?Correctness?

Compliance to standards

Security

10



V&V problems in non-functional design

Proof of correctness

Performance prediction

Qualitative dependabilityassessment(fault impact

analysis)

Damage confinement and recovery Error detection

Performability control

Availability … prediction

SLA requirements specification

Quantitative dependabilityassessment



Core: Mathematical Analysis

Huge complexity ->Importance of mathematical analysis integrated into the design workflow

12



Engineeringmodel

Implementation

Design

Mathematicalmodel

Automatedmodel generation

Analysis tool

Mathematical analysis

Back-annotation

Code generation

Mechanized approach

13



Transformation development

Metamodels

Graph transformation rules

Transformation control structure

Transformation development &

testing

Source modelNative transformation

pluginTarget model

Transformation trace, debug information

Plu

gin

gene

rato

rTransformation design time

Transformation runtime

14



VIATRA 2 as Eclipse Generative Model Transformer

GMT is an independent part of the Eclipse Modeling Project led by IBM and Borland



Design verification

Complex, critical business processes require a proof of correctness covering ALL the cases of operations


16



Objectives

Service composition (e.g. BPEL)– Widespread tool support

– Design errors in choreography

– Lack of formal verification

Objectives:– Formal proof of compliance to the requirements on workflow

– Derivation of mathematical analysis models by model transformations

Formal analysis of workflows– Formal workflow semantics

– Formal verification of properties

– E.g. variable access

– Fault simulation: assessment of error propagation

17



A Workflow Example

RecordingEstablish

type

Policy

Premium

Reject

Basic activity

Beginning of parallel execution

End of parallel execution

PayControl flow

Selection

18



Verification of Workflows

Workflow (BPEL)

Formal model

(dataflow network)

Analysis model

(Promela)

Model checker(SPIN )

Requirement (LTL

expression)

Positive result

Negative result +

counterexample

Simulation

19




Workflow (BPEL)

Formal model

(dataflow network)

Analysis model

(Promela)

SPIN modelchecker

Requirement (LTL

expression)

Positive result

Negative result +

counterexample

Simulation

IBM WebSphereIntegration Developer

20



Verification of WorkflowsDataflow Network

(generated)• Abstract data• Hierarchic modeling • Model refinement

Workflow (BPEL)

Formal model

(dataflow network)

Analysis model

(Promela)

SPIN modelchecker

Requirement (LTL

expression)

Positive result

Negative result +

counterexample

Simulation

Representation in the VIATRA2 framework

• Dataflow Network generated from parsed BPEL model

21




Workflow (BPEL)

Formal model

(dataflow network)

Analysis model

(Promela)

SPIN modelchecker

Requirement (LTL

expression)

Positive result

Negative result +

counterexample

Simulation

Requirements• LTL: linear temporal logical expression

Target requirement•Business level: „no unauthorized business transaction” •Implementation level: „each variable should be initialized prior to a read access”

22



Workflow (BPEL)

Formal model

(dataflow network)

Analysis model

(Promela)

SPIN modelchecker

Requirement (LTL

expression)

Positive result

Negative result +

counterexample

Simulation


Model checker• Evaluation of LTL expressions• Exhaustive state space traversal

23



Workflow (BPEL)

Formal model

(dataflow network)

Analysis model

(Promela)

SPIN modelchecker

Requirement (LTL

expression)

Positive result

Negative result +

counterexample

Simulation


ModelltranszformációModel transformationVIATRA2 framework

24



Abstraction: qualitative modeling

Formal methods have strict complexity limitations– Efficient, but still faithful abstractions are needed

Qualitative abstraction:– A few of qualitative values out of an enumerated data type set

– No detailed data representation

– Drastic state space (analysis complexity) reduction

Systematic methodology: predicate abstraction

25



Example Full model:

IF credit_requested < 2.000.000 THEN approval(director) ELSE approval(board)

Deterministic abstraction:IF minor_credit_requested THEN approval(director) ELSE approval(board)

– No representation is needed for value of credit_requested,

– Only a single binary value (minor_credit_requested) representing the mode of operation

– Invariant wrt. the limit of 2.000.000 changes

Nondeterministic abstraction:CHOOSE (approval(director), approval(board))

– No representation is needed for value of credit_requested,

– No representation of the logic of selecting the mode of operation

– Details -> random behavior

26



Estimation of the effects of a fault in a business workflow

A resource/operation is good / faulty / missing (FAULT) → System behavior ?

Analysis principle:– Assign faults to resources / operations

– Trace the flow of errors (ERROR)

– Check: is a service to the user affected (FAILURE) ?

Modeling and analysis:– Data items colored as good / faulty / suspicious

– A component connected to another one in a potentially erroneous state is suspicious

– Static worst case approximation: Damage Confinement Region

27



Dataflow Networks

G(Variable.state!=Fault_written)

Variable Uninitialized Written Read Written and read Fault written Fault written and read

Activity Control Data D_F_Control

Node

State

Port

ChannelToken

28



Mapping a Workflow to Dataflow Networks

RecordingEstablish

type

Policy

Premium

Recording Establish type

Beginningof parallelexecution

End of parallel Execution

Policy

Premium



Early dependability assessment

Objective: identification of the critical processes and their dependence on services and resourcesReinforcement of the workflow (ABFT)

30



Systematic analysis techniques (overview)

1. Fault tree analysis

2. Event tree analysis

3. Cause-consequence analysis

4. Failure mode and effects analysis (FMEA)

→ Risk matrix with acceptable hazards

31



Fault tree analysisService

unavailable

Failure of servers

Primaryserverfailure

Networkswitchfailure

Secondaryserverfailure

Failoverunsuccessful

HAmiddleware

failure

Server software designfailure

SPOF

PossibleSPOF

(not analyzed)

System leveleffect

Basicevents

Serviceunavailable

Serviceunavailable

Failure of servers





Secondaryserverfailure



HAmiddleware

failure

Server software designfailure

SPOF

PossibleSPOF

(not analyzed)

System leveleffect

Basicevents

32



Quantitative analysis

Probabilities assigned to basic events– Component data book, estimation, measurements

Probability of system level failure is computed– AND gate: product of probabilities

– OR gate: sum of probabilities

Independent basic events are assumed here. Problems:

– Correlated basic events

– Handling the scenario of basic events (fault tree is a static snapshot)

33



Failure mode and effects analysis

Failures and system level effects are listed Advantages:

– Systematic analysis of component failures

– Efficiency of redundancy can be estimated

Component Failure mode Probability Effect

Network switch

- garbage out - broken link

35% 65%

- access denied

- service timeout

... ... ... ...

34



Risk matrix and acceptable hazards

Hazard effect Catastrophic Critical Marginal Negligible

Frequent

Probable Network switch failure

Primary server failure

Occasional Server sw. failure

Secondary server failure

Remote HA middleware failure

Improbable

Impossible

Protectionlevel

35



Dynamics: Qualitative Data Fault Simulation / Model Checking

Variable 1 Uninitialized Written Read Written and read Fault written Fault written and read

Activity A Read Control Data D_F_Control

Variable 2 Uninitialized Written Read Written and read Fault written Fault written and read

Activity A Write Control Data D_F_Control

36



Simulation of the Error Propagation Dynamics

Variable Uninitialized Written Read Written and read Fault written Fault written and read

If Control Data D_F_Control

Otherwise Control



37



Dependable design patterns

Critical elements of the model can be replaced

N-Version programming– Here: N-Version Invocation

– Simultaneous invocation of multiple service implementations (variants)

Recovery Block– Here: Sequential invocation

of variants

– Until the result is acceptable

– Adjudicator?

Version 1

Version N

Version 2 VOTER

Version 1

Version N

Version 2

Fails

Fails



Quantitative Dependability Analysis

Prediction of quantitative service/business level characteristics


Availability … predictionSLA

requirements specification


39



Objectives

Composite services Composed of basic service components Only partial control over the different servicesAnalysis of composite services According to SLA parameters of services

(e.g. throughput, reliability, availability) User perceived service:

potentially different service levels for different users Required parameters for the invoked services Guaranteed parameters for the main serviceNon-functional analysis PREDICTION of

– Dependability metrics for the services

– Business impacts WHAT-IF analysis

40



Phased Mission SystemsUpper layer: phases

•Operational life•Tree or cyclic Petri Net•One active phase („performing action X”)•Routing may depend on resource states

DEEM tool •Dependability Evaluation of Multiple-phased Systems•Representation: Deterministic and Stochastic Petri Nets•Evaluation: Markov Regenerative Processes•Developed in Pisa/Florence

Multiple Phased Systems •Systems which lifecycle consists of different phases•Phases have different resource characteristics

•Expected response time•Failure rate, etc.

Lower layer: resources•Representing the state of the system•Characteristics depend on the actual phase

41



Example: Phased Mission Systems

Stochastic modeling Phased operational life System changes during the phases

– E.g. resource states

System characteristics depend on the actual phase– E.g. phase-dependent failure rates

Mission goal depends on system state– Degradation

Dependability modeling and analysis– Described as GSPN

– Originally for mission-critical systems

42



SOA service flows as PMS

SOA service flow as PMS The operational life is built of distinct steps

– Web service invocations are the phases

– The dependability requirements of the phases are different

– Based on Service Level Agreements– The execution of the phases depends on the result of

previous steps

– Restricted operation if a service invocations fails Dependability of the main service Bottleneck analysis Sensitivity analysis

– Component’s failure rate System dependability

43



Modeling vs monitoring based SOA lifecycle

Process modeling and analysis RT data acquisition and monitoring

112

2

3

45

678

9

10

11


Service (J2EE)

Service (Web)

Service (e-mail)

IMS transaction

Service (human)

Hitelkérelem létrehozása

Előzetesen jóváhagyva?(üzleti szabály)

START

IGEN

Hitelképesség-ellenőrzés

NEM

Fedezet foglalása

Hitelbírálati jóváhagyás

Hitelkockázat értékeléseJóváhagyva?

Elutasító email küldése

IGEN

NEM

Kockázatos?(Üzleti szabály)

IGEN

NEMElfogadás email küldése

VÉGE

Service (human)

Service (Web)



Model-based optimization ofService Deployment

Availability aware deployment of services:integrated deployment design and optimizationunder cost and performance constraints


Availability …

prediction



45



Objective

Enterprise Information Systems– Towards Service Oriented Architecture

System development– Model-Driven Architecture

Quality aspects of services– Growing importance

Simultaneous assurance of – Required availability level

– Performance

– Cost minimization

46



Model-Driven Architecture + QoS analysis

ModelXform.

CodeGeneration

Source code

PlatformIndependent

Model


QoSmodel &

properties

platformdescription

QoSanalysis

Analysisresults

47



Model-Driven Architecture + QoS-based synthesis

ModelXform.

CodeGeneration

Source code

PlatformIndependent

Model


QoSmodel &

properties

platformdescription

QoSsynthesis

Synthesisresults

48



Architecture Synthesis – Design space

Total Cost of Ownership(TCO)

Availability Capacity

49



J2EE Architecture

J2EE Server

CORBAServer

IIOP

LDAP

RDBMSSQL

MessageQueue

JMS

EJB ContainerRMI

Client

EJB Container

IIOPClient

JSP ServletServlet Container

HTTPClient Other

Resource

???

HTTP Engine

JDBC

• Entity beans• Persistence management

• Backend services• messaging• authentication• databases

•Session beans•Business logic•Service access points

• Servlets and Java Server Pages• Web-based user interface

50



QoS model for services

Stand-alone components– QoS attributes

– Capacity requirement (throughput)

– Availability requirement Links

– Represents single usage relationship

– Directed

– QoS attributes are propagated

ServiceAA = 99.99%, C=100/min

ServiceBA = 99.99%

«StatelessSessionBean»Serv iceA

+ operation() : void

tagsQOS_Availabil ity: 99.99%QOS_Capacity: 100

«StatelessSessionBean»Serv iceB

+ op() : void

tagsQOS_Availabil ity: 99.99%

«uses»

51



General Resource Model

Applicationcomponent<<Client>>

Server computer<<Resource>>

Deploys to

QoSValueRequiredQoS

OfferedQoS

52



Mapping components to the QoS Model

Fault model– Hardware components

– Independent faults

– Operating system

– Application server software

– The application components are treated fault-free

– Majority of the code – automatically generated– Formally verified

QoS Service Component– EJB Module

– atomic deployment unit Component availability

– Max(required availability for the services) < minimal availability of the runtime platform running the beans in the module

Capacity requirements– Sum of capacity reqs. of the contained

beans

53



Architecture Optimization – Objective Function

HWm

System musednumbermTCOTCO )(_)(

System

Node1 Node2 Node3 Node4 Node5

Total Cost of Ownership of the system

Total Cost of Ownership of the specific node type

Actual number of nodes from the specified type

54



Architecture Optimization – Component Workload Balance

)(

)()(_)(idependsj

jWorkloadineedCapacityiWorkload

)(

)()(_)(idependsj


Service1W = 100

Service2W = 50

Service3C = 150

Actual workload of the specified component

Defined direct load of the component

Indirect workload from depending services

55



Architecture Optimization – Component Throughput Limits

)(

)()(_)(idependsj


)(

)()(:mdeployeds

sWorkloadSFmCapacityHWm

Service1W = 100

Service2W = 50

Service3W = 150

Node1C = 200

Node2C= 200

A specific hardware node of the system

Capacity of node m(from benchmark)

Saturation factorThe maximum load (0..1) on the machine

Aggregate workload of all components running on the node.

56



Architecture Optimization – Availability Effect of Interactions

)(

)()(_)(idependsj


serviceneededrunning)j(HW,j

)j(HW)i(HW

srvc.reqrunning

HWall

act

AA)availHW(P)availableHW(P

)availableservicesneededAllavailableHW(P)i(A

Service1 Service2Service3

A = ?

Node1A = 99

Node2A = 99

Actual availability of the componentAvailability of the deployment target HW

Availability of the deployment target HW of invoked services

57



Architecture Optimization – Availability Requirements

Constraints cont’d

)(

)()(_)(idependsj


)i(A)i(A:servicesi requiredact

Actual availability of the component

Required availability of the component



Dependability consolidation

Numerous applications implemented with no dependability considerations, but delivering business critical services ?

59



IT Service Management Processes are Interdependent

Service LevelManagement Framework

Service Catalogue

Service LevelAgreements

Evaluate andReport

Service LevelAchievements

Assess Service Level

Results

FormulateService LevelImprovement

Plan

EvaluateService LevelManagementPerformance

DetermineAvailability

Requirements

FormulateAvailability

Criteria

DefineAvailability

Targets

EstablishMeasures

and Reporting

Monitor, Analyze, and

Report

InvestigateUnavailability

ProduceAvailability

Plan

Availability Management

Service Level Management

Detect and Record Incident

Classification and Initial Support

Investigate and

Diagnose

Resolution and

Recovery

Own, Monitor, Track, and

Communicate

Close Incidents

Incident Reports

Incident Management

IT FinancialManagement Framework

Plan and Control

IT Budgets

PerformIT FinancialAccounting

AdministerIT Charging

EvaluateManagementPerformance

IT Financial Management

60



Today’s Service Visibility Challenges

Exploding complexity Accelerated change Silo-based management views Visibility is the key to success

– Know and control what you have

– Change it effectively

Automated architecture discovery – IBM Tivoli Application Dependency Discovery Manager (TADDM)

Components and interdependencies ALL THE FORMAL METHODS PRESENTED BEFORE CAN BE

(RE)USED!

61



How TADDM Works

API

Discovery Engine & Sensors

Data Center Reference Model

Application Mapping Database

Run-Time Environment

External Applications

TADDMClient

TADDM Server

62



Automated Application Maps Provides the Visibility

Application Service Management

INVENTORY ORDER ENTRY LOGISTICS PRICINGAUTOMATED APPLICATION INFRASTRUCTURE MAPS

INVENTORY ORDER ENTRY LOGISTICS PRICING

InfrastructureComponent Monitors



Service Availability Forum

Platform consolidationFine granular redundancy, fast error detection and recovery are key factors in HA


Availability prediction

64



SA Forum and objectives

A consortium of industry-leading companies:– Network Equipment Providers

– Computer System Vendors

– Silicon, Board and System Platform Providers

– System Integrators

– Application, Middleware and Operating System Vendors

Mission: – enable the use of commercial off-the-shelf building blocks

in the creation of high availability network infrastructure services

Approach: – Develop and publish HA and management software interface specifications

– Promote and facilitate their adoption by the industry

65



Systems Management

Interface

Hardware Platform Interface

(HPI)

Application Interface

Specification (AIS)

Application Management Framework

(AMF)

Carrier Grade OSCarrier Grade OS

Hardware Platform Hardware Platform

Communications FabricCommunications Fabric

Application Management FrameworkApplication Management Framework

SMI

SMI

Oth

er

Mid

dle

wa

re

Highly Available Applications

HPI

HA Middleware

Application Interface Specification

SA Forum Standard Interface Specifications

66



Application Management FrameworkApplication Management Framework

Application Interface SpecificationApplication Interface Specification

Components Service Units

Node 1 Node 2 Node 3

Cluster

Service Group : 2 + 1 redundancy

Service Group : 1+1

Redundancy

SG 1+1

Application Management Framework (AMF)

67



Application Interface Specification (AIS)




Cluster MembershipBookkeeping of nodes joining and leaving the cluster


CheckpointService

CheckpointService

EventServiceEvent

ServiceMessaging

ServiceMessaging

ServiceLockingServiceLockingService

Notification ServiceNotification ServiceLoggingService

LoggingService






CheckpointService

CheckpointService

EventServiceEvent

ServiceMessaging

ServiceMessaging



LoggingService




CheckpointService

CheckpointService

EventServiceEvent

ServiceMessaging

ServiceMessaging



LoggingService



CheckpointService

CheckpointService

EventServiceEvent

ServiceMessaging

ServiceMessaging



LoggingService

68




Performance prediction

Qualitative dependabilityassessment(fault impact

analysis)

Damage confinement and

recovery Error detectionPerformability

control

Availability … prediction



Conclusion

Non-functional requirements are critical to business success

The entire lifecycle has to be covered

40 years of fault-tolerant computing research can be reused

Ongoing research and development

– University

– Spinoff (optXware)

Internationally– ReSIST NoE

© 2006 ibm corporation building information society with innovation business process...

Documents

spain slide

soa slide

innovation componentization

standards security slide

modeldriven architecture

soa systems

parasitic interaction

requirement classes