A Framework for REST Service Registry

A Framework for REST Service Registry Tiemei Irene Zhang School of Management and Information Systems, Faculty of Business and Law, Victoria University, Footscray Park Campus, Australia and Janaka Indrajith Wijayanayake School of Management and Information Systems, Faculty of Business and Law, Victoria University, Footscray Park Campus, Australia ABSTRACT In today’s business environment, many computerised information systems are used within and external to businesses. It is costly and inefficient if these systems cannot directly communicate with each others when ever necessary. SOA (Service Oriented Architecture) provides a paradigm that enables businesses provide and consume services through communications internally and externally. REST services use HTTP protocol facilities, a simplified solution to services that emphasized on resources. To deal with diverse REST services, the major challenge is service registry & discovery, in which services are described, catalogued and can be discovered when they are needed. Our research aims to develop a framework to deal with diverse REST services with an emphasis on a service registry and discovery for various REST services. This paper presents a framework for REST service registry and discusses the information required for registering services. Examples are also provided to illustrate how the framework works. Keywords: Service Oriented Architecture, REST Services, Service Registry, Service Discovery and Web Services

1.

INTRODUCTION

In today’s business environment, there are many computerised information systems used within and external to businesses. It is costly and inefficient that these systems cannot always directly communicate with other systems. In today’s business world organisations and individuals require high quality services (computer systems that provide operations/functions that others need) over the Internet to be competitive. To meet customers’ needs, organisations have to be responsive to customers, business partners, employees and suppliers. This is especially true in today's budget-constrained and highly competitive business environment [3]. With the growth of services across different industrial sectors, the difficulty that organisations confront is how to determine appropriate services according

to the customers’ needs, budget and specific requirement as a service consumer. In previous research, Zhang and Jiang [13] has incorporated software agents to SOA (Service Oriented Architecture) for Web services queries, negotiation, selection, reaching agreement, invocation, monitoring and close-out. In this research, the typical example of online procurement was demonstrated. Web Services have a set of standards for service registry, description and communication, which require the use of standard format (e.g. XML) to exchange information between computer systems. They are difficult to build as complicated protocols (standards, rules, and languages) are adopted. Furthermore, web services are unable to deal with the heavy demands for various services. REST (Representational State Transfer) services have emerged to overcome these problems. It is an approach for getting information content from distributed hypermedia systems, such as the World Wide Web [3]. REST is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use [3]. At present, some commercial organizations such as Google and Amazon have provided REST services [7]. To deal with diverse REST services, the major challenge is Service registry & discovery in which services are described, catalogued and can be found when they are needed. A service registry integrates a repository to store service information provided by providers. By searching the repository many similar services can be found for given requirements. Consumers evaluate these services and choose the best one to meet the requirements. This research aims to develop a framework to deal with diverse REST services with an emphasis on a service registry and discovery for various REST services. These outcomes will be applied to E-business as it paves the path for a simplified, generic and internet-scaled infrastructure for distributed and diversified services.

2.

BACKGROUND AND RELATED WORK

Rest services Pautasso and et al. [10] identified the biggest strength of RESTful web services as the simplicity because REST architectural style leverage exiting well-know W3C standards. According to them, the necessary infrastructure has already become pervasive and available for all major programming languages and operating system/hardware platforms. According to Muehlen et. al. [8] the main advantage of the REST-based approach is the potential scalability of a REST-based system and the lightweight access to its operations due to the limited number of operations and the unified address schema. In such a situation where services can be provided in a simple lightweight manner with less infrastructure development and low investment, the possibility of adoption of the architectural style in large scale by organizations in the future is very high. Therefore, we can expect an increase rate of adoption of REST architectural style for service delivery by organizations all over the world. REST architectural style has been proposed by researchers not only for information centric services, but even for activity centric services such as services oriented business process execution, business process modelling and decentralized systems [6][12][5]. They have shown that how this particular architectural style can be used effectively in dynamic, flexible and scalable process executions where business process logic enforcement is required to reflect the behaviour of business processes and activity dependencies. Information is an asset for any business organization and providing access to crucial business information itself is a services. According to Hagemann and et al. [5] a convenient way of delivering this information is via the Internet as it gets rid of the problem of updating local databases. Therefore, providing information as a service over the Internet is gong to be a big business in the future. Interestingly, information services do not need very complex APIs as there is no much functionality in the service and hence, REST architectural style is the most suitable way of delivering the service. Muehlen et al [8] have highlighted that one of the advantage of REST is that client does not need to know the routing information beyond the URI. However, once services are provided the burning issue for the organizations/users will be how to find such services (URIs) provided by various organizations.

