Semantic Weaving for Context-aware Web Service ... - Semantic Scholar

Semantic Weaving for Context-aware Web Service Composition Li Li, Dongxi Liu, and Athman Bouguettaya CSIRO ICT Centre, Australia {lily.li, dongxi.liu, athman.bouguettaya}@csiro.au

Abstract. An Aspect-oriented Programming (AOP) based approach is proposed to perform context-aware service composition on the fly. It realises context-aware composition by semantically weaving context into static Web service composition. A context weaver is implemented based on the proposed approach. The proposed semantic weaving allows services to be composed in a systematic way with changing context.

1

Introduction

In recent years, Web service composition has attracted increasing attention in the research community. However, it is far from trivial [1, 2]. In addition to functional and nonfunctional requirements, a fully workable context-aware service composition requires the context to be taken into account. Context is any information (e.g., location and time information), which can be used to characterise the situation to which the Web service is being applied. Information such as location and time may change over time. Context is recognised as important and has been widely studied in the field of Mobile and Pervasive Computing [3, 4]. It needs to be explicitly described and managed in Web service composition so that different participating Web services can be connected correctly. Several papers [4–6] have identified different context dimensions for different types of Web services, and various attempts have been made to cope with the utilisation of the context. However, they provide little guideline on how to use dynamically changing context in service composition. Achieving context-aware service composition is challenging [7]. Some methods include hard-coding context and the use of Aspect-oriented programming. Hard-coding context approaches assume that context remains unchanged throughout the service life cycle. In fact, the context of a Web service changes as the state of a predefined environment evolves. Take the popular travel package for example. Assuming a user sends a request to the composer to book a travel package to the Gold Coast in Australia. The user also requires tickets to the Gold Coast Theme Parks (e.g., the Dreamworld, Movie World, and Sea World). This example involves Web services that manage booking the flight, hotel, car rental and ticket (e.g., flightBooking, hotelBooking, carRental, and ticketBooking). Consider now the user is based in a non-English speaking country. The challenge is to take this contextual information into service composition efficiently without reconstructing the entire composition from scratch.

Aspect-oriented programming (AOP) [8] is an effective module mechanism used in software engineering for separating crosscutting concerns from primary concerns. For example, logging the execution results of some Java methods for debugging is a crosscutting concern since the logging operation may need to appear in multiple classes and methods. In AOP, the logging operation is encapsulated by an aspect as a separate module, so the logging operation can be easily removed after debugging is over. This feature of AOP is very desirable for context-aware service composition. The context services as crosscutting concerns can be represented by aspects to be woven into the primary services determined by the business logic. We can thus separate context services from main services clearly and context services can be updated independently into new contexts without changing the main services. AOP is well suited to context-aware service composition because it provides support for runtime contexts updating. Charfi et al. [9] present an aspect-oriented extension to BPEL (AO4BEPL) to deal with crosscuts in Web service composition. Our work shares similarities with AO4BPEL. Both approaches use AOP technology. However, the discussion in this paper is aimed at introducing semantic weaving instead of syntactic weaving as used in AO4BPEL. We treat context as an aspect. Thus the context can be semantically woven into composition at runtime. There are several properties commonly regarded as context attributes, but there exists no universal context model that applies to all applications [10]. In this paper, the term context relates to the collection of assumptions that are required to perform correct composition of Web services. Several issues pointed out by Satyanarayanan in Pervasive Computing [3] are applicable to Web services. Typical issues include how context is structured, activated and woven into Web service composition, and how context-aware service composition is achieved. They are the driving force of this paper. Unlike most of the current work, this paper takes a different view that focuses on AOP-based context-aware service composition. Our main contributions in this paper are summarised as follows: – We propose to use AOP technology to cope with context-aware Web service composition. We show that AOP can treat context composition in a more systematic way. – We propose a method of describing context as an aspect to reflect the nature of context. The proposed method is generic to be able to cope with different contexts of Web services. – We define context configuration based on semantic weaving and implement the context weaver. The novelty of our semantic weaving algorithm is that it enables quick and dynamic adaptation by the composer in a systematic way. The proposed approach can work independently or together with existing composition strategies. The rest of the paper is organised as follows. Section 2 presents how to use aspect to describe context. Section 3 discusses semantic context weaving algorithm in service composition. Section 4 provides an overview of related work. Finally, Section 5 is the conclusion.

