Model-based Generic Website Tooling

Transcription

1 Integrating Security and RESTful Services into Model-based Generic Website Tooling A dissertation submitted to The University of Manchester for the degree of MSc in Software Engineering in the Faculty of Engineering and Physical Sciences 2010 Qinan Lai School of Computer Science

2 LIST OF CONTENTS LIST OF CONTENTS...1 LIST OF FIGURES...3 LIST OF TABLES...5 ABSTRACT...6 DECLARATION...7 COPYRIGHT STATEMENT...7 ACKNOWLEDGMENT Introduction Overview Structure of the dissertation Background Data Intensive Websites Spring Framework Hibernate Java Server Faces Spring Security Model Driven Software Development Meta-model Eclipse Modeling Project Model-driven work flow Models and model driven workflow in WebGen Website PIM Model driven workflow RESTful web service REST and SOAP Jersey Project Summary Model and Website Design Server side of RESTful service Website model and JSF model GenJSF model Client side of RESTful service Security Model Security settings Global security model Presentation layer Altered models Design of Website Summary Implementation of code generation Server side RESTful service generation...54 By Qinan Lai 1

3 4.1.1 Main class Change of web.xml Generating a RESTful webpage client Client architecture Client content units Securing the generated website The spring security configuration file Development of Content Units Summary Testing and Results RESTful Service test Integrating test Testing Model Test results Summary Conclusion Achievements Limitations and Further development References...83 Appendix A Website PIM Emfatic Implementation...86 Appendix B ORM Model Emfatic Implementation...92 Appendix C JSF model Emfatic Implementation...94 Appendix D GenORM model Emfatic implementation...99 Appendix E GenJSF model Emfatic Implementation The final word count: Body of the dissertation Complete dissertation By Qinan Lai 2

4 LIST OF FIGURES Figure 1 Model editor Figure 2 Webpage screenshot [9]...12 Figure 3 three-tier architecture...14 Figure 4 Inversion of control...16 Figure 5 Hibernate architecture [18]...17 Figure 6 JSF example...19 Figure 7 Workflow of presentation layer...21 Figure 8 A simplified subset of the Ecore Meta-Model...23 Figure 9 Example Model-to-Model Transformations [30]...26 Figure 10 Example ATL Model-to-Model Transformation [31]...27 Figure 11 an Example JET Model-to-Text Transformation...28 Figure 12 Hierarchical structure of persistence model [9]...30 Figure 13 Hierarchical structure of presentation model [9]...31 Figure 14 Model transformation workflow...34 Figure 15 RESTful service server side PIM...39 Figure 16 RESTful server side service PSM...41 Figure 17 Security PIM...45 Figure 18 Security PSM...46 Figure 19 Authentication Provider Model...47 Figure 20 New content unit models...48 Figure 21 New Presentation PIM...49 Figure 22 New Presentation PSM...50 Figure 23 Spring security with website...51 Figure 24 Default login page...51 Figure 25 Login page design...52 Figure 26 Logout unit...52 Figure 27 RESTClient...58 Figure 28 jquery JET template file...60 Figure 29 RESTful client: DataIndexUnit...60 Figure 30 DataIndexUnit with modify and delete action...61 Figure 31 RESTful client: UpdateUnit...61 Figure 32 RESTful client: CreateUnit...62 Figure 33 Basic authentication for RESTful client...62 Figure 34 Login page with minimised features Figure 35 Login page with all features...66 Figure 36 Open-ID login...66 Figure 37 Logout unit (not logged-in)...67 Figure 38 Logout unit (login user)...67 Figure 39 Profile page Figure 40 Profile page Figure 41 Register unit...69 By Qinan Lai 3

5 Figure 42 Test case: GUI editor...73 Figure 43 Test case: website model editor...74 Figure 44 Test case: access property...74 Figure 45 Test case: GenJSM PSM editor...76 Figure 46 Test case: GloalSecuritySetting...77 Figure 47 Test case: generated workspace...77 Figure 48 Test case: index.xhtml...78 Figure 49 Test case: createproblem.xhtml...78 Figure 50 Test case: 403 error...79 Figure 51 Test case: manager.xhtml...79 Figure 52 Test case: createlocate.xhtml...79 Figure 53 Test case: delete a problem...80 Figure 54 Client page: index.html...80 By Qinan Lai 4

6 LIST OF TABLES Table 1 RESTful requests and HTTP requests (Modified from Fielding [14] s work)...36 Table 2 Default generated requests...42 Table 3 Access Options...45 Table 4 Operations in RestResource class...55 Table 5 Test cases for RESTful service...71 Table 6 Test case: security settings...75 By Qinan Lai 5

7 ABSTRACT WebGen is website generation software using a model-driven software development approach. It can generate a robust persistence of a website and a JSF presentation for creating, updating and deleting functionalities. However, the model of WebGen has limited ability to express the concept of a website. This project proposes a set of models to present RESTful service and security settings for a website, then integrating the model to the original model. The code generation part is also re-evaluated and modifications and new templates are developed to enable the generation of a website with RESTful service and a role-based authentication system. The development work is completed and models and code generations are tested. By Qinan Lai 6

8 DECLARATION That no portion of the work referred to in the dissertation has been submitted in support of an application for another degree or qualification of this or any other university or other institute of learn in. COPYRIGHT STATEMENT i. Copyright in text of this dissertation rests with the author. Copies (by any process) either in full, or of extracts, may be made only in accordance with instructions given by the author. Details may be obtained from the appropriate Graduate Office. This page must form part of any such copies made. Further copies (by any process) of copies made in accordance with such instructions may not be made without the permission (in writing) of the author. ii. The ownership of any intellectual property rights which may be described in this dissertation is vested in the University of Manchester, subject to any prior agreement to the contrary, and may not be made available for use by third parties without the written permission of the University, which will prescribe the terms and conditions of any such agreement. iii. Further information on the conditions under which disclosures and exploitation may take place is available from the Head of the School of Computer Science. By Qinan Lai 7

9 ACKNOWLEDGMENT I would like to show my great gratitude to my project supervisor Dr. Andy Carpenter for his guidance and feedback on the project. I also want to thank my parents for making the memorable life in Manchester possible. By Qinan Lai 8

10 1 Introduction This chapter briefly introduces the problems faced when hand constructing a website, and demonstrates different approaches for solving these problems. It also introduces each chapter. 1.1 Overview The rapid development of communication technologies has almost made ubiquitous internet access possible. This has resulted in an explosion of websites, as individuals and businesses seek to make information about themselves available. A recent report [1] estimated that there are currently more than 206 million websites in the world, which equates to a doubling of the number of sites since However, in comparison to the rapid growth of websites, the method of developing websites remains mostly unchanged. There are three different kinds or structures of website. One is the static website. It is used for the display of static documents; each of the users will see the same content. A purely static website is not widely used now due to its limited ability. Dynamic websites are opposite to static websites. It can respond to different messages due to different requests. The dynamic content is generated by the program running in the server, such as PHP or JavaServlet. A dynamic website also involves static contents. Tools exist for supporting the design of static content, such as Dreamweaver[]; it provides a What You See Is What You Get(WYSIWYG) software environment for developing static contents. The last kind of website is a data intensive website, which this paper focuses on. A data intensive website involves retrieving data from a backing database, so it needs to be more robust. Such a web application is usually used with complex data persistence and business logic. Due to its complexity, a data intensive website is time-consuming and needs a high level of skill from the developer to build it. By Qinan Lai 9

11 Technologies provide alternative solutions for the rapid development of web applications. Often these technologies refer to web application frameworks. A web application framework supports the developer in creating a web application without too much repeated work. Among web application frameworks, Ruby on Rails[2], or RoR for short, is extremely effective. Ruby on Rails is a web application framework for Ruby language [3]. It provides standard templates for developing a website that follows the Model-View-Controller (MVC) [4] pattern. RoR relies on the pattern of names to establish relationship between different parts of the website. That means the developer does not need to do much configuration work, which is considered as the key point of RoR - favouring convention over configuration [5]. Consequently, RoR gains its popularity by its philosophy of fast development and less configuration. The Zend [6] framework is another widely used web application framework for PHP. Different from RoR, it is a use-at-will framework. There is no restriction of development regulation which all developers must follow. It provides similar components as RoR, such as MVC implementation and database abstraction [7]. The developers can apply those components based on their needs. Web application frameworks simplify the activity of development. However, coding is still a requisite activity. Repeated work decreases when a web application framework is applied, but is not eradicated altogether. Another possible way of simplifying website development is by using an approach where a model of the required website functionality is combined with automatic code generation, which encapsulates development practices and transforms the model into implementation code. Usually, this approach is referred to Model-Driven Software Development (MDSD)[8]; further details are given in Section 2.2. By using this approach, website designers can focus on the content and data of their website rather than the technology used to build it. Although automatic code generation relieves By Qinan Lai 10

