RDBMS for Service Repository and Matchmaking

Deepak ChenthatiTeradata(R&D) India Pvt Ltd

Hyderabad, Indiachvcdeepak@gmail.com

Hrushikesha MohantyDepartment of CIS

University of HyderabadHyderabad, India

hmcs hcu@yahoo.com

Avula DamodaramDepartment of CSE

JNTUH, Hyderabad,Indiadamodarama@gmail.com

Abstract—Web Services is an upcoming technology in thecurrent Internet revolution. Web Services have a potentialto enhance Business to Business collaboration by composingcompatible services to a service of higher dimension. Twoservices are composable only if there is a matching betweentheir conversation protocol. For modeling and matching ofconversations, the usability of formal structure like Finite StateMachine (FSM) is well studied. However, we are in a opinionthat storing, matchmaking and retrieving FSMs using graphstructure is not scalable for representing conversation protocolfor thousands of web services that will soon be available on web.In order to cope up with the challenge we propose relationalmodel to store FSMs and a query system to retrieve servicesthat are matching to a given service.

Keywords-webservice, RDBMS, matchmaking

I. INTRODUCTION

Web Services have a potential to enhance B2B collabora-tion by integrating compatible services to a service of higherdimension. For service composition, matching of conversa-tion protocols of participating services is required. This cangive rise to new business norms with which all categories oforganizations (particularly small and medium organizations)can get opportunities to reach out by publishing servicedetails on web to customers and to form a consortium foroffering complex services.

Some repositories like UDDI (Universal Description, Dis-covery and Integration) [4] exist for publishing and discover-ing of web services which enhance the service composition.Service Composition can be done by orchestrating existingservices into a new service that implements a businessprocess. A business process involves a sequence of mes-sage exchanges (i.e., flow of messages) among constitutingservices (choreography). So, search of services not onlyhave to ensure exchange of identified messages but alsoshould agree with sequence of message transactions amongcomposing services. For this modeling of business process-communications and business logic, is required. Variousapproaches e.g. EPC, Petrinet, UML have been proposed forspecifying a web services and their compositions. We foundthat FSM is being studied actively for modeling web servicesespecially it is being used to model web choreography toensure that a web service is communicating successfullywith its collaborating services.

II. SURVEY

FSM[3][8] has been used to model and match conversa-tion protocols. However, we are in a opinion that storing,matchmaking and retrieving FSMs using graph structureis not scalable for representing conversation protocol forthousands of web services that will soon be available on web.In order to cope up with the challenge we propose relationalmodel to store FSMs and a query system to retrieve servicesthat are matching to a given service.

A very recent work [7] deals with the problem weaddress here. The authors view composability of services in-terms of matching their input and output parameters. Twoservices match when one’s output parameters match withinput parameters of the other. While matching, they haveused semantic similarity based in WordNet. Service inputoutput parameters are stored in databases. Being soft insemantic matching, we may get several services matchingwith a given service but at different degrees. The matchingresult is represented in a directed graph. Where an edgeconnects two matching services and the label of the edgenotes the degree of matching. Then the service compositionproblem is seen as shortest path finding problem. Other thanthat QoS is also considered in deciding weight of an edge.Shortest path finding algorithm is modified to operate onrelational repository of service data.

Our work is distinct from [7] by taking message trans-actions into consideration. We argue, for work-ability ofa composed service matching of their message communi-cations is important. In-spite of input output matching, acomposition will fail to match in case of their mismatch incommunication. While matching we consider the sequenceas well as importance of messages (defining types likecompulsory and optional). Alike [7] we have used relationaldatabase to store communication details in order to make thetechnique scalable. Message communications of each serviceare recorded in databases and matching of two servicesis performed by joining of two tables. The join operationis relaxed to provide results of kinds of matching FullMatch, Partial Match and No Match. We have also discussedpossible implementation of the proposed technique. We viewour technique along with the technique proposed in [7] will

2011 Second International Conference on Intelligent Systems, Modelling and Simulation

978-0-7695-4336-9/11 $26.00 © 2011 IEEE

DOI 10.1109/ISMS.2011.53