2

Context as Aspect

Current Web service composition techniques can hardly cope with dynamic changes. Usually, whenever a new context is available, most current composition techniques have to reconsider the whole composition. This is because they are essentially static. Aspect-oriented programming (AOP) [8] is a programming paradigm that allows the composition system to adopt new characteristics as contexts change. In what follows we first briefly introduce AOP. We then discuss how the context is structured to allow context-aware composition with the AOP technology. 2.1

Aspect-oriented Programming

We expect relevant context services to be invoked automatically whenever a change takes place. Usually, a context service may be applied to a class of service composition scenarios in differen parts. For example, language translation context may be needed by services hotelBooking and ticketBooking separately. This is also referred to as crosscutting concern in AOP terminology. Below is a brief introduction to AOP terminology with a focus on Web service composition scenarios [8, 11]. – join points: Join points are well-defined points in the execution of a program. These are points in an automaton, used to depict a Web service. – pointcut: A pointcut is a way of detecting a join point by a means of configuration. A dedicated context service will be applied whenever a pointcut is reached. The pointcut can be checked in different ways. Type checking is a popular one. Essentially, type checking considers syntactics such as the type of parameters and matching patterns in the names. With the presence of context, semantic checking is necessary to complement type checking. More detail is given in Section 3. – advice: An advice is a context service which deals with context. It can be executed before, after, or around the joint point at hand. Figure 1 demonstrates three advices in the travel example. The original composition schema is on the left hand side (Figure 1) with an advice “cut” at hotelBooking. On the right hand side (Figure 1) are three schemata in accordance with three different actions. – aspect: An aspect is the combination of the pointcut and advice. In the travel example, we add a context service to service composition as recommended by pointcut.

2.2

Context Structure

As previously stated, AOP allows the changing context to be handled by weaving it into the main services for a new requirement. The context structure is

Context service hotelBooking flightBooking

ticketBooking carRental

(a) before context hotelBooking flightBooking

hotelBooking ticketBooking

carRental

ticketBooking carRental

(b) after context

pointcut Context service

Context service

flightBooking

Context service flightBooking

ticketBooking

context carRental

(c) around context

Fig. 1. Before, after, and around advice

important to realise it. The following are two considerations in defining context structure for context weaving in AOP. The first one is about the syntax of context structure. The following definitions are in BNF with “::=” standing for “is defined as”, and “|” for “or”. ctx ::= pos des serv pos::= before |after |around des::= isMsg (C ) |C op val |des∧des |des∨des C ::= concept of an ontology val := numbers|alphanumeric strings op ::= < |= |> serv ::= automaton We use a dotted style notation to address context structure in semantic weaving. The representation ctx.pos is used to refer to one of the positions (e.g., before, after, and around ). Similarly, ctx.serv stands for an automaton, whilst ctx.des for a descriptor. The second one is about the semantic definition of context. We describe context as a concept of an ontology. Generally, an ontology [12] can be described as a tuple in a form (C, Rel, Axiom) with C denoting Concepts, Rel is an n-ary predicate Rel(x1 , x2 , ..., xn ), where x1 , x2 , ..., xn ∈ Concepts, and Axiom is a set of axioms specifying the intended interpretation of concepts in some domains. As our focus is on context-aware composition, only standard semantic relations (i.e., equivalent and containment semantic relations) will be considered in this paper. A consideration of other semantic relations will be deferred to a later study. The ontology formalism definition is as follows: (C, Rel, ∅), or simply (C, Rel) when Rel ∈ {=, @, A}. For example, if C = {C1 , C2 , C3 } with C1 is the superclass of C2 and C3 , then the ontology would be: ({C1 , C2 , C3 }, {C2 A C1 , C3 A C1 , C1 = C2 u C3 }). Uppercase characters such as C1 , C2 , and C3 are used to represent contexts in the following discussion.

3

Context Weaving for Composition

In this section, we explain context weaving that is implemented as a context weaver.With context weaving, a service is instrumented with the context services to generate a new service that is thus context-aware. The syntactic weaving method adopted by aspect-oriented programming [11, 8] is not suitable for context weaving. Our approach implements weaving based on the semantics of join points (i.e., service messages in this work). Our semantic weaving method is expected to contribute to AOP in the future. 3.1