12 developers from doing repetitive work, it does have a reputation for limiting a developer s ability to get exactly what they want; i.e. of not being controllable. WebGen [9] is a tool that enables the generation of a website from models. This tool is built by using both modelling and website developing technologies. WebGen is based on the Eclipse Modeling Framework (EMF) [10], which is usually considered as the standard environment for modelling and code generation. It can generate a data intensive website by applying the MVC (Model-View-Controller) pattern. By using its graphical model editor, the users can easily model the back-end and front-end of a website. The website model can by easily designed by a model editor (see Figure 1). After the construction of website models, the persistence data, typically database and entity classes, are generated, as well as the dynamic web pages. The generated pages can perform all the create, update and delete (CRUD) functionality of the data, with multiple presentation ways to achieve it. Figure 2 shows a screenshot of a generated webpage. The generated website can be deployed to a web server with modifying minimal places (such as providing a relevant username and password for the database server). Further details will be provided in section 2.4. Figure 1 Model editor By Qinan Lai 11

13 Figure 2 Webpage screenshot [9] WebGen proposed a set of models for presenting generic data intensive websites. These models place particular emphasis on how to present data entities and page contents; in other words, other features, which might be desirable, are not supported. In particular, a security model is needed to present security settings, such as authorisation and authentication - necessary for a modern website, but lacking in WebGen. Another weakness of the WebGen model is that the result for users to consume is only web pages. Nowadays, as the concept of web services gain in popularity, content other than web pages is required. An AJAX[11]client might prefer JSON, whereas another web client may prefer to use XML. A lot of famous websites, including Google and Yahoo[12], provides both web pages and web service APIs. A web service is a system of client-server architecture; the client performs remote calls, translating data to the server via HTTP. The two possible architectures for web services are Simple Object Access Protocol(SOAP)[13], which is usually considered as a widely used and complex solution, and Representational State Transfer (REST) [14], which is considered as a lightweight solution. Due to limited space, this project focuses on the RESTful web service. Detailed discussion of the web service is presented in section 2.4. The persistence data model of WebGen needs some modification to work as a data model for the RESTful web service. The presentation model lacks required features and a new model is proposed. By Qinan Lai 12

14 This project aims to make the model and code generation of WebGen more useable, by proposing models for website security and web service (RESTful) and integrating them with WebGen, thus enabling the code generation of a secured website and a RESTful web service. 1.2 Structure of the dissertation Chapter 2 introduces WebGen and the relevant knowledge needed to understand this project, including the RESTful web service and code generation. The background includes: a knowledge-required understanding of WebGen; Model-Driven Software Development; model transformation and code generation. Chapter 3 describes the design of the proposed model for security and the RESTful web service. The requirement of the system as well as how the models solve problems will be discussed. Chapter 4 conducts the implementation detail of code generation. It also demonstrates how to use the new software to generate website for different scenarios. Chapter 5 introduces the test strategy - a combination of automatic test code generation and manual testing for the generated result. Project evaluation and limitations are discussed. The final chapter summarises the work of this project, by proposing a conclusion and identifying further work to improve the software. By Qinan Lai 13

15 2 Background This chapter introduces the necessary background knowledge for understanding this project. Firstly, a background data intensive website is presented. Technologies for developing separated levels of a data intensive website are introduced. Secondly, the introduction of Model-driven software development is presented and how its concepts are demonstrated with WebGen software. Finally, because an objective of this project is to develop a RESTful model, the background to the RESTful web service is introduced. 2.1 Data Intensive Websites Websites can be classified into two kinds: static and dynamic; the difference is whether the website can generate different responses to different requests. Dynamic websites usually use a programming language to generate static contents, such as PHP. A data intensive website is similar to a dynamic website. It usually has a complicated architecture, using separated levels (3 or more). The standard 3-tier architecture (seefigure 3) website consists of a presentation tier, a business logic tier, and a data tier. By separating levels on the website, modification in one level does not affect the others. This approach is more robust and more suitable for complex use cases. Figure 3 three-tier architecture A data intensive website deals with a large amount of data, as well as many user interactions. As a result, developers must place emphasis on security issues. Authentication and authorisation are considered as basic requirements for supplicated websites. Authentication is a process to see whether the user can provide correct identity proof, such as a password, so the system knows who the user is. Authorisation checks By Qinan Lai 14

16 whether the user has the authority to perform some actions; in other words, it tells the system what the user can do. This section discusses different tiers and security concerns of data intensive websites by introducing the particular implementation technology applied in WebGen Spring Framework The complexity of data intensive websites means that their implementation is not based on raw Java or PHP code. Instead, they build on frameworks that provide much of the implementation code required. These are more than APIs. An API provides functions that can be used by the developer s own code; the interaction between the developer s code and a framework is much more dynamic and will include the framework code using the developer s code. There are varieties of web application frameworks for Java EE application, such as Spring Framework, Apache Struts 2 or JBoss Seam. The website generation project adopts Spring Framework because it is popular and developing quickly. The Spring Framework is an application framework for Java and the.net platform that provides a complex infrastructure, so the developer can focus on the logic of the application rather than on the architecture. Although the Spring Framework supports to develop any kind of application, it is most commonly used for developing the Java EE application. It is treated as a lightweight alternative to the EJB model in the Java community and is gaining in popularity [15]. The core of Spring Framework is based on the principle of Inversion of Control (IoC), or by its more descriptive name Dependency Injection (DI), to describe IoC in runtime [16]. IoC means that the application does not control its structure; the Spring IoC framework will do that. For example, if a class A depends on class B to perform some operations, traditionally A creates an instance of B in a function. Through this method A By Qinan Lai 15

17 and B are coupled with a hard dependency. When moving the logic to a new environment, the code needs to be changed. A example can be found in Figure 4. In this example, if Spring Framework is used, the class does not need to manage their dependencies, the job are left to the framework. Figure 4 Inversion of control By using IoC, it is possible to develop disparate components. In the example, the instance of B will be provided to A at runtime by Spring. It makes the objects reusable by separating the control logic from different objects. By using the Spring IoC container, the configuration file will be used to manage the dependencies between different objects. Thus, by applying Spring Framework, the complexity of developing web application is reduced: developers are released from managing the control flow of different classes and they only need to write Plain Old Java Objects (POJOs)[17], and to configure Spring Framework to manage the calling or injection of classes. Spring Framework can be configured by its configuration file - usually the name is application-context.xml - or a set of Java annotations applying to the business objects that are managed by Spring Framework. WebGen will generate the right annotation of each object and the global configure file Hibernate The traditional relational database model for the data persistence of a website will cause mismatch between the programming model and the persistence model because most of the programming languages are object-oriented, while the relational database is based on data tables. To solve this problem, Object-relational mapping (ORM) provides a By Qinan Lai 16

18 programming model that can convert the object-oriented data to the type systems in the relational database. The use of ORM will reduce the code that needs to be written; in addition, it will decrease the difficulty of migrating from one database system to another. In order to separate the persistence layer and the business logic layer of a website, the Data Access Object (DAO) design pattern is applied. DAOs warp the implementation detail of the persistence mechanism. Although the DAO is specific to the implementation technology, the interface to the business object remains unchanged. Application Data Access Object Hibernate Hibernate properties XML/annotation mapping Database Figure 5 Hibernate architecture [18] Hibernate is an ORM library for Java and.net platform. It has been developed by the JBOSS Community as free and open source software. It enables the user to develop the persistence layer of an application and apply the DAO pattern easily. Figure 5 shows that Hibernate stands in the middle of the programme persistence objects and the database; with the right XML configuration files, Hibernate will generate the SQL scripts for managing the data. Hibernate is widely supported by other programming frameworks; for example, Spring Framework provides the APIs and templates to By Qinan Lai 17

19 integrate Hibernate. Integrating Security and RESTful Services into Model-based Generic Website Tooling WebGen will generate a series of objects from an entity instance defined in the website model. They are placed in the following packages: domain.entityname: this includes proper getter and setter functions for an entity model instance and dao.entityname/dao.hibernate.entityname. The configuration files and the possible operations of an entity; for instance, delete, save, or find a particular record, are encapsulated in these packages Java Server Faces JavaServer Faces (JSF) aims to establish the standard for building server-side user interfaces [19]. It provides an easy user interface programming model that can gain the benefits of the high-performance backend of Java EE technologies. JSF has the following parts [20]: A set of prefabricated UI (user interface) components An event-driven programming model A component model that enables third-party developers to supply additional components. By Qinan Lai 18

20 Figure 6 JSF example These parts are achieved by a set of APIs in JSR 314 and 2 tag libraries for expressing UI components. JSF can manage the Java Beans and the navigation model that are defined in the XML configuration files. It is easy to configure JSF to interact with other frameworks, for example, Spring Framework. The version of JSF applied in this project is JSF1.2; it uses JSP files for presenting the page content. Unlike raw JSP where features such as page navigation and validation has to be developed manfully, JSF provides a automatic solution. In the past, Java EE was known as a technology with high performance but hard to develop; in contrast, technologies such as ASP.NET provide an easier approach that does not need much programming. JSF provides a method of bringing easy user interface development to Java EE [20]. By Qinan Lai 19

