Cardinality heterogeneities in Web service composition: Issues and solutions

Cardinalit y heterogeneiti es in W eb service comp osition: Issues and solutions M. Mrissa 1 , Ph. Thiran 1 , J-M. Jacquet 1 , D. Benslimane 2 and Z. Maamar 3 1 Universit y of Namur, Namur, Belg ium { michael.mrissa, philipp e. t hir an, je an-marie.jac quet } @fundp.ac.b e 2 Claude Bernard Ly on 1 U niv ersity , Ly on, F rance djamal.b enslimane@liris.cnrs.fr 3 Za yed Univers it y , Dubai, U nited Arab Emirates zakaria.maamar@zu.ac.ae Abstract. Data exchanges b et ween W eb services e ngaged in a comp osi - tion raise sev eral heterogeneities. In th i s pap er, we address the p ro blem of data cardinalit y heterogeneity in a composition. Firstly , we build a theoretical framew ork to describe different aspects of W eb services t h a t relate to data cardinality , and secondly , we solve this problem by de- velo ping a solution for cardinalit y m ed i ation based on constraint logic programming. Keywords. W eb services, Comp osi tion, Mediation, Cardinality . 1 In tro duction W eb services are indep enden t s oft ware comp onen ts that users or other peer s can in vok e in or d er to utilize their functionalities, like Wea therForeca st and RoomBo oking . W eb services co m bine the b enefits of service-o rien ted computing paradigm and platform- independent proto cols (HTTP [6]) to enable and sustain business-to-busines s collab oratio ns . T o make these colla b o rations happe n and last for long p erio ds of time, W eb services rely on a set of XML-based proto cols and la nguages that suppo rt their discov ery (UDDI [10]), description (WSDL [3]) and in v o cation (SOA P [2]). Comp osition o rchestrates the functionalities of several W eb ser vices into the same lo osely-co upled business pro cesses to answ er co mplex users’ needs. Differ- ent languages exist to specify comp osition scenarios in terms of W eb services to include, interactions to allow, exceptions to handle, just to cite a few. WS-BPEL is now adays the defacto co mpo sition standard [4]. Ho wever despite this “battery” of pr oto cols and languages , comp osition r emains a tedious task. W eb serv ices contin ue to b e designed in iso lation from each other, which increa ses the levels of heterog e ne ities b etw een them. In to day’s economy , it is unlikely that s upplier s will develop the same types of W eb services and comply with the sa me design options. In this pap er, w e lo ok into these hetero geneities from a da ta-cardina lity per - sp ective. Ca rdinality typically refer s to the num b er of elements in a set or gro up, and is co nsidered as a prop er t y o f that g rouping (W o r dnet [1]). In the co n text of W eb services co mp o sition, w e refer to car dinality as the n um ber of data instances contained in the messag es that W eb services eng aged in comp ositio n exchange. W eb ser vices hav e different limitations in terms of minimum a nd maximum da ta cardinalities, and this for several r easons such as technical limitatio ns , search for interop erability with s p ecific partners, qua lity of service dep ending on the nu m ber of results pr ovided, etc. W e refer to these limitations as c ar dinality c on- str aints . Mismatching cardina lity constraints will for sur e hamp er the smo oth progre s s o f a compo sition by making W eb services, for example, indefinitely wait for the rig ht n um ber of elemen ts o r re tur n inv a lid resp onses because of the lack o f appropria te elements. Additional illustrative examples are provided throug hout this pap er. While cardinality heterogeneities hav e b een tackled in the field o f schema matching [7], a nd despite the large amount of work o n W eb services mediation, the res olution of cardina lit y heterogeneities b etw een W eb ser v ices remains some- how marg inalized. In [8], Nag ara jan et a l. present a classificatio n of W eb services heterogeneities. In s pite of an exhaustive classification, the author s do not explic- itly men tio n ca rdinality heterogeneities. Instead, they men tion a n “ ent it y level” category of data incompatibilities, to which car dinality hetero geneities b e long. In the following, we specifica lly fo cus on car dinality heterogeneities, and as sume that semantic and structural data heterog eneities are already fixed. The r est of this pap er is structured a s follo ws. Section 2 presents the v oca b- ulary and theor etical background that was develop ed to tackle the cardinality concern. Section 3 lists the different cases of ca rdinality heterog e neities that arise betw een W eb ser vices. Section 4 describe s the prop osed solution a long with its theoretical and implemen tation framework, pr ior to concluding in Section 5. 2 Theoretical framew ork Our work starts by defining v ar ious co ncepts suc h as data flow, W eb service, and comp ositio n. The purp ose of these definitions is to formalize the car dinality issue, and provide a solid background fo r the pro p osed solution. 2.1 Data flow representation A compositio n or chestrates several W eb services in to a business proces s. In this pro cess, W eb s e rvices typically manage data and ex change them with p eers in compliance with some predefined flows. Characteristics of data flow: Fig. 1 illustrates a simple data flow betw een t wo W eb services: da ta are passed on from a source W eb serv ice W S 1 ( sender ) to a tar get W eb ser vice W S 2 ( r e c eiver ). Thes e data a re o rganized in terms of input and output messages that are structured using several par ts. E ach message part ha s a typ e describ ed with an XML Schema [11]. This typ e may contain additional elements integrated in to a complex s tr ucture. Car dinality constraints on da ta ar e express ed at the t ype level using minO ccu rs and ma xOccur s XML Schema attr ibutes. Examples of such constr a ints in Fig. 1 ar e [ min A 1 , max A 1 ], [ min AP , max AP ], [ min A 1 ′ , max A 1 ′ ], and [ min AP ′ , max AP ′ ]. Fig. 1. Simple data flo w in a composition F or s implifica tion pur p o ses, this pap er deals with messag es that cont ain one part with a data type that contains one co uple of minO ccur s a nd maxOccur s cardinality cons traints. How e ver, this do es not limit the a pplica bility of our solution to complex data structures and m ulti-part messages. Constrain ts on data flo ws: In a compo sition, different cons traints that rela te to the ca rdinality concern apply to data flows. W e illustrate these co nstraints with the following exa mples: – Example 1 : Edito r W S 1 sends data to prin ting W S 2 . – Example 2 : Go o g le-like W S 1 sends data to mashup W S 2 . – Example 3 : Shopping W S 1 sends data for paymen t to banking W S 2 . Data sele ction c onstr aint. Denotes the p os sibility of selecting s ome e le men ts out of the data flow. In Exa mple 1, data selection is not author ized, i.e., a ll data from W S 1 m ust b e pr int ed. Similarly , all s ho pping items must b e pro cessed by the banking W eb ser vice in Example 3. Data flows in bo th examples are not data-selection toler ant. In Example 2, W S 2 only selects the first element s in the list, b ecause sear ch results ar e classified according to their relev a nce, and a s a consequence the first r esults ar e the most relev an t. If the mashup W S 2 offers three en tries for the search answers, only the first three results are sele c ted. In this example, the data flow is data-s election tolerant . Duplic ate c onstr aint. Denotes whether receiver W eb ser vices tolerate inco ming data with duplicate e le ments. In Examples 1 and 3, data flows are duplica te tolerant. Indeed, a same do cument can be printed se veral times, and a shopping item b oug ht sev eral times needs to b e paid several times. In Exa mple 2, dupli- cates a r e not tolerated and s hould b e merged into a unique element, as us e rs are not interested in duplicate sea rch results, so the data flow is not duplicate tolerant. Or dering c onstr aint. Relates to how muc h changes in the order of elements in the data flow are accepted. Both Data flows of exa mples 1 and 2 are not order- change tole r ant, i.e., the order of trans mitted elemen ts nee ds to be maintained. Indeed, the order of s earch results is impor tant to the user, and the order of printed do cuments in also relev a nt to the printing W eb s ervice. In Exa mple 3, data flow is order-change tolerant, all the b ought items hav e the same priority and the pa yment order do es not affect the banking W eb service. The aforementioned three types of c o nstraints p ermit describing data flows along the following asp ects: (i) data sele ction attribute (b o olean) denotes whether sp ecific par ts of data can be selected, (ii) duplic ate attribute (bo o lean) denotes whether duplicate elemen ts a re toler ated in the data flow, and (iii) or dering at- tribute (b o ole an) deno tes whether the o rder o f the elemen ts must b e conserved. This classification of constra int s is particularly relev ant during the ca rdinality- mediation exe r cise (Section 4). Each attribute impacts the n um ber and orga ni- zation o f ele men ts that W eb services exc hange and the mediation to adopt p er t ype of c onstraint. 2.2 Data schema and constrain t represen tation T o highlig ht the cardinality issue in the definition of data sc hema, we follow the definition of a schema gr aph given in [9]. A schema gra ph is a la b eled directed graph with prop erty sets. In this graph, no des represent element types, edges represent relationships, and pr op erty se ts on no des o r edges describ e sp ecific XML feature s . In this pap er, we define a c onst r aine d schema as a sc hema gra ph with its cardinality constraint s des crib ed via prop erty sets, but w e remind that prop erty s ets also describe o ther XML features in the o riginal w ork [9]. Definition 1 (Co n s trained Schema). A co nstrained schema is a t u ple C S = h E T , R , s, t, P S i wher e: - E T is a nonempty finite s et of element t yp es; - R ⊆ ( E T × E T ) is a fi n ite set of r elationships; - s : R → E T is a function that indic ates the sour c e of a r elationship ; - t : R → E T is a function that indic ates the tar get of a r elationship; - P S : { E T ∪ R } × P → V is a function that r epr esents pr op erty sets, wher e P is a set of pr op erties and V is a set of values including the nul l value. In the c ontext of XML Schema, V = R ∪ S ∪ U ∪ { ∅ } wher e R , S , U ar e sets of r e al numb ers, strings, and user-define d lab els, r esp e ctively. Definition 2 (Cardinali t y Cons traint). A cardinality constra int k is a pr op- erty of a c onstr aine d schema C S = h E T , R , s, t, P S i , as afor ementione d. This pr op erty is asso ciate d with a r elationship r of C S and is define d as fol lows: - minCar d: minC ard ( r ) = i wher e i ∈ ℵ + ; - maxCar d: maxC ar d ( r ) = j wher e j ∈ ℵ + and i ≤ j . In the rest of this pap er, a cardinality constr aint on a re lation r ∈ R is de no ted as k r = [ i , j ]. 2.3 W eb service represe ntation W e simply r e present W eb se rvices a s bla ck b oxes accepting inputs and returning outputs. Additionally , we consider the p ossibility fo r a W eb service to b e inv oked several times and to r eturn a dditional r esults. Suc h invocation p os sibility can be exploited for the purp ose of cardinality mediation. Maxim um num b er of inv o cations. Inv oking a same W eb service several times ma y help gather additiona l da ta fo r the purp ose of car dina lity mediatio n. How ever, some W eb services cannot be indefinitely inv oked when participating in a co mp o s ition, for several reasons such as cost of the inv oca tion, real world mo difications, change of the W eb ser vice state, etc. F o r example, “a dd-to-car t” or “pay” op eratio ns of a shopping W eb ser vice must b e inv oked exactly once , as their e x ecutions make changes in the real world like up dating a customer ’s banking account. O n the contrary , s o me W eb services ca n be indefinitely in v oked without any c hanges in the e nvironmen t, suc h as random num b er generator W eb services. According to the characteristics detailed ab ove, we provide a definitio n of W eb services that includes all the relev ant a sp ects to cardinality mediation: Definition 3 (W eb service). A Web servic e W S along with r esp e ct ive c ar di- nality c onstr aints is define d as a t uple h w s, C S I n , C S Out , I nv max i wher e, – w s is the W eb service’s identifier. – C S I n and C S Out are the co nstrained schemas that define the schema and cardinality constraints on data input and data output of ws . – I nv max is the maxim um n um ber of allow ed in vo cations in the compos ition. F or the purp ose of cardinality mediation, we no tice d a s pe c ific category of W eb services that ar e indefinitely inv o c able and provide new data o n each in- vocation. These W eb services pr esent in teresting characteristics for car dinality mediation a s they allow gathering new data on each inv o cation and th us they can to a certain e x tent fulfill the cardina lit y constraints of other W eb services in c a se o f lack of data. W e qualify these W e b s e r vices as data pr oviders . Data provider W eb services include: (i) biological W eb service that s e nds pieces of DNA informa tio n, (ii) mathema tical W eb se r vices that generate rando m num- ber s, (iii) W eb services that give up-to-date infor mation on a patient (heartb eat, blo o d pressur e, e tc.), (iv) geog raphical lo calization W eb s ervices, (v) weather W eb services, etc. 2.4 Constrained comp o sition representa tion A constrained compo sition is r e presented as a com bination of W eb serv ices and data flows with sha r ed co nstraints. Indeed, tw o data flows connecting to the same W eb service share the constraint o n its maxim um n umber of inv oc a tions. Definition 4 (Co n s trained W eb services comp ositio n). A c onstr aine d Web servic es c omp osition C is define d as a set of Web servic es W S and data flows d f wher e a data flow is define d as a t uple h W S s , W S r , dup, sel , ord i , W S s is the sender Web servic e, W S r is the r e c eiver Web servic e, dup ex pr esses the t oler anc e to duplic ates, sel expr esses the p ossibility to sele ct data in the data flow, and ord denotes whether the or der of data elements mu st b e c onserve d. T o gra phically mo del a constra ined W eb services comp os ition and facilitate cardinality mediation, a lab eled directed g raph representation with prop erty sets is adopted (Fig. 2). In this g raph, W eb se rvices and data flows co rresp o nd to no des a nd edges, resp ectively . A W eb s ervice is represe nted by its constr ained input and output sc hemas a nd a pr op erty that describ es the maximum num b er of times it can b e inv oked in the comp osition. An edge has three constra ints resp ectively related to data selection, duplica tes and o rdering. In Fig. 2 a simple data flow be t ween W S 1 and W S 2 is represe nted. The prop er ties in this data flow are: data selec tio n is not allow ed, data or dering must b e conser ved, a nd data duplica tes ar e tolerated. Pro pe rties asso ciated with W eb se rvices ar e a s follows: E ditor W S 1 can b e invok ed at most o nce, and printing W S 2 can b e inv oked a s man y times as required. Fig. 2. Editor W S 1 sending out do cuments to printing W S 2 3 Classification of cardinality heterogeneities Let us consider the comp osition o f Fig. 2. W S 1 generates a list of elemen ts that comply with a c onstrained schema C S 1 out = ( E T , R , s, t, P S 1 out ) and W S 2 re- quires the r eception of elements that comply with a constr ained schema C S 2 in = ( E T , R , s, t, P S 2 in ). In such a comp osition, ca rdinality co nstraints compatibility consists in chec king out if the constraints P S 1 out and P S 2 in are compatible 1 . Given tw o cardinality constr aints k r 1 = [ i, j ] ∈ P S 1 out and k r 2 = [ m, n ] ∈ P S 2 in , r esp ectively asso ciated with C S 1 out and C S 2 in , differen t corr esp ondence cases can be iden tified as sho wn below: Case a. j < m : Guaranteed la ck of elements. T o b e executed, W S 2 needs at least m elements from W S 1 . How ever, W S 1 can return at most j elements, 1 W e remind the reader our work is limited to one coup le of constrain ts p er schema for simplicity purp ose. Fig. 3. Cardinality constra ints compatibility cas es which is less tha n needed. As a result, ther e is a lack of required elements to make a W S 2 inv o ca tion p os sible. Case b. i < m ∧ m ≤ j ≤ n : Poten tia l lack of elemen ts. A lack of elemen ts will only o c c ur if, at runtime, the num b er of data instances in the W S 1 result is smaller than the minimum n um ber of elements exp ected by W S 2 as a n input. Otherwise, cardinality constr aints P S 1 out and P S 2 in are compatible. Case c. i ≥ m ∧ j ≤ n : No cardinality cons traints compatibility . Case d. m ≤ i ≤ n ∧ j > n : Poten tia l o verabundance. When in vok e d, the W eb service W S 2 might r eceive more elements than needed. Ther e is therefore a po tent ial ov erabundance of elements when W S 2 is in v oked. Case e. i > n : Guaranteed overabundance. When inv oked, the W eb service W S 2 will receive more ele ment s than needed. Ther e is there fore a gua ranteed ov er abundance o f element s when W S 2 is in v oked. Case f. i < m ∧ j > n : Poten tial lack and ov er a bundance. Depe nding on the rea l nu m ber of elements o f the W S 1 result, a la ck or o verabundance of elemen ts might o c c ur as expla ined previously . T otal sa tisfaction of constr ained schema compa tibilit y only happ ens in ca se c. How ever, in the other cases , it is still p ossible to re c oncile car dinality constr aints of W eb ser vices by applying appr opriate mediation strategies. W e remind that cardinality mediation o ccurs at the ins tance lev e l. Then, we can group differen t schema-lev el hetero geneities in to common mediation cases. – Lack of elements: cases a and b, possibly case f. – Overabundance of elements: cases d and e, possibly case f. W e note that cas e f, dep ending on the a c tual num ber of instances sen t, ma y belo ng to the “lack of elements” situation, to the “overabundance of elements” situation. 4 Cardinalit y mediation for W eb services In this section, we rely on the theor etical framework developed pr eviously and prop ose a solutio n ba sed on constr aint logic to handle data ca rdinality in W eb services comp ositio n. First, we describ e the require ments of cardinality media- tion for a data flow, and show how these requir ement s apply b y extension to a comp osition ; second, we quickly introduce c onstraint log ic and show its rele- v ance for the pur p o se of describing the r equirements of cardinality mediation ; and third w e presen t the sets o f constraints we developed and show their appli- cability with a gr aphical data flo w sim ula tion implemen tation. 4.1 Requirements of cardinalit y me d i ation Cardinality mediation requires c omplex co mputations in o r der to adapt data flows betw een W eb services. In the following, we formally describ e the req uire- men ts for obtaining succe s sful cardinality mediation in a da ta flo w . W e identif y different situations dep ending on the duplic ate toler ant a nd data sele ction tol- er ant constra ints on the data flow, and ex plain how the o rdering constra int is dealt with. In o rder to demo nstrate the r equirements of cardinality mediation, we con- sider a da ta flow b etw een t w o W eb ser vices W S 1 and W S 2 , with structur ally matching constra ined schemas C S 1 out and C S 2 in . C S 1 out holds a constra int k r 1 = [ a, b ] and C S 2 in holds a constraint k r 2 = [ x, y ]. W e a lso define the num - ber of inv o c ations m and n of W S 1 and W S 2 resp ectively . [ a, b ] and [ x, y ] are int erv als that represe nt the p ossible num ber of instances that can b e obtained on one invocation of W S 1 and W S 2 resp ectively , and the o p erator ∗ applies to these interv a ls as follo ws: m ∗ [ a, b ] is equiv alent to [ m ∗ a, m ∗ b ] to represent the nu m ber of instances that can b e o btained after m inv oca tions of a W eb service. Duplicate toleran t/data sel e ction untoleran t data flo ws. L et us conside r that the a forementioned da ta flow is duplicate toler ant and data selection un- tolerant, with k r 1 = [9 , 11] and k r 2 = [6 , 8] 2 . At first sight, k r 1 cannot meet the cardinality constr a ints of k r 2 . Indeed, a firs t call to W S 1 binds k r 1 to [9 , 1 1] a nd a second call to W S 1 binds k r 1 to [18 , 2 2 ], a nd both do not match k r 2 . How ever, we notice that three inv o ca tions to W S 2 bind k r 2 to [18 , 24 ]. Then, a reconciliation betw een W S 1 and W S 2 is poss ible if W S 1 is in v oked twice and W S 2 is invok e d three times, as in this case k r 1 ⊂ k r 2 . Hence, the num ber o f elements required by W S 2 is provided by W S 1 . By extrap olatio n, we devis e when a cardinality mediation for this t ype of da ta flow is probably succes sful when: ∃ m, n ∈ ( N + ) 2 such that ( m ∗ [ a, b ]) ∩ ( n ∗ [ x, y ]) 6 = ∅ . 2 Such cardinality constraints are improbable but they illustrate the complexity of cardinalit y mediation and show that our solution is applicable to any couples of constrain ts. This situation bec o mes mor e and more unlikely to happen as n grows and as ( m ∗ [ a, b ]) ∩ n ∗ [ x, y ] beco mes small. Accordingly , cardinality mediation for this t ype of da ta flow is certa in to b e successful when: ∃ m, n ∈ ( N + ) 2 such that ( m ∗ [ a, b ]) ⊆ ( n ∗ [ x, y ]), which means that m and n verify the following condition: x a 6 m n 6 y b . W e remind that suc h condition applies to duplicate tolera nt and data selection un- tolerant da ta flo ws o nly . Duplicate toleran t/data selectio n tole rant data flo ws. Duplicate and data selection tolera nt data flows need ca lling W S 1 as many times as required to exceeding the minimal cardina lity require d by W S 2 , and then select elements depe nding on the users’ selection p olicy (the “sele ct” op er a tion is detailed b e- low). The forma l representation is trivial and is: ∃ m ∈ N + such that ( m ∗ a ) > x , Duplicate un toleran t/data selection unt oleran t data flo ws. In duplicate un tolerant data flows the nu m ber o f duplica tes in a messa ge par t is undeter- mined. Hence, the n umber of unique elements con tained in a messa g e part may v ary b e t ween 0 and the maximum num ber of elements. On a single run of W S 1 , the num b er o f unique elements contained in C S 1 out is b ound b etw e e n 0 and n ∗ b . As duplicate detec tio n and remo v al a pplies to the instance level, it is not possi- ble to determine a priori whether o r not cardinality mediation will b e succes s ful. How ever, it is p ossible to descr ib e it at run time. Being given i the num b er of da ta instances returned by W S 1 and a function f that r e mov e duplicates, cardinality mediation for a data selection un tolerant, duplicate untoleran t data flow s uccessful when: ∃ n ∈ N + such tha t f ( i ) ∈ ( n ∗ [ x, y ]). Duplicate un tol e ran t/data s election toleran t data flows. Accordingly , if data selection is allow ed, then cardina lit y media tio n is successful when: ∃ n ∈ N + such that f ( i ) > ( n ∗ x ). Ordering on data flows. It is no t p oss ible to determine or der-change tolera nce without the interv en tion o f the co mpo sition designer. Then, the data order ing is left to the user via a n user interface that interacts with the user if necessa ry . If the data flow supp o rts unordered lists, the cardina lit y mediator simply concatenates data elements. If o rdering is imp ortant, alternative strategies ar e pro po sed to the user (concatenation of results, mixing of results dep ending on an algorithm, or manual or dering). Application to a comp ositi o n. In this section, w e presented the requir ements of a co mpo sition for one data flow. Indeed, these requirements can b e scaled up to a comp ositio n. In such case, num ber s of inv o cations m , n , cardina lit y co nstraints [ a, b ], [ x, y ] a r e shared b etw een several data flows. Such situations reduces the nu m ber of pos sibilities of the comp osition to succeed, how ev er it simplifies the resolution of cardina lity requirements a s it provides a unified v iew of the whole business pro cess with all the cardinality constra ints. 4.2 Constrain t logi c for cardinality mediation It turns out that constraint lo g ic programming is well-suited for mo delling car- dinality mediation. More precisely , constraint logic progra mming ov er finite do- main v ariables allows to sp ecify constr aints o ver these v ariables and to use these constraints in an a pr iori wa y to reduce the s earch space. The res ulting fra mework is quite elegant since, on the one hand, it conse r ves the dec larative ex pr ession of logic pr ogra mming, including the m ulti-dir ectionalities of its quer ies, and, on the other hand, it in tegrates an efficien t w ay of solving constraints. This is v ery app ea ling in our car dina lity media tion co nt ext. F or instance, the following predicate basic mediation ( A, B , X , Y , M , N , D , S ) a ims a t determining whether there are M , N such that M * [A,B] is a subset o f N * [N,M] for a duplicate toler ant and data selection untolerant data flow. Such predicate describ es the constraints we devised: basic_ media tion(A,B,X,Y ,M,N,Mmax,Nmax,D,S) :- fd_dom ain([ M],1,Mmax), fd_dom ain([ N],1,Nmax), N * X #=<# M * A, M * B #=<# N * Y, fd_lab eling ([M,N]). The couples A, B and X , Y represent the ca rdinality constraints of r esp ec- tively W S 1 and W S 2 , M , N a r e the n um b er of in vo cations o f W S 1 and W S 2 to be found, M max a nd N max their max imum num b er of p ossible in v o c ations, D and S ar e bo o leans that describe duplicate tolerance and data selection resp ec- tively . The co de first defines the in terv als [1..Mmax] and [1..Nmax] as finite domains for the v aria bles M and N a nd then sp ecifies the cons tr aints as given befo r e, with the symbols # =<# indicating the less than equal rela tion. Finally , the f d l abel ing predicate is used to sta rt an exhaustive search but by firs t fixing a v alue for M, then b y propa gating this v alue in the co nstraints to reduce the domain of N and finally b y searching in the reduced domain N for a v alue. An ex a mple is worth to capture wha t this means. Let us c o nsider tw o W eb services that hold [9, 1 1] and [6, 8] as ca rdinality constraints. The corr e s po nding query is basi c media tion (9 , 11 , 6 , 8 , M , N , 10 , 10 , true , f alse ). Th us the domains of M and N are b o th limited to [1..1 0]. Then M is fixed to 1 and the co nstraints bec ome N ∗ 6 6 9 and 11 > N ∗ 8. All the p ossible v alues o f N a re then sear ched but ther e is no in teger v a lue of N that is co mprised b etw e en 11 / 8 a nd 9 / 6. Then M is fixed to 2 and the constraints b ecome N ∗ 6 6 1 8 and 22 > N ∗ 8. In such case, N = 3 is co mprised betw e en 22 / 8 and 18 / 6. Hence, the first solution returned by the P r olog eng ine is the couple of v alues ( M = 2 , N = 3). O ther solutions are p ossible but they req uir e additional in v o cations of W S 1 or W S 2 , th us the first solution is the most in teresting one. 4.3 Implementation W e developed a pro of-of-co ncept proto t yp e to ol that simulates a data flow b e- t ween W eb s ervices and shows the p os s ibilities offered by our cardinality me- diation appr oach (Figure 4). This pro totype to ol re lies on Jav a platform, and connects to a Pro log reasoner that contains car dinality mediatio n functions en- co ded as shown in the ab ov e. Our Jav a program is a client application and the Prolog engine is curr e ntly deploy ed in a W eb server as a CGI pr ogra m that relies on GNU Pro log [5]. The Jav a pro gram is actually a CGI client and user fro n- tend, its per fo rms the CGI calls and in teracts with the end- user. The mediation pro cess is p er formed b y the Prolog engine, it dep ends on the cons tr aints on W eb services and data flow entered via the interface. Our solution o p e r ates as follows: for ea ch da ta flow, the end- user feeds a Prolog engine with the different constr aints on W eb serv ices a nd data flow via our g raphical interface. Then, the Prolog engine calculates the po ssibilities to obtain a successful result and selects the bes t result if found. The constraints are a priori requir e d and the use r needs to provide them be- fore r unt ime. These are the constraints on the maximum n umber of executions for W S 1 and W S 2 , to gether with the constr a ints o n data flow (Data selection, duplicates and ordering), which are descr ib ed neither in typical (WS-BPEL) business pro cesses nor in typical W eb ser vice descriptions (WSDL). W e are cur- rently working on a W eb servic e comp os ition platfor m that connects to our cardinality mediation simulator and feeds it with the comp osition parameters , in order to apply our constraint-based reas o ning to the whole compo s ition. Cardinality media tion inv olv es different op er ations on data flows. W e defined the following o p er ations: – sel ect ( O , str ateg y ) selects particula r elements of the result set O dep ending on a us er selection str ategy (first elements, each t w o elements, last elements, manual selectio n. . . ) – mer g e ( O 1 , O 2 , str ateg y ) merges lis ts of r esults O 1 and O 2 depe nding on a user merging strategy (conca tenate elemen ts o f the second call to the firs t, mix each t wo elemen ts, concatenate elements of the first call to the seco nd, manual merg ing. . . ) – rm dup ( O , stra teg y ) removes all the duplicates in O acco rding to a user selection strategy (remov e fir s t duplicate first, remov e last duplicate first). These op era tio ns are per formed with the help of the user via the g r aphical int erface. Fig. 4. Screenshot of the data cardinality mediation simulator 5 Conclusion In this pa pe r, w e s hed the light on a n imp o r tant issue that could refrain the smo oth progr ess of s ervice comp ositio n scenarios if not address ed pro p erly . This issue, which we referred to as cardinality heterog eneity , s tresses out the im- po rtance of quantifying the data that W eb ser vices engag ed in these scenario s exchange. L ittle resear ch work has been done to address this issue. In this pap er, we pr op osed a classification of cardinality heter ogeneities a nd highlighted for ex - ample how a W eb service could be ov e r loaded with data that it migh t not need, and ho w la ck of e x pe c ted data could degrade the W eb serv ice compo stition. A constraint logic-based ca rdinality media tion a ppr oach is pro p o sed. It aims to adapt data flows b etw een W eb services by consider ing the req uirements of b o th data flows in terms of toler a nce to duplica te, selection and or dering, and W eb services in terms of n um ber of allowed inv o ca tions and constrained sc hemas. As a future work, we intend to study ho w different hetero geneous web s ervices providing a same functiona lit y could be combined to cov er the car dinality con- straint of a service. A W eb services communit y-based approa ch could b e ado pted. W e a r e also interested in handling data cardinality of web services in the context of data pr iv acy where some da ta might b e hidden or shown depending on the existing priv acy p olicies. References 1. W ordnet definition. http://wo rdnet.pri nceton.edu/perl/we bwn?s=cardinality . 2. D. Bo x , D. Eh nebuske, G. Kakiv aya, A. La yman, N. Mendelsohn, H. F. Nielsen, S. Thatte, and D . Winer. Simple ob ject access proto col (SOAP) 1.1. T echnical rep ort, The W orld Wide W eb Consortium (W3C), 2000. http://www .w3.org/T R/SOAP/ . 3. E. Christensen, F. Curb era, G. Meredith, and S. W eeraw arana. W eb Services Description Language (WSDL) 1.1, W3C N ote. T echnical rep ort, The W orld Wide W eb Conso rtium (W 3C), Marc h 2001. 4. F. Curb era, Y. Goland, and J. K. et al. Business Pro cess Execution Language for W eb Services (BPEL4WS) V ersion 1.1, Ma y 2003. 5. D. Diaz and P . Cod ognet. Design and implementation of the gnu prolog system. Journal of F unctional and L o gic Pr o gr amm ing , 2001 (6), 20 01. 6. R . Fielding, J. Gett ys, J. Mogul, H. F rystyk, L. Masin ter, P . Leach, and T. Berners- Lee. Hyp ertext transfer protocol – HTTP/1.1, 1999. 7. A. Gal. On the cardinality of sc hema matching. In S. LNCS, editor, O n the Move to Me aningful Internet Systems 2005: OTM Workshops , pages 947–956. Springer LNCS, 2005. http://www.springerli nk.com/con tent/8 371xt8xek05h9t0. 8. M. Nagara jan, K. V erma, A. P . Sheth, J. Miller, and J. Lathem. Semantic inter- operability of w eb services - challenges and exp eriences. In ICWS , pages 373–382. IEEE Computer Society , 2006. 9. M. Smiljanic, M. v an Keulen, and W. Jonker. D efining the xml schema matching problem for a p ersonal sc h ema b ased q uery answering sy stem. T echnical rep ort, Universit y of Tw en te - CT IT, 200 4. 10. udd i.org. U DDI T echnical White Paper. http://www .uddi.org/, 2003. Visited August 2003. 11. W3C. XML Schema P art 2: Datatypes Second Edition. T echnical rep ort, W3C, Octob er 2004. http://www.w3 .org/TR/xmlsc hema-2/.