Automatic generation of distributed dynamic applications in a thin client environment

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

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). 2

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

Table of Contents 1 Introduction...6 1.1 Client-server concepts...6 1.2 Objectives...7 1.3 Methodology...7 1.4 Analysis criteria...8 1.5 Document outline...8 2 Technical background...9 2.1 Introduction...9 2.2 Caleigo technology platform...9 2.2.1 Caleigo Foundation Builder...9 2.2.2 The Framework...13 2.2.3 More about the CEL layer...15 2.3 Web technologies in Java...16 2.3.1 Java enabled web servers...16 2.3.2 Java Servlet...16 2.3.3 JSP...18 2.4 Distributed programming in Java...19 2.4.1 History of Distributed Systems...19 2.4.2 Distributed programming in Java...21 2.4.3 Fundamentals of EJB...21 2.4.4 Example...22 3 Market Analysis...28 3.1 Introduction...28 3.2 Analysis criteria...28 3.2.1 Definitions...29 3.3 JSP...29 3.3.1 Introduction...29 3.3.2 Analysis results...30 3.3.3 Problems with JSP...31 3.3.4 Solutions to some problems...31 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 4.2.5 Prototype design conclusions...50 4

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 5

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 thinclient 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. 6

1.2 Objectives Caleigo was interested to see if it was possible to create thin-client 1 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. 7

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. Chapter 6 presents a conclusion of the master thesis. 8

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

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. Figure 2.1: Specification of connections settings 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 10

presentation of how it works. Figure 2.2: Configuration of meta data 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. 11

Figure 2.3: Specification of where generated files should reside. 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. 12

Figure 2.4: Finished application 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 patterndriven 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. 13

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. Figure 2.5: The Caleigo framework 14