21 This project uses two parts of JSF technology: the navigation model and the tag library. The navigation model of JSF puts all the navigating rules in a central XML file called faces-config.xml. This approach enables the user to navigate to different pages based on preconditions; it also avoids hard coded page addresses. The tag library provides more powerful UI components, which can easily retrieve data from the business object. Figure 6 gives an example of the navigation rule and the usage of the JSF tag library. The presentation layer and workflow of the generated website can be seen in Figure 7. The GenJSF model will mainly generate: 1) A service object - standing between the persistence and presentation layer of the website - which sends and receives information from the persistence objects (which are generated by the GenORM model). This design helps to layer the website and makes it easier to be modified. 2) A backing bean object: so-called managed beans in the JSF world which retrieves data from the service object, performs operations on the service object, and incorporates the properties in a Backing bean which can be bounded to the value of a component from a JSP page. 3) a converter object which tells the JSP page how to present a business object. For example, to print a date object following the pattern dd/mm/yy. 4) Validator object: it is in charge of validating the users input. 5) A JSP file which shows the generated content and interacts with the user. (But not exactly. JSF will render the page as a plain html page, so any browser can accept it; however, this process is automatic and seamless to the user.) All the content units defined in the website model will be translated as a JSF component, for example, a DataIndexUnit is represented as a <h:datatable>. 6) Message bundle, which is not shown in the picture. The message bundle gives a mapping of the text shown in the page to an identifier; consequently, if some texts appear in different places, it is easier to modify the message bundle file than to modify every appearance of the text. By Qinan Lai 20

22 Persistence object Information flow Use Interact Service object Converter Backing bean JSP file User Validator Figure 7 Workflow of presentation layer With the technologies of Spring, JSF and Hibernate, a data intensive website can be built; nevertheless, in reality more advanced features are desired. In the next section, the background that is not supported by WebGen but is integrated in this project, will be introduced Spring Security A significant drawback of WebGen is that it lacks protection. Security requirements such as authorisation and authentication are important for a website. Java EE framework has provided some security controls, for example, protecting web pages in a particular path. More advanced protections, however, need to be coded by hand. There is software that aims to simplify the security coding of a website, Spring Security is one of the best choices for Spring Framework. Spring Security is probably the most widely used of the Spring projects; it is formerly known as the Acegi Security System for Spring. It is easy to learn, deploy and manage, making complete web application security possible by a few XML configurations [21]. The main features of Spring Security [22]are summarised below: a) It is easy to By Qinan Lai 21

23 configure by using the Spring IoC container. b) It can keep the application objects free of security code. In other words, it is non-invasive. When adding security to an application, an extensive change of the code is needed. c) It provides comprehensive authorization services. It can protect static URLs defined by regular expressions, it provides special authorisation for RESTful requests and there are a range of options for accessing control. d) It supports different authentication providers, such as a database, open-id[23], and Central Authentication Service (CAS). In addition, the developers can easily implement customised authentication details. 2.2 Model Driven Software Development The basic principle of Model-Driven Software Development (MDSD) is to model some, or all, of an application and to generate automatically at least part of the implementation of the application. The model concentrates on design aspects of the application, e.g. its functional features, and does not include low-level implementation detail. Experience has shown that by using a model-driven approach, it is possible to simplify the process of design and increase productivity. The phrase MDSD refers to a generic approach of combining abstract models and code generation to produce parts of an application. The Object Management Group (OMG) [24] defines a specific model-driven approach, known as Model-Driven Architecture (MDA)[25]. The aim and purpose of MDA is the same as any MDSD approach; however, it requires the use of particular standards for particular roles within the process; for example, the use of UML to capture application models. Although restrictive in the way in which a model-driven approach is applied, MDA has introduced terminology that is generally accepted as being useful in the description of any model-driven process; this will be introduced as required in subsequent sections Meta-model To create a model requires a notation in which the model can be described; also, to By Qinan Lai 22

24 perform automatic code generation from a model requires this notation to have clear and unambiguous semantics. In MDSD, the semantics of models are defined using models; as these models are models about models, they are referred to as meta-models [8]. In practice, although there may be many notations in which application models are written, there are very few meta-modelling notations; the OMG uses the meta-modelling notation Meta Object Facility (MOF)[26], whereas the Eclipse Modeling Project(EMP) uses Ecore as its meta-modelling notation. An advantage of a restrictive set of meta-model notations is that generic tools can be written against a notation and used to process any application model defined using that notation. The major elements of the Ecore meta-model are shown in Figure 8. Ecore is an abstract syntax that conceptually defines what a model can consist of. It also has several concrete syntaxes, any of which can be used to define an application model. Figure 8 uses the Ecore tools graphical syntax; this has many similarities with the UML Class Diagram syntax and can be correctly interpreted by reading it as a class diagram. The reason for the similarity is that a meta-model only needs the concepts of data type, class, attribute and association. Although It shows the major elements of Ecore, the major components of OMG s Essential (core) MOF (EMOF) [10] are the same, and application models can be easily transferred between the two representations. Figure 8 A simplified subset of the Ecore Meta-Model By Qinan Lai 23

25 2.2.2 Eclipse Modeling Project Integrating Security and RESTful Services into Model-based Generic Website Tooling WebGen is developed by using EMP. EMP is an Eclipse top-level project within which many very useful MDSD tools are being developed. In outline, Eclipse is an extensible multi-language software development IDE. Its extensible nature is achieved via its support of plug-ins and EMP creates a wide range of plug-ins that make MDSD tools available within the IDE. Some of these, e.g. ATL [27] and JET[28], will be introduced in the next section. At the centre of EMP is Ecore, the meta-model notation on which the EMP plug-ins are based. Ecore is defined by the Eclipse Modeling Framework (EMF) component of EMP. EMF includes a model-to-text transformation that can generate a Java implementation of any model defined using Ecore. The limited expressive capabilities of Ecore mean that this equates to the data structure elements (domain model) of an application. These data structures can form the core of MDSD tools, but they have also had general-purpose applications built round them. In the early days, EMF was the only EMP component, and the phrase EMF is still sometimes used to refer to the whole suite of tools which EMP now encompasses. In addition to the Java classes of the domain model, an edit framework and an editor can also be generated from an Ecore model. With no programming by a user, an application can be generated that allows manipulation of the instances of a model. However, it must be stated that the master-details style of this editor with a tree-view master that shows elements of a model and a properties base details view does not have the most user-friendly interface. This is significant, as the Ecore model is self-defining and an Ecore model can be created using this tool. Alternative mechanisms for creating Ecore models now include the graphical syntax provided by Ecore tools and the textual syntax of Emfatic [29]. By Qinan Lai 24

26 2.2.3 Model-driven work flow Integrating Security and RESTful Services into Model-based Generic Website Tooling MDSD involves an abstract model of an application from which, some of the application s implementation is generated. In practice to achieve this, two processes are required: implementation details need to be added and the concrete syntax of the implementation generated. It is complex to perform both of these processes in a single step. Thus, they are normally performed as two sequential steps; in the first implementation, detail is added and in the second implementation, code is generated. PIM and PSM Adding implementation detail to a model is performed by modifying the model or, more usually, by creating a second model. As the target implementation technology is referred to generically as a platform, the two types of model are distinguished by describing them as a Platform Independent Model (PIM) or a Platform Specific Model (PSM). Therefore, in a model-driven workflow, a PSM is created from a PIM; this process is usually described as the PIM being transformed into a PSM. Importantly, a PIM defines the concepts and characteristics of the specific domain without any implementation technology constraints; for example, that a website is composed of persistent objects, pages and forms, etc. In real applications, it is rarely the case that a single implementation technology is used; for example, a website will use a persistent technology, a business logic or framework technology, and a presentation technology. As a PSM is targeted at a specific technology, a PIM will be transformed to a series of PSMs, one for each technology used in the complete application; this is shown in Figure 9. By Qinan Lai 25

27 Figure 9 Example Model-to-Model Transformations [30] Model transformation As previously described, the process of creating a PSM from a PIM is described as a transformation. The generation of implementation code from a PSM is also described as a transformation. To distinguish these two types of transformation, the PIM to PSM process is called a model-to-model, or m2m, transformation, whereas the code generation process is described as a model-to-text, or m2t, transformation. The use of the phrase text, rather than code, in the second case recognises that not all implementation is code; it can include, for example, XML configuration files or HTML pages. The characteristics of these two transformations are sufficiently distinct that different languages and tools are required to implement each of them. So how are those transformations performed in terms of technology? There are several model-to-model transformation languages, or model transformation languages (MTL). Their common characteristic is that they are rule-based or declarative in style. Figure 10 shows an example using the Atlas Transformation Language (ATL), which is part of the Eclipse Project. An ATL transformation (right-hand box) is composed of a set of rules (one in this case). The rule identifies a concept (Person) in the source model (left-hand box) that triggers the rule and the concept (Contact) in the target model (central box) By Qinan Lai 26

28 that results when the rule is executed. The body of the rule defines how the properties of the concepts are mapped. A rule can include an additional guard condition and restricts when it is executed. In the example, the rule is only executed when the function property of the Person concept has the value Boss. Figure 10 Example ATL Model-to-Model Transformation [31] Note that the transformation is based on the occurrence of concepts in the source and target models, provided by the meta-model of a model. Thus, the transformation is written in terms of the source and target meta-model and it is these that are shown in Figure 10. The input model must conform to the source meta-model and would contain the names of actual people. As in model-to-model transformations, several tools and languages provide model-to-text transformations. The common characteristic of these is that they have a template of the output text that contains placeholders which are replaced with information from the model during the transformation. Figure 11 shows an example transformation using Java Emitter Template (JET), which is again part of the Eclipse Modeling Project. In this a placeholder (<c:get select= $currperson/@name >) in the template (top-left box) is replaced with values from a model (bottom-left box) to produce Java code (right-hand box). By Qinan Lai 27

