activityamazonec2

CloudResources-Events-AgentsModel:TowardsTOSCA-BasedApplicationsSoheilQanbari1,VahidSebto2,andSchahramDustdar11TechnicalUniversityofVienna{qanbari,dustdar}@dsg.
tuwien.
ac.
athttp://dsg.
tuwien.
ac.
at2Baha'iInstituteforHigherEducation(BIHE){vahid.
sebto}@bihe.
orghttp://www.
bihe.
orgAbstract.
Thedilemmafordomainexpertsanddevelopersduringde-signtimeofacloudapplicationisensuringthesucientprogrammingabstractionsbetweentheminmappingthebusinessrequirementstocloudspecications.
Thus,amodelinglanguageisneededtocaptureandexpressthebusinessrequirements.
Resources-Events-Agents(REA)isawell-knownbusinessrequirementmodelinglanguagethatdecomposestheinformationsystemintothreeconstituentswiththesetofcompliantbinarycollaborationscalled,Duality.
ThisstudyisapreliminaryattempttoemployREAfordevelopingcloudapplications.
Inthisstudy,wede-neaconceptualmappingbetweenREAmodelandOASISTopologyandOrchestrationSpecicationforcloudApplications(TOSCA)poli-cies,plansandtemplates.
Basedonthat,weproceedwiththeprocessofbuildingbusiness-drivencloudapplications.
Insupportofourmodel,weimplementacloudREAModelingtoolreferredtoasCREAM,wherebusinessrequirementsarespeciedinREA,thencorrespondingcloudapplicationiscomposedandbuilt.
Wedescribetheunderlyingmappingstrategyaswellasthedetailsofourtoolinsupportoftheproposedapproach.
Keywords:Cloudapplication,Resources-Events-Agents(REA),TOSCA,Businessrequirements.
1IntroductionThecloudabstractionmodeldeliversasharedpoolofcongurablecomputingresources(processors,storage,applications,etc.
)thatcanbedynamicallyandautomaticallyprovisionedandreleased[1].
Thiselasticdeliveryofcloudre-sourcesimprovesbusinessagilitybyenablingtheproviderstorespondfastertothedemandingneedsofthemarkets.
Firmsbenetfromthisasanenablerinde-velopingadaptivebusinessmodelsbuiltuponcloudapplicationsthatmeetbothbusinessandcustomerneeds.
Thus,theycanorchestrateprocesses,(de)allocateresources,(de)provisionservicesandseamlesslyadapttotheconstantlychangingM.
Villarietal.
(Eds.
):ESOCC2014,LNCS8745,pp.
160–170,2014.
IFIPInternationalFederationforInformationProcessing2014CREAM:CloudResources-Events-AgentsModel161requirementsoftheirclients.
Cloudadaptivebusinessmodeling,poseschallengesofperforminganongoingassessmentstoensurecomplianceandalignmentbe-tweenbusinessrequirementsandsystemspecications.
Inarchitectingcloudapplications,thecloudmarket-leader,Amazonwebser-vices(AWS),oersaCloudFormation1servicewherewecancreateastacktoseamlesslyprovisionthecollectionofresourcesrequiredbyapplications.
WecandeployCloudFormation'stemplates2orcreateourowntemplatestodescribetheAWSresourceswithassociateddependenciesorruntimeparameters,requiredtorunourapplications.
Thecloudmanagementplatform,OpenStackprovidesaservicecalledHeat3toorchestratemultiplecompositecloudapplicationsusingtheAWSCloudFormationtemplateformat,throughbothanOpenStack-nativeRESTAPIandaCloudFormation-compatibleQueryAPI.
TheHeatengine'smainresponsibilityistoorchestratethelaunchingoftemplatesandprovideeventsbacktotheAPIconsumer.
Onasimilarservice,theUbuntuopen-sourcecommunity,providesUbuntuJuJu4,aserviceorchestrationmanagementtoolwherewecandenethetechnicalrequirementsandspecicationsofourcloudapplicationandproceedwithitsdeployment.
Similarly,theopenTOSCA5pro-videsacontainerwherewecandeneandrunourTOSCA-basedcloudapplica-tionimplementationartifactscomposedintothecloudServiceArchive(CSAR)lewhichincludestheservicetopologyanditsimplementationplans.
Sucetosaythattheseinitiativesaremorefocusedoncapturingtechnicalre-quirementsratherthanbusinessmodels.
Suchsolutionsareappropriateforcloudapplicationdevelopersandposelimitationsforbusinessdeveloperswhoknowthedomainknowledgebestbutwithlimitedprogrammingskills.
Thereareseveralwell-establishedbusinessmodelingframeworks,includinge3-value[3],Resource-Event-Agent(REA)[4]andtheBusinessModelingOntology(BMO)[5].
Thesemodelsallowshorterdevelopmentcyclesandfastertimetoproductsandvalue.
However,atthemoment,tothebestofourknowledge,thereisnoengagementbetweenthecurrentbusinessmodelingframeworksandcloudcomputingbusi-nessmodels.
Inthispaper,weprovidethismappingandultimately,showhoweectiveourtoolingis.
Insummary,ourcontributionistwofoldasfollows:–Analyzingthecontemporarybusinessmodelingframeworksonwhichrmsbasetheirserviceidentication,specication,andrealizationstrategies.
–ThemappingrulesbetweentheREAmodelandtheTOSCAmodel.
Weimplementatoolinsupportofthesecompliancerules.
ThepapercontinueswithabackgroundinthecloudREAmodelinsection2insupportofproperpositioningoftheCREAMtool.
Section3introducestheREAbusinessmodelingframeworkasaninputmodel.
Insection4TOSCAspec-icationsasanoutputmodelaredetailed.
Section5presentstheactualcontribu-tionofthepaper,theconceptualmappingrulestogetherwiththeirsupporting1http://aws.
amazon.
com/cloudformation/2http://aws.
amazon.
com/cloudformation/aws-cloudformation-templates/3https://wiki.
openstack.
org/wiki/Heat4https://juju.
ubuntu.
com5http://www.
iaas.
uni-stuttgart.
de/OpenTOSCA/indexE.
php162S.
Qanbari,V.
Sebto,andS.
Dustdarfacts.
Next,theCREAMtoolarchitectureispresentedinsection6andasampleuse-casescenarioisgiventosupporttheeciencyandutilizationofourtool.
Subsequently,section7surveyssomescienticrelatedwork.
Finally,section8concludesthepaperandpresentsanoutlookonfutureresearchdirections.
2RelatedWorkInrelationtoourapproach,therearesomeprominentapproachesfordeningthecloudvaluechainreferencemodel[7],likeani6,agoal-orientedsocialmodelingframeworkforlinkingbusinessmodelstotheirsupportingservicesandprocessmodelsbyJaapetal[8]andRameletal[9].
Intheirapproach,rst,thebusinessrequirementsaremodeledwiththeinotationandthenbusinessservicesarederived.
Inthesecondphase,theidentiedservicesarerenedaccordingtotheserequirementsusingUMLactivityandclassdiagrams.
Onasimilarapproach,Gaillyetal[10]denedasetofbusinessrulestotransformtheREAmeta-modelintoaUMLclassdiagramwithaccompanyingOCLconstraints.
Schusteretal[11]leveragesmodeldrivendevelopmentandprovideamappingfromREAtoUMM.
Insupportofthismapping,Sonnenbergetal[12],developedadomainspecicmodelinglanguagecalledREA-DSL.
AnothermoreconceptualapproachexploitingservicescienceperspectiveonREAbusinessmodelingisintroducedbyRoelensetal[13].
TheauthorsspecifysixdesigncriteriatoevaluatetheabilityofREAbusinessmodeltocreateserviceinteractionmodel.
Poelsetal[14]proposetheResource-Service-SystemmodeladaptedfromREAasaconceptualmodelforservicesciencethatemphasizestheservicesystemsinteractionthroughtheexchangeofresourceformoreutilization.
Tothebestofourknowledge,theexistingapproachesdonotaddressthecloudcomputingbusinessmodelsasweaimtodobyamappingfromREAmodelinglanguagetocloudTOSCAmodel.
Next,weexploreeachofthemasaninputandanoutputmodelsofourmappingprocess.
3REA–TheInputModelTheREA(Resources-Events-Agents)modelfocusesonthevalueofbusinessob-jectsexchangedamongpartiesandabstractsawaytheimplementationdetailsofthesystemtobusinessdevelopers.
Figure1,illustratesthecoreconceptsofREA.
Nowwedelveintothecoreconcepts,theirmeaningsandinterdependencies:EconomicResourceisathingthathasutilityforAgents.
Infact,usersneedtodeploy,monitor,andutilizetheresources.
Forinstance,economicre-sourcescanbeproducts,tools,servicesandhumansaswell.
EconomicAgentisastakeholderororganizationcapableofhavingcon-trolovereconomicresources,withaninterestinit.
Agentsdealonresourcesupontheirestablishedservicelevelagreements.
Examplesofeconomicagentsareconsumers,vendors,employees,andthird-partyenterprises.
6http://www.
cs.
toronto.
edu/km/istarCREAM:CloudResources-Events-AgentsModel163Fig.
1.
ExcerptoftheREAmeta-modelandcoreconceptsEconomicEventrepresentseitheranincrementoradecrementinthevalueofeconomicresources.
Someeconomiceventsaredemand,supplyofre-sources.
EventscanbeclassiedintotwopolesofTakeandGive.
Atleastonetakeeventandonegiveeventexistforeachresource.
Whentheeventoccurs,theproviderlosesrightstotheresource,andtheconsumerreceivestherights.
EconomicCommitmentisapromiseorobligationofaneconomicAgenttoperformaneconomicEventinthefuture.
Forexample,lineitemsonasalesorderrepresentcommitmentstosellgoods.
Lackofresourcesleadstounmetde-mandsand,whilereectingtheSLAviolations,leadstonancialconsequencesandpenalties.
EconomicContractisacollectionofincrementanddecrementcommit-mentsandterms.
Thus,thecontractcanspecifywhatshouldhappenifthecommitmentsarenotfullled.
InREA,businessprocessesaretheorchestrationofeventsthatcanbetrig-geredbyagentsaectingtheresources.
Resourcesareexchangedthroughtheseprocesses.
Thenotionofstockowisusedtospecifyinwhatwayaneconomiceventaectsaresource.
REAidentiesvestockows:Produce,Use,Consume,GiveandTake.
Forinstance,theDeploymentprocessoftheVendorspeciesanoutowofResourcesandinowofCashtotheVendor.
ThemodeloftheUsageprocessfromtheperspectiveoftheclientagentisamirrorimageoftheven-dor'sDeploymentprocess.
TheUsagepatternoftheclientspeciestheinowofResourceandoutowofCashfromtheclient.
4TOSCA–TheOutputModelTheTopologyOrchestrationSpecicationforcloudApplications(TOSCA)lan-guageintroducesagrammarfordescribingservicetemplatesbymeansofTopol-ogyTemplatesandPlans.
TherootofaTOSCAserviceistheServiceTemplate.
TheServiceTemplatecontainsadirectedgraphthatrepresentsthestructureof164S.
Qanbari,V.
Sebto,andS.
DustdartheservicecalledaServiceTopology.
Everyservicetemplatehasatleastoneservicetopology.
Thetopologygraphiscomposedofnodesandedges.
Edgesinadirectedgrapharelinkswithadirectionfromnodetonode.
TheedgesinaServiceTopologygrapharebinaryrelationshipsbetweennodes.
Thenodesrep-resentthelogicalcomponentsoftheservice.
Thesenodesandrelationshipsaretemplatesthatarepatternsfortherealnodesandrelationshipsinstantiatedinadeployedservice.
Plansorchestratevariousaspectsofaservicelifecycle.
TheTOSCAspecicationdenesBuildplansandTerminationplans.
BuildPlansorchestratethedeploymentandinstallationofaservice.
TerminationPlansor-chestratedecommissioningofaservice.
DesignersofTOSCA-basedapplicationscanaddplantypesasneeded.
Thedesignerscanbenetbywork-ownotationssuchasBPMNorBPEL.
InourCREAMmodel,TOSCAembodiesthecloudcompositeapplicationdesignanditselasticityspecicationsdirectlyderivedfromthebusinessrequirementsmodelusingREA.
5MappingREAtoTOSCAInthissectionwedescribethemappingfromaREAmodeltoTOSCAartifacts.
Beforewedelveintothedetailsofmodelingandimplementation,itisreasonabletofocusontheunderlyingapproachesaswehavetakenonthemappingprocesstoprovideaholisticviewaboutthesourcemodel(REA)andtarget(TOSCA)artifacts.
Ourapproachistwofold:rst,weproceedwiththeconceptualmappingfromameta-levelperspective.
Second,wedenethemappingrulesofthetwomodelssupportedbytheirimplementationscriptsinthetool.
5.
1ConceptualMappingAmappingfromtheREAbusinessmodelinglanguagetotheTOSCAartifactsisarststepintheprogressofdevelopingbusiness-orientedcloudapplications.
Thissectionformulatessuchamapping.
Todeneamapping,werstdiscoverthemostsuitablematchesforREAconceptsinTOSCA,thenweformulatethisconnectioninruleswhichwillbeformalizedfurtherinthetooling.
WestartwiththeeightconceptsderivedfromtheREAascoreconcepts.
AslistedinTable1,weidentiedthefollowingeightrules.
5.
2MappingRules(M.
R.
)M.
R.
1:Resource,indicatethingsthatareaectedorexchangedinprocesses.
Forcloudapplications,softwareservicesorinfrastructureresourcesexpressthesamesemantics.
ItcanbespeciedbynodeTemplateandnodeTypeelementsinTOSCA.
Forinstance,anodeTypeofApacheWebServercanbeinstantiatedbyanodeTemplateofMoodleAppServer.
M.
R.
2:Event,isnestedwithinaneconomicExchange.
Theseeventsareini-tiatedbyAgentsaectingaResource.
InTOSCA,thenodeTypeshaselementCREAM:CloudResources-Events-AgentsModel165Table1.
MappingRulesfromREAmodeltoTOSCAartifactsNoRulesREAConceptsTOSCAConcepts1ResourceEconomicResourceNodeTempalate2EventEconomicEventInterfaceOperation3ExchangeEconomicExchangeRelations/Plans4EntityEconomicAgentRoles5ContractContract/CommitmentPolicyTypes6DualityExchangeDualityRelationTypes7LinksStockow,Inow,OutowRelationsTypes8PackTypication,GroupingServiceTemplatesofInterfacesinwhicheachinterfaceincludessomeOperations.
Forinstance,re-leasingorallocatingstorageresourceunitfrom/toaVM.
M.
R.
3:Exchange,isavalueorresourceExchangewithpairofeconomicEventslinkedbyDualityrelationship.
ItismappedtoTOSCArelationTypeandplanswhichdenestheprocessmodelsthatareusedtomanagetheapplicationlife-cycle.
InTOSCA,aplanisasetofoperationsexposedinasequenceowbytheservicetemplate.
Bothconceptscontainthebusinesstransactions,resourceexchange,events,andagentsthatarenecessarytofulllthebusinessgoal.
ThetypicalTOSCAplansarebuildPlans,terminationPlansandcanbeextendedtomodicationPlans.
M.
R.
4:Entity,isbasicallyaneconomicunitoranAgentrepresentinganactorandthereforemappedtoRoleinTOSCAplans.
Themappingislogicalsincebothconceptssharethesamesemantics.
TOSCArolesareorientedonthreeactorsofcloudserviceDeveloper,ProviderandConsumer.
AneconomicagentinREAandaroleinTOSCAarebothactorswithaninterestinacol-laboration.
TOSCAtypeArtifact,artifactDeveloperandapplicationArchitectarethespecializationoftheservicedeveloperrole.
Cloudserviceproviderhostsandoperatestheapplicationtobeusedbytheserviceconsumer.
M.
R.
5:Contract,detailsanagreementreectedinaneconomicEvent.
TheresourcedeliveryisgovernedbyanassociatedContract,composedofsetofCommitments.
Aneconomiccontractcomprisesagreements,rightsandtermsmadeamongagents.
Commitmentfulllstheexchange-reciprocityapplication.
InTOSCA,thecommitmentscanbedeclaredbytheuseofPolicyTypesandAppliesToelement.
ApolicytypecanexpresstheresourceintendedbehaviorortheQualityofService(QoS)thatanodeTypeisabouttoexpose.
ATOSCAPol-icycanalsoexpressdiversethingslikemonitoringbehavior,paymentconditions,scalability,oravailability,forinstance.
PoliciescaninheritandapplypropertiesbyderivedFromandappliesToelements.
ThusarelevantpolicytypecanshowthespeciedbehaviorofaresourceinaContract.
166S.
Qanbari,V.
Sebto,andS.
DustdarM.
R.
6:Duality,alsonestedwithinaneconomicExchangeandtheEventholdingthisassociationtriggerstheresourceexchange.
Dualitycanbeusedtomodelmany-to-manyrelationshipsbetweenanytworesources.
ThisallowsGive&Takeoperationstoincreaseordecreasetheamountofresourceallocation.
Dualityimplementstheelasticitybehaviorofthecloudapplication.
Thus,themessagingamongtheresourcesshouldbepairedviaadualityrelationshiptobindeventstogetherwiththeresourceexchange.
Forinstance,Request&Re-sponse,Demand&Allocate,ServiceAcquisition&ServiceProvisionandPay-perresourceusagecanbeconsideredasclouduse-casesofDualityconcepts.
Inthissense,DualityismappedtoTOSCArelationTypethatidentiesthecorrespondingrelationofaserviceprovisioningeventtoaspecicrequestandpaymentsubsequently.
M.
R.
7:Link,denotesthesemanticsbehindthelinksamongserviceencom-passedcomponents.
TheStockowassociationdenotestheowofresourceex-changetriggeredbyaneconomiceventslikeincrementordecrementresourceallocation.
Therelationshipbetweenanincrementeventandaresourceiscalledinowandtherelationshipbetweenadecrementandaresourceiscalledoutow.
Forinstance,invendor'ssalesprocess,theexchangewillrepresentanoutowofresourceandaninowofcashinreturn.
InTOSCA,therelationshipspeciesthesemanticsbetweennodesofsourceElementandtargetElementinatopologytemplate.
TheREArelationscanbemappedtotheTOSCArelationTypeslikedependsOn,hostedOnanddeployedOnconcerningthecontext.
M.
R.
8:Pack,isacourseorprincipleofcompositionaction,adoptedbyGroupingandTypicationabstractionsintheREAapplicationmodel.
Typi-cationimplementsa-kind-ofelement,groupingrealizesa-member-ofapplica-tions.
Thisformsacompositeapplicationwhichwillbedeployedundercertainpolicies.
HybridassociationofTypesandGroupingsdenesthePolicyLayerontopoftheOperationLayerinthemodel.
InTOSCA,apolicytypedenestheconstraintsofaproperty,i.
e.
datatypes,allowedvalues,obligationsandauthorizationrequirementsinacorrespondingtemplate.
6Implementation:CREAMToolSupportTheaimofthistoolkitistoprovideaframeworktofacilitatethemodelinganddeploymentofcloudbasedapplications.
Ourtoolkitprovidesawebinterfacewhichhidesandabstractsawaythecloudimplementationdetailstobusinessdevelopers.
CREAMcapturesthesystemrequirementsandtheirrelationships,thenbuildsthecloudapplicationtopologyinTOSCA.
TheCREAMisaJava-basedwebapplicationwhichisdevelopedinWSO2DeveloperStudio7.
WeusedMaventoresolveitsdependenciesanddeployedCREAMonWSO2ApplicationServer.
CloudresourcesarestoredinWSO2GovernanceRegistryincompliancewithTOSCAstandard.
Allresourcesandartifactsarelocatedin"/cream"path7http://wso2.
com/products/developer-studioCREAM:CloudResources-Events-AgentsModel167intheregistryandcategorizedintwocollections:(i)TOSCATemplates:thiscollectioncontainscloudandREAresources.
Forinstance,InstructorismappedtoaTOSCANodeTypewhichislocatedinhumanresourcescategory(HuaaS).
Foreachresourceandcollectionin"/cream/ToscaTemplates",atitleissetinregistrythatwillbedisplayedinCREAMToolcanvas,otherwisethenameoftheresourcewillbeused.
(ii)CSAR:thecloudtopologiesdesignedbybusinessandapplicationdeveloperswillbestoredinthiscollection.
EachdesignedtopologyisaTOSCAXMLlenamedwithaUUIDandcontainsaServiceTemplate.
Thiscontainsallrequiredinformationaboutservicesandresourcesrequestedbytheuser.
6.
1CREAMArchitectureNow,wedetailthearchitecture.
WedevelopedtheCREAMToolkitbasedonaModel-View-Controller(MVC)designpattern.
MVCframeworkisdesignedaroundaDispatcherServletthatdispatchesrequeststohandlers.
InCREAM,Dispatcherservletisresponsibletohandlerequestsandresponses.
Itdelegatesre-queststocontroller(i.
e.
,classCloudApplicationDesignerController).
Controllerclassisidentiedby@Controllerannotationandhasmethodstohandleincomingrequests.
EachURLismappedtoamethodannotatedwith@RequestMapping.
Thismethodexecutestheuserrequests,generatesamodelobjectandreturnsittodispatcher.
Dispatchersendmodelstoviewtemplatewhichisresponsibletorenderresponse.
Finallydispatcherreturnsrenderedresponsetouser.
Forthesakeofbrevity,weonlydescribethepackagesandclassestoclarifytheCREAMarchitectureasillustratedinFig2.
Fig.
2.
CloudREAModel(CREAM)architecture168S.
Qanbari,V.
Sebto,andS.
Dustdar6.
2PackageDescriptionInthissection,wedescribethepackages,theirbundledclasses,andimplementedinterfacestosupporttheCREAMarchitecture.
Packageorg.
cream.
commonsThispackageincludesexceptionclasses,simpleclassesforJaksonObjectMap-perandotherhelperclasseswhicharecommoninwholeapplication.
ItscoreclassesareApplicationConguration,ServletContextHelper,ResourceObjectMap,andDesignedApplicationObjectMapItem.
TheApplicationCongurationisre-sponsibletoreadcongurationleandmakeitsentriesaccessiblebyothercomponentsoftheapplication.
TheApplicationCongurationusestheServlet-ContextHelperclasstondtherealpathofthecongurationle.
BothclassesaredesignedusingSingletonpattern.
Packageorg.
cream.
tosca.
modelThispackagecontainsJAXBgeneratedclassesfromTOSCAXMLschema(XSD).
Italsocontainsasub-packageorg.
cream.
tosca.
model.
propertieswhichincludesJAXBgeneratedclassesforourdenedpropertiesschema.
Thereareseveralsub-packagessuchasorg.
cream.
tosca.
model.
properties.
amazonec2whereaseachpackagecontainsJAXBgeneratedclassesfromaspe-cicpropertiesXMLschemale.
WeusePropertieselementinTOSCANode-Templatetostorespecicationsofeachresource.
Wehavedenedtheseprop-ertieselementsforeachresourcewithXMLschema.
ForeachXMLschema,wehavegeneratedcorrespondingclassesusingJavaAPIJAXB.
Allpackagesinorg.
cream.
tosca.
model.
propertiescorrespondstooneschema.
Packageorg.
cream.
wso2.
gregThispackagecontainshelperclassestoconnecttoWSO2GovernanceRegistryandtoretrieveresourcesandcollections.
ClassGovernanceRegistryConnectorisresponsibletomakeconnectiontoWSO2GovernanceRegistry.
Methodge-tRemoteRegistryreturnsaninstanceofclassRemoteRegistrysincetheregistrydataretrievalAPIsaredenedhere.
ClassGovernanceRegistryReaderisrespon-sibletoreadandwriteresources.
Packageorg.
cream.
tosca.
loaderClassesofthispackageworkswithJAXBgeneratedclasses.
TheyextractTOSCAelementsfromTOSCAlesandgenerateTOSCADenitionsandCSARles.
ClassJAXBMetaDataExtractorusesJavaReectionAPItoextractprop-erties'elementnamesfromJAXBpropertyclasses.
ClassToscaFileReadermar-shalsTOSCADenitionsfromthegivenInputStream.
ItalsoprovidesafewhelperclassesforentireapplicationtoretrieveneededinformationaboutaTOSCAXMLle.
ClassToscaBuilderisresponsibletogeneratenalTOSCAdenitionobjectfromuser-denedtopology.
Finallythisclassconvertsthegen-eratedTOSCADenitionstoitsXMLstringandstoresitinWSO2GovernanceRegistry.
CREAM:CloudResources-Events-AgentsModel1697ConclusionandOutlookSofar,wehaveusedtheREAmodeltospecifythebusinessrequirements,con-straintsandrulesforbuildingcloudapplications.
Insupportofourapproach,wedevelopedtheCREAMtoolinwhich,initiallydoestheconceptualmappingandbuildtheTOSCA-basedcloudapplication.
Asanoutlook,ourfutureworkincludesfurtherextensiontotheCREAMtoolthatcanalsosupporttheREA'sstructuralandbehavioralbusinesspatterns[15]atpolicy,operationalandaspectlayerstoprovideamoreholisticcoverageofthevariousperspectivesrelevanttoapplicationdevelopmentprocess.
Summarizing,weenvisioncloudREAModelasapotentialcloudvaluemodelingframeworkforbuildingbusiness-drivencloudapplications.
References1.
Papazoglou,M.
P.
:Cloudblueprintsforintegratingandmanagingcloudfederations.
In:Heisel,M.
(ed.
)SoftwareServiceandApplicationEngineering.
LNCS,vol.
7365,pp.
102–119.
Springer,Heidelberg(2012)2.
Osterwalder,A.
,Pigneur,Y.
,Tucci,C.
L.
:Clarifyingbusinessmodels:Origins,present,andfutureoftheconcept.
CommunicationsoftheAssociationforInfor-mationSystems16,article1(2005)3.
Gordijn,J.
,Akkermans,H.
:e3-value:Designingandevaluatingebusinessmodels.
IEEEIntelligentSystems16(4),11–17(2001)4.
Mccarthy,W.
E.
:Thereaaccountingmodel:Ageneralizedframeworkforaccount-ingsystemsinashareddataenvironment.
TheAccountingReview57(3),554–578(1982)5.
Iso:Informationtechnology-businessoperationalview-part4:Businesstransac-tionscenarios,iso/iec2007,iso15944-4(2007)6.
Oasis,un/cefact:ebxml-technicalarchitecturespecication,version1.
4(February2001)7.
Mohammed,A.
B.
,Altmann,J.
,Hwang,J.
:Cloudcomputingvaluechains:Un-derstandingbusinessesandvaluecreationinthecloud.
In:EconomicModelsandAlgorithmsforDistributedSystems,AutonomicSystems,pp.
187–208.
Birkh¨auser,Basel(2010)8.
Gordijn,J.
,Yu,E.
,vanderRaadt,B.
:E-servicedesignusingi*ande3valuemod-eling.
IEEESoftware23(3),26–33(2006)9.
Ramel,S.
,Grandry,E.
,Dubois,E.
:Towardsadesignmethodsupportingthealignmentbetweenbusinessandsoftwareservices.
In:33rdAnnualIEEEInterna-tionalComputerSoftwareandApplicationsConference,COMPSAC2009,vol.
1,pp.
349–354(2009)10.
Gailly,F.
,Geerts,G.
:FrederikGaillyandGuidoGeerts.
Formaldenitionofbusi-nessrulesusingreabusinessmodelinglanguage.
In:Proceedingsofthe7thInter-nationalWorkshoponValueModelingandBusinessOntology,p.
7(2013)11.
Schuster,R.
,Motal,T.
,Huemer,C.
,Werthner,H.
:FromeconomicdriverstoB2Bprocessmodels:AmappingfromREAtoUMM.
In:Abramowicz,W.
,Tolksdorf,R.
(eds.
)BIS2010.
LNBIP,vol.
47,pp.
119–131.
Springer,Heidelberg(2010)12.
Sonnenberg,C.
,Huemer,C.
,Hofreiter,B.
,Mayrhofer,D.
,Braccini,A.
:TheREA-DSL:Adomainspecicmodelinglanguageforbusinessmodels.
In:Mouratidis,H.
,Rolland,C.
(eds.
)CAiSE2011.
LNCS,vol.
6741,pp.
252–266.
Springer,Heidelberg(2011)170S.
Qanbari,V.
Sebto,andS.
Dustdar13.
Roelens,B.
,Lemey,E.
,Poels,G.
:Aservicescienceperspectiveonbusinessmod-eling.
In:Proceedingsofthe6thInternationalWorkshoponValueModelingandBusinessOntology,p.
8(2012)14.
Poels,G.
:Theresource-service-systemmodelforservicescience.
In:Trujillo,J.
,etal.
(eds.
)ER2010.
LNCS,vol.
6413,pp.
117–126.
Springer,Heidelberg(2010)15.
Hruby,P.
:Model-DrivenDesignUsingBusinessPatterns.
Springer-VerlagNewYork,Inc.
,Secaucus(2006)