Automata-based Service Model

For our context weaving purpose, services are modeled by automata. An automaton is a tuple (Q, s, F, δ), where Q is a set of states, s ∈ Q the start state, F ⊆ Q a set of final states, and δ contains the transition rules. A transition rule has the forms either (q, c, ?m, q 0 ) or (q, c, !m, q 0 ), meaning that the state can change from q to q 0 after reading or transmitting message m if the condition c holds (lowercase letter c standing for the condition). In the future, transitions concerning messages are represented by prefixing the message with ? (reading/receiving) or ! (transmitting/sending), respectively. A message has the structure mn(v1 : ty1 , ..., vn : tyn ), where mn is the message name, vi a message variable and ty i its type. We assume that all variables are different in a message. The types can be described in XML Schema. The details of types are not required here. There is a special message called null, which means there is no message to receive or send for an (internal) transition of service automata. A condition c in transition rules is defined on message variables. For example, if there is a message ?getPrice(p : double) before the message !order(), then we define the condition p < 10 to guard the second message so as to determine whether an order message should be sent or not. For a service automaton S, we use S.Q to represent its states set, and similarly S.s for the start state, S.F final states, and S.δ transition rules. For service automata with context services, we require that the automata have only one final state. A service automaton for the example in Section 1 is depicted in Figure 2. For brevity, all transition conditions are true. The state set Q is {q1 , q2 , q3 , q4 , qf }, in which q1 is the start state, and qf is the final state. There are six transition rules in total. For example, the state transition from q1 to q2 when receiving the message flightRes, which contains the user’s name Name, the departure airport Airport1 , the departure data Date1 , the destination airport Airport2 and the return date Date2 . 3.2

Context Configuration

Messages defined in the service model are syntactic. Syntactic messages do not explicitly express what context these messages involve. Different services may use different message names, variables and types even if they are related to the same contexts. For example, the message b(n : string, p : double) does not tell

?flightRes(Name : String, Airport1 : String,Date1 : String, Airport2 : String, Date2 : String)

q2

q1

!flightResOk(Name : String, Airport1 : String, Date1 : String, Time1 : String, Airport2 : String, Date2 : String, Time2 : String, FlightNo : String, Class : String)

!flightResFail(Name : String, Airport1 : String, Date1 : String, Airport2 : String, Date2 : String)

q3

?hotelResFail(Name : String, Date1 : String, Date2 : String)

qf

?hotelRes(Name : String, Date1 : String, Date2 : String) q4

?hotelResOk(Name : String, Date1 : String, Date2 : String, HName : String, HAddres : String)

Fig. 2. Services in an automaton

anything about the context applicable to this message. As done in semantic web services [13–15], we address this problem by configuring messages with semantic context information. A context configuration is a mapping from messages to its relevant context. Given a message mn(v1 : ty1 , ..., vn : tyn ), its context is described by a configuration in the following form: mn(v1 : ty1 , ..., vn : tyn ) 7→ (C0 , {(v1 , C1 ), ..., (vn , Cn )}) It means that the message mn is supposed to be run in the context C0 with each message vi related to the context Ci . In this context description, the context C0 is the major context for the whole message, and the contexts Ci are specific ones for each message variable. Specific contexts can be interpreted more accurately when combined with their major contexts. For example, a time context may be concerned when combined with the major context for flight reservation, while not when combined with the major context for ordering books. Specific contexts have values at run time, which are the values of the corresponding message variables. For example, if a variable vi is associated with the context Location and it has the value Australia at runtime, then this Location context also has the value Australia. For a message, its configured contexts on variables are required to be not overlapped. That is, if a variable vi is configured with a context Ci , then any other variable vj must not be configured with a context Cj where Ci = Cj , Ci @ Cj or Cj @ Ci . Otherwise, we cannot determine the value of context Ci since its value is not unique in one message. We do not annotate services with context information directly. Thus, a service can be deployed to other contexts by using different context configurations. And we also can configure only those messages concerned in a specific context. 3.3

Semantic Weaving

To implement context weaving, we need to define the join points in the service model, which are the possible points where context services can be brought in. As

next(q, ∅) next(q, {(q1 , c, ?m, q2 )} ∪ δ) next(q, {(q1 , c, !m, q2 )} ∪ δ) next(q, {(q1 , c, ?m, q2 )} ∪ δ) next(q, {(q1 , c, !m, q2 )} ∪ δ)

