REST architecture for perfSONAR - Nina Jeliazkovavedina.users.sourceforge.net/publications/2010/RESTful_perfSONAR... · REST architecture for perfSONAR Nina Jeliazkova (BREN), Candido

REST architecture for perfSONAR

NinaJeliazkova(BREN),CandidoMontes(RedIris)

GN3JRA2Task3

2010

AninvestigationofRESTarchitectureforwebservicesanditsapplicabilitytoperfSONARwebservices

infrastructure.WepresentashortbackgroundonRESTprinciplesandproposeamappingofexistingperfSONARschemasandprotocolsasRESTresources.Additionally,theresultsofaperformancecomparisonofSOAPandRESTdemoimplementationofperfSONARserviceshasbeenperformed,with

resultsfavouringtheRESTarchitecture.

1RepresentationalStateTransfer(REST) .................................................................................................... 5

1.1 Designprinciples......................................................................................................................... 5

1.1.1Resourceoriented....................................................................................................................... 5

1.1.2Transportprotocol ...................................................................................................................... 6

1.1.3Operations .................................................................................................................................. 6

1.1.3.1RESTfuloperations ............................................................................................................... 6

1.1.3.2Non‐RESTfuloperations ....................................................................................................... 6

1.1.4Resourcerepresentation ............................................................................................................ 7

1.1.5HypermediaastheEngineofApplicationState(HATEOAS) ....................................................... 7

1.1.6Errorcodes.................................................................................................................................. 8

1.2 Constraints ................................................................................................................................. 8

1.3 Designgoals................................................................................................................................ 8

1.4 Drawbacks .................................................................................................................................. 9

1.5 Frameworks ................................................................................................................................ 9

1.6 ExamplesofRESTAPIs ................................................................................................................ 9

2RESTAPIforperfSONARservices............................................................................................................ 11

2.1 MIMEtypes .............................................................................................................................. 11

2.2 ResourcesandURLpatterns..................................................................................................... 11

2.2.1Service....................................................................................................................................... 12

2.2.2Topologyelements.................................................................................................................... 12

2.2.3Topologyelementsofspecifictype(Metadata) ....................................................................... 13

2.2.4Topologyelementsofspecifictype(Data)................................................................................ 15

2.2.5Asingletopologyelement ........................................................................................................ 18

2.2.6Monitoringdataofatopologyelement.................................................................................... 19

2.2.7Metadatachaining .................................................................................................................... 20

2.3 Errorcodes ............................................................................................................................... 21

2.4 Echomessage ........................................................................................................................... 21

2.5 Authenticationmodel............................................................................................................... 22

2.5.1ProfilebasedonX.509digitalcertificates................................................................................. 23

2.5.2ProfilebasedonSAMLassertions ............................................................................................. 23

2.5.3Requestnotvalid ...................................................................................................................... 24

2.5.4Newmodel(REST)vsClassicmodel(SOAP).............................................................................. 24

2.6 Performancecomparison ......................................................................................................... 24

2.6.1SOAPvsRESTperformancecomparison................................................................................... 25

2.6.1.1PerfsonarECHOmessage................................................................................................... 26

2.6.1.2ExtendedECHOmessage ................................................................................................... 26

2.6.1.3Summary ............................................................................................................................ 31

2.6.1.4Conclusions ........................................................................................................................ 32

2.6.2PerformancecomparisonofdifferentRESTimplementationsofextendedECHOservicesbymessagegenerationandmessagesize .............................................................................................. 32

2.6.2.1PerformanceofRESTservices,relatedtothesizeofresponsemessage .......................... 32

2.6.2.2PerformanceofRESTservicesforthesamemessagesize,usingdifferentJavalibrariesfor

messagegeneration....................................................................................................................... 37

2.6.2.3Summary ............................................................................................................................ 41

2.6.3PerformancecomparisonofSOAPanddifferentRESTimplementationsofSetupDataresponse........................................................................................................................................................... 42

2.6.3.1PerformanceofSOAPservices,relatedtothequerytimerange ...................................... 43

2.6.3.2PerformanceofRESTservices,relatedtothequerytimerange ....................................... 43

2.6.3.3REST‐StAX........................................................................................................................... 45

2.6.3.4Summary ............................................................................................................................ 47

2.6.3.5Conclusions ........................................................................................................................ 48

2.6.4PerformanceofSOAPimplementations ................................................................................... 48

2.7 Conclusions............................................................................................................................... 49

1 Representational State Transfer (REST)

RESTisasoftwarearchitecturestyle,definedbyRoyFieldinginhisPhDthesis(2000).ThereisamultitudeofinformationonRESTfuldesignprinciples,developmentframeworksandexamples.Forastart,thefollowingreferencescouldberecommended:

• Chapter5ofFielding'sdissertation:

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

• LeonardRichardson,SamRuby,RESTfulWebServices,O'Reilly2007:http://oreilly.com/catalog/9780596529260

• FromSOAtoREST:DesigningandImplementingRESTfulServices,TutorialatWWW2009:http://dret.net/netdret/docs/soa‐rest‐www2009/

• HowDoIModelState?LetMeCounttheWays,ACMQueue2009:

http://queue.acm.org/detail.cfm?id=1516638

• rest‐discussYahoogroup:http://groups.yahoo.com/group/rest‐discuss/

ContrarytoestablishedWS‐SOAPstandards,thereareno(currently)standardsforRESTfulapplications,butmerelydesignguides.Perhapsthefirstmovetowardsstandardizationistheupcoming(FirstInternationalWorkshoponRESTfulDesignWS‐REST2010)tobeheldatWWW2010inRaleigh,North

Carolina,USAnext26April2010.

Besidesalldiscussions,settingRESTagainstSOAP,thiskindofcomparisonisnotentirelycorrect,forSOAPisaprotocol,andRESTisanarchitecturalstyle,notaprotocol.

SOAPvsREST:http://www.iks.inf.ethz.ch/education/ss07/ws_soa/slides/SOAPvsREST_ETH.pdf

RESTstylecanbebrieflysummarizedas:

1.1 Design principles

1.1.1 Resource oriented

Everyobject(resource)isnamedandaddressable(e.g.HTTPURL)

Example:http://perfsonarservice.net/MeasurementArchive/interface/interface_identifier

RESTfullAPIdesignstartsbyidentifyingmostimportantobjectsandgroupsofobjects,supportedbythesoftwaresystemandproceedsbydefiningURLpatterns.Commonpatternsare:

Returnslistofobjectsinsomeformathttp://myservice.net/myobject

• Returnsrepresentation(s)ofanobject,identifiedby{myobjectid}

http://myservice.net/myobject/{myobjectid}

Patternsmaybenested,e.g.http://myservice.net/myobject/{myobjectid}/details/{detailsid}

1.1.2 Transport protocol

HTTPisthemostpopularchoiceoftransportprotocol,butthereareexamplesofsystemsusingotherprotocolsaswell.

1.1.3 Operations

Resources(nouns)supportlimitednumberofoperations(verbs).HTTPoperationsarethecommonchoice,whenthetransportprotocolisHTTP.

1.1.3.1 RESTful operations

• GET(retrievetheobjectunderspecifiedURL)

• PUT(updatethecontentofanobjectatthespecifiedURL)

• POST(createanewobjectandreturntheURLofthenewlycreatedresource)

• DELETE(deletetheobject)

Alloperations,exceptPOSTshouldbesafe(nosideeffects)andidempotent(sameeffectifexecutedmultipletimes).

1.1.3.2 Non-RESTful operations

• Everythingelse,e.g.POSTXMLmessagetohttp://perfsonarservice.net/MAservice

Decidingontheoperationtobedone,onthebasisofinterpretingPOSTedmessagecontent(thewayatypicalSOAPserviceworks!)isNOTrecommended.Thisisreferredtoas"overloadedPOST"and

consideredviolationofRESTfulprinciples!

1.1.4 Resource representation

EveryresourceisdefinedbyanURI.IfGEToperationonaresourceURIreturnssomecontent,itisregardedas"dereferencable"(effectivelyitisanURL).Aresourcemayreturncontentindifferentformats(byspecifyingMediaTypeintheAccept:headerofGEToperation).Thecontentisregardedas

resource"representation".Therecouldbemultiplerepresentationsofthesameresource(e.g.text/htmlortext/xml).

RESTfullAPIdesignincludesspecificationofallowedmediatypesforeachresource/operationpair.

1.1.5 Hypermedia as the Engine of Application State (HATEOAS)

Allresourcesshouldbereachableviaasingle(orminimum)numberofentrypointsintoaRESTfulapplications.Thus,arepresentationofaresourceshouldreturnhypermedialinkstorelatedresources

• Forexample/perfsonar/interface/{id}resourceshouldreturnlinksto

/perfsonar/interface/{id}/metadataand/perfsonar/interface/{id}/metadata

