Res Report

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

Reseda Engineering.

Master Thesis

Beat RaessJuly 2006

Thesis supervisors:

Prof. Dr. Jacques Pasquier-Rochaand

Dr. Patrik FuhrerSoftware Engineering Group

Software Engineering GroupDepartment of Informatics

University of Fribourg (Switzerland)

“So long, and thanks for all the fish.”

- Douglas Adams

Acknowledgements

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

ii

iii

Abstract

Reseda is a new company in the furniture business. The enterprise is divided into ResedaEngineering, responsible for the design, development and marketing of the products,and Reseda Home, concerned with the production and sale. The Reseda E-Shop masterproject consists of the planning, design and implementation of an online shop and websitefor Reseda Engineering.An online shop, internet shop, webshop or online store is “an electronic commerce ap-plication used for B2B or B2C” [Wik05b], which serves to sell products or services overthe internet. As such, an online shop is part of the e-commerce field of the e-businessframework.The two primary objectives of the Reseda E-Shop application are the presentation of thecompany’s 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, con-sultings) and support options (Frequently Asked Questions (FAQ), general terms, legalnotice, links). All these storefront features of the online shop can be managed online inthe storeback area.In order to fulfill the objectives of the e-shop, the design of the application needs to beclean, modular, extensible and well documented. As a consequence, the project relieson Unified Modeling Language (UML) diagrams, design patterns and frameworks. Theapplication is based on a multi-tier architecture using Java 2 Platform, Enterprise Edition(J2EE) and implemented with Enterprise JavaBeans (EJB), Struts and Hibernate, as wellas 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 includesthe application’s specification as well as notes concerning the involved technology andthe implementation. In addition to the report, also manuals for the e-shop’s 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 21.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2. Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3. Notations and Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Business Aspects 52.1. Reseda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2. A Franchising System . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3. Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.4. Market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.5. Target Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.6. Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2. E-Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.1. E-Business Framework . . . . . . . . . . . . . . . . . . . . . . . . 92.2.2. E-Commerce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.3. Best Practices of Online Retailing . . . . . . . . . . . . . . . . . . 112.2.4. Exemplary Internet Shops . . . . . . . . . . . . . . . . . . . . . . 12

2.3. Online Shop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.2. Basic Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.3. Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.4. Product Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.5. Existing Online Shop Software . . . . . . . . . . . . . . . . . . . . 18

3. Specification 193.1. Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.1. ShopConfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.1.2. CatalogMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

iv

Table of Contents v

3.1.3. ProductMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.1.4. BrowseProductCatalog . . . . . . . . . . . . . . . . . . . . . . . . 223.1.5. ProductInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.1.6. ShoppingBasket . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.1.7. CompanyMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.1.8. CompanyInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.1.9. NewsMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.1.10. News . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.11. Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.12. SupportMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.13. Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.1.14. Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.1.15. AccountMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.1.16. Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.1.17. OrderMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1.18. Consulting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1.19. ConsultingMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.1.20. ValidateInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2. State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3. Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.3.1. Product Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.3.2. Order and Consulting Items . . . . . . . . . . . . . . . . . . . . . 353.3.3. Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.4. Company and Employees . . . . . . . . . . . . . . . . . . . . . . . 363.3.5. News . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.6. Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.7. Shop Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

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

4. Technology 394.1. Multi-Tier-Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1.1. Three-Tier Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.1.2. Five-Tier Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2. J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2.1. Component Model . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2.2. Enterprise JavaBeans (EJB) . . . . . . . . . . . . . . . . . . . . . 434.2.3. Servlets and Java Server Pages (JSP) . . . . . . . . . . . . . . . . 45

4.3. Software Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3.1. J2EE Application Server . . . . . . . . . . . . . . . . . . . . . . . 464.3.2. Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Table of Contents vi

4.3.3. Integrated Development Environment (IDE) . . . . . . . . . . . . 484.3.4. Development Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 484.3.5. Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

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

5. Implementation 545.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.1.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.1.2. Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.1.3. J2EE Application . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2. Presentation Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.2.1. Presentation Tier Patterns . . . . . . . . . . . . . . . . . . . . . . 585.2.2. Struts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.3. Business Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.3.1. Business Tier Patterns . . . . . . . . . . . . . . . . . . . . . . . . 635.3.2. EJB Session Beans . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.4. Integration Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.4.1. Integration Tier Patterns . . . . . . . . . . . . . . . . . . . . . . . 665.4.2. Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6. Conclusion 706.1. Achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.1.1. Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.1.2. Website Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.1.3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.2. Possible Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.3. Final Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

A. Screenshots 75

B. Ant 79

C. Struts 84

D. EJB 92

E. Hibernate 97

F. License of the Documentation 101

G. Website of the Project 102

H. CD-ROM 103

Table of Contents vii

I. Common Acronyms 104

References 106

Referenced Web Ressources 109

List of Figures

1.1. Reseda E-Shop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1. Franchising System (cf. [Res05, p. 9]) . . . . . . . . . . . . . . . . . . . . 62.2. E-Business Framework [Sch05] . . . . . . . . . . . . . . . . . . . . . . . 92.3. E-Commerce Customer Cycle (cf. [Sch05]) . . . . . . . . . . . . . . . . . 102.4. Multi-Tier Shop Architecture [Mer02, p. 411] . . . . . . . . . . . . . . . 142.5. Basic Shop Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . 152.6. Basic Storefront Process (cf. [Mer02, p. 410]) . . . . . . . . . . . . . . . 162.7. Generic Product Catalog [Mer02, p. 415] . . . . . . . . . . . . . . . . . . 17

3.1. Online Shop Use-Case Diagram . . . . . . . . . . . . . . . . . . . . . . . 213.2. Online Shop Storefront State Diagram . . . . . . . . . . . . . . . . . . . 323.3. Online Shop Storeback State Diagram . . . . . . . . . . . . . . . . . . . 333.4. Online Shop Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . 343.5. Development Process [Fow02, p. 14] . . . . . . . . . . . . . . . . . . . . . 37

4.1. Three-Tier Architecture [Wik05c] . . . . . . . . . . . . . . . . . . . . . . 404.2. Five-Tier Architecture [ACM03, p. 120] . . . . . . . . . . . . . . . . . . . 414.3. J2EE Server and Containers [Sun05d, p. 10] . . . . . . . . . . . . . . . . 434.4. EJB 2.1 Architecture [MH04, p. 20] . . . . . . . . . . . . . . . . . . . . . 44

5.1. Implementation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 555.2. Reseda E-Shop Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 565.3. Model-View-Controller [Hus03, p. 44] . . . . . . . . . . . . . . . . . . . . 595.4. Service To Worker [ACM03, p. 279] . . . . . . . . . . . . . . . . . . . . . 595.5. Context Object [ACM03, p. 183] . . . . . . . . . . . . . . . . . . . . . . 605.6. Composite View [ACM03, p. 265] . . . . . . . . . . . . . . . . . . . . . . 615.7. Struts Architecture [Hus03, p. 15] . . . . . . . . . . . . . . . . . . . . . . 615.8. Session Façade [ACM03, p. 344] . . . . . . . . . . . . . . . . . . . . . . . 645.9. Business Delegate [ACM03, p. 305] . . . . . . . . . . . . . . . . . . . . . 65

viii

List of Figures ix

5.10. Service Locator [ACM03, p. 318] . . . . . . . . . . . . . . . . . . . . . . 665.11. Transfer Object [ACM03, p. 417] . . . . . . . . . . . . . . . . . . . . . . 675.12. Data Access Object [ACM03, p. 464] . . . . . . . . . . . . . . . . . . . . 685.13. Hibernate Architecture [Hib05, p. 24] . . . . . . . . . . . . . . . . . . . . 69

A.1. Screenshot: Product Catalog . . . . . . . . . . . . . . . . . . . . . . . . . 76A.2. Screenshot: Product Information . . . . . . . . . . . . . . . . . . . . . . 76A.3. Screenshot: Shopping Basket . . . . . . . . . . . . . . . . . . . . . . . . . 77A.4. Screenshot: Order Process . . . . . . . . . . . . . . . . . . . . . . . . . . 77A.5. Screenshot: Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78A.6. Screenshot: Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . 78

List of Tables

2.1. Product Lines (cf. [Res05, p. 14-15]) . . . . . . . . . . . . . . . . . . . . 72.2. Furniture Companies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3. Exemplary Online Shops . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4. Online Shop Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1. Java Enterprise APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2. Software Products: J2EE Application Server . . . . . . . . . . . . . . . . 464.3. Software Products: Database . . . . . . . . . . . . . . . . . . . . . . . . 474.4. Software Products: IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.5. Software Products: Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.6. Software Products: Frameworks . . . . . . . . . . . . . . . . . . . . . . . 504.7. Software Products: Frameworks (Logic) . . . . . . . . . . . . . . . . . . . 514.8. Software Products for the Online Shop . . . . . . . . . . . . . . . . . . . 52

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

x

Listings

B.1. Ant Build File (Part 1/4): build.xml . . . . . . . . . . . . . . . . . . . . . 80B.2. Ant Build File (Part 2/4): build.xml . . . . . . . . . . . . . . . . . . . . . 81B.3. Ant Build File (Part 3/4): build.xml . . . . . . . . . . . . . . . . . . . . . 82B.4. Ant Build File (Part 4/4): build.xml . . . . . . . . . . . . . . . . . . . . . 83C.1. Struts Form (Part 1/2): ProductForm.java . . . . . . . . . . . . . . . . . . 85C.2. Struts Form (Part 2/2): ProductForm.java . . . . . . . . . . . . . . . . . . 86C.3. Struts Action (Part 1/2): SaveOrUpdateProductAction.java . . . . . . . . . . 87C.4. Struts Action (Part 2/2): SaveOrUpdateProductAction.java . . . . . . . . . . 88C.5. Struts Core Configuration (Part 1/2): struts-config.xml . . . . . . . . . . . 89C.6. Struts Core Configuration (Part 2/2): struts-config.xml . . . . . . . . . . . 90C.7. Struts Tiles Definitions: tiles-defs.xml . . . . . . . . . . . . . . . . . . . . . 90C.8. Struts Validator Rules: validator-rules.xml . . . . . . . . . . . . . . . . . . . 91C.9. Struts Validator Validation: validation.xml . . . . . . . . . . . . . . . . . . 91D.1. Business Delegate: ProductMgmtDelegate.java . . . . . . . . . . . . . . . . . 93D.2. Business Delegate Interface: IProductMgmtDelegate.java . . . . . . . . . . . 93D.3. EJB Session Bean: ProductMgmtSessionBean.java . . . . . . . . . . . . . . . 94D.4. EJB Deployment Descriptor: ejb-jar.xml . . . . . . . . . . . . . . . . . . . 95D.5. JBoss Deployment Descriptor: jboss.xml . . . . . . . . . . . . . . . . . . . 96E.1. Hibernate Bean: ProductHB.java . . . . . . . . . . . . . . . . . . . . . . . . 98E.2. Hibernate XML Mapping File: ProductHB.hbm.xml . . . . . . . . . . . . . . 99E.3. Hibernate Configuration: hibernate.cfg.xml . . . . . . . . . . . . . . . . . . 99E.4. Hibernate MBean: jboss-service.xml . . . . . . . . . . . . . . . . . . . . . . 100E.5. Persisting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

1

1Introduction

1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3. Notations and Conventions . . . . . . . . . . . . . . . . . . . . . 4

Reseda is a new company active in the furniture business. The company consists of ResedaEngineering, responsible for the design, development and marketing of the products, andReseda Home, concerned with the production and sale. This division allows the enterpriseto concentrate the cost intensive aspects of the business in a central unit, and to combinethe production and sale in several independent shops. Due to this structure, costs arereduced and therefore Reseda Home can offer high quality products at a reasonable price.The master project Reseda E-Shop consists of the planning, design and implementation ofan online shop and website for Reseda Engineering. This e-shop is a three-tier applicationusing the J2EE technology. The application needs to reflect the structure and strategyof this new company and must be suited to their specific needs.

1.1. Objectives

The two primary objectives of the e-shop application are the presentation of the company’sproducts on the website and the possibility for online orders and consultings. In additionto the web application, the complete website needs to be designed and programmed. Thelong term goal of this project is to provide all data related to product information, ordersand customers in an electronical form, such that it could be used in a future productionsystem 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 ina database. The website’s content is afterwards generated from this information and acustomer can browse the offered products on the site and obtain detailled informationabout a specific product. The second step is to offer the possiblity for online orders andconsultings. A customer at home can make an order of a product, customized with theavailable options, or request a consulting to obtain more information. Apart from theseprimary goals, tools for the administration of the online shop and website as well as forthe corresponding management tasks are required.

2

1.2. Document Structure 3

Figure 1.1.: Reseda E-Shop

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

1.2. Document Structure

The report is structured into a business part, the specification, technology, implemen-tation 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 recom-mended 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, backgroundinformation is given on the companies Reseda Home and Reseda Engineering. Afterwards,e-business and especially the field of e-commerce is introduced, and finally, the focus ison online shops.

1.3. Notations and Conventions 4

The next chapter contains the specification of the J2EE application. A specification is anabstract and formal description of an application’s requirements and functionalities, whichis independent of the actual software or hardware used. First, a UML use-case diagramgives an overview over the functionalities. A state diagram then outlines the involvedprocesses and a class diagram captures the underlaying object model. An outline of theadopted development methodology finally 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-tierarchitecture. In principle, a multitiered architecture separates an application into severalindependent components. Frameworks then provide developers with a reusable commonstructure, as often required by such applications. This section includes an introductionto multi-tier architectures and J2EE as well as the corresponding available software andframeworks.The focus of Chapter 5 is on the implementation of the reseda e-shop application. For thedevelopment of this J2EE application, the integration-, business- and presentation tierhad to be implemented. This section first provides an overview over the involved layersand components as well as on the project itself. Afterwards, the implementation of thepresentation-, business- and integration-tier is explained in more details.

1.3. Notations and Conventions

This report uses the notations and conventions as defined by the documentation guidelinesof the Software Engineering Group:

• The report is devided in Chapters, which are broken down into Sections. Wherenecessary, sections are further broken down into Subsections, and subsections maycontain Paragraphs.

• Cited literature is given in References, while references to web sites are listed inReferenced 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 first time they are used.

For the formatting of the text, the following conventions apply:

• Italic is used for emphasis and to signify the first use of a term.

• Courrier is used for web addresses.

• Code is used in anything that would be typed literally when programming.

Courrier

2Business Aspects

2.1. Reseda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.2. A Franchising System . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.3. Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.4. Market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.5. Target Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.6. Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2. E-Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1. E-Business Framework . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.2. E-Commerce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.3. Best Practices of Online Retailing . . . . . . . . . . . . . . . . 11

2.2.4. Exemplary Internet Shops . . . . . . . . . . . . . . . . . . . . . 12

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

2.3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.2. Basic Functionalities . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.3. Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.4. Product Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.5. Existing Online Shop Software . . . . . . . . . . . . . . . . . . 18

Chapter 2 covers the business aspects of the Reseda E-Shop project. First, backgroundinformation is given on the companies Reseda Home and Reseda Engineering. Afterwards,e-business and especially the field of e-commerce is introduced, and finally, the focus ison online shops.

2.1. Reseda

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

5

2.1. Reseda 6

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

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

2.1.1. Background

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

2.1.2. A Franchising System

The standard marketing system in the furniture business consists of several cost intensivesteps: design of the product, production, sales organisation, trade fair, distributor andfinally 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, develop-ment and marketing and offers 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, developmentand marketing of the products, also Information Technology (IT) solutions for produc-tion, organisation and administration are provided. Further responsibilities include theprocurement of material, quality control, search for new franchisees and financing solu-tions.The franchisee then is Reseda Home. The concept is to have several small, independentshops with 4-7 employees each, where the production and sale is done strictly on demand.

2.1. Reseda 7

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

2.1.3. Products

Reseda offers high quality, customized and individual solid wood furniture at a reasonableprice. These products are manufactured in all important wood species like beech, maple,ash, oak, birch, pine, cherry and nut tree wood. Three different product lines - Resedagreen, Reseda yellow and Reseda red - are aimed at the various price segments of the targetmarket. Table 2.1 compares these product lines according to the estimated household-come in, wood species and prize range.

ProductLine

Income[SFr]

Wood Species Tables[SFr]

Chairs[SFr]

Beds[SFr]

Resedagreen

> 60000 Birch, Pine, Fir 600 -1200

180 -250

600 -1200

Resedayellow

> 90000 Beech, Maple, Ash,Oak

1200 -2800

250 -500

1200 -2400

Reseda red >120000 Cherry-, Nut-Tree 2800 -5000

500 -1000

2400 -4800

Table 2.1.: Product Lines (cf. [Res05, p. 14-15])

Apart from these product lines, the customer is further offered the possiblity to completelyspecify 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 thenmanufactured according to this plan.

2.1.4. Market

The current situation of the swiss furniture business consists of a total sales volume of 3.7milliard swiss francs. The biggest market participants are Möbel Pfister with 15% andIKEA with 14% market share. Further participants in this low and middle price segmentare for example Micasa, Conforama or Interio. Table 2.2 lists these companies and theirwebsites.

Company URLMöbel Pfister http://www.moebelpfister.chIKEA http://www.ikea.comMicasa http://www.micasa.chConforama http://www.conforama.frInterio http://www.interio.ch

Table 2.2.: Furniture Companies

http://www.moebelpfister.ch

http://www.ikea.com

http://www.micasa.ch

http://www.conforama.fr

http://www.interio.ch

2.2. E-Business 8

The remaining 25% of this market (940 million swiss francs) are high quality furniturecompanies, smaller specialized furniture stores, design boutiques and carpenter’s work-shops. As a consequence, these kind of furniture companies are considered as Reseda’sstrongest competitors. Reseda mainly concentrates on this high price segment of themarket, 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 anddesign quality, lasting, durable, authentic products with a good price-achievement ratio,people who desire a high living quality and customized and individual furniture, whichare at the same time modern and timeless. It is assumed, that this target group consistsof about a third of the high price segment market, which is about 8% of the whole swissfurniture market.

2.1.6. Strategy

The vision of Reseda is to become the leader in its market segment. This objectiverequires a share of 20-25% of the target market, respectively 1.6-2.0% of the whole swissfurniture market. The objective is achieved due to the benefits of the franchising systemas well as due to Reseda’s high quality products and further competitive advantages.The franchising system allows to offer reduced costs. This is due to the fact that there isno intermediary trade involved, production is done strictly on demand, the transport fromthe production to the point of sale is omitted, the small manufacturing area, no stock-keeping is necessary and also because of the synergies in the human resource management.The further competitive advantages include the high quality, solid wood products, theoffering of all common species of wood, a high design as well as product and manufac-turing 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 unrivaledprice-achievement ratio.Despite this ambitious objective, Reseda’s corporate values should not be neglected. Allemployees participate in the success of Reseda, as their salary consists of a base salaryand a share of the success. Reseda Home is further obliged to honesty towards its con-tacts, mainly its customers. But also the ecological and social environment is of centralimportance for Reseda.