= = = = =

∅ {(m, q2 )} ∪ next(q, δ), if q = q1 {(m, q2 )} ∪ next(q, δ), if q = q1 next(q, δ), if q 6= q1 next(q, δ), if q 6= q1

Fig. 3. The next Operator

the method calls in AspectJ [11], service invocations in BPEL has been chosen as the main joint points in AO4BPEL [9]. In our service model, service invocations are embodied by message transmission !m or message reception ?m. Thus, we use messages as the join points in our work. With the context configuration, context services can thus be woven into main services based on the semantics of service messages. For the example in Figure 2, there are six messages and for each message we will determine whether there is possibility to invoke context services either before, after or around this message. select(smsg, ∅) =∅ select(smsg, {ctx } ∪ Ctx ) = {(ctx, cond)} ∪ select(smsg, if smsg ` ctx .des ⇒ cond ) select(smsg, {ctx } ∪ Ctx ) = select(smsg, Ctx ), if smsg 6` ctx .des Fig. 4. The select Operator

3.3.1 Two Operators: next and select The operators next and select are two auxiliary operators used by the semantic weaving algorithm in the next section. The operator next is defined in Figure 3. This operator takes as inputs a state q and a set δ of transition rules in a service automaton, and returns a set of pairs (m, q 0 ) with either (q, c, ?m, q 0 ) ∈ δ or (q, c, !m, q 0 ) ∈ δ for a certain condition c. By using this operator, we can know what the join-point messages and successor states are at the state q. For example, given the state q2 and the transition relation δ in Figure 3, the operation next(q, δ) returns the following set. {(!flightResFail(Name:String, ...),q3 ), (!flightResOk(Name:String, ...), qf ) } The operator select is defined in Figure 4. Given a message configuration smsg, defined as (C0 , {(v1 , C1 ), ..., (vn , Cn )}), and a set of contexts Ctx, the operation select(smsg, Ctx ) returns a set of pairs (ctx, cond), which means that if the condition cond holds, then the context service described in ctx can be applied. This operator depends on the validity check of a context descriptor against the configuration of a message. The validity check is defined in Figure 5. A descriptor isMsg(C) holds on a message if the major context of this message is subsumed under C. This descriptor can be checked statically, so the condition to

guard this context is trivially true. For the descriptor C op val , if there is a context Ci (1 ≤ i ≤ n) in the message configuration (C0 , {(v1 , C1 ), ..., (vn , Cn )}), then this descriptor is valid together the condition vi op val , which will be checked at runtime, where op ∈ {}. Recall that vi is the value of Ci at runtime. The descriptors des ∧ des 0 and des ∨ des 0 are checked based on the validity of their sub-descriptors des and des 0 . let smsg = (C0 , {(v1 , C1 ), ..., (vn , Cn )}) R1 : smsg ` isMsg(C) ⇒ true, if C0 @ C R2 : smsg ` C op val ⇒ vi op val , if ∃i : 1 ≤ i ≤ n.Ci op C, where op ∈ {} R3 : smsg ` des ∧ des 0 ⇒ cond ∧ cond 0 , if smsg ` des ⇒ cond and smsg ` des 0 ⇒ cond 0 R4 : smsg ` des ∨ des 0 ⇒ cond ∨ cond 0 , if smsg ` des ⇒ cond or smsg ` des 0 ⇒ cond 0 Fig. 5. The Validity of context descriptors

3.3.2 Semantic Weaving Algorithm The semantic weaving algorithm is defined in Figure 6. The inputs of this algorithm include a service automaton S, a set of contexts Ctx and a context configuration Conf . The algorithm returns a new service automaton S 0 that is obtained by weaving applicable contexts from Ctx into the input service automaton S. This algorithm consists of two parts. The first part includes the code from line (08) to line (26). This part generates for each transition rule a set of pairs of context and applicable condition. Concretely, a tuple of the form (q, m, q 0 , pCtx ) is generated from the transition rule (q, c, !m, q 0 ) or (q, c, ?m, q 0 ), where pCtx is a set of pairs of context and applicable condition computed by using select. The code in this part traverses the automaton states following the transitions rules, and after a state is processed, it is recorded in O and it will not be processed again even if there are transition loops. Hence, the first part must terminate after processing all reachable states. The code from line (27) to line (48) is the second part of the weaving algorithm. This part will insert context services into the service automaton. For a tuple (q, m, q 0 , pCtx ), there must be a transition either (q, c, !m, q 0 ) or (q, c, ?m, q 0 ) in the service automaton according to the first part algorithm. After weaving, the transition (q, c, !m, q 0 ) or (q, c, ?m, q 0 ) is removed at line (47) and new transitions are created by calling the function createtran and the code at lines (35), (39) and (46). The function createtran is shown in Figure 7. The new transitions connect the context service automata with the original service automaton. Below, we demonstrate the newly generated transitions following the algorithm shown in Figure 6. Example 1: suppose pCtx includes two applicable contexts (ctx 1 , cond 1 ) and (ctx 2 , cond 2 ) for (q, c, !m, q 0 ). The ctx 1 and ctx 2 has the following forms (see Section 2.2 for detail):

(01) (02) (03) (04) (05) (06) (07) (08) (09) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) (20) (21) (22) (23) (24) (25) (26) (27) (28) (29) (30) (31) (32) (33) (34) (35) (36) (37) (38) (39) (40) (41) (42) (43) (44) (45) (46) (47) (48) (49) (50)