• RESTAPIsmustbehypertextdriven(http://roy.gbiv.com/untangled/2008/rest‐apis‐must‐be‐hypertext‐driven)

1.1.6 Error codes

HTTPStatuscodesareusedtoindicateanoperationsuccessorfailure.

RESTfullAPIdesignincludesspecificationofstatuscodesforeachresource/operationpair.

1.2 Constraints Client‐server‐Clientsareseparatedfromserversbyauniforminterface.

Cacheable‐Clientsareabletocacheresponses.

Statelessdesign‐Noclientcontextshouldbestoredontheserverbetweenrequests.Eachrequestfromanyclientcontainsalloftheinformationnecessarytoservicetherequest,andanystateisheldinthe

client.

Cookiesareconsideredbadpractice!

Layered‐Aclientcannotordinarilytellwhetheritisconnecteddirectlytotheendserver,ortoanintermediaryalongtheway.Intermediaryserversmayimprovesystemscalabilitybyenablingloadbalancingandbyprovidingsharedcaches.Theymayalsoenforcesecuritypolicies.

Uniforminterface‐Theuniforminterfacebetweenclientsandservers,(HTTPGET/PUT/POST/DELETEverbsonly)simplifiesanddecouplesthearchitecture,whichenableseachparttoevolveindependently.

1.3 Design goals • Scalabilityofcomponentinteractions;

• Generalityofinterfaces;

• Independentdeploymentofcomponents;

• Intermediarycomponentstoreducelatency,enforcesecurityandencapsulatelegacysystems

RESTfuldesignprinciplesareadvocatedasbeingsuccessful,forunderlyingtheexistingWWWarchitecture.RESTapplicationarebecomingincreasinglypopular,thetrendwithmajorservicevendors

aretoofferRESTAPIalongwithanexistingSOAPAPI.SomereportRESTAPIusageisincreasingandSOAPAPIusagedecreasing.

1.4 Drawbacks • Lackofstandards.

• Developmentframeworksarerelativelyyoung.

• ThecommonlyrecommendedpracticeforsecurityistouseHTTPAuthenticationmechanismsandSSL.Othersolutionsareemergingaswell(discussedbelow).

• ExamplesofRESTfulfederatedsystemsarerare.

1.5 Frameworks NonexhaustivelistofpopularframeworksfordevelopingRESTfulapplications:

• Java‐Restlet,Jersey

• PHP‐CakePHP

• Ruby‐RubyOnRails,Sinatra

• Perl‐PerlApplicationFrameworkandERPApplications

1.6 Examples of REST APIs • AmazonWebServices

o AmazonS3RESTAPI

• GoogleDataAPIprotocol

• TheSunCloudAPI

• Yahoowebservices

• Doodle

• Flickr

• NetFlix

• TwitterRESTAPI

• FacebookRESTAPI

• Blinksale

2 REST API for perfSONAR services

TheproposalisbasedontheRESTviewthatdesignofaRESTsystemstartsbyidentifyingdomainobjects;followingbymappingobjectstoURLpattenrsanddefiningoperationsoneachobject,byusingHTTPverbs.IncaseofPerfSONAR,theobjectsofinterestaremonitoredtopologyelements(e.g.

interfaces,links,etc.).Itseemssuitabletorepresenttopologyelementsasresources,havinguniqueURL.

TheproposalfollowstherecommendedpracticeinRESTistohavemultipleURLs,correspondingtothedomainobjects,andonly4typeofactions(verbs),corrsespondingtoHTTPGET/POST/PUT/DELETEoperations.

ThereisnotnecessaryastraightforwardmapbetweenexistingPerfsonarSOAPmessagesandtheREST

API,butNMWGschemaisusedasXMLrepresentationforallRESTPerfSONARresources.RequestsaregenerallysimplifiedtouseURLs,insteadofspecifyingparametersinXMLmessage(theremightbeexceptions).

2.1 MIME types ARESTresourcemayhavemorethanonerepresentation.Forexample,arepresentationofamonitoredinterfacemayreturnitsrepreentationinXMLformat,followingNMWGschema,butmayalsoreturn

alternativerepresentationindifferentformats(evenreturnagraphofthemonitoreddatainimage/jpegformat)

MediaType[1]:

• text/xml

• application/vnd.xml

• definePerfSONARspecificMIMEtype(ifnotexistingalready)application/vnd.perfsonar.xml

• text/uri‐list(returnslistofURLstoRESTresources)

• alternativeMIMEtypes(e.g.image,ordatarepresentationinmoreefficient/compressed

formats)

2.2 Resources and URL patterns

2.2.1 Service

URL:http://servicehostname:port/servicename/

Representation:text/xml

Operations:

• GET‐returnmetadataoftheserviceitself

• PUT‐input:XMLwithservicemetadata;output:addsservicemetadata

• POST‐input:XMLwithservicemetadata;output:replacesservicemetadata

• DELETE‐removeservicemetadata(wemaydecidenottoimplementthisoperation)

2.2.2 Topology elements

URL:http://servicehostname:port/servicename/topologyelements?paramName=value&paramName=value1&paramName1=value2


Operations:

• GETReturnsNMWGrepresentationoftopologyelements(responseoftheNMWG

MetadataKeyRequest)

• PUT

• POSTCreatenewtopologyelement(s)bysendingrepresentationinNMWGTXML

• DELETEDeletealltopologyelements

Parameters:parametersandvaluesasinNMWG/NMWGT

Examples:

• Getallmetadataelementshttp://servicehostname:port/servicename/topologyelements

• Getalltopologyelements,wherethereexistdataforutilizationanderrorsmetricshttp://servicehostname:port/servicename/topologyelements?eventType=http://ggf.org/ns/nmwg/characteristic/utilization/2.0&eventType=http://ggf.org/ns/nmwg/characteristic/err

ors/2.0&startTime=1262304000&endTime=1262390400&timeType=unix

• FindaninterfacewithIP10.0.0.1http://servicehostname:port/servicename/topologyelements?ipaddress=10.0.0.1‐>returnsURL

oftheinterfaceintheformofhttp://servicehostname:port/servicename/topologyelements/interface/interface‐id(seenextsection)

2.2.3 Topology elements of specific type (Metadata)

SOAPrequest:MetadataKeyRequest

<nmwg:message id="1264011628" type="MetadataKeyRequest" xmlns:errors="http://ggf.org/ns/nmwg/characteristic/errors/2.0/" xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/" xmlns:select="http://ggf.org/ns/nmwg/ops/select/2.0/">

<nmwg:metadata id="meta1">

<errors:subject id="iusub1">

<nmwgt:interface/>

</errors:subject>

<nmwg:eventType>

http://ggf.org/ns/nmwg/characteristic/errors/2.0

</nmwg:eventType>

</nmwg:metadata>

<nmwg:data id="data_1" metadataIdRef="meta1"/>

</nmwg:message>

URL(RESTrequest):

http://servicehostname:port/servicename/topologyelements/{type‐of‐topology‐element}/metadata?parameterName=value

SOAPresponse:MetadataKeyResponse

Representation:

• (RESTGETresponse)

• NMWGXML,contenttypetext/xmlortobedefined

<nmwgt:interface>

<nmwgt:hostname>hostname</nmwgt:hostname>

<nmwgt:ifName>ifName</nmwgt:ifName>

<nmwgt:ifDescription>ifDescription</nmwgt:ifDescription>

<nmwgt:ifAddress>ifAddress</nmwgt:ifAddress>

<nmwgt:ifIndex>ifIndex</nmwgt:ifIndex>

<nmwgt:direction>direction</nmwgt:direction>

<nmwgt:capacity>capacity</nmwgt:capacity>

</nmwgt:interface>

• text/uri‐list,returninglistofURLsofthespecifictopologyelements,matchingthequery,asbelow

http://servicehostname:port/servicename/topologyelements/interface/id1

http://servicehostname:port/servicename/topologyelements/interface/id2

Operations:

• GETReturnqueryresultsinNMWGXML

• PUTUpdateinformationoftopologyelementsinput:Content‐type:text/xml;output:Content:NMWGrepresentationofaninterfacemetadata

• POSTAddinformationoftopologyelementsinput:Content‐type:text/xml;output:

Content:NMWGrepresentationofaninterface

• DELETEDeletealltopologyelementsofthistype

Examples:

• ContentType:text/xmlhttp://servicehostname:port/servicename/topologyelements/interface/metadata?eventType=h

ttp://ggf.org/ns/nmwg/characteristic/utilization/2.0&direction=in

<nmwgt:interface>

<nmwgt:hostname>hostname1</nmwgt:hostname>

<nmwgt:ifName>ifName1</nmwgt:ifName>

<nmwgt:ifDescription>ifDescription1</nmwgt:ifDescription>

<nmwgt:ifAddress>ifAddress<1/nmwgt:ifAddress>

<nmwgt:ifIndex>ifIndex1</nmwgt:ifIndex>

<nmwgt:direction>in</nmwgt:direction>


</nmwgt:interface>

<nmwgt:interface>

<nmwgt:hostname>hostname2</nmwgt:hostname>

<nmwgt:ifName>ifName2</nmwgt:ifName>

<nmwgt:ifDescription>ifDescription2</nmwgt:ifDescription>

<nmwgt:ifAddress>ifAddress2</nmwgt:ifAddress>

<nmwgt:ifIndex>ifIndex</nmwgt:ifIndex>



</nmwgt:interface>

• ContentType:text/uri‐listhttp://servicehostname:port/servicename/topologyelements/interface/metadata?eventType=h

ttp://ggf.org/ns/nmwg/characteristic/utilization/2.0&direction=in

http://servicehostname:port/servicename/topologyelements/interface/1


2.2.4 Topology elements of specific type (Data)

SOAPrequest:SetupDataRequest

<nmwg:message id="message1264011954" type="SetupDataRequest" xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/" xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/" xmlns:select="http://ggf.org/ns/nmwg/ops/select/2.0/">

<nmwg:metadata id="meta_in">

<netutil:subject id="subject_1">

<nmwgt:interface>

<nmwgt:hostName>rtr.chic.net.internet2.edu</nmwgt:hostName>

<nmwgt:ifName>ge-2/1/0.178</nmwgt:ifName>

<nmwgt:ifAddress>192.245.196.110</nmwgt:ifAddress>


</nmwgt:interface>

</netutil:subject>

<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>

</nmwg:metadata>

<nmwg:metadata id="m_param_in">

<select:subject id="subject1_2" metadataIdRef="meta_in"/>

<nmwg:eventType>http://ggf.org/ns/nmwg/ops/select/2.0</nmwg:eventType>

<select:parameters id="param_3">

<nmwg:parameter name="startTime">1264011835</nmwg:parameter>

<nmwg:parameter name="endTime">1264271035</nmwg:parameter>

<nmwg:parameter name="consolidationFunction">AVERAGE</nmwg:parameter>

<nmwg:parameter name="resolution">300</nmwg:parameter>

</select:parameters>

</nmwg:metadata>

<nmwg:data id="data_in" metadataIdRef="m_param_in"/>

<nmwg:metadata id="meta_out">

<netutil:subject id="subject_3">

<nmwgt:interface>

<nmwgt:hostName>rtr.chic.net.internet2.edu</nmwgt:hostName>

<nmwgt:ifName>ge-2/1/0.178</nmwgt:ifName>


<nmwgt:direction>out</nmwgt:direction>

</nmwgt:interface>

</netutil:subject>

<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>

</nmwg:metadata>

<nmwg:metadata id="m_param_out">

<select:subject id="subject1_4" metadataIdRef="meta_out"/>

<nmwg:eventType>http://ggf.org/ns/nmwg/ops/select/2.0</nmwg:eventType>

<select:parameters id="param_5">

<nmwg:parameter name="startTime">1264011835</nmwg:parameter>

<nmwg:parameter name="endTime">1264271035</nmwg:parameter>

<nmwg:parameter name="consolidationFunction">AVERAGE</nmwg:parameter>

<nmwg:parameter name="resolution">300</nmwg:parameter>

</select:parameters>

</nmwg:metadata>

<nmwg:data id="data_out" metadataIdRef="m_param_out"/>

</nmwg:message>

URL(RESTrequest):

http://servicehostname:port/servicename/topologyelements/{type‐of‐topology‐element}/data?parameterName=value&paramName=value1

Representation:

• NMWGXML,contenttypetext/xmlortobedefined

• text/uri‐list,returningURLsofthespecifictopologyelements,matchingthequery,asbelow

http://servicehostname:port/servicename/topologyelements/interface/id1/data?parameterName=value

http://servicehostname:port/servicename/topologyelements/interface/id2/data?parameterName=value

Operations:

• GETReturnqueryresultsinNMWGXML

• PUT‐none

• POST‐none

• DELETEDeletealldataforthetopologyelementsofthistype

Examples:

• Retrieveutilisationdataforallinterfaceswithspecifiedtimeintervalandresolution

http://servicehostname:port/servicename/topologyelements/interface/data?eventType=http://ggf.org/ns/nmwg/characteristic/utilization/2.0&startTime={unixtime}&endTime={unixTime}&re

solution={resolution}

SOAPandREST(text/xml)Response(SetupDataResponse)

<?xml version="1.0" encoding="UTF-8" ?>

<nmwg:message id="message1264013036_resp" messageIdRef="message1264013036" type="SetupDataResponse" xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">

<nmwg:metadata id="meta542_0">

<netutil:subject id="subj542" xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/">

<nmwgt:interface xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/">

<nmwgt:hostName>swiNE1.switch.ch</nmwgt:hostName>

<nmwgt:ifName>GigabitEthernet1/4</nmwgt:ifName>

<nmwgt:ifDescription>bidir ZX-SFP to NE2</nmwgt:ifDescription>

<nmwgt:ifAddress type="ipv4">130.59.36.117</nmwgt:ifAddress>

<nmwgt:direction>out</nmwgt:direction>

<nmwgt:authRealm>TestRealm</nmwgt:authRealm>

<nmwgt:capacity>1000000000</nmwgt:capacity>

</nmwgt:interface>

</netutil:subject>

<nmwg:eventType>

http://ggf.org/ns/nmwg/characteristic/utilization/2.0

</nmwg:eventType>

</nmwg:metadata>

<nmwg:metadata id="meta541_1">

<netutil:subject id="subj541"

xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/">

<nmwgt:interface xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/">

<nmwgt:hostName>swiNE1.switch.ch</nmwgt:hostName>

<nmwgt:ifName>GigabitEthernet1/4</nmwgt:ifName>

<nmwgt:ifDescription>bidir ZX-SFP to NE2</nmwgt:ifDescription>

<nmwgt:ifAddress type="ipv4">130.59.36.117</nmwgt:ifAddress>


<nmwgt:authRealm>TestRealm</nmwgt:authRealm>


</nmwgt:interface>

</netutil:subject>

<nmwg:eventType>

http://ggf.org/ns/nmwg/characteristic/utilization/2.0

</nmwg:eventType>

</nmwg:metadata>

<nmwg:data id="localhost.616fe810:1264cf81d1b:-38e6_0" metadataIdRef="meta542_0">

<netutil:datum timeType="unix" timeValue="1263852300" value="31074.162409547513" valueUnits="Bps" xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/" />



....



<nmwg:parameters id="localhost.616fe810:1264cf81d1b:-38d3" />

</nmwg:data>

</nmwg:message>

2.2.5 A single topology element

URL:

http://servicehostname:port/servicename/topologyelements/{type‐of‐topology‐element}/{id‐of‐the‐topology‐element}


Operations:

• GETRetrievemetadataofthetopologyelement

• PUTAddmetadataofthetopologyelementinput:NMWGTXML

• POSTReplacemetadataofthetopologyelementinput:NMWGTXML

• DELETEDeletetopologyelement

Examples:

• GEThttp://servicehostname:port/servicename/topologyelements/interface/1

<nmwgt:interface>

<nmwgt:hostname>myhostname</nmwgt:hostname>

<nmwgt:ifName>myifname</nmwgt:ifName>

<nmwgt:ifDescription>My Interface</nmwgt:ifDescription>


<nmwgt:ifIndex>eth0</nmwgt:ifIndex>



</nmwgt:interface>

GEThttp://servicehostname:port/servicename/topologyelements/link/XYZ

TODO

2.2.6 Monitoring data of a topology element

URL:

http://servicehostname:port/servicename/topologyelements/{type‐of‐topology‐element}/{id‐of‐

the‐topology‐element}/data

