naucni rad
of 7
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  A Framework for the Service Provisioning of Community-Contributed Web APIs Daniel Vijayakumar School of Computer ScienceUniversity of GuelphGuelph, CanadaEmail: Qusay H. Mahmoud Dept. of Electrical, Computer and Software EngineeringUniversity of Ontario Institute of TechnologyOshawa, CanadaEmail:  Abstract —With the increased adoption of cloud com-puting in recent years due to its projected benefits as acomputing-as-a-utility paradigm, the industry has conse-quently seen a rise in software-as-a-service via Web ser-vices. Serving as a safe and valuable interface between theprovider’s data and outsider parties who have a potentialuse for the data, services allow developers to enhancethe value of their applications by integrating with them.Initially, standardization and research efforts were gearedlargely towards enterprise use-cases of Web services. Thisresulted in the global Web service vision becoming largelyprivatized. But in recent years, the number and diversityof Web APIs have increased tremendously and developershave additionally become more open and decentralized.This poses the interesting problem of aggregating the vastnumber of distributed codebases and exposing them asconsumable services for the benefit of all. The existingenterprise-oriented standards are unable to cater to sucha scenario. We respond to this by presenting an alternativeto the status quo of service registries. We specifically arguefor the feasibility of a RESTful framework for the designand implementation of an open service registry that servesa community of Web services that can be contributed toor consumed by any developer on the Web. I. I NTRODUCTION Cloud computing has seen increased adoption overthe last decade due to its projected benefits as acomputing-as-a-utility paradigm. The infrastructure of the Cloud is an attractive platform for distributed ar-chitectures and the industry has taken this opportunityto propel the development of various implementationsof the service-oriented architecture (SOA). One of themore prolific paradigms is that of Web services. A Webservice serves as an interface between some valuabledata of the entity providing the service and parties(either external or internal) who may have an interestin consuming this data. Emphasis is placed on abstract-ing away the interface definition from the underlyingimplementation in order to yield a loosly coupled andplatform/language-interoperable system [1].An important feature is the enabling of independentcomponents (including legacy/archaic code) within amodern system to be seamlessly integrated with the restof the architecture, conditional on adherence to the inter-face definitions [2]. Furthermore, there is no conceptualconstraint on the scope of publishing: if desired, acomponent can be made available to any interested partyon the Web. As a consequence of the above two features,application developers are able to enhance the value of their applications by integrating with such services tocreate features that would be impossible or infeasible tobe developed in-house. Additionally, services can serveas building blocks for the creation of more complexservices. These composite services are themselves, asthe name implies, services; this detail is abstracted awayfrom the service consumer.The number of extant Web services is no smallnumber. As of July 2013, there were at least 9500 Webservice interfaces (referred to as Web APIs) and 7100mashups (composite services formed from composingWeb APIs [3]) registered in one of the most popular APIdirectories called ProgrammableWeb 1 [4]. This is onlyone of other similar registries and the reported statisticsare only expected to grow as more web services andmashups come to existence. However, the literature isalmost unanimous in the view that the publishing anddiscovery of services still remains an open researchproblem (citation required).While standardization and research efforts have un-derstandably been geared largely towards internal/exter-nal enterprise integration, a ripe but largely unexploredarea (to the best of our knowledge) is the rapidlygrowing eco-system of decentralized and distributeddevelopers, such as the open source community. Aninteresting research problem is how can such vastlydistributed codebases be aggregated and exposed aseasily consumable Web services. For some perspective,the popular source code version-control service GitHub 2 is single-handedly a home to more than 4 millionheterogeneous codebases [5] as of 2012.We propose a framework for the implementation of a globally unified registry where 1) any developer can 1 2 CCECE 2014 1569880107 1 978-1-4799-3010-9/14/$31.00 ©2014 IEEECCECE 2014 Toronto, Canada  register self-sufficient pieces of code as services, 2) anydeveloper can discover these services, 3) any party isable to invoke these services and consume the output,4) any developer can create composite services usingexisting services, 5) and the entire registry (includingthe above four features) is exposed via a RESTfulinterface.Such a diverse and open conglomerate of servicesoffers as key benefits the openness of a collaborativecommunity and the simplicity and robustness of theunderlying REST architecture. This open, simplified andscalable access lowers the barrier of entry for developersand naturally facilitates increased innovation, the returnsof which benefit all participants of the community.Our contribution to the literature would be thedemonstration of the feasibility of such a framework.We aim to demonstrate this through the implementationof a proof-of-concept prototype and performing em-pirical evaluations thereof. The scope of our researchis currently limited to the performance dimension of feasibility, and this is what we emphasize in this paper.The remainder of this paper is organized as follows: Section 2  briefly discusses background information andrelevant literature;  Section 3  presents our framework; Section 4  describes our prototype implementation;  Sec-tion 5  outlines a few practical use cases of our system;and we conclude by identifying future work in  Section6  .II. R ELATED  W ORK This section discusses some of the key works in theliterature that are relevant to our research.  A. RESTful Architecture Coined by the famous Dr. Fielding (to whom allof us who enjoy a highly performant Web are eternallyindebted) in his Doctoral dissertation [6], the REpresen-tational State Transfer (REST) architectural style hasproven to be the cornerstone of the Web’s success atscale.A summary of the main principles that most of theliterature agrees with is given by [7]:1) The central entity of a RESTful system is a resource . Every resource also has a  uniqueidentifier/address , standardized as the Uni-form Resource Identifier (URI), within anamespace.2) All resources can be interacted with via astandard  uniform interface , through which thestate of a resource can be manipulated.3) Resources are not accessed directly; rather, allresources contain at least one  representation ,which represents the state of the resource at thetime of access. Multiple representations canalso be manifested through the use of multiplemedia types.4) Requests on resources and responses must beself-contained, i.e.  stateless .5) The flow of the system is primarily, if notonly, through navigation of   hyperlinks  foundin resource representations. Fielding referredto this as  Hypermedia As The Engine of Application State  (HATEOAS).The idea of applying the principles of REST towardsWeb services has received great interest throughout theliterature in recent years. It has brought about the riseof a new paradigm known as the Resource-OrientedArchitecture (ROA) where resources are consideredfirst-class citizens instead of services (SOA) [8].In response to the vast amount of studies performedon the status of Web services, like [9], but the lack of exploration into comparisons of interfaces, the authorsof [10] have performed a thorough investigation of thelandscape of public Web services and their APIs. As of July 2013, this is the only broad study performed onWeb APIs to the best of our knowledge. An importantobservation is that of the usage of RESTful APIs.Out of a representative sample of 222 services froma 2010 crawl of ProgrammableWeb, RESTful APIsformed only about 32% of the sample. But in a separate2012 study [11] of the same directory, the number of representative RESTful services doubled to 72% whilethe total number of services also increased from [10].This massive shift towards RESTful services from thestandardized WS-* stack offers insights towards APIpreferences among developers.  B. Service Registries Collaboration efforts of enterprises such as Ariba,IBM and Microsoft who were interested in B2B(Business-to-Business) transactions in the late twentiethcentury resulted in a standard known as the UniversalDescription Discovery and Integration (UDDI) [2]. Itserved the role of service discovery within the well-known WS-* stack. It was created in order to addressthe then popular idea of a Universal Business Registry(UBR). As [2] further notes, the initial goal was tosupport service directories all over the world such thatany party could freely publish service descriptions aswell as query such directories for interesting services.UDDI was much criticized even in its early days due tothe small population of services in such directories [12].But interestingly enough, [12] defended the criticism bypointing out that web services were not intended forpublic use, but within the restricted enterprise arena.This has unfortunately turned out to be quite the case,as recent literature seems to indicate [13], [14]. As thelatter citation observes, the UBR concept has seen moresuccess in the form of private company registries.The ProgrammableWeb is currently the most popularcentralized repository of listings of Web services, their 2  interfaces (API) and their descriptions. As mentionedbefore, it is a directory which lists APIs as well asmashups. It functions as a portal site where users canregister their APIs and mashups, manually search andretrieve API descriptions, and view analytics on APIsand mashups, such as popularity and usage patterns.The literature critiques its minimalistic keyword andcategory-based search functionality as well as the extramanual effort required of end-users to sift throughAPI descriptions in order to consume services [11],[15]–[17]. The ProgrammableWeb seems to functionsimilarly to the white/yellow/green pages style of UDDIregistries. C. Web Intents Knowing that many diverse remote services are usedon a daily basis, it is quite ideal that web applicationswould be able to seamlessly integrate with each other.As documented above, this has proven to be quite achallenge largely due to the difficulty of unifying/ag-gregating new services. In order to address this issue,a framework for seamless client-side service discoveryand inter-application communication known as WebIntents [18] was conceived. It is modelled after thesimilarly-named system in the Android platform [19].The system involves three parties: Client, UserAgent and Service Provider. The Client is a user that isin need of a particular service for its own workflow. Itregisters this need with the Intents server via the UserAgent. This registration is expressed in the form of anIntent, which is composed of an Action and a Type.In advance, Service Providers register with the Intentsserver and declare themselves capable of handling aspecific Action and Type. From these two parameters,the server creates matches and provides a list of ServiceProviders to the User Agent, which in turn presentsthis list to the Client. The Client chooses the desiredService Provider and the chosen Service Provider, thenperforms the requested action. Input and output betweenthe Client/Service Provider is optional but in most caseswill exist.Web Intents has unfortunately not enjoyed practicaluse and the w3 specification that was being activelydeveloped has been halted and published as just aninformative Working Group Note as of May 23rd 2013[20].III. P ROPOSED  F RAMEWORK Our framework serves as a response to the failure of the UBR concept described in section 2. In particular,we argue that an open collaborative registry of servicesfounded upon the architectural principles of REST isa strong candidate for the fulfillment of the UBR con-cept, which we would informally modify as Universal Service  Registry (USR) in order to emphasize that thescope goes beyond the enterprise world.  A. Web Service The term  Web Service  has been defined at varyinglevels of specificity throughout its time. Arguably themost specific [2] definition is provided by Webopedia[21] and is associated very tightly with the traditionalWS-* stack. A more generic one is provided as anapplication whose operations can be accessed by otherapplications over the Web [2]. We present our own defi-nition of a service within the context of our framework:  A  Web service  (referred to in short as a  service )is defined as a modular piece of code which, like a function, accepts certain input arguments, performs itstask based on the inputs, and accordingly produces theoutput, if any. A service may call upon other servicesto aid in performing its task. It can be seen that we have applied certain con-straints to our definition of a service. Firstly, we detractfrom the notion of a service as an entire self-containedapplication consisting of various operations that forma cohesive whole. Instead, we enforce a service tofocus on a single operation that it performs very well.Such modularity encourages reuse and is a well-receivedsoftware engineering principle. One may observe thatfocus on operations instead of applications hearkensback to the low-level RPC-based middleware protocols.However, RPC mechanisms are founded on distributedshared state. This leads us to our next constraint, whichis the RESTful denunciation of maintaining applicationstate among queries. This is inspired by the functionalprogramming paradigm of avoiding state, mutable dataand side-effects. The latter is a little more nuanced andwill be touched on in sub-section D. Finally, the conceptof services invoking other services will be explained insub-section E.  B. Service as a Resource In the Resource-Oriented Architecture paradigm, thedata that needs to be exposed via services is modelledas the resource within the RESTful architecture. Butwe face the interesting conundrum of the services them-selves being the data that is being exposed to the public.Thus, we refer to the Web services in our framework asthe resources. This model is key to enjoying the benefitsof REST. We discuss these specifics in the sub-sectionsthat follow. C. Addressing Strategy Every resource must be uniquely addressable viaa URI. In our framework, every service must beaccessible at a unique URI  within its respectivenamespace . This means that each service must havea unique identifier within its namespace. For example,a service which computes the sum of a sequence of numbers may be identified as  addnums . Assuming anamespace of  and the HTTP URI 3  scheme, the complete URI (to be precise, URL) may be .A resource can only be interacted with via itsrepresentations, which must also be uniquely identified(commonly referred to as endpoints). In the contextof our framework, the representations of a service canbe seen as the various output values that are returnedbased on the provided input parameters 3 . An importantobservation on the definition of a function from a formalperspective is that each element of the domain canonly map to one other element of the co-domain. Al-though the programming language concept of a functiongenerally varies from the mathematical definition, thispreliminary premise holds. Thus, we are guaranteedunique addresses for each tuple of input parametersfor any given service. Continuing the example of theaddition service, let us assume that we have two cases:1) compute the sum of 2 and 3, and 2) compute the sumof 5, 6 and 7. The URLs 4 would be: 1)  /services/addnums?num1=2&num2=3 2)  /services/addnums?num1=5&num2=6&num3=7  D. Cacheing One of the best explanations for the inherent scal-ability of the RESTful architecture is its consequentcacheing mechanism [7]. This has been applied suc-cessfully to the Web via the underlying HTTP protocol,especially the Conditional GET feature [23] coupledwith the entity tag (ETag) 5 . Cacheing is an extremelyimportant feature of our framework as it drasticallyreduces the number of service invocations necessary.According to the principle of   referentialtransparency  [24], an expression will always eval-uate to the same value as long as it does  not haveany side-effects . Such a function is commonly referredto as a  pure  function, whereas the converse case isknown as an  impure  function. In other words, given aspecific tuple of input parameters, a pure function willalways return its corresponding value. Applying this toour framework, services that can be classified as purefunctions can be cached via the HTTP Conditional GETmechanism while impure function, such as services thatwrite to remote databases, are never cached. Continuingthe previous example, the representation of   addnums that computes thw sum of 2 and 3 will always be5. Thus, the URL  /services/addnums?num1=2&num2=3 can be cached. 3 We found a very similar addressing strategy in [22], albeit it isemployed in the paper for a different purpose. Although we hadcreated our strategy long before running into this paper, it servesas a fine example of scientific replication. 4 We have not included the namespace and the HTTP URI schemeonly for spatial concerns. 5 \ #sec14.19 Since a fairly large number of services tend tobe pure, we naturally notice significant performanceimprovements and better scalability.  E. Registration and Storage An important feature of our framework is that ser-vice code will be stored directly in the registry asopposed to a reference to an external URL. This enablesthe enforcing of service standards and consequentlyenhances trust levels. F. Search and Discovery A key feature of REST is the HATEOAS principle.Navigation in the standard document Web is driven bythis mechanism. To elaborate, whenever the represen-tation of a resource is received, it more often than notcontains links to other resources. Upon selecting a link,the representation for the selected resource is retrieved,which in turm may contain links to other resources.This gradual transitioning between application states asopposed to providing access to all application statesat any given time is a consequence of the statelessconstraint of REST and is also another crucial factor(apart from cacheing) for the scalability of the Web.We apply a similar perspective of HATEOAS to ourframework to facilitate the gradual discovery of ser-vices. Whenever the description of a service is queried,it may contain links or advertisements to other servicesin the registry. For example, the description of thesummation service used in the previous sub-sectionsmay contain links to related services such as servicesfor performing other arithmetic operations on numbers. G. Service Composition The creation of composite services is supported inour framework via two constructs: 1) the Module systemand 2) Service-to-Service Consumption (S2SC) 1) Modules :  We have already provided the def-inition of a service in sub-section A. We introduce aslightly different type of a service known as a Module.It is a service that cannot be consumed (invoked) butserves as a helper or utility service that other services,including other Modules, can build on. As such, theonly representations of Modules are their descriptionsand their raw code. This intentionally models the designof local software libraries in order to encourage modulardevelopment of services. 2) S2SC :  Service-to-Service Consumption is theapplication of the traditional concept of service compo-sition to our constrained definition of Web services. Itis a feature that allows services to function as clients toeach other and perform invocations between each other.This also encourages modular design. For example, aservice that implements the binary search algorithm mayinvoke another service that performs sorting right before 4

Space Jam2

Jul 23, 2017


Jul 23, 2017
Similar documents
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks