LNCS 4275 - Defining and Modelling Service-Based ... - Springer Link

Defining and Modelling Service-Based Coordinated Systems Thi-Huong-Giang Vu, Christine Collet, and Genoveva Vargas-Solar LSR-IMAG Laboratory, BP 72, 38402 Saint Martin d’Hères, France {Thi-Huong-Giang.Vu, Christine.Collet, Genoveva.Vargas}@imag.fr

Abstract. This paper introduces M EO - a model for securing servicebased coordinated systems. The model uses constraints for expressing the application logic of a coordinated system and its required security strategies. Coordination activities are the key concepts used for controlling the execution of participating services. Constraints are specified as pre and post conditions of these coordination activities.

1

Introduction

The democratization of Internet along with recent advances in information technologies has made the global networked marketplace vision a reality. In such an environment, companies form alliances for building information systems that aggregate their services. Effective service sharing and integration is a critical step towards developing next generation of information systems for supporting the new online economy. Given the time-to-market, rapid development and deployment requirements, information systems are made up of the services of different providers that are accessible through networks, e.g., Internet. Such information systems are called coordinated systems. A service provider is an autonomous organism that keeps control on the service execution with respect to some nonfunctional aspects such as security. It predefines instructions and descriptions for using its services (e.g., where and when functions of these services can be accessed). Using a service implies invoking a method and (possibly) waiting for execution results. Numerous systems, models and languages have been proposed for supporting services coordination, i.e., the way services invocations are orchestrated according to the application logic of a given coordinated system. Existing solutions such as workflow models [5,8] or Petri nets [18] tackle the specification and enactment of services coordination. Using a workflow model, the execution of a coordinated system is controlled by a data flow and a control flow. The data flow specifies data exchange among participating services. The control flow describes their dependencies and it is expressed by ordering operators such as sequence, selection (OR-split, OR-joint) and synchronization (AND-split, AND-joint). Using a Petri net, the execution of a coordinated system is expressed by rules applied on data delivered to or consumed by participating services (i.e., places). It defines (i) R. Meersman, Z. Tari et al. (Eds.): OTM 2006, LNCS 4275, pp. 391–407, 2006. c Springer-Verlag Berlin Heidelberg 2006

392

T.-H.-G. Vu, C. Collet, and G. Vargas-Solar

rules for abstracting the structure of exchanged data (i.e., tokens) among services and (ii) rules for scheduling and sending input and output data that can fire some service execution (i.e., transitions). The interaction among services has been facilitated by current technologies that either adopt approaches based on interoperation [9,6] and based on intercommunication [10]. While particular attention has been devoted to services coordination, nonfunctional aspects such as security have been poorly addressed by existing coordination models, languages and execution engines. It is hard to accurately specify what a coordinated system has to do under specific security requirements such as authentication, reliability, non repudiation and messages integrity. It is also often difficult to consider in advance the coordination of participating services under a large set of interactions and interdependencies among them. A loose specification of an application logic can lead to a wrong order of interactions among services. We can also mistreat real situations during the coordination execution, e.g., invoked service is undesirably replaced by another. Another example is that information exchanged among services in the coordination context is altered without our knowledge. Managing secure coordination at execution time implies: – Verifying messages integrity (i.e., those exchanged among services) in order to avoid their unauthorised alteration. – Authentication of the services that participate in a coordination process (i.e., identify the invoked service and the service that provides results after an invocation). – Ensuring non repudiation of coordination: post-check the validity of coordinated system execution and prevent a participating service from denying previous actions. The challenges are to avoid security vulnerabilities of services coordination and provide strategies for ensuring security at run-time. Moreover, the proposed strategies should not contradict the facility of the coordinated system construction and services flexibility. It should be possible to adapt coordination and security aspects of coordinated systems according to different topologies, scenarios, delegation requirements and security configurations. We focus on the functional safety of coordination. We propose to enrich and adapt a coordination specification in a way that unintended behaviours can be detected and rectified. We propose to model such a control as constraints associated to so called coordination activities. Our model, called M EO (constraintbased Model for sEcure cOordination) offers concepts to describe the coordination of services as coordination activities and their associated constraints. These constraints are used to express coordination and security strategies for a coordinated system. The remainder of this paper is organized as follows. Section 2 introduces the M EO model. Section 3 and 4 describe the way coordination and security strategies are expressed in our model. Section 5 explains how to specify coordination and security aspects of a coordinated system. Section 6 compares our work with