services are provided using service oriented architecture in REST style, it is very important to have a mechanism to discover available services without much difficulty. Without a discovery mechanism finding services from various providers will be harder, time consuming and inefficient. Hence have a registry for REST services are necessary as it will make the service discovery easier, less time consuming and efficient. Web services and its registry Web services are either software components or resources that are self-described and self-contained applications that can be located and invoked across the Web. Web services allow applications to interoperate in a loosely coupled environment enabling various consumers to obtain services from various providers. It allows discovering and connecting services dynamically to several applications according to user needs making the entire infrastructure a single application from the users’ point of view. For these services to be found and used they need to be registered or published as services in a web service registry. The services are owned and located in provider’s application environment as per the Web service configurations. Service providers publish their services in the service registries. Once a Web services is registered, applications can discover and invoke the registered services. The framework that is being used widely for registering and discovering Web services is the Universal Description, Discovery and Integration (UDDI). The core specifications of this framework are Web Service Description Language (WSDL) and Simple Object Access Protocol (SOAP). WSDL is the interface description language of a service application and SOAP is the messages format which could be exchanged using variety of transport protocols. UDDI is a mature stable registry which has been there for several years. However, it has failed to reach widespread acceptance in the industry [10]. Hence there are several proprietary WSDL-based registry and repository products in use. On the other hand Web 2.0 seems to neglect most of these standards and instead use light-weight models based on HTTP and REST architectural style [1]. However, according to literature there is no standard way of registering REST services and most common choice of developers is the “Do-it yourself build time look up”. To overcome the difficulties of having and managing “Do-it yourself type registries, we propose a framework to established a standardized registry for REST Web services.

3. According to Pastore [9] deployment and use of applications in a distributed environment pose a service discovery challenge as resources need to be identified in terms of their location and features in a transparent way for the user or the client application that is looking for them. Furthermore, Wang et al [11] emphasized that web services are meaningful only if potential users can find information sufficient enough to permit the execution. Therefore when

A FRAMEWORK FOR RESET SERVICES

Overview This research is based on SOA that has three major components: Service Providers, Service Consumers and Registry Repository where Service Providers register their services for discovery by Service Consumers. The Figure 1 depicts the overview for how these components work together. Service providers can register REST services as

same as they do with Web Services. Service consumers then are able to explore the appropriate services they need.

Figure 1: Service registry in SOA This paper focuses on REST service registry and repository that is able to facilitate REST services registering and discovery according to the characteristics of REST service, the following diagram depicts the framework of a REST service registry and repository. Figure 2, illustrate the core part of the REST Registry, which includes three layers the top layer provides mechanism for service providers to publish/register their services and service consumer to discover the registered services; the middle layer contains an engine that handles the interaction between top layer and the middle layer and manage the details of registered services. The major tasks performed by the engine are: 1) Directing and coordinating the information flow and tasks between layers; 2) Data management such as handling the request for data from DB repositories and File Systems; 3) Invocation of agreement logic and contact details of services and implementation of security in the registry systems. Proper data management service of the engine ensures the registry’s capability of dealing with wide range of database systems regardless of their location or data format. The strength of having powerful business logic processing capability ensures the efficient delivery of real-time services via Web. The bottom layer has different adaptors to access different repositories such as databases and file systems. Data repositories can be implemented using any DBMS such as Oracle or using file management mechanism such as Hadoop. To use the registry, service providers publish/register the information of their service profiles to Registry; service consumers access the registry, make a query to discover the URL of the service it wants. The service then can be invoked by using the discovered URL. The invoked service may work as a function of an application by forming as a part of business logic, which can be used by user via user interface.

Figure 2: A Framework of REST service registry and repository Information required for registry- Service profile The most general use of registry is to have a domainindependent global registry which is public and open to all service providers and consumers. It functions as a service registry and search engine to establish contact and facilities between service providers and services consumers. On the other hand industry specific or organizational specific registries can be used to register services related to a specific industry or an organization. Our proposed framework would facilitate the establishment of either public or private registries depending on the requirements. We focus on a lightweight approach in contrast to existing web service registry solutions where the application needs complex software installations. In our framework simple data model has been proposed which provide transparent and flexible extensions to the registry as need arises. The proposed data model is shown in Figure 3

Company

*

1

Business

Contact 1

1

1 * Price

1

1

Service

Category 1