2.2. E-Business

Electronic business (e-business) refers to “any business process that is empowered by aninformation system” [Wik05a]. The objective is to link a company’s internal and externalprocesses more efficiently and to integrate partners and suppliers in order to better satisfythe customer’s needs.The next paragraph introduces the basic notions and terms of e-business. Then, the focusis on e-commerce and online shops as well as the best practices for online retailing andexemplary internet shops.

2.2. E-Business 9

Figure 2.2.: E-Business Framework [Sch05]

2.2.1. E-Business Framework

The whole e-business framework (cf. Figure 2.2) can be classified into three main fields:e-procurement, e-commerce and e-government.

E-procurement describes the “electronic support of buying processes (purchase) of a com-pany” [Sch05]. These activities are mainly concerned with the integration of softwaresystems of different companies by means of an extranet. The field of e-commerce thenfocuses on the electronic support for order and sale processes of products and servicesto either customers or other companies. For the sale to customers, this is most oftenaccomplished by means of an online shop. Finally, the term e-government refers to therelations between a company or citiziens to the administration. This includes for exam-ple public tendering procedures or tax affairs in the case of enterprises, or electronic taxdeclarations 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 de-scribe the relation of a company to either enterprises, customers or the administration.

2.2.2. E-Commerce

In the field 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 offer the customer the choice to use hispreferred channel to either obtain information, buy products or get support.According to [Sch05], the typical phases of B2C e-commerce can be structured by thecustomer cycle (cf. Figure 2.3): motivation-, information-, agreement-, settlement- andloyalty phase.In the motivation phase, vendors want to make product or service information availablefor customers. The objective is to address potential customers and make them awareof a company’s online presence. This web promotion can be based on common offlinemarketing, where the domain name is communicated through press releases, articles orthe existing brand. But to take advantage of the medium internet, especially onlinemarketing is of importance. This includes choosing a suitable domain name, search enginemarketing 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 configuration, theshopping basket, support options and legal aspects. First, a company must decide whichproducts 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 imagesshould be included, as this is the basis for the order request. Here it holds, that thevisual impression is key. It should also be considered, that the internet often influencesoffline buying behaviour: customers inform themselves on the internet and buy a productin a physical store afterwards. In addition to a simple product catalog, it is also possibleto offer some kind of product configuration, where a customer can customize an articleaccording to his needs. A client then can add all items she is interested in to a shoppingbasket, which lists information like article name, quantity, price, total costs and shippingfees. Another enhancement could be a personalized product catalog, where the customeronly is offered the products that match his profile. In the information phase, a customershould further be informed about possible support options. This reinforces trust, as thecustomers feels that he can get into contact with the company if necessary. Possibilitieshere are FAQ’s, e-mail, telephone, fax or online forms. This phase further serves to makethe customer aware of legal aspects. This includes for example the common terms andconditions of a company or information specific 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 anactual negotiation, but rather an acceptance of the terms by the customer. The commonB2C process consists of the selection of products, the shopping basket, choosing paymentand delivery options, clicking on the accept button and an order confirmation by e-mail.A central aspect of this phase is security. All sensitive data should be encrypted andtransmitted over secure channels. For online shops, the question further arises, when thiscontract between the customer and the company is legally binding. Somehow contraryto offline sales, not the product catalog on the internet, but the order of the customer isrearged as the buying offer for online sales. It is then up to the company to either accept

2.2. E-Business 11

this offer and deliver the good, or reject. How this is treated and when this contract islegally binding must be indicated in the general terms and conditions of an enterprise.

The settlement phase deals with the fulfillment of the order. Here, the company transfersthe property or rights to the customer and receives corresponding payment in return. Inaddition to the actual delivery, the customer can also be offered tracking or tracing, sothat he can check the current status of his order. The main problem of this phase isliability, who is liable and where is the transfer point of the ordered good? Again, thispoint should be treated in the general terms and conditions.

The last part of this e-commerce customer cycle is the loyalty phase. It deals withimproving customer orientation and satisfaction in order to assure the retention of existingcustomers of an enterprise. To achieve this objective, a company should offer necessaryservices such as support options, treating complaints, guarantee or the right to returnorders. This phase may also serve to inform the customer of e.g. new products that hecould be interested in or special offers.

2.2.3. Best Practices of Online Retailing

Philip Bannister summarizes in his article [Ban02] the ten best practices of online retail-ing. These best practices have emerged, as online retailing has matured and customershave become comfortable with online shopping.

Go to the Buyers Online shops need to reach customers, as do normal stores. Whilethis is achieved mainly by a good location in the case of stores, this objective can bereached for online shops by a good ranking in search engines and e-commerce brokers. Inorder 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 orthe structure have an impact on the ranking (cf. [2] and [Sze04]). Alternatively to theoptimization, it is also possible to include one’s website in relevant online directories (e.g.online shop directories, cf. [2]) or purchase banner ads (e.g. Google AdWord, cf. [13]) toattract customers to a company’s website.

Optimize Home Page Design Concerning the appearance of a website, often the firstimpression decides if a customer stays on the site. Therefore, the design of the homepageneeds to be attractive and the navigation should help orient visitors (usability) and allowthem to find the searched information quickly. Moreover, the design should be consistentwith an enterprise’s corporate identity. As a consequence, often the same advertisingagency designs all of a company’s logos and layouts in order to create a unique corporatedesign.

Content Partnerships By building synergies with similar companies or websites, thecustomer base and user trust can be increased. As an example, online travel sites canform content partnerships with travel guides. This encourages new customers to visitone’s website.

2.2. E-Business 12

Persistent Shopping Cart Concerning online shopping, customers tend to place itemsin their shopping cart and return later to complete the sale. To avoid loosing returningclients, 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 recognizedand have items in their basket. As a further benefit, the products placed in the shoppingcarts can also serve as useful information to analyse selling trends.

Strong Supporting Images and Content As customers can not inspect products di-rectly 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 completesales as well as it has an impact on a company’s brand.

Promote Online and Offline Synergies Bannister points out the value of “tightlyintegrating 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 buyproducts afterwards in a store. As a consequence, a customer must be able to locatephysical stores simple and quick. Locator tools or contact information, maps, directionsand local dealer links help to reach this goal.

Excellent Search Engine Capabilities Many online customers use the search enginecapabilities of a website. Therefore a website should support multiple search options, sothat users can quickly find the desired items and information.

Clear Customer Support Options As each customer has a different preference forinteracting with retailers, he should be offered as many online and offline support optionsas possible. Common options here include FAQ’s, email phone or fax. Offering suchoptions creates user comfort and may reinforce a buying decision.