300

2011 Second International Conference on Intelligent Systems, Modelling and Simulation

978-0-7695-4336-9/11 $26.00 © 2011 IEEE

DOI 10.1109/ISMS.2011.53

300

give precisely workable service composition.Rest of the paper is organized as follows. Section 3

illustrates FSM based approach for modeling service com-munication and matching of compatible services for servicecomposition. Section 4 gives a new approach that describesRDBMS schema to store services and its communicationprotocol. Also this section presents a new matching algo-rithm and explains it with an example. Section 5 givesthe analysis of algorithm and simulation results. Section 6describes the way RDBMS is embedded into the currentlyavailable jUDDI architecture and how it is used for matchingof services to compose a larger service. Section 7 concludesthe paper.

III. SERVICE COMPOSITION AND MATCHING

A service has business logic driven by business commu-nication. In [3] we have shown how both can be modeledby FSM. Here, we are only interested in modeling businesscommunications by FSM as shown in Figure 1. Each nodeindicates a state and an edge for communication. A labelon edge follows a format sender#receiver#message details.Figure 1 specifies two services name Book store and Ship-ping and the chain of events follow from ordering of bookto shipping it are as follows:

Let us consider the example of Ordering a Book processin an electronic book store. The chain of events will be asfollows:

1) Customer(c) Requests for a Book in e-Book store (bs).2) Book store sends availability confirmation to customer

if book is available else it says Unavailable to cus-tomer.

3) Customer places an order for the book.4) Book Store responds with make payment message.5) Customer makes payment.6) Book Store sends the payment confirmation.7) bs interacts with shipping service provider (s) with a

request for shipping message.8) The shipper replies to bs with availability information

if shipping is available to that particular location.9) Then bs puts a message to Deliver the book.

10) On receiving Delivered message bs chooses any oneof the modes of payment (Credit Card) CCPaymentand (Debit Card) DCPayment.

11) Shipper sends a payment confirmation message onreceiving the payment.

12) Book Store sends Book Delivered message to cus-tomer.

The aim of this paper is to identify service partnerswhose message exchange sequence matches that of therequesting service. From the figure we see that the BookStore service communicates with consumer and shipper.Here shipper is the service collaborator with whom BookStore service collaborates. The states that are darkenedinvolve communication with that of shipper. Now the aim

is to find the shipper service whose message flow matcheswith that of the Book Store service. Figure 1 shows the

Figure 1. AFSM representation for ”Book store” and ”Shipping” services

AFSM representation of Ordering a Book process. Here bs#c# Avail Conf, c# bs#Order Book, bs# c # Make Payment,bs# c # Pay Conf and c# bs # Book Delivered and c#bs#Payment are mandatory messages bs #s #CCPayment andbs#s#DCPayment are optional messages.

A match between two FSMs is said to have occurred ifand only if there exists a non-empty intersection betweenthe two corresponding FSMs. For non-empty intersection,first we will do intersection operation on two FSMs, thenwe will perform emptiness test on the resulted intersectedFSM. If emptiness test fails (i.e., FSM is accepting somestring of messages), then it indicates that there is a pathfrom start state to final state in that intersected FSM. So, wesay that two FSMs are matched. Drawback of FSM basedmatchmaking is that storing, matching and retrieving FSMsusing graph structure is not scalable when there are hugenumber of services that are available on the web. Hence, welook for relational repository for this purpose.

IV. A PROPOSED SCALABLE APPROACH

Relational databases has been successful in maintainingand accessing large repository of information. For this

301301

problem, we resort to the same technology to store FSMs foreach service and to perform matching required for servicecomposition.

B u s i n e s s E n t i t ye - m a i l

B u s i n e s s K e y

B u s i n e s s N a m e

p h o n e

F a x

U R L

P r o v i d e s B u s i n e s s S e r v i c e s

S e r v i c e K e y

B u s i n e s s K e y

C a t e g o r y

S e r v i c e N a m e

D e s c r i p t i o n

S e r v i c e M e s s a g e

F l o wD e s c r i b e s

S e r v i c e K e y