Defining and Modelling Service-Based Coordinated Systems

393

existing ones. Finally, section 7 concludes the paper and discusses further research directions.

2

The Main Concepts of MEO

This section details the main concepts of M EO, the proposed constraint-based Model for sEcure cOordination.

Fig. 1. Booking flight application

Let us consider a flight booking application expressed as a coordinated system in Figure 1 (called coordinated system). The system is built from three existing services (called participating services). – Adventurer manages clients that are interested in booking flights. – P ayment executes online payment transactions on given client accounts. – Seeking looks for available seats and performs flight pre-booking operations on a flight database.

394


By invoking methods of these services, the flight booking application performs the following functions: (i) Lookup an available flight list according to given client’s needs. (ii) Book a flight by choosing it from the returned available flights list. (iii) Buy a tickets. As shown in Figure 2, using M EO, such a coordinated system is modelled through three fundamental concepts: coordination activity, coordination scenario and constraint. The application logic of this coordinated system is specified as a set of constraints on coordination activities within a given coordination scenario. Similarly, constraints expressed on security properties provided by services are coupled with reliability constraints used to express control flow among coordination activities in order to specify security strategies.

Fig. 2. Main concepts of MEO

2.1

Coordination Activity

A coordination activity specifies an interaction between two services, where one invokes a function provided by another and (possibly) waits for its execution results. Generally speaking a coordination activity (CA) is characterized as CA = (P, F, S, I, O, A), where: – – – –

P is the profile that identifies the coordination activity by a unique name. F denotes a specific function of a participating service. S is the current execution state of the coordination activity. I contains a set of parameters related to the input data of the coordination

activity. – O contains a set of parameters related to the output data of the coordination activity. – A is a set of attribute. Every attribute represents a specific property of the coordination activity and a possible value. For instance, the reservation function in our example is described as follows: In case of buying a booked flight, the booking confirmation is transferred to


395

the P ayment service. These information is redirected to the Seeking service to validate the reservation by invoking the method reserve Flight. We define the following coordination activities: – CA7 , where the payment information is collected: P7 = getPaymentInfos; F7 = Adventurer.get Booked Confirmation. – CA8 , for booking the flight according to the information received as input: P8 = reserveFlights; F8 = Seeking.reserve Flights. – CA9 , for processing a client’s order according to the information received as input: P9 = processingOrder; F9 = P ayment.processing Order. – CA10 , for displaying the booking result: P10 = showBookingResult; F10 = Adventurer.display Results. 2.2

Coordination Scenario

A coordination scenario is the history of the execution of a set of coordination activities. A coordination scenario (CS) is characterized by CS = (N, L, {(ER, IT, OT)}, CT), where: – – – –

N is a name identifying the scenario. L is a log that registers the execution status of a coordination. ER is an execution reference of an identified coordination activity. IT (incoming trace), contains the values of the input parameters of an identified

coordination activity. – OT (outgoing trace) contains the values of the output parameters of an identified coordination activity. – CT (context trace) contains the values describing the execution context of an identified coordination activity. For every coordination activity CAj belonging to the scenario CSi , the following information is traced: information about the instant in which a participating service starts or finishes a function (i.e., ERi,j ). Information about message producers and consumers (e.g., services) is logged (CTi ) with a time stamp and a signature, i.e., ITi,j , OTi,j . All coordination activities of CSi result in a log that contains information about successful or unsuccessful execution of the coordination scenario CSi . We can then analyze these traces to extract information that can be used to diagnose coordination failures. Through the log provided by the scenario, the coordination can be monitored and evaluated. Considering our example, we have three coordination scenarios CS1 , CS2 , CS3 , which are respectively the execution information of the lookup, book and purchase functions. For instance, the coordination scenario CS3 is defined as follows: CS3 = (N3 , L3 , {(ER3,j , IT3,j , OT3,j )}, CT3 ), where N3 = ”reserve” and (ER3,7 , IT3,7 , OT3,7 ), (ER3,8 , IT3,8 , OT3,8 ), (ER3,9 , IT3,9 , OT3,9 ), (ER3,10 , IT3,10 , OT3,10 ) are respectively the traces of coordination activities CA7 , CA8 , CA9 , CA10 of the

purchase function.

396

2.3


Constraint