http://servicehostname:port/servicename/topologyelements/{type‐of‐topology‐element}/{id‐of‐the‐topology‐element}/data?parameterName=value

Representation:

• text/xml(e.g.nmwg:datumelements)

Operations:

• Alloperationsareonthetopologyelement(e.g.interface),determinedbytheURL

• GETRetrievesmonitoringdataofthetopologyelement(e.g.nmwg:datumelements)

• PUTAddsmonitoringdataofthetopologyelement

• POSTReplacemonitoringdataofthetopologyelement

• DELETEDeletemonitoringdataofthetopologyelement

Examples:

• GEThttp://servicehostname:port/servicename/topologyelements/interface/1/data?startTime12639

45600&endTime=1263946200&resolution=300

<nmwg:data>

<netutil:datum value="31074.162409547513" timeValue="1263945600" valueUnits="Bps" timeType="unix"/>



</nmwg:data>

• POST‐similartoStoreDataRequest

2.2.7 Metadata chaining

Theconceptofmetadatachainingdoesn'tseemtofitwiththeRESTviewofrepresentingeachtopologyelementasaresourcewithuniqueURL.Therearetwotypeofmetadatachaining‐mergingandfiltering.

• Example1

o SOAPexample

http://anonsvn.internet2.edu/svn/perfsonar/branches/new‐structure‐with‐base2/ps‐

