Business Process Transformation

Transcription

1 Building Information Society with Innovation Business Process Transformation Based on the presentation of András Pataricza, Budapest University of Technology and IBM Academic Days 2006 University Relations Academic Days May 9-10, 2006 Barcelona, Spain

2 Service Oriented Architecture 2

3 Applications Development Services IT Service Management SOA reference architecture Business Innovation and Optimization Services Interaction Services Process Services Information Services Enterprise Service Bus Partner Services Business Application Services Access Services Infrastructure Services Modeling, composition Deployment/implementation Monitoring 3

4 SOA lifecycle design testing Integration human process information Requirement analysis modeling & simulation design Financial Business/IT harmonization Process control Application and service monitoring Identity management Business indicators 4

5 Model-Driven Architecture for Classical Approaches platform description Platform Independent Model Model Xform. Platform Specific Model Code Generation Source code 5

6 Model-Driven Architecture for SOA Service Catalogue/ Standard (eg. BPEL) Platform Independent Model Model Xform. Platform Specific Model Service mapping + deployment Service invocation Business workflow Configuration 6

7 Building Information Society with Innovation Componentization and requirements A functionally correct system has to fulfill additional non-functional requirements, as well

8 Requirement classes 8

9 Applications Development Services IT Service Management SOA systems are vulnerable Compliance to standards Business Innovation and Optimization Services Complexity Completeness Consistency Interaction Services Process Services Information Services Enterprise Service Bus Partner Services Business Application Services Access Services Complexity? Correctness? 9 Not owned Availability Reliability Infrastructure Services Platforms Outsourcing? Parasitic interaction Modeling, composition Deployment/implementation Monitoring Security

10 V&V problems in non-functional design Proof of correctness SLA requirements specification Availability prediction Qualitative dependability assessment (fault impact analysis) Quantitative dependability assessment Performance prediction Damage confinement and recovery Error detection Performability control 10

11 Building Information Society with Innovation Core: Mathematical Analysis Huge complexity -> Importance of mathematical analysis integrated into the design workflow

12 Mechanized approach Design Engineering model Automated model generation Backannotation Mathematical analysis Mathematical model Analysis tool Code generation Implementation 12

13 Transformation development Metamodels Graph transformation rules Transformation development & testing Transformation trace, debug information Transformation control structure Plugin generator Transformation design time Transformation runtime Source model Native transformation plugin Target model 13

14 VIATRA 2 as Eclipse Generative Model Transformer GMT is an independent part of the Eclipse Modeling Project led by IBM and Borland 14

15 Building Information Society with Innovation Design verification Proof of correctness 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 16

17 A Workflow Example Basic activity Beginning of parallel execution Selection Policy Reject Recording Establish type Control flow Premium Pay End of parallel execution 17

18 Verification of Workflows Simulation Positive result Workflow (BPEL) Formal model (dataflow network) Analysis model (Promela) Model checker (SPIN ) Requirement (LTL expression) Negative result + counterexample 18

19 Verification of Workflows Simulation Positive result Workflow (BPEL) Formal model (dataflow network) IBM WebSphere Integration Developer Analysis model (Promela) SPIN modelchecker Requirement (LTL expression) Negative result + counterexample 19

20 Verification of Workflows Dataflow Network (generated) Abstract data Hierarchic modeling Model refinement Simulation Positive result Workflow (BPEL) Formal model (dataflow network) Analysis model (Promela) SPIN modelchecker Requirement Negative result Representation in the VIATRA2 (LTL + framework expression) counterexample Dataflow Network generated from parsed BPEL model 20

21 Verification of Workflows Target requirement Business level: no unauthorized business transaction Implementation level: each variable Positive Simulation should be initialized prior to a read access result Workflow (BPEL) Formal model (dataflow network) Analysis model (Promela) SPIN modelchecker Requirements LTL: linear temporal logical expression Requirement (LTL expression) Negative result + counterexample 21

22 Verification of Workflows Simulation Positive result Workflow (BPEL) Formal model (dataflow network) Analysis model (Promela) SPIN modelchecker Model checker Evaluation of LTL expressions Exhaustive state space traversal Requirement (LTL expression) Negative result + counterexample 22

23 Verification of Workflows Simulation Positive result Workflow (BPEL) Formal model (dataflow network) Analysis model (Promela) SPIN modelchecker Modelltranszformáció Model transformation VIATRA2 framework Requirement (LTL expression) Negative result + counterexample 23

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 24

25 Example Full model: IF credit_requested < 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 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 25

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 26

27 Dataflow Networks Node Port State Variable Uninitialized Written Read Written and read Fault written Fault written and read Token Activity Control Data D_F_Control Channel G(Variable.state!=Fault_written) 27

28 Mapping a Workflow to Dataflow Networks Policy Recording Establish type Premium Recording Establish type Policy Beginning of parallel execution Premium End of parallel Execution 28