Constraint is the basic concept used to manage and control coordination. A constraint defines the behaviour, the data, the characteristic or the interface that is selected as a requirement for a coordination activity or to refer to coordination scenarios. Constraints can be enabled, validated, observed and verified. Constraints are defined using set operators (∪, ∩, −), logic operators (∨, ∧, ¬, →), relation operators (∈, ∈, / ⊂, ⊆, ⊃, ⊇, =) and functions. A constraint (C) is characterized as C = (P, SC, T, ST), where: – P is a predicate defining the condition to be evaluated. – SC defines the scope of the constraint. It may be a coordination activity and a coordination scenario. – T is the occurrence time of the constraint verification. It can be before, during or after (i) the execution of a coordination activity, (ii) the activation of a coordination context and (iii) the validation of another constraint. So, constraints are of three types: pre-condition, post-condition and invariants. – ST is the structure that characterizes possibilities for composing constraints. It has three values: atomic, composite and nested. Given a set of coordination activities needing to be orchestrated according to specific functional (e.g. coordination) and non functional aspects (e.g. security), constraints express these requirements. So for each coordination activity, constraints describe what is considered, permitted, obligatory and forbidden. The following sections detail the constraints designed for our coordinated system example to ensure its functional safety.

3

Coordination Strategy

A coordination strategy corresponds to a specific logic property of a coordinated system. Properties are expressed by f unctional constraints considering the exchanged data and the temporal relationships among a set of coordination activities. Such constraints are added to coordination activities and are evaluated on coordination scenarios. We identify the following functional constraint types: ordering, firing and data dependency. The following sections define these constraint types. 3.1

Ordering

An ordering constraint represents temporal relationships between two coordination activities. Let CAi , CAj be two coordination activities to be orchestrated, and sti , stj and eti , etj their start and termination times respectively. Three ordering constraints can be associated to CAi in order to determine its relationship with CAj . – Before(CAj ): T RU E if CAi starts before CAj , F ALSE otherwise. – After(CAj ): T RU E if CAi terminates after CAj , F ALSE otherwise. – Simultaneous(CAj ): T RU E if CAi starts and terminates simultaneously with CAj , F ALSE otherwise.


3.2

397

Firing

A firing constraint represents the situation where the execution of a coordination activity cannot be fired until the execution of another coordination activity has terminated in a particular state. Let CA be a coordination activity to be orchestrated, and STATE = {S1 ,S2 ,..,Sn } be the set of possible termination states for this coordination activity. The following constraints can be defined on each state Si ∈ STATE of CA: – Consider(Si ): T RU E if Si is considered to fire the execution of the coordination activity CA, F ALSE otherwise. – Permit(Si ): T RU E if Si is permitted in order to decide whether to fire the execution of the coordination activity CA, F ALSE otherwise. – Obligate(Si ): T RU E if Si is obligatory to fire the execution of the coordination activity CA, F ALSE otherwise. – Forbid(Si ): T RU E if Si must not happen if the execution of the coordination activity CA must be fired, F ALSE otherwise. 3.3

Data Dependency

A data dependency constraint indicates the situation where a coordination activity consumes data produced by another coordination activity. Let CAi , CAj be two coordination activities to be orchestrated, Ii , Ij , and Oi , Oj their input and output data respectively. There are three possibilities for the input data Ii of the coordination activity CAi in relation with the output data Oj of the coordination activity CAj : – Contain(Oj ): T RU E if Ii contains Oj , F ALSE otherwise. – Belong(Oj ): T RU E if Ii belongs Oj , F ALSE otherwise. – Match(Oj ): T RU E if Ii matches Oj , F ALSE otherwise.

4

Security Strategy

We use non f unctional constraints to define security aspects such as integrity, authentication, authorisation, non repudiation and the final objective is the functional safety of coordination. Constraints are added to coordination activities to define authentication, authorisation, non repudiation and the integrity of exchanged messages. 4.1

Integrity

An integrity constraint provides a way for ensuring that authorized changes made to an application logic or a coordination activity do not violate their consistency. The consistency of a coordinated system is defined by the properties of coordination activities (e.g., profile), a coordination scenario (e.g., execution state) and constraints (e.g., scope). An integrity constraint associated to a specific property restricts the values that can be assigned to it.

398


