Petri Net Based Components for Evolvable ... - Semantic Scholar

Petri Net Based Components for Evolvable Architectures Julia Padberg

Technical University Berlin Theoretical Computer Science/ Formal Speci cation Group Sekr. FR 6-1, Franklinstr. 28-29 D-10587 Berlin, Germany [email protected]

Herbert Weber, Asuman Sunbul

Technical University Berlin Computation and Information Structures Sekr.E-N 7, Einsteinufer 17, D-10587 Berlin, Germany fhweber,[email protected]

October 4, 1999 Abstract

Evolvable architectures are an important design principle in order to cope with the continuously changing requirements for work ow management systems (WMS). These changes are induced by changes of the enterprises market, changes of the demands of society, and changes of the IT infrastructure. We propose a design strategy for evolvable architectures, called Eva1 . This approach is component-based as well as process-centered. We suggest to consider business process as components. Hence, we obtain dierent kinds of components, that nevertheless have the same interfaces. The main focus of this paper is the net component in Eva and the composition in this approach. We use net components that are based on Petri nets for the representation of business processes in components. We use nets that are an restriction of FunSoft nets. These nets, called FEva net are adapted for modeling business processes as well as for supporting the consistent composition of components. We explain the composition that makes use of additional information in the import and export interface.

Keywords: evolvable architectures, Funsoft nets, temporal logic, composition of components, work ows

1 Introduction To maintain competitiveness enterprises have to be able to adapt their business processes to the changing requirements in a smooth and exible way. The demand for suitable concepts has recently led to a new research area, namely continuous engineering [Web99]. An 1 This paper gives the formal foundation for Eva, especially for the business process components. In contrast [WSP00] (also submitted to IDPT2000) focuses on the conceptual foundation of Eva.

1

