Multilayer resource-oriented architecture supporting restful and non-restful resources.

Toader, Cezar

1. INTRODUCTION

World Wide Web has known a constant evolution, since its appearance, but many specialists consider that new changes are expected. The potential of Web to support distributed programming is the subject that keeps awake the specialists.

The development of complex architectures based on services (similarly with DOM and CORBA) determines a new evolution comparing to the initial Web simplicity (Erl, 2007).

There are some specialists claiming that there is a danger that complex architectures based on Web services could modify or ignore the features that brought success to the Web since the beginning. In the meantime, the concepts of Resource Oriented Architectures (ROA) gradually evolved and comparisons between these architectures and those based on services can be made (Richardson & Ruby, 2007).

Resource Oriented Architectures are developed based on the following concepts: resources, identification of resources, their representation, and links between resources. The URI technology is fundamental for the Web because allows the interconnection of Web resources. The principles of URI technology are described by Berners-Lee (Berners-Lee, 1996).

2. ADDRESSABILITY OF WEB RESOURCES

ROA follows several principles, described below:

* Addressability. A Web application based on ROA exposes an URI for every resource it serves.

* Statelessness. Every HTTP request is completely isolated from the other requests.

* Uniform interfaces. The access to any Web resource can be made using standardized HTTP methods: GET, PUT, POST, DELETE, HEAD, and OPTIONS.

Two important characteristics must be emphasized here: the way a resource is addressed, and the lack of state information between HTTP requests. The Web was developed by creating new levels of abstracting, but its initial simplicity was necessary at that moment. The subsequent development of the Web and development of Web services required a special attention given to scalability and adaptability.

R. Fielding promoted in his doctoral thesis a set of principles defining a programming style for Web-based architectures, named REST (Representational State Transfer). The Web application architectures following those principles get the attribute RESTful (Fielding, 2000).

3. MULTILAYER ARCHITECTURES

Consider now a complex Web application having the layered architecture shown in Fig.1.

Modern Web application could have modularized user interfaces. Different areas in application user interface are, basically, the presentation layer of specialized task-oriented applications running behind the scene. These applications are in fact modules of a complex application. These task-oriented modules are on the highest layer of a multilayered application.

On the highest level, these specialized Web modules are waiting for client requests. In order to build the responses, these applications need to access different kind of resources: static or dynamic HTML, static XML, Web services based on XML, etc.

According to their role in a complex application, we can define several layers: Task Layer, Entity Layer, and Utility Layer, as we can see in Fig.1.

The Task Layer is the highest level of this architecture. It contains several application modules which can be called by external pieces of software, for example by a Web browser.

The Web application modules situated on the higher level are oriented to specific tasks, by their design. Their potential for reusing for other tasks is relatively low. According to client requests, the applications on this layer will access various resources situated on Entity Layer.

The Entity Level is subordinated to the application nodules situated on Task Layer. This level contains various pieces of software specifically designed for the application, which are considered Web resources for the higher level.

A Web resource supply data in HTML or XML format. The resources on the Entity Level can deal with RPC-style requests.

This is the usual case for existing applications in organizations that use this type of applications for several years, based on various technologies. A Web resource situated on Entity Layer often has to obtain data from Utility Layer.

The Utility Layer contains Web services ready to offer data to the upper layer. The data format used here is based on XML.

Often, the old resources are RPC-style. The modules on the higher level must be able to process such requests.

[FIGURE 1 OMITTED]

4. RESTFUL MULTILAYER ARCHITECTURE

An important issue must be solved: how to modify the application architecture in order to permit the highest level applications to use RESTful URIs and resources at the lowest level to be called using both REST-style and RPC-style URIs?

The solution presented here consists in creation of a specific method to transform the RPC-style URIs in REST-style URIs, with respect of existing resource hierarchy, and without redesigning the old modules and resources.

The proposed solution consists in inserting a new adapting layer between Task Layer and Entity Layer. Hence a new architecture is created, and the highest level applications can use only REST-style URIs to access all resources.

The proposed name is RESTful Multilayer Architecture. The goal of this architecture is to permit the clients to use the REST-style URIs when accessing both, the new REST-style resources, and the existing old RPC-style resources, without the need to redesign these resources, as we can see in Fig.2.