m s g f o l l o w e d B y M s g

s n d _ r c v

t y p e

C P a r t n e r

Figure 2. E-R Diagram

A. Service Repository

In the literature, a way of storing web service detailsand its ontologies using Relational Database was proposed[2]. But it had not taken the message flows into concern.So, we have proposed an RDBMS schema for storing notonly messages but also the sequence of communications.Figure 2 shows the E-R diagram of the proposedschema. From the figure, we can observe that a singleBusinessEntity can provide many BusinessServices and forevery BusinessServices there is a corresponding descriptionabout its ServiceMessageFlow. We have also proposed theRequestorMessageFlow table which specifies the format acustomer has to send his/her request.BusinessEntity:A given instance of the BusinessEntityis uniquely identified by a BusinessKey. Simple textualinformation about the BusinessEntity is given by its nameand contacts like e-mail, WebURL.BusinessServices: A given BusinessServices entity isuniquely identified by its ServiceKey. The BusinessKeyattribute uniquely identifies the BusinessEntity which is theprovider of the BusinessService. Simple textual informationabout the BusinessServices is given by its name and shortservice description and its Category.ServiceMessageFlow: A given instance of ServiceMes-sageFlow is uniquely identified by its ServiceKey, msgand followedByMsg. This table stores the message flowof services. Type of message, optional or mandatory, isspecified by its type field. snd rcv field specifies whetherthe message is a sent by customer or received by customer.RequestorMessageFlow: A given instance ofRequestorMessageFlow structure is uniquely identifiedby its msg and followedByMsg. The table has the messageflow of a requested service, which can be given externallyor can be generated from the ServiceMessageFlow table.Now, we can summarize the tables in the proposed RDBMSschema as follows.

BusinessEntity(BusinessKey, BusinessName, Phone, Fax, e-mail, URL)Provides(BusinessKey, ServiceKey)BusinessServices(ServiceKey,BusinessKey,ServiceName,Description,Category)Describes(ServiceKey, msg, followedByMsg)ServiceMessageFlow(ServiceKey,msg,followedByMsg,snd rcv,type,CPartner)RequestorMessageFlow(msg, followedByMsg, snd rcv, type)

Table ISERVICEMESSAGEFLOW

sk msg followedByMsg snd rcv type CPart1 Req Book NULL receive man cust1 Avail Conf Req Book send man cust1 Order Book Avail Conf receive man cust1 Make Payment Order Book send man cust1 Payment Make Payment receive man cust1 Pay Conf Payment send man cust1 Req Shipping Pay Conf send man shipper1 Ship Avail Req Shipping receive man shipper1 Deliver Item Ship Avail send man shipper1 Delivered Deliver Item receive man shipper1 CCPayment Delivered send man shipper1 DCPayment Delivered send man shipper1 Ship Pay Conf DCPayment receive man shipper1 Ship Pay Conf CCPayment receive man shipper1 Book Delivered Ship Pay Conf send man cust2 Req Shipping NULL receive man cust2 Ship Avail Req Shipping send man cust2 Deliver Item Ship Avail receive man cust2 DCPayment Deliver Item receive man cust2 Ship Pay Conf DCPayment send man cust3 Req Shipping NULL receive man cust3 Ship Avail Req Shipping send man cust3 Deliver Item Ship Avail receive man cust3 Delivered Deliver Item send man cust3 DCPayment Delivered receive man cust3 Ship Pay Conf DCPayment send opt cust

Considering the same example Ordering a Book from sec-tion 3. Fig. 1 shows the FSM with annotations and Table Ishows the schema representation of the corresponding FSMfor Book Store with ServiceKey (SK) as 1. We propose 6column table; Where msg is the message for communication,followedByMsg is the previous message which was received,snd rcv gives the detail if message is sent or received,thereare two types of messages ’mandatory’ (man) and ’optional’(op), Communication Partner (CPartner) gives the partnerdetails with whom the service collaborates. ServiceKey’s sk2and sk3 are two variants of shipping processes.Let us take a look at the first row. Here, followedByMsg isNULL because there is no preceding message to Req Bookmessage.