Strong and Relevant Cross Selling Concerning product recommendation based onalready purchased items, it is important, that these sale suggestions are relevant and instock. This way of cross-selling, as it is for example used by Amazon, provides a simpleway to increase revenue and profits. To support this cross selling, a number of recom-mender 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 onlinecompanies were profitable (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 andhas 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 currentstandard for B2C e-commerce.

Company URLAmazon http://www.amazon.comEBay http://www.ebay.comDell http://www.dell.comWalmart http://www.walmart.comIKEA http://www.ikea.comBuch.ch http://www.buch.chLe Shop http://www.le-shop.chFleurop 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 appli-cation used for B2B or B2C” [Wik05b], which serves to sell products or services over theinternet. 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 isthe possibility to compare prices and conditions of different retailers online.

This subsection first presents a possible system architecture for webshops. Afterwards,the basic functionalities and processes of online shops are outlined, followed by a schemafor 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 ona 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 theapplication server (3), which accesses the database (4) to either store or retrieve thenecessary data contained in the database. The result is finally returned via the web-server to the customer’s browser. Additionally, an external payment gateway can beintegrated to allow for example payment by credit-card.

Such multi-tier architectures divide application logic according to their function intoseveral distributed components. The objectives are to reduce development time andtherefore costs. This goal is achieved due to the clear division between these components,which improves reusability, speed, security, and reliability. In general, they are separatedinto three different parts: a presentation, business and backend layer.

The presentation layer resides on the client machine. The function of this layer is tooffer an interface to the user and is therefore mainly concerned with the layout of theapplication. Here, the application client is a simple browser, but it also could be a so-called rich client like a Java application.

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

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 appli-cation. The web- and application server residing on this layer provide middleware servicesfor communication, security, transaction, data access, persistence and administration. Asa 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 anonline 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 inFigure 2.5. A customer has only access to the storefront, where he can obtain informationabout the offered products and effect orders. Access to the storeback is only granted tothe 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 accessingthe storeback, also rich clients are possible.The core component of such an online shop is the product catalog. On the one hand,this database reflects the structure of the offered product range according to e.g. productline, product group and product category. On the other hand, also the detailed informa-tion 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 shopowner has entered the corresponding data on the storeback using the catalog and productmanagement functionalities, a customer then can browse the product catalog and obtaindetailled 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 persistentstate in order to allow customers to add items and return to it at a later time. Usuallythis is done by assigning the customer a session id, which is either stored in a cookie orin the Uniform Resource Locator (URL).

To effect an order, the customer then needs to enter his user profile or login if he alreadyis a registered client. User profiles can contain contact information (e.g. name, adress,email, telephone), demographic data (e.g. gender, date of birth) and payment or deliverypreferences (e.g. credit card, paypal). Care needs to be taken concerning data securityand privacy. No data should be accessible by unauthorized persons nor should it be usedwithout the explicit approval of a customer. Therefore only the shop owner has access tothis user profiles using the user management functionalities, and all communication andstorage involving user data needs to be encrypted.

To complete the ordering process, the customer further can specify options like the pre-ferred payment and delivery. Concerning the payment options, this can either be a simpleinvoice, credit-card or e-cash systems like PayPal (cf. [35]). For such payments, often anencrypted communication channel to an external payment gateway is used. If the order-ing process is successfully completed, the order information is stored in a database andthe customer receives a confirmation. 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 theshop owner, reporting or statistic tasks might be useful, as these tools offer information

2.3. Online Shop 16

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

about the online shop’s performance. Further functionalities for an online shop could besearch engines, a direct integration into the Enterprise Resource Planning (ERP) system,online Customer Relationship Management (CRM) tools or the integration into a contentmanagement system.

2.3.3. Processes

The processes involved in an online shop can again be separated into the storefront andstoreback procedures. The basic storefront process consists of the necessary steps involvedfor a customer to order a product, while the storeback process treats the tasks for handlingan order by the store owner.In the storefront process (cf. Figure 2.6), a customer first browses the product cata-log, consults the detailled product information and adds items he is interested in to hisshoping basket. Afterwards, he can continue to browse the catalog or start the orderingprocess. New clients of an online shop then need to register their data for the user profile,existing customers login to the system. The order process then usually involves check-ing the current user profile (e.g. correct adress), selecting payment and delivery optionsand finally controlling the whole order information before submitting it. At this point,the customer receives a confirmation indicating the successful order. Afterwards he cancontinue to browse the product catalog. Before his order is ready, he receives a deliverynotification 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 profile anytime he logs into the online shop system.For the storeback processes, the first step is always a login to the system in order toidentify the store owner. Afterwards, he can choose between all offered administrationfunctionalities of the online shop. He can for example manage the product catalog, theproducts or the user profiles. 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 onlineshop need to be adjusted accordingly. The order management allows to process an order,which usually involves checking the customers data, his creditworthiness and the orderitself. This check is important, as, depending on the business sector, the rate of junk-orders (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 notification, followed by the actualdelivery. Further administrative functionalities of such an online shop can include forexample tools for reports and statistics.

2.3.4. Product Catalog

The product catalog is the core component of an online shop, which reflects the structureof the offered product range and contains all product related information. Merz distin-guishes between two general kind of catalogs (cf. [Mer02, p. 414-420]), depending on thenature of the offered products. The first one is suited for heterogeneous products, whichall have different properties. These articles can be grouped into categories, which allowsfor a hierarchical navigation as well as for queries based on their attribute values. Thesecond kind of products all have rather similar characteristics. Here, a parametric querycan be used to step by step define the desired attribute values, which eventually leads to aselection 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 furtherinformation like images, text or the price. Each product belongs to a category, which canthemselve extend other categories. This allows to define a general hierarchic structure of

2.3. Online Shop 18

the product catalog according to the offered product categories. A product can further beof zero or more product types. Each product type defines some common characteristicsas well as common attributes for all these products. Moreover, products can also containany number of only product specific attributes.Like the products, the attributes can as well be of zero or more attribute types. Theseattribute types define common characteristics and attribute values. Attributes can furtherhave only a default value, but also zero or more attribute values. This allows to definefor example custom options.

2.3.5. Existing Online Shop Software

Table 2.4 lists a selection of available open-source and proprietary online shop softwareand their technology. All open-source products are published under a GNU GeneralPublic Licence (cf. [GNU05b]), and their technology is mostly based on PHP (cf. [36]).Apart from the commercial Intershop Enfinity, none of these online shops uses Sun’s EJBtechnology.

Name Lic. Techn. URLosCommerce GPL PHP http://www.oscommerce.comphpShop GPL PHP http://phpshop.orgPhPepperShop GPL PHP http://www.phpeppershop.comOSIS Online Shop GPL PHP http://www.oos-shop.deeSarine GPL J2EE http://diuf.unifr.ch/

is/research/esarine/introduction.php

Intershop Enfinity Prop. J2EE http://www.intershop.comBusiness One eS-hop

Prop. SAP http://www.sap.com/solutions/smb/businessone/index.epx

Table 2.4.: Online Shop Software

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



3Specification

3.1. Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.1. ShopConfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.2. CatalogMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.3. ProductMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.4. BrowseProductCatalog . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.5. ProductInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.6. ShoppingBasket . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.7. CompanyMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1.8. CompanyInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1.9. NewsMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1.10. News . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.11. Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.12. SupportMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.13. Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.14. Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.15. AccountMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.16. Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1.17. OrderMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1.18. Consulting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1.19. ConsultingMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.1.20. ValidateInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2. State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3. Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.3.1. Product Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3.2. Order and Consulting Items . . . . . . . . . . . . . . . . . . . . 35

3.3.3. Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3.4. Company and Employees . . . . . . . . . . . . . . . . . . . . . 36

19

3.1. Use-Cases 20

3.3.5. News . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3.6. Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3.7. Shop Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

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

This chapter contains the specification of the online shop. A specification is an abstractand formal description of an application’s requirements and functionalities, which is inde-pendent 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-proprietarystandard 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 spec-ification. First, the use-case diagram gives an overview over the application’s functionali-ties. The state diagram outlines the involved processes and the class diagram captures theunderlaying object model. An outline of the adopted development methodology finallyconcludes this chapter.

3.1. Use-Cases

Use-cases (cf. [Fow02, p. 39-47]) are the result of the discussion with the client anddescribe the typical interactions of a user with the system. The UML use-case diagramcaptures all possible interactions and hence the main functionalities, which are coveredby the application. The diagram itself is only intended to give an overview, but it doesnot contain any details. The graphical use-cases themselves are afterwards described ina 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 aspecific interaction of the user with the system with a common goal. Which actor is givenwhat permissions is indicated with the relations. The UML standard further specifiesgeneralization to extend an existing use-case and inclusion to capture behaviour that issimilar accross several use-cases.Figure 3.1 shows the use-case diagram of the online shop. There are three main actorsinvolved: the customer, who visits the web store, the administrator, responsible for thesetup and configuration of the online shop, and the manager, concerned with the dailybusiness. The use-cases are then structured by the storefront and storeback area, andthe lines indicate the relationships between the actors and the use-cases. Basically, thestorefront use-cases cover the customer’s interaction with the online shop, and the shopowner is given the necessary administrative tools for all the corresponding cases in thestoreback.While UML specifies use-case diagrams, there does not exists a standardized formatfor the description of the individual use-cases. But a commonly used format is givenin [Fow02, p. 40]. In this format, a use case is considered as a set of scenarios, tiedtogether by a common user goal. Such a scenario is a sequence of steps describing thesuccessful interaction of the user with the system. Extensions cover the variations onthis 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. Thefollowing paragraphs specify the individual use cases of the online shop by means of theabove format. Additionally, a short description as well as comments for each use-case aregiven.

3.1.1. ShopConfig

Description:Configure the editable properties of the online store.

Main Actor:Admin

Scenario:

1. System shows an overview of the editable properties.

2. User can configure 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 offered 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.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 theProductInfo (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 eitheradd the item to the shopping basket, to print or to download a pdf file of the productinformation.

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 Shopping-Basket (3.1.6), or downloads a pdf file 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 buythe selected products, download a pdf file with the information of all items or requestconsulting 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 prod-ucts, download a pdf file 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 em-ployee.


3.1.8. CompanyInfo

Description:Show all information (e.g. address, image, contact, map) of a selected company, whichcan afterwards be either printed or downloaded as a pdf file.

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

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.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 offered news formats.

2. System shows the corresponding news.

3. System validates (use-case 3.1.20) and stores email address for a newsletter sub-scription.

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 fills 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.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 customer’s account and its information (e.g.address, contact).

Main Actor:Customer

Scenario 1: Register

1. User enters profile 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 profile data and password.

3. System validates (use-case 3.1.20) and stores modified 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, telephonenumber, orders).

Main Actor:Manager, Administrator

Scenario 1: Create Account

1. System shows the customer data form.

2. User fills in the form.


3.1. Use-Cases 28

Scenario 2: Manage Account

1. System shows the customer’s data.

2. User can modify the data.


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 profile, choose payment and deliveryoptions and check the order once again. Afterwards, a confirmation mail is sent to thecustomer.

Main Actor:Customer

Scenario:

1. User registers or logs into his Account (3.1.14).

2. User checks his current profile.

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 confirmation email.

9. System stores order and informs store manager.

Extensions:2a. Outdated account information.

1. User updates Account (3.1.14).


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.


Comments:

1. Correct login is required.

2. A manager can only view and process orders of his shop.



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 profile (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 confirmation email.

8. System stores consulting and informs store manager.

Comments:

1. Correct registration or login is required.



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.


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.1.20. ValidateInput

Description:Validates a user’s 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 system’s be-haviour. Their purpose is to “describe all of the possible states that a particular objectcan get into and how the object’s state changes as a result of events that reach the object”[Fow02, p. 119]. The diagram basically consists of labelled state boxes and transitionsbetween them. A transition arrow indicates, that a state change is possible under certaincircumstances. 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 statediagrams 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 onlineshop. These diagram are not intended to cover all details of the application’s 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 application’s business objects and how they are related.In order to describe the types of objects and the relationship among them, UML classdiagrams can be used (cf. [Fow02, p. 49-65]). In this type of diagram, the system’sbusiness objects are modelled as classes and the relationship between them is eitherexpressed as an association, aggregation, composition or generalization.A class is visualized by a box and specified with a name, attributes and operations.Attributes describe the content and operations processes that a class knows to carryout. An association represents a general kind of relationship between objects. Eachassociation end has a multiplicity, which indicates the number of participating objects.The type of relation can be specified by a label and the navigability described by arrows,hence uni- or bidirectinal relations can be expressed. Aggregation and composition aresimilar 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 tothe other. The composition is even stronger, indicating that the object ceases to exists ifthe other does not exist anymore. Generalization then covers similarities between severalobjects. A superclass contains common attribute and methods, which are available toall 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.


Figure 3.4.: Online Shop Object Model


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

3.3.1. Product Catalog

The product catalog represents the company’s offered product range. The product catalogconsists of the following business objects: Category, ProductType, ProductFieldType, Product-FieldValueStandard, 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 define either parent or sub categories. Foreach 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 morecategories (e.g. a table belongs to a category Table and a residential environment LivingRoom).The ProductType serves as a generic definition for a concrete product. Such a producttype consists of assigned ProductFieldType objects (e.g. tablewidth, tablelength) with theirdefault values in the ProductFieldValueStandard objects. Each concrete Product then is initial-ized with the values defined in the type objects. Hence a product has its own ProductFieldand ProductFieldValue objects, which are independent from the type and the other prod-ucts. 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 fields and theirvalues can be edited, added or deleted for each product individually.One then can distinguish between customizable and non-customizable products. For acustomizable product, the ProductField objects have more than one value, which allows thecustomer to choose from these proposed values. The corresponding prices are calculatedas a function of the selected value of the product fields. This information is stored inthe ProductPriceMatrix and the ProductPriceMatrixCell objects. A customizable as well as anon-customizable product is further specified by images, html resources and relations.A Image represents an image of the product and a HtmlResource object a link to furtherinformation sources (e.g. woodtype description). The Relation object is used for includingproducts, which are related to the specified Product (e.g. matching chairs for a certaintable).

3.3.2. Order and Consulting Items

The order and consulting items contain a customer’s order or consulting data. The in-volved business objects are the OrderItem, ConsultingItem, ProductItem and ProductItemOption.The order or consulting items hold the basic information, like the chosen payment, de-livery or consulting option. An unlimited number of ProductItem objects are associated tosuch a ConsultingItem or OrderItem. This ProductItem object contains the required data of

1Denoted as i18nSomeName: Collection


an actual product, like the product id, name or price. The product fields and their se-lected values are represented in a ProductItemOption object, which contains the informationconcerning the chosen option. Each order or consulting is then associated to exactly onecustomer and one company, which processes the request. Wether the consulting nor theorder objects have references to the actual products, which allows to modify the productswithout any consequences for the already ordered items.

3.3.3. Account

The Account models a user’s system account. It basically serves as a container for thereferences to the Login, Profile, Preferences, OrderItem and ConsultingItem objects. Furtherinvolved business objects are the Role, Email, Address and Phone objects.

Each Account has exactly one Login object associated, used to access this account. Thegranted permissions are managed by assigning the required Role objects to the Login. The1:1 bidirectional aggregation to the Profile represents the fact, that each account belongs toone user. This profile contains a user’s 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 OrderItemand ConsultingItem objects.

3.3.4. Company and Employees

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

3.3.5. News

The NewsEntry and NewsletterSubscription objects serve to communicate a company’s infor-mation to their customers. These entries are either published online, as rss feed or sent ina newsletter. For this newsletter, the NewsletterSubscription allows a customer to subscribeor unsubscribe from this emailing list.

3.3.6. Support

To provide the customer’s with additional information like the general terms, legal notice,faq or links, the InfoTopic and InfoItem objects are used. The InfoTopic contains an unlimitednumber of InfoItem objects, which allows to for example define the individual terms in thegeneral terms.

3.4. Development Methodology 37

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

3.3.7. Shop Config

Finally, the shop config consists of all objects relevant for the configuration of the onlineshop. The ShopProperty holds any kind of property used to configure the basic functionali-ties (e.g. mailserver to use). The emails sent by the application are stored in the ShopEmailobjects, while the Slideshow contains the information for the website’s slideshows. TheLocaleLanguage and LocaleCountry hold all language and country codes, while the ShopLo-caleLanguage, ShopLocaleCountry and ShopLocaleCurrency contain the locales currently sup-ported by the online shop. Likewise, the PaymentOption, DeliveryOption and ConsultingOptionlist all possible options, and the corresponding ShopPaymentOption, ShopDeliveryOption andShopConsultingOption the ones supported by the e-shop. Finally, the WebResource objectholds arbitrary files (e.g. images, pdfs), which can afterwards be embedded in the websitesusing standard html tags.

3.4. Development Methodology

Current software development methodologies (cf. [Des04]) can be classified into twomain categories: traditional waterfall models and iterative processes. They differ in howa project’s tasks and activities are structured.In the waterfall model, a project is analysed, specified and designed once in the beginningand afterwards programmed, tested and finally delivered as a whole to the client. Thedrawback of this approach is, that an application often does not satisfy the needs of theclient anymore in the end. This is mainly due to the fact, that a client does often notknow 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 participatesin this development, as he tries out the individual parts of the software. This allows toinclude his needs and requests for changes throughout the whole lifecycle of the project.Popular iterative methodologies are for example the Rational Unified 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: in-ception, elaboration, construction and transition phase. In the inception phase, the scopeof the project and its business cases are defined. Afterwards, these abstract specificationsare converted to the architectural foundations and the design of the application in theelaboration phase. This phase also deals with the various risks (requirement, technolog-ical, skills and political) of a project. The application is then implemented, tested andre-defined in the construction phase using an incremental approach. Each iteration anal-ysis, designs, codes, tests and integrates a subset of the use-cases. In the final transitionphase, the completed application is delivered to the client.

3.4. Development Methodology 38

The Reseda e-shop project is based on the rational unified process, but does not implementall its development processes completely. Although the specification defines the mainuse-cases already in the beginning, their exact functionalities will be adapted throughoutthe 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 agiledevelopment process supported by e.g. automatic build tools and unit tests.

4Technology

4.1. Multi-Tier-Architecture . . . . . . . . . . . . . . . . . . . . . . . 40

4.1.1. Three-Tier Model . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1.2. Five-Tier Model . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2. J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2.1. Component Model . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2.2. Enterprise JavaBeans (EJB) . . . . . . . . . . . . . . . . . . . . 43

4.2.3. Servlets and Java Server Pages (JSP) . . . . . . . . . . . . . . . 45

4.3. Software Products . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.3.1. J2EE Application Server . . . . . . . . . . . . . . . . . . . . . . 46

4.3.2. Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3.3. Integrated Development Environment (IDE) . . . . . . . . . . . 48

4.3.4. Development Tools . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.3.5. Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 ar-chitecture. In principle, a multitiered architecture separates an application into severalindependent components. The objective is to improve reusability and therefore reducedevelopment time and costs. An open standard used for the development of such multi-tiered applications is J2EE. Frameworks then provide developers with a reusable commonstructure, as often required by applications. Such a framework is a “semi-complete appli-cation that can be specialized to produce custom applications” [Hus03, p. 5].This section includes an introduction to multi-tier architectures and J2EE as well asthe corresponding available software and frameworks. All information in the followingparagraphs is based on [MH04], [FCF02], [Sun05d] and [AT02]. Refer to this literature orto Dominic Brügger’s master thesis [Bru05] for a more more detailed discussion of thesetopics.

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 logicaccording to their function into several distributed components, which can reside ondifferent computers connected by a network. Oellermann states, that “this architecturehas proven to be very robust. It has managed to grow with the evolving technologybecause it is a logical architecture” [Oel01, p. 45]. Due to the clear separation, thesecomponents can be developed and maintained individually, which improves reusability,speed, security, and reliability. In general, such multi-tier applications are separated intothree or five different layers.

4.1.1. Three-Tier Model

Figure 4.1 shows a three-tier architecture, consisting of the presentation, logic and datatier. The presentation layer presents an interface to the user. Its main function is totranslate tasks and results to something the user can understand. The actual businesslogic 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. Thedata 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. Hecan enter his request in the offered 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 responsiblefor accessing the data stored in the data tier, calculating the result and sending back theresponse. The result is then displayed in the user’s web browser.

4.1.2. Five-Tier Model

The five-tier model (cf. Figure 4.2) then is an extension to the above three-tier architec-ture, where the layers are further refined. According to [ACM03, p. 120-121], the layersin 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 applica-tion (e.g. Java applet) or device (e.g. WAP phone). The required presentation logic toserve these clients is encapsulated in the presentation tier. This tier basically “interceptsthe client requests, provides single sign-on, conducts session management, controls accessto business services, and delivers the responses to the client” [ACM03, p. 121]. Like inthe 3-tier-model, the required business services are implemented in the business tier. Thedata layer is then split into the integration and resource tier. Due to this refinement,the communication with external resources and systems (e.g. data stores, legacy apppli-cations) is encapsulated in the integration tier. The business layer is coupled with thislayer, 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, legacysystem, 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 Microsoft’s .NET framework(cf. [29]). J2EE and .NET offer similar functionalities, but .NET is a proprietary standardand requires corresponding licence fees. As the Reseda online shop project is basedentirely on open standards and open source software, the Microsoft .NET technology isnot considered nor treated in this paper.The J2EE specification offers a range of Application Programming Interfaces (APIs) usedfor 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 DescriptionJDBC Java Database Connectivity

Used for working with relational database systems.RMI Remote Method Invocation

Allows distributed client-server programming.JAXP XML Parsing and Messaging

API required for processing xml files.JNDI Java Naming and Directory Interface

Provides networked naming and directory services.JMS Java Message Service

API for working with networked messaging services.JavaMail Java Mail

API offering support for email protocols.EJB Enterprise JavaBeans

Used for distributed server side components.Servlet Servlet

Server side applet to generate dynamic HTML content.JSP 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 inFigure 4.3. The following paragraphs introduce the underlaying component model as wellas the EJB, Servlet and JSP APIs.

4.2.1. Component Model

A component model “defines a set of contracts between the component developer andthe system that hosts the component” [MH04, p. 8]. This model specifies the servicesthat the corresponding component container offers as well as how a component shouldbe developed and packaged in order to be deployed in the container. As a consequenceof this approach, a component becomes an independent piece of software, which is notdeveloped for a specific application but for a specific 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 different applications by simply assembling therequired components. The J2EE specification defines a component model for the Enter-prise JavaBeans as well as for Servlets. These components are then hosted respectivelyin the Web and EJB container of a J2EE compliant application server (cf. Figure 4.3).

A J2EE application server implements the specification for the EJB and Servlet com-ponent model (for a list of J2EE compliant application servers, see section 4.3.1). Suchan application server further provides middleware services for communication, security,transaction, data access, persistence and administration. Hence the developer can benefitfrom these services, as he is not required to implement these low-level functionalities orcross-cutting aspects, but can instead concentrate on the actual business logic.

In the context of a five-tier architecture (cf. Figure 4.2), the user’s browser on the clientmachine represents the client layer. The Web container of the application server hostingthe Servlets and JSP pages covers the presentation tier, while the Enterprise JavaBeansin the EJB container form the business layer. The EJB container then implements theintegration tier, as it provides the required services for accessing the data of the databaseserver in the resource tier. As a consequence, a developer only needs to implement thepresentation and business tier parts of an application by providing the correspondingEJB, Servlet and JSP components. Further, these components can be deployed on anyJ2EE compliant application server and assembled and reused for different applications.

4.2.2. Enterprise JavaBeans (EJB)

Sun Microsystems defines the Enterprise JavaBeans architecture as a “component archi-tecture for the development and deployment of component-based distributed business ap-plications [which are] scalable, transactional and multi-user secure [and can be] deployedon any server platform that supports the Enterprise JavaBeans specification” [MH04, p.5]. These server-side components include both business objects and business processesand hence cover the business tier of a five-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 repre-sent processes. A further rarely used third type are message-driven beans. An entitybean 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 thebean developer is responsible for accessing the resource tier, and Container ManagedPersistence (CMP), where the application server is concerned with this data access. Inthe case of session beans, there also exists a distinction: stateful session beans maintainsome kind of conversational state, while stateless ones can be used independent of a client.Finally, message-driven beans allow for asynchronous message driven communication, assometimes required for the integration of external systems.

In the EJB 2.1 specification, both entity and session beans require to provide corre-sponding component interfaces: either a remote interface and remote home interface ora local interface and local home interface or both. The remote or local interfaces definea bean’s business methods (e.g. getSalesTotal), while the home interfaces represent its lifecycle 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 andEJB home stub objects from the provided bean interfaces and classes. As the applica-tion 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 compliantapplication server, as the components only provide the actual business logic while theserver is concerned with the required concrete implementation of the bean objects.

Apart from hosting the components, the application server further is concerned withthe offered middleware services. These services for communication, security, transaction,data access, persistence and administration can be used by the Enterprise JavaBeancomponents, but they are not hard coded in the beans. Instead, they are configured indeployment descriptors. This allows for flexibility, as the configuration and assemblingof the individual components is done descriptive and hence does not require touching orrewriting a beans source code.

While the EJB 2.1 specification offers a flexible basis for a wide range of enterprise appli-cation, its architecture is considered as rather complicated and tedious to program. Thesubsequent EJB 3.0 release1 tries to overcome this drawback by providing new simplified

1announced 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 simplification has several aspects:

• Simplification of the interface definition requirements for enterprise beans: elimina-tion of requirements for the specification of home and component interfaces in theEJB 3.0 programming model.

• Simplification of the contractual requirements between the bean provider and thecontainer: elimination of the requirements for the specification of the EnterpriseBeaninterfaces.

• Simplification of APIs for access to the bean’s environment: definition of a depen-dency injection facility and simpler look-up APIs.

• Introduction of Java metadata annotations to be used as an alternative to deploy-ment descriptors.

• Simplification of object persistence by the definition of a light-weight object/rela-tional mapping facility based on the direct use of Java classes rather than persistentcomponents.

As an alternative to persist data with EJB, frameworks such as Hibernate (cf. [14]), JavaData Objects (JDO) (cf. [30]) or Spring (cf. [42]) can be used. These frameworks do notrequire a container, as they provide all services needed for a persistence layer. Hibernatefor 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)

Java’s Servlet (server-side applet) specification defines a component model for the dy-namic 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 andrenders a response. As such, the Servlet and the Java Server Pages cover the presentationtier of the five-tier architecture of Figure 4.2.In most cases, the request is a http request, from which a servlet extracts the requiredparameters. Depending on these parameters, it then renders a html page, which is sentback to the client and displayed in his browser. The drawback of Servlets is, that therendered html contains static as well as dynamic content, which somehow mixes logic andpresentation.Java Server Pages are an extension to Servlets that try to overcome this drawback. AJSP page is a text file, which contains static data as well as the embedded code (scripplet)for the generation of the dynamic content. The webserver then automatically generatesa Servlet from the JSP file and stores it in the servlet container. This approach separateslogic and presentation more clearly, but the presentation still contains application logic.A further improvement is therefore the use of tag libraries. This library defines tags,which can be used in JSP pages. But the code for these tags is then implemented in plainJava classes, and hence the JSP page itself does not contain any application logic. Withthis approach, an application developer can provide the necessary tags for the generationof 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 benefit, taglibraries 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 anapplication server and a database. For the software development, Integrated DevelopmentEnvironment (IDE) are used together with further development tools (e.g. for buildmanagement). In addition to this fundamental software, frameworks can provide oftenrequired functionalities like e.g. for a coherent layout control or for unit tests.The following paragraphs provide an overview over available software products for appli-cation servers, databases, IDE, development tools and frameworks. As the online shopwill be based entirely on open standards and open source software, only correspondingproducts are presented. For each software category, a selection of available products isfirst listed in a table. For a more exhaustive list of open source software for Java, consulte.g. the Java-Source (cf. [17]) website. The more interesting products are introducedafterwards, 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 givenin Section 6. Details for software used in the online shop can afterwards be found in theimplementation section of this report.

4.3.1. J2EE Application Server

The general requirement for an application server to be J2EE compliant is, that it needsto implement the corresponding specification. As a consequence, their offered basic mid-dleware services are similar. The main difference between the available products is howthey implement the J2EE specification and what tools they offer for development, de-ployment and administration. Table 4.2 lists a selection of available J2EE applicationserver products.

Product URLJBoss http://www.jboss.comSun Microsystems ASPlatform Edition

http://java.sun.com/j2ee/1.4/download.html

JOnAS http://jonas.objectweb.orgApache Geronimo 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 theirproducts 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 usedin productive systems and considered as stable and reliable. It integrates technology likeHibernate (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

http://www.jboss.com



http://jonas.objectweb.org

http://geronimo.apache.org


plugin (cf. [20]) or JBoss jBPM (cf. [19]) are available in addition to the standarddeployment and administration consoles.

Sun Microsystems AS Sun Microsystems (cf. [47]) offers three different applicationserver editions (cf. [46])): the platform edition is free for development, deployment andredistribution, while the standard and enterprise edition require a software license. Thedifference between these versions are the offered capabilities. The key features of theplatform edition are the Web Services Security and JavaServer Faces support, as well asthe integration into Sun’s development environment NetBeans.

JOnAS JOnAS (cf. [24]) is a pure Java implementation of the J2EE specification bythe ObjectWeb group. While they provide a standard EJB container, the Web containercan be configured to use Tomcat or Jetty. It offers all required middle tier services aswell as an administration console and clustering and performance services.

Apache Geronimo Geronimo (cf. [12]) is the J2EE server project of the Apache Soft-ware Foundation. Although currently it is not fully J2EE compliant, it offers most ofthe required middleware services. Also development tools like e.g. an Eclipse plugin areavailable, but as an unstable release.

4.3.2. Database

In order to integrate a database in a J2EE application, a database vendor needs toprovide the required Java Database Connectivity (JDBC) driver. Currently, there existtwo popular open source databases used for web applications: MySQL (cf. [31]) andPostgreSQL (cf. [38]). They are similar in the offered services as well as in the availabletools. For a more detailled comparison between the two, refer to [Con04] or [Gil03]. Apartfrom these relational databases, there exist other types like object-oriented or ExtensibleMarkup Language (XML) databases (cf. [3]), but they are still under development andusually not used for productive systems.

Product URLMySQL http://www.mysql.comPostgreSQL http://www.postgresql.orgBerkeley DB XML http://www.sleepycat.com/products/

xml.shtml

Table 4.3.: Software Products: Database

MySQL There are two MySQL database editions available: the Community Edition isopen source, while the Pro Certified Server requires a corresponding commercial licenceand offers additional enterprise functionalities. The Community Edition is publishedunder a GNU Public License (GPL) licence (cf. [GNU05b]), which means that thisedition can only be used for software which is also open source. The Graphical UserInterface (GUI) tools include the MySQL Migration Tool Kit, Administrator and QueryBrowser.

http://www.mysql.com

http://www.postgresql.org

http://www.sleepycat.com/products/xml.shtml



PostgreSQL The PostgreSQL database is developed by the University of California atBerkeley and published under a Berkeley Licence. In contrast to the MySQL licencingscheme, it allows to integrate this database in any software product as long as the BerkeleyLicence is included with it. Graphical administration tools for PostgreSQL are pgAdminIII and PhpPgAdmin.

Berkeley DB XML The Berkeley DB XML is an XML database implemented as alayer on top of the relational Berkeley DB database. It stores XML files in collections anallows 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. PopularIDE for J2EE development are Eclipse (cf. [9]) and NetBeans (cf. [32]). The choicebetween the two somehow depends on the application server in use, as Eclipse mainlysupports JBoss while NetBeans the Sun application server.

Product URLEclipse http://www.eclipse.orgNetBeans http://www.netbeans.org

Table 4.4.: Software Products: IDE

Eclipse Eclipse is an extensible open source development platform and applicationframework. A variety of commercial and free plugins are available (cf. [10]), like theJBoss-IDE (cf. [20]) or QuantumDB (cf. [39])plugin. Further, it directly integrates theAnt build tool into the IDE.

NetBeans NetBeans is an open-source project sponsored by Sun Microsystems. TheIDE includes features for web, EJB or web service development as well as a range ofadditional plugins.

4.3.4. Development Tools

Development tools serve to facilitate the software development process. This can includefor 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 URLAnt http://ant.apache.orgMaven http://maven.apache.orgXDoclet http://xdoclet.sourceforge.net

Table 4.5.: Software Products: Tools

http://www.eclipse.org

http://www.netbeans.org

http://ant.apache.org

http://maven.apache.org

http://xdoclet.sourceforge.net


Ant Apache Ant is a Java and XML-based build tool, similar to the make utility forthe C programming language, but with the great benefit to be platform/OS independent.The ant tasks provide services for e.g. compilation, running XDoclet, JUnit or creatingthe necessary ejb-jar, war and ear files. The ant build script calls these tasks and allowsto define dependencies between them.

Maven Maven (cf. [27]) is a software project management and comprehension tool byApache. Its objective is to make the build process easy and provide a uniform buildsystem. The main difference to Ant is, that the build tasks are implemented as plugins,which hides their complexity from the developer. Further, Maven tries to enforce bestpractices in software development and project management. But currently, Maven is stillunder development and not yet as mature as Ant.

XDoclet XDoclet is an open source code generation engine, which enables attribute-oriented programming for Java. This is accomplished by adding meta annotations in theform of special JavaDoc tags (similar to Java 1.4 annotations) to the source file. Ant thencalls the corresponding tasks and XDoclet parses the annotated source files and generatese.g. XML descriptors or source code. XDoclet can be used for example to generate thenecessary EJB component interfaces, Hibernate mapping files or Struts configuration files.

4.3.5. Frameworks

Frameworks provide the developer with a reusable common structure, as often requiredby applications. A developer can extend these frameworks at the corresponding hotspotsin order to customize it for his needs. For J2EE based web applications, there exists awide variety of available frameworks. Struts (cf. [44]), stxx (cf. [45]) and Java ServerFaces (JSF) (cf. [25]) offer 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]) offerscaching functionalities. Spring (cf. [42]) and HiveMind (cf. [15]) even go a step furtheras 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]) offer speficapplication logic, e.g. for treating Java beans or XML files.