Input: S : a service automaton Ctx : a set of contexts Conf : a context configuration Output: S 0 : a service automaton that is context-aware Code: W = {S.s}; //the set of states to be processed O = ∅; //the set of processed states cserv = ∅; while(W is not empty) assume q ∈ W and W 0 = W \ {q}; O = O ∪ {q}; N = next(q,S.δ); for each (m, q 0 ) ∈ N do smsg = Conf(m); //get the semantic of of m pCtx = select(smsg, Ctx ); //select applicable contexts for m from Ctx cserv = cserv ∪ {(q, m, q 0 , pCtx )}; //applicable contexts recorded in cserv if q 0 6∈ O then //q 0 not processed yet W 0 = W 0 ∪ {q 0 }; endif endfor W = W 0; endwhile for each (q, m, q 0 , pCtx ) ∈ cserv do //weave for each rule that has applicable contexts (q 00 , S 00 ) = createtran(q, pCtx , S, before); (q 000 , S 000 ) = createtran(q 00 , pCtx , S 00 , around); if q 000 = q 00 then // no around contexts let q1 be a fresh state; S 00 .Q = S 00 .Q ∪ {q1 }; if (q, c, !m, q 0 ) ∈ S 00 .δ then S 00 .δ = S 00 .δ ∪ {(q 00 , c, !m, q1 )}; q 000 = q1 ; S 000 = S 00 ; else S 00 .δ = S 00 .δ ∪ {(q 00 , c, ?m, q1 )}; q 000 = q1 ; S 000 = S 00 ; endif endif (q 00 , S 00 ) = createtran(q 000 , pCtx , S 000 , after); S = S 00 ; S.δ = S.δ ∪ {q 00 , true, null, q 0 }; S.δ = S.δ \ {(q, c, !m, q 0 ), (q, c, ?m, q 0 )}; endfor S 0 = S; return S 0 ; Fig. 6. Semantic weaving algorithm

(01) (02) (03) (04) (05) (06) (07) (08) (09) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) (20) (21) (22) (23) (24)

Input: q: an entry state for creating transitions pCtx : a set of contexts S : a service automaton pos: the concerned position of contexts Output: q 0 : an exit state after creating transitions S 0 : a set of states Code: q 0 = q; S 0 = S; for each (ctx , cond ) ∈ pCtx do if ctx .pos = pos then let q1 be a fresh state; S 0 .Q = S 0 .Q ∪ ctx .serv .Q ∪ {q1 }; let ctx .serv .F = {q 00 }; S 0 .δ = S 0 .δ ∪ ctx .serv .δ; S 0 .δ = S 0 .δ ∪ {(q 0 , cond , null, ctx .serv .s)}; S 0 .δ = S 0 δ ∪ {(q 0 , ¬cond , null, q1 )}; S 0 .δ = S 0 .δ ∪ {(q 00 , true, null, q1 )}; q 0 = q1 ; endif endfor return (q 0 , S 0 ); Fig. 7. The createtran algorithm