mdm‐rrd‐ma/samples/requests/SetupDataRequest‐Utilization‐2.xml

Thisexamplespecifiestheinterfacesearchingcriteriainfirstmetadataandthendefinestimerange,resolutionandconsolidationfunctioninthesecondmetadata.Theresponsewillreturnmonitoringdataofthespecifiedinterfaceandtimerange,ifsuchexist.

o REST

RESTimplementationcouldbeobtainedbysimplysendingsubsequentHTTPGET

requestsfortherequireddata.

• Findtheinterface

curl -X GET "Content-Type:text/uri-list" http://servicehostname:port/servicename/topologyelements/interface/metadata?ifAddress=10.1.2.3&hostName=test-hostName&direction=in

TheresultisURLoftheinterface,ifexist,withstatuscode200andstatuscode400"NotFound",ifnosuchinterfaceexist.


• Retrievemonitoringdata

curl -X GET "Content-Type:text/xml;charset=UTF-8" GET http://servicehostname:port/servicename/topologyelements/interface/1/data?startTime=2007-08-10T10:40:00Z&endTime=2007-08-10T11:45:00Z&timeType=ISO&consolidationFunction=AVERAGE&resolution=60

Thiswillreturnnmwg:datumelements,ifsuchexist,otherwisestatuscode400

Notfoundshouldbereturned

• Example2

o SOAP

http://anonsvn.internet2.edu/svn/perfsonar/branches/GEANT2‐JAVA‐RRD‐MA‐STABLE/samples/requests/SetupDataRequest‐Utilization‐5.xml

o REST

SimilartoExample1,achievedbysequenceofHTTPGETrequests

2.3 Error codes HTTPstatuscodesshouldbedefinedforeachRESToperation

2.4 Echo message Therearetwokindofrequests:

• Echorequest:checksiftheserviceisalive.

• Selftestsrequest:checksiftheservicehasbeenconfiguredproperly.

EchorequestusingNMWG

Therequestis:

<nmwg:message type="EchoRequest"

id="id1"

xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">

<nmwg:metadata id="meta">

<nmwg:eventType>http://schemas.perfsonar.net/tools/admin/echo/2.0</nmwg:eventType>

</nmwg:metadata>

<nmwg:data id="data" metadataIdRef="meta"/>

</nmwg:message>

Andtheresponsesayingthattheserviceisreadyis:

<nmwg:message xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"

id="id1_resp"

messageIdRef="id1"

type="EchoResponse">

<nmwg:metadata id="resultCodeMetadata">

<nmwg:eventType>success.echo</nmwg:eventType>

</nmwg:metadata>

<nmwg:data id="resultDescriptionData_for_resultCodeMetadata"

metadataIdRef="resultCodeMetadata">

<nmwgr:datum xmlns:nmwgr="http://ggf.org/ns/nmwg/result/2.0/">

This is the echo response from the service.

</nmwgr:datum>

</nmwg:data>

</nmwg:message>

EchorequestinREST

Therequestis:

http://ps_rest_service/admin/echo/2.0

or

http://servicehostname:port/servicename/echo/2.0

Andtheresponsesayingthattheserviceisreadyis:

<nmwg:message xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"

id="id1_resp"

messageIdRef="id1"

type="EchoResponse">

<nmwg:metadata id="resultCodeMetadata">

<nmwg:eventType>success.echo</nmwg:eventType>

</nmwg:metadata>

<nmwg:data id="resultDescriptionData_for_resultCodeMetadata"

metadataIdRef="resultCodeMetadata">

<nmwgr:datum xmlns:nmwgr="http://ggf.org/ns/nmwg/result/2.0/">

This is the echo response from the service.

</nmwgr:datum>

</nmwg:data>

</nmwg:message>

orcouldbejustHTTP200Success.

2.5 Authentication model TheauthenticationoftheofficialperfSONARisbasedonWebServicesSecurity,astheyareservices

usingSOAP1.1.Furthermore,itusestheX.509digitalcertificateprofileandtheSAMLprofileinorderintoincludethesecuritytokensdefinedinitsarchitecture.

ThemainproblemwithRESTfulwebservicesisthatthereisnodefinedstandardforprotectingthem.However,thereisonedraft,HTTPAuthentication:TokenAccessAuthenticationwhichcanbeusedin

ordertoincludethesecuritytokensineveryrequest.

AlthoughthatdraftwasdefinedbyitsauthorforfindingoutabettersolutionforOAuth,it'squitegenericanditcanbeusedforotherkindoftokens.

2.5.1 Profile based on X.509 digital certificates

Whenthesecuritytokenisbasedondigitalcertificates,thehttprequestwillincludethenextattributesinthehttpauthenticationheader:

• class:containsthevaluex509,specifyingthatthetokenisaX.509digitalcertificate.

• method:containsthevaluersassa‐pkcs1‐v1.5‐sha‐256.

• nonce:containsarandomstringasthedraftspecifies.

• token:containsthedigitalcertificateinbase64codification.

• timestamp:containsthetimestampoftheuser'sclient.

• auth:containsahashusingtheprivatekeyoftheclient/user.

