WS-PSC Monitor: A Tool Chain for Monitoring ...

WS-PSC Monitor: A Tool Chain for Monitoring Temporal and Timing Properties in Composite Service Based on Property Sequence Chart Pengcheng Zhang1 , Zhiyong Su2 , Yuelong Zhu1 , Wenrui Li1 , and Bixin Li3 1 3

College of Computer and Information Engineering, Hohai University, Nanjing, China 2 Wuxi Huishi Technology Co., Ltd, Wuxi, China School of Computer Science and Engineering, Southeast University, Nanjing, China {pchzhang,ylzhu,liwenrui}@hhu.edu.cn, [email protected], [email protected]

Abstract. Web service composition is a new paradigm to develop distributed and reactive software-intensive systems. Due to the autonomous attribute of each basic service, validation of composite services must be extended from design time to run-time. In this paper, we describe a novel tool chain called WS-PSC Monitor to monitor temporal and timing properties in composite service based on graphical specification property sequence chart and timed property sequence chart. The tool chain provides a completely graphical front-end which can make software designers do not have to deal with any particular textual and logical formalism. Keywords: Composite service, run-time monitor, property sequence chart, timed property sequence chart.

1

Introduction

In recent years, the idea of software as a service has added a new paradigm to the service oriented architecture(SOA). In SOA, basic services are seen as autonomous agents acting according to certain contracts. For example, through work flow languages BPEL [6], service requestors may compose existing basic services to provide more powerfully composite services. For such systems, verification is particularly challenging as the overall behavior of such systems depends heavily on the involved agents, which renders the analysis of such systems prior to execution next to impossible [5]. Consequently, runtime analysis techniques, such as runtime monitoring [2], are being pursued as a lightweight verification technique complementing traditional verification techniques, such as model checking and testing, and establishes another trade-off point between these forces. The property specifications for monitored properties focus mostly on logicbased or scenario-based specification formalisms. Logic-based formalisms are often more expressive than scenario-based formalisms. However, scenario-based 

This work is supported partial by the Fundamental Research Funds for the Central Universities under Grant No.2009B04314 and 948 project of Ministry of Water Resources under Grant No.201016.

G. Rosu and O. Sokolsky (Eds.): RV 2010, LNCS 6418, pp. 485–489, 2010. c Springer-Verlag Berlin Heidelberg 2010 

486

P. Zhang et al.

approaches provide a graphical modeling formalism that is widely accepted in industrial practice. Consequently, this paper focuses on monitoring temporal and timing properties of a composite service based on existing graphical specification formalisms Property Sequence Chart(PSC) [1] and Timed Property Sequence Chart (TPSC) [8], since PSC and TPSC specifications are as simple as possible, without losing expressive power. A corresponding tool chain called WS-PSC Monitor is developed.

2 2.1

The Approach Theoretical Foundations

Monitors are typically generated automatically from some high-level specifications. As defined in [5], the generated monitor is a device that reads a finite trace and yields a certain result (for example, true, false or inconclusive). To ensure the correctness of the monitor itself and to reduce costs, different monitoring approaches have been developed over the last years to automatically generate monitors for high-level property specification formalisms. According to the formal semantics of PSC [1], we have defined four different functions of the message in PSC specifications [9], i.e. Constraint, NextCorrect, NextFail, and NextIgnore. The messages constrained by the messages are contained in Constraint function; the next expected messages are contained in NextCorrect according to the PSC specifications; the next unexpected messages are contained in NextFail ; the next ignored messages are contained in NextIgnore. The four functions of each occurred message in PSC can be counted iteratively, and results are placed into a Property Database. The Property Database is used as monitor for further analyzing temporal properties. According to the formal semantics of TPSC [8], we can also define the formal translational semantics that maps TPSC specifications into a corresponding timed B¨ uchi automata(TBAs) [10]. The rules are divided into basic and compositional rules. Basic rules discuss how to translate single TPSC into a TBA while compositional rules show how to compose these basic automata with structured operators, such as par, loop and alt. The generated TBAs are also used as monitor for analyzing timing properties. 2.2

Framework Overview

The flow of the WS-PSC Monitor framework is shown in Figure 1 and divided into the following steps: 1) AOP(Aspect-Oriented Programming) based approach [4] is used to extend the BPEL engine. According to PSC and TPSC specifications, the monitoring aspects are automatically generated to intercept the messages among the interactions of each basic service. The interceptor intercepts the run-time messages in BPEL-based composite service, then sends these messages to the Observer; 2)According to property types, the observer can classify the intercepted messages. If property type is temporal property, the observer can only record all the

WS-PSC Monitor: A Tool Chain for Monitoring

487

interaction messages; if property type is timing property, the observer needs also to record the time frames for each interaction message. 3)The informal requirements are represented by PSC and TPSC specifications, where PSC specifications are used to represent temporal properties and TPSC specifications are used to represent timing properties. 4)We can use the two translators of the system and translate PSCs and TPSCs into property database and timed B¨ uchi automata, respectively. 5)Analyzers receive the intercepted messages and the properties represented by PSC and TPSC, then Analyzers check whether the runtime information satisfies the desired properties. If property type is temporal property, Analyzer1 is used. If property type is timing property, Analyzer2 is used. 6)The analysis results are shown for designers. Then designers can further analyze and correct the possible errors in the systems.

