July 7, 2010 21/07/2010 ECE Presentation G1 1ltahvild/courses/... · – service‐to‐service...

A Generic Architecture for

Developing Cloud Applications

Mohammad Hamdaqa, Tassos LivogiannisGroup 1

Department of Electrical and Computer EngineeringUniversity of Waterloo

ECE750 Topic 5 – Spring 2010Project supervisor: Ladan Tahvildari{mhamdaqa, livtasos}@uwaterloo.ca

July 7, 2010

1ECE 750 ‐ Presentation 2 ‐ G121/07/2010

OutlineOutline

• Problem Description

• UML Profile presentation– Cloud Application Profile

– Profile Constraints

– Mapping ‐ PIM to PSM

• Case study

• Project Contribution

21/07/2010 ECE 750 ‐ Presentation 2 ‐ G1 2

Problem DescriptionProblem Description

• Lack of modeling language, to model cloud applications

• Lack of cloud computing standards

• Lack of vocabulary, jargons, and design patterns


MethodologyMethodology


Extract Main ComponentsExtract Main Components


What is a Cloud Service?

The Developer Perspective

(SW Architecture)

Core cloud servicesCore cloud services

• Core cloud services are services that support – identity management– service‐to‐service integration– Mapping– billing/payment systems– Search– Messaging– business process management– workflow– and so on.


Simplified VersionSimplified Version


A Cloud Application consists of a number of Tasks

What is a Tasks?• a special kind of service•Set of actions that provides specific functionality to solve a problem

a Task is special because it is a mutated unit that can be copied to other virtual machines

Like any other service or component aCloudTask has a definition file. TaskDefinition: Store information about tasks that the cloud application provides

These information provide the structure of the cloud application. In term of the provided tasks and the types of these tasks.

Dynamic aspect of cloud applications and elasticity!!!

CloudTask can be further classified:

CloudFrontTask:1.WebTask (Web Application)2.ServiceTask (Web Service)

CloudRotorTask: Background cloud process

Eg. Grid Computing Tasks

CloudPersistenceTask: Can be classified based on storage mechanism to

CloudPersistenceTask: 1.Queue (Message Passing)2.Blob (Large files and folders)3.Table (ERM)

EndPoint:Connection mechanism between:•Task – Task•Task – EnvironmentSemantic => OCL

OCL Constraints (1/5)OCL Constraints (1/5)

• CloudTasks are not allowed to accept connections from outside of the cloud, via TCP protocol

Context CloudTask

Inv: self.endpoint->select(endpoint:Endpoint | oclIsTypeOf(External) and endpoint.protocol.oclIsTypeOf(TCP))->isEmpty()



• CloudFrontTask should have at least 1 External Endpoint and at most 2, one using the HTTP Protocol and the other using the HTTPS protocol

Context CloudFrontTaskInv: self.endpoint->select(oclIsTypeOf(External))->size() >= 1 and

self.endpoint->select(oclIsTypeOf(External))->size() < 3

Inv: self.endpoint->select(endpoint:Endpoint | endpoint.oclIsTypeOf(External) and endpoint.protocol.oclIsTypeOf(HTTP))->size() <= 1

Inv: self.endpoint->select(endpoint:Endpoint | endpoint.oclIsTypeOf(External) and endpoint.protocol.oclIsTypeOf(HTTPS))->size() <= 1



• CloudPersistenceTask should not accept connections from outside the cloud, neither accept non‐secure connections from other components in the cloud

Context CloudPersistenceTaskInv: self.endpoint->select(oclIsTypeOf(External))->isEmpty()

Inv: self.endpoint->forAll(endpoint:Endpoint | endpoint.protocol.oclIsTypeOf(HTTPS))



• CloudRotorTasks should not accept connections from outside the cloud

Context CloudRotorTaskInv: self.endpoint->select(oclIsTypeOf(External))->isEmpty()



• A CloudApplication should have at least one CloudFrontTask

Context CloudApplicationInv: self.cloudTask->exists(oclIsTypeOf(CloudFrontTask))


Cloud Application ProfileCloud Application Profile


UML Class Diagram MetamodelUML Class Diagram Metamodel


Component

0..10..10..1

ownedElement

Comment

*

Link

1..*1..*1..*

EnumerationLiteral

ProgrammingLanguageTypeEnumerationPrimitive

******