Thenextrequestisanexample:

GET aaaa HTTP / 1.1

Host: example.com

Authorization: Token token="h480djs93hd8...yZT4=",

class="x509",

method="rsassa-pkcs1-v1.5-sha-256",

nonce="dj83hs9s",

timestamp="137134190",

auth="djosJKDKJSD8743243/jdk33klY="

2.5.2 Profile based on SAML assertions

WhenthesecuritytokenisbasedonSAMLassertions,thehttprequestwillincludethenextattributesin

thehttpauthenticationheader:

• class:containsthevaluesamlv2.0,specifyingthatthetokenisanassertionoftheSAMLv2specification.

• method:containsthevaluenone.

• token:containstheSAMLassertioninbase64codification.

Thenextrequestisanexample:

GET aaaa HTTP / 1.1

Host: example.com

Authorization: Token token="h480djs93hd8...yZT4=",

class="samlv2.0",

method="none"

2.5.3 Request not valid

Incasetherequestdoesn'tapplyanyofbothpreviousprofiles,theservicemustreplysayingwhichthat

theclientisnotauthorizedandwhichprofilesmustapply.

Anexampleofarequest:

GET aaaa HTTP / 1.1

Host: example.com

Anexampleofaresponse:

HTTP / 1.1 401 Unauthorized

WWW-Authenticate: Token class="samlv2.0",

methods="none",

timestamp="137131190"

WWW-Authenticate: Token class="x509",

methods="rsassa-pkcs1-v1.5-sha-256",

timestamp="137131190"

2.5.4 New model (REST) vs Classic model (SOAP)

Therearen'tmaindifferencesbetweenbothmodelsasthey'reusingthesamesecuritytokensbut

describedindifferentways.The90%ofthesourcecoderelatedtoAuthenticationcanbere‐usedsoitwon'trequiredalotofefforttoimplementtheseprofiles.

2.6 Performance comparison SimpleSOAPandRESTserviceshavebeendevelopedspecificallyforthepurposeofperformancecomparisonbetweenSOAPandRESTimplementationsofPerfsonar.TheSOAPserviceisastripped‐downimplementation,usingsamecodebase,asproductionPerfsonarservicesandApacheAxis2SOAP

implementation.TheRESTservicesarebasedonRestletframework.

2.6.1 SOAP vs REST performance comparison

ResponsetimeoftestimplementationsofSOAPandRESTserviceswerecomparedwiththeuseofSmokePing,curlprobes,runningontwodifferentserversatBREN‐oneonthesameserver,asthetestservicesitself,(CentralBRENnode,Sofia,BG),andoneonaserverinadifferentcity(BRENPoPat

PlovdivUniversity,Plovdiv,BG),connectedvia1Gblink.SmokePingcurlprobesareconfiguredtosend10requestsforeverytargetevery5min.

Server:

• Intel(R)Xeon(TM)CPU2.00GHz

• Linux2.6.18‐6‐686

• LocationSofia

Client(smokepingcurlprobe):

• AMDAthlon(tm)ProcessorLE‐16402.6GHz

• Linuxversion2.6.26‐2‐amd64(Debian2.6.26‐19lenny2)

• LocationPlovdivUniversity

AllchartsinthisreportsarefromtheSmokePinginstallationinPlovidivUniversity.Thismeasurementsetupmimicstherealusecaseofconsumingwebservicesremotely.

2.6.1.1 Perfsonar ECHO message

• ECHOrequest:asabove

• ECHOresponse:asabove

• Responsemessagesize:~400b

SOAPEcho:

• SOAPimplementation:http://uran.acad.bg:8180/rest‐test/services/SimpleService

• Responsemessagegeneration:NMWGclasses,perfsonar‐base2

• TESTquery:

curl -X POST -H Content-Type:text/xml;charset=UTF-8 -d @FileWithEchoRequest http://uran.acad.bg:8180/rest-test/services/SimpleService

RESTEcho:

• RESTimplementation:http://uran.acad.bg:8180/rest‐test/rest/echo

• Responsemessagegeneration:NMWGclasses,perfsonar‐base2

• TESTquery:

curl -X GET http://uran.acad.bg:8180/rest-test/rest/echo

Responsetime:

2.6.1.2 Extended ECHO message

Inordertotestperformanceofserviceswhenhandlinglargemessages,andextendedECHOrequestwasintroduced(forthistestonly)whichaddsnmwg:metadata/nmwg:datapairstothe

ECHOresponse.Testsareperformedwithmessages,containing10,100,1000,10000and50000metadata/datapairs.

ECHOrequest

REST

http://uran.acad.bg:8180/rest‐test/rest/extendedecho/nmwg/NUMBER_OF_METADATA_DATA_PAIRS

SOAP

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

<soapenv:Header/>

<soapenv:Body>

<nmwg:message type="ExtendedEchoRequest" id="id1" xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">

<nmwg:metadata id="meta">

<nmwg:eventType>http://schemas.perfsonar.net/tools/admin/echo/2.0/NUMBER_OF_METADATA_DATA_PAIRS</nmwg:eventType>

</nmwg:metadata>

<nmwg:data id="data" metadataIdRef="meta"/>

</nmwg:message>

</soapenv:Body>

</soapenv:Envelope>

ECHOResponse(SOAPandREST)

<nmwg:message xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" type="EchoResponse" id="uri:ps-element-id:1263973869874:1280641648">

<nmwg:data metadataIdRef="meta0" id="data0"></nmwg:data>



</nmwg:metadata>

....

<nmwg:data metadataIdRef="meta9999" id="data9999"></nmwg:data>



</nmwg:metadata>

</nmwg:message>

Performance

SOAPExtEcho‐10vsRESTExtEcho‐10

• Messagesize(metadata/datapairs):10

• Messagesize(b):

• RESTservice:

curl -X http://uran.acad.bg:8180/rest-test/rest/extendedecho/nmwg/10

• SOAPservice:

curl -X POST -H Content-Type:text/xml;charset=UTF-8 -d @FileWithExtendedEchoRequest http://uran.acad.bg:8180/rest-test/services/SimpleService



• Messagesize(b):

• RESTservice:


• SOAPservice:




• Messagesize(b):

• RESTservice:


• SOAPservice:




• Messagesize(b):

• RESTservice:


• SOAPservice:




• Messagesize(b):

• RESTservice:


• SOAPservice:


2.6.1.3 Summary

PerformanceofSOAPservices,relatedtothesizeofresponsemessage

