Miniwebcoach
Total Page：16
File Type：pdf, Size：1020Kb
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 2 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. 3 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. 4 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. 5 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 6 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) 7 ● 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” 8 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) 9 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 10 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. 11 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.