This adaptation of RESTful requests sent by client applications and arrived on Task Layer, to the real resource identifiers on Entity Layer is made by Resource Dispatcher.

Important actions take place within Resource Dispatcher:

* a REST-style request is received;

* the received URI is parsed;

* a new URI is build, according to the application hierarchy;

* the caller is redirected using the new URI.

After these steps, the client application reaches the needed resource and "hunks" that the received HTTP message is the natural response according to the earlier request.

At Resource Dispatcher level, a URI mapping technique is implemented, between Task Layer and Entity Layer. This mapping must be modifiable afterwards. Within ASP.NET application, this mapping leads to URL rewriting and there are several techniques for URL rewriting (Evjen et.al., 2008).

[FIGURE 2 OMITTED]

5. IMPLEMENTATION ON ASP.NET

Our implementation of RESTful Multilayer Architecture in ASP.NET applications uses the object called Context. The proposed solution is based on the method RewritePath() of the Context object. The application is allowed to dynamically modify the incoming URL and continue the execution with a new URL, build on URI Adapting Layer.

In this paper, we are focused on HTTP methods used by the client applications, on analyzing client requests and taking the routing decisions within Resource Dispatcher.

Increased attention will be given to the use of HTTP methods (PUT, GET, POST, DELETE) to trigger CRUD operations (CREATE, READ, UPDATE, DELETE) over a specific resource. As we can see in Fig.2, the request sent by the client application arrived at the Resource Dispatcher, specifically at the Incoming URI Analyzer sub-layer.

Here, the first step is to identify the HTTP method used in the request. In ASP.NET this can be done by getting the value from Request.RequestType. This value can be either GET, POST, PUT, or DELETE. The path to the specified resource is important information extracted from the request in the Incoming URI Analyzer sub-layer. This is done by using Request.AbsoluteUri property or Request.AbsolutePath property (depending on the relevance of server name).

In the second step, according to the value of RequestType, the next sub-layer called New URI Builder will prepare the redirection to specific Web pages.

The third step is to rewrite the path to resource using the newly created URI and the Context.RewritePath() method. After all these steps, the client will get to necessary resources.

6. CONCLUSIONS

We propose a modern way to design and organize the algorithmic resources of Web applications in order to implement the REST architectural principles, which further leads to a better structuring of resources and to an increased degree of uniformity in resources addressability.

In this paper, a RESTful Multilayer Architecture is proposed, in order to implement the principle of uniform access to resources, regardless the initial style used for the existing resources at the design time, either RPC-style, or REST-style.

A new virtual and flexible hierarchy of all distributed application resources became possible, regardless of the existence of old resources inherited from company network.

The separation between developing application modules for Task Layer and developing resources and utilities for lower level becomes possible. Thus, new applications with backward compatibility with existing resources can be developed.

This solution doesn't provide a centralized resources registration system. In the future research plan we intent to develop an automatic resource registration system, in order to make this architecture more adaptive to resource changes, and open to other distributed systems.

7. REFERENCES

Berners-Lee, T. (1996). Universal Resource Identifiers Axioms of Web Architecture, World Wide Web Consortium, Available from: http://www.w3.org/DesignIssues/Axioms, Accessed on: 2009-05-04

Erl, T. (2005). Service-Oriented Architecture: Concepts, Technology, and Design, Prentice Hall PTR, ISBN 978-0-131-85858-9, New York, Montreal, London, Munich, Paris

Erl, T. (2007). SOA. Principles of Service Design, Prentice Hall, ISBN 978-0-132-34482-1, London, Munich, Paris

Evjen, B., Hanselman, S. & Rader, D. (2008). Professional ASP.NET 3.5: In C# and VB, Wiley Publishing USA, ISBN 978-0-470-18757-9, Indianapolis

Fielding, R.T. (2000). Architectural Styles and the Design of Network-based Software Architectures, PhD Dissertation, University of California USA, ISBN 0-599-87118-0, Irvine

Richardson, L. & Ruby, S. (2007). RESTFul Web Services, O'Reilly, ISBN 978-0-596-52956-0, Cambridge, Koln