29 Figure 11 an Example JET Model-to-Text Transformation In the example transformation of Figure 11, the input model is given via an XML file; this is just one of the model formats that JET supports. The placeholders use XPath like expressions to control the selection of values from the input model. The example template also shows that templates can contain control-flow structures that are used during the processing of the transformation. In the example template, an iteration control is used to output a println statement in the Java code for each of the values present in the input model. Control-flow structures are also available that allow the conditional inclusion of parts of the template based on values present in the input model. In many ways, model-to-text templates are like JSP pages and PHP scripts, and they are processed and used in a similar way. 2.3 Models and model driven workflow in WebGen With the background of MDSD, how WebGen works can be demonstrated. WebGen follows the standard approach in the previous section. It defines a website PIM, and then uses the PIM to create PSMs by m2m transformation. The code is generated at the last step by a m2t transformation Website PIM The website model is the top-level model of WebGen. It tries to capture the concept of a generic data intensive website by using a set of models. They can be divided into two By Qinan Lai 28

30 parts: persistent models and presentation models. Persistence Model Data is an independent part of a website. Usually the data is stored in a relational database system; however, relational databases are organised by columns and rows and are different from the object-orientated model that is used in a program language. Fortunately, a lot of Object Relational Mapping framework (such as Hibernate[32]) can organise data for the developers. WebGen constructs its persistence model the same way as entity objects in program language. The hierarchical structure of the persistence model is given in Figure 12. The core of the persistence model is Entity. An Entity model has: 1) Association it is a reference of other Entities. A reference describes the relationship of two entities. The relationship can be unique or ordered, and it can also be multiple i.e. their relationship can be one-to-one, one-to-many, many-to-one, and many-to-many. 2) Attribute it is a value with a particular data type. Attribute is the normal way to store some data. Now it supports basic Java types. By Qinan Lai 29

31 Presentation Model Figure 12 Hierarchical structure of persistence model [9] From the users point of view, a website can be considered as a set of web pages. The website model of WebGen use Page and Link to describe a website. The hierarchical structure of the presentation model can be seen in Figure 13. By Qinan Lai 30

32 Figure 13 Hierarchical structure of presentation model [9] Page Model A page has some identical attributes, for example, title, layout style and summary. It uses different CountentUnits to present data in different ways. A ContentUnit has a necessary reference of an Entity as the target. The data of target entity can be presented by different kinds of ContentUnit. WebGen supports these ContentUnits. An IndexDataUnit: represents the details about all of the instances of a persistent entity. CreateUnit: represents the content that enables a user to create a new instance of a persistent entity. EditUnit is similar to CreateUnit. It allows a user to change an instance of a persistent entity. Action Model The Action Model describes a command that the user can perform; a simple example is to control how the user navigates between different pages. A CreateUnit has two By Qinan Lai 31

33 actions which identify the success and fail destination of the create command. In addition, an IndexDataUnit can have a delete action to delete the record of an entity. By using Actions, different data content units can be linked to each other, which all work as a navigation model. Website Property Global configuration is part of this model, such as the title of the website and the name of the generated project. The website model only contains the necessary concept of a website; however, to make code generation possible, other information depending on particular technology is necessary. Thus, multiple models are needed for the abstraction of a website. In the next section, how the specific model works and how the workflow is managed by a different model of WebGen will be introduced Model driven workflow In WebGen, the models also follow the principle of differentiated model definition and code generation. The website model is the PIM of the software. There are other models which help the system to generate code and enable users to control the generation. These models are listed below. Due to limited space in this report, the architecture figures of those models are presented in the appendix. i) ORM (Object-Relational Mapping) model The ORM model is a PIM that describe the properties of persistent data. ii) JSF (Java-Server Facelet) model This PIM abstracts the information of presentation. Although the name contains a specific implementation technology (JSF), it does not facilitate any platform-specific information. iii) GenORM model This is the PSM for generating persistence layer code of the website. It provides all the information defined in the PIM, as well as other technology-specific properties for By Qinan Lai 32

34 example, the identifier of the database system or the type of generated ORM code (To generate Hibernate implementation or JPA implementation). iv) GenJSF model GenJSF model is the PSM for generating the JSF implementation for the presentation layer of the website. Many details go into this model; for example, to render a many-to-many association as lists or checkboxes or to control the layout of the page. By using these models, the necessary information of a website is captured. The next section will explain how these models are created from the initial website model. WebGen follows the common approach for m2m transformation. The workflow of the creation for different models is presented in Figure 14.The user defines the website PIM by the graphical editor. The website model is translated to three models: ORM, JSF, and the configuration model. These models are intermediate artefacts. They serve the system, not the users; in other words, the users cannot directly modify these models. The users can modify the GenORM and, GenJSF model that extend the ORM and JSF model. Once a user has completed their alteration of these models, the software will generate the code from them. By Qinan Lai 33

35 2.4 RESTful web service Figure 14 Model transformation workflow project. This section gives a short introduction of the RESTful web service and the Jersey REST and SOAP REST stands for Representational State Transfer. Sometimes the software, which adopts a REST framework, is called a RESTful approach. It is lightweight architecture for web services and system. The initiative of REST is to use simple HTTP requests to communicate between machines (typically the servers and the clients), rather than complex mechanisms such as Simple Object Access Protocol. Roy Fielding [14]provides a succinct definition of REST : "Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual By Qinan Lai 34

36 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." As HTTP has the ability to post and read data, it is suitable for using HTTP requests for all CRUD functions. REST uses HTTP as the communication vocabulary between server and client; in contrast, SOAP encourages the developer to invent their own languages. In SOAP, a request is an XML file. Elkstein [33] provides the metaphor that a SOAP request is a mail with an envelope while a REST style request is a postcard. A postcard is easier to deliver and costs less paper, which means RESTful framework is more efficient in using the bandwidth. A typical example of a SOAP request looks like this: <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body pb=" <pb:getentity> <pb:entityid>12345</pb:entityid> </pb:getentitydetails> </soap:body> </soap:envelope> A RESTful request looks like this: GET Resource is the key principle of REST, which is usually presented as a URI. In a good REST design, all information is associated with resource. To use the resource, clients make calls by HTTP requests. The resource should be a noun rather than verb, for example, a call of getresource will not be be issued in REST; rather than using use instead. Table 1 shows how HTTP verbs are used for implementing a web service. By Qinan Lai 35

37 Resource GET PUT POST DELETE Collection URI, such as List the elements of the collection, complete with their member URIs for further navigation. For example, list all the resource information. Create a new entry in the collection where the ID is assigned automatically by the collection. The ID created is usually included as part of the data returned by this operation. Create a new entry in the collection where the ID is assigned automatically by the collection. The ID created is usually Meaning defined as "delete the entire collection". Element URI, such as 141/ Retrieve a representation of the addressed member of the collection expressed in an appropriate MIME type Update the addressed member of the collection or create it with the specified ID. Treats the addressed member as a collection in its own right and creates a new subordinate of it. Delete the addressed member of the collection. Table 1 RESTful requests and HTTP requests (Modified from Fielding [14] s work) The information received from the server is usually a HTML, XML or JavaScript Object Notation (JSON) document, though other types such as plain text or media files are fine. There is not an official standard for the RESTful web service; however, as it gains in popularity, it is easy to implement a RESTful service with the support of other technologies. Although REST has some advantages, that does not mean SOAP is falling behind. SOAP is mature and designed for enterprise usage with many tools that support By Qinan Lai 36