ctx 1 = before des 1 serv 1 , where serv 1 = (Q1 , s1 , {q1 }, δ1 ) ctx 2 = after des 2 serv 2 , where serv 2 = (Q2 , s2 , {q2 }, δ2 ) After weaving, the new transitions include those in δ1 and δ2 , and also the following connecting transitions: (q, cond 1 , null, s1 ), (q, ¬cond 1 , null, q 00 ), (q1 , true, null, q 00 ), (q 00 , c, !m, q 000 ), (q 000 , cond 2 , null, s2 ), (q 000 , ¬cond 2 , null, q 0000 ), (q2 , true, null, q 0000 ), (q 0000 , true, null, q 0 ), where q 00 , q 000 and q 0000 are all new states. Example 2: consider pCtx including one more applicable context service (ctx 3 , cond 3 ), which has the form: ctx 3 = around des 3 serv 3 , where serv 3 = (Q3 , s3 , {q3 }, δ3 ) For this example, the new transitions also include those in δ1 , δ2 and δ2 , and the connecting transitions become: (q, cond 1 , null, s1 ), (q, ¬cond 1 , null, q 00 ), (q1 , true, null, q 00 ), (q 00 , cond 3 , null, s3 ), (q 00 , ¬cond 3 , null, q 000 ), (q3 , true, null, q 000 ), (q 000 , cond 2 , null, s2 ), (q 000 , ¬cond 2 , null, q 0000 ), (q2 , true, null, q 0000 ), (q 0000 , true, null, q 0 ), where q 00 , q 000 and q 0000 are all fresh states.

For demonstration purpose, the above examples include only one context service at the positions before, around and after, respectively. Our algorithm allows any number of context services at any positions. Moreover, there is no limit to the number of final states. Our algorithm can be applied easily in both situations.

4

Related Work

A significant amount of research has been done in the areas of Web services composition [16–19]. A good survey on context-aware frameworks and middleware can be found in [20]. Various attempts have been made to cope with Web service contexts since then. The following is an overview of some recent work in two categories. 4.1

Semantic Context Model

Medjahed et al. [21] introduced a generic definition of Web service context through an ontology-based categorisation of contextual information. The rulebased service matchmaking was proposed to consider the relevant context. Similarly, we construct an ontology (context ontology) to facilitate the detection of join point semantically. However, we are more concerned about the support of changing context as we treat the context as aspect in AOP. In our view, their work is more on context categorisation. Gu et al. [22] proposed a Service-Oriented Context-Aware Middleware (SOCAM) architecture for the building and rapid prototyping of context-aware services, but with focus on infrastructure support to context-aware systems. We are interested in providing a systematical approach to cope with context-aware composition on the fly. Mrissa et al. [23] proposed a context-based approach for semantic Web services composition. The approach enables developers to annotate WSDL descriptions to describe contextual details; to deploy a context-based mediation architecture to allow explicit assumptions on data flow; to automatically generate and invoke Web service mediator to handle data heterogeneities during Web service composition. The context ontology was defined to make context explicit for each concept of a domain ontology. Unlike ours, the approach presented in [23] restricts to data interpretation in Web service composition. It has little support to other heterogeneities such as heterogeneities at the process-level. As such, the proposed approach works at instance level, and are thus not very suitable for coping with some context changes which required substitutions taking place at not only the nonfunctional-level but also the functional-level. Maamar et al. [24] proposed an approach for context-oriented Web service composition by using agents. The context model presented in [7, 24] comprises four types of context: W -context deals with Web services’ definitions and capabilities; C-context addresses how Web services are discovered and combined; S-context handles the semantic heterogeneity that arise between Web services;

and R-context focuses on the performance of Web services. After identified these different types of context in Web service composition, the authors presented a policy-based approach for developing context-oriented Web services. Three types of policies were introduced to support transitions between the four context levels. They are engagement, mediation and deployment. While the proposed context model is advantageous in terms of context categorisation, it is less generic than the one defined in [21].

4.2

AOP in Web Service and Web Service Composition