Let us denote such a property by Ch and the set of its possible valid values by V = {v1 ,v2 ,..,vn }. The integrity Ch is determined by the following constraints: – Unique(Ch): T RU E if the value v to be assigned to Ch is unique among all possible values vi ∈ V, F ALSE otherwise. – Range(Ch, [vx , vy ]): T RU E if the value v to be assigned to Ch belongs to an interval [vx , vy ], where vx and vy ∈ V, F ALSE otherwise. – Free(Ch): T RU E if the value v is free to be assigned to Ch, F ALSE otherwise. – Invariant(Ch): T RU E if the value v is not altered after having been assigned to Ch, F ALSE otherwise. For a given tuple of characteristics (Ch1 , Ch2 ,.., Chn ) the following constraints can be defined in relation with their real assigned values: – Nul(Chi ): T RU E if no value is assigned to Chi , F ALSE otherwise. – Exist(Chi ): T RU E if there is a Chi with a valid assigned value, F ALSE otherwise. – ForAll(Chi ): T RU E all Chi have valid assigned values, F ALSE otherwise. The next paragraphs describe how to associate these constraints on coordination activities and an application logic. For coordination activity: Given a set of coordination activities CA set = {CA1 ,CA2 ,..,CAn }, where CAi = {Pi , Fi , Si , Ii , Oi , Ai }, the following integrity constraints can be defined: – Unique(Pi ): the profile (P) must have an unique combination of values for the name and the description. – Unique({Fi , provider, context}): (F) invoked within the coordination context, must refer to a unique function provided by a unique service. – Range(Si , [R1 , R2 , R3 ]): the execution state (S) of a coordination activity can have one of the following values R1 , R2 , R3 . • In the preparation step there are three values to be assigned to the state of a coordination activity CAi : R1 = {UNDERCONSIDERATION, WAIT, READY}. • In the treatment step there is one value to be assigned to the state of coordination activity CAi : R2 = ACTIVE. • In the termination step there are three values to be assigned to the state of coordination activity CAi : R3 = {ABORT, COMMIT, COMPENSATION}. – ForAll(Ii ): all input parameters (I) must have associated valid values. – Invariant((Oi )): output parameters (O), must be consistent when they are exchanged. – Exist(Ai ): attributes (A) must have some valid associated values. For application logic: Such a constraint is coupled with ordering constraints to verify exchanged data among a sender and a recipient.


4.2

399

Authentication

An authentication constraint represents the situation where an invocation in a coordination activity occurs only until its sender and/ or its recipient have been identified. Typically, authentication constraints merely ensure that the invocation sender is the coordinated system and/ or the invocation recipient is a participating service. The authentication card is associated with a coordination activity as its authentication attributes, e.g. digital certificates. It serves to the mutual authentication. Let CA set = {CA1 ,CA2 ,..,CAn } be a set of coordination activities to be orchestrated, CAi = {Pi , Fi , Si , Ii , Oi , Ai }, a set of possible names used to identify these coordination activities as NAME set = {N1 ,N2 ,..,Nn }, Ni ∈ Pi , and DEMO set = {D1 ,D2 ,..,Dn }, Di ∈ Ai a set of possible cards used to authenticate these coordination activities. The following authentication constraints are defined on the identity and the identity card: – NotConsidered(Ni ): T RU E if the name Ni is not considered as an authentication identity of the coordination activity CAi , i.e., there is no need for authenticating CAi , F ALSE otherwise. – Approved(Ni ): T RU E if the name Ni is in the list of approuved identities of the coordinated system, F ALSE otherwise. – Coupled(Ni , Di ): T RU E if the authentication card Di of the coordination activity CAi is correctly demonstrated for its identity Ni , F ALSE otherwise. At the execution level, once sender’s and recipient’s identities are explicitly represented, authentication constraints are validated by the relationships between authentication demonstration and the implicit sender and recipient of a coordination activity. Authentication constraints will be then applied on the function dimension (F ) of a coordination activity. 4.3

Authorisation

Based on the identity of a specific coordination activity, an authorisation constraint represents the situation where the invocation of a function is granted. Logically, authorisation constraints are checked after authentication constraints because authorisation solvers use the results of authentication solvers as their inputs. Authorisation constraints are defined by predicates that are similar to those defining firing constraints. Let us denote by FUNCTIONALITY = {f1 ,f2 ,..,fn } a set of possible functions to be invoked. Let CA = (P,F,S,I,O,A) be a coordination activity needing to be orchestrated and N ∈ P the approuved identity of CA produced by authentication solvers. There are four authorisation constraints that define the relation between an approuved identity IDi ∈ IDENTITY and an authorized function invocation fi ∈ FUNCTIONALITY in the scope of CA. – Consider(N, fi ): T RU E if N is under consideration to invoke the function fi in the scope of CA, F ALSE otherwise.

