630 likes | 748 Views
Application and Data Portability in Cloud Computing The Cirrocumulus Way. Ajith Ranabahu and Amit Sheth Ohio Center of Excellence in Knowledge enabled Computing ( Kno.e.sis ) http://knoesis.org Wright State University, Dayton OH, USA. Agenda. Issues in Cloud computing and its adoption
E N D
Application and Data Portability in Cloud ComputingThe Cirrocumulus Way AjithRanabahuand AmitSheth Ohio Center of Excellence in Knowledge enabled Computing (Kno.e.sis) http://knoesis.org Wright State University, Dayton OH, USA
Agenda • Issues in Cloud computing and its adoption • Vendor lock-in problem • Understanding cloud heterogeneity • Using Domain Specific Languages to implement application portability • Using RDFS based modeling to implement data portability • Two Example applications • Where are the semantics ?
Cheap No upfront cost Utility style Resources Service oriented provisioning over the Web APIs enabling programmatic access Numerous support services Data access (Amazon RDS, Amazon simple DB, Google Big Table Automatic scaling (Amazon Elastic Beanstalk)
Almost always heterogeneous platforms Supported programming languages Data representation Resource provisioning and Management Workflow
Writing one application is not enough !
Amazon EC2 accepts almost any language Windows Azure support .NET (other languages need workarounds) Google App Engine only supports Java and Python
Users locked into clouds proprietary APIs Limited language support Custom tools and workflows
We need a better way of doing things !
Write applications in cloud agnostic ways : "Write once - Run on any cloud"
Move applications and data across clouds when the need arises
Understanding Heterogeneity : Where does it exist ?
Vertical Within the same type of clouds - Say Infrastructure service providers
Horizontal Across different types of clouds - Say Infrastructure clouds and platform clouds
Amazon EC2 vs Rackspace Both are infrastructure providers Process of starting a VM in EC2 is very different from doing the same in Rackspace
Google App Engine vs Windows Azure Both are platforms Supports differentlanguages (Java/Python vs C#/.NET) Requires using different custom libraries Requires adhering to different data models (document-oriented vs Relational)
Domain Specific Languages (DSL) are specialized, mini languages that address problems in a limited domain. • Matlab (Mathematics) • SQL (Data definitions and manipulation) • Ant / Make (build scripts)
Some example domains of Interest (in the Cloud context) Enterprise data retrieval applications Data driven mobile applications Statistical Scientific Workflows
DSLs are not universal applicable: Useful only in a supported domain
The case of the "smallest common set of features" When using an abstraction over multiple platforms, only the smallest common set of features can be effectively supported.
The number of unique features across the major platforms is quite small [quantification needed !]
In case platform specific features are needed Use the DSLs as boiler-plate code generators Use Bison-like conditional code additions to insert specific code fragments
MobiCloud Generating hybrid applications that have pieces running on clouds and mobile devices http://mobicloud.knoesis.org
SCALE : Scalable Cloud AppLicationgEnerator Generating statistical workflows for biologists http://metabolink.knoesis.org/SCALE
What kind of Heterogeneity are we talking about ?
An Example for a simple class [ Code generated by MobiCloud for task manager example ] package bean; import com.google.appengine.api.datastore.Key; import javax.jdo.annotations.IdGeneratorStrategy; import javax.jdo.annotations.IdentityType; import javax.jdo.annotations.PersistenceCapable; import javax.jdo.annotations.Persistent; import javax.jdo.annotations.PrimaryKey; @PersistenceCapable(identityType = javax.jdo.annotations.IdentityType.APPLICATION) public class Todoitem { @PrimaryKey @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) private Key key; public Key getKey() { return key; } @Persistent private java.lang.String time; public java.lang.StringgetTime() { return time; } public void setTime(java.lang.Stringlocal_time) { this.time = local_time; } …….. } package bean; public class Todoitem { /* PrimaryKey */ private int key; public intgetKey() { return key; } public void setKey(intlocalkey) { this.key = localkey; } private java.lang.String time; public java.lang.StringgetTime() { return time; } public void setTime(java.lang.Stringlocal_time) { this.time = local_time; } … } Code for Local / EC2 version Code for Google App Engine version
The DSL code fragment relevant to the generated code model(:todoitem,{:time => :string,:location => :string, :description => :string,:name => :string}) Taking care of proper annotations and adhering platform specific restrictions Is taken care of by the generators !
Issues caused by the difference in data models Often more crucial than porting the application code
We are in luck ! We already followed a model-driven development process
We get to define data at a higher level of abstraction Data transformations can be generated along with the application code