29 Formal Verification of Cooperating BPEL 2.0 Processes Tibor Bende, Ábel Hegedüs, Máté Kovács SENSORIA Workshop Munich, February

30 BPEL Processes The application of workflows As Web services Business-to-Business Inter-enterprise application integration (EAI) Reception of service request Modification of data Invocation of educational and administrative processes Is the request accepted? Transmitting the response 30

31 Potential Faults in BPEL Workflows Missing data (Reading uninited variables) Deadlock due to loss of data Corruption of the control flow due to faulty data 31

32 Cooperating Business Processes Processing an application to participate in a course on a different university Request 1. Invocation of local modules The message does not arrive The effect of the fault on the control flow 2. Local decision 3. Invocation of remote modules 4. Transmitting response 32 Response Main WF Local Admin WF Local Edu WF Remote Edu WF Remote Admin WF

33 Analysis of Workflows Generating Process description Modelling Installaiton Graphical editing Execution Modellchecker Engine Corrections Runtime results Execution Verification 33

34 Summary of the Contribution The application of design time verification There are various approaches Formal Verification of BPEL 1.1 processes Formal Verification of BPEL 2.0 processes New control flow structures Event and fault handling Algorithm for dead path elimination The analysis of the cooperation of such processes 34

35 Modelling a Stand Alone Workflow Semantics BPEL 2.0 Variables: non-interpreted modelling Behaviour: transitions 36

36 Modelling the Cooperation of Workflows Abstraction Based on communicating activities Smaller statespace Overestimation of the behaviour 37

37 Steps of Model Refinement 1. Abstract model 2. Verification of the requirement 3. Refinement 4. Refined model A X? C?? B 38

38 Roles 39

39 Steps of the Verification Process BPEL editor BPEL code BPEL Importer (Java) SAL modell (VIATRA2) Modeltransformation (VIATRA2) BPEL modell (VIATRA2) Code generation (VIATRA2) SAL code Modelchecking (SAL) Result 40

40 Case Study 42

41 43/17 Analysis of the Case Study Requirement # of states Verification time [s] Execution time [s] Result Not reading uninitialized variable? ,5 4,6 True A Requirement variable is not needed? # of states Verification 0,3 time [s] Execution 5,8 time [s] Result False No deadlock? ,2 6,0 True Does falut propagate to the response? ,6 6,2 False Not reading uninitialized variable? ,5 4,6 True Do we send faulty data? ,4 5,8 False Is there unhandled exception? ,8 5,4 True Does A -> B exist? ,1 2,0 True A variable is not needed? ,3 5,8 False Does A -> C exist? ,05 2,0 False Does trans. spoil data? ,12 2,2 True 43

42 Conclusion Verification of business processes and their cooperation in design time Advantages: Finding usual practical mistakes and unhandled exceptions Compatible with SOA Further research directions Graphical requirement specification Domain specific fault model Automatic model refinement 44

43 Building Information Society with Innovation Early dependability assessment Objective: identification of the critical processes and their dependence on services and resources Reinforcement of the workflow (ABFT)

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

45 Fault tree analysis Service unavailable System level effect Network switch failure SPOF Basic events Failure of servers Primary Failover server unsuccessful failure Secondary HA server middleware failure failure Server software design failure Possible SPOF (not analyzed) 51

46 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) 52

47 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 Network switch - garbage out - broken link 35% 65% Effect - access denied - service timeout

48 Risk matrix and acceptable hazards Hazard effect Catastrophic Critical Marginal Negligible Frequent Probable Occasional Remote Improbable Network switch failure HA middleware failure Server sw. failure Primary server failure Secondary server failure Protection level Impossible 54

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

50 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 Activity Control Data D_F_Control Otherwise Control Activity Control Data D_F_Control 56

51 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 2 VOTER Version N Version N Fails Version 2 Fails Version 1 57

52 Quantitative Dependability Analysis Building Information Society with Innovation SLA requirements specification Quantitative dependability assessment Availability prediction Performability control Prediction of quantitative service/business level characteristics

53 Objectives Composite services Composed of basic service components Only partial control over the different services Analysis 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 service Non-functional analysis PREDICTION of Dependability metrics for the services Business impacts WHAT-IF analysis 59

54 Phased Mission Systems 60

55 Phased Mission Systems Multiple Phased Systems Systems which lifecycle consists of different phases Phases have different resource characteristics Expected response time Failure rate, etc. DEEM tool Dependability Evaluation of Multiple-phased Systems Representation: Deterministic and Stochastic Petri Nets Evaluation: Markov Regenerative Processes Developed in Pisa/Florence Upper layer: phases Operational life Tree or cyclic Petri Net One active phase ( performing action X ) Routing may depend on resource states Lower layer: resources Representing the state of the system Characteristics depend on the actual phase 61

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

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

