In recent years the design of enterprise Web applications is more and more based on the integration of resources delivered through data services from outside the organization boundaries. Searching and composing existing data services o er many advantages, namely, the availability of widespread solutions in the form of services and data shared over the Web, and reduced development costs. In this scenario, new methods for speeding up the design process are emerging and, in particular, developers' social networks have been established, where developers follow other developers to learn from their choices in selecting suitable services. In this paper, we propose a framework to support data service selection for modern Web application design, by also considering the developers' social network. The network of social relationships, properly weighted with the developers' credibility, is used to compute developers' rank. This rank quali es developers' experience in selecting data services.
Modern enterprise Web application design increasingly relies on the selection and composition of external services, that provide access to resources from outside the organization boundaries. Availability of data services, that meet these requirements, are becoming more and more important, as also witnessed by the growth of public Web API repositories (e.g., ProgrammableWeb.com, Mashape.com). In particular, the lightweight description of RESTful services (often referred to as Web APIs), compared to the standard description of SOAP-based service capabilities (e.g., WSDL), is the main reason of their increasing success.
Starting from RESTful lightweight description, recommendation of the most
suitable services to be adopted within a Web application development process
combines several factors, beyond functional and non-functional requirements [
In this paper, we describe an extension to WISeR [
The paper is organized as follows: Section 2 describes the social network of developers, underlying the framework, and the developers' credibility assessment; Section 3 explains techniques behind developers' ranking for improving data service selection process and discusses a preliminary validation of the framework; nally, Section 4 closes the paper. 2
Social network-based model for data service selection
To enable social network-based selection of data services, we extended an existing
framework, WISeR (Web apI Search and Ranking) [
Formally, data services and aggregations are de ned as follows.
De nition 1. We de ne a data service s (hereafter, service) as an operation/method/query to access data of a web source, whose underlying data schema might be unknown to those who use the service. Within the scope of this paper, we model a service s as hns; ftsgi, where: ns is the service name; ftsg is a set of tags. We denote with S the overall set of available services.
De nition 2. A service aggregation represents a set of services usable to deploy a Web application. An aggregation g is modeled as a triple hng; S(g); di, where: ng is the aggregation name; S(g) = fs1; : : : ; sng is the set of data services used in g; d2D is the developer who designed the web application by composing services in g. We denote with G the overall set of service aggregations, that is, g2G, and with G(s) the set of aggregations where s has been included.
According to this vision, best representatives of data services are resourceoriented services (i.e., RESTful ones). For services that present a structured, operation-oriented description (e.g., WSDL), we consider only data they work on, represented through tags.
Developers, who used services to design their applications, are organized in a social network, de ned as follows.
De nition 3. The social network of developers is a pair SN = hD; E i, where: (a) D is the set of developers; (b) E is a set of follower-of relationships between developers, de ned as E = fdi !fdj jdi; dj 2Dg, where di !fdj indicates that di explicitly declares to be inclined to learn from the choices made in the past by dj for web application design purposes.
Each developer di2D is modeled as hG(di); D i, where G(di) G is the set of aggregations designed by di in the past, D D is the set of other developers, whom di declares to be inclined to learn from, in order to design web applications, that is, D = fdkjdi !fdk2E g. The organization of the follower-of relationships determines the network structure as extracted from Mashape repository. The developers' social network can be represented as one or more directed graphs, as shown in Figure 1.
dev2
dev5 dev1 dev4
dev8 dev3 dev6
dev7 (a) dev9 dev12 (b) dev10 dev13 dev11 dev14
Developers' credibility In our approach, a developer may assign votes to services used in the applications. In particular, since developers exchange their experiences in using services, votes become an enabling feature to this purpose. Following this vision, for example, all the most popular Web API repositories include a rating system. Our approach introduces an important distinction for service rating, compared to existing systems, because it takes into account the aggregation in which services have been evaluated (aggregation-contextual rating), according to the following de nition.
De nition 4. Given a service sj 2S, we denote with v(sj ; gk; di)2[0; 1] the vote assigned to the service sj by a developer di2D with reference to the aggregation gk2G in which sj has been used.
Aggregation-contextual rating helps in properly weighting votes assigned to
services. When a developer is looking for the average of votes assigned to a service,
relevant votes to be considered are those that have been assigned with reference
to aggregations that are similar to the one that is being developed, according
to the aggregation similarity, AggSim(), introduced in [
M (sj ) = centroid(maxik=1(Ci)) (1) where Ci is the i-th cluster, k = jfCi)gj is the total number of clusters, max() returns the cluster with the largest membership and centroid() computes the centroid of the cluster. The number k of desired clusters is set to lpN=2m where N is the number of considered votes and dxe is the smallest integer not less than x. Therefore, considering a developer di, having a credibility cn(di) after he/she already assigned n votes, and given a new vote v(sj ; gm; di) assigned by di to a service sj when used within an aggregation gm, the new credibility value for the developer is computed as follows: cn+1(di) = cn(di) n + (1 jM (sj ) n + 1 v(sj ; gm; di)j) According to Equation (2), if the vote v(sj ; gm; di)2[0; 1] di ers from the centroid M (sj )2[0; 1], then term 1 jM (sj ) v(sj ; gm; di)j tends to zero, therefore cn+1(di) < cn(di) (the decrement is controlled by denominator n + 1, to avoid the case in which a designer looses too quickly his/her credibility for few assigned votes that are not aligned with the majority opinion). Viceversa, if the vote v(sj ; gm; di) is close to M (sj ), then term 1 jM (sj ) v(sj ; gm; di)j tends to 1 and cn+1(di) > cn(di) until cn+1(di) reaches 1 (max credibility). Initial values c0(di) are set to 0:5. Note that credibility of a developer with a high value of n and who is assigning a vote di erent from the ones expressed by the majority, is reduced of a low amount. In fact, this type of vote is not necessarily describing an incoherent behavior of the developer and could be the result of a recent change in the service conditions or quality perceived by the voter. The rationale for clustering votes can be explained with the help if an example: if a service receives votes 1,1,1,2,9,9,8, and we adopt an average-based model, we obtain an overall rating of 4.4. Actually, this rating is not representative of the depicted situation, where the majority of voters gives a low vote. 3
Let's consider a developer dr, who is searching for a service sr. Consider two
candidate services s1 and s2, used by two developers d1 and d2, respectively, in
aggregations that are similar to the one that is being developed. If s1 and s2 are
equally relevant for the developer dr according to the overall similarity function
Sim(s1; s2) (de ned in [
Rank of a developer di2D is computed as the product of two di erent rankings, according to the following formula: dr(di) = r rdel(di) abs(di) 2 [0; 1] (3) where: (a) a relative ranking rdel(di)2[0; 1] ranks developer di based on the follower-of relationships between di and dr (this rank is introduced to take into account the viewpoint of dr, who explicitly declared to learn from other developers to select the right service); (b) an absolute ranking abs(di) is based on the overall network of developers, to take into account the centrality of di in the network independently of the developer dr, who issued the request.
In particular, the relative ranking rderl(di) is inversely proportional to the distance `(dr; di) between dr and di, in terms of follower-of relationships, that is: r 1 rdel(di) = `(dr; di) 2 [0; 1] (4) If there is no a path from dr to di, `(dr; di) is set to the length of the longest path of follower-of relationships that relate dr to the other developers, incremented by 1, to denote that di is far from dr more than all the developers within the dr sub-network. Consider for example the network topology shown in Figure 1, where the developer dev3 is the requester and has to choose among services that have been used in the past by the developers dev4, dev5, dev6, dev8 and dev11, whose follower-of relationships are depicted in the gure. In the example, `(dev3,dev4)=`(dev3,dev8)=1, `(dev3,dev5)=2, and `(dev3,dev6)=`(dev3, dev11)=2 + 1=3.
The absolute ranking abs(di)2[0; 1] is evaluated no matter is the viewpoint of the requester dr. This ranking is composed of two di erent parts. The rst one depends on the number of aggregations designed by di, the second one depends on the topology of the network of other developers who declared their interest for di past experiences, that is: 1
jDj abs(di) = jG(di)j +
Xn c(dj) abs(dj) j=1
F (dj) (5) This expression is an adaptation of the PageRank metrics to the context we are considering. The value abs(di) represents the probability that a developer will consider the example given by di in using a service for designing a Web application. Therefore, Pi abs(di) = 1. Initially, all developers are assigned with the same probability, that is, abs(di) = 1=jDj. Furthermore, at each iteration of the absolute ranking computation, the absolute rank of a developer dj, such that dj !fdi, is "transferred" to di according to the following criteria: (i) if dj follows more developers, his/her rank is distributed over all these developers, properly weighted considering the credibility c(dj) of dj(see the second term in Equation (5), where F (dj) is the number of developers followed by dj); (ii) a contribution to abs(di) is given by the experience of di and is therefore proportional to the number of aggregations designed by di(see the rst term in Equation (5)). A damping factor 2[0; 1] is used to balance contributions explained in (i) and in (ii). At each step, a normalization procedure is applied in order to ensure that Pi abs(di) = 1.
The computation algorithm used for Equation (5) is similar to the one applied for PageRank. In particular, denoting with abs(di; N ) the N-th iteration in computing abs(di), with DR( N ) the column vector whose elements are abs(di; N ), we have: where M denotes the adjacency matrix properly modi ed to consider credibility, that is, Mij = Fc((ddjj)) if dj !fdi, zero otherwise. As demonstrated in PageRank, computation formulated in Equation (6) reaches a high degree of accuracy within only a few iterations.
Framework validation. Since there are no benchmarks to compare our approach with similar e orts, we built a dataset to perform a validation on the framework. We used wrappers to extract from Mashape repository service descriptions and the developers who follow/consume those services, including the 1 2jG(d1)j3 6jG(d2)j7 jDj 646 ... 757
jG(dn)j DR( N+1) = +
M DR( N ) (6) network of their follower-of relationships. We completed the dataset construction by adding the number of developed aggregations and developers' credibility values in order to obtain the following classes of developers: (i) developers with a high number of followers, who in turn have several followers as well, with high credibility (0:7 c(di) 1:0) and several designed aggregations (jG(di)j 3), like dev5 in Figure 1; (ii) developers who present few followers, medium credibility (0:4 c(di)<0:7) and several designed aggregations (jG(di)j 3); (iii) developers who present few followers, medium credibility and few designed aggregations (jG(di)j < 3); (iv) developers who present few followers, low credibility (0 c(di)<0:4) and who designed few aggregations. Intuitively, the above mentioned classes are ordered according to an increasing rank of developers, where developers in class (i) are top ranked. This rank will be considered as reference for setup of the damping factor and approach validation.
We run the system randomly selecting a subset of developers as requesters, we computed the Kendall tau distance k for each run with respect to the reference developers' rank described above and we computed the average value for k. We also repeated the same experiment considering two di erent con gurations of the approach, namely: (a) an optimistic con guration, where we considered all developers having maximum credibility (i.e., c(di) = 1:0, 8i); (b) a con guration biased on the requester, where only the relative ranking rderl(di) has been considered. We kept the value = 0:6 for the damping factor. The results of this validation are shown in Table 1. The average value of the Kendall tau distance shows the accuracy of our ranking solution compared to an intuitive sorting of developers described above considering the four classes of developers (i)-(iv). Validation results also demonstrate the impact of considering developers' credibility and the topology of social relationships between developers through the computation of the absolute ranking abs(di). Indeed, if we do not consider di erent levels of credibility (optimistic case), the quality of ranking slightly decreases. However, decrement of ranking quality is even more evident if we do not consider the absolute ranking (biased case), thus demonstrating that the relative viewpoint of the requester is not able to correctly identify the centrality of other developers in the social network.
c(di)
Optimistic case c(di) = 1, 8di Our approach c(di)2[0; 1], 8di = 0:6 = 0:6 = 0:6
distance k2[0; 1] 0.6026 0.1795 0.0360
In this paper, we discussed how developers' social relationships, as well as their credibility, can be properly exploited to support data service selection. In particular, we proposed a framework for ranking developers by considering both a relative and an absolute perspective. The framework interacts with the Mashape repository, the largest service repository where developers can follow each other in a social network. Other developers' social networks, such as GitHub, are not speci cally meant for data service selection, while other highly populated Web API repositories (e.g., ProgrammableWeb) do not present social relationships between developers. Further studies are on going for extending the social network model: speci cally, other aspects such as the maturity of the use of data services (estimated through their publishing data and the number and quality of aggregations including the services) and speci city of the searched services (i.e., general purpose or domain-speci c) may be investigated with respect to a possible in uence in the search and ranking process.