UsingContinuationsfor FlexibleProvisionof GridServices
MaurizioGiordano and Claudia Di Napoli
IstitutodiCibernetica“E. Caianiello” -C.N.R. ViaCampi Flegrei 34, 80078 Pozzuoli, Naples -ITALY { m.giordano,c.dinapoli} @cib.na.cnr.it
Abstract. The main challenge of grid computing is to provide auni- fied computational infrastructure composed of networked heterogeneous resourcesthat makes effectiveuse of the computational powerdelivered by eachresource. To reach thisobjective managementofcomputational resources is acrucialaspect because of the decentralized, heterogeneous and autonomousnatureofthese resources that usuallybelong to different administrativedomains. As such theycannot be managed by adopting a centralizedapproach, but more sophisticated computing methodologies are necessary.Inthis context, the possibilitytomanage the execution of services is advisable to control their provision in dynamic and chang- ing environments. In the presentwork an infrastructuretomodel service providers is proposed to allow for flexible provision of grid services, i.e.to allowproviders to dynamically adapt the execution of services according to both the changing conditions of the environmentwhere they operate in, and the requirementsofserviceusers. The infrastructure is based on continuations ,aprogramming paradigm that allowstocontrol the state of code execution at programming level withoutdirectlyusing operating system facilities.
1Introduction
Computational gridsrepresentthe new researchchallenge in theareaofdis- tributed computing. They aim to provide aunified computational infrastruc- ture composed of geographically distributed heterogeneous resources cooperating with eachother throughmiddlewaresoftware to enable usage of thecollection of these resources in an easy andeffectivemanner. In thepresentworkaservice-orientedapproachisadopted as describedin[1], wheregridresources areabstracted as grid service s, i.e. computational capabili- ties exposed to the network throughaset of well-defined interfacesand standard protocols usedtoinvokethe servicesfromthose interfaces, andthey have to be identified,published,allocated,and scheduled. Services are notsubject to cen- tralized control (i.e. they livewithin differentcontrol domains and they do not rely on acentral managementsystem), theyuse standard, open, general-purpose protocols and interfaces(i.e. notapplication-specific), andthey canbecombined in order to deliver added valuefunctionalities so that theutilityofthe resulting
96 system is significantly greater than that of thesum of itsparts.Inordertopro- vide such acomputational infrastructure, grid technologies should supportthe sharing andcoordinated use of diverseresources in adynamicenvironment[1]. Aservice is provided by the body responsible foroffering it,werefer to as serviceprovider,for consumptionbyothers, we refertoas serviceconsumers, un- der particular conditions. In this view,service providers(that can be individuals, organizations, groups, government, andsoon) areindependent andautonomous entities representingthe interface between aservice consumer andarequired functionality, i.e. agridservice. Userswill be able to access andshare these computational capabilities on demandoverthe Internet,relying on an infras- tructure that is expectedtoberesilient, self-managing, andalwaysavailable, and aboveall that is perceived as aunified framework by end users. Aservice request is fulfilled whenthe consumer requirements can be met by theservice provider that received the request, i.e. whenconsumers’s Quality- of-Service requirements can be met by provider’sQuality-of-Service capabilities [2]. ThetermQuality-of-Service is usedinageneralsensereferring to avery widerange of non-functional service characteristics.Itisbeyondthe scopeof thepresentworktostudy howcomplexthe quality of aservice canbe, andhow to characterize it, i.e. howmanyparameters should be considered to express the qualityofaservice,and howitcan be represented. This is mainly adomain- specificproblem. In this approach, service providers must be equippedwith mechanismswithin their architecturestoallowfor theprovisionofknown qualitylevels andfor the possibilitytochangequalitylevels when necessary.So, providers need to have controlonthe execution of theservices they provideinordertoaccommodate for the changingconditions under whichaservice could be provided. In sucha way providers areabletodecide at run-time “how” to fulfillaservice request, i.e. what Quality-of-Service they canprovide the service with. In this work we propose an infrastructure to model service providers to con- trol theexecutionofservices by allowingfor service suspensionand resumingin away similar to process preemption in traditional operating system design. Theinfrastructure relies on continuation programmingparadigm [3]inor- dertoprovide executionstate saving/restoringmechanisms for services. These mechanisms willsupportthe possibilityofdynamically controllingthe execution of services to allowproviders to change at run-time parametersaffecting service provision either driven by consumer or system requirements. The rest of thepaper is organized as follows. Section 2gives an overview of thenotion of continuation and its deploymentinsome classes of program- minglanguages. Section 3describes the high-level designofthe proposed service provider infrastructure andits functionalities, together with theAPIs to use it. Section 4gives detailsonthe infrastructure implementationand Sec.5describes thereference applicationscenario of theproposed work.Finally Sect. 6reports some conclusions andcomparison to related work.
97 2ContinuationsinProgramming Languages
A continuation relativetoapointinaprogram represents the remainderof the computation fromthatpoint[3], so acontinuation is arepresentationof theprogram current executionstate. Continuation capturing allowstopackage thewhole state of acomputation up to agiven point. Continuation invocation allowstorestore that previous state restartingthe computation fromthatpoint. Although anyprogrammingsystem maintains the current continuation of each program instructionitevaluates, thesecontinuationsare generally notaccessible to the programmer. In functional programminglanguages, the continuation can be represented as afunction and thepossibilityofexplicitly managingitallows to effect the program controlflow [4]. In languages likeCthecurrentexecutionstate is rep- resentedbythe call stackstate, theglobals, and theprogram counter. Some object-oriented programminglanguagessupportcontinuationsbyprovidingcon- structs to save thecurrentexecutionstate into an object, and then to restore thestate fromthisobject at alatertime. Depending on whichoperations can be done at programminglevel on the continuation storeobject, it is possible to classify the type of support forcon- tinuations in thegiven programminglanguage.Inparticular, a first-class con- tinuation is representedbyafirst-class objectasdefined by Abelson &Sussman in [5]:
afirst-classdata object is alanguage element that may be named by variables,passedasarguments to procedures,returned as resultsofpro- cedures,and includedindata structures
Thereare Java languageextensions supporting continuations as not-first-class objects, likeRIFE [6]and Jetty6[7], in what they provide constructstocapture andresume continuations,but no mechanismstostore them in data objects that can be passed as functions call parameters. In what follows we outlineashort andnon-exhaustivelist of programming languageextensions that supportcontinuations. Our attentionisfocusedon languages and programmingenvironments providingcontinuation capturing and resumingconstructs to builduplightweightuser-level threads thatcan be easily managed andscheduled at applicationlevel.
– JavaFlow[8] is aJavacomponentofthe Apache Jakarta[9] project that implements continuations.InJavaFlowacontinuation is thestate of an application, i.e. thestackoffunctions calls including local and globalvari- ablesand theprogram counter. Continuations are capturedand savedinto aJavaobject that allowstorestart theprocessingfromthe pointstoredin it. JavaFlowsupports continuations as first-class objects: thecontinuation objectinterface includes methods to suspend andresume it. – Stackless Python [10]isanexperimentalimplementation of thePython pro- gramminglanguage that usescontinuation support to model concurrency in
98 an easy way.Itprovidesabstractions of microthreads at applicationlevel, named tasklets,whose implementationisbased on continuations.Stackless Pythonsupports tasklets as built-in user-level lightweightthreads with con- structstocontrol their creation, suspension, resuming andscheduling at applicationlevel. – Ruby[11] language supportsnatively continuations as first-class data types. The callcc{ |$cc|} construct is provided to capture continuation of pro- grams at anylocation,binding it to the $cc argument variable.Continua- tion resumption is performed by the $cc.call function invocation. Contin- uations can be usedinRubytoimplementuser-level threads with suspen- sion/resumingand schedulingsupportatapplicationlevel. – Rhino[12]isanopensource Javascript implementation writteninJava. There is aRhino additional package [13]which introducesanadditional mode for theRhino (Javascript) interpreter thatsupports first-class continuations. In Rhino acontinuation is aJavascript objectthatrepresents the storing of theRhino script execution state. Youcan return this object, storeitina variable,assignittoapropertyofanother object. Thecontinuation objectis alsoafunction: when youcall it thecurrentexecutionstate of theprogram is discarded andthe snapshotofthe program representedbythe continuation objectisresumed in its place. Apache Cocoon webdevelopmentcomponent- based framework [14] usesRhino Javascript to implementits controller logic.
3Service Provider Design
In order to be able to provide services that meet Quality-of-Service require- ments both of service consumers (e.g. cost, response-time) andofproviders (e.g. throughput, profit,CPU utilization),itiscrucial to be able to controlthe exe- cution of services in accordancewith new events occurring in theenvironment since these requirements cannot be alwaysstatically determined. Service preemption mechanismsare away to provide full control of service execution andthey canbeimplemented (or simulated) using severalapproaches, both at applicationoroperatingsystem level. Forexamples,atapplicationlevel the Java languageprovides(deprecated)threadsuspension/resumingsupport. Other approaches [15] use operating systemssignals ( SIGSTOP/ SIGCONT)avail- able in most operating system infrastructures. Themain objectiveofthe proposed service provider architecture is application- level preemption of services in order to supportatprogramminglevel the de- velopmentofdynamicpolicies for service execution. Service preemptionisnot providedatoperatingsystem level, but at application-level by managingprogram continuations.Thischoice makes theframework flexible and easily adaptable for developingand experimentingscheduling facilities, policies and service-control in differentservice-oriented architecture applications. Existingweb service frameworks[16,17]makeitdifficult to implementa service provider architecture with preemption mechanismsofweb services with- outadeep changingofthe controlpatterns usuallyimplemented as abuilt- in feature.Thisisbecausemostframeworks obey to the InversionofControl
99 WebServiceState Transition Diagram submit Running Service suspend finished Provider Service resume Expired u-thread Suspended Expiring Expirequeue kill kill expired Srv Result Terminated Service ... Service Finished u-thread u-thread Waitqueue Request Kill Suspend Resume WS Client SOAP Handler Service Scheduler Submit Service ... Service ... u-thread u-thread u-thread Runqueue
Fig. 1. Services provider architecture andservicestate transition
(IoC) programmingpattern[18,19]widely usedinmostJavaand object-oriented web-applicationenvironments. So,web service instantiationand life-cycle man- agementcannotbefully controlled by programmerswho develop andadd web servicestothe framework. Forthisreasonexisting webservice frameworksare notsuitable to provide an application-level controlofservice executionsupporting service suspension andresuming. Forthisreasonwedesigned aservice provider equippedwith mechanisms to process suspension andresuming notifications. The service provider should process,fromtime to time, arrival of notificationmessages in order to sus- pend/resumethe execution of aservice it is providingbycapturing/restoring its continuation. Thecontrol of service execution canbedrivenboth by the service provider itself and by anyclientprogram. Service preemption, driven or notbyclientrequests, is carried outbythe providerstoringatthe preemption points theexecutionstate of thespecified service. Aclientprogram canrepresenteither aservice consumer that requires a service result,orametascheduler or service broker [20] tryingtoadapt local service execution policies so that resources canbeshared in areliable andefficient way in aheterogeneous anddynamically changingenvironmentlikethe grid.
3.1 User-Level Control of Services
Our proposal of aservice provider architecture supporting user-level preemptible service execution is depicted in Fig. 1. Theproviderisrepresented by a ser- vicecontainer consisting of apooloflightweightuser-level threads, named u- threads,whose implementationshouldsupportsuspension and resuming facilities of threadsatapplicationlevel.
100 In ourdesignu-threads arewrapper functions that embody andcontrol the executionofweb service WSDL operations [21]. Webservice operationsare sup- plied as parameterstou-threads andexecuted within their contexts (see Fig. 1). Thus thewrapping guarantees the required functionalities to suspendand resumeweb service operations. Au-thread, andhence the enveloped service instance, can be in thefollowing states: – running,i.e. theservice instance is executing or readytobescheduled for execution; – suspended ,i.e. theservice instance is not yetterminated, butcannotbe scheduledfor execution; – expiring ,i.e. theservice instance terminated, but thewrapping u-thread descriptor is still alive to makethe service resultavailable to successive requests; – terminated ,i.e. theservice instance terminatedand thewrapping u-thread descriptor is freed andnolongeravailable becauseeither aspecified expi- ration time elapsed,orthe clientrequested andobtained the service result before theexpiration time. Theservice state transitiondiagramisshowedinthe leftmost part of Fig. 1. Amain u-thread, alwaysin running state,represents the service provider exe- cutioncontext. The main u-threadprogram interleavesmessaging andscheduling activities by runningtwo modules:the Request Handler andthe ServiceSched- uler.The Request Handler deals with probing incoming SOAP messages; the ServiceScheduler controls thestate transitions of u-threads wrappingservice instances. This is accomplished by means of thefollowingprimitives: submit , suspend, resume, kill .The primitives are reported as blackthinlines in theser- vice providerarchitecture of Fig.1,and as blackarrows in thetransition state diagram in thesame figure. The submit primitivecreatesanew u-thread, wrap- ping up aspecified service operation andputsitinthe running state. TheService Scheduler maintains three queues to manageu-threads,and the wrapped services instances,inthe differentstates: Runqueue -itcontains all service instances running or readytobescheduled for execution. Services in this queueare by default executed in time-sharing mode by assigning to each u-threadatime quantum that can be changedby theService Scheduler (also in response to incoming SOAP requests). Waitqueue -itcontains all service instances suspended andthusremovedfrom theRunqueue.The providermay decidetosuspend/resumeservice execution according to both its ownscheduling policy,and upon receiving specific SOAP requests from an external application, e.g. ametascheduler. Expirequeue -itcontains all u-threads’ descriptorswrapping up terminated service instances whose results arenot yetrequested by clients via SOAP messages. U-threads aremaintained in an inactivestate in this queueto temporarily storeunused service results untilacertain expiration time is elapsed. The expiration time is notnecessarily asystem specificparameter, anditcould be specified as aQoS parameter at thesubmittingphase.
101 It should be noted that in theService Scheduler module differentscheduling policies can be implemented at application-level overriding thedefault oneboth by changingthe time quantum andbyaccessingand managingthe Runqueue in differentmodes. In this way theservice provider is able to change itsown local schedulingpolicy at run-time directly invoking the primitives to control service execution.
3.2 Service ControlAPIs
As outlined earlier,the proposed infrastructure allowsalso to accessthe primi- tives to control service execution as webservices to be invokedbyany external clientprogram. In suchacase, aclient-providerinteraction takes place anditis implemented as an asynchronous request/response operation with polling[22]. Asynchronicityallows theclienttoproceed the computationconcurrently with theweb service executionuntil theoperation result is required:atthispointthe clientneeds to synchronize withthe providerand establishes anew communica- tion to retrievethe result. We extend the asynchronous request/response operation mode with func- tionalities to suspendand resumeweb service execution. The client-provider asynchronous interactionpatternisdescribed in Fig.2where aclientinvokes a webservice operation,named”Operation A”,offered by thecontinuation-based service provider. Theprimitives to control service execution are exposed as thefollowing WSDL operations: submit, suspend, resume and probe.They represent meta- operations becausethey areinvoked by clients to controland to monitor web service operation executions. Theclient-providerinteraction patternisstartedbyclients invoking the submit WSDL operation to request aservice execution. The submit request invokesthe ”Operation A” on aset of input argumentsand starts itsexecution (seethe syntax in Fig.3(a)). Theprovidersendsbacktothe clientareply with an acknowledge that thesubmission is done together with a correlation ID.The correlation ID is unique andisset by theprovidertobeused together with theclienttoassociate subsequentrequests andresponses belonging to thesame client-provider transaction. Correlationtokens to embedmultiple messages in transactions arewidely usedinmostasynchronousweb service protocolproposals [23,24]. Approaches differfor theparticular protocoladopted (JMS, SOAP,and so on)and/or the mechanismsused to implementmessagecorrelation. In ourapproachcorrelation is explicitly included in SOAP messagebodies as showninFig. 3. The submit request includes aset of qos parameters. QoS attributes arespec- ified by clients to driveoraffect scheduling policy of theweb service operation execution. The clientstarts theexecutionof”Operation A” andcontinues its computa- tion so that it mayalso decidetosuspend theweb service execution, to resume it later on up to completion.
102 Client WebService (invoker) (provider)
1: Submit”Operation A” (Request)
2: Ack. ”OperationAstarted” (Reply with Correlation ID)
3: Suspend ”Operation A” (Request with Correlation ID)
4: Ack. ”Operation Asuspended”(Reply)
5: Resume ”Operation A” (Request with Correlation ID)
6: Ack. ”Operation Aresumed”(Reply)
7 1 :Proberesult (Request with Correlation ID)
8 1 :Ack. ”no result yet”(Reply)
7 n :Proberesult (Request with Correlation ID)
8 n :Response of ”Operation A” (Reply)
Fig. 2. Asynchronous request/response operation with polling and suspend/resume facility
To perform suspensionand resumingactions the clientuses the suspend and resume meta-operations. The suspend request usesthe correlation ID to refertothe webservice operation (instance) to be suspended.Uponreceiving the request, the provider capturesand savesthe execution state of ”OperationA”, anditsendsbackto theclientanacknowledge. The resume request usesthe correlation ID to refertothe webservice oper- ation (instance) whose executionmust be resumed. Upon receiving the request, the providerretrieves the executionstate (continuation) stored and tagged with thespecified correlationID. It then resumesthe webservice operation andsends back to theclientanacknowledge. As describedinFig. 3(b), also the resume request includes specifications of QoSparameters.Thismeans that in ourframework aservice executioncould be resumed by changingatrun-time theweb service operation scheduling policies. Client-providersynchronizationisimplemented by the probe request. The probe checks if ”Operation A” is finished. If therequestoccursbefore the web service operation exits(thefirst probe of Fig.2), theclientisacknowledged that theresult in not readyyet. After asuccessful probe request, the client synchronizes withthe providerand gets theresult.
103
(a) (b)
Fig. 3. Service control primitives syntax: (a) submit;(b) resume
4Implementation
We outlineherethatour proposalofaservice provider architecture with support to user-level preemptible service execution can be implemented with one of the continuation-based languages mentioned in Sec.2.Infactuser-level threads with suspensionand resumingcontrol functions can be implemented in ahosting languagesupporting first-class continuation management. Ourservice provider current implementationisinStacklessPython [10]. The choiceisdue to two main motivations. First,the language directly supplies the support of user-level threadsbased on continuations,named tasklets that are built-in user-level lightweightthreads with constructstocontrol their creation, suspension, resumingand schedulingatapplicationlevel. Secondly,the Python scriptinglanguage offersafast prototypingand testingprogrammingenviron- mentfor theproposed SOAframework, with minor performance penalties com- pared to other languages likeC.Furthermore, Python is one of thelanguages that providesasatisfactorysupportoflibraries andtools forthe development of webservices [25]. We implemented our user-level threadsasextensions of tasklets objects (see Fig.4), named WSTasklets.WSTasklets arethreads wrappingupfunctions whose code implements webservice operations (inWSDL specification).Web service operationsare given as parameterstoaWSTasklet constructor method andexecuted within its context (see Fig. 4). Our u-threadsinheritbytasklets the required functionalities to suspendand resumeweb service operation executions by means of theStacklessPython con- tinuation storingand resumingfeatures. The service provider implementationisaServiceContainer objectman- agingand controllingapool of WSTasklets. It executes in the context of the main WSTasklet,which is alwaysinthe running state.Its execution is inter- leavedwith other tasklets that are presentinthe Stackless Python systemwide runqueue. Note thatthisqueue containsall tasklets in thesystem (Phytonin-
104 terpreter) while theservice provider Runqueue definedinSect. 3.1 is usedto manageand controlWSTasklets wrapping service instances in thecontext of theservice container. As describedinFig. 4, the ServiceContainer object, once started,exe- cutes anever-ending loop interleaving the executionofthe Request Handler andthe ServiceScheduler (seerespectively the handle request noblock() and timeshared scheduling() functions). TheRequestHandler listens to thespecified socketaddress/port to probe forincomingSOAPrequests. If aSOAPmessagearrived, it is processed by the TaskletController object: this is thePython moduleprovidingaccess to the controlprimitives of services offered by ourframework. In thebottom of Fig.4we report only fragmentsofthe TaskletController code: the tsksubmit method implements the submit primitiveWSDL interface. In the same part of Fig.4the foo method represents an example of aweb service of ourproviderwhose execution can be controlled by means of theset of primi- tives whose semantics and interfacesweredefined in Sect. 3. It should be noted that webservice code does not need to be rewritten in order to be integrated and providedbyour service provider. Only onemodificationisneeded to convert the return construct withasystem-dependentversion: in fact,according to our design, service terminationleavesthe wrappingthreadstill alivealthough in an inactivestate (Expirequeue) just forthe time required by theservice consumer to gather the result storedinthe expiring WSTasklet. Rememberthatnovalueis returnedbythe service to clients if amaximum expiration time elapses without no probe incoming requests. The Service Scheduler is themoduleinchargeofmanagingthe user-level thread Runqueueand Waitqueuedescribed in the previous section. In the exam- ple of Fig.4we report around-robinscheduler module that assigns at each round afixed time quantum(timeshare)for executiontoall threadsinthe Runqueue. As before mentioned thescheduling module is acomponentofour framework that can be modified to program andexperimentwith differentscheduling poli- cies of service execution.
5The Economic-Grid Scenario
In order to reachthe fullpotential of grid computing, it is well-recognizedthat thegridneeds to shift towards production-oriented platforms,sothatservice providersare motivated to makeavailable theresources they provide. Acomputational economyapproachcan be usedtoprovide the possibility of buyingand sellingcomputational resources in the same way as goodsand servicesare bought andsold in therealworld economy[26].Adoptingacompu- tationaleconomy-based view [27,28] whereservices areprovidedatagiven cost constitutes perse amechanism for encouragingresource owners to contribute their resource(s) for the constructionofthe grid,and compensate them basedon theresource usage,i.e. on thevalueofthe work done.So, theultimate success of computationalgrids as aproduction-oriented commercial platformfor solving
105 problemsiscritically dependent on thesupportofmarket/economy-based mech- anisms to resourcemanagement.Insuch“commercial” computational grids, re- source owners actasservice providersthatmakeaprofit by selling theirservices to usersthatact as buyers of computational resources forsolvingtheirproblems. Asuitable applicationdomainfor theproposed architecture is theeconomic- aware gridsinwhich Quality-of-Service features mayinclude the cost of the service to be provided. In fact,inour framework it is possible to associatetothe requestofaservice execution a qos parameter taking into accountthe cost of aservice andtoallowboth theclientand theprovidertouse itsvaluetodrive suspensionand resumingofservice execution. It is likely that in very dynamic and changingcomputingenvironments like thegrid, service providerscan makedifferent decisionsonthe Quality-of-Service they provide their services with, according to therequirements of new service requests. Forexample, theymay want to breakorchangesome previous agree- ments when anew consumer comes withamore remunerativerequest. The pro- posed framework makes it possible to implementdynamicpriority-based service scheduling policies by means of suspension and resuming facilities andbytak- ingintoaccount qos parameter changesatrun-time, so that more remunerative service requests can be executed withahigher priority.
6Conclusions
In this work we propose aservice provider architecture basedoncontinuations managementthatprovidesprimitives to control webservices executionand to implementdifferent service scheduling policies.The primitives are offered by the service provider to external(client) applications throughSOAPmessages. With this approachwemay implementthe service execution policies at two levels:the lowerlevel relies on theservice provider layertoimplementlocal schedulers; the higher levelcan be ametascheduler that interacts withmultiple service providerschedulers in adistributed settingbymeans of SOAP messaging. The close related work we found in literatureisthe framework proposed in [15] thatallows fortwo-level approachtoprocess scheduling: theuser-level schedulerdivides time into equal size decision intervals (higher-level quantum) at thebeginning of whichitdecides the processes eligible to run during the interval; thekernel-level scheduler executes the selected processes according to theoperatingsystem schedulingpolicy.The selection of processes to be run is carried outusing suspend andresume mechanisms offered by theunderlying operating system.Onthe contrary,our approachrelies completely on user-level suspend andresume functions,and it providesscheduling mechanisms in the extentofthe service providerapplicationrather than in the operating system one. Our approachhas similaritiestoCommunity Scheduler Framework (CSF) [29], an infrastructure providing facilities to define,configure andmanage meta- schedulers for the grid.Metaschedulingisconceived as ahigher level of schedul-
106 ingdecisions to coordinate local schedulers (PBS [30], LSF[31]) on hostsand clusters in agridenvironment. LikeCSF we provide high-level schedulingfunctionalities either to service consumers or to metascheduler middleware. CSF functionalities mainly target configuration and managementofscheduling policies and their coordinationin agridenvironment. LikeCFS, ourframework allows service execution control and scheduling queues configuration and managementthroughSOAP/WSDL messaging. Although both approaches supportsuspension/resumingfacilities, CSF ap- plies them to control jobs, i.e. processes running in thehosting operating system environments. CSF defines high-level scheduling services(in Java)tomap con- sumer requests into job control commandsimplemented at lowerlevel in the scheduler runningonthe target host (kernel scheduler) or clusters(as PBS and LSF). In both cases,CSF job-control functionalitydependsonthe underlying operating system layer. Sinceinour approachservice controldoesnot rely on theoperatingsys- tem layer, theframework results in aflexible andeasilyadaptable program- ming environment to develop andexperimentscheduling facilities, policies and service-control in differentservice-oriented architecture applications. Further- more,portabilitycan be guaranteed across heterogeneous programmingenvi- ronments with(explicit) supportofcontinuation capturing andresuming. We plan to test the proposed architecture by setting up an experimental applicationwhere aservice provider can vary its schedulingpolicy at run-time according to theincomingservice requests by changingthe time quantumpa- rameter representingthe cost associatedtoeachrequestsothatitcan maximize its income.
References
1. Foster, I., Kesselman, C., Nick, J., Tuecke,S.: Thephysiology of the grid: An open grid service architecturefor distributed system integration. Technical report Open Grid Service Infrastructure WG (2002) 2. MacLaren, J., Sakellariou, R., Garibaldi, J., Ouelhadj, D.: Towards service level agreementbased scheduling on the grid. In: Proceedings of the second European Across GridsConference. (2004) 3. Daniel P. Friedman,C.T.H., Kohlbecker, E.E.:ProgrammingwithContinua- tions. In: Program Transformation and Programming Environments. Springer- Verlag(1984) 263–274. 4. Di Napoli, C. and Mango Furnari,M.: Acontinuation–based distributed lisp sys- tem. In: Proceedings of the First International Conference on Massively Parallel Computing Systems, IEEE ComputerSocietyPress(1994) 523–527 5. Abelson,H., Sussman,G.J.: Structureand Interpretation of Computer Programs. 2nd edn. Volume ISBN 0-262-01077-1.MIT-Press (1993) 6. RIFEWeb Continuations. http://rifers.org/wiki/display/RIFE/Web+ continuations (2007) 7. JettyContinuations. http://docs.codehaus.org/display/JETTY/Continuations (2007)
107 8. The JakarteProject: Commons Javaflow. http://jakarta.apache.org/commons/ sandbox/javaflow (2007) 9. The Apache Jakarta Project. http://jakarta.apache.org (2007) 10. Tismer, C.: Stackless python. http://www.stackless.com (2007) 11. Thomas, D., Fowler, C., Hunt, A.: Programming Ruby. 2nd edn. Volume ISBN 0-9745140-5-5.(October 2004) 12. Rhino: Javascript for Java. http://www.mozilla.org/rhino/ (2007) 13. RhinoWithContinuations. http://wiki.apache.org/cocoon/ RhinoWithContinuations (2007) 14. The ApacheCocoonProject. http://cocoon.apache.org/ (2007) 15. Newhouse, T., Pasquale,J.: Auser-level framework for scheduling withinservice execution environments. In: Proceedingsofthe 2004 IEEE International Confer- ence on Services Computing (SCC ’04), Washington, DC, USA,IEEE Computer Society(September2004) 311–318 16. The ApacheSoftware Foundation: Apache webservices project-axis. http: //ws.apache.org/axis (2007) 17. IBMdeveloperWorks: WebSphere. http://www-128.ibm.com/developerworks/ websphere (2007) 18. Johnson, R.E., Foote, B.: Designing reusable classes. Journal of Object-Oriented Programming 1 (2) (1988)22–35 19. Fowler, M.: Inversion of control containers and the dependency injection pattern. http://www.martinfowler.com/articles/injection.html (2004) 20. Vadhiyar, S., Dongarra, J.: Ametascheduler for the grid. In: Proceedings of the 11th IEEE Symposium on High-Performance Distributed Computing. (2002) 21. Booth, D., Liu, C.K.:Web services description language(wsdl)version 2.0 part 0 primer. http://www.w3.org/TR/2007/PR-wsdl20-primer-20070523 (2007) 22. Adams, H.:Asynchronous operations and webservices, part2. http://www-128. ibm.com/developerworks/library/ws-asynch2/index.html (2002) 23. Swenson, K., Ricker, J.:Asynchronous webserviceprotocol. http://xml. coverpages.org/AWSP-Draft20020405.pdf (2002) 24. Sun Developer Network: Developingasynchronous webservices withjavamessage serviceinsun java studio enterprise 7. http://developers.sun.com/prodtech/ javatools/jsenterprise/reference/techart/jse7/asynch.html (2005) 25. SourceForge.net: Python webservices. http://pywebsvcs.sourceforge.net (2007) 26. Wooldridge, M.: Engineering the computational economy. In: Proceedings of the Information SocietyTechnologies Conference (IST–2000), Nice,France (2000) 27. Buyya, R., Abramson, D.,Giddy,J.: An economy driven resource management architecture for global computational powergrids. In: Proceedings of The2000 International ConferenceonParallel and Distributed Processing Techniquesand Applications (PDPTA2000), Las Vegas, USA (2000) 28. Buyya, R., Giddy,J., Abramson, D.: An evaluation of economy–based resource trading and scheduling on computational powergridsfor parameter sweep appli- cations. In: Proceedings of The Second Workshop on ActiveMiddlewareServices (AMS 2000), In conjuctionwithNinth IEEEInternationalSymposiumonHigh Performance,Pittsburgh, USA (2000) 29. Platform: Open sourcemetascheduler for virtual organizations withthe commu- nityscheduler framework(csf). Technical report, http://www.cs.virginia.edu/ ~ grimshaw/CS851-2004/Platform/CSF_architecture.pdf (2007) 30. Open portablebatchsystem. http://www.openpbs.org (2007) 31. Load sharing facility. http://www.platform.com (2007)
108 class ServiceContainer(ServiceContainer): sleepingTasklets={} runningTasklets ={} expiredTasklets ={} Tasklets={} timeshare =1000
def __init__(self, server_address, services=[], RequestHandlerClass=SOAPRequestHandler): ... return ServiceContainer.__init__(self, server_address, services=[], RequestHandlerClass=SOAPRequestHandler)
def timeshare_scheduling(self): """Round-robin scheduling with fixed time-share""" #ifthe main u-thread is not the only running... if stackless.getruncount() != 1: t=stackless.run(self.gettimeshare()) #Ifwegot atasklet, it was the interruptedone ... we need to reinsert it for rescheduling. if t: t.insert()
def serve_forever(self): """Service Container: interleave communicationand scheduling activities""" while 1: #handle incoming requests (SOAP) in not-blockingmode self.handle_request_noblock() #schedule services self.timeshare_scheduling() ...
def AsServer(port=80, services=(), RequestHandlerClass=SOAPRequestHandler): ’’’services -- list of registered and exposedweb service instances’’’ address =(’’, port) sc =PreemptServiceContainer(address, RequestHandlerClass=RequestHandlerClass) #register web services in the service container for service in services: path =service.getPost() sc.setNode(service, path) service.setContainer(sc) sc.serve_forever()
print "... starting server" AsServer(port=12321, services=[TaskletController()],RequestHandlerClass=SOAPRequestHandler)
class TaskletController(ServiceSOAPBinding): soapAction ={} root ={} container ={} _wsdl =""" ..."""
def __init__(self, post=’/TaskletScheduler’, **kw): ServiceSOAPBinding.__init__(self,post)
def setContainer(self,sc): self.container =sc
def tsksubmit(self, quanta, service,*args): if service in dir(self): #create the tasklet and use it to wrap service t=WSTasklet(eval("self.%s"%service))(*args) #set qos parametersoftasklet t.setquanta(quanta) unID ="%s:%i" %(t.getname(), t.getID()) #manage scheduling queues self.container.Tasklets[unicode(unID)] =t self.container.runningTasklets[unicode(unID)] =t #schedule tasklet fo execution t.insert() #ifback the tasklet has run for aquanta and now is suspended return [t.getname(), t.getID(), t.getquanta(), "suspended" ] else: return "\n...no such service %s" %service
...
def foo(self, name): n=1 while n<1000000: n+=1 self._return("Hello "+name)
....
Fig. 4. Continuation-basedserviceproviderimplementationinPython
109