Composite Web Services as Dataﬂow Graphs for Constraint Veriﬁcation

Jyotsana Gupta, Joey Paquet and Serguei A. Mokhov

Concordia University, Montreal, Quebec, Canada

Keywords:

Composite Service, Service Constraint Veriﬁcation, Service Context.

Abstract:

Owing to advantages such as re-usability of components, broader options for composition requesters and

liberty to specialize for component providers, composite services have been extensively researched and signif-

icantly enhanced in several respects. Yet, most of the studies undertaken fail to acknowledge that every web

service has a limited context in which it can successfully perform its tasks. When used as part of a composition,

the restricted context-spaces of all such component services together deﬁne the contextual boundaries of the

composite service. However, from a thorough review of the existing literature on the subject, we have discov-

ered that no systems have yet been proposed to cater to the speciﬁc veriﬁcation of internal constraints imposed

on components of a composite service. In an attempt to address this gap in service composition research, we

propose a multi-faceted solution capable, ﬁrstly, of automatically constructing context-aware composite web

services with their internal constraints positioned for optimum resource-utilization and, secondly, of validat-

ing the generated compositions using the General Intensional Programming SYstem (GIPSY) as a time- and

cost-efﬁcient simulation/execution environment.

1 INTRODUCTION

Web services are independent, self-describing, modu-

lar programs that can be published, searched for, in-

voked, and executed via the World Wide Web. In

order to enhance their clarity and re-usability, web

services are usually designed to perform simple and

speciﬁc tasks. To accomplish more complex tasks,

such as a shopping process comprising of product cat-

alog display, customer order gathering, credit card

payment processing and product shipment initiation

(as depicted in Figure 1), simple web services (called

component services) are selected for each sub-task

and composed together in the form of a workﬂow

to build a composite web service, which is a cus-

tomized service assembled and arranged according to

each client’s particular and potentially elaborate re-

quirements. The process of web service composition,

besides broadening the client base for each service

provider, opens up a wide variety of service options

to choose from for each sub-task for the service users,

thereby beneﬁting both of the parties involved in the

transaction.

Figure 1: Composite Online Shopping Service.

Owing to such advantages, among others, service

composition has been extensively researched. Sev-

eral aspects of the composition process have been ex-

haustively explored and honed. Yet, there are certain

facets of composite web services that have not been

granted proper consideration. For example, almost all

of the existing research on web service composition

overlooks the fact that every service has a limited con-

text (albeit possibly wide) in which it can successfully

perform its tasks. Such limitations are deﬁned by

service providers and are called internal service con-

straints. For example, while one credit card payment

service (say, W

) might be capable of processing only

Visa cards (internal constraint: CreditCardBrand =

Visa), another service (say, W

) might be able to

process both Visa and Master cards (internal con-

straint: CreditCardBrand ∈ {Visa, Master}). Simi-

larly, a shipment service (say, W

) might be capable of

delivering products only to addresses within Canada

(internal constraint: ShippingAddress ∈ {Canada}).

It cannot be assumed that services can process ev-

ery existing credit card brand or deliver products to

every country in the world. Furthermore, if the ser-

vices W

and W

mentioned above were to be used

as components of the composite online shopping ser-

vice depicted in Figure 1, the shopping service as a

unit would be constrained to {CreditCardBrand =

Visa ∩ ShippingAddress ∈ {Canada}}, i.e., it would

282

Gupta, J., Paquet, J. and Mokhov, S.

Composite Web Services as Dataﬂow Graphs for Constraint Veriﬁcation.

DOI: 10.5220/0009342302820291

In Proceedings of the 10th International Conference on Cloud Computing and Services Science (CLOSER 2020), pages 282-291

ISBN: 978-989-758-424-4

be useful for only those customers who reside in

Canada and use a Visa card for online transactions.

Clearly, this limits the customer-base of the online

store employing the composite shopping service. Due

to such impact, it is important to take all the inter-

nal constraints of atomic services into account while

studying the behavior of composite services. Inter-

nal constraints in the context of service composition

have been discussed in elaborate detail only by Wang,

Ding, Jiang, and Zhou in (Wang et al., 2014), fol-

lowed by Laleh, Paquet, Mokhov, and Yan in (Laleh,

2018; Laleh et al., 2018; Laleh et al., 2017).

Due to the limited exposure received by this as-

pect of web service composition, no systems (as per

our knowledge) have yet been proposed to cater to the

speciﬁc veriﬁcation and validation of constraints im-

posed on component atomic services by their devel-

opers/providers. Most of the existing research on ver-

iﬁcation/simulation/execution of composite web ser-

vices has been concerned with validating their Qual-

ity of Service (QoS) constraints (Shkarupylo, 2016),

functional requirements (Dechsupa et al., 2016) or or-

der of execution of the component services (Huynh

et al., 2015).

The internal service constraints that we aim to ver-

ify are different from those discussed in the research

works cited above. These are restrictions imposed on

the context in which a service can be executed. We

borrow the concept of execution context of a web ser-

vice from (Laleh, 2018) and consider it to be an ag-

gregation of all the information that could affect the

