While there are some data for real individual web services’ quality attributes such as the Quality of Web Service (QWS) data set by Al-Masri and Mahmoud (2007), there is no public information on web services’ pricing or bundling. Therefore, we designed a stochastic data generation model based on the literature of combinatorial auctions. The design of the model includes: firstly, a parametric model to generate data so that it is as
153
close as possible to real-world web services’ offers and requests and, secondly, establishing a careful starting configuration for seeding the parameters used in simulation.
6.4.4.1 Data Generation Model
In the evaluation of the simultaneous auction mechanism, we need to have the data for bids as well as the requests. The data generation model follows three steps to generate the data:
Step 1. Generating the tasks in the market:
The model starts by generating a fixed number of tasks for the market, based on the given value for the simulation parameter Tasks_Number. This is the set of tasks that are mostly relevant to a particular business domain, and therefore, there is a community of service providers and requesters interested in these tasks.
Step 2. Generating the set of service providers:
In the second step, a fixed number of service providers will be created, based on the given value for the simulation parameter Providers_Number. Each provider will have an independent valuation for each task, drawn from a uniform distribution between [1,100]. This is referred to as Independent Private Valuation (IPV) model in auction theory (Kagel and Levin 1993) and is similar to the CATS approach in generating the prices for the items under auction. Participants with an IPV model only know their own valuation and they do not care about others’ valuations for the items being auctioned. The IPV model is the common assumption in the auction and mechanism design literature.29
Subsequently, each provider will be assigned a discount factor which is drawn from a uniform distribution between [0, Max_Discount], where Max_Discount is the maximum discount given by providers in that market.
29 As discussed in subsection 5.3.2.2 (stage 2), another valuation function in auction theory is called “the
common value” where the value of offering the service for a task is more or less the same for all providers, but each provider’s estimate for how much they can charge to sell the service in the market is different. Although this approach seems to be more realistic than the IPV, it is not used very often in research and experiments. One reason might be the complexity of analysis related to games based on this model. For example, the winners of a game with this valuation model will always suffer from the winner’s curse. Moreover, in the previous chapter, the results of the experiments with the two valuation functions did not lead to significant difference in the cost or success rate. Therefore, we decided to base the simulation for the simultaneous auction on the more commonly used independent private valuation (IPV) model.
154 Step 3. Generating the offers (bids):
In the third step, a fixed number of combinatorial offers (bids) is generated for one simulation round based on the given value for the simulation parameter Offers_Number.
Offers are then randomly assigned to providers. This means that each provider might have one or more bids active in the market. Each bid has the following elements to be considered during bid generation:
1. Number of services to be offered in the bid 2. The services to be offered
3. The price for the bundle.
To decide the number and the services in each bid, we have two options:
1. Uniform distribution: m, the number of services in each bid, is drawn from a uniform distribution between [1, M], where M is the number of tasks in the market. Then, choose m random tasks from the set of M tasks, and add the equivalent services to the bid.
2. Decay distribution: Consider a new parameter, α < 100, which determines the bid (bundle)’s crowdedness. α can be set at different values for different providers or can have the same value across all providers in the market. Randomly, choose the first service to be included in the bid. Then, draw a random number between [0,100]. If this number is smaller than α, choose another service randomly to be added to the bundle and start over, otherwise stop.
We chose the decay distribution option as it is said to generate harder instances of combinatorial bids for solvers (Sandholm et al. 2002). To set α, we initially experimented with setting a different α for different providers. As the average α across all providers had been close to 50%, the average size of the bids would be less than having three services. This would create simple combinatorial bid instances. To have more variety of simple and complex bids, we decided to keep α fixed for the whole market on 75%.
The price requested for the services offered in a bid is calculated as the sum of the provider’s valuations for the services in the bid, minus a discount which is calculated based on the provider’s discount factor.
155
Step 4. Generating the requests for composite services
In the final step, a fixed number of requests is generated in the market based on the given value for the simulation parameter Requests_Number. To specify a composite service request, we needed similar elements to those of a bid:
1. The size of the composite service (CS) 2. The tasks requested in the CS
3. The requester’s budget constraint to procure the CS.
Based on the market sections considered, the composite services are generated in two sizes: small for a market with simple CSs or large for a market with complex CSs. The tasks in a request are randomly chosen from the set of tasks in the market. To calculate the budget constraint, firstly, the requester’s valuation for each task is generated based on the IPV model. Then, the budget is calculated as the sum of the requester’s valuations for the tasks in that request.
Note that, as the data generation model does not guarantee the existence of at least one bid for each task in the market directory, there might be some service requests including tasks for which no service is being offered. Such a scenario is very likely to happen in a real-world web service market. This means that requesters are interested in a specific service that is not currently offered and it signals the providers the need for developing such a service. However, apparently all the requests including such tasks would be infeasible, regardless of the allocation mechanism.
6.4.4.2 Seeding the Parameters
Due to the absence of publicly available real data for web services’ offers and requests, and lack of similar experiments on web services’ markets in the current literature, seeding of the simulation parameters was a challenging problem for this study. The main difficulty was related to visualizing a marketplace for web services: What would be the likely number of service bids or requests in such a market? Or what would be the range of numbers? What is the likely size of composite services requested in that marketplace?
To answer these questions, we referred to the existing communities around web services on the Internet. These communities currently do not have the functionalities of a market,
156
that is, price discovery or facilitating the exchange. Nevertheless, they can be a representation of marketplaces in the future.
We believe that future markets for web services will focus on specific domains, rather than being a generic marketplace. Similar to the existing communities of web services around different domains, there will be markets focusing on different areas, such as GIS- related web services to retrieve, store, display and analyze GIS-enabled information. General web services might attend domain-specific markets as well as more generic ones.
Our belief is supported by the studies that we performed over some of the real-world examples of web services’ markets. Companies interested in providing a marketplace for web services have moved toward offering more specialized web services in a specific domain, rather than offering an environment for exchanging all sorts of web services. For example, StrikeIron30 and Xignite31 are two start-up companies which initially appeared as general web services’ markets (Blau et al. 2010). However, they later focused on offering services in specific domains: data quality validation and verification web services in the case of StrikeIron, and financial services in the case of Xignite. This trend pictures the web services’ market, not as a general purpose market, but rather as specialized, domain-dependent markets.
In our studies, we reviewed active communities of web service providers and requesters focusing on different domains, including but not limited to: biodiversity research, GIS- related web services, life science research, astronomy and eLearning web services. The website, ProgrammableWeb, also provides information on web services and their users, categorized in more than 60 domains.
Our search showed that, depending on the maturity level of the community of web service users and providers, they form small or large communities (the economy size of the communities). Moreover, the services offered in these communities can be composed together to create composite services ranging from simple to complex. Simple composite services do not include many single web services (less than five), while complex composite services may incorporate more than 20 services to achieve their goal.
30 <http://www.strikeiron.com>, active since 2002 31 <http://splice.xignite.com/>, active since 2003
157
Table 6.3. Seeding the experiment’s input parameters
Parameter Values of the parameter for Levels
Tasks_Number (in the market) [25,50] 2
Providers_Number [5,50] 2
Offers_Number (Bids_Number) In small economy: [50,100]
In large economy: [300,500] 4
α in the market 75% 1
Max_Discount 25% 1
Requests_Number In small economy: [4,12]
In large economy: [20,28] 4
Requests_Size Small, #tasks between [3,4,5]
Large, #tasks between [15,16,..,20] 2
Total combinations 128
For seeding the parameters, we relied on these observations to gain insight on the number of service providers, service offers, service requesters and size of requests for composite services. Based on the market sections discussed before, Table 6.2, we focused the experiments on two extremes of composite service complexity: marketplaces with simple requests (such as mobile applications), and marketplaces with complex ones (such as scientific workflows). The final seeding of the simulation parameters is depicted in Table 6.3.