Miniwebcoach

MiniWebCoach

Project Report

Annaliese Fässler Muriel Bowie

Supervisor: Prof. J. Pasquier-Rocha Assistant: P. Fuhrer University of Fribourg, Switzerland

January 2004 Content

1. INTRODUCTION 3 2. THE ARCHITECTURE 4

2. 1 CLIENT-TIER 4 2. 2. APPLICATION-SERVER-TIER 5 2. 3 DATA-SERVER-TIER 5 3. PROJECT SCOPE DESCRIPTION 6

3. 1 DATABASE TABLES 6 3. 2 ENTITY BEANS 6 3. 3 SESSION BEANS 7 3. 4 XML-RELATED SESSION BEANS 9 3. 5 DATA TRANSFER OBJECTS 10 3. 5 XML FILES 11 4. LOMBOZ: A J2EE IMPLEMENTATION UTILITY 12 5. JUNIT TESTING 13 6. DEPLOYMENT 15

6. 1 JAVA ARCHIVES (JARS) 15 6. 2 WEB ARCHIVES (WARS) 15 7. CONCLUSION 16

7.1 DESIGN AND IMPLEMENTATION ISSUES 16 7. 2 SECURITY 17 7. 3 PERSONAL CONCLUSION 17 REFERENCES 18

1. Introduction

This project was completed within the scope of the master’s course “Advances Software Engineering” held by Professor J. Pasquier-Rocha at the University of Fribourg, Switzerland. It consisted of building a mini cyber coach based on a Java Entreprise Bean (EJB) Architecture which aims at maintaining profiles of athletes and providing different utilities for data interpretation. Situated within their own tier of the Java 2 Enterprise Edition (J2EE) specification, EJB components tie the presentation layer of an application to back-end enterprise information systems, such as databases or mainframes. EJB architecture utilises functionality from both EJB objects and the environment in which they run. The architecture of our project is straightforward. First, we defined a set of Entity Beans in order to maintain the database and its functionality. Subsequently, based on the database structure and the definition of the Entity Beans, we constructed a number of Session Beans in order to associate requests with a specific client. Session Beans act on a session-by-session basis. After a client requests and receives bean functionality, the session with that particular bean ends, leaving no record of what occurred.

2. The Architecture

Our architecture is a 3-tier architecture that is built up as follows:

Figure 1: Three tier architecture

2. 1 Client-tier

The client-tier is responsible for the presentation of data, receiving user events and controlling the user interface. The actual business logic (e.g. calculating added value tax) has been moved to an application-server. Our client is not a “real world” client which would be found in a professional enterprise. As this project mainly aims at building up tha application- and the data-server-tier, our client-tier is a simple JUnitEE-Servlet and therefore rather a testing tool than a “real” client. Although it would be easily possible to extend the architecture in order to support a real form-based client that accepts requests and entries from a client user.

2. 2. Application-server-tier

The application-server-tier is new, i.e. it isn’t present in 2-tier architecture in this explicit form. Business-objects that implement the business rules "live" here, and are available to the client-tier. This level now forms the central key to solving 2-tier problems. This tier protects the data from direct access by the clients. Consequently, this is also were our Entreprise Java Beans “live”, that means, all the Entity Beans which are responsible for interacting with the data-server-tier and the Session Beans which implement the actual business logic.

2. 3 Data-server-tier

The data-server-tier is responsible for data storage. In our case it consists of a relational database that can be maintained through the Entity Beans in the application-server-tier. It is important to note that boundaries between tiers are logical. It is quite easily possible to run all three tiers on one and the same (physical) machine. The main importance is that the system is neatly structured, and that there is a well planned definition of the software boundaries between the different tiers.

3. Project Scope Description

This project has been fully implemented by both of us.

3. 1 Database Tables

The following tables have to be described: 1. Person 2. Login 3. Activity 4. Athlete 5. Discipline

3. 2 Entity Beans

The following Entity Beans have been implemented in order to map the relational database tables: 1. Person: A person’s profile 2. Login: A person’s login information 3. Activity: An athletes activity profile 4. Athlete: A person’s athlete profile 5. Discipline: To maintain a list of involved disciplines 6. Primary Key Generator: Maintains a list of the table’s primary keys an increments the according values if a primary key is required by a session bean

Figure 2: Entity Bean UML

3. 3 Session Beans

The following Session Beans have been implemented in the business logic:

1. Person Management Façade Session Bean The implemented use cases include: ● Insert Person: Insert a person’s profile and creates a login profile for that same person. Arguments: DTOPerson (see section 3.4) Return value: The primary key of the inserted person (an integer value)

● Update Person: Update a person’s profile and the person’s login profile. Arguments: DTOPerson (see section 3.4) Return Value: none ● Delete Person: Delete a person’s profile and all related information, that means, the person’s login profile, as well as the athletes and the activities . Arguments: A person’s Integer primary key Return value: none ● Insert Athlete: Insert a new athlete for a person. The newly created athlete is subsequently set as the current athlete of that same person. Arguments: DTOAthlete (see section 3.4) Return value: The primary key of the inserted athlete