execution of a service. According to this deﬁnition,

each element of an execution context is a name-value

pair. Based on that, the context of a service (be it

atomic or composite) is considered to be the set of all

its input parameters and the values that are assigned

to them at the time of a service call. For example,

consider the composite shopping service depicted in

Figure 1 and its component details for a sample run

provided in Table 1. For this sample run, the context

of atomic service W

would be:

{ProductNumber : ST1234, ProductPrice : 75.00}

while the context of composite shopping service (as-

suming that it takes ProductName, CreditCardBrand,

CreditCardNumber and ShippingAddress as input)

would be:

{ProductName : StudyTable, CreditCardBrand : Visa,

CreditCardNumber : CCVS56789,

ShippingAddress : Canada}

For any composite service, many of the con-

text parameters/dimensions of its component services

could get their values assigned dynamically as the

composite service is being executed. Therefore, in

order to check if the restrictions placed on such vari-

ables (i.e., the internal constraints) are satisﬁed, we

must either actually execute the composite service

or else simulate its execution. For example, sup-

pose, the Shipment service provider imposes a 50-

pound weight-limit on packages shipped by the ser-

vice (internal constraint: ProductWeight <= 50). In

that case, the ProductWeight output parameter pro-

duced by the Catalog service (which is an input to the

Shipment service) would have to be inspected for val-

ues exceeding 50 before the Shipment service could

conﬁrm acceptance of the shipment job. To accom-

plish that, the composite service would have to be

executed, which would produce some value for the

ProductWeight parameter to be compared with the

shipment weight-limit. Such veriﬁcation demands

a simulation or execution environment capable of

executing composite web services composed of ei-

ther simulated or real-world, internally-constrained

atomic web services.

In an attempt to address the above concerns re-

lated to web service composition, in this paper,

we propose the use of the General Intensional Pro-

gramming System (GIPSY) (Paquet, 2009) as a

simulation/execution-based environment for veriﬁca-

tion and validation of constraint- and context-aware

composite web services.

1.1 Objectives and Motivation

Consider an online store that needs a shopping ser-

vice that can display a product catalog to its cus-

tomers, accept their orders, process their credit card

payments and initiate shipment of the ordered goods.

Such a store effectively needs a composition engine

that can construct the required shopping service (sim-

ilar to the one depicted in Figure 1) based on the in-

puts that the store’s customers would be able to pro-

vide, the outputs that they would expect in return and

the set of atomic services available to perform each

of the required tasks. However, as discussed earlier,

atomic services may have restrictions, known as in-

ternal constraints, imposed on their execution context

by their providers, which, in turn, deﬁnes the con-

textual boundaries of any composite service of which

they form a part. Table 1 speciﬁes such internal con-

straints placed on the Payment and Shipment services

that serve as components of the shopping service. The

combinatorial effect of these constraints transforms

the shopping service into a utility tailor-made for cus-

tomers who use Visa credit cards for online trans-

actions, order products weighing up to 50 lbs and

get their purchased goods delivered within Canada,

which makes it essential for the composition engine

Composite Web Services as Dataﬂow Graphs for Constraint Veriﬁcation

283

Table 1: Online Shopping Service Component Details.

Service Type Input Parameters Sample Input Output Parameters Sample Output Internal Constraints

Values Values

Catalog {ProductName} {StudyTable} {ProductNumber, {ST1234, C

ProductPrice, 75.00,

ProductWeight} 45}

Order {ProductNumber, {ST1234, {OrderNumber, {ORD1234, C

ProductPrice} 75.00} PaymentAmount} 82.50}

Payment {OrderNumber, {ORD1234, {PaymentStatus} {Complete} C

= {CreditCardBrand = Visa}

PaymentAmount, 82.50,

CreditCardBrand Visa,

CreditCardNumber} CCVS56789}

Shipment {PaymentStatus, {Complete, {ShipmentStatus} {Conﬁrmed} C

= {ProductWeight <= 50}

ProductWeight, 45, C

= {Ship pingAddress = Canada}

ShippingAddress} Canada}

to take the internal constraints of the Payment and

Shipment services into account while assembling the

shopping service.

Continuing with the motivation scenario, once

the composition engine assembles a suitable com-

posite shopping service, it must subject the service

to some basic behavioral tests, such as validation of

input-output relationships, correct constraint enforce-

ment, and elimination of inaccessible or malfunction-

ing components, before it can be proposed as a prac-

ticable solution to the service requester, i.e., the on-

line store. However, as mentioned in Section 1, while

there are systems available for testing composite ser-

vice behaviors in an unlimited context space, no exist-

ing research offers a solution for veriﬁcation and val-

idation of internally-constrained composite web ser-

vices. Therefore, the composition engine in this sce-

nario has no option other than to trust the component

services to function well within their bounded con-

text space (as advertised in their descriptions) and to

present the composed shopping service to the service

requester without testing its contextual limits. Sim-

ilarly, the service requester has no alternative but to

trust the composition engine to have performed all

possible checks and to accept the composed solution

as a feasible one, following which it might enter into

a binding contract or lease with the providers of each

