Analyzing the implementation

The session

The multi-user functionality in the prototype, which is described in chapter 4, uses a session object that is handled by the web client and the Java Servlet engine together. It works fine in a web based

environment, and probably just as fine in a WAP environment since the WAP standard include the session concept. It probably will not work for other kind of clients that does not have the cookie concept built-in.

We have put effort in using the session object defined in the CEL framework, in order to become as independent of different session implementations as possible. At the moment, it should be possible to implement session handling using URL re-writing, which would be an even more general approach than using cookies. The problem with URL re-writing is that the URL:s cannot exceed a certain number of characters. This can become a problem when other data has to be sent in the URL together with the session ID. Cookies, on the other hand, are included in the request regardless of the length of the URL.

Introducing Servlet Filters

We have implemented the session handling functionality in the RootViewServlet. This works because at the moment all communications with web clients only goes through the RootViewServlet, as illustrated in Figure 5.7. If a second Java Servlet is introduced, it would not be part of the session handling functionality and that could seriously break the data flow in an application.

In order to avoid code duplication for session handling in the Java Servlets, another technology that has Figure 5.7: Using RootViewServlet as a communication point

been introduced since Java Servlet Specification 2.4 [jsr24] could be used. The technology is called filtering, and can be seen as components that transforms requests and responses to and from, in our case, a Java Servlet. The filter is a Java object which is registered in the Java Servlet engine to listen to certain patterns of URLs. When a client sends a request to a Java Servlet that are within the domain of a filter, the filter is invoked and has an opportunity to look at, and even alter the request parameters, before it is passed on to the called Java Servlet. The filter object would be a good candidate for containing session handling code, because it can then be invoked before all Java Servlets that are depending on a valid session to work properly. This is scenario is illustrated in Figure 5.8. It is also possible to create a chain of filters, where the request/response data are sent along the chain. This could be used to write filter modules with specialized tasks, and then connect them in a chain to get special functionality for different situations. One example is to create a user authentication filter that could be added after the session handling filter, in order to have an option to require valid users in the system.

Session timeout notification

As request-response communication is stateless, there is no implicit way for the server to know when a session with the client has ended. The solution for this is much like a watchdog functionality: If the time between two concurrent requests from a client exceeds a predefined value, the session is

considered to be closed and should be invalidated on the server. The Java Servlet Specification [jsr24] contains information of how the session timeout is defined.

The Java Servlet Specification [jsr24] also gives a possibility to register an object in the session, which, if implementing a special interface, would be notified when a session is about to time out. This object could then include code for cleaning up internal session handling data before the session for a user is timed out.

Conclusions

In order to fully analyze the session handling functionality, it would be good to have the following features implemented:

A complete user authentication module in Caleigo's frameworks. A Java Servlet Filter module

A WAP client, to analyzing the session concept further.

Although these features were missing at the time of the writing of this report, we have successfully made use of the Caleigo's Session object. This was the most important goal to achieve, because it proves that the existing frameworks can support thin clients without re-designing the code base.

The user authentication module

Partly because of lack of time, and partly because of the user authentication API in CEL being new and somewhat incomplete, we decided not to implement a fully working user login functionality for the thin clients in the prototype. Schematics of a framework was instead created, and it is presented below. Web application servers often have user authentication capabilities built-in, which adheres to the HTTP authentication recommendation [rfc2617]. There are different kinds of authentications available in a Java Web application server, such as browser login, form-based login, and login using certifications. All these can often be done using either clear-text or encrypted data channels.

Browser login means that the web browser is used to authenticate the user. When a user tries to access a restricted resource on the server, the web browser displays a login dialog box where the user must enter user name and password. When the user has been granted access, the web browser remembers the user name and automatically sends it along with every request to the restricted area. The web server, which the web browser is communicating with, then passes on the user name to the restricted resource (Java Servlets, scripts etc). This information can be used for further authentication inside the restricted resource.

Form based login is a plain server-side login method, which means that all the functionality is implemented in the server. When a client tries to access a restricted resource, the server automatically redirects the user to a login page. When the user supplies the login information on the login page, the server automatically redirects the user to the first page and displays the content. The server will then supply the correct login information to the restricted pages for all subsequent requests, until the session times out. The form-based login functionality is described in the Java Servlet Specification [jsr24], where the syntax for the login information can be found. The form-based login functionality is only recommended to use when the client supports cookies, or if secure communication using Secure Socket Layer (SSL) is used. This is because the server relies on a valid session to work properly.

