Pattern-based orchestration and automatic verification of composite cloud services

(1)

Contents lists available at ScienceDirect

Computers

and

Electrical

Engineering

journal homepage: www.elsevier.com/locate/compeleceng

Pattern-based

orchestration

and

automatic

veriﬁcation

of

composite

cloud

services

Flora

Amato

a,∗

_,

_Francesco

_Moscato

b a_{DIETI, University}_{of Naples Federico}_{II, Italy}

b_DiSciPol,_{Second University of Naples, Italy}

a

r

t

i

c

l

e

i

n

f

o

Article history: Received 29 August 2015 Revised 7 August 2016 Accepted 8 August 2016 Available online 24 August 2016 Keywords:

Cloud patterns Veriﬁcation Semantics Orchestration

Service level agreeement Quality of service

a

b

s

t

r

a

c

t

Recentyearshaveseenanincreaseofcomplexityinparadigmsandlanguagesfor devel-opmentofCloudSystems.Theneedtobuildvalueaddedservicesandresourcespromoted pattern-basedcompositionand orchestrationasnewhot researchtopics.Anyway, unlike webservices,itisunclearwhat orchestrationmeansforCloudSystems.Inthisscenario, away toautomaticallybuildcompositeservicesfromtheir pattern-baseddescriptionis appealing.Inthisworkwedescribeamethodologyforautomaticcompositionand veriﬁ-cationofCloudServiceswhichisdrivenbyformalorchestrationlanguage.

1. Introduction

CloudArchitectureisnowadaysadefactostandardforprovidinganykindofserviceonInternet.Bigvendors,likeAmazon WebServices (AWS)1 orMicrosoftwithAzure2 aredefinitely themainactors inCloudArchitecturedefinition.In[1]NIST extends themeaning oforchestration to CloudArchitecture. Inaddition,a newtrend inCloud Servicesdesign and man-agement grew up in the last years: the definition of design patterns forCloud Computing. Anyway, the introduction of designpatternsinCloudComputingrequiresaconceptoforchestrationthat ismorecomplexthantheonedefinedin[1]: aswe will show inthiswork manydesign patterns[2]with differentpurposes canbe describedascomplex workflows. Workflowbased compositionopenstheproblemofunderstanding ifa compositeserviceiscompliantwithusers’ require-ments andQoS. Propertiesofcomposite servicesobviouslydepend oncomponents propertiesandcomposition.We think that compliancecannot beevaluated onlyby meansofsyntacticalortype checking.Actually, severalsemantics-based ap-proaches forsimple web servicescomposition exist (asurvey isin [3]).Some of themexploit BPEL4WS [4]orchestration languageandOWL-basedontologiesforservicesdescription.Inthiscontext,itisclearthatamethodologyabletocompose andverifyCloud Servicesby using CloudDesignPatterns is reallyappealing.This isthe reasonforwe propose a formal orchestrationlanguage abletodescribe allelements,eventsandcompositionissueswe needtodescribe complexservices. The language enablespattern-based composition ofCloud elementsat different layers. Inthis way,we reach two goals:

∗ _{Corresponding author.}

E-mail addresses: ﬂ[email protected](F. Amato), [email protected] (F. Moscato).