ExtendedechoresponsemessagesgeneratedbyNMWGJavaclasses

PerformanceofRESTservices,relatedtothesizeofresponsemessage

ExtendedechoresponsemessagesgeneratedbyNMWGJavaclasses

2.6.1.4 Conclusions

• Smallresponsemessages

Withthesizeofresponsemessageabout400b,SOAPandRESTimplementations'responsetimeispracticallythesame.

• Largeresponsemessages

Withthesizeofresponsemessagecloseto2Mb,bothimplementationsareconsiderablyslower,thaninthecaseofsmallmessages,butRESTimplementationwinbybeing3timesfaster.

2.6.2 Performance comparison of different REST implementations of extended ECHO services by message generation and message size

Withtheobservationofmessagesizerelatedtotheresponsetime,thefollowingtestsetuphasbeenestablished:

2.6.2.1 Performance of REST services, related to the size of response message

ExtendedechoresponsemessagesgeneratedbyNMWGJavaclasses,DOMandStaX.Eachgrophassubgroupsbyresponsemessagesizeinmetadata/datapairs.

NMWGclasses

NMWGjavaclasses[URL‐TODO]areusedinalljavabasedperfsonarservices.

NMWG‐10:

• RESTservice:http://uran.acad.bg:8180/rest‐test/rest/extendedecho/nmwg/10


• Messagesize(b):1942

NMWG‐100:




NMWG‐1000:




NMWG‐10000:




NMWG‐50000:




DOM(withoutNMWGclasses)

PerformanceofRESTservices,implementingextendedechoresponsebyDocumentObjectModel(DOM)

DOM‐10:

• RESTservice:http://uran.acad.bg:8180/rest‐test/rest/extendedecho/nonmwg/10



DOM‐100:




DOM‐1000:




DOM‐10000:




DOM‐50000:




StAX

PerformanceofRESTservices,implementingextendedechoresponsebyStreamingAPIforXML(StAX)

StAX‐10:

• RESTservice:http://uran.acad.bg:8180/rest‐test/rest/extendedecho/nodom/10



StAX‐100:




StAX‐1000:




StAX‐10000:




StAX‐50000:




Conclusions

• TestmeasurementsRESTserviceswithdifferentmessagesizeandusingdifferenttechnologiesforgeneratingXMLresponsehasbeenperformed.

• RESTperformanceisbetterthanSOAP

• SOAPperformancewithsmallmessagesizeisrelativelyclosetoRESTperformanceand

canbeconsideredsufficient

• ThetechnologyusedtogenerateXMLresponsehasahugeinfluenceontheresponsetime

o DOMperformanceisworst,probablybecausehandlingXMLdocumentsinmemorybecomesprohibitivewithlargemessages

o StAXperformanceisbest,becauseofitsstreamingnature.

o NMWGperformance(basedonStAXparser)isquitecloseandcanbe

consideredgood.

2.6.2.2 Performance of REST services for the same message size, using different Java libraries for message generation

PerformanceofRESTservices,generatingextendedechoresponsemessagesbyNMWGJavaclasses,DOMandStaX.Responsetimegroupedbyresponsemessagesize.

NMWGvsDOMvsStAX‐10

NMWG‐10

RESTservice:http://uran.acad.bg:8180/rest‐test/rest/extendedecho/nmwg/10

DOM‐10

RESTservice:http://uran.acad.bg:8180/rest‐test/rest/extendedecho/nonmwg/10

StAX‐10

RESTservice:http://uran.acad.bg:8180/rest‐test/rest/extendedecho/nodom/10


NMWG‐100


DOM‐100


StAX‐100



NMWG‐1000


DOM‐1000


StAX‐1000



NMWG‐10000


DOM‐10000


StAX‐10000



NMWG‐500000


DOM‐50000


StAX‐50000


2.6.2.3 Summary

Thetestimplementationmakeuseofrandomdata,ratherthanretrievingrealmetadataanddatafromRRDfileordatabases.Theresponsetimefiguresshouldberegardedastheminimumresponsetimefor

therelevantimplementations,sinceRRD/databaseinteractionswilladdadditionallatency.

ThesizeofXMLresponsesbecomesprohibitivelylargewiththeamountofdatarequested.

2.6.3 Performance comparison of SOAP and different REST implementations of SetupData response

SetupDataRequest/Responseprovidesmeanstoretrievedataforselectedperformancemetric,topology

elementandtimerange(e.g.utilizationdataforaninterfaceandselectedtimerange).

Testsaredoneforseveraltimeranges.Thetestservicesgenerateresponse,basedonstartTime,endTimeandresolutionandrandomutilizationdata.Themessagesidedepends(linearly)onthequeriedtimerange.

Messagesizevsresponsetimeforoneinterface,twodirections(in/out),onemetric,5minresolution

Size(b)Dataforthetimeinterval:

• 357768631year

• 88233523months

• 30400861month

• 6878261week

• 2958603days

• 9986424h

• 344988h

• 794290min

• 283915min

2.6.3.1 Performance of SOAP services, related to the query time range

SetupDataresponsemessagesgeneratedbyNMWGJavaclasses.

2.6.3.2 Performance of REST services, related to the query time range

ExtendedechoresponsemessagesgeneratedbyNMWGJavaclassesandStaX.Eachgrophassubgroupsbyrequestedtimerange.

SOAP‐NMWG

curl -X POST -H "Content-Type:text/xml;charset=UTF-8" -d @message http://host.net/MA/interface/

REST‐NMWG

NMWGjavaclassesareusedinalljavabasedperfsonarservices.

• 15min

http://uran.acad.bg:8180/rest‐test/rest/ma/interface/10.0.0.1/data?startTime=1263945600&endTime=1263946500&resolutio

n=300&mode=nmwg

• 90min

http://uran.acad.bg:8180/rest‐test/rest/ma/interface/10.0.0.1/data?startTime=1263945600&endTime=1263951000&resolution=300&mode=nmwg

• 8hours

http://uran.acad.bg:8180/rest‐

test/rest/ma/interface/10.0.0.1/data?startTime=1263945600&endTime=1263974400&resolution=300&mode=nmwg

• 24h


n=300&mode=nmwg

• 3Days


• 1week


• 1month


test/rest/ma/interface/10.0.0.1/data?startTime=1262304000&endTime=1264982400&resolution=300&mode=nmwg

• 3months


n=300&mode=nmwg

