EndUserOrchestrations?VishalDwivedi,DavidGarlan,andBradleySchmerlInsti - PDF document

EndUserOrchestrations?VishalDwivedi,DavidGarlan,andBradleySchmerlInstituteforSoftwareResearchCarnegieMellonUniversity,Pittsburgh,PA-15213,USA{vdwivedi,garlan,schmerl}@cs.cmu.eduAbstract.Service-orchestrationsdenehowservicescanbecomposedtogetherandarewidelyusedtoexecuteapplicationsbasedonServiceOrientedArchitectures(SOAs).However,thevariousspecialpurposeor-chestrationlanguagesusedtodayrequirecode-levelconstructsthatforcetheuserstoprovideexcessivetechnicaldetail.FormanySOAdomainsend-usersoftheseorchestrationshavelimitedtechnicalexpertise,andhencetheseusersnditdiculttospecifyorchestrationsincurrentlanguages.Additionally,usersspecifyingorchestrationswouldoftenliketoreasonaboutarchitecturalattributessuchasperformance,securityandcomposability-capabilitiesthatcurrentlanguagesandtoolsdonotsupport.Inthispaperweprovideanimprovedtechniqueformodelingorchestrationsthatallowsuserstofocusprimarilyonthefunctionalcompositionofservicesthatisguidedbytoolsupporteddomain-specicanalyses.WeintroduceanabstractarchitecturalspecicationlanguagecalledSCORE(SimpleCompositionalORchestrationforEndusers)thatdenesthevocabularyofelementsthatcanbeusedinaservicecomposition.SCOREnotonlyallowsuserstocreatecorrectservice-orchestrations,butitalsoremovestheneedfortechnicaldetail,mostofwhichisauto-generatedbytoolsupport.Wedemonstratetheuseofourapproachtospecifyservice-orchestrationsinSORASCS(ServiceORientedArchitecturesforSocio-CulturalSystems),whichisaSOAsystemfortheintelligenceanalysisdomain.SORASCSusersareanalysts,whoareinvolvedwithdomain-specicanalysisworkowsthatarerepresentedusingSCOREandexecuted.1IntroductionTheraisond'êtreofweb-servicesisthattheycanbecomposedwithotherservices,dataelementsandmiddlewarecomponentstodelivercompositefunctionality.MostSOAsarebasedonthisprincipleanduseorchestrationsasanunderlyingmethodforspecifyingandexecutingsuchservicecompositions.Inearly2000,anumberofopenXML-basedstandardswereintroducedtoenableservice-orchestrationsbyinternationalconsortiumslikeOASIS,BPMIandtheApacheFoundation.TheseeortswereledbylargevendorslikeIBM,SAPandOracle.Theprimarygoalofthesestandardswastoprovideauniformmethodofcollaborationbetweenorchestratedweb-servicesbydeningpatternsatthemessage-levelofserviceinteraction.Thesestandardswereprimarilydesignedforenterpriseintegrationandprovidedthebasisforcurrentservice-orchestrationlanguagessuchasBPEL[1],BPML[2],andWSCI[3]. ?Submittedforpublication 2 Figure1:AsnapshotofBPELorchestrationUI-elementsanditsXMLcodeTodaySOAbasedsystemsareusedacrossvariousdomainswherethecomputationalmodelisaggregationoffunctionsfromvarioustoolsandservices.Inmanycases,usersofsuchorchestrationsaredomainexperts,whoareprimarilyconcernedwithcompositionofservices,buthavelimitedexpertisetowritedetailedtechnicalspecications.LanguageslikeBPELandBPMLarenotappropriateforthisclassofusersastheyinvolvecodeconstructsthatrequiredescriptionsoforchestrationsatverydetailedtechnicallevel.Forinstance,Figure1depictsasimpleservice-orchestrationsegmentshowingtheuser-interfaceelementsandthecorrespondingXMLcodeusingastandardBPEL-orchestrationtool.ForaSOAdomainwhereusersarenotcomputersavvy,understandingandwritingsuchspecicationsisdicultbecauseof:1.Complexity:Existinglanguagesrequireuserstohaveknowledgeoftechni-caldetailssuchasschema-denitions,namespacesandvariables,makingitdicultforthemtodeneorchestrationscorrectlyandeasily.2.ConceptualMismatch:Usersthinkfunctionally(compositionofactivitiesinaworkow)whileorchestrationsinvolvethespecicationsofcontrolowandvariables.3.Lackofanalysissupport:Fewmechanismsexisttoreasonaboutarchitecturaldriverssuchasperformance,securityandcomposability,whichcanaidinthedesignofcorrectorchestrations.Traditionalservice-orchestrationlanguagesrequiredeveloperstowriteXMLspecications,anddeploythem,beforetheycanbeusedbyotherusers;but 3thatishardfordomainssuchasanalyticsthatrequiredynamicorchestrations.Usersinthesedomainsneedamodelingapproachthatallowsthemtofocusprimarilyonhigh-levelfunctionalcompositionofservices,andatthesametime,allowsthemtocreateandexecutecorrectservice-orchestrations.Ourworkspecicallyaddressesthisclassofusers(whomwerefertoas"end-users").Thispaperproposesanimprovedapproachformodelingservice-orchestrationsusinganabstractarchitecturalspecicationlanguagecalledSCORE(SimpleCompositionalORchestrationforEndusers)thatcanbeusedtospecifyahigh-levelfunctionalcompositionofservices.SCOREprovidesadomain-specicvocabularythatcanbetailoredfordierentusersanddomainsanddoesnotrequirewritinglow-levelcode.Further,weprovidevariousanalysestocheckcomposability,securityandperformanceoverSCOREspecicationsinordertohelpend-userstocomposecorrectservicecompositions.Thesehigh-levelSCOREspecicationsareautomaticallyconvertedintoexecutablespecicationsthatcanbeexecutedbythesystem.2DistinguishingCharacteristicsofSCORESCOREcanbecharacterizedasprovidinganabstractlanguageforspecifyingservice-orchestrations,whichcanbeanalyzedforvariousqualityattributesusingafunctionalvocabularyandexecutedthroughtoolsupport.WeusethischaracterizationtocompareSCOREwiththerelatedwork.2.1AbstractSCOREprovidesanabstractcomponent-orientedlanguagethathidesthetechnicaldetailsfromend-users.Itusesafunctionalvocabularywithadomain-speciccomponentandpropertytypesystemalongwitharichsetofconstraints.Thisallowsuserstofocusprimarilyonthefunctionalcompositionofservices.OrchestrationscanbeexpressedinSCOREusingacollectionofstylesthataredesignedforaparticularSOAdomain.ThereexistssimilarworkbyEsfahaniandcolleaguesatGeorgeMasonUniversity,wheretheyprovidealanguagenamedSAS[4]formodelingfunctionalandQOSrequirementsinanactivitylevelspecication.However,theirapproachreliesoncreatingdomainontologiesandmappingworkowactivitiestothedo-main.Incontrast,SCOREusesasetofdomain-specicarchitecturalstylesthatcanbecustomizedforaspecicSOAdomain.Likewise,MayerandFoster[5]usedmodel-drivenarchitecture(MDA)fororchestrationcodegenerationusingaUMLproleforSOA,butasinglesuchproleisdiculttogeneralizeacrossvariousSOAdomains.Bycomparison,mostcurrentservice-orchestrationlanguagesareatoppositeendsofaspectrumwithrespecttotheirsupportforabstraction.LanguageslikeBPEL[1]andBPML[2]requirespecicationofdetailedcodeconstructslikeschema-denitions,namespacesandvariableassignmentsandhaveminimalsupportforabstraction.Alternatively,UML-basedlanguageslikeBPMN[6]allowabstractionatthelevelofcompositionofactivities,butareusedprimarilyfordocumentationpurposes,andarenotexecutable. 42.2AnalyzableSCOREprovidesvariousanalysessuchascheckingforcomposability,securityandperformancethataidend-usersincomposingcorrectorchestrations.Someoftheseanalysesarebasedondomain-specicconstraintsthatcannotbeeasilyspeciedusingunconstrainedUML-basedmodelingapproaches.Although,thereexistsaconsiderableamountofworkdemonstratinganalysisofworkows,currentorchestrationlanguagesprovidelimitedsupportforanalysesbeyondtype-checking.Oneofthereasonsforlackofanalysissupportcanbeattributedtothefactthatmostofthecurrentapproachesrelyonmodelingformalrepresentations,andthenusingthemtoanalyzestructuralorruntimeproperties.ForinstancePuhlmannet.al.proposedanalyzingstructuralsoundnessoforchestrations[7].KoshkinaetalproposedcheckingconcurrencyofBPELorchestrationsbyformallymodelingBPELinaprocessalgebra[8].Similarly,VanderAalstandcolleagueshavedoneworktowardsPetriNet-basedanalysisofworkowstocheckforcontrolowerrors[9].ThefactthatmostcurrentlanguagesarebuiltonXMLwitharelativelyxedschema,andallowlimitedsupportforaddingadditionalattributesandconstraints,makesitdiculttoprovideanalysisatdesigntime.Veryoften,thedomainoftheworkowenforcesconstraintsthatmustbefollowedbyend-users.SCOREprovidessupportforaddingpropertiesandconstraints,allowingdesignerstowritedomain-specicanalysisthatotherlanguagesnddiculttosupport.2.3ExecutableSCOREspecicationsarecompiledintolow-levelorchestrationspecicationsthatcanbeexecutedbyanorchestrationengine.Ourcurrentprototypeassociatesthearchitecturalspecicationwithascriptandusesthecompositionlogictogeneratelow-levelBPELscripts.ThegeneratedBPELscriptsaredeployedonApache-ODEBPELengine[10]andexecuted.Whetheraservicecompositionlanguageisexecutableornotdependsonthelevelofabstractionitsupports.BPMN[6]forexampleprovidessupportforabstractspecication,butisusedprimarilyfordocumentationpurposes.Ontheotherhand,languagessuchasBPEL[1],BPML[2]andWSCI[3]areexecutablebutarecode-centric.TherehasbeensomesupportforexecutableBPELcodegenerationfromBPMNmodelsbyvendorssuchasIntalio[11]butthatisfairlyrestricted.Ingeneral,itisdiculttotranslateafree-formUMLbaseddiagramunlesstheconstraintsarecodied-somethingwhichismucheasierthrougharchitecturalsupportforwritingconstraints.3DesignApproachWedecidedtodesignatwo-layeredspecicationforrepresentingorchestrations,whereeachlayerhandlesdierentconcerns.Theend-userspecicationlanguage,namedSCORE,isanabstractspecication,isprimarilyfunctionalinnature,andisusedtodesignhigh-levelworkowsdescribingservicecompositions.OrchestrationsaredetailedexecutablespecicationsinalanguagelikeBPEL,whichareauto-generated. 5 Figure2:Anillustrativetwo-layeredspecicationAsimpleexampleforsuchamulti-levelspecicationisshowninFigure2.Theguredescribesasimpleworkow,whichcomposesthreeserviceswithvaryinginputandoutputdatarequirementsandlocationconstraints.Italsoshowsthecorrespondingorchestrationthatincludesadditionalcomponentsfordatatranslationanddatafetchingtocomposeasoundorchestrationspecication.NotethathereDataTranslateelementisrepresentativeofalargeclassoflow-levelcomponentsthatmustbepresentinanexecutableorchestration.ForinstancearealizationofthistranslationservicemayinvolveadditionaloperationssuchasconversionofrelationaltuplesintoXML,theirXSLTbasedtransformation,andconversiontoacomma-separatedle,eachofwhichmayrequireinvokingadditionalservices.Although,thisisasimpleillustration,itprovidesaglimpseofhowabstractmodelscanbehelpfultoend-usersbyprovidingjustthenecessarydetailsallowingforasimplerend-userspecicationthatcanbetranslatedintoanexecutablespecicationusingadditionalpropertiesandconstraints.WeprovidearestrictedvocabularyforthespecicationofworkowsusingSCORE,whereitabstractsthespecicationofworkowstotheessentialcomponentandconnectortypesandthepropertiesofconcern.Inthisabstractvocabulary:Componentsrepresenttheprimarycomputationalelementsanddatastoresofaworkow.ConnectorsrepresentinteractionsamongcomponentsthatmayvaryfromsimpleHTTPbasedcallstocomplexprotocolsPropertiesrepresentsemanticinformationaboutthecomponentsConstraintsrepresentrestrictionsontheservicecompositionsthatshouldremaintruewhiledesigningorchestrations.Typicalconstraintsincluderestrictionsonallowablevaluesofproperties,compositionrestrictions,ormembershipconstraints(asdescribedinSection3.2). 6Theaboveelementsareprovidedviaapredenedtemplate(calledastyle)thatdenesthevocabularyofdesignelementsforaparticulardomain.Unlikefree-formUMLbasedapproachesforworkowcomposition,astyle-centricapproachconstrainsend-userstousetheappropriateelementsalongwiththeirassociatedrestrictions.Suchastylecanbefurthercustomizedorextenedtoincludeadditionalconstraintsbasedonthedomainofusage,therebyprovidingmoresupporttoend-users.End-userswhousetheSCOREstyletocomposeworkowsareprovidedwithdefaultvaluesforvariousattributesmakingtheirjobmoreeasier.Thenextfewsectionsdescribethetype-systemofSCOREandhowitcanbeusedbyend-userstogenerateorchestrations.SCOREcomponenttypes SCOREProperties Figure3:SCOREbasiccomponentandpropertytypes 73.1ElementaryvocabularyforSCORESCOREwasprototypedusingtheAcmearchitecturedenitionlanguage[12]viaaspecial-purposedata-owarchitecturalstylethatprovides(i)acomponenttypesystemrepresentingtheSOAdomain,(ii)apropertysystemthatcansupportanalysis,and(iii)asetofanalysisbasedonrulesaboutpropertiesoftheworkow.InFigure3,wedetailtheelementtypesusedintheSCOREvocabulary.Thehigh-levelcomponenttypessuchasServiceOperation,DataStore,andaretheelementarycomponenttypesforthework-owsandtheyrepresentweb-services,data-accesselements(suchasleaccessandSQLdata-access),controlowlogicbasedonconditionsandexternaltoolAPIsrespectively.Theisahigh-levelcomponenttypethathandlesuser-interaction.Similarly,thehigh-levelconnectorsand-,asthenamessuggest,providedata-owandcontrol-owsemanticsinacompositionandareprimarilyresponsibleforcommunicationbetweenthecomponents.Theandarepri-marilymeanttoreadandwritedatafromaComponent.TheisaspecialpurposeAJAXconnectorthatprovidescapabilitiestointeractwithuserinterfaces.Theportsactasinterfacestothecomponentsandserveasinteractionpointsforeachcomponent.Theandporttypesareresponsibleforrepresentingdata-outputanddata-inputinterfacesbetweenthevariouscomponents.Theandport-typesarethedatareadandwriteinterfacesforthestoragecomponents.Theisaspecialpurposeporttypethatservesasaninterfacetoaddcongurationdetailstocomponents.Similarly,port-typeactsasaninterfacetothe.Inthisstyle,connectorsratherthanbeingunchangeablyboundtospecicports,haveinterfacesthataredenedbyasetofroles.Eachroleofaconnectordenesaparticipantoftheinteractionrepresentedbytheconnector.Wedenesomeprimitiverolesandasserviceconsumerproviderrolesandandasrolesoverandports.Eachroleofaconnectordenesaparticipantoftheinteractionrepresentedbytheconnector.TheportsandtherolesintheSCOREstyleallowustowritevariousdomain-specicconstraintsthatrestrictcongurationsofworkows,andthusavoidpotentialmismatches.Specicationswrittenusingthesecomponenttypesarethencheckedforconsistencyandwell-formedness.Weimplementsomeoftheseconsistencychecksbyenforcingconstraintsontheworkowelements.WewoulddiscusstheseindetailinSection.Oneofthecriticaltrade-osinthedesignofSCOREvocabularywasensuringabalancebetweenthecomplexityofthecomponenttype-systemandthepropertytype-system.Theyneedtobeexpressiveenoughsothatworkowsinthedomaincanberepresentedusingtheprovidedvocabulary.However,sincetheseworkowspecicationsformthebasisofautomatedcodegeneration,theyhavetocaptureenoughdetailtobeabletodoso. 8Inthissectionwedescribedthetype-systemforthebasestyleforSCORE.However,inpractice,othersub-stylesextendthisbasestyletoprovideadditionalcapabilities.Thesearecustomizedforthedomaintheyareusedandareextendedwithadditionaldomain-specicrules.Wedescribesomeofthesedomain-speciccustomizationsinlatersections.3.2Domain-specicconstraints Workflow.ConnectorsThesetofconnectorsinaworkow ConnectorName.RolesThesetoftherolesinconnectorConnectorName self.PROPERTIESAllthepropertiesofaparticularworkowelement,whereselfisapointertotheelementitself size()Sizeofasetofworklowelements invariantAconstraintthatcanneverbeviolated heuristicAconstraintthatshouldbeobservedbutcanbeselectivelyviolated Table1:SampleAcmeconstructs SL.NoConstrainttypeExample 1StructuralCheckingthatConnectorshaveonlytworolesattachedruleonlyTwoRoles=heuristic!size(self.ROLES)=2; 2StructuralCheckingifaspecicmethodoftheservicecalledexistsruleMatchingCalls=invariantforallrequest:!ServiceCallTinself.PORTS|existsresponse:!ServiceResponseTinself.PORTS|request.methodName==response.methodName; 3PropertyCheckingifallpropertyvaluesarelledinConstraintsruleallValues=invariantforallpinself.PROPERTIES|hasValue(p); 4MembershipEnsuringthataworkowcontainsonlythe3typesofservicesrulemembership-rule=invariantforalle:Componentinself.MEMBERS|declaresType(e,ServiceTypeA)ORdeclaresType(e,ServiceTypeB)ORdeclaresType(e,ServiceTypeB); Table2:SampleconstraintsspeciedinpredicatelogicinSCOREstyleAnimportantroleoftheSCOREstyledescriptionistomakeexplicitthepreconditionsthatmustbesatisedinordertocreateawell-formedworkow.Inpractice,notallworkowspecicationsarevalid,andbyenforcingrulesthatdeterminerestrictionsonthestructure,propertyormembershipofworkow,end-usersareprovidedadditionalmodelingsupport.TheSCOREstylespeciestheserulesthatareevaluatedatdesigntime,enforcingcertainrestrictionsonthekindsofservicesuserscancompose.Writingtheseconstraintsinvolvessomedegreeoftechnicalexpertise,buttheseareassociatedwiththearchitecturalstyle,whichiswrittenonce,andthenusedformodelingallworkowsusingthestyle.Table2illustratessomeexamplesofconstraintsrepresentedinSCORE.TheconstraintsinSCOREarebasedonAcme'srstorderpredicatelogic(FOPL), 9wheretheyareexpressedaspredicatesoverarchitecturalpropertiesoftheworkowelements.ThebasicelementsoftheconstraintlanguageincludesFOPLconstructssuchasconjunction,disjunction,implicationandquantication.Table1illustratessomefunctionsandexpressionsprovidedbyAcme,whichareusedtospecifyworkowconstraints.TheseconstraintsareassociatedwithvariousdesignelementsoftheSCOREspecicationsuchasthecomponents,connectors,portortheentireworkowitself.Bycomparison,currentUMLbasedlanguagesutilizeconstraintlanguageslikeOCL[13]tocheckforwell-formednessrules.SCORE'sconstraintsusesaconcretesyntaxsimilartoOCLandcanbeassociatedwiththeworkowdesign-elementsusingFOPLbasedrules.AnimportantroleoftheSCOREstyledescriptionistodenethemeaningofsyntacticconstructsintermsofthesemanticmodeloftheorchestration.Weachievethis,atleasttoacertainextent,byenforcingthesedomain-specicconstraints.Thesenotonlyprohibitend-usersincreatinginappropriateservicecompositions,butalsopromotesoundnessoftheorchestrationsbyensuringfeedbackmechanismviamarkingerrorswhenauserfailsanysuchconstraint.3.3SupportforanalysisAswediscussedinSection3.1,alongwiththecomponenttypesystemSCOREalsoprovidesapropertytypesystem.Someexamplesofpropertiesincludethespecicationoflocationinformation,tooloriginofservices,securitycredentialsandotherattributesovertheelementsoftheSCOREstyle.InthissectionwedescribesomeoftheexampleanalysistypesthatcanbebuiltusingSCOREproperties,suchasanalyzingaworkowforcomposabilityerrors,checkingforsecurityorensuringvariousperformanceconstraints.Therulesfortheseanalysesarewrittenaspredicateswhichareanalyzedforcorrectness. ConstrainttypeDetails DataIntegrityData-formatoftheoutputportofthepreviousconnectormatchestheformatoftheinputport SemanticappropriatenessMembershipconstraintsforhavingonlylimitedcomponenttypesaremet StructuralsoundnessAllStructuralconstraintsaremet,andthereare:*nodanglingports*nodisconnecteddataelements Table3:ComposabilityAnalysis Figure4:Data-formatmismatchComposabilityAnalysis:Com-posabilityisdenedastheabilitytoselectandassembleappropriatecomponentstosatisfyauserrequirement.Animportantaspectofcomposabilityanalysisistodeterminethattheworkowsdesignedbyusersarewell-formed. 10WeensurethisbyprovidingtheanalysisasshowninTable3.ComposabilityanalysisisprovidedbyacollectionofrulesexpressedinSCORE.WorkowsarecreatedasinstancesoftheSCOREstyleandallfailuresarevisuallymarkedaserrorsbythetool.Figure5forinstanceillustratesafailureinstanceofarulewhereaninappropriatemethodofserviceiscalled.Theerrorismarkedvisuallyanddisplayedasanerrormessage. Figure5:Anerrormarkupshowinginappropriatemethodcall InuencingFactors Requirementsforsecurity ComponentLevel ConnectorLevel TrustBoundaries Authentication Authorization Logging Encryption Integrity From To Trusted Trusted 3 3 Trusted Semi-Trusted 3 3 3 Trusted Untrusted 3 3 3 Semi-trusted Trusted 3 3 Semi-trusted Semi-trusted 3 3 3 Semi-trusted Untrusted 3 3 3 Untrusted Trusted 3 3 3 Untrusted Semi-trusted 3 3 3 3 Table4:SecurityAnalysisSecurityAnalysis:AnotheranalysisprovidedbySCOREistoensurethatthemodeledorchestrationissecure.AnillustrativeexampleforthiskindofanalysisasshowninTable4,whichrepresentsthesecurityrequirementsforanorganization.Thetableliststhesecurityrequirementsforthevariouscomponentsandconnectorsfordierentmodesofinteractions.Forexample,ifatrustedcomponentinvokesasemi-trustedcomponent,theorganizationalpolicyrequiresthecomponentstoimplementauthorizationandauthentication,andensurethatthemessagingmechanismassuresintegrity.Acollectionofsuchrulesisrepresentedinastyleandworkowsareanalyzedtoconformtothestyle.Notethattherequirementsforsecuritymayvaryacrossdomainsandorganizations.Table4illustratesanexamplescenarioofasecuritypolicythatneedstobeenforcedforallservicecompositions.SCOREcanbeusedtospecifysuchconstraints,andanalyzethem. 11PerformanceAnalysis:SCOREcanbeusedtoanalyzeworkowperformancebyaddingperformancerelatedpropertiestothecomponentsandconnectorsusedtomodeltheworkowsandusinganexternalplugintoperformtheanalysis.Someexamplesforsuchananalysisare:i)Evaluatingapproximatetimetoexecutetheorchestration,ii)analyzingthattheorchestrationwouldnotstall(forexampleduetocycles),etc.Thereexistsaconsiderableamountofliteratureforanalyzingworkowperformancevaryingfromstochasticanalysisbasedonqueuingtheory,PetriNetbasedmodelingandotherformalapproaches.SCOREprovidesanarchitecturalstylewhichcanformthebasisofsuchanalyses,eachofwhichcanbeimplementedaspluginsimplementingtheindividualanalysiscode.4SCOREuse-case Figure6:SORASCStoolpipelineWeuseSCOREasanunderlyingstyletorepresentworkowsfromSORASCS(ServiceORientedArchitecturesforSocio-CulturalSystems)[14].SORASCSisanend-userSOAsystemandanarchitectureplatformfortheintegrationofasetofintelligenceanalysistoolsandservicesfromCarnegieMellonandotherpartnerinstitutions.ThecomputationalmodelinSORASCSisbasedonaggregationofservicesandfunctionsfromvariousanalyticaltoolsandweb-servicesfromdierentorganizations.Usersinthisdomainareintelligenceanalystswhohaveexpertiseinanalyzingdata,butusecomputersmerelyastoolstoaccomplishtheirtasks;theircomputerexpertiseislimitedtoonlygeneraluseandtraininginprogramsfromtheirdomain.Intelligenceanalystshaveawidevarietyofcomputerprogramsthatassistthemintheirtasks.Figure6showsasetofsuchtoolsdevelopedattheCenterforComputationalAnalysisofSocialandOrganizationalSystems(CASOS)atCarnegieMellonUniversity:AutoMap[15]forextractingnetworksfromnaturallanguagetexts,ORA[16]foranalyzingtheextractednetworks,Construct[17]forwhat-ifreasoningaboutthenetworks.Inadditiontothesetools,thereareavarietyoftoolsfromotherorganizationsthatmaycontainoverlappingfunctionality.Whiletheexistingtoolswerequitepowerfulintermsoffunctionality,theyaremostlystandalonetoolsthatrequiretrainingtouse,andaredicultto 12integrateandusetogether.Thereisaneedinthecommunitytomixandmatchthecapabilitiesofmanytools,dependingonneed,torecordcommonsequencesofusageforparticularcases,toprovidetraceabilitysothatanalystscandeterminehowconclusionswerereachedbytools,andtobeabletoassemblemultipletoolfunctions,datasourcesandnewcapabilities.SuchneedscanbeaddressedbyprovidingtoolfunctionalityasservicesinaServiceOrientedArchitecture(SOA),thatsupportsend-userworkowconstruction.SCOREwasusedasanunderlyingarchitecturestyleforSORASCSasitprovidedcapabilitiesforcomposingSORASCSservicesintoworkows.Thetoolcapabilitieswerethusdecomposedintonegrainedweb-servicesthatallowsthemtobeorchestratedtogethertoperformamultitudeoftasks.WhilealmostallservicesprovidedbySORASCSarecurrentlyne-grainedweb-servicesimplementedbywrappingthefunctionalityoftools,thegranularityoftheseservicesvariedfromverynegrainedtext-processingdata-servicesinAutomap,tobulkyapplicationservicesinORAvisualization.SCOREallowedsupportfororchestratingsuchthin-clientandthick-clientservices.Although,creatinganarchitecturalstyleforthedomaininvolvedanadditionaloverhead,butitwasaonetimejob.Oncedened,SCOREprovidedconsiderablesupporttoend-userstomodelworkowsinSORASCSandgeneratethecorrespondingexecutableorchestrations.4.1SORASCSWorkowsinSCORE Figure7:HotTopicsWorkowcomposedusingSCOREFigure7providesasimpleillustrationofaworkowcomposedusingSCORE.Theworkowdescribesacompositionoffewdomain-specicweb-services,avisualizertoolandinputandoutputdataelements.ThisscenariofromtheSORASCSsystem[14]describestheHotTopicsWorkowwhichinvolvesextractionofdatafromemails,generationofanetworkrepresentation,visual-izationofthenetworkandcreationofareportwhichdescribesthekeyactorswhoareinvolvedinthetextdescription.Theworkowuses5keyservices-Ap-plyDeleteList,GeneralizeNetwork,GenerateSemanticNetworks,GenerateUnion,andHotTopicsReport.Theseservicesprimarilydealwithnetworkextraction 13andgenerationtasksfortheintelligenceanalysisdomainandarehostedontheSORASCSplatform.andservicesareresponsiblefordeletingsometextkey-wordsandperformingnaturallanguageprocessingonthetext.servicecreatesasetofnetworksforanalysisthatarecombinedtogetherbytheservice.Thesearethenfedtoservice-athickclientbasedservicetogenerateareport.4.2CodegenerationSCOREspecicationsaredesignedtobeabstractinnatureastheyenablefunctionalcompositionofservicesbasedonagivendomain-vocabulary.Weusethesespecicationstoauto-generatelow-levelorchestrationcode.OurcodegenerationapproachprimarilyconsistsofassociatingchunksofBPELcodewithSCOREcomponents,andusingthesespecicationstocreateexecutableBPELscripts.ThegeneratedBPELscriptsarethendeployedonODEBPELengine[10]andexecuted.WetestedourapproachfordeningSORASCSworkows,wherethestandardsizeofBPELorchestrationsvariedfrom100linesto4200linesofcode.Itwasobviousthatanalystswouldnditdiculttomodelorchestrationofthislargesize.SCOREnotonlyautomatedthecodegeneration,butitalsomadeiteasierfortheend-userstomodelthembyprovidinganabstractandfunctionalvocabulary. Figure8:ComparisonofconstructsoftheHotTopicsworkowmodeledinBPEL,BPMNandSCORE5SCOREconceptsevaluationInSection2weidentiedthedistinguishablecharacteristicsofSCORE.Wealsodiscussedhowanabstract,domain-specicandfunctionalvocabularyenablesSCOREtoprovideend-userrepresentation.ThissectiondescribeshowSCOREmeetsthecriteriaweidentiedearlier. 14WedesignedasmallexperimenttocomparetheconceptsrequiredbycurrentorchestrationlanguageswiththeonesbySCORE.WeusetheSORASCSintelligenceanalysisdomainasastandarddomainforourtest.Specically,weusethesameHotTopicsWorkowdescribedinFigure7andmodelitusingBPEL,BPMNandSCORE.ChoreographylanguageslikeWSCIwerenotconsideredsuitableforend-usersintheSORASCSdomainastheyinvolvewritingmessageinterchangespecicationsinXMLthatarenoteasytospecifyforuserswithlimitedtechnicalexpertise. Type BPEL BPMN SCORE WSCI Abstractrepresentation - + + - Functionalvocabulary - +/- + - Domain-specicconstraints - - + - Supportforanalysis - - + - Executable + +/- + + Table5:ComparisonofmodelingsupportNR*:NotRequired Concepts(bytype) BPEL BPMN SCORE No.ofActivities 70 13 7 No.ofVariableAssignments 14 14 NR* No.ofCorrelationParameters 5 5 NR* No.ofMessages 2 NR* NR* NameSpaces Required NR* NR* Table6:ComparisonofConceptsrequiredtomodeltheHotTopicsWorkowTable6providesasnapshotoftheconceptsinvolvedincreatingsuchanorchestrationusingBPEL,BPMNandSCORE.Weprovidealogicalcomparisonoftheconceptsinvolvedinmodelingthesameworkow.LanguageslikeBPMNandBPELmakeithardtomodelsuchorchestrationsforend-usersduetothecomplexityofthetechnicalconstructsinvolved.Figure8providesanactivity-levelcomparisonformodelingthesameHotTopicsworkow.Itisnoticeablethatit'snotsomuchthenumberofactivities,butthemoretechnicalvocabularyofthedomainthatallowssignicantreductioninthecode-levelsemantics.BPMNprovidesacertainlevelofabstraction,butisnotexecutable.LanguageslikeBPELandBPMNalsodonotprovideanysupporttoaddconstraintsandpropertiestoperformarchitecturalanalysis.Bycomparison,SCORErequireslessernumberofconcepts,makingiteasierforend-userstodeneorchestrations.6ConclusionsandFutureWorkInthispaperwedescribeSCORE,anabstractarchitecturalspecicationlanguageformodelingservice-orchestrations.Ourworkisinspiredbytheproblemsend-usersfaceinmodelingorchestrationsandthelimitedanalysiscapabilitiesofthecurrentorchestrationlanguages.SCOREnotonlyallowssimplermodelingcapabilities,butitalsoprovidesadditionalsupportfordesigntimeanalysis.Ouraimistoaddresstherequirementsofend-userswhoare 15primarilyconcernedwithservicecompositionandanalysis,buthavelimitedtechnicalexpertisetowritecode.SCOREaddressessuchusersbyprovidingpre-denedtemplatesrepresentingthevocabularyandrulesthatcanbecustomizedfordierentdomains.Thisdomain-specicvocabularyisfurthersupportedbyadditionalpre-builtanalysesforvariousqualityattributes.SCOREispartofourongoingresearcheortinbuildingSORASCS,anend-userSOAsystemfortheintelligenceanalysisdomain.Wearecurrentlyworkingonanimprovedfront-endtosimplifyservice-orchestrationsusingSCORE.Inthenearfuture,wewouldliketoprovidevariousdomain-specicsub-stylesandotheranalysisthatcanalloweasiercompositionofservicesbyend-users.Webelievethatanarchitecturalapproachtorepresentservicecompositionscanbeextendedtovariousothercompositionscenarios,providingmoreformalreasoningsupportforvariousqualityattributes.7AcknowledgementsThisworkwassupportedinpartbytheOceofNavalResearch(ONR-N000140811223).AdditionalsupportwasprovidedbytheCenterforComputa-tionalAnalysisofSocialandOrganizationalSystems(CASOS).Theviewsandconclusionscontainedinthisdocumentarethoseoftheauthorsandshouldnotbeinterpretedasrepresentingtheocialpolicies,eitherexpressedorimplied,oftheOceofNavalResearch,ortheU.S.government.References1.BPEL:BPELWebServicesBusinessProcessExecutionLanguage.(http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html/)2.BPML:BusinessProcessModelingLanguage.(http://xml.coverpages.org/bpml.html)3.WSCI:WebServiceChoreographyInterface.(http://www.w3.org/TR/wsci)4.Esfahani,N.,Malek,S.,Sousa,J.P.,Gomaa,H.,Menascé,D.A.:Amodelinglanguageforactivity-orientedcompositionofservice-orientedsoftwaresystems.In:MoDELS.(2009)5916055.Mayer,P.,Schroeder,A.,Koch,N.:Mdd4soa:Model-drivenserviceorchestration.In:EDOC.(2008)2032126.BPMN:BusinessProcessModelingNotation.(http://www.bpmn.org/)7.Puhlmann,F.,Weske,M.:Interactionsoundnessforserviceorchestrations.In:ICSOC.(2006)3023138.Koshkina,M.,vanBreugel,F.:Modellingandverifyingwebserviceorchestrationbymeansoftheconcurrencyworkbench.ACMSIGSOFTSoftwareEngineeringNotes29(5)(2004)1109.Aalst,W.M.P.V.:Workowverication:Findingcontrol-owerrorsusingpetri-net-basedtechniques.In:BusinessProcessManagement.(2000)16118310.ODE:ApacheOrchestrationDirectorEngine.(http://ode.apache.org/index.html)11.Intalio|works:BPMS.(www.intalioworks.com/products/bpm)12.Garlan,D.,Monroe,R.T.,Wile,D.:Acme:Anarchitecturedescriptioninterchangelanguage.In:ProceedingsofCASCON'97,Toronto,Ontario(1997)16918313.OCL:ObjectConstraintLanguage.(http://www-st.inf.tu-dresden.de/ocl/) 1614.Garlan,D.,Carley,K.M.,Schmerl,B.,Bigrigg,M.,Celiku,O.:Usingservice-orientedarchitecturesforsocio-culturalanalysis.In:Proceedingsofthe21stInternationalConferenceonSoftwareEngineeringandKnowledgeEngineering(SEKE2009),Boston,USA(2009)15.Diesner,J.,Carley,K.:Automap1.2-extract,analyze,represent,andcomparementalmodelsfromtexts.TechnicalReportCMU-ISR-07-114,CarnegieMellonUniversity(2004)16.Carley,K.,Reminga,J.:Ora:Organizationriskanalyzer.TechnicalReportCMU-ISRI-04-101,CarnegieMellonUniversity(2004)17.Schreiber,C.,Singh,S.,Carley,K.:Construct:Amulti-agentnetworkmodelfortheco-evolutionofagentsandsocio-culturalenvironments.TechnicalReportCMU-ISRI-04-109,CarnegieMellonUniversity(2004)