400


– Permit(N, fi ): T RU E if N is authorised to invoke the function fi in the scope of CA, F ALSE otherwise. – Obligate(N, fi ): T RU E if N must obligatory invoke the function fi in the scope of CA, F ALSE otherwise. – Forbid(N, fi ): T RU E if it is f orbidden for N to invoke the function fi in the scope of CA, F ALSE otherwise. 4.4

Non Repudiation

A non repudiation constraint represents the situation where we can post-check the validity of coordination activities and prevent a participating service from denying previous behaviours that are related to its input or output data. Let {CA1 ,CA2 ,..,CAn } be the set of coordination activities to be orchestrated. The following non repudiation constrains can be associated to coordination scenarios: – Ordered({CAi }): T RU E if it is possible to proof from the previous evaluations of constraints the real execution order of coordination activities, F ALSE otherwise. – Approval(CAi ): T RU E if from the coordination scenario we can proof who is responsible for approving the exchange of data when a function was invoked within the scope of a given coordination activity, F ALSE otherwise. – Sent(CAi , [invocation, result]): T RU E if from the coordination scenario we can proof who sent an invocation and who sent the corresponding result within the scope of a given coordination activity, F ALSE otherwise. – Original(CAi ): T RU E if both Approval(CAi ) and Sent(CAi ) are T RU E, F ALSE otherwise. – Received(CAi , [invocation, result]): T RU E if from the coordination scenario we can proof that the recipient received an invocation or a result, F ALSE otherwise. – Known(CAi , [invocation, result]): T RU E if from the coordination scenario we can proof that the recipient recognised the content of a received invocation or result, F ALSE otherwise. – Delivered(CAi ): T RU E if both Received(CAi ) and Known(CAi ) proof that the recipient received and recognised the content of an invocation or a result, F ALSE otherwise. – Submitted(CAi ): T RU E if from the coordination scenario we can proof that a delivery authority has accepted the transmission of an invocation, F ALSE otherwise. – Transported(CAi ): T RU E if from the coordination scenario we can proof that a delivery authority has given the invocation or the result of a specific sender to an intended recipient, F ALSE otherwise. 4.5

Safety

These constraints serve to diagnose following unintended behaviours: – a required coordination activity is not performed; – an incorrect or unsafe coordination activity is performed;


401

– a required coordination activity is performed at the wrong time or at the wrong crosslink; – a correct coordination activity is not stopped in prescribed order. We suggest additional constraints for reinforcing the described constraints in order to ensure a correct specification of an application logic. There are intrasafety constraints of coordination activities and inter-safety constraints of coordination activities. These constraints can be used as safeguards to detect and handle unintended behaviours at execution time. Intra-safety constraints diagnose if (i) a required functional constraint is not considered or (ii) a non required functional constraint is considered in the application logic. These constraints serve to compare and post check the execution state of coordination activities. They are verified on L, CT , OT of coordination scenarios. Inter-safety constraints diagnose if a required functional constraint is considered at the wrong time. In this case, they serve to check the validity of a constraint corresponding with a given activity. Also, inter-safety constraints prevent the dependencies that exist between constraints of the same type. They serve to avoid the redundance and the contradiction of constraints imposed to a coordination activity.

5

Execution Policies

As shown in Figure 3, the execution of every coordination activity is done in three steps: preparation, treatment, termination. Constraints are handled as pre-conditions, post-conditions and invariants of the corresponding invocation according to the following rules: – Rule 1. Preconditions must be verified and treated before firing the execution of invoked functions of a participating service. For a given coordination activity, preconditions are specified by firing, authentication and authorisation constraints. For a coordination activity (i.e. the current coordination activity) in relation with another coordination activity (i.e. next coordination activity), preconditions of the next coordination activity are ordering and data dependency constraints (see (1), (2)). – Rule 2. Postconditions must be verified and treated after having the result of an invoked function. For a coordination activity post conditions are specified by non repudiation constraints. For a coordination activity (i.e., the current coordination activity) in relation with another coordination activity (i.e., next coordination activity), the postcondition of current coordination activity is specified by integrity constraints (see (1), (3)). – Rule 3. Invariants are always translated as preconditions and postconditions. They must be verified and treated respectively as part of the treatment of preconditions and post conditions.

402


