Abstract: - This paper describes model driven development of dynamic web application ... ModelibraWicket is an application development framework. This web.
ADVANCES in DATA NETWORKS, COMMUNICATIONS, COMPUTERS
Frameworks for Model-Driven Development of Web Applications VENSADA OKANOVIĆ, DZENANA DONKO, TADEJ MATELJAN Computer Science Department University of Sarajevo Faculty of Electrical Engineering, Zmaja od Bosne bb, Sarajevo BOSNIA AND HERZEGOVINA
Abstract: - This paper describes model driven development of dynamic web application using a few different frameworks. Those are the following open source Java frameworks: Modelibra, ModelibraWicket and Wicket. Modelibra is a domain model framework. ModelibraWicket is an application development framework. This web framework uses Modelibra for domain models and Wicket for application views. The domain models are created by ModelibraModeler, design and code generation tool. ModelibraWicket interprets the application model and creates default web application. Web pages of the default web application are created from ModelibraWicket components. Those web components are based on the domain model. Key-Words: - application development, model, framework, web component
1 Introduction
2.1 Domain Model
A web application is a software framework that is designed to support the development of web applications. For creating web applications in Java there are many open source frameworks [1]. Some of them are action based frameworks, while others are component based frameworks. For example, Struts is very popular action based web application framework for Java development [2,3]. It relies more on external configuration files and less on Java code. Wicket is a web component based framework [4,5]. There are no configuration files and a web component is in the center of preoccupation of Wicket developers. A web application has two major parts: a domain model and views. Modelibra is a domain model framework [6]. It provides an easy support for domain models, which are usually used in web development. The domain models are created by ModelibraModeler, design and code generation tool [6]. ModelibraWicket is web component framework which creates more advanced web components from basic components provided by Wicket. It interprets the aplication model and creates default web application. This framework makes a domain model alive as a web application.
The backbone of any software is a domain model. A domain model is a representation of user concepts, concept properties and relationships between concepts. The easiest way to present a domain model is through a graphical representation. Figure 1. represents simple domain model of the web application.
2 Modelibra Modelibra is a domain model framework [6]. Its objective is to provide an easy to learn and easy to use framework. Modelibra has been designed to help developers of small applications in representing and using application domain models.
ISSN: 1792-6157
Figure 1. Graphical representation of a domain mode
The domain model is created by the ModelibraModeler design and code generation tool [6].
67
ISBN: 978-960-474-245-5
ADVANCES in DATA NETWORKS, COMMUNICATIONS, COMPUTERS
In this case, the domain model's concepts are: Student, Course and StudentCourse. A concept is described by its properties and neighbors. The Student concept has a indexNumber, a firstName and a lastName. The Student concept has one neighbor, the StudentCourse concept. In this simple example, the Course concept also has one neighbor, the StudentCourse concept. But, StudentCourse concept has two parents, Student and Course concepts. A relationship between two concepts is represented by two neighbor directions, displayed together as a line. A neighbor direction is a concept special (neighbor) property, with a name and a range of cardinalities. The Student -- > StudentCourse direction is named studentCourses; its minimal cardinality is 0 and its maximal cardinality is N (many). The StudentCourse -- > Student direction is named student; its minimal and maximal cardinality is 1. In summary, a concept is described by its properties and neighbors. A neighbor is either a child or a parent. A child neighbor has the maximum cardinality of N (or a number greater than 1). A parent neighbor has the maximum cardinality of 1. A concept is represented as a list of entities. The retrieval of entities starts with the entry concepts of the domain model. In the domain model represented on Figure 1, the entry concepts are Student and Course. They all have a darker border and the || symbol in the upper left corner of the concept. Once an entity of the entry concept is retrieved in the list of entities, the retrieval of neighbor entities may start. A child neighbor is represented as a list of entities. A parent neighbor is represented as a single entity. The StudentCourse concept is not an entry concept. As a non-entry the StudentCourse concept has a lighter border. Hence, entities of the StudentCourse concept may be reached only through its parent concept. Since StudentCourse concept has two parents, its entities may be retrieved either from the Student concept or the Course concept. A concept that has more than one parent is called an intersection concept. An intersection concept that represent a many-to-many relationship has the X sign in the upper right corner of the concept. Every concept has a predefined property called oid. The oid property is mandatory. It is used as an artificial concept identifier and is completely managed by Modelibra. Its value is unique universally. In addition, a concept may have at most one user oriented identifier (id) that consists of the concept's properties and/or neighbors. A simple id has only one property. In an entry concept, all entities must have a unique value for the concept id. However, in a non-entry child concept, the id is often unique only within the child parent. The ϕ symbol in front of a property name means that a property can't be null. And the o symbol in front of a property name means that a property can be null.
ISSN: 1792-6157
2.2 Java Classes A concept is represented in Modelibra as two Plain Old Java Object (POJO) classes. Both POJOs are specific to the domain. One extends the generic Entity class and the other extends the generic Entities class. Both generic classes are part of Modelibra and may be reused in different domains. For example, the Course concept has two specific classes: Course and Courses. The Course class describes the Course concept and the Courses class represents all courses. For the sake of space, only Course and StudentCourse concepts with their relationship will be considered in this example. The basic content of the domain model's specific classes may be generated by Modelibra. The Course class extends the abstract GenCourse class which extends the abstract Entity class passing Course class as a generic type parameter. It contains three properties and one child neighbor with the corresponding set and get methods. All properties are typed by Java classes. The class constructor passes the domain model to its inheritance parent. The internal neighbor is created in the class constructor. The neighbor set method sets the current object as the neighbor parent. public class Course extends GenCourse { public Course(IDomainModel model) { super(model); } } public abstract class GenCourse extends Entity { private String courseId; private String courseName; private String description; private StudentCourses studentCourses; public GenCourse(IDomainModel model) { super(model); setStudentCourses(new StudentCourses((Course) this)); } public void setCourseId(String courseId) { this.courseId = courseId; } public String getCourseId() { return courseId; } public void setCourseName(String courseName) { this.courseName = courseName; } public String getCourseName() {
68
ISBN: 978-960-474-245-5
ADVANCES in DATA NETWORKS, COMMUNICATIONS, COMPUTERS
return courseName;
return enrollmentDate;
}
}
public void setDescription(String description) { this.description = description; }
public void setStudentOid(Long studentOid) { this.studentOid = studentOid; student = null; }
public String getDescription() { return description; }
public Long getStudentOid() { return studentOid; }
public void setStudentCourses(StudentCourses studentCourses) { this.studentCourses = studentCourses; if (studentCourses != null) { studentCourses.setCourse((Course)this); } }
public void setCourse(Course course) { this.course = course; }
public StudentCourses getStudentCourses() { return studentCourses; }
public void setStudent(Student student) { this.student = student; if (student != null) { studentOid = student.getOid(). getUniqueNumber(); } else { studentOid = null; } }
public Course getCourse() { return course; }
}
The StudentCourse class is also a POJO. It contains one property and two parent neighbors with the corresponding set and get methods. In Modelibra both relationship directions are represented as neighbors.
public Student getStudent() { if (student == null) { Service service = (Service) getModel(); Students students = service.getStudents(); if (studentOid != null) { student = students. getStudent(studentOid); } } return student; }
public class StudentCourse extends GenStudentCourse { public StudentCourse(IDomainModel model) { super(model); } public StudentCourse(Course course, Student student) { super(course, student); } }
}
public abstract class GenStudentCourse extends Entity { private Date enrollmentDate; private Long studentOid; private Course course; private Student student;
2.3 Domain Model XML Configuration A domain with its models must be configured in an XML configuration file. This configuration reflects the model's POJO classes. However, it provides more information about the model's default behavior used in web components of ModelibraWicket. The XML configuration is loaded up-front and converted into meta entities. The XML configuration may be generated automaticaly from the domain model in ModelibraModeler. In order to save some space, only part of the XML configuration file will be given in the following.
public GenStudentCourse(IDomainModel model){ super(model); } public GenStudentCourse(Course course, Student student) { this(student.getModel()); setCourse(course); setStudent(student); } public void setEnrollmentDate(Date enrollmentDate) {
Education
Reusable
this.enrollmentDate = enrollmentDate; } public Date getEnrollmentDate() {
ISSN: 1792-6157
69
ISBN: 978-960-474-245-5
ADVANCES in DATA NETWORKS, COMMUNICATIONS, COMPUTERS
Service
vensada xml data/xml/education/service true
...
2.4 Persistent Model
Course
Courses true courseId
java.lang.String true true true courseName
java.lang.String true true description
java.lang.String false
A domain model is usually persistent. Model entities may be saved to an XML file or model changes may be registered in a relational or an object database. By default, Modelibra uses XML files to save data of the current domain model. However, Modelibra allows the use of both relational and object databases. The upgrade of an application from XML data files to a database does not require a single line of programming code to be changed. It is enough to change a domain configuration in XML, and create a database and configure it to run the same application again. At the beginning of its use, a domain model is completely loaded from an external memory. When the model is loaded, all model actions are done in the main memory of a computer. A software application programmer works with a domain model and does not have to write a single line of code to persist data. When specific entities, such as Courses, change by adding a new entity, by removing an entity, or by updating an entity, the entities are saved back to the corresponding XML data file by Modelibra. An XML persistent domain model is loaded from one or more XML data files. There is one XML data file for each entry concept of the domain model. What is saved in an entry data file depends on the relationship type: internal or external. In general, a model is a network graph where each concept is a node and each relationship is a line. For the purpose of persistence, the network model is divided into hierarchical sub-models, where each entry concepts represents a root of a hierarchy of concepts and internal relationships. Starting with the entry concept, the internal neighbor directions of the child type determine a scope of the hierarchy. External relationships are used to connect hierarchical sub-models. An internal neighbor is saved within its parent, while an external neighbor is not. From the entry concept, its internal neighbor directions are followed to save the entry with its children hierarchy in the XML data file of the entry concept. External neighbor directions determine the entry hierarchy boundary.
studentCourses
StudentCourse course true true child 0 N
3 Wicket
Course
...
ISSN: 1792-6157
Wicket is a web component based framework [4,5]. It is easy to develop a dynamic web application with Wicket once there is a well designed domain model. Wicket
70
ISBN: 978-960-474-245-5
ADVANCES in DATA NETWORKS, COMMUNICATIONS, COMPUTERS
brings plain object oriented programming to web applications. It is a web application framework for creating dynamic web pages by using web components. It uses only two technologies: Java and HTML. Wicket pages can be designed by a visual HTML editor. Dynamic content processing and form handling is all handled in Java code. A web component, such as a web page or a page section, is in the center of preoccupations in Wicket. Wicket provides a generic support for web applications. Web application concepts have corresponding classes in the Wicket framework and in the web application. For example, for the web application concept, Wicket has the WebApplication class. For a web page, Wicket has the WebPage class. Each web page in the web application has its own class that extends WebPage. Wicket web framework is used to develop specific and generic web components of ModelibraWicket.
Figure 2. Page table section with a list of courses and links to display
The component called EntityUpdateTablePanel is used to display entities as a table with the links to display, update and remove the selected entity and a link to update child entities of the selected entity (Figure 3).
Figure 3. Page table section with a list of courses and links to display, update and remove
The application pages are divided into sections. A section is presented through a specific or a generic web component. A generic web component must be able to accept different parameters in a generic way, so that the same web component may be used with different domain models. A web component uses a part of a domain model. It has also its view presentation parameters. If a web component is available in a catalog of generic components, the productivity of web page development will increase. Also, generic components save a time and improve quality of application development. Therefore, we have developed a catalog of reusable components for ModelibraWicket framework. They can be used for a dynamic web application development. For the sake of space, only two reusable components will be given in the following. EntityPropertyDisplayListPanel generic component displays a list of values for only one property of an entity. This web component shows here a list of courses obtained from the course name property (Figure 4).
4 ModelibraWicket ModelibraWicket is component web framework [6]. It makes a domain model alive as a web application. Thus, a model data can be displayed and updated through web application. This web application is a default application of the domain. The model is metamorphosed into a web application from its XML configuration. ModelibraWicket has a collection of generic web components that make a default Wicket application out of a domain model. This web application is not a version that one would like to install as a web site. Its main purpose is to validate a domain model by designers and future users of the web application and consequently refine the domain model. ModelibraWicket consists of generic web components that may be easily reused in professional web applications to display or update entities. The generic web components may be easily reused in a specific web application. Their reuse consists of collecting data from a domain model by using Modelibra and by supplying the data as parameters to the web components. The generic web components from ModelibraWicket use Modelibra for a domain model and Wicket for application views. Thus, for example, the component called EntityDisplayTablePanel is used to display entities as a table with a link to display the selected entity and a link to display child entities of the selected entity (Figure 2).
Figure 4. Courses web component
Often there is a need to display data based on the oneto-many relationship between two concepts.
ISSN: 1792-6157
71
ISBN: 978-960-474-245-5
ADVANCES in DATA NETWORKS, COMMUNICATIONS, COMPUTERS
ParentChildPropertyDisplayListPanel generic component dispalys one property from a parent entity and one property from a child entity but in a list of parents with the corresponding child list for each parent. Figure 5. presents visually the web component. This component lists the students and the dates of registration for the course.
supported by a web component. ModelibraWicket generic components save a time, battle code duplication and improve quality of application development. Therefore, we have developed a catalog of reusable components for ModelibraWicket framework. They can be used for a dynamic web application development. Using ModelibraWicket framework it is possible to develop a dynamic web application with a minimum amount of programming.
References: [1] Open Source Web Frameworks in Java (http://javasource.net/open-source/web-frameworks) [2] T. Husted, C. Dumoulin, G. Franciscus, D. Winterfeldt, Struts in Action, Manning Publications Co., 2002. [3] Struts (http://struts.apache.org) [4] M. Dashorst, E. Hillenius, Wicket in Action, Manning Publications Co., 2008. [5] Wicket (http://wicket.apache.org) [6] D. Ridjanovic, Title Rapid Development of Web Applications with Web Components, Springer, 2007. [7] D. Ridjanovic, T. Mateljan, V. Okanovic, mvcLite Framework, TDP, 2006. [8] D. Ridjanovic, V. Okanovic, Using Database Framework in Web Applications, 12th IEEE Mediterranean Electrotehnical Conference, Dubrovnik, Croatia, 2004. [9] V. Okanovic, D. Ridjanovic, Dynamic Web Application Development with Component Frameworks, 20th International Symposium on Information, Comunication and Automation Technologies, Sarajevo, Bosnia and Herzegovina, 2007.
Figure 5. Student-enrollment date web component
5 Conclusion In this paper is given a breaf overview of domain model driven development with open source Java frameworks: Modelibra, ModelibraWicket and Wicket. Those frameworks can be used for developing dynamic web application in a relatively short time and with minimal programming. Modelibra is a domain model framework. It has been designed to help developers of small applications in representing and using application domain models. The domain models are created by ModelibraModeler, design and code generation tool. A domain with its models must be configured in an XML configuration file. This configuration file may be generated automaticaly from the domain model in ModelibraModeler. ModelibraWicket is a web component framework which makes it possible to produce quickly a web application based on the given domain model which is expressed in Modelibra. ModelibraWicket uses Wicket for advanced web components that are based on Wicket’s base components. Advanced web components are tightly integrated with Modelibra and its meta entities that represent the configuration of a domain model. ModelibraWicket consists of generic web components that may be easily reused in web applications to display or update entities. A generic web component uses a part of the domain model, called a view model. ModelibraWicket uses the Modelibra domain model framework for its view models, and the Wicket web framework for its web views. Breaking pages into sets of components enables us to better delegate development tasks across multiple team members. In this way, a designer can focus on how to divide a page into sections, where each section is
ISSN: 1792-6157
72
ISBN: 978-960-474-245-5