The services registry content should not contain invalid entries and must be tightly coupled with the service provider. The main issue involves when changes are made to existing web services. Currently there is no mechanism to notify the service consumers the changes made to the existing services in other systems. In this framework we allow the provider to change the version of the service with information of indicating the new version and updated details in the service registry.

*

1 * Resource

Figure 3: Data structure model In view of facilitating the creation of a public registry, the higher level of information incorporated in the registry is information related to business organization. The table 1 shows the attributes related to business entities. Table 1: Business information Description System generated key for identification URL Domain name of the business Country Country of the head office Name Name of the company (Multiple names possible) Description Brief description of the business Contact Contact details the services provider wants disclose to public Service List of services provided by the business Category Service category (Multiple categories possible)

Attribute Key

Our registry framework is based on property-based lookup or categorization and classifications. The model allows the definition of properties for each resource that are stored in the registry at different levels. To improve the efficiency of discovery the categorization and classification of resources can be done using different classification criteria such as Standard Industrial Classification. Service consumers should be able to discover the service that is offered by a provider. The provider has the responsibility of providing more detailed information about the meaning of the services. To facilitate the incorporation of service related information second level has been introduced to our registry framework. The second level of the data structure of the registry contains service description information and related attributes are shown in Table 2.

Table 2 Service description information Attribute Description Key System generated key for identification Name Name of the service Description Brief description of the service Price Pricing details of the service Agreement Service agreement details Condition Any applicable conditions Resource List of resources Category Service category (Multiple categories possible) Tag Any related key word Version Version of the service Updates New version update details In general, service registry can be used in a combination of browse and drill down search patterns. When a list of services is found from the registry the search results can be inspected manually to find the required service or refined through more specific search in order to find more specific service with certain properties. To facilitate the drill down search patterns and refinement a third level has been introduced and Table 3 shows the related attribute of the level. This level contains the specific details of resources available under each service which can be used in search criteria. Once the information is listed it is possible to drill down to specific resource to get more details. Table 3: Resources description information Attribute Description Key System generated key for identification Description Resources description Category Service category (Multiple categories possible) URI Specific URI of the resource

4.

EXAMPLES

Overview of cases In this section we present a real world e-business problem in e-procurement as an illustrative example. E-procurement systems are used by organizations to purchase goods and services either internationally or locally. Three types of organization are involved in these processes:

1. 2. 3.

Consumer (organization) which tries to purchase items from the market e-market place which provide information of suppliers and other services of a particular industry the suppliers who fulfil the procurement request.

Depending on the situation either two parties or all three parties involved in the transaction process. Procurement process in business is not as simple as buying something from a shop or a supermarket by a customer. It involves several steps and various cost elements. Total cost of procuring good and services involves not only the cost of good and services. It comprises of various cost elements which vary depending on the location of the buyer & seller, exchange rate of currencies, administrative cost, customs duties & various taxes, and transportations. Therefore, the total cost can be varied from transaction to transaction even for same product with a same quantity. This requires client organisation to be able to determine its preference from a variety of suppliers by evaluation of the information obtained via REST services. For consumers to be able to find the specific details of the service, first of all, service providers need to register their details such as business profile, services specific data and resources specific data in a registry. Once the services are registered there can be various ways where consumers can find the services they need. Generally there can be two processes:. First case is consumer looking for specific product or services without accessing an e-market place. If the consumer is searching for previously unknown business, or service, new business or service can be found by searching on the category attribute which is based on different universally accepted product and services categorizations standards. Searching will also be possible using different key words as the registry have tagging facility. Upon finding the business organizations which provides the product or service, the consumer can analyse the business organization details and decide on one or few organizations for further considerations. Then for the selected organizations the drill down facility can be used to access product or service specific information such as pricing, service agreement and other details. If the service consumer is satisfied with the service and its conditions, it is just a matter of drill down one level to get the URL of the required recourse. The correct URI will provide all the required information to make the purchase decision. If the consumer is searching for already known business entity of or service, the required information can be accessed either by using the business name or the service name. That will deliver the required higher level information and thereafter finding the exact resource will be the same as earlier scenario. Second case is where consumer uses the e-market place to find the required goods or services. An e-market place is a web portal which provides links to service providers in the industry. In addition, it provides facilities such as comparison of services from different providers in terms of price, quality, conditions