2. Activities Information Façade Session Bean The implemented use case includes: ● Search activities for person from [date] to [date]: Searches activities for a person for a specified time interval. Arguments: DTOActivitiesForPerson Return value: returns a Collection of activities ● Search activities for person and discipline from [date] to [date]: Searches activities for a person and discipline for a specified time interval. Arguments: DTOActivitiesForPerson Return value: returns a Collection of activities ● Get total distance for person and discipline from [date] to [date]: Gets the total distance for a person and a discipline for a specified time interval. Arguments: DTOActivitiesForPerson Return value: returns an Integer value “distance”

Figure 3: Bean Container

3. 4 XML-related Session Beans

In order for the input to the different Test Cases to be changeable during runtime, we decided to adopt an a solution based on XML. The XML is parsed with a simple SAX-Parser, that is implemented in a Session Bean. Such an XML solution could be also used, when implementing a real Web-Interface. The following XML-parsing session beans have been implemented: ● Person XML Parser: Parses a person-related XML file and generates a DTOPerson as output. Arguments: XML Input File (person.xml) Return value: DTOPerson (see section 3.4) ● Athlete XML Parser: Parses a athlete-related XML file and generates a DTOAthlete as output. Arguments: XML Input File (athlete.xml) Return value: DTOAthlete (see section 3.4) ● Activities For Person XML Parser Parses a XML file that contains the necessary information in order to create a DTOActivitiesForPerson. Arguments: XML Input File (activiesforperson.xml)

Return value: DTOActivitiesForPerson

3. 5 Data Transfer Objects

When using remote interfaces, each call to it is expensive. As a result, for performance reasons, it makes sense to reduce the number of calls, and that means to transfer more data with each call. One way to do this is to use a large amount of parameters. However, this is often awkward to program - indeed, it's often impossible with languages such as Java that return only a single value. The solution is to create a Data Transfer Object (DTO) that can hold all the data for the call. It needs to be serializable (in Java: implements Serailizable) to go across the connection. Usually an assembler is used on the server side to transfer data between the DTO and any domain objects.

The following data transfer objects (DTO) have been implemented: • DTO Person A DTO to match the Person and Login Entity Bean • DTO Activities A Java Vector of DTOActivty objects • DTO Activity A DTO to match the Activity Entity Bean and Discipline Information • DTO Discipline A DTO to match the Discipline Entity Bean

Figure 4: Project Overview

3. 5 XML Files

In order to make testing easier during execution, we provide a mapping of XML files with the data transfer objects. That means, when using the JUnitEE Servlet for testing, the data which has to be provided for the use cases to be tested, is extracted from an XML file. The XML file mapping could be subsequently also used when working with a “real” client interface, such as a Servlet, as it would make data fetching and transport much easier. In most cases, the XML file could even completely replace the Data Transfer Objects. But as our project definition was based on DTO’s we didn’t want to change the architecture.

4. Lomboz: A J2EE Implementation Utility

Lomboz is a development tool for the J2EEplatform. It is an eclipse plugin for building, testing, and deploying Java2 Enterprise Edition (J2EE) and Web service applications. Lomboz philosophy is that J2EE application development is an end-to-end integrated process. It must involve all stages of the application development process from coding, compiling, deploying, testing and debugging. All of its behaviours can be modified. It uses standard open source frameworks such as Ant, XDoclet, Jasper, Axis to do this. Lomboz is not specific to any application server. It requires that the applications server supports the J2EE 1.2 specification or higher and be based on Java. All server definitions are externalized so that developers can add their own to the list of supported servers. Lomboz comes pre-packaged with definitions for Apache Tomcat, JBoss, BEA Weblogic Server. We started this project, using Lomboz as an implementation utility, hoping that this would help us concentrate on the important implementation aspects, without taking care of the rest. Unfortunately, it turned out that Lomboz, although we consider it a great step in the right direction, is still not sufficiently stable to be used in an J2EE project. We found several bugs in the implementation of Lomboz which make Lomboz quite unreliable. Due to this problems, we finally decided to use Xdoclet instead for the generation of the EJB interfaces and the related XML files, which somehow seems to be more reliable. Nevertheless, we will carefully watch the development process of Lomboz, as we really think it could be a very helpful tool for future EJB projects.

5. JUnit Testing

Most developers agree that they should test their code before it is delivered and use tools to detect any regression. A simple way to do this is to implement tests in a main() method in all Java classes. Although this might be appropriate for single Java classes, testing can be much more difficult when several classes are involved. JUnit provides a simple framework to address these issues. Unfortunately, JUnit was mainly defined for client-side applications and is therefore not well suited when used in J2EE applications. JUnit comes with three TestRunners: an AWT application, a Swing application, and a text-based command-line application. Neither are they suitable for running in an app-server environment nor do they output the HTML we desire.

Figure 5: HTML form to start a test case.

There is no reason for not using the standard TestRunners when writing tests as external clients to the application server. But this is undesirable for several reasons: First, it is necessary to set up all the client JNDI properties in the test cases, making it difficult to run against several different test servers. Also, it takes some time to set up a standalone client.

Figure 6: JUnitEE Servlet Testing Screen.

