Automatic generation of distributed dynamic applications in a thin client environment

(1)

CODEN: LUTEDX ( TETS-5469 ) / 1-77 / (2002)&local 26

Master thesis

Automatic generation of distributed dynamic

applications in a thin client environment

by

Klas Ehnrot and Tobias Södergren

February, 2003

Advisors:

Per Runeson, Dept. of Communication Systems, Lund University Dennis Zikovic, Caleigo AB, Lund

(2)

Abstract

Caleigo is a company that has developed a technology which promises to change the way software are created. Generally speaking, this technology helps developers in two phases in the software

development process. The first part speeds up the development phase, by automatically generating an application based on data extracted from a given structured data source. The other part addresses the problem that the environment, in which software is running, often changes over time due to factors such as evolving business structures and routines. This means that the software has to be adapted to address the change of the environment. The second part of Caleigo's technology addresses the maintenance and support phase, by providing very flexible and adaptable ways to alter the behavior of the application, in run-time, without having to change the source code or recompile the application. The technology from Caleigo has no support for thin clients, such as web browsers as of today. This master thesis is aimed at investigating if the concepts used in the technology can be applied to web applications. To test the viability of our theories and investigations in practice, a prototype is

developed and evaluated. As web applications also are inherently distributable, we also focus on how existing distribution techniques can be incorporated into our prototype.

The conclusion is that we successfully implemented a thin client prototype server of the Caleigo technology framework, and it contains much of the dynamic features found in the application that are being built by Caleigo today. The prototype server can also be automatically generated to include distribution based on Enterprise Java Beans (EJB).

(3)

Acknowledgments

The work on the master thesis was performed at Caleigo AB in Lund, Sweden from June 2002 to January 2003.

We would like to thank our advisor Per Runeson at the Department of Communication Systems, Lund University, for helping us with the document structure and for reviewing this master thesis.

We would like to thank Caleigo AB for the opportunity of making this thesis, and especially: Our Advisor Dennis Zikovic for guiding us onto the right path.

Mattias Hagstrand for guiding us through the Caleigo technologies with great patience. Mathias Albertson for his enthusiasm and making us feel as part of the Caleigo team.

(4)

3.3.5 Conclusion...31 3.4 JSP/Struts (Model2)...31 3.4.1 Introduction...31 3.4.2 Overview of Struts...32 3.4.3 Analysis results...32 3.4.4 Conclusion...33 3.5 Tapestry...33 3.5.1 Introduction...33 3.5.2 Analysis results...33 3.5.3 Conclusion...34 3.6 XMLC/Barracuda...35 3.6.1 Introduction...35 3.6.2 Analysis results...36 3.6.3 Conclusion...37 3.7 Velocity...37 3.7.1 Introduction...37 3.7.2 Analysis results...37 3.7.3 Conclusion...38

3.8 Conclusions from the prestudy...38

3.9 Comparison chart...40

4 Prototype ...42

4.1 Introduction...42

4.2 Implementation of a dynamic web client...42

4.2.1 Solution for the dynamic view structure ...42

4.2.2 More about the view layer...43

4.2.3 Request handling...46

4.2.4 Concurrent users...47

(5)

4.3 Implementing a distributed way of connecting to CEL...51

4.3.1 Description of the problem. ...51

4.3.2 Conclusions...54

5 Prototype analysis...56

5.1 Introduction...56

5.2 Criteria...56

5.3 Analyzing the presentation framework...56

5.3.1 Dynamic views...57

5.3.2 Use JSP as a template engine...58

5.4 Customization possibilities...60

5.4.1 Use case scenario...60

5.4.2 Summary and conclusions...67

5.5 Integrating web services with the prototype...67

5.5.1 The Web client and CEL in the same JVM...67

5.5.2 CEL tunneling...68

5.5.3 Conclusion...69

5.6 Possible use of EJB / J2EE in Caleigo's products...69

5.6.1 Implementation of the CEL layer in EJB/J2EE...69

5.6.2 EJB facade...70

5.6.3 Packaging of CEL in an Enterprise archive...70

5.6.4 Summary...70

5.7 Multi-user functionality...71

5.7.1 Analyzing the implementation...71

5.7.2 Conclusion...75 6 Goals revisited...76 6.1 Final conclusions...77 Appendix A...79 Appendix B...80 Appendix C ...81 Appendix D...85 Appendix E...87 Appendix F...90 References...96

(6)

1 Introduction

This master thesis was created due to the fact that Caleigo felt a need for performing an investigation of the possible potential of their current technologies in the thin client market. This introduction presents a general view of what development issues the products of Caleigo is addressing, together with the goals for this master thesis.

There are different ideas of how to create computer software. There is always some kind of more or less structured process involved, that hopefully address most of the problems that can arise while developing a system. One thing that often happens when following a classical software process model is that the application that emerges during the process, is often static in its nature. The business logic is often very specific, the collaborating objects has hard-coded relationship between each other, and the logic for accessing data is often very tightly coupled with the business logic. Hard pressed dead-lines and schedules, together with management decisions not to emphasize the importance of building applications that are easy to change, when the business strategy in the company changes, is often causing this inflexibility in the application. One other aspect is that it requires people highly skilled in object oriented analysis and design to create flexible computer programs, and skillful people are often hard to find, and the salary cost is often rather high when using their services.

Caleigo has put a lot of effort to try to change the way client-server programming is done. They have realized that there is a need for a higher abstraction of the data in the database, in order to provide a flexible and dynamic way of accessing the data. They have also found out that much development is put into changing the way users look at the data. Often when the business is changing in the company, other types of data in the database, and most often other relationships between the data is getting more interesting to work with from the users point of view. This means that the application the user is running in order to get a graphical view of the data, also has to be very flexible and easy to adapt to the changing data.

At the moment, the only way to access the data, using Caleigos' products, is by using a smart client written in Java. One goal for this master thesis was to analyze if the concept also could work in a thin-client environment, such as having dynamic views inside a web browser or a WAP phone. Another goal was to see if the data abstraction concept could be implemented together with Enterprise Java Beans. We also had a goal to implement these technologies in a prototype, to give an answer to whether or not the goals were practically achievable.

1.1 Client-server concepts

Clients can be divided into two types, namely fat clients and thin clients. Caleigo has also introduced something called smart client, which is an extension of a fat client.

A fat client is a client that contains more system resources than a thin client. The fat client is often an application which uses the server solely as a data storage, all the application logic and the calculations happens inside the fat client. A computer that runs for example a word processor that gets its

documents from a file server on a network can be seen as a fat client.

A thin client is a client with limited system resources, such as processing power, memory and sometimes battery resources. It often only has enough built-in logic to render the layout information that is transmitted from a server. The thin client does very little work by itself, most work is done by the server. A web client connecting to a web server is considered to be a thin client. The client only displays the HTML code that comes from the server and does mostly no data processing by itself. The smart client, as Caleigo defines it, is a fat client that contains logic for finding out if it has become outdated by a newer client version. If this would be the case, the user would be notified and suggested to take appropriate actions, or the update process can be handled automatically by having the client to download the new client from the server and perform the necessary update steps by itself. A smart client in the Caleigo scope also points out dynamic user interface and layout possibilities which will be further explained later on.

(7)

1.2 Objectives

Caleigo was interested to see if it was possible to create thin-client1_{applications that has the dynamic}

user interface that the smart clients have. They were also interested to see in what extent, using standard technologies, a web client would be able to mimic the layout functionality of the smart client, such as using pop-up menus, drag & drop and such. The second step was to investigate if the

applications could be applied to a distributed environment on the server side. The issues to be investigated were:

Market Analysis

Do a market analysis and find technologies that can be used inside the prototype. Develop a prototype

Develop the prototype to prove that dynamic views on thin clients are possible to do. Distribution technologies

Integration of the prototype with a distributed technology, namely Enterprise JavaBeans. Analysis of the prototype and surrounding technologies

Deeper analysis of the result, criteria for this is found in section 1.4.

1.3 Methodology

To achieve the objectives we apply the following methodology:

Perform a prestudy to investigate which existing technologies could be used to achieve the objectives.

Create a prototype that explicitly uses Caleigo's existing frameworks as far as possible, to analyze how versatile the frameworks are in other environments.

Analyze the created prototype to find its weaknesses and describe solutions, and especially look at the following issues:

Adaptability to other application types.

Creation of a use case and use the application to build an application from the information in the use case.

Analyze possible 3rd party technologies that can be used to create a distributed prototype, such as: EJB

Web Services

Implement the final details in the prototype and combine with the issues that was found during the analysis phase.

Conclusions

1 Thin clients come in many flavors and platforms. We have decided to base our master thesis on the web platform, since web browsers are very popular thin clients. It is also the most interesting platform for Caleigo Solutions, as one of their future product will be based on the web platform.

(8)

1.4 Analysis criteria

The criteria we will look into when it comes to the prototype client are:

Functional similarity to the Swing application explained in chapter 2 such as Input handling, such as event handling.

Template flexibility. Topics are:

Does recursive behavior reduces flexibility? How do one address customization of the layout?

Increasing the functionality, for example making new views and actions. How well can the application handle concurrent users?

How well does customization work with the prototype?

Criteria used when analyzing the implementation of the distributed prototype: Is the prototype actually distributed?

Are there any obvious performance issues?

1.5 Document outline

This report is outlined in the following manner:

Chapter 2 gives the reader a thorough introduction of the concepts and technologies that are used in different parts of this master thesis.

In chapter 3, we present a pre-study of the market to see if there are tools available today that resembles what we want to achieve.

The prototype is explained in detailed in chapter 4 followed by an analysis of the prototype and used technologies in chapter 5.

(9)

2 Technical background

2.1 Introduction

This chapter aims at giving insight into the technologies being used in our master thesis. The reader will have the opportunity to understand the underlying technologies that are discussed in this report and being used in the prototype, and thereby hopefully gain a better understanding of the achieved results.

We have decided to split up the technical background into three different parts; the technologies made by Caleigo, the thin-client technologies used in the prototype and finally the technologies used to create a distributed application.

Caleigo technology platforms

A lot of the implementations in the prototype use technology developed by Caleigo, so it is important to have a good understanding of the major features of the Caleigo technology platform. This includes knowledge about the basic components making up a generated application and how the automatic generation of code is done. The presentation of these technologies is found in section 2.2. Web programming technologies

One major part of the master thesis is centered around creating a dynamic thin client. To be able to understand how this is accomplished, a presentation of basic building blocks for web programming in Java is found in section 2.3.

Distributed programming technologies

The master thesis includes an analysis and implementation of distributed basic building blocks using the Caleigo platform. The building blocks are based on the standard enterprise distribution solution for Java objects supplied by Sun Microsystems, namely Enterprise Java Beans or in short EJB. A

presentation of the EJB basics is found in section 2.4.

2.2 Caleigo technology platform

Caleigo develops database driven software development tools in Java. These tools are used to generate finished applications from existing databases. Today, the product line consists of a single product, Caleigo Foundation Builder, that generates a smart client, which is a fat client with the extra version check functionality, and the corresponding server part.

This client is graphically built of Java Swing components for making it able to run on many different operating systems. Java Swing is a graphical window toolkit which is developed by Sun Microsystems, and it is a standard component in the Java Development Kit.

The client communicates with a server that is responsible for providing data from a data source, for example a database. This data is transported to the client to be displayed and edited, and it is sent back to the server whenever it needs to be put in a persistent state.

2.2.1 Caleigo Foundation Builder

Caleigo Foundation Builder is an application that generates the smart client with an option to also generate the server. We will go through an example of an application generation to present the usage and functionality of Caleigo Foundation Builder. The sample uses a reference database called Northwind. It is used as an example database in Microsoft SQL Server and consists of 13 tables, constituting a trading system. The corresponding database schema can be seen in Appendix A.

(10)

Wizard

When first starting Caleigo Foundation Builder, the user has to go through a wizard, consisting of a number of steps that leads the user through the configuration setup. The first step is to point out a data source which can be seen in Figure 2.1.

At the time this report was written only databases could be used as data sources, which explains why Caleigo's first wizard is very database centric.

In the first field, the user is required to supply a suitable database driver class. This class should contain the implementation of the Java Database Connectivity (JDBC) API, which unifies the way of how to communicate with databases. From a developer's point of view, the communication details are handled inside the JDBC driver, and the high level routines used to access a database is the same for every database that conforms to the JDBC Specification [jdbc].

To be able to connect to a specific database, the user specifies a JDBC Uniform Resource Locator (URL), that tells the JDBC driver where the actual database can be found. The JDBC URL can differ from database to database and it is defined in the JDBC driver documentation for each database. In addition to the URL a user name and password is specified, which is needed by the database for authentication.

When all information is entered, Caleigo Foundation Builder uses the information to connect to the database. It retrieves the meta data of the database, which contains the table structure information and the relations to other tables, among other things. This information is used by Caleigo Foundation Builder to calculate how the table views should be generated, however the user has full freedom to change the way Caleigo Foundation Builder will treat meta data. See Figure 2.2 for a visual Figure 2.1: Specification of connections settings

(11)

presentation of how it works.

All tables are listed in the second step and the user has the ability to edit the meta data for all tables and relations to other tables. A table can be represented in three ways:

As a Master Entity: The table is a standalone table, which does not depend on other tables. As a Slave Entity: The table has a reference to a master table. It is not a master table itself, so it depends on the tables it references.

As a Link Entity: The table is treated as a link between two other tables. It needs to have references to each of the linked tables.

The user can also remove tables, which means they will not show up in the application, but it will not be deleted from the database. Actually nothing that is done at this stage affects neither the data nor the meta data in the database.

When the configuration of meta data is done, the user has the opportunity to save the configuration and watch a preview of the application. The preview is identical to the finished application. If the user is satisfied, he or she presses the "Next" button which leads to a dialog that asks where to generate the application. See Figure 2.3.

(12)

The "Template Directory" should point to the directory containing the templates that are used in the creation of the source code for the application. Other values can be left as default. When the user presses "Next", the sources are being created and presented to the user.

The application is now ready for usage. A display of the created program can be seen in Figure 2.4. Tables are represented by tabs in the top of the screen. The user can press a tab and get a list of rows in the table at the left hand side of the screen. The user can then choose one field and get a more

exhaustive representation of the field in the right hand side of the screen. This all seems very

straightforward, but the real strength lies in the flexibility of the created application. Entities and fields can now be moved via the user interface to other parts of the screen as long as they have a relationship with the entity where it is moved. All different views on the screen can be moved around and overlap each other (done with tabs). Hereby a complete application is developed. So, how is this

accomplished? To answer that question, we have to take a look at the architecture behind all of Caleigo's products.

(13)

2.2.2 The Framework

The technology from Caleigo uses a layered solution that breaks up an application in 5 layers, all working together. An overview of the layers can be seen in Figure 2.5.

DB layer

The DB layer can consist of a variety of data sources. The most used data source is the relational database, RDBMS (Relational Database Management System), but it can also be a object-based database, an XML file, Web service or possibly an EJB solution.

Service layer

The service layer handles the direct connection to the database, and it makes it possible to write data services that wraps different types of data sources, using different protocols. JDBC/ODBC is used for connecting to an RDMBS for example. The service layer provides a uniform interface towards the Core Entity Layer (CEL) layer so that CEL does not have to know what kind of data source it wraps. This is of great importance for keeping the model generic.

Data model/CEL layer

The Core Entity Layer is responsible for representing a data source as a highly object-oriented pattern-driven data structure, with the strength to dynamically change how we look upon the data. We can for example define new entity types (entity types normally represent tables in a database) with fields taken from many entities. CEL basically have two structures, a meta model that describes the data source, and an entity model that represents the actual data in the data source. The meta model is very useful when creating the application views because it contains the structural information needed for rendering the views. CEL defines all relations between entity types (tables) and incorporates them into the meta model.

(14)

Data View layer

The data view layer is responsible for reading the meta model, and converting it into an actual view structure that reflects the meta model. A view is a graphical representation of data. View factories are special Java classes that are responsible for creating views for a certain component in the meta model. Everything down to the field level can be represented by a view. In this way we can create a hierarchy of views, starting with a root view, going down through selection views, entity views and at the end field views.

Framework layer

The framework layer is responsible for utilizing the view layer in a certain presentation interface, such as a Swing application in the smart client. An example of a Swing implementation of the framework layer is presented in Figure 2.4. The framework layer in the Swing case can be changed at runtime via an ingenious interface created by Caleigo. The user can add, remove and move entity types, fields and search filters by a drag&drop interface, which is presented in Figure 2.6.

(15)

2.2.3 More about the CEL layer

The CEL layer is the data abstraction layer and it maintains all data and equally important, it contains all the relationships between data. To gain a deeper understanding of CEL, some components in the architecture needs to be explained.

Entity

In databases, an entity corresponds to a row in a table. It encapsulates the data contained in one row and has retrieve and set methods for all fields belonging to the entity. The programmer needs to created source code for all entities, though as we have seen above, Caleigo Foundation Builder helps to generate the source code in question, by analyzing the database.

EntityDescriptor

An EntityDescriptor contains information about the specified entity type. It contains information about what fields exists in the entity, and their properties. All entities have a reference to an EntityDescriptor. An EntityType can be seen as a description of a table in a database.

DataSourceDescriptor

A DataSourceDescriptor has the same purpose as an EntityDescriptor, but instead of describing a type of entity, it describes a Data Source that contains a number of Entity types. A DataSourceDescriptor can be seen as a descriptor of a database, and it has a reference to every EntityDescriptor.

(16)

DataSource

A DataSource has connections to the underlying persistence mechanism via a DataService (see below). It also has a reference to a DataSourceDescriptor, and it works as the connection between the

persistence mechanism and the CEL representation of it. DataService

A DataService contains the actual implementation of the used persistence mechanism. A DataService has connection information and code that creates, retrieves, updates and removes data from the persistence source. This code combined with the information in the Entities and EntityDescriptors makes it possible to manipulate the correct data in the persistence source. A good example of a DataService is the JDBCDataService that encapsulates the ability to make JDBC queries to a database. Qualifier

A qualifier is an object that encapsulates a query to the DataSource in a general and DataService independent way. When the user passes a qualifier along together with an EntityDescriptor to the DataService, only Entities that fulfill the criterias in the Qualifier will be returned to the caller. Selection

A Selection contains a list of Entities grouped together. The selection can be all entities belonging to an EntityDescriptor or a set of Entities that fulfills a Qualifier.

For more information about the Caleigo technology, see [celWP]. We cover details of the technology as the need emerges in later sections.

2.3 Web technologies in Java

Web programming is well handled by Java, because Sun Microsystems and other vendors have developed a large set of tools for creating web related systems. In fact, Java has become many developers first choice when implementing a web solution.

Sun Microsystems is the creator of Java, their web libraries are the building blocks used by other vendors so the focus in this chapter will be on these technologies.

2.3.1 Java enabled web servers

A web server is responsible for handling incoming HTTP requests. HTTP stands for Hyper Text Transfer Protocol and it is a protocol that defines how web clients communicate with web servers. An incoming HTTP request contains a destination address and user defined parameters. The web server is responsible for retrieving the data, whose location is specified in the HTTP request, and send it back to the client. Normally the request address points to a specially formatted text file known as a HTML document which the web server finds and returns to the client, but in the case of a Java enabled web server, the procedure is a bit more complex.

The web server is running within a Java Virtual Machine where Java objects can be instantiated and run. The web server has the ability to map an externally reachable address against a special Java object called a Java Servlet. The Java Servlet object is invoked when a client request the address mapped to the Java Servlet, and the Java Servlet is then responsible for returning data back to the client.

2.3.2 Java Servlet

A Java Servlet is, as mentioned above, a Java class responsible for handling HTTP requests. The Java Servlet must inherit from an abstract class, which specifies the hooks and methods used by web server for access.

An example of a Java Servlet is found in the program list below:

(17)

import javax.servlet.*; import javax.servlet.http.*;

public class Hello extends HttpServlet {

/** Initializes the servlet. */

public void init(ServletConfig config) throws ServletException

{

super.init(config); }

/** Destroys the servlet. */

public void destroy() {

}

/** Processes requests for both HTTP GET and POST methods. * @param request servlet request

* @param response servlet response */

protected void processRequest(HttpServletRequest request, HttpServletResponse response)

throws ServletException, java.io.IOException {

response.setContentType("text/html");

java.io.PrintWriter out = response.getWriter(); /* output your page here

out.println("<html>"); out.println("<head>"); out.println("<title>Servlet</title>"); out.println("</head>"); out.println("<body>"); out.println(“Hello World!<BR>”); out.println("</body>"); out.println("</html>"); */ out.close(); }

/** Handles the HTTP <code>GET</code> method. * @param request servlet request

* @param response servlet response */

protected void doGet(HttpServletRequest request, HttpServletResponse response)

processRequest(request, response); }

(18)

* @param request servlet request * @param response servlet response */

protected void doPost(HttpServletRequest request, HttpServletResponse response)

processRequest(request, response); }

/** Returns a short description of the servlet. */

public String getServletInfo() {

return "Short description"; }

A Java Servlet is created by having a Java class implementing the "javax.servet.http.HTTPServlet"

abstract class. To enable users to access the Java Servlet on the web server, it has to be registered in the web server under a specific URL (Unified Resource Locator). An URL is the address that one would write in a web browser to access a resource on the Internet, for example "http://java.sun.com/". When this is done, all requests to that URL is passed to an instance of the Java Servlet class.

To handle a request from a web browser inside the Java Servlet, the developer has to implement the methods "doPost()" and/or "doGet()" which is responsible for handling requests [JSS23]. "doGet()" is used when the caller issues an HTTP GET request, and "doPost()" is used if the caller issues an HTTP POST request [http11]. Both "doGet()" and "doPost()" takes two object as parameters:

javax.servlet.http.HTTPRequest: This is an object that contains all parameters and information about the request. It also contains all information about the session.

Javax.servlet.http.HTTPResponse: This is an object that contains a reference back to the client, making it possible to send data to the client that has sent a request to the Java Servlet.

In the example above, both "doGet()" and "doPost()" calls the "processRequest()" method. The HttpServletResponse object contains a Writer object, which can be reached by calling

"HttpServletResponse.getWriter()". The Writer object is the link back to the web server, and it can be used to send any kind of data. When the data stream in the Writer is closed, the web server sends back the data to the client. In this case, the web browser will display a page that says "Hello World!" when calling the example.

2.3.3 JSP

Java Servlets are a powerful way to dynamically create Web pages and send them back to clients, but they do have disadvantages when it comes to readability, maintainability and development time. Since the HTML pages are generated from within the Java Servlet, any changes that is made to what will be displayed on the client requires a re-compilation of the Java Servlet.

Because of this, Sun developed a technique called JSP, which stands for JavaServer Pages. The idea with JSP is to write HTML pages and embed Java code inside. An example can be found in the listing below: <%@page contentType="text/html"%> <html> <head><title>JSP Page</title></head> <body> Hello <% out.print("World!"); %><BR>

(19)

</body> </html>

This JSP example will produce the same output as the code listing in the Java Servlet section above. The Java code is surrounded by “<%” and “%>” characters. The difference between Java Servlets and JSP is that a JSP page is automatically parsed by a JSP parser, compiled and instantiated whenever a change has been made to the JSP page. The outcome of the parser is a Java Servlet that will be compiled and instantiated inside the Web server. When the JSP page is changed, the Java Servlet instance will be replaced by another instance of the newly parsed JSP page [JSS23]. From the developers point of view, he can focus on the layout of the page and, when needed, add dynamic content by using special JSP tags. The JSP can be edited in any text editor, just like any other HTML page. A Java Servlet on the other hand, would have required a complete development environment, with a Java editor, compiler and so forth, just to edit the HTML on a page.

2.4 Distributed programming in Java

When system complexity evolves from simple client-server handling, like the one we have seen an example of in section 2.3.2 to a more dynamic and distributed approach, we need to provide technologies that can handle this. This section covers the fundamentals of distributed programming, starting with the history of the technology and ending with a focus on Java technologies that helps us to create distributed systems. For a more detailed study see [Adatia 2001].

2.4.1 History of Distributed Systems

In the 1970's, hardly no personal computers existed, and all processor power were packed in one mainframe system that handled everything from persistence, calculations and user interface. To make many users use this mainframe at the same time, dumb terminals were created that did not have computing power to either control any calculations nor even control its own graphical interface. Instead this control was given to the mainframe computer. A distributed system like this one is referred to as a 1-tier system, meaning that only one instance handles persistence, business logic and user interface. The obvious drawback of a system setup like this is that the mainframe needs to be powerful enough to handle all clients' workload. Another problem is that if you need to update one part of the system, you need to basically shutdown the whole system, since everything exists in one place. In the 1980's the concept of client-server systems arrived. PC's were getting more and more powerful, and were able to take over all or parts of the computing process. Often, the setup consisted of many clients, all containing both the user interface and the business logic. Another setup could be that the client handled user interface and input validation, while the server still handled business logic and persistence. Hence the servers task was to control and maintain data persistence, and a variable amount of business logic. A system setup like this is referred to as a 2-tier system.

The client-server solution was not free of problems. Problems were:

Changes in business logic often meant changing large portions of the application.

Tight coupling between database and business logic, often business logic access the database directly from within the code.

Because of the tight coupling, it is difficult to implement load balancing, as in introduce another server to handle some of the user requests.

The solution is to break up the system in three parts: Presentation layer, often residing at the client.

Business logic, which could reside on a server of its own. Persistence layer, residing on a database server.

(20)

user interface require no changing of business logic on the server, the business logic could communicate with different databases, and so on.

A 3-tier architecture can be further refined to support interfaces between persistence and business logic and interfaces between business logic and user interface. We then refer to this as an n-tier architecture. In an n-tier system with many concurring connections, there are some critical issues that need to be addressed. A list of some of them is presented below:

Transaction handling Application server fail over Scalability

Resource Management, component pooling Database connection pooling

Security Persistence Transaction handling

A transaction is defined as one unit of work. If the execution of a piece of code is surround by a transaction, it means that either all code is successfully run within the transaction, or all code is undone if the transaction fails.

Transactions can be described with the ACID concepts. ACID is an abbreviation for:

Atomic, meaning what we have described above. All changes are roll backed if any part of the transaction fails.

Consistent, a transaction must never leave data in an inconsistent state, which means "half the data is updated, half is not".

Isolation. The code inside the transaction can be sure that it is the only one part modifying the data source during the time of the transaction.

Durability. The effect of the transaction will be seen in the state of the system. The change will be logged for reference and possible for doing a compensating transaction, if needed.

A transaction handling scheme should make sure that the ACID properties are fulfilled. Application Server fail over

A connected client has a certain state in the system. If the server goes down while the client is

connected, there should be a mechanism for transferring the clients session (and hence the clients state) to another server.

Scalability

A system should be able to scale with increasing load. This means both for single server solutions and multi-server solutions, working together as a cluster. A cluster is a group of application servers that share workload and incoming connections. They incorporate a load balancing scheme, meaning having the ability to redirect incoming requests to different servers, according to some load balancing scheme. Resource management with component pooling

Component pooling means having instances of one component in a pool. This is done due to the fact that instantiation of components take time and resources in a server. Component pooling means that the components are instantiated once, and re-used for subsequent requests. A new request for a component, means a lookup in the component pool and a retrieval of a free component to the client. When the client is finished with the component, it is released back into the component pool.

(21)

Database connection pooling

Database connection pooling works in the same way as component pooling, but instead of components, the connection pool contains connections to a database. Since opening up connections to a database is a time consuming process, a connection pool will increase performance within the server.

Security

A Security model is needed for authorization to use resources on the application server. Persistence

Persistence handling is an important topic to centralize in an application server. Objects to data relations in a database is one area in which application servers should help developers.

2.4.2 Distributed programming in Java

A more detailed discussion of these topics can be found in [Adatia 2001]. All this important issues are handled by the J2EE technology developed by Sun. J2EE stands for Java 2 Enterprise Edition and it is a specification of an implementation that encapsulates business logic in special enterprise Java classes called EJB (Enterprise Java Beans). EJB helps the developer with all the surrounding services that are not directly associated with the business logic, which gives the developer more time to focus on his own logical problems. J2EE contains more than the EJB technology, but we are emphasizing EJB since they automatically, and in the background, integrate other parts of J2EE, and also because EJB is what we use in our prototype.

2.4.3 Fundamentals of EJB

All EJB applications are running inside an EJB container, which is responsible for the services

mentioned in the previous chapter. To benefit from these services, the developer needs to create classes with business data according to the EJB specification. The special classes are called "beans".

Today, the developer can choose between the following types of beans:

Stateless session bean, they do not remember any data between method calls.

Stateful session bean, they store data between method calls. The data storage has to be implemented by the developer, since no automatic persistent data storage is provided by the EJB container. Bean-managed persistence Entity Bean, they also include persistent storage of data. Programmer still needs to program database usage.

Container-managed persistence Entity Bean. Persistent storage of data. All database connectivity and usage is controlled by the container.

Message Driven Bean. Beans that can be asynchronously contacted by clients.

The difference between a session bean and an entity bean is that session beans are involved in the business logic, and the entity beans are involved in data storage.

EJB relies heavily on RMI which stands for Remote Method Invocation. It is a method for making methods and classes callable between applications. In RMI, there is a remote stub, with all distributed methods in. This stub runs on the client. When the client wants to call a method on the server, it addresses the stub, which in turn sets up the communication to the servers home stub, that is a corresponding interface to the remote stub. The home stub in turn makes the call to the real class and returns the result, which has to be serializable. EJB uses this technology, and it is obvious when you are developing EJB classes. A visualization of this can be seen in Figure 2.7.

(22)

2.4.4 Example

To describe how EJB works, it is best to do a practical example. We are going to develop a system that stores tracks. For a specification of the system, see section 5.4.1.

A track has an id, a title and an artist. To model this in EJB, we choose to do it with a CMP Entity Bean, since we do not want to code the database connectivity ourselves. We need to develop three classes

Remote Interface Home Interface Bean class Remote interface

The remote interface is run on the client, and sets up the communication to the home interface, which has direct connection to the bean class.

Our remote interface looks like this:

import java.rmi.*;

public interface Track extends javax.ejb.EJBObject {

public int getID() throws RemoteException;

public String getTitle() throws RemoteException; public String getArtist() throws RemoteException;

public void setTitle(String newTitle) throws RemoteException; public void setArtist(String newArtist) throws RemoteException; }

The remote interface displays all available methods that are callable. The important part here is to note that it inherits from javax.ejb.EJBObject which marks the class as and EJB.

Home Interface

The home interface exposes methods that are connected to the life cycle of the bean, such as the create method. Our home interface look like this:

import java.rmi.*; import java.util.*; import javax.ejb.*;

public interface TrackHome extends EJBHome {

Figure 2.7: The home and remote interfaces existing on client and server and communicating via RMI

(23)

public Track create(int, ID, String title, String artist) throws CreateException, RemoteException;

public Track findByPrimaryKey(int ID) throws FinderException, RemoteException; public Collection findAll()

throws FinderException, RemoteException; }

Interesting to note here is that this methods should correspond to a similar method in the bean that follows.

Bean class

The bean class contains the actual logic. Note that this is an CMP entity bean, which means that all variable instances we declare and use are automatically stored in a database. Code follows:

import javax.ejb.*; import java.rmi.*;

public class TrackBean extends Object implements EntityBean { public AddressEntryBean() { } // Fields to be stored

public int id;

public String title; public String artist;

// Implementation of the Track interface public String getName()

{

return name; }

public String getTitle() {

return address; }

public String getArtist() {

return artist; }

public void setID(int newID) {

(24)

}

public void setTitle(String newTitle) {

title = newTitle; }

// Implementation of the Entity Bean methods public void ejbActivate()

{ }

public void ejbStore() {

}

public void setEntityContext(EntityContext entityContext) {

}

public void unsetEntityContext() {

}

public void ejbPassivate() {

}

public void ejbLoad() {

}

public void ejbRemove() {

}

public String ejbCreate(int newID,String newTitle,String newArtist)

throws CreateException, RemoteException { id = newID; title = newTitle; artist = newArtist; return “” + id; }

public void ejbPostCreate(int newID,String newTitle,String newArtist)

throws CreateException, RemoteException {

}

We have three sections to look at here:

The variables: All variables declared in TrackBean is automatically stored permanently by the EJB container.

(25)

The track interface implementation: The methods declared in the Remote interface needs to be implemented here.

The Entity methods that need to be implemented: These can be seen as entry points in the life cycle of the bean where we get the chance to add code. We have left almost all of these methods empty which is perfectly alright since they already are doing what they are supposed to inside the container itself.

Deployment

So how do we deploy these EJBs? We need to specify information about the bean in a XML descriptor file called ejb-jar.xml. The description for this XML is rather complex and contains a lot of options, but we are going to create a simple one that is sufficient for our needs.

The file ejb-jar.xml is listed below:

<ejb-jar>

<display-name>Soundsystem</display-name>

<description>Soundsystem with as of this moment only one EJB, Track</description>

<enterprise-beans> <entity>

<description>This bean implements the persistence of a Track object</description> <display-name>Track</display-name> <ejb-name>com.celgen.ejb.Track</ejb-name> <home>com.celgen.ejb.TrackHome</home> <remote>com.celgen.ejb.Track</remote> <ejb-class>com.celgen.ejb.TrackBean</ejb-class> <persistence-type>Container</persistence-type> <prim-key-class>java.lang.Integer</prim-key-class> <reentrant>False</reentrant> <cmp-field><field-name>id</field-name></cmp-field> <cmp-field><field-name>title</field-name></cmp-field> <cmp-field><field-name>artist</field-name></cmp-field> <primkey-field>id</primkey-field> </entity> </enterprise-beans> </ejb-jar>

The file ejb-jar.xml is needed by the container so it knows how to deal with the Entity bean. Ejb-jar gives us information about what classes that constitute an EJB and what fields that exists in it. Ejb-jar is given in the EJB specification but it is not enough to deploy an EJB. Unfortunately, the rest of the deployment configuration is not given in the EJB specification, so it is basically a different setup for all application servers on the market. However the end result is the same, and all have some similarities with each other.

Application file structure

A J2EE application often has the following file structure:

/ejbapp1.jar /ejbapp2.jar /webapp1.war

(26)

/webapp2.war

/META-INF/application.xml /META-INF/Manifest.Mf /lib1.jar

/lib2.jar

The EJB applications in turn have the following file structure:

/com/celgen/ejb/Track.class /com/celgen/ejb/TrackHome.class /com/celgen/ejb/TrackBean.class /META-INF/ /META-INF/ejb-jar.xml /META-INF/Manifest.Mf

and the web applications have this file structure:

/index.html /images/img1.gif /jsp/hello.jsp /WEB-INF/ /WEB-INF/classes/com/celgen/servlet/hello.class /WEB-INF/lib/log4j.jar /WEB-INF/web.xml /META-INF/Manifest.Mf

What is new here? In the enterprise archive, we have a file called application.xml. It is a description of the entire application and looks like this for our sample track system:

<?xml version="1.0"?>

<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.2//EN"

"http://java.sun.com/j2ee/dtds/application_1_2.dtd"> <application>

<display-name>SoundSystem</display-name>

<description>Soundsystem web application that

uses a Container Managed Entity Bean</description> <module> <ejb>ejbapp1.jar</ejb> <ejb>ejbapp2.jar</ejb> </module> <module> <web> <web-uri>webapp1.war</web-uri> <context-root>/webapp1</context-root> </web>

(27)

<web> <web-uri>webapp2.war</web-uri> <context-root>/webapp2</context-root> </web> </module> </application>

From this we see that we have two EJB modules and two web modules. We also see that the web modules are attached to the relative URLs "/webapp1" and "/webapp2". This is relative to the URL of the whole application which is specified in a vendor specific configuration file.

(28)

3 Market Analysis.

3.1 Introduction

In this chapter, we present an analysis of available technologies we figured could be of use to us during the prototype construction phase. We were looking for technologies that could reside between the thin client and the existing frameworks from Caleigo.

Requirements dictated from Caleigo were:

The technologies should be created in Java so it could be incorporated in the existing frameworks. The analysis should produce a comparison chart, listing the pros, cons and differences between them.

The next section discuss the criteria used for comparing the different technologies, then follows a presentation of each technology, with conclusions for each criteria. The last sections includes a comparison chart and final conclusions of what we chose to use for our prototype implementation. After performing a search in the market for products, we found some technologies that could be used for creating thin client applications. Some common characteristics could be found among some of these technologies, and we have grouped them together into two different areas:

Template-based technologies

Document objectification technologies

Template-based technologies

A template engine works with templates, which are text files containing static information together with placeholders where dynamic data should be inserted. The template engine is responsible for fetching the dynamic data from a data source and merge it together with the static content. These are the template-based technologies we have looked into:

JSP

JSP/Struts (Model2) Velocity/Model2

Document objectification technologies

This concept treats the document as a hierarchical object structure. Words are combined to sentences, sentences forms sections, and sections forms a chapter, and so on. In order to make this documents dynamic, the technologies provide methods to alter the object structure, such as adding, moving and removing text nodes at different levels in the structure.

Here is the list of technologies we have looked into: Tapestry

XMLC/Barracuda

3.2 Analysis criteria

This chapter presents the criteria which we used to compare the different technologies to each other:

Design and maintainability

This criteria deals with the code that has to be written using the technology in question. How structured and clean is the resulting source code? Does the technology enforce the user to write good code, or bad code? How hard is it to understand and maintain a code base that has been written by somebody else?

(29)

Dynamic layout

Here we try to analyze the potential of the technology for writing the dynamic layout we need in the prototype.

Areas of responsibilities

Can the development using the technology in question be divided into areas of responsibilities? Is it possible to have a web designer being responsible for the graphical user interface for the application and having a developer being responsible for the business logic? This criteria can be interesting for different reasons, such as planning the development teams, in number and in skill requirements.

Demands on skills

What skills are required for the different areas of responsibility in the technology? For example, what else beside HTML does a designer need to know to produce something using a technology. What Java skill level, or special technology knowledge does a developer need to know.

Feasibility for small and large projects

This is a sum of different issues, like abstraction level for the technology, the overhead that might exist in the development process and the skill demand for using the technology in question.

Connection with business logic

This section describes how the communication is done between the GUI and the underlying business logic.

Learning curve

How hard is it to understand the technology? How long does the technology take to master?

State handling

When a thin client connects to a server, an application state has to be introduced for that user. A discussion of why this has to be done, is found in chapter 47. This section describes how state handling is done for the technology in question.

3.2.1 Definitions

In this chapter, the following concepts are used consequently throughout the text, where nothing else is specified:

The developer means the Java developer who is responsible for the functionality within the application, such as business logic.

The designer is the graphical user interface designer, who are responsible for creating the user interface for the thin client.

3.3 JSP

3.3.1 Introduction

JSP [JSPS12] is is a scripting language developed and maintained by Sun Microsystems. It is a standard component in Sun's recommendation of how to build front-ends to web applications using Java Enterprise technologies (J2EE) [Alur 2001].

To use the language in practice, the JSP page needs to be compiled before it can be activated inside an application. Most Java application servers do this automatically if they are provided a Java compiler, which is a standard component inside the J2EE framework.

JSP was originally an answer to a product from Microsoft which was competing to Java Servlets, but to meet the needs of enterprise web applications, the JSP specification has been continuously extended. The Java Enterprise blueprints present recommended ways to combine the technologies together

(30)

[j2eebp].

JSP is a template based language, where the dynamic data could be introduced using Java code directly, or by using JSP tags. For an example of how this could look like, see chapter 5.3.2.

3.3.2 Analysis results

JSP gives some freedom of choice of how to design the JSP page and how the communication with the underlying business objects is performed, which is to:

Include Java code directly in the page Use the beans concept

Use the Java Servlet Session object, which is presented in chapter 5.7.1, to store and fetch data Use custom made tags

Since it is possible to add Java code directly into a JSP page, designers can be lured into adding code in the page, because it is allowed and because it is a way to get results fast.

Even worse is that it is possible to add business logic into the pages, which breaks the distinction between the layout and the functionality, and this makes applications which can be hard to debug and maintain.

To prevent this, the custom tag library initiative, JSTL, has started. It is a growing collection of standard tags that can be used by designers in JSP pages, instead of writing Java code. One example is the Iterator tag, that makes it possible to create conditional loops within a page without writing Java code. This, together with using a strict Model-View-Controller pattern (see appendix B) is the preferred way to build an application according to Sun Microsystems. [Alur 2001]

Dynamic layout

The language itself gives no explicit help with creating a dynamic layout, other than rendering the JSP tags dynamically. The developer needs to create an solution of his own to add more flexibility to the layout. This might be done by adding custom tags, which is JSP tags that the developer has created himself. When included in a JSP document, they will be replaced by underlying code that is mapped to the specific custom tag.

There can be at least two areas of responsibilities of the JSP when using a clean design principle: The designer has the responsibility of creating the views of the application

The developer is responsible providing the views with data, and also decide which view to show in different scenarios.

Depending on how much logic that can be found in custom made tags, the designer might have to know about Java to perform certain operations in the HTML page. One example can be to populate a table with data and iterate through a set of data.

The developer needs to create a design policy and an API for the designer so that no code appear inside the JSP that really should have been in another layer.

Feasibility for small and large project

For prototyping and smaller projects, the JSP concept can be very productive, but JSP pages can soon become cluttered and hard to understand if not a strict design policy is followed. In projects close to deadline, the temptation of putting business logic or Java code in the page can be high, and thus break the coupling between the graphical user interface and the underlying business objects.

(31)

Connections to business logic

There is some freedom of choice here on how to access the underlying business objects, but the recommended way is to follow the Model-View-Controller model, called model 2 in the J2EE blueprint [j2eebp]. There is no implicit MVC model included in the language itself.

Learning curve / threshold

The JSP syntax itself can be somewhat hard to read at first, but the language is rather small and quite easy to comprehend, once the JSP syntax threshold has been passed. If the designer has to write his own functions in Java, then of course knowledge in the Java language is required.

State handling

The JSP technology does not implicitly introduce session handling, but the GUI designer has access to the Java Session object inside the JSP page which can be used to store data that should exist during the time of a user session.

3.3.3 Problems with JSP

Allowing Java code in the presentation layer. Java code is often required in a JSP page to perform certain operations.

Designers can not see the final result while working with the page. This is a problem found in all template based technologies we have looked into.

The syntax makes it sometimes hard to follow the logic inside a JSP page.

Error messages are often hard to understand for a developer since the error messages stem from the generated Java code, which the page designer has had nothing to do with.

3.3.4 Solutions to some problems

Introducing custom tags

Custom tags are access points in the JSP page to custom made Java objects. When the JSP page is accessed, the tags are replaces with the output from a method in the Java object. This makes the JSP pages easier to read and comprehend, and it also gives a more profound line between the layout and the underlying business logic.

3.3.5 Conclusion

It is the recommended way to build enterprise applications using Java by Sun Microsystems. That JSP is a recommendation might be a good enough reason to choose to use it, because of the great support it has in the market.

To write a well designed application, JSP strict code design policy had to be introduced, one has to implement some kind of abstraction layer, and create some distinctions between the layout and business objects. The recommended way to do this is to use the Model 2 MVC model specification from Sun Microsystems.

3.4 JSP/Struts (Model2)

3.4.1 Introduction

Struts [struts] is a Model-View-Controller [Gamma 1995] pattern project handled by the Jakarta Apache group. It consists of a framework of classes that implements a Model 2 MVC model, described in the Java Blueprints document [j2eebp], and in appendix B in this master thesis. The main ability of Struts is its comprehensive integration with the J2EE model, leveraging techniques as Java Server Pages, Java Servlets, Java Beans, Enterprise Java Beans etc.

(32)

Model 2 essentially means implementing MVC with a Servlet functioning as a controller that takes care of incoming requests, sends them to the model, and then forwarding the results to the View, represented as JSP pages. An illustration of this can be found in appendix B.

3.4.2 Overview of Struts

The MVC model in struts is built upon a framework of other design patterns. The term "design pattern" is commonly used in the IT industry, and is described thoroughly in the book "Design Patterns" [Gamma 1995].

The controller is implemented using the "command" design pattern that updates the business model through action objects that works according to the "adapter" design pattern. The action objects are the only way to communicate with the business objects from the designer's point of view, which ensures that there are strict rules for how to communicate with the application from the graphical user interface (GUI).

The view, or the GUI, consists of JSP pages with custom made tags, which are preferably used instead of adding Java code inside the JSP page.

3.4.3 Analysis results

Design and Maintainability

MVC models are usually constructed for making the maintainability of a system easier. And the same applies to Struts: It is easy to change the Views without touching the business model. The requests to the business model are nicely structured in different action objects. A problem though is that JSP invites the developer or the designer to potentially enter business logic into the view and thereby destroying the structure build up by Struts. This is especially true with projects that has a short developing time. But with discipline and well balanced projects, this hazard could be minimized, nevertheless it is a drawback. See also the study of JSP in chapter 3.3.3.

Dynamic layout

Except for separating the data from the design, there is no additional help to create the dynamic layout we are looking for in our prototype, because the JSP pages are templates that are static in nature. One solution to a dynamic layout would be to create JSP pages inside Caleigo's source code generator, but then the layout would still be static, although easier to re-generate.

Areas of responsibility

If the designer strictly follows the Struts model, he is limited to using the action objects created by the developer. The action objects can be created in an earlier stage, before the designer is introduced to the project. Using the action objects ensures that there is a rather clear distinction between the work done by the GUI designer and the developer.

From the designer's point of view

Since the view consists of JSP pages, there will be a need for the designer to have basic Java knowledge which must be seen as a drawback. Struts does alleviate some of the more advanced Java implementation with well constructed custom tags that encapsulates the model, but the syntax is not straightforward for a HTML designer.

From the developer's point of view

It seems that there are a certain threshold to overcome, but the time required to overcome it is acceptable. Since the MVC model is based upon the Model 2 MVC model from Sun, there are a lot of source materials to look into for help.

(33)

The structure enables support for larger projects. For large and complicated projects with dynamically changing views, there can be a risk that the model is too rigid.

Connections to business logic and/or databases

Struts uses action objects that wraps business logic. There exist one action object for every interaction that a client can make with the logic. Struts also helps with the interaction with a database by providing a primitive data access framework.

Learning curve/threshold

It takes some time to understand the inner working of Struts, but the threshold is not that high. The GUI designer might need to write Java code in the JSP pages if the developer has not provided him with custom made tags to access the business logic. Otherwise, the developer has to provide the designer with a business logic interface.

State handling

Struts uses the Java Session object to handle the application states for the user.

3.4.4 Conclusion

It is a popular framework on the market.

The extra functionality included in JSP is not helping us out when we want to create the flexible layout we are trying to achieve.

We believe that the design of Struts is not very elegant. It seems to have had a good start, but have become a bit bloated when problem areas have been discovered along the way. Of course our limited time to investigate these suspicions might not give Struts justice on this.

3.5 Tapestry

3.5.1 Introduction

Tapestry is an object driven model for creating dynamic web pages. It can be compared to traditional GUI libraries such as Swing, with the intent to mimic the component models. It is based upon that the designer should not need to know a scripting language when designing a web page. The method used to inform tapestry where to insert data is to add an identification to the standard HTML tags. The tags will then be replaced with content retrieved from components by the Tapestry engine when the

application is executed. The components are written by the developer to provide the page designer with data from the business logic. This makes it easy to separate the designer and developers tasks.

An example of a Tapestry application can be found in appendix D.

3.5.2 Analysis results

Tapestry systems are highly maintainable, since the separation of logic and layout is very good. Templates can be changed at any time by a designer, without having to change the components that provides the page with data, unless of course the designer wants to make fundamental changes to the logic of a page. It is a similar situation with the developer, who can change the underlying business logic, as long as he does not change the interface in the components against the templates.

The re-usability of components are one of the really strong points of Tapestry, but it requires a good component based design of pages and their subparts.

(34)

Dynamic layout

Tapestry has the potential to be able to create really dynamic layouts, with its ability to create hierarchies of components, nested inside each other. One thing that still is a bit unclear to us is if the components are dynamically exchangeable at runtime. If this is the case, the Tapestry technology would be a very promising technology for creating highly dynamic views.

The developer creates the components and gives them their abilities, he would most probably create a rudimentary template including all component functionality.

The designer can freely design the template as long as he saves the Tapestry id attributes within the HTML tags.

From the designers point of view

The page designer only need be skilled in HTML. The most likely process used to create Tapestry applications would be for the designer to get a rudimentary HTML design from the developer, with the Tapestry IDs included in the HTML tags. The designer has to be careful not to alter any tags to prevent the view logic to be changed. He would need to understand some programming logic when creating conditional loops and iterations with Tapestry, but they could be inserted beforehand by the developer. From the developers point of view

The developer needs to be skilled in Java, together with a good understanding of the Tapestry framework. The tapestry framework seems to be clean and structured, no strange workarounds or illogical statements were found at first glance.

Tapestry should be perfect for large projects, with its clear separation of layout and business logic with its component based model.

Tapestry might be an overkill for smaller projects, due to the time it takes to set up a system, but it may still be worthwhile if the project is likely to grow.

Connections to business logic and/or databases

Connections to business logic are done through Java Beans associated with components. They are responsible for the state of the component and any eventual data it holds, and are much like a GUI component in Swing, which is the component model used in Caleigo's smart clients.

Learning curve

Tapestry can be a bit tough to master, when being confronted with it the first time, but when the concepts and the design is understood, the threshold could be passed. There are a lot of configuration steps to be done before seeing the results, but from the designer's point of view, there is no problems, since he sees the resulting page, filled with dummy data, from the start.

State handling

State is preserved in two ways: Either in the Java Beans, used as value holders, or in a so called Visit object that can be created per session and can contain global data for the session. These Visit objects are created when needed and they trigger the creation of a Java Servlet Session object, used to store the data in the background.

3.5.3 Conclusion

Tapestry looks like a very promising framework to create a dynamic layout, because the components can be nested inside themselves.

Automatic generation of distributed dynamic applications in a thin client environment

Master thesis