The aspect-oriented programming (AOP) paradigm [8] has been mostly applied to object-oriented programming to date. AOP introduces a new concept called aspect aiming at concerns in complex systems by using join points, crosscuts, and advices. Dynamic AOP [25, 26] is widely recognised as a powerful technique for dynamic programming adaptation. Using AOP to increase the flexibility of workflows are discussed in [27, 28]. Baumeister et al. [29] examined the use of aspectoriented modelling techniques in the design of adaptive Web applications to achieve systematic separation of general system functionality and context adaptation. Perhaps Courbis and Finkelstein [30] are the first few authors who used dynamic AOP to adapt Web service composition. However, their work did not address the issues of crosscutting concerns, and of course, no semantic context weaving mechanism is discussed. Few work discussed the applications of AOP in Web service or Web service composition. WSML [31] realises dynamic service selection and integration of Web services through WSML, with a management layer placed in between the application and the Web services. The main motivation of WSML is to provide management support to achieve high modularity, whereas our main motivation is to deal with context by semantic context weaver to achieve context-aware Web service composition. Ortiz et al. [32] use AspectJ [11] to modularise and add nonfunctional properties to Java Web services. Unfortunately, this approach provides very limited support to Web service composition as it mainly works for Java. The AOP for process-oriented Web service composition (AO4BPEL) is presented by Charfi et al. [9] to address the issue of crosscutting concerns in Web service composition and how to modularise them using aspects. It is an aspectoriented extension to BPEL to support dynamic adaptation of composition at runtime. However, its syntactic weaving method did not suitable for contexts weaving. It lacks the semantic weaving mechanism as discussed in our paper. Moreover, the focus of AO4BPEL aims at using AOP to improve the modularity and increases the flexibility of Web service composition, whereas the main focus of our work is supporting automatic service composition with a systematic approach. In saying so, we study how to efficiently generate a new automaton given an automaton and the context.

5

Conclusion

We proposed the use of Aspect-oriented programming to cope with context-aware Web service composition. Technically, we discussed how to detect the context and how to semantically weave it into composition. The focus of our work is on composing Web services with context on the fly. The most interesting feature of our approach is that it provides a systematic way to compose context-aware Web services.

References 1. Alonso, G., Casati, F., Kuno, H.A., Machiraju, V.: Web Services - Concepts, Architectures and Applications. Data-Centric Systems and Applications. Springer (2004) 2. Medjahed, B., Bouguettaya, A., Elmagarmid, A.K.: Composing web services on the semantic web. VLDB J. 12 (2003) 333–351 3. Satyanarayanan, M.: Pervasive computing: Vision and challenges. IEEE Personal Communications 8 (August 2001) 4. Schilit, B.N., Theimer, M.M.: Disseminating active map information to mobile hosts. IEEE Network 8 (1994) 22–32 5. Dey, A.K., Abowd, G.D., Wood, A.: Cyberdesk: a framework for providing selfintegrating context-aware services. Knowl.-Based Syst. 11 (1998) 3–13 6. Most´efaoui, S.K., Hirsbrunner, B.: Towards a context-based service composition framework. In Zhang, L.J., ed.: Proceedings of the International Conference on Web Services, ICWS’03, CSREA Press (June 2003) 42–45 7. Maamar, Z., Benslimane, D., Thiran, P., Ghedira, C., Dustdar, S., Sattanathan, S.: Towards a context-based multi-type policy approach for web services composition. Data Knowl. Eng. 62 (2007) 327–351 8. Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C.V., Loingtier, J.M., Irwin, J.: Aspect-oriented programming. In: ECOOP. (1997) 220–242 9. Charfi, A., Mezini, M.: AO4BPEL: An aspect-oriented extension to bpel. World Wide Web 10 (2007) 309–344 10. Ceri, S., Daniel, F., Matera, M., Facca, F.M.: Model-driven development of contextaware web applications. ACM Trans. Interet Technol. 7 (2007) 2 11. Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., Griswold, W.G.: An overview of AspectJ. In Knudsen, J.L., ed.: ECOOP 2001 - Object-Oriented Programming, 15th European Conference, Proceedings. Volume 2072 of Lecture Notes in Computer Science., Springer (June 2001) 327–353 12. Gruber, T.R.: A translation approach to portable ontology specifications. Knowl. Acquis. 5 (1993) 199–220 13. Paolucci, M., Sycara, K.P., Kawamura, T.: Delivering semantic web services. In: WWW (Alternate Paper Tracks). (2003) 14. Sirin, E., Parsia, B., Hendler, J.A.: Filtering and selecting semantic web services with interactive composition techniques. IEEE Intelligent Systems 19 (2004) 42–49 15. Sycara, K.P., Paolucci, M., Ankolekar, A., Srinivasan, N.: Automated discovery, interaction and composition of semantic web services. J. Web Sem. 1 (2003) 27–46 16. Benatallah, B., Sheng, Q., Dumas, M.: The self-serve environment for web services composition. IEEE Internet Computing 7 (2003) 40–48