58 Modeling vs monitoring based SOA lifecycle Process modeling and analysis RT data acquisition and monitoring START Hitelkérelem létrehozása Hitelképesség-ellenőrzés IGEN Előzetesen jóváhagyva? (üzleti szabály) NEM Fedezet foglalása Hitelbírálati jóváhagyás Hitelkockázat értékelése IGEN Jóváhagyva? NEM Kockázatos? (Üzleti szabály) NEM Elfogadás küldése IGEN Elutasító küldése VÉGE Enterprise Service Bus IMS transaction Service (J2EE) Service ( ) Service (Web) Service (human) Service (Web) Service (human) 64

59 Building Information Society with Innovation Model-based optimization of Service Deployment Quantitative dependability assessment SLA requirements specification Availability prediction Performability control Availability aware deployment of services: integrated deployment design and optimization under cost and performance constraints

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

61 Model-Driven Architecture + QoS analysis platform description Platform Independent Model Model Xform. Platform Specific Model Code Generation QoS model & properties QoS analysis Analysis results Source code 67

62 Model-Driven Architecture + QoS-based synthesis platform description Platform Independent Model Model Xform. Platform Specific Model Code Generation QoS model & properties QoS synthesis Synthesis results Source code 68

63 Architecture Synthesis Design space Total Cost of Ownership (TCO) Availability Capacity 69

64 J2EE Architecture Entity beans Persistence management Backend services messaging authentication databases 70 RMI Client Servlets and Java Server Pages Web-based user interface IIOP Client HTTP Client HTTP Engine Session beans EJB Container Business logic Service access points EJB Container JSP Servlet Servlet Container J2EE Server JMS RDBMS Message Queue CORBA Server Other Resource

65 QoS model for services «StatelessSessionBean» Serv icea Stand-alone components Links QoS attributes Capacity requirement (throughput) Availability requirement Represents single usage relationship Directed QoS attributes are propagated + operation() : void tags QOS_Availability: 99.99% QOS_Capacity: 100 «uses» «StatelessSessionBean» Serv iceb ServiceA A = 99.99%, C=100/min ServiceB A = 99.99% + op() : void tags QOS_Availability: 99.99% 71

66 General Resource Model Application component <<Client>> Deploys to Server computer <<Resource>> RequiredQoS QoSValue OfferedQoS 72

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

68 Architecture Optimization Objective Function TCO System m HW TCO( m) number _ used ( m) Total Cost of Ownership Total of Cost of Ownership of Actual number of nodes the system the specific node type from the specified type System Node1 Node2 Node3 Node4 Node5 74

69 Workload ( i) Capacity _ need ( i) j depends( i) Workload ( j) Architecture Optimization Component Workload Balance Workload ( i) Capacity _ need ( i) j depends( i) Workload ( j) Actual workload of the specified component Defined direct load of the component Indirect workload from depending services Service1 W = 100 Service3 C = 150 Service2 W = 50 75

70 Workload ( i) Capacity _ need ( i) j depends( i) Workload ( j) Architecture Optimization Component Throughput Limits A specific hardware node of the system Saturation factor The maximum load (0..1) on the machine m HW : Capacity ( m) SF s deployed( m) Workload ( s) Aggregate workload of all components running on the node. Capacity of node m (from benchmark) Service1 W = 100 Service2 W = 50 Service3 W = 150 Node1 C = 200 Node2 C=

71 Workload ( i) Capacity _ need ( i) j depends( i) Workload ( j) Architecture Optimization Availability Effect of Interactions A act (i) P(HWavailable P(HW available) all HW running req. srvc All needed P(HW avail) A services HW(i) available) A HW( j) j,hw( j) running neededservice Availability of the deployment target Availability HW of the deployment target HW of Actual availability of the component invoked services Service1 Service2 Service3 A =? Node1 A = 99 Node2 A = 99 77

72 Workload ( i) Capacity _ need ( i) j depends( i) Workload ( j) Architecture Optimization Availability Requirements Constraints cont d i services : A act (i) A required (i) Actual availability of the component Required availability of the component 78

73 Building Information Society with Innovation Dependability consolidation Numerous applications implemented with no dependability considerations, but delivering business critical services?

74 IT Service Management Processes are Interdependent IT Financial Management IT Financial Management Framework Plan and Control IT Budgets Perform IT Financial Accounting Administer IT Charging Evaluate Management Performance Service Level Management Service Level Management Framework Service Catalogue Service Level Agreements Evaluate and Report Service Level Achievements Assess Service Level Results Formulate Service Level Improvement Plan Evaluate Service Level Management Performance Availability Management Determine Availability Requirements Formulate Availability Criteria Define Availability Targets Establish Measures and Reporting Monitor, Analyze, and Report Investigate Unavailability Produce Availability Plan Incident Management Detect and Record Incident Classification and Initial Support Investigate and Diagnose Resolution and Recovery Own, Monitor, Track, and Communicate Close Incidents Incident Reports 80