of the component services involved. Let us suppose

that the Payment component service, W

, has a faulty

implementation or its constraint description was mis-

takenly replaced by that of a different Payment ser-

vice. Because of one or more of such human-errors,

ends up being presented as a Visa card process-

ing service while actually having been programmed

to process Master cards. Now, suppose that the on-

line shopping store is not allowed to accept Master

cards because of an agreement with Visa. In this sit-

uation, if a customer of the store attempts to make an

online purchase with their Visa credit card, the Pay-

ment service would fail and the order would be re-

jected. Meanwhile, another customer using a Master

card might succeed in placing their order, thus violat-

ing the store’s agreement with Visa. Not only would

such an event prevent the store from making any valid

sale until the service is repaired or replaced, it could

have an adverse effect on the store’s reputation, which

could harm its business. Additionally, the store might

have to suffer monetary losses because of the contract

signed with the provider of the Payment service (W

as it no longer holds any utility for it, or even face le-

gal consequences for their breach of agreement with

Visa. Besides, the composition engine is also likely

to get affected by such occurrences and lose its credi-

bility with its clients for supplying unreliable and de-

fective composite services.

As explained earlier, contextual elements of com-

ponent services often get their values assigned dy-

namically as their composite service is being exe-

cuted, which implies that any conditions placed on

those elements must be evaluated at run-time. There-

fore, a system meant for the veriﬁcation of context-

and constraint-aware composite web services must be

capable of either simulating execution of or actually

executing those composite services.

While with the execution system we aim to test

the actual behavior of services and weed out non-

functional components or components that do not be-

have according to their agreed constraints/speciﬁca-

tions, our purpose for the simulation system is to be

able to test the suitability of composition solutions

and implement quick ﬁxes in case of issues with min-

imal resources and time and without requiring access

to any service’s code.

We recognize an enhancement in time-efﬁciency

by a reduction in the average response-time of a com-

posite service both during simulation and execution.

An increase in cost-efﬁciency, on the other hand, can

have two aspects: a reduction in the average fee to be

paid to the component service providers for utilizing

(i.e., executing) their services as part of a composi-

tion or a decrease in the number of component ser-

vice rollbacks to be borne due to constraint-violation

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

284

during composite service execution.

1.2 Literature Review

The primary goal of this paper is to present a

simulation/execution-based veriﬁcation solution for

context- and internal-constraint-aware composite ser-

vices. We present here some related solutions.

The research conducted by Wang et al. (Wang

et al., 2014) and Laleh et al. (Laleh, 2018; Laleh

et al., 2018; Laleh et al., 2017) on composition

of internally-constrained web services. These re-

searchers propose graph-search-based composition

algorithms augmented with novel techniques to merge

composition plans/sub-plans operating in different

contexts into a single larger plan for widening the

overall contextual range of a composite service. How-

ever, neither of these solutions can guarantee exhaus-

tive coverage of a context space, which leaves the

generated composite services vulnerable to run-time

constraint-veriﬁcation failures, thereby necessitating

the construction of a behavior veriﬁcation and vali-

dation system. Using Petri nets for composition of

internally-constrained services allows for such a ver-

iﬁcation to a certain extent by means of simulation.

For example, Cheng, Liu, Zhou, Zeng, and Yla-Jaaski

(Cheng et al., 2015) introduce an automated composi-

tion method for internally-constrained fuzzy semantic

web services using Fuzzy Predicate Petri Nets. Such

approaches ensure that the generated composite ser-

vices satisfy the input/output requirements of the user

while ensuring that they do not conﬂict with the inter-

nal constraints of component services. However, Petri

nets are not capable of executing real services and,

therefore, cannot be used for execution-based veriﬁ-

cation of composite services.

Most of the simulation/execution solutions use

WS-BPEL representation of composite services as

their input, which they ﬁrst translate into a veriﬁca-

tion language or a formal simulation model and then

validate them using a simulator or model checker tool.

For example, Siala, Ait-Sadoune, and Ghedira (Siala

et al., 2014) propose translation of WS-BPEL pro-

cesses into Multi-Agent Systems, which can simu-

late service behavior using JADE framework for ob-

servation and detection of undesired properties, such

as live-lock and deadlock. Meanwhile, Juan and Hao

(Juan and Hao, 2012) use QPME tool for, ﬁrst, trans-

forming WS-BPEL processes into Queuing Petri Nets

(QPN’s) and, then, simulating the QPN’s for quanti-

tative performance analysis. Dechsupa, Vatanawood,

and Thongtak (Dechsupa et al., 2016) suggest Col-

ored Petri Nets for formal modeling of WS-BPEL

processes and CPN Tool for editing, simulation and

analysis of the CPN’s generated. Translation of com-

posite services written using WS-BPEL into Promela

language is discussed by Nagamouttou et al. (Nag-

amouttou et al., 2015). SPIN tool is used for an-

alyzing these translations for various desirable and

undesirable properties. Chen, Tan, Sun, Liu, and

Dong (Chen et al., 2014) propose using VeriWS for

analyzing the semantics of a WS-BPEL process di-

rectly (i.e., without translation) to check for dead-

locks, reachability, and QoS constraint-satisfaction as

well as for detecting anomalies in the composition’s

functionality. Shkarupylo (Shkarupylo, 2016) pro-

poses synthesis of formal TLA+ speciﬁcation for a

WS-BPEL composition and testing its functional and

non-functional properties using TLC model checker

and DEVS Suite toolkit through simulation and vi-

sualization of service behavior. Although several of

these approaches succeed in incorporating automa-

tion and extensibility into their translation processes

(similar to ours), none of them supports completely

automated composition of services, which limits their

practicality while handling complex compositions or

large repositories of services.

2 SERVICE COMPOSITION

While simulating and executing internally-

constrained composite services is the primary

goal of this paper, constructing such services based

on a composition request and a set of services avail-

able for composition is an essential prerequisite to the

simulation/execution process. The automated service

composition technique that we employ in this paper

has been borrowed from the research conducted by

Laleh et al. (Laleh, 2018; Laleh et al., 2018; Laleh

et al., 2017; T. Laleh et al., 2017) for its formal model

of constraint-aware composite services and its unique

constraint-adjustment technique, which enhances the

time- and cost-efﬁciency of the composition and,

subsequently, the simulation/execution process.

To aid with a better understanding of the service

composition methodology devised by Laleh et al., in

this section, we present the formal deﬁnitions of the

fundamental entities and concepts involved in the pro-

cess (Laleh, 2018).

Deﬁnition 1. A Service is a tuple S =

I, O,C, E, QoS

where: I is the set of ontology

types representing the input parameters of the

service; O is the set of ontology types representing

the output parameters of the service; C is the set

of constraint expressions representing limitations

on service features; E is the set of ontology types

representing parameters whose values are affected as

Composite Web Services as Dataﬂow Graphs for Constraint Veriﬁcation

285

a result of the execution of the service; QoS is the set

of quality parameters of the service.

Deﬁnition 2. An Internal Constraint

is a boolean expression of the form:

feature

operator

literalValue

, where:

feature

represents an input parameter of a

service, which is an ontology type;

operator

repre-

sents operators such as =, <, >, ≤, ≥;

literalValue

represents a value or a set of values of the same data

type as the expression feature.

Deﬁnition 3. A Service Composition Request is a tu-

ple R =

I, O,QoS,C

where: I is the set of ontology

types representing the input the customer can provide;

O is the set of ontology types representing the output

expected by the customer; QoS is the set of quality pa-

rameters expected from the service by the customer;

C is the set of constraints representing limitations of

service requester.

Since, in this paper, we take only internal constraints

into consideration, our current implementation of a

composition request models but does not process the

requester’s QoS and constraint requirements. In re-

sponse to a composition request, we generate a set of

one or more solution plans, i.e., workﬂows of compo-

nent services capable of producing the requested out-

put by processing the given input while verifying the

internal constraints placed on the components. These

plans are called constraint-aware plans.

Deﬁnition 4. A Constraint-Aware Plan is a directed

graph extracted from the search graph in which each

node is a service-node

, service

, using initial pa-

rameters (R.I), whose successive application of ser-

vices of nodes eventually generates the goal parame-

ters (R.O).

The search graph referred to in the above deﬁnition

is the graph of service nodes that gets generated as a

result of the forward expansion stage of the composi-

tion process and represents a collection of all the solu-

tion plans that can be constructed for a given compo-

sition request. For each service-node

, service

a constraint-aware plan, C

refers to the set of all ser-

vice constraints that must be veriﬁed before service

can be executed as part of the plan. The term R.I

refers to the input parameters speciﬁed as part of the

given composition request R while R.O refers to the

requested output parameters. Each service-node in a

constraint-aware plan has a set of predecessors and a

set of successors associated with it, which are deﬁned

as follows:

Deﬁnition 5. The predecessor set of a service-node

in a constraint-aware plan represents the set of all

services-nodes that must be executed before the exe-

cution of the service-node, and the successor set rep-

resents the set of all services-nodes that will be exe-

cuted only after the execution of the service-node in

the constraint-aware plan.

We present our service composition methodology

as a set of algorithms, which transform a given com-

position request and set of available services into a

set of constraint-aware composition plans or compos-

ite services.

The main ServiceComposition algorithm drives

the service composition process: (1) forward expan-

sion constructs a search graph based on a given com-

position request and available services; (2) backward

search extracts solution plan sets from the search

graph; (3) plan construction discards extraneous ser-

vices from solution plan sets and arranging the re-

maining ones into solution plans, and (4) constraint-

aware plan construction transforms solution plans

into constraint-aware plans with their constraint ver-

iﬁcation points adjusted to optimum locations.

The ForwardExpansion algorithm generates a

search graph for a given composition request. A

search graph is a directed graph composed of ordered

layers, each of which is assigned certain speciﬁc ser-

vices selected from the given repository. As forward

expansion begins, prdSet is initialized with the initial

parameters, after which the repository is searched for

those services all of whose input parameters exist in

prdSet. Each of the suitable services discovered dur-

ing the search must generate an output parameter that

is not already present in prdSet and must not violate

any of the requested constraints. Services that match

these criteria are added to the next layer in the search

graph. The output parameters produced by all the ser-

vices included in the layer are then added to prdSet

and the repository is searched again for services that

can be added to the following layer based on the up-

dated set of parameters. The search graph thus grows

layer by layer until no more services from the reposi-

tory can be added. If the prdSet obtained at the end of

the expansion contains all the goal parameters (R.O),

the problem is solvable and the search graph is re-

turned to the ServiceComposition algorithm for fur-

ther processing.

The BackwardSearch algorithm recursively ex-

tracts service sets that can reach the goal parameters

from the initial parameters from a search graph us-

ing a backward-chaining strategy. The algorithm be-

gins by generating all possible combinations of the

services in the last layer of the search graph. For

each of these combinations, it extracts their predeces-

sors from the previous layer and generates all possi-

ble combinations. The process is repeated for these

and all subsequent combinations until the ﬁrst layer

is reached. Thus, a large number of branches or se-

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

286

quence of sets of services (planSet) going from the

ﬁrst to the last layer of the search graph are created.

For each of these sets, the set of outputs of all its ser-

vices is checked to ensure that it includes all the goal

parameters. Each planSet that is successfully veriﬁed

is returned to the Service Composition algorithm for

further processing while others are discarded as in-

valid. This process is repeated with each layer of the

search graph serving as the starting layer for back-

ward search.

The ConstructPlans algorithm ﬁrst organizes the

services in a planSet from the BackwardSearch algo-

rithm in order of their layer indexes to create a lay-

ered directed graph, or plan. Then, for each service

in the plan, the set of outputs of all its predecessors

present in the plan together with the initial parame-

ters is checked to ensure that it includes all the inputs

of the service, otherwise, the service is removed from

the plan. Each of the remaining services in the plan

that neither have a successor in the plan nor produce

any goal parameter are also discarded. This removal

process continues until no more services can be re-

moved from plan. If the set of outputs of all remain-

ing services in the plan includes all the goal param-

eters, the plan is returned to the ServiceComposition

algorithm for further processing.

The ConstructCAPlans algorithm ﬁrst trans-

forms the solution plans generated by ConstructPlans

into constraint-aware plans and then adjusts each

constraint of each service-node (serviceNode) in each

plan to an optimal location. To accomplish that, a pre-

decessor service-node (preNode) to serviceNode that

affects the value of the feature to which the constraint

applies is selected. The constraint is then moved to

veriﬁcation points immediately before the execution

of all successor service-nodes of preNode. This pro-

cess is repeated with all the predecessors of serviceN-

ode as well as their predecessors until the constraint

is moved to the earliest and most efﬁcient veriﬁca-

tion point in cnstrAwrPlan. In case no predecessors

are found to affect the constrained feature’s value, the

constraint is moved to the beginning of cnstrAwrPlan.

Once all the constraints in all cnstrAwrPlans are ad-

justed, they are returned to the main ServiceCompo-

sition algorithm as constraint-aware solutions to the

given composition request.

3 TRANSLATION TO OBJECTIVE

LUCID

We propose the use of GIPSY as the simulation/exe-

cution environment for context- and constraint-aware

composite services. However, since GIPSY is dedi-

cated to the compilation and execution of LUCID pro-

grams (Ashcroft et al., 1995; Wadge and Ashcroft,

1985), composite services, before being executed on

GIPSY, must be translated into a LUCID dialect,

which, in our case, is OBJECTIVE LUCID (Mokhov,

2005; Mokhov and Paquet, 2005). To accomplish

that, we design and implement a ﬂexible translator

framework capable of allowing modular plugging-

in and -out of different translator programs, as and

when required. This framework can accept a com-

posite service as input through an extensible multi-

modal input system and translate it into any of the

target models for which a translator module is avail-

able. There are several reasons responsible for our

decision to use OBJECTIVE LUCID for represent-

ing and GIPSY for simulating/executing context- and

constraint-aware composite services, which we dis-

cuss below:

LUCID, being an intensional programming lan-

guage, it can efﬁciently represent context-dependent

entities, allowing each context to be composed of

inﬁnite-many dimensions and each dimension to be

deﬁned as a regular variable in a concise and precise

manner besides providing operators # and @ for di-

rectly extracting values from and specifying values

for the contextual dimensions respectively. Addition-

ally, the whenever operator supplied by LUCID en-

ables context-dependent conditions (i.e., internal con-

straints) to be placed on variable and function deﬁ-

nitions (i.e., services), allowing them to be comput-

ed/executed only if the conditions evaluate to true

(Ashcroft et al., 1995; Wadge and Ashcroft, 1985).

OBJECTIVE LUCID is a hybrid language that em-

ploys LUCID for representing a composite service as

a dataﬂow network and JAVA for specifying the op-

erations performed by component services, thereby

combining the ease and enhanced productivity of pro-

gramming in mainstream languages with the efﬁ-

ciency of intensional dataﬂow languages (Mokhov,

2005; Mokhov and Paquet, 2005). In addition to that,

its use of JAVA enables a simulated function deﬁni-

tion for a component service to be easily swapped

with a deﬁnition that invokes the real online service,

thereby allowing the veriﬁcation process to be con-

ducted through simulation as well as execution while

minimizing the effort involved in switching between

the two modes.

Since LUCID is a dataﬂow programming lan-

guage, upon execution, a LUCID program repre-

senting a constraint-aware composite service is in-

terpreted as a dataﬂow network of concurrently-

executing component service ﬁlters enveloped in

wrappers serving as internal-constraint-veriﬁcation

layers. GIPSY’s eductive, demand-driven approach

Composite Web Services as Dataﬂow Graphs for Constraint Veriﬁcation

287

towards execution together with its warehouse unit

capable of storing and being queried for execution

results computed earlier in speciﬁc contexts (instead

of re-evaluating them) signiﬁcantly reduce the over-

all time, effort and cost spent on simulation/execution

of composite services (Paquet, 2009; Ashcroft et al.,

1995).

The implementation and operation of our OBJEC-

TIVE LUCID translator is based on a set of algorithms

that together deﬁne our translation methodology. In

this section, we present and explain these algorithms

using the shopping composite service depicted in Fig-

ure 2.

The TransCSToOLucid algorithm drives the

translation process, invoking the other algorithms

when required. It consists of four major steps: (1)

ValidateInpValues responsible for ensuring that each

composite service input parameter receives a value of

appropriate data type, (2) GenerateJavaSegment for

producing the JAVA segment of the translation, (3)

GenerateOLucidSegment tasked with generating the

LUCID segment of the resultant program, and (4) ap-

pending the generated JAVA segment with the LU-

CID segment for constituting the complete OBJEC-

TIVE LUCID translation of the given composite ser-

vice.

The GenJavaSegment algorithm is responsible

for generating the JAVA segment of the OBJECTIVE

LUCID translation of a composite service. This seg-

ment, comprises of a collection of JAVA class and

method deﬁnitions representing two types of nodes:

the output accumulator node and the component ser-

vice nodes. The output accumulator node represented

as JAVA class CAWSReqComp, where CAWS stands

for Constraint-Aware Web Service) assembles com-