1_{https://aws.amazon.com} 2_{https://azure.microsoft.com/}

(2)

Fig.1. System architecture.

ﬁrst,ourmethodologyenablesClouddesignerandprogrammerstodescribeinteractions ofcomponentsdirectlybymeans ofpatterns;second, theproposedapproachallowsfortheanalysisofsemanticsandQualityofServices(QoS)ofcomposite servicesandresources.

Thepaperisorganizedasfollows.Section2containsthedescriptionofthemethodologyweproposeandthearchitecture ofa frameworkusedtoenactitssteps.Inordertodescribe patternsandcompositeservicesinSection3weintroducean orchestrationlanguage.Section4discussestheproblemofbindingrealservicesintocompositeservices.Section5proposes afullexampleandSection6containsananalysisofrelatedworks.Finally,Section7reportssomeconcludingremarks. 2. Methodologyandarchitecture

Inthemethodologywearegoing toillustrate,aformal workflowlanguage describescompositionandpatterns.Its for-malsemantics,together witha semantic-baseddefinitionofcloudresources andservices,enablesautomaticcomposition. Patternsgive informationabouthowservicesandresources interactatearlydesign anddevelopmentstages.Thisabstract informationsuggeststhewaytoanalyse,forexample,compositionsoundnessorqualityofservices.Letusconsidera sim-pleexamplewithtwobasiccontrol flowpatterns:thesequenceandthe1outofN.Fromanavailability pointofview,ifN servicesareorganizedinasequence,thefailureprobabilityofthecompositeserviceisthesumofthefailure probabilities ofcomponents,ontheother handinthe 1outofNcomposition, itistheirproduct. Ourworkflow language (Operational Flow Language:OFLinthe following) hassimpleconstructs that canbe used todefine complexCloud Patterns3 [2].OFL isexpressive enoughtodescribeseveralpatterns,aswell assimpleenoughtobedefinedbyaclearoperationalsemantics. ThefinalstepisthemanagementofCloudcompositeservicesaspatternsinstances.

Inordertobindrealservices incompositionskeleton, wehaveto knowtheirfunctionalities andtheirQoSproperties. Ourmethodology supports ontology-baseddescription ofservices by usingOWL-S [5]butit is not enough expressive to characterizegeneralcomposition[4].WethinkthatanInputs,Outputs,Preconditions,Effects(IOPE[6])characterizationof Cloudresources,aswellasasemanticdescriptionofwhatresourcesareandwhattheydo,areusefultochoosecomponents thatbestmatchsemanticsandrequirementsofcompositeservices.Forpropermatchingandontology[7]describesrolesof availableresourcesandservices.Finally,forwhatQoSanalysisandcompositionconcerns,theworkﬂowgraphsdescribedby OFLallowforthecreationofanalysismodelsbyusingModelTransformationtechniques[8].

Fig.1depictsthearchitecturethatenforcesthemethodologypreviouslyintroduced.

TheWF Builder,the IOPEInteroperability Matcher andthe QoSBuilder respectively managegoals of:(a)creating a workflowof compositeservicesfromtheir patter-based description;(b)matching componentservicesintheorchestrated service;(c)analysingQoSofresultingcompositeCloudServices.TheWF(Workflow)BuilderisbasedonaKnowledgeBase oflogicrules containing(a) theOperationalsemanticsofOFL(in therepository WFSemanticRules);(b)theoperational semanticsrulesoforchestrationpatterns(PatternsCompositionRules).TheyareinturndefinedbyOFL.ResultsfromWF BuilderareskeletonsusedtoimplementOrchestratedCloudServices.Properback-endunitscanreadskeletonsinorderto createstubsfordifferentVendorslanguagesandAPIs. InputsfortheServiceInteroperability MatchingareCloud Orches-trationskeletons(declaringhowservicesinteract)andthedescriptions ofcomponentservicesandresources.Descriptions useOWL-SandIOPEgroundingforcloud resources.Inaddition,thedescriptionofservicesfunctionalitiesdependson do-mainontologies(i.e.financialservices,E-Healthetc.).FurthermoreCloudOntology[7]describestherolesofelementsinthe CloudArchitecture.Thedescriptionoftheseontologiesisout ofthescope ofthiswork. Finally,QoSAnalyzer takesCloud OrchestrationandQoSdescriptionsinordertobuildanalysablemodels(byusingQoSCompositionrules).Atthemoment theanalyzersupportsonlyperformanceandavailabilityanalyses.

(3)

Table1

OFL main elements.

Element SubElement Description

Transition ControlFlow Deﬁnes precedences among activities in OFL control ﬂows DataFlow Declares data routing

Event Declares asynchronous events like interrupts

DependsOn Deﬁnes if an element in OFL depends on the existence or the correct execution of another element in process deﬁnition

Handling Declares relationships among Events and their managing activities InstalledOn Deﬁnes where activity-related services are installed

PoolCreate declares that the source activity of this transition may create a persistent instance of a Pool PoolCreateOn Like PoolCreate but it creates services on existing Virtual or physical resources

PoolCreate1S Creates a service and destroys when it ends PoolDestroy Deallocate resources in a Pool

Monitoring Monitors resource PoolInvokeOn Invoke a service in a Pool

Participant Actor Represents an external user for the process: it can send events and/or provide data PhysicalP A physical resource

VirtualP A Virtual Server

Activity Interruptible Deﬁnes interruptible activities: these activities can be target of Event Transitions Handler Handles events. Connected to an event by an Handling Transition

NoReturnH This is a Handler that does not return control to the interrupted activity ReturnH This is a Handler that returns control to the interrupted activity

Resource A Cloud Resource that can execute some operation (for example a storage element) AbstractRes Deﬁnes that the activity is an abstract resource

PhysicalRes Defines that the activity is at physical resource SaaS Defines that the activity is at SaaS layer PaaS Defines that the activity is at PaaS layer IaaS Defines that the activity is at IaaS layer Monitor Defines a monitoring activity Route processes only inner data Process Data Data Simple data like files, streams etc.

Message Data containing messages from an activity to another Inner Data Variable A process variable

Transition Condition predicates that enables ﬁring of transition LoopCond Conditions for Loop blocks

PoolCond Conditions for Pool instantiation and activation Block Structural a simple activities grouping

Loop Activities in a loop

SubProcess Declares sub-processes structures

Pool A Pool is a collection of instances of activities that can be created dynamically. Once a Pool instance is created (by proper transition), it is associated to proper pool condition. Whenever an activity ﬁres to a pool, the ﬁring condition selects the proper instance of resource and services to use

3. OFLsemantics

In thissection we briefly introduce the basicelementsandoperational semantics ofOFL. Then, we show how OFLis expressiveenoughtodescribeCloudPatterns.OFLisaworkflow-basedlanguage:itconsistsofagraphofactivities, partici-pantsandtheirproperties.AnActivityrepresentsonelogicalstepwithinacompositeprocess.Thecompletionofanactivity andthestartingofanotheroneisatransitionpointintheworkflow execution.Transitionsmaybeunconditional,butthe order ofexecution ofactivities atrun-timemay depend on one ormore logical expressions calledtransitionconditions. Conditions areevaluated whenactivities start andendandtheir valuesaffectthebehavioursofactivities. Moreindetail, Table1liststhemainconstructsofOFLandtheirmeanings.

Dependencies existamong elementsin differentgroups. Forexample, ControlFlow transitions can be connectedonly to activities;transitionconditions existonly inControl Flow etc. Weomit hereall dependences forbrevity. Some points exists within the workflow that allow forthe control ofactivities execution:AND-split is a point where a singlethread ofcontrolsplits intotwoormorethreadswhichare executedinparallel.AND-join isapointwheretwoormoreparallel activitiesconvergeintoasinglethreadofexecution.XOR-splitisadecisionpointwhereonlyoneofalternativebranchesis executed.XOR-joinisapointintheworkflowwheretwoormoreparallelactivitiesconvergeinasinglethreadofexecution withoutsynchronization. OR-splitisadecisionpointbetweenseveralalternativeworkflow branches.OR-joinisa pointin which several alternative branches re-convergeinto a singlethread. In the following XOR, AND and OR are called Split or Join Conditions. Thereforein the OFLlanguage, workflow processes consist of a graphof nodes(activities) and edges (transitions)identifiedby apairofnodes(From,To).Handling transitionsaretheonlyexception sincethey connectEvent Transitions toHandler Activities. Activitiesrepresentatomic CloudServiceexecution orresource uses.Types of elements

(4)

Fig.2. OFG example.

inOFLgraphs (OperationalFlowGraph: OFG)aredepictedasstereotypes(i.e.reportedinsidedouble-angledbrackets). An exampleisinFig.2thatreportstheOFGofaninstanceoftheCompensatingTransactionPattern.

Theworkﬂowhereisreallysimple:itincludesonlySaaSactivitiesandControlFlowtransitions,hence,weomitted stereo-typesforsimplicity.Transitionsconditionsarereportedneartherelatedtransitions.Ifthey miss,wealways evaluate con-ditionstrue.Intheﬁgure,Err andNoErr aretruewhenan errorornoerrorsrespectivelyoccursduringtheexecutionof thefromactivity.Obviouslytheyaremutuallyexclusive:anXORsplitassuresthatonlyonebetweencompensatingandnext activitiesareabletoexecute.Ifatheserviceexecutesacompensationactivity,itexecutesthefollowingcompensationstoo.

3.1. MappingCloudPatternstoOFLgraph

OFGs represent executableprocesses that can be easily implemented in differentCloud environments. We only need a wayto generalize OFG inorder torepresent CloudPatterns. Some patterns are not parametricin terms ofcomponent servicesandanOFGisenoughtodescribethem.Moregenerally,aCloudPatternisaparametricgraphwhereservicesand resourcesinvolvedininstancesmodifythepatterntemplate.Inordertoallowforautomaticcomposition,wemusttranslate patternsintoOFGs.The mainstructureofa patternisaparticularBlock,calledTemplate.Wehavedeﬁnedanimperative languagecalledPatternGroundingLanguage (PGL)inordertodescribeBlocksreplicasandgroundings.Wedonotdescribe PGL herefor brevity: its main features are the abilityof deﬁning sets (lists) ofServices that are grounded intoan OFG that describespatternsinstances.A properfunction, connect,linksservicesandresources each other by means ofproper Transitions.LetusconsidertheCompensationPattern:aDesignerwoulddescribethepatterninthefollowingway:

compensation₋pattern

(

S,Ser

v

ices,Compensating,E

)

whereServicesisalistofnormalservicesandCompensatingisthelistofservicesthatcompensatetheonesinServices.Sand

Eare thestartandendactivities respectively.The generalcompensationpatternisaBlockcoupledwithaPGLdeﬁnition. Fig.3reportstheOFGandthePGLdescriptionforcompensationpattern.

ItissimpletoprovethatthePGLontherightofFig.3,invokedwithparameters: Compensation

(

S,[A,B,C],[CA,CB,CC],E

)

producestheOFGinthebottomofFig.2. 4. Conditionspropagationandsemantics

Inprevioussectionsweoutlinedthatweareinterestedinpattern-basedcompositionandorchestrationofCloudservice. Startingfrom anabstract pattern-based descriptionwe provide asets ofrules ableto translate pattern-based description intoa workflow process. Compositionmust be verified in orderto understand ifcomponents match inputs, outputs and semanticsrequiredbyother connectedelements. Matchingispartofverificationprocessthatshould controlifInputsand Outputs are inthe rightformat forconnected elementsandif semantics ofCloud Servicesandresources arecorrect. At this purpose,we inherit some Web Servicelanguages andmethods: the Semantic Web Community created OWL-S [9], andmatchingalgorithms, methodsandtoolsbasedonIOPE(Inputs,Outputs,PreconditionsandEffects)analyses [10].The matchingprocess requires theexistence ofa Knowledge Base KB and ofa set of Inference Rules IR. A formal, explicit descriptionoftheDomainisgivenbyOWLandOWL-S.WithreferencetoFig.1,

(5)

Compensation(S, Services, Compensating, E) :

P rec(C) =

size(Services) ==size(Compensating)

Condition_Cok = List[size(Services)] ConditionCerr = List[size(Compensating)] foreach (c_{1 :}_{Cok, c}_{2 :}Cerr):

c₁.value=true;c₂.value=true;

sH=head(Services);_sT =tail(Services);

C=reverse(Compensating);

foreach (srv:Services;cmp:C;ok:_{Cok, err}:Cerr):

if(srv==_sH) : connect(srv,cmp,ControlFlow,err); connect(S,srv,ControlFlow,“true”); else if(srv==_sT) : connect(srv,E,ControlFlow,“true”); connect(srv,succ(srv,Services),ControlFlow,ok); connect(srv,cmp,ControlFlow,err); foreach (srv:Services):

srv.J oinCond=AN D;srv.SplitCond=XOR;

S.SpliCond=AN D;E.J oinCond=XOR

Fig.3. Compensating pattern OFG and PGL.

ElementsinKB are axiomsderivedfroma Domainontology.Relationshipsamong dataandoperationsdepend onthe semantic descriptionof operations, Pre-conditions, Effects, InputsandOutputs. Rulesfor reasoningon _KB are deﬁnedin operationalsemantics.IRcontainstherulestoapply inordertobuild validOGintermsofIOPEs.Theinferencerulesdo notdependontheDomain.NoticethatmatchingdependsonlyonOFGstructure.Hence,aCloudresourcecanbegrounded toan activityif:(a)its Inputformats(ifany)meet Outputformatsofresources andservicesofincomingactivitiesinthe OFG; andif:(b)AllofitsPreconditionsare satisﬁed.Input andOutputmatchingisrelativelysimpletoanalyse aswell as I/Oproblemsarequitesimpletomanage:iftherequiredinputisnotavailable,probablythewholeprocessisnotcorrect;if therequiredinputexistsbutindifferentformat,properwrapperscanbeusedinordertotranslatedataformats.

PreconditionsandEffects(PE) aremorediﬃculttomanage.Theyaredeﬁnedby logicpredicatesandtheyexpress con-ceptspresentbothinCloudOntology(CO)andDomainOntology(DO)(seeFig.1).AftertheexecutionofaCloudService,some thingsmayhappenorchange:thesearetheEffectsthattheserviceproduces.ExecutionofCloudServicesmaychangethe truth value ofsome predicates:thismeans that thePE matching dependsonOFG too:a runningcomposite servicemay evaluatesome predicatestrueorfalseaftertheexecutionofany activityintheOFG.Meetingofpreconditionsis assuredby servicespreviouslyexecutedatanytimeinthecompositeprocessandconditionvaluesmaychangeduringitsexecution.

ThisisaneffectwecallConditionPropagationanditprovidesameantodescribethesemanticsofthewholecomposite service.

Solvingthematchingproblemrequiresthataresourceorservice:(a)acceptsalltheinputsrequiredbytheIOPE speci-ficationofanode intheOFG,(b)producesalloutputsrequiredbytheIOPEspecificationofanodeintheOFG,(c)satisfies all preconditions required by the IOPE specificationof a node inthe OFG, (d) produces all effects requiredby the IOPE specificationofanodeintheOFG.

The real problem is to understand if a Composite service is soundin terms of IOPE matching. Checking of adjacent elementsinanOFGissimple:Outputsofincomingnodes,mustcomplywithInputsneededbythenode wearechecking. TheproblemofPEmatchingismorecomplex:foreachnodeinthegraph,thematchermustanalysemanypredicatesinthe workﬂowgraph.Aneffectenablesnewpredicatesorchangestruthvaluesofexistingones.Inaddition,andthisisthecase ofourexample,duringtheexecutionofacompositeservice,somepredicatesmaychangetheiruniﬁcationwithvariables.

Preconditions ofan activity depend on Effectsof activities executed before. Anyway, the set of these activities is not uniquely determined: thanks to different Join andSplit conditions instances ofan OFG run across different paths ofthe graph(forexamplethishappensatORandXORsplitpoints).

LetPrec(N)andEff(N)bethesetsofpreconditionsandeffectsrespectively,foranodeNintheOFG.Letuscall: e

v

al

(

p

)

−→

{

true,f alse

}

,p∈Prec

(

N

)

orE ff

(

N

)

thefunctionthatevaluatesatruthvalueofapreconditionoraneffect.

Let us consider the sets PL (predicates lists) composed by the couples (pnode_, _eval₍_pnode₎₎ _where _pnode _∈

Prec(node)∪Eff(node)andeval(pnode_).

PLnode₌

_{

_pnode 1 ,e

v

al

(

pnode1

)

,· · ·,

pnode n ,e

v

al

(

pnoden

)

}

Weconsidertheunionofpreconditionsandeffectsbecause,forConditionPropagation,weassumethat,inordertobind arealserviceintotheworkﬂow,itmustmeetallpreconditionsand,afteritsexecution,itmustproducealldeclaredeffects. The important isto understand ifa servicecan avoidmeeting a precondition becauseof ConditionPropagation. We call PHnode_(Possibly_Happens)_the_set_with_all_possible_{conﬁgurations}_of_predicates_lists_(i.e._predicates_with_their _evaluations)

(6)

foranodeintheOFG. PHnode₌

_{

_P_Lnode

1 ,· · ·,PLnoden

}

NoticethataPLnode_in_PHnode_contains_all_predicates_(with_their_evaluation)_evaluated_before_the_execution_of_node

activ-ity(wecallthisset:_PHnode

be f ore)aswellasitsEffects.Thesemayeventuallysubstitutethetruthvalueofpredicatespreviously

evaluatedinthecaseEffectscontainpredicatesthathavebeenalreadyconsidered.IfEffectscontainnewpredicates,theyare addedtoallPLsinPH:if PHnode be f ore=

{

PL node be f ore1,· · ·,PL node be f orek

}

letE ffcommon_i

(

node

)

the set containingall predicates (and their evaluation) inPLnode_{be f ore}

i∈PH

node

be f orethatare inEff(node) even

withsameordifferentevaluation. PHnode₌

_{

_P_Lnode

be f orei−E ffcommoni

(

node

)

∪E ff

(

node

)

}

,i∈

(

1..k

)

Inbrief,we addneweffectswithproperevaluationtoeachPredicateList andeventually wesubstituteold evaluationsin theEffectslist.MultiplePLsinPHsetrepresentthefactthatOFGmaycontaindifferentpathsfromastarttoendpoints. Thisobviouslyhappenswhenthecomposition containschoicesorconditional executionofpaths,buthavingmultiplePLs isuseful alsoin parallel paths when they managespreconditions andeffects of the samepredicates. IfOFG is a simple sequenceofnodes,foreachnode,thecardinalityofPHis1foreachnodeinthesequence:card

PHnode

₌₁

_∀

_node_∈_OF_G_.

Thisbecauseinasimplesequenceofnodesthereisalwaysonepossibleevaluationofpredicates.Anyway,formorecomplex OFGs,wehave:

card

PHnode

_≥₁

_∀

_node_∈_OF_G

Letusnowdescribe howPHnode _sets_are_built_for_all_nodes_in_OFG._We_visit_all _the_OFG_from_the_start_to_the_END_points

updating PL sets: updatesdepend on Effects andSplit and Join points in the OFG.The simplestcase, aswe introduced before,isthepuresequencepathinOFG.Ifwehavetwonodesinasequence(letuscallthemAandB,withBfollowingA

inthegraph),withAasstartpointandBtheendpoint(i.e.agraphwithonlytwonodes),wehave: PHB₌

_{

_P_LB i =

PLA_i ∪

(

e

v

al

(

Prec

(

B

))

−E ffcommon

(

B

)

∪E ff

(

B

)

}∀

PLA i ∈PHA

Noticethat,ifAisastartingpointintheprocess: PHA₌

{

_e

_v

_al

₍

_{E f}_f

₍

_A

₎

_∪_P_rec

₍

_A

₎

}

IftheinplaceofAamorecomplexgraphexists,wemustdistinguishtwocasesforBdependingonitsjoincondition.The ﬁrstcaseiswhenthejoinconditionofBisORorXOR:Here,wecanbuildthesetPHB

be f oreandthenthePHBwiththerule

previouslyreported. PHB be f ore= t∈incoming(B)

PHf rom(t)_∪_e

_v

_al

₍

_P_rec

₍

_B

₎₎

InXORandORjoin, simplyallprevious preconditionslists (inall incomingpaths)areconsidered.Notice thatiftwo pre-conditionslists exist withboth sameprecondition andevaluation, their union resultsin an unique PL.The other caseis whenthejoin conditionofBisAND.Thisismorediﬃcultto managebecause twofurthercases arepossible: (1)theset ofpredicatesthat changefromthesplitnodeofparallel incomingpaths, duringpaths executionsaredisjointondifferent paths;(2)somepredicatesareintheEffectssetsofnodesbelongingtodifferentparallelpaths.

LetSPNbethenameofthe(split)nodewheretheparallelpathsbegin,andJPNthejoinpointweareconsidering.Letus call

CHnode₌

_{

_predicates_∈_f_irst

₍

_P_Lnode

₎

_:

PLnode_∈

_{

_PHnode₋_PHnode be f ore

}

thelistofpredicatesthatchangetheirevaluationorthatareinsertedintopredicatelistsaftertheevaluationoftheeffects inanode(ﬁrstfunctionhereselecttheﬁrstelementinacouple).Ifweconsideragenericpath

φ

intheOFGterminatingin

node,wecandeﬁnetheCHnode _set_for_a_whole_path:

CHnode

φ =

node∈φ

CHnode_.

Intheﬁrstcase,wehave:

φ∈SPNincomingpaths

CHnode

(7)

Fig.4. PE matching example. And PHJPN be f ore=

{

PLi=PLi−

{

(

pk,e

v

al

(

pk

))

:pk∈CH_φJPN

}

(1) ∪

{

(

pl,e

v

al

(

pl

))

∈PLm∈PHI:pl ∈CH_φJPN

}}

∀

PLi∈PHSPN,

∀

φ

fromSPNtoJPN,

∀

I∈ f rom

(

incoming

(

JPN

))

Thismeansthatthe_PHJPN_is_the_same_of_the_PHSPN_except_for_the_predicates_that_have_changed_in_all_JPN_incoming_paths.

Inaddition,predicatesoriginallynotinPHSPN_in_parallel_paths

_φ

_are_added_in_PHJPN _as_well.

Thesecondcaseismorecomplicated:itinvolvesthecasewhenthesamepredicatechangesindifferentparallelpaths.It isusuallyacaseoferroneousdesign(itﬁgureslikeananomaly inatransactionbasedsystem),butweconsideritanyway since sometimesthisbehaviour maybeexplicitlywanted. Letusconsiderapartition

ofall paths

φ

connectingSPNto

JPN:

=

{

NC∪

C

}

,

NC∩

C=∅

where

C isthesetofpathswhereapredicatechangeexists.Inthesecondcasewehave:

PHJPN be f ore=PH JPN be f oreNC∪PH JPN be f oreC (2) PHJPN

be f ore_NC iscomputedasdescribedin(1)butonlyonpathsin

NC.Inaddition,

PHJPN be f oreC=

Inc∈f rom(incoming(JPN))onC PHInc

∪e

v

al

(

Prec

(

JPN

))

WehavenowallelementstounderstandifanOFGissoundintermsof(IO)PEMatching.WeanalyseallnodesintheOFG, buildingforeachnodethesetsPHnode_and_PHnode

be f ore.ThenweanalyseagaintheOFG.Twocasesmayhappen:

∀

node∈OFG,Prec

(

node

)

PLi

∀

PLi∈PHnodebe f ore (3)

∀

node∈OFG,

∃

PLi∈PHbe f orenode :Prec

(

node

)

PLi (4)

AND

∃

j:PLj∈PHnodebe f ore:¬

Prec

(

node

)

PLj

In the case(3), all execution paths allow forthe executionof a servicein nodeif itmeets the speciﬁed Prec(node) pre-conditions.Thecase(4) ismorecomplex:atleastapath existswhereacomponentwithPrec(node) preconditionscanbe executed withoutproblembutatleastone pathexists toowhereaservicemeeting onlypreconditionsinPrec(node) can-not beexecuted.Inthiscase, thematchingalgorithmsalertsusersthat somethingmaygowrongduringtheexecutionof the compositecloud service. Ifthe problemwasan incorrect design, userscan solve the problemby analysing PHnode

be f ore.

Otherwise,propercompensationelementscanbeintroducedinordertocorrectproblematrun-time.

Inorder toprovide an exampleofhow _PH sets arebuilt,let usconsiderFig. 4.It depictsan OFGwherebold letters representnodes(activities) names.Predicates appearitalicizedbeloweach node.Withoutlosinggeneralitywereport here onlyeffects.Thepresenceofthenameofapredicate,indicatesthattheprocessevaluatesittrueaftertheexecutionofthe relatedactivity,whilethepresenceofan exclamationmarkmeansthattheprocessevaluates thepredicatefalse.Splitand Join conditionsare reportedtoo.Theﬁgure showstwocases: intheﬁrstcase, theLPC₌

_{

₍

_P

4,true

)

}

,inthesecond case,

LPC₌

_{

₍

_P

4,true

)

,

(

P2,f alse

)

}

.

Intheﬁrstcase(Fig.5ontheleft),ifPrec

(

I

)

₌

{

Prec1,Prec2,P1,P4

}

wecanbindtoIaservicewithpreconditionPrec

(

I

)

=

{

Prec1,Prec2

}

sinceP1 andP4arepropagatedduringprocessexecution.ThesameservicecannotbindtoIinthesecondcase

(Fig.5ontheright),becausethereisacasewherePHH _that_does_not_contain_P

4andweareinthecaseof(4).Noticethat PHH _describes_the_semantics_of_all_the_composite_process_except_for_the_execution_of_I_.

(8)

Fig.5. Propagation.

Fig.6. Block OFG for Load Balancer.

5. LoadBalancerfullexample

Inthissectionwe describeallsteps neededtoprovideanOFGdescriptionoftheLoadBalancerPattern.4 Then wewill discusshowwestudymatchingontherealizedpattern.Thestepswediscussarethefollowing:(1)wedeﬁneaparametric OFGforthepatternandtherelatedPGL;(2)weanalyzesoundnessforagiveninstanceofthepattern;(3)oncesomeIOPE speciﬁcationforthepatternarereportedontheOFG,weshowhowmatchingisenacted.

Fig.6 showstheparametric OFG forthe LoadBalancer Pattern. Inthe ﬁgure,LBal is theLoad Balancer servicewhich interfaceswithmonitored services;S andVS arerespectively the genericService andVirtualServer wherethe serviceis installed. They are collected in a Block. The Route Activity choose the Service in the Pool forload balancing purposes. It actuallyselects the virtual server withminimal load. This updatesa listof transitionconditions(Cond−Pool):the only

(9)

LoadBalancer(S, Service, V irtualServer, instances, E) : P rec(LoadBalancer) = (size(Services) ==

size(V irtualServers)), type(Service) ==

SaaS, type(V irtualServer) ==P aaS

Saas LBal = SaaS();

Condition_Cbal = List[instances]; Route r = Route(“lbal.alg”); Monitor m = Monitor();

SaaSActivity Services = List[instances]; PaaSActivity VirtualServers = List[instances]; VirtualServerData[] VSD= List[instances]; createInnerDataVector(VSD);

ServiceData[] SD= List[instances]; createInnerDataVector(SD); connect(lbal,r,ControlFlow,true);

foreach (s:Services, vs:V irtualServers, c:_Cbal, i= (1· · ·instances)): bind(Service,s); bind(VirtualServer,v); connect (s,vs,installedOn,0); connect (r,s,ControlFlow,c); connect (s,E,ControlFlow,true); c.value = “false”; connectMonitor(m,vs,monitors,VSD,i);

S.SpliCond=AN D;E.J oinCond=XOR

Fig.7. Load Balancer PGL.

Fig.8. Load Balancer workﬂow.

conditiontrueistheonethatwillconnecttherouteactivityRwithchosen serviceintheBlock.TheMonitoractivityMon storesloadandperformancesmeasuresintheInnerDatarepositoryoftheProcess.

Fig.7reportsPGLdeﬁnitionfortheLoadBalancer;dataﬂowisomittedforbrevity’ssake.Newelementstointroduceare: theinstructionstocreatedataintoInnerDataSection(i.e.VirtualServerDataandServiceData,thatcontainsallinformation neededtorecordmonitoredvalues);thebindfunctionthatlinkaSaaSoraPaaStotherelatedactivity.Noticethatlbal.alg

containsthetextthatappearsintherouteactivitybox.Ifweinstancesthispatternwith: LoadBalancer

(

S,Ser

v

,VirtSer

v

,2,End

)

thegeneratedworkﬂowistheonedepictedinFig.8.

Thisisthepointwherewedefinethesemanticsofthecompositeservice.Compositeservicedescriptionisdefinedhere intermsofstructure(patternsandOFL).WecanusePreconditionsandEffectsdefinitionsforaddingsemanticsdescriptions. The goal here is to define a Load Balanced GPS navigator service. Hence, load balanced services must compute a path betweentwoGPScoordinates.TheOFGweuseforsemanticsanalysisisinFig.9thatreportsbasic(IO)PEinformationnear eachnode.

(10)

Fig.9. OFG with IOPE for Load Balancer.

Itis easy toprove that theprecondition LoadBalancedonboth S1 andS2 issatisﬁed foranyserviceinstalled since it ispropagated fromPHS1

be f oreandPHSbe f ore2 :boundedserviceshavetoverifyonlytheotherpreconditions.WecanuseasS1

service,anyCloudServicemeetingallS1preconditionexceptLoadBalanced:theS1servicehastobeaGPSNavigatorservice, thatcomputesaroutefromgps1togps2coordinates;S1mustbeinstalledonamonitoredVirtualServerwithagiven avail-ability.IfallpreconditionaresatisﬁedintheOFG,TheEndActivityhasthehasRouteeffectsfromgps1andgps2coordinates, allpreconditions inStart,S1 andS2 nodes,aswellasminLoadBalanced.Informationfromtransitions inFig.8that is not relatedtocontrol ﬂow(i.e.all dottedtransitions) generatesPrecondition fortheStartActivity, like installedOnormonitors

predicates.

6. Relatedworks

Intheearly2000sservicecompositionwasintroducedandinvestigatedforwebservices[11,12].Inparticular,BPEL4WS [13]waselectedbyW3CconsortiumasreferencelanguageforcompositionofWebServices.NISTdefinitionsandstandards forCloudComputing includedComposition ofServices by meansof Orchestrationonly inthe last years[1] butthey are stillfarfromformalizingcompositionandorchestrationinthesamewayitwasdone forwebservices.Themain effortin compositionduringlast years focusedon thechoice ofservicesandresources tousein acomposite CloudServicein or-derto improveQualityof Service[14].Many worksdealwithoptimizationproblems [15–23].Anyway, themostofthese workslacksinaformaldefinitionoftheOrchestrationproblem.AtentativeofprovidingaCloudOrchestrationEnginewith anorchestrationlanguage isin[24]whereCOPE(CloudOrchestrationPolicyEngine)ispresented.Peer-to-peerand collab-orative approachesto composition havebeen proposed too: in [25–27]authors show the usefulnessof the platformnot onlyforefficientandreliabledistributedcomputingbutalsoforcollaborativeactivitiesandubiquitouscomputing[28].The onlymature workon Orchestration wasmadeby OASIS inthe TopologyandOrchestration SpecificationforCloud Appli-cation(TOSCA) [29].Severalworkshave beenreportedin literature aboutCloudPattern exploitation [30], butingeneral they contain onlydescriptions of differentdesign patterns.At thebest of ourknowledge, thisis theonly work address-ingcompositionintermsofbothCloudComputingPatternsandWorkflowpatterns.Wethinkthat thesetwoconcepts are strictlyrelatedatdifferentlayersofabstraction.Inaddition,weaddressmatchingproblemnotasoptimizationproblem.We provideawayto copematchingandanalyses oftheorchestration process.Wealsoprovideaformal languageto describe compositionin termsofworkflow.The language isa workflowlanguage, so itisdifferentfromthe other declarativeand imperative-scriptinglanguageusuallyusedinliterature.

7. Conclusionsandfutureworks

Thispaperpresentsa methodologyable tobuild andanalyse compositeCloud Services.Themethodology isbased on CloudPatternsandOrchestrationintermsofworkflowactivities.WeenableCloudDesignerstospecifypatternstheyneedin compositeservicecreation.Pattern-basedspecificationisthenautomaticallytranslatedintoaworkflowprocess.Weprovide aformallanguage (OFL)forprocessdescriptionthat takesintoaccountofresourcesandservicesrelationshipsatdifferent CloudServiceLayers.OFLis formallydefinedandits operationalsemanticscan be usedtoprove soundnessofcomposite services.Inadditionwesolvetheproblemofsemantics-basedmatchingandanalysisofcompositeprocessbymeansof Con-ditionPropagation.Futureworksincludethedefinitionofmodeltransformationalgorithmsforthestudyofotherproperties likeperformances,deadlocks,availabilityetc.

(11)

References

[1] VV.AA.Usgovernmentcloudcomputingtechnologyroadmaprelease1.0(draft).In:Specialpublication500-293,2.NIST;2011.p.1–85.

[2] FehlingC,LeymannF,RütschlinJ,SchummD.Pattern-baseddevelopmentandmanagementofcloudapplications.FutureInternet2012;4(1):110–41. [3] DustdarS,SchreinerW.Asurveyonwebservicescomposition.IntJWebGridServ2005;1(1):1–30.

[4] LorenzoGD,MazzoccaN,MoscatoF,VittoriniV. Towardssemanticsdrivengeneration ofexecutablewebservicescompositions.IntJSoftwJSW 2007;2(5):1–15.

[5] Martin D, BursteinM,Mcdermott D,Mcilraith S,Paolucci M, SycaraK,etal.Bringingsemantics towebserviceswith owl-s.World WideWeb 2007a;10(3):243–77.

[6] MedjahedB,MalikZ,BenbernouS.Onthecomposabilityofsemanticwebservices.In:Webservicesfoundations.Springer;2014.p.137–60. [7] MoscatoF,AversaR,MartinoBD,FortisT-F,MunteanuVI.Ananalysisofmosaicontologyforcloudresourcesannotation.In:IEEEproceedingsof

FedCSIS2011conference;2011.p.973–80.

[8] MoscatoF,AmatoF,AmatoA,AversaR.Model–drivenengineeringofcloudcomponentsinmetamorp(h)osy.IntJGridUtilComput2014;5(2):107–22. [9] Martin D, BursteinM,Mcdermott D,Mcilraith S,Paolucci M, SycaraK,etal.Bringingsemantics towebserviceswith owl-s.World WideWeb

2007b;10(3):243–77.

[10] KleinM,Konig-RiesB,MussigM.Whatisneededforsemanticservicedescriptions?aproposalforsuitablelanguageconstructs.IntJWebGridServ 2005;1(3–4):328–64.

[11] Rao J,SuX.Asurveyofautomatedwebservicecompositionmethods.In:Semanticwebservicesandwebprocesscomposition.Springer;2005. p.43–54.

[12] MilanovicN,MalekM.Currentsolutionsforwebservicecomposition.IEEEInternetComput2004:51–9.

[13] WeerawaranaS,CurberaF,LeymannF,StoreyT,FergusonDF.Webservicesplatformarchitecture:SOAP,WSDL,WS-policy,WS-addressing,WS-BPEL, WS-reliablemessagingandmore.PrenticeHallPTR;2005.

[14] JulaA,SundararajanE,OthmanZ.Cloudcomputingservicecomposition:asystematicliteraturereview.ExpertSystAppl2014;41(8):3809–24. [15] Gutierrez-GarciaJO,SimKM.Agent-basedcloudservicecomposition.ApplIntell2013;38(3):436–64.

[16] LiuY,LiM,WangQ.Anoveluser-preference-drivenserviceselectionstrategyincloudcomputing.IntJAdvComputTechnol2012;4(21). [17] MarroneS,NardoneR.Automaticresourceallocationforhighavailabilitycloudservices.ProcediaComputSci2015;52(1):980–7.

[18] PllanaS,BenknerS,XhafaF,BarolliL.Anovelapproachforhybridperformancemodellingandpredictionoflarge-scalecomputingsystems.IntJGrid UtilComput2009;1(4):316–27.

[19] Erfani S, Malek M, Sachar H. An expert system-based approach to capacity allocation in a multiservice application environment. IEEE Netw 1991;5(3):7–12.

[20] FengG,BuyyaR.Maximumrevenue-orientedresourceallocationincloud.IntJGridUtilComput2016;7(1):12–21.

[21] EzugwuAE,BuhariSM,JunaiduSB.Resourcemanagementsystemforscientiﬁcvirtuallaboratoryapplications.IntJGridUtilComput2014;6(1):8–20. [22] MondolMAS,AkbarMM.Anewapproachtoscheduleworkﬂowapplicationsforadvancereservationofresourcesingrid.IntJGridUtilComput

2014;5(3):165–82.

[23] Flammini F., Marrone S., Mazzocca N., Pappalardo A., Pragliola C., Vittorini V. Trustworthiness evaluation of multi-sensor situation recognition in transit surveillance scenarios. Lec. Notes in C. Sc. 8128 LNCS2013:442–456.

[24] LiuC,LooBT,MaoY.Declarativeautomatedcloudresourceorchestration.In:Proceedingsofthe2ndACMsymposiumoncloudcomputing.ACM; 2011.p.26.

[25] BarolliL,XhafaF.Jxta-overlay:ap2pplatformfordistributed,collaborative,andubiquitouscomputing.IndElectronIEEETrans2011;58(6):2163–72. [26] XhafaF,FernandezR,DaradoumisT,BarolliL,Caballé S.Improvementofjxtaprotocolsforsupportingreliabledistributedapplicationsinp2psystems.

In:Network-basedinformationsystems.Springer;2007.p.345–54.

[27] FrenchT,BessisN,XhafaF,MapleC.Towardsacorporategovernancetrustagentscoringmodelforcollaborativevirtualorganisations.IntJGridUtil Comput2011;2(2):98–108.

[28] Barolli L, Xhafa F, Durresi A, De MarcoG. M3ps: a jxta-based multi-platform p2p system and itsweb application tools. Int J Web Inf Syst 2007;2(3/4):187–96.

[29] BinzT,BreitenbücherU,KoppO,LeymannF.Tosca:portableautomateddeploymentandmanagementofcloudapplications.In:Advancedweb ser-vices.Springer;2014.p.527–49.

(12)

FloraAmato, Ph.D., is Assistant Professor at the Department of Electrical Engineering and Information Technology of University of Napoli Federico II. Her research activities mainly concern Formal Modeling , Veriﬁcation Techniques, Knowledge Management, Information Extraction and Integration. She is author of more of 70 research papers, published on International Journals and Conference Proceedings, and she worked as Program Chair in several international Workshops.

FrancescoMoscato, Ph.D., is Researcher and Assistant Professor Professor at Second University of Naples. His research activities include Formal Modeling, Model Driven Engineering and Veriﬁcation, Intelligent Systems and Cloud Computing. He is author of many research papers, published on International Journals and Conference Proceedings, and he worked in Program Committees of several international Workshops.