Business Process Execution Language (BPEL), its metrics and Control Flow Graph (CFG)

1. Business Process Execution Language (BPEL), its metrics and Control Flow Graph (CFG) by Esubalew Alemneh

2. Contents 1. Introduction to BPEL • BPEL can’t work alone • BPEL process Structure • Benefits of BPEL 2. Metrics of BPEL • Size Metrics • Complexity Metrics 3. Static code Analysis • Scanner and Parser • Static code Analysis to calculate metrics • example 4. BPEL control flow graph

3. Introduction • Now a days the speed of internet is alarmingly increasing. • In other hand huge numbers of web service applications are available distributed throughout the world. • These applications can be composed to create new web service applications promoting reusability. • BPEL is one of the means to do this. • Evolved from WSFL and XLANG;

4. Introduction (cont’d) • BPEL (WSBPEL or BPEL4WS), is an XML-based web service composition language for business processes. • Web service composition refers to the creation of new web services by combination of existing ones[1]. • Web service is a software system designed to support interoperable machine-to-machine interaction over a network [15]. • A business process is a collection of related, structured activities or tasks that produce a specific service or product [15].

5. Introduction (cont’d) • In other words we can say that BPEL is an orchestration language. • Message exchange sequence is Controlled by • the orchestration Designer. Figure 1. BPEL is orchestration language

6. Introduction (cont’d) • A BPEL process can be defined using the notion of abstract process and/or executable process. • Abstract process is partially specified process that is not intended to be executed. • Executable process are fully specified and thus can be executed.

7. BPEL can’t work alone • BPEL is layered on top of web service technology stack. • It uses existing XML specifications such as WSDL, XPath, SOAP and XML Schema. • WSDL defines the operations (i.e., the methods) and message types used by a web service. • XML Schema is used for data modeling • XPath expressions are used for handling of XML Schema based data. • SOAP is used for messages exchanged,

8. BPEL Processes Structure • BPEL process has two sections; global declarations section and process definition section. <process name=”Process_Name” …> Global Declarations Process Definitions (activity) </process> • Global declarations contain extensions, imports, partnerLinks, Variables, CorrelationSets, faultHandlers, eventHandlers, etc

9. Process Definition • Process definition contains process activities • Activities represent the actions to be carried out within a business process. • There are two types of activities in BPEL; basic activities and structured activities. • Basic activities are those that are considered to be atomic, meaning that they cannot be subdivided. • Structured activities are those activities which can contain other activities.

10. Basic Activities • receive:- The job of the receive activity is to wait for an incoming message from a partner. • reply:- Used to send a response to a request previously accepted through a receive activity. • reply activity must be always preceded by receive activity. • It is the combination of the two that defines the process's synchronous interactions. • invoke:- used to invoke or call a web service. • An Invoke can be either one-way or it can use a request-response exchange.

11. Basic Activities (cont’d) • assign:- Manipulating data variables. • Assign Activities, using their internal Copy operations, control the movement of data in a BPEL process. • One Assign activity can have many internal Copy commands • throw:- Signaling faults and exceptions. • wait:- Waiting for some time. • exit:- Terminating the entire process. • empty:- An activity that does not do anything

12. Structured Activities • sequence:- Structures a set of activities tobe invoked in an ordered sequence. <sequence> activity+ </sequence> Scope:- provides fault and compensation handling capabilities to the activities nested within it.

13. Structured Activities (cont’d) • if :- Provides a construct to choose one activity among a collection of activities. <if> <condition expressionLanguage="anyURI"?>bool-expr</condition> activity <elseif>* <condition expressionLanguage="anyURI"?>bool-expr</condition> activity </elseif> <else>? activity </else> </if>

14. Structured Activities (cont’d) • Pick:- Used to have the process wait until one of a set of events is triggered. • Message events via onMessage element • Alarm events via onAlarm element

