Assuming that we have a multi-attribute CDA in place to allow for buyers and sellers to interact, what causes the buyer to come back after one transaction?
a) When the utility function that monitors the value from the purchase becomes negative, the buyer needs to come back. That is, if an app bought an image-manipulation ws with a stated performance rating of 10AMM (Above Market Minimum) for £x +£y(market entry cost), it expects a value of at least £x + £y to be delivered. Upon composition and monitoring, if the value that the app receives is less than £(x+y), then the app will consider returning to the market. But there are two possible outcomes: the app goes back and bids for more than 10AMM or the app will try to buy 10AMM for less then £x
How do we figure out what's optimal for the app?
Wednesday, 29 July 2009
Kinds of quality attributes
There are at least two types of quality attributes in an architecture:
1) Those that can be 'designed in' at design time: These are effected at design. Modularity, testability are examples of this
2) operational quality: These can be measured only at runtime. During design time, one can only hypothesize or simulate their values. Performance and availability are examples of this
In my work, I'm going to look at operational QAs. Design-time QAs are best manipulated at design time, but operational QAs can only be guesstimated. Therefore, the maximum benefit is obtained when operational QAs are adapted based on actual, in-the-field situations.
1) Those that can be 'designed in' at design time: These are effected at design. Modularity, testability are examples of this
2) operational quality: These can be measured only at runtime. During design time, one can only hypothesize or simulate their values. Performance and availability are examples of this
In my work, I'm going to look at operational QAs. Design-time QAs are best manipulated at design time, but operational QAs can only be guesstimated. Therefore, the maximum benefit is obtained when operational QAs are adapted based on actual, in-the-field situations.
Friday, 24 July 2009
While creating bids, the essential attributes are:
1) Time for which service will be provided
2) Renewal, whether automatic or not
3) functionality - how do we denote this for automatic recognition
4) QA - direct - performance on a known data set / per sec
5) QA - indirect - number of locations occupied by web-svc instances (reliability, for instance)
1) Time for which service will be provided
2) Renewal, whether automatic or not
3) functionality - how do we denote this for automatic recognition
4) QA - direct - performance on a known data set / per sec
5) QA - indirect - number of locations occupied by web-svc instances (reliability, for instance)
Tuesday, 14 July 2009
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.
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.
Subscribe to:
Posts (Atom)