(1) coordination_activity := treatment | ( preparation ^ treatment ^ termination ); (2) preparation := precondition-checking | ( precondition-checking ^ exception-treatment ) | UNDER_CONSIDERATION | WAIT | READY; (3) treatment := invoked_functionality-execution | ( invoked_functionality-execution ^ faillure-treatment ) | ACTIVE; (4) termination := postcondition-checking | ( postcondition-checking ^ exception-treatment ); (5) precondition-checking := TRUE | FALSE; (6) postcondition-checking := TRUE | FALSE; (7) faillure-treatment := STOP | ( STOP ^ exception-treatment )| CONTINUE | COMPENSABLE; (8) exception-treatment := ABORT | COMMIT | COMPENSATION; Fig. 3. Handling rules of a coordination activity

– Rule 4. During the condition treatment process, the intra-safety and intersafety constraints must be ensured. – Rule 5. If the result of an invoked function notifies and failure, failure treatment must be executed as part of the treatment of post conditions (see (7), (8)). – Rule 6. The validity of a constraint is either T RU E or F ALSE (see (5), (6)). – Rule 7. Constraints evaluation to FALSE is captured as the occurrence of an exception (see (8)). – Rule 8. The matching of coordination and security strategies to the execution of the coordinated system are validated by post-checking the information extracted from coordination scenarios. Figure 4 illustrates the state automation of a coordination activity during execution. To glue together a set of coordination activities {CA1 , CA2 , .., CAn }, we predefine their associated constraints as constructors. The following constructors have been identified: sequence, selection (OR-split, OR-joint), iteration, synchronisation (AND-split, AND-joint) and free (unordering). – sequence(CA1 ,CA2 ) expresses a sequential order among coordination activities, i.e. the fact that the execution of one coordination activity (CA2 ) is carried out after another (CA1 ). – OR-split(CA1 ,{CA2 ,..,CAn }), or sequence(CA1 ,CA2 ) ∨ .. ∨ sequence(CA1 ,CAn ), is used to select one coordination activity from a set of coordination activities CA2 ,.., CAn . CA1 and only one of them ensure a sequential order. – OR-joint({CA1 ,..,CAn−1 },CAn ), or sequence(CA1 ,CAn ) ∨ .. ∨ sequence (CAn−1 ,CAn ), is used to select one coordination activity from a set of coordination activities CA1 ,.., CAn−1 . Only one of them and CAn ensure a sequential order.


403

Fig. 4. State automation of coordination activity

– AND-split(CA1 ,{CA2 ,..,CAn }), or sequence(CA1 ,CA2 ) ∧ .. ∧ sequence(CA1 ,CAn ), expresses the fact that two or more coordination activities are executed at the same time, after the execution of another. This is an effect of synchronisation among coordination activities {CA2 ,..,CAn }. CA1 and all of them ensure a sequential order. – AND-joint({CA1 ,..,CAn−1 },CAn ), or sequence(CA1 ,CAn ) ∧ .. ∧ sequence (CAn−1 ,CAn ), expresses the fact that two or more coordination activities CA1 ,.., CAn−1 are executed at the same time. All of them and CAn ensure n-1 sequential orderings. – iteration(CA1 ) expresses the fact that the execution of a coordination activity CA1 is repeated. – unordering(CA1 , .., CAn ) expresses the fact that no coordination constraints described above are met. In other words, there is no dependency among coordination activities. Such activities can be executed at the same time or according to any order. For example, consider the three coordination activities implementing the look up function. The flight booking application first interacts with Adventurer service to get information about a client and her/his needs by invoking the method get Requirements (CA1 ). This information is used by the method seek Flights of the Seeking service for looking for available flights (CA2 ). This service returns a list of possible flights that are displayed by the method display Results of the Adventurer service (CA3 ). A sequential constructor is expressed as a set of pre and post conditions of these coordination activities. The following constraints specify coordination and security aspects associated to CA2 as pre conditions: – Obligate(S1 = COMMIT): once the execution status of CA1 (i.e., S1 ) is succesful, the method seek Flights of the Seeking service can be invoked.

404


– Match(O1 ): information about customer’s needs (i.e., (O1 )) produced by the method get Requirements of the Adventurer service is used as input data of the method seek Flights provided by the Seeking service. – After(CA1 ): the end of the execution of the method get Requirements must precede the beginning of the execution of the method seek Flights. – Approuved(searchFlights): the identity of the service providing the invoked method (seek Flights) must belong to the list of valid names of the coordinated system. Similarly, the following post conditions of CA2 must hold: – Permit(S3 = READY): CA3 can fire the invocation to a method of the Adventurer service. This constraint plays also the role of an authorisation constraint for CA3 . – Invariant(O2 ): the flight search result cannot be altered until it is delivered to the Adventurer service. – Received(searchFlights, invocation) ∧ Sent(searchFlights, result): it ensures that the invocation and the transmission of results are done within the same execution scope. In the example, the invocation of the method seek Flights is received and its results are sent within the scope of the coordination activity CA2 . This constraint is used for avoiding non-repudiation.