In both scenarios above, encryption can be added without changing the underlying code in the Java Servlets. The encrypted communication is handled by the server and the browser. The most common encryption method on the web is Secure Socket Layer, abbreviated as SSL. It is supported by the most common browsers and all industrial-strength web application servers on the market.

Implementation

This section contains the schematics of a user authentication framework. The following prerequisites for the framework were solved in the framework:

The authentication framework should be compatible with the existing login functionality that is used by the Java Swing client.

Depending on the login information supplied by a client, different authentication modules should be used, to validate the login information.

The class diagram for the user authentication framework is presented in Figure 5.9. Below the diagram, an explanation for each class can be found.

LoginService

This class is the main class of the framework and it is responsible for figuring out whether a user is allowed to login or not. The class supports two login methods: Direct and indirect login.

Direct login is done by calling one of the three login methods. If the supplied login information corresponds to a valid user in the system, a UserInfo object is returned, otherwise the methods return null.

Indirect login is done by calling the UserInfo.getCurrentUserInfo() method. If the user has not previously logged in, the system displays a login form and asks for login information. If the user is logged in, the method returns the currently logged in user's UserInfo object.

When a user is logged in, a corresponding Session object is created and stored inside the SessionHandler.

UserInfo

This is the class that represents users which are currently logged in to the system. By calling the static method UserInfo.getCurrentUserInfo(), one gets a reference to the user who is actively using the current thread. Since many users can be active at the same time inside the system, but only one thread can be active in each processor inside a computer, calling this method ensures that the user

corresponding to the currently active thread is returned.

The getSessionID() method is not a static method and should be called on the UserInfo object. It returns the sessionID key that is used to get the Session object corresponding to the current user, from

the SessionHandler. SessionHandler

This class will, when instantiated, contain all Session objects for the currently logged in users. The LoginService is responsible for creating and destroying Session objects when users logs on and off the server.

ISession

This is, broadly speaking, a Session object. It can be used to store data that should be used during the time the user is logged in to the system. For example, the thin client prototype stores the views for each logged in user inside the Session object. When a user logs out, the views for the specific user should be destroyed in order to save system resources on the server. By storing them inside the Session object, they will be automatically destroyed along with the Session object.

ILoginHandler

This is an interface which is used by the LoginService to authenticate users. Two suggested implementations of the interface are the DataSourceLoginHandler and the WebLoginHandler. The login information, which is sent as a parameter to the "login()" method inside the LoginService, would be different in the two implementations. The login information for the DataSourceLoginHandler would be the information gotten from the form used in the indirect login method. In the case of having a Web server handling the authentication, the WebLoginHandler would instead be used. The login information would probably be an object descending from the "javax.servlet.HttpServletRequest" object, which contains the authenticated user's login name. This name could then be used to do an extra lookup inside the login framework, in order to see that the user actually exist inside the database. The LoginService decides which implementation of the ILoginHandler to be used to authenticate the different login informations. It does this by checking the internal list of login handlers, and it uses the class of the provided login information object to find the matching login handler.

ILoginInfoProvider

This interface is used by the LoginService to ask the user for login information when the indirect login method is used. At the moment, this functionality is only used by the smart client and it uses a Java Swing dialog, which implements the ILoginInfoProvider, to get the login name and password from a user.

5.7.2 Conclusion

It is kind of a tricky business to map the Java Servlet Session object to the CEL Session object in a general way. The code that is responsible for handling this mapping can not easily be included inside the CEL framework, since it relies on the web server. To avoid code duplication in each and every Java Servlet exposed to the users, the Java Servlet Filter technique would be a nice solution for handling the session functionality.

This means that badly configured web applications can have servlets that does not include the necessary functionality to handle sessions. It maybe is not such a serious issue, but the person responsible for deploying the application needs to be aware of this.

On the positive side, we have shown that is is possible to have a session object that is shared between the smart and the thin client.

The user authentication framework unfortunately did not got implemented in time to be tested in the prototype during the finish of this report. The framework has been peer-reviewed and approved by Caleigo, and it will probably be implemented at a later stage of the prototype project.

We suggest that the future Caleigo Foundation Web Builder product optionally make use of the user authentication functionality in web application servers to authenticate users, since most authentication work would then be done in the server.

6 Goals revisited

This chapter consists of the summary of this master thesis. The goals defined in chapter 1.2 are presented, together with conclusions of how far we came to reach them.