302302

Algorithm MATCHInput: servicemessageflow and ServiceKey(skey) tables,req categoryOutput: servicename and type of matchAlgorithm

1: match()2: {3: Build RequestMessageFlow Table4: cnt← number of tuples in bussinessservices

where category = req category;5: while cnt>0 do6: sk ← bussinessservices.servicekey;

{For each service with unique sk}7: create temporary table t1 where service message-

flow.ServiceKey= sk;8: create another temporary table t2 where msg and

followedByMsg of t1 and RequestorMessageFlow areequal which is full outer join table.

9: full, partial← 0;10: ct← numberoftuplesint2;11: m1,fm1,sr1,ty1,m2,fm2,sr2,ty2← t2(msg1,

followedbymsg1,snd rcv1, type1,msg2,followedbymsg2,snd rcv2, type2);

12: while ct>0 do13: if ((sr1=’send’ and sr2=’receive’) or (sr1=’receive’

and sr2=’send’)) then14: if (m1==m2 and( fm1==fm2 or (fm1=NULL or

fm2=NULL)) then15: if (ty1=’man’ or ty1=’op’) and (ty2=’man’ or

ty2=’op’) then16: full← 1;17: end if18: end if19: else if (fm1=fm2) then20: if (m1 != NULL and m2 == NULL) then21: if (ty1=’man’ and ty2=’opt’) then22: partial ← partial +123: else if (ty1=’opt’ and ty2=’opt’) then24: full ← 125: end if26: end if27: if (m1 == NULL and m2 != NULL) then28: if (ty1=’opt’ and ty2=’man’) then29: partial ← partial +1

full ← 030: else if (ty1=’opt’ and ty2=’opt’) then31: full ← 132: end if33: end if34: if (m1!=m2) and m1!= NULL and m2 != NULL)

then35: if (ty1=’man’ or ty1=’opt’) and

(ty2=’man or ty2=’opt’) then36: partial ← partial +1

full ← 037: end if38: end if39: end if40: if ((m1==m2) and (fm1!=fm2)) then41: partial ← partial +142: full ← 043: end if44: if (m1=NULL and fm1=NULL) and (m2!=NULL

and fm2!=NULL) and (ty2=’man’) then45: full ← 046: end if47: if (m1!=NULL and fm1!=NULL) and (m2=NULL

and fm2=NULL) and (ty2=’opt’) then48: full ← 049: end if50: ct ← ct -151: increment one tuple in t2;52: end while53: if ( full=1 and partial =0) then54: Print ServiceName, ”Exact Match”;55: else if ( full=1 and partial>0) then56: Print ServiceName, ”Partial Match”57: else58: Print ServiceName, ”No Match”;59: end if;60: cnt ← cnt-1;61: increment one tuple in BussinessServices;62: end while63: }And rcv value is receive because BookStore(bs) is receivingthat message from customer(c) type is set to mandatory.Similarly all the remaining rows in that table are inserted.Number of rows in a table is equal to the number ofmessages in FSM. Messages CCPayment and DCPaymentare entered into table as optional because, by default if a non-annotated FSM state has two or more messages emergingfrom it, that messages are treated as optional.

B. Service Matching Algorithm and Analysis

By looking at the example table given in section 4, wehave observed that a single services message flow spansover multiple rows in a relational table. So, it is notpossible for any type of query in RDBMS to perform matchoperation between two such multiple row spanned messageflow sequences. So, we have proposed an algorithm formatchmaking of web services based on above defined tables.This algorithm is also implemented as a stored procedure inMySQL. After matching process is completed, a service fallsinto one of the three categories namely Exact match, Partial

303303

match and No match.In case of exact match, all the messages of both serviceprovider and requestor message flow sequence matchestotally (or) some optional messages of requestor messageflow sequence may not be present in message flow sequenceof service provider. In case of Partial match, some messagesof service provider message flow sequence dont have corre-sponding messages in requestor message flow sequence.Incase of no match, no messages of service provider andrequestor match (or) some mandatory messages of requestormessage flow sequence dont have corresponding messagesin service provider message flow sequence.Looking into the steps involved in the proposed matchingalgorithm. Line numbers at the end of each step refers tothe part of algorithm which is performing that particularstep.