essential issue is the architecture of the system, as it describes the structure of the system and its interdependencies. Hence, the architecture is most sensitive to changes. Consequently the demand for evolvable architectures rises from the need to adapt continuously work ow based applications to the changing environment. The evolution of those systems comprises changes of the organizational structure as well as the IT-infrastructure. For the design of evolvable architectures we propose the combination of two successful strategies: component-based and process-centered design. Eva, short for Evolvable Architecture for Communication and Information Infrastructures [DDF+ 99, WSP00], combines the advantages of both, because components are regarded as containers for software, business objects as well as process descriptions. Petri nets have been chosen as the modeling technique for the process description since they provide an intuitive semantics as well as sucient modeling power. Therefore, we distinguish code components, business objects components, and business process components. Imports and exports are based on signatures and net based abstraction of the hidden body. In order to ensure correct and consistent composition of components import and export are subject to compatibility conditions based on the veri cation of temporal logic formulas in Petri nets. Hence, in the Eva approach compositionality of components is provided independent of the internal structure of the body. Eva supports the "black box" metaphor on components. Moreover, this metaphor is transferred to the process view too, because process descriptions are encapsulated as business process components. Hence, our approach improves adaptivity and exibility of work ow based applications, because changes of the system { and even of the work ow itself { reduce to changes or replacements of components. Consistency and correctness of the system is assured due to the compatibility conditions of import and export. This paper is organized as follows: Next we introduce the Eva approach and discuss the dierent kinds of components (see also [WSP00]). In Section 4 we explain the basic ideas of composition and give an example from our case study. The conclusion (Section 5) summarizes our approach and discusses further topics.

2 The Components of Eva One of the main ideas of Eva is to introduce business processes into the component concept as well. In usual work ow management systems (WMS) we have the business process on top of the software and communication infrastructure. In Eva we introduce a concept, where the business process are considered to be on the same conceptual level as other components. In Eva we propose components with the following properties:  The black box principle is well accepted and is supposed to be more adequate for component based approaches since it allows a loose connection and less dependencies between system parts (e.g. [Gri98]). A component is provided with interfaces and a body. The body is encapsulated and cannot be accessed.  Services are provided by components. Their signatures may be used in the interfaces, their implementation or model is encapsulated in the body of the component.  Interfaces provide the necessary information for the composition and the use of components. The interfaces we propose in the Eva approach are import and export. The import states the used services and the export states the services provided by a component. 2

In order to stress the process aspects interfaces may be additionally provided with process information. The export interface is extended by constraints xing the causal dependencies of services. The import interface may contain an abstraction of the progression, either sequential or parallel, of the imported services.  Composition of components is based on matching signatures in the export and import. Moreover, the causal dependency constraints given in the export have to be satis ed by the import net. The composition of components is obtained by putting together components with matching interfaces. Hence, components are connected according to their use of services. The resulting composition hierarchy has to be acyclic. Eva components comprises three types of components: business process components, business object components and code components. These three kinds of components provide nevertheless the same interfaces. The import interfaces contains on the one hand the signatures of the services used by this component and optionally an abstraction of the processes using the those services. The export interface provides the signatures of the services provided by the component together with constraints concerning the use of those services.

 Business process components describe a subprocess of the overall business process

using Petri nets. Petri nets have been chosen since they have a graphical representation an a intuitive semantics. Moreover, they are especially adequate for the modeling of work ows [vdA96, vdA98]. The body contains a FEva nets and a Petri net interpreter. The import contains the same net and the signatures of the imported services. For the imported services we have the following consistency condition: the imported services have to be annotated to some transition, so that the input parameters of the service corresponds to the types of he places in the pre-domain. Analogously, the output parameters have to correspond to the types of the places in the post-domain. Depending on the output behavior of the service the corresponding transition has to have the same ring modus. The export provides the signatures of the provided services and constraints that state the causal dependencies between the provided services. Moreover, the export signatures and the corresponding net have to be related. The input parameters of the services correspond one-to-one to the types of the input places. The same holds for the output parameters and places.  Code components contain speci c code, that may serve the integration of legacy systems or may oer general services. The export gives the corresponding signatures and may provide causal dependencies.For more details see [WSP00].  Business object components are special code components that contain business objects. Business objects can be identi ed with a real-world entity. A business object has a certain role in the business process and hence stays coherent during that process. It describes a data structure and and can be assigned values and types.A business object can be considered as an object in the object oriented paradigm. Business process components constitute the static part of the business process. Moreover, business objects are assigned to variables in the FEva nets of some business process component. For more details see [WSP00].

3

3 FEva Nets In this section we introduce a simple variant of FunSoft nets (see [Gru91, DG98]). This variant is quite simple but has nevertheless all the features to make the Eva concept work. Moreover, these nets can be transformed to place/transition nets [Rei85]. Hence, they can be easily checked for the validity of temporal formulas. FEva Nets A FEva net is given by N = (P; T; F; ; X; S;type; insc; serv; mode) where we have:

1. P is a set of places, with IP; OP  P.

Moreover, we distinguish input IP and output OP places.

2. T is a set of transitions. 3. F  (S  T) [ (T  S) is the set of arcs. There are no multiple arcs allowed.

IP = fpj(p; t) 2= F for all t 2 T g , analogously for OP

Input places are those without pre set, output places those without post set.

4.   L is the set of object signatures. 5. X = (X )2 is the family of object variables.

The variables can be assigned with business objects.

S

6. S L is a set of services. 7. type : P !  is a total mapping of the set of places P to the set of object signatures , that is a typing of the places. Since type is total, each place has to be annotated with an object signature. 8. incs : F ! Pf+ (X) is a total mapping of the set of arcs F to the nonempty, nite power set of variables over Pf+ (X), that is the arc inscriptions with variables, where insc(x; y)  Xtype(p) with x = p 2 P or y = p 2 P.

The arc inscriptions are variables, that are of the same type as the adjacent place.

Moreover, we require jinsc(p; x)j = 1 for p 2 IP and jinsc(x; p)j = 1 for p 2 OP.

Arcs adjacent to input or output places can only be inscribed with one variable.

9. serv : T  Sis a partial mapping of the set of transitions T to the set of services S, that is the invocation of a service. Since serv is a partial mapping, transitions can but do not have to be annotated with /

services. If they are not they only represent control ow.

10. mode : T ! fALL; DET; COMPLEX g give the ring modes, where we have serv(t) = ? implies mode(t) = ALL. There are three ring modes, ALL correspond to the usual ring of transitions: all places in the post-domain get tokens after ring. DET some of the places get tokens after ring. The corresponding service determines which places receive tokens. The ring mode COMPLEX is a combination of the previous ones.

This de nition diers from FunSoft, since it does not provide extra vertical structuring techniques as invocation. These are not provided in the de nition of FEva nets, since the 4

composition of components has the same eect. Moreover, the ring modes only concern the places in the post-domain. There are no ring modes for the pre-domain. The graphical notation in an abstract example of FEva nets is given in the subsequent illustration. An example net from our case study can be found in Figure 2 in Section 4. Explanation input place name of place

p1 Sig x

transition without service x

x

p4 Sig

p5

Sig

arc with inscriptions

x

x

places typed by object signatures

transition name transition 1 K2.D1[x][y,z] z

y

Sig1

transition 2 K2.D2[x][y]

p6

transition with

service

firing modus ALL firing modus DET

y

output place

p7 Sig2

Transformation of FEva Nets

Next, we consider the transformation of FEva nets to labeled place/transition nets. This transformation is needed to check the constraints when composing Eva components. The transformation is basically the skeleton where additionally the ring modes are unfolded. The invocation of services is abstracted by labeling of the transitions. The ring modes are unfolded into dierent con icting transitions with post domains according to the ring modus. Given a FEva Net N = (S; T; F; ; X; S; type; insc; serv; mode) then the corresponding labeled place/transition nets is given by V (N) = (P; T 0; F 0; L; lab; c M) and is computed in the following way: T0 = ftjt 2 T ; mode(t) = ALLg[ all transitions with mode ALL as many transitions as places in ftp1 ; :::; tp jt 2 T ; mode(t) = DET ; pi 2 tg[ the post-domain for each transition in mode DET fts1 ; :::; ts jt 2 T ; mode(t) = COMPLEX ; si 2 P (t)g as many transitions as sets of places in the post-domain for each transition in mode COMPLEX n

n

5

serv0 : T 0  Swith ;x = t 2 T serv0 (x) = serv(t) serv(t) ; x = ts 2 T 0 nT /

The services of the original transition.

F 0 is the set of arcs with F0 = f(p; t)j(p; t) 2 F g[ f(t; p)jmode(t) = ALL ; (t; p) 2 F g[

All arcs from places to transitions. All arcs from transition to places for ring mode ALL. One arc from each transition to corresponding place for ring mode DET.

f(tp ; pi)jmode(t) = DET ; pi 2 tg[ i

f(ts ; p)jmode(t) = COMPLEX ; ; p 2 si 2 P (t)g All arcs from each transition to i

corresponding places for ring mode COMPLEX. L = f  2 Sg is the set of object signature names Names of services as labels. lab : T  L is a partial mapping of T to L with Labeling of transitions with lab(t) = name(serv0 (t)) service names. P c M = p2IP p Initial marking by tokens on input places. /

Figure 1 depicts the labeled place/transition net obtained by transformation of the FEva net given in gure 2. Get Data

Handle Request

Information. input

New Request

Give Information

Message.quest

Information. output

New Request Message.quest

Figure 1: Labeled Place/Transition Net

T Eva: Temporal logic for Eva The quite simple temporal logic T Eva we need is given for a labeled place/transition net

an merely uses the most fundamental notions of temporal logic in the sense of [MP92]. We 6

sketch the way formulas are given only for those expression needed in the example in the next section. The satisfaction of a formula is de ned over the labeled transition system generated by the place-/transition net, again only for those expression needed in the example. First we give the syntactic description of the temporal logic T Eva over a place/transition net. T = (L; F ) over a labeled place/transition net N = (P; T 0; F 0; L; lab; c M) is given by

 L the set of labels, and  F the set of formulas recursively de ned by: 1. L  F 2. ' 2 F implies not ' 2 F 3. '; '0 2 F implies 'or '0 2 F , 4. ' 2 F implies once ' 2 F 5. ' 2 F implies always ' 2 F ,

6. and so on (see [MP92]). Satisfaction of those formulas is given by the labeled transition system generated by the place/transition net. Given a labeled place/transition net N = (P; T 0; F 0; L; lab; c M) and the corresponding formulas T = (L; F ), then we have with labels l 2 L, markings M; M 0 , and formulas ' 2 F : t 1. (N; M) j= l i 8M ?! M 0 : lab(t) = l 2. (N; M) j= :' i :(N; M) j= ' 3. (N; M) j= 'or '0 i (N; M) j= ' or (N; M) j= '0

4. (N; M) j= once ' i

t t1 Mn = M : 9Mi : (N; Mi ) j= ' M2::: ?! 8M0 ?! t t1 ::: : 8Mi : (N; Mi ) j= ' M2 ::: ?! 8M = M1 ?! n

5. (N; M) j= always i 6. and so on. The satisfaction of a FEva net is given by the satisfaction of the corresponding labeled place/transition net. Given a FEva net N = (S; T; F; ; X; S;type; insc; serv; mode) and the corresponding labeled place/transition net V (N) = (P; T 0; F 0; L; lab; c M), then we have: N j= ' i (V (N); c M ) j= ' n

4 Composition in Eva Composition of components is given by the matching of import and export. The signatures have to match and additionally the temporal conditions of the export have to be satis ed by the import net.

7

Example from Case Study

Our case study describes a simple model of a \calling center" of a telephone company (see [DDF+ 99] and [WSP00]). This case study models the calling center receives the request of some customer, either a request for ordering services or a request for obtaining information of data concerning the customer. Our example illustrates the composition of our components as well as the checking of the constraint formulated in the export. In Figure 2 a net component InformationService is depicted, that models the service for handling a request for obtaining information. It Information Service EXPORT Signature information service [InformationRequest][InformatioRequest,CostItem] Constraints BODY IMPORT Information Request r

Get Data d

Information. input[r][d]

ReqData d

Handle Request [d][res]

res

r Information Request

Result res rr

New Request r

Message. quest[r][r] DET

Cost Item

Give Information r

r

Information Request

Information. output [r,res][ci]

ci

Information Request r

Signature Information.input[InformationRequest][ReqData,InformationRequest] Information.output[Informationrequest,Result] [CostItem,InformationRequest] Message.quest[Informationrequest][Informationrequest]

Figure 2: Net Component uses services of a code component Information given in Figure 3. The import interface of information service contains on the one hand the object signatures of the services used

by this component and an abstraction of the processes using the imported services. Hence, 8

the constraints given in the export of the component Information have to be satis ed by the import net. The body contains the same net together with a Petri net interpreter that enacts the net. The import net models that an business object InformationRequest on the input place, the the transition Get Data res invoking the service Information.input with the input parameters [r] of type InformationRequest and output parameters [d] of type emphReqData and [r] of type InformationRequest. The transition Handle Request evokes another net component, hence the service does not have an extra name. Then by transition Give Information the requested information is given and a cost item is created using the service Information.out. Next the transition New Request invokes the deterministic service Message.quest. Hence, either a token is layed onto the output place or onto the input place. The export interface of the code component Information in Figure 3 provides Information EXPORT Signature input[InformationRequest] [ReqData,InformationRequest] output[Informationrequest,Result] [CostItem,InformationRequest] Constraints always (output once input)

Message EXPORT Signature quest[InformationRequest][InformationRequest](DET)

BODY

BODY

IMPORT

IMPORT

Figure 3: Code Components the signatures of the services for the processing of the information request together with constraints concerning the causal dependencies of those services. This causal dependency constraint always (output =) once input) means that the invokation of service output implies that service input has already been invoked at least once. The export interface of the code component Message in Figure 3 provides the signatures of the services concerning the automated question for further requests. The composition of these three components yields a component that has an import based on the imports of the used components and the export interface of the using component, namely Information Service. Moreover, the export constraints have to be checked. Clearly, the labeled place/transition net given in Figure 1 satis es the export constraints. In more complex cases various model checking techniques can be required (see for example [Hei98, BS90]). The causal dependency constraint always (output =) once input ) is satis ed in the transformed net depicted in Figure 1 since the rst ring step is the ring of transition Get Data with label Information.input. Therefore, for any transition ring subsequerntly we have once input, especially output =) once input. Since, there is no other way for ring the rst transition we have always (output =) once input). Note, the net would satisfy the even stronger constraint, that for each invokation of service output there has been the `new' invokation of service input.

9

5 Conclusion We have introduced a Petri net based concept for describing with a process-centered and component-based design strategy evolvable architectures. The Eva approach strengthens the component principle without weakening the business processes. Eva proposes three kinds of components: for business processes, business objects and for code. The component for business processes is based on a special variant of Petri nets. Here, we have concentrated on the underlying Petri net formalisms and its role for the composition. In an example from our case study [DDF+99] we have illustrated the composition of components. The composition follows the black box principle, but allows checking consistency with respect to the business processes. This consistency check is part of the static composition. This possibility is achieved by additional information in the interfaces. We have presented three components from our case study and have illustrated the composition of these. Future research comprises the extension of the Eva approach to communication between components and the integration of side-eects. Moreover, a sucient concept of instances of components has to be formulated.

References [BS90]

J. Brad eld and C. Stirling. Verifying temporal properties of processes. In J. C. M. Baeten and et al., editors, Lecture Notes in Computer Science; CON-

CUR'90, Theories of Concurrency: Uni cation and Extension. (Conference, 1990, Amsterdam, The Netherlands), pages 115{125, Berlin, Germany, 1990.

[DDF+ 99] M. Datta, M. Demski, S. Frassdorf, A. Gzik, M. Kirchho, S.-P. Maliyakkal, K. Meier, J. Padberg, A. Sunbul, A. Tagia Mueen, E. Vogel, and A. Zauner. EVA: Evolutionsfahige Architektur fur Kommunikations- und InformationsInfrastrukturen. Students Project - Technical University Berlin, Department 13 Computer Science, 1999. [DG98] W. Deiters and V. Gruhn. Process Management in Practice - Applying the FunSoft Net Approach to Large-Scale Processes. Automated Software Engineering, 5:7{25, 1998. [Gri98] F. Griel. Componentware { Konzepte und Techniken eines Softwareparadigmas. dpunkt Verlag, 1998. [Gru91] V. Gruhn. Validation and Veri cation of Software Process Models. PhD thesis, Universitat Dortmund, Abteilung Informatik, 1991. [Hei98] M. Heiner. Petri Net Based System Analysis without State Explosion. In Proc. High Performance Computing `98, pages 394{403. SCS Int., 1998. [MP92] Zohar Manna and Amir Pnueli. The Temporal Logic of Reactive and Concurrent Systems, Speci cation. Springer-Verlag, 1992. [Rei85] W. Reisig. Petri Nets, volume 4 of EATCS Monographs on Theoretical Computer Science. 1985. [vdA96] W.M.P. van der Aalst. Three good reasons for using a Petri-net-based work owmanagement system. In S. Navathe and T. Wakayama, editors, International Working Conference on Information and Process Integration in Enterprises, pages 179{201, Cambridge, Massachusetts, November 1996. 10

[vdA98]

Wil van der Aalst. The application of Petri nets to work ow management. The Journal of Circuits, Systems and Computers, 1998. [Web99] H. Weber. Continoius Engineering of Communication and Software Infrastructures. volume 1577 of Lecture Notes in Computer Science, pages 22{29. Berlin, Heidelberg, New York, 1999. [WSP00] H. Weber, A. Sunbul, and J. Padberg. Evolutionary Development Of Business Process Centered Architectures Using Component Technologies. In IDPT 2000, 2000. SUBMITTED.

11