Figure 2.6: Application modified at runtime 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. 15

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: package hello; 16

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) throws ServletException, java.io.ioexception { processrequest(request, response); } /** Handles the HTTP <code>post</code> method. 17

* @param request servlet request * @param response servlet response */ protected void dopost(httpservletrequest request, HttpServletResponse response) throws ServletException, java.io.ioexception { 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> 18

</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. A system like this is referred to as a 3-tier system, and is much easier to modularize. Changes in the 19

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

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

Figure 2.7: The home and remote interfaces existing on client and server and communicating via RMI 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 { 22

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) { id = newid; 23

} 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. 24

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 25

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

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

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? 28

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 29

[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 Design and maintainability 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. Areas of responsibilities 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. Demands on skills 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. 30

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

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. Demands on skills 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. 32

Feasibility for small and large projects 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 Design and maintainability 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. 33

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. Areas of responsibilities 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. Demands on skills 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. Feasibility for small and large projects 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. 34

The templates are free from scripting language codes, and they are filled with dummy data where the dynamic content should be inserted. This enables the designers to emulate the finished result inside their page creation tools. Tapestry is an open source project, for good and bad 3.6 XMLC/Barracuda 3.6.1 Introduction XMLC "Enhydra XMLC is an XML compiler that converts document templates, including HTML, chtml, WML, XHTML, and custom XML, into resources that can be directly accessed from a Java program using standard DOM manipulation syntax." [xmlcp] The document formats listed above all contains markup languages. A markup language adds extra information to text by encapsulating the text in question with elements from the language. HTML is used for adding layout information to a text, XML is a generalized language that can be extended with user defined elements. XMLC makes use of the fact that all markup languages above has a way to identify part of text, by adding an identification parameter to the markup language element. An example of an HTML document, with the ID parameter, is listed below: <H1 id="header">welcome to this page</h1> <DIV id="text">it is under construction at the moment</div> In the example, we see plain text with the elements H1 and DIV surrounding parts of the text. The elements are used to tell a web browser how to render the texts within. The identification parameter is ignored by the web browser. When XMLC parses the example above, it identifies all parameters that includes the identification parameter. After compilation of the page, a resulting Java class is created which is an object oriented representation of the text document. The class contains methods for manipulating the text it represents, together with special help methods for accessing the text parts containing the identification parameters. The class conforms to the Document Object Model (DOM) interface [DOM1], which is a standardized way of how to represent documents with objects. The XMLC technology aims at separating the UI design from the business back-end to an extent that designers will not have anything to do with the data flow and content. The designer would only have to add the identification parameter in the document where dynamic content from the application should be inserted. The developer works with a Java object which represents the complete document. He or she uses the methods in the object to add, modify or remove content, which makes the developer more or less unaware of the look of the document layout. XMLC gives: A well-formed XML / HTML documents No custom tags are included in the document A well defined line between design and logic XMLC does not give: An abstract way for providing the document with dynamic information An MVC model to provide ways for the layout to alter the state of the application 35

The Barracuda project XMLC does not supply the developer with any other functionality than compiling a text document into a Java object representation. To be able to create an application, there is a lot of other things required, such as an MVC model to add interactions to the layout, for altering the application state. Some framework for handling the dynamic content in the Java object compiled by XMLC has to be created, otherwise the developer needs to change the code every time the designer changed the structure of the page. The Barracuda project consists of different kinds of frameworks that could be used as front-ends to the XMLC technology. For example, there is both an MVC model and a template engine which both could be used to help the developer to create applications based on XMLC. The Barracuda project also contains a collection of objects that helps with rendering HTML. They exist to help the developer with adding dynamic content from the application that should be rendered as HTML on the client. 3.6.2 Analysis results Design and maintainability The GUI designer has to write well structured HTML documents. He or she adds the identification parameter to all markup elements where dynamic data should be inserted. The developer gets compiled Java objects from XMLC and uses other tools, for example Barracuda, for creating an application framework that interacts with the Java objects generated by XMLC. The maintainability for the designer is very straight forward, there are no special tags in the HTML code, all tags are conforming to the HTML standard. He has to rely on developers to populate the document with data, but he can add dummy data to emulate the finished look of the application. Due to lack of information about how to get Barracuda up and running, we could not evaluate the ease of maintainability for the developer. Presumably, the developer has to be skilled in object oriented software creation even though Barracuda promises to help. Dynamic layout XMLC gives great flexibility in the layout because the complete document is accessible on server-side, as a Java object representation. The document can be altered by adding, changing and removing nodes and entities at those nodes marked with an identifier in the document. The way to alter the nodes are standardized according to the Document Object Model interface [DOM1]. Areas of responsibilities The designer is responsible for the layout of the document, which will be used as a template for the developer. The designer can add temporary data to the document to emulate how a complete layout would look like. This means that the designer does not need to know any Java to produce layout that provides dynamic layouts. The developer does need to be engaged with generating layout data, since he is responsible for adding dynamic content to the layout page. The Barracuda project contains a collection of Java objects that represents HTML elements. The developer can feed these objects with dynamic data and then let them render the corresponding HTML code by calling the rendering method. Although they make it easier for the developer, he still need to be concerned with layout issues. Demands on skills The designer has to understand the importance of writing documents that conforms to the DOM standard. Knowing how to write well-formed documents is often a required skill for web designers due to the need to do so for other technologies to work. The document designer does not have to know anything about the underlying business logic and data flow. The developer needs to have a high level of competence in the DOM standard and how to write well designed web applications, even though the existence of the Barracuda project. This is because both XMLC and Barracuda are highly ambitious projects, using very high levels of abstractions in the interfaces. It is not intuitive how to connect the projects together, and things can be done in many 36

ways. Another factor that makes it even harder to develop anything using these technologies is that the documentation found on the Barracuda homepage is limited at best. Feasibility for small and large projects These technologies are probably best suited for really big projects that requires a clean design and strict rules for how to create content. It is not suited for smaller applications, since it is very hard to get started, and it requires a lot of object oriented analysis to create a framework for how to deliver data from the business logic to the clients. Connections to business logic Since the document is compiled into a Java class, the developers have complete access to what flexibility Java provides. Real-time configuration of the views, like in the Swing clients, should be possible to do in a a highly dynamic fashion. Learning curve / threshold The learning curve for the developer is very high, due to the reasons described above. State handling. The state is handled by the frameworks in the Barracuda project, but even the document itself keep a level of state, since it is a Java object on the server. 3.6.3 Conclusion Both technologies in conjunction looks promising for larger projects. If the level of the documentation improves for the Barracuda project, it could be interesting to look further into these technologies. 3.7 Velocity 3.7.1 Introduction Velocity is a template based scripting language, created by the Jakarta-Apache group [jakvel], well suited for adding dynamic data to static templates. It has built in functionality for creating dynamic web pages. Velocity can effectively replace JSP, Servlets and other HTML producing technologies. One of the major benefits of Velocity is that it does not mix code with design and the scripting languages are easy to understand. The templates can only use objects that are given to them via the context object, which prevents access to other objects on the server. Compared to JSP, Velocity is more dependent on an existing framework for handling the flow of the system. The benefit is that the programmer can focus on the business logic and interface with the page designer by creating objects that are sent to the context object. The designer can then use the objects that are registered in the context to build up the presentation layer without necessarily involving the developer. Velocity does not solve all aspects of the MVC model, so it should be combined with a framework that helps it with that issue. Turbine is an MVC model project, handled by the Jakarta Apache group, that integrates with Velocity. When answering the comparison areas, we assume that we connect Velocity with a Model 2 MVC framework and use Velocity to represent the View. 3.7.2 Analysis results Design and maintainability If a Model 2 framework is used, the system design is very nice and clean. The Velocity framework helps with making sure that no Java code and business logic are allowed inside the pages. There are simple conditional loops and data flow logic within the Velocity scripting language, but there is no direct access to Java objects on the client side. The drawback of this design compared to for example 37

component based frameworks, such as Tapestry, is that it is not as flexible when it comes to very dynamically changing views, where you can at runtime add/remove and move components within the page. Dynamic layout As all other template languages used together with Model 2 like models, they are not very good for views with dynamically changing layouts. Templates together with a component based framework supports this better. Areas of responsibilities. The designer is limited to use 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. Demands on skills Designer : Probably the easiest of all template technologies to use for the designer. As long as he knows how to make a request to the controller and what requests he can do, as well as knowing what data he will get back after a request, all he have to learn is the six directives, described in appendix E. Developer : Depending on the complexity of the MVC model, it will take the developer some time to get to know it, but the template parsing should be very straightforward to comprehend. Knowledge of Java and knowledge of how a MVC model works is otherwise sufficient. Feasibility for small and large projects. The technology works well for both small and large projects, because the velocity templates forces the views to only present the data given to it by the model via the controller. This ensures that the project does not get bloated in the views with time. The drawback comes when the pages changes dynamically. To accomplish this, the developer has to write the functionality outside the model, which might lower the maintainability and with that the feasibility of the project. Connection with business logic The business logic is made accessible by registering objects in the context. Learning curve. Easy to master for the template designer. No Java knowledge is required, only HTML and velocity scripting language. The developer needs to understand the Velocity engine. State handling The state handling is done using the context, and the objects residing within. 3.7.3 Conclusion It is not directly suitable for use in the prototype to create dynamic views. 3.8 Conclusions from the prestudy While performing the prestudy of the technologies available on the market, we noticed that the source code generator that exists in Caleigo's frameworks has the same characteristics as other template based engines. Analyzing this issue further showed that there were no features existing in the other technologies that would rule out using the source code generator as a template engine. When discussing this with the developers at Caleigo, they thought it was an interesting idea and we 38

finally decided to create the presentation layer of the prototype using the source code generator, called GEN. We also decided to perform an analysis of whether it would be possible to use JSP as a template engine, since it is a de facto recommendation to use in Java Enterprise applications. The result of the analysis can be found in chapter 5.3.2. 39

3.9 Comparison chart Comparison JSP Velocity/Model2 Struts/JSP Design & Maintainability Dynamic layout Area of responsibilities Demands on skills Feasibility for large and small projects Connection with business logic Learning curve State handling Company / License model Because of the possibility to include, and in some case, the necessity to include, Java code can really break the distinction between design and data. The language itself does not help with dynamic layout, other than rendering the JSP tags. Responsibility separations can be possible using custom tags Designer : Might have to know about Java to perform certain operations in the HTML page. Developer : Need to create an MVC model 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. JavaBeans together with Taglibs could be used to wrap the business logic. Designer - depending on the availability of tags, otherwise knowledge of Java is needed. Normal Session handling, nothing extra. Sun / Sun Community Source license 2 Good for Static systems,clean separation of layout and code. Better for static systems where pages does not change much. Designer : Page layout and presentation of data. Developer : Create the Actions that interfaces to the business logic. Designer: HTML and simple velocity directives. Data/code separation makes it usable for both. Actions wraps the business logic. Designer : Easy, only a few velocity directives to learn Developer : Depending on the Model 2 complexity Normal Session handling, nothing extra. Jakarta / Apache Software License 1.1 3 Price free free free Market share big small big Design is a bit bloated. Separation of code and layout is sufficient but can be violated. See JSP. Better for static systems where pages does not change much. Designer : Page layout and presentation of data. Developer : Create the Actions that interfaces to the business logic. Designer : HTML and possibly basic Java knowledge. Data/code separation makes it usable for both. Actions wraps the business logic. Designer : May need some Java knowledge. See JSP. Developer : Design of Struts is a bit bloated, takes some time to master. Normal Session handling, nothing extra. Jakarta / Apache Software License Standards used JSP, Java HTML, Java is de facto standard 2 http://wwws.sun.com/software/java2/license.html 3 http://www.apache.org/license 40

Comparison XMLC Barracuda Tapestry Design&Maintainability Very clean separation of layout and business logic Includes a powerful MVC model and uses a clean separation of layout and business logic. Components for rendering HTML Dynamic layout Truly dynamic Truly dynamic, needs more investigation Area of responsibilities Demands on skills Feasibility for large and small projects Connections with business logic Learning curve State handling Company / License model Designer : Page layout Developer : Create frameworks, data flow etc Designer : very low Developer : very high, professional architect Useless in itself, probably suitable for larger projects together with an MVC or template framework. No help for accessing business logic Designer - Easy, only HTML Designer - Very high No state handling, other than the document itself Open source / Enhydra Public License 4 Designer : Page layout with components Developer : Use the MVC model Designer: low Developer : high, good knowledge of frameworks Probably suitable for larger projects. Event driven MVC model Designer : Easy, need to know about the components Developer : Need to understand the barracuda framework Do not know yet Open source / Enhydra Public License Price No cost No cost No cost Very nice design and separation of code and data makes maintainability easier. Potential for creating truly dynamic layout and changing it runtime. Designer : Page layout Developer : Create components and attach them via Java beans to business logic Designer : very low Developer : Java and a good knowledge of Tapestry Good for large projects because of design Maybe not so good for small projects because of overhead. Java beans connected to components handles business logic Designer : Easy, only HTML to learn. Developer : Takes time to grasp Tapestry fully. Worthwhile for larger projects. State stored as Java beans connected to components, and as Visit Objects for session global data Open Source / LGPL 5 Market share Very small Very small Very small Standards used DOM, HTML DOM, HTML, Java XML, HTML, Java 4 http://xmlc.enhydra.org/software/license/index.html 5 http://www.gnu.org/licenses/lgpl.txt 41

4 Prototype 4.1 Introduction The prototype is the implementation work of the master thesis. After researching technology areas that are explained in chapter 2 and 3, we now have sufficient background knowledge to start designing a solution. This demands a proper definition of the objectives of the prototype. A brief description of the objectives are covered here, and they will be further refined in this chapter. Implementation of a dynamic web client The goal is to create a web client that has a similar behavior as the fat client, also known as the Java Swing client. The view structure designed by CEL should be reflected in the web interface. This is the major goal for the web client. Other objectives are also: Implementing client request handling. Implementing session handling. Automatic generation of code. All these goals are covered in detail in section 4.2. Implementing a distributed way of connecting to a CEL application The objective is to design a way to make an external Java Swing client with full CEL capabilities to use another CEL application as its storage facility. This makes it possible for both web and Java Swing clients to use the same CEL layer simultaneously. By using EJB:s (covered in chapter 2) as the intermediary layer, we can also enable non CEL clients to access the data. We basically need to develop the following functionality: Automatic generation of an EJB layer from a database. Implementation of a DataService that connects to the EJB layer. This is covered in detail in section 4.3. 4.2 Implementation of a dynamic web client The thin client is supposed to use HTML as its user interface. Hence our code generator should create an application that does this. Caleigo Foundation Builder already generates the code for the Java Swing fat client application. Parts of the result of running Caleigo Foundation Builder on the Northwind example database (see Appendix A) can be seen in the listing below: /northwindapp.html /northwind /northwind/client/northwindapp.java /northwind/data/customerentity.java /northwind/meta/customer.java Caleigo Foundation Builder creates a number of files organized in a directory structure. These files contains the generated source code that is unique for the generated application. NorthwindApp.java is the starting point for a Java Swing application and it is generated with the correct database settings, and references to the created code. CustomerEntity.java and Customer.java is the Java objects that encapsulates data and meta data from the customer table. NorthwindApp.java is the code we want to replace with automatic generated Java source code for web clients. 4.2.1 Solution for the dynamic view structure There is a need for a mechanism to dynamically alter how data is viewed on screen. The tool also needs to be able to reflect the hierarchical nature of the CEL structure. As explained above, the view 42

structure used in Java Swing should also be applied to web client applications. Caleigo Foundation Builder is described in chapter 2, and together with it an illustration of how a finished application could look like (see Figure 2.4). This illustration reveals the following necessities: First off, there is a Root view. This is the view that is basically the whole window area and it should contain all other views. After this there are the tabs that cover all tables in the database, one tab per table. These tabs are logically placed right below the Root view. These tabs in turn contain a setup of windows/views. At the left there is a selection view with a list of entities. At the right there is a view displaying the current entity and under this view, there can be one or more slave views. Inside the entity view for example, is a view for every field, encapsulating a field-descriptor. Note that this setup is just the default structure, and can at any time be modified via the very capable user interface. This structure can be written down as: /RootView /RootView/MasterView(of a table) /RootView/MasterView/Selection View /RootView/MasterView/EntityView /RootView/MasterView/EntityView/FieldView /RootView/MasterView/EntityView/FieldView /RootView/MasterView/SelectionView(Slave View) We need a hierarchical solution to this problem. The solution should also be based on the MVC framework (See Appendix B), since it should mimic the Java Swing framework as close as possible. We realized, during the market research that we could possibly use one of the already existing tools that Caleigo has created, namely Gen, to produce these views on demand in the application server. 4.2.2 More about the view layer We have two major type of views: Application specific views and structural views. Looking at our view structure above we have the following views: Application specific views The application specific views are used for defining the rules of how a specific application should look like. In our case, the first view that will be called when the prototype is initialized is a view called the Root view. The second view used in the application is the Master view. The Root view encapsulates the application and the Master views group together related views in one view. Structural views Structural views are views that encapsulate an element in the CEL meta data tree. The most used types of views are: Entity views: They encapsulate both an entity descriptor and a proxy entity. They also contains several field views, one for each field descriptor that belongs to the entity descriptor. Field views: They encapsulate a field descriptor. The field views contains all information about how to display a field, such as information about the prefered size on the field, the default value of the data, whether the data is read only and so on. Selection views: They encapsulate an entity descriptor together with a selection of entities that are of the entity descriptor type. They also contain field views for all fields for the entity descriptor. Qualifier views: They contain a view to a qualifier, which is a tool for filter data. All views in the prototype implements the following interface: package com.celgen.celview.web; 43

import java.io.writer; import java.util.hashmap; public interface IWebView extends com.celgen.celview.iview { public void produceview(writer writer); public String getid(); public void handlerequest(hashmap parameters); } public String gettemplatename(); The method "produceview()" is called when the view is to be displayed in the thin client. The method is responsible for sending output to the writer object, which is given as parameter to the method. The writer object would typically be connected with the output stream of the Java Servlet, which in turn is used to send the data to the thin client. The sent stream will in our case be HTML-formatted. The code inside the "produceview()" would typically create the HTML output by calling Gen and provide a specific template file as a parameter. Which template file to use is decided by calling the "gettemplatename()" method in the view. Along with the template file parameter, a property object is provided which is used by Gen for accessing dynamic content from the view. In this way, we can retrieve all data the view encapsulates at parsing time of the template. Using this scenario, we let the template handle layout and content in the output stream and the view object keeps a reference to the data. All views are used as controllers as well. The "handlerequest()" method takes input parameters and acts upon them. The requests are most often coming as a request as specified in the templates. All views have an unique ID that is used to retrieve the correct view in a view lookup service. The necessity of this is obvious if we look on how we have solved the request handling. The template engine concept In order to understand how Gen works, a short description of the concept of template engines is presented. A template engine uses templates, which describe how and where data should be displayed on a client. Templates, in general, consists of: Static content, which looks the same every time the template engine renders the view. Placeholders for dynamic content, which, when after being rendered in the engine, will be replaced with the data it represents. Program logic, to be able to create loops, conditional statements etc. The template engine parses the template and creates a data structure from it, according to the program logic inside the template. The static content in the template is replaced with static strings. The placeholders are replaces with handlers to objects, according to the instructions in the templates. When telling the template engine to render the template, it walks through the data structure and either writes static content directly to the client, or descends into objects through the registered handles and fetches the data from the object and render it on the client. The objects has to implement some kind of interface in order to make the template engine able to access the data. Gen Gen was developed by Caleigo to be the module that generates the Java source code when creating an application. Gen is a template parser, which is the application that does the job with generating the 44

resulting output from the instructions inside a template file. One important feature in Gen is the ability to parse other templates inside a template by using the "#INSERT" directive. A simple example of this is presented in the template example below: #DEFINE TestTemplate(data)##WS# <html> <body> #PROP(data.Hello)# </body> </html> #ENDDEF# #DEFINE The "#DEFINE" tag defines the boundaries of the template and also gives a name to the property to use when rendering. Gen reads the template and looks for parsing directives. A directive is a known command that Gen must act upon. Important directives are listed below: #PROP This directive is used to specify that dynamic content is to be inserted. The dynamic content is retrieved from the property that is specified in the "#DEFINE" tag. #IF #ELSE This is a conditional directive, it makes a decision depending on the outcome from the expression inside the "#IF" clause. #REPEAT This is a looping directive. The text inside the loop clause is parsed while the condition inside the "#REPEAT" clause is met. #INCLUDE This gives the ability to include another template inside the parsed template and also supply it with a data object. This is very useful considering our hierarchical structure of views explained above. In order to illustrate the complete process of displaying the content of a template in a web browser, a simple schematics is presented in Figure 4.1. It illustrates of how views, templates, Gen and a Java Servlet works together to create a HTML document on the web browser. The Java Servlet Figure 4.1: Putting it all together The entry point for a thin client to the application is a single Java Servlet called "RootViewServlet". It functions both as producing output to the client and accepting input. The Java Servlet concept is 45

presented in chapter 2. In order for the Java Servlet to produce the output of the whole application, it simply needs to maintain a reference to the Root view and call the "produceview()" method inside it. Below is a listing of the most important parts of the Root view template: #DEFINE RootView(view)##WS# <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/tr/html4/loose.dtd"> <html> <head>...... Setup of stylesheets, left out for easier reading... #INSERT javascripts(view)# </head> <body> <table width=100% height=600 border=0> <tr> <td valign=top> #INSERT compositeview(view)# </td> </tr> </table> </body> </html> #ENDDEF# Note: Most templates can be found in Appendix C. The view parameter is a property that is a link to the RootView object. If looking at the structure of the property it can be seen that it includes references to all master views in the application. The RootView object extends a class called CompositeView, which is a view that can contain other views. As seen in the template, there is a directive that includes a template called "compositeview" via the "#INSERT" directive, with the root view object as parameter. The "compositeview" template is a generic template that can be used with all views that extends the CompositeView class; its main task is to handle positioning of nested views, which are child views registered in a parent view. When looking at the constructor of the RootView class it can be seen that all master views have been positioned in the center view and this means that there are multiple views on a single position. The default behavior of composite view is to handle views that are in the same positions as tabs. This is done by creating a new view type class called a TabView, and it has a corresponding "tabview" template that renders the HTML for it. This structure solves our hierarchical problems, and we can create a dynamic application with a view that reflects the database, but we still need to handle the issues with request and session handling. 4.2.3 Request handling Request handling is about giving the user the ability to interact with the system. This is accomplished by giving every view object a unique identification number (ID). When a view is created, it is given an ID by a dedicated lookup service. This ID is mainly used to enable request handling from the thin client to the server. Since the views also functions as controllers, it is important that whatever the user does in the thin client is sent to the controller on the server. The requests data that comes from the thin client when the controller is to be updated contains the ID for the specific view that corresponds to the view that is displayed on the thin client. The ID is used for getting the view from the lookup service so that the RootViewServlet know which server to send the request data. 46

When the correct view object is returned from the lookup service, the RootViewServlet calls the "handlerequest()" method inside the view, with the request data supplied as a parameter. This request data is used in the view to take the appropriate actions. 4.2.4 Concurrent users In this section we look into the issue of having many thin-client users accessing a server. Since thin clients often have limited capabilities of storing application states, it is the responsibility of the server to provide the multi-user functionality, which among other things means creating unique views for the users and keep track of the application state for each concurrent user. This is opposed to the fat clients, where it is up to the clients themselves to create the views for the users. The server in the fat client scenario only acts as a data provider for the clients. Even though the server provides the multi-user functionality for the thin clients, it still needs to know which clients that are connected to it in any given moment. The reasons for this are: When a request for displaying a view on one of the thin clients has arrived on the server, it needs to know which client that has made the request and where to send the layout information. When a client requests that the application state needs to be changed, the server needs to know which client it was that made the request in order to change the correct view. In order to be able to save system resources on the server, it needs to be informed when clients connects to it and when they log off. Often views and client-specific applications will be loaded into memory only during the time the client is connected to the server. The important thing is that the server developers has the opportunity to optimize the server behavior if they can rely on that the clients notify when they connects or disconnects. The issues above are normally easy to implement when the thin clients are connected to the client during the whole session. This is the case when the clients are dumb terminals, fat clients or something alike. Clients that communicates according to a request-response model, such as web browsers and WAP clients, need to be handled differently. In the request-response model, the client itself decides when it needs information from the server, or when it needs to send new directives to the server. The client handles this by first connecting to the server to set up a communication channel. After the connection is established, the client sends request data to the server, where the request data contains information of what resource to access and what to do with it. The server processes the request and sends back response data to the client. When the data has been fully transmitted to the client, it processes the response and finally disconnects from the server. There is no implicit state on neither the client nor the server between two concurrent requests. In this scenario, the server can not rely on the active communication channel, since the client connects and disconnects every time it sends new instructions to the server. Currently the only way to solve this problem is to introduce explicit state handling. One way of implementing a stateful client-server solution with a thin client could be to send the state data in the request to the server. When the server is done processing the request, it would then send the state data back to the client for storage until next request. This was actually the only option available to programmers back in the days of 1996 when web browsers only supported the HTTP 1.0 protocol [http10], not counting URL re-writing, which is presented in the next section. In our experience, the solution of having the Web client responsible for keeping track of the application state has two major drawbacks. The first thing is that it doesn't take long until the program logic is very hard to understand, since state variables are bouncing back and forth between the client and the server. The data has to be stored as a sequence of characters in the client, which means that a lot of data translations occurs in the server. The other, and maybe more serious issue is that some of the internal logics of the server is exposed at the client. It is very possible for a user to alter the states of the application by sending fake requests to the server. 47

The session The solution for implementing state on the server was rather cleverly made by using the cookie functionality in the web browsers. A cookie is a small storage for information, which will automatically be sent to the server that put the cookie on the client for every request the client makes. When a client connects to the server, it checks if the cookie exists. If no cookie is set on the client, the server consider the client to be part of a new session. It calculates a new session ID and stores it in a new cookie, which will be sent to the client in the response data. The client is considered to be part of the session for every other request, until the cookie is removed, or the server invalidates the session [rfc2965]. A session can also be created using something called URL re-writing, which means that extra data automatically will be added to the address used by the client to contact a server. As long as the client sends the extra data in the address, the client will be part of the session. Below is an example of URL re-writing: An example of an URL that a client uses to contact a server: http://www.someserver.com/servlet/main This is the URL that will be used after URL re-writing made in the server: http://www.someserver.com/servlet/main?jsessionid=12345 Java Servlet engines give even more functionality to aid the programmers than just automatic session handling. One important thing thing is the session object, which is an object that works in conjunction with the session. Java Servlets can use this object to store session-bound data that should only exist during a session. We use this session object in our prototype of Caleigo Foundation Web Builder to store references to objects. To wrap up the session and cookie functionality: The concept can be seen as an extension to the stateful client. The difference is that instead of storing all states at the client, the only state needed to be sent between the server and the client is the session ID. Implementation Our approach for solving the multi-user problem was to store the views for a user in the session object, since the views should be unique for each user, and they should only exist during the time a user is connected to the server. We decided to use the session object that exists in the CEL package in order to use the same session management functionality for all types of clients. The most important objects used to provide the multi-user functionality are: UserInfo ViewCache SessionHandler Session AbstractView HttpSession RootViewServlet Object Description Contains user information about the current user. A data container, used to store views. Stores all active sessions in the application. Session objects can be retrieved by supplying the UserInfo for a user. The session object used in CEL The base class for all views in the Caleigo Foundation Web Builder prototype. The session object used in Java Servlets The Java Servlet that is responsible for the communication between the server and web clients. 48

How everything is connected The initial connection The first thing that happens when a web client connects to the server is that a new session is created. The RootViewServlet is the access point for clients when they communicate with the server. Whenever the Java Servlet notices a client with a new session, it creates a new UserInfo object and registers it in the SessionHandler container. At this point, it is possible to retrieve the current user, which is the UserInfo object, from the HttpSession object, and use the current user to fetch the Session object from the SessionHandler container. These events are illustrated in Figure 4.2. Figure 4.2: Illustration of an initial client connection When the session is created, the Java Servlet continues with creating the RootView, which is responsible for building all other views in the application. These views will then be unique for the session in question. While the views are created, the AbstractView class, from which all views inherit, ensures that all views get registered in the ViewCache. All views also get a unique ID from the ViewCache, when they are registered. The ID is used as the key when asking the ViewCache for a specific view. There is one ViewCache per session in order to ensure that all users get unique views in the system. Working with views The views on the thin client are only a rendered version of the views on the server. When the client needs to update a view, it sends directives to the RootViewServlet together with the view ID used as a the key for the view in the ViewCache. The RootViewServlet gets the UserInfo object from the HttpSession and use the user object to get the Session object from the SessionHandler. The Session object contains the ViewCache which contains all views that are registered for the specific user. When the RootViewServlet finally has a reference to the cache, is uses the supplied view ID to get the corresponding view. It then passes the directives from the client to the handlerequest() method, which has to be implemented by all views in WebGen. When the view is done processing the directives, the RootViewServlet sends back response data to the client, where the response data contains layout information that the client uses to render the views. The relationship between the different objects and the containers are illustrated in Figure 4.3. Figure 4.3: The relationship between objects in the session 49

The authentication framework The authentication framework is connected with the session functionality in the way that before a session is created, the user must authenticate him- or herself. In the fat client, this is done by displaying a login form to the user the first time the user information is needed. This approach does not work with thin clients that does not support servers that pushes out information to the clients. Web clients would have to constantly pull information from the web server in order to implement this kind of functionality. Our approach uses the browser authentication login functionality, which is explained in section 5.7.1, to provide the user login information to the server. It basically means that the web browser asks the user for login information and uses this to actively login the user from start. After a successful login attempt, the web browser remembers the login information, which it automatically adds to the request data every time a resource is accessed on the server. Unfortunately the authentication framework on the server relies on that it can initiate a login request itself. There is currently no suitable way in the existing authentication framework to login a user and provide the login information at the same time. Section 5.7.1 presents some possible solutions to this problem by extending the authentication framework on the server. 4.2.5 Prototype design conclusions We spent a lot of time sorting out how the parsing of the templates should work. It is not perfect yet, but the idea proved to work out rather well, because of the hierarchical nature of the system. We used Gen as the template engine and was satisfied with the result. We could have used other template engine, however Gen suited us very well because it already was integrated with how CEL is working. Web client prototype summary Functionality Here, we list features that are fully implemented in the prototype. The prototype implements the basics features of a Caleigo application. For a reminder of how a Caleigo application works, see chapter 2. The prototype has successfully implemented the following functionality: Viewing a selection of entities / tables Listing the entity content / rows in a table. Adding / editing / deleting rows. Dynamic creation of views in a recursive behavior. Viewing of slave views Functionality missing Because of time limitations of the master thesis project, we could not implement all functionality that is to be expected from a fully working Caleigo application. The most important missing features are listed below: The prototype is lacking qualifier views, which are needed for performing searches and data filtering in an application. They are a cornerstone in most applications but they are not that hard to implement, since most of the functionality is already inside the CEL framework. The views are very similar to the selection views, which we do have implemented. Support for user configuration of views is not yet implemented. This feature would makes it possible to change the layout of the views in runtime, just as in the smart client. It is rather hard to implement, because of the limited support for "drag and drop" functionality inside thin clients. A work-around could be to change the view layout inside the smart client, save the configuration and then restart the web client, which would read the configuration data. 50

Bugs and other technical shortcomings There is a performance problem in the selection view when there are many rows in a table. This probably has to do with our implementation of a property source, since it uses Java reflection functionality to access the dynamic content. Reflection is a time consuming task for the Java virtual machine. We also use a lot of debugging messages on the console, which slows down the rendering of the layout. A solution to this problem could be to implement a UI widget that only displays a limited number of rows at one time. Another solution could be to create a property that does not rely on Java reflection. Our prototype implementation has support for these specialized properties. When an active entity is deleted it is still visible in the entity-view. We believe that this is not an bug from our part, but a bug existing inside the Caleigo CEL framework. Application design shortcomings In the prototype, we always start rendering from root view, and then inserts other templates inside parent templates. We may need to support that it is possible to start the rendering from any view in the hierarchy. Usage and presentation shortcomings Here, we list problems associated with how limited users are with the existing prototype, and also limitations in the HTML design. The HTML "tables" concept limits positioning possibilities of the views in the layout. HTML "tables" are very fixed in their nature, one can not specify the absolute position of a table. In order to increase the freedom of positioning the views, it would be interesting to see if the tables could be replaced by the HTML "div" concept. We did not have the time to actually implement this solution, but according to the HTML 4.0 specification [html40], they seem to have support for both absolute and relative positioning, which together would create a different level of freedom of placement of the views. The pop-up menu, used in the selection views, are crude to say the least. It is only a HTML problem and it is easy to replace when a better-working menu is created. 4.3 Implementing a distributed way of connecting to CEL One important goal of the master thesis was to make the system distributed. An explanation of what this means can be found in chapter 2. Sun has developed Enterprise Java Beans, EJB, as a solution to many of the existing hurdles when creating a distributed system and it is a standard used and known today by many vendors and corporations. For these reasons, it would be to our, and Caleigo's, advantage to utilize EJB when we design our solution. EJB is also described in chapter 2 and it is recommended to have a good understanding of that chapter before continuing. 4.3.1 Description of the problem. As described in Chapter 2, CEL encapsulates data with help of components such as Entities, EntityDescriptors, DataSources and DataServices as explained in chapter 2. A client should have a tight integration with the CEL layer to be able to utilize the dynamics of the solution, but at the same time we want the data to be distributed from a central data source to external clients that reside on many external systems. The distributing system should in itself be able to encapsulate the real persistence mechanism with a CEL layer. What is needed is a CEL layer both at the client application and at the distributed persistence source. The CEL layer at the client should call the CEL layer at the server to retrieve data. The CEL layer at the server can be encapsulated by EJBs to utilize the advantages EJB brings in distributed programming. A graphical representation of this can be seen in Figure 4.4. 51

Figure 4.4: A distributed model of CEL with EJB Figure 4.4 indicates that we basically need to develop two things, a DataService handling EJBs, and the EJB layer that handles incoming requests. The EJB layer for an example EJB called CustomerBean is depicted in Figure 4.6. Code examples and a more extended visualization of how EJB work together with an EJBDataService can be found in the next section. EJBDataService Today, the most used data service in Caleigo applications is the JDBCDataService. It provides access to a database via JDBC. Given an entity descriptor, it makes SQL queries to the database and returns entities. We want to achieve the same objective with EJB. Instead of connecting to a database, a connect should be made to a remote EJB layer. The EJB layer is responsible for returning data and there need to be a mechanism for converting that data into entities and selections. Creation and manipulation of existing data must also be covered. A proper name for this service should be EJBDataService because the name describes exactly what we want, a service that connects to EJB. Chapter 2.2 deals with how CEL and DataServices work, and it is a recommended reading in order to understand the concept in this chapter. Figure 4.5: Example of a EJBDataService connected to a remote EJB 52

An UML diagram of how JDBCDataService and EJBDataService interact with the CEL layer can be seen in Figure 4.5. Note that according to the figure, EJBDataService interacts with the client side CEL code, and communicates with EJBHome and EJBRemote via RMI, because they reside on the server together with the EntityBean, and JDBCDataService. EJBDataService has five operations that it needs to perform: Connection The EJBDataService needs a way to connect to the EJB layer. The "connect()" method take care of that. Below is an example of how a "connect()" method looks like: /** * Retrieve the Home object for the given entitydescriptor. * Home objects can then be used for querying for * entities,creating,deleting etc. * * @param entitydescriptor the entitydescriptor we want to * manipulate. * @return a Home object with creation and finder methods */ public IBaseHome connect(ientitydescriptor entitydescriptor) { IBaseHome home = null; try { Object boundobject = context.lookup(entitydescriptor.getjndiname()); Class homeclass = entitydescriptor.gethomeclass(); home = (IbaseHome) PortableRemoteObject.narrow(boundObject,homeClass); } catch (javax.naming.namingexception e) { Log.print(this,"Unable to lookup homeobject " + e); } } return home; To make a connection it is necessary to supply an EntityDescriptor as a parameter. The reason is that there is exactly one EJB class per EntityDescriptor. When the EntityDescriptor was generated it was given the correct JNDI name that is needed for looking up the Home object for the entity bean. JNDI stands for Java Naming and Directory Interface and is a technology for looking up objects in a general way. J2EE uses JNDI to remotely lookup Enterprise Java Beans, or rather their Home interfaces. The Home interface then redirects all incoming calls to the proper Bean with the help of RMI. The lookup name can be retrieved by calling the method getjndiname() on the EntityDescriptor, and it is used in the code above for the lookup functionality. The Home object is responsible for supplying the client with the correct bean, and it also has methods used during creation. A generated Home interface has the following methods: public java.util.collection findbyqualifier(qualifier qualifier); public void saveentity(ientity entity); public void deleteentity(ientity entity); 53

public CustomerRemote create(); public CustomerRemote findbyprimarykey(ientity primarykey); (Exceptions removed for clarity) The "findbyqualifier()" method can be used for making a query for finding entities. This is used in the EJBDataService when it is called by the client CEL layer to query using a qualifier. Next method to be explained is the "executequery()" method listed below: protected void executequery(dataquery query,iselection selection) throws DataServiceException { try { // Get Home object from EJB source IBaseHome home = connect(selection.getentitydescriptor()); Collection collection = (List) home.findbyqualifier(query.getqualifier()); if (collection!= null) { Iterator iter = collection.iterator(); } while (iter.hasnext()) { IEntity entity = ((IbaseRemote) iter.next()).getvalueentity(); selection.addentity(entity); } } } catch(exception e) { e.printstacktrace(); Log.print(this,"Error querying entity " + e); throw new DataServiceException("" + e); } This method retrieves a Home object by calling the "connect()" method, and then calls the "findbyqualifier()" method on the Home object. The result would be a collection of entities from the server, which is put in a collection. The collection is actually a CEL enabled container called a Selection. There is a bit more happening in the background, but these are the essential parts and do point out the elegance of the solution. 4.3.2 Conclusions We have successfully created a DataService that uses an automatically generated EJB layer as its persistence source. There are three major benefits from this. We have created a distributed solutions as specified in the description of the task. We have created a mechanism that gives the user the ability to generate a complete EJB layer that wraps a database using mainly the Caleigo Foundation Builder wizard. Creating this EJB layer by 54

hand is often a very time consuming task, but with this solution it is done within a very short timespan. Note however that the framework limit the user in the flexibility of the wanted EJB layer, which could be a topic for further research. We have made use of much of the existing CEL technology to make the EJB layer, which was a preferred design goal. The created EJB layer is general in that way that it can also be used by clients that have nothing to do with CEL and the related technologies, and that makes the solution even more attractive. Figure 4.6: UML Model of EJBDataService interaction with the CEL layer 55

5 Prototype analysis 5.1 Introduction This analysis chapter aims to clarify the results made in the prototype. It also goes into questions of what other areas that could be interesting to analyze further, and what future additions that can be made in the prototype. Outline Section 5.2 covers the criteria for the analysis, followed by five major topics divided into sections. Section 5.3 looks into the presentation framework used in the prototype. Section 5.4 presents an investigation about if the prototype is versatile enough to be used to implement a custom made system. Section 5.5 looks into the possibilities for using the prototype together with Web Service technology as a distribution method. Section 5.6 analyzes if it is possible to integrate Caleigo's Core Entity Library framework with the J2EE and EJB technologies. Finally section 5.7 investigates how multi-user functionality could be introduced in the prototype. 5.2 Criteria These criteria are needed for clarifying what areas we will analyze. They are centered on the technologies of which the prototype is made, and presented below: Dynamic views Analyze how well the dynamic view concept works in the prototype. Especially the use of templates should be evaluated, and possible replacement technologies. Customization possibilities Analyze the feasibility of customizing a generated application so it fulfills a certain specification requirement. Web Services feasibility study Evaluate how well the prototype can be used as a Web Service. EJB usage areas Evaluate the of possible usage areas for EJB and J2EE including the already implemented solution in the prototype. Multi-user functionality Evaluate the usability of the prototype in a multi-user scenario and possible ways of improving the multi-user ability of the prototype. 5.3 Analyzing the presentation framework In this chapter, an analysis of the presentation framework of the prototype is presented. The questions that were raised in chapter 4, together with some other issues found during the analysis phase will be answered in this chapter. The first, and probably the most interesting question to answer, is if we managed to develop a framework for creating the dynamic views as discussed in chapter 4. The short answer would be "yes", and a slightly longer answer will follow after this introduction. 56

The second issue would be to use an existing template-based technology and see if it is possible to get the same functionality in the presentation layer, as when using our Gen-based prototype. 5.3.1 Dynamic views In this chapter, a deeper analysis of the dynamic views is presented. The dynamic view concept is explained in chapter 2, and the implementation is presented in chapter 4. The thin client concept is discussed in chapter 1. The presentation framework in the prototype is divided into two parts: Views and templates. This extra layer gives at least two benefits: Views can be shared between templates Different skills are needed for creating views and templates The template engine is the part in the system that builds the necessary layout information needed for a thin client. It creates HTML pages for web browsers, and it can in theory create WAP-pages to be rendered in cellular phones. The layout is defined in template files, as described in chapter 4. The templates defines the static layout data inside the template document, and get the dynamic layout data from the views. The definition of the static and the dynamic layout data exists solely inside the template, which makes the views more general than in the Swing counterpart. This means that different layouts can be constructed using the same view, as long as the dynamic data used in the templates are the same. The benefit of this is that making changes to a layout does in many cases not mean that the Java code has to be re-generated, the changes are done in the templates alone. The conclusions above also leads to another interesting point, namely the second point. Since the templates are constructed using a scripting language, the skill needed for creating a template is different from the skill needed to create a view. The developers that implement the views need to be skilled in the Java language and must be familiar with the object oriented way of thinking. The internal structure of CEL must be mastered in order to extract the layout information, however the developers do not have to be concerned about the layout, other than creating the API for the templates. The developers concerned with creating templates have to know about the clients layout rendering capabilities and the language used to create the layout inside them. The developers also need to understand the scripting language used in the template files and what dynamic information the views can deliver. Template issues The layout is slow The dynamic functionality of the views is, as stated in chapter 4, created by having a template recursively include itself until an end point is found. The end point is called a base view and it contains the dynamic content that is specialiced for the view in question. When the template engine parses a template, a tree is created in memory to be cached during the life-time of the application. The first time a template is used in the application the parsing occurs, the next time the cached copy inside the cache tree is used. This makes the HTML rendering to be quite fast. Our current prototype uses templates that in the end constructs a single HTML page. This means that there are a lot of views that recursively are getting called every time something on the HTML page changes. We do experience some performance issues when rendering the pages, but we have some good guesses of the cause of these issues: There is a lot of debug information on the console, while rendering the HTML pages and writing text in the console is a time-consuming operation. This can be solved by simply removing the debug information. The GeneralPropertySource and WebPropertyEnumeration classes, which are called inside the templates, are using the reflection 6 functionality in Java, which is quite time-consuming, at least 6 The reflection functionality makes it possible to call methods, or constructors, on objects of which you only know the name. The reflection framework uses the name and checks if the method exists 57

when it is being done a multitude of times inside the templates. The solution to this problem is to create special types of property sources and register them in a lookup service for a specific class. When a property source is needed inside a template, the special property source will be used if it correspond to the data that the template needs, otherwise the GeneralPropertySource is used, which can wrap any kind of data. Web applications can gain performance by splitting up the layout in frames, which are sub-documents inside a frame set document. These frames can be updated independently of the other frames and thus a smaller part of the complete application has to be redrawn. The Gen scripting language is proprietary That the scripting language in Gen is proprietary might be an issue, since there are a lot less developers that knows about the Gen scripting language than for example the de facto standard JSP. This issue is not that big, because the scripting language is quite small and all template engines more or less share the same concept, which makes it rather easy to learn a new scripting language. The templates might be hard to debug There is no working environment today that supports debugging Gen templates. This can make debugging of thin client applications cumbersome, at least when creating templates that include other templates in an iterative manner, because it is hard to tell in which template an error occurs by just looking at the generated layout. Often errors might not even stem from the template itself, but from a Java object used within the template. If this prototype would be used as a base for a product, debugging facilities would of course be provided by Caleigo. Conclusion Templates are good because they separate data from presentation details, and it is an advantage when there are different roles collaborating to make the application. Templates have problems though, and we believe one of the major problem is the mapping of the object oriented view structure to a script based template structure. It is not a functional problem, but more of an architectural one. It can be quite a challenge to understand how an application is built up, by just looking at the templates, because of the vital recursive behavior in them. 5.3.2 Use JSP as a template engine In this chapter, we will make a theoretical analysis of the similar functionality as presented in chapter 4 and id it can be created using JSP. The concept used in the templates for creating the dynamic views are the "#INCLUDE" statement, together with the possibility to pass a PropertySource as parameter to the page. This concept is vital for the dynamic views to work and without being able to mimic this functionality in JSP, this project will fail. In the JSP 1.2 documentation [JSP12], a <jsp:include> tag is presented as being able to dynamically insert other pages. The syntax for the tag is listed below [jspsx]: <jsp:include page="{relativeurl <%= expression %>}"> <jsp:param name="parametername" value="{parametervalue <%= expression %>}" />+ </jsp:include> There seems to be no way to pass an object directly to an included page, using the tag. One can supply additional parameters though, but they are limited to be only strings. So, there exists a tag for including other pages in a JSP page, but there seems to be no way to give information to the included page. We need to check out the JSP concept a bit further to see if we can find a solution to this problem. and then calls it using supplied parameters. 58

The Context object When creating a web application, is is possible to introduce global information that should be accessible to all Java Servlets and JSP pages in the application. Such information can be found in the Context object. This object can be used to store global information in run-time, which is done by calling the "context.setattribute(key, value)" method, where key is a String object and value can be any object. The session object When a user requests a page from a web application, a session is created and set up between the browser and the Java Servlet engine the first time a Java Servlet or JSP is accessed. When no accesses has been made between the client and the server for a specific amount of time, the session is considered obsolete, and all object instances inside the session object for that session is thrown away inside the Servlet engine. The Session object can, just like the Context object above, be used to store run-time data. The request object When a client accesses a Java Servlet instance, either the method "doget()" or "dopost()" is called. A Request object is passed as a parameter to one of these methods. This object contains browser information, such as the name of the web browser, and variables defined in the HTML page that linked to the Servlet. The Request object can also be used to store run-time data, using the "request.setattribute(key, value)" method, where the key is a String object and the value is any type of object. The object is passed to all pages included in the page being requested, where the other pages would be pages included using the <jsp:include> tag in a JSP page. The Request object exists during the access time for the pages, and is thrown away at the end of the request. All of these objects above can be used to hold run-time information from Java Servlets and JSP pages. The best object to use for our specific problem would be the Request object, since it is automatically thrown away after a request is finished, and it is only shared between the called page and its included pages. The complete solution A small example of the include and object passing functionality is presented in this section. First out is a JSP page called "mainpage.jsp" that includes another JSP page called "name.jsp" and sends some information to it: <HTML> Welcome <% request.setattribute("username", "Joe"); %> <jsp:include page="name.jsp"> <jsp:param name="extradata" value="username"> </jsp:include> </HTML> 59

The text "Joe" in inserted in the request object using the key "username", and then the page "name.jsp" is included inside the JSP page. The page "name.jsp" is presented next: <HTML> <% %> String key = request.getparameter("extradata"); String text = request.getattribute(key); <B><%= text%></b> </HTML> When calling the page "mainpage.jsp", the following output should be produced: Welcome Joe The example is maybe not that exiting, but it uses all the functionality needed to create more advanced dynamic views. The JSP pages could also communicate with the business logic using sub-classes of the PropertySource class, which is the object used in Gen templates that contains the dynamic content. Using the method above, it should be a rather trivial task to switch from Gen templates to JSP pages. Conclusion It seems that it is possible to use JSP templates to create dynamic views in thin clients. This statement is not empirically tested, but the key issues with creating dynamic views has been identified and theoretically solved. It might be interesting to implement it in the final prototype. The main reason for still using Gen is that it is tightly integrated with the CEL framework, and thus Gen fulfills our design goal of utilizing Caleigo's technologies as much as possible. 5.4 Customization possibilities To be able to find out if our prototype is flexible enough for making more customized solutions with it, with richer user interfaces and B2C (Business to Consumer) business logic, we have developed a case study [Wohlin 2000] where we try to create a system that conform to a specification requirement list. 5.4.1 Use case scenario The scenario starts out with a requirement specification. We want to create a Sound Selling system and pretend a customer has set up the following directives: The system must support selling individual tracks of music and it should have a web interface in HTML with the following functionality: Category navigation, where the tracks are grouped in different categories according to the type of music within the tracks. Show a list of tracks in active folder combined with search results. A method of selecting a track to perform operations on it. Ability to view info of a selected track Ability to store the selected track in a personal folder. Ability to buy the selected track. Categorization of tracks under categories / CD. Ability to listen to a low quality samples before buying. 60

Minimum of 10 tracks to buy at one time. Rebate on price for large number of tracks bought at one time. Maybe keeps track of history as well. Ability to collect tracks under a folder for later purchase. All bought tracks should reside under a folder and always be available for direct download via the Internet. Searching ability that takes the following input parameters : Category/Folder, Title, Composer, Genre. Configurable branding for making the system attractive and blend in with the layout requirements found with other buyers of the system. It is an attempt to make this system a more general shopping system. The system must also have administration capabilities with the following functionalities: Customer administration In the customer administration, the administrator should be able to view, search, add, edit and delete customers. Every customer in the system should have the following attributes: User ID Name Email Password for login Company name Address City Zip code List of all tracks saved for later use List of all tracks bought for retrieval. It must be possible to search for a customer on the following fields: Name Email User ID Company name Category administration There should also be a category administration part. Tracks should be divided into different categories to make it easier for the customer to find tracks. The administration module should contain functionality for adding, editing and removing categories and it should be possible to move tracks between categories. Track Administration The system must support the ability to add, edit and remove tracks. Every track should have the following info: Genre Style 61

Title Tempo Length Composer Copyright Price Link to a sound file. Link to a low quality sound file. Together with the customer, use cases are created and from these a system architect start making conceptual diagrams which in the end results in a database schema. The database schema for the system is visualized in Figure 5.1. Figure 5.1: Database model for the use case scenario After the database is created, it is time to let Caleigo Foundation Builder developers take over. They start the Caleigo Foundation Builder wizard and connects it to the database. The instructions for how this is done, together with screen shots of the process can be found in chapter 2. When the connection is made to the database, the developer gets a listing of all available tables and has the opportunity to configure the meta data for the system properly. All link tables, which in this case are "user_saved_tracks", "user_bought_tracks" and "category_has_tracks", should be marked as LINK_ENTITY. This means that Caleigo Foundation Builder sees these tables as a links between two other tables. When the configuration part is done, it is possible to run a preview of the system as a Java Swing application, which can be seen in Figure 5.2. Although it is not yet possible at this phase to see the web application, this view is still potentially useful for seeing that all relationships between the tables work as planned. Also, this preview gives us a good insight of how the administration tool for the system will look like. When the Caleigo Foundation Builder developer is satisfied with the result, the next step in the wizard is to specify the name of the application together with where the generated application should be placed. The generated files represent the table structure as Java classes, and the created class structure can be put into a single JAR (Java Archive) file for easier deployment of the application. 62

Figure 5.2: Swing application for the Sound application Now it is time to see what the web application looks like. First off, a Java Servlet enabled application server is needed. There are a multitude of choices on the market ranging from free open source technology to expensive proprietary software, but they all have the Java Servlet specification in common [JSS23]. This means that web applications should be created in accordance to this specification. An example of a file structure is exemplified here: /index.html /hello.jsp /images/image.gif /WEB-INF/web.xml /WEB-INF/classes/com/celgen/Hello.class /WEB-INF/lib/cel.jar At the root level, which in the example above are filenames only preceeded with a "/" sign, one can put ordinary documents, like HTML files, images and other files that are recognizable to a normal web server. It is also possible to put JSP files at the root level. Under the root, lies a special folder called WEB-INF with an important configuration file in it, called "web.xml". One important task for this file is to map Java Servlet classes to a specified URL. Request made to this URL will be transferred to the Java Servlet being pointed out. A thorough explanation of this can be found in the Java Servlet specification [JSS23]. Caleigo Foundation Builder creates a very important class, namely RootViewServlet, which is the interface between the browsers and the prototype. The RootViewServlet needs to be mapped to an URL, and that is done inside "web.xml". The example below is an extract of a "web.xml" file. It shows a configuration that will in effect make all calls to the URL "http://www.host.com/servlet/rootview" go to the Java Servlet RootViewServlet's handlerequest method. 63

... <web-app> <servlet> <servlet-name>rootview</servlet-name> <servlet-class>soundsystem.client.rootviewservlet</servlet-class> </servlet> </web-app> The WEB-INF/classes should contain the classes that we want the web application to use. Here is where the developer can add his own classes. The WEB-INF/lib is where we put our libraries and Java archives (jars). We want the following jars here: "cel.jar", "gen.jar", "webgen.jar" and the generated classes as a jar, but they can possibly also be placed as files in the WEB-INF/classes folder. After placing of the proper jars and the creation of "web.xml", it is time to see our first result. The result can be seen in Figure 5.3. Figure 5.3: Un-customized web interface of the Sound system It does not really look like what we want to achieve, but there are important similarities. There is a selection view of categories and tracks together with an entity view to the left, which are views needed in the wanted application. So where do we go from here? There is a need of a filter that shows a selection list of tracks that relates to a certain category and possibly also a search criteria. There is also a need for a filter that shows a selection list of tracks that relates to the saved sounds for the logged in user, as could be seen in table "user_saved_tracks" in Figure 5.1. As with the saved sounds, there is a need for a filter that shows a selection list of tracks that relates to the bought sounds for the current user. These tracks are found in the table "user_bought_tracks". 64

In order to implement the user concept, some kind of login functionality would be needed, and it should be possible to get access to the currently logged in user inside the views. We are going to need more than this but it is a good start. Filters and qualifiers are implemented in the generated Swing applications, but not yet for the Web client. This is a very import logical part of the system and it is recommend to be added. Since there is no search functionality implemented, a shortcut is made by simply displaying all tracks in the selection view, as a start. To make it useful for this project, we need to alter the template for the selection view. In order to implement the functionality specified in the requirement section above, we also need to define the following actions: The "buy track" action, which basically should add the track to the 'user_bought_sounds'table." and in some way charge the customer for the price connected the track. A "save track" action, which means the business logic should add the selected track to the "user_saved_tracks" table. A "track info" action, which should tell the application to show an entity view of the selected track. So how do one change the template for the selection view for tracks? There are two ways to do this: Change the template for the general selection view. This is not a very good approach, because it means changing the layout for all other entity descriptors at the same time. Create a new selection view that possibly extends the normal selection view, and create a new template that works with the new view. The thing that needs to be done with this approach is to override a few methods in the new selection view. The second choice is the most promising choice, since it only affects a specific view. The approach is to extend the SelectionView class, and we do this by creating a new class called "TrackSelectionView". This class need to override the following methods: All constructors should be extended with a simple "super()" call to the extended SelectionView class. The "handlerequest" method, which would implement responses to the actions listed above. The whole base view, since we need to change it to point to a different template file. To accompany this one, we should write a template that is unique for viewing a selection of tracks in the list. We will build upon the existing template file "selectionview.gtf", which is seen below. We have total freedom to create a new template with the same basic functionality but with the required new layout. Below is the original selection view template "selectionview.gtf", which needs to be updated with the layout specification in the requirement list: #DEFINE SelectionView(selectionView)##WS# <div id="selviewchoice#prop(selectionview.id)#" class="box"></div> <table> <tr> #REPEAT(fieldView=selectionView.FieldViews)# <th class="selection">#prop(fieldview.displayname)#</th> #ENDREPEAT# </tr> #REPEAT(entity=selectionView.Entities)# <tr> #REPEAT(fieldView=selectionView.FieldViews)# #IF(fieldView.Index==selectionView.SelectedIndex)# <td class="aselection"> #ELSE# <td class="selection"> 65

#ENDIF# #INSERT selectionfieldview(fieldview,selectionview)# </td> #ENDREPEAT# </tr> #ENDREPEAT# </table> #ENDDEF# which includes the template file "selectionfieldview.gtf": #DEFINE SelectionFieldView(view,selectionView)# <a class="selection" onmouseout="selviewunchoose(document.getelementbyid('selviewchoice #PROP(selectionView.ID)#'));" onmouseover="selviewchoose(#prop(selectionview.id)#,#prop(view.ind ex)#,document.getelementbyid('selviewchoice#prop(selectionview.id) #'));" href="rootview?viewid=#prop(selectionview.id)#&id=#prop(view.index )#&action=view">#prop(view.data)# </a> #ENDDEF# Login The login functionality is still under development today at Caleigo, however we can use their existing technology to achieve the goal. The steps to do it are: Create a view structure per session. This is needed in order to have unique views to each user that is currently logged in. A new session starts with a very simple view structure consisting of one qualifier view with a user name and password field taken from the customer table. It also contains a login button connected to an action that validates via the qualifier and if a match is found, sets that user as active entity in a "ProxyEntity". The action then resets the view structure and creates the real view structure with the system views. The problem here is that we do not have the concept of storing data per session today. As Caleigo is working on this login issue, the suggested implementation here will be super-seeded by a general method of logging in. The analysis of how such a framework could look like can be found in chapter 5.7 in this report. Actions In the current prototype, the actions are defined by sending a specific action key in the request. When a user for example clicks on a track in the HTML page, a request to the server containing the string "action=select&data=5" is sent to the server, where "action" is the specific action key, and "data" contains additional data which in this case would be the track number. The requested view uses the action key to decide which action to perform, and uses the additional data for further processing. Caleigo is building a more complex solution, using action objects, but we feel that the current solution is sufficient for this system. Decorator views We need a way to simply display views with no visible logical content. It could be help views, 66

branding, static information or similar. This can be accomplished by using user entity views or by having some internal logic decide what template we are using for a certain view. The HTML will be placed in the template and we have the option of using user data and its relations to other data to display meaningful information. 5.4.2 Summary and conclusions We have now done a first basic iteration of a simple E-commerce system with a web presence. It seems that the project was feasible with some added development summarized below: Session handling needs to be fully implemented. Qualifiers and filters are essential and need to be implemented. There is a need for the tree functionality that exists in the Java Swing client. Login functionality as described above, or with a more specific login approach must be developed. There is a need for decorator views working as entity views with context objects. We need to extend views via inheritance to support more actions or use actions as pluggable modules, which could be registered into views. The latter functionality is something that Caleigo is working on. We need to implement a way to specify which templates to use in certain situations, as in the case of decorator views described above. If these areas are developed and fully functional, we would be able to fulfill the requirement specification. 5.5 Integrating web services with the prototype In this chapter, a discussion of how web services can be introduced in the prototype is presented. A thorough explanation of the web services concept can be found in Appendix F. Due to the multi-layered nature of the Core Entity Layer (CEL), together with the added extra layer by the application server, web services technologies can be introduced in different levels in the application. How and where it can be done is presented in the sections that follows this introduction. 5.5.1 The Web client and CEL in the same JVM Figure 5.4: Running WebGen and CEL in the same JVM In this scenario, the application logic runs inside the same Java virtual machine (JVM), as illustrated in Figure 5.4. Network communications occurs between the thin client and the application server and between the CEL layer and the data source. Data transfers between the prototype and CEL occurs inside the JVM, which means that the data never reaches the network. There are two places in this scenario where web services technologies can be introduced: Between the thin-clients and the application server Between the CEL Layer and the data source Introducing a web service server in front of the application server, or making the front-side 67

communication layer of the prototype implement the necessary web service interfaces, makes the whole application itself to become a web service since the clients communicate with it through a web service layer. In Figure 5.5, the web service layers are represented by filled rectangles, where the light gray rectangles represents web service clients, and the web service servers are dark gray. The communication between the web service server and client depends on the protocol supported by the server, but it is illustrated in the figure by the text "SOAP". The SOAP concept is described in appendix F. Figure 5.5: Introducing Web services technologies In order to communicate with a web service server, the clients need to be able to understand the protocol used for data transmission and then be able to decode the data being transferred. Thin clients can not be used as web service clients due to their limited data processing capabilities. Adding a web service aware data service, which is the layer between CEL and the data source, would enable web services to be used as data sources. This might be an interesting way of introducing the possibility to communicate with other systems from within systems built by Caleigo. It would perhaps be easier to communicate with legacy systems by developing a web service layer in front of them and then use a web service compliant data service to enable CEL to access them. The things that one has to be aware of, are the current lack of features in the web service concept as described in Appendix F. Read-only web services, or web services that are not involved in any transactions, would probably be very suitable for a data source that implements the web service interface. 5.5.2 CEL tunneling The CEL layer also supports being split into running on two different JVM, which means running two instances on the same server, or running them on different servers. One situation would be to have a server somewhere that communicates with one or many clients using a split CEL layer. Figure 5.6 illustrates what happens when using web services as a communication layer between the two CEL instances. Today, a proprietary tunneling protocol is used when sending data between the two CEL instances. What introducing web services would give, is using a standardized communication protocol. It would probably also add extra overhead, both in the size of the data being transferred, and extra strain on the computers running the CEL instances, since XML translations has to occur for every message sent. Our conclusion is that there is no extra value, at the moment, to replace the existing protocol because of the reasons just listed. 68

Figure 5.6: Using SOAP to communicate with 2 CEL instances 5.5.3 Conclusion An interesting integration would be to make the prototype to act as a web service server for web service clients. However, because of the time limit of the master thesis, this option has not been implemented and tested. We can say that using a web service server as a data source for CEL does seem to have problems because of the added overhead, and the lack of transaction support. This might change in the future, as web service is a rather new invention. 5.6 Possible use of EJB / J2EE in Caleigo's products The prototype uses EJB / J2EE as a data source, which is used by an implemented EJBDataService to connect to and retrieve data from. This implementation had many advantages, as can be seen in chapter 4. However we also wanted to analyze in what other areas this technique could be used. We have derived 4 possible usage areas for EJB / J2EE: Having EJB as a data service, which would be used when accessing a database through an EJB API. This scenario is implemented and discussed in chapter 4. Implementation of the CEL layer in EJB. Create an EJB facade, which is useful for creating an API to other type of clients. Packaging of CEL in an enterprise archive, which is a concept supported by a majority of application servers. 5.6.1 Implementation of the CEL layer in EJB/J2EE It is possible to wrap all individual classes making up the CEL structure in EJB. The purpose would be to let EJB add to, or take over functionality from the CEL classes. We would in theory benefit from all the services that EJB provides. However there are practical implications too that can be seen as major drawbacks when determining if it is worth the effort migrate. They drawbacks are: Object oriented programming limitations of the EJB framework. EJB should more be seen as components than classes. There is a contract with restrictions to fulfill that prohibits more advanced forms of object orientation, and thus limit the flexibility of the frameworks. Necessity to provide an EJB container with the products. This introduces a dependence of a thirdparty product in the application, a product which often can be rather expensive. Difficulty to remake an existing application into EJB without a total remodeling of the application. The conclusion for implementing the CEL layer in EJB is that this is not a useful tool for distributing CEL at this time. CEL already handles much of the distributing by itself, and potential benefits from EJB does not weigh up the development cost and complexity of the solution. 69

5.6.2 EJB facade Instead of implementing EJB on the fundamental elements of the CEL structure, there is another alternative, namely to create a session facade that can transfer method calls to an internal CEL structure and get results back as value objects that is not EJB. The facade should be able to wrap both the CEL structure and the specific view for thin clients structure. The solution should have facade methods for all methods in the CEL and view structures that carries out an action. It should also have data holders that are used to transport data from the client and the facade, and nothing more. The normal classes cannot be used since they have action methods as well. Data holders should have an association with an instance of CEL via a lookup service, so a data holder actually can be used as a parameter to session facade method. So what is gained using this approach? Wrapping of CEL in an EJB container, which makes it possible to introduce the CEL architecture into an already existing EJB solution. Avoid tight coupling between business objects and clients. A standardized way of connecting to a remote CEL application. EJB specialists can use their knowledge to develop clients that works against the session facade. What are the drawbacks? One more layer on top of CEL that will decrease performance. Value holders of data increase memory usage. Large and unmaintainable number of session facades. Difficulty in treating hierarchical and iterative algorithms. The facades would probably be more suited to message oriented problems, such as reporting tools and HTML or XML generation tools, and not very good for business logic connected to a Swing application. A better way would be to use facades that give whole answers back to well defined questions / parameters. This could be accomplished by letting qualifiers and entity descriptors represents the parameters, and the answer would be a selection of entities, that can be used for reporting back data to an application. The facade can also make use of a bridging pattern [Gamma 1995] so that it returns data in a given format, such as another type of data structure that is known by the client, or for example as a XML stream. However this kind of service is what the web services technology is all about. Read more about this in the evaluation of Web Services in section 5.5. 5.6.3 Packaging of CEL in an Enterprise archive Another useful aspect of J2EE is the standardized way of distributing whole applications as one compressed archive file. In theory this file should be completely compatible with all standard compliant Java application servers. Therefore, there exists a good motivation for packaging the finished product in such a file. The file is a so called EAR file, which stands for "enterprise archive". The file contains a structured way to store the application and it has an standardized internal file structure. It has settings for both EJB and web applications, and a typical file structure has been explained in a previous section. There is one major problem to solve, and that is how to distribute the "cel.jar" package. To make it visible for EJB and the web applications, we need to add a line to the manifest part of the jar and war files: classpath: cel.jar This assumes that "cel.jar" is placed in the root of the ear file. 5.6.4 Summary The creation of a data service that works against an EJB structure seems to be a good idea, since there exist legacy systems on the market that demand that data only is changed through an EJB layer. It is therefore a good project to implement, and it is studied in detail in section 4.3. 70

Wrapping the inner structure of CEL in EJB is not an equally good idea. EJB will add an overhead and the services that EJB offer are in many areas already covered in the CEL structure. The extremely object oriented structure of CEL is not trivial to solve with the more modular component based solution in EJB. It would require high competence in EJB design patterns to be able to solve the wrapping problems. Our conclusion is that the cost in time to do the wrapping overweights the potential gain of such a project. Making an EJB facade to the system is a better idea, but not in the sense as to wrap CEL in detail, but rather to construct larger messages to be sent into the system from an external client and return answers in a format suitable to the independent client. However, web services may be a better way to achieve this. In conclusion, even if we do not use EJB in the end, it is still a good idea to package at least the prototype in an enterprise archive file. This makes it easier to move the code base between application servers. 5.7 Multi-user functionality In this chapter, an analysis of the multi-user functionality in the prototype will be presented. The first part takes up good and bad issues with the current implementation. The second part is a discussion of missing parts, which were not implemented due to different reasons. The third part contains the schematics of a user authentication framework. 5.7.1 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. Figure 5.7: Using RootViewServlet as a communication point In order to avoid code duplication for session handling in the Java Servlets, another technology that has 71

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. Figure 5.8: Introducing a Java Servlet Filter 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. 72

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

Figure 5.9: Class diagram for the authentication framework 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 74

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

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 76

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

78

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 Figure A.1 Northwind database schema Northwind models a trading system, with customers, employees, orders etc. It is good for educational purposes because it highlights several areas in database usage. 79

Appendix B Model - View - Control The model-view-control pattern [Gamma 1995] is a means for separating the presentation logic, which is the part of an application that interfaces with the user, from business logic. It is built of three concepts: The view, which is a graphical representation of the data, and the interface where the user has the possibility of changing the state of the application. The model, which represents the system in which the users operate. It contains the application states and the data. The controller, which is the the mediator between the view and the model. It contains the logic for how to translate the directives from the view into logic to change state or data in the model. Figure B.1: MVC model2 used within Struts see [struts] Model 2 Model 2 is an implementation for the Web with a Servlet working as the controller being a single point of entry. See figure above. Views are often represented by JSP pages and the business logic are represented by Java beans. 80

Appendix C Templates Composite View #DEFINE CompositeView(view)##WS# #REM Composite view #REM #REM This template iterates through all children of the supplied view and #REM creates compositions until there are no more than one view inside the #REM composite view. When a base view is found and it is not placed inside #REM a tab view, the base view template will be used in the INSERT paragraph. #REM Assumptions made for this template: #REM o The base view is always in the CENTER position #REM o There can only be 0 or 1 view for each position #REM #IF(view.LeftViewExists view.rightviewexists)# <table border=1 cellspacing=0 cellpadding=5 width=100% height=100%> <tr> #ENDIF# #IF(view.LeftViewExists)# <td valign="top" height=100% width=33%> #IF(view.LeftViewExists)# #INSERT #PROP(view.LeftView.TemplateName)#(view.LeftView)# #ENDIF# </td> #ENDIF# #IF(view.TopViewExists view.centerviewexists view.bottomviewexis ts)# #IF(view.LeftViewExists view.rightviewexists)# <td valign="top" height=100% width=33%> #ENDIF# <table border=0 cellspacing=0 cellpadding=0 height=100%> #IF(view.TopViewExists)# <tr> <td valign="top" height=100% border=1 width=33%> #INSERT #PROP(view.TopView.TemplateName)#(view.TopView)# </td> </tr> #ENDIF# #IF(view.CenterViewExists)# <tr> <td valign="top" height=100% border=1 width=33%> 81

#INSERT #PROP(view.CenterView.TemplateName)#(view.CenterView)# </td> </tr> #ENDIF# #IF(view.BottomViewExists)# <tr> <td valign="top" height=100% border=1 width=33%> #INSERT #PROP(view.BottomView.TemplateName)#(view.BottomView)# </td> </tr> #ENDIF# </table> #IF(view.LeftViewExists view.rightviewexists)# </td> #ENDIF# #ENDIF# #IF(view.RightViewExists)# <td valign="top" height=100% width=33%> #IF(view.RightViewExists)# #INSERT #PROP(view.RightView.TemplateName)#(view.RightView)# #ENDIF# </td> #ENDIF# #IF(view.LeftViewExists view.rightviewexists)# </tr> </table> #ENDIF# #ENDDEF# Tab View #DEFINE tabview(view)##ws# #REM Tab view #REM #REM This template acts as the tab component found in Swing. #REM It iterates through all registered views and display the name of #REM the view in tabs. Under the tab, the active view, which is the view #REM one choose by clicking on a tab, is displayed. The name of the #REM template used is fetched from the active view. #REM It also is aware of the base view in that sense that it will render #REM it instead of the usual template name if the base view is included #REM in a tab. #REM <table border=1 width=100% height=100%> <tr> <td class="tab"> 82

#REPEAT(tab=view.Views)# <SPAN CLASS="tab" #IF(tab.ID==view.ActiveView.ID)#id="active"#ENDIF#> <a class="tab" href="rootview?viewid=#prop(view.id)#&setview=#prop(tab.id)#"> #PROP(tab.DisplayName)# </a> </SPAN> #ENDREPEAT# </td> </tr> <tr> <td class="tabdata" height=100% valign=top> #INSERT #PROP(view.ActiveView.TemplateName)#(view.ActiveView)# </td> </tr> </table> #ENDDEF# Selection View #DEFINE SelectionView(selectionView)##WS# <div id="selviewchoice#prop(selectionview.id)#" class="box"></div> <table> <tr> #REPEAT(fieldView=selectionView.FieldViews)# <th class="selection">#prop(fieldview.displayname)#</th> #ENDREPEAT# </tr> #REPEAT(entity=selectionView.Entities)# <tr> #REPEAT(fieldView=selectionView.FieldViews)# #IF(fieldView.Index==selectionView.S electedindex)# <td class="aselection" #ELSE# <td class="selection"> #ENDIF# #INSERT selectionfieldview(fieldview,selectionview)# </td> #ENDREPEAT# </tr> #ENDREPEAT# </table> #ENDDEF# Selection Field View #DEFINE SelectionFieldView(view,selectionView)# <a class="selection" onmouseout="selviewunchoose(document.getelementbyid('selviewchoice 83

#PROP(selectionView.ID)#'));" onmouseover="selviewchoose(#prop(selectionview.id)#,#prop(view.ind ex)#,document.getelementbyid('selviewchoice#prop(selectionview.id) #'));" href="rootview?viewid=#prop(selectionview.id)#&id=#prop(view.index )#&action=view"> #PROP(view.Data)# </a> #ENDDEF# Entity View #DEFINE EntityView(entityView)##WS# #REM Entity view #REM #REM This is the entity view representation. #REM It will iterate trough its field views and insert them. #REM The submit button initiates a save action and it is routed to the #REM entity view by the request servlet. #REM <form action="rootview" method="post"> <table> #REPEAT(field=entityView.FieldViews)# <tr> <th align="left"> #INSERT fieldviewname(field)# </th> <td> #INSERT fieldviewdata(field)# </td> </tr> #ENDREPEAT# <tr> <td colspan=2 align="right"> <input type="submit" value="apply"> </td> </tr> </table> <input type="hidden" name="viewid" value="#prop(entityview.id)#"> </form> #ENDDEF# 84

Appendix D Structure of a simple Tapestry application ApplicationServlet First, a Java Servlet must be created, that inherits from "net.sf.tapestry.applicationservlet". The Java Servlets serves as the request handler for an entire Tapestry Application. The only thing needed to be implemented in the Java Servlet is the "getapplicationspecificationpath()" that points out where the application specification XML resides. Application Specification This is a XML document that describes the application. It contains description of the existing pages and other global properties such as Visitor objects. Example: <application name="simple Tutorial" engineclass="net.sf.tapestry.engine.simpleengine"> <page name="home" specificationpath="/tutorial/simple/home.jwc"/> </application> The example above defines a Home page and points out where the describing XML document resides. HTML Template Connected to a page attribute in the application specification is a HTML Template. Example: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <title>simple</title> </head> <body> This application demonstrates some dynamic behavior using Tapestry components. <p>the current date and time is: <b>< jwcid="insertdate">current Date</span></b> <p>click <a jwcid="refresh">here</a> to refresh. </body> </html> The template should have the same name as its page name, but with the added extension ".html" We see that in the <span> tag resides a new attribute, "jwcid". This maps the span to a component specified in the file "home.jwc". Same goes with the <a> element. Note here that it's possible to create components that wraps other components that has their own templates. This can be useful feature to create truly dynamic pages. Pages Component Specification Document All components including pages has a specification document attached to them that describes what internal components exists, the name of the document is "home.jwc", an example is presented below: 85

<specification class="tutorial.simple.home"> <component id="insertdate" type="insert"> <binding name="value" propertypath="currentdate"/> </component> <component id="refresh" type="page"> <static-binding name="page">home</staticbinding> </component> </specification> These internal components are supplied by the Tapestry framework, but could just as well have been custom made by a third party developer. These components in their turn has corresponding templates,classes and component specification documents. Notice the attribute class to the specification tag. This maps the page component to a Java Bean. The property-path attribute to the binding tag maps the value of "insertdate" to a method "getcurrentdate()" in "tutorial.simple.home" via reflection. Example: package tutorial.simple; import java.util.date; import net.sf.tapestry.html.basepage; public class Home extends BasePage { public Date getcurrentdate() { return new Date(); } } Page components Java Beans are a bit different from other components in that they have to extend "net.sf.tapestry.html.basepage". 86

Appendix E A Velocity application example First we start off with describing the data flow inside the Velocity parser: 1. Create a class that inherits from VelocityServlet. Inside it, do: 2. Collect all objects to be used in the generation of the page, in a context object. The context object works basically as HashMap, add objects to it and provide an object as a key, for example a String object. 3. Point out a template file to velocity. 4. Parse. 5. Send the output of the parsing to your preferred device. This process is explained by creating a small example: We have the following class: public class Customer {.... public String getname() {... } } public String getemail() {... } We create our Servlet with one important method to implement : public class SampleServlet extends VelocityServlet { public Template handlerequest( HttpServletRequest request, HttpServletResponse response, Context context ) { // Create our object Customer customer1 = new Customer(1,"Olle","olle@test.se"); Customer customer2 = new Customer(2,"Nisse","nisse@test.se"); ArrayList list = new ArrayList(); list.add(customer1); list.add(customer2); // Add it to the context object context.put("customers", list); 87

} } // Get our template Template template = gettemplate("sample.vm"); return template; The parsing is done in a method implemented in the VelocityServlet class, we only override getting the request method where the template is set. The VelocityServlet then merges the template given with the data in the context object. A template can look like this: <html> <body> #foreach ( $customer in $customers ) Customer ID : $customer.id<br> Customer Name : $customer.name<br> Customer Email : $customer.getemail()<br> <BR> #end </body> </html> The output from the Servlet is then: <html> <body> Customer ID : 1<BR> Customer Name : Olle<BR> Customer Email : olle@test.se<br> <BR> Customer ID : 2<BR> Customer Name : Nisse<BR> Customer Email : nisse@test.se<br> <BR> </body> </html> The most useful directives for the designer are: 88

#set ( $foo = expression ) sets an objects value. #if ($foo==expression).. #elseif ( expression ).. #else.. #endif #foreach ($var in $list) use $var #end #include ( filename ) #parse ( template file ) #macro ( row $list ) #foreach( $item in $list) <tr><td>$item.name</td></tr> #end #end conditional statement complete with most conditional and logical operations.(==,<>,and,or,not etc) Looping of list objects and arrays. Handles Hashtables, vectors and ararys of objects. Includes a file inside a template without parsing its content. Includes a template inside a template and parses its content. Create macros so we can reuse common scripts. Example using our VelocityServlet above: <table> #row($customers) </table> then becomes: <table> </table> <tr><td>olle</td></tr> <tr><td>nisse</td></tr> 89

Appendix F Web services This chapter explains the Web services concept and present some of the technologies which are being worked on to aid developers to create the services. As the Internet has become more and more common in the world, both at companies and in peoples homes, the benefits of communicating over the net has steadily increased. Business to consumer sites has been around for a while with shopping sites, banking services, ticket booking services, etc. Companies are also looking to streamline their businesses and cut down costs, by using business to business applications which help them in their daily work. Often, in these types of systems, different applications has to communicate with each other. An airline ticket booking system might need to connect to the airline company to check the status of a flight, a shopping site might need to check the account status of a customer when she wants to place an order etc. The communication between the applications might often be a rather hard task; the applications might be written in different computer languages which requires some type of communication bridge between them. They might not share the same concepts. For example a customer might be described differently in two systems, which would require some sort of data translation. A system might not support transactions or undo-functionality which means that when something unwanted happens in a chain of events, for example a system might crash, the transaction needs to be rolled back. There are a lot of other issues that needs to be handled when creating an enterprise system and some of them are addressed in the Web service concept. Web services is a rather new invention, the Web Service Description Language specification version 1.0 was out in the late 2000, and the 1.1 version arrived in the first quarter of 2001. There is a lot of anticipations about this technology, some say that the economic forecast for the year 2006 is about $7 billion in the US market, for professional web services related projects [idc0502]. An active player in the Web Services arena is the World Wide Web consortium (W3C). They have formed a group consisting of interested parties in the web services market, and the goal for the group is to "develop a set of technologies in order to bring Web services to their full potential" [w3cwsa]. The W3C is deeply involved in the technologies that forms the web, ranging from communication protocols (HTTP), data structures used between applications (HTML, XML, SOAP) to creating reference implementations of the technologies such as Amaya, a HTML editor, and Jigsaw, an application server which supports many of the technologies maintained at W3C [w3c]. The main technologies used for Web Services applications are described in the next section. The concept The formal definition of a Web service is: "A Web service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artifacts. A Web service supports direct interactions with other software agents using XML based messages exchanged via Internet-based protocols." [w3car] Web services deals with the fact that applications needs a standardized way of describing exactly what kind of service is provided and how a client is supposed to communicate with it as both the protocol used and how the message should look like is described. All the description is done in XML, which is an open standard created for describing structural information in a text format. The formal definition above might change in the future, since it is a draft and open for public review. The same is true for some of the technologies which builds up a Web service, where some of them are presented in the next sub-chapter. Architects and developers at IBM has analyzed the current definitions from w3c [w3car], and has come up with the following definitions of the concepts used to build up a Web service [ibmbp]: A Web service needs to address the following: 1. Specify the platform. The Web service should describe which methods that are available for clients, and which messages that will be passed when calling the method. (WSDL) 2. Specify how the data is coded in the message (SOAP, XML) 90

3. Specify the communication protocol to use (HTTP, TCP/IP etc) 4. The Web service might be registered in a lookup service, in order to enable clients to find it (UUDI) The figure below illustrates the relationship between the technologies: Platform description protocols WSDL SOAP Platform message protocols HTTP, TCP/IP, SMTP Transport protocols Web services technologies As stated above, there is a need for enabling applications connected to the Internet to communicate with each other. Some key issues for W3C when developing the technologies are : Make the technologies a standard and universally available. Enable applications built in different computer languages or applications running on different operating systems to communicate using the same communication protocol, and data structure. Try to use open technologies as far as possible, which also includes to use license free technologies. The two most important technologies used as platforms for open Web services are SOAP and WSDL. WSDL WSDL is an acronym for Web Services Description Language. It describes where a Web service is located, what service it provides and how to communicate with the service. The language used for describing Web services is XML. XML is a text format which uses some special notations (tags) to add structural information to a text. Below is an example of a rudimentary XML file. <information> <price section="stockquote" name="ericsson" currency="sek">4.00</price> </information> WSDL contains four main sections in the XML file: porttype message types binding The first three are abstract descriptions, whereas the binding element binds the communication to a concrete protocol. The porttype section describes which services the Web service provides, together with what messages 91

are involved when using the service. The porttype can be seen as a method or a function in a computer language. The message element describes the structure of a message. The parts of the message can be seen as parameters to a method or a function in a computer language, where the message itself is the encapsulation of the parameters. The types defines a data type. The definitions are defined elsewhere, such as using XSD (XML Schema Definition) data types. The binding element defines what kinds of protocol the web service actually supports. It is here where the communication method gets concrete. To sum it all together, a small example of a WSDL file is presented below [w3cwsdl]. <?xml version="1.0"?> <definitions name="stockquote" targetnamespace="http://example.com/stockquote/definitions" xmlns:tns="http://example.com/stockquote/definitions" xmlns:xsd1="http://example.com/stockquote/schemas" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/"> /> <import namespace="http://example.com/stockquote/schemas" location="http://example.com/stockquote/stockquote.xsd" <message name="getlasttradepriceinput"> <part name="body" element="xsd1:tradepricerequest"/> </message> <message name="getlasttradepriceoutput"> <part name="body" element="xsd1:tradeprice"/> </message> <porttype name="stockquoteporttype"> <operation name="getlasttradeprice"> <input message="tns:getlasttradepriceinput"/> <output message="tns:getlasttradepriceoutput"/> </operation> </porttype> </definitions> The document is structured using XML 1.0, as seen in the top of the document. The <definitions> element encapsulate the whole Web service definition. The namespace attribute to the <definitions> element is there to insure that each tag name is unique in the document. The <message name="stockquotetradepriceinput"> element defines the input message, with the data definition existing in the xsdl namespace. The <message name=" StockQuoteTradePriceoutput"> element is the message that will be used as a return message. The data is also defined in a document somewhere else. The <porttype> element defines an operation, called "getlasttradeprice", which has two parameters, the messages above. This WSDL document contains the abstract part of the Web Service. In order to use this Web service, a concrete protocol has to be bound to the port, which would be defined in the <binding> element. SOAP 92

SOAP is a framework for accessing objects at a remote location, or as it is defined by the XML protocol working group [w3cs]: "a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment". SOAP is an abbreviation of "Simple Application Message Protocol". SOAP uses the client-server architecture to support synchronized messaging, where the client information sends a request message from the server, and the server replies with a response message. Asynchronous messaging can be implemented by having two applications act as both clients and servers at the same time. A schema of how to implement how a client can communicate with objects on a remote server is illustrated in Figure F.1 [ibms]. Figure F.1: A SOAP client-server implementation schematics XML is used in SOAP for representing objects and that give several benefits. Since XML is very suitable for marking up structures, the object data can be fully expressed in the XML document. XML documents are written in Unicode text, which is a standard that can be readable by any client. XML is also a standard, which makes SOAP a rather promising technology from that perspective. To visualize SOAP a bit further, a simple example will follow. First off is a small class, created in Java: public class Person { public String name; public int age; public float height; public boolean female; } It defines something called Person with some characteristics such as name, age etc. How does a SOAP definition of this object look like? Let us say that we requested a Person object from a SOAP server, then a response could look like the example below: <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <SOAP-ENV:Body> <ns1:getpersonresponse xmlns:ns1="urn:personservice" SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <person> <name xsi:type="xsd:string">mariah Carey</name> <age xsi:type="xsd:integer">32</age> <height xsi:type="xsd:float">1.75</height> 93

<female xsi:type="xsd:boolean">true</female> </person> </ns1:getpersonresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> In this example, the data inside the <person> element is type-casted using the XML Schema definition language. XML Schema is a language used for describing the structure of XML documents. The description contains rules for describing things such as which elements a document contains, which elements are sub-elements to other elements, the number of instances of elements that are allowed in a document and what kinds of data the elements are allowed to contain, etc. As can be seen in the example above, the <name> element has an attribute called type which defines the data type according to the XML Schema definition language [w3csc]. In this case, the data type is a string. The description of the valid syntax for the SOAP response above is not included, but it could be described using XML Schema or using a DTD (Document Type Definition), a description language which exists in conjunction and is probably about to be superseded by the XML Schema definition language. Problems with soap As described in the previous section, SOAP encapsulates objects, or rather the object data, by encoding it in XML. There is some areas where one can run into problems when using SOAP [xmle]: It is hard to encapsulate XML messages. It is problematic to encapsulate binary data The first issue is because SOAP itself is notated in an XLM format. If including another XML file, problems can occur since they might be encoded using different character sets. This can happen, because it is allowed to write XML in Unicode, which supports a myriad of character sets (European, Chinese, Arabic etc). Another problem is that the XML syntax might be overlapping between the document, that is that the same XML elements might be used in the SOAP document and in the XML file that is encapsulated. The solution to this problem is often to create a link to the XML file on the server, instead of encapsulating it. The second issue is a problem, because binary data can, from time to time, contain the exact right combination of characters so that it becomes an XML syntax. There might be a sequence in the binary data that looks like "<!--" which means "start of comment" in XML, and this breaks the document structure. The solution to this problem can be to use an ASCII encoding technique, such as base64, to encode the binary data into valid ASCII sequences instead. This approach does introduces a second decoding phase, and extra document overhead and thus extra strain on the bandwidth and servers. The other solution is to wait for the SOAP 1.2 attachment feature to be accepted in the community, or use a link to the binary data as suggested above. UDDI Another technology worth mentioning is the UDDI (Universal Description, Discovery and Integration) specification. It enables Web services providers to register and in a structured way, describe their services in a lookup service and make them available for Web services clients. In this lookup service, the information is searchable on many criteria, which makes it possible for the clients to find Web services based on some criteria and then choose among them. Those two features are the "description" and "discovery" parts in the UUDI specification. Combining these features, Web services can be integrated in other applications or even in other Web services. WSDL and UDDI can coexist because UDDI documents can link to WSDL documents. Using this scenario, UDDI is used for exposing the Web services to the world and WSDL is used for describing the Web service functionality, which is defining the operations and the parameters. Issues not solved There are a lot of positive things that comes with Web services, but there are also issues that it does not solve, or it is dependent on other technologies to solve [ibmpb]: 94

How do one find which Web services that exists in the world, and how do one know which ones that apply to a specific problem? UDDI is aimed for handling this particular issue. How do you insure reliable Web services? What tools are there to measure and identify unreliable services? What happens when a Web service goes off-line? How do you ensure that nobody else is snooping the transaction, and how do you ensure that data is not altered on the way, when communicating with a remote Web service? How do you identify who the user of a service is? How do one report to a Web service about the authentication scheme used in an application? A solution to the first issue is to add data encryption to in the Web service communication layer. What about support for transactions? There is a need for ACID two-phase commits. ACID is described in the EJB chapter. Two-phase commits means that when performing a commit to many open transactions in different Web services, if anything goes wrong during the transaction, all transactions for each involved Web services should be rolled back. This does not work when transactions can span for days, since resources are locked until the final commit is done. How do you manage a distributed system which relies on Web services on different remote places? How do you coordinate development? How do you debug applications that uses Web services? Should there be a remote debugging facility somehow? There are existing techniques for solving many of these issues, but there is a lot of work to be done to include them in the different Web service technologies. 95

References CelWP Caleigo Foundation Suite white paper, Caleigo, 2002 JSPS12 JSS23 Wohlin 2000 Adatia 2001 Pelegri-LLopart Eduardo, Java Server Pages Specification version 1.2", Sun Microsystems Inc, 2001, http://jcp.org/aboutjava/communityprocess/final/jsr053/index.html Coward Danny, "Java Servlet Specification Version 2.3", Sun Microsystems Inc, 2001, http://jcp.org/aboutjava/communityprocess/final/jsr053/index.html Claes Wohlin, Per Runeson, Martin Höst, Magnus C Ohlsson. Björn Regnell, Anders Wesslén, "Experimentation in software engineering, An introduction", 2000, Kluwer Academic Publishers, USA Rahim Adatia, Faiz Arni, Kyle GabHart etc, "Professional EJB", Wrox Press Ltd, 2001 w3car Web Services Architecture Requirement, W3C Working Draft August 19, 2002, http://www.w3.org/tr/2002/wd-wsa-reqs-20020819 w3cwsa w3c w3cs w3csc Web Services Activity, http://www.w3.org/2002/ws The World Wide Web Consortium, http://www.w3c.org SOAP 1.2 Working draft June 26, 2002, http://www.w3.org/tr/2002/wdsoap12-part1-20020626/ XML Schema Part 1: Structures, http://www.w3.org/tr/xmlschema-1/ idc0502 IDC, press release 28 May, 2002 xmle Rich Salz, Transporting binary data in SOAP, www.xml.com, 2002-08-28, http://www.xml.com/pub/a/2002/08/28/endpoints.html ibmbp Holt Adams, Dan Gisolfi, James Snell, Raghu Varadan, Best practices for Web services, September 2002, http://www- 106.ibm.com/developerworks/webservices/library/wsbest1/?dwzone=webservices ibms Bilal Siddiqui, Deploying Web services with WSDL - Part 2, Mars 2002, http://www-106.ibm.com/developerworks/library/ws-intwsdl2/ jspsx WAP210 http10 http11 rfc2965 JavaServer Pages v1.2 syntax reference http://java.sun.com/products/jsp/syntax/1.2/syntaxref12.html WAP-210-WAPArch-20010712, Version 12-July-2001, http://www.wapforum.org/what/technical.htm HTTP 1.0 request for comment, http://www.w3.org/protocols/rfc1945/rfc1945 HTTP 1.1 request for comment, http://www.w3.org/protocols/rfc2616/rfc2616.html Request for comment nr. 2965, http://www.ietf.org/rfc/rfc2965.txt jsr24 Java Servlet Specification 2.4, http://jcp.org/aboutjava/communityprocess/first/jsr154/ rfc2617 Alur 2001 j2eebp Gamma 1995 DOM1 Request for comment nr 2617, ftp://ftp.isi.edu/in-notes/rfc2617.txt Alur, Crupi, Malks, "Core J2EE Patterns - Best Practices and Design Strategies", Sun Microsystems Press, 2001, J2EE blueprints, http://java.sun.com/blueprints/enterprise/ Gamma, Helm, Johnson, Vlissides, "Design Patterns", Addison-Wesley Pub Co, 1995 Document Object Model level 1, http://www.w3.org/tr/1998/rec-dom- Level-1-19981001/ 96

jdbc xmlcp jakvel html40 Java Database Connectivity API by Sun, http://java.sun.com/products/jdbc/ Enhydra XMLC project, http://xmlc.enhydra.org/project/aboutproject/index.html Jakarta Velocity project, http://jakarta.apache.org/velocity/index.html HTML 4.0 Specification, http://www.w3.org/tr/html4/ Struts Jakarta Struts project, http://jakarta.apache.org/struts/index.html All web references were checked for validity 2003-01-29 97