1) RequestMessageFlow table shown in Table II is cre-ated from ServiceMessageFlow table which has thesame ServiceKey as given input and whose CPartneris same as req Category.

2) Temporary table is created for a service from Ser-viceMessageFlow that has matched Category withrequestors category. (Line 7,8)

3) Another temporary table is created by doing a fullouter join operation on the above obtained table andRequestMessageFlow table based on their msg andfollowedByMsg.

4) For each message(row or tuple), if for each send typeof message there is receive type of message with theprovider service or vice-versa then if the attributesmsg, followedByMsg of both(service provider and re-questor) in the above full outer join table are equal andif that is the first message the followed by messageswould be null this check is performed and full is setto 1. (Lines 13-15)

5) For the messages whose previous messages matchdifferent conditions are checked. (Line 19)

6) If both message types are equal (or) if service providerhas mandatory message corresponding to optionalmessage of requestor then set full to 1. (Lines 20-26)

7) If there is no message in requestor for the correspond-ing message in service provider then for mandatorymsg of provider partial is incremented else fullis setto 1 (Lines 20-25)

8) If there is no message in provider for a correspond-ing message in requestor if the type of requestor ismandatory partial is incremented and fullis set to 0.(Lines 27-29) It is given partial as there is scope fornegotiation. If type is optional then full is set to 1.

9) If there is mismatch in messages then the partial valueis incremented and full is set to 0.

10) Now, if full is 1 and partial is 0 then the services are’Exactly Matched’ else if full is 0 and partial >0

then they are ’Partially Matched’ else they are ’NotMatched’. (Lines 53-59)

11) Repeat the above steps for all services that are matchedwith requestor category. (Lines 5-60)

V. SIMULATION & ANALYSIS

Let us again consider the same example of Ordering aBook service. The following Table 1 and Table 2 showstwo tables: one is ServiceMessageFlow table containingthree services ( Assuming that only these three services areavailable and all of them belongs to same category), andother one is RequestorMessageFlow table. Let us analyzethe matching process of service 2 message flow with re-questor message flow. Full outer join table of service 2 andRequestorMessageFlow tables is shown in Table III

Table IIREQUESTMESSAGEFLOW

msg followedByMsg snd rcv typeReq Shipping Pay Conf send man

Ship Avail Req Shipping receive manDeliver Item Ship Avail send man

Delivered Deliver Item receive manDCPayment Delivered send manCCPayment Delivered send man

Ship Pay Conf DCPayment receive manShip Pay Conf DCPayment receive man

Initially, full and partial are set to 0. First three mes-sages(rows) of service sk2 exactly matched with that ofrequestor messages. line 14-18 of algorithm handles it. Fromthe join table shown in Table III, There is a mis match in thefourth message of sk2 and from the join table we can observethat the followedByMsg’s are different where as the msg’sare same. Since there is a skip in the message exchangeboth the services can negotiate hence lines 41-42 will setthe value of full to 0 and increment the partial value. Againthere is match in the fifth message hence full is set to 1 butpartial value is greater than 0 hence its a Partial Match. Fewmessages that are specified in the provider service may notbe present at the requestor’s end, and both the requestor andprovider can negotiate and agree upon the missing message.

In this way our matching algorithm performs matchingof each service in ServiceMessageFlow table with the Re-questorMessageFlow table. Similarly, according to the abovegiven algorithm, sk3 matches exactly with requestors oneand sk2 has partial match with requestors one. Due to thespace constraint we have not presented all the cases. As wetold earlier that we have implemented the above algorithmas a stored procedure in MySQL, the way of calling it is asfollows: call match();

VI. A NEW FRAMEWORK

Some organizations have already implemented UDDI[4]depending on their requirements. One of them is jUDDI[6],

304304

Table IIIFULL OUTER JOIN TABLE FOR SERVICE2