posite service outputs generated by one or more com-

ponent services as data members of a single object,

which can be returned as the computed value of the

composite service’s LUCID expression, thereby al-

lowing the composite service to produce multiple out-

puts in any given context.

The GenAtomSvcJavaDef algorithm is invoked

by GenJavaSegment for generating a pair of JAVA

class and free function deﬁnitions that together de-

ﬁne and provide the means of triggering the opera-

tion of a component service. For example, consider

the call to service W4’s free function w4. User input

shippingAddress and outputs productWeight and pay-

mentStatus produced by components W1 and W3 re-

spectively, which serve as inputs to W4, are supplied

as arguments to this function call to be used by the

function as arguments while calling the corresponding

service class (CAWSW4) constructor. The constructor

initializes W4’s input parameters acting as CAWSW4’s

data members with these arguments while initializ-

ing the output data members with dummy values.

Once service object oCAWSW4 is created, method w4

uses it to invoke CAWSW4’s process member method

responsible for processing the given inputs and up-

dating the output data members with the results ob-

tained, following which method w4 returns the up-

dated oCAWSW4 object and, hence, the service out-

puts to the LUCID segment. The algorithm begins

by deﬁning the given component service’s JAVA class,

comprising of its input and output parameters as data

members, a constructor to initialize them, and process