38 development. In comparison, the RESTful framework is relatively young and as yet lacks support for commercial application Jersey Project JSR 311: JAX-RS: The Java API for RESTful Web Services[34]is the official specification of the RESTful web service for Java. There are several implementations of this specification and the Jersey Project is one of them. The Jersey Project is an open source project, providing APIs for both server side and client side. It is simple to use Jersey API for adding RESTful functionality in an existing Java web application. Jersey manages the RESTful service by a set of Java annotations. The code gives a very simple example class that handles HTTP GET Path annotation specifies the URL of the specifies what method this function should request. Then the function finds the requested object and returns public TestEntity1 gettestentity1(@pathparam("id") long id){ TestEntity1 result = testentity1service.findtestentity1(id); return result; Usually, the response would be either a serialisable object, if the request is GET, and the object is converted to XML or JSON, or HTTP status code. Technologies i.e. JAXB: Java API for XML Binding[35]can carry out the former perfectly while, if the HTTP status code is successful, the server returns code 200 OK or code 202 accepted ; otherwise, the server returns a code which specifies the error. 2.5 Summary This chapter described how WebGen works in terms of its model and model transformation flows. In addition, the relevant knowledge for understanding MDSD was outlined. After discussion of the models in WebGen, the architecture of generated websites was introduced with the supply knowledge of web technology. Lastly, Spring Security and RESTful service, which will be integrated with WebGen in this project, were explained. In the next chapter, the model design will be presented. By Qinan Lai 37

39 3 Model and Website Design This chapter proposes some models that can integrate RESTful service and security with WebGen. The model can be divided into three main parts: the RESTful service on the server side; the RESTful service on the client side, and the security model. In each section, the model design is demonstrated, with an explanation of what necessary requirements need to be introduced, and how the design captures those properties. 3.1 Server side of RESTful service This section introduces the models for RESTful web service Website model and JSF model A server side RESTful service deals with the HTTP requests that are performed by any client. It also transforms the right content type of data or a relevant status code to a client. The core concept of a RESTful service is a URI, which is called a resource. A resource is linked to the backend of the website and performs as an interface between the user and website backend. Therefore, a model of a RESTful resource must deal with the mapping to the backend data. In thewebgen website model, the meta-model of data is Entity. Normally, RESTful resource has a reference to an Entity instance. By mapping a RESTful resource to an Entity instance, the ability of transforming data between server and client is given to the user client. It is similar to the content unit model of WebGen. Each content unit has a reference to an Entity, thus a user can perform actions through a web browser and communicate to the backend of the website. As a RESTful service, the only difference is that the communication intermediary is not only a browser, it can be any client able to perform an HTTP request and receive data. By Qinan Lai 38

40 1 WebGenModel -resources -entities 1 * Classifier NamedElement -name Entity 1 1 RESTResource * -source Figure 15 RESTful service server side PIM Figure 15 shows the model design of RESTful service of the server side. It only describes the necessary part of the whole model design. Figure 12 and Figure 13 provide the original model of the website. The WebGenModel contains one to many references of Datatype, Entity or Pages. It also contains multiple instances of RESTResource. There is a one-way entity reference in a RESTResource model. The RESTResource model also requires a consideration of security. If the source entity name is used to generate the path of a RESTful resource, the name of the backend persistence data structure is leaked to the user. To avoid that, the model must support the customisation of the name of a RESTful resource; this is why RESTResource inherits the NamedElement. The model transformation flow (Figure 14) shows how a website model is transformed to a Configuration model, an ORM model and a JSF model. The RESTful service has a tight relationship to the ORM model in our case, it is a one-to-one mapping. However, the RESTful service is open to the public; it is more suitable if those properties are provided to the JSF model. Another concern of putting the RESTful service model to the JSF model is that the ORM model is sufficiently tested to support different association aggregations. If too many modifications of the ORM model are performed, By Qinan Lai 39

41 the testing work will be huge because a new unit test generation should be developed. Due to limited space, this project will follow the approach of modifying the JSF model while attempting not to affect the ORM model. The design of the JSF model is the same as the website model, because the concepts captured in the website model is technology independent. As a result, the model diagram is omitted GenJSF model A particular lifecycle of a RESTful request can be explained as follows: the user sends a request to a destination with some data and waits for a response. A RESTful resource, typically a URI, is like the destination of a request. The HTTP requests work like a verb and tells the server what operation should be done to a resource. However, those requests are not modelled in the website model; they are placed in the PSM. You may doubt that HTTP requests are platform-independent, so why not put those to the PIM? There are some usability concerns. The modular use of the RESTful service is to generate operations dealt with by GET, POST, PUT, and DELETE request, with a particular URI path, usually using the plural form of the resource name for POST requests and using the resource name+ resource id to identify a resource instance for a GET request. If requests are placed in PSM, after model transformation, those models can be created from the information provided in PIM; otherwise, the user has to define each request in the website model and do the same for each resource. Another concern is that, though a RESTful request is platform-independent, the security implementation may be platform-specific. In this project, the implementation of the technology of Spring Security supports request method security, but other implementations might not support this. The discussion of a security model will be presented in the next section. Figure 16 describes the design of PSM; it only shows the relevant part of the RESTful By Qinan Lai 40

42 service. A GenJsfModel contains zero or more reference of GenRESTResource. Each GenRESTResource model has a reference to the RESTResource model defined in the PIM, and one or more GenRESTRequest models. The reference to PIM helps the code generator to find the necessary information of persistence data. The GenRETRequest model has two attributes: path and method. Path can form the URI of a resource; it enables the user to customise a particular path for a request. Method stands for the name of a HTTP request. Figure 16 RESTful server side service PSM The m2m transformation will create five GenRESTRequest models for each RESTResource by default; they are listed in Table 2. If the user does not want a specific operation to be generated, he can delete the model. The path of each GenRESTRequest model is transformed from the name of the RESTResource model. To use the mapping between CRUD operations and simple HTTP requests is a standard approach; nevertheless, other requests such as HEAD, OPTIONS, and MOVE might be added if further implementation was carried out. Path Request Operation ResourceName/{id GET Request the data of resource with a particular ID ResourceNames GET Get all instances of a resource ResourceNames POST Create a new resource By Qinan Lai 41

43 ResourceName/{id PUT Modify an instance of resource with a particular ID ResourceName/{id DELETE Delete a resource instance with a particular ID Table 2 Default generated requests When a user performs a request, either the requested data or a status code (when he meets an error or no content is returned, such as a delete request) will be returned. The in-memory presentation of a resource is, in this project, a Java object. As mentioned before, usually the client prefers XML or JSON contents. There are technologies that can automatically serialise an object to XML or JSON content. The PSM of the ORM model already has the ability to capture some of the information for XML serialisation, so those properties are not included in the PSM. 3.2 Client side of RESTful service The extended models of WebGen support the abstraction of the server side of a RESTful service. To make the service available for users, a tool that can talk to the RESTful server is needed. The advantage of a RESTful service is that it does not restrict the implementing technology for its client. Any programming language, as long as it supports HTTP, is enough for writing a RESTful service client. However, it is also a problem because there is not a standard way to develop a RESTful service client. There are many choices to implement a client for a RESTful service. Simple Javascript can perform the HTTP request and wait for the data returns. Much AJAX application talks to a RESTful server. In the world of Java, Apache HttpClient [36]provides a HTTP client library; it includes APIs that can deal with HTTP requests and authentication issues. Other implementations, such as RESTEasy client[37], provide similar functionalities. By using these technologies, a RESTful client can be built. However, WebGen is a tool for generating websites. It is not complete if it can generate the server side code of a RESTful service but fails to generate a client. What properties must be captured, then, in a model for a RESTful client? A RESTful By Qinan Lai 42

44 client is an interface between the user and RESTful server. The language for RESTful server is HTTP requests and XML (or JSON) data, which are not human-friendly. It should present the data in a human friendly way, probably HTML or an application with GUI; and it should help to translate the users input into XML or JSON code. Thus, a RESTful client is very similar to the existing JSF models in WebGen. It should present data entities, create/modify/delete entities in the same way as JSF content units. Consequently, a RESTful client can be treated as another platform-specific implementation of the presentation layer in a website. The meta-model of presentation PIM was presented in Figure 13 Hierarchical structure of presentation model. The DataIndexUnit can be used as a unit that use GET request to retrieve data from the user. The DeleteAction can be used for performing a DELETE request to the server. The CreateUnit and ModifyUnit can be used for performing POST and PUT requests to the server. The only difference is in the M2T transformation; those units should be mapped to text artefacts that use HTTP requests to communicate with the server. As this project uses the existing content model of WebGen, the remaining problem is to decide the implementation technology of a RESTful client. As discussed earlier, libraries such as Apache HTTP client or RESTeasy are Java libraries. WebGen is a website generation tool; it is better to generate something relevant to the webpage, rather than to generate a Java desktop application. In addition, as a RESTful client is probably deployed in the user s computer, the runtime environment of the user must be considered. The user may not have a Java Runtime Environment (JRE). As a result, to build a RESTful client without platform restriction is a better choice, using plain HTML+Javascript. There is therefore, no need to be concerned about the users environment. Only a modern web browser is required, and the implementation work for HTML and JavaScript is acceptable for a 3-month project. By Qinan Lai 43

45 3.3 Security Model Integrating Security and RESTful Services into Model-based Generic Website Tooling This section demonstrates the configuration model for security and modifications for other models to enable security options Security settings To add security settings to a website, the first thing that needs to be considered is: what resources should be protected? Web pages should definitely be protected, as a minimal requirement for a secured website. In addition, the RESTful service models were added in the former section, so those RESTful resources also need protection. A website is usually layered; the backend of the website should be invisible, so the database should be protected by its own security strategy and is hidden from users. As a result, the models that need protection are Page and RESTResource. The next question is how to protect those resources; in other words, what necessary information should be modelled to enable the generation of security code. Usually, to protect a website, a mechanism of authentication and authorisation is needed. Authentication tests if the user provides the right identity proof and authorisation checks if the user has the privilege to perform a particular request. How to configure authentication is a global setting for a website and will be discussed in the next sub-section. For authorisation, attributes that determine the authorisation strategy should be added to every model that needs protection. There are many ways to conduct authorisation. Usually, a role-based authorisation system will be introduced; the system checks if the user is assigned to a role that can perform the request. Other approaches exist, such as checking if the user is from a particular IP address. As an initial attempt to model security settings, this project aims to offer models that can capture a role-based authorisation system. By Qinan Lai 44

46 Figure 17 Security PIM The website model diagram can be found in Figure 17 Security PIM (above). The two kinds of resource that need to be protected RESTResource and Page - are provided with a new property, SecuritySetting. SecuritySetting has two attributes. AccessOptions is an enumeration type and supports four options: Access Option PermitAll Explanation All of the users, no matter authenticated or not, can request the resource. AuthenticatedUser Only authenticated users can request the resource. PaticularRoles Authenticated users with a particular role can request the resource. The names of the roles are placed in a roleslist attribute in SecuritySetting. UserProfile Only the user associated with this resource can request it. Table 3 Access Options In the PSM, the AccessOptions model is translated to a Spring Security Expression. This enables the user to make a complex authorisation configuration. The PSM can be seen in Figure 18 By Qinan Lai 45

47 3.3.2 Global security model Figure 18 Security PSM In the previous sub-section, the issue of authorisation is discussed. In the following sub-section, global security settings such as authentication are introduced. In this project, the implementation technology for security has been determined as Spring Security. So, the global security model tries to capture the features of Spring Security. If the feature is platform-independent, then this model is in PIM, otherwise PSM. The only property that is added to PIM is authentication provider, because other features are mainly platform-specific. The design of authentication provider should enable the system to carry out authentication from different providers. As a result, the design is shown in Figure 19; an AuthenticationProviders model is added to the WebsiteProperty model, and is able to include multiple authentication providers. It also has the potential to be scratched if other providers need to be added. Now three authentication providers are described: 1) DatabaseProvider: is the simplest approach for authentication. The Username, password and role of user are stored in the same database of the entities. 2) By Qinan Lai 46

48 LdapProvider: LDAP can act as an authentication provider, usually for a large system. A complex system might have several sub-systems with different databases, but the authentication should be managed by one server, so the user does not need to have a separate username and password for each subsystem. 3) OpenidProvider: Open-ID[23] provides a solution that enables the user to use their open id to sign in on any site that supports open ID. WebGenModel 1 +websiteproperty WebsiteProperties +authenticationproviders AuthenticationProvider 1 * DatabaseProvider LdapProvider OpenidProvider Figure 19 Authentication Provider Model In the PIM, security settings and other settings are modelled in the WebsiteProperties model. In the original implementation of WebGen, all WebsiteProperties are translated to a persistence property model in the ORM model. As security settings are not a part of ORM model, a new model GlobalSecuritySetting is added to the GenJSF model. This model includes configurations that are more detailed: a) createformlogin is a Boolean value and tells the system whether to create a login form. b) createbasicauthentication: tells the system whether to enable basic authentication. The system will create a login form by default; however, basic authentication can also be achieved. c) 1 CreateRememberMe tells the system to create a remember me option in the login page. d) systemkey: the system key to encrypt the cookie stored in the user s system. e) logoutsuccessurl: the default URL when the 1 A better approach is to enable a different URL path by using a form login or basic authentication; nevertheless it is not supported by Spring Security yet. By Qinan Lai 47