6

Related Work

Coordination is described and managed as constraints on interactions among services. From this point of view, we consider existing related works according to the service interaction mechanisms they support. The first category of mechanisms is based on sharing data space, naturally a common accessible data structure for all of participating services. Their communication is realized by the way they control or process common data values in sharing space. In this category, the target coordinated system configuration is supported by suitable coordination languages at run-time, i.e. the Linda family [16,17] and other varieties. [19] combines the Linda language with certain standards of W3C (XML, XSL) to build a workflow system management on the Internet. Polished [4] is a coordination language, which provides basic descriptions and automatic analysis for mobile agent system architectures. The security solution is to build a secured sharing space [7,13] corresponding with a given coordination model in a concrete context. The second category is based on data passing among participating services. A participating service is then considered as a black box process that produces or consumes data via well defined interfaces, called ports. These boxes communicate directly in several ways: establishing connections among participating services ports for exchanging data, diffusing control events or messages among processes. The coordinated system is configured at runtime with the support of integration tools or integration environments according to specified software architecture.


405

This category of mechanisms can be used to manage complex distributed systems [12], especially multi-agent systems [3]. ToolBUS [15] and coordination orchestration [13] are used to facilitate and to control potential interactions between system components. A coordination protocol for distributed applications (e.g. Web services) is specified in [11]. A coordination tool based on local data space of participating Web services is also studied in [1]. Nevertheless, at the abstraction level of coordination, these works do not consider the security by the way coordination is abstracted and specified. Security and coordination are differently modelled. If we wish to consider security requirements using the concepts and terminologies of a coordination model, there is no way to explicitly determine the relation between such a coordination model and a specific security model. Security management relies upon the architecture components that implement coordinated systems. At the execution level, existing security solutions are strictly proposed as tools for securing the execution of specific components that carry out the coordination. With regard to the first category of coordination, the execution architecture of coordination is the sharing space. So, the main security solution is to build a secured sharing space [7,13] corresponding with a given coordination model deployed in a concrete environment. Following this idea, security techniques for controlling access (authorization, control privilege, etc.) and for identifying participating services are focused. With regard to the second category, the execution architecture of coordination is a tool that supports interconnection and communication among participating services. Security measures are then applied to these tools. Efforts like WS-Policy and WS-Secure-Conversation combined with WS-Security and WS-Trust are going in this direction. [7] presents an approach for building a secure mobile agent environment. Moreover, some methodologies used to evaluate the security quality of participating services are quoted. [2] presents a specification to secure exchanged messages among Web services by using SOAP protocols. In [14], a component characterization diagram for component-based system is proposed. Based on this diagram, a formal security model to identify and quantify security properties of component functionalities is also presented. The purpose is to protect user data by evaluating and certifying the components and their composition (if they are re-used by another). Security solutions that are defined at the abstraction level can be mapped and reused as security solutions at the execution level. For example, at the abstraction level, we use constraints to define an authentication strategy of coordination activities. At the execution level, this strategy is mapped and implemented as one component that performs the coordination. It can be reused to define an authentication strategy of participating services. In this case, it is implemented as a tool for securing the execution of components that perform the coordination.

7

Conclusion

This paper presented M EO - a secure coordination model that enables the specification of secure service-based coordinated systems. Both functional and non

406


functional requirements of such coordinated systems are specified by constraints for coordination activities and that refer to coordination scenarios. The originality of our solution is that security requirements are considered at both abstraction and execution level. In the M EO model, security solutions (e.g., authentication strategy) are constructed in the same way in which coordination solutions (e.g., application logic) are constructed. For this reason, the first essential point making our proposition different from other current solutions is that we can consider the functional safety requirements early on the coordination abstraction level, while other solutions can only consider it at the execution level. Our M EO model takes some advantages for defining a secure coordinated system. First, M EO enables the definition of security strategies without redundancy by distinguishing different levels of coordination and security. Moreover, these strategies can be independently applied to different objectives at both abstraction and execution level. Second, with M EO coordination and security requirements of the coordinated system are specified in the same way, so there is no need to consider the relation of terminologies and concepts amongst different coordination and security models. Further research focuses on the construction of a secure coordination framework. It will support the building elements for coordinating services. Executing a coordination in a secure way means defining tools that control and validate the constraints specified at abstraction level. That means also supporting tools for ensuring other security objectives at execution level: exchanged message integrity, service authentication and non repudiation of coordination activities. It implies also the capability to enable the coordinated system to automatically adapt the coordination and security strategies.

