Integrating Security and RESTful Services into Model-based Generic Website Tooling · 2010-12-08 · Integrating Security and RESTful Services into Model-based Generic Website Tooling

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

Integrating Security and RESTful Services into Model-based Generic Website Tooling

By Qinan Lai 1

LIST OF CONTENTS

LIST OF CONTENTS ..............................................................................................1 LIST OF FIGURES...................................................................................................3 LIST OF TABLES.....................................................................................................5 ABSTRACT..............................................................................................................6 DECLARATION.......................................................................................................7 COPYRIGHT STATEMENT....................................................................................7

ACKNOWLEDGMENT...........................................................................................8

1 Introduction.........................................................................................................9 1.1 Overview ..................................................................................................9

1.2 Structure of the dissertation....................................................................13

2 Background .......................................................................................................14 2.1 Data Intensive Websites..........................................................................14

2.1.1 Spring Framework .........................................................................15

2.1.2 Hibernate .......................................................................................16

2.1.3 Java Server Faces...........................................................................18

2.1.4 Spring Security ..............................................................................21

2.2 Model Driven Software Development....................................................22

2.2.1 Meta-model....................................................................................22

2.2.2 Eclipse Modeling Project...............................................................24

2.2.3 Model-driven work flow................................................................25

2.3 Models and model driven workflow in WebGen....................................28 2.3.1 Website PIM ..................................................................................28

2.3.2 Model driven workflow .................................................................32

2.4 RESTful web service ..............................................................................34

2.4.1 REST and SOAP ...........................................................................34

2.4.2 Jersey Project .................................................................................37

2.5 Summary.................................................................................................37

3 Model and Website Design ...............................................................................38

3.1 Server side of RESTful service ..............................................................38

3.1.1 Website model and JSF model.......................................................38

3.1.2 GenJSF model................................................................................40

3.2 Client side of RESTful service ...............................................................42

3.3 Security Model .......................................................................................44

3.3.1 Security settings.............................................................................44

3.3.2 Global security model....................................................................46

3.3.3 Presentation layer ..........................................................................48

3.4 Altered models........................................................................................48

3.5 Design of Website...................................................................................50

3.6 Summary.................................................................................................52

4 Implementation of code generation...................................................................54

4.1 Server side RESTful service generation.................................................54


By Qinan Lai 2

4.1.1 Main class ......................................................................................54

4.1.2 Change of web.xml........................................................................57

4.2 Generating a RESTful webpage client ...................................................58

4.2.1 Client architecture..........................................................................58

4.2.2 Client content units........................................................................59

4.3 Securing the generated website ..............................................................62

4.3.1 The spring security configuration file ...........................................63

4.3.2 Development of Content Units ......................................................65

4.4 Summary.................................................................................................69

5 Testing and Results ...........................................................................................70 5.1 RESTful Service test ..............................................................................70

5.2 Integrating test ........................................................................................71

5.2.1 Testing Model ................................................................................72

5.2.2 Test results .....................................................................................77

5.3 Summary.................................................................................................80

6 Conclusion ........................................................................................................81 6.1 Achievements .........................................................................................81

6.2 Limitations and Further development.....................................................81

7 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...........................................101

The final word count: Body of the dissertation - 14505 Complete dissertation - 18289


By Qinan Lai 3

LIST OF FIGURES

Figure 1 Model editor.............................................................................................. 11 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. .....................................................65

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 1..........................................................................................68 Figure 40 Profile page 2..........................................................................................68 Figure 41 Register unit............................................................................................69


By Qinan Lai 4

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 5

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 6

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 7

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 8

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 9

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 2006. 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 10

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 11

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 12

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 13

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 14

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 15

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.

2.1.1 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 16

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.

2.1.2 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 17

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

Hibernate

Database

Data Access Object

Hibernate propertiesXML/annotation

mapping

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 18

integrate Hibernate.

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

2.1.3 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 19

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 20

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 21

Persistence object

Service object

Backing bean JSP file

Converter

Validator

User

Information flow

Use

Interact

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.

2.1.4 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 22

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.

2.2.1 Meta-model

To create a model requires a notation in which the model can be described; also, to


By Qinan Lai 23

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 24

2.2.2 Eclipse Modeling Project

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 25

2.2.3 Model-driven work flow

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 26

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 27

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 28

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.

2.3.1 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 29

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 30

Figure 12 Hierarchical structure of persistence model [9]

Presentation Model

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 31

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 32

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.

2.3.2 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 33

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 34

Figure 14 Model transformation workflow

2.4 RESTful web service

This section gives a short introduction of the RESTful web service and the Jersey

project.

2.4.1 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 35

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="http://www.w3.org/2001/1 2/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap- encoding">

<soap:body pb="http://www.example.com/entity">

<pb:GetEntity>

<pb:EntityID>12345</pb:EntityID>

</pb:GetEntityDetails>

</soap:Body>

</soap:Envelope>

A RESTful request looks like this:

GET http://www.example.com/resource/entity/12345

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

http://example.com/getResource?id=001, use http://example.com/resource/001 instead.

Table 1 shows how HTTP verbs are used for implementing a web service.


By Qinan Lai 36

Resource Collection URI, such as

http://example.com/resources/

Element URI, such as

http://example.com/resources/http://example.com/resources/http://example.com/resources/http://example.com/resources/32323232

141/141/141/141/

GET

List the elements of the

collection, complete with their

