e8b21c520969efe3e8e3c20ca13a9f54.ppt
- Количество слайдов: 41
Capsules, Micropayments, and the Democratization of Cloud Computing Aditya P. Mathur Professor Department of Computer Science Purdue University, West Lafayette CS 197 Freshman Honors Seminar Wednesday January 19, 2011 p. SSP 1
A Problem Perennial inconvenience to the software user…. Users forced to purchase software upgrades while a majority of the new, as well as existing code, is not used. Forced to upgrade hardware because the new software demands it. Software oligopolies control the OS and officeproducts market. January 19, 2011 p. SSP 2
A Wish • Allow users the option of paying for only as much as and what they use. • Allow users the option of never having to buy new hardware but be still able to use new versions of software that they need. • Allow individual developers across the world to contribute to software development and get rewarded based on usage of their work. January 19, 2011 p. SSP 3
State of affairs Software Service providers, service platforms, and Saa. S • Google docs • www. zoho. com • Service platforms (e. g. , Qianxiang Wang’s work on programming in the cloud) January 19, 2011 p. SSP 4
Our proposal Create a pure Software Service Provider (p. SSP) paradigm analogous to the telephone service paradigm. January 19, 2011 p. SSP 5
Software industry: Today and tomorrow January 19, 2011 p. SSP 6
Scenario: Consumer Buy software New version Upgrade software Too slow? Upgrade hardware Next version Does not work App conflicts January 19, 2011 p. SSP 7
Scenario: Marketplace Developer app Software marketplace app Customer Apps are monolithic Apps execute at customer site Apps (mostly) for mobile platforms Apps (mostly) task specific January 19, 2011 p. SSP 8
Scenario: Cloud Computing Cloud Infrastructure Management Customer Hardware Software Apps are monolithic Developers part of management infrastructure Data and/or apps in the cloud January 19, 2011 p. SSP 9
Tomorrow’s Scenario: p. SSP Developer Infrastructure Management Customer Hardware Software Apps are “capsulized” Microeconomic model Apps are reconfigurable Developers: a mix of employees and independent p. SSP: pure Software Service Provider January 19, 2011 p. SSP 10
Marketplace, Cloud, p. SSP M C p. SSP Clientele Individual Organizations Economics Micro Macro Micro: perennial Governance Controlled; democratic Controlled Democratic Apps Monolithic Capsulized and reconfigurable Purchase Yes No, rental Subscription Yes/Maybe No/No Software/Har Yes/Maybe dware upgrade January 19, 2011 p. SSP 11
What is p. SSP? p User Dynamic App Repository P App Management Dynamic Data Repository S Outsourcing Management Developer S January 19, 2011 p. SSP 12
Software usage in p. SSP User signs up with a p. SSP as a member. User has minimal hardware and network connection. User has access to all software available for the membership category. January 19, 2011 p. SSP 13
Software execution in p. SSP An application may be executed at the p. SSP. An application may be executed on the user’s hardware. An application may execute partly at the p. SSP and partly at the user site: depends on the feature used. January 19, 2011 p. SSP 14
Data storage in p. SSP User data may be stored at the p. SSP. User data may be stored at the user site. User data may be stored at the p. SSP and at the user site. January 19, 2011 p. SSP 15
Software Development in p. SSP An application is a collection of interconnected capsules. Capsules are developed by independent developers and development organizations. Capsules are integrated at the p. SSP to create an application. January 19, 2011 p. SSP 16
Software Development in p. SSP An application has multiple incarnation. Each incarnation contains only features demanded by a subset of p. SSP subscribers. An incarnation is composed semi-automatically and on-demand. January 19, 2011 p. SSP 17
Software Economics in PSSP Capsule developer is paid based on usage, or one time, or a both. Copyright for a capsule may be owned by the developer. No single individual or organization might own copyright to an application. January 19, 2011 p. SSP 18
p. SSP: Architecture January 19, 2011 p. SSP 19
Capsules A capsule is a self sufficient piece of code that encapsulates one or more features. API: Input set Code Output set Attributes Attribute extraction and update January 19, 2011 p. SSP 20
Dynamically Composable Applications Capsule App 2 Capsule App 1 App 3 Capsule January 19, 2011 p. SSP 21
Application and capsules User API C 2 C 1 Avatar A C 3 Avatar B User API C 2 C 1 C 4 January 19, 2011 p. SSP 22
Capsules and components Capsule Component Independently executable Yes Maybe Coupling Loose or tight Platform independence Yes Maybe Features encapsulated Simultaneous avatars Few No constraint Multiple One January 19, 2011 p. SSP 23
Application use: Scenario I 1. Request an app Subscriber 2. App ready p. SSP 3. Use app 4. Terminate Today’s paradigm (e. g. Google docs, Zoho) January 19, 2011 p. SSP 24
Application use: Scenario 1 I Subscriber 1. Request an app 2. Receive capsule(s) p. SSP 3. Use app 4. Terminate January 19, 2011 p. SSP 25
Application use: Scenario III 1. Request an app Subscriber 2. Receive capsule(s) 3. Use app 4. Feature interrupt p. SSP 5. Receive capsule(s) 6. Continue using app 7. Terminate January 19, 2011 p. SSP 26
p. SSP: Application development 1. Develop requirements 2. Develop framework p. SSP 3. Issue RFCs 4. Accept capsules (QA) 4. Integrate and develop app (QA) Framework: a skeletal structure designed to support or enclose something. . . dictionary. com January 19, 2011 p. SSP 27
p. SSP: Capsule development 1. Issue an RFC Developer(s) 2. Receive c. Set p. SSP 3. Subject to QA c. Set’ 4. Accept c. Set’ c. Set: Set of capsules January 19, 2011 p. SSP 28
p. SSP: Capsule QA: Basic p. SSP Capsule +Test set Capsule Tests (Basic) QA Quality gate (Basic) Accept Reject Cleared? January 19, 2011 p. SSP 29
p. SSP: Capsule QA: Advanced p. SSP Capsule Tests (Advanced*) Capsule +Test set QA Quality gate (Advanced) Update Quality Level, Reliability *FSM tests, combinatorial tests, code coverage, mutation coverage, etc. January 19, 2011 p. SSP 30
p. SSP: App Assembly p. SSP Capsules Plug capsules into the framework App tests Perform app-level QA* Update app Quality characteristics *Component based modeling and reliability estimation; path and statebased models. January 19, 2011 p. SSP 31
p. SSP: App server/client p. SSP Subscriber App Client App Server January 19, 2011 p. SSP Capsules Apps 32
p. SSP: Management Tools Outsourcing Manager App Server Capsules Apps Quality Manager Payment System January 19, 2011 p. SSP 33
p. SSP: Implementation Challenges January 19, 2011 p. SSP 34
Quality Management: Reliability Ensure capsule conformance to RFCs Obtain accurate estimates of capsule reliability in the absence of a known operational profile Obtain accurate estimates of application avatars in the absence of a known operational profile January 19, 2011 p. SSP 35
App Avatar Determining the structure of an app avatar Composing an app avatar Delivering an app avatar Managing the evolution of an app avatar January 19, 2011 p. SSP 36
Execution of an App Avatar Determining where to execute a capsule Managing data Managing feature interrupts January 19, 2011 p. SSP 37
Customer management Determining customer profile Assigning apps to customers January 19, 2011 p. SSP 38
Developer management Developer acceptance criteria Developer reimbursements Developer competition across p. SSPs January 19, 2011 p. SSP 39
Embedded software Delivery Execution Maintenance January 19, 2011 p. SSP 40
Thank you! January 19, 2011 p. SSP 41