1..*

*

Object

ParameterdefaultValuekind

InstanceNamespace

specialization*

parent

*child

GeneralizableElementisRootisLeafisAbstract

Package

Model

SubsystemDataTypeInterfacedeploymmentLocation* resident

*

AssociationClass

Class Node

owner

{ordered}

participant*

specification*

AssociationEndisNavigableaggregationmultiplicity

connection2..*2..*2..*

Association

Methodbody

OperationisAbstract

0..1

qualifier *AttributeinitialValue

{ordered}*

specification******

* type

Generalizationdiscriminator

Featurevisibility

BehaviouralFeatureStructuralFeaturemultiplicity

Classifier

ModelElementname

Element

Relationship*

*

type

importedElement*

*

Mapping Cloud ComponentsMapping Cloud Components


Azure Azure GoogleGoogle

Names Underlying Technologies Names Underlying Technologies

Cloud Front TaskCloud Front Task

Web Task (HTTP

request)Web Role

ASP.NET, IIS 7.0(Ajax, Silverlight, Flash)

Welcome Page

JSP, Servlet(JavaFX, Ajax, JavaScript, Flash, Google Web Toolkit, GAE SWF), Python Django

Service Task (RPC, REST)

Web Role.NET/WCF, .NET/WSDL,

.ASMX pages, MSSOAP, IIS 7.0

Web ServiceMetro Stack (Jax-WS,Jax-RPC), Python Web Services, webapp

framework, zope

Cloud Rotor TaskCloud Rotor Task Worker Role .NET, SQL Azure QueueSchedule or Queue Task

Java/Python Task Queue API, Scheduled Cron Jobs

Cloud Persistence Cloud Persistence TaskTask

TableSQL Azure

TableADO.NET, LINQ, ODBC,

PHP/HTML(REST)Datastore

Google BigTable, JDO, JPA, JDOQL, JDBC, Django Data

modelling API

QueueSQL Azure

QueueREST ―― ――

BlobSQL Azure

BlobADO.NET, ODBC, PHP/HTML(REST)

Blobstore Blobstore Python/Java API

Case StudyCase Study


Message passing

Project contributionProject contribution

• Providing a generic cloud architecture, that provides stakeholders with the basic components for modeling and developing cloud applications, Independent of the platform

• Generating a profile for cloud architecture using the eclipse modeling framework (EMF)

• Using the architecture to design a cloud application


References References [1]M. Armbrust, A. Fox, R. Griffith, A.D. Joseph, R.H. Katz, A. Konwinski, G. Lee, D.A. Patterson, A. Rabkin, I. Stoica, and others, “Above the clouds: A berkeley view of cloud computing,” EECS Department, University of California, Berkeley, Tech. Rep. UCB/EECS‐2009‐28, 2009. [2] J. Cała and P. Watson, “Automatic Software Deployment in the Azure Cloud,” Distributed Applications and Interoperable Systems, 2010, pp. 155‐168. [3] G. Reese, Cloud Application Architectures, O'Reilly Media, 2009. [4] D.S. Linthicum, Cloud Computing and SOA Convergence in Your Enterprise: A Step‐by‐Step Guide, Addison‐Wesley Professional, 2009. [5] T. Leveque, J. Estublier, and G. Vega, “Extensibility and Modularity for Model Driven Engineering Environments,” Proceedings of the 16th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems, 2009, pp. 305‐314.[6] K. Czarnecki and S. Helsen, “Feature‐based survey of model transformation approaches,” IBM Systems Journal, 2006. [7] S. Crawley, “Generating software from models,” Proceedings of the International Conference on Software Methods and Tools, 2000, pp. 233‐239. [8] D. Thomas, “MDA: revenge of the modelers or UML utopia?,” IEEE Software Journal, vol. 21, pp. 15‐17, 2004.[9] S. Kent, “Model Driven Engineering,” Integrated Formal Methods, Springer, 2002, pp. 286‐29[10] M. Brandel, “The Trouble with Cloud: Vendor Lock‐in ‐ CIO.com,” www.cio.com, Apr. 2009.


July 7, 2010 21/07/2010 ECE Presentation G1 1ltahvild/courses/... · – service‐to‐service...

Documents

Transcript of July 7, 2010 21/07/2010 ECE Presentation G1 1ltahvild/courses/... · – service‐to‐service...