If the production clients are servlets running inside the application server, the tests could be affected by being run in a different execution environment. Additonally, it is not possible to unit test your non-EJB web-application components. JUnitEE, in contrast, provides a TestRunner which outputs HTML and a servlet which can be used as an entry point to the cases. Building a test as a standard J2EE web application means: The tests are packaged conveniently into a “.war” file which can easily be moved between servers; the ” .war” file can be placed in the main “.ear “ file and therefore it is simple to avoid enabling the test web application on the production server. The test classes will be dynamically reloaded by the application server (assuming the server supports this), and the test cases look just like the production code, and can use the same beans as a facade for your EJBs.

6. Deployment

Web and EJB components are packaged separately into Web Archives (.war files) and Java Archives (.jar files). JARs and WARs are assembled into an EAR. All the components can be deployed independently.

6. 1 Java Archives (JARs)

The ejb-jar file must contain the deployment descriptor. The deployment descriptor must be stored with the name META-INF/ejb-jar.xml in the ejb-jar file. For each enterprise bean, the ejb-jar file must include the class files of the following: ● The enterprise bean classes. ● The enterprise bean home and remote interface. ● The primary key class if the bean is an entity bean. The ejb-jar file must also contain the class files for all the classes and interfaces that the enterprise bean class, and the remote and home interfaces depend on. This includes their super-classes and super-interfaces, and the classes and interfaces used as method parameters, results, and exceptions. An ejb-jar file does not have to include the class files of the home and remote interfaces of an enterprise bean that is referenced by an enterprise bean in the ejb-jar, or other classes needed by the referenced enterprise bean.

6. 2 Web Archives (WARs) A Web Archive is an assembly of Web components that is deployed on the web server. It consists of one or more of the following: ● Servlets (in our case, the JunitEE Servlet) ● JavaServer Pages ● Taglibs ● Utility classes ● JAR files ● Static documents (HTML, images, text...)

A Web application is rooted at a specific path within a Web server. The URL by which a Servlet is known on the J2EE platform depends on the J2EE application in which it was deployed, so for reasons of robustness, servlets that call one another must be packaged and deployed together. Since a WAR is typically deployed under its own context root, static content that is cross- linked has to be packaged in a single .war file to avoid broken links. Static content is also typically reusable.

7. Conclusion

7.1 Design and Implementation Issues

During the implementation of the project different design issues came up. One major issues is concerned with the implementation of the autoincrement in the entity beans. Of course, Jboss provides facilities to implement an autoincremt mechanism. Although, it would have been easy to simply use the Jboss specific mechanism, we decided to make our implementation a bit more application server independent, by adapting our own solution with an additional entity bean that keeps track of all the primary keys in the related tables. Other design methods are possible, but it did not seem necessary for this project to implement a more sophisticated primary key generator. Another problem concerns the “blob” in the Activity database table. During the implementation of the activity-related Session Beans we always encountered an Exception that was due to the fact that the “blob”-Object is not a serializable Object. In a “real world” situation hardly anybody would consider using a “blob” in a database, but would load the concerned files to a specific folder that resides on the server and then just write a string to the database table which contains the full file path. Therefore, we decided that for this project, we actually don’t really make use of the XML file loaded to the database table, and we simply deleted it from our tables and removed it in the implementation of the Activity Entity Bean.

Another issue occurred when using different utilities, such as Lomboz to implement our project. It somehow turned out that most utilities, do not hold what they promise. Bugs in the implementation of those utilities require for the user to pay much attention to the whole autogeneration process. Finally, we reckoned that it is actually easier to use Xdoclet for generating the XML files and the ejb-related interfaces instead of using a utility such as Lomboz.

7. 2 Security Security is actually an important issue when dealing with J2EE Architectures. Access control is therefore crucial, as well as data protection. For this project, we did not implement any security mechanism, but just relied on the mechanisms provided by the EJB Container. Additional security and transaction mechanisms could be added to enhance security.

7. 3 Personal Conclusion The project that was completed within the scope of the master’s course “Advances Software Engineering” held by Professor J. Pasquier-Rocha at the University of Fribourg, Switzerland, consisted of building a Mini Cyber Coach based on a Java Entreprise Bean (EJB) Architecture. It was the first time that we dealed which J2EE Applications, and consequently, there was much preliminary learning necessary in order to successfully complete the required tasks. Personally, we found this project a very interesting, but strenuous assignment. The most time- consuming part was the processing of information finding and gathering, especially concerning Xdoclet definitions. All in all, we can say though, that we really learnt a lot during the implementation of the project, especially about the whole process of development, deployment , and testing.

References

[1] The image on the title page was taken from: http://www.tux.org/~bagleyd/unicycle_factory/cartoons/evolution.gif

[2] The JUnitEE website: http://www.junitee.org

[3] The “Advanced Software Engineering” course homepage: http://diuf.unifr.ch/courses03-04/ase

[4] Richard Monson-Haefel, Entreprise JavaBeans, 3rd Edition, O’Reilly & Associates, Cambridge (MA), 2001.

[5]The “objectlearn “ homepage: http://www.objectlearn.com/products/lomboz.jsp