Reseda E-Shop.

Planning, Design and Implementation of an Online-Shop for Reseda Engineering.

Master Thesis

Beat Raess
July 2006

Thesis supervisors: Prof. Dr. Jacques Pasquier-Rocha and Dr. Patrik Fuhrer Software Engineering Group

Software Engineering Group Department of Informatics University of Fribourg (Switzerland)

So long, and thanks for all the sh. - Douglas Adams

Acknowledgements

The Reseda E-Shop project was accomplished in collaboration with the Software Engineering Group, Reseda Engineering and die3.

ii

iii

Abstract
Reseda is a new company in the furniture business. The enterprise is divided into Reseda Engineering, responsible for the design, development and marketing of the products, and Reseda Home, concerned with the production and sale. The Reseda E-Shop master project consists of the planning, design and implementation of an online shop and website for Reseda Engineering. An online shop, internet shop, webshop or online store is an electronic commerce application used for B2B or B2C [Wik05b], which serves to sell products or services over the internet. As such, an online shop is part of the e-commerce eld of the e-business framework. The two primary objectives of the Reseda E-Shop application are the presentation of the companys products on the website and the possibility for online orders and consultings. Further features include general company information (company, employees, products, factory, showroom), contact possibilities (address and email, email form, address form), news (online news, newsletter, rss feed), customer account (customer data, orders, consultings) and support options (Frequently Asked Questions (FAQ), general terms, legal notice, links). All these storefront features of the online shop can be managed online in the storeback area. In order to fulll the objectives of the e-shop, the design of the application needs to be clean, modular, extensible and well documented. As a consequence, the project relies on Unied Modeling Language (UML) diagrams, design patterns and frameworks. The application is based on a multi-tier architecture using Java 2 Platform, Enterprise Edition (J2EE) and implemented with Enterprise JavaBeans (EJB), Struts and Hibernate, as well as various other frameworks (e.g. OSCache, FOP, JDOM, POI, ROME) and tools (e.g. Ant, XDoclet). This report covers the necessary business background required for the project, it includes the applications specication as well as notes concerning the involved technology and the implementation. In addition to the report, also manuals for the e-shops features, administration and management tasks are available.

Keywords: E-Business, E-Commerce, Online Shop, E-Shop, UML, Design Patterns, Multi-Tier Architecture, Java, J2EE, EJB, Struts, Hibernate, OSCache, JUnit, DbUnit, Cactus, Commons Beanutils, Commons Email, Log4j, FOP, JDOM, POI, ROME, Ant, XDoclet

Table of Contents

1. Introduction 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Notations and Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Business Aspects 2.1. Reseda . . . . . . . . . . . . . . . . . . . 2.1.1. Background . . . . . . . . . . . . 2.1.2. A Franchising System . . . . . . . 2.1.3. Products . . . . . . . . . . . . . . 2.1.4. Market . . . . . . . . . . . . . . . 2.1.5. Target Group . . . . . . . . . . . 2.1.6. Strategy . . . . . . . . . . . . . . 2.2. E-Business . . . . . . . . . . . . . . . . . 2.2.1. E-Business Framework . . . . . . 2.2.2. E-Commerce . . . . . . . . . . . 2.2.3. Best Practices of Online Retailing 2.2.4. Exemplary Internet Shops . . . . 2.3. Online Shop . . . . . . . . . . . . . . . . 2.3.1. Architecture . . . . . . . . . . . . 2.3.2. Basic Functionalities . . . . . . . 2.3.3. Processes . . . . . . . . . . . . . 2.3.4. Product Catalog . . . . . . . . . 2.3.5. Existing Online Shop Software . .

2 2 3 4 5 5 6 6 7 7 8 8 8 9 9 11 12 13 13 14 16 17 18 19 20 21 22

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

3. Specication 3.1. Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1. ShopCong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2. CatalogMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

iv

Table of Contents

v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 22 23 23 24 24 24 25 25 25 26 26 27 28 29 29 30 31 31 33 35 35 36 36 36 36 37 37 39 40 40 41 42 42 43 45 46 46 47

3.1.3. ProductMgmt . . . . . . . . 3.1.4. BrowseProductCatalog . . . 3.1.5. ProductInfo . . . . . . . . . 3.1.6. ShoppingBasket . . . . . . . 3.1.7. CompanyMgmt . . . . . . . 3.1.8. CompanyInfo . . . . . . . . 3.1.9. NewsMgmt . . . . . . . . . 3.1.10. News . . . . . . . . . . . . . 3.1.11. Contact . . . . . . . . . . . 3.1.12. SupportMgmt . . . . . . . . 3.1.13. Support . . . . . . . . . . . 3.1.14. Account . . . . . . . . . . . 3.1.15. AccountMgmt . . . . . . . . 3.1.16. Order . . . . . . . . . . . . 3.1.17. OrderMgmt . . . . . . . . . 3.1.18. Consulting . . . . . . . . . . 3.1.19. ConsultingMgmt . . . . . . 3.1.20. ValidateInput . . . . . . . . 3.2. State Diagram . . . . . . . . . . . . 3.3. Object Model . . . . . . . . . . . . 3.3.1. Product Catalog . . . . . . 3.3.2. Order and Consulting Items 3.3.3. Account . . . . . . . . . . . 3.3.4. Company and Employees . . 3.3.5. News . . . . . . . . . . . . . 3.3.6. Support . . . . . . . . . . . 3.3.7. Shop Cong . . . . . . . . . 3.4. Development Methodology . . . . .

4. Technology 4.1. Multi-Tier-Architecture . . . . . . . . . . . . 4.1.1. Three-Tier Model . . . . . . . . . . . 4.1.2. Five-Tier Model . . . . . . . . . . . . 4.2. J2EE . . . . . . . . . . . . . . . . . . . . . . 4.2.1. Component Model . . . . . . . . . . 4.2.2. Enterprise JavaBeans (EJB) . . . . . 4.2.3. Servlets and Java Server Pages (JSP) 4.3. Software Products . . . . . . . . . . . . . . . 4.3.1. J2EE Application Server . . . . . . . 4.3.2. Database . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

Table of Contents

