CC BY-NC-ND
0Available online at www.sciencedirect.com
ScienceDirect
Electronic Notes in Theoretical Computer Science 207 (2008) 33-48
www.elsevier.com/locate/entcs
A Rigorous Model of Service Component
Architecture
Zuohua Ding 1
Center of Math Computing and Software Engineering Zhejiang Sci-Tech University Hangzhou, 310018, P.R.China
Zhenbang Chen 2
International Institute For Software Technology United Nations University P.O. Box 3058, Macau
National Laboratory for Parallel and Distributed Processing Changsha, 410073, P.R.China
Jing Liu 3 '4
Institute of Theoretic Computing East China Normal University Shanghai, 200062, P.R.China
Abstract
The Service Component Architecture (SCA) provides a platform-independent component model for service-oriented development. A service component with different communication mechanisms and implementation languages can be modeled in SCA. However, it lacks a formal foundation for SCA-based system specification and verification. This paper presents a formal service component signature model with respect to the specification of the SCA assembly model. Inspired by the idea of independence in SCA, a language-independent dynamic behaviour model is proposed for specifying the interface behaviour of the service component by port activities. Based on the dynamic behaviour model, the compatibility relation between components is discussed. A set of transition rules are given to map Business Process Execution Language for Web Services (BPEL) to dynamic behaviour expressions and then to Petri nets, thus the service component based system can be verified with existing tools. A case study is demonstrated to illustrate how to use our approach to constructing a web application in a rigorous way.
Keywords: Service Component Architecture, Formal Semantics, Service Composition, Petri nets, Verification.
1 Email:zuohuading@hotmail.com
2 Email:zbchen@iist.unu.edu
3 Email:jliu@sei.ecnu.edu.cn
4 Corresponding author
1571-0661/$ - see front matter © 2008 Published by Elsevier B.V. doi:10.1016/j.entcs.2008.03.084
34 Z. Ding et al. /Electronic Notes in Theoretical Computer Science 207 (2008) 33-48
1 Introduction
Nowadays service orientation becomes an important theme in software development. Based on the emerging computer network technologies, Service Oriented Computing (SOC) enables an environment in which software can be collaboratively and remotely developed rather than just locally developed. The key idea in SOC is the Service-Oriented Architecture (SOA), which provides a new paradigm for the existence and development of software system. Currently, many industrial standards are proposed in the spirits of SOA, such as Web services [25] and Open Services Gateway Initiative (OSGI) [22]. Though many specifications are presented in those standards, the main attention is usually put on the service communication and composition, such as SOAP [26], BPEL [1], etc. How to implement a service and what the service programming model is are still problems. Recently, in the background of SOA, the Service Component Architecture (SCA) [3] is proposed for facilitating the implementation of service based systems. The SCA definition from the official site [3] is as follows:
"Service Component Architecture is a set of specifications which describe a model
for building applications and systems using a Service-Oriented Architecture."
Besides that, SCA provides a language-independent way to define and compose service components in the system, and it also supports different language-specific ways to implement the components including Java, C++, etc. SCA complements some service composition languages (such as BPEL) for enabling the more convenient and efficient service-based development.
From the SCA specification document [3], we can see that the SCA assembly model lacks a formal definition, and only static signature information of the service component can be defined. As a service programming model [2], it is not enough for SCA to just provide informal definitions by which only the static signature information can be defined. A rigorous definition for the programming model is required, and a model for specifying the dynamic behaviour of the service-based system is also needed. In addition, how to ensure the correctness of the service-based system is also an important problem for service-based development.
The contributions of this paper contain four parts. Firstly, a formal service component signature model is presented with respect to the specification of the SCA assembly model. Secondly, based on the signature model, a language-independent dynamic behaviour model is proposed for specifying the interface behaviour of the service component by port activities. Thirdly, a method for translating BPEL to the dynamic behaviour expression is given for showing that the dynamic behaviour model is rich enough in expressivity. Lastly, based on the dynamic behaviour model, we present a verification method for the service component based system by translating the dynamic behaviour model to a Petri nets and using the existing tools for verification.
Through our approach, the component structure of the SCA assembly model is defined rigorously, and some structure constraints are especially reflected. The syntax and semantics of the dynamic behaviour model can capture two different types
of communications, and support the component composition directly. The developer of the service component based system can use our approach to understanding SCA correctly, and specifying the service component formally for verification to ensure the correctness and decrease the errors in development.
The paper is organized as follows. In Section 2, a component model for the assembly model in SCA is presented and the operational semantics of the dynamic behaviour model is given. Section 3 models BPEL interface behaviour with SCA and verifies BPEL process by mapping dynamic behaviour expressions to Petri nets. Section 4 is a case study to illustrate the formalism and the verification. In Section 5, the related work is reviewed and compared. Section 6 concludes the paper and discusses some future directions.
2 Component Model for SCA
SCA aims to encompass a wide range of technologies for service components and for the accessing methods which are used to connect them. One basic artifact of SCA is the service component, which is the construction unit for service-oriented system.
2.1 Service Component Model
A service component may provide or require some services, which can be described by the operation activities as well-defined business function. Component interaction is through message exchange, and the business flow can be represented by the message exchange flow. A service component is a configured instance of a component implementation. A component provides and consumes services via ports as shown in Fig. 1.
Properties
Implementation
- Java
- BPEL
- Composite
Fig. 1. SCA component diagram
Ports represent the addressable interfaces of the component and the requirement that the component has on a service provided by other component. Each component offers the business functionalities through ports, and a set of methods are contained in each port. In SCA, if the component provides a service through a port, the port is called service port; if the component requires a service through a port, the port
is called reference port. Beside that, two communication types can be supported by the port in SCA: synchronous communication, which means that the sending side needs to wait until the result is received; asynchronous communication, which means that the sending side can proceed without waiting for the result. The formal definition of a port is given as follows.
Definition 2.1 [Port] A port p is a tuple (M, t, c), where M is a finite set of methods, t is the port type that can be provided or required, and c is the communication type that can be synchronous or asynchronous.
Each method is of the form op(T x ; T y), where op is the method name, T x and T y are the input and output parameter lists, in which T is the parameter type and x,y are the parameter names. We use p.M to denote the method set of port p, p.t to denote the port type, and p.c to denote the communication type. Two ports pi and p2 are equal iff they have same methods and types, that is, p\.M = p2.M A pi.t = p2.t A pi.c = p2.c. For the sake of simplicity, we use !p to denote the provided port (service port), ?p to denote the required port (reference port), •p to denote the synchronous port, and 4p to denote the asynchronous port.
'^composite x
Fig. 2. SCA composite diagram
The SCA assembly model consists of a series of artifacts which define the configuration of an SCA domain in terms of composites. A composite contains assemblies of service components, the connections and related artifacts which describe how they are linked together. The composite diagram is shown in Fig. 2. An SCA wire within a composite connects source component required port to target component provided port. If a link is from service port to service port or from reference port to reference port, then it is called promote. In addition, a component can be implemented by a composite, which means that the component can be hierarchical. From the SCA specification, a unified static signature definition for SCA components and composites is given as follows.
Definition 2.2 [Component] A component Com is a tuple (Pp,Pr, G, W), in which Pp is a finite set of provided ports, Pr is a finite set of required ports, G is a finite sub component set, W C TP x (Jceo(C-PP u C.Pr) is the port relation that is nonreflexive, where TP = Pp U Pr uUceo C.Pr, C.PP and C.Pr denote the provided
and required port sets of the sub component C respectively.
A component Com = (Pp,Pr, G, W) is an atomic component if G = 0, otherwise Com is a composite. A port relation (pi,p2) is a promote if p1.t = p2.t, and (pi,p2) is a wire if p1.t = required A p2.t = provided. In SCA specification, there are some constraints on the static signature definition of composite, such as the wire compatibility. Consistency has been defined to represent that the component is statically well-composed [17].
Besides the static consistency checking, the formal reasoning or verification during the development process cannot be supported using the static signature information. We use port activities to describe the component dynamic behavior, the basic activity of which is assumed to be the message exchange between two ports. The syntax of the component dynamic behaviour expression is defined as follows.
p •m (Synchronous sending message)
P1 •m P2
P ◦m (Synchronous receiving message)
P1 ◦m P2
P im (Asynchronous sending message)
PlimP2
P Om (Asynchronous receiving message)
Pl0mP2
stop (Stop)
BE ; BE (Sequence)
BE <b> BE (Condition)
b * BE (Loop)
BE n BE (Non-determinism)
BE || BE (Parallel)
BE[pi/p2] (Renaming)
BE \ a (Restriction)
BE[pi ^ P2] (Wiring)
Here b represents the boolean expression, whose definition is omitted, and m stands for the message. p •m represents that the port p sends the message m synchronously, but p is not wired with any reference port. p1 •m p2 represents that the port pi synchronously sends the message m to the port p2. a represents a set of ports. The meanings of the other basic activities are similar.
BE[p1/p2] is the syntactic renaming, which just replaces each p2 in BE with pi, and can be used for specifying the promote element in SCA composite. BE[p1 ^ p2] is used to specify the wiring operation, which is the syntactic transformation defined as follows (0 £ {•m, om, Om}).
P2 *m Pi
BE[pi ^ p2] = <
P2^mPi PiOmP2
BEi [pi ^ P2] ; BE2 [pi ^ P2] BEi [pi ^ P2] < b > BE2 [pi ^ P2] b * BEi [pi ^ P2] BEi [pi ^ P2] n BE2 [pi ^ P2] BEi [pi ^ P2] I BE2 [pi ^ P2] BEi \ a BEi [pi ^ P2] \ a BE
BE = p »m Ap = P2
BE = p om Ap = pi
BE = p A p = P2
BE = p Om A p = Pi
BE = BEi ; BE2
BE = BEi < b > BE2
BE = b * BEi
BE = BEi n BE2
BE = BEi | BE2
BE = BEi \ a A (pi e a V p2 e a)
BE = BEi \ a A (pi / a A p2 / a)
BE = pi 0 P2
From the syntax of dynamic behaviour expression, we can see that the ports for message exchange do not need to have the same methods, and the information of the communicating ports will be gotten after wiring.
2.2 Operational Semantics
The operational semantic of the dynamic behaviour expression will be presented in this subsection. We use the classical Labelled Transition System (LTS) to define an operational semantics, and the small-step operational semantics is adopted here. The transition label a can be the message activity or the internal action (t). We use O(a) to denote the communication type of the message activity a: O(p1 © p2) = ©, O(p ©) = ©, where © G {•m, om, 0m, +m}.
For interpreting the semantics of asynchronous communication, the configuration of the transition system is {BE, E), where BE is the behaviour expression and E is the global asynchronous activity queue, which is unbounded. We use E"a to represent the resulting queue after adding activity a to the end of E, E \ a to represent the resulting queue after removing the first activity a in E, and a G E to represent that the activity a is contained in the queue E. In the following definitions, BE is used to abbreviate {BE, E) if no conflict exists.
The basic synchronous semi-message activity does not have the complete communicating partner information, which will be achieved in the future. We adopt an optimistic semantics at here, and assume that the component environment will always provide a legal support for the semi-message activities in the component behaviour expression, so the basic synchronous semi-message activity will always complete. After getting the complete port information, the basic synchronous message activity can complete after synchronization.
Pi •m P2
Pi»m P2
P om PiOmP2
P Om -► Stop pi Om P2 -► Stop
The transition of basic asynchronous semi-message activity is similar to that of the synchronous one. The sending of asynchronous message will add the activity to the global queue. If the corresponding sending activity exists in the global queue, the asynchronous receiving activity can complete and the first appeared corresponding
activity is removed from the global queue.
P im stop (PiimP2, E) ^ ^ mP— (stop, E^PiimP2)
P2+mPi G E
p Om Stop (piOmp2 , E) P 1 0 > (stop, E \ p2^mpi) There are two rules for the sequential behaviour composition BEi; BE2. The second rule means that the completion of the first behaviour will begin the second one.
BEj A BE[ BEj A stop
BEi; BE2 —> BEi; BE2 BEi; BE2 —> BE2 The semantics of condition expression is also defined by two rules. The evaluation of boolean expression b can be true or false, which determines the one for executing.
b = true A BEi A BE[ b = false A BE2 A BE'2 BEi <b > BE2 A BE[ BEi <b > BE2 A BE'2
The loop expression will continue if the boolean expression is evaluated to be true, otherwise it will complete.
b = true A BEi— BEi b = false
b * BEi — b * BEi b * BE — stop
The non-determinism expression can select any one branch for execution, and the semantics rules can be given as follows.
BEi — BEi BE2 — BE2
BE1 n BE2 A BEi BE1 n BE2 A BE2
The parallel expression will have different cases. If the two wired component can take the synchronous communication, they will both transit to the next configuration, and the global transition action is the internal action t, which represents that the communication cannot be observed from the outside of the composite containing those two components.
BE1 l-^mA. BE'1 A BE2 BE2
BE1 y BE2 — BE[ y BE¡2
The transition of internal action or semi-message activity in one component will not need the participation of the other component, so it will not block the behaviour.
BEi —> BEi
1 (ae{r,p©})
BEi y BE2 — BE[ y BE2
The asynchronous message activity will also not block, but it cannot be observed from the outside of the composite.
BEi A BEi , . A
(■a = Pi+mP2 V a = pi<)mP2)
BEi y BE2 —► BEi H BE2
The switching of the expressions of the parallel expression will not change the behaviour.
BEi || BE2 —► BE3 BE2 || BEi —> BE3 The message exchange can only occur between non-restricted ports.
BEi —> BE2 , , , , , n
------— (a = Pi ©m P2 V a = piQm) A (Pi f a A p2 f a)
BE1 \ a — BE2 \ a
The stop represents the termination of the dynamic behaviour, and it cannot engage in any action.
The dynamic behaviour of the component can be interpreted by the sequences
of actions. A finite action trace tr is ai,a2,..., an. We use BE —► BE' to represent that BE can transit to BEt by the preceding operational semantics rules, and the transition sequence is the action trace tr, that is, BE ^ BEi,..., BEn-i BE'.
2.3 Component Composition
In an SCA composite, the wires can be generated automatically. This feature can be reflected by the automatic composition, which can automatically relate the required ports and provided ports of two components, and generate the resulting composite by promoting the remaining non-wired ports.
At the signature level, two components Com,i = (Pp,Pl,Gi, Wi) (i G {1,2}) are composable if they do not provide the same port, that is, Ppi n Pp = 0. We define the automatically related required port set as follows:
Mp(Comi,Com2) = (Pri ffl Pp2) U (Pr2 ffl Ppi), where Pr ffl Pp = {p | p G Pr A (p.M, provided,p.c) G Pp}. The automatically generated wire set can be defined as follows:
Mw(Comi,Com2) = {(pi,p2) | Pi G Mp(Comi,Com2)A
P2 = (pi.M, provided,pi.c)}. The automatic composition is defined as follows, where the definition of the wire set operation is:
nrnw i = / be i/w = 0,
BE[W 1 ^ BE[pi ^p2][w\{(pi,P2)}] (P1,P2) ew.
Definition 2.3 [Automatic Composition] Given two composable components Comi = (Pp,P,i,Gi, Wi) and their dynamic behaviour expressions BEi (i G {1,2}), their automatic composition Com = (Pp,Pr,G,W) (denoted by Comi © Com2) is defined as follows:
(1) Pp = (Ppi U Pp2) \ {(p.M, provided ,p.c) | p G Mp}; (2) Pr = (Pri U P2) \ Mp;
(3)G = Gi U G2;(4)W = Mw U {(p,p) | p e Pp U Pr};(5)BE = (BEi || BE2)[MW], where Mp and Mw are the abbreviations for Mp(Comi,Com2) and Mw(Comi,Com2) respectively.
Theorem 2.4 Comi © Com2 = Com2 © Comi.
Theorem 2.5 If Mp(Comi,Comj) n Mp(Com-i,C omk) = 0, where i,j,k e {1,2, 3}, i = j, i = k, and j = k, then (Comi © Com2) © Com3 = Comi © (Com2 © Com3).
Definition 2.6 [Promoting] Given a component Com = (Pp,Pr,G,W) and a promote (pi,p2), and the dynamic behaviour expression of Com is BE, where p2 e Pp U Pr, the dynamic behaviour expression of the resulted component after promoting is BE[pi/p2].
Based on the promoting definition and the behaviour semantics, the composition of specific port relation can be defined as follows, where the definition of promote set operation is:
BE(W) = { BE[pi/p2]{WE\ {(pi,p2)}> (L «) e W.
Definition 2.7 [Composition] Given two composable components Comi = (Pp,, P£,Gi, Wi), their dynamic behaviour expressions BE, (i e {1,2}), and a port relation set W, the specific composition of Comi and Com2 under W is Com = (Pp,Pr, G, Wc) (denoted by Comi ©w Com2), which is defined as follows: (1) Pp = {pi | (!pi, !p2) e W};(2) Pr = {pi | (?pi, ?p2) e W};(3) G = {Gi,G2};
(4) Wc = W; (5) BE = (BEi || BE2)[Ww](Wp), where Ww ={(pi,p) | (pi,p2) e W Api.t = p2.t}, and Wp = {(pi,p2) | (pi,p2) e W Api.t = p2.t}.
Theorem 2.8 Comi ©w Com2 = Com2 ©w Comi.
Lemma 2.9 Comi © Com2 = Com2 ©w Comi, where W = Mw(Comi,Com2) U {(p,p) | p e ((Pp1 U Pp2) U (Pi U Pr2)) \ (Mp U {(p.M, provided,p.c) | p e Mp})}, and Mp is the abbreviation for Mp(Com1,Com2).
Through the above definitions, we can calculate the dynamic behaviour expression of the composite based on the dynamic behaviour expressions of the contained components. Given the composite Com = (Pp,Pr,G, W), and the dynamic behaviour expressions of the sub components, the dynamic behaviour expression BE of Com can be calculated as follows: BE = n{BEC | C e G}[Ww](Wp), where nB = Bi || ... || Bn if B = {Bi,...,Bn}, Ww ={(pi,p) | (pi,p2) e WA pi.t = p2.t}, and Wp = {(pi,p2) | (pi,p2) e W Api.t = p2.t}.
With the assumption that the environment will always provide what the component needs, the dynamic behaviour compatibility between two components only requires that the dynamic behaviour of the composed composite can complete, which can be defined as follows.
Definition 2.10 [Compatibility]Given two components Comi and Com2, their dynamic behaviour expressions BE1 and BE2, and a port relation W, Com1 and Com2
are compatible under W (denoted by Compw(Comi,Com2)) if the following conditions hold: (1) Comi and Com2 are composable; (2) there exists an action trace
tr such that BE —► stop, where BE is the dynamic behaviour of Comi ©w Com2.
3 SCA Modeling and Verification of BPEL
BPEL [1] is an XML language that supports service composition and can be used to describe executable business process behavior. WSDL is now a standard for describing its interfaces. WSDL proposes a model containing two parts: in the first part there are methods; the second part defines the messages each method can send and receive. However, WSDL addresses only static interface specifications and it does not describe the observable behavior of the web service. We show that, as a language-independent dynamic behaviour model, SCA can be used to model the interface behavior of BPEL.
In BPEL, the participating services are called partners, and message exchange or intermediate result transformation is called an activity. A process thus consists of a set of activities. A process interacts with external partner services through a WSDL interface. An interaction is characterized by the partner link, the port type, and the operation involved in the two communicating partners (each partner defines these three elements for each interaction). We say that an interaction corresponds to a port of a component. For example, if an interaction is to receive a request from a client,
{receive partnerLink = "client"
portType = "com : InsuranceSelectionPT" operation = " Select Insurance" variable = " InsuranceRequest" createlnstance = "yes" /) then there is a port p=(M, t, c), where
M = {SelectInsurance(T InsuranceRequest;)},
t=provided,
c=asynchronous.
In this example, the partnerLink, portType and createInstance are all contained in the message and will be used in the management components in the future. In this paper, we only consider functionality components.
BPEL supports primitive and structural activities. Primitive activities represent basic constructs and are used for common tasks, structural activities manage the control flows. Some commonly used activities are: {invoke), {receive),{reply), {sequence), {flow), {switch), {while), {pick), etc.
By defining some transition rules for these constructs, we may map a BPEL process model to an SCA model, and then following the sematic model in Section 2, we can study the dynamic behaviour of BPEL. Due to the space limit, the rules can be refered to [17].
BPEL provides no way to verify correctness. A few works have been done to overcome the this problem such as mapping BPEL to LOTOS [8], translating BPEL into FSP [14], analyzing BPEL composite web services communicating through asynchronous messages [15], etc. Our solution is mapping dynamic behaviour expressions of SCA to Petri nets, so that we can use the existing net tools for the verification. In this way, the BPEL process model may get the following benefits: 1) it has strong scalability and can manipulate both control and data, 2) it can be verified, and 3) it stands a good position for service substitution [17]. Another reason choosing Petri net as a verification method is due to the work by Tsai and Xu [24]: Petri-nets, as the intermediate formal basis, can be transformed into the input languages of existing analysis tools such as SPIN, SMV, SMC, and IOTA.
By setting some rules, we can transform component dynamic behaviour expressions to Petri nets [16]. The details can be found in [17].
4 Case Study
In this section we present an online shop as our example process. It is a simple but realistic business process.
The process is structured into two concurrent activities: customers initial choice and order processing. These activities are synchronized by two order links. Hence, the order processing is started only if the customer sends an order right at the beginning or he sends a request, the product is available, and he decides to order after getting the confirmation. Assuming the customer has ordered a product, he gets the invoice or he is asked questions concerning his order exactly once. The payment is handled by charging the credit card. Finally, the process sends the delivery data.
The interface of the service is defined by WSDL and the interaction is defined by BPEL4WS. We may get the SCA model by transforming WSDL/BPEL defines to dynamic behavior expressions. The SCA model of the online shop is shown in Figure 3.
Fig. 3. SCA model of online shop.
For example, ports
P^Me-si = ({request(T Req; T Resp)}, provided, synchronous), pChecfc = ({check(T checkReq; T checkResp)}, required, synchronous), Polder = ({order(T orderReq; T order Resp)}, required, synchronous), form atomic component C11 = INIT with dynamic behavior expression
BE Prequest . CPchecfc ^ b > pnder ).
Ports pC2ecfe, P^eject and p]2-der form atomic component C02 = ORDER with dynamic behavior expression
BEee = p02 . (p02 4ht>p02 ). p02
BE pcheck.(preject ^ b > pconfirm); porder .
Ports P^der> Pf/uestion, P^ate and P^voice form atomic comPonent C20 = INVOICE with dynamic behavior expression
BE2 = P2 ; P2 ; P2 ; P2 .
BE p order . P question. pupdaie. pinvoice.
Ports P^voice, Ppaycheck and Pd°Ziver form atomic-comPonent C22 = pAYMENT with
dynamic behavior expression
B22 = P22 ; P22 ; P22 .
B Pinvoice. Ppaycheck. Pde/iver.
Let C0 be the automatic composition of components C00 and C02, then C0 = C00 © C02 = (Pp0,Pr0,G0,W), where
p0 = p00 U P02 \ {(p.M, provided,P.c)|P e Mp)}
= {PlUestj }, Pr0 = Pr00 U Pr02 \ Mp(C00 ,C02)
= {Pfim Polder Polder PU } \ {pcl*}
= {P02 P01 P02 }
confirm order order
G0 = {},
W0 = Mw U{(P,P)|P e Pp0 u Pr0}
= {(P^ecfc^Lfc)} U {(P,P)|P e Pp0 U Pr0}
{(P00eck,Pc2eck)} U {(P0equest,P0equest), Polder Prder ), (Pjet ),
(P02nfirm,P00nfirm), (porder ,porder ) },
BE0 ^BE00!^02)^^ - Pcheck) }].
Similarly, we can get the automatic composition of components C20 and C22 as C2 = C20 © C22 = (Pp ,Pr2,G2,W2) with behaviour expression:
BE° = (BE°° ! BE°2)[{ (invoice — invoice i) }].
Assume that port relation set is W = W\UW2U{(pOrder,p2order)}, then a semantic model of dynamic behavior of online shop, denoted as SCAonline, would be
SCAonline C l ©w C2
with behaviour expression:
BE = (BE11| BE2)[Ww ] (Wp),
where ww = {(pi,p2)|(pi,p2) G W A pi.t = p2.t}, and Wp = {(pi,p2)|(pi,p2) G W A pi.t = p2.t}.
Our interest is located in computing the dynamic behavior BE. Based on Lemma 1,
SCAonline C l©w C2 = C1 © C2.
Thus, the dynamic behavior BE = (BE1|BE2)[mw ] = BE1[MW ]||BE2[mw ],
12 11 22 21 21 12 mw = {pcheck * pcheck,pinvoice * p2nvoice,porder * p02der, 1 = User — InpUtS}.
As an example we compute BE1 to illustrate our method: BE1 = ((BE11 [mw ])||(BE12 )[mw ]), where
BE11[Mw ]
= (plrl^quest°;(plolrder ♦ < b > PCheck•))[Mw]
= ^request 0 [{I,... }]; (pCCder♦ < b > plheck*)[{plcheck ^ Scheck,-. }] = stOp;(p0rder ♦ < b > plcheck^)[{plleck ^ p^ck^.. }]
= (p0rder }] < b>pcheck^)[{pcheck ^ pcheck,...}]
check 11 12 11
pcheck • Wp check ^ pcheck^.. }]
Scheck • pcheck
BE12 [mw]
(pcheck0;(pccject • <b > p1onfirm o); P order ^)[{pc2eck > Pcheck,1,... }] = Scheck 0 KC^heck ^ pcheck) }];
inject • <b > pa1nfirm^l^1^.. }]; po2der ^)[{porder ^ p12der }] pcheck 0 pcheck; p confirm • K1^.. }]; porder ♦[{po1der ^ porder,... }].
BE1 = (plcheck • pcheck) H (pcheck 0 Scheck; infirm • [{I,... }]; pofder ^[{(po1der ^ p 12der ,... }])
StOlp ! (StOP. P0onfirm • [{1,... }]. Po2der ^[{Porder * Porder, ... }D = Pconfirm • — }]. Po2der ^[{Porder — Porder,... }] stoP. Po2der ^[{Porder * Po2der, ... }] P02d,er order.
After translating the dynamic behavior expression into a Petri nets, we can perform the analysis on the SCA model of the online shop by the following two ways: either using net tools such as Design/Net [6], or converting the Petri-net model into the input languages of analysis tools such as SPIN, SMV, SMC, and IOTA [24]. In Design/CPN, we can perform two kinds of analysis through simulation. The first can be done on the standard simulation report directly, which includes Boundedness and Liveness properties. The second is performed based on user-defined queries about the Occurrence Graph, which is the state space of the model.
5 Related Work
Because SCA is a new proposed specification, there are few existing work in formal-ization and verification for SCA. In [13], a small core formal language (SRML-P) is presented to specify the interaction protocol between components. SRML-P follows the ideas in SCA and provides a mathematical framework in which some service-modeling primitives are defined and application models can be reasoned about. Based on the primitives, some communication paradigm can be specified, such as synchronous, asynchronous, timeout, etc. Besides that, the proposed concepts, such as modules and external interface, are also related to the modeling elements in SCA. Compared with the work in [13], our work directly formalizes the SCA assembly model and the service dynamic behaviour model also supports synchronous and asynchronous communication.
In the implementation level, [4,27] propose formal models to formalize XML-based Web service languages. In [27], H. Yang et al. propose a formal model to WS-CDL to guarantee the correct interaction of independent web services. Based on the this model, it is possible to formally reason about the choreography in a manual way. In [4], Antonio Brogi et al. formalize WSCI using CCS. Compatibility and replaceability between Web services are discussed. In [23], G. Pu et al. develop semantics for BPEL and then to verify BPEL. Compared with them, we are concerned with the interface dynamic behavior from an orchestration view, and apply our platform-independent description mechanism to BPEL. In [28], CSP is directly used to formalize WS-CDL and BPEL, and verification can be taken after translation. We share the idea of using existing tools for verification, and the dynamic behavior model is proposed according to the SCA specification, which is convenient to model the system using SCA.
In component based development (CBD), how to construct composite components from existing ones is not new [11,12]. In the object-oriented programming community, there has been extensive research on attacking this issue, such as Su-perGlue [21], Jiazzi [20], the calculus of assemblages [19], etc. However, our model
is constructed based on the service. It is not only directly for internet use but also provides dynamic property check in composition. When chaining components together, the verification and calculation should be based on the semantics of the behavior. In [7], static structure, dynamic behavior and refinement of component systems is proposed based on UML 2.0 superstructure. Interface Protocol State Machine (IPSM) in UML 2.0 is used to specify the interface behaviour and contract automata is presented as the transition model of IPSM. The component structure model is also hierarchical, and the stateless operation feature is included in the contract automata. Compared with the work in [7], we unify the component definition using port, and take into account different communication types in the behaviour model.
6 Conclusion
We have proposed a rigorous approach to supporting service oriented development based on service component. Service component is modeled according to the standard of service component architecture issued recently. Dynamic behavior expression is developed to describe the composition activities in service composition. A set of transition rules are given to map BPEL to dynamic behavior expression, thus the service composition process can be verified with Petri net. A case study is given to show how to use this approach to constructing web based software in a rigorous way.
Our future work includes introducing agents to route service, in order that a source can easily find the target one. We will also look into adaptable service component architecture to improve the adaptability of the component to the environment. It will be an interesting research topic to investigate how different verification techniques and tools can be applied.
Acknowledgments
This work is partially supported by the National High Tech Research 863 Program of China under Grant No.2006AA01Z165; the National Natural Science Foundation of China under Grant No.60673114, No.60603033, No.60603037, the projects HTTS funded by Macao Science and Technology Fund. The second author is partially supported by the project HighQSoftD funded by Macao Science and Technology Development Fund, the National Basic Research Program of China (973) under Grant No.2005CB321802 and NSFC under Grant No.90612009 and No.60573085.
References
[ 1 ] Arkin, F. et al. Web Services Business Process Execution Language Version 2.0, http://www.oasis-open.org/apps/org/workgroup/wsbpel/, 2005.
[2] Apache TUSCANY, http://cwiki.apache.org/TUSCANY/sca-overview.html, 2007.
[3] Beisiegel, M. et al., Service component architecture specification, http://www.osoa.org/display/Main/Home, 2007.
[4] Brogi, A., C. Canal, E. Pimentel and A. Vallecillo, Formalizing web wervice choreographies, Electr. Notes Theor. Comput. Sci. 005 (2004), pp.73-94.
[5] Brogi, A., C. Canal and E. Pimentel, Component adaptation through flexible subservicing, Science of Computer Programming, Vol.63, No.0 (2006), pp.39-56.
[6] Design/CPN, http://www.daimi.au.dk/designCPN/.
[7] Dong, W., Z. Chen and J. Wang, A contract-based approach to specifying and verifying safety critical systems, Electr. Notes Theor. Comput. Sci. 076(2007), pp.89-003.
[8] Ferrara, A., Web services: a process algebra approach, in Proceedings of 2nd ACM International Conference on Service Oriented Computing, New York, USA, 2004, pp.242-250.
[9] Fisteus, J.A., L.S. Fernandez and C. D. Kloos, Formal verification of BPEL4WS business collaborations, in Proceedings of the 5th International Conference on Electronic Commerce and Web Technologies (EC-Web'04), 2004.
[00] Farahbod, R., U. Glasser, M. Vajihollahi, Specification and validation of the Business Process Execution Language for web services, LNCS, vol. 3052 (2004), Springer-Verlag, pp.78-94.
[00] Chen, Z.B., Z. Liu, V. Stolz, L. Yang and A. Ravn, A Refinement Driven Component-Based Design , in Proc. Of ICECCS 2007, pp. 277-289, IEEE.
[02] Chen, Z.B., Z.Liu, A. Ravn, V. Stolz and N. Zhan, Refinement and Verification in Component -Based Model Driven Design, Technical report 388, UNU-IIST, Nov. 2007.
[03] Fiadeiro, J. L., A. Lopes and L. Bocchi, A formal approach to service component architecture, in Proc. of Third International Workshop Web Services and Formal Methods, LNCS, vol. 4084(2006), Springer-Verlag, pp.093-203.
[04] Foster, H., S. Uchitel, J. Magee and J. Kramer, Model-based verification of web service compositions, in Proc. of ASE'03, Canada, 2003, pp.052-063.
[05] Fu, X., T. Bultan and J. Su, Analysis of interacting BPEL web services, in Proc. of WWW'04, USA, 2004, ACM Press.
[06] Girault, C. and V. Valk, Petri nets for systems engineering, a guide to modeling, verification and applications, Springer-Verlag, Berlin, 2003.
[07] Ding, Z. and J. Liu, A rigorous model of service component architecture, Technical report, preprint of Institute of Software Engineering, East China Normal University, Dec. 2007, will be available at: http://www.sei.ecnu.edu. cn/~ jliu/.
[08] Hinz, S., K. Schmidt and C. Stahl, Transforming BPEL to Petri nets, LNCS, vol. 3649 (2005), pp. 220-235.
[09] Liu, Y. and S. Smith, Modules with interfaces for dynamic linking and communication, LNCS, vol. 3086 (2004), pp.404-439.
[20] McDirmid, S., M. Flatt and W. Hsieh, Jiazzi: new-age components for old-fashioned java, in Proc. Of OOPSLA 2000, pp.200-222, ACM.
[20] McDirmid, S. and W. Hsieh, Superglue: component programming with object-oriented signals, LNCS, vol.4067 (2006), pp.206-229.
[22] Open Services Gateway Initiative, OSGi Service Platform Specification, 3rd Release, 2003.
[23] Pu, G., X. Zhao, S. Wang and Z. Qiu, Towards the semantics and verification of BPEL4WS, Electr. Notes Theor. Comput. Sci. Vol.050, No.2 (2006), pp.33-52.
[24] Tsai, J.J.P. and K. Xu, An empirical evaluation of deadlock detection in software architecture specifications, Annals of Software Engineering, 7(0999), pp.95-026.
[25] W3C World Wide Web Consortium, Web Services Architecture. http://www.w3.org/TR/ws-arch/, 2004.
[26] W3C World Wide Web Consortium, Simple Object Access Protocol (SOAP) 0.0, http://www.w3.org/TR/soap/, 2000.
[27] Yang, H., X. Zhao, Z. Qiu, G. Pu and S. Wang, A formal model for Web Service Choreography Description Language (WS-CDL), ICWS 2006, pp.893-894.
[28] Yeung, W. L., Mapping WS-CDL and BPEL into CSP for Behavioural Specification and Verification of Web Services, ECOWS 2006, pp.297-305.