Struts Struts is an open source framework of the Apache Software Foundation for build-ing Java web applications. The framework is based on the Model 2 approach, a variationof the classic MVC design paradigm. The objective of this framework is to clearly sepa-rate data, its presentation and how it is processed. It provides a controller, responsible forprocessing a request. Data is encapsuled in the model, where the interaction can be basedon e.g. JDBC, EJB or Hibernate. The view component then often is implemented in JavaServer Pages, but also Extensible Stylesheet Language Transformations (XSLT) or otherpresentation systems can be used. In addition, struts also integrates the Struts Tiles andStruts Validator packages. Tiles is used for a coherent layout, while the Validator allowsto verify user input.


Product Type URLStruts Presentation http://struts.apache.orgStruts Tiles Presentation http://struts.apache.org/

struts-tiles/Struts Valida-tor

Presentation http://struts.apache.org

sslext Presentation http://sslext.sourceforge.net/stxx Presentation http://stxx.sourceforge.netJava ServerFaces (JSF)

Presentation http://java.sun.com/j2ee/javaserverfaces/download.html

Struts-Faces Presentation http://struts.apache.org/proposals/struts-faces.html

Hibernate Integration http://www.hibernate.orgJava DataObjects(JDO)

Integration http://java.sun.com/products/jdo/

JUnit Test http://www.junit.orgDbUnit Test http://dbunit.sourceforge.netCactus Test http://jakarta.apache.org/cactusOSCache Cache http://www.opensymphony.com/

oscacheSpring Middle-Tier http://www.springframework.orgHiveMind Middle-Tier http://jakarta.apache.org/

hivemind

Table 4.6.: Software Products: Frameworks

stxx The stxx framework is an extension of Struts for transforming XML with XSLT.The idea is to offer a more XML based alternative for the model and view components. Ituses the W3C standard XForms to model the data in XML format. This XML data thencan 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 forJava server applications. Like Struts, it is also based on the MVC design pattern. Afurther objective of this framework is to overcome the limitations of HTML by providinga rich User Interface (UI). It includes a set of APIs to represent these UI components,manage their state, handle events, input validation and defining page navigation. TheUI components can afterwards be used in JSP pages by using the tags defined in thecorresponding tag library.

Struts-Faces Struts-Faces is a library to include Java Server Faces in a Struts basedapplication. This allows to e.g. take advantage of the capabilities of JSF components for arich 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 andoutlines how to integrate JSF with Struts in a J2EE application.

http://struts.apache.org

http://struts.apache.org/struts-tiles/

http://struts.apache.org/struts-tiles/


http://sslext.sourceforge.net/

http://stxx.sourceforge.net

http://java.sun.com/j2ee/javaserverfaces/download.html

http://java.sun.com/j2ee/javaserverfaces/download.html

http://struts.apache.org/proposals/struts-faces.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



CommonsBeanutils

Java Beansutils

http://jakarta.apache.org/commons/beanutils/

CommonsEmail

Email tools http://jakarta.apache.org/commons/email/

Log4j Logging ser-vice

http://logging.apache.org/log4j

FOP XSL, XSL-FO transfor-mation

http://xmlgraphics.apache.org/fop/

JDOM XML file pro-cessing

http://www.jdom.org/

POI Microsoftfile formatprocessing

http://jakarta.apache.org/poi/

ROME RSS readerand writer

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

Table 4.7.: Software Products: Frameworks (Logic)

JUnit, DbUnit, Cactus JUnit is a testing framework for implementing unit tests inJava. It allows to define TestCases in a TestSuite and execute them using the TestRunner.DbUnit is an extension to this framework aimed at putting the database into a definedstate before running the unit tests. This avoids possible side effects which may be causedby previous test runs. For J2EE applications, the difficulty arises that these tests mustbe executed in the application server’s containers. Cactus is a framework for unit testingsuch server-side Java code (e.g. Servlets, JSP, EJB). It provides the necessary tools torun JUnit tests in this context.

OSCache A crucial criteria for J2EE applications is performance. The OSCache frame-work is aimed at in memory and persistent on disk caching of JSP content, servlet re-sponses or arbitrary objects. As a consequence, the web application can use these cachedresults 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 necessarymiddle-tier services. Its objective is to reduce the complexity of developing J2EE basedapplications. Spring is based on a modular architecture, with the possibility to either usethe provided services or plugin other frameworks. The core is its lightweight containerbased on the inversion of control (dependency injection) principle. An application’s busi-ness objects are then developed using POJO and the necessary configuration is donedeclaratively through XML files. As such, it provides an alternative to the EnterpriseJavaBeans. But Spring also covers other middle-tier services like object-relational map-ping or presentation layer services. A developer can either use the provided modules orplugin other frameworks such as e.g. Hibernate or Struts.

HiveMind HiveMind is a services and configuration microkernel. In this framework,services are implemented in POJO and configured in XML descriptors. The startup logic



http://jakarta.apache.org/commons/email/


http://logging.apache.org/log4j



http://www.jdom.org/



4.4. Conclusion 52

of HiveMind parses these module deployment descriptors, instantiates and initializes thoseservices and configurations 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 themain decisions for the project is the choice of the J2EE application server. Sun’s as wellas 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, butalso because of the available plugins (e.g. for debugging), the good integration into theEclipse IDE and because Hibernate already is included in the standard distribution. Analternative to an application server would have been Spring. But as this frameworkonly provides a lightweight container, all required services, like e.g. for transaction orcommunication, would have needed to be included. JBoss in contrast already offersthese services out of the box, and hence one can benefit from the coherent and testedconfiguration.Concerning the database, the choice was for MySQL. This decision is based on the fact,that MySQL currently offers better administration tools (MySQL Query Browser, MySQLAdministrator), which facilitates working with this database, especially during develop-ment. But due to the use of Hibernate (see below), the reseda e-shop application couldeasily be configured to use PostgreSQL or any other major database instead of MySQL.

Product TypeJBoss J2EE Application ServerMySQL DatabaseEclipse IDEAnt, XDoclet Development ToolHibernate Framework (Integration)Struts, Struts Tiles, Struts Val-idator, sslext

Framework (Presentation)

JUnit, DbUnit, Cactus Framework (Test)OSCache Framework (Cache)Commons Beanutils, CommonsEmail, Log4j, FOP, JDOM, POI,ROME

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 theoffered plugins. For the development, also Ant as well as XDoclet is used, because theseframeworks 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 wasfinally chosen, because this framework is thoroughly tested, documented and widely usedin production. Also other required functionalities like validation, layout, ssl encryption areavailable by using Struts Validator, Struts Tiles and the sslext extension. The drawbackof using Struts is, that this framework is considered to be a bit out of date (“the dinosaurof 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 Beansor implementing the data access by means of an integration framework like Java DataObjects or Hibernate. It was decided to not use the Entity Beans, as they are rathercomplicated to program and not so flexible. In contrast, the chosen Hibernate frameworkallows to easily map POJO to a database and also automatically create the correspond-ing database schemas from these mapping files. Another benefit is, that OSCache canbe plugged into Hibernate as second level cache, which improves the application’s per-formance. While the integration layer does not rely on the EJB technology, the businesstier does use standard Session Beans to implement the project’s use cases. This ap-proach allows to benefit from e.g. the JNDI lookup, and the declarative transaction andauthorization management offered by the JBoss application server.The application is then unit tested using JUnit, DbUnit and Cactus. Further frameworksused for the reseda e-shop include the Apache Commons Beanutils and Commons Email,Log4j, FOP, JDOM, POI and ROME, which offer additional application logic not providedby the standard Java APIs.

5Implementation

5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.1.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.1.2. Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.1.3. J2EE Application . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2. Presentation Tier . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.1. Presentation Tier Patterns . . . . . . . . . . . . . . . . . . . . . 58

5.2.2. Struts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.3. Business Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.3.1. Business Tier Patterns . . . . . . . . . . . . . . . . . . . . . . . 63

5.3.2. EJB Session Beans . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.4. Integration Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.4.1. Integration Tier Patterns . . . . . . . . . . . . . . . . . . . . . 66

5.4.2. Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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- andpresentation tier had to be implemented (cf. Figure 5.1). This section first providesan overview over the involved layers and components as well as on the project itself.Afterwards, the presentation-, business- and integration-tier implementation is explainedin 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 usto document a known recurring problem and its solution in a particular context, and tocommunicate this knowledge to others” [ACM03, p. 9]. As such, patterns are observedthrough experience, are written in a structured format, prevent reinventing the wheel,are reusable artifacts, exist at different levels of abstraction, can be used together tosolve larger problems and hence communicate design and best practices (cf. [Pas04]).Afterwards, the details concerning the actual implementation and the used frameworksfor 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 first introducedby a UML sequence diagram. This diagram shows how the involved components interactto store or retrieve data. Afterwards, some notes concerning the J2EE application, buildmanagement 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 theintegration tier is done with Hibernate (cf. [14]), EJB Session Beans (cf. [16]) are used forthe business-tier, Struts (cf. [44]) for the presentation-tier and the client-tier consists ofa web browser. The global architecture of the application and its components are shownin Figure 5.2. The simplified example treats the steps involved to save or update datain the resource-tier. In order to retrieve information from the database, similar steps areinvolved.First, a Client submits a request to the Struts ActionServlet. Based on the Uniform ResourceIdentifier (URI), this servlet dispatches to the appropriate Struts Action, which then pro-cesses the request. The action creates the required Bean used to transport the data andpopulates 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 sessionbean as well uses the ServiceLocator instance to lookup the Hibernate SessionFactory.After this initialization, the actual request is processed. The Struts Action invokes theBusinessDelegate’s business method and passes the data in the TransferObject Bean. Theinvocation is then propagated to the SessionFacade, which is responsible for processing therequest 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 currentSession and to load the corresponding Beans from it. Likewise, this Session is used to saveor delete Hibernate Beans. All changes applied to these persistent objects are afterwardspropagated to the database by the Hibernate framework. After a successful transaction,the call returns to the Struts Action, which returns an ActionForward depending on theoutcome of the invocation. The ActionServlet finally forwards the Client to the path storedin 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), whichconstantly analyses, specifies, 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 toaccomplish some kind of work by calling the required Ant tasks. The Eclipse IDE allowsto launch these targets individually or to build the whole project. The build process isconfigured in the Ant build.xml file (cf. extracts in appendix B). First, the projects globalproperties and paths are defined (cf. Listing B.1). The targets afterwards serve to eithergenerate code by using XDoclet (cf. Listing B.2), accomplish any other kind of otherwork like creating the database schema (cf. Listing B.3) or to finally build and packagethe project (cf. Listing B.4).

The unit tests rely on the JUnit, DbUnit and Cactus frameworks. JUnit serves to definethe actual unit tests, DbUnit allows to put the database into a well defined state for eachtest run and Cactus is required to run these tests in an EJB container. For each EJBSession Bean, there exists a corresponding test class to verify the correct behaviour of itsmethods. Note that these unit tests only check if the methods work correctly, but usuallythe returned or saved content is not verified.

5.1.3. J2EE Application

In order to deploy the J2EE application on an application server like JBoss, all compo-nents listed in Table 5.1 are packaged together with the required libraries, classes andconfiguration files into an Enterprise Archive (EAR) file. The Hibernate Archive (HAR)file contains all Hibernate libraries, classes, mapping files and configurations. Likewise, allEJB beans and their deployment descriptor are packaged into an EJB Java Archive (JAR)file. The content of the Web Archive (WAR) file consists of all resources related to theweb application, which includes the Struts libraries, classes, configuration, as well asthe 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 Authen-tication and Authorization Service (JAAS) configuration is further packaged in a ServiceArchive (SAR).

Component File ContentHibernate Archive res-hb.har HibernateEnterprise JavaBeans Archive res-ejb.jar EJBWeb Archive res-web.war Web applicationClient res-client.jar Client applicationJava Authentication and Autho-rization Service

res-jaas.sar JAAS configuration

Table 5.1.: EAR Content

5.2. Presentation Tier 58

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

5.2. Presentation Tier

The purpose of the presentation tier is to present an interface to the user. Its mainfunction is to translate tasks and results to something the user can understand. The resedae-shop application uses the Struts MVC framework, which implements several designpatterns. These patterns are outlined only briefly, and afterwards the implementation ofthe 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 frameworkitself is based on various other design patterns, like the Service to Worker, Front Controllerand 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): TheModel, View and Controller. The Model represents the business logic or state of anapplication, while the View is responsible for the layout of the application’s state and theController mediates the application flow.In this model, the Controller delegates requests to the appropriate handlers. The appro-priate business logic of the Model is then called to perform the requested task. If the stateof the Model changes, the View is notified and changes the layout accordingly. The ben-efit of this MVC architecture is the clear separation and loose coupling between the Viewand 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 andrequest 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 FrontController, Application Controller and View Helper pattern.In this pattern (cf. Figure 5.4), the FrontController receives a request from a Client, whichit delegates to the ApplicationController. Here, the request is resolved and the appropri-ate Command is invoked. The Command then accesses some kind of BusinessService thatprovides the data for the PresentationModel. The ApplicationController then performs the ap-propriate view management and dispatches to it. The ViewHelper finally transforms thepresentation model for the view.