member method to transform the inputs into outputs.

Then the algorithm generates the component service’s

free function deﬁnition.

The GenOLucidSegment algorithm builds the

LUCID segment of the OBJECTIVE LUCID translation

of a composite service. The algorithm starts by deﬁn-

ing the main LUCID expression, representing the out-

come of the composite service, along with the global

execution context, comprising of composite service

input name-value pairs leading to context-driven exe-

cution. Then the algorithm constructs the LUCID ex-

pression representing the output accumulator node of

the composition. This node accepts composite ser-

vice outputs as inputs or arguments to its JAVA func-

tion call, which assembles them into an object. Val-

ues for the arguments are extracted from the local

context of the accumulator’s LUCID expression de-

ﬁned as a set of composite service output parameter

names paired with their respective values generated

by various component services. The LUCID represen-

tation of each of the component services, which also

forms part of the accumulator node’s where clause,

is generated by the GenAtomSvcLucidDef algorithm

invoked iteratively from the GenOLucidSegment for

each service-node in the composition’s constraint-

aware plan.

The GenAtomSvcLucidDef algorithm is invoked

by GenOLucidSegment for generating the LUCID

representation of a component service. It begins by

deﬁning the set of the given service-node’s input pa-

rameters and constraint-features as the contextual di-

mensions for its LUCID expression. Since, before