Informal temporal requirements

(3) PSCs

Interceptor

BPEL Runtime

(1) Observer1

Informal timing requirements

(3) TPSCs

PSC2PD

TPSC2TA

Property Database

Timed Automata

(4) Properties

Observer2 (5) Analyzer

(2)

Analyzer1

Analyzer2

(6)

Checking Results

Fig. 1. The framework of tool chain WS-PSC Monitor

2.3

The Implementation

The tool is developed on the Eclipse Rich Client Platform (RCP). It has 122 java classes and about 20 thousand lines of codes. Figure 2 shows the main user interface with Prop3 of a TA (TeleAssistant) BPEL composite service, which is a software and telecommunication-based service which is designed to help patients needing daily assistance in remote areas. The tool has the following additional components and interfaces: Navigator, TPSC Editor, Automata view, Property view, BPEL files view, Message view and Console. The navigator is used to manage and show the opened projects and files. The PSC and TPSC Editor allows users to manually specify temporal properties in PSC and timing properties in

488

P. Zhang et al.

Fig. 2. The main interface of the tool WS-PSC monitor

3000 2500

time in ms

3500

2000 t

1500 1000

ǻt

500 #System Interactions (*1000)

0 1

2

3

4

5

6

7

8

9

10

Fig. 3. The performance measurement of the tool WS-PSC monitor

TPSC, respectively. There is a Palette window, which is used to help users to drag and drop the PSC or TPSC elements. The lifeline or message elements of each property can be shown in the property view, where the first message e:[inv]alarm(high) of Prop3 and its constraint is shown under clock constraints in the screen shot. The Automata view is used to show the generated TBA for the property in the PSC or TPSC Editor. We use the textual representation of TBA. The BPEL files view shows the monitored BPEL specification and the message view shows the monitored messages including its time information. Finally, the Console is used to show that whether the collected messages satisfying the desired timing property and the time the algorithm takes.

WS-PSC Monitor: A Tool Chain for Monitoring

489

The performance measurement of the monitoring approach is presented in Figure 3, where t shows the time for checking the trace for TBA and t shows the time consumed for monitoring 1000 system interactions. From the curves, we can see that the time for the process will grow when the number of system interactions increases and it will just take about 3000 ms even when the number of system interactions is 105 . The curve for t shows that the time consumed per 1000 system interaction is between 250ms and 300ms.

3

Conclusion

This demonstration of WS-PSC tool chain aims to show the process of monitoring temporal and timing properties in composite services by the use of PSC and TPSC specifications. Compare to other approaches, our approach provides a complete graphical front-end for software designers that do not have to deal with any particular textual and logical formalisms. In the future, we will extend this work to automatically generate monitors for probabilistic properties from Probabilistic TPSC (PTPSC) specifications [7,3].

References 1. Autili, M., Inverardi, P., Pelliccione, P.: Graphical scenarios for specifying temporal properties: an automated approach. Automated Software Engineering 14(3), 293– 340 (2007) 2. Delgado, N., Gates, A.Q., Roach, S.: A taxonomy and catalog of runtime softwarefault monitoring tools. IEEE Trans. Software Eng. 30(12), 859–872 (2004) 3. Grunske, L., Zhang, P.: Monitoring probabilistic properties. In: ESEC/FSE, pp. 183–192 (2009) 4. Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C.V., Loingtier, J.M., Irwin, J.: Aspect-oriented programming. In: Aksit, M., Matsuoka, S. (eds.) ECOOP 1997. LNCS, vol. 1241, pp. 220–242. Springer, Heidelberg (1997) 5. Leucker, M., Schallhart, C.: A brief account of runtime verification. J. Log. Algebr. Program. 78(5), 293–303 (2009) 6. WS-BPEL. Web services business process execution language version 2.0, committee specification. OASIS (2007) 7. Zhang, P., Grunske, L., Tang, A., Li, B.: A formal syntax for probabilistic timed property sequence charts. In: Proc. of ASE, 500–504 (2009) 8. Zhang, P., Li, B., Grunske, L.: Timed property sequence chart. Journal of System and Software 83(3), 371–390 (2010) 9. Zhang, P., Li, B., Muccini, H., Sun, M.: An approach to monitor scenario-based temporal properties in web service compositions. In: Ishikawa, Y., He, J., Xu, G., Shi, Y., Huang, G., Pang, C., Zhang, Q., Wang, G. (eds.) APWeb 2008 Workshops. LNCS, vol. 4977, pp. 144–154. Springer, Heidelberg (2008) 10. Zhang, P., Li, B., Sun, M.: Extending PSC for monitoring the timed properties in composite services. In: Proc. of APSEC, pp. 335–342 (2008)