49 user logs out Presentation layer In this sub-section, the issues in the presentation layer that enable the users to use the above security settings will be discussed. As stated earlier, WebGen supports the generation of CRUD data units; however, it lacks the capability to generate units that perform authentication. Typically, a login page, a logout button, a unit that shows the detail information of the current user and a user self-registration data unit are desirable. Figure 20 shows the design of the presentation model. As the name suggests, those units will become their relevant content in the code generation stage; the details of code generation will be explored in the next chapter. WebGenModel +pages Page 1 * 0..1 * +units ContentUnit LoginUnit LogoutUnit RegistrationUnit DetailsUnit Figure 20 New content unit models 3.4 Altered models As mentioned outlined above, WebGen has already provided an effective website PIM and PSMs. This project added some new models and modified others, enabling more information to be abstracted. After explaining each part of the altered model, now let s look at the big picture of the models. The modified meta-model for the website PIM can be seen in Figure 21, and the PSM can be seen in Figure 22. These figures only show the models infected in this project; a complete Emfatic file is listed in the appendix. The By Qinan Lai 48

50 basic philosophy of M2M transformation flow is that the presentation model in PIM is transformed to those models with a name-prefix Gen in PSM i.e. Page GenPage, CreateUnit GenCreateUnit. DatabaseProvider +authenticationproviders 1 WebsiteProperties +sitetitle +projectname +testprojectname 1 1 WebGenModel +resources -websiteproperties 1 OpenidProvider AuthenticationProvider * 1 +pages * LdapProvider 0..1 * +units 1 Page +title +navigationlabel +securitysetting childpages 1 1 RESTResource 1 +securitysetting SecuritySetting -roleslist +access <<enumeration>> AccessOptions 1 1 +PermitAll +AuthenticatedUser +ParticularRoles +UserProfile +cancelaction 1 1 * PageLink * ContentUnit +confirmaction +purposesummary +header +footer +headerclass +captionclass +controlclass +footerclass +errorclass 1 EditUnit +clearfieldsonconfirm +clearfieldsoncancel +layoutclass +columnclasses DataUnit UpdateUnit CreateUnit +actions 1 +targetpage * Action +header +footer +headerclass +footerclass SelectAction DetailsUnit IndexUnit LoginUnit LogoutUnit RegistrationUnit DeleteAction +confirmmessage Figure 21 New Presentation PIM By Qinan Lai 49