member URIs for further

navigation. For example, list all

the resource information.

Retrieve a representation of the

addressed member of the

collection expressed in an

appropriate MIME type

PUT

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.

Update the addressed member of

the collection or create it with the

specified ID.

POST

Create a new entry in the

collection where the ID is

assigned automatically by the

collection. The ID created is

usually

Treats the addressed member as a

collection in its own right and

creates a new subordinate of it.

DELETE Meaning defined as "delete

the entire collection".

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 37

development. In comparison, the RESTful framework is relatively young and as yet

lacks support for commercial application.

2.4.2 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 requests. @ Path annotation specifies the URL

of the resource. @GET specifies what method this function should request. Then the

function finds the requested object and returns the response.

@Path( "/resource/{id}" )

@GET

public TestEntity1 getTestEntity1( @PathParam( "id" ) long id){

TestEntity1 result = testEntity1Service.fin dTestEntity1(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 38

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.

3.1.1 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 39

WebGenModel

RESTResource

-name

NamedElement

Entity

-resources

1

*

-source

11

-entities

1

*

Classifier

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 40

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.

3.1.2 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 41

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 42

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 43

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 44

3.3 Security Model

This section demonstrates the configuration model for security and modifications for

other models to enable security options.

3.3.1 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 45

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 Explanation

PermitAll 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 46

Figure 18 Security PSM

3.3.2 Global security model

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 47

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

WebsiteProperties AuthenticationProvider

DatabaseProvider LdapProvider OpenidProvider

+websiteProperty11

+authenticationProviders

1 *

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)1CreateRememberMe 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 48

user logs out.

3.3.3 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 Page+pages

1 *

ContentUnit

LoginUnit LogoutUnit RegistrationUnit DetailsUnit

+units0..1

*

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 49

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 .

+siteTitle

+projectName

+testProjectName

WebsiteProperties

AuthenticationProvider

DatabaseProvider

LdapProvider

OpenidProvider

+authenticationProviders

1

*

WebGenModel

+title

+navigationLabel

Page

+pages1

*

+purposeSummary

+header

+footer

+headerClass

+captionClass

+controlClass

+footerClass

+errorClass

ContentUnit

LoginUnit

LogoutUnit RegistrationUnit

+units

0..1

*

-rolesList

SecuritySetting

+PermitAll

+AuthenticatedUser

+ParticularRoles

+UserProfile

<<enumeration>>

AccessOptions

RESTResource

+access

1 1

+securitySetting1

1

+securitySetting

1

1

+clearFieldsOnConfirm

+clearFieldsOnCancel

+layoutClass

+columnClasses

EditUnit

PageLink

CreateUnit

UpdateUnit

DataUnit

+header

+footer

+headerClass

+footerClass

Action

+confirmMessage

DeleteAction

IndexUnitDetailsUnit

SelectAction

-websiteProperties

11 +resources

1

*

+targetPage

1

1 +childPages1

*

+confirmAction

1

1

+cancelAction 1

1

+actions

1

*

Figure 21 New Presentation PIM


By Qinan Lai 50

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 51

and despatches a response.

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.

JSF page

RESTful service

Website

backend

Spring

Security

User

Request

Grant or Deny

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 52

shows the username and a logout button, so it is placed in the banner, as in Figure 26

The login page

Login

Or, if you have an Open-ID

account(optional)

name

*****

Text

Title of Login page

Footer

Username

Password

Login

Login

Remember me

Figure 25 Login page design

Content page

page

Footer

Navigation

Parent page

Child page

LogoutHello Username! |

Content Units

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 53

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 54

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.

4.1.1 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 55

Operation Request/Response data Success

code

Fail code

getResource(int

id)

The response is the entity

instance with the provided id

200 OK 404 Not found

getResources() A List contains all instances

of the resource

200 OK 404 Not found

postResource(object) The request must contain an

XML serialised entity data.

The <id> element can be

omitted. If the create

operation succeeds, the

created object will be

returned

201 Created 400 Bad request

putResource(int id) The request must contain an

XML serialised entity data.

202 Accept 304 Not

Modified

deleteResource(int

id)

Only a status code presents

the status of the request will

be sent back

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 56

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>



</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 57

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 http://server/rest/objects?start=10&size=20

The response will return 20 records from the 10th of the records.

4.1.2 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.ser vlet.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 58

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.

4.2.1 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 59

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.

4.2.2 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 60

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 61

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 31 RESTful client: UpdateUnit

Figure 32 shows two CreateUnits .


By Qinan Lai 62

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 63

development of new content units of WebGen.

4.3.1 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 64

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 65

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.

4.3.2 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 66

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 67

of the class is modified to support the login/logout logic generation.

Figure 37 Logout unit (not logged-in)

Figure 38 Logout unit (login user)

Profile page

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 68

“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 69

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 email 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.

Figure 41 Register unit

4.4 Summary

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 70

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 71

“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 Test if the status code is “OK”

testResourceGET 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 72

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.

5.2.1 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 73

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 74

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 75

createProblem Authenticated User

updateProblem 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 76

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 77

Figure 46 Test case: GloalSecuritySetting

5.2.2 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 78

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 79

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 80

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.

Figure 54 Client page: index.html

5.3 Summary

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 81

6 Conclusion

This chapter gives an overview of the successes of the project. Its limitations are

analysed and further work for improvement suggested.

6.1 Achievements

This project proposes RESTful services and security models to WebGen software for

implementing code generation for RESTful services and a secured website. The

RESTful service model can capture normal concepts in a RESTful service. With the

different abstraction level models (PIM and PSM), a RESTful service can be modelled.

The generation of RESTful service is sufficiently tested and the RESTful client is

successfully generated. It functions correctly and all CRUD functions are tested.

The proposed security model can properly capture the concepts in a role-based

authentication system. The PSM can express relevant information for Spring Security

for the creation of a secured website. The model transformation works; M2M andM2T

transformation are executed without flaws and the generated website can immediately

work immediately without any further modification.

To summarise the project: it successfully achieved all proposed work in the background

report. Considering the limited time, and the steep learning curve experienced by the

author of this project, it is a significant achievement.

6.2 Limitations and Further development

Due to the limited time and knowledge of the author, the project is not perfect. Some

issues were not resolved in terms of the level of customised configuration, and the

features of this project can be thus extended in the future.


By Qinan Lai 82

Some parts of the model should enable a higher level of customised configuration, for

instance, the RESTful client should enable the user to customise the content units

instead of using the same units as the JSF implementation. The security model should

also enable the user to use a customised entity to act as a user and authority table.

Extending the project in these ways will make it more usable.

Users might also expect other features. Currently, the tool does not support a profile

security option for RESTful service, and the authentication provider options are limited.

Only the database and open-id were fully tested as authentication providers. LDAP only

works in the in-memory server of Spring Security; with more time and effort, it can be

made to be compatible with other LDAP servers.

The project can generate scenarios for basic authentication. However, basic

authentication is considered to be insecure if SSL/TLS is not applied. Therefore, the

application of an SSL connection for the website would enhance it considerably.

The project is currently built by Ant. Due to the complex dependency of other libraries

(74 library files from Spring Project, JSF project, apache project and open-id project), a

new project organisation software, such as Maven [50], will help to manage such

dependencies and to organise different versions of library files.


By Qinan Lai 83

7 References

[1] Netcraft.Ltd. "March 2010 Web Server Survey," 2010.04.02; http://news.netcraft.com/archives/2010/03/17/march_2010_web_server_survey.html.

[2] D. Hansson. "Ruby on Rails," 2010.08.28; http://rubyonrails.org/. [3] Y. Matsumoto. "Ruby programming language," 2010.08.28;

http://www.ruby-lang.org/en/. [4] Sun Microsystems, "Model-View-Controller,"

http://www.oracle.com/technetwork/java/mvc-140477.html, 2002]. [5] S. Holzner, Beginning Ruby on Rails, Indianapolis, Ind.: Wrox ;

[Chichester : John Wiley distributor], 2007. [6] Zend Technologies Ltd. "Zend Framework,"

http://framework.zend.com/; http://framework.zend.com/. [7] Zend Technologies Ltd. "Programmer's Reference Guide," 2010.08.28;

http://framework.zend.com/manual/en/introduction.overview.html. [8] S. Beydeda, M. Book, V. Gruhn et al., "Model-driven software

development," Springer, 2005, pp. xii, 464 p. [9] M. Wood, “Enabling the Generation of Websites from Models,”

School of Computer Science, The University of Manchester, Manchester, 2009. [10] The Eclipse Foundation. "Eclipse Modeling Framework Project

(EMF)," 2010.04.02; http://www.eclipse.org/modeling/emf/?project=emf. [11] G. Murray. "Asynchronous JavaScript Technology and XML (Ajax)

With the Java Platform "; http://www.oracle.com/technetwork/articles/javaee/ajax-135201.html.

[12] Yahoo! Inc. "YAHOO! developer network," http://developer.yahoo.com/.

[13] W3C. "Latest SOAP versions," http://www.w3.org/TR/soap/. [14] R. T. Fielding, “Architectural Styles and the Design of Network-based

Software Architectures,” Information and Computer Science, UNIVERSITY OF CALIFORNIA, IRVINE, 2000.

[15] springsource.org. "1. Introduction to Spring Framework," 2010.04.05; http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/overview.html.

[16] J. Machacek, J. Ditt, A. Vukotic et al., Pro Spring 2.5, Berkeley, CA: Apress, 2008.

[17] C. Richardson, POJOs in action : developing enterprise applications with lightweight frameworks, Greenwich, Conn.: Manning ; [London : Pearson Education, distributor], 2006.

[18] AllAppLabs.com. "HIBERNATE - Overview of Hibernate," 2010.04.06; http://www.allapplabs.com/hibernate/overview_of_hibernate.htm.

[19] Oracle Corporation. "JavaServer Faces Technology," 2010.04.17; http://java.sun.com/javaee/javaserverfaces/.

[20] D. M. Geary, and C. S. Horstmann, Core JavaServer faces, 2nd ed.,


By Qinan Lai 84

Upper Saddle River, NJ: Prentice Hall, 2007. [21] springsource.org. "Welcome to the Spring Security Website,"

2010.04.06; http://static.springsource.org/spring-security/site/index.html. [22] springsource.org. "Spring Security – Main Features," 2010.04.06;

http://static.springsource.org/spring-security/site/features.html. [23] Open ID foundation. "Open ID foundation website," 2010.08.10;

http://openid.net/. [24] Object Management Group. "Object Management Group," 2010.07.05;

http://www.omg.org/. [25] Object Management Group. "OMG Model Driven Architecture "

2010.08.03; http://www.omg.org/mda/. [26] Object Management Group. "OMG's MetaObject Facility," 2010.08.05;

http://www.omg.org/mof/. [27] The Eclipse Foundation. "ATL - a model transformation technology,"

2010.08.05; http://www.eclipse.org/atl/. [28] The Eclipse Foundation. "Model To Text (M2T)," 2010.08.05;

http://www.eclipse.org/modeling/m2t/?project=jet. [29] A. Carpenter. " Model-Driven Software Development - Emfatic

(School of Computer Science - The University of Manchester) " 2010.04.12; http://www.cs.man.ac.uk/~andy/sectionShow.php?id=29.

[30] A. G. Kleppe, J. B. Warmer, and W. Bast, MDA explained : the model driven architecture : practice and promise, Boston ; London: Addison-Wesley, 2003.

[31] Wikipedia. "ATLAS Transformation Language," 2010.04.18; http://en.wikipedia.org/wiki/ATLAS_Transformation_Language.

[32] JBoss Community. "Hibernate:Relational Persistence for Java and .NET," 2010.08.06; http://www.hibernate.org/.

[33] M. Elkstein. "Learn REST: A Tutorial," 2010.04.22; http://rest.elkstein.org/.

[34] Sun Microsystems. "JSR 311: JAX-RS: The JavaTM API for RESTful Web Services," 2010.08.10.

[35] java.net. "the JAXB Reference Implementation Project. ," 2010.08.10; https://jaxb.dev.java.net/.

[36] Apache Software Foundation. "HTTP Client," 2010.08.10. [37] J. Community. "RESTEasy Project," 2010.08.10. [38] subwiz. "rest-client - Java application to test RESTful webservices. ,"

2010.08.10; http://code.google.com/p/rest-client/. [39] J. Chaffer, and K. Swedberg, Learning jQuery : better interaction

design and web development with simple JavaScript techniques, Birmingham: Packt, 2007.

[40] Yahoo! Inc. "YUI Library," 2010.08.10; http://developer.yahoo.com/yui/.

[41] W3C. "Document Object Model (DOM)," 2010.08.11; http://www.w3.org/DOM/.

[42] The Internet Society. "The Base16, Base32, and Base64 Data Encodings," 2010.08.11; http://tools.ietf.org/html/rfc4648.


By Qinan Lai 85

[43] The Open Group. "Regular Expressions," 2010.07.06; http://www.opengroup.org/onlinepubs/007908799/xbd/re.html.

[44] springsource.org. "Spring Expression Language (SpEL)," 2010.08.03; http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/expressions.html.

[45] OpenID Foundation. "Get an OpenID," 2010.08.15; http://openid.net/get-an-openid/.

[46] The Apache Software Foundation. "The Apache Directory Project," 2010.08.16; http://directory.apache.org/.

[47] I. Stürmer, and M. Conrad, “Code Generator Testing in Practice,” GI Jahrestagung, vol. 2, pp. 33-37, 2004.

[48] The University of Manchester. "Welcome to Building Maintenance," 2010.08.10; http://bm.stars.manchester.ac.uk/Terminal/Default.aspx.

[49] The Apache Software Foundation. "Apache Tomcat," 2010.08.17; http://tomcat.apache.org/.

[50] Oracle Corporation. "MySQL - The world's most popular open source database," 2010.08.10; http://www.mysql.com/?bydis_dis_index=1.


By Qinan Lai 86

Appendix A Website PIM Emfatic Implementation

@namespace(

prefix=website,

uri= "http://www.cs.man.ac.uk/mdsd/2010/Website" )

@Ecore(

validationDelegates= "http://www.eclipse.org/emf/2002/Ecore/OCL" ,

settingDelegates= "http://www.eclipse.org/emf/2002/Ecore/OCL" ,

invocationDelegates= "http://www.eclipse.org/emf/2002/Ecore/OCL" )

package website;

enum AccessOptions {

PermitAll; AuthenticatedUser; ParticularRoles; UserProfile; }

@Ecore(

constraints= "classifierNameUnique pageNameUnique" )

@OCL(

classifierNameUnique= "classifiers->isUnique(name)" ,

pageNameUnique= "pages->isUnique(name)" )

class WebGenModel {

val WebsiteProperties[ 1] websiteProperties;

val Classifier[*] classifiers;

val Service[*] services;

val Page[*] pages;

val Action[*] actions;

val RESTResource[*] resources;

}

class WebsiteProperties {

attr EString[ 1] siteTitle;

attr EString[ 1] projectName;

attr EString[ 1] testProjectName = "" ;

val AuthenticationProviders authenticationProviders;

attr EBoolean[ 1] useDefaultLoginPage = true;

}

@Ecore(

constraints=mustBeNamed)

@OCL(

mustBeNamed= "not name.oclIsUndefined() implies name.size() > 0" )

abstract class NamedElement {


By Qinan Lai 87

attr EString[ 1] name = "" ;

}

abstract class NamedDisplayElement extends NamedElement {

attr EString displayLabel = "" ;

}

abstract class Classifier extends NamedDisplayElement {

}

class DataType extends Classifier {

}

@Ecore(

constraints= "featureNameUniqueWithinEntity

displayOnlyLocalFeatures" )

@OCL(

featureNameUniqueWithinEntity= "features->isUnique(name)" ,

displayOnlyLocalFeatures= "features->union(associationEnds)->include

sAll(displayFeatures)" )

class Entity extends Classifier {

val Feature[*] features;

ref Association[*]#targetEntity associationEnds;

ref Service#encapsulates x;

ref Feature[*] displayFeatures;

attr EString displayFormat = "" ;

}

@Ecore(

constraints=cardinalityNaturalNumber)

@OCL(

cardinalityNaturalNumber= "cardinality >= 0" )

abstract class Feature extends NamedDisplayElement {

attr EInt[ 1] cardinality = 0;

attr EBoolean[ 1] ~unique = true;

attr EBoolean[ 1] ~ordered = false;

attr EString headerClass = "" ;

attr EString displayClass = "" ;

attr EString footerClass = "" ;

}

class Attribute extends Feature {

ref DataType[ 1] dataType;

attr EString[ 1] inputClass = inputAttribute;

}


By Qinan Lai 88

@Ecore(

constraints= "targetCardinalityNaturalNumber

bidirectionalAssocationsNeedsTargetFeatureName" )

@OCL(

targetCardinalityNaturalNumber= "targetCardinality >= 0" ,

bidirectionalAssocationsNeedsTargetFeatureName= "bidirectional

implies not targetFeatureName.oclIsUndefined() and

targetFeatureName.size() > 0" )

class Association extends Feature {

ref Entity[ 1]#associationEnds targetEntity;

attr EBooleanObject[ 1] bidirectional = false;

attr EInt[ 1] targetCardinality = 1;

attr EBooleanObject[ 1] targetUnique = false;

attr EString[ 1] inputClass = inputAssociation;

attr EString targetFeatureName = "" ;

attr EString targetDisplayLabel = "" ;

attr EString targetHeaderClass = "" ;

attr EString targetDisplayClass = "" ;

attr EString targetFooterClass = "" ;

}

@Ecore(

constraints=contentUnitNameUniqueWithinPage)

@OCL(

contentUnitNameUniqueWithinPage= "units->isUnique(name)" )

class Page extends NamedElement {

val PageLink parentPage;

ref PageLink[*]#targetPage childPages;

val ContentUnit[*] units;

val RawLink[*] hyperlinks;

attr EString title = "" ;

attr EString navigationLabel = "" ;

val SecuritySetting[ 1] securitySetting;

}

class PageLink {

ref Page[ 1]#childPages targetPage;

}

class Service extends NamedElement {

ref Entity[*]#x encapsulates;

}

abstract class SelectTarget {

}


By Qinan Lai 89

@Ecore(

constraints=includedFeaturesMustBeFromSource)

@OCL(

includedFeaturesMustBeFromSource= "includedFeatures->forAll(f |

source.features->includes(f.feature))" )

abstract class ContentUnit extends NamedDisplayElement {

ref Entity[ 1] source;

val IncludedFeature[*] includedFeatures;

attr EString purposeSummary = "" ;

attr EString header = "" ;

attr EString footer = "" ;

attr EString[ 1] headerClass = unitHeader;

attr EString[ 1] captionClass = unitCaption;

attr EString[ 1] controlClass = unitControl;

attr EString[ 1] footerClass = unitFooter;

attr EString[ 1] errorClass = error;

}

@Ecore(

constraints=cannotReduceRequirement)

@OCL(

cannotReduceRequirement= "feature.cardinality = 1 implies required" )

class IncludedFeature {

ref Attribute[ 1] feature;

attr EBoolean required;

attr EString displayLabel;

attr EString footer;

attr EString headerClass;

attr EString inputClass;

attr EString displayClass;

attr EString footerClass;

}

abstract class EditUnit extends ContentUnit {

ref Page confirmAction;

attr EBoolean clearFieldsOnConfirm;

ref Page cancelAction;

attr EBoolean clearFieldsOnCancel;

attr EString[ 1] layoutClass = inputForm;

attr EString[ 1] columnClasses = "labelColumn,valueColumn" ;

}

class CreateUnit extends EditUnit {

attr EString[ 1] styleClass = createUnit;

}


By Qinan Lai 90

class UpdateUnit extends EditUnit, SelectTarget {

attr EString[ 1] styleClass = updateUnit;

}

class DeleteUnit extends EditUnit, SelectTarget {

attr EString[ 1] styleClass = deleteUnit;

}

abstract class DataUnit extends ContentUnit {

val ContextualLink[*] contextualLinks;


}

class DetailsUnit extends DataUnit, SelectTarget {

attr EString[ 1] styleClass = readUnit;

attr EString[ 1] layoutClass = readLayout;

attr EString[ 1] columnClasses = "labelColumn,valueColumn" ;

}

class IndexUnit extends DataUnit {

attr EString[ 1] styleClass = indexUnit;

attr EString[ 1] layoutClass = indexLayout;

attr EString[ 1] rowClasses = "oddRow,evenRow" ;

attr EString[ 1] columnClasses = "oddColumn,evenColumn" ;

}

abstract class Action extends NamedDisplayElement {

attr EString header = "" ;

attr EString footer = "" ;

attr EString headerClass = "" ;

attr EString footerClass = "" ;

}

class SelectAction extends Action {

ref SelectTarget[ 1] target;

}

class DeleteAction extends Action {

ref Page destination;

attr EString confirmMessage = "" ;

}

abstract class Link extends NamedDisplayElement {

}

class RawLink extends Link {


By Qinan Lai 91

ref Page[ 1] destination;

attr EString[ 1] linkText;

attr EBoolean[ 1] clearFields;

}

class ContextualLink extends Link {


attr EString[ 1] action;

}

class RESTResource extends NamedElement{



}

class SecuritySetting {

attr AccessOptions[ 1] access;

attr EString[ 1] rolesList = "" ;

}

abstract class AuthenticationProvider{

}

class DatabaseProvider extends AuthenticationProvider{

}

class OpenidProvider extends AuthenticationProvider{

}

class LdapProvider extends AuthenticationProvider{

}

class AuthenticationProviders{

val AuthenticationProvider[*] authenticationProviders;

}

class LogoutUnit extends ContentUnit{

attr String[ 1] styleClass = logoutUnit;

attr String[ 1] layoutClass = logoutLayout;

attr String[ 1] columnClasses = "labelColumn,valueColumn" ;

}

class RegisterUnit extends ContentUnit{

attr String[ 1] styleClass = readUnit;

attr String[ 1] layoutClass = readLayout;

attr String[ 1] columnClasses = "labelColumn,valueColumn" ;


By Qinan Lai 92

}

Appendix B ORM Model Emfatic Implementation

@namespace(

prefix=orm,

uri= "http://www.cs.man.ac.uk/mdsd/2010/ObjectRelational Mapping" )

@Ecore(




package orm;

class OrmModel {

val PersistenceProperties[ 1] persistenceProperties;

val CollectionType[*] collectionTypes;

val DataType[*] dataTypes;

val Entity[*] entities;

}

class PersistenceProperties {

attr EString[ 1] projectName;

attr EString[ 1] testProjectName;

attr EString[ 1] databaseName;

}

abstract class NamedElement {

attr EString[ 1] name;

}

abstract class NamedDisplayElement extends NamedElement {

attr EString[ 1] displayLabel;

}

class Classifier extends NamedDisplayElement {

}

enum CollectionTypes {

Bag;

List;

OrderedSet;

Set;

}


By Qinan Lai 93

class CollectionType extends Classifier {

attr CollectionTypes collectionType;

ref Classifier[ 1] elementType;

attr EString[ 1] persistenceType;

attr EString[ 1] javaInterfaceType;

attr EString[ 1] javaImplementationType;

}

class DataType extends Classifier {

}

class Entity extends Classifier {

attr EString[ 1] keyName;

val Feature[*]#parentEntity features;

ref Association[*]#targetEntity associationEnds;

ref Feature[*] displayFeatures;

attr EString displayFormat;

}

abstract class Feature extends NamedDisplayElement {

ref Entity[ 1]#features parentEntity;

}

abstract class SingletonFeature extends Feature {

attr EBoolean required;

}

abstract class CollectionFeature extends Feature {

ref CollectionType[ 1] collectionType;

}

class ElementSingleton extends SingletonFeature {

ref DataType[ 1] dataType;

}

class ElementCollection extends CollectionFeature {

}

abstract class Association extends Feature {

ref Entity[ 1]#associationEnds targetEntity;

attr EBooleanObject[ 1] bidirectional;

attr EString targetFeatureName;

attr EString targetDisplayLabel;

attr EBooleanObject[ 1] targetUnique;

attr EString[ 1] inverseCollectionPersistenceType;


By Qinan Lai 94

attr EString[ 1] inverseCollectionJavaInterfaceType;

attr EString[ 1] inverseCollectionJavaImplementationType;

}

enum SingletonAssociationRelationships {

OneToOne;

ManyToOne;

}

class SingletonAssociation extends Association, SingletonFeature {

attr SingletonAssociationRelationships associationRelat ionship;

}

enum CollectionAssociationRelationships {

OneToMany;

ManyToMany;

}

@Ecore(

constraints=x)

@OCL(

x= "targetEntity = collectionType.elementType" )

class CollectionAssociation extends Association, CollectionFeature {

attr CollectionAssociationRelationships associationRela tionship;

}

Appendix C JSF model Emfatic Implementation

@namespace(

prefix=jsf,

uri= "http://www.cs.man.ac.uk/mdsd/2010/Jsf" )

@Ecore(




package jsf;

import "platform:/resource/uk.ac.man.cs.mdsd.orm.model/mod el/orm.emf" ;

enum AccessOptions {

PermitAll; AuthenticatedUser; ParticularRoles; UserProfile; }

class JsfModel {

attr EString[ 1] siteTitle;

ref OrmModel[ 1] persistence;


By Qinan Lai 95

val Service[*] services;

val Page[*] pages;

ref Page[*] topLevelPages;


val RESTResource[*] resources;

val GlobalSecurity[ 1] globalSecuritySetting;

}

class Service extends NamedElement {

ref Entity[+] entities;

val Property[*] daosUsed;

attr EString[ 1] beanId;

}

class Property extends NamedElement {

ref Classifier type;

}

abstract class SelectTarget {

ref SelectAction[*]#target targettingActions;

}

class Page extends NamedElement {

ref Page#childPages parentPage;

ref Page[*]#parentPage childPages;

val ContentUnit[*]#displayedOn units;

val RawLink[*] hyperlinks;

attr EString title;

attr EString[ 1] navigationLabel;

attr EString[ 1] propsId;


}

abstract class ContentUnit extends NamedDisplayElement {

ref Page[ 1]#units displayedOn;


ref Service[ 1] service;

attr EString[ 1] localBeanId;

attr EString[ 1] beanId;

val IncludedFeature[*] includedFeatures;

attr EString purposeSummary;

attr EString header;


attr EString[ 1] styleClass;

attr EString[ 1] headerClass;


By Qinan Lai 96

attr EString[ 1] captionClass;

attr EString[ 1] controlClass;

attr EString[ 1] footerClass;

attr EString[ 1] errorClass;

attr EString[ 1] layoutClass;

attr EString[ 1] columnClasses;

}

abstract class IncludedFeature {

ref Feature[ 1] feature;

attr EString[ 1] ~id;

attr EBoolean[ 1] required;

attr EString displayLabel;



attr EString inputClass;

attr EString displayClass;


}

class IncludedForwardFeature extends IncludedFeature {

attr EString optionProperty;

}

class IncludedInverseFeature extends IncludedFeature {

}

abstract class LinkableViaContext extends ContentUnit {

}

abstract class ModifyUnit extends ContentUnit {

val ConfirmAction[ 1] confirmAction;

attr EBoolean[ 1] clearFieldsOnConfirm;

val CancelAction[ 1] cancelAction;

attr EBoolean[ 1] clearFieldsOnCancel;

}

class CreateUnit extends ModifyUnit {

}

class EnhancedUpdateUnit extends ModifyUnit, SelectTarget {

ref Association[*] includedRelationships;

}

class DeleteUnit extends ModifyUnit, SelectTarget {

attr EString filter;


By Qinan Lai 97

}

abstract class ReadUnit extends ContentUnit {

val ContextualLink[*] contextualLinks;


}

class EnhancedDataUnit extends ReadUnit, SelectTarget {

}

class EnhancedDataIndexUnit extends ReadUnit {

attr EString[ 1] rowClasses;

}

abstract class Action extends NamedDisplayElement {

attr EString[ 1] actionId;


}

class ConfirmAction extends Action {

}

class CancelAction extends Action {

}

abstract class InlineAction {

attr EString header;




}

class SelectAction extends Action, InlineAction {

ref SelectTarget[ 1]#targettingActions target;

}

class DeleteAction extends Action, InlineAction {

attr EString[ 1] confirmMessage;

}

abstract class Link extends NamedDisplayElement {

}

class RawLink extends Link {


attr EString[ 1] linkText;


By Qinan Lai 98

attr EBoolean[ 1] clearFields;

}

class ContextualLink extends Link {

ref LinkableViaContext[ 1] destination;

attr EString[ 1] action;

}

class RESTResource extends NamedElement {



}

class SecuritySetting {

attr AccessOptions[ 1] access;

attr EString[ 1] rolesList;

}


}


}


}


}



}

class GlobalSecurity{


}

class LogoutUnit extends ContentUnit{

}

class RegisterUnit extends ContentUnit{

}


By Qinan Lai 99

Appendix D GenORM model Emfatic implementation

@namespace(

prefix=jsf,

uri= "http://www.cs.man.ac.uk/mdsd/2010/GenOrm" )

@Ecore(




package genorm;

import "platform:/resource/uk.ac.man.cs.mdsd.orm.model/mod el/orm.emf" ;

enum OrmTechnologies {

JPA2;

HBM;

}

class GenOrmModel {

ref OrmModel[ 1] ormModel;

val GenCollectionType[*] genCollectionTypes;

val GenDataType[*] genDataTypes;

val GenEntity[*] genEntities;

attr OrmTechnologies[ 1] ormTechnology = JPA2;

attr EString basePackage;

attr EString[ 1] domainPackage = domain;

attr EBooleanObject includeXmlBindingAnnotations;

attr EString[ 1] daoPackage = dao;

attr EString[ 1] daoImplPackage = "dao.hibernate" ;

attr EString[ 1] databaseName;

attr EString[ 1] databaseUsername;

attr EString[ 1] databasePassword;

}

class GenCollectionType {

ref CollectionType[ 1] ormCollectionType;

}

class GenDataType {

ref DataType[ 1] ormDataType;

attr EString[ 1] persistenceType;

}

class GenEntity {

ref Entity[ 1] ormEntity;


By Qinan Lai 100

attr EString[ 1] tableName;

val GenFeature[*] genFeatures;

attr EBooleanObject[ 1] xmlTransient;

attr EBooleanObject[ 1] xmlRootElement;

attr EString[ 1] xmlNamespace;

attr EString[ 1] xmlName;

}

abstract class GenFeature {

}

abstract class GenSingletonFeature extends GenFeature {

attr EString[ 1] columnName;

}

abstract class GenCollectionFeature extends GenFeature {

attr EString[ 1] tableName;

}

class GenElementSingleton extends GenSingletonFeature {

ref ElementSingleton[ 1] ormFeature;

ref GenDataType[ 1] genDataType;

}

class GenElementCollection extends GenCollectionFeature {

ref ElementCollection[ 1] ormFeature;

attr EString[ 1] columnName;

}

class GenSingletonAssociation extends GenSingletonFeature {

ref SingletonAssociation[ 1] ormFeature;

}

class GenCollectionAssociation extends GenCollectionFeature {

ref CollectionAssociation[ 1] ormFeature;

}

class GenBidirectionalAssociationEnd extends GenFeature {

ref Association[ 1] ormFeature;

}


By Qinan Lai 101

Appendix E GenJSF model Emfatic Implementation

@namespace(

prefix=jsf,

uri= "http://www.cs.man.ac.uk/mdsd/2010/GenJsf" )

@Ecore(




package genjsf;

import "platform:/resource/uk.ac.man.cs.mdsd.jsf.model/mod el/Jsf.emf" ;

import

"platform:/resource/uk.ac.man.cs.mdsd.genorm.model/ model/GenOrm.emf" ;

enum SelectOneofOptions {

Menu;

RadioHorizontal;

RadioVertical;

}

enum SelectManyOptions {

List;

CheckboxHorizontal;

CheckboxVertical;

}

enum InputMessagePlacementOptions {

FormHead;

FormFoot;

OnFeature;

FormHeadAndFoot;

FormAndOnFeature;

}

enum InputMessageDisplayOptions {

Short;

Description;

ToolTip;

}

enum CollectionDisplayFormat {

LineDirection;

PageDirection;


By Qinan Lai 102

}

class GenJsfModel extends GenOrmModel {

ref JsfModel[ 1] jsfModel;

val GenService[*] genServices;

val GenPage[*] genPages;

ref GenPage[*] genTopLevelPages;

val GenAction[*] genActions;

val GenRESTResource[*] genResources;

attr EString[ 1] backingPackage = backing;

attr EString[ 1] converterPackage = converter;

attr EString[ 1] validatorPackage = validator;

attr EString[ 1] servicePackage = service;

attr EString[ 1] uiPackage = ui;

attr EString[ 1] restPackage = rest;

attr EString[ 1] securityPackage = security;

val GlobalSecurity[ 1] globalSecuritySetting;

}

class GenJsfEntity extends GenEntity {

attr EString[ 1] daoId;

attr EString[ 1] backingId;

attr EString[ 1] propsId;

}

class GenJsfElementSingleton extends GenElementSingleton {

}

class GenJsfElementCollection extends GenElementCollection {

}

class GenJsfSingletonAssociation extends GenSingletonAssociation {

}

class GenJsfCollectionAssociation extends GenCollectionAssociation {

}

class GenService {

ref Service[ 1] jsfService;

}

class GenPage {

ref Page[ 1] jsfPage;

ref GenPage#genChildPages genParentPage;

ref GenPage[*]#genParentPage genChildPages;

val GenContentUnit[*] genUnits;


By Qinan Lai 103

val GenRawLink[*] genHyperlinks;

val GenSecuritySetting[ 1] genSecuritySetting;

}

abstract class GenContentUnit {

ref ContentUnit[ 1] jsfUnit;

ref GenJsfEntity[ 1] genSource;

val GenIncludedFeature[*] genIncludedFeatures;

}

abstract class GenIncludedFeature {

ref IncludedFeature[ 1] jsfIncludedFeature;

attr InputMessageDisplayOptions messageDisplayOption = ToolTip;

}

class GenIncludedElementSingleton extends GenIncludedFeature {

}

class GenIncludedElementCollection extends GenIncludedFeature {

attr CollectionDisplayFormat[ 1] displayOption = LineDirection;

}

class GenIncludedSingletonAssociation extends GenIncludedFeature {

attr SelectOneofOptions[ 1] selectOption = Menu;

}

class GenIncludedCollectionAssociation extends GenIncludedFeature {

attr CollectionDisplayFormat[ 1] displayOption = PageDirection;

attr SelectManyOptions[ 1] selectOption = List;

}

abstract class GenModifyUnit extends GenContentUnit {

attr InputMessagePlacementOptions[ 1] messagePlacementOption =

OnFeature;

attr InputMessageDisplayOptions[ 1] formMessageDisplayOption =

Description;

ref GenPage[ 1] genConfirmAction;

ref GenPage[ 1] genCancelAction;

}

class GenCreateUnit extends GenModifyUnit {

}

class GenEnhancedUpdateUnit extends GenModifyUnit {

}


By Qinan Lai 104

class GenDeleteUnit extends GenModifyUnit {

}

abstract class GenReadUnit extends GenContentUnit {

val GenContextualLink[*] genContextualLinks;

val GenAction[*] genActions;

}

class GenEnhancedDataUnit extends GenReadUnit {

}

class GenEnhancedDataIndexUnit extends GenReadUnit {

}

abstract class GenAction {

ref Action[ 1] jsfAction;

}

class GenSelectAction extends GenAction {

}

class GenDeleteAction extends GenAction {

}

abstract class GenLink {

}

class GenRawLink extends GenLink {

ref Page[ 1] genDestination;

}

class GenContextualLink extends GenLink {

}

class GenRESTResource {

ref RESTResource[ 1] resource;

val GenRESTRequest[*] requests;

}

class GenRESTRequest {

attr EString[ 1] path;

attr EString[ 1] method;

val GenSecuritySetting[ 1] genSecuritySetting;

}

class GenSecuritySetting {


By Qinan Lai 105

attr EString access;

}


}


}


}


attr EString server;

attr EString user;

attr EString group;

}



}

class GlobalSecurity{


attr EBoolean createBasicAuthentication;

attr EBoolean createRememberMe;

attr EString systemKey;

attr EString logoutSuccessUrl;

attr EString loginPage;

}

class GenLogoutUnit extends GenContentUnit{

}

class GenRegisterUnit extends GenContentUnit{

}

Documents

Integrating Security and RESTful Services into Model-based Generic Website Tooling · 2010-12-08 · Integrating Security and RESTful Services into Model-based Generic Website Tooling