17. Berardi, D., Calvanese, D., Giacomo, G.D., Hull, R., Mecella, M.: Automatic composition of transition-based semantic web services with messaging. In B¨ ohm, K., Jensen, C.S., Haas, L.M., Kersten, M.L., Larson, P.˚ A., Ooi, B.C., eds.: Proceedings of VLDB’05, ACM (2005) 613–624 18. Casati, F., Ilnicki, S., jie Jin, L., Krishnamoorthy, V., Shan, M.C.: Adaptive and dynamic service composition in eflow. In: CAiSE ’00: Proceedings of the 12th International Conference on Advanced Information Systems Engineering, London, UK, Springer-Verlag (2000) 13–31 19. Fan, W., Geerts, F., Gelade, W., Neven, F., Poggi, A.: Complexity and composition of synthesized web services. In: PODS’08: Proceedings of the twenty-seventh ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems, New York, NY, USA, ACM (2008) 231–240 20. Baldauf, M., Dustdar, S., Rosenberg, F.: A survey on context-aware systems. IJAHUC 2 (2007) 263–277 21. Medjahed, B., Atif, Y.: Context-based matching for web service composition. Distributed and Parallel Databases 21 (2007) 5–37 22. Gu, T., Pung, H.K., Zhang, D.: A service-oriented middleware for building contextaware services. J. Network and Computer Applications 28 (2005) 1–18 23. Mrissa, M., Ghedira, C., Benslimane, D., Maamar, Z., Rosenberg, F., Dustdar, S.: A context-based mediation approach to compose semantic web services. ACM Trans. Interet Technol. 8 (2007) 4 24. Maamar, Z., Most´efaoui, S.K., Yahyaoui, H.: Toward an agent-based and contextoriented approach for web services composition. IEEE Trans. Knowl. Data Eng. 17 (2005) 686–697 25. Pawlak, R., Seinturier, L., Duchien, L., Florin, G.: JAC: A flexible solution for Aspect-oriented programming in java. In Yonezawa, A., Matsuoka, S., eds.: Metalevel Architectures and Separation of Crosscutting Concerns, Third International Conference, REFLECTION 2001. Volume 2192 of Lecture Notes in Computer Science., Springer (September 2001) 1–24 26. Sato, Y., Chiba, S., Tatsubori, M.: A selective, just-in-time aspect weaver. In: GPCE ’03: Proceedings of the 2nd international conference on Generative programming and component engineering, New York, NY, USA, Springer-Verlag New York, Inc. (2003) 189–208 27. Bachmendo, B., Unl, R.: Aspect-based workflow evolution. In: In Proc. of the Workshop on Aspect-Oriented Programming and Separation of Concerns. (2001) 28. Schmidt, R., Assmann, U.: Extending aspect-oriented-programming in order to flexibly support workflows. In: Proceedings of the ICSE Aspect-Oriented Programming Workshop. (April 1998) 29. Baumeister, H., Knapp, A., Koch, N., Zhang, G.: Modelling adaptivity with aspects. In Lowe, D., Gaedke, M., eds.: Web Engineering, 5th International Conference, ICWE 2005, Sydney, Australia, July 27-29, 2005, Proceedings. Volume 3579 of LNCS., Springer (2005) 406–416 30. Courbis, C., Finkelstein, A.: Towards aspect weaving applications. In: ICSE ’05: Proceedings of the 27th international conference on Software engineering, New York, NY, USA, ACM (2005) 69–77 31. Verheecke, B., Cibrn, M.A., Vanderperren, V., Suvee, D., Jonckers, V.: Aop for dynamic configuration and management of web services. International Journal of Web Services Research 1 (2004) 25– 41 32. Ortiz, G., Herandez, J., Clemente, P.J.: How to deal with non-functional properties in web service development. In Lowe, D., Gaedke, M., eds.: Web Engineering: 5th International Conference, ICWE 2005. (July 2005)