SKey msg followedByMsg snd rcv type msg followedByMsg snd rcv type2 Req Shipping NULL receive man Req Shipping Pay Conf send man2 Ship Avail Req Shipping send man Ship Avail Req Shipping receive man2 Deliver Item Ship Avail receive man Deliver Item Ship Avail send man2 DCPayment Deliver Item receive man DCPayment Delivered send man2 Ship Pay Conf DCPayment send man Ship Pay Conf DCPayment receive man2 Ship Pay Conf DCPayment send man Ship Pay Conf CCPayment receive man2 NULL NULL NULL NULL CCPayment Delivered send man2 NULL NULL NULL NULL Ship Pay Conf CCPayment receive man

Q u e r y

S e r v i c e

C o m p o s e

S e r v i c eP u b l i s h

S e r v i c e

M a t c h i n g A l g o r i t h m

b a s e d o n R D B M S

S e r v i c e

D BS e r v i c e

C o m m n

m s g f l o w

D B

Figure 3. Extended jUDDI Architecture

which is developed by Apache group and it is open source.We have extended this jUDDI by means of adding Servicecommunication message flow Database and Matching algo-rithm based on RDBMS as highlighted in Figure 3. As wetold earlier, Service communication message flow Databasestores the message exchange sequences of all services thatare registered in UDDI. This database is used by our newlyproposed matching algorithm.

A. jUDDI Exension

Now, the overall architecture of jUDDI can be describedas follows. Three functionality’s are primarily provided byjUDDI namely a) Publish Service b) Query Service andc) Compose service. Service Providers publish their detailsinto the Service Database and their message flow sequencesinto Service Communication message flow Database. Theservice requestors which requires a service places a query byspecifying the type of service it wants. This query is handledby UDDI normally with serviceDB. The service requestorsthat requires service composition sends its required messageexchange sequence (which is stored in the specified tables)also along with type of service. This is handled by matchingalgorithm component and returns the resulted set of matchedservices by interacting with both Service Database andService communication message flow Database components.

VII. CONCLUSION & FURTHER WORK

This paper has proposed a new scalable approach formatchmaking of web services based on Relational Databasemodel by taking communication message flow of servicesinto consideration. Service communication is modeled inFSM and then protocol details are extracted to store inRDBMS and queried for finding matches(of different de-grees) We have extended the open source jUDDI by addingthe new matching algorithm as well as message flowdatabases. As an extension to this work, we would liketo give the percentage of match for each matched service.Currently we are working on an algorithm in RDBMS forrecursive matching of web services.

REFERENCES

[1] Andreas Wombacher, Peter Fankhauser, Bendick Mahleko,Erich Neuhold : ”Matchmaking for Business Processes basedon Choreographies”. In Proceedings of the IEEE InternationalConference on e-Technology, e-Commerce and e-Service,Taipei, Taiwan, pages 359-368,28-31 March (2004)

[2] Ruiqiang Guo, DongDong, Jiajin Le, Discovery for Web Ser-vices based on Relationship Model, In Proceedings of the6th International Conference on Computer and InformationTechnology, Korea, pages 253-259, September (2006)

[3] Hrushikesha Mohanty, Deepak Chenthati, Supriya Vaddi, andR. K. Shyamsundar. 2008. HUMSAT for State Based WebService Composition. In Proceedings of the 2008 InternationalConference on Information Technology (ICIT ’08). IEEE Com-puter Society, Washington, DC, USA, Pages 273-278.

[4] UDDI Version 3.0.2 from http://uddi.org/pubs/uddi v3.htm

[5] WSDL Version 1.1 from http://www.w3.org/TR/wsdl.

[6] jUDDI from http://ws.apache.org/juddi/.

[7] Efficient Web Service Composition and Intelligent SearchBased on Relational Database, In International Conference onInformation Science and Applications (ICISA) seoul,Pages 1-8, 21-23 April 2010.

[8] Hu jingjing, Zhao xing, Cao Yuanda, Zhou ruitao. A ServiceComposition Model with Characteristic of Transaction Basedon Finite State Machine. International Conference on Com-puter and Electrical Engineering, 2008. ICCEE 2008. 20-22Dec. 2008. Page(s): 450 - 454

305305