I've decided on the broad thrust of my research. I'm looking at self-organisation of web-applications on the cloud, to ensure quality attributes.
That is, I shall propose a method for architects to create web-applications, which connect to various web-services, based not only on functionality offered but also quality attribute targets.
What does this mean? I envision, a marketplace where web-services bid for and sell functionality. However, connecting to a component (inside a web-service) is not an easy decision to make. Not all components are created equal. Some components exhibit high-performance and scalability, while others exhibit dependability. Still others might exhibit a secure layer. Depending on which Quality Attribute the web-application is looking for, it will connect to the web-service that offers that particular one.
Connecting and use of a web-service cannot be gratis. This is where the marketplace comes in. If we imagine a set of WS buyers and sellers, then the following conditions are necessary for an efficient marketplace to exist:
1) There should be an efficient matching of buyers and sellers
a) Ex-post individual rationality should hold
b) Matching should happen quickly - low order polynomial time
2) Matching of buyers and sellers must be done on multiple attributes
3) The market should have some incentive to be present, id est Both the buyer and seller will have to pay to participate in the market.
a) The buyer will have to enter the market with a frequency that is directly proportional to the frequency with which its focus (or chosen QA) changes. So, if the application changes its preferred QA with a high frequency, then the cost of entering the market will have to factored into the budget that it is willing to spend on acquiring a web-service. On the other hand, if the frequency of change is low, then the cost of entering the market could be seen as a one-time fixed cost.
b) Allocative efficiency should be high. The total utility of the matching should be high enough, for buyers and sellers to continue to stay in the marketplace. Else, they would leave the market and try to deal outside.
A multi-attribute auction allows for (2), while a continuous double auction exhibits (3_b). I wonder if a combination of the two would be suitable for my purpose.
What're the modelling aspects to take care of?
1) Web-apps would have to be strictly monotonic in their preferences for QAs
2) A notation for indicating QAs would need to be evolved.
3) A notation for indicating functionality would need to be evolved.
Interesting stuff Vivek!
ReplyDeleteA couple of questions, not particularly bright ones, but just some clarifications really:
- Do you care about centralised vs decentralised approaches? Should you?
- Are things like secure layers, scalability not functional requirements rather than quality ones? Where is the line drawn?
- "Connecting and use of a web-service cannot be gratis." Why not?
- "There should be an efficient matching of buyers and sellers". This might sound like a dumb question, but why? From whose perspective, i.e. who cares if it's efficient or not? Surely each participant just cares if they get their stuff, not about anyone else (under your model)?
- Also, are you assuming that there is a "matcher", who has some algorithm to do this? Who is this matcher? Is he needed, owned, necessary etc?
- "The buyer will have to enter the market with a frequency that is directly proportional to the frequency with which its focus (or chosen QA) changes." Why? If it's because the buyer would just carry on buying from the same guy unless his own requirements changed, will this be the case? What if he could have got a better deal for the same thing? How would he know? Wouldn't he check? Should he be required to re-enter the market for every purchase or is it okay to continue with the same seller. Similarly, from the seller's point of view, there might be some new buyer in the market who would pay more than the old buyer, but he'd never know. Does this make sense, or did I misunderstand?
Feel free to ignore my ramblings!
:-)
Thanks for the questions. They make me think a bit deeper about what I'm doing. Here's a shot at answering them:
ReplyDeleteI don't know if I *should* care about centralized approaches or not. I like decentralized approaches since they're more robust and seem more like natural systems.
Security and scalability are traditionally not viewed as functional requirements. Correctness is usually considered an indicator of functionality. Two algorithms that sort: one is nlog(n) while the other is n^2. They both fulfill the functional requirement of sorting correctly, but the former is more scalable than the other. And hence of better quality. See?
Connecting and use of a web-service cannot be free, because there is an entry fee to enter the cloud. It is unreasonable to expect someone to put up money and skill, and have it used for free. Of course, if there's a cross-subsidy by way of adverts or even indirect sponsorship by way of a university cloud, then there need not be a direct cost. But there's always a cost, direct or indirect.
The sellers care if it's efficient or not. Since this is not a manual negotiation, one must have a reasonable assurance that if one's web-service was offering a competitive rate, it would be chosen and there would be some return on investment. The buyer doesn't care, as long as he gets the best price.
The matcher is the market. A multi-attribute continuous double auction. Of course, there could be many markets. Which one to enter, we'll allow Edd to figure out :-)
If the buyer's requirements don't change, then he continues getting serviced by the same guy. To go back to the market, both the buyer and the seller have to pay an entry fee to the market (else the marketplace app has no incentive to exist). They go back to the market when there's a chance of them getting a better deal. In case of changed requirements, it's a necessity. Otherwise not. Does that make sense?
Fair enough... couple of follow-ups:
ReplyDelete- "The matcher is the market. A multi-attribute continuous double auction..." So the matcher is an auctioneer. That's fine, but you need to acknowledge that he's a player too. And if there's only one (or a small number) I don't think we can call it decentralised, personally.
- "They go back to the market when there's a chance of them getting a better deal." How can they know this unless they go back to the market to find out?
:-)
> And if there's only one (or a small >number) I don't think we can call it >decentralised, personally.
ReplyDeleteI don't understand. The marketplace is not a privileged app. Anyone can set one up. So a buyer could be in many marketplaces at once, with a strategy that lets him learn which marketplace is the best (for some utility function).
> "They go back to the market when there's a chance of them getting a better deal."
> How can they know this unless they go
> back to the market to find out?
They don't. Which is why they (the agents) need to have a learning strategy of which markets to enter and when. I know, I'm making this quite complicated by adding more learning strategies at the agent's end, but I can't seem to find a simpler solution.