• 6months


2.6.3.3 REST-StAX

• 15min


test/rest/ma/interface/10.0.0.1/data?startTime=1263945600&endTime=1263946500&resolution=300

• 90min

http://uran.acad.bg:8180/rest‐test/rest/ma/interface/90min/data?startTime=1263945600&endTime=1263951000&resolution

=300

• 8hours

http://uran.acad.bg:8180/rest‐test/rest/ma/interface/8hours/data?startTime=1263945600&endTime=1263974400&resolution

=300

• 24h

http://uran.acad.bg:8180/rest‐test/rest/ma/interface/24hours/data?startTime=1263945600&endTime=1264032000&resolution=300

• 3Days


test/rest/ma/interface/3days/data?startTime=1262304000&endTime=1262563200&resolution=300

• 1week

http://uran.acad.bg:8180/rest‐test/rest/ma/interface/1week/data?startTime=1262304000&endTime=1262908800&resolution

=300

• 1month

http://uran.acad.bg:8180/rest‐test/rest/ma/interface/1month/data?startTime=1262304000&endTime=1264982400&resolution=300

• 3months


test/rest/ma/interface/3months/data?startTime=1262304000&endTime=1270080000&resolution=300

• 6months


test/rest/ma/interface/1year/data?startTime=1230768000&endTime=1246320000&resolution=300

2.6.3.4 Summary

2.6.3.5 Conclusions

Sameasinprevioussection.Clientsshouldavoidworkingwithlargemessages.Servicesmightbeimplementedtoreturnerrorswhenhugeamountofdataisrequested.

Serversshouldobeythesearchparameters,especially"resolution",whenrequestingmonitoringdata.

Thiswillallowclientstoimplementmoreefficientrequestsofthedata.

2.6.4 Performance of SOAP implementations

WehavenotdoneanyteststocompareexistingSOAPlibraries,andprovidehereexcerptsfromstudiesdoneelsewhere:

• ApacheAxis2,CXFandSunJAX‐WSRIincomparison

Published:20Oct2008

http://predic8.com/axis2‐cxf‐jax‐ws‐comparison.htm

Performance

DuetothemodernstreamingXMLparser,theperformanceofallthreeSOAPenginesisverywell.Thepingtimeforalocaleroundtripisabout2‐4milliseconds(messagesizeabout3KB,

DualCoreNotebook).ThereforethetimedelaybytheSOAPcommunicationisnegligibleinmanyprojects.

Thisisinagreementwithourinitialtests,donewithsmallEchomessages,locallyfromthe

machinerunningtheservices.However,therealusecaseinvolvelargermessagesizeandnetworklatencies.

• JavaWebservices

Metrovs.Axis2performance

Published:19Jan2010

http://www.ibm.com/developerworks/java/library/j‐jws11/

ComparesperformanceofMetroandAxis2withandwithoutWS‐Security,withsmallandlargeresponsemessages.

Responsetime1‐16seconds

MetrooffersperformanceequaltoAxis2forplain‐textmessageexchangesandmuchbetter

performancethanAxis2whenWS‐Securityisinvolved.

Responsetimewithin1‐16secondsisconsistentwithourtestsforperfsonarSOAPservicesperformance

• ColdfusionSOAPvsRESTbenchmark

http://www.lynchconsulting.com.au/blog/index.cfm/2008/3/13/CFMX‐‐SOAP‐vs‐REST‐

benchmarks

March2008

5foldperformanceincreaseSOAP‐>REST

• LatencyPerformanceofSOAPImplementations,IEEECLUSTERCOMPUTINGANDTHEGRID2002

ComparesSOAPvsRMIandCORBA,withsmallandlargemessages,sameandseparateclientandserver,

Published2002

http://www.caip.rutgers.edu/TASSL/Papers/p2p‐p2pws02‐soap.pdf

Mightbeoutdated,butinterestingtoseethetestsetupandnumbers;SOAPslower10‐100timesthanpredecessors.

2.7 Conclusions • TheresponsetimeofSOAPservicewasslightlyhigherthanRESTservicesonverysmallresponse

messagesandalmost10timeshigherthanRESTwiththelargestmessagesizetested.SOAPresponsetimeincreaseswithresponsemessagesize

• TheperformancecriticallydependsonthetechnologyusedforgeneratingXMLmessages.StreamingXML(StAX)isalwaysbetter,withNMWGperformanceclose.

• ThetestStAXimplementationdoesn'tstoreanythinginmemory,hencethegoodperformance.

Butitshouldberegardedasanestimateofthebestresponsetime,inrealimplementationsonecouldhardlydoanyprocessingwithouthavingobjectsinmemory.

• ItispossibletodefineRESTinterfacetoperfsonarSOAPservices.TheproposedRESTinterfacedoesn'tstrivetoestablishdirectmappingbetweenRESTandSOAPmessages,butratherfollows

RESTdesignguidestorepresentresourcesbyURLsanddefineoperationsonresources.ThisisincontrasttotheSOAPstyleofhavingasingleentrypointanddecidingonoperationsbyinspectingtheincomingXMLmessage.

• AtopologyelementisrepresentedbyRESTresourceandavailableviaURL.Metadataanddata

oftheresourcecanberequested,bysendingHTTPGETrequeststothisURLandspecifying

queryparameters.Thedefaultresourcerepresentationistext/xml,butmultipleformatscanbesupportedbyHTTPContent‐typeheader.Writeoperationstotheresourceareperformedvia

HTTPPUT,POSTorDELETErequests.

• RESTandSOAPinterfacestoperfSONARmonitoringdatamayexisttogetherandallowclientstousethepreferredinterface.Thisisthecurrentpracticewithmostpopular

servicesworldwide.AvailableinterfacescouldbespecifiedwhenregisteringtoaLookupService.

• TheAuthenticationandauthorizationmodelisquitesimilarinRESTandSOAP.Thesecurity

tokensandprofilesarethesameandthe90%ofthesourcecodecouldbere‐used(orreleasinganAAbaselibraryforbothimplementations).Forthefuture,OAuthshouldbeconsideredtouseinperfSONAR.OAuthWRAPhasbeenreleasedrecentlyanditfitsperfectlyforperfSONAR.

Documents

REST architecture for perfSONAR - Nina Jeliazkovavedina.users.sourceforge.net/publications/2010/RESTful_perfSONAR... · REST architecture for perfSONAR Nina Jeliazkova (BREN), Candido