vi (IDE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 48 49 52 54 55 55 57 57 58 58 61 63 63 65 66 66 67 70 70 70 72 72 72 73 75 79 84 92 97 101 102 103

4.3.3. Integrated Development Environment 4.3.4. Development Tools . . . . . . . . . . 4.3.5. Frameworks . . . . . . . . . . . . . . 4.4. Conclusion . . . . . . . . . . . . . . . . . . . 5. Implementation 5.1. Overview . . . . . . . . . . . . . . 5.1.1. Architecture . . . . . . . . 5.1.2. Development . . . . . . . 5.1.3. J2EE Application . . . . . 5.2. Presentation Tier . . . . . . . . . 5.2.1. Presentation Tier Patterns 5.2.2. Struts . . . . . . . . . . . 5.3. Business Tier . . . . . . . . . . . 5.3.1. Business Tier Patterns . . 5.3.2. EJB Session Beans . . . . 5.4. Integration Tier . . . . . . . . . . 5.4.1. Integration Tier Patterns . 5.4.2. Hibernate . . . . . . . . . 6. Conclusion 6.1. Achievements . . . . . 6.1.1. Application . . 6.1.2. Website Design 6.1.3. Deployment . . 6.2. Possible Enhancements 6.3. Final Thoughts . . . . A. Screenshots B. Ant C. Struts D. EJB E. Hibernate F. License of the Documentation G. Website of the Project H. CD-ROM

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

Table of Contents

vii 104 106 109

I. Common Acronyms References Referenced Web Ressources

List of Figures

1.1. Reseda E-Shop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 3.1. 3.2. 3.3. 3.4. 3.5. 4.1. 4.2. 4.3. 4.4. 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. 5.8. 5.9. Franchising System (cf. [Res05, p. 9]) . . . . . E-Business Framework [Sch05] . . . . . . . . E-Commerce Customer Cycle (cf. [Sch05]) . . Multi-Tier Shop Architecture [Mer02, p. 411] Basic Shop Functionalities . . . . . . . . . . . Basic Storefront Process (cf. [Mer02, p. 410]) Generic Product Catalog [Mer02, p. 415] . . . Online Shop Use-Case Diagram . . . . Online Shop Storefront State Diagram Online Shop Storeback State Diagram Online Shop Object Model . . . . . . . Development Process [Fow02, p. 14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 6 9 10 14 15 16 17 21 32 33 34 37 40 41 43 44 55 56 59 59 60 61 61 64 65

Three-Tier Architecture [Wik05c] . . . . . . Five-Tier Architecture [ACM03, p. 120] . . . J2EE Server and Containers [Sun05d, p. 10] EJB 2.1 Architecture [MH04, p. 20] . . . . . Implementation Overview . . . . . . Reseda E-Shop Architecture . . . . . Model-View-Controller [Hus03, p. 44] Service To Worker [ACM03, p. 279] . Context Object [ACM03, p. 183] . . Composite View [ACM03, p. 265] . . Struts Architecture [Hus03, p. 15] . . Session Faade [ACM03, p. 344] . . . Business Delegate [ACM03, p. 305] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

viii

List of Figures

ix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 67 68 69 76 76 77 77 78 78

5.10. Service Locator [ACM03, p. 318] . . 5.11. Transfer Object [ACM03, p. 417] . . 5.12. Data Access Object [ACM03, p. 464] 5.13. Hibernate Architecture [Hib05, p. 24] A.1. A.2. A.3. A.4. A.5. A.6. Screenshot: Screenshot: Screenshot: Screenshot: Screenshot: Screenshot: Product Catalog . . . Product Information Shopping Basket . . . Order Process . . . . Manager . . . . . . . Administrator . . . . . . . . . . . . . . . .

List of Tables

2.1. 2.2. 2.3. 2.4. 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8.

Product Lines (cf. [Res05, p. Furniture Companies . . . . Exemplary Online Shops . . Online Shop Software . . . .

14-15]) . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

7 7 13 18 42 46 47 48 48 50 51 52 57

Java Enterprise APIs . . . . . . . . . . . . . Software Products: J2EE Application Server Software Products: Database . . . . . . . . Software Products: IDE . . . . . . . . . . . Software Products: Tools . . . . . . . . . . . Software Products: Frameworks . . . . . . . Software Products: Frameworks (Logic) . . . Software Products for the Online Shop . . .

5.1. EAR Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Listings

B.1. B.2. B.3. B.4. C.1. C.2. C.3. C.4. C.5. C.6. C.7. C.8. C.9. D.1. D.2. D.3. D.4. D.5. E.1. E.2. E.3. E.4. E.5.

Ant Build File (Part 1/4): build.xml . . . . . . . . . . . Ant Build File (Part 2/4): build.xml . . . . . . . . . . . Ant Build File (Part 3/4): build.xml . . . . . . . . . . . Ant Build File (Part 4/4): build.xml . . . . . . . . . . . Struts Form (Part 1/2): ProductForm.java . . . . . . . . Struts Form (Part 2/2): ProductForm.java . . . . . . . . Struts Action (Part 1/2): SaveOrUpdateProductAction.java Struts Action (Part 2/2): SaveOrUpdateProductAction.java Struts Core Conguration (Part 1/2): struts-cong.xml . Struts Core Conguration (Part 2/2): struts-cong.xml . Struts Tiles Denitions: tiles-defs.xml . . . . . . . . . . . Struts Validator Rules: validator-rules.xml . . . . . . . . . Struts Validator Validation: validation.xml . . . . . . . . Business Delegate: ProductMgmtDelegate.java . . . . . . . Business Delegate Interface: IProductMgmtDelegate.java . EJB Session Bean: ProductMgmtSessionBean.java . . . . . EJB Deployment Descriptor: ejb-jar.xml . . . . . . . . . JBoss Deployment Descriptor: jboss.xml . . . . . . . . . Hibernate Bean: ProductHB.java . . . . . . . . . . . . . . Hibernate XML Mapping File: ProductHB.hbm.xml . . . . Hibernate Conguration: hibernate.cfg.xml . . . . . . . . Hibernate MBean: jboss-service.xml . . . . . . . . . . . . Persisting Objects . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

80 81 82 83 85 86 87 88 89 90 90 91 91 93 93 94 95 96 98 99 99 100 100

1
Introduction
1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Notations and Conventions . . . . . . . . . . . . . . . . . . . . . 2 3 4

Reseda is a new company active in the furniture business. The company consists of Reseda Engineering, responsible for the design, development and marketing of the products, and Reseda Home, concerned with the production and sale. This division allows the enterprise to concentrate the cost intensive aspects of the business in a central unit, and to combine the production and sale in several independent shops. Due to this structure, costs are reduced and therefore Reseda Home can oer high quality products at a reasonable price. The master project Reseda E-Shop consists of the planning, design and implementation of an online shop and website for Reseda Engineering. This e-shop is a three-tier application using the J2EE technology. The application needs to reect the structure and strategy of this new company and must be suited to their specic needs.

1.1. Objectives
The two primary objectives of the e-shop application are the presentation of the companys products on the website and the possibility for online orders and consultings. In addition to the web application, the complete website needs to be designed and programmed. The long term goal of this project is to provide all data related to product information, orders and customers in an electronical form, such that it could be used in a future production system for further tasks like order processing, bookkeeping or analytical purposes (e.g. data warehouse). For the product presentation, all products and their relevant information are stored in a database. The websites content is afterwards generated from this information and a customer can browse the oered products on the site and obtain detailled information about a specic product. The second step is to oer the possiblity for online orders and consultings. A customer at home can make an order of a product, customized with the available options, or request a consulting to obtain more information. Apart from these primary goals, tools for the administration of the online shop and website as well as for the corresponding management tasks are required.

1.2. Document Structure

Figure 1.1.: Reseda E-Shop

In order to fulll the objectives of the e-shop, the design of the application needs to be clean, modular, extensible and well documented. Customer related as well as security aspects should be implemented. As a consequence, the use of UML diagrams, design patterns and the integration of existing frameworks is a must.

1.2. Document Structure

The report is structured into a business part, the specication, technology, implementation and a conclusion. In addition to this report, also a manual of the features (cf. [Res06b]), as well as for the administration (cf. [Res06a]), management (cf. [Res06e]) and installation (cf. [Res06d] and [Res06c]) of the online shop is available. It is recommended to directly try out the application with the easy to install evaluation version (cf. [Res06c]). Chapter 2 covers the business aspects of the Reseda E-Shop project. First, background information is given on the companies Reseda Home and Reseda Engineering. Afterwards, e-business and especially the eld of e-commerce is introduced, and nally, the focus is on online shops.

1.3. Notations and Conventions

The next chapter contains the specication of the J2EE application. A specication is an abstract and formal description of an applications requirements and functionalities, which is independent of the actual software or hardware used. First, a UML use-case diagram gives an overview over the functionalities. A state diagram then outlines the involved processes and a class diagram captures the underlaying object model. An outline of the adopted development methodology nally concludes this chapter. Chapter 4 gives an overview of the technology involved for the online shop application. Current e-business applications are essentially web applications based on a multi-tier architecture. In principle, a multitiered architecture separates an application into several independent components. Frameworks then provide developers with a reusable common structure, as often required by such applications. This section includes an introduction to multi-tier architectures and J2EE as well as the corresponding available software and frameworks. The focus of Chapter 5 is on the implementation of the reseda e-shop application. For the development of this J2EE application, the integration-, business- and presentation tier had to be implemented. This section rst provides an overview over the involved layers and components as well as on the project itself. Afterwards, the implementation of the presentation-, business- and integration-tier is explained in more details.

1.3. Notations and Conventions

This report uses the notations and conventions as dened by the documentation guidelines of the Software Engineering Group: The report is devided in Chapters, which are broken down into Sections. Where necessary, sections are further broken down into Subsections, and subsections may contain Paragraphs. Cited literature is given in References, while references to web sites are listed in Referenced Web Resources. Figures, Tables and Listings are numbered inside a chapter. Diagrams are based on the UML standard. Acronyms are listed in the appendix and only expanded the rst time they are used. For the formatting of the text, the following conventions apply: Italic is used for emphasis and to signify the rst use of a term. Courrier is used for web addresses. Code is used in anything that would be typed literally when programming.

2
Business Aspects
2.1. Reseda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2. A Franchising System . . . . . . . . . . . . . . . . . . . . . . . 2.1.3. Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.4. Market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.5. Target Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.6. Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. E-Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1. E-Business Framework . . . . . . . . . . . . . . . . . . . . . . . 2.2.2. E-Commerce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3. Best Practices of Online Retailing . . . . . . . . . . . . . . . . 2.2.4. Exemplary Internet Shops . . . . . . . . . . . . . . . . . . . . . 2.3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2. Basic Functionalities . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3. Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.4. Product Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.5. Existing Online Shop Software . . . . . . . . . . . . . . . . . . 5 6 6 7 7 8 8 8 9 9 11 12 13 14 16 17 18

2.3. Online Shop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chapter 2 covers the business aspects of the Reseda E-Shop project. First, background information is given on the companies Reseda Home and Reseda Engineering. Afterwards, e-business and especially the eld of e-commerce is introduced, and nally, the focus is on online shops.

2.1. Reseda
Reseda is a new company in the furniture business, whose main strategy is based on a franchising system. The company consists of Reseda Engineering, responsible for the

2.1. Reseda

Figure 2.1.: Franchising System (cf. [Res05, p. 9])

design, development and marketing of the products, and Reseda Home, concerned with the production and sale. This division allows the enterprise to concentrate the cost intensive aspects of the business in a central unit, and to combine the production and sale in several independent shops. Due to this structure, costs are reduced and therefore Reseda Home can oer high quality solid wood furniture at a reasonable price. The next paragraphs explore the background, franchising system and the products of the company in more details. Then, the market, target group and strategy of Reseda is presented.

2.1.1. Background
The original business idea for Reseda was hetched in 2003 and gradually put into practice in the two subsequent years. In September 2005, the rst Reseda Home store opened in Spreitenbach. By the end of 2006, it is planned to establish a second branch. In 2007 and 2008, there should be each year two new shops and from 2009 on three new shops a year. As of June 2006, there are nine people involved in the company. Andreas Niederer is responsible for the management of Reseda Engineering, Helmut Niederer and Urban Meier for the design of the products, Paul Niederer is concerned with the design of the shops and Pascal Schneider is the manager of the rst Reseda Home store in Spreitenbach.

2.1.2. A Franchising System

The standard marketing system in the furniture business consists of several cost intensive steps: design of the product, production, sales organisation, trade fair, distributor and nally the point of sale. Reseda overcomes this structure by its franchising system (cf. Figure 2.1). Reseda Engineering centralizes the cost intensive parts of design, development and marketing and oers these services to all independent Reseda Home branches. Reseda Home then is only concerned with the production and sale of the products. Reseda Engineering is the franchisor of this system. Apart from the design, development and marketing of the products, also Information Technology (IT) solutions for production, organisation and administration are provided. Further responsibilities include the procurement of material, quality control, search for new franchisees and nancing solutions. The franchisee then is Reseda Home. The concept is to have several small, independent shops with 4-7 employees each, where the production and sale is done strictly on demand.

2.1. Reseda

A client can order a customized product, which is afterwards manufactured in the same shop by a computer based production system. Apart from the good price, the customer is also oered a unique purchase experience, as he can see how his new furniture is produced in the shop.

2.1.3. Products
Reseda oers high quality, customized and individual solid wood furniture at a reasonable price. These products are manufactured in all important wood species like beech, maple, ash, oak, birch, pine, cherry and nut tree wood. Three dierent product lines - Reseda green, Reseda yellow and Reseda red - are aimed at the various price segments of the target market. Table 2.1 compares these product lines according to the estimated householdcome in, wood species and prize range. Product Line Reseda green Reseda yellow Reseda red Income [SFr] > 60000 > 90000 >120000 Wood Species Birch, Pine, Fir Beech, Maple, Ash, Oak Cherry-, Nut-Tree Tables [SFr] 600 1200 1200 2800 2800 5000 Chairs [SFr] 180 250 250 500 500 1000 Beds [SFr] 600 1200 1200 2400 2400 4800

Table 2.1.: Product Lines (cf. [Res05, p. 14-15]) Apart from these product lines, the customer is further oered the possiblity to completely specify an individual furniture by himself. Together with an employee of Reseda Home, a client can draw the design of his piece of furniture on a grid. The furniture is then manufactured according to this plan.

2.1.4. Market
The current situation of the swiss furniture business consists of a total sales volume of 3.7 milliard swiss francs. The biggest market participants are Mbel Pster with 15% and IKEA with 14% market share. Further participants in this low and middle price segment are for example Micasa, Conforama or Interio. Table 2.2 lists these companies and their websites. Company Mbel Pster IKEA Micasa Conforama Interio URL http://www.moebelpfister.ch http://www.ikea.com http://www.micasa.ch http://www.conforama.fr http://www.interio.ch

Table 2.2.: Furniture Companies

2.2. E-Business

The remaining 25% of this market (940 million swiss francs) are high quality furniture companies, smaller specialized furniture stores, design boutiques and carpenters workshops. As a consequence, these kind of furniture companies are considered as Resedas strongest competitors. Reseda mainly concentrates on this high price segment of the market, but also tries to establish itself in the middle price segment.

2.1.5. Target Group

The target market of Reseda consists of customers with the needs for high material and design quality, lasting, durable, authentic products with a good price-achievement ratio, people who desire a high living quality and customized and individual furniture, which are at the same time modern and timeless. It is assumed, that this target group consists of about a third of the high price segment market, which is about 8% of the whole swiss furniture market.

2.1.6. Strategy
The vision of Reseda is to become the leader in its market segment. This objective requires a share of 20-25% of the target market, respectively 1.6-2.0% of the whole swiss furniture market. The objective is achieved due to the benets of the franchising system as well as due to Resedas high quality products and further competitive advantages. The franchising system allows to oer reduced costs. This is due to the fact that there is no intermediary trade involved, production is done strictly on demand, the transport from the production to the point of sale is omitted, the small manufacturing area, no stockkeeping is necessary and also because of the synergies in the human resource management. The further competitive advantages include the high quality, solid wood products, the oering of all common species of wood, a high design as well as product and manufacturing quality, an individual customization of the products as well as a common brand - Reseda Home - and marketing for all branches. This altogether leads to a unrivaled price-achievement ratio. Despite this ambitious objective, Resedas corporate values should not be neglected. All employees participate in the success of Reseda, as their salary consists of a base salary and a share of the success. Reseda Home is further obliged to honesty towards its contacts, mainly its customers. But also the ecological and social environment is of central importance for Reseda.

2.2. E-Business
Electronic business (e-business) refers to any business process that is empowered by an information system [Wik05a]. The objective is to link a companys internal and external processes more eciently and to integrate partners and suppliers in order to better satisfy the customers needs. The next paragraph introduces the basic notions and terms of e-business. Then, the focus is on e-commerce and online shops as well as the best practices for online retailing and exemplary internet shops.

2.2. E-Business

Figure 2.2.: E-Business Framework [Sch05]

2.2.1. E-Business Framework

The whole e-business framework (cf. Figure 2.2) can be classied into three main elds: e-procurement, e-commerce and e-government. E-procurement describes the electronic support of buying processes (purchase) of a company [Sch05]. These activities are mainly concerned with the integration of software systems of dierent companies by means of an extranet. The eld of e-commerce then focuses on the electronic support for order and sale processes of products and services to either customers or other companies. For the sale to customers, this is most often accomplished by means of an online shop. Finally, the term e-government refers to the relations between a company or citiziens to the administration. This includes for example public tendering procedures or tax aairs in the case of enterprises, or electronic tax declarations for citiziens. Depending on the corresponding partner involved, the terms Business-to-Business (B2B), Business-to-Consumer (B2C) or Business-to-Administration (B2A) are often used to describe the relation of a company to either enterprises, customers or the administration.

2.2.2. E-Commerce
In the eld of e-comerce, the most common option for a B2C relation is an online shop. Experience shows, that the internet should not be considered as a new business segment, but rather as an additional distribution channel to already existing ones (cf. case studies

2.2. E-Business

10

Figure 2.3.: E-Commerce Customer Cycle (cf. [Sch05])

[Koc03], [Eug00] and [Sch00]). The idea is to oer the customer the choice to use his preferred channel to either obtain information, buy products or get support. According to [Sch05], the typical phases of B2C e-commerce can be structured by the customer cycle (cf. Figure 2.3): motivation-, information-, agreement-, settlement- and loyalty phase. In the motivation phase, vendors want to make product or service information available for customers. The objective is to address potential customers and make them aware of a companys online presence. This web promotion can be based on common oine marketing, where the domain name is communicated through press releases, articles or the existing brand. But to take advantage of the medium internet, especially online marketing is of importance. This includes choosing a suitable domain name, search engine marketing to receive a high page ranking, inscriptions to portals, newsletters, sponsoring, ad banners and cross links from other sites. The information phase is concerned with product information and conguration, the shopping basket, support options and legal aspects. First, a company must decide which products it wants to sell over the internet and assemble them in a product catalog. For each product, information like article number, product description, price or images should be included, as this is the basis for the order request. Here it holds, that the visual impression is key. It should also be considered, that the internet often inuences oine buying behaviour: customers inform themselves on the internet and buy a product in a physical store afterwards. In addition to a simple product catalog, it is also possible to oer some kind of product conguration, where a customer can customize an article according to his needs. A client then can add all items she is interested in to a shopping basket, which lists information like article name, quantity, price, total costs and shipping fees. Another enhancement could be a personalized product catalog, where the customer only is oered the products that match his prole. In the information phase, a customer should further be informed about possible support options. This reinforces trust, as the customers feels that he can get into contact with the company if necessary. Possibilities here are FAQs, e-mail, telephone, fax or online forms. This phase further serves to make the customer aware of legal aspects. This includes for example the common terms and conditions of a company or information specic to online orders like shippment conditions. The terms and conditions of the contract, like e.g. price, delivery or payment conditions, are then negotiated in the agreement phase. For B2C relations, it is usually not an actual negotiation, but rather an acceptance of the terms by the customer. The common B2C process consists of the selection of products, the shopping basket, choosing payment and delivery options, clicking on the accept button and an order conrmation by e-mail. A central aspect of this phase is security. All sensitive data should be encrypted and transmitted over secure channels. For online shops, the question further arises, when this contract between the customer and the company is legally binding. Somehow contrary to oine sales, not the product catalog on the internet, but the order of the customer is rearged as the buying oer for online sales. It is then up to the company to either accept

2.2. E-Business

11

this oer and deliver the good, or reject. How this is treated and when this contract is legally binding must be indicated in the general terms and conditions of an enterprise. The settlement phase deals with the fulllment of the order. Here, the company transfers the property or rights to the customer and receives corresponding payment in return. In addition to the actual delivery, the customer can also be oered tracking or tracing, so that he can check the current status of his order. The main problem of this phase is liability, who is liable and where is the transfer point of the ordered good? Again, this point should be treated in the general terms and conditions. The last part of this e-commerce customer cycle is the loyalty phase. It deals with improving customer orientation and satisfaction in order to assure the retention of existing customers of an enterprise. To achieve this objective, a company should oer necessary services such as support options, treating complaints, guarantee or the right to return orders. This phase may also serve to inform the customer of e.g. new products that he could be interested in or special oers.

2.2.3. Best Practices of Online Retailing

Philip Bannister summarizes in his article [Ban02] the ten best practices of online retailing. These best practices have emerged, as online retailing has matured and customers have become comfortable with online shopping. Go to the Buyers Online shops need to reach customers, as do normal stores. While this is achieved mainly by a good location in the case of stores, this objective can be reached for online shops by a good ranking in search engines and e-commerce brokers. In order to optimize a website for search engines, aspects like the keywords, domain name, number of links to a site, the size of a website, its content, title and further tags or the structure have an impact on the ranking (cf. [2] and [Sze04]). Alternatively to the optimization, it is also possible to include ones website in relevant online directories (e.g. online shop directories, cf. [2]) or purchase banner ads (e.g. Google AdWord, cf. [13]) to attract customers to a companys website. Optimize Home Page Design Concerning the appearance of a website, often the rst impression decides if a customer stays on the site. Therefore, the design of the homepage needs to be attractive and the navigation should help orient visitors (usability) and allow them to nd the searched information quickly. Moreover, the design should be consistent with an enterprises corporate identity. As a consequence, often the same advertising agency designs all of a companys logos and layouts in order to create a unique corporate design. Content Partnerships By building synergies with similar companies or websites, the customer base and user trust can be increased. As an example, online travel sites can form content partnerships with travel guides. This encourages new customers to visit ones website.

2.2. E-Business

12

Persistent Shopping Cart Concerning online shopping, customers tend to place items in their shopping cart and return later to complete the sale. To avoid loosing returning clients, it is necessary to store items in this basket persistent for a certain amount of time. Additionally, these returning visitors should receive indicators that they are recognized and have items in their basket. As a further benet, the products placed in the shopping carts can also serve as useful information to analyse selling trends. Strong Supporting Images and Content As customers can not inspect products directly as in normal stores, it is important to close this gap with a good product description, images and sales information. This improves user experience and the ability to complete sales as well as it has an impact on a companys brand. Promote Online and Oine Synergies Bannister points out the value of tightly integrating bricks and clicks and providing seamless cross-channel customer experience [Ban02]. This can promote trust, purchasing comfort, good will and customer experience, as the customer himself can decide which channel he prefers to use. Excellent Store Locator Often, customers inform themselves on the internet and buy products afterwards in a store. As a consequence, a customer must be able to locate physical stores simple and quick. Locator tools or contact information, maps, directions and local dealer links help to reach this goal. Excellent Search Engine Capabilities Many online customers use the search engine capabilities of a website. Therefore a website should support multiple search options, so that users can quickly nd the desired items and information. Clear Customer Support Options As each customer has a dierent preference for interacting with retailers, he should be oered as many online and oine support options as possible. Common options here include FAQs, email phone or fax. Oering such options creates user comfort and may reinforce a buying decision. Strong and Relevant Cross Selling Concerning product recommendation based on already purchased items, it is important, that these sale suggestions are relevant and in stock. This way of cross-selling, as it is for example used by Amazon, provides a simple way to increase revenue and prots. To support this cross selling, a number of recommender systems are available (e.g. Web Trends [49], Epiphany [43] or NetPerceptions [33]).

2.2.4. Exemplary Internet Shops

According to a study by Giga-Group in the year of 1999, only about 5% of all online companies were protable (cf. [Mer02, p. 54]). By 2000, a majority of these web shops, like boo or ToySmart, closed down. Since this crash, e-commerce steadily stabilized and has now reached a normal level with a fewer number of active participants. By now, also de facto standards for internet shops have emerged. Table 2.3 lists some exemplary

2.3. Online Shop

13

online shops, whose structure, layout and functionalities can be considered as the current standard for B2C e-commerce. Company Amazon EBay Dell Walmart IKEA Buch.ch Le Shop Fleurop URL http://www.amazon.com http://www.ebay.com http://www.dell.com http://www.walmart.com http://www.ikea.com http://www.buch.ch http://www.le-shop.ch http://www.fleurop.ch Table 2.3.: Exemplary Online Shops

2.3. Online Shop

An online shop, internet shop, webshop or online store is an electronic commerce application used for B2B or B2C [Wik05b], which serves to sell products or services over the internet. Online shopping has become an important part of the internet usage (cf. [Mer02, p. 49]), mainly due to its speed and ease of use. The main advantage for customers is the possibility to compare prices and conditions of dierent retailers online. This subsection rst presents a possible system architecture for webshops. Afterwards, the basic functionalities and processes of online shops are outlined, followed by a schema for a generic product catalog and a listing of existing online shop software.

2.3.1. Architecture
Merz proposes a general model for online shops (cf. [Mer02, p. 407-413]) based on a multi-tier-architecture, as seen in Figure 2.4. Here, a customer uses a browser (1) to access the web server (2) of an online shop. Such a request is then treated by the application server (3), which accesses the database (4) to either store or retrieve the necessary data contained in the database. The result is nally returned via the webserver to the customers browser. Additionally, an external payment gateway can be integrated to allow for example payment by credit-card. Such multi-tier architectures divide application logic according to their function into several distributed components. The objectives are to reduce development time and therefore costs. This goal is achieved due to the clear division between these components, which improves reusability, speed, security, and reliability. In general, they are separated into three dierent parts: a presentation, business and backend layer. The presentation layer resides on the client machine. The function of this layer is to oer an interface to the user and is therefore mainly concerned with the layout of the application. Here, the application client is a simple browser, but it also could be a socalled rich client like a Java application.

2.3. Online Shop

14

Figure 2.4.: Multi-Tier Shop Architecture [Mer02, p. 411]

The function of the business layer is to implement the business logic needed for the application. The web- and application server residing on this layer provide middleware services for communication, security, transaction, data access, persistence and administration. As a consequence, a programmer only needs to develop the actual business logic, like e.g. order processing, without beeing concerned about these low-level functionalities. Finally, the backend is responsible for storing the application data. In the case of an online shop, the database contains the necessary information of the products, customers, administration or further shop related data.

2.3.2. Basic Functionalities

The basic functionalities of an online shop according to [FMSW04, p. 2-5] and [Mer02, p. 397-407] can be separated into the storefront and storeback services, as illustrated in Figure 2.5. A customer has only access to the storefront, where he can obtain information about the oered products and eect orders. Access to the storeback is only granted to the shop owner, as it includes functionalities for the administration of the online shop. In order to access the storefront, most often a web browser is used, while for accessing the storeback, also rich clients are possible. The core component of such an online shop is the product catalog. On the one hand, this database reects the structure of the oered product range according to e.g. product line, product group and product category. On the other hand, also the detailed information for each product is stored. This includes for example the product id, name, price, description and images or also comments and recommendations entered by other users. Section 3.3.1 outlines a generic product catalog scheme in more details. After the shop owner has entered the corresponding data on the storeback using the catalog and product management functionalities, a customer then can browse the product catalog and obtain detailled information about these goods. If a client is interested in buying a certain prod-

2.3. Online Shop

15

Figure 2.5.: Basic Shop Functionalities

uct, he can add it to his shopping cart. Such a shopping basket needs to have a persistent state in order to allow customers to add items and return to it at a later time. Usually this is done by assigning the customer a session id, which is either stored in a cookie or in the Uniform Resource Locator (URL). To eect an order, the customer then needs to enter his user prole or login if he already is a registered client. User proles can contain contact information (e.g. name, adress, email, telephone), demographic data (e.g. gender, date of birth) and payment or delivery preferences (e.g. credit card, paypal). Care needs to be taken concerning data security and privacy. No data should be accessible by unauthorized persons nor should it be used without the explicit approval of a customer. Therefore only the shop owner has access to this user proles using the user management functionalities, and all communication and storage involving user data needs to be encrypted. To complete the ordering process, the customer further can specify options like the preferred payment and delivery. Concerning the payment options, this can either be a simple invoice, credit-card or e-cash systems like PayPal (cf. [35]). For such payments, often an encrypted communication channel to an external payment gateway is used. If the ordering process is successfully completed, the order information is stored in a database and the customer receives a conrmation. By using the order management functionalities, the shop owner then can process this order. After the actual sale, further tasks like order tracking and tracing can be implemented. This allows the customer to check the status of his current order and delivery. For the shop owner, reporting or statistic tasks might be useful, as these tools oer information

2.3. Online Shop

16

Figure 2.6.: Basic Storefront Process (cf. [Mer02, p. 410])

about the online shops performance. Further functionalities for an online shop could be search engines, a direct integration into the Enterprise Resource Planning (ERP) system, online Customer Relationship Management (CRM) tools or the integration into a content management system.

2.3.3. Processes
The processes involved in an online shop can again be separated into the storefront and storeback procedures. The basic storefront process consists of the necessary steps involved for a customer to order a product, while the storeback process treats the tasks for handling an order by the store owner. In the storefront process (cf. Figure 2.6), a customer rst browses the product catalog, consults the detailled product information and adds items he is interested in to his shoping basket. Afterwards, he can continue to browse the catalog or start the ordering process. New clients of an online shop then need to register their data for the user prole, existing customers login to the system. The order process then usually involves checking the current user prole (e.g. correct adress), selecting payment and delivery options and nally controlling the whole order information before submitting it. At this point, the customer receives a conrmation indicating the successful order. Afterwards he can continue to browse the product catalog. Before his order is ready, he receives a delivery notication and then obtains the product. If needed, he can afterwards request support. Further, he can check the status of his order or change his user prole anytime he logs in to the online shop system. For the storeback processes, the rst step is always a login to the system in order to identify the store owner. Afterwards, he can choose between all oered administration functionalities of the online shop. He can for example manage the product catalog, the products or the user proles. As it is recommended to integrate an e-shop in the common

2.3. Online Shop

17

Figure 2.7.: Generic Product Catalog [Mer02, p. 415]

business processes of a company, tasks like order or delivery management of the online shop need to be adjusted accordingly. The order management allows to process an order, which usually involves checking the customers data, his creditworthiness and the order itself. This check is important, as, depending on the business sector, the rate of junkorders (e.g. with fake adresses like Donald Duck) can be up to 30% (cf. [Mer02, p. 437]). The delivery management can be built up by a notication, followed by the actual delivery. Further administrative functionalities of such an online shop can include for example tools for reports and statistics.

2.3.4. Product Catalog

The product catalog is the core component of an online shop, which reects the structure of the oered product range and contains all product related information. Merz distinguishes between two general kind of catalogs (cf. [Mer02, p. 414-420]), depending on the nature of the oered products. The rst one is suited for heterogeneous products, which all have dierent properties. These articles can be grouped into categories, which allows for a hierarchical navigation as well as for queries based on their attribute values. The second kind of products all have rather similar characteristics. Here, a parametric query can be used to step by step dene the desired attribute values, which eventually leads to a selection of some products. The following paragraph discusses a generic product catalog (cf. [Mer02, p. 414-420]), as it could be used for heterogeneous products. In this metamodel (cf. Figure 2.7), a product is composed of attributes and further information like images, text or the price. Each product belongs to a category, which can themselve extend other categories. This allows to dene a general hierarchic structure of

2.3. Online Shop

18

the product catalog according to the oered product categories. A product can further be of zero or more product types. Each product type denes some common characteristics as well as common attributes for all these products. Moreover, products can also contain any number of only product specic attributes. Like the products, the attributes can as well be of zero or more attribute types. These attribute types dene common characteristics and attribute values. Attributes can further have only a default value, but also zero or more attribute values. This allows to dene for example custom options.

2.3.5. Existing Online Shop Software

Table 2.4 lists a selection of available open-source and proprietary online shop software and their technology. All open-source products are published under a GNU General Public Licence (cf. [GNU05b]), and their technology is mostly based on PHP (cf. [36]). Apart from the commercial Intershop Ennity, none of these online shops uses Suns EJB technology. Name osCommerce phpShop PhPepperShop OSIS Online Shop eSarine Lic. GPL GPL GPL GPL GPL Techn. PHP PHP PHP PHP J2EE URL http://www.oscommerce.com http://phpshop.org http://www.phpeppershop.com http://www.oos-shop.de http://diuf.unifr.ch/ is/research/esarine/ introduction.php http://www.intershop.com http://www.sap.com/ solutions/smb/businessone/ index.epx

Intershop Ennity Business One eShop

Prop. Prop.

J2EE SAP

Table 2.4.: Online Shop Software

3
Specication
3.1. Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.1. ShopCong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2. CatalogMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.3. ProductMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.4. BrowseProductCatalog . . . . . . . . . . . . . . . . . . . . . . . 3.1.5. ProductInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.6. ShoppingBasket . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.7. CompanyMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.8. CompanyInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.9. NewsMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.10. News . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.11. Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.12. SupportMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.13. Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.14. Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.15. AccountMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.16. Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.17. OrderMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.18. Consulting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.19. ConsultingMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.20. ValidateInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 22 22 22 23 23 24 24 24 25 25 25 26 26 27 28 29 29 30 31

3.2. State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3. Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.3.1. Product Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2. Order and Consulting Items . . . . . . . . . . . . . . . . . . . . 3.3.3. Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4. Company and Employees . . . . . . . . . . . . . . . . . . . . . 35 35 36 36

19

3.1. Use-Cases 3.3.5. News . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.6. Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.7. Shop Cong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 36 37

20

3.4. Development Methodology . . . . . . . . . . . . . . . . . . . . . 37

This chapter contains the specication of the online shop. A specication is an abstract and formal description of an applications requirements and functionalities, which is independent of the actual software or hardware used. In object-oriented software development, often the UML is used for these analysis and design tasks. UML is a non-proprietary standard of the Object Management Group (OMG), which serves to specify, visualize, construct and document software development. The Reseda e-shop project uses the UML use-case, state and class diagrams for the specication. First, the use-case diagram gives an overview over the applications functionalities. The state diagram outlines the involved processes and the class diagram captures the underlaying object model. An outline of the adopted development methodology nally concludes this chapter.

3.1. Use-Cases
Use-cases (cf. [Fow02, p. 39-47]) are the result of the discussion with the client and describe the typical interactions of a user with the system. The UML use-case diagram captures all possible interactions and hence the main functionalities, which are covered by the application. The diagram itself is only intended to give an overview, but it does not contain any details. The graphical use-cases themselves are afterwards described in a structured textual (more verbose) format. A use-case diagram consists of the involved actors, the use-cases and the relationships. An actor is a role, which a user plays with respect to the system. The use-case is a specic interaction of the user with the system with a common goal. Which actor is given what permissions is indicated with the relations. The UML standard further species generalization to extend an existing use-case and inclusion to capture behaviour that is similar accross several use-cases. Figure 3.1 shows the use-case diagram of the online shop. There are three main actors involved: the customer, who visits the web store, the administrator, responsible for the setup and conguration of the online shop, and the manager, concerned with the daily business. The use-cases are then structured by the storefront and storeback area, and the lines indicate the relationships between the actors and the use-cases. Basically, the storefront use-cases cover the customers interaction with the online shop, and the shop owner is given the necessary administrative tools for all the corresponding cases in the storeback. While UML species use-case diagrams, there does not exists a standardized format for the description of the individual use-cases. But a commonly used format is given in [Fow02, p. 40]. In this format, a use case is considered as a set of scenarios, tied together by a common user goal. Such a scenario is a sequence of steps describing the successful interaction of the user with the system. Extensions cover the variations on this sequence. A use-case is then formalized by indicating the main actor, outlining

3.1. Use-Cases

21

Figure 3.1.: Online Shop Use-Case Diagram

the success scenarios as a sequence of numbered steps, followed by the extensions. The following paragraphs specify the individual use cases of the online shop by means of the above format. Additionally, a short description as well as comments for each use-case are given.

3.1.1. ShopCong
Description: Congure the editable properties of the online store. Main Actor: Admin Scenario: 1. System shows an overview of the editable properties. 2. User can congure these properties.

3.1. Use-Cases

22

3. System validates (use-case 3.1.20) and stores the properties.

3.1.2. CatalogMgmt
Description: Allows to set up the structure of the product catalog. Main Actor: Admin Scenario: 1. System shows an overview of the existing categories, product types and attributes. 2. User can add new ones, edit or delete existing ones. 3. System validates (use-case 3.1.20) and stores input.

3.1.3. ProductMgmt
Description: Manage the oered products. Main Actor: Admin Scenario: 1. System shows an overview of the existing products. 2. User can add new ones, edit or delete existing ones. 3. System validates (use-case 3.1.20) and stores input.

3.1.4. BrowseProductCatalog
Description: Browse the product categories and obtain an overview of matching products. Main Actor: Customer

3.1. Use-Cases

23

Scenario: 1. System shows an overview of the product catalog. 2. User selects a category of the product catalog. 3. System returns an overview of matching products. 4. User either continues BrowseProductCatalog (3.1.4) or selects a product to view the ProductInfo (3.1.5). Extensions: 3a. Category contains sub categories. 1. System shows sub categories. 2. User selects a sub category.

3.1.5. ProductInfo
Description: Show detailed product information and custom options and allow the customer to either add the item to the shopping basket, to print or to download a pdf le of the product information. Main Actor: Customer Scenario: 1. System shows detailled product information and options. 2. User selects custom options. 3. System shows adapted product information. 4. User either continues BrowseProductCatalog (3.1.4), adds the item to the ShoppingBasket (3.1.6), or downloads a pdf le of the product information.

3.1.6. ShoppingBasket
Description: Persistently collect items a customer is interested in, show information (e.g. article name, id, price) and the total of the purchase. Allows to modify or supress items, to buy the selected products, download a pdf le with the information of all items or request consulting service for the selected products. Main Actor: Customer

3.1. Use-Cases

24

Scenario: 1. System shows the shopping basket and its current items. 2. User can modify the content of the basket. 3. User can continue BrowseProductCatalog (3.1.4), Order (3.1.16) the selected products, download a pdf le with their information or request Consulting (3.1.18).

3.1.7. CompanyMgmt
Description: Manage the company and employee information (e.g. address, contact, map). Main Actor: Admin Scenario: 1. System shows the existing companies and employees. 2. User can edit the information of existing ones or add or delete a company or employee. 3. System validates (use-case 3.1.20) and stores input.

3.1.8. CompanyInfo
Description: Show all information (e.g. address, image, contact, map) of a selected company, which can afterwards be either printed or downloaded as a pdf le. Main Actor: Customer Scenario: 1. User selects one of the companies. 2. System shows the store and the corresponding information. 3. User can print the information or download it as a pdf le.

3.1.9. NewsMgmt
Description: Manage the news entries.

3.1. Use-Cases

25

Main Actor: Admin Scenario: 1. System shows the existing news entries. 2. User can edit, add or delete entries. 3. System validates (use-case 3.1.20) and stores input.

3.1.10. News
Description: Allow a customer to get the news in his desired format (e.g. online, newsletter, rss feed). Main Actor: Customer Scenario: 1. User selects one of the oered news formats. 2. System shows the corresponding news. 3. System validates (use-case 3.1.20) and stores email address for a newsletter subscription.

3.1.11. Contact
Description: Allow a customer to contact a company. Main Actor: Customer Scenario: 1. User selects a mail or address contact form. 2. System shows the corresponding form which the user lls out. 3. System validates (use-case 3.1.20) and sends the data to the company per email.

3.1.12. SupportMgmt
Description: Manage the support options (e.g. FAQ, Help, General Terms).

3.1. Use-Cases

26

Main Actor: Admin Scenario: 1. System shows the existing support options. 2. User can edit, add or delete support options. 3. System validates (use-case 3.1.20) and stores input.

3.1.13. Support
Description: Allow a customer to obtain the desired support (e.g. Help, FAQ). Main Actor: Customer Scenario: 1. User selects one of the support options. 2. System shows the corresponding support option details.

3.1.14. Account
Description: Allow to register, login, logout or update a customers account and its information (e.g. address, contact). Main Actor: Customer Scenario 1: Register 1. User enters prole data (e.g. name, address), user name and password. 2. System validates input (use-case 3.1.20). 3. System stores data and creates an account. Scenario 2: Login 1. User enters username and password 2. System checks username and password. 3. System logs user in.

3.1. Use-Cases

27

Extensions: 2a. Username does not exist or wrong password. 1. System shows error message. 2. User reenters username and password or requests to send him the lost password. Scenario 3: Update 1. User logs in. 2. User can modify prole data and password. 3. System validates (use-case 3.1.20) and stores modied data. Scenario 4: Logout 1. User chooses logout. 2. System logs the user out. Comments: 1. Sensitive data needs to be transmitted over secure channels. 2. Sensitive data must be encrypted. 3. Only registered users can login. 4. Correct login is required for accessing the account.

3.1.15. AccountMgmt
Description: Allow to manage the account information of existing customers (e.g. address, telephone number, orders). Main Actor: Manager, Administrator Scenario 1: Create Account 1. System shows the customer data form. 2. User lls in the form. 3. System validates (use-case 3.1.20) and stores input.

3.1. Use-Cases

28

Scenario 2: Manage Account 1. System shows the customers data. 2. User can modify the data. 3. System validates (use-case 3.1.20) and stores input. Scenario 3: Delete Account 1. System shows the customer accounts. 2. Administrator can select accounts to delete.

3.1.16. Order
Description: Order selected products. Allows to check the user prole, choose payment and delivery options and check the order once again. Afterwards, a conrmation mail is sent to the customer. Main Actor: Customer Scenario: 1. User registers or logs into his Account (3.1.14). 2. User checks his current prole. 3. User selects a store. 4. User selects a payment option. 5. User selects the delivery options. 6. User checks his order. 7. User accepts the terms and conditions, submits order. 8. User receives a conrmation email. 9. System stores order and informs store manager. Extensions: 2a. Outdated account information. 1. User updates Account (3.1.14). 2. System validates (use-case 3.1.20) and stores input.

3.1. Use-Cases

29

Comments: 1. Correct registration or login is required. 2. Communication channel needs to be secured for sensitive data. 3. Sensitive data needs to be encrypted.

3.1.17. OrderMgmt
Description: Manage online orders. Main Actor: Manager Scenario 1: Manage Orders 1. System shows an overview of open online orders. 2. User can select orders and process them. Scenario 2: Create Orders 1. User can create an order for a customer. 2. System validates (use-case 3.1.20) and stores input. Comments: 1. Correct login is required. 2. A manager can only view and process orders of his shop. 3. Communication channel needs to be secured for sensitive data. 4. Sensitive data needs to be encrypted. Comments:

3.1.18. Consulting
Description: Allow a customer to arrange a meeting for a consulting without obligation. Main Actor: Customer

3.1. Use-Cases

30

Scenario: 1. User registers or logs into his Account (3.1.14). 2. User checks his prole (e.g. telephone number). 3. User selects a store. 4. User selects a consulting option and date if required. 5. User checks his consulting request. 6. User accepts the terms and conditions, submits consulting. 7. User receives a conrmation email. 8. System stores consulting and informs store manager. Comments: 1. Correct registration or login is required. 2. Communication channel needs to be secured for sensitive data. 3. Sensitive data needs to be encrypted.

3.1.19. ConsultingMgmt
Description: Manage consulting requests. Main Actor: Manager Scenario 1: Manage Consultings 1. System shows an overview of open consulting requests. 2. User can select requests and process them. Scenario 2: Send Consulting Email 1. User enters the required data. 2. System sends the product information to the customer per email. Scenario 3: Create Consulting 1. User can create a consulting for a customer. 2. System validates (use-case 3.1.20) and stores input.

3.2. State Diagram

31

Comments: 1. Correct login is required. 2. A manager can only view and process consulting requests of his shop. 3. Communication channel needs to be secured for sensitive data. 4. Sensitive data needs to be encrypted.

3.1.20. ValidateInput
Description: Validates a users input. Main Actor: Admin, Manager, Customer Scenario: 1. System validates the input (format, constraints, etc.). Extensions: 1a. Invalid input. 1. System shows error message. 2. User corrects input.

3.2. State Diagram

Other UML models are state diagrams, which are intended to describe a systems behaviour. Their purpose is to describe all of the possible states that a particular object can get into and how the objects state changes as a result of events that reach the object [Fow02, p. 119]. The diagram basically consists of labelled state boxes and transitions between them. A transition arrow indicates, that a state change is possible under certain circumstances. Often labels are used to describe the event which leads to this change. Further, states can be superstates if they contain states inside them and concurrent state diagrams can be used to visualize objects with a set of independent behaviours. Figure 3.2 and Figure 3.3 show the storefront and storeback state diagrams of the online shop. These diagram are not intended to cover all details of the applications behaviour, but to give an overview over the fundamental interactions a user with the system.

3.2. State Diagram

32

Figure 3.2.: Online Shop Storefront State Diagram

3.3. Object Model

33

Figure 3.3.: Online Shop Storeback State Diagram

3.3. Object Model

An object model describes an applications business objects and how they are related. In order to describe the types of objects and the relationship among them, UML class diagrams can be used (cf. [Fow02, p. 49-65]). In this type of diagram, the systems business objects are modelled as classes and the relationship between them is either expressed as an association, aggregation, composition or generalization. A class is visualized by a box and specied with a name, attributes and operations. Attributes describe the content and operations processes that a class knows to carry out. An association represents a general kind of relationship between objects. Each association end has a multiplicity, which indicates the number of participating objects. The type of relation can be specied by a label and the navigability described by arrows, hence uni- or bidirectinal relations can be expressed. Aggregation and composition are similar to associations, but express a stronger relationship between the involved objects. An aggregation represents a is-part-of relation, which means that the object belongs to the other. The composition is even stronger, indicating that the object ceases to exists if the other does not exist anymore. Generalization then covers similarities between several objects. A superclass contains common attribute and methods, which are available to all their subclasses. The relation between a subclass and its parent is a so called is-a relation, which means that the sub class is considered as the same type as its parent.

3.3. Object Model

34

Figure 3.4.: Online Shop Object Model

3.3. Object Model

35

The object model of the online shop is given in Figure 3.4. The fundamental parts of this model are the product catalog, consulting and order items, account, company and employee, news, support and shop conguration objects, as described in the following paragraphs. All business objects support internationalization (i18n), the corresponding objects hold a reference1 to the global I18N object, which contains the actual translations.

3.3.1. Product Catalog

The product catalog represents the companys oered product range. The product catalog consists of the following business objects: Category, ProductType, ProductFieldType, ProductFieldValueStandard, Product, ProductField, ProductFieldValue, PriceMatrix, PriceMatrixCell, Image, ResourceHtml and Relation. The Category object is intended to create the hierarchical structure of the product catalog. The bidirectional association to itself allows to dene either parent or sub categories. For each category, at least one Image object and an unlimited number of HtmlResource objects, which link to further information, is associated. A product then belongs to one or more categories (e.g. a table belongs to a category Table and a residential environment Living Room). The ProductType serves as a generic denition for a concrete product. Such a product type consists of assigned ProductFieldType objects (e.g. tablewidth, tablelength) with their default values in the ProductFieldValueStandard objects. Each concrete Product then is initialized with the values dened in the type objects. Hence a product has its own ProductField and ProductFieldValue objects, which are independent from the type and the other products. Basically, the types only avoid entering input common for some kind of product (e.g. available lenghts for the tables). As a consequence, the product elds and their values can be edited, added or deleted for each product individually. One then can distinguish between customizable and non-customizable products. For a customizable product, the ProductField objects have more than one value, which allows the customer to choose from these proposed values. The corresponding prices are calculated as a function of the selected value of the product elds. This information is stored in the ProductPriceMatrix and the ProductPriceMatrixCell objects. A customizable as well as a non-customizable product is further specied by images, html resources and relations. A Image represents an image of the product and a HtmlResource object a link to further information sources (e.g. woodtype description). The Relation object is used for including products, which are related to the specied Product (e.g. matching chairs for a certain table).

3.3.2. Order and Consulting Items

The order and consulting items contain a customers order or consulting data. The involved business objects are the OrderItem, ConsultingItem, ProductItem and ProductItemOption. The order or consulting items hold the basic information, like the chosen payment, delivery or consulting option. An unlimited number of ProductItem objects are associated to such a ConsultingItem or OrderItem. This ProductItem object contains the required data of
1

Denoted as i18nSomeName: Collection

3.3. Object Model

36

an actual product, like the product id, name or price. The product elds and their selected values are represented in a ProductItemOption object, which contains the information concerning the chosen option. Each order or consulting is then associated to exactly one customer and one company, which processes the request. Wether the consulting nor the order objects have references to the actual products, which allows to modify the products without any consequences for the already ordered items.

3.3.3. Account
The Account models a users system account. It basically serves as a container for the references to the Login, Prole, Preferences, OrderItem and ConsultingItem objects. Further involved business objects are the Role, Email, Address and Phone objects. Each Account has exactly one Login object associated, used to access this account. The granted permissions are managed by assigning the required Role objects to the Login. The 1:1 bidirectional aggregation to the Prole represents the fact, that each account belongs to one user. This prole contains a users personal data and has further aggregations to Email, Address and Phone objects. As a user can make none or several orders and consultings, there is a 1:many bidirectional aggregation from the Account to the corresponding OrderItem and ConsultingItem objects.

3.3.4. Company and Employees

The Company and Employee objects model the physical stores and their employees. The contained data includes for example the company name, description, business hours or directions. Further information is stored by the aggregations to the corresponding Email, Address and Image objects. For each Company, an unlimited number of Employee objects can be assigned, which hold information concerning an individual employee as well as his Image.

3.3.5. News
The NewsEntry and NewsletterSubscription objects serve to communicate a companys information to their customers. These entries are either published online, as rss feed or sent in a newsletter. For this newsletter, the NewsletterSubscription allows a customer to subscribe or unsubscribe from this emailing list.

3.3.6. Support
To provide the customers with additional information like the general terms, legal notice, faq or links, the InfoTopic and InfoItem objects are used. The InfoTopic contains an unlimited number of InfoItem objects, which allows to for example dene the individual terms in the general terms.

3.4. Development Methodology

37

Figure 3.5.: Development Process [Fow02, p. 14]

3.3.7. Shop Cong

Finally, the shop cong consists of all objects relevant for the conguration of the online shop. The ShopProperty holds any kind of property used to congure the basic functionalities (e.g. mailserver to use). The emails sent by the application are stored in the ShopEmail objects, while the Slideshow contains the information for the websites slideshows. The LocaleLanguage and LocaleCountry hold all language and country codes, while the ShopLocaleLanguage, ShopLocaleCountry and ShopLocaleCurrency contain the locales currently supported by the online shop. Likewise, the PaymentOption, DeliveryOption and ConsultingOption list all possible options, and the corresponding ShopPaymentOption, ShopDeliveryOption and ShopConsultingOption the ones supported by the e-shop. Finally, the WebResource object holds arbitrary les (e.g. images, pdfs), which can afterwards be embedded in the websites using standard html tags.

3.4. Development Methodology

Current software development methodologies (cf. [Des04]) can be classied into two main categories: traditional waterfall models and iterative processes. They dier in how a projects tasks and activities are structured. In the waterfall model, a project is analysed, specied and designed once in the beginning and afterwards programmed, tested and nally delivered as a whole to the client. The drawback of this approach is, that an application often does not satisfy the needs of the client anymore in the end. This is mainly due to the fact, that a client does often not know the exact requirements for an application in the beginning. Iterative development models try to avoid this pitfall by constantly analysing, specifying, designing, implementing and testing selected use cases. The client actively participates in this development, as he tries out the individual parts of the software. This allows to include his needs and requests for changes throughout the whole lifecycle of the project. Popular iterative methodologies are for example the Rational Unied Process (RUP) (cf. [Kru04]) or agile processes (cf. [Coc01]) like Extreme Programming (XP) (cf. [Bec99]). RUP (cf. [Fow02, p. 13-37]) is structured into four main phases, as seen in Figure 3.5: inception, elaboration, construction and transition phase. In the inception phase, the scope of the project and its business cases are dened. Afterwards, these abstract specications are converted to the architectural foundations and the design of the application in the elaboration phase. This phase also deals with the various risks (requirement, technological, skills and political) of a project. The application is then implemented, tested and re-dened in the construction phase using an incremental approach. Each iteration analysis, designs, codes, tests and integrates a subset of the use-cases. In the nal transition phase, the completed application is delivered to the client.

3.4. Development Methodology

38

The Reseda e-shop project is based on the rational unied process, but does not implement all its development processes completely. Although the specication denes the main use-cases already in the beginning, their exact functionalities will be adapted throughout the development. During the construction phase, a subset of the use-cases is analysed, designed, implemented and tested in each iteration. This requires an adaptive or agile development process supported by e.g. automatic build tools and unit tests.

4
Technology
4.1. Multi-Tier-Architecture . . . . . . . . . . . . . . . . . . . . . . . 40 4.1.1. Three-Tier Model . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2. Five-Tier Model . . . . . . . . . . . . . . . . . . . . . . . . . . 40 41 4.2. J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.2.1. Component Model . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2. Enterprise JavaBeans (EJB) . . . . . . . . . . . . . . . . . . . . 4.2.3. Servlets and Java Server Pages (JSP) . . . . . . . . . . . . . . . 42 43 45

4.3. Software Products . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.3.1. J2EE Application Server . . . . . . . . . . . . . . . . . . . . . . 4.3.2. Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3. Integrated Development Environment (IDE) . . . . . . . . . . . 4.3.4. Development Tools . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.5. Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 47 48 48 49

4.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

This chapter gives an overview of the technology involved for the online shop application. Current e-business applications are essentially web applications based on a multi-tier architecture. In principle, a multitiered architecture separates an application into several independent components. The objective is to improve reusability and therefore reduce development time and costs. An open standard used for the development of such multitiered applications is J2EE. Frameworks then provide developers with a reusable common structure, as often required by applications. Such a framework is a semi-complete application that can be specialized to produce custom applications [Hus03, p. 5]. This section includes an introduction to multi-tier architectures and J2EE as well as the corresponding available software and frameworks. All information in the following paragraphs is based on [MH04], [FCF02], [Sun05d] and [AT02]. Refer to this literature or to Dominic Brggers master thesis [Bru05] for a more more detailed discussion of these topics.

39

4.1. Multi-Tier-Architecture

40

Figure 4.1.: Three-Tier Architecture [Wik05c]

4.1. Multi-Tier-Architecture
A multi-tier architecture (also referred to as n-tier architecture) divides application logic according to their function into several distributed components, which can reside on dierent computers connected by a network. Oellermann states, that this architecture has proven to be very robust. It has managed to grow with the evolving technology because it is a logical architecture [Oel01, p. 45]. Due to the clear separation, these components can be developed and maintained individually, which improves reusability, speed, security, and reliability. In general, such multi-tier applications are separated into three or ve dierent layers.

4.1.1. Three-Tier Model

Figure 4.1 shows a three-tier architecture, consisting of the presentation, logic and data tier. The presentation layer presents an interface to the user. Its main function is to translate tasks and results to something the user can understand. The actual business logic is implemented in the logic tier, which processes these tasks and delivers the results. This layer further moves and translates data between the two surrounding layers. The data tier then is responsible for storing and retrieving the required data. As a simple example, suppose a user wants to get a sales total in an online shop. He can enter his request in the oered interface (e.g. a web form) of the presentation layer.

4.1. Multi-Tier-Architecture

41

Figure 4.2.: Five-Tier Architecture [ACM03, p. 120]

The request is then propagated and processed by the logic tier. This tier is responsible for accessing the data stored in the data tier, calculating the result and sending back the response. The result is then displayed in the users web browser.

4.1.2. Five-Tier Model

The ve-tier model (cf. Figure 4.2) then is an extension to the above three-tier architecture, where the layers are further rened. According to [ACM03, p. 120-121], the layers in this model consist of the client, presentation, business, integration and resource tier. The client tier represents all devices and system clients accessing the application. Often, this is a so called thin client like a web browser, but it can be any other kind of application (e.g. Java applet) or device (e.g. WAP phone). The required presentation logic to serve these clients is encapsulated in the presentation tier. This tier basically intercepts the client requests, provides single sign-on, conducts session management, controls access to business services, and delivers the responses to the client [ACM03, p. 121]. Like in the 3-tier-model, the required business services are implemented in the business tier. The data layer is then split into the integration and resource tier. Due to this renement, the communication with external resources and systems (e.g. data stores, legacy appplications) is encapsulated in the integration tier. The business layer is coupled with this layer, whenever a business object requires data or services of the resource tier. Finally, the resource tier contains all business data and external resources (e.g. mainframe, legacy system, credit card authorization service).

4.2. J2EE

42

4.2. J2EE
An open standard often used for the development of multi-tier applications is J2EE (cf. [16]). Another popular technology for such applications is Microsofts .NET framework (cf. [29]). J2EE and .NET oer similar functionalities, but .NET is a proprietary standard and requires corresponding licence fees. As the Reseda online shop project is based entirely on open standards and open source software, the Microsoft .NET technology is not considered nor treated in this paper. The J2EE specication oers a range of Application Programming Interfaces (APIs) used for enterprise computing, a term which is simply a synonym for distributed computing: computation done by groups of programs interacting over a network [FCF02, p. 3]. Table 4.1 lists an overview over the more common Java Enterprise APIs (cf. [FCF02]). API JDBC RMI JAXP JNDI JMS JavaMail EJB Servlet JSP Description Java Database Connectivity Used for working with relational database systems. Remote Method Invocation Allows distributed client-server programming. XML Parsing and Messaging API required for processing xml les. Java Naming and Directory Interface Provides networked naming and directory services. Java Message Service API for working with networked messaging services. Java Mail API oering support for email protocols. Enterprise JavaBeans Used for distributed server side components. Servlet Server side applet to generate dynamic HTML content. Java Server Pages Alternative approach for servlets. Table 4.1.: Java Enterprise APIs The APIs central for this project are the EJB, Servlets and the Java Server Pages (JSP). They are hosted in the Web and EJB container of a J2EE application server, as seen in Figure 4.3. The following paragraphs introduce the underlaying component model as well as the EJB, Servlet and JSP APIs.

4.2.1. Component Model

A component model denes a set of contracts between the component developer and the system that hosts the component [MH04, p. 8]. This model species the services that the corresponding component container oers as well as how a component should be developed and packaged in order to be deployed in the container. As a consequence of this approach, a component becomes an independent piece of software, which is not developed for a specic application but for a specic purpose. This allows to reuse the

4.2. J2EE

43

Figure 4.3.: J2EE Server and Containers [Sun05d, p. 10]

once developed components for several dierent applications by simply assembling the required components. The J2EE specication denes a component model for the Enterprise JavaBeans as well as for Servlets. These components are then hosted respectively in the Web and EJB container of a J2EE compliant application server (cf. Figure 4.3). A J2EE application server implements the specication for the EJB and Servlet component model (for a list of J2EE compliant application servers, see section 4.3.1). Such an application server further provides middleware services for communication, security, transaction, data access, persistence and administration. Hence the developer can benet from these services, as he is not required to implement these low-level functionalities or cross-cutting aspects, but can instead concentrate on the actual business logic. In the context of a ve-tier architecture (cf. Figure 4.2), the users browser on the client machine represents the client layer. The Web container of the application server hosting the Servlets and JSP pages covers the presentation tier, while the Enterprise JavaBeans in the EJB container form the business layer. The EJB container then implements the integration tier, as it provides the required services for accessing the data of the database server in the resource tier. As a consequence, a developer only needs to implement the presentation and business tier parts of an application by providing the corresponding EJB, Servlet and JSP components. Further, these components can be deployed on any J2EE compliant application server and assembled and reused for dierent applications.

4.2.2. Enterprise JavaBeans (EJB)

Sun Microsystems denes the Enterprise JavaBeans architecture as a component architecture for the development and deployment of component-based distributed business applications [which are] scalable, transactional and multi-user secure [and can be] deployed on any server platform that supports the Enterprise JavaBeans specication [MH04, p. 5]. These server-side components include both business objects and business processes and hence cover the business tier of a ve-tier application.

4.2. J2EE

44

Figure 4.4.: EJB 2.1 Architecture [MH04, p. 20]

The business objects are implemented in entity beans, while the session beans represent processes. A further rarely used third type are message-driven beans. An entity bean represents data, which is usually stored in a record of a relational database table. This type of bean distinguishes between Bean Managed Persistence (BMP), where the bean developer is responsible for accessing the resource tier, and Container Managed Persistence (CMP), where the application server is concerned with this data access. In the case of session beans, there also exists a distinction: stateful session beans maintain some kind of conversational state, while stateless ones can be used independent of a client. Finally, message-driven beans allow for asynchronous message driven communication, as sometimes required for the integration of external systems. In the EJB 2.1 specication, both entity and session beans require to provide corresponding component interfaces: either a remote interface and remote home interface or a local interface and local home interface or both. The remote or local interfaces dene a beans business methods (e.g. getSalesTotal), while the home interfaces represent its life cycle methods (e.g. create, destroy), called by the application server to manage the beans. The application server then generates an EJB object, EJB object stub, EJB home and EJB home stub objects from the provided bean interfaces and classes. As the application server wraps the actual bean class, a client never directly communicates with it (cf. Figure 4.4). This convention allows to deploy EJB components on any J2EE compliant application server, as the components only provide the actual business logic while the server is concerned with the required concrete implementation of the bean objects. Apart from hosting the components, the application server further is concerned with the oered middleware services. These services for communication, security, transaction, data access, persistence and administration can be used by the Enterprise JavaBean components, but they are not hard coded in the beans. Instead, they are congured in deployment descriptors. This allows for exibility, as the conguration and assembling of the individual components is done descriptive and hence does not require touching or rewriting a beans source code. While the EJB 2.1 specication oers a exible basis for a wide range of enterprise application, its architecture is considered as rather complicated and tedious to program. The subsequent EJB 3.0 release1 tries to overcome this drawback by providing new simplied
1

announced for mid 2006

4.2. J2EE

45

APIs, which are currently available as a public draft (cf. [Sun05a], [Sun05c], [Sun05b]). According to [Sun05a, p. 13], this simplication has several aspects: Simplication of the interface denition requirements for enterprise beans: elimination of requirements for the specication of home and component interfaces in the EJB 3.0 programming model. Simplication of the contractual requirements between the bean provider and the container: elimination of the requirements for the specication of the EnterpriseBean interfaces. Simplication of APIs for access to the beans environment: denition of a dependency injection facility and simpler look-up APIs. Introduction of Java metadata annotations to be used as an alternative to deployment descriptors. Simplication of object persistence by the denition of a light-weight object/relational mapping facility based on the direct use of Java classes rather than persistent components. As an alternative to persist data with EJB, frameworks such as Hibernate (cf. [14]), Java Data Objects (JDO) (cf. [30]) or Spring (cf. [42]) can be used. These frameworks do not require a container, as they provide all services needed for a persistence layer. Hibernate for example uses Plain Old Java Object (POJO) for the object to relational mapping. See section 4.3.5 for further details on such frameworks.

4.2.3. Servlets and Java Server Pages (JSP)

Javas Servlet (server-side applet) specication denes a component model for the dynamic generation of content. This model is based on request-response programming, where a client sends a request to the webserver, which in turn processes this request and renders a response. As such, the Servlet and the Java Server Pages cover the presentation tier of the ve-tier architecture of Figure 4.2. In most cases, the request is a http request, from which a servlet extracts the required parameters. Depending on these parameters, it then renders a html page, which is sent back to the client and displayed in his browser. The drawback of Servlets is, that the rendered html contains static as well as dynamic content, which somehow mixes logic and presentation. Java Server Pages are an extension to Servlets that try to overcome this drawback. A JSP page is a text le, which contains static data as well as the embedded code (scripplet) for the generation of the dynamic content. The webserver then automatically generates a Servlet from the JSP le and stores it in the servlet container. This approach separates logic and presentation more clearly, but the presentation still contains application logic. A further improvement is therefore the use of tag libraries. This library denes tags, which can be used in JSP pages. But the code for these tags is then implemented in plain Java classes, and hence the JSP page itself does not contain any application logic. With this approach, an application developer can provide the necessary tags for the generation of dynamic content. The person responsible for the layout can use these tags afterwards

4.3. Software Products

46

without being concerned about how they are implemented. As a further benet, tag libraries also avoid redundant code, as a tag can be reused in several pages.

4.3. Software Products

For a J2EE based multi-tier application, the necessary software consists primarily of an application server and a database. For the software development, Integrated Development Environment (IDE) are used together with further development tools (e.g. for build management). In addition to this fundamental software, frameworks can provide often required functionalities like e.g. for a coherent layout control or for unit tests. The following paragraphs provide an overview over available software products for application servers, databases, IDE, development tools and frameworks. As the online shop will be based entirely on open standards and open source software, only corresponding products are presented. For each software category, a selection of available products is rst listed in a table. For a more exhaustive list of open source software for Java, consult e.g. the Java-Source (cf. [17]) website. The more interesting products are introduced afterwards, but an in depth description and comparison is out of the scope of this paper. Which software is chosen for the project as well as a short argumentation is then given in Section 6. Details for software used in the online shop can afterwards be found in the implementation section of this report.

4.3.1. J2EE Application Server

The general requirement for an application server to be J2EE compliant is, that it needs to implement the corresponding specication. As a consequence, their oered basic middleware services are similar. The main dierence between the available products is how they implement the J2EE specication and what tools they oer for development, deployment and administration. Table 4.2 lists a selection of available J2EE application server products. Product JBoss Sun Microsystems AS Platform Edition JOnAS Apache Geronimo URL http://www.jboss.com http://java.sun.com/j2ee/1.4/ download.html http://jonas.objectweb.org http://geronimo.apache.org

Table 4.2.: Software Products: J2EE Application Server

JBoss JBoss Inc. (cf. [18]) is one of the leading middleware provider. While their products are distributed for free under an open source licence, they sell additional support, consulting and training services. Their JBoss Application Server (cf. [21]) is widely used in productive systems and considered as stable and reliable. It integrates technology like Hibernate (cf. [14]), Apache Tomcat (cf. [48]), EJB 3.0, and JBoss Cache (cf. [22]) directly into its microkernel. A range of further products like the JBoss Eclipse IDE

4.3. Software Products

47

plugin (cf. [20]) or JBoss jBPM (cf. [19]) are available in addition to the standard deployment and administration consoles. Sun Microsystems AS Sun Microsystems (cf. [47]) oers three dierent application server editions (cf. [46])): the platform edition is free for development, deployment and redistribution, while the standard and enterprise edition require a software license. The dierence between these versions are the oered capabilities. The key features of the platform edition are the Web Services Security and JavaServer Faces support, as well as the integration into Suns development environment NetBeans. JOnAS JOnAS (cf. [24]) is a pure Java implementation of the J2EE specication by the ObjectWeb group. While they provide a standard EJB container, the Web container can be congured to use Tomcat or Jetty. It oers all required middle tier services as well as an administration console and clustering and performance services. Apache Geronimo Geronimo (cf. [12]) is the J2EE server project of the Apache Software Foundation. Although currently it is not fully J2EE compliant, it oers most of the required middleware services. Also development tools like e.g. an Eclipse plugin are available, but as an unstable release.

4.3.2. Database
In order to integrate a database in a J2EE application, a database vendor needs to provide the required Java Database Connectivity (JDBC) driver. Currently, there exist two popular open source databases used for web applications: MySQL (cf. [31]) and PostgreSQL (cf. [38]). They are similar in the oered services as well as in the available tools. For a more detailled comparison between the two, refer to [Con04] or [Gil03]. Apart from these relational databases, there exist other types like object-oriented or Extensible Markup Language (XML) databases (cf. [3]), but they are still under development and usually not used for productive systems. Product MySQL PostgreSQL Berkeley DB XML URL http://www.mysql.com http://www.postgresql.org http://www.sleepycat.com/products/ xml.shtml

Table 4.3.: Software Products: Database

MySQL There are two MySQL database editions available: the Community Edition is open source, while the Pro Certied Server requires a corresponding commercial licence and oers additional enterprise functionalities. The Community Edition is published under a GNU Public License (GPL) licence (cf. [GNU05b]), which means that this edition can only be used for software which is also open source. The Graphical User Interface (GUI) tools include the MySQL Migration Tool Kit, Administrator and Query Browser.

4.3. Software Products

48

PostgreSQL The PostgreSQL database is developed by the University of California at Berkeley and published under a Berkeley Licence. In contrast to the MySQL licencing scheme, it allows to integrate this database in any software product as long as the Berkeley Licence is included with it. Graphical administration tools for PostgreSQL are pgAdmin III and PhpPgAdmin. Berkeley DB XML The Berkeley DB XML is an XML database implemented as a layer on top of the relational Berkeley DB database. It stores XML les in collections an allows to retreive them using XQuery or XPath.

4.3.3. Integrated Development Environment (IDE)

An Integrated Development Environment is a software tool used for developing software, which usually includes a source code editor, compiler, build tools and a debugger. Popular IDE for J2EE development are Eclipse (cf. [9]) and NetBeans (cf. [32]). The choice between the two somehow depends on the application server in use, as Eclipse mainly supports JBoss while NetBeans the Sun application server. Product Eclipse NetBeans URL http://www.eclipse.org http://www.netbeans.org Table 4.4.: Software Products: IDE

Eclipse Eclipse is an extensible open source development platform and application framework. A variety of commercial and free plugins are available (cf. [10]), like the JBoss-IDE (cf. [20]) or QuantumDB (cf. [39])plugin. Further, it directly integrates the Ant build tool into the IDE. NetBeans NetBeans is an open-source project sponsored by Sun Microsystems. The IDE includes features for web, EJB or web service development as well as a range of additional plugins.

4.3.4. Development Tools

Development tools serve to facilitate the software development process. This can include for example the build management or source code generation. The Apache Ant (cf. [1]) tools has become the defacto standard for Java build management, while XDoclet (cf. [50]) is often used for J2EE development. Product Ant Maven XDoclet URL http://ant.apache.org http://maven.apache.org http://xdoclet.sourceforge.net Table 4.5.: Software Products: Tools

4.3. Software Products

49

Ant Apache Ant is a Java and XML-based build tool, similar to the make utility for the C programming language, but with the great benet to be platform/OS independent. The ant tasks provide services for e.g. compilation, running XDoclet, JUnit or creating the necessary ejb-jar, war and ear les. The ant build script calls these tasks and allows to dene dependencies between them. Maven Maven (cf. [27]) is a software project management and comprehension tool by Apache. Its objective is to make the build process easy and provide a uniform build system. The main dierence to Ant is, that the build tasks are implemented as plugins, which hides their complexity from the developer. Further, Maven tries to enforce best practices in software development and project management. But currently, Maven is still under development and not yet as mature as Ant. XDoclet XDoclet is an open source code generation engine, which enables attributeoriented programming for Java. This is accomplished by adding meta annotations in the form of special JavaDoc tags (similar to Java 1.4 annotations) to the source le. Ant then calls the corresponding tasks and XDoclet parses the annotated source les and generates e.g. XML descriptors or source code. XDoclet can be used for example to generate the necessary EJB component interfaces, Hibernate mapping les or Struts conguration les.

4.3.5. Frameworks
Frameworks provide the developer with a reusable common structure, as often required by applications. A developer can extend these frameworks at the corresponding hotspots in order to customize it for his needs. For J2EE based web applications, there exists a wide variety of available frameworks. Struts (cf. [44]), stxx (cf. [45]) and Java Server Faces (JSF) (cf. [25]) oer presentation logic based on the Model-View-Controller (MVC) design paradigm. For the object to relational mapping required in the integration layer, Hibernate (cf. [14]) or Java Data Objects (cf. [30]) can be used. JUnit (cf. [26]), DbUnit (cf. [7]) and Cactus (cf. [4]) are frameworks for unit testing and OSCache (cf. [34]) oers caching functionalities. Spring (cf. [42]) and HiveMind (cf. [15]) even go a step further as the other frameworks, as they provide complete middle-tier services. In addition, frameworks (cf. Table 4.7) like the Commons Beanutils (cf. [5]), Commons Email (cf. [6]), FOP (cf. [11]), JDOM (cf. [23]), POI (cf. [37]) and ROME (cf. [41]) oer spec application logic, e.g. for treating Java beans or XML les. Struts Struts is an open source framework of the Apache Software Foundation for building Java web applications. The framework is based on the Model 2 approach, a variation of the classic MVC design paradigm. The objective of this framework is to clearly separate data, its presentation and how it is processed. It provides a controller, responsible for processing a request. Data is encapsuled in the model, where the interaction can be based on e.g. JDBC, EJB or Hibernate. The view component then often is implemented in Java Server Pages, but also Extensible Stylesheet Language Transformations (XSLT) or other presentation systems can be used. In addition, struts also integrates the Struts Tiles and Struts Validator packages. Tiles is used for a coherent layout, while the Validator allows to verify user input.

4.3. Software Products

50 Type Presentation Presentation Presentation Presentation Presentation Presentation Presentation Integration Integration URL http://struts.apache.org http://struts.apache.org/ struts-tiles/ http://struts.apache.org http://sslext.sourceforge.net/ http://stxx.sourceforge.net http://java.sun.com/j2ee/ javaserverfaces/download.html http://struts.apache.org/ proposals/struts-faces.html http://www.hibernate.org http://java.sun.com/products/ jdo/ http://www.junit.org http://dbunit.sourceforge.net http://jakarta.apache.org/cactus http://www.opensymphony.com/ oscache http://www.springframework.org http://jakarta.apache.org/ hivemind

Product Struts Struts Tiles Struts Validator sslext stxx Java Server Faces (JSF) Struts-Faces Hibernate Java Data Objects (JDO) JUnit DbUnit Cactus OSCache Spring HiveMind

Test Test Test Cache Middle-Tier Middle-Tier

Table 4.6.: Software Products: Frameworks stxx The stxx framework is an extension of Struts for transforming XML with XSLT. The idea is to oer a more XML based alternative for the model and view components. It uses the W3C standard XForms to model the data in XML format. This XML data then can be transformed to either HTML or PDF using Extensible Stylesheet Language (XSL) and XSL-Formating Objects (FO). Nevertheless, as stxx is only a layer on top of Struts, all original functionalities still are available. Java Server Faces (JSF) JSF is another technology for building user interfaces for Java server applications. Like Struts, it is also based on the MVC design pattern. A further objective of this framework is to overcome the limitations of HTML by providing a rich User Interface (UI). It includes a set of APIs to represent these UI components, manage their state, handle events, input validation and dening page navigation. The UI components can afterwards be used in JSP pages by using the tags dened in the corresponding tag library. Struts-Faces Struts-Faces is a library to include Java Server Faces in a Struts based application. This allows to e.g. take advantage of the capabilities of JSF components for a rich user interface where needed, while the basic presentation services (like the controller) are provided by Struts. The article [McC05] explains the advantages in more details and outlines how to integrate JSF with Struts in a J2EE application.

4.3. Software Products

51 Java Beans utils Email tools Logging service XSL, XSLFO transformation XML le processing Microsoft le format processing RSS reader and writer http://jakarta.apache.org/ commons/beanutils/ http://jakarta.apache.org/ commons/email/ http://logging.apache.org/log4j http://xmlgraphics.apache.org/ fop/ http://www.jdom.org/ http://jakarta.apache.org/poi/

Commons Beanutils Commons Email Log4j FOP

JDOM POI

ROME

https://rome.dev.java.net/

Table 4.7.: Software Products: Frameworks (Logic) JUnit, DbUnit, Cactus JUnit is a testing framework for implementing unit tests in Java. It allows to dene TestCases in a TestSuite and execute them using the TestRunner. DbUnit is an extension to this framework aimed at putting the database into a dened state before running the unit tests. This avoids possible side eects which may be caused by previous test runs. For J2EE applications, the diculty arises that these tests must be executed in the application servers containers. Cactus is a framework for unit testing such server-side Java code (e.g. Servlets, JSP, EJB). It provides the necessary tools to run JUnit tests in this context. OSCache A crucial criteria for J2EE applications is performance. The OSCache framework is aimed at in memory and persistent on disk caching of JSP content, servlet responses or arbitrary objects. As a consequence, the web application can use these cached results and does not need to e.g. perform frequent queries on the database again. Spring Spring is a complete Java/J2EE application framework providing all necessary middle-tier services. Its objective is to reduce the complexity of developing J2EE based applications. Spring is based on a modular architecture, with the possibility to either use the provided services or plugin other frameworks. The core is its lightweight container based on the inversion of control (dependency injection) principle. An applications business objects are then developed using POJO and the necessary conguration is done declaratively through XML les. As such, it provides an alternative to the Enterprise JavaBeans. But Spring also covers other middle-tier services like object-relational mapping or presentation layer services. A developer can either use the provided modules or plugin other frameworks such as e.g. Hibernate or Struts. HiveMind HiveMind is a services and conguration microkernel. In this framework, services are implemented in POJO and congured in XML descriptors. The startup logic

4.4. Conclusion

52

of HiveMind parses these module deployment descriptors, instantiates and initializes those services and congurations for the underlaying J2EE or other APIs.

4.4. Conclusion
The software products used for the reseda e-shop project are listed in Table 4.8. One of the main decisions for the project is the choice of the J2EE application server. Suns as well as the JBoss application server are both stable products and widely used in production. The JBoss server was chosen rather due to personal preferences and experience, but also because of the available plugins (e.g. for debugging), the good integration into the Eclipse IDE and because Hibernate already is included in the standard distribution. An alternative to an application server would have been Spring. But as this framework only provides a lightweight container, all required services, like e.g. for transaction or communication, would have needed to be included. JBoss in contrast already oers these services out of the box, and hence one can benet from the coherent and tested conguration. Concerning the database, the choice was for MySQL. This decision is based on the fact, that MySQL currently oers better administration tools (MySQL Query Browser, MySQL Administrator), which facilitates working with this database, especially during development. But due to the use of Hibernate (see below), the reseda e-shop application could easily be congured to use PostgreSQL or any other major database instead of MySQL. Product JBoss MySQL Eclipse Ant, XDoclet Hibernate Struts, Struts Tiles, Struts Validator, sslext JUnit, DbUnit, Cactus OSCache Commons Beanutils, Commons Email, Log4j, FOP, JDOM, POI, ROME Type J2EE Application Server Database IDE Development Tool Framework (Integration) Framework (Presentation) Framework (Test) Framework (Cache) Framework (Logic)

Table 4.8.: Software Products for the Online Shop The IDE used for the project then was Eclipse, as JBoss can be well integrated by the oered plugins. For the development, also Ant as well as XDoclet is used, because these frameworks are stable and complete versions in contrast to e.g. Maven. For the presentation layer, Struts as well as Java Server Faces were an option. Struts was nally chosen, because this framework is thoroughly tested, documented and widely used in production. Also other required functionalities like validation, layout, ssl encryption are available by using Struts Validator, Struts Tiles and the sslext extension. The drawback of using Struts is, that this framework is considered to be a bit out of date (the dinosaur of the MVC frameworks) and rather complicated in use.

4.4. Conclusion

53

The decision for the integration layer was between using the standard EJB Entity Beans or implementing the data access by means of an integration framework like Java Data Objects or Hibernate. It was decided to not use the Entity Beans, as they are rather complicated to program and not so exible. In contrast, the chosen Hibernate framework allows to easily map POJO to a database and also automatically create the corresponding database schemas from these mapping les. Another benet is, that OSCache can be plugged into Hibernate as second level cache, which improves the applications performance. While the integration layer does not rely on the EJB technology, the business tier does use standard Session Beans to implement the projects use cases. This approach allows to benet from e.g. the JNDI lookup, and the declarative transaction and authorization management oered by the JBoss application server. The application is then unit tested using JUnit, DbUnit and Cactus. Further frameworks used for the reseda e-shop include the Apache Commons Beanutils and Commons Email, Log4j, FOP, JDOM, POI and ROME, which oer additional application logic not provided by the standard Java APIs.

5
Implementation
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 55 57 57 5.1.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2. Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.3. J2EE Application . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2. Presentation Tier . . . . . . . . . . . . . . . . . . . . . . . . . . 58 58 61 5.2.1. Presentation Tier Patterns . . . . . . . . . . . . . . . . . . . . . 5.2.2. Struts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3. Business Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.3.1. Business Tier Patterns . . . . . . . . . . . . . . . . . . . . . . . 5.3.2. EJB Session Beans . . . . . . . . . . . . . . . . . . . . . . . . . 63 65

5.4. Integration Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.4.1. Integration Tier Patterns . . . . . . . . . . . . . . . . . . . . . 5.4.2. Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 67

The focus of this chapter is on the implementation of the reseda e-shop application. For the development of this multi-tier J2EE application, the integration-, business- and presentation tier had to be implemented (cf. Figure 5.1). This section rst provides an overview over the involved layers and components as well as on the project itself. Afterwards, the presentation-, business- and integration-tier implementation is explained in more details. For each of these layers, the used J2EE patterns are presented. Design patterns (cf. [ACM03] and [GHJV02]) serve to communicate problems and solutions, they enable us to document a known recurring problem and its solution in a particular context, and to communicate this knowledge to others [ACM03, p. 9]. As such, patterns are observed through experience, are written in a structured format, prevent reinventing the wheel, are reusable artifacts, exist at dierent levels of abstraction, can be used together to solve larger problems and hence communicate design and best practices (cf. [Pas04]). Afterwards, the details concerning the actual implementation and the used frameworks for each tier is outlined.

54

5.1. Overview

55

Figure 5.1.: Implementation Overview

5.1. Overview
In this overview, the global architecture of the reseda e-shop application is rst introduced by a UML sequence diagram. This diagram shows how the involved components interact to store or retrieve data. Afterwards, some notes concerning the J2EE application, build management and the unit tests are given.

5.1.1. Architecture
The reseda e-shop application is based on a multi-tier architecture (cf. Figure 5.1). The resource tier is a relational database (MySQL, cf. [31]), the implementation of the integration tier is done with Hibernate (cf. [14]), EJB Session Beans (cf. [16]) are used for the business-tier, Struts (cf. [44]) for the presentation-tier and the client-tier consists of a web browser. The global architecture of the application and its components are shown in Figure 5.2. The simplied example treats the steps involved to save or update data in the resource-tier. In order to retrieve information from the database, similar steps are involved. First, a Client submits a request to the Struts ActionServlet. Based on the Uniform Resource Identier (URI), this servlet dispatches to the appropriate Struts Action, which then processes the request. The action creates the required Bean used to transport the data and populates it with the user input of the Struts Form. Next, the BusinessDelegate is created, which uses the ServiceLocator to lookup the corresponding EJB SessionFacade. The session bean as well uses the ServiceLocator instance to lookup the Hibernate SessionFactory. After this initialization, the actual request is processed. The Struts Action invokes the BusinessDelegates business method and passes the data in the TransferObject Bean. The invocation is then propagated to the SessionFacade, which is responsible for processing the request in a single transaction. New Hibernate Beans are created and their values are set. To get already existing data, the Hibernate SessionFactory is used to retrieve the current Session and to load the corresponding Beans from it. Likewise, this Session is used to save or delete Hibernate Beans. All changes applied to these persistent objects are afterwards propagated to the database by the Hibernate framework. After a successful transaction, the call returns to the Struts Action, which returns an ActionForward depending on the outcome of the invocation. The ActionServlet nally forwards the Client to the path stored in the ActionForward.

5.1. Overview

56

Figure 5.2.: Reseda E-Shop Architecture

5.1. Overview

57

5.1.2. Development
The reseda e-shop project is based on an iterative development model (cf. 3.4), which constantly analyses, species, designs, implements and tests selected use cases. Hence, the whole build management for the project was completely automatized using the Ant (cf. [1]) build tool and unit tested with JUnit (cf. [26]), DbUnit (cf. [7]) and Cactus (cf. [4]). Ant decomposes the build process into interdependent targets. Each target serves to accomplish some kind of work by calling the required Ant tasks. The Eclipse IDE allows to launch these targets individually or to build the whole project. The build process is congured in the Ant build.xml le (cf. extracts in appendix B). First, the projects global properties and paths are dened (cf. Listing B.1). The targets afterwards serve to either generate code by using XDoclet (cf. Listing B.2), accomplish any other kind of other work like creating the database schema (cf. Listing B.3) or to nally build and package the project (cf. Listing B.4). The unit tests rely on the JUnit, DbUnit and Cactus frameworks. JUnit serves to dene the actual unit tests, DbUnit allows to put the database into a well dened state for each test run and Cactus is required to run these tests in an EJB container. For each EJB Session Bean, there exists a corresponding test class to verify the correct behaviour of its methods. Note that these unit tests only check if the methods work correctly, but usually the returned or saved content is not veried.

5.1.3. J2EE Application

In order to deploy the J2EE application on an application server like JBoss, all components listed in Table 5.1 are packaged together with the required libraries, classes and conguration les into an Enterprise Archive (EAR) le. The Hibernate Archive (HAR) le contains all Hibernate libraries, classes, mapping les and congurations. Likewise, all EJB beans and their deployment descriptor are packaged into an EJB Java Archive (JAR) le. The content of the Web Archive (WAR) le consists of all resources related to the web application, which includes the Struts libraries, classes, conguration, as well as the taglibs, jsp pages and images. The client archive contains the business delegates, Transfer Object (TO) beans and other Java utility classes and tools. The Java Authentication and Authorization Service (JAAS) conguration is further packaged in a Service Archive (SAR). Component Hibernate Archive Enterprise JavaBeans Archive Web Archive Client Java Authentication and Authorization Service File res-hb.har res-ejb.jar res-web.war res-client.jar res-jaas.sar Content Hibernate EJB Web application Client application JAAS conguration

Table 5.1.: EAR Content

5.2. Presentation Tier

58

Usually, this EAR le is uploaded as a whole to the server, but JBoss also supports to deploy such an application in an exploded1 format. This approach was used by the project, as it allows to dynamically upload or generate les (e.g. images) used by the application.

5.2. Presentation Tier

The purpose of the presentation tier is to present an interface to the user. Its main function is to translate tasks and results to something the user can understand. The reseda e-shop application uses the Struts MVC framework, which implements several design patterns. These patterns are outlined only briey, and afterwards the implementation of the presentation tier with the Struts framework is explained in more details.

5.2.1. Presentation Tier Patterns

Struts is a web application framework based on the MVC architecture. The framework itself is based on various other design patterns, like the Service to Worker, Front Controller and Application Controller, Context Object, View Helper and Composite View. Model-View-Controller The Model-View-Controller pattern consists of three components (cf. Figure 5.3): The Model, View and Controller. The Model represents the business logic or state of an application, while the View is responsible for the layout of the applications state and the Controller mediates the application ow. In this model, the Controller delegates requests to the appropriate handlers. The appropriate business logic of the Model is then called to perform the requested task. If the state of the Model changes, the View is notied and changes the layout accordingly. The benet of this MVC architecture is the clear separation and loose coupling between the View and the Model, which facilitates the development and maintenance of an application. Service To Worker The Service to Worker (cf. [ACM03, p. 276-287]) can be used to centralize control and request handling to retrieve a presentation model before turning control over to the view [ACM03, p. 276]. It helps to perform core request handling and invoke business logic, before the control is passed to the view. The pattern itself is composed of the Front Controller, Application Controller and View Helper pattern. In this pattern (cf. Figure 5.4), the FrontController receives a request from a Client, which it delegates to the ApplicationController. Here, the request is resolved and the appropriate Command is invoked. The Command then accesses some kind of BusinessService that provides the data for the PresentationModel. The ApplicationController then performs the appropriate view management and dispatches to it. The ViewHelper nally transforms the presentation model for the view.
1

The content is extracted.

5.2. Presentation Tier

59

Figure 5.3.: Model-View-Controller [Hus03, p. 44]

Figure 5.4.: Service To Worker [ACM03, p. 279]

Front Controller The purpose of the Front Controller (cf. [ACM03, p. 166-180]) pattern is to centralize control logic that might otherwise be duplicated [and to] manage the key request handling activities [ACM03, p. 166]. The Front Controller is hence the entry point of the system, which manages and handles all related requests. It then delegates work to the Application Controller. Application Controller The Application Controller pattern (cf. [ACM03, p. 205 - 239]) is used to centralize retrieval and invocation of request-processing components, such as commands and views [ACM03, p. 205]. It centralizes and modularizes action and view management and dispatches the requests to the appropriate ones.

5.2. Presentation Tier

60

Figure 5.5.: Context Object [ACM03, p. 183]

View Helper In the View Helper pattern (cf. [ACM03, p. 240-261]), Views serve to encapsulate formatting code and Helpers to encapsulate view-processing logic [ACM03, p. 241]. Views delegate the processing to Helper classes (POJO, tags), which perform the required formatting logic (e.g. generating a Hypertext Markup Language (HTML) table).

Context Object The Context Object pattern (cf. [ACM03, p. 181-204]) allows to encapsulate state in a protocol-independent way to be shared throughout your application [ACM03, p. 181]. As a consequence, system data can be shared with other parts of the application without tying the application to a specic protocol. As an example, the Hypertext Transfer Protocol (HTTP) request parameters of a form can be stored in a context object and thus made available, converted or validated without depending on the protocol. The idea behind the pattern (cf. Figure 5.5) is, that a Client creates a ContextObject with a ContextFactory. The ContextObject encapsulates the data and hides the application components from the underlying details of the ProtocolInterface.

Composite View The aim of the Composite View pattern (cf. [ACM03, p. 262-275]) is to allow views to be composed of multiple atomic subviews [ACM03, p. 262]. The benet of this approach is, that these subviews can be included dynamically and therefore the page layout can be managed independently of the content. In Struts, this functionality is provided by the Struts Tiles framework. In this pattern (cf. Figure 5.6), the View is rendered by a ViewManager. Using the layout Template, the CompositeView is created by including the SimpleView subviews.

5.2. Presentation Tier

61

Figure 5.6.: Composite View [ACM03, p. 265]

Figure 5.7.: Struts Architecture [Hus03, p. 15]

5.2.2. Struts
The reseda e-shop application uses Struts as well as the Struts Validator and Struts Tiles frameworks and the sslext extension. Struts is a web application framework based on the MVC paradigm. Struts Validator allows to verify user input and Struts Tiles is used for the layout. Finally, sslext is an extension to struts for HTTP / Hypertext Transfer Protocol Secure (HTTPS) switching. The necessary Struts, Struts Validator, Struts Tiles and sslext conguration les are generated with XDoclet from the annotations in the corresponding Java classes. All the conguration les are then packaged together with the struts libraries, classes, jsp pages and further web resources in the WAR le, which is deployed in the EAR le on the application server. The global architecture of the Struts framework is outlined in Figure 5.7. The ActionServlet controls the navigation ow, Forms are used to capture user input and Actions serve to access business logic. Based on the URI, a clients request is rst dispatched by the ActionServlet to the appropriate Action class. If required, the Action collects the users input

5.2. Presentation Tier

62

from the Form. The Action is responsible for accessing the business tier in order to perform the requested task. Upon completion, the Action class returns an ActionForward, which is used by the ActionServlet to forward to the corresponding page. The Struts Validator framework is responsible for the validation of the Struts Forms. It provides several built in validators (dened in the validator-rules.xml le) to e.g. assure that an input eld is not empty or to control the correct format of an email address, but also custom validation rules can be implemented. The validator is called prior to an Action, and returns control to the input upon a detected error. The layout of the web application is built by Struts Tiles. This framework allows to dene a central layout and each page then declares which subviews (tiles) are inserted into this layout. All denitions are kept in the tiles-defs.xml le. The ActionServlet only calls the identier of a page, and Struts Tiles is then responsible to render the actual page. Finally, the sslext extension for Struts provides functionalities for HTTP / HTTPS switching. The standards allow to switch from HTTP to HTTPS, but the inverse is by denition not possible without loosing the session context2 . The sslext extension allows switching in both directions by copying the corresponding session information. For each page denition, one can declare whether it should be in the HTTP or HTTPS context. Form The Struts forms serve to collect user input. Each form is identied by its name and an annotation indicates whether it should also be validated. Such a form (cf. Listing C.1, Listing C.2) is basically a bean with getter and setter methods for the properties, and optional validate and reset methods called by the frameworks. As a convention for the reseda e-shop application, each form also has setForm(bean), setBlankForm(bean, supportedLocales) and populateBean(bean) methods to initialize or retrieve a forms data. The XDoclet annotations allow to automatically generate the corresponding Struts conguration les. Action Struts actions are used to call the business logic for the requested task. An action (cf. Listing C.3, Listing C.4) is dened by its path and type. It further indicates its scope and if the framework should validate the form prior to calling the action. If the action has a form input, its name and input are also indicated. In addition, each action may specify local action forwards. The framework then calls the execute method, in which the action performs the required tasks. Depending on the output of the action (success / failure), the corresponding ActionForward is returned by this method, which the ActionServlet uses to dispatch. Again, the Struts conguration les are generated by XDoclet from the provided annotations. Conguration Files For the Struts core framework, all conguration information is dened in the strutscong.xml le (cf. Listing C.5, Listing C.6 ). This includes form bean denitions, action
2

It is considered as a potential security risk, because condential information could be afterwards available in a non-secure context.

5.3. Business Tier

63

mapping denitions, global forward denitions, controller denition, as well as message resource and plugin denitions. The Struts Validator framework lists its validators in the validator-rules.xml (cf. Listing C.8) and the validation conguration in the validation.xml le (cf. Listing C.9 ). Finally, the layout as used by Struts Tiles is dened in tiles-defs.xml (cf. Listing C.7 ). A global layout denes the general layout of the website, and extensions allow to specify the required tiles for a certain group of pages. A concrete page extends such a denition and puts in the required jsp page for the view.

5.3. Business Tier

In the business tier, all of an applications business logic is implemented. Further, it serves to move or translate data between the resource- and the presentation tier. This layer includes various J2EE design patterns (Business Delegate, Session Faade, Service Locator, Transfer Object), and the actual business logic is implemented by using EJB Session Beans.

5.3.1. Business Tier Patterns

For the reseda e-shop application, several J2EE design patterns are used: The Session Faade encapsulates business tier components and exposes a coarse grained service, the Business Delegate hides the complexity of remote communication, a Service Locator serves to retrieve components and services and the Transfer Object pattern is used to move data between tiers. Session Faade The Session Faade pattern (cf. [ACM03, p. 341-356]) is used to encapsulate businesstier components and expose a coarse-grained service to remote clients [ACM03, p. 342]. The general idea behind the pattern is, that clients do not access business objects directly, but instead access a Session Faade. The Session Faade then calls the required business components and thus also hides the complex interactions and dependencies, reduces network trac, reduces coupling between layers and centralizes security and transaction control. Usually, each use case of an application is implemented in a seperate Session Faade. In the case of J2EE, EJB Session Beans are used for this purpose. Figure 5.8 shows a sequence diagram of the pattern. A client invokes the oered methods of the SessionFacade, which then in turn invokes the required BusinessObjects and DataAccessObjects. Business Delegate The purpose of the Business Delegate pattern (cf. [ACM03, p. 302-314]) is to encapsulate access to a business service [ACM03, p. 303]. It abstracts and hides the details of the implementation of the business services from the client, handles exceptions, can perform retry or recovery operations or cache results. Usually, the services oered by a Business Delegate correspond to the ones implemented in a Session Faade. As such, this pattern

5.3. Business Tier

64

Figure 5.8.: Session Faade [ACM03, p. 344]

hides remoteness and provides a logical extension of the business tier, which is accessed from clients in the presentation tier like a normal Java object. The pattern (as seen in Figure 5.9), consists of the Client, who rst creates a BusinessDelegate. Afterwards, he invokes the oered services and the BusinessDelegate is charged with getting or invoking the required BusinessService. Service Locator The Service Locator pattern (cf. [ACM03, p. 315-240]) helps to implement and encapsulate service and component lookup [ACM03, p. 316]. It therefore hides the implementation details from the client and can increase performance through caching. Most often, the Service Locator is called from a Business Delegate. In this pattern (cf. Figure 5.10), the Client rst gets an instance of the ServiceLocator. The service locator then is concerned with creating or retrieving the requested service or component by e.g. Java Naming and Directory Interface (JNDI), and the client receives a reference or handle to the desired object. Transfer Object The Transfer Object (cf. [ACM03, p. 415-432]) can be used to carry multiple data elements accross a tier [ACM03, p. 415]. The forces for this pattern are to reduce remote requests accross a network and to increase network performance. Usually this pattern is used together with the Business Delegate, where each method accepts or returns a Transfer Object.

5.3. Business Tier

65

Figure 5.9.: Business Delegate [ACM03, p. 305]

The pattern (cf. Figure 5.11) is rather simple: A TransferObject basically is a Java bean. A Client or Component creates such an object by providing the required values, which afterwards can be retrieved by its getter methods.

5.3.2. EJB Session Beans

In the reseda e-shop application, the implementation of the business tier is done in EJB Session Beans. There exists a stateless or stateful Session Bean for each use case of the specication. A Session Bean requires a remote interface and remote home interface or a local interface and local home interface, or both. In addition, an EJB deployment descriptor and the JBoss specic jboss.xml descriptor for the Session Beans is needed. For the project, all the necessary interfaces and descriptors were generated with XDoclet from the annotations in the Session Beans. The Session Beans and deployment descriptors are then packaged in a EJB jar archive and deployed together with the other components of the J2EE application in the EAR le. Session Beans A Session Bean is used to implement the business logic needed for a use case. These beans can be either stateless or stateful, depending on weather they maintain some kind of conversational state or not. A client can lookup such a Session Bean with JNDI to invoke some kind of business task on the server. For the reseda e-shop application, they are mainly used to store or retrieve the online shops data. Listing D.3 shows a simplied version of the product management Session Bean together with the XDoclet annotations.

5.4. Integration Tier

66

Figure 5.10.: Service Locator [ACM03, p. 318]

Deployment Descriptors For each Session Bean, the EJB deployment descriptor must contain the corresponding entries. The descriptor tells the J2EE application server which classes make up a beans implementation, its properties like the JNDI name, as well as the services (e.g. transaction, security) it requires. Listing D.5 and Listing D.4 show the entries as generated by XDoclet from the annotations found in the Session Bean of Listing D.3.

5.4. Integration Tier

The purpose of the integration tier is to encapsulate all functionalities required for accessing data in the resource tier. As such, it decouples the resource- from the business-tier. The design patterns used is the Data Access Object, while the implementation of this layer is done by means of the Hibernate framework.

5.4.1. Integration Tier Patterns

In the integration tier, the Data Access Object pattern is used. Although this pattern is not used in a custom implementation, but actually already implemented in the interface provided by Hibernate. Data Access Object The Data Access Object pattern (cf. [ACM03, p. 462-495] serves to abstract and encapsulate all access to the persistent store [ACM03, p. 463]. Such an object manages the connection with the resource tier to store and retrieve data. Hence, it decouples the

5.4. Integration Tier

67

Figure 5.11.: Transfer Object [ACM03, p. 417]

persistent storage from the application and provides a uniform data access API. As a consequence, this pattern facilitates maintainability and portability of the application. The pattern (cf. Figure 5.12) basically consists of the Client that requires access to the data and the DataAccessObject which abstracts the underlying data access implementation. The DataSource then represents the resource tier (e.g. a relational database) and the data to store or retrieve is contained in the Data object.

5.4.2. Hibernate
For the reseda e-shop application, the implementation of the integration tier is done by using the Hibernate framework. Hibernate is an object/relational mapping tool, which maps Java beans to the tables and rows of a relational database by means of XML mapping les. In addition to this mapping, the corresponding database schema can be automatically generated and the framework also provides data query and retrieval facilities. All Hibernate libraries, Java classes, XML mapping and conguration les are then packaged in a HAR le and deployed together with the other components of the J2EE application in the EAR le. Figure 5.13 shows a high level abstraction of the Hibernate architecture. Apart from the Hibernate XML mapping les, a SessionFactory is created. An application obtains a reference to this SessionFactory in order to get a Hibernate Session. The session is then used to store or retrieve the required data by means of persistent objects. Hibernate works together with various support services, like transaction managers, connection pools or caching services. They can be provided by a J2EE application server (managed environment), but it is also possible to run Hibernate in a standalone mode (nonmanaged environment), where the application oers the required services.

5.4. Integration Tier

68

Figure 5.12.: Data Access Object [ACM03, p. 464]

Hibernate Mapping Files The purpose of the Hibernate XML mapping les is to provide the Hibernate framework with information on how to persist objects to a relational database. In addition, this information can also be used to generate the database schema. Such a mapping le (cf. Listing E.2) rst declares the persistent Java class and the database table it corresponds to. Each class then requires a unique id attribute, which unambiguously identies a row in the database table. Each property, component or collection (e.g. set) is then mapped to the columns and tables of the database. When a caching service is used, the usage for the whole class (entity) and the sets (collection) is indicated. While it is possible to write these mapping les manually, they can also be generated with XDoclet from the annotations provided in the hibernate beans (cf. Listing E.1). Session Factory The conguration for the SessionFactory then is done by the hibernate.cfg.xml le. This XML le (cf. Listing E.3) declares the basic Hibernate properties like the Standard Query Language (SQL) dialect to use or the database connection properties, as well as all the mappings. This conguration le can be automatically generated with XDoclet from the XML mapping les. The conguration le serves to instantiate the Hibernate SessionFactory. The session factory can be either created by the application, but it is also possible to generate and deploy it as a JMX service on a compliant J2EE application server. In the case of

5.4. Integration Tier

69

Figure 5.13.: Hibernate Architecture [Hib05, p. 24]

JBoss, a corresponding MBean is provided by Hibernate. The required service descriptor (cf. Listing E.4) for this MBean contains the initial parameters, like the factory name, datasource name and caching options. The service descriptor, Java classes, XML mapping and conguration les are packaged in a HAR le. The SessionFactory is instantiated on startup of the application, the session is automatically bound to the scope of the Java Transaction API (JTA) transactions and the factory can be retrieved by JNDI. Persistent Objects In order to store or retrieve data from the database, persistent objects are used. These objects are normal Java beans (with getter and setter methods), which implement the entities of an applications business problems (e.g. product, category). Their state is synchronized with the content of the database, as dened in the mapping les. Listing E.5 outlines the required steps to work with such persistent objects. First, the SessionFactory is looked up using JNDI (in this case by means of a ServiceLocator). Next, the current Session is obtained from the factory. To save an object, the persistent object is treated like a normal Java bean and afterwards saved in the session. Likewise, an object can be loaded from the session to get its values or it can be deleted. All changes done to a persistent object are afterwards propagated to the database by the Hibernate framework.

6
Conclusion
6.1. Achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.1.1. Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.2. Website Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 72 72 6.2. Possible Enhancements . . . . . . . . . . . . . . . . . . . . . . . 72 6.3. Final Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

In conclusion, the Reseda E-Shop project was successful: The J2EE application is running and currently successfully deployed on the test server. Afterwards, the migration from the old static website to the new online shop (cf. [40]) should be possible without any major problems1 . This chapter provides some more notes and remarks concerning the project, like for the achievements, possible enhancements and nal thoughts.

6.1. Achievements
The whole Reseda E-Shop project is entirely based on standard and free software and hence does not require any licence fees. The J2EE application implements most of the best practices for online retailing (cf. 2.2.3) and the basic functionalities of online shops (cf. 2.3.2) in a clean and extensible architecture. In addition to the actual planning and development of the application, a special eort was put into optimizing the websites design and usability, and also the deployment of the nal application in a production environment showed to be a challenge.

6.1.1. Application
The Reseda E-Shop application oers all required functionalities of an online shop. This includes the product catalog, product information, shopping basket, customer account and order or consultings. In addition, also information concerning the company, contact possibilities, news and support is provided on the website. All these storefront features
1

The new site should go online in August 2006.

70

6.1. Achievements

71

can be managed and maintained in the storeback area by the store owner, without any technological knowledge. This section outlines the main features of the online shop application, refer to the corresponding manuals (cf. [Res06a], [Res06e] and [Res06b]) for a more detailled explanation, or directly try out the application with the easy to install evaluation version (cf. [Res06c]). The online shops product catalog (cf. Screenshot Figure A.1) structures the available products into categories. An unlimited number of such categories can be dened and grouped into parent and sub-categories. Apart from the basic information like title, description and image of a category, additional information in the form of custom HTML pages as well as image galleries are available. A user can browse this catalog and obtain general information as well as an overview over a categorys products. The product information (cf. Screenshot Figure A.2) then is concerned with providing information to a specic product. This includes basic information like name, description and images as well as links to further information and related products (cross-selling). Each product can either be non-customizable or customizable, meaning that in the later case a customer can choose between the oered options. First, the customer obtains an overview over the available options for a product. In the customization, he then selects the options and the price is calculated. A customer can add products he is interested in to the persistent shopping basket (cf. Screenshot Figure A.3). The basket lists all these items together with the quantity, chosen options and price. The shopping baskets content then can either be downloaded as a pdf le, the customer can request a consulting or order the items. In the order process (cf. Screenshot Figure A.4), a customer rst needs to create an account or login to his existing one. The account stores all the customers data as well as all information concerning previous consultings and orders. To continue the order process, the customer then controls his user data (e.g. address), selects the desired company, payment option, delivery option and delivery date. He then checks the whole order, submits it and receives a conrmation by email. All information concerning the order can afterwards be downloaded in a pdf le. The consulting process is similar, with the dierence that a customer does not select a payment and delivery option, but a consulting option (email, phone or meeting) instead. All transmissions in the account and the order or consulting process are secured by Secure Sockets Layer or Secure Server Line (SSL) encryption. Apart from the basic online shop functionalities, the website also provides general information concerning the company and their employees. Slideshows for the products, factory and showroom allow the customer to gain an overall impression of the enterprise. For each company, detailled information like opening hours and directions are provided online and can be downloaded as a pdf. In addition, also job oers can be published on the website. To contact the company, the customer is given the possibility to either ll out an online email or address form and submit it. The news section allows the company to communicate all kinds of information to their customers. Apart from the online news, also a newsletter and rss feeds (rss 1.0, rss 2.0, atom 0.3) are available. In the support area, the customer can nd various kinds of information. This includes the general terms, legal notice, faqs and links to other websites. All the above mentioned storefront features can be managed and maintained in the storeback area by users with the Manager (cf. Screenshot Figure A.5) or Administrator (cf.

6.2. Possible Enhancements

72

Screenshot Figure A.6) role. A manager is concerned with the daily business like the account management and processing of the online orders or consultings. He can manage the customer accounts, process or create online orders and consultings and send consulting information per email to a customer. The administrator is responsible for the setup and maintenance of the online shop. This includes the conguration of the general parameters of the application, user management, setting up the product catalog and managing the products, providing the company information, publishing news and maintaining support options.

6.1.2. Website Design

For the use of this e-shop in a real production environment, one of the most important issues is the layout and usability of the website. A customer is not (and must not be) interested at all in the technology behind the website - it simply needs to work. As a consequence, the website should reect the corporate identity of a company (e.g. layout, colors, font, style), so that a customer always knows that he is visiting the site of a certain enterprise. Likewise, the usability (e.g. navigation, content, presentation, fast page loading) is important, a customer quickly needs to nd the desired information and we do not want him to quit the site frustrated. In order to achieve these objectives, it was decided that the advertising agency die3 (cf. [8]) will revise the websites layout and usability. This agency is responsible for all marketing and advertising activities of Reseda. Based on their propositions and remarks, the website was afterwards optimized to reect Resedas corporate identity and to meet the current usability standards.

6.1.3. Deployment
Another challenge for the project was the deployment of the J2EE application on a server, as this required to setup and congure a Linux operating system for use in production. The important issues here are security and maintenance. While it is for example easy to use JBoss for development, as every feature already is installed, many of them need to be secured (e.g. jmx- and web-console) or can even be removed (e.g. web services) to improve the performance of the J2EE server. In addition, also standard operating system applications (e.g. ssh, rewall) need to be congured and additional ones (e.g. mailserver, webalizer) must be installed. The online shop application is now hosted by Metanet (cf. [28]) on a dedicated server.

6.2. Possible Enhancements

The choice of the main technologies and frameworks for the project was in general a good decision. Only the Struts framework had some drawbacks and one could reconsider replacing it with another web framework. The possible enhancements of the application itself are not mainly in its functionalities, but more in the integration of the e-shop into other software systems, which it currently lacks. But due to the clean and extensible software architecture of the Reseda E-Shop application, most of these improvements could be accomplished easily.

6.3. Final Thoughts

73

Concerning the technology involved for the online shop application, Struts showed to be somehow rather tedious to programm and not very well suited for dynamic and rich user interfaces. It requires rather many classes to implement functionalities and does not provide sophisticated means to treat dynamic forms. Currently, the only alternative would be using JSF, as other frameworks and technologies are not yet as mature. But in the future, XML based technologies like e.g. XForms could provide these required rich user interfaces. While the online shop application itself implements most of the current standards for e-business, its major drawback is the missing integration into other software systems. Possible enhancements would be to provide e.g. interfaces to ERP or other IT systems in order to avoid the media disruption caused by printing out the information and entering it manually in another system. Likewise, the stored information (e.g. orders) in the database is currently not used for analytical purposes. Enhancements could therefore include basic data analysis tools for the e-shop application or tools for the integration into e.g. a data warehouse.

6.3. Final Thoughts

For the project in general, it turned out to be dicult to plan and estimate the time needed to accomplish certain tasks. Especially the time required for the programming of the application, the deployment and the revision of the websites layout was underestimated. As a consequence, the whole project was delayed and took about two months longer than expected. The choice of using J2EE, Struts and Hibernate as the main technologies for the application prooved to be a good combination. These technologies and frameworks are stable production versions and work together well. Another benet of using these standards is their good documentation and the available tutorials, which makes learning the essentials and programming much easier. Especially using Hibernate in contrast to EJB Entity Beans was a great relief for the programming, as this framework provides much better object to relational mapping possiblities and useful tools like e.g. for automatically creating the database schema. The implementation itself was accomplished without any major diculties, but a considerable eort was required mainly for installing, conguring and understanding the various technologies. Nevertheless, there were always some minor problems (e.g. nding bugs, xing some XDoclet tasks) which needed to be solved in order to continue the project. But it somehow became dicult in time to unit test the application. The testing frameworks seem not to be designed for rather large databases, as used by this project2 . Because each test run drops and inserts all data to put the database in a well dened state, it takes about ve minutes to test one single method. Likewise, as the project itself is rather large3 , some memory problems with Ant and XDoclet had to be xed. The Reseda E-Shop project was an interesting an challenging master thesis, as it required to lead a real-world project from the beginning to the end. Starting from meeting the user and discussing their requirements, to planning, implementing, testing and nally de2 3

The database consists of about 80 tables. The project consists of about 600 source les (ca. 66000 lines of code, 28000 number of statements).

6.3. Final Thoughts

74

ploying the application in a production environment, many elds of project management and software development were involved. The online shop application itself reects the needs of the Reseda company: it allows to present their highly customizable products online, provide information concerning the company, publish news and send newsletters. Further, it integrates the website to their physical stores by means of the consulting and contact possiblities, and the online orders provide an additional sales channel. In comparison to the websites of other furniture companies, Resedas online presence will be leading in this market area.

A
Screenshots

75

76

Figure A.1.: Screenshot: Product Catalog

Figure A.2.: Screenshot: Product Information

77

Figure A.3.: Screenshot: Shopping Basket

Figure A.4.: Screenshot: Order Process

78

Figure A.5.: Screenshot: Manager

Figure A.6.: Screenshot: Administrator

B
Ant

79

80

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37

<?xml v e r s i o n = " 1 . 0 " ?> <! =================================================================== > <! Reseda EShop B u i l d F i l e > <! =================================================================== > < p r o j e c t name= " r e s " d e f a u l t = " d i s t " > <! =================================================================== > <! P r o p e r t i e s > <! =================================================================== > <! p r o j e c t name f i l e > < p r o p e r t y name= " p r o j e c t . name . f i l e " v a l u e = " r e s " / > <! deploy d i r e c t o r y > < p r o p e r t y name= " deploy . d i r " v a l u e = "C : \ Programme \ jboss 4 . 0 . 3 \ s e r v e r \ d e f a u l t \ deploy " / > <! d i r e c t o r y p r o p e r t i e s > < p r o p e r t y name= " s r c . d i r " v a l u e = " $ { b a s e d i r } / s r c " / > < p r o p e r t y name= " j a v a . s r c . d i r " v a l u e = " $ { s r c . d i r } / j a v a " / > < p r o p e r t y name= " c o n f . d i r " v a l u e = " $ { s r c . d i r } / c o n f " / > < p r o p e r t y name= " b u i l d . d i r " v a l u e = " $ { b a s e d i r } / b u i l d " / > < p r o p e r t y name= " j a v a . b u i l d . d i r " v a l u e = " $ { b u i l d . d i r } / j a v a " / > < p r o p e r t y name= " d i s t . d i r " v a l u e = " $ { b a s e d i r } / d i s t " / > < p r o p e r t y name= " l i b . d i r " v a l u e = " $ { b a s e d i r } / l i b " / >

<! =================================================================== > <! Paths > <! =================================================================== > <! g l o b a l p r o j e c t c l a s s p a t h s > <path i d = " p r o j e c t . c l a s s p a t h " > <path > < f i l e s e t d i r ="${ l i b . d i r } "> < i n c l u d e name= " / . j a r " / > </ f i l e s e t > <pathelement path= " $ { j a v a . b u i l d . d i r } " / > </ path > </ path >

Listing B.1: Ant Build File (Part 1/4): build.xml

81
<! =================================================================== > <! XDoclet > <! =================================================================== > < t a r g e t name= " x d o c l e t i n i t " depends= " i n i t " > < t a s k d e f name= " h i b e r n a t e d o c l e t " classname= " x d o c l e t . modules . h i b e r n a t e . H i b e r n a t e D o c l e t T a s k " classpathref=" project . classpath " / > < t a s k d e f name= " e j b d o c l e t " classname= " x d o c l e t . modules . e j b . EjbDocletTask " c l a s s p a t h r e f = " project . classpath " / > < t a s k d e f name= " webdoclet " classname= " x d o c l e t . modules . web . WebDocletTask " c l a s s p a t h r e f = " project . classpath " / > </ t a r g e t > <! > <! h i b e r n a t e d o c l e t : generates h i b e r n a t e mapping and c o n f i g u r a t i o n f i l e s > <! > < t a r g e t name= " x d o c l e t h i b e r n a t e d o c l e t " depends= " x d o c l e t i n i t " > < h i b e r n a t e d o c l e t d e s t d i r = " $ { j a v a . s r c . d i r } " e x c l u d e d t a g s = " @version , @author , @todo " addedtags = " @xdocletgenerated a t $ {TODAY} " f o r c e = " f a l s e " verbose= " t r u e " > < f i l e s e t d i r ="$ { java . src . d i r } "> < i n c l u d e name= " / h i b e r n a t e / / . j a v a " / > </ f i l e s e t > <hibernate version=" 3.0 " / > < h i b e r n a t e c f g v e r s i o n = " 3 . 0 " d e s t D i r = " $ { c o n f . d i r } / h i b e r n a t e " d r i v e r = " $ { db . d r i v e r } " j d b c U r l = " $ { db . u r l } " userName= " $ { db . u s e r i d } " password= " $ { db . password } " p o o l S i z e = " 10 " d i a l e c t = " org . h i b e r n a t e . d i a l e c t . MySQLDialect " showSql= " f a l s e " / > </ h i b e r n a t e d o c l e t > </ t a r g e t > <! > <! e j b d o c l e t : generates e j b i n t e r f a c e s , d e p l o y m e n t d e s c r i p t o r > <! > < t a r g e t name= " x d o c l e t e j b d o c l e t " depends= " x d o c l e t i n i t " > < e j b d o c l e t d e s t d i r = " $ { j a v a . s r c . d i r } " e x c l u d e d t a g s = " @version , @author , @todo " addedtags= " @xdocletgenerated a t $ {TODAY} " ejbspec = " 2 . 1 " f o r c e = " f a l s e " > < f i l e s e t d i r ="$ { java . src . d i r } "> < i n c l u d e name= " / . j a v a " / > <exclude name= " / Adaptor . j a v a " / > </ f i l e s e t > <localinterface /> <localhomeinterface / > < d e p l o y m e n t d e s c r i p t o r d e s t d i r = " $ { c o n f . d i r } / e j b " validateXML= " t r u e " / > < j b o s s v e r s i o n = " 4 . 0 " s e c u r i t y d o m a i n = " j a v a : / j a a s / appr e s " d e s t d i r = " $ { c o n f . d i r } / e j b " validateXML= " t r u e " / > </ e j b d o c l e t > </ t a r g e t > <! > <! webdoclet : generates web . xml , s t r u t s c o n f i g , v a l i d a t o r f i l e s > <! > < t a r g e t name= " x d o c l e t webdoclet " depends= " x d o c l e t i n i t " > <webdoclet d e s t D i r = " $ { c o n f . d i r } / web " excludedTags= " @author , @version , @todo " addedtags= " @xdocletgenerated a t $ {TODAY} " > < f i l e s e t d i r ="$ { java . src . d i r } "> < i n c l u d e name= " / . j a v a " / > </ f i l e s e t > <! web deployment d e s c r i p t o r > < d e p l o y m e n t d e s c r i p t o r s e r v l e t s p e c = " 2 . 4 " d e s t d i r = " $ { c o n f . d i r } / web " mergeDir= " $ { c o n f . d i r } / web / merge " displayname= " r e s " validateXML= " t r u e " / > <! j b o s s web deployment d e s c r i p t o r > <jbosswebxml v e r s i o n = " 4 . 0 " s e c u r i t y d o m a i n = " j a v a : / j a a s / appr e s " d e s t d i r = " $ { c o n f . d i r } / web " validateXML= " t r u e " / > <! s t r u t s > < s t r u t s c o n f i g x m l v e r s i o n = " 1 . 2 " d e s t D i r = " $ { c o n f . d i r } / s t r u t s / core " mergeDir= " $ { c o n f . d i r } / s t r u t s / core / merge " c o n t r o l l e r = " org . apache . s t r u t s . c o n f i g . S e c u r e A c t i o n C o n f i g " validateXML= " t r u e " / > < s t r u t s v a l i d a t i o n x m l v e r s i o n = " 1 . 1 . 3 " d e s t D i r = " $ { c o n f . d i r } / s t r u t s / v a l i d a t o r " validateXML= " true " /> <! t a g l i b > < j s p t a g l i b d e s t i n a t i o n F i l e = " rest a g s . t l d " shortName= " r e s " xmlencoding= "UTF8" j s p v e r s i o n = " 1 . 1 " t a g l i b v e r s i o n = " 1 . 2 " d e s c r i p t i o n = " Tags f o r t h e r e s a p p l i c a t i o n . " / > </ webdoclet > </ t a r g e t >

2 4

8 10 12 14

16 18

20 22 24 26

28 30 32 34

36 38 40 42

44 46 48

50

52

54

56

Listing B.2: Ant Build File (Part 2/4): build.xml

82

2 4 6 8 10 12 14 16 18 20 22

24

<! =================================================================== > <! H i b e r n a t e Schema > <! =================================================================== > <path i d = " h i b e r n a t e . schema . c l a s s p a t h " > <path > < f i l e s e t d i r ="${ l i b . d i r } / hibernate "> < i n c l u d e name= " . j a r " / > </ f i l e s e t > < f i l e s e t d i r = " $ { l i b . d i r } / mysql " > < i n c l u d e name= " . j a r " / > </ f i l e s e t > < f i l e s e t d i r = " $ { l i b . d i r } / commons " > < i n c l u d e name= " . j a r " / > </ f i l e s e t > < f i l e s e t d i r ="${ l i b . d i r } / log4j "> < i n c l u d e name= " . j a r " / > </ f i l e s e t > <pathelement path= " $ { j a v a . b u i l d . d i r } " / > </ path > </ path > < t a r g e t name= " h i b e r n a t e i n i t " depends= " i n i t " > < t a s k d e f name= " schemaexport " classname= " org . h i b e r n a t e . t o o l . hbm2ddl . SchemaExportTask " c l a s s p a t h r e f = " h i b e r n a t e . schema . c l a s s p a t h " / > < t a s k d e f name= " schemaupdate " classname= " org . h i b e r n a t e . t o o l . hbm2ddl . SchemaUpdateTask " c l a s s p a t h r e f = " h i b e r n a t e . schema . c l a s s p a t h " / > </ t a r g e t > <! > <! h i b e r n a t e schemaexport f i l e : e x p o r t s t h e schema t o a f i l e > <! > < t a r g e t name= " h i b e r n a t e schemaexport f i l e " depends= " compilejava , h i b e r n a t e i n i t " > <schemaexport c o n f i g = " $ { c o n f . d i r } / h i b e r n a t e / h i b e r n a t e . c f g . xml " o u t p u t = " $ { s q l . d i r } / $ { db . s c r i p t . schema } " q u i e t = " no " t e x t = " yes " drop= " no " d e l i m i t e r = " ; " / > </ t a r g e t > <! > <! h i b e r n a t e schemaexportf i l e drop : e x p o r t s t h e drop schema t o a f i l e > <! > < t a r g e t name= " h i b e r n a t e schemaexportf i l e drop " depends= " compilejava , h i b e r n a t e i n i t " > <schemaexport c o n f i g = " $ { c o n f . d i r } / h i b e r n a t e / h i b e r n a t e . c f g . xml " o u t p u t = " $ { s q l . d i r } / $ { db . s c r i p t . drop } " q u i e t = " no " t e x t = " yes " drop= " yes " d e l i m i t e r = " ; " / > </ t a r g e t > <! > <! h i b e r n a t e schemaexportdb : e x p o r t s t h e schema t o t h e db > <! > < t a r g e t name= " h i b e r n a t e schemaexportdb " depends= " compilejava , h i b e r n a t e i n i t " > <schemaexport c o n f i g = " $ { c o n f . d i r } / h i b e r n a t e / h i b e r n a t e . c f g . xml " q u i e t = " no " t e x t = " no " drop= " no " d e l i m i t e r = " ; " / > </ t a r g e t > <! > <! h i b e r n a t e schemaexportdbdrop : drops t h e schema o f t h e db > <! > < t a r g e t name= " h i b e r n a t e schemaexportdbdrop " depends= " compilejava , h i b e r n a t e i n i t " > <schemaexport c o n f i g = " $ { c o n f . d i r } / h i b e r n a t e / h i b e r n a t e . c f g . xml " q u i e t = " no " t e x t = " no " drop= " yes " d e l i m i t e r = " ; " / > </ t a r g e t > <! > <! h i b e r n a t e schemaupdatedb : updates t h e schema o f t h e db > <! > < t a r g e t name= " h i b e r n a t e schemaupdatedb " depends= " compilejava , h i b e r n a t e i n i t " > <schemaupdate c o n f i g = " $ { c o n f . d i r } / h i b e r n a t e / h i b e r n a t e . c f g . xml " q u i e t = " no " t e x t = " no " / > </ t a r g e t >

26 28 30

32 34 36 38

40 42 44

46 48 50 52

54 56 58 60

Listing B.3: Ant Build File (Part 3/4): build.xml

83

2 4 6 8 10 12 14 16 18 20 22

<! =================================================================== > <! b u i l d > <! =================================================================== > <! > <! compile : compiles t h e source > <! > < t a r g e t name= " cleanjavab u i l d " > <delete d i r ="$ { java . b u i l d . d i r } " / > <mkdir d i r = " $ { j a v a . b u i l d . d i r } " / > </ t a r g e t > < t a r g e t name= " resourcesj a v a " > <copy t o d i r = " $ { j a v a . b u i l d . d i r } " > < f i l e s e t d i r ="$ { java . src . d i r } "> <exclude name= " / . j a v a " / > <exclude name= " / . c l a s s " / > </ f i l e s e t > </ copy > </ t a r g e t > < t a r g e t name= " compilej a v a " depends= " cleanjavab u i l d , resourcesj a v a " > <javac s r c d i r ="$ { java . src . d i r } " d e s t d i r =" $ { java . b u i l d . d i r } " classpathref =" p r o j e c t . c l a s s p a t h " debug= " on " d e p r e c a t i o n = " on " o p t i m i z e = " o f f " / > </ t a r g e t >

24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64 66 68 70

<! > <! b u i l d har : c r e a t e s t h e h i b e r n a t e har a r c h i v e > <! > < t a r g e t name= " b u i l d har " > < j a r j a r f i l e = " $ { b u i l d . d i r } / $ { p r o j e c t . name . f i l e }hb . har " > <! c l a s s e s > < f i l e s e t d i r ="$ { java . b u i l d . d i r } "> < i n c l u d e name= " / h i b e r n a t e / / . " / > </ f i l e s e t > <! c o n f > <metainf d i r =" $ { conf . d i r } / hibernate " > < i n c l u d e name= " jbosss e r v i c e . xml " / > </ m e t a i n f > <! bundled l i b r a r i e s > <manifest > < a t t r i b u t e name= " ClassPath " v a l u e = " commonsb e a n u t i l s . j a r oscache . j a r " / > </ m a n i f e s t > <! s e r v e r l i b r a r i e s i n j b o s s / s e r v e r / d e f a u l t / l i b > <! h i b e r n a t e j a r s > </ j a r > </ t a r g e t > <! > <! b u i l d e j b : c r e a t e s t h e e j b j a r a r c h i v e > <! > < t a r g e t name= " b u i l d e j b " > < j a r j a r f i l e = " $ { b u i l d . d i r } / $ { p r o j e c t . name . f i l e } e j b . j a r " > <! c l a s s e s > < f i l e s e t d i r ="$ { java . b u i l d . d i r } "> < i n c l u d e name= " / e j b / / . c l a s s " / > </ f i l e s e t > <! c o n f > <metainf d i r =" $ { conf . d i r } / ejb " > < i n c l u d e name= " . " / > </ m e t a i n f > <! c l i e n t > <manifest > < a t t r i b u t e name= " ClassPath " v a l u e = " $ { p r o j e c t . name . f i l e } c l i e n t . j a r " / > </ m a n i f e s t > <! s e r v e r l i b r a r i e s i n j b o s s / s e r v e r / d e f a u l t / l i b > <! h i b e r n a t e j a r s > <! l o g 4 j j a r s and c o n f > </ j a r > </ t a r g e t > </ p r o j e c t >

Listing B.4: Ant Build File (Part 4/4): build.xml

C
Struts

84

85
/ S t r u t s form h o l d i n g p r o d u c t i n p u t . @struts . form name = " ProductForm " validate = " true " / p u b l i c c l a s s ProductForm extends AAdminValidatorForm { / Fields / p r i v a t e Long p r o d u c t I d ; p r i v a t e S t r i n g productName ; p r i v a t e Map p r o d u c t C a t e g o r i e s ; / Creates a new i n s t a n c e . / p u b l i c ProductForm ( ) { super ( ) ; t h i s . p r o d u c t C a t e g o r i e s = new TreeMap ( ) ; } / V a l i d a t e s t h e form . @param mapping The a c t i o n mapping . @param r e q u e s t The h t t p r e q u e s t . @return The a c t i o n e r r o r s . / p u b l i c A c t i o n E r r o r s v a l i d a t e ( ActionMapping mapping , HttpServletRequest request ) { A c t i o n E r r o r s e r r o r s = new A c t i o n E r r o r s ( ) ; e r r o r s . add ( super . v a l i d a t e ( mapping , r e q u e s t ) ) ; return errors ; } / Resets t h e form . @param mapping The a c t i o n mapping . @param r e q u e s t The h t t p r e q u e s t . / p u b l i c v o i d r e s e t ( ActionMapping mapping , H t t p S e r v l e t R e q u e s t r e q u e s t ) { super . r e s e t ( mapping , r e q u e s t ) ; } / I n i t i a l i z e s t h e form . @param p r o d u c t The p r o d u c t bean . @exception S t r u t s E x c e p t i o n / p u b l i c v o i d setForm ( Product p r o d u c t ) throws S t r u t s E x c e p t i o n { t h i s . set ( product ) ; t h i s . p r o d u c t C a t e g o r i e s = super . generateCategoriesMap ( p r o d u c t . g e t C a t e g o r i e s ( ) ) ; } / I n i t i a l i z e s a b l a n k form . @param su pp or ted Lo ca les The su pp o r t e d L o c a le s . @param productType The p r o d u c t t y p e bean . @exception S t r u t s E x c e p t i o n @exception BeanToolsException / p u b l i c v o i d setBlankForm ( ProductType productType , C o l l e c t i o n s u p p o rt e d L o c a l e s ) throws S t r u t s E x c e p t i o n , BeanToolsException { t h i s . s e t ( productType ) ; } / Populates t h e bean . @param p r o d u c t The bean . @throws BeanToolsException @exception IOException / p u b l i c v o i d populateBean ( Product p r o d u c t ) throws BeanToolsException , IOException { product . set ( t h i s ) ; product . setCategories ( t h i s . getProductCategories ( ) ) ; }

2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56

58 60 62 64 66 68 70

Listing C.1: Struts Form (Part 1/2): ProductForm.java

86

2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54

/ Gets t h e p r o d u c t I d . @return Returns t h e p r o d u c t I d . / p u b l i c Long g e t P r o d u c t I d ( ) { return t h i s . productId ; } / Sets t h e p r o d u c t I d . @param p r o d u c t I d The p r o d u c t I d t o s e t . / p u b l i c v o i d s e t P r o d u c t I d ( Long p r o d u c t I d ) { t h i s . productId = productId ; } / Gets t h e productName . @return Returns t h e productName . / p u b l i c S t r i n g getProductName ( ) { r e t u r n t h i s . productName ; } / Sets t h e productName . @param productName The productName t o s e t . @struts . v a l i d a t o r t y p e =" r e q u i r e d " msgvalue = " p r o d u c t name i s r e q u i r e d " / p u b l i c v o i d setProductName ( S t r i n g productName ) { t h i s . productName = productName ; } / Adds t h e p r o d u c t t o t h e c a t e g o r y . @param c a t e g o r y The bean . / p u b l i c v o i d addCategory ( Category c a t e g o r y ) { i f ( ! t h i s . p r o d u c t C a t e g o r i e s . containsKey ( c a t e g o r y . g e t C a t e g o r y I d ( ) ) ) { t h i s . productCategories . put ( category . getCategoryId ( ) , category ) ; } } / Removes t h e p r o d u c t from t h e c a t e g o r y . @param c a t I d The i d . / p u b l i c v o i d removeCategory ( S t r i n g c a t I d ) { Category c a t e g o r y = ( Category ) t h i s . p r o d u c t C a t e g o r i e s . g e t ( new Long ( c a t I d ) ) ; c a t e g o r y . setRemoveProduct ( t r u e ) ; } / Gets t h e c a t e g o r i e s . @return The c o l l e c t i o n . / public C o l l e c t i o n getProductCategories ( ) { r e t u r n t h i s . productCategories . values ( ) ; } }

Listing C.2: Struts Form (Part 2/2): ProductForm.java

87
/ S t r u t s a c t i o n t o save o r update a p r o d u c t . @struts . a c t i o n path = " / sb / a d m i n i s t r a t o r / productMgmt / saveOrUpdateProduct " t y p e = " ch . u n i f r . r e s . web . s t r u t s . sb . a d m i n i s t r a t o r . productMgmt . a c t i o n . SaveOrUpdateProductAction " name = " ProductForm " i n p u t = " page . sb . a d m i n i s t r a t o r . productMgmt . productForm " scope = " s e s s i o n " validate = " false " @struts . a c t i o n f o r w a r d name=" form " path =" page . sb . a d m i n i s t r a t o r . productMgmt . productForm " @struts . a c t i o n setp r o p e r t y p r o p e r t y =" secure " v a l u e =" f a l s e " / p u b l i c c l a s s SaveOrUpdateProductAction extends ProductManagementAction { / Creates a new i n s t a n c e . / p u b l i c SaveOrUpdateProductAction ( ) { super ( SaveOrUpdateProductAction . c l a s s ) ; } / Executes t h e a c t i o n . @param mapping The a c t i o n mapping . @param form The form . @param r e q u e s t The h t t p r e q u e s t . @param response The h t t p response . @return The a c t i o n f o r w a r d . @exception IOException @exception S e r v l e t E x c e p t i o n / p u b l i c ActionForward execute ( ActionMapping mapping , ActionForm form , H t t p S e r v l e t R e q u e s t request , HttpServletResponse response ) throws IOException , S e r v l e t E x c e p t i o n { super . logDebug ( " execute . . . " ) ; try { // get session H t tp S e ss i o n s e s s i o n = r e q u e s t . getSession ( ) ; / / get i n p u t ProductForm productForm = ( ProductForm ) form ; / / parameter add S t r i n g add= r e q u e s t . getParameter ( S t r u t s C o n s t a n t s .PARAM_ADD) ; i f ( ! super . i s B l a n k ( add ) ) { i f ( add . equalsIgnoreCase ( " c a t e g o r y " ) ) { Long c a t e g o r y I d = productForm . getSelectedAddCategoryId ( ) ; Category c a t e g o r y = super . g e t S e s s i o n C o l l e c t i o n C a t e g o r y ( request , c a t e g o r y I d ); productForm . addCategory ( c a t e g o r y ) ; s e s s i o n . s e t A t t r i b u t e ( S t r u t s C o n s t a n t s .FORM_PRODUCT, productForm ) ; super . l o g I n f o ( " Add c a t e g o r y : parameter = " + add + " , i d = " + c a t e g o r y I d ) ; r e q u e s t . s e t A t t r i b u t e ( S t r u t s C o n s t a n t s .PARAM_HASH, " # c a t e g o r i e s " ) ; r e t u r n ( mapping . f i n d F o r w a r d ( " form " ) ) ; } } / / parameter remove c a t e g o r y S t r i n g remCat = r e q u e s t . getParameter ( S t r u t s C o n s t a n t s .PARAM_REMOVECATEGORY) ; i f ( ! super . i s B l a n k ( remCat ) ) { productForm . removeCategory ( remCat ) ; s e s s i o n . s e t A t t r i b u t e ( S t r u t s C o n s t a n t s .FORM_PRODUCT, productForm ) ; super . l o g I n f o ( " Remove c a t e g o r y : parameter = " + remCat ) ; r e q u e s t . s e t A t t r i b u t e ( S t r u t s C o n s t a n t s .PARAM_HASH, " # c a t e g o r i e s " ) ; r e t u r n ( mapping . f i n d F o r w a r d ( " form " ) ) ; }

2 4

6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52

54 56

58 60 62 64 66 68 70

Listing C.3: Struts Action (Part 1/2): SaveOrUpdateProductAction.java

88

2 4 6 8 10 12 14 16 18 20 22 24

/ / action S t r i n g actionParam = r e q u e s t . getParameter ( S t r u t s C o n s t a n t s . PARAM_ACTION) ; i f ( ! super . i s B l a n k ( actionParam ) ) { / / save i f ( actionParam . equalsIgnoreCase ( S t r u t s C o n s t a n t s . PARAM_ACTION_SAVE) ) { // validate ActionMessages e r r o r s = productForm . v a l i d a t e ( mapping , r e q u e s t ) ; i f ( ! e r r o r s . isEmpty ( ) ) { t h i s . s a v e E r r o r s ( request , e r r o r s ) ; r e t u r n ( new ActionForward ( mapping . g e t I n p u t ( ) ) ) ; } // bean Product p r o d u c t = new Product ( ) ; productForm . populateBean ( p r o d u c t ) ; / / update on db IProductMgmtDelegate productMgmtDelegate = new ProductMgmtDelegate ( ) ; Long p r o d I d = productMgmtDelegate . saveOrUpdateProduct ( p r o d u c t ) ; super . l o g I n f o ( " Product updated : prod i d = " + p r o d I d ) ; } // cancel e l s e i f ( actionParam . equalsIgnoreCase ( S t r u t s C o n s t a n t s . PARAM_ACTION_CANCEL) ) { super . l o g I n f o ( " Cancel a c t i o n . " ) ; } }

26 28 30 32

/ / success r e t u r n super . execute ( mapping , form , request , response ) ; } c a t c h ( De le gat eE xce pt ion e ) { super . logWarn ( " Del eg ate Ex ce p t i o n : " + e . getMessage ( ) ) ; r e t u r n super . h a n d l e S t o r e b a c k E r r o r B 2 I ( request , mapping , e , product " ) ; } c a t c h ( BeanToolsException e ) { super . logWarn ( " BeanToolsException : " + e . getMessage ( ) ) ; r e t u r n super . h a n d l e S t o r e b a c k E r r o r B 2 I ( request , mapping , e , product " ) ; } catch ( StrutsException e ) { super . logWarn ( " S t r u t s E x c e p t i o n : " + e . getMessage ( ) ) ; r e t u r n super . h a n d l e S t o r e b a c k E r r o r B 2 I ( request , mapping , e , product " ) ; } catch ( Exception e ) { super . logWarn ( " E x c e p t io n : " + e . getMessage ( ) ) ; r e t u r n super . h a n d l e S t o r e b a c k E r r o r B 2 I ( request , mapping , e , product " ) ; } } }

" e r r o r saving the

34

" e r r o r saving the

36 38

" e r r o r saving the

40

" e r r o r saving the

42 44

Listing C.4: Struts Action (Part 2/2): SaveOrUpdateProductAction.java

89

<?xml v e r s i o n = " 1 . 0 " encoding= "UTF8" ?> <!DOCTYPE s t r u t s c o n f i g PUBLIC " // Apache Software Foundation / / DTD S t r u t s C o n f i g u r a t i o n 1 . 2 / / EN" " h t t p : / / j a k a r t a . apache . org / s t r u t s / d t d s / s t r u t s c o n f i g _ 1 _ 2 . d t d " > < s t r u t s c o n f i g > <! ========== Form Bean D e f i n i t i o n s =================================== > <formbeans> <formbean name= " ProductForm " t y p e = " ch . u n i f r . r e s . web . s t r u t s . sb . a d m i n i s t r a t o r . productMgmt . form . ProductForm " /> </ formbeans> <! ========== A c t i o n Mapping D e f i n i t i o n s =================================== > < a c t i o n mappings t y p e = " org . apache . s t r u t s . c o n f i g . S e c u r e A c t i o n C o n f i g " > <action path= " / sb / a d m i n i s t r a t o r / productMgmt / saveOrUpdateProduct " t y p e = " ch . u n i f r . r e s . web . s t r u t s . sb . a d m i n i s t r a t o r . productMgmt . a c t i o n . SaveOrUpdateProductAction " name= " ProductForm " scope= " s e s s i o n " i n p u t = " page . sb . a d m i n i s t r a t o r . productMgmt . productForm " unknown= " f a l s e " validate=" false " > <setp r o p e r t y p r o p e r t y = " secure " value=" f a l s e " /> <forward name= " form " path= " page . sb . a d m i n i s t r a t o r . productMgmt . productForm " redirect =" false " /> <forward name= " success " path= " page . sb . a d m i n i s t r a t o r . productMgmt . productManagement " redirect =" false " /> <forward name= " a p p l i c a t i o n e r r o r " path= " page . e r r o r . a p p l i c a t i o n e r r o r " redirect =" false " /> </ a c t i o n > </ a c t i o n mappings >

4 6 8 10 12 14 16 18

20 22 24 26 28 30 32 34 36 38 40 42 44

Listing C.5: Struts Core Conguration (Part 1/2): struts-cong.xml

90

1 3 5 7 9 11 13 15 17 19 21 23

<! ========== G l o b a l Forward D e f i n i t i o n s =================================== > < g l o b a l forwards > <forward name= " sba d m i n i s t r a t o r productMgmtproductManagement " path= " / sb / a d m i n i s t r a t o r / productMgmt / productManagement . do " / > </ g l o b a l forwards > <! ========== C o n t r o l l e r D e f i n i t i o n ========================================== > < c o n t r o l l e r p r oc e ss o rC l as s = " org . apache . s t r u t s . a c t i o n . SecureTilesRequestProcessor " / > <! ========== Message Resources D e f i n i t i o n =================================== > <messager e s o u r c e s f a c t o r y = " ch . u n i f r . r e s . web . s t r u t s . messages . ResMessageResourcesFactory " parameter= " . " /> <! ========== P l u g i n D e f i n i t i o n s =================================== > <plugi n className= " org . apache . s t r u t s . t i l e s . S e c u r e T i l e s P l u g i n " > <setp r o p e r t y p r o p e r t y = " d e f i n i t i o n s c o n f i g " v a l u e = " /WEB INF / c o n f / t i l e s d e f s . xml " / > </ plugi n > <plugi n className= " org . apache . s t r u t s . v a l i d a t o r . V a l i d a t o r P l u g I n " > <setp r o p e r t y p r o p e r t y = " pathnames " v a l u e = " /WEB INF / c o n f / v a l i d a t o r r u l e s . xml , / WEB INF / c o n f / v a l i d a t i o n . xml " / > </ plugi n > <plugi n className= " org . apache . s t r u t s . a c t i o n . SecurePlugIn " > <setp r o p e r t y p r o p e r t y = " h t t p P o r t " v a l u e = " 80 " / > <setp r o p e r t y p r o p e r t y = " h t t p s P o r t " v a l u e = " 443 " / > <setp r o p e r t y p r o p e r t y = " enable " v a l u e = " t r u e " / > <setp r o p e r t y p r o p e r t y = " addSession " v a l u e = " t r u e " / > </ plugi n > </ s t r u t s c o n f i g >

25 27 29 31

Listing C.6: Struts Core Conguration (Part 2/2): struts-cong.xml

1 3 5

<?xml v e r s i o n = " 1 . 0 " encoding= " ISO88591" ?> <!DOCTYPE t i l e s d e f i n i t i o n s PUBLIC " // Apache Software Foundation / / DTD T i l e s C o n f i g u r a t i o n 1 . 1 / / EN" " h t t p : / / j a k a r t a . apache . org / s t r u t s / d t d s / t i l e s c o n f i g _ 1 _ 1 . d t d " > < t i l e s d e f i n i t i o n s >

7 9 11 13 15 17 19

<! g l o b a l l a y o u t > < d e f i n i t i o n name= " l a y o u t . s i m p l e " path= " / l a y o u t / s i m p l e . j s p " > < p u t name= " n a v i g a t i o n main " v a l u e = " $ { n a v i g a t i o n main } " / > < p u t name= " c o n t e n t " v a l u e = " $ { c o n t e n t } " / > </ d e f i n i t i o n > <! l a y o u t a d m i n i s t r a t o r > < d e f i n i t i o n name= " l a y o u t . s i m p l e . sb . a d m i n i s t r a t o r " extends= " l a y o u t . s i m p l e " > < p u t name= " n a v i g a t i o n main " v a l u e = " / t i l e s / n a v i g a t i o n _ a d m i n i s t r a t o r . j s p " / > </ d e f i n i t i o n > <! l a y o u t p r o d u c t mgmt> < d e f i n i t i o n name= " page . sb . a d m i n i s t r a t o r . productMgmt . productManagement " extends= " l a y o u t . s i m p l e . sb . a d m i n i s t r a t o r " > < p u t name= " c o n t e n t " v a l u e = " / pages / sb / a d m i n i s t r a t o r / productMgmt / productManagement . j s p " / > </ d e f i n i t i o n > < d e f i n i t i o n name= " page . sb . a d m i n i s t r a t o r . productMgmt . productForm " extends= " l a y o u t . s i m p l e . sb . a d m i n i s t r a t o r " > < p u t name= " c o n t e n t " v a l u e = " / pages / sb / a d m i n i s t r a t o r / productMgmt / productForm . j s p " / > </ d e f i n i t i o n > </ t i l e s d e f i n i t i o n s >

21 23

25 27

Listing C.7: Struts Tiles Denitions: tiles-defs.xml

91

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31

<!DOCTYPE formv a l i d a t i o n PUBLIC " // Apache Software Foundation / / DTD Commons V a l i d a t o r Rules C o n f i g u r a t i o n 1 . 1 . 3 / / EN" " h t t p : / / j a k a r t a . apache . org / commons / d t d s / v a l i d a t o r _ 1 _ 1 _ 3 . d t d " > <formv a l i d a t i o n > <global > < v a l i d a t o r name= " r e q u i r e d " classname= " org . apache . s t r u t s . v a l i d a t o r . FieldChecks " method= " v a l i d a t e R e q u i r e d " methodParams= " j a v a . l a n g . Object , org . apache . commons . v a l i d a t o r . V a l i d a t o r A c t i o n , org . apache . commons . v a l i d a t o r . F i e l d , org . apache . s t r u t s . a c t i o n . ActionMessages , org . apache . commons . v a l i d a t o r . V a l i d a t o r , javax . s e r v l e t . h t t p . HttpServletRequest " msg= " e r r o r s . r e q u i r e d " / > < v a l i d a t o r name= " e m a i l " classname= " org . apache . s t r u t s . v a l i d a t o r . FieldChecks " method= " v a l i d a t e E m a i l " methodParams= " j a v a . l a n g . Object , org . apache . commons . v a l i d a t o r . V a l i d a t o r A c t i o n , org . apache . commons . v a l i d a t o r . F i e l d , org . apache . s t r u t s . a c t i o n . ActionMessages , org . apache . commons . v a l i d a t o r . V a l i d a t o r , javax . s e r v l e t . h t t p . HttpServletRequest " depends= " " msg= " e r r o r s . e m a i l " / > </ g l o b a l > </ formv a l i d a t i o n >

Listing C.8: Struts Validator Rules: validator-rules.xml

<?xml v e r s i o n = " 1 . 0 " encoding= "UTF8" ?> <!DOCTYPE formv a l i d a t i o n PUBLIC " // Apache Software Foundation / / DTD Commons V a l i d a t o r Rules C o n f i g u r a t i o n 1 . 1 . 3 / / EN" " h t t p : / / j a k a r t a . apache . org / commons / d t d s / v a l i d a t o r _ 1 _ 1 _ 3 . d t d " > <formv a l i d a t i o n > < formset > <form name= " ProductForm " > < f i e l d p r o p e r t y = " productName " depends= " r e q u i r e d " > <msg name= " r e q u i r e d " key= " p r o d u c t name i s r e q u i r e d " resource=" f a l s e " / > <arg0 key= " ProductForm . productName " / > </ f i e l d > </ form > </ formset > </ formv a l i d a t i o n >

4 6 8 10 12 14 16 18

Listing C.9: Struts Validator Validation: validation.xml

D
EJB

92

93

1 3 5 7 9 11 13 15 17

/ Delegate f o r t h e ProductMgmt use case . / p u b l i c c l a s s ProductMgmtDelegate extends ABaseDelegate implements IProductMgmtDelegate { / Fields / p r i v a t e ProductMgmtSessionLocal productMgmtSession ; / Creates a new i n s t a n c e . @exception De le gat eE xce pt ion / p u b l i c ProductMgmtDelegate ( ) throws D e l e g a t e E x c e p t i o n { super ( ProductMgmtDelegate . c l a s s ) ; try { / / i n i t s e s s i o n bean ProductMgmtSessionLocalHome home = ( ProductMgmtSessionLocalHome ) S e r v i c e L o c a t o r . g e t I n s t a n c e ( ) . getLocalHome ( " ProductMgmtSessionLocal " ) ; t h i s . productMgmtSession = home . c r e a t e ( ) ; } catch ( ServiceLocatorException e ) { throw new De le gat eE xce pt ion ( e ) ; } c a t c h ( C re at eE xc ep ti on e ) { throw new De le gat eE xce pt ion ( e ) ; } } / Saves o r updates a p r o d u c t . @param p r o d u c t The p r o d u c t bean . @return The p r o d u c t i d . @throws De le gat eE xce pt ion / p u b l i c Long saveOrUpdateProduct ( Product p r o d u c t ) throws D e l e g a t e E x c e p t i o n { super . logDebug ( " saveOrUpdateProduct . . . " ) ; try { r e t u r n t h i s . productMgmtSession . saveOrUpdateProduct ( p r o d u c t ) ; } c a t c h ( EJBException e ) { throw new De le gat eE xce pt ion ( e ) ; } } }

19 21 23 25 27 29 31 33 35 37 39 41

Listing D.1: Business Delegate: ProductMgmtDelegate.java

1 3 5 7 9 11

/ I n t e r f a c e f o r t h e ProductMgmt d e l e g a t e . / p u b l i c i n t e r f a c e IProductMgmtDelegate { / Saves o r updates a p r o d u c t . @param p r o d u c t The p r o d u c t bean . @return The p r o d u c t i d . @throws De le gat eE xce pt ion / p u b l i c a b s t r a c t Long saveOrUpdateProduct ( Product p r o d u c t ) throws D e l e g a t e E x c e p t i o n ; }

Listing D.2: Business Delegate Interface: IProductMgmtDelegate.java

94
/ SessionBean f o r t h e ProductMgmt use case . @ejb . bean name=" ProductMgmtSession " d i s p l a y name=" ProductMgmtSession " d e s c r i p t i o n =" SessionBean f o r t h e ProductMgmt use case " j n d i name=" e j b / ProductMgmtSession " t y p e =" S t a t e l e s s " viewt y p e =" l o c a l " @ejb . home l o c a l c l a s s = " ch . u n i f r . r e s . e j b . ProductMgmtSessionLocalHome " l o c a l extends = " j a v a x . e j b . EJBLocalHome " @ejb . i n t e r f a c e l o c a l c l a s s = " ch . u n i f r . r e s . e j b . ProductMgmtSessionLocal " l o c a l extends = " j a v a x . e j b . EJBLocalObject " @ejb . t r a n s a c t i o n t y p e = " Required " / p u b l i c c l a s s ProductMgmtSessionBean extends SessionBeanAdaptor { S es si o nF a ct or y hbSessionFactory ; / Creates a new i n s t a n c e . / p u b l i c ProductMgmtSessionBean ( ) { super ( ProductMgmtSessionBean . c l a s s ) ; } / D e f a u l t c r e a t e method . @throws Cr e at eE xc ep ti on @ejb . c r e a t emethod @ejb . p e r m i s s i o n unchecked = " t r u e " / p u b l i c v o i d e j b C r e a t e ( ) throws C re a t e E x c e p t i o n { try { / / i n i t hibernate session t h i s . hbSessionFactory = ( S e s s i o n F a c t o r y ) S e r v i c e L o c a t o r . g e t I n s t a n c e ( ) . getJndiResource ( " j a v a : h i b e r n a t e / RESSessionFactory " ) ; } catch ( ServiceLocatorException e ) { throw new Cr ea t eE xc ep ti on ( e . getMessage ( ) ) ; } } / Business method t o save o r update a p r o d u c t . @param p r o d u c t The p r o d u c t bean . @return The p r o d u c t i d . @exception j a v a x . e j b . EJBException @ejb . i n t e r f a c e method viewt y p e = " l o c a l " @ejb . p e r m i s s i o n r o l e name = " A d m i n i s t r a t o r " / p u b l i c Long saveOrUpdateProduct ( Product p r o d u c t ) throws EJBException { super . logDebug ( " saveOrUpdateProduct . . . " ) ; Long p r o d u c t I d = n u l l ; try { / / get c u r r e n t hibernate session Session hsession = t h i s . hbSessionFactory . g e t C u r r e n t S e s s i o n ( ) ; / / create product ProductHB productHB = new ProductHB ( ) ; productHB . s e t ( p r o d u c t ) ; / / add t o c a t e g o r i e s C o l l e c t i o n categories = product . getCategories ( ) ; i f ( categories != n u l l ) { I t e r a t o r i t e r a t o r = categories . i t e r a t o r ( ) ; w h i l e ( i t e r a t o r . hasNext ( ) ) { Category c a t e g o r y = ( Category ) i t e r a t o r . n e x t ( ) ; CategoryHB categoryHB = ( CategoryHB ) hsession . l o a d ( CategoryHB . c l a s s , category . getCategoryId ( ) ) ; productHB . set Ass oci a t i o n C a t e g o r y H B ( categoryHB ) ; } } / / save hsession . saveOrUpdate ( productHB ) ; p r o d u c t I d = productHB . g e t P r o d u c t I d ( ) ; } catch ( HibernateException e ) { throw new EJBException ( e ) ; } return productId ; } }

2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36

38 40 42 44 46 48 50 52 54 56 58 60 62 64

66 68 70 72 74 76

Listing D.3: EJB Session Bean: ProductMgmtSessionBean.java

95

<?xml v e r s i o n = " 1 . 0 " encoding= "UTF8" ?> <ejbj a r xmlns= " h t t p : / / j a v a . sun . com / xml / ns / j 2 e e " xmlns : x s i = " h t t p : / / www. w3 . org / 2 0 0 1 /XMLSchema i n s t a n c e " x s i : schemaLocation= " h t t p : / / j a v a . sun . com / xml / ns / j 2 e e h t t p : / / j a v a . sun . com / xml / ns / j 2 e e / ejbj a r _ 2 _ 1 . xsd " v e r s i o n = " 2 . 1 " > < d e s c r i p t i o n > < ! [CDATA[ No D e s c r i p t i o n . ] ] > < / d e s c r i p t i o n > < d i s p l a y name>Generated by XDoclet < / d i s p l a y name> < e n t e r p r i s e beans> <session > < d e s c r i p t i o n > < ! [CDATA[ SessionBean f o r t h e ProductMgmt use case ] ] > < / d e s c r i p t i o n > < d i s p l a y name>ProductMgmtSession < / d i s p l a y name> <ejbname>ProductMgmtSession < / ejbname> < l o c a l home>ch . u n i f r . r e s . e j b . ProductMgmtSessionLocalHome < / l o c a l home> < l o c a l >ch . u n i f r . r e s . e j b . ProductMgmtSessionLocal < / l o c a l > <ejbc l a s s >ch . u n i f r . r e s . e j b . ProductMgmtSessionBean < / ejbc l a s s > <sessiontype > S t a t e l e s s < / sessiontype > < t r a n s a c t i o n type > Container < / t r a n s a c t i o n type > </ session > </ e n t e r p r i s e beans> <assemblyd e s c r i p t o r >

4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48

< s e c u r i t y r o l e > < d e s c r i p t i o n > < ! [CDATA[ d e s c r i p t i o n n o t supported y e t by e j b d o c l e t ] ] > < / d e s c r i p t i o n > < r o l e name> A d m i n i s t r a t o r < / r o l e name> </ s e c u r i t y r o l e > <methodp e r m i s s i o n > < d e s c r i p t i o n > < ! [CDATA[ d e s c r i p t i o n n o t supported y e t by e j b d o c l e t ] ] > < / d e s c r i p t i o n > < r o l e name> A d m i n i s t r a t o r < / r o l e name> <method > < d e s c r i p t i o n > < ! [CDATA[ Business method t o save o r update a p r o d u c t . ] ] > < / d e s c r i p t i o n > <ejbname>ProductMgmtSession < / ejbname> <methodi n t f >Local < / methodi n t f > <methodname>saveOrUpdateProduct < / methodname> <methodparams> <methodparam>ch . u n i f r . r e s . bean . p r o d u c t . Product < / methodparam> </ methodparams> </ method> </ methodpermission > < c o n t a i n e r t r a n s a c t i o n > <method > <ejbname>ProductMgmtSession < / ejbname> <methodname> </ methodname> </ method> < t r a n s a t t r i b u t e >Required < / t r a n s a t t r i b u t e > </ c o n t a i n e r t r a n s a c t i o n > </ assemblyd e s c r i p t o r > </ ejbj a r >

Listing D.4: EJB Deployment Descriptor: ejb-jar.xml

96

<?xml v e r s i o n = " 1 . 0 " encoding= "UTF8" ?> <!DOCTYPE j b o s s PUBLIC " // JBoss / / DTD JBOSS 4 . 0 / / EN" " h t t p : / / www. j b o s s . org / j 2 e e / d t d / jboss_4_0 . dtd " > <jboss > < s e c u r i t y domain> j a v a : / j a a s / appres < / s e c u r i t y domain> < e n t e r p r i s e beans> <session > <ejbname>ProductMgmtSession < / ejbname> < l o c a l j n d i name>ProductMgmtSessionLocal < / l o c a l j n d i name> <methoda t t r i b u t e s > </ methoda t t r i b u t e s > </ session > </ e n t e r p r i s e beans> </ jboss >

3 5 7 9 11 13

Listing D.5: JBoss Deployment Descriptor: jboss.xml

E
Hibernate

97

98
/ H i b e r n a t e bean f o r t h e p r o d u c t data . @hibernate . c l a s s t a b l e = " p r o d u c t " @hibernate . cache usage = " n o n s t r i c t readw r i t e " / p u b l i c c l a s s ProductHB extends ABaseHB { / Fields / p r i v a t e Long p r o d u c t I d ; p r i v a t e Set categoryHBs ; p r i v a t e S t r i n g productName ; / Creates a new i n s t a n c e . / p u b l i c ProductHB ( ) { super ( ) ; t h i s . categoryHBs = new HashSet ( ) ; } / Gets t h e p r o d u c t I d . @return Returns t h e p r o d u c t I d . @hibernate . i d t y p e = " l o n g " column = " p r o d u c t I d " g e n e r a t o rc l a s s = " i n c r e m e n t " / p u b l i c Long g e t P r o d u c t I d ( ) { return t h i s . productId ; } / Sets t h e p r o d u c t I d . @param p r o d u c t I d The p r o d u c t I d t o s e t . / p u b l i c v o i d s e t P r o d u c t I d ( Long p r o d u c t I d ) { t h i s . productId = productId ; } / Gets t h e productName . @return Returns t h e productName . @hibernate . p r o p e r t y t y p e = " s t r i n g " column = " productName " / p u b l i c S t r i n g getProductName ( ) { r e t u r n t h i s . productName ; } / Sets t h e productName . @param productName The productName t o s e t . / p u b l i c v o i d setProductName ( S t r i n g productName ) { t h i s . productName = productName ; } / Gets t h e categoryHBs . @return Returns t h e categoryHBs . @hibernate . s e t name= " categoryHBs " t a b l e = " p r o d u c t _ c a t e g o r y " cascade = " none " @hibernate . c o l l e c t i o n cache usage = " n o n s t r i c t readw r i t e " @hibernate . c o l l e c t i o n key column = " p r o d u c t I d " @hibernate . c o l l e c t i o n manytomany c l a s s = " ch . u n i f r . r e s . h i b e r n a t e . p r o d u c t . CategoryHB " column = " c a t e g o r y I d " / p u b l i c Set getCategoryHBs ( ) { r e t u r n t h i s . categoryHBs ; } / Sets t h e categoryHBs . @param categoryHBs The categoryHBs t o s e t . / p u b l i c v o i d setCategoryHBs ( Set categoryHBs ) { t h i s . categoryHBs = categoryHBs ; } }

2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58

60 62 64 66 68 70

Listing E.1: Hibernate Bean: ProductHB.java

99

<?xml v e r s i o n = " 1 . 0 " encoding= "UTF8" ?>

2 4 6 8 10 12 14 16 18 20 22 24 26

<!DOCTYPE h i b e r n a t e mapping PUBLIC " // H i b e r n a t e / H i b e r n a t e Mapping DTD 3 . 0 / / EN" " h t t p : / / h i b e r n a t e . s o u r c e f o r g e . n e t / h i b e r n a t e mapping 3.0. d t d " > < h i b e r n a t e mapping> < c l a s s name= " ch . u n i f r . r e s . h i b e r n a t e . p r o d u c t . ProductHB " table =" product "> <cache usage= " n o n s t r i c t readw r i t e " / > <id name= " p r o d u c t I d " column= " p r o d u c t I d " type=" long " > <generator class=" increment " / > </ g e n e r a t o r > </ i d > <property name= " productName " type=" s t r i n g " update= " t r u e " insert =" true " column= " productName " / > <set

28 30 32 34 36 38 40

name= " categoryHBs " table =" product_category " lazy=" false " cascade= " none " s o r t =" unsorted " > <cache usage= " n o n s t r i c t readw r i t e " / > <key column= " p r o d u c t I d " > </ key > <manytomany c l a s s = " ch . u n i f r . r e s . h i b e r n a t e . p r o d u c t . CategoryHB " column= " c a t e g o r y I d " o u t e rj o i n = " auto " / > </ set > </ c l a s s > </ h i b e r n a t e mapping>

Listing E.2: Hibernate XML Mapping File: ProductHB.hbm.xml

<?xml v e r s i o n = " 1 . 0 " encoding= "UTF8" ?> <!DOCTYPE h i b e r n a t e c o n f i g u r a t i o n PUBLIC " // H i b e r n a t e / H i b e r n a t e C o n f i g u r a t i o n DTD 3 . 0 / / EN" " h t t p : / / h i b e r n a t e . s o u r c e f o r g e . n e t / h i b e r n a t e c o n f i g u r a t i o n 3.0. d t d " > < h i b e r n a t e c o n f i g u r a t i o n > <! a Se ss i on F ac to r y i n s t a n c e l i s t e d as / j n d i / name > <sessionf a c t o r y > <! p r o p e r t i e s > < p r o p e r t y name= " d i a l e c t " >org . h i b e r n a t e . d i a l e c t . MySQLDialect < / p r o p e r t y > < p r o p e r t y name= " show_sql " > f a l s e < / p r o p e r t y > < p r o p e r t y name= " u s e _ o u t e r _ j o i n " > f a l s e < / p r o p e r t y > < p r o p e r t y name= " c o n n e c t i o n . username " >res < / p r o p e r t y > < p r o p e r t y name= " c o n n e c t i o n . password " >res123 < / p r o p e r t y > < p r o p e r t y name= " c o n n e c t i o n . d r i v e r _ c l a s s " >com . mysql . j d b c . D r i v e r < / p r o p e r t y > < p r o p e r t y name= " c o n n e c t i o n . u r l " > j d b c : mysql : / / l o c a l h o s t : 3 3 0 6 / res < / p r o p e r t y > < p r o p e r t y name= " c o n n e c t i o n . p o o l _ s i z e " >10 </ p r o p e r t y > <! mapping f i l e s > <mapping r e s o u r c e = " ch / u n i f r / r e s / h i b e r n a t e / p r o d u c t / CategoryHB . hbm . xml " / > <mapping r e s o u r c e = " ch / u n i f r / r e s / h i b e r n a t e / p r o d u c t / ProductHB . hbm . xml " / > </ sessionf a c t o r y > </ h i b e r n a t e c o n f i g u r a t i o n >

3 5 7 9 11 13 15 17 19

Listing E.3: Hibernate Conguration: hibernate.cfg.xml

100

2 4

<?xml v e r s i o n = " 1 . 0 " encoding= "UTF8" ?> <!DOCTYPE s e r v e r > <server > <mbean code= " org . j b o s s . h i b e r n a t e . jmx . H i b e r n a t e " name= " ch . u n i f r . r e s : s e r v i c e = HibernateSessionFactory "> <! Required s e r v i c e s > <depends> j b o s s . j c a : s e r v i c e =RARDeployer < / depends> <! Bind t h e H i b e r n a t e s e r v i c e t o JNDI > < a t t r i b u t e name= " SessionFactoryName " > j a v a : h i b e r n a t e / RESSessionFactory < / a t t r i b u t e > <! Datasource s e t t i n g s > < a t t r i b u t e name= " DatasourceName " > j a v a : j d b c / mysql / res < / a t t r i b u t e > < a t t r i b u t e name= " D i a l e c t " >org . h i b e r n a t e . d i a l e c t . MySQLDialect < / a t t r i b u t e > <! Secondl e v e l caching > < a t t r i b u t e name= " SecondLevelCacheEnabled " > t r u e < / a t t r i b u t e > < a t t r i b u t e name= " CacheProviderClass " >ch . u n i f r . r e s . h i b e r n a t e . OSCacheProvider < / a t t r i b u t e > < a t t r i b u t e name= " QueryCacheEnabled " > t r u e < / a t t r i b u t e > <! Logging > < a t t r i b u t e name= " ShowSqlEnabled " > f a l s e < / a t t r i b u t e > </mbean> </ s e r v e r >

6 8 10 12 14 16 18 20 22 24

Listing E.4: Hibernate MBean: jboss-service.xml

/ / lookup s e s s i o n f a c t o r y S es si o nF a ct or y hbSessionFactory = ( S e s s i o n F a c t o r y ) S e r v i c e L o c a t o r . g e t I n s t a n c e ( ) . getRESSessionFactory ( ) ; / / get c u r r e n t hibernate session Session hsession = t h i s . hbSessionFactory . g e t C u r r e n t S e s s i o n ( ) ; / / save ProductHB newProductHB = new ProductHB ( ) ; newProductHB . setProductName ( "New Product " ) ; newProductHB . s e t P r o d u c t P r i c e ( 1 0 0 . 0 0 ) ; newProductHB . setCategoryHBs ( categoryHBs ) ; Long p r o d u c t I d = hsession . save ( newProductHB ) ; / / load ProductHB e x i s t i n g P r o d u c t H B = hsession . l o a d ( ProductHB . c l a s s , p r o d u c t I d ) ; i n t price = existingProductHB . getProductPrice ( ) ; / / delete ProductHB deleteProductHB = hsession . l o a d ( ProductHB . c l a s s , p r o d u c t I d ) ; hsession . d e l e t e ( deleteProductHB ) ;

4 6 8 10 12 14 16 18 20

Listing E.5: Persisting Objects

F
License of the Documentation
Copyright (c) 2006 Beat Raess. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. The GNU Free Documentation Licence can be read from [GNU05a].

101

G
Website of the Project
A website was created for this project: http://diuf.unifr.ch/softeng/student-projects/completed/raess. On this page you will nd: The binaries and source of the Reseda E-Shop application. The documentation and manuals.

102

H
CD-ROM
On the CD-ROM of the project you will nd: The source code, conguration les and required libraries of the application. Binaries of the Reseda E-Shop application. Additional software used for the project. The binaries and sources of this documentation and the manuals.

103

I
Common Acronyms
APIs Application Programming Interfaces B2A Business-to-Administration B2B Business-to-Business B2C Business-to-Consumer BMP Bean Managed Persistence CMP Container Managed Persistence CRM Customer Relationship Management EAR Enterprise Archive EJB Enterprise JavaBeans ERP Enterprise Resource Planning FAQ Frequently Asked Questions FO Formating Objects GPL GNU Public License GUI Graphical User Interface HAR Hibernate Archive HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol

104

105 HTTPS Hypertext Transfer Protocol Secure IDE Integrated Development Environment IT Information Technology J2EE Java 2 Platform, Enterprise Edition JAAS Java Authentication and Authorization Service JAR Java Archive JDBC Java Database Connectivity JDO Java Data Objects JNDI Java Naming and Directory Interface JSF Java Server Faces JSP Java Server Pages JTA Java Transaction API MVC Model-View-Controller OMG Object Management Group POJO Plain Old Java Object RUP Rational Unied Process SAR Service Archive SSL Secure Sockets Layer or Secure Server Line SQL Standard Query Language TO Transfer Object UI User Interface UML Unied Modeling Language URI Uniform Resource Identier URL Uniform Resource Locator WAR Web Archive XML Extensible Markup Language XP Extreme Programming XSL Extensible Stylesheet Language XSLT Extensible Stylesheet Language Transformations

References

[ACM03] Deepak Alur, John Crupi, and Dan Malks. Core J2EE Patterns: Best Practices and Design Strategies. Prentice Hall, 2nd edition, 2003. [AT02] Scott Ambler and Jewell Tyler. Mastering Enterprise JavaBeans. Wiley Computer Publishing, 2nd edition, 2002.

[Ban02] Philip Bannister. Ten Best Practices of Online Retailing. ecommerce-guide.com, 2002. URL: http://www.ecommerce-guide.com/news/trends/article.php/ 979861 (accessed October 1, 2005). [Bec99] [Bru05] Kent Beck. Extreme Programming Explained: Embrace Change. AddisonWesley, 1999. Dominic Bruegger. Konzeption und Implementation einer multi-tier Anwendung mit J2EE. Masters thesis, University of Fribourg, Switzerland, 2005. URL: http://diuf.unifr.ch/softeng/student-projects/ completed/bruegger/ (accessed October 1, 2005). Alistar Cockburn. Agile Software Development. Addison-Wesley, 2001.

[Coc01]

[Con04] Tim Conrad. PostgreSQL vs. MySQL vs. Commercial Databases: Its All About What You Need. DevX, 2004. URL: http://www.devx.com/dbzone/Article/ 20743 (accessed October 1, 2005). [Des04] Jean-Francois Descloux. Project Management. Lecture Documents, University of Fribourg, Switzerland., 2004.

[Eug00] Jrg Eugster. Fallstudie distrelec ag. eXperience Case Study Database. Faculty of Economics and Business Administration (FEBA) of the University of Applied Sciences, Basel., 2000. URL: http://www.experience-de.fhbb.ch/cases/ experience.nsf/volltext/distrelec (accessed October 1, 2005). [FCF02] Jim Farley, William Crawford, and David Flanagan. Java Enterprise in a Nutshell. A Desktop Quick Reference. OReilly, 2nd edition, 2002. [FMSW04] Daniel Frauchiger, Andreas Meier, Hendrik Stormer, and Nicolas Werro. Zur Entwicklung des Struts-basierten Webshops eSarine. HMD - Praxis der Wirtschaftsinformatik, Jhrg 41, HMD Nr. 238, August 2004. URL: http:

106

References

107 //diuf.unifr.ch/is/research/esarine/publications.php (accessed October 1, 2005).

[Fow02] Martin Fowler. UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison Wesley, 2002. [GHJV02] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley, 2002. [Gil03] Ian Gilllan. PostgreSQL vs MySQL: Which is better? Database Journal, 2003. URL: http://www.databasejournal.com/features/mysql/article. php/3288951 (accessed October 1, 2005).

[GNU05a] GNU. Free Documentation Licence (GNU FDL). Online, 2005. URL: http: //www.gnu.org/licenses/fdl.html (accessed October 1, 2005). [GNU05b] GNU. General Public License (GNU GPL). Online, 2005. URL: http://www. gnu.org/licenses/gpl.html (accessed October 1, 2005). [Hib05] [Hus03] Hibernate. Hibernate Reference Documentation. Hibernate, 2005. URL: http: //www.hibernate.org/5.html (accessed October 1, 2005). Ted Husted. Struts in Action: Building web applications with the leading Java framework. Manning Publications, 4th printed edition, 2003.

[Koc03] Michael Koch. Integrating the Online Shop with the ERP System at Strack AG. eXperience Case Study Database. Faculty of Economics and Business Administration (FEBA) of the University of Applied Sciences, Basel., 2003. URL: http://www.experience-de.fhbb.ch/cases/experience.nsf/ volltext/strack_en (accessed October 1, 2005). [Kru04] Philippe Kruchten. The Rational Unied Process: An Introduction. AddisonWesley, 3rd edition, 2004. [McC05] Craig McClanahan. The Best of Both Worlds: Integrating JSF with Struts in Your J2EE Applications. Oracle Technology Network, 2005. URL: http://www.oracle.com/technology/pub/articles/ masterj2ee/j2ee_wk8.html (accessed October 1, 2005). [Mer02] Michael Merz. E-Commerce und E-Business. Marktmodelle, Anwendungen und Technologien. Dpunkt, 2nd edition, 2002. [MH04] [Oel01] [Pas04] [Res05] Richard Monson-Haefel. Enterprise JavaBeans. OReilly, 4th edition, 2004. William L. Oellermann. Architecting Web Services. Apress, 2001. URL: http: //www.architectingwebservices.com (accessed October 1, 2005). Jacques Pasquier. Advanced Software Engineering. Lecture Documents, University of Fribourg, Switzerland., 2004. Reseda Engineering. Businessplan. Fr Geschftspartner, February 2005.

[Res06a] Reseda Engineering. Reseda E-Shop Manual: Administrator. Technical report, Reseda Engineering, 2006.

References

108

[Res06b] Reseda Engineering. Reseda E-Shop Manual: Features. Technical report, Reseda Engineering, 2006. [Res06c] Reseda Engineering. Reseda E-Shop Manual: Installation Evaluation. Technical report, Reseda Engineering, 2006. [Res06d] Reseda Engineering. Reseda E-Shop Manual: Installation Production. Technical report, Reseda Engineering, 2006. [Res06e] Reseda Engineering. Reseda E-Shop Manual: Manager. Technical report, Reseda Engineering, 2006. [Sch00] Petra Schubert. Otto Fischer AG: E-Shop im Elektrofachhandel. eXperience Case Study Database. Faculty of Economics and Business Administration (FEBA) of the University of Applied Sciences, Basel., 2000. URL: http://www.experience-de.fhbb.ch/cases/experience.nsf/ volltext/otto_fischer (accessed October 1, 2005). Petra Schubert. Electronic Business in the Global Economy, 2005. Lecture Documents, University of Fribourg, Switzerland., 2005.

[Sch05]

[Sun05a] Sun Microsystems. JSR 220: Enterprise JavaBeans, Version 3.0. EJB 3.0 Simplied API. Technical report, Sun Microsystems, 2005. URL: http: //java.sun.com/products/ejb/docs.html (accessed October 1, 2005). [Sun05b] Sun Microsystems. JSR 220: Enterprise JavaBeans, Version 3.0. EJB Core Contracts and Requirements. Technical report, Sun Microsystems, 2005. URL: http://java.sun.com/products/ejb/docs.html (accessed October 1, 2005). [Sun05c] Sun Microsystems. JSR 220: Enterprise JavaBeans, Version 3.0. Java Persistence API. Technical report, Sun Microsystems, 2005. URL: http://java. sun.com/products/ejb/docs.html (accessed October 1, 2005). [Sun05d] Sun Microsystems. The J2EE 1.4 Tutorial Update 5. Sun Microsystems, 2005. URL: http://java.sun.com/j2ee/1.4/docs/ (accessed October 1, 2005). [Sze04] Tadeusz Szewczyk. Suchmaschinen-Optimierung. Phlow: Magazin fr Musik und Netzkultur, 2004. URL: http://www.phlow.net/webtechnik/ suchmaschinenoptimierung.php (accessed October 1, 2005).

[Wik05a] Wikipedia. Electronic business. Online, 2005. URL: http://en.wikipedia. org/wiki/E-business (accessed October 1, 2005). [Wik05b] Wikipedia. Online shop. Online, 2005. URL: http://en.wikipedia.org/ wiki/Online_shop (accessed October 1, 2005). [Wik05c] Wikipedia. Three-tier computing. Online, 2005. URL: http://en.wikipedia. org/wiki/3_tier_architecture (accessed October 1, 2005).

Referenced Web Ressources

[1] Apache Ant, 2006. http://ant.apache.org (accessed April 10, 2006). [2] At-Web, 2006. http://www.at-web.de (accessed April 10, 2006). [3] Berkley DB XML, 2006. http://www.sleepycat.com/products/xml.shtml (accessed April 10, 2006). [4] Jakarta Cactus, 2006. http://jakarta.apache.org/cactus (accessed April 10, 2006). [5] Apache Commons Beanutils, 2006. beanutils/ (accessed April 10, 2006). http://jakarta.apache.org/commons/

[6] Apache Commons Email, 2006. http://jakarta.apache.org/commons/email/ (accessed April 10, 2006). [7] DbUnit, 2006. http://dbunit.sourceforge.net (accessed April 10, 2006). [8] Agentur die3, 2006. http://www.die3.co.at (accessed April 10, 2006). [9] Eclipse, 2006. http://www.eclipse.org (accessed April 10, 2006). [10] Eclipse Plugins, 2006. 2006). http://www.eclipse-plugins.info (accessed April 10,

[11] Apache FOP, 2006. http://xmlgraphics.apache.org/fop/ (accessed April 10, 2006). [12] Apache Geronimo, 2006. http://geronimo.apache.org (accessed April 10, 2006). [13] Google, 2006. http://www.google.ch (accessed April 10, 2006). [14] Hibernate, 2006. http://www.hibernate.org (accessed April 10, 2006). [15] HiveMind, 2006. http://jakarta.apache.org/hivemind (accessed April 10, 2006). [16] Java Platform, Enterprise Edition (Java EE), 2006. http://java.sun.com/javaee/ index.jsp (accessed April 10, 2006).

109

Referenced Web Ressources

110 http://java-source.net (accessed April 10,

[17] Java-Source. 2006).

Java-Source, 2006.

[18] JBoss, 2006. http://www.jboss.org (accessed April 10, 2006). [19] JBoss. JBoss jBPM, 2006. http://www.jboss.com/products/jbpm (accessed April 10, 2006). [20] JBoss. JEMS Development Tools for Eclipse, 2006. products/jbosside (accessed April 10, 2006). http://www.jboss.com/

[21] JBoss Application Server, 2006. http://www.jboss.com/products/jbossas (accessed April 10, 2006). [22] JBoss Cache, 2006. http://www.jboss.org/products/jbosscache (accessed April 10, 2006). [23] JDOM, 2006. http://www.jdom.org (accessed April 10, 2006). [24] JOnAS, 2006. http://jonas.objectweb.org (accessed April 10, 2006). [25] Java Server Faces (JSF), 2006. http://java.sun.com/j2ee/javaserverfaces (accessed April 10, 2006). [26] JUnit, 2006. http://www.junit.org (accessed April 10, 2006). [27] Maven, 2006. http://maven.apache.org (accessed April 10, 2006). [28] Metanet, 2006. http://www.metanet.ch (accessed April 10, 2006). [29] Microsoft .NET, 2006. http://www.microsoft.com/net (accessed April 10, 2006). [30] Sun Microsystems. Java Data Objects (JDO), 2006. products/jdo/ (accessed April 10, 2006). http://java.sun.com/

[31] MySQL, 2006. http://www.mysql.com (accessed April 10, 2006). [32] NetBeans, 2006. http://www.netbeans.org (accessed April 10, 2006). [33] NetPerceptions, 2006. http://www.netperceptions.com (accessed April 10, 2006). [34] OSCache, 2006. 2006). http://www.opensymphony.com/oscache (accessed April 10,

[35] PayPal, 2006. http://www.paypal.com (accessed April 10, 2006). [36] PHP, 2006. http://www.php.net (accessed April 10, 2006). [37] Apache POI, 2006. http://jakarta.apache.org/poi/ (accessed April 10, 2006). [38] PostgreSQL, 2006. http://www.postgresql.org (accessed April 10, 2006). [39] QuantumDB Eclipse Plugin, 2006. http://quantum.sourceforge.net (accessed April 10, 2006).

Referenced Web Ressources

111

[40] Reseda Home, 2006. http://www.resedahome.ch (accessed April 10, 2006). [41] ROME - RSS and Atom Utilities for Java, 2006. https://rome.dev.java.net/ (accessed April 10, 2006). [42] Spring Framework, 2006. http://www.springframework.org (accessed April 10, 2006). [43] SSA Global, 2006. http://www.ssaglobal.com (accessed April 10, 2006). [44] Apache Struts, 2006. http://struts.apache.org (accessed April 10, 2006). [45] stxx - Struts for Transforming XML with XSL, 2006. http://stxx.sourceforge. net (accessed April 10, 2006). [46] Sun Java System Application Server Platform Edition, 2006. http://java.sun. com/j2ee/1.4/download.html (accessed April 10, 2006). [47] Sun Microsystems, 2006. http://www.sun.com (accessed April 10, 2006). [48] Apache Tomcat, 2006. http://tomcat.apache.org (accessed April 10, 2006). [49] WebTrends, 2006. http://www.webtrends.com (accessed April 10, 2006). [50] XDoclet, 2006. http://xdoclet.sourceforge.net (accessed April 10, 2006).