computing a component service expression in LU-

CID, all the constraints attached to its service-node

must evaluate to true, constraint-features must be in-

cluded in the component service’s dimension list as

well as evaluation context, which speciﬁes the source

of their values – essential for their computation. The

algorithm builds this evaluation context, pairing the

component’s dimensions with values either received

from the user (extracted from global dimensions using

# operator) or generated as outputs by other compo-

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

288

Figure 2: Constraint-aware Shopping Composite Service.

nent services. The algorithm then extracts the inputs

and constraints attached to the given service-node and

use them as the second and ﬁfth arguments respec-

tively to DeﬁneSvc procedure while leaving its last ar-

gument blank (depicted as

0) as there are no compo-

nent service deﬁnitions to be included in the given ser-

vice’s where clause. During execution of the OBJEC-

TIVE LUCID program so generated, component ser-

vice name, which serves as the ﬁrst argument to De-

ﬁneSvc, is used to invoke the free function deﬁned for

the service in the JAVA segment with the input values

extracted from its LUCID expression’s local context

(using # operator) passed as arguments to the func-

tion call and the outputs obtained by processing them

returned as an object from the JAVA segment.

4 SOLUTION EVALUATION

To assess the operational aspect of our solution, we

focus our evaluation process on ensuring that the

composition and translation applications that we de-

veloped based on these designs function absolutely in

accordance with them and, hence, achieve each of the

research goals deﬁned on the operational level. We

meticulously analyzed every step of the algorithms

and prepared exhaustive lists of all their constituent

operations/tasks together with all the essential condi-

tions to be met and properties to be exhibited at every

step. We divided the composition and translation pro-

cesses into various stages each of which has a speciﬁc

goal to be achieved by performing a well-speciﬁed

series of tasks. For example, the forward expansion

stage of the composition process aims at generating

a valid search graph while the backward search stage

is focused on extracting valid solution plan sets from

that search graph. Each separate modular task can

then be more effectively speciﬁed and then tested. We

manually designed test cases, including atomic and

composite services, repositories, and composition re-

quests required as input for each of them, to ensure

that each of the required operations, conditions, and

properties are properly incorporated into the imple-

mented solution and that the composition and trans-

lation applications function as per their designs both

individually and as a uniﬁed process. This thorough

analysis and careful design enabled us to design 76

different unit tests.

5 CONCLUSION

Owing to advantages such as clarity of structure, re-

usability of components, broader options for users

and liberty to specialize for providers, composite web

services have been extensively researched over the

past two decades. Yet, from a thorough review of the

literature available on the studies undertaken in the

ﬁeld so far, we gather that most of these studies fail

to acknowledge that every service has a limited con-

text in which it can successfully perform its tasks, the

boundaries of which are deﬁned by the internal con-

straints placed on the service by its providers. When

used as part of a composition, the restricted context-

spaces of all such component services together deﬁne

the contextual boundaries of the composite service as

a unit, which makes internal constraints an inﬂuen-

tial factor for composite service functionality. How-

ever, due to the limited exposure received by this as-

pect of web service composition, no systems (as per

our knowledge) have yet been proposed to cater to

the speciﬁc veriﬁcation and validation of internal con-

straints imposed on components of a composite ser-

vice.

Based on the concept of context found in in-

tensional logic together with the deﬁnition proposed

by (Laleh, 2018), the execution context of a web ser-

vice can be considered as a set of all its input param-

eters paired with the values assigned to them at the

time of the service call. In case of composite services,

many of these contextual parameters for component

services could get their values assigned dynamically

as the composite service is being executed. There-

fore, in order to check if the restrictions placed on

such variables (i.e., the internal constraints) are satis-

ﬁed, any veriﬁcation solution proposed would need to

Composite Web Services as Dataﬂow Graphs for Constraint Veriﬁcation

289

either actually execute the composite service or else

simulate its execution.

In an attempt to address the above problems re-

lated to web service composition, in this paper, we

propose the use of GIPSY as a simulation/execution-

based environment for veriﬁcation and validation of

constraint- and context-aware composite web ser-

vices. Since GIPSY is a system dedicated to the com-

pilation and execution of LUCID programs, it requires

the composite services under examination to be trans-

lated into programs written in some LUCID dialect.

Therefore, as part of our proposed solution, we design

and implement in JAVA an automated and extensible

translator framework that allows modules for translat-

ing composite services into OBJECTIVE LUCID.

In order to assess the extent to which these two

processes fulﬁll their design goals, we prepare ex-

haustive lists of all their constituent operations to-

gether with the other required conditions to be met

by each of their algorithms and perform tests on them

individually as well as all of them combined as a

composition or translation process. Taking our scope

and time restrictions under consideration, the meticu-

lous study that we have conducted on the composition

methodology and the LUCID/GIPSY model, we can

conclude that we have been able to effectively eval-

uate our composition and translation solutions and

have found them to be capable of fulﬁlling all their

design objectives.

6 LIMITATIONS AND FUTURE

WORK

During the course of this research, we discovered sev-

eral features that can be incorporated into our current

veriﬁcation solution in order to make it more compre-

hensive, maintainable, efﬁcient, robust, reliable and

versatile while improving the quality of the composi-

tions that it generates and validates. The current user

interface for the service composition application can

be enhanced to assist the user in applying customized

termination conditions on the forward expansion pro-

cess for increased control over the processing dura-

tion. For instance, growth of a search graph can be

stopped once a certain number of possible solutions

are likely to have been obtained, a certain number of

layers have been constructed or a certain amount of

time has been consumed. Although we allow service

requesters to specify their constraints and expected

QoS features as part of a composition request for

the sake of completeness, we do not implement any

mechanisms as of now that would enable requester

constraints or QoS features to be included in a solu-

tion plan. While our composition application allows

composite services to be used as components in other

compositions, our translator framework still assumes

the components of its source composite services to

be atomic in nature. We plan to improve the design

of our existing translator modules so as to be able to

represent composite component services in the trans-

lations generated. We currently use a scenario-based

testing approach which does not represent an abso-

lute proof of absence of unexpected or faulty behav-

ior. We are working on the design of a formal model

of the OBJECTIVE LUCID translation model followed

by development of a correctness proof.

REFERENCES

Ashcroft, E. A., Faustini, A. A., Jagannathan, R., and

Wadge, W. W. (1995). Multidimensional Program-

ming. Oxford University Press, London.

Chen, M., Tan, T. H., Sun, J., Liu, Y., and Dong, J. S.

(2014). VeriWS: A tool for veriﬁcation of combined

functional and non-functional requirements of web

service composition. In Proc. of the 36th Int’l Conf.

on Softw. Eng., pages 564–567, New York, NY, USA.

ACM.

Cheng, J., Liu, C., Zhou, M., Zeng, Q., and Yla-Jaaski, A.

(2015). Automatic composition of semantic web ser-

vices based on fuzzy predicate petri nets. IEEE Trans.

on Automation Sc. and Eng., 12(2):680–689.

Dechsupa, C., Vatanawood, W., and Thongtak, A. (2016).

Formal veriﬁcation of web service orchestration us-

ing colored petri net. In Int’l MultiConf. of Eng. and

Comp. Sc., volume 1.

Huynh, K. T., Quan, T. T., and Bui, T. H. (2015). Fast and

formalized: Heuristics-based on-the-ﬂy web service

composition and veriﬁcation. In 2nd Nat. Found. for

Sc. and Techn. Devel. Conf. on Inf. and Comp. Sc.,

pages 174–179.

Juan, S. and Hao, W. (2012). Performance analysis for web

service composition based on queueing petri net. In

Int’t Conf. on Softw. Eng. and Service Sc., pages 501–

504. IEEE.

Laleh, T. (2018). Constraint Veriﬁcation in Web Service

Composition. PhD thesis, Department of Computer

Science and Software Engineering, Concordia Univer-

sity, Montreal, Canada.

Laleh, T., Paquet, J., Mokhov, S., and Yan, Y. (2018).

Constraint veriﬁcation failure recovery in web service

composition. Future Generation Computer Systems,

89:387 – 401.

Laleh, T., Paquet, J., Mokhov, S. A., and Yan, Y. (2017).

Predictive failure recovery in constraint-aware web

service composition. In Proc. of the 7th Int’l Conf. on

Cloud Computing and Services Sc., pages 241–252.

SciTePress.

Mokhov, S. and Paquet, J. (2005). Objective Lucid – ﬁrst

step in object-oriented intensional programming in the

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

290

GIPSY. In Proceedings of the 2005 International

Conference on Programming Languages and Compil-

ers (PLC 2005), pages 22–28. CSREA Press.

Mokhov, S. A. (2005). Towards hybrid intensional pro-

gramming with JLucid, Objective Lucid, and General

Imperative Compiler Framework in the GIPSY. Mas-

ter’s thesis, Dept. of Comp. Sc. & Softw. Eng.

Nagamouttou, D., Egambaram, I., Krishnan, M., and

Narasingam, P. (2015). A veriﬁcation strategy for

web services composition using enhanced stacked au-

tomata model. SpringerPlus, 4(1):98.

Paquet, J. (2009). Distributed eductive execution of hybrid

intensional programs. In Proc. of the 33rd Ann. IEEE

Int’l Comp. Softw. and Appl. Conf., pages 218–224.

IEEE Computer Society.

Shkarupylo, V. (2016). A simulation-driven approach for

composite web services validation. In Central Euro-

pean Conf. on Inf. and Intel. Systs., page 227. Faculty

of Organization and Informatics Varazdin.

Siala, F., Ait-Sadoune, I., and Ghedira, K. (2014). A multi-

agent based approach for composite web services sim-

ulation. In Int’l Conf. on Model and Data Eng., pages

65–76. Springer.

T. Laleh, J. P., Mokhov, S., and Yan, Y. (2017). Con-

straint adaptation in web service composition. In 2017

IEEE International Conference on Services Comput-

ing (SCC), pages 156–163.

Wadge, W. W. and Ashcroft, E. A. (1985). Lucid, the

Dataﬂow Programming Language. Academic Press,

London.

Wang, P., Ding, Z., Jiang, C., and Zhou, M. (2014).

Constraint-aware approach to web service composi-

tion. IEEE Trans. on Systems, Man, and Cybernetics

Syst/, 44(6):770–784.

Composite Web Services as Dataﬂow Graphs for Constraint Veriﬁcation

291