and other attributes. So it is a one stop option and easy for the consumer to make comparison of different good & services based on various criteria and makes a decision. However, it is not an easy task to keep all the information up to date in an emarket place as suppliers make changes to their existing product and introduce new product and services time to time. Furthermore, there can be new business organizations coming in to the market and if there services are not listed in the emarket place, the usefulness of the portal will slowly diminish. Therefore, maintaining all up-to-date information in the emarket place is important for its long term survival. However, looking for new services and update from various suppliers manually is not an easy task. A registry of services will be helpful in this regards. E-market can employ an application to compare listings in their system with registry entries and makes required links to new or updated resources to keep the e-market place up to date. On the other hand registry itself can have a subscription facility where it sends notification to subscribers whenever a new business or service becomes available that conforms to a pre-defined set of criteria.

Application of the framework As a result of the interactions between service provider and registry, the information for registering REST services are obtained. The top layer provides the interface for the service provider to publish the profiles of the services in the registry. Once this interaction is established the engine interacts with top layer to direct and coordinate the registering process. Depending on the type of data format and the repository location the engine of the registry coordinate with relevant adapters to direct the information flows to the appropriate physical storage. In our above example the information that will be stored in the registry could be information of different business organizations which have e-commerce business model, the services they provide. The discovery process is usually initiated by consumers. Consumers interact with the registry via query interface to discover the services they need. As explain in the above example consumers will be able to discover the required services using the different criteria such as business organization data, business category and service category. Once the consumer execute the query using key words, the engine of the registry interacts with the query interface to get the details and pass them to adapters to be processed on different databases to obtain the service registry information which satisfy the criteria. After processing the query on different databases the result are forwarded to the engine. Upon receiving the queried information from different repositories, the engine consolidates result into a standard format and pass on to the top layer for display. Then the consumers can analyse the result and choose the appropriate service for invocation.

5.

CONCLUSION AND FUTURE RESEARCH

This research has developed a framework for REST service registry and repository which provide a mechanism for computer systems to communicate under SOA architecture. Using the proposed framework, REST services can be easily found and utilised to improve efficiency in business organisations. In this paper, we also demonstrated the information required for service registration and its structure that facilitates the service discovery. The framework has been also applied to examples of E-business procurement service. Immediate future work will be directed to evaluate and validate the proposed framework. Evaluation and validation of the framework will be done by developing a prototype of the proposed framework and testing it on an E-commerce environment. Our future research work also will focus on extending REST to manage quality of services and to develop a security framework for REST services. We firmly believe that by adopting REST when ever appropriate organizations can significantly improve performance of distributed systems and reduce application development cost. Therefore we intend to do an empirical investigation of performance and cost of SOA services in the future.

6.

REFERENCES

[1] R.T. Fielding, and R.N. Taylor, “Principled Design of the Modern Web Architecture”, ACM Transactions on Internet Technology, Vol2, No, 2, 2002, Page 114-150 [2] R.T. Fielding, “Architectural Styles and the Design of Network-based Software Architectures”, Doctoral dissertation, University of California, Irvine, 2000. [3] R. Gupta, “The promise and peril of web services: management will make the difference - Industry commentary”, Web Services Journal, 2003. [4] S. Hagemann, C. Letz, and G. Vossen, “Web Service Discovery – Reality Check 2.0”, Third International Conference on Next Generation Web Services Practices 2007. [5] R. Khare and R. N. Taylor “Extending the Representational State Transfer (REST) Architectural Style for Decentralized Systems”, 26th International Conference of Software Engineering 2006. [6] S. Kumaran “A RESTful Architecture for ServiceOriented Business Process Execution” IEEE International Conference on e-Business Engineering 2008. [7] R. Mooney, “Security for REST and Web 2.0”, 2007.xtech.org/public/asset/attachment/76, Last accessed on 1st July, 2008.

[8] M. Z. Muehlen, J.V. Nickerson and K. D. Swenson, “Developing web services choreography standards – the case of REST and SOAP”, Decision Support Systems 2008. [9] S. Pasto, “Exploring grid and e-business solutions in discovering web services software applications, Second International Conference on Systems 2007. [10] C. Pautasso, O. Zimmermann, and F. Leymann, “RESTful Web Services vs. “Big” Web Services: Making the Right Architectural Decision”, International World Wide Web Conference Committee, 2008. [11] H. Wang, J.Z. Huang, Y. Qu Y, and J. Xie, “ Web services: problem and future directions”, Journal of Web Semantics 2004. [12] X. Xu, L. Zhu, Y. Liu and M. Staples, “ResourceOriented Business Process Modeling for Ultra-LargeScale Systems”, Second International Workshop on Ultra-Large-Scale Software-Intensive Systems 2008. [13] T.I. Zhang, and H.C. Jiang, “A Framework of Incorporating Software Agents into SOA”, International Conference on Artificial Intelligence and Soft Computing 2005.