Market Analysis

The first goal was to create a market analysis of existing web technologies that might be used inside the prototype. The goal was to find technologies that could help us with building dynamic views that resembles those found in the smart client. We chose to use the source code generator called Gen, which is used internally in one of Caleigo's frameworks, to generate the dynamic views.

Develop a prototype

The development of the prototype was our second goal. It would hopefully give an answer to whether that dynamic views could be generated inside a web browser using a web platform. The resulting prototype proved that it is actually possible to achieve a rather high degree of flexibility and

adaptability in the resulting views. Unfortunately we did not have the time to implement all concepts used in the dynamic views found in the Java Swing client, but we feel that the most important parts are there.

Distribution technologies

The third goal was to introduce automatic generation of a distributed web application server. With the help of the Enterprise Java Beans technology, we were able to reach this goal in a rather general approach, by introducing EJB in the data service layer. We also concluded that EJB could be introduced in other areas, were some solutions would be viable for special use cases of the Caleigo technology platform.

Analysis of the prototype and surrounding technologies

The analysis part of the master thesis is intended to go more deeply into the different areas in the prototype. Answers to questions like "did the prototype provide expected results", "can it be used to construct applications that differs from, or is more specialized, than those currently generated by the Caleigo Foundation Builder" and "is this a viable platform to build a Caleigo Foundation Web Builder from" should be answered.

The prototype was analyzed by looking into the following criteria: Functional similarity to the Java Swing client

Our goal was to have the same or similar functionality in the thin client as existing in the Java Swing client. The browser environment with its limited layout capabilities was the major obstacle for the success, but the basic functionality is in place. From there it is all up to what layout functionality the thin client platform provides.

Our market analysis showed us some technologies that looked more promising than template engines for using when creating the dynamic layout in the prototype. As we started to think about how we should go through with it, we realized it actually could be done with templates. The solution was interesting and seemed to be working. The drawback with using the Gen technology is that it can be hard to debug a web application, since there is no debugging-tool available today.

We also posed the question if the solution with iterative templates to create the dynamic layout is limiting the freedom of the users to create other kinds of layouts, which might be needed for different types of web applications. We found that changing the layout could be done by either create new types of views, or by introducing the concept of views having many templates registered within. The latter solution would then include some logic for choosing which template that should be used for different states in the application.

How well does the prototype handle concurrent users

The important goal here was to try to use the existing session handling functionality in a Caleigo Foundation application as far as possible. We managed to support multiple users by instantiating views

per user. The analysis phase concluded that the existing framework was not fully implemented, but we could see that our implementation was working. Schematics of a user authentication framework that would extend the existing smart client authentication scheme was also created.

How well does customization work with the prototype

We analyzed this question by setting up a use case scenario. From this we found that there were some lack of functionality that needs to be implemented in order to have a complete solution for

customization. However, there is nothing that indicates that it is impossible to add the missing functionality. Hence, we concluded that customization is possible for the prototype.

Is the prototype actually distributed

By using the proposed Java framework for making distributed applications, namely EJB, we managed to find different places in the architectural level inside the frameworks of Caleigo where we could introduce EJB. An example of a data source which was wrapped inside an EJB, together with a client that could communicate with it was implemented.

The web service concept, which could be seen as a way of distributing the application was looked into. Due to lack of time, we did not perform any practical tests on the technology, however it looks promising and should be a good candidate to explore further, although it lacks some vital features to be introduced in all layers of the Caleigo framework.

Obvious performance issues

The prototype was somewhat slow when there was a lot of data on screen. We did analyze the situation, and came up with a few solutions.

6.1 Final conclusions

We conclude with the fact that we were successful with the goal of implementing a functional prototype. A major reason for the success is our choice of methodology. Starting out with a market analysis, followed by a first attempt to solve the problem gave us practical insight of problem areas. These were analyzed and corrected in an iterative manner, which also gave us the needed knowledge of the Caleigo technology framework.

We hope and believe that the prototype will be used by Caleigo as the base for their next product, the Caleigo Foundation Web Builder.

Appendix A

Northwind

Northwind is the database structure we have chosen to demonstrate all database related functionality in the master thesis. It origins as a test database in Microsoft SQL Server, and demonstrates many important aspects of a table structure. The schema for Northwind can be seen in Figure A.1

Northwind models a trading system, with customers, employees, orders etc. It is good for educational