15. Structured Activities (cont’d) <pick createInstance="yes|no"? > <onMessage partnerLink="ncname" portType="qname“ operation ="ncname" variable="ncname"? messageExchange="ncname"?>+ <correlations>? <correlation set="ncname" initiate="yes|no"?>+ </correlations> <fromParts>? <fromPart part="ncname“ toVariable="BPELVariableName" />+ </fromParts> activity </onMessage> <onAlarm>* ( <for expressionLanguage="anyURI">duration-expr</for> | <until expressionLanguage="anyURI">deadline-expr</until> ) activity </onAlarm> </pick

16. Structured Activities (cont’d) • while:-Defines the notion of loops. • It executes an activity repeatedly until its associated Boolean condition is no longer true. <while> <condition expressionLanguage="anyURI"?> bool-expr </ condition> activity </while>

17. Structured Activities (cont’d) • repeatUntil:- Is a looping activity which executes activity contained inside it at least once. <repeatUntil> activity <condition expressionLanguage = "anyURI“?> bool-expr </condition> </repeatUntil>

18. Structured Activities (cont’d) • flow:- Enables the concurrent execution of activities. • It defines a set of activities that will be invoked in parallel. <flow> <links>? <link name="NCName">+ </links> activity+ </flow> • The links put their own constraints on how the activities of a process are set to run.

19. Structured Activities (cont’d) • forEach:- forEach activity executes its scope activity exactly N+1 times serially in iteration or concurrently where N is the difference between finalCounterValue and startCounterValue. • Based on the complitionCondition all activities inside scope activity of forEach activity might not be executed.

20. Structured Activities (cont’d) <forEach counterName="BPELVariableName" parallel = "yes|no“ > <startCounterValue expressionLanguage="anyURI"?> unsigned-integer-expression </startCounterValue> <finalCounterValue expressionLanguage="anyURI"?> unsigned-integer-expression </finalCounterValue> <completionCondition>? <branches expressionLanguage="anyURI"? successfulBranchesOnly="yes|no"?>? unsigned-integer-expression </branches> </completionCondition> <scope ...>.......</scope> </forEach>

21. Example BPEL Source Code

22. Benefits of BPEL • Industry-wide language for expressing business processes---standard by OASIS – Leverage a common skill set and language • Designed to fit naturally into the Web services stack – Is expressed entirely in XML – Uses and extends WSDL 1.1 – Uses XML Schema 1.0 for the data model • Portable across platform and vendor – Will run on any BPEL-compliant engine • Interoperable between interacting processes – Layering on top of Web services stack

23. Metrics of BPEL • Software metric is a measure of some property of a piece of software or its specifications [15]. • Effective management of any process requires quantification, measurement, and modeling. • Metrics are useful for [12]; • prioritizing remediation efforts • allocating resources among multiple projects • quantify the amount of risk associated with a piece of code. • getting feedback on the effectiveness of the security process

24. Metrics of BPEL • The BPEL language is quite new, and much hasn’t been done on its metrics. • However, there are some metrics which are proposed but almost all of them are not validated. • Most of the metrics are inspired from the traditional software program metrics. • Broadly BPEL metrics can be classified in to two; Size metrics and complexity metrics.

25. Size Metrics • BPEL has three size metrics • 1. Number of Activities (NOA) • Count all activities in a process. • 2. Number of activities, joints and splits of a process (NOAJS). • count the number of activities, joints and splits in a process

26. Size Metrics (cont’d) 3. Number of activities and control-flow elements (NOAC). • number of activities and control-flow elements in a process. • There are four types of control flow elements in BPEL • Sequencing:- <sequence> • Branching:- <if>, <pick> • Iteration:- <while>, <repeatUntil>, <forEach p=n> • concurrent execution:-<flow>, <forEach p=y>

27. Complexity Metrics • BPEL by its nature is very complex. • High complexity results in • poor understandability • less flexibility • less quality • more chance of failure • more errors and defects, and exceptions • leading to processes requiring more time to design, test and maintain. • There is no a single measure for process complexity