51 Figure 22 New Presentation PSM 3.5 Design of Website After the explanations of the extended website models, it is now time to discuss the design of the website. The JSF pages of the website are handled by the JSF servlet; however, the RESTful services are handled by other servlets. So a particular URL path is allocated to RESTful service. All RESTful resources will follow the URL pattern illustrated in Table 1 with a prefix path i.e. /rest/resourcename/{id. REST request handler is a Java class developed by Jersey Project API. It receives calls from clients By Qinan Lai 50

52 and despatches a response. Integrating Security and RESTful Services into Model-based Generic Website Tooling The RESTful client is placed in the web content folder; as the files are independent of the server, they can be copied to other servers or be used as local html files. The HTML page is static; it acts like the skeleton of the page. Dynamic content is generated by Javascript. Spring Security Framework mandates the logic of security. It adds its filter to the global configuration of the website and checks each of the requests to assess if the request satisfies the configuration (see Figure 23). The configuration file of Spring Security is applicationcontext-security.xml ; it provides the information for access information checking, authentication of the provider s configuration, etc. Request JSF page User Grant or Deny Spring Security Website backend RESTful service Figure 23 Spring security with website The new content units will follow the look and feel of the existing content units. Spring Security has a default login page (See Figure 24); however, it is not consistent with the theme of the website. The Login page is designed like Figure 26, which also supports the generation of Open-ID login. Figure 24 Default login page The logout unit is a little different from the existing content units, since all the existing content units were placed in the body of the page. The logout unit is just a status bar that By Qinan Lai 51

53 shows the username and a logout button, so it is placed in the banner, as in Figure 26 The login page Title of Login page Login Username Password name ***** Remember me Login Or, if you have an Open-ID account(optional) Text Login Footer Figure 25 Login page design Content page page Hello Username! Logout Navigation Parent page Child page Content Units Footer Figure 26 Logout unit The registration unit will have the same layout as a CreateUnit, so the design figure is omitted. 3.6 Summary In this section, the three main parts of the model design: Server/client of RESTful service and security model have been demonstrated. Each part of the model have been introduced together with the concerns of usability and system expandability. In addition, some complex model transformations have been illustrated, though some are omitted because the PIM and PSM are similar. Then, the design of the new website has been By Qinan Lai 52

54 described, with the emphasis on RESTful service and security. In the following chapter, the issues of code generation and details of M2T implementations will be discussed. By Qinan Lai 53

55 4 Implementation of code generation This chapter focuses on the issues of M2T transformation. How the website is generated and what concerns arise will be discussed. In addition, some system screenshots are presented to demonstrate the system. 4.1 Server side RESTful service generation This section introduces the implementation detail of the RestResource class Main class The RESTful server-side models are mapped to a class RestResource through M2T transformation. This class is responsible for retrieving data from the service class and sending data/responses back. It is managed by Spring Framework, so the reference of service class is injected to the RESTResouce class. For each of the RESTRequests, the system generates relevant operations to deal with request and response. Table 4 shows the interfaces of those operations. The name of the operations depends on the name of the RESTResouce and consequently multiple-generated results of RESTResouce will not affect each other. To make the table easy to read, we assume the name of the RESTResource is resource. By Qinan Lai 54

56 Operation Request/Response data Success Fail code getresource(int The response is the entity code 200 OK 404 Not found id) instance with the provided id getresources() A List contains all instances of the resource 200 OK 404 Not found postresource(object) The request must contain an 201 Created 400 Bad request putresource(int id) deleteresource(int id) XML serialised entity data. The <id> element can be omitted. If the create operation succeeds, the created object will be returned The request must contain an XML serialised entity data. Only a status code presents the status of the request will be sent back 202 Accept 304 Not Modified 201 OK 410 Gone Table 4 Operations in RestResource class As described in chapter 3, the data in a RESTful response is serialised to an XML document. The serialisation strategy is the default approach of JAXB. The class name of the object is applied to generate a root element of the XML document. Each of the attributes, in other words, the properties of a Java bean, is serialised to an element. If the property belongs to a basic type, the text content of the element is set to the value of the property; if the property is an object, the system transforms the object to an XML element recursively. An example is shown below: Java classes: public class RootResource{ public String getname{... public String setname{... By Qinan Lai 55

57 public SubResource getsubresource{... public SubResource setsubresource{... public class SubResource{ public String getname{... public String setname{... XML Document: <RootResource> <name>root resource name</name> <subresource> <name>sub resource name</name> </subresource> </RootResource> However, this approach also has a problem. The ORM model of WebGen supports bidirectional associations. A bidirectional association is an entity that has a reference to another entity, and the other entity also has a reference to it. In this case, the serialisation of the XML document will be an endless loop, because the two entities referenced each other. To solve this problem, the original XML binding model is modified; the end direction of the bidirectional association will not be serialised. If the response is a list of entities, the name of the entity plus s is used as the root element, with each of the entity as a sub element i.e. <objects> <object><name>data1</name></object> <object><name>data2</name></object> <object><name>data3</name></object> </objects> If there is a large amount of data entities, the user may not want to get them all in one request due to the bandwidth or the limitation of the client. Therefore, two URL By Qinan Lai 56

58 parameters are applied to limit the result: Start: specifies from which record the response should return. Size: specifies how many records the response should return. For example, the request: GET The response will return 20 records from the 10 th of the records Change of web.xml RESTful service is managed by the servlet provided by the Jersey project. Therefore, the original JET template of web.xml file is changed and the relevant content is added: <servlet> <servlet-name>servletadaptor</servlet-name> <servlet-class> com.sun.jersey.spi.spring.container.servlet.springservlet </servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>servletadaptor</servlet-name> <url-pattern>/rest/*</url-pattern> </servlet-mapping> Figure 27 shows a runtime screenshot for RESTful service. The RESTClient[38] software is used as the testing client. You can see that the XML document is correctly generated. By Qinan Lai 57

59 Figure 27 RESTClient 4.2 Generating a RESTful webpage client As we have seen, the RESTful client will apply the existing presentation models and no other model definition is needed. Therefore, the work left is to develop another implementation of presentation layer content units Client architecture JavaScript is used in performing HTTP requests and to process the XML documents. One problem is that different browsers have different API for processing XML By Qinan Lai 58

60 documents. The JSF implementation of WebGen also have some JavaScript codes, such as showing a confirm dialog when deleting records. Because the work is not large, it does not need cross-browser features; but now the project needs the capability of a cross-browser. The cross-browser feature can be achieved by using a JavaScript Library. There are a lot of options i.e. jquery[39] and YUI[40]. In this project, jquery is used because of its quick learning curve and that it is widely supported. By using jquery, more than cross-browser capability is obtained. jquery simplifies the process of the XML document and the DOM [41] of the webpage by providing a powerful document selector. It is also extensible due to its plug-in system. Some required features were already developed by a plug-in developer, so this project could concentrate on models. Three jquery plug-ins are included: 1) jquery.query.js provides functions for processing URL parameters, where it is used in the sending and receipt of parameters between DataIndexUnit and UpdateUnit. 2) jquery.base64.js provides base64 [42] encryption functions, where it is used in the encryption of the password for authentication. 3) jquery.cookie.js provides operations for managing cookies. A RESTful client needs the authentication information in each request to gain the stateless feature; however, it is not an efficient system as the user has to type a username and password per request. Rather, the first time the user is authenticated, the information is stored in a cookie Client content units The layout of the client is the same as the JSF pages. Figure 29 gives an example of a page with two DataIndexUnits. The banner displays the title of the page; the navigation bar displays the sub-pages of this page. JavaScript controls the main content. Figure 28 shows the JET template of generating a DataIndexUnit. By Qinan Lai 59

61 Figure 28 jquery JET template file Figure 29 RESTful client: DataIndexUnit The DataIndexUnit can also generate a delete and a modify link, similar to the JSF version. In Figure 29, there are two units, one with a delete link and one without. Figure 30 shows a unit with both modifying and deleting actions. By Qinan Lai 60

62 Figure 30 DataIndexUnit with modify and delete action Figure 31 shows an example of UpdateUnit. When a ModifyAction link is clicked in Figure 30, the user will be taken to this page. Figure 32 shows two CreateUnits. Figure 31 RESTful client: UpdateUnit By Qinan Lai 61

63 Figure 32 RESTful client: CreateUnit These content units are all developed with a simple logic. If the unit aims to show the user something, it retrieves the XML document via RESTful service provided by the server, and translates the document to a HTML table. If the unit aims to send some information to the server, the program use the input from the HTML page to make an XML document, and makes an HTTP request with the document. If the basic authentication option is enabled in GlobalSecuritySetting model, when a request requires restricted resource, a dialog will appear to ask authentication information. Figure 33 shows the basic authentication dialog generated in a browser. Figure 33 Basic authentication for RESTful client 4.3 Securing the generated website This section introduces the generation of Spring Security Configuration file, and the By Qinan Lai 62

64 development of new content units of WebGen. Integrating Security and RESTful Services into Model-based Generic Website Tooling The spring security configuration file Spring Security uses its own namespace element to work as a supplement of Spring Framework. It has additional XML schema to configure the security setting of the website. The security architecture of the generated website is based on Spring Security; therefore, the models that define the security settings are used to generate the configuration file application-security.xml. Firstly, the syntax of Spring Security configuration file must be understood. The first element of the XML document that needs to be considered is <http>element. It defines the authorisation rules i.e. who can access a page or an URL; and other issues in the presentation layer, such as whether to use the Remember me checkbox on the login page. The <http> element would contain several <intercept-url> elements. It defines a rule of authorisation. A typical element looks like this: <intercept-url pattern="/index.xhtml" method= GET access="hasrole('role_super')"/> The pattern attribute specifies the subject of the rule. It can be a simple file path, or a path with wildcard i.e. /css/*, or a regular expression[43] for more complex scenarios. The method attribute states the request of the rule. It is extremely useful when defining the authorisation rules for RESTful resources. The access attribute defines the object of the rule. The content is a Spring EL expression[44]. If the expression evaluates to false, the request will be denied, the user will be redirected to a login page or receive an access denied status code if basic authentication is applied. In Chapter 3, we have seen that the SecuritySettings model in PIM is an enumeration type, and after the M2M transformation, it is transformed to a relevant built-in function in Spring EL expression. If the user wants to use other functions, he can change the value directly in PSM and affect the result. By Qinan Lai 63

65 When authentication fails, the browser redirects to the login page. And when authorisation fails? The project provides a simple solution: return status code 403 forbidden. The attributes in GlobalSecuritySetting PSM are used to generate other configurations in the <http> element. <form-login /> element indicates the use of a login form. The path of the login form should be specified, otherwise, a default page will be generated. <http-basic/> states whether to use basic authentication. Basic authentication stores the username and password in the head of the request. In this project, it is required in the RESTful client. Because a RESTful service is stateless, a request does not require the previous state of the requests. A RESTful client usually sends the authentication message in every request. Another point to which the user should pay attention is that basic authentication must be generated if the user wants to use RESTful client. Otherwise, the server cannot identify whether the request is from a browser or a RESTful client; the denied access will be redirected to the login page, and the RESTful client will receive a pile of HTML code, which is meaningless. <remember-me /> element specifies to use the Remember me function on the login page. If the Remember me checkbox is not checked during login, the dialog is session-scope; either closing the browser or waiting for timeout will cause the user to login a second time. If it is checked, the username and password are encrypted as a cookie, so on a subsequent occasion, the user does not need to login. <openid-login/> specifies to use open-id as an authentication provider. It is a little tricky because other authentication providers (Database, LDAP) are configured in the <authentication-provider> element. The reason for this is that open-id cannot perform as a complete authentication and authorisation provider. The Open-ID provider [45] only providers authentication service, it only proves the user can provide the correct username and password; however, the role of the user has to be stored in the local database. The solution is that when the user uses open-id to login for the first time, the system updates the authority table, adding default supply information to enable the authorisation: <logout/> element indicates the URL when logout is successful. By Qinan Lai 64

66 The other significant element of the configuration file is that <authentication-manager>, DatabaseProvider and LdapProvider in the PSM are transformed to syntax in this element. To use JDBC as an authentication provider, two particular tables must be created in the database: The USER S table stores the username, password and if the user is active the AUTHORITIES table stores the username and its roles. To create the tables, the new version of WebGen generates two additional entity objects in the domain package, so that the existing ORM framework generates the tables. The LdapProvider is mapped to the <ldap-server> element. Spring Security provides an in-memory LDAP server (which is developed by using ApachDS [46]). It can quickly start a LDAP server for test purposes Development of Content Units Figure 34 shows a screenshot of a login page. Depending on the value of the GlobalSecuritySetting model, the system will generate the right content. Figure 35 illustrates a login page with open-id login and the Remember me option. Figure 36 shows that when the user uses open-id to login, the browser redirects to an open-id provider page. Figure 34 Login page with minimised features. By Qinan Lai 65

67 Figure 35 Login page with all features Figure 36 Open-ID login Logout unit A logout unit locates in the right corner of a JSF page. When the current user is not an authenticated user, it shows a login button and welcome message, as in Figure 37. When the user logs in, the Logout unit displays the username and a logout link. It is shown in Figure 38. The interaction code in a JSF page is placed in a managed-bean class. The JET template By Qinan Lai 66

68 of the class is modified to support the login/logout logic generation. Figure 37 Logout unit (not logged-in) Profile page Figure 38 Logout unit (login user) The possible options in the AccessOptions model are used to generate a Spring EL expression in the configuration file, except for the UserProfile option. Although Spring Security supports that only one particular user has the right to access a page, it is not a very useful approach. In reality, a profile page is a page that shows different information depending on the current user, rather than generating a standalone page for each user. So, for implementing a profile page, an alternative approach is applied. There is only one content unit in the existing WebGen presentation model DataIndexUnit. A profile page can be achieved if this unit has the ability to display records that are associated with a user. The source entity of the data unit must have an attribute called By Qinan Lai 67

69 username. The attribute states who creates this record. The enhanced code generation of DataIndexUnit will detect whether the page is a profile page, and display the right contents. The detail unit only displays one particular record of an entity and depends on the current user. It can be used to show information associated with a user, such as the user s detail information. Similarly, in relation to the DataIndexUnit, the source of the unit must have a username attribute that creates a relationship to the user entity. Figure 39 and Figure 40 provide examples of profile pages. They contain a detail unit and a DataIndexUnit. By comparing the two figures, you can see that the unit displays different results when different users login. Figure 39 Profile page 1 Figure 40 Profile page 2 Register Unit As the name suggests, a Register Unit enables the creation of a new user. This unit is available to use only if one of the authentication providers is a database; as an LDAP server is usually managed by another server, a self-registration process is meaningless for such scenario. By Qinan Lai 68

70 The users details are stored in two different parts. The username, password and authority are stored in the users and authorities tables according to the requirements of Spring Security; however, a website usually requires other information from the user, such as an address. This is stored as the source entity of the Register Unit. Therefore, the business logic of a Register Unit includes two parts. Firstly, when the user submits the form, the users and authorities table is updated, and then the source entity is updated. To act as a source unit of a Register Unit, the entity must have a username attribute. 4.4 Summary Figure 41 Register unit This chapter demonstrates the implementation of code generation through a range of system screenshots. The issues with M2T transformation and some concerns of implementation detail have been discussed. The discussion focused on describing the logic of the program and the concern when developing it to avoid too much detail in the code. By Qinan Lai 69

71 5 Testing and Results Testing is an important part of software development. Especially in an agile model, testing is iterated in each development period to ensure the quality of the delivered software. In addition, Spring Framework encourages the developer to use a test-driven development approach, which suggests writing the test case before writing the code. In a model-driven world, various automatic test approaches are used. One possible way of achieving an automatic test is to develop a test framework that enables automatic model generation and validation of the model [47]. However, this will take a great deal of time and effort in developing test tools and learning how to achieve this aim and there would be insufficient time to generate a unit test for each of the classes. In addition, some parts of the website are not appropriate to be tested automatically. Consequently, the test approach of this project is to generate an automatic test script for the RESTful service, and the other parts are mostly checked manually. Although the test method is largely informal, the developer writes a comprehensive test case to maintain the quality of the software. 5.1 RESTful Service test The server side RESTful service is tested by generating unit test cases. The RESTClient test library is used to simplify the work of code generation. The aim of the unit tests is to assess whether the RESTful service can successfully deal with the test request, send an appropriate proper response back, and that the data is correctly manipulated in the database. Functions for testing response code are provided by RESTClient, and the relevant service class is injected into the test class, so the test class can directly access the database and check the result. As explained earlier, a RESTful resource has two different URLs. One is resourcename/{id when it receives GET, PUT, and DELETE requests. The other is By Qinan Lai 70

72 resourcenames, it receives GET and POST requests. So five test functions are generated for one RESTResource model. The titles of each test case, and how each works, are listed in Table 5. Test case Comment testresourcespost An XML document is created, and posted to the server. Then the status code is checked. If it is created then check whether a new record is added to the database. testresourcesget testresourceget Test if the status code is OK Make a GET request to the resource newly created in the POST request, and check the received XML document to see if it is the same as the original. testresourceput Change the first element of the test XML document to the original text+ modified. Make a PUT request with the received XML document, and check whether the data is modified in database. testresourcedelete Make a DELETE request to the resource just created, and see if the data is deleted in database. Table 5 Test cases for RESTful service Although the test cases are generated, the effect of the test depends on the complexity of the website model. In other words, it can only test a predefined model; if the model is simple, errors might not surface or be ignored. To avoid that, the project uses a test model that contains all possible associations that can be defined by WebGen, which contains 72 entities. This test was passed successfully. 5.2 Integrating test The RESTful service is tested by generating test script. The other parts of the system are tested by writing a model and testing the generated website. The testing activity in this project will include two stages. By Qinan Lai 71

73 The first is to test if the contents of every generated artefact are the same as expected. When one feature is implemented, several small test models will be written and generated. The result will be checked manually by reading the code and deploying it to a web server to see the result. This stage will be combined with the implementing process. Because this project is developed by using an agile method approach, new small features are developed and tested in the same process. The second is to test the functionality of the completely generated website. A complete website model is constructed and the generated website is deployed to a web server. The RESTful functionality and security functionality will be checked by manually executing the request Testing Model The testing model aims to generate a website for a building maintenance system. The user can login, add/modify/delete a problem from/to the system, and specify the location. Meanwhile, the administrator of the system can view and modify all the problems listed by users. The administrator can also manage the location system. The test case is inspired by a similar web application, which can be found in the Building Maintenance of the University of Manchester [48]. The test case will show how the website models can capture the concepts of a real website and how the system generates the website. The website model is defined in the GUI editor in Figure 42. It contains three Entity models: a) UserDetail: It stores the information of the user. B) Problem: It defines the reported problem. There is a one-to-one reference to UniversityLocation which specifies the information of a location. There are five Page Models in the website model. The index page has two units: a detail unit and a DataIndexUnit. The detail unit shows the information of the current user, and the DataIndexUnit displays the problems created by the current user. There are By Qinan Lai 72

74 also a create page and a modify page that enables the user to report a new problem or modify an existed problem. There is a link to a manager page in the index page. The manager page displays all the instances of problems no matter who created them. After the defining models in the GUI editor, the next step is to add details to the website model editor, which is shown in Figure 43. Figure 42 Test case: GUI editor By Qinan Lai 73

75 Figure 43 Test case: website model editor In the model editor, the relevant authentication provider, public RESTful service, and security setting models are added. From the Properties window, the access right for each page is selected (see Figure 44). The details of access property for each page can be found in Table 6. Figure 44 Test case: access property Page Access Roles index UserProfile By Qinan Lai 74

76 createproblem updateproblem Integrating Security and RESTful Services into Model-based Generic Website Tooling Authenticated User Authenticated User manager ParticularRoles ROLE_SUPER createlocation ParticularRoles ROLE_SUPER updatelocation ParticularRoles ROLE_SUPER Table 6 Test case: security settings A RESTful service of University location is also created. In this simple website, such a service is not a necessary; the aim in the table is simply to demonstrate the creation of RESTful Service. After defining the website PIM, the M2M transformation can be carried out. Figure 45 provides a screenshot of the created PSM from the defined PIM. By Qinan Lai 75

77 Figure 45 Test case: GenJSM PSM editor After M2M transformation, global security can be defined as shown in Figure 46. After the relevant modification of PSM, the code can be generated. By Qinan Lai 76

78 Figure 46 Test case: GloalSecuritySetting Test results Figure 47 shows the generated project. The M2T transformation runs smoothly and the code is compiled correctly. No errors have been found. Figure 47 Test case: generated workspace By Qinan Lai 77

79 The website is deployed to a Tomcat v7.0 server [49], with a MySQL [50] database service running in the local host. Then the functionalities within each page are tested manually. The index page is a profile page, so when a user accesses the page for the first time, he is redirected to the login page (see Figure 35 Login page with all features). After the user logins, the index page can be accessed. The index page shows the appropriate content, even if there are already some records in the database. A screen shot can be found in Figure 48. The functionality of create, modify and delete works correctly. Figure 48 Test case: index.xhtml Figure 49 Test case: createproblem.xhtml The manager.xhtml page is restricted; only a user with a ROLE_SUPER authority can access this page. In this case, a normal user will receive an error (see Figure 50) if he/she tries to access the page. By Qinan Lai 78

80 Figure 50 Test case: 403 error The create and update pages for university locations also function correctly. Figure 51, Figure 52, and Figure 53 provide screenshots for those pages. Figure 51 Test case: manager.xhtml Figure 52 Test case: createlocate.xhtml By Qinan Lai 79

81 Figure 53 Test case: delete a problem The REST client is also correctly generated. Figure 54 shows the location management page. The create and modify page looks the same as the JSF version, so the screenshot is omitted. 5.3 Summary Figure 54 Client page: index.html This chapter describes issues around testing. A combination of automatic testing and manually testing is applied. Firstly, the design of unit tests for RESTful service is discussed, and the test model for unit test is introduced. Then an integrating test is used by generating a simple website, and the result is evaluated. By Qinan Lai 80