1The content is extracted.


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 handlingactivities” [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 ApplicationController.

Application Controller

The Application Controller pattern (cf. [ACM03, p. 205 - 239]) is used to “centralizeretrieval and invocation of request-processing components, such as commands and views”[ACM03, p. 205]. It centralizes and modularizes action and view management anddispatches the requests to the appropriate ones.


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

View Helper

In the View Helper pattern (cf. [ACM03, p. 240-261]), Views serve to “encapsulateformatting code” and Helpers to “encapsulate view-processing logic” [ACM03, p. 241].Views delegate the processing to Helper classes (POJO, tags), which perform the requiredformatting 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 aprotocol-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 withouttying the application to a specific protocol. As an example, the Hypertext TransferProtocol (HTTP) request parameters of a form can be stored in a context object andthus 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 ContextObjectwith a ContextFactory. The ContextObject encapsulates the data and hides the applicationcomponents 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 benefit of this approachis, that these subviews can be included dynamically and therefore the page layout can bemanaged independently of the content. In Struts, this functionality is provided by theStruts Tiles framework.

In this pattern (cf. Figure 5.6), the View is rendered by a ViewManager. Using the layoutTemplate, the CompositeView is created by including the SimpleView subviews.


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 Tilesframeworks and the sslext extension. Struts is a web application framework based onthe MVC paradigm. Struts Validator allows to verify user input and Struts Tiles is usedfor the layout. Finally, sslext is an extension to struts for HTTP / Hypertext TransferProtocol Secure (HTTPS) switching. The necessary Struts, Struts Validator, Struts Tilesand sslext configuration files are generated with XDoclet from the annotations in thecorresponding Java classes. All the configuration files are then packaged together withthe struts libraries, classes, jsp pages and further web resources in the WAR file, whichis deployed in the EAR file on the application server.

The global architecture of the Struts framework is outlined in Figure 5.7. The ActionServletcontrols the navigation flow, Forms are used to capture user input and Actions serve toaccess business logic. Based on the URI, a client’s request is first dispatched by theActionServlet to the appropriate Action class. If required, the Action collects the user’s input


from the Form. The Action is responsible for accessing the business tier in order to performthe requested task. Upon completion, the Action class returns an ActionForward, which isused by the ActionServlet to forward to the corresponding page.The Struts Validator framework is responsible for the validation of the Struts Forms. Itprovides several built in validators (defined in the validator-rules.xml file) to e.g. assure thatan input field is not empty or to control the correct format of an email address, but alsocustom 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 definea central layout and each page then declares which subviews (tiles) are inserted into thislayout. All definitions are kept in the tiles-defs.xml file. The ActionServlet only calls theidentifier 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 switch-ing. The standards allow to switch from HTTP to HTTPS, but the inverse is by definitionnot possible without loosing the session context2. The sslext extension allows switchingin both directions by copying the corresponding session information. For each page defi-nition, 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 identified by its name and anannotation 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 op-tional validate and reset methods called by the frameworks. As a convention for the resedae-shop application, each form also has setForm(bean), setBlankForm(bean, supportedLocales)and populateBean(bean) methods to initialize or retrieve a form’s data. The XDoclet an-notations allow to automatically generate the corresponding Struts configuration files.

Action

Struts actions are used to call the business logic for the requested task. An action (cf.Listing C.3, Listing C.4) is defined by its path and type. It further indicates its scope andif the framework should validate the form prior to calling the action. If the action has aform input, its name and input are also indicated. In addition, each action may specifylocal action forwards. The framework then calls the execute method, in which the actionperforms the required tasks. Depending on the output of the action (success / failure),the corresponding ActionForward is returned by this method, which the ActionServlet usesto dispatch. Again, the Struts configuration files are generated by XDoclet from theprovided annotations.

Configuration Files

For the Struts core framework, all configuration information is defined in the struts-config.xml file (cf. Listing C.5, Listing C.6 ). This includes form bean definitions, action

2It is considered as a potential security risk, because confidential information could be afterwards availablein a non-secure context.

5.3. Business Tier 63

mapping definitions, global forward definitions, controller definition, as well as messageresource and plugin definitions. The Struts Validator framework lists its validators in thevalidator-rules.xml (cf. Listing C.8) and the validation configuration in the validation.xml file(cf. Listing C.9 ). Finally, the layout as used by Struts Tiles is defined in tiles-defs.xml (cf.Listing C.7 ). A global layout defines the general layout of the website, and extensionsallow to specify the required tiles for a certain group of pages. A concrete page extendssuch a definition and puts in the required jsp page for the view.

5.3. Business Tier

In the business tier, all of an application’s business logic is implemented. Further, itserves to move or translate data between the resource- and the presentation tier. Thislayer includes various J2EE design patterns (Business Delegate, Session Façade, ServiceLocator, Transfer Object), and the actual business logic is implemented by using EJBSession Beans.

5.3.1. Business Tier Patterns

For the reseda e-shop application, several J2EE design patterns are used: The SessionFaçade encapsulates business tier components and exposes a coarse grained service, theBusiness Delegate hides the complexity of remote communication, a Service Locator servesto retrieve components and services and the Transfer Object pattern is used to move databetween tiers.

Session Façade

The Session Façade pattern (cf. [ACM03, p. 341-356]) is used to “encapsulate business-tier 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 Façade. The Session Façade then calls the required busi-ness components and thus also hides the complex interactions and dependencies, reducesnetwork traffic, reduces coupling between layers and centralizes security and transactioncontrol. Usually, each use case of an application is implemented in a seperate SessionFaçade. 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 offered meth-ods of the SessionFacade, which then in turn invokes the required BusinessObjects andDataAccessObjects.

Business Delegate

The purpose of the Business Delegate pattern (cf. [ACM03, p. 302-314]) is to “encapsulateaccess to a business service” [ACM03, p. 303]. It abstracts and hides the details of theimplementation of the business services from the client, handles exceptions, can performretry or recovery operations or cache results. Usually, the services offered by a BusinessDelegate correspond to the ones implemented in a Session Façade. As such, this pattern


Figure 5.8.: Session Façade [ACM03, p. 344]

hides remoteness and provides a logical extension of the business tier, which is accessedfrom clients in the presentation tier like a normal Java object.The pattern (as seen in Figure 5.9), consists of the Client, who first creates a BusinessDele-gate. Afterwards, he invokes the offered services and the BusinessDelegate is charged withgetting or invoking the required BusinessService.

Service Locator

The Service Locator pattern (cf. [ACM03, p. 315-240]) helps to “implement and encap-sulate service and component lookup” [ACM03, p. 316]. It therefore hides the implemen-tation 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 first gets an instance of the ServiceLocator.The service locator then is concerned with creating or retrieving the requested service orcomponent by e.g. Java Naming and Directory Interface (JNDI), and the client receivesa reference or handle to the desired object.

Transfer Object

The Transfer Object (cf. [ACM03, p. 415-432]) can be used “to carry multiple dataelements accross a tier” [ACM03, p. 415]. The forces for this pattern are to reduce remoterequests accross a network and to increase network performance. Usually this patternis used together with the Business Delegate, where each method accepts or returns aTransfer Object.


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, whichafterwards 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 EJBSession Beans. There exists a stateless or stateful Session Bean for each use case of thespecification. A Session Bean requires a remote interface and remote home interface ora local interface and local home interface, or both. In addition, an EJB deploymentdescriptor and the JBoss specific jboss.xml descriptor for the Session Beans is needed. Forthe project, all the necessary interfaces and descriptors were generated with XDoclet fromthe annotations in the Session Beans. The Session Beans and deployment descriptors arethen packaged in a EJB jar archive and deployed together with the other components ofthe J2EE application in the EAR file.

Session Beans

A Session Bean is used to implement the business logic needed for a use case. Thesebeans can be either stateless or stateful, depending on weather they maintain some kindof conversational state or not. A client can lookup such a Session Bean with JNDI toinvoke some kind of business task on the server. For the reseda e-shop application, theyare mainly used to store or retrieve the online shop’s data. Listing D.3 shows a simplifiedversion 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 correspondingentries. The descriptor tells the J2EE application server which classes make up a beansimplementation, its properties like the JNDI name, as well as the services (e.g. transac-tion, security) it requires. Listing D.5 and Listing D.4 show the entries as generated byXDoclet 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 access-ing 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 thislayer 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 isnot used in a custom implementation, but actually already implemented in the interfaceprovided by Hibernate.

Data Access Object

The Data Access Object pattern (cf. [ACM03, p. 462-495] serves to “abstract and en-capsulate all access to the persistent store” [ACM03, p. 463]. Such an object managesthe connection with the resource tier to store and retrieve data. Hence, it decouples the


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

persistent storage from the application and provides a uniform data access API. As aconsequence, this pattern facilitates maintainability and portability of the application.The pattern (cf. Figure 5.12) basically consists of the Client that requires access to thedata and the DataAccessObject which abstracts the underlying data access implementation.The DataSource then represents the resource tier (e.g. a relational database) and the datato 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 byusing the Hibernate framework. Hibernate is an object/relational mapping tool, whichmaps Java beans to the tables and rows of a relational database by means of XMLmapping files. In addition to this mapping, the corresponding database schema canbe automatically generated and the framework also provides data query and retrievalfacilities. All Hibernate libraries, Java classes, XML mapping and configuration files arethen packaged in a HAR file and deployed together with the other components of theJ2EE application in the EAR file.Figure 5.13 shows a high level abstraction of the Hibernate architecture. Apart from theHibernate XML mapping files, a SessionFactory is created. An application obtains a ref-erence to this SessionFactory in order to get a Hibernate Session. The session is then usedto store or retrieve the required data by means of persistent objects. Hibernate workstogether with various support services, like transaction managers, connection pools orcaching services. They can be provided by a J2EE application server (managed envi-ronment), but it is also possible to run Hibernate in a standalone mode (nonmanagedenvironment), where the application offers the required services.


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

Hibernate Mapping Files

The purpose of the Hibernate XML mapping files is to provide the Hibernate frameworkwith information on how to persist objects to a relational database. In addition, thisinformation can also be used to generate the database schema.Such a mapping file (cf. Listing E.2) first declares the persistent Java class and thedatabase table it corresponds to. Each class then requires a unique id attribute, whichunambiguously identifies a row in the database table. Each property, component orcollection (e.g. set) is then mapped to the columns and tables of the database. Whena 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 files manually, they can alsobe generated with XDoclet from the annotations provided in the hibernate beans (cf.Listing E.1).

Session Factory

The configuration for the SessionFactory then is done by the hibernate.cfg.xml file. ThisXML file (cf. Listing E.3) declares the basic Hibernate properties like the StandardQuery Language (SQL) dialect to use or the database connection properties, as well asall the mappings. This configuration file can be automatically generated with XDocletfrom the XML mapping files.The configuration file serves to instantiate the Hibernate SessionFactory. The sessionfactory can be either created by the application, but it is also possible to generate anddeploy it as a JMX service on a compliant J2EE application server. In the case of


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 mappingand configuration files are packaged in a HAR file. The SessionFactory is instantiated onstartup of the application, the session is automatically bound to the scope of the JavaTransaction 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. Theseobjects are normal Java beans (with getter and setter methods), which implement theentities of an application’s business problems (e.g. product, category). Their state issynchronized with the content of the database, as defined in the mapping files.Listing E.5 outlines the required steps to work with such persistent objects. First, theSessionFactory 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 objectis treated like a normal Java bean and afterwards saved in the session. Likewise, anobject can be loaded from the session to get its values or it can be deleted. All changesdone to a persistent object are afterwards propagated to the database by the Hibernateframework.

6Conclusion

6.1. Achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.1.1. Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.1.2. Website Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.1.3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.2. Possible Enhancements . . . . . . . . . . . . . . . . . . . . . . . 72

6.3. Final Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

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

6.1. Achievements

The whole Reseda E-Shop project is entirely based on standard and free software andhence does not require any licence fees. The J2EE application implements most of thebest 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 anddevelopment of the application, a special effort was put into optimizing the website’sdesign and usability, and also the deployment of the final application in a productionenvironment showed to be a challenge.

6.1.1. Application

The Reseda E-Shop application offers all required functionalities of an online shop. Thisincludes the product catalog, product information, shopping basket, customer accountand order or consultings. In addition, also information concerning the company, contactpossibilities, news and support is provided on the website. All these storefront features

1The 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 anytechnological knowledge. This section outlines the main features of the online shop ap-plication, refer to the corresponding manuals (cf. [Res06a], [Res06e] and [Res06b]) fora more detailled explanation, or directly try out the application with the easy to installevaluation version (cf. [Res06c]).

The online shop’s product catalog (cf. Screenshot Figure A.1) structures the availableproducts into categories. An unlimited number of such categories can be defined andgrouped 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 HTMLpages as well as image galleries are available. A user can browse this catalog and obtaingeneral information as well as an overview over a category’s products.

The product information (cf. Screenshot Figure A.2) then is concerned with providinginformation to a specific product. This includes basic information like name, descriptionand 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 latercase a customer can choose between the offered options. First, the customer obtains anoverview over the available options for a product. In the customization, he then selectsthe 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, chosenoptions and price. The shopping basket’s content then can either be downloaded as a pdffile, the customer can request a consulting or order the items.

In the order process (cf. Screenshot Figure A.4), a customer first needs to create anaccount or login to his existing one. The account stores all the customer’s data as wellas all information concerning previous consultings and orders. To continue the orderprocess, the customer then controls his user data (e.g. address), selects the desiredcompany, payment option, delivery option and delivery date. He then checks the wholeorder, submits it and receives a confirmation by email. All information concerning theorder can afterwards be downloaded in a pdf file. The consulting process is similar,with the difference that a customer does not select a payment and delivery option, buta consulting option (email, phone or meeting) instead. All transmissions in the accountand the order or consulting process are secured by Secure Sockets Layer or Secure ServerLine (SSL) encryption.

Apart from the basic online shop functionalities, the website also provides general in-formation 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 providedonline and can be downloaded as a pdf. In addition, also job offers can be published onthe website. To contact the company, the customer is given the possibility to either fillout an online email or address form and submit it. The news section allows the companyto 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 supportarea, the customer can find 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 store-back 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 ac-count management and processing of the online orders or consultings. He can manage thecustomer accounts, process or create online orders and consultings and send consultinginformation per email to a customer. The administrator is responsible for the setup andmaintenance of the online shop. This includes the configuration of the general parametersof the application, user management, setting up the product catalog and managing theproducts, providing the company information, publishing news and maintaining supportoptions.

6.1.2. Website Design

For the use of this e-shop in a real production environment, one of the most importantissues 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 aconsequence, the website should reflect 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 acertain enterprise. Likewise, the usability (e.g. navigation, content, presentation, fastpage loading) is important, a customer quickly needs to find the desired information andwe 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 website’s layout and usability. This agency is responsible for allmarketing and advertising activities of Reseda. Based on their propositions and remarks,the website was afterwards optimized to reflect Reseda’s corporate identity and to meetthe 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 configure a Linux operating system for use in production.The important issues here are security and maintenance. While it is for example easyto use JBoss for development, as every feature already is installed, many of them needto 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 operatingsystem applications (e.g. ssh, firewall) need to be configured and additional ones (e.g.mailserver, webalizer) must be installed. The online shop application is now hosted byMetanet (cf. [28]) on a dedicated server.

6.2. Possible Enhancements

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

6.3. Final Thoughts 73

Concerning the technology involved for the online shop application, Struts showed tobe somehow rather tedious to programm and not very well suited for dynamic and richuser interfaces. It requires rather many classes to implement functionalities and doesnot provide sophisticated means to treat dynamic forms. Currently, the only alternativewould be using JSF, as other frameworks and technologies are not yet as mature. But inthe future, XML based technologies like e.g. XForms could provide these required richuser interfaces.While the online shop application itself implements most of the current standards fore-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 inorder to avoid the media disruption caused by printing out the information and enteringit manually in another system. Likewise, the stored information (e.g. orders) in thedatabase is currently not used for analytical purposes. Enhancements could thereforeinclude basic data analysis tools for the e-shop application or tools for the integrationinto e.g. a data warehouse.

6.3. Final Thoughts

For the project in general, it turned out to be difficult to plan and estimate the time neededto accomplish certain tasks. Especially the time required for the programming of theapplication, the deployment and the revision of the website’s layout was underestimated.As a consequence, the whole project was delayed and took about two months longer thanexpected.The choice of using J2EE, Struts and Hibernate as the main technologies for the appli-cation prooved to be a good combination. These technologies and frameworks are stableproduction versions and work together well. Another benefit of using these “standards”is their good documentation and the available tutorials, which makes learning the es-sentials and programming much easier. Especially using Hibernate in contrast to EJBEntity Beans was a great relief for the programming, as this framework provides muchbetter object to relational mapping possiblities and useful tools like e.g. for automaticallycreating the database schema.The implementation itself was accomplished without any major difficulties, but a con-siderable effort was required mainly for installing, configuring and understanding thevarious technologies. Nevertheless, there were always some minor problems (e.g. findingbugs, fixing some XDoclet tasks) which needed to be solved in order to continue theproject. But it somehow became difficult in time to unit test the application. The testingframeworks 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 definedstate, it takes about five minutes to test one single method. Likewise, as the project itselfis rather large3, some memory problems with Ant and XDoclet had to be fixed.The Reseda E-Shop project was an interesting an challenging master thesis, as it requiredto lead a real-world project from the beginning to the end. Starting from meeting theuser and discussing their requirements, to planning, implementing, testing and finally de-

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

6.3. Final Thoughts 74

ploying the application in a production environment, many fields of project managementand software development were involved. The online shop application itself reflects theneeds of the Reseda company: it allows to present their highly customizable productsonline, provide information concerning the company, publish news and send newsletters.Further, it integrates the website to their physical stores by means of the consulting andcontact possiblities, and the online orders provide an additional sales channel. In com-parison to the websites of other furniture companies, Reseda’s online presence will beleading in this market area.

AScreenshots

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

BAnt

79

80

1 <?xml vers ion=" 1.0 "?><!−− =================================================================== −−>

3 <!−− Reseda E−Shop Bu i ld F i l e −−><!−− =================================================================== −−>

5 < p r o j e c t name=" res " d e f a u l t = " d i s t ">

7 <!−− =================================================================== −−><!−− Proper t i es −−>

9 <!−− =================================================================== −−>

11 <!−− p r o j e c t name f i l e −−><proper ty name=" p r o j e c t . name . f i l e " value=" res " / >

13 <!−− deploy d i r e c t o r y −−><proper ty name=" deploy . d i r " value="C : \ Programme \ jboss −4.0.3\ server \ d e f a u l t \ deploy " / >

15 <!−− d i r e c t o r y p r o p e r t i e s −−><proper ty name=" src . d i r " value=" $ { based i r } / s rc " / >

17 <proper ty name=" java . src . d i r " value=" $ { src . d i r } / java " / ><proper ty name=" conf . d i r " value=" $ { src . d i r } / conf " / >

19 <proper ty name=" b u i l d . d i r " value=" $ { basedi r } / b u i l d " / ><proper ty name=" java . b u i l d . d i r " value=" $ { b u i l d . d i r } / java " / >

21 <proper ty name=" d i s t . d i r " value=" $ { basedi r } / d i s t " / ><proper ty name=" l i b . d i r " value=" $ { basedi r } / l i b " / >

23

25 <!−− =================================================================== −−><!−− Paths −−>

27 <!−− =================================================================== −−>

29 <!−− g loba l p r o j e c t c lasspaths −−><path i d =" p r o j e c t . c lasspath ">

31 <path >< f i l e s e t d i r = " $ { l i b . d i r } ">

33 < inc lude name=" ∗∗ /∗ . j a r " / ></ f i l e s e t >

35 <pathelement path=" $ { java . b u i l d . d i r } " / ></ path >

37 </ path >

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

81

<!−− =================================================================== −−>2 <!−− XDoclet −−>

<!−− =================================================================== −−>4 < t a r g e t name=" xdoc le t− i n i t " depends=" i n i t ">

< taskdef name=" h ibe rna tedoc le t " classname=" xdoc le t . modules . h iberna te . HibernateDocletTask "c l as spa th r e f = " p r o j e c t . c lasspath " / >

6 <taskdef name=" e j b d oc l e t " classname=" xdoc le t . modules . e jb . EjbDocletTask " c l asspa th re f = "p r o j e c t . c lasspath " / >

< taskdef name=" webdoclet " classname=" xdoc le t . modules . web . WebDocletTask " c l asspa th re f = "p r o j e c t . c lasspath " / >

8 </ ta rge t >

10 <!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−><!−− h ibe rna tedoc le t : generates h iberna te mapping and c o n f i g u r a t i o n f i l e s −−>

12 <!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−>< t a r g e t name=" xdoc le t−h ibe rna tedoc le t " depends=" xdoc le t− i n i t ">

14 < h ibe rna tedoc le t d e s t d i r = " $ { java . src . d i r } " excludedtags=" @version , @author , @todo" addedtags=" @xdoclet−generated a t $ {TODAY} " fo rce=" f a l s e " verbose=" t rue ">

< f i l e s e t d i r = " $ { java . src . d i r } ">16 < inc lude name=" ∗∗ / h iberna te / ∗ ∗ / ∗ . java " / >

</ f i l e s e t >18 <h iberna te vers ion=" 3.0 " / >

<h ibe rna tec fg vers ion=" 3.0 " des tD i r= " $ { conf . d i r } / h iberna te " d r i v e r = " $ { db . d r i v e r } "j dbcUr l = " $ { db . u r l } " userName=" $ { db . user id } " password=" $ { db . password } " poolSize=" 10 "d i a l e c t = " org . h iberna te . d i a l e c t . MySQLDialect " showSql= " f a l s e " / >

20 </ h ibe rna tedoc le t ></ ta rge t >

22

<!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−>24 <!−− e j bd o c l e t : generates e jb i n t e r f aces , dep loymentdescr ip tor −−>

<!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−>26 < t a r g e t name=" xdoc le t−e j bd o c l e t " depends=" xdoc le t− i n i t ">

< e j b do c l e t d e s t d i r = " $ { java . src . d i r } " excludedtags=" @version , @author , @todo" addedtags="@xdoclet−generated a t $ {TODAY} " ejbspec=" 2.1 " fo rce=" f a l s e ">

28 < f i l e s e t d i r = " $ { java . src . d i r } ">< inc lude name=" ∗∗ /∗ . java " / >

30 <exclude name=" ∗∗ /∗Adaptor . java " / ></ f i l e s e t >

32 < l o c a l i n t e r f a c e / >< loca lhome in te r face / >

34 <deploymentdescr ip tor d e s t d i r = " $ { conf . d i r } / e jb " val idateXML=" t rue " / >< jboss vers ion=" 4.0 " secur i tydomain=" java : / jaas / app−res " d e s t d i r = " $ { conf . d i r } / e jb "

val idateXML=" t rue " / >36 </ e jbdoc le t >

</ ta rge t >38

<!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−>40 <!−− webdoclet : generates web . xml , s t r u t s−conf ig , v a l i d a t o r f i l e s −−>

<!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−>42 < t a r g e t name=" xdoc le t−webdoclet " depends=" xdoc le t− i n i t ">

<webdoclet des tD i r= " $ { conf . d i r } / web" excludedTags=" @author , @version , @todo" addedtags="@xdoclet−generated a t $ {TODAY} ">

44 < f i l e s e t d i r = " $ { java . src . d i r } ">< inc lude name=" ∗∗ /∗ . java " / >

46 </ f i l e s e t ><!−− web deployment d e s c r i p t o r −−>

48 <deploymentdescr ip tor se rv le tspec=" 2.4 " d e s t d i r = " $ { conf . d i r } / web" mergeDir= " $ { conf . d i r } /web / merge " displayname=" res " val idateXML=" t rue " / >

<!−− jboss web deployment d e s c r i p t o r −−>50 <jbosswebxml vers ion=" 4.0 " secur i tydomain=" java : / jaas / app−res " d e s t d i r = " $ { conf . d i r } / web"

val idateXML=" t rue " / ><!−− s t r u t s −−>

52 < s t r u t s c o n f i g x m l vers ion=" 1.2 " des tD i r= " $ { conf . d i r } / s t r u t s / core " mergeDir= " $ { conf . 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 . con f i g . SecureAct ionConf ig "val idateXML=" t rue " / >

< s t r u t s v a l i d a t i o n x m l vers ion=" 1 .1 .3 " des tD i r= " $ { conf . d i r } / s t r u t s / v a l i d a t o r " val idateXML=" t rue " / >

54 <!−− 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 = " res−tags . t l d " shortName=" res " xmlencoding="UTF−8" j spve rs i on

=" 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 the res a p p l i c a t i o n . " / >56 </ webdoclet >

</ ta rge t >


82

2 <!−− =================================================================== −−><!−− Hibernate Schema −−>

4 <!−− =================================================================== −−><path i d =" h iberna te . schema . c lasspath ">

6 <path >< f i l e s e t d i r = " $ { l i b . d i r } / h iberna te ">

8 < inc lude name=" ∗ . j a r " / ></ f i l e s e t >

10 < f i l e s e t d i r = " $ { l i b . d i r } / mysql ">< inc lude name=" ∗ . j a r " / >

12 </ f i l e s e t >< f i l e s e t d i r = " $ { l i b . d i r } / commons">

14 < inc lude name=" ∗ . j a r " / ></ f i l e s e t >

16 < f i l e s e t d i r = " $ { l i b . d i r } / l o g 4 j ">< inc lude name=" ∗ . j a r " / >

18 </ f i l e s e t ><pathelement path=" $ { java . b u i l d . d i r } " / >

20 </ path ></ path >

22 < t a r g e t name=" h ibernate− i n i t " depends=" i n i t ">< taskdef name=" schemaexport " classname=" org . h iberna te . t o o l . hbm2ddl . SchemaExportTask "

c l as spa th r e f = " h iberna te . schema . c lasspath " / >24 <taskdef name=" schemaupdate " classname=" org . h iberna te . t o o l . hbm2ddl . SchemaUpdateTask "

c l as spa th r e f = " h iberna te . schema . c lasspath " / ></ ta rge t >

26

<!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−>28 <!−− hibernate−schemaexport− f i l e : expor ts the schema to a f i l e −−>

<!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−>30 < t a r g e t name=" h ibernate−schemaexport− f i l e " depends=" compile−java , h ibernate− i n i t ">

<schemaexport con f i g = " $ { conf . d i r } / h iberna te / h iberna te . c fg . xml " output= " $ { sq l . d i r } / $ { db .s c r i p t . schema } " qu ie t = " no " t e x t = " yes " drop=" no " d e l i m i t e r = " ; " / >

32 </ ta rge t >

34 <!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−><!−− hibernate−schemaexport−f i l e −drop : expor ts the drop schema to a f i l e −−>

36 <!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−>< t a r g e t name=" h ibernate−schemaexport−f i l e −drop " depends=" compile−java , h ibernate− i n i t ">

38 <schemaexport con f i g = " $ { conf . d i r } / h iberna te / h iberna te . c fg . xml " output= " $ { sq l . d i r } / $ { db .s c r i p t . drop } " qu i e t = " no " t e x t = " yes " drop=" yes " d e l i m i t e r = " ; " / >

</ ta rge t >40

<!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−>42 <!−− hibernate−schemaexport−db : expor ts the schema to the db −−>

<!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−>44 < t a r g e t name=" h ibernate−schemaexport−db " depends=" compile−java , h ibernate− i n i t ">

<schemaexport con f i g = " $ { conf . d i r } / h iberna te / h iberna te . c fg . xml " qu i e t = " no " t e x t = " no " drop="no " d e l i m i t e r = " ; " / >

46 </ ta rge t >

48 <!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−><!−− hibernate−schemaexport−db−drop : drops the schema of the db −−>

50 <!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−>< t a r g e t name=" h ibernate−schemaexport−db−drop " depends=" compile−java , h ibernate− i n i t ">

52 <schemaexport con f i g = " $ { conf . d i r } / h iberna te / h iberna te . c fg . xml " qu i e t = " no " t e x t = " no " drop="yes " d e l i m i t e r = " ; " / >

</ ta rge t >54

<!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−>56 <!−− hibernate−schemaupdate−db : updates the schema of the db −−>

<!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−>58 < t a r g e t name=" h ibernate−schemaupdate−db " depends=" compile−java , h ibernate− i n i t ">

<schemaupdate con f i g = " $ { conf . d i r } / h iberna te / h iberna te . c fg . xml " qu i e t = " no " t e x t = " no " / >60 </ ta rge t >


83

2 <!−− =================================================================== −−><!−− b u i l d −−>

4 <!−− =================================================================== −−>

6 <!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−><!−− compile : compiles the source −−>

8 <!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−>< t a r g e t name=" clean−java−b u i l d ">

10 <de le te d i r = " $ { java . b u i l d . d i r } " / ><mkdir d i r = " $ { java . b u i l d . d i r } " / >

12 </ ta rge t >< t a r g e t name=" resources−java ">

14 <copy t o d i r = " $ { java . b u i l d . d i r } ">< f i l e s e t d i r = " $ { java . src . d i r } ">

16 <exclude name=" ∗∗ /∗ . java " / ><exclude name=" ∗∗ /∗ . c lass " / >

18 </ f i l e s e t ></copy>

20 </ ta rge t >< t a r g e t name=" compile−java " depends=" clean−java−bu i ld , resources−java ">

22 <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 } " c l asspa t h re f = " p r o j e c t .c lasspath " debug=" on " deprecat ion=" on " opt im ize=" o f f " / >

</ ta rge t >24

26 <!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−><!−− bu i ld−har : c reates the h iberna te har arch ive −−>

28 <!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−>< t a r g e t name=" bu i ld−har ">

30 < 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 "><!−− classes −−>

32 < f i l e s e t d i r = " $ { java . b u i l d . d i r } ">< inc lude name=" ∗∗ / h iberna te /∗∗ /∗ .∗ " / >

34 </ f i l e s e t ><!−− conf −−>

36 <meta in f d i r = " $ { conf . d i r } / h iberna te ">< inc lude name=" jboss−serv i ce . xml " / >

38 </ metainf ><!−− bundled l i b r a r i e s −−>

40 <manifest >< a t t r i b u t e name=" Class−Path " value="commons−b e an u t i l s . j a r oscache . j a r " / >

42 </ mani fest ><!−− server l i b r a r i e s i n jboss / server / d e f a u l t / l i b −−>

44 <!−− h iberna te j a r s −−></ j a r >

46 </ ta rge t >

48 <!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−><!−− bu i ld−e jb : creates the e jb j a r a rch ive −−>

50 <!−− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − −−>< t a r g e t name=" bu i ld−e jb ">

52 < 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 }−ejb . j a r "><!−− classes −−>

54 < f i l e s e t d i r = " $ { java . b u i l d . d i r } ">< inc lude name=" ∗∗ / e jb / ∗ ∗ / ∗ . c lass " / >

56 </ f i l e s e t ><!−− conf −−>

58 <meta in f d i r = " $ { conf . d i r } / e jb ">< inc lude name=" ∗ .∗ " / >

60 </ metainf ><!−− c l i e n t −−>

62 <manifest >< a t t r i b u t e name=" Class−Path " value=" $ { p r o j e c t . name . f i l e }− c l i e n t . j a r " / >

64 </ mani fest ><!−− server l i b r a r i e s i n jboss / server / d e f a u l t / l i b −−>

66 <!−− h iberna te j a r s −−><!−− l o g 4 j j a r s and conf −−>

68 </ j a r ></ ta rge t >

70 </ p ro jec t >


CStruts

84

85

/∗ ∗2 ∗ S t r u t s form ho ld ing product i npu t .

∗ @struts . form4 ∗ name = " ProductForm "

∗ v a l i d a t e = " t r ue "6 ∗ /

p u b l i c c lass ProductForm extends AAdminValidatorForm {8 /∗

∗ F ie lds10 ∗ /

p r i v a t e Long produc t Id ;12 p r i v a t e S t r i n g productName ;

p r i v a t e Map productCategor ies ;14 /∗ ∗

∗ Creates a new ins tance .16 ∗ /

p u b l i c ProductForm ( ) {18 super ( ) ;

t h i s . productCategor ies = new TreeMap ( ) ;20 }

/∗ ∗22 ∗ Va l ida tes the form .

∗ @param mapping The ac t i on mapping .24 ∗ @param request The h t t p request .

∗ @return The ac t i on e r r o r s .26 ∗ /

p u b l i c Ac t i onEr ro rs v a l i d a t e ( ActionMapping mapping ,28 HttpServ le tRequest request ) {

Ac t i onEr ro rs e r r o r s = new Ac t ionEr ro rs ( ) ;30 e r r o r s . add ( super . v a l i d a t e ( mapping , request ) ) ;

r e t u r n e r r o r s ;32 }

/∗ ∗34 ∗ Resets the form .

∗ @param mapping The ac t i on mapping .36 ∗ @param request The h t t p request .

∗ /38 p u b l i c vo id rese t ( ActionMapping mapping , Ht tpServ le tRequest request ) {

super . rese t ( mapping , request ) ;40 }

/∗ ∗42 ∗ I n i t i a l i z e s the form .

∗ @param product The product bean .44 ∗ @exception St ru tsExcep t ion

∗ /46 p u b l i c vo id setForm ( Product product ) throws St ru tsExcep t ion {

t h i s . se t ( product ) ;48 t h i s . productCategor ies = super . generateCategoriesMap ( product . getCategor ies ( ) ) ;

}50 /∗ ∗

∗ I n i t i a l i z e s a blank form .52 ∗ @param supportedLocales The supportedLocales .

∗ @param productType The product type bean .54 ∗ @exception St ru tsExcep t ion

∗ @exception BeanToolsException56 ∗ /

p u b l i c vo id setBlankForm ( ProductType productType , C o l l e c t i o n supportedLocales ) throwsSt ru tsExcept ion , BeanToolsException {

58 t h i s . se t ( productType ) ;}

60 /∗ ∗∗ Populates the bean .

62 ∗ @param product The bean .∗ @throws BeanToolsException

64 ∗ @exception IOExcept ion∗ /

66 p u b l i c vo id populateBean ( Product product ) throws BeanToolsException ,IOExcept ion {

68 product . se t ( t h i s ) ;product . se tCategor ies ( t h i s . getProductCategor ies ( ) ) ;

70 }

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

86

/∗ ∗2 ∗ Gets the produc t Id .

∗ @return Returns the produc t Id .4 ∗ /

p u b l i c Long getProduct Id ( ) {6 r e t u r n t h i s . p roduc t Id ;

}8 /∗ ∗

∗ Sets the produc t Id .10 ∗ @param produc t Id The produc t Id to set .

∗ /12 p u b l i c vo id se tProduc t Id ( Long produc t Id ) {

t h i s . p roduc t Id = produc t Id ;14 }

/∗ ∗16 ∗ Gets the productName .

∗ @return Returns the productName .18 ∗ /

p u b l i c S t r i n g getProductName ( ) {20 r e t u r n t h i s . productName ;

}22 /∗ ∗

∗ Sets the productName .24 ∗ @param productName The productName to set .

∗ @struts . v a l i d a t o r type =" requ i red " msgvalue = " product name i s requ i red "26 ∗ /

p u b l i c vo id setProductName ( S t r i n g productName ) {28 t h i s . productName = productName ;

}30 /∗ ∗

∗ Adds the product to the category .32 ∗ @param category The bean .

∗ /34 p u b l i c vo id addCategory ( Category category ) {

i f ( ! t h i s . productCategor ies . containsKey ( category . getCategoryId ( ) ) ) {36 t h i s . productCategor ies . put ( category . getCategoryId ( ) , category ) ;

}38 }

/∗ ∗40 ∗ Removes the product from the category .

∗ @param ca t I d The i d .42 ∗ /

p u b l i c vo id removeCategory ( S t r i n g ca t I d ) {44 Category category = ( Category ) t h i s . productCategor ies . get (new Long ( ca t I d ) ) ;

category . setRemoveProduct ( t r ue ) ;46 }

/∗ ∗48 ∗ Gets the ca tegor ies .

∗ @return The c o l l e c t i o n .50 ∗ /

p u b l i c C o l l e c t i o n getProductCategor ies ( ) {52 r e t u r n t h i s . productCategor ies . values ( ) ;

}54 }

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

87

/∗ ∗2 ∗ S t r u t s ac t i on to save or update a product .

∗ @struts . ac t i on4 ∗ path = " / sb / a d m i n i s t r a t o r / productMgmt / saveOrUpdateProduct "

∗ type = " ch . u n i f r . res . web . s t r u t s . sb . a d m i n i s t r a t o r . productMgmt . ac t i on .SaveOrUpdateProductAction "

6 ∗ name = " ProductForm "∗ i npu t = " page . sb . a d m i n i s t r a t o r . productMgmt . productForm "

8 ∗ scope = " session "∗ v a l i d a t e = " f a l s e "

10 ∗∗ @struts . ac t ion−forward

12 ∗ name=" form "∗ path ="page . sb . a d m i n i s t r a t o r . productMgmt . productForm "

14 ∗∗ @struts . ac t ion−set−proper ty

16 ∗ proper ty =" secure " value =" f a l s e "∗ /

18 p u b l i c c lass SaveOrUpdateProductAction extends ProductManagementAction {

20 /∗ ∗∗ Creates a new ins tance .

22 ∗ /p u b l i c SaveOrUpdateProductAction ( ) {

24 super ( SaveOrUpdateProductAction . c lass ) ;}

26

/∗ ∗28 ∗ Executes the ac t i on .

∗ @param mapping The ac t i on mapping .30 ∗ @param form The form .

∗ @param request The h t t p request .32 ∗ @param response The h t t p response .

∗ @return The ac t i on forward .34 ∗ @exception IOExcept ion

∗ @exception Serv le tExcept ion36 ∗ /

p u b l i c Act ionForward execute ( ActionMapping mapping , ActionForm form ,38 HttpServ le tRequest request , HttpServletResponse response )

throws IOException , Serv le tExcept ion {40 super . logDebug ( " execute . . . " ) ;

t r y {42 / / get session

HttpSession session = request . getSession ( ) ;44

/ / get i npu t46 ProductForm productForm = ( ProductForm ) form ;

48 / / parameter addS t r i n g add= request . getParameter ( St ru tsConstants .PARAM_ADD) ;

50 i f ( ! super . i sB lank ( add ) ) {i f ( add . equalsIgnoreCase ( " category " ) ) {

52 Long category Id = productForm . getSelectedAddCategoryId ( ) ;Category category = super . getSess ionCol lec t ionCategory ( request , ca tegory Id

) ;54 productForm . addCategory ( category ) ;

session . s e t A t t r i b u t e ( St ru tsConstants .FORM_PRODUCT, productForm ) ;56 super . l o g I n f o ( "Add category : parameter = " + add + " , i d = " + category Id )

;request . s e t A t t r i b u t e ( St ru tsConstants .PARAM_HASH, " # ca tegor ies " ) ;

58 r e t u r n ( mapping . f indForward ( " form " ) ) ;}

60 }

62 / / parameter remove categoryS t r i n g remCat = request . getParameter ( St ru tsConstants .PARAM_REMOVECATEGORY) ;

64 i f ( ! super . i sB lank ( remCat ) ) {productForm . removeCategory ( remCat ) ;

66 session . s e t A t t r i b u t e ( St ru tsConstants .FORM_PRODUCT, productForm ) ;super . l o g I n f o ( "Remove category : parameter = " + remCat ) ;

68 request . s e t A t t r i b u t e ( St ru tsConstants .PARAM_HASH, " # ca tegor ies " ) ;r e t u r n ( mapping . f indForward ( " form " ) ) ;

70 }

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

88

/ / ac t i on2 S t r i n g actionParam = request . getParameter ( St ru tsConstants .PARAM_ACTION) ;

i f ( ! super . i sB lank ( actionParam ) ) {4 / / save

i f ( actionParam . equalsIgnoreCase ( St ru tsConstants .PARAM_ACTION_SAVE) ) {6 / / v a l i d a t e

ActionMessages e r r o r s = productForm . v a l i d a t e ( mapping , request ) ;8 i f ( ! e r r o r s . isEmpty ( ) ) {

t h i s . saveErrors ( request , e r r o r s ) ;10 r e t u r n (new ActionForward ( mapping . ge t Inpu t ( ) ) ) ;

}12 / / bean

Product product = new Product ( ) ;14 productForm . populateBean ( product ) ;

16 / / update on dbIProductMgmtDelegate productMgmtDelegate = new ProductMgmtDelegate ( ) ;

18 Long prodId = productMgmtDelegate . saveOrUpdateProduct ( product ) ;super . l o g I n f o ( " Product updated : prod i d = " + prodId ) ;

20 }/ / cancel

22 else i f ( actionParam . equalsIgnoreCase ( St ru tsConstants .PARAM_ACTION_CANCEL) ) {super . l o g I n f o ( " Cancel ac t i on . " ) ;

24 }}

26

/ / success28 r e t u r n super . execute ( mapping , form , request , response ) ;

30 } catch ( DelegateExcept ion e ) {super . logWarn ( " DelegateExcept ion : " + e . getMessage ( ) ) ;

32 r e t u r n super . handleStorebackErrorB2I ( request , mapping , e , " e r r o r saving theproduct " ) ;

} catch ( BeanToolsException e ) {34 super . logWarn ( " BeanToolsException : " + e . getMessage ( ) ) ;

r e t u r n super . handleStorebackErrorB2I ( request , mapping , e , " e r r o r saving theproduct " ) ;

36 } catch ( S t ru tsExcep t ion e ) {super . logWarn ( " S t ru tsExcep t ion : " + e . getMessage ( ) ) ;

38 r e t u r n super . handleStorebackErrorB2I ( request , mapping , e , " e r r o r saving theproduct " ) ;

} catch ( Except ion e ) {40 super . logWarn ( " Except ion : " + e . getMessage ( ) ) ;

r e t u r n super . handleStorebackErrorB2I ( request , mapping , e , " e r r o r saving theproduct " ) ;

42 }}

44 }

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

89

<?xml vers ion=" 1.0 " encoding="UTF−8" ?>2 <!DOCTYPE s t r u t s−con f i g PUBLIC " − / /Apache Software Foundation / / DTD S t r u t s Con f i gu ra t i on 1 . 2 / /

EN" " h t t p : / / j a k a r t a . apache . org / s t r u t s / dtds / s t r u t s−conf ig_1_2 . dtd ">

4 < s t r u t s−conf ig >

6 <!−− ========== Form Bean D e f i n i t i o n s =================================== −−><form−beans>

8 <form−beanname=" ProductForm "

10 type=" ch . u n i f r . res . web . s t r u t s . sb . a d m i n i s t r a t o r . productMgmt . form . ProductForm "/ >

12 </ form−beans>

14 <!−− ========== Act ion Mapping D e f i n i t i o n s =================================== −−><act ion−mappings type=" org . apache . s t r u t s . con f i g . SecureAct ionConf ig ">

16 <ac t i onpath=" / sb / a d m i n i s t r a t o r / productMgmt / saveOrUpdateProduct "

18 type=" ch . u n i f r . res . web . s t r u t s . sb . a d m i n i s t r a t o r . productMgmt . ac t i on .SaveOrUpdateProductAction "

name=" ProductForm "20 scope=" session "

i npu t = " page . sb . a d m i n i s t r a t o r . productMgmt . productForm "22 unknown=" f a l s e "

v a l i d a t e =" f a l s e "24 >

<set−proper ty26 proper ty= " secure "

value=" f a l s e "28 / >

<forward30 name=" form "

path=" page . sb . a d m i n i s t r a t o r . productMgmt . productForm "32 r e d i r e c t = " f a l s e "

/ >34 <forward

name=" success "36 path=" page . sb . a d m i n i s t r a t o r . productMgmt . productManagement "

r e d i r e c t = " f a l s e "38 / >

<forward40 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 "42 r e d i r e c t = " f a l s e "

/ >44 </ act ion >

</ ac t ion−mappings>

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

90

1

<!−− ========== Global Forward D e f i n i t i o n s =================================== −−>3 <globa l−forwards >

<forward5 name=" sb−admin i s t ra to r−productMgmt−productManagement "

path=" / sb / a d m i n i s t r a t o r / productMgmt / productManagement . do " / >7 </ g loba l−forwards >

9 <!−− ========== 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 processorClass=" org . apache . s t r u t s . ac t i on . SecureTi lesRequestProcessor " / >

11

<!−− ========== Message Resources D e f i n i t i o n =================================== −−>13 <message−resources

f a c t o r y = " ch . u n i f r . res . web . s t r u t s . messages . ResMessageResourcesFactory "15 parameter= " . "

/ >17

<!−− ========== Plug in D e f i n i t i o n s =================================== −−>19 <plug−i n className=" org . apache . s t r u t s . t i l e s . SecureT i lesP lug in ">

<set−proper ty p roper ty= " d e f i n i t i o n s−con f i g " value=" /WEB−INF / conf / t i l e s−defs . xml " / >21 </ plug−in >

<plug−i n className=" org . apache . s t r u t s . v a l i d a t o r . Va l i da to rP lug In ">23 <set−proper ty p roper ty= " pathnames " value=" /WEB−INF / conf / v a l i d a t o r−r u l es . xml , /WEB−INF / conf /

v a l i d a t i o n . xml " / ></ plug−in >

25 <plug−i n className=" org . apache . s t r u t s . ac t i on . SecurePlugIn "><set−proper ty p roper ty= " h t t p P o r t " value=" 80 " / >

27 <set−proper ty p roper ty= " h t t p sP o r t " value=" 443 " / ><set−proper ty p roper ty= " enable " value=" t rue " / >

29 <set−proper ty p roper ty= " addSession " value=" t rue " / ></ plug−in >

31 </ s t r u t s−conf ig >

Listing C.6: Struts Core Configuration (Part 2/2): struts-config.xml

1 <?xml vers ion=" 1.0 " encoding=" ISO−8859−1" ?><!DOCTYPE t i l e s−d e f i n i t i o n s PUBLIC

3 " − //Apache Software Foundation / / DTD T i l e s Con f i gu ra t i on 1 . 1 / /EN"" h t t p : / / j a k a r t a . apache . org / s t r u t s / dtds / t i l e s−conf ig_1_1 . dtd ">

5

< t i l e s−d e f i n i t i o n s >7

<!−− g loba l l ayou t −−>9 < d e f i n i t i o n name=" layou t . s imple " path=" / l ayou t / s imple . j sp ">

<put name=" nav iga t ion−main " value=" $ { nav iga t ion−main } " / >11 <put name=" content " value=" $ { content } " / >

</ d e f i n i t i o n >13

<!−− l ayou t a d m i n i s t r a t o r −−>15 < d e f i n i t i o n name=" layou t . s imple . sb . a d m i n i s t r a t o r " extends=" layou t . s imple ">

<put name=" nav iga t ion−main " value=" / 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 sp " / >17 </ d e f i n i t i o n >

19 <!−− l ayou t product 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=" layou t .

s imple . sb . a d m i n i s t r a t o r ">21 <put name=" content " value=" / pages / sb / a d m i n i s t r a t o r / productMgmt / productManagement . j sp " / >

</ d e f i n i t i o n >23 < 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=" layou t . s imple .

sb . a d m i n i s t r a t o r "><put name=" content " value=" / pages / sb / a d m i n i s t r a t o r / productMgmt / productForm . j sp " / >

25 </ d e f i n i t i o n >

27 </ t i l e s−d e f i n i t i o n s >

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

91

1 <!DOCTYPE form−v 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 Con f i gu ra t i on 1 . 1 . 3 / /EN"

3 " h t t p : / / j a k a r t a . apache . org / commons / dtds / va l ida tor_1_1_3 . dtd ">

5 <form−v a l i d a t i o n >

7 <globa l >< v a l i d a t o r name=" requ i red "

9 classname=" org . apache . s t r u t s . v a l i d a t o r . FieldChecks "method=" va l ida teRequ i red "

11 methodParams=" java . lang . Object ,org . apache . commons . v a l i d a t o r . Va l i da to rAc t i on ,

13 org . apache . commons . v a l i d a t o r . F ie ld ,org . apache . s t r u t s . ac t i on . ActionMessages ,

15 org . apache . commons . v a l i d a t o r . Va l i da to r ,javax . s e r v l e t . h t t p . Ht tpServ le tRequest "

17 msg=" e r r o r s . requ i red " / >

19 < v a l i d a t o r name=" emai l "classname=" org . apache . s t r u t s . v a l i d a t o r . FieldChecks "

21 method=" va l i da teEma i l "methodParams=" java . lang . Object ,

23 org . apache . commons . v a l i d a t o r . Va l i da to rAc t i on ,org . apache . commons . v a l i d a t o r . F ie ld ,

25 org . apache . s t r u t s . ac t i on . ActionMessages ,org . apache . commons . v a l i d a t o r . Va l i da to r ,

27 javax . s e r v l e t . h t t p . Ht tpServ le tRequest "depends=" "

29 msg=" e r r o r s . emai l " / >

31 </ g loba l ></ form−v a l i d a t i o n >

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

<?xml vers ion=" 1.0 " encoding="UTF−8" ?>2 <!DOCTYPE form−v 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

Con f i gu ra t i on 1 . 1 . 3 / /EN" " h t t p : / / j a k a r t a . apache . org / commons / dtds / va l ida tor_1_1_3 . dtd ">

4 <form−v a l i d a t i o n ><formset >

6 <form name=" ProductForm ">< f i e l d p roper ty= " productName "

8 depends=" requ i red "><msg

10 name=" requ i red "key=" product name i s requ i red "

12 resource=" f a l s e " / >

14 <arg0 key=" ProductForm . productName " / ></ f i e l d >

16 </ form ></ formset >

18 </ form−v a l i d a t i o n >

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

DEJB

92

93

1 /∗ ∗∗ Delegate f o r the ProductMgmt use case .

3 ∗ /p u b l i c c lass ProductMgmtDelegate extends ABaseDelegate implements IProductMgmtDelegate {

5

/∗ F ie lds7 ∗ /

p r i v a t e ProductMgmtSessionLocal productMgmtSession ;9

/∗ ∗11 ∗ Creates a new ins tance .

∗ @exception DelegateExcept ion13 ∗ /

p u b l i c ProductMgmtDelegate ( ) throws DelegateExcept ion {15 super ( ProductMgmtDelegate . c lass ) ;

t r y {17 / / i n i t session bean

ProductMgmtSessionLocalHome home = ( ProductMgmtSessionLocalHome ) Serv iceLocator .ge t Ins tance ( ) . getLocalHome ( " ProductMgmtSessionLocal " ) ;

19 t h i s . productMgmtSession = home . create ( ) ;} catch ( Serv iceLocatorExcept ion e ) {

21 throw new DelegateExcept ion ( e ) ;} catch ( CreateExcept ion e ) {

23 throw new DelegateExcept ion ( e ) ;}

25 }

27 /∗ ∗∗ Saves or updates a product .

29 ∗ @param product The product bean .∗ @return The product i d .

31 ∗ @throws DelegateExcept ion∗ /

33 p u b l i c Long saveOrUpdateProduct ( Product product ) throws DelegateExcept ion {super . logDebug ( " saveOrUpdateProduct . . . " ) ;

35 t r y {r e t u r n t h i s . productMgmtSession . saveOrUpdateProduct ( product ) ;

37 } catch ( EJBException e ) {throw new DelegateExcept ion ( e ) ;

39 }}

41 }

Listing D.1: Business Delegate: ProductMgmtDelegate.java

1 /∗ ∗∗ I n t e r f a c e f o r the ProductMgmt delegate .

3 ∗ /p u b l i c i n t e r f a c e IProductMgmtDelegate {

5 /∗ ∗∗ Saves or updates a product .

7 ∗ @param product The product bean .∗ @return The product i d .

9 ∗ @throws DelegateExcept ion∗ /

11 p u b l i c abs t r ac t Long saveOrUpdateProduct ( Product product ) throws DelegateExcept ion ;}

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

94

/∗ ∗2 ∗ SessionBean f o r the ProductMgmt use case .

∗ @ejb . bean4 ∗ name=" ProductMgmtSession "

∗ d isp lay−name=" ProductMgmtSession "6 ∗ d e s c r i p t i o n =" SessionBean f o r the ProductMgmt use case "

∗ j n d i−name=" e jb / ProductMgmtSession "8 ∗ type =" S ta te less "

∗ view−type =" l o c a l " ∗10 ∗ @ejb . home

∗ l o ca l−c lass = " ch . u n i f r . res . e jb . ProductMgmtSessionLocalHome "12 ∗ l o ca l−extends = " javax . e jb . EJBLocalHome " ∗

∗ @ejb . i n t e r f a c e14 ∗ l o ca l−c lass = " ch . u n i f r . res . e jb . ProductMgmtSessionLocal "

∗ l o ca l−extends = " javax . e jb . EJBLocalObject " ∗16 ∗ @ejb . t r a n s a c t i o n

∗ type = " Required "18 ∗ /

p u b l i c c lass ProductMgmtSessionBean extends SessionBeanAdaptor {20 SessionFactory hbSessionFactory ;

/∗ ∗22 ∗ Creates a new ins tance .

∗ /24 p u b l i c ProductMgmtSessionBean ( ) {

super ( ProductMgmtSessionBean . c lass ) ;26 }

/∗ ∗28 ∗ Defau l t c reate method .

∗ @throws CreateExcept ion30 ∗ @ejb . create−method

∗ @ejb . permiss ion unchecked = " t rue "32 ∗ /

p u b l i c vo id ejbCreate ( ) throws CreateExcept ion {34 t r y {

/ / i n i t h iberna te session36 t h i s . hbSessionFactory = ( SessionFactory ) Serv iceLocator . ge t Ins tance ( ) .

getJndiResource ( " java : h iberna te / RESSessionFactory " ) ;} catch ( Serv iceLocatorExcept ion e ) {

38 throw new CreateExcept ion ( e . getMessage ( ) ) ;}

40 }/∗ ∗

42 ∗ Business method to save or update a product .∗ @param product The product bean .

44 ∗ @return The product i d .∗ @exception javax . e jb . EJBException

46 ∗ @ejb . i n t e r f a c e−method view−type = " l o c a l "∗ @ejb . permiss ion ro le−name = " Admin i s t r a to r "

48 ∗ /p u b l i c Long saveOrUpdateProduct ( Product product ) throws EJBException {

50 super . logDebug ( " saveOrUpdateProduct . . . " ) ;Long produc t Id = n u l l ;

52 t r y {/ / get cu r ren t h iberna te session

54 Session hsession = t h i s . hbSessionFactory . getCurrentSession ( ) ;/ / c reate product

56 ProductHB productHB = new ProductHB ( ) ;productHB . set ( product ) ;

58 / / add to ca tegor iesC o l l e c t i o n ca tegor ies = product . getCategor ies ( ) ;

60 i f ( ca tegor ies != n u l l ) {I t e r a t o r i t e r a t o r = ca tegor ies . i t e r a t o r ( ) ;

62 whi le ( i t e r a t o r . hasNext ( ) ) {Category category = ( Category ) i t e r a t o r . next ( ) ;

64 CategoryHB categoryHB = ( CategoryHB ) hsession . load ( CategoryHB . class ,category . getCategoryId ( ) ) ;

productHB . setAssociat ionCategoryHB ( categoryHB ) ;66 }

}68 / / save

hsession . saveOrUpdate ( productHB ) ;70 produc t Id = productHB . getProduct Id ( ) ;

} catch ( HibernateExcept ion e ) {72 throw new EJBException ( e ) ;

}74 r e t u r n produc t Id ;

}76 }

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

95

<?xml vers ion=" 1.0 " encoding="UTF−8"?>2 <ejb−j a r xmlns=" h t t p : / / java . sun . com/ xml / ns / j2ee " xmlns : x s i = " h t t p : / / www.w3 . org /2001/XMLSchema−

i ns tance " x s i : schemaLocation=" h t t p : / / java . sun . com/ xml / ns / j2ee h t t p : / / java . sun . com/ xml / ns /j2ee / ejb−jar_2_1 . xsd " vers ion=" 2.1 ">

4 < desc r i p t i on > <! [CDATA[No Desc r i p t i on . ] ] > < / desc r i p t i on ><d isp lay−name>Generated by XDoclet </ d isp lay−name>

6 <en te rp r i se−beans><session >

8 < desc r i p t i on > <! [CDATA[ SessionBean f o r the ProductMgmt use case ] ] > < / desc r i p t i on ><d isp lay−name>ProductMgmtSession </ d isp lay−name>

10 <ejb−name>ProductMgmtSession </ ejb−name>< loca l−home>ch . u n i f r . res . e jb . ProductMgmtSessionLocalHome </ l oca l−home>

12 < loca l >ch . u n i f r . res . e jb . ProductMgmtSessionLocal </ l oca l ><ejb−class >ch . u n i f r . res . e jb . ProductMgmtSessionBean </ ejb−class >

14 <session−type >Sta te less </ session−type >< t ransac t i on−type >Container </ t ransac t i on−type >

16 </ session ></ en te rp r i se−beans>

18

<assembly−d e s c r i p t o r >20

< secu r i t y−ro le >22 < desc r i p t i on > <! [CDATA[ d e s c r i p t i o n not supported yet by e j bd o c l e t ] ] > < / desc r i p t i on >

<ro le−name>Admin is t ra to r </ ro le−name>24 </ secu r i t y−ro le >

26 <method−permiss ion >< desc r i p t i on > <! [CDATA[ d e s c r i p t i o n not supported yet by e jb d o c l e t ] ] > < / desc r i p t i on >

28 <ro le−name>Admin is t ra to r </ ro le−name><method >

30 < desc r i p t i on > <! [CDATA[ Business method to save or update a product . ] ] > < / desc r i p t i on ><ejb−name>ProductMgmtSession </ ejb−name>

32 <method−i n t f >Local </ method−i n t f ><method−name>saveOrUpdateProduct </ method−name>

34 <method−params><method−param>ch . u n i f r . res . bean . product . Product </ method−param>

36 </method−params></method>

38 </method−permission >

40 <conta iner−t r a n s a c t i o n ><method >

42 <ejb−name>ProductMgmtSession </ ejb−name><method−name>∗</method−name>

44 </method><trans−a t t r i b u t e >Required </ t rans−a t t r i b u t e >

46 </ conta iner−t r ansac t i on >

48 </ assembly−desc r i p to r ></ ejb−j a r >

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

96

1 <?xml vers ion=" 1.0 " encoding="UTF−8"?><!DOCTYPE jboss PUBLIC " − / / JBoss / / DTD JBOSS 4 . 0 / /EN" " h t t p : / / www. jboss . org / j2ee / dtd / jboss_4_0 .

dtd ">3

<jboss >5 < secu r i t y−domain> java : / jaas / app−res </ secu r i t y−domain>

<en te rp r i se−beans>7 <session >

<ejb−name>ProductMgmtSession </ ejb−name>9 < loca l−j n d i−name>ProductMgmtSessionLocal </ l oca l−j n d i−name>

<method−a t t r i b u t e s >11 </method−a t t r i b u t e s >

</ session >13 </ en te rp r i se−beans>

</ jboss >

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

EHibernate

97

98

/∗ ∗2 ∗ Hibernate bean f o r the product data .

∗ @hibernate . c lass tab l e = " product "4 ∗ @hibernate . cache usage = " n o n s t r i c t−read−w r i t e "

∗ /6 p u b l i c c lass ProductHB extends ABaseHB {

/∗8 ∗ F ie lds

∗ /10 p r i v a t e Long produc t Id ;

p r i v a t e Set categoryHBs ;12 p r i v a t e S t r i n g productName ;

14 /∗ ∗∗ Creates a new ins tance .

16 ∗ /p u b l i c ProductHB ( ) {

18 super ( ) ;t h i s . categoryHBs = new HashSet ( ) ;

20 }

22 /∗ ∗∗ Gets the produc t Id .

24 ∗ @return Returns the produc t Id .∗ @hibernate . i d type = " long " column = " produc t Id " generator−c lass = " increment "

26 ∗ /p u b l i c Long getProduct Id ( ) {

28 r e t u r n t h i s . p roduc t Id ;}

30 /∗ ∗∗ Sets the produc t Id .

32 ∗ @param produc t Id The produc t Id to set .∗ /

34 p u b l i c vo id se tProduc t Id ( Long produc t Id ) {t h i s . p roduc t Id = produc t Id ;

36 }/∗ ∗

38 ∗ Gets the productName .∗ @return Returns the productName .

40 ∗ @hibernate . p roper ty type = " s t r i n g " column = " productName "∗ /

42 p u b l i c S t r i n g getProductName ( ) {r e t u r n t h i s . productName ;

44 }/∗ ∗

46 ∗ Sets the productName .∗ @param productName The productName to set .

48 ∗ /p u b l i c vo id setProductName ( S t r i n g productName ) {

50 t h i s . productName = productName ;}

52 /∗ ∗∗ Gets the categoryHBs .

54 ∗ @return Returns the categoryHBs .∗ @hibernate . se t name= " categoryHBs " t ab l e = " product_category " cascade = " none "

56 ∗ @hibernate . c o l l e c t i o n−cache usage = " n o n s t r i c t−read−w r i t e "∗ @hibernate . c o l l e c t i o n−key column = " produc t Id "

58 ∗ @hibernate . c o l l e c t i o n−many−to−many c lass = " ch . u n i f r . res . h iberna te . product . CategoryHB "column = " ca tegory Id "

∗ /60 p u b l i c Set getCategoryHBs ( ) {

r e t u r n t h i s . categoryHBs ;62 }

/∗ ∗64 ∗ Sets the categoryHBs .

∗ @param categoryHBs The categoryHBs to set .66 ∗ /

p u b l i c vo id setCategoryHBs ( Set categoryHBs ) {68 t h i s . categoryHBs = categoryHBs ;

}70 }

Listing E.1: Hibernate Bean: ProductHB.java

99

<?xml vers ion=" 1.0 " encoding="UTF−8"?>2

<!DOCTYPE hibernate−mapping PUBLIC4 " − / / Hibernate / Hibernate Mapping DTD 3 . 0 / /EN"

" h t t p : / / h iberna te . sourceforge . net / h ibernate−mapping−3.0. dtd ">6

<hibernate−mapping>8 <c lass name=" ch . u n i f r . res . h iberna te . product . ProductHB "

tab l e =" product ">10 <cache usage=" n o n s t r i c t−read−w r i t e " / >

12 < i dname=" produc t Id "

14 column=" produc t Id "type=" long " >

16 <generator c lass=" increment " / ></ generator >

18 </ id >

20 <proper tyname=" productName "

22 type=" s t r i n g "update=" t r ue "

24 i n s e r t = " t r ue "column=" productName " / >

26

<set28 name=" categoryHBs "

t ab l e =" product_category "30 l azy=" f a l s e "

cascade=" none "32 s o r t = " unsorted ">

<cache usage=" n o n s t r i c t−read−w r i t e " / >34 <key column=" produc t Id " ></key>

<many−to−many36 c lass=" ch . u n i f r . res . h iberna te . product . CategoryHB "

column=" ca tegory Id "38 outer−j o i n = " auto " / >

</ set >40 </ class >

</ h ibernate−mapping>

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

1 <?xml vers ion=" 1.0 " encoding="UTF−8"?><!DOCTYPE hibernate−c o n f i g u r a t i o n PUBLIC " − // Hibernate / Hibernate Con f i gu ra t i on DTD 3 . 0 / /EN" "

h t t p : / / h iberna te . sourceforge . net / h ibernate−con f i gu ra t i on −3.0. dtd ">3

<hibernate−con f i gu ra t i on >5 <!−− a SessionFactory ins tance l i s t e d as / j n d i / name −−>

<session−f ac to ry >7 <!−− p r o p e r t i e s −−>

<proper ty name=" d i a l e c t ">org . h iberna te . d i a l e c t . MySQLDialect </ proper ty >9 <proper ty name=" show_sql "> fa l se </ proper ty >

<proper ty name=" use_oute r_ jo in "> fa l se </ proper ty >11 <proper ty name=" connect ion . username ">res </ proper ty >

<proper ty name=" connect ion . password ">res123 </ proper ty >13 <proper ty name=" connect ion . d r i v e r _ c l a s s ">com. mysql . jdbc . Dr iver </ proper ty >

<proper ty name=" connect ion . u r l "> jdbc : mysql : / / l o c a l h o s t :3306/ res </ proper ty >15 <proper ty name=" connect ion . poo l_s ize " >10</ proper ty >

<!−− mapping f i l e s −−>17 <mapping resource=" ch / u n i f r / res / h iberna te / product / CategoryHB .hbm. xml " / >

<mapping resource=" ch / u n i f r / res / h iberna te / product / ProductHB .hbm. xml " / >19 </ session−f ac to ry >

</ h ibernate−con f i gu ra t i on >

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

100

<?xml vers ion=" 1.0 " encoding="UTF−8"?>2 <!DOCTYPE server >

<server >4 <mbean code=" org . jboss . h iberna te . jmx . Hibernate " name=" ch . u n i f r . res : se rv i ce=

HibernateSessionFactory ">

6 <!−− Required serv ices −−><depends> jboss . j ca : se rv i ce=RARDeployer </ depends>

8

<!−− Bind the Hibernate se rv i ce to JNDI −−>10 < a t t r i b u t e name=" SessionFactoryName "> java : h iberna te / RESSessionFactory </ a t t r i b u t e >

12 <!−− Datasource s e t t i n g s −−>< a t t r i b u t e name=" DatasourceName "> java : jdbc / mysql / res </ a t t r i b u t e >

14 < a t t r i b u t e name=" D i a l e c t ">org . h iberna te . d i a l e c t . MySQLDialect </ a t t r i b u t e >

16 <!−− Second−l e v e l caching −−>< a t t r i b u t e name=" SecondLevelCacheEnabled "> t rue </ a t t r i b u t e >

18 < a t t r i b u t e name=" CacheProviderClass ">ch . u n i f r . res . h iberna te . OSCacheProvider </ a t t r i b u t e >< a t t r i b u t e name=" QueryCacheEnabled "> t rue </ a t t r i b u t e >

20

<!−− Logging −−>22 < a t t r i b u t e name=" ShowSqlEnabled "> fa lse </ a t t r i b u t e >

</mbean>24 </ server >

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

2 / / lookup session f a c t o r ySessionFactory hbSessionFactory = ( SessionFactory ) Serv iceLocator . ge t Ins tance ( ) .

getRESSessionFactory ( ) ;4

/ / get cu r ren t h iberna te session6 Session hsession = t h i s . hbSessionFactory . getCurrentSession ( ) ;

8 / / saveProductHB newProductHB = new ProductHB ( ) ;

10 newProductHB . setProductName ( "New Product " ) ;newProductHB . se tProduc tPr ice (100.00) ;

12 newProductHB . setCategoryHBs ( categoryHBs ) ;Long produc t Id = hsession . save ( newProductHB ) ;

14

/ / load16 ProductHB exis t ingProductHB = hsession . load ( ProductHB . class , p roduc t Id ) ;

i n t p r i ce = exis t ingProductHB . getProductPr ice ( ) ;18

/ / de le te20 ProductHB deleteProductHB = hsession . load ( ProductHB . class , p roduc t Id ) ;

hsession . de le te ( deleteProductHB ) ;

Listing E.5: Persisting Objects

FLicense of the Documentation

Copyright (c) 2006 Beat Raess.

Permission is granted to copy, distribute and/or modify this document under the termsof the GNU Free Documentation License, Version 1.2 or any later version published bythe Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and noBack-Cover Texts.The GNU Free Documentation Licence can be read from [GNU05a].

101

GWebsite of the Project

A website was created for this project:http://diuf.unifr.ch/softeng/student-projects/completed/raess.

On this page you will find:

• The binaries and source of the Reseda E-Shop application.

• The documentation and manuals.

102

http://diuf.unifr.ch/softeng/student-projects/completed/raess

HCD-ROM

On the CD-ROM of the project you will find:

• The source code, configuration files 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

ICommon 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 Unified Process

SAR Service Archive

SSL Secure Sockets Layer or Secure Server Line

SQL Standard Query Language

TO Transfer Object

UI User Interface

UML Unified Modeling Language

URI Uniform Resource Identifier

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 Practicesand Design Strategies. Prentice Hall, 2nd edition, 2003.

[AT02] Scott Ambler and Jewell Tyler. Mastering Enterprise JavaBeans. Wiley Com-puter 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] Kent Beck. Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999.

[Bru05] Dominic Bruegger. Konzeption und Implementation einer multi-tier An-wendung mit J2EE. Master’s thesis, University of Fribourg, Switzer-land, 2005. URL: http://diuf.unifr.ch/softeng/student-projects/completed/bruegger/ (accessed October 1, 2005).

[Coc01] Alistar Cockburn. Agile Software Development. Addison-Wesley, 2001.

[Con04] Tim Conrad. PostgreSQL vs. MySQL vs. Commercial Databases: It’s All AboutWhat You Need. DevX, 2004. URL: http://www.devx.com/dbzone/Article/20743 (accessed October 1, 2005).

[Des04] Jean-Francois Descloux. Project Management. Lecture Documents, Universityof Fribourg, Switzerland., 2004.

[Eug00] Jörg Eugster. Fallstudie distrelec ag. eXperience Case Study Database. Facultyof Economics and Business Administration (FEBA) of the University of AppliedSciences, 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 aNutshell. A Desktop Quick Reference. O’Reilly, 2nd edition, 2002.

[FMSW04] Daniel Frauchiger, Andreas Meier, Hendrik Stormer, and Nicolas Werro.Zur Entwicklung des Struts-basierten Webshops eSarine. HMD - Praxis derWirtschaftsinformatik, Jhrg 41, HMD Nr. 238, August 2004. URL: http:

106

http://www.ecommerce-guide.com/news/trends/article.php/979861

http://www.ecommerce-guide.com/news/trends/article.php/979861

http://diuf.unifr.ch/softeng/student-projects/completed/bruegger/

http://diuf.unifr.ch/softeng/student-projects/completed/bruegger/

http://www.devx.com/dbzone/Article/20743

http://www.devx.com/dbzone/Article/20743

http://www.experience-de.fhbb.ch/cases/experience.nsf/volltext/distrelec

http://www.experience-de.fhbb.ch/cases/experience.nsf/volltext/distrelec

http://diuf.unifr.ch/is/research/esarine/publications.php


References 107

//diuf.unifr.ch/is/research/esarine/publications.php (accessed Octo-ber 1, 2005).

[Fow02] Martin Fowler. UML Distilled: A Brief Guide to the Standard Object ModelingLanguage. Addison Wesley, 2002.

[GHJV02] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Pat-terns. Elements of Reusable Object-Oriented Software. Addison-Wesley, 2002.

[Gil03] Ian Gilfillan. 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] Hibernate. Hibernate Reference Documentation. Hibernate, 2005. URL: http://www.hibernate.org/5.html (accessed October 1, 2005).

[Hus03] Ted Husted. Struts in Action: Building web applications with the leading Javaframework. Manning Publications, 4th printed edition, 2003.

[Koc03] Michael Koch. Integrating the Online Shop with the ERP System at StrackAG. eXperience Case Study Database. Faculty of Economics and Busi-ness 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 Unified Process: An Introduction. Addison-Wesley, 3rd edition, 2004.

[McC05] Craig McClanahan. The Best of Both Worlds: Integrating JSFwith Struts in Your J2EE Applications. Oracle Technology Net-work, 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 undTechnologien. Dpunkt, 2nd edition, 2002.

[MH04] Richard Monson-Haefel. Enterprise JavaBeans. O’Reilly, 4th edition, 2004.

[Oel01] William L. Oellermann. Architecting Web Services. Apress, 2001. URL: http://www.architectingwebservices.com (accessed October 1, 2005).

[Pas04] Jacques Pasquier. Advanced Software Engineering. Lecture Documents, Uni-versity of Fribourg, Switzerland., 2004.

[Res05] Reseda Engineering. Businessplan. Für Geschäftspartner, February 2005.

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



http://www.databasejournal.com/features/mysql/article.php/3288951

http://www.databasejournal.com/features/mysql/article.php/3288951

http://www.gnu.org/licenses/fdl.html

http://www.gnu.org/licenses/fdl.html

http://www.gnu.org/licenses/gpl.html

http://www.gnu.org/licenses/gpl.html

http://www.hibernate.org/5.html

http://www.hibernate.org/5.html

http://www.experience-de.fhbb.ch/cases/experience.nsf/volltext/strack_en

http://www.experience-de.fhbb.ch/cases/experience.nsf/volltext/strack_en

http://www.oracle.com/technology/pub/articles/masterj2ee/j2ee_wk8.html

http://www.oracle.com/technology/pub/articles/masterj2ee/j2ee_wk8.html

http://www.architectingwebservices.com

http://www.architectingwebservices.com

References 108

[Res06b] Reseda Engineering. Reseda E-Shop Manual: Features. Technical report,Reseda Engineering, 2006.

[Res06c] Reseda Engineering. Reseda E-Shop Manual: Installation Evaluation. Technicalreport, Reseda Engineering, 2006.

[Res06d] Reseda Engineering. Reseda E-Shop Manual: Installation Production. Techni-cal 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. eX-perience Case Study Database. Faculty of Economics and Business Ad-ministration (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).

[Sch05] Petra Schubert. Electronic Business in the Global Economy, 2005. LectureDocuments, University of Fribourg, Switzerland., 2005.

[Sun05a] Sun Microsystems. JSR 220: Enterprise JavaBeans, Version 3.0. EJB 3.0Simplified 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 CoreContracts 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 Persis-tence 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 fürMusik 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).

http://www.experience-de.fhbb.ch/cases/experience.nsf/volltext/otto_fischer

http://www.experience-de.fhbb.ch/cases/experience.nsf/volltext/otto_fischer

http://java.sun.com/products/ejb/docs.html





http://java.sun.com/j2ee/1.4/docs/

http://www.phlow.net/webtechnik/suchmaschinenoptimierung.php

http://www.phlow.net/webtechnik/suchmaschinenoptimierung.php

http://en.wikipedia.org/wiki/E-business

http://en.wikipedia.org/wiki/E-business

http://en.wikipedia.org/wiki/Online_shop

http://en.wikipedia.org/wiki/Online_shop

http://en.wikipedia.org/wiki/3_tier_architecture

http://en.wikipedia.org/wiki/3_tier_architecture

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 (ac-cessed April 10, 2006).

[4] Jakarta Cactus, 2006. http://jakarta.apache.org/cactus (accessed April 10,2006).

[5] Apache Commons Beanutils, 2006. http://jakarta.apache.org/commons/beanutils/ (accessed April 10, 2006).

[6] Apache Commons Email, 2006. http://jakarta.apache.org/commons/email/ (ac-cessed 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. http://www.eclipse-plugins.info (accessed April 10,2006).

[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

http://ant.apache.org

http://www.at-web.de


http://jakarta.apache.org/cactus




http://dbunit.sourceforge.net

http://www.die3.co.at

http://www.eclipse.org

http://www.eclipse-plugins.info


http://geronimo.apache.org

http://www.google.ch

http://www.hibernate.org


http://java.sun.com/javaee/index.jsp

http://java.sun.com/javaee/index.jsp


[17] Java-Source. Java-Source, 2006. http://java-source.net (accessed April 10,2006).

[18] JBoss, 2006. http://www.jboss.org (accessed April 10, 2006).

[19] JBoss. JBoss jBPM, 2006. http://www.jboss.com/products/jbpm (accessed April10, 2006).

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

[21] JBoss Application Server, 2006. http://www.jboss.com/products/jbossas (ac-cessed April 10, 2006).

[22] JBoss Cache, 2006. http://www.jboss.org/products/jbosscache (accessed April10, 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 (ac-cessed 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. http://java.sun.com/products/jdo/ (accessed April 10, 2006).

[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. http://www.opensymphony.com/oscache (accessed April 10,2006).

[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 (accessedApril 10, 2006).

http://java-source.net

http://www.jboss.org

http://www.jboss.com/products/jbpm

http://www.jboss.com/products/jbosside

http://www.jboss.com/products/jbosside

http://www.jboss.com/products/jbossas

http://www.jboss.org/products/jbosscache

http://www.jdom.org

http://jonas.objectweb.org

http://java.sun.com/j2ee/javaserverfaces

http://www.junit.org

http://maven.apache.org

http://www.metanet.ch

http://www.microsoft.com/net



http://www.mysql.com

http://www.netbeans.org

http://www.netperceptions.com


http://www.paypal.com

http://www.php.net


http://www.postgresql.org

http://quantum.sourceforge.net


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

http://www.resedahome.ch


http://www.springframework.org

http://www.ssaglobal.com






http://www.sun.com

http://tomcat.apache.org

http://www.webtrends.com

http://xdoclet.sourceforge.net

Res Report

Documents

rational unied

cost intensive

referenced

multitiered

ant build

install evaluation

class diagram

external payment