References 1. P. Alvarez, J. A. Banares, P. R. Muro-Medrano, J. Nogueras, and F. J. Zarazaga. A java coordination tool for web-service architectures: The location-based service context. In FIDJI ’01: Revised Papers from the International Workshop on Scientific Engineering for Distributed Java Applications, pages 1–14, London, UK, 2003. Springer-Verlag. 2. Khalid Belhajjame, Genoveva Vargas-Solar, and Christine Collet. Defining and coordinating open-services using workflows. In Proceedings of the Eleventh International Conference on Cooperative Information Systems (COOPiS03), number 2519, Catania Sicily-Italy, Novembre 2003. Lecture Notes in Computer Science. 3. Ciaran Bryce, Manuel Oriol, and Jan Vitek. A coordination model agents based on secure spaces. In COORDINATION ’99: Proceedings of the Third International Conference on Coordination Languages and Models, pages 4–20, London, UK, 1999. Springer-Verlag. 4. P. Ciancarini, F. Franze, and C. Mascolo. Using a coordination language to specify and analyze systems containing mobile components. ACM Trans. Softw. Eng. Methodol., 9(2):167–198, 2000. 5. Workflow Management Coalition. Workflow management coalition: Terminology and glossary, 1996.


407

6. Microsoft Corporation. http://msdn.microsoft.com/webservices /building /interop/, 2003. 7. Marco Cremonini, Andrea Omicini, and Franco Zambonelli. Coordination in context: Authentication, authorisation and topology in mobile agent applications. In COORDINATION ’99: Proceedings of the Third International Conference on Coordination Languages and Models, page 416, London, UK, 1999. Springer-Verlag. 8. Dimitrios Georgakopoulos, Mark F. Hornick, and Amit P. Sheth. An overview of workflow management: From process modeling to workflow automation infrastructure. Distributed and Parallel Databases, 3(2):119–153, 1995. 9. Object Management Group. http://www.corba.org/, 2002. 10. IBM. http://www-306.ibm.com/software/htp/cics/, 1999. 11. IBM, Microsoft, and BEA. Web services coordination. Technical report, 2003. 12. Paola Inverardi and Henry Muccini. Coordination models and software architectures in a unified software development process. In COORDINATION ’00: Proceedings of the 4th International Conference on Coordination Languages and Models, pages 323–328, London, UK, 2000. Springer-Verlag. 13. Valerie Issarny, Christophe Bidan, and Titos Saridakis. Characterizing coordination architectures according to their non-functional execution properties. In HICSS ’98: Proceedings of the Thirty-First Annual Hawaii International Conference on System Sciences-Volume 7, page 275, Washington, DC, USA, 1998. IEEE Computer Society. 14. K. Khan, J. Han, and Y. Zheng. Characterising user data protection of software components. In Proceedings of the 2000 Australian Software Engineering Conference, page 255, WCanberra, Australia, 2000. IEEE Computer Society. 15. Paul Klint and P. Olivier. The TOOLBUS coordination architecture - a demonstration. In Algebraic Methodology and Software Technology, pages 575–578, 1996. 16. Thomas W. Malone and Kevin Crowston. What is coordination theory and how can it help design cooperative work systems? In CSCW ’90: Proceedings of the 1990 ACM conference on Computer-supported cooperative work, pages 357–370, New York, NY, USA, 1990. ACM Press. 17. George A. Papadopoulos and Farhad Arbab. Coordination models and languages. Technical report, Amsterdam, The Netherlands, The Netherlands, 1998. 18. James Lyle Peterson. Petri Net Theory and the Modeling of Systems. Prentice Hall PTR, Upper Saddle River, NJ, USA, 1981. 19. Robert Tolksdorf. Coordination technology for workflows on the web: Workspaces. In COORDINATION ’00: Proceedings of the 4th International Conference on Coordination Languages and Models, pages 36–50, London, UK, 2000. Springer-Verlag.