28. Complexity Metrics (cont’d) 1. Control Flow Complexity (CFC) • There are two independent approaches to develop a CFC metric to analyze business processes. • Based on the complexity of each activity. • Based on process joins and splits. • In the first approach, a formula has been provided for each activity. • Example, for while activity CFC (W) = log2 (CFC (a) +2)* CFC (a) • Then the CFC of a process is the cumulative effect of complexity of all activities it contains.

29. Complexity Metrics (cont’d) • The second CFC metrics is calculated based on the splits and joins of a process. • It is proposed as a design time metrics. • To calculate it from source code we need to determine control flow graph of a process. • A Split is an activity (node) with more than one outgoing transition. • A Join is an activity (node) with more than one incoming transition.

30. Complexity Metrics (cont’d) • Where, • CFCXOR split (a) = fan-out(a) , a is a XOR-split activity of P • CFCOR split(a) = 2fan-out(a)-1 , a is an OR-split activity of P • CFCAND split(a) = 1 , a is an AND-split activity of P

31. Complexity Metrics (cont’d) 2. Data Flow Complexity (DFC) • The study of DFC involves the analysis of XML Schema data types and the input and output messages of web service. • Three metrics are proposed: • data complexity • interface complexity • interface integration complexity. • ICBPEL Process (P) = Length * (Fan-in *Fan-out) 2

32. Complexity Metrics (cont’d) 3. McCabe’s cyclomatic complexity (MCC) • Calculated as MCCBPEL Process(P) = e+n-2 • where e is total number of edges and n is total number of nodes in the process control graph.

33. Complexity Metrics (cont’d) 4. Halstead-based process complexity (HPC). • Determine [22], • Number of distinct operators (n1) • Number of distinct operands (n2) • Total number of operators (N1) • Total number of operands (N2) • Calculate the metrics • Process Length: N = n1*log2(n1) + n2*log2(n2) • Process Volume: V = (N1+N2)*log2(n1+n2) • Process Difficulty: D = (n1/2)*(N2/n2)

34. Complexity Metrics (cont’d) 5. Process Graph Complexity (PGC) • Graph theory provides a rich set of graph metrics. • Coefficient of network Complexity (CNC) • CNC = number of arcs / (number of activities, joins, and splits) • Structuredness of process graph • Number of structured activities

35. Static code Analysis • Static code analysis is the analysis of computer software that is performed without actually executing programs [15]. • The analysis can be manual inspection or automated one. • It is important for [15, 11] • finding low-level errors • software metrics calculation • testing

36. Scanner and Parser • Automatic static analysis have two important components; Scanner and Parser. • Scanner is a lexical analyzer which is responsible for; • converting character stream to token stream • strips out white space, comments • Token is categorized block of text [15]. • Tokens are frequently defined by regular expressions (example. Digits(0|1|2|…|9) )

37. Scanner and Parser (cont’d) • Parser is responsible for • Checking input for grammatical correctness • Determines syntax of token stream • construct intermediate representation • produce meaningful error messages • It needs • mathematical model of syntax, context free grammar • algorithm for testing syntax, parsing

38. Specification (in RE) Specification (in Grammar) IR (usually AST) Source code Tokens Scanner Parser Error Scanner and Parser (cont’d) Fig 3. scanner and parser in compilers

39. Source code Tokens Metrics Scanner Parser Token separators Static Analysis for metrics calculation • Assume that the source code is synthetically correct Fig 4. scanner and parser for metrics computation

40. Example, NOA • Global declaration • Identify all activities and store them in some data structure. • Scanner • Open source code file for reading • If there is more line read a line at a time, else return tokens • If the line is comment line go to 3 • Break a line into tokens and store it in some data structure • Parser • Take a token and compare it with the content of globally declared and initialized date structure. • If there is a match increase NOA by 1. • Do the above two steps until no more tokens are left

41. public Vector<String> scanner(String path){ • String line = null; • Scanner input= new Scanner(new FileInputStream(path)); • StringTokenizer st; • Vector<String> tokens=new Vector<String>(); • while(input.hasNextLine()){ • line=input.nextLine(); • if(line is comment line) • continue; • //break the line into tokens • st = new StringTokenizer(line, " <,>\"=", false); • String temp=null; • while (st.hasMoreTokens()){ • temp=st.nextToken(); • tokens.add(temp); • } • } • return tokens; • }

42. final String activities = {“receive”, “reply”, … }; public int parser(Vector<String> tokens){ int NOA=0; String token = null; for(int i = 0; i<tokens.size(); i++){ token = tokens.get(i); for(int j=0;j<activities.length;j++) if(token.equals(activities[j])) NOA++; } return NOA; }

43. BPEL Control flow graph • CFG promotes the understandability of the source code. • This is particularly important for complex programming languages like BPEL. • The formal definition of the BPEL control flow graph as given in [9] is; BFG = <N, E, S, F>,where, • N is set of nodes • E is set of edges • S start node • F set of final nodes

44. BPEL Control flow graph (cont’d) • There are two types of edges • Implicit edges • Explicit links • Mapping rules • What type of edges/links exist between activities • Determines which activities form which type of nodes

45. BPEL Control flow graph (cont’d)

46. BPEL Control flow graph, example Fig 5. Control flow graph for PurchaseorderProcess.bpel

47. Conclusion • BPEL had become the de facto standard for process orchestration, even prior to the publication of the BPEL 2.0. • It is a broadly adopted process orchestration standard supported by many vendors today. • However, regarding to its metrics and CFG much hasn’t been done. • The proposed metrics must be validated using empirical investigations. • As CFG is vital for metrics calculation and for understandability the process emphasis should also be given here.

48. References • Fundamentals of BPEL, Active BPEL • J. Cardoso, J. Mendling, G. Neuwmann and H.A. Reijers. A Discourse on Complexity of Process Models. BPM 2006 workshops, LNCs 4103. 2006. • Michael Havey, Essential Busines Process Modeling, Publisher: O'Reilly, ebook, 2005. • A close look at BPEL (magazine) • BPEL's Growing Up(magazine) • C Ouyang, E Verbeek, Wil M.P. van der Aalst, S Breutel, M Dumas, and A.H.M. ter Hofstede. WofBPEL: A Tool for Automated Analysis of BPEL Processes. 2005. • Frederic Servais, Verifying and Testing BPEL Process, masters thesis, 2007. • A. Arkin, S. Askary, B. Bloch, F. Curbera, Y. Goland, N. Kartha, C. K. Liu, S. Thatte, P. Yendluri, and A. Yiu, editors. Web Services Business Process Execution Language Version 2.0. WS-BPEL TC OASIS, May 2005. Available via: http://www.oasis-open.org/committees/download.php/12791/. • Y Yuan, Z Li, Wei Sun. A Graph-search Based Approach to BPEL4WS Test Generation, 2006. • J. Cardoso, Complexity Analysis of BPEL web Process, Journal of Software Process: Improvement and Practice, 2006.

49. References • http://www.testingfaqs.org/t-static.html. • https://www.informit.com/articles/article.aspx?p=768662&seqNum=3 • J Carduso. Complexity analaysis of BPEL web services. Software process: improvement and Practical Journal. 2006. • Ms Weidlich, Efficient Analysis of BPEL 2.0 Processes using pi-Calculus, 2007 • http://www.en.wikipedia.com • Y Qianz, Y Xuz, Z Wangz, GPuz, H Zhuz, and C CaiyTool Support for BPEL Verification in ActiveBPEL Engine , 2007. • Design and Implementation of a Framework for Testing BPEL Compositions • R.M. Pariizi and A.A.A Ghani. An Ensemble of Complexity Metrics for BPEL web Process. Ninth ACIS International Conference on Software Engineering, Artificial intellegince, Networking, and Parallel/Distributed Computing. 2008. • AJcFGraph • Structural Testing of Concurrent Programs • Choy Kho Yee, Design and Implementation of Test Case Generation Tool for BPEL Unit Testing, thesis, 2007. • http://www.verifysoft.com/en_halstead_metrics.html

50. Thank you