A COMPONENT BASED ONLINE ORDERING SYSTEM USING ENTERPRISE JAVABEANS 3.0

Transcription

1 A COMPONENT BASED ONLINE ORDERING SYSTEM USING ENTERPRISE JAVABEANS 3.0 AUTHOR: JAMES OSBORNE SUPERVISOR: DR. KUNG KIU LAU 2 MAY 2007

2 ABSTRACT Title: A Component Based Online Ordering System Using Enterprise JavaBeans 3.0 Student: Supervisor: James Osborne Dr. Kung Kiu Lau Date: 2 nd May 2007 Component based systems are comprised of a number of reusable software components that can be used to rapidly build fully functional applications. Enterprise JavaBeans 3.0 is a rich technology specifically designed for developing software components, providing developers with everything they need to implement component based systems. This project details the development of one such component based system designed to take advantage of the features offered by Enterprise JavaBeans 3.0 by implementing an online ordering system for a fictitious company. The aims of the project have been met as a result of the implementation of the system. A number of server side components have been implemented for use in two applications; a web client that allows for customer interaction with the system over the Internet, and an administrative client for company employees to maintain the company s data. The results of the project are illustrated and details of the testing provided to demonstrate that the system is a working solution to the original project proposal. The conclusion presents the project as an overall success, with the solution providing a working component based system that implemented the majority of features offered by Enterprise JavaBeans 3.0. The reusability of the system has been demonstrated by the two client applications, and the project provides a large scope for further development. 2

3 ACKNOWLEDGEMENTS Firstly I would like to thank my supervisor Dr. Kung Kiu Lau for his relaxed approach to guiding me through the project, giving me free reign to take the project in whatever direction I felt would be best and allowing me to work at my own pace. He was always readily available when I needed him, and his assistance at these times was invaluable. I would also like to thank the EJB community for their support throughout the duration of the project. Without the assistance I received from online tutorials and community forums I would not have got as far as I did. Thanks in particular go to those who posted information on their problems which I then also encountered, for these were often seldom seen issues that required very specific fixes. A final show of appreciation goes to my fellow Computer Scientists who were able to lend me their support when I needed it and keep me motivated when things were not going according to plan. 3

4 TABLE OF CONTENTS Abstract... 2 Acknowledgements... 3 Table of Contents... 4 Chapter 1: Introduction Project Proposal Project Aims Project Motivation Other Work in the Area Report Overview... 8 Chapter 2: Background and Literature Survey Overview of Software Components Component Based Sofware Engineering Component Based Technologies Overview of Enterprise JavaBeans Software Components in EJB Component Interfaces in EJB Application Servers EJB Container Web Container Primary Services Java Naming and Directory Interface Annotations and XML Deployment Descriptors Dependency Injection Deployment Entity Beans Java Persistence Entity Manager Persistence Unit Persistence Context Mapping Persistent Objects Embedded Objects and Composite Keys Entity Relationships Entity Inheritance Single Table per Class Strategy Table per Subclass Strategy Mapped Superclass Queries & EJB QL Named Queries Session Beans Stateful Session Beans Lifecycle Stateless Session Beans Lifecycle Message Driven Beans Lifecycle Java Message Service Messaging Models Message Driven Beans Using JMS Interceptors Security Web Components

5 Servlets JavaServer Pages Web Components and EJB Chapter 3: Requirements Specification Purpose of the Project Users of the Project Project Constraints Functional Requirements Essential General Website Administrative Client Desirable General Website Administrative Client Data Requirements Chapter 4: Design System Architecture Database Design Enterprise JavaBeans Design Entity Beans Session Beans Message Driven Beans Website Design Application Design Chapter 5: Implementation Development Methodology Environment Setup Application Server Database Server Integrated Development Environment Tool Enterprise JavaBeans Development Entity Beans Entity Relationships Entity Inheritance Stateful Session Beans Stateless Session Beans Session Bean Interfaces Message Driven Beans Website Development Servlets JavaServer Pages Application Development Remote Interfaces and JNDI Security Graphical User Interface Chapter 6: Results Website Administrative Client Chapter 7: Testing and Evaluation Testing Strategy

6 7.2 Test Results Analysis and Evaluation Of Testing Chapter 8: Conclusions Achieving The Project Objectives Issues Encountered Alternative Implementations Potential Further Developments Appraisal of EJB Closing Comments References Appendix A: Gantt Chart Appendix B: Database Tables Appendix C: Test Data

7 CHAPTER 1: INTRODUCTION 1.1 PROJECT PROPOSAL This project proposes the creation of a component based distributed ecommerce application to meet the needs of a fictional electronic entertainment company that run an online store to retail their products. This will require the acquisition of detailed knowledge of software components and a technology that can be used to develop them. The technology that this project will use is Enterprise JavaBeans 3.0 (EJB). 1.2 PROJECT AIMS EJB 3.0 is a rich technology for developing software components and provides many features that can be used to develop a component based online ordering system to meet the needs of our fictional business. With this in mind a number of key aims have been produced that will allow for sufficient opportunities to showcase these features: 1. The project will focus on the development of an ordering system that will be: a. Component based b. Accessible to customers through a website c. Accessible to employees through an administrative client 2. The project will involve the creation of a website that will let users: a. Register their details with the company b. Browse the products the company offers c. Perform actions on the products (e.g. review and rate them, add to wish lists, etc) d. Order and pay for items 3. An accompanying administration client will be produced that will let company employees: a. Add new products b. Update and remove existing products c. Maintain customer details d. Manage orders By choosing to develop the project for a fictitious online retailer a highly extensible domain has been selected that has the potential for extra features to be added on top of the list of aims provided here. This opens up the possibility that additional functionality can be added later in the project that can make use any features of EJB not yet utilized in the implementation of the list above. 1.3 PROJECT MOTIVATION Since the explosion of the Internet as a means to retail goods and services many firms are now opening up their systems to the whole world to reach ever increasing audiences. Initially this posed a problem for firms who already had technology implemented internally do they create a separate system so that they can access the online market and run two systems in parallel, or do they rewrite their internal systems so that they can also be accessed from the internet? This situation is analogous to large firms with several departments, where it is not ideal for each department to have their own custom systems. Clearly the option to have a single system is the most desirable for these firms. Component based software development allows businesses to develop these systems. It has become far more popular in recent years as the features it provides make it highly suitable for developing distributed business applications that meet the needs of modern organizations. It allows for the creation of multi tiered architectures whereby several applications can make use of the same components. This means that a component only needs to be written once but can be used by any number of applications. This is attractive to businesses as it reduces the cost of developing their applications and maintaining them after they are deployed into the production environment. Updates to the system can be easily applied as changes to a component are then reflected in the operation of all the applications that use that component, rather than having to repeat the change in many different applications. This also helps to mitigate the risk associated with updating code. 7

8 As the technology that drives the development of software components has matured it has become more widely accepted. EJB in particular has benefited from this since it also comes with the advantages of platform independence due to its roots in Java. Using it to develop an online ordering system provides the perfect opportunity to write reusable components that can be used by both the technology that runs the website and by the application used by the company s employees. There are many examples of similar work in the real world that make this project an insight into how the technology behind many companies is written. For these reasons learning how to develop software components using a technology like EJB that is dedicated to their development is an attractive proposal which will provide valuable experience of creating reusable components in a modern programming language. 1.4 OTHER WORK IN THE AREA Since its proposition as a branch of software engineering by Douglas McIlroy in 1968 there has been significant research into software components. They initially found popularity in the development of graphical user interface (GUI) widgets and in other areas where there was wide spread possibilities for reuse. Since then it has expanded rapidly to cover far more diverse areas, especially from the time when the Internet was invented. Now software components are being heavily utilized to take advantage of the opportunities the Internet provides in the creation of online booking and ordering systems. There are numerous examples of similar work that has been produced on the domain chosen for the project. Many examples of comparable work can be found by examining the workings of almost any online store. Perhaps the most obvious example of an online ordering system would be Amazon.com, but there are thousands of companies that offer their products for purchase over the Internet. Whilst it is hard to ascertain what technology these companies are using behind the scenes they all offer the same basic functionality, the implementation of which will form the basis of this project. Enterprise JavaBeans 3.0 is the latest incarnation of EJB and is quite a radical departure from previous versions. There are however considerable resources for the previous version (2.1) which is similar enough in many respects to be useful in the development of this project. Unfortunately the majority of the resources on similar projects that would be helpful are not publicly available due to the fact that most of the systems developed using EJB are built in house, although there is still plenty of related work that has been done on similar domains that is published for the EJB community to view. 1.5 REPORT OVERVIEW The remainder of this report is split up into several sections that cover the project from the initial research through to the design, implementation and testing phases. Immediately following this introduction is a chapter that gives essential background information gathered as a result of a comprehensive literature survey on the concepts and technology around which the project is based. Chapter three then presents the design process and details the decisions made and the reasons behind them, which leads on to a segment covering the implementation of this design where a selection of the most interesting and significant aspects of the implementation are presented in detail. Following this is a chapter dedicated to demonstrating how the completed system works in practice. A series of use cases illustrated to ascertain whether or not the system does what it was intended to do. Chapter six will then focus on the testing and evaluation of the project. The strategies for testing are explained and the results of the tests presented. There is an assessment of how successfully the implementation met the key objectives of the project. The final chapter then covers the conclusions drawn from the project, highlighting the challenges faced and key successes as well as presenting possible extensions to the project. Supplementary material, such as the Gantt chart for the project plan, can be found in the Appendix. 8

9 CHAPTER 2: BACKGROUND AND LITERATURE SURVEY 2.1 OVERVIEW OF SOFTWARE COMPONENTS Software components suffer from a lack of an agreed definition. Whilst there are several definitions of software components that have considerable differences between one another, fortunately there are a number of definitions that only diverge slightly for a core set of ideas. Clemens Szyperski proposes one such definition that covers the fundamental features of a software component: A software component is a unit of composition with contractually specified interfaces and explicit context dependencies. An interface is a set of named operations that can be invoked by clients. Context dependencies are specifications of what the deployment environment needs to provide, such that the components can function [1] This specifies software components to be reusable pieces of encapsulated code that have a well defined interface, allowing the component to offer services to other components. They are independent entities and only become useful when combined with other software components to build applications. In a sense they can be thought of as Lego bricks that can be plugged into one another to build something useful COMPONENT BASED SOFWARE ENGINEERING Component based software engineering (CBSE) or component base software development (CBSD) as it is otherwise known is a process for building applications using a number of software components. For this process to be applicable the software components to be used in the development of a system must provide a set of services to other components in the system, and importantly it should be to replace components with functionally equivalent components if the need arises. The development of component based systems using CDSE can be broken down into the following steps: Development of reusable software components Assembly of software components into a workable system In some cases this first phase is not necessary if the development of in house software is not a requirement for the system. There has been a recent rise in the popularity of Commercial Off The Shelf (COTS) components that can then be glued together using connector code. This provides a number of benefits. Firstly, development time is reduced for the system as a whole as the majority of components that provide the systems functionality have already been written, the only thing left to do is fit the components together. Coupled with the reduction in development time is typically a reduction in development costs, provided costs saved from the time saved is less than the costs of the purchased COTS components. These systems are intended to be easy to maintain due as a result of the plug and play nature of software components, but this is not usually the case. Using COTS components means there is a reliance on the developer of the component to maintain it and fix any issues that may arise which can cause problems. Also, finding COTS components that exactly match the specification of a system is rare COMPONENT BASED TECHNOLOGIES Software components are typically implemented as objects or collections of objects in an object orientated (OO) programming language like Java or C++. Despite this there are significant differences between what is considered to be a reusable component from an OO perspective compared to that of a software component perspective. In OO languages a reusable component usually refers to a class or collection of classes in the form of a library that provide a set of services that other class can use. These are very closely tied to the underlying technology however, and can only interact with other classes written in the same language. Software components on the other hand allow their services to be accessed by other components regardless of the programming language used in their underlying implementation. There are several programming languages that have been designed specifically for the development of software components. Some of these component orientated programming languages have been around for quite some time and there is a great volume of information published on each one. These languages include Enterprise JavaBeans, UNO, Z++ and Eiffel. 9

10 2.2 OVERVIEW OF ENTERPRISE JAVABEANS 3.0 Enterprise JavaBeans 3.0 is the latest incarnation of EJB to be released by its developer Sun Microsystems, and forms a key part of the Java Enterprise Edition 5.0 platform (Java EE). Sun provide the following definition of Enterprise JavaBeans: The Enterprise JavaBeans architecture is a architecture for the development and deployment of component based business applications. Applications written using the Enterprise JavaBeans architecture are scalable, transactional, and multi user secure. These applications may be written once, and then deployed on any server platform that supports the Enterprise JavaBeans specification. [2] This means that EJB allows for the development of server side software components that can be used by client applications in a multi tiered system. Once a component has been written it can be used in any number of client applications, and these can be built by combining any number of components. This allows for the rapid development of client applications once a set of server side components have been produced. In order for these components to be accessed they need to be deployed on a server platform that supports the Enterprise JavaBeans specification. These are known as application servers, and provide an environment in which the components are managed and accessed by their clients. Figure 2.1 displays the how EJB systems typically fit together. Figure 2.1: A typical multi tiered system using EJB EJB has become very popular in the commercial world. It allows for the reuse of code and is very focused on the development of business logic code. Combining this with the fact that it is freely available as part of Java EE and has a large community for support has led to EJB becoming a, if not the, leading technology for the development of software components at this moment in time SOFTWARE COMPONENTS IN EJB Components in EJB are referred to as beans and come in three types: entity beans, session beans and messagedriven beans. Of these only the last two can be considered as software components. Entity Beans used to model business concepts and real world objects that are typically stored as data in a relational database. They are not directly accessible from remote clients. Session Beans server side components that can be accessed from remote clients via the application programming interface (API) that they expose in the form of a remote interface or web service. Typically used to represent business processes that a client would want to perform. They come in one of two types: o o Stateful Session Beans a session bean that maintains a conversational state with the client and therefore requires there to be one instance of the bean per client Stateless Session Beans a session bean that does not maintain a conversational state with the client therefore allowing a single instance to service multiple clients Message Driven Beans server side components that are used to process asynchronous messages received from messaging systems This is just a brief overview of what the different types of beans are. They will all be discussed in detail in the coming sections. 10

11 2.2.2 COMPONENT INTERFACES IN EJB A software component must specify an interface that defines its use, and in EJB session beans do exactly that. There are two types of interface that session beans can decide to implement depending on the context of their use: local interfaces and remote interfaces. Indeed, if needed a session bean can implement both a local and a remote interface. A remote interface defines a session bean s methods that are available to application clients that are outside of the application server in which the session bean is running. For these two to communicate there must be some interaction over the network. A local interface defines a session bean s methods that are available to other beans running in the same application server. The fact that it is local means that the beans in question are running in the same Java Virtual Machine (JVM) and therefore there is no need for them to interact via the network. In both cases the interfaces are written as plain Java interfaces. Imagine our fictitious online retailer requires a software component to generate a random integer that should be accessible by external client applications. In this instance we need to create a remote interface and a stateless session bean that implements this interface. A stateless session bean is suitable in this case as no conversation state needs to be maintained with the client. First we would specify the remote public interface RandomIntegerRemote { public int getrandominteger(); Notice that the interface is annotated This specifies that this interface is a remote interface. Annotations are used to provide metadata for use by the application server, and will be discussed further in the following section. Now we have specified the interface we can implement the session bean public class RandomIntegerBean implements RandomIntegerRemote { public int getrandominteger() { Random random = new Random(); return random.nextint(); 2.3 APPLICATION SERVERS Application servers are a key part of EJB since they are responsible for the environment in which the beans will be run. They are very complex pieces of software that provide a number of services that allow EJB developers to concentrate on the development of business logic rather than having to worry about how the beans will be managed. They typically have three main parts: An EJB container in which the beans are housed and managed A web container which acts like a web server to allow access to the beans via servlets and JavaServer Pages (JSP) A number of primary services to provide the infrastructure needed for a multi tier system There are many application server vendors that meet the EJB specifications, including JBoss, IBM WebSphere, BEA Weblogic and Apache Geronimo EJB CONTAINER The EJB container is the environment in which the beans are managed and accessed by the various clients that use the beans. The container is responsible for managing the life cycles of bean instances and provides the bean instances with security and transaction management. It is also responsible for routing the remote method invocation (RMI) to the bean instances so that the clients can access the services that the beans provide. This process of providing access is a key task that the EJB container provides. Application clients do not interact directly with the bean instances housed within the EJB container. Instead all requests from the client are invoked on the remote interface of the bean in question, but are actually invoked on a proxy stub that implements this interface which has been generated by the container. This proxy stub is the actual 11

12 object that the client is interacting with, and is responsible for routing the client s request over the network to the EJB container. The container routes the request to an EJB object designated to handle the request, which in turn routes the request to an actual bean instance to be processed. Figure 2.2: Accessing a bean instance This illusion of a direct connection to the beans is an important feature that the server takes advantage of with some of its primary services WEB CONTAINER It is typical for application servers that adhere to the EJB specification to also come bundled with a web container which acts as a web server. It houses web components that can access the enterprise beans that are located in the EJB container. This allows the beans to be accessible from the Internet via an HTML interface PRIMARY SERVICES EJB servers offer a number of primary services the most important of which is resource management. The number of objects in use on an application server can easily reach into the millions for large organizations, and without good resource management performance will undoubtedly degrade to the point of the system becoming so slow it is rendered unusable. EJB servers aim to keep performance at an acceptable level by using instance pooling and activation. Instance pooling reduces the number of objects in memory by sharing instances between various clients. Since the EJB container doesn t provide clients with direct access to the instances themselves there is no need to create a copy of the bean in question for each client. Instead the server can reuse the same instances over and over again to service clients requests. Figure 2.3: Instance pooling Activation is used with stateful session beans the only type of bean that requires an instance to be created for each client so that conversational state between the bean and the client can be maintained. Since instance pooling is not possible in this circumstance activation is used to conserve resources instead. Typically when a bean hasn t been in used by its client for a certain amount of time the server performs the passivation process on it whereby it is evicted from memory and its state is serialized to secondary storage usually a hard drive. When it is needed again by the client the activation process is performed which instantiates a new bean instance in memory and populates it with the state of the passivated bean. The activation process also provides a number of lifecycle call back methods that can be used by developers to perform specific actions when bean instances are about to go through certain events in the activation process. For instance, there is a call back whenever a bean instance is about to be passivated which can be intercepted by the 12

13 developer if the bean needs to perform some specific work before it is passivated. These will be covered in greater detail when session beans are discussed. The other services that application servers provide that are persistence, naming, security, concurrency, transaction management, asynchronous messaging and a timer server. Most of these will be covered in detail in later sections but naming is an important service that is appropriate to examine at this point JAVA NAMING AND DIRECTORY INTERFACE Naming services provide clients with a mechanism for locating distributed resources, in this case the beans that are running on the application server. All naming services provide two things that are necessary in order for clients to gain access to these remote resources: object binding and a lookup API. Object binding simply assigns an identifier with the distributed resource, usually in the form of a human readable string. For instance, assume our fictitious company has a bean called PaymentBean on their application server that provides payment operations. We may decide to bind the identifier payment to that bean. The lookup API provides the client with the ability to request a remote reference to these distributed resources by supplying an object binding. The naming service employed by EJB is the Java Naming and Directory Interface (JNDI). This provides the ability for the client to lookup and retrieve references to the beans deployed on an application server. The server is responsible for creating the object bindings for the beans so that applications use the JNDI lookup method with relevant identifiers to retrieve references to the beans. The following is an example of a client obtaining a remote reference to the PaymentBean component we mentioned earlier: Context jndicontext = new InitialContext(); Object ref = jndicontext.lookup("payment"); PaymentBeanRemote bean = (PaymentBeanRemote) PortableRemoteObject.narrow(ref, PaymentBeanRemote.class); ANNOTATIONS AND XML DEPLOYMENT DESCRIPTORS Earlier on the concept of annotations was briefly introduced. Annotations are new to EJB 3.0 and are used to specify EJB metadata on the bean classes, methods and variables. This metadata is then used to supply the application server with runtime information that it uses when deploying the beans to determine the beans runtime behaviour. Using annotations is good when the configuration of the beans is likely to remain the same permanently. This information does not have to be supplied via annotations. It is also possible to pass this information to the server through the use of XML deployment descriptors. When the beans are deployed the application server will search for any of these deployment descriptors and use the metadata supplied in these to determine the runtime behaviour of the beans. Importantly, the information specified in the XML file can be used to override annotation metadata. Using XML deployment descriptors is particularly useful as they can be customised on a per deployment basis without the need to change and recompile the code itself. If we refer to our earlier example of the random integer generating session bean we can see an example of annotations and the corresponding XML deployment descriptor for that bean if we choose not to use public class RandomIntegerBean implements RandomIntegerRemote { public int getrandominteger() { Random random = new Random(); return random.nextint(); <ejb-jar> <enterprise-beans> <session> <remote>randomintegerremote</remote> <session-type>stateless</session-type> </session> </enterprise-beans> </ejb-jar> Notice that the use of annotations allows someone reading the code to instantly know what type of session bean this is and what its remote interface is. They are also much less verbose than the XML equivalent. 13

14 2.3.5 DEPENDENCY INJECTION Another important use of the EJB application server is dependency injection. This allows references to other objects to be automatically injected into a member variable of a bean rather than having to write specific lookup code to obtain a reference manually. This is achieved through either annotations or XML deployment descriptors. This is particularly useful for inserting bean references into a specific bean. For example, consider we have a shopping cart bean that uses the payment bean to process payments for items in the shopping cart. Since the application server is already managing the beans it can insert a reference to one of the payment beans directly into the shopping cart bean when it is public class ShoppingCartBean implements ShoppingCartRemote private PaymentBean payment; annotation here tells the application server to inject a reference to a payment bean into this member variable. There is no need to manually obtain a reference and the variable will be ready for use immediately. This very useful feature of the application server is heavily used in EJB DEPLOYMENT In order to deploy the beans onto the server the Java classes and other resources must be first packaged into a Java Archive (JAR) file. This file contains all the enterprise beans, their interfaces and any utility classes that they use as well as any XML deployment descriptors and other configuration files. When this file is then passed to the application server s deployment tools the EJB container examines the contents of the JAR file to determine what beans are in the JAR file, how to manage those beans runtime behaviour, and how to map the entity beans to the underlying database. To deploy other items at the same time as the enterprise beans such as web components and Java applications a special type of JAR file called an Enterprise Archive (EAR) file is used. This contains the JAR of the enterprise beans, a JAR containing the Java application classes and resources, and a Web Archive (WAR) file that contains the web components and their associated resources. 2.4 ENTITY BEANS Entity beans are not software components themselves and have no remote interfaces that clients can use. Instead, entity beans are designed to be Java representations of database tables, allowing each entity bean instance to store the values of a single row from the database table that it maps to. Entity beans consist of a number of Java primitives (or their corresponding wrapper classes) and strings that hold the values retrieved from the database columns, typically with getter and setter methods for each property. Since entity beans are just plain Java objects they can be used as arguments to methods in other classes such as session beans and can also be serialized and sent over the network as results from method invocations. In order for entity beans to function they need to interact with a database, and this interaction takes place through the Java Persistence API. 2.5 JAVA PERSISTENCE 1.0 The Java Persistence API is an object to relational mapping engine (ORM) used in the development of entity beans in EJB. An ORM is responsible for mapping objects to and from a relational database. Java Persistence is an abstraction on top of Java Database Connectivity (JDBC) that provides for the mapping of objects to their corresponding database representations. This means the developer does not need to know anything about JDBC in order to interact with the database. It also provides a query language called EJB QL that is comparable to Structured Query Language (SQL) but specifically designed for use with entity beans rather than the database itself. It is implemented differently by each application server, with JBoss using Hibernate to implement the API for instance. Java Persistence allows for the development of entity beans as plain old Java objects (POJOs) unlike in any of the previous versions of the EJB specification. The required metadata for mapping these classes to the database is provided simply through the use of annotations on the entity bean class. The fact that entity beans are just POJOs allows them to be used to transfer data between the client and the server. In previous versions of EJB entity beans 14

15 had to be mapped to equivalent objects in order to be transferred across the network, but now they are POJOs the need for the Data Transfer Object pattern has been made redundant. The workhorse behind Java Persistence is a service called the EntityManager ENTITY MANAGER The entity manager is the service that is responsible for all persistence related actions, providing methods to create, find, query, remove and update entity beans. It manages the object to relational (O/R) mapping between an entity bean and an underlying database. An entity bean instance can be either attached (managed) or detached (unmanaged) from the entity manager. Entity beans that are attached to an EntityManager service are automatically synchronised with its data source, whereas unmanaged entity beans are detached from the entity manager and therefore do not have their changes synchronised automatically PERSISTENCE UNIT Each entity manager is associated with a persistence unit, which maps a set of entity beans to a particular database. In order to configure the entity manager Java Persistence requires an XML deployment descriptor file named persistence.xml to be included in the deployment JAR. This XML file defines the properties of each persistence unit such as its name and its data source. Unless the entity beans are explicitly associated with certain persistence contexts in this file the EJB container presumes all entities can be used with any persistence unit PERSISTENCE CONTEXT An entity manager is also associated with a persistence context, which is a set of managed entity bean instances. While a persistence context is open the entity manager synchronises the state of all managed entity bean instances within that context, but once the context is closed all entity bean instances becoming detached from the entity manager and any changes to their state will not be synchronised to the underlying data source the entity manager maps to. There are two types of persistence contexts: extended and transaction scoped. A transaction scoped persistence context is open for as long as a transaction. It is opened when the transaction begins and is closed when the transaction is completed. In EJB transactions are implicitly the same as method invocations, although they can be set explicitly. Below is a piece of sample code of a transaction scoped persistence = testdb, type = PersistenceContextType.TRANSACTION) private EntityManager entitymanager; public void renamecustomer(int customerid, String name) { Customer customer = entitymanager.find(customer.class, customerid); customer.setname(name); In our example we have an entity manager that is associated with a transaction scoped persistence context for a persistence unit identified by the name testdb. The call to entitymanager.find() returns a managed customer instance populated with the corresponding data in the database. The subsequent call to customer.setname() will then be synchronised to the database automatically as the instance is attached to the entity manager. At the end of the method the customer is returned to the client that invoked the call. Since this method and hence transaction is now complete the persistence context will be closed and the customer instance detached from the entity manager. An extended persistence context lasts longer than the length of a transaction with entity bean instances remaining managed even after transactions are complete. It is often used when it is necessary to avoid long transactions with the database since it allows for the work to be broken up across various shorter transactions whilst the entities to remain managed by the entity manager. An example can be seen = testdb, type = PersistenceContextType.EXTENDED) private EntityManager entitymanager; private Customer customer; 15

16 public void setcustomer(int customerid) { customer = entitymanager.find(customer.class, customerid); return customer; public void renamecustomer(string name) { customer.setname(name); This example provides the same functionality as our transaction scoped persistence context, but separates the work over two methods. Initially a client will make a call to setcustomer() to retrieve a managed customer instance from the entity manager. A subsequent call to renamecustomer() from the client will cause the name of our customer to be changed. Since we are using an extended persistence context our customer entity is still managed even across transactions, so this change will be propagated to the database automatically MAPPING PERSISTENT OBJECTS Mapping entity beans to database tables requires the developer to supply Java Persistence with some metadata that describes the object to relational mapping. This metadata is typically supplied through annotations (or the XML equivalent). At a minimum Java Persistence requires an entity bean to be annotated with annotation that indicates that the class in question is an entity bean, and annotation which designates a property of the class to be used as the primary key. The primary key can be automatically generated using annotation on the primary key property. It is common to find annotations present in entity bean classes as well. annotation provides the name of the database table that the entity bean maps to. If it is not specified the entity manager will assume that table has the same name as the class. Similarly annotation is used to indicate how the entity beans properties map to their corresponding columns in the database table. Again, if a name is not specified the entity manager will assume a mapping to a column with the same name as the property. Like all property mapping annotations definition can be defined on either the property definition or the getter/setter methods for that property. Figure 2.4 provides a simple example of an entity bean: Figure 2.4: Mapping persistent objects There are a number of other annotations that can be used to describe the property mappings of an entity bean. annotation provides the entity manager with information about how to manage Date or Calendar properties. Since databases can store dates in different formats (date, time, timestamp) the entity manager requires additional information about how to persist these properties to the database to ensure they are in the correct format. The following example shows how to annotate a Date property to be persisted as a timestamp: 16

17 @Column(name = "course_start private Date startdate; annotation maps Java enums to the values in a column of a database table. A Java enum property can be mapped either to the ordinal value or string representation of the enum value. This is a powerful feature as it allows for the entity bean to enforce a set of values that are valid for the corresponding column of the database, and also can provide meaningful interpretations of the values in the database. For instance, assume there is a column named student_type in a database table that we are mapping with an entity bean. This column may contain the values 0, 1, or 2 which are meaningless on their own. However, we can map these with a Java enum to represent their actual meanings: public enum StudentType { UNDERGRADUATE, POSTGRADUATE, = "student_type private StudentType type; In the example above the entity manager will map the ordinal values returned from the database to their corresponding values in the enum. When an entity bean is persisted to the database one of these values from the enum will be persisted which ensures data integrity EMBEDDED OBJECTS AND COMPOSITE KEYS An entity bean can have other Java objects embedded within them. These embedded objects contain property mappings which the entity manager will map to the entity bean. The entity bean will inherit these new mappings to add to ones that it itself defines. These objects are defined as embeddable objects through annotation. One of their uses is in the definition of composite primary keys. Since an entity bean cannot have more than annotation an embeddable class can be used to define the object to relational mappings for the primary key properties. This embedded class can be then be defined as the primary key class of the entity bean via public class StudentPK = university_id ) private Integer = surname ) private String surname; public CompositePK(Integer uniid, String surname) { this.uniid = uniid; this.surname = student ) public class Student implements Serializable private StudentPK = name ) Private String name; ENTITY RELATIONSHIPS Entity relationships can be mapped in EJB just as they can in relational databases, providing a mechanism for easy domain navigation between related entities. Many different relationship types can be mapped to cover the various relationships that can be mapped in a relational database, and there is a notion of directionality that is not present in a relational database. 17

18 One to one relationships can be mapped using annotation. This annotation is applied to the property in the same way annotations are. For example, assume we have a Customer entity and an Address entity which we want to relate using a one to one relationship. The Address entity can define a relationship that indicates that an Address entity is related to a corresponding Customer public class = customer_id ) private Customer customer; This is an example of a unidirectional relationship since the Customer entity is unaware of the Address entity. The example assumes that the table in the database for Address has a foreign key column called customer_id that is used as the join column between the two tables. annotation provides the entity manager with this information and is used in place of the annotation. It is important to note that although the Customer entity bean is involved in this relationship it does not need to be mapped by the Customer entity bean as well. This is because an entity bean only needs to map the relationships that it is interested in for the benefits of domain navigation. We can modify this example to demonstrate a bidirectional one to one relationship, where Customer entity does have a reference to an Address entity, and the Address also has a reference to the public class = customer_id ) private Customer public class Customer = customer ) private Address address; The mappedby argument to annotation in the Customer class tells the entity manager that the property named customer in the Address class has the information necessary to map this relationship. One to many relationships can be mapped using annotations. When used on their own they represent unidirectional relationships between entities. The choice of which annotation to use depends one whether the entity bean in question is on the many side of the relationship or the one side of the relationship. If we update our earlier example so that a Customer entity bean can now have many Address entity beans related to it we can map a one to many public class = customer_id ) private Set<Address> addresses; In this example the property has become a collection of Address entities rather than a single entity as it was in the one to one relationship described earlier. The other difference to note is that annotation has specified the name of the foreign key column in the Address table rather than a column in the Customer table. For a bidirectional one to many relationship both annotations are used in the appropriate beans, with one side owning the relationship mapping as in one to one bidirectional public class = customer_id ) private Customer customer; 18

19 @Entity public class Customer = customer ) private Set<Address> addresses; Besides providing an easy way to navigate between related entities, entity relationships can be used with cascading and lazy/eager initialisation. Cascading allows for entity manager operations like persist and update to be automatically performed on the related entities of an entity bean. In the flowing example cascading is applied to our relationship between the Customer and Address entities, which allows a new customer to be persisted along with their related address in a single call to the entity = FetchType.EAGER, cascade = = address_id ) private Address address; Customer customer = new Customer(); Address address = new Address(); customer.setaddress(address); entitymanager.persist(customer); //Both address and customer entities are persisted to the database Relationships can define whether they are eagerly or lazily initialised. The example above shows how this is specified on a relationship. If a relationship is defined as being eager then whenever the entity manager loads an instance of an entity from the database all its corresponding related entities are also loaded at the same time. Lazy initialisation on the other hand does not cause the entity manager to retrieve the related entities from the database until they are accessed explicitly at a future point in time ENTITY INHERITANCE Entity inheritance allows for entity beans to become part of inheritance hierarchies. The Java Persistence API provides three strategies for mapping entity inheritance to a relational database: a single table per class, a table per subclass and table per concrete class. Of these only the first two are of interest SINGLE TABLE PER CLASS STRATEGY The single table per class strategy has a single database table representing every class in an inheritance hierarchy. The database table therefore has fields for all the properties that the entity beans in the hierarchy can have. In order for the different entities to be identified from this single table there needs to be some way of discerning which rows correspond to which entity beans. This is achieved through the use of a discriminator column. This column in the database table holds the values that will be used to identify which entity bean each row maps to. Each entity bean in the hierarchy has an annotation that defines the value in this column that they expect. The example below shows an inheritance hierarchy using this strategy: create table Product( id integer primary key, name varchar(30), artist varchar(30), product_type = = product_type, discriminatortype = DiscriminatorType.STRING) public class = id ) private Integer = name ) private CD ) public class CD extends Product = artist ) private String artist; 19

20 Our database table holds all of the properties that both of our entities use. The root of our class hierarchy is the Product class, and this is where the majority of the metadata is specified for our inheritance hierarchy. annotation is used to specify what inheritance strategy this class and all its subclasses uses. annotation identifies the column in the database table that will be used to determine which rows map to which entity beans in our hierarchy. It also defines what type the values in the discriminator column will be. If we look at our CD subclass we will notice that it extends the Product class. This allows us to inherit all the properties of the Product class and use them in our CD class. annotation is used to specify the value that the discriminator column will have for entities of this type. We also define some new properties for this class that do not form part of the Product class since they are specific to this entity bean, even though these properties are all in the same database table. Notice that the CD entity bean does not need to define a primary key column with annotation. This is because this is inherited from the Product class TABLE PER SUBCLASS STRATEGY The table per subclass strategy has a table per entity bean in the inheritance hierarchy and that table holds only the properties defined in that bean. This strategy requires there to be a column in each table that can be used to join each table. This is required because when the entity manager tries to load an entity bean in the hierarchy it needs to perform an SQL join with all the other tables in the hierarchy up to that point. It is usually the primary key of each table, but it can be any column as long as contains the values that will allow the join to be performed. create table Product( id integer primary key, name varchar(30) ) create table CD ( id integer primary key, artist = InheritanceType.JOINED) public class = id ) private Integer = name ) private public class CD extends Product = artist ) private String artist; In the example above the database tables only have the properties that are specific to the entities that they represent unlike the single table example we have just looked at. This is similar to what we are trying to replicate in our entity bean inheritance hierarchy, although we must also provide the data from the other classes in the hierarchy in our entity beans rather than only the properties in the corresponding table. Like in our single table per class example we need to annotate the root class of our hierarchy with annotation to specify the inheritance type. This strategy is known as Joined. For the first subclass in our hierarchy the only thing we need to specify is the column that will be used for the SQL join. In this case both database tables will be related by the id columns in the database tables, i.e. their primary keys. annotation can be used to indicate this, although if the primary keys of both tables have the same name it is not strictly necessary as this is assumed by the entity manager if the annotation is absent. We then just map the entity s properties to the fields in the CD database table. Again notice that the CD class does not need to specify a primary key column as this is inherited from the Product class. 20

21 MAPPED SUPERCLASS In the inheritance hierarchies presented in the strategies above every class in the hierarchy has an associated table in the database. This is not always the case however, as there may be opportunities to encapsulate common code into a superclass that doesn t correspond to a table in the database. In this instance EJB provides annotation to allow for this mapping. Although not an entity bean class it does still define column mappings that subclasses will inherit, and as such is useful when two or more entities share similar columns that can be encapsulated into a common base class. For instance, if we continue our example using products we might have CD and DVD tables in the database that share similar properties which we could encapsulate in a mapped superclass: create table CD ( id integer primary key, price integer, artist varchar(30) ) create table DVD( id integer primary key, price integer, title varchar(30) public class = id ) private Integer = price ) private Integer public class CD extends Product = artist ) private String public class DVD extends Product = title ) private String title; QUERIES & EJB QL One of the reasons relational databases are so useful is the ability to query them to extract information. As a result Java Persistence provides two ways of querying a database: via native SQL or by using EJB QL. EJB QL is similar to SQL in that they are both declarative query languages but instead of using the databases relational schema it works with Java objects in the form of entity beans. Since entity beans provide the application server with all the information it requires to map them to the database through the beans metadata the server can build up an abstract persistence schema for the entity that details its properties and relationships. When executing an EJB QL query this information is used by the entity manager to generate the corresponding SQL query that is then executed on the database. This process is easiest to see with Cust ) public class Customer = Name ) private String name; Assume we want to query the database for all customers whose name begins with a J. We would create and execute a query like so: 21

22 Query query = entitymanager.createquery( SELECT c FROM Customer c WHERE c.name LIKE?1 ); query.setparameter(1, J% ); query.setfirstresult(0); query.setmaxresults(10); List results = query.getresultlist(); Take a look at the EJB QL for this query. The first thing to notice is that it looks very similar to SQL but there is a key difference to highlight the table in the database that our entity bean maps to is called Cust but our EJB QL uses the name of the entity bean, Customer. Also, the use of the?1 in the EJB QL is to allow for customisable parameters to be set in the query before it is executed. The other thing to notice is that we have decided to page our results by setting the index of the first result and the maximum number of results we are interested in before executing the query. This does not form part of the EJB QL so the use of paging is completely optional and independent from the EJB QL query. When the query is executed the entity manager performs the conversion of the EJB QL and all other query options to SQL to execute on the database and returns the results in a list. By using EJB QL instead of the native SQL not only are things much easier to understand but also the results of our query will have been converted into our entity types automatically by the entity manager. This is because the entity manager knows from the EJB QL that we expect to get Customer instances back and so performs the conversion to entity bean instances for us automatically. Using SQL would return a result list of object arrays to represent each row returned. Although EJB QL provides the majority of features that are available with SQL it does have its limitations. Since it is generic and non database vendor specific it cannot take advantage of any proprietary features of the underlying database should it offer any and it is also unable to execute stored procedures. However, since Java Persistence provides a mechanism for executing native SQL on the database these problems can be overcome NAMED QUERIES Java Persistence allows developers to predefine EJB QL or SQL queries which are expected to be reused in multiple situations. The queries are associated with a name which is then used to look them up when a new query is created. Each entity bean can have a number of named queries associated with them, and this is done through the use annotation (or of course the XML equivalents in a deployment descriptor). Below is = CustomerQuery, query = SELECT c FROM Customer c ) public class Customer { Once a named query has been defined on an entity bean we can then reference this when we create queries instead of having to copy and paste the EJB QL. This is done like so: Query query = entitymanager.createnamedquery( CustomerQuery ); 2.6 SESSION BEANS Session beans are server side components that be accessed from remote clients via the API that they expose in the form of a remote interface or web service. They are typically used to represent business processes that a client would want to perform, with each method typically representing a particular task that may require the bean to interact with several other session beans and entity beans. They come in two types: stateful and stateless STATEFUL SESSION BEANS A stateful session bean is one that maintains a conversational state with the client and therefore there needs to be one instance per client that is accessing the stateful session bean. Conversational state is not written to persistent storage, but is instead information that is kept in memory in the bean s instance variables while a client carries out a conversation with the bean and is lost when the conversation ends. This means that the same bean instance must service every method invocation from its client so that this state is preserved across method calls. This means that instance pooling is not possible for stateful session beans as it is with stateless session beans as the state specific to the client would not be available. 22

23 Stateful session beans are typically specific to scenarios where information needs to be maintained and shared across a number of method invocations from the client. For example, a web client that uses a stateful session bean may have several pages where the user inputs data and this should be remembered by the bean as the user goes through the different pages before affecting the behaviour of subsequent method calls. Below is an example of very simple stateful session bean to represent a shopping public class ShoppingCartBean implements ShoppingCartRemote = testdb ) private EntityManager entitymanager; private List basket; public void addtobasket(product product) { public void purchase() { Order order = new Order(basket); enitymanager.persist(order); The class is designated a stateful session bean as a result of the use of annotation, which informs the application server of the type of bean this class is. In this example our bean has a list that is holding all the products that have been added to our shopping cart via the addtobasket() method. This conversational state needs to be maintained between method calls otherwise when we call our purchase() method we would be creating an order without any products. The only other thing to note in our example is the use of annotation on the purchase() method. This annotation informs the application server that after this method has been executed the client will no longer require the session bean and this instance can be removed from the EJB container LIFECYCLE It is common for stateful session beans to have a timeout period which upon expiration will trigger the passivation process. Similarly, these beans can be passivated by the application server when not active. This is to prevent instances hanging around in memory for clients that have not performed any actions for an extended period for whatever reason, perhaps because the user has stepped away from their machine or the client application has crashed. This results in the following lifecycle for a stateful session bean: Figure 2.5: Stateful session bean lifecycle As can be seen in the diagram the bean s lifecycle consists of three states: does not exist, method ready and passivated. In the does not exist state there is not yet an instance in memory. The method ready state is the state in which the bean instance can service requests from its client. When transitioning between the does not exist to method ready state three operations are performed. Initially a new instance of the stateless session bean is created via the 23

24 Class.newInstance() method, followed by the application server injecting the bean with any resources it may have specified it needs in its metadata. After this the EJB container makes a call back to annotated method of the bean if one exists where initialisation code is usually located. While in the method ready state the bean instance is free to receive method invocations from the client and maintains conversational state between itself and the client in its instance variables. Bean instances leave the method ready state to enter either the does not exist state or passivated state. A client can end a bean s life by invoking a method that is annotated at which point method of the bean class is called if one exists to free any resources that the bean may need to release. It can also transition to the does not exist state if the bean times out, i.e. has not been active for a period of time. It may or may not when the bean times out. A bean instance may move to the passivated state if the bean has been inactive for some time and the container wishes to conserve resource by evicting the instance from memory after having its conversational state preserved. Before being passivated the bean method is called if one exists and usually closes any open resources the bean was using. At this point the bean moves to the passivated state and is serialized to secondary storage. If a client makes a request on a passivated bean the bean is activated again and transitions back to the method ready state. This is done by de serializing the bean instance and moving it back into main memory. Once this is done call back is invoked if there is one for the bean to reopen any resources the bean needs. Alternatively, if a timeout occurs when in the passivated state the bean instance is destroyed and moves to the does not exist state. Finally, when a system exception is thrown by a bean method the container will destroy the bean instance STATELESS SESSION BEANS A stateless session bean is one that does not maintain a conversational state with the client and therefore allows a single instance to service multiple clients. Usually several instances are created by the EJB container and stored in an instance pool, any of which can then be selected to service client requests. This is much more efficient than a stateful session bean. Stateless session beans provide better performance and consume fewer resources than entity and stateful session beans because a few stateless session bean instances can serve hundreds or possibly thousands of clients. They are typically a collection of related services that take a set of parameters and return a result with each method being completely independent, using only the data passed to it in its input parameters to perform its work. Below we will extend our simple random integer generating bean that we have seen before as an example of a stateless session public class RandomIntegerBean implements RandomIntegerRemote { public int getrandominteger() { Random random = new Random(); return random.nextint(); public void getrandominteger(int minimum, int maximum) { Random random = new Random(); int randomint = random.nextint(maximum - minimum); return randomint + minimum; The class is designated a stateless session bean as a result of the use of annotation, exactly the same as we have seen with annotation for stateless session beans. Within our bean we have two methods to generate and return a random integer. Notice that the class does not have any member variables and that each method only uses its input parameters to perform its task LIFECYCLE The lifecycle of a stateless session bean only has two states: does not exist and method ready pool. 24

25 Figure 2.6: Stateless session bean lifecycle In the does not exist state there is not yet a bean instance in memory. The method ready pool is an instance pool of stateless session bean instances that are not currently in use by any clients, the number of which is managed by the server. Not all EJB application servers will use instance pooling and may create and destroy instances when each client request arrives, but because of the potentially large overhead of instantiating an instance if the bean has a significant amount of initialisation code it is usually more efficient to save bean instances when they are not in use and reuse them. This concept of instance pooling in the life cycle is an important difference between a stateless and stateful session bean. When transitioning between the does not exist state to the method ready state the same three operations we saw when creating a stateless session bean are invoked. When the bean is in the method ready pool state it is prepared to service client requests. The application server selects an instance from the pool to handle a client request as it arrives, and while it is processing a request the instance is unable to deal with any other requests. As a result of this a client is not guaranteed to have the same instance process their requests every time they call a method exposed by the bean, which is why they cannot maintain state. Bean instances transition back to the does not exist state when the server no longer needs them, usually when the server decides to reduce the size of the instance pool. Again, method of the bean class is called if one exists to free any resources that the bean may need to release. 2.7 MESSAGE DRIVEN BEANS Message driven beans (MDB) are different to session beans in the way that they are accessed. Instead of exposing an interface to clients who then invoke the bean s methods message driven beans are accessed through the sending of messages. Message driven beans are associated with destination addresses that the messages get sent to. When an incoming message arrives at one of these addresses the onmessage() method of the MDB that registers its interest in that destination is invoked. This takes a copy of the message and then processes it. Whilst message driven beans can process any messages sent via a messaging system that implements the Java Connector Architecture 1.5 (JCA) the usual messaging system that is used is the Java Message Service (JMS). The other key difference between message driven beans and session beans is that messaging systems are asynchronous, rather than the synchronous messaging of RMI that is used with session beans. Being asynchronous allows message driven beans able to handle operations that do not require an immediate response, or indeed even a response at all. For example, a user of a website might click on a button labelled subscribe to mailing list that in turn triggers a message to be sent to a MDB to add the user to an list. This call is asynchronous because the user does not need to wait to be informed of its success or failure. Message driven beans do however share a number of similarities with stateless session beans. Neither maintains any conversational state which allows the application server to use instance pooling on them both, and as such their lifecycles are the same. 25

26 2.7.1 LIFECYCLE The lifecycle of a message driven bean is almost identical to that of a stateless session bean. The only difference is that while in the method ready pool the instances are awaiting messages to arrive rather than for clients to explicitly invoke a method on them JAVA MESSAGE SERVICE The Java Message Service is a message orientated middleware (MOM) that allows for messages to be sent between applications over a network. Applications that send or receive JMS messages are known as JMS clients, with those that send messages being referred to as producers and those that receive messages being known as consumers. A JMS client can be both simultaneously. A JMS provider is responsible for routing the messages between clients. The JMS API provides a number of different message types for sending data of different forms. The most frequently used are TextMessage, MapMessage, and ObjectMessage. The data types they transfer can be inferred from their names MESSAGING MODELS JMS supports two messaging models: publish and subscribe (pub/sub) and point to point (p2p). The pub/sub model is used to broadcast messages to multiple consumers. The messages are sent via topics. A consumer subscribes to a topic and any messages sent to this topic are delivered to all the topic s consumers. The point to point model uses queues which producers to send messages to and consumers to read messages from. Unlike the pub/sub model only a single consumer will receive the message even though the queue can have multiple consumers. This ensures that the message is only processed once MESSAGE DRIVEN BEANS USING JMS Most message driven beans are developed using JMS as all EJB application server vendors are required to support a JMS provider. For a message driven bean to be useful it must have messages sent to it from a JMS client, otherwise it will have nothing to process. Below is a simple example of a JMS client sending a message: public class SimpleJMSClient { public void static void main(string [] args) { Context jndicontext = new InitialContext(); ConnectionFactory factory = (ConnectionFactory) jndicontext.lookup( ConnectionFactory ); Queue queue = (Queue) jndicontext.lookup( displayqueue ); Connection connect = factory.createconnection(); Session session = connect.createsession(true, 0); MessageProducer producer = session.createproducer(queue); TextMessage textmessage = session.createtextmessage(); textmessage.settext( Hello ); producer.send(textmessage); connect.close(); There are a number of things that need to be set up before a message can be sent. Firstly the client needs to acquire a connection to the JMS provider running on the application server. This is exposed via the ConnectionFactory that we lookup via JNDI. We also use JNDI to gain a reference to the destination address of our messages, in this case a queue named displayqueue. Having acquired the remote references to these two objects from the application server we can establish a connection to the JMS provider through the call to factory.createconnection() and create a session with that connection. The session provides the ability to send and receive messages through its MessageProducer and MessageConsumer objects. Here we are sending messages so we gain a reference to the MessageProducer and in the process inform it of our destination. After this we can create and populate our message to send and then send it. Our JMS client would not be very useful if there was not message driven bean to receive and process these messages. The following example is a simple message bean that displays the text it receives from the messages sent by our example JMS client: 26

27 @MessageDriven (activationconfig = = "acknowledgemode", propertyvalue = = "destinationtype", propertyvalue = propertyvalue=" displayqueue") ) public class DisplayMessageMBean implements MessageListener { public void onmessage(message message) { TextMessage textmessage = (TextMessage) message; System.out.println( Message: + textmessage.gettext()); annotation indicates to the application server that this class is a message driven bean. More importantly however it also provides the application server with the configuration necessary for this MDB. supplies the server with information about what messages this MDB has registered its interest in. In this case we are registered to receive messages delivered to the destination queue named displayqueue, the same destination that our JMS client sent the messages to. The class also implements the MessageListener interface and the corresponding onmessage() method. This processes a TextMessage which is one of the JMS message types whose message body simply contains a string. 2.8 INTERCEPTORS Interceptors are a feature of EJB that allow developers to gain fine grained control over the method invocations. Importantly the interceptors are separate classes that allow extra code to be executed along with a bean s methods rather than needing to include it in the bean s business logic code. In most cases it is useful for separating validation rules from the actual business logic of a bean, or adding profiling to the beans without including it in the actual source code of the bean classes themselves. They are also commonly used to modify the input parameters to bean methods and catch exceptions thrown by them. To make the features of interceptors clear let us assume that we want to add some profiling to one of our beans to provide performance statistics. Obviously we would not want to add this code to the bean class itself as we will only want this information provided during testing and it should not be included when the bean is released into the real world. Although this could be achieved by commenting out the code and recompiling this is unnecessary if we use interceptors. Below is an example of our method performance profiling interceptor: public class MethodPerformanceProfiler public Object profile(invocationcontext invocation) throws Exception { System.out.println( Bean: + invocation.gettarget()); System.out.println( Method: + invocation.getmethod()); System.out.println( Arguments: + invocation.getparameters()); long starttime = System.currentTimeMillis(); try { return invocation.proceed(); finally { long executetime = System.currentTimeMillis() starttime; System.out.println( Executed in + executetime + milliseconds ); annotation on the profile() method tells the application server that when this interceptor is used this method will be invoked instead of the actual bean method itself. The call to invocation.proceed() is what actually executes the bean method. A benefit of using an interceptor to draw performance statistics from a method is that we can reuse the same interceptor on any of our beans. This is because they use annotations (and therefore XML deployment descriptors) to allow their behaviour to be applied to any bean. In order to apply this interceptor to a bean we will annotate our bean to tell the application server what interceptor to run when this bean s methods are invoked by public class RandomIntegerBean implements RandomIntegerRemote { public int getrandominteger() { Random random = new Random(); return random.nextint(); 27

28 Here we have added annotation to our earlier session bean example. As an argument to this annotation we have specified the interceptor class we want applied to the methods of this bean. Whenever a client uses the bean the application server will route the request from the proxy stub to the interceptor. Interceptors can also be applied on a per method basis rather than on the whole bean. This is done by simply moving the annotation from the class level to the method level. 2.9 SECURITY The Enterprise JavaBeans specification provides three types of security that must be supported by EJB compliant application servers: authentication, authorization and secure communication. Of these the two that are most used are authentication and authorization. Authentication is where the identity of a user is validated. This is typically used on secure systems whereby a user must first supply a username and password before they can access the system. The application server is responsible for checking that the user exists and has supplied the correct credentials so that unauthorized access to the system is prevented. It does this by assigning a security identity to each client that tries to access the beans on the server. Each time a client tries to access a bean their security identity is passed implicitly with the method invocation. The bean then checks whether or not the user is valid and if not aborts the invocation of the method. There is no standard way of passing credentials to the server when a client connects, however it is typical for JNDI to be used by passing the client s id and credentials as part of the properties of the connection to the server. Authorization builds on the security provided by authentication. Once a user has been validated by the application they will have access to perform method invocations on the beans. However, in most circumstances this black and white definition of full access or no access is not enough. Authorization is used to provide another level of authentication on a per method basis. Each user is assigned one or more roles in the system and their roles dictate what methods they have access to execute. Usually roles represent groups of people. For instance, a user may be a member of the admin group, but might also be a member of the manager group. In this example it is likely that being a member of the manager group would open up more of the system to the user. Bean methods can be annotated with annotation to specify what roles are permitted to invoke the method. For example, only users in assigned the manager role will be able to invoke the method in our example bean below: public class RandomIntegerBean implements RandomIntegerRemote manager ) public int getrandominteger() { Random random = new Random(); return random.nextint(); Using annotation informs the application server of the check it needs to make on the user s identity which it does automatically. In some circumstances however it is necessary to have access to the user s security information which can be obtained through the SessionContext object. This provides information on the context of the method call, including information on the user s identity. The example below is the programmatic equivalent of our earlier example: public class RandomIntegerBean implements RandomIntegerRemote SessionContext sessioncontext; public int getrandominteger() { if(ctx.iscallerinrole( manager )) Random random = new Random(); return random.nextint(); else throw new Exception( User not in correct role ); 2.10 WEB COMPONENTS Web components is a collective term used for servlets and JavaServer Pages. Both of these are key components of the Java EE platform. Most application servers that adhere to the EJB specification also comply with the rest of the Java EE specification and thus come bundled with support for servlets and JSP. This allows for EJB and web components to interact therefore allowing companies to expose their business logic to the Internet. 28

29 SERVLETS Servlets are server side components that are responsible for generating dynamic web pages. Much like session beans they receive requests from clients (in these cases web clients), service these requests and typically provide a response of some kind. Also much like Enterprise JavaBeans servlets are written in plain Java code. Of the two web components servlets are the ones that can interact with the beans running in the EJB container on the same application server, and as such are the gateway between the Internet and the business logic. Each servlet is assigned a web page that it is responsible for handling requests for. Each time this page is accessed by a client the web container sends a request to the corresponding servlet for processing by invoking the doget() method. Whilst it is possible for servlets to generate dynamic HTML as its response, it is far more common for servlets to be used in conjunction with JavaServer Pages via web forms. A user will enter information into a form on a JSP and when they submit this information it is forwarded by the JSP to the servlet by invoking the dopost() method. The servlet then processes this information and can choose to send a response back to the same JSP or to another JSP for display in the client s web browser. In order to send responses back to JSP pages servlets can embed their results in the request object or in the session object. A session is created for each web client for the duration of the time that they are connected with the web container, and during this time allows the client to access any variables stored in the session object. The request object is only available for the duration of a single request to a servlet and can be used if the results the servlet wants to forward to a JSP only need to be available in the short term. Once the request has been processed the results are no longer available to the web client. The following example shows how a servlet can respond to a request either directly from a web client (invoking the doget() method) or from a JSP (via the dopost() method) by forwarding the results to a JSP page: public abstract class ExampleServlet extends HttpServlet { protected void doget(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { processrequest(request, response); protected void dopost(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { processrequest(request, response); private void processrequest(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { HttpSession session = request.getsession(true); session.setattribute( name, james ); //available to access for length of client s session request.setattribute("name", james ); //available to access for length of this request RequestDispatcher disp = this.getservletcontext().getrequestdispatcher( /web/somejsp ); disp.forward(request, response); JAVASERVER PAGES JavaServer Pages are HTML pages that include the use of Java as a scripting language. They are very closely related to servlets, mainly due to the fact that during runtime JSP pages are translated and complied into servlets themselves by the application server. They are useful in providing the presentation layer for the results a servlet returns, allowing a further separation of the business logic from the presentation tier. The following is a small code example of a JSP page: <html> <body> <p>my name is stored in a session variable called name. Using JSP we can display it below:</p> <p><%=(string)session.getattribute( name )%></p> </body> </html> WEB COMPONENTS AND EJB Combining web components and EJB allows businesses to expose their business logic to the world through the Internet. Having discussed EJB and web components in depth we can now see how they fit together to provide distributed business applications: 29

30 Figure 2.7: Fitting web components and EJB together As the diagram presented in Figure 2.7 shows, combining web components with EJB allows for the creation of a multitiered architecture that provide clients with access to the business logic provided by Enterprise JavaBeans through the use of JSP pages and servlets. This architecture allows for maximum reuse of the EJB components that contain the business logic by all clients. 30

31 CHAPTER 3: REQUIREMENTS SPECIFICATION This chapter presents the full requirements specification for the project including the essential features that must be implemented to meet its aims as well as several other requirements that, time permitting, would be beneficial. 3.1 PURPOSE OF THE PROJECT The purpose of the project is to develop a component based online ordering system for a fictitious company. The company in question retails electronic entertainment media and is looking to take advantage of the Internet to retail its products to a far greater audience. To facilitate this objective the company requires the development of a system that can make the ordering of their products over the Internet a possibility. The key goal that the company has specified is to provide their customers with an online ordering system that is accessible through a website and is also accessible to their employees through a custom built application client. 3.2 USERS OF THE PROJECT There are two main groups of users of the system: the customers and the company s employees. Customer User Name User Category User Roles Subject Matter Experience Technological Experience Other Characteristics Customer Key User The user is responsible for interacting with the website to browse the company s products and purchase them online Novice Novice / Journeyman / Master The customer user group represents a large audience with widely differing skill sets. Whilst none with understand the intricacies of the business many will be aware of how similar firm s retail their products online and how their websites work. From a user technical background perspective nothing can be assumed; some users will be experts with web technologies while others will have a very basic understanding. The customers also represent a broad age group The company s employees can be broken down into two groups of users: administrators of the proposed system and those with general access who interact with the system on an infrequent basis. Casual User User Name User Category User Roles Subject Matter Experience Technological Experience Other Characteristics Administrator User Name User Category User Roles Subject Matter Experience Technological Experience Other Characteristics Casual User Secondary User Maintaining company data Journeyman Novice As a secondary user (or perhaps even an infrequent user) of the system the users are unlikely to display much motivation for learning how the system works other than for the functions they require to do their work which means the client should be intuitive for them to use Customer Key User Maintaining company data Master Journeyman As a full time administrator of the system the user will gain a detailed knowledge of the business and the technology behind it. The client should provide them with the ability to perform all the actions they require 31

32 3.3 PROJECT CONSTRAINTS The key constraint on the project is time. It is suggested that 240 hours of work should go into the project as a whole, covering the phases of research, design, implementation, testing and report writing. This figure is only a guide however. The real constraint on time is that the project must be completed by the beginning of May 2007, which gives the project a total time of around seven months in which to be developed. The other constraint on this project is that it must be implemented as a component based system, written using EJB FUNCTIONAL REQUIREMENTS The functional requirements for the project have been split into two categories: essential and desirable. The essential requirements are exactly that, i.e. the features the system must have in order to meet the aims of the project. The desirable requirements are features that would add significantly to the projects usability but are not required for the project aims to be met. After all of the essential requirements have been met the remaining time of the project can be used to implement the desirable features. Each category of requirements has been further split into sections based on what part of the system the requirement relates to. These are classified as general, website or administrative client requirements. Rather than list each individual requirement separately groups of requirements have been grouped together and described ESSENTIAL GENERAL Requirement Component Based Relational Database Ordering Functionality Description The system must be comprised of a number of software components that can be reused in the development of the website and administrative client A relational database is required to store the companies data that will be managed by the administrative client and presented on the website The development of the ordering functionality is the key goal of the project, and will be central to the functions of the website WEBSITE Requirement Access to Ordering System Appropriate Presentation Customer Registration Security Product Categories Product Actions Wish Lists Description The website must provide access to the ordering functionality of the system to allow customers to make purchases. A shopping cart will need to be created to facilitate this The website should be presented in a way that is intuitive to the users so they are not put off by a confusing design. It should mimic similar websites already in existence that retail products so that customers feel familiar with its layout from the outset Customers should be allowed to register themselves with the company to provide all their personal details that will be required to make an order Customers should be required to login to the website to gain access to the features that it offers and allow them to access their account information Since the firm offers a range of electronic media a number of categories of products should be available on the site A number of product actions should be provided, such as the ability to browse products by category and also to search products. Product details should be available on request. Products can be added to wish lists or the shopping cart for purchase. Users should also be able to rate products to indicate to other users what they think about the product in question The website should provide wish list functionality whereby the user can save a list of their desired products for purchase at a later date. Customers can have as many wish lists as they desire 32

33 ADMINISTRATIVE CLIENT Requirement Customer Actions Product Actions Order Actions Security Description The client should provide access to all customer records, providing the ability to create new customers and edit or remove existing ones. A search facility for finding customers in the database is also required The client should provide access to all product information, providing the ability to add new products and edit or remove existing ones. A search facility for finding products in the database is also required This should provide users with a way to manage customer orders. The user should be able to create a new order for a customer and also edit existing orders The client should be secure as it is intended for company employee s use only. Different levels of access to the client should be enforced to prevent casual users from having full access to the system DESIRABLE GENERAL Requirement Notification PDF Generation Recommendation Engine Description Upon the completion of certain actions by the system notifications could be sent out to interested parties. This could include s to the customers confirming their registration and s as receipts of orders Building from the above requirement the system could generate PDF files as the receipts for customer orders that can then either be ed to the automatically or via a tool A recommendation engine could be developed to analyse customers browsing and purchasing trends and use this to recommend other products that customers with similar interests have bought or viewed WEBSITE Requirement Recommended Lists Gift Vouchers Special Offers Product Review Googlemap Address Locator AJAX Description Similar to wish lists this functionality would allow customers to put together lists of products that they recommend to other people that customers can then search A gift voucher product category could be introduced that could be purchased like any other product and also used to pay for orders Special offers could be defined that would affect the pricing of products Customers could be allowed to the review products on the website to convey their opinions to other customers When a customer enters their address into the website Googlemaps could be used to validate the address entry by showing the customer the location of the address that they have entered Implemented AJAX features to the website for the product search could be used to take advantage of the latest developments in web technology ADMINISTRATIVE CLIENT Requirement Employee Details Newsletter Description Another area of management could be introduced to cover employees details in much the same way as customer management The client could include a tool for generating newsletters that could be sent out to all registered customers detailing popular products 33

34 3.5 DATA REQUIREMENTS The company requires all its data to be stored in a relational database. From the essential functional requirements and associated concepts a domain model has been identified that represents they key data requirements of the business: Figure 3.1: Domain model 34

35 CHAPTER 4: DESIGN This chapter presents the design of the system as a whole, including the database, enterprise beans, website and administrative client. The system was designed with a multi tier architecture and the following sections are organised in the order that the layers were considered, starting from the data tier of the system and progressing through to the presentation tier. 4.1 SYSTEM ARCHITECTURE A multi tiered architecture was decided upon for the system. The reason behind this was that it provided a logical separation of the different parts of the system based on the functions they provided. Figure 4.1 presents the logical separation of the component parts of the system into three layers: Figure 4.1: Multi tier layers At the base of the tiers is the data access layer which is responsible for handling all interaction with the system s data. This includes the database where the data is to be stored and the entity beans that are used to provide access to the data contained within the database. The next layer up is where the business logic resides. The components in this layer are responsible for providing the functionality that drives our fictional business, such as the business logic for the ordering of products and management of customers. The servlets also live in this layer. Whilst not strictly business logic themselves they are responsible for accessing the other components in this layer and passing on their results to the presentation layer. The presentation layer contains the GUI code for the administrative client and the JSP pages from the website that are used solely as ways do interact with the business logic and display the system s data. Figure 4.2 presents the system architecture as a whole: Figure 4.2: System architecture 35

36 4.2 DATABASE DESIGN The first phase in designing the individual parts of the system was to devise the database schema since this was to form the base of the system as a whole. Its design was crucial as it would influence many of the subsequent decisions concerning the enterprise beans. The first step in designing the database schema was to identify what entities would need to be created and how they would relate to one another. Only after the entities had been identified and the relationships mapped could a complete listing of their attributes including primary and foreign keys be drawn up. The schema proposed is shown in Figure 4.3. Figure 4.3: Database Schema 36

37 The fictitious online retailer that that system is being designed for has customers, and as such there needs to be an entity to represent a customer. A customer has a number of things associated with it which can be mapped by other entities, such as an address and payment card. It is likely that the customer will have more than one of each of these, so there is a one to many relationship between the customer and these entities. The website allows a customer to write reviews for products, therefore requiring an entity to represent the reviews and a one to many relationship between the customer and the review entity. The customer also has a set of preferences for the website that can be stored in the database, with there being a one to one relationship between a customer and their set of preferences. Part of the customer preferences requirement is the ability to store a default delivery address, which requires a oneto one relationship between this and the address entity. It also specifies that a default wish list be referenced which requires an entity to represent the concept of a list. There are two types of list that need to be represented in the database: wish lists and recommended lists. A single entity can represent both of these lists using a column to distinguish which type of list each entry in the entity corresponds to. Each list has a number of related products, and a product can be in many lists. This many to many relationship can be mapped through a join table for list products. Since there are two types of lists there needs to be two join tables, one for the wish lists and one for the recommended lists. There are a number of different types of product that the online retailer offers, and each one has its own entity. These are related to the product entity in that there is a corresponding entry in the product table for each row in these other entities. This allows for the entities to inherit the attributes of the product entity and add their own specific attributes to give a full description of the product. The concept of an order needs to be represented in the database. Since an order can be for many products and a product can be in many orders, there is a many to many relationship between the order and product entities. An ordered product entity is used as a join table to help map this relationship. The order entity is also involved in a number of other relationships. It has two one to one relationships with the address entity to specify an order s billing and dispatch addresses. It also has a one to one relationship to a customer and a payment card. Once the entities and relationships between them had been identified it was possible to accurately define the primary and foreign keys for each table as well as the rest of each entity s attributes. These have been listed in the diagram, with those attributes in blue being foreign keys and those in red being foreign keys that are also the primary key of an entity. 4.3 ENTERPRISE JAVABEANS DESIGN ENTITY BEANS The design of the entity beans is heavily influenced by the database design that has already been presented. There will need to be a single entity bean implemented for every table defined in the database to allow the system to interact with all the tables. The design of the database was made with the intention that it would provide opportunities for the various features of the Java Persistence API to be tried, and there is clearly the potential to use entity relationships and cascading, as well as entity inheritance in the implementation of the entity beans SESSION BEANS A number of stateless session beans are needed to handle entity bean management, which involves providing all the database actions for an entity such as persisting, merging and removing. There will not need to be one stateless session bean per entity bean since a number of entity beans will make use of cascading which eliminates the need to perform database actions specifically on each entity. Besides basic database operations several of these entity management session beans will need to implement business logic relevant to their corresponding entity beans. This will allow the session beans to encapsulate all the functions related to their entity beans that other beans can then use rather than having the code spread out amongst the session beans. This also presents the opportunity to implement a series of session bean façades that can wrap up the functions offered by related entity management session beans to provide a single interface for a number of different session beans. Figure 4.4 presents the proposed architecture for the session beans (note the arrows indicate the interaction between the beans, e.g. the Product Manager uses the DVD Manager): 37

38 Figure 4.4: Session bean architecture The Account Manager and Product Manager are façades, wrapping up the functionality of the other session beans that they interact with. By using façades the number of session beans that need to be exposed to external clients is reduced. The session façades can expose a remote interface which allows external clients to connect to a single session bean but gain access to the functionality of several. Local interfaces are to be utilised as much as possible in the interests of efficiency, since they do not require remote method invocations and the associated overhead that entails. Remote interfaces will be kept to a minimum, only exposing those functions that external clients will need to access for both efficiency and security. The only stateful session bean that needs to be implemented is the shopping cart session bean since this is the only session bean that has been identified as having to maintain conversational state. This bean will need to maintain a list of products that the customer is interested in purchasing, as well as order information such as delivery address for use when the customer makes the purchase. The session beans are designed to contain entity management and business logic only. All forms of validation that is not an integral part of the business logic itself will be implemented through the use of interceptors. This will allow the business logic to remain unchanged even as the businesses validation rules evolve over time MESSAGE DRIVEN BEANS The design of the message driven beans is based on identifying where their use is appropriate and which JMS messaging model to use. From the requirements the only asynchronous tasks identified are the functions. For each different type of that the system needs to send there will be a MDB that will process JMS messages that request the sending of the . The messaging model to be used will be point to point (queues) since each request to the message driven beans to send an will only need to be processed once to ensure only a single is sent to the designated recipient. Each MDB will need to receive a message type that provides it with all the information it requires to send the , including the recipients address and any information that needs to be included in the body of the . The message driven beans identified are: Welcome MDB Forgotten Password MDB Order Confirmation MDB 4.4 WEBSITE DESIGN The website has been designed to facilitate the online aspect of the project. It is a portal into the business logic contained within the enterprise beans, allowing the company s customers access to the ordering system and other features that the enterprise beans provide. Servlets and JSP pages have been chosen as the technology of choice for implementing the website due to their close relationships with EJB and the Java EE platform. Figure 2.7 has already presented the standard architecture for combining web components and EJB, and this architecture is adopted for the design of the website. The basic flow of control for all servlets and JSP pages will all work on the same basic principles. Firstly, an HTTP request will be made to a servlet either directly from a web client or from a JSP page. This request will then be processed by the servlet which will validate the request and then interact with session beans to service the request. 38

39 Once this has been performed the servlet will forward its results to a JSP page for display. Several use cases were devised to model the flow of control for several key tasks that the website would need to provide, such as the login flow presented in Figure 4.5. Figure 4.5: Login flow A large number of servlets will need to be created to provide access to the functions provided by the session beans that should be accessible from the client. This is due to the fact that each servlet is responsible for performing a single task, thus the servlets map almost one to one to the session bean methods that the website must provide access to. The servlets themselves shall access the session beans via their local interfaces since an EJB application server that incorporates a web container will be used to deploy both the enterprise beans and web components. The session bean façades will be the main beans that the servlets interact with as these wrap up all the functions that the website will need. In terms of the design of the actual JSP pages themselves a common layout has been deduced that should be applicable to every page on the website. This allows the user to become quickly accustomed with the layout of the site and provides easy navigation between the various areas of the website. To make this possible cascading style sheets (CSS) will be used to maintain a common look and feel across all the pages and each page should be split into reusable sections (such a header, footer, navigation bar, etc) that can be written once and imported into each page, minimising the amount of repeated code on each page. Figure 4.6 presents the proposed layout of each JSP page: Figure 4.6: JSP page layout 39

40 4.5 APPLICATION DESIGN The administrative client provides the employees of our fictitious company with a way to maintain the system s data. The majority of the requirements are based around the ability to add, update and remove data from the database, and to facilitate this a GUI consisting of a number of screens needs to be created. The focus will be on the efficient layout of the data input controls and security. In terms of the GUI design as much as possible should be encapsulated into widgets. These can then be reused on any number of screens without the need to repeat the code for their layout and validation. This should speed up the development of the GUI considerably. Since the client provides access to the company database the application needs to be secure. This will require user authentication through a login screen when the client is started, with only authorized users allowed to proceed to the GUI. Even after the user has successfully logged in there will still be checks that they are authorised to perform the actions that they are attempting through the use of security roles. These will associated with the users to give them different levels of permissions. The table below presents the proposed roles for the system and what actions it allows the users to perform: Role Name default product_admin manager Actions All customer actions, add products All default actions, update / remove products All actions In order to access the business logic on the application server the administrative client will also be required to acquire remote references to the session beans. This will have to be done through the session beans remote interfaces. The client will need to perform JNDI lookups to obtain references to the session beans that it requires. The following table details the session beans that the client will need to access to (and hence will need to implement remote interfaces) and the JNDI name by which the beans should be identified: Session Bean Remote Interface JNDI Object Binding CustomerManagerBean CustomerManagerRemote CustomerManagerBean/remote ProductManagerBean ProductManagerRemote ProductManagerBean/remote OrderManagerBean OrderManagerRemote OrderManagerBean/remote 40

41 CHAPTER 5: IMPLEMENTATION This chapter gives an overview of the implementation of the online ordering system for a fictitious electronic entertainment retailer. Its focus is on the most interesting and challenging aspects of the implementation, with the details of these examined in depth. 5.1 DEVELOPMENT METHODOLOGY Since EJB 3.0 is a new technology it was difficult to foresee what would and would not be possible when it came to implementing the enterprise beans. Taking this into account an agile development approach was taken. This allowed the greatest flexibility in being able to implement the enterprise beans and other components that the project required. As development progressed code was constantly refactored and improved, which could only happen as a result of experience. 5.2 ENVIRONMENT SETUP Getting a working environment up and running is a non trivial task when developing a multi tier system using EJB 3.0. Several piece of software were required in order to establish an environment in which to develop the system: an EJB compliant application server, a database server with a JDBC driver, a web server and an integrated development environment (IDE) APPLICATION SERVER JBoss application server was chosen as the EJB 3.0 compliant application server for the project. One of the key reasons behind this decision was that it comes bundled with Apache Tomcat, a web server in which the servlets and JSP pages could be deployed. This allows the servlets to use the enterprise beans through their local interfaces as both the EBJ container and web container will be running within the same JVM DATABASE SERVER The database server chosen for the project was MySQL 5.0. This was freely available and offered all the services that would be required for the development of the database. It also came bundled with a number of administrative tools that made interacting with the database straightforward. Once the database server was installed and running the database schema presented in Figure 4.3 could be implemented through the creation of tables with the appropriate fields and relationships. Appendix B contains the details of implementation of the database tables INTEGRATED DEVELOPMENT ENVIRONMENT TOOL NetBeans 5.5 was the IDE chosen in which to develop the enterprise beans. As an IDE specifically designed for the development of enterprise beans it offered a number of features to allow for rapid development. Like most other IDEs such as Eclipse or Visual Studio it offered code completion, automatic code generation for simple things like getter and setter methods, and code navigation functions. It also integrated with the application server and database, allowing these to be accessed through the IDE. The build scripts for generating the JAR and EAR files for deployment were automatically configured so this alleviated some of the problems associated with poorly structured deployment files that the application server would be unable to deploy. 5.3 ENTERPRISE JAVABEANS DEVELOPMENT ENTITY BEANS The development of the entity beans was based heavily on the design of the database schema presented in Figure 4.1. For each table in the database a corresponding entity bean implementation had to be created to provide the session beans with access to the data stored in the database tables. Implementing the entity beans was non trivial, largely as 41

42 a result of the large number of relationships between the database tables and the need for inheritance hierarchies to be used to model several entities properly ENTITY RELATIONSHIPS In terms of entity relationships one of the most complex entity beans to implement was the Customer entity bean. As can be seen in the diagram below the Customer entity bean was involved in a number of different relationships (note these are only the relationships that the Customer entity bean itself is aware of): Figure 5.1: Customer entity bean relationships In order for the Customer entity bean to be mapped correctly it needed not only to map to all the columns in its corresponding table but also to the Address, CustomerPreferences, PaymentCard and WishList entity beans for the benefits of domain navigation. For each Customer entity there is a single CustomerPreferences entity related to it, which required a simple one to one = "customer", cascade = CascadeType.ALL) private CustomerPreferences preferences; The Customer entity s relationships with the Address and PaymentCard entities are identical. For both there are a number of instances related to a single customer, which means the relationship is a one to many between the customer and themselves. The code for the Address relationships is presented = "customer", fetch = FetchType.EAGER, cascade = CascadeType.ALL) private Set<Address> addresses = new HashSet<Address>(); Every time a Customer entity is loaded we want its related addresses and payment cards to be loaded as well so they are accessible immediately. To force the entity manager to do this the fetch type is specified to be eager. Just as we want the addresses and payment cards to be loaded along with the customer we also want changes to these entities to be persisted automatically along with the Customer entity. This has been achieved through the use of cascading. The relationship between the Customer entity and a WishList entity is similar but features a key difference. Whilst it is possible for a customer to maintain a number of wish lists simultaneously thus requiring a one to many relationship, it is not required that the wish lists be loaded automatically by the entity manager along with customer. Since the wish lists are only used on the website and not needed by the admin client it seemed unnecessary to force the entity manager into loading the wish lists automatically if having access to them is not always required. This meant that although the relationship was useful for the web client the data could be lazily loaded to prevent the avoidable overhead of loading it every time = "customer", fetch = FetchType.LAZY, cascade = CascadeType.ALL) private Set<WishList> wishlists = new HashSet<WishList>(); The Customer entity bean also required the use of several different annotations for its properties. The date of birth of the customer was stored in the database as a date, and as such required the use of annotation on this property to ensure it was handled accordingly by the entity manager. 42

43 @Column(name = "date_of_birth", nullable = private Date dateofbirth; annotation was also required for the customer s title. An enumeration was defined called TitleType which listed the permitted values for this column, and the property that used this type was designated as having requiring the entity manager to map the values returned from the database into the corresponding value in the enumeration. public enum TitleType { Mr, Mrs, Miss, Dr, Lord, = "title", nullable = private TitleType title; The other most significant entity bean to implement in terms of relationships was the OrderedProduct entity bean. In order to map the relationship between orders and products a join table had to be created as a bridge for the many to many relationship. This in turn required an entity bean to be developed to represent this in EJB. Figure 5.2: Relationship between Orders and Product entities The difficulty in implementing this bean was the fact that not only was it related to both Order and Product entities but that it also required a composite primary key. The composite key was made up of the product id and the order id and was implemented using an embedded primary key class as shown public class OrderedProductPK implements Serializable = "order_id", nullable = false, updatable = false) private Integer = "product_id", nullable = false, updatable = false, length = 20) private String productid; public OrderedProductPK(Integer order, String product) { this.orderid = order; this.productid = product; The fact that the primary key of this class was made up of the primary keys of two other entities caused a problem. Since the primary key can only be implemented using Java primitives (including wrappers) and strings it was not possible to use a composite key comprised of an Order entity and Product entity. As a result the only workaround was to then implement the relationships with these other entities separately in the bean class so that they overlapped with the primary key definition. Whenever these properties were then set via the setter methods the corresponding primary key field was also set so that the entity could be persisted to the = "ordered_product") public class OrderedProduct implements private OrderedProductPK primarykey; // "Overlaps" with = "order_id", insertable = false, updatable = false) private Order order; // "Overlaps" with = "product_id", insertable = false, updatable = false) private Product product; 43

44 public void setorder(order order) { this.order = order; this.primarykey.setorderid(order.getid()); public void setproduct(product product) { this.product = product; this.primarykey.setproductid(product.getid()); ENTITY INHERITANCE A challenging set of entity beans to implement were those that represented the products. The key to implementing these beans was to ensure that each entity bean only referenced properties that belonged to the table it mapped to, and to ensure that they inherited everything else they required correctly from their superclasses. From the database design it was clear that to implement the entity beans accurately the table per subclass inheritance strategy had to be used to map the beans precisely to the database, with the Product entity bean forming the root of the inheritance hierarchy. Figure 5.3 Product entity beans inheritance hierarchy The CD and DVD subclasses were straightforward to implement as they simply extended from the Product entity and added their own property mappings. The HD DVD and BluRay entities however were implemented slightly differently. Once the database tables had been developed it was clear that the tables for both these entities actually had the same columns. This presented the opportunity to introduce a mapped superclass HDMovie between the Product entity and the implementations of the HD DVD and BluRay entity beans themselves. This allowed the mapped superclass to inherit from Product and specify all the column mappings for both entities. The HD DVD and BluRay entities are then able to simply inherit from the mapped superclass and indicate which table to map to; there is no need for them to define any property = = InheritanceType.JOINED) public class Product implements = "id", nullable = false, updatable = false, length = 20) private String = "product_name", nullable = false, length = 100) private String public class HDDisc extends Product implements Serializable = "studio", nullable = false) private String = "classification", nullable = private ClassificationType = "resolution", nullable = private ResolutionType resolution; 44

45 @Table(name = = "getblurays", query = "FROM BluRay bluray WHERE bluray.deleted = false") ) public class BluRay extends HDDisc implements Serializable { public BluRay() { setproducttype(producttype.bluray); Each product class has a number of named queries for performing common queries on the entity in question. This allows each entity to have the common queries that are typically performed on the entity located within its definition, providing a central location for these queries. The single table inheritance strategy was also used in the development of the entity beans in order to implement the WishList and RecommendedList entities. The hierarchy was very simple as the two entities only differed in their relationships. At the root of the inheritance hierarchy was a class called List which defined all the columns found in the corresponding table in the database which both the WishList and RecommendedList entities shared, with both extending this List class and implementing their specific relationships only. The code samples below show the List entity s column definitions and the implementation of the = = = "list_type", discriminatortype = public class List implements @Column(name = "id", nullable = false, updatable = false) private Integer = "list_name", length = 40) private String = "private") private public class WishList extends List implements = "list", fetch = FetchType.EAGER, cascade = CascadeType.ALL) private Set<WishListProduct> wishlistproducts = new = = "customer_id", nullable = false) private Customer customer; STATEFUL SESSION BEANS There was only one situation that required a stateful session bean to be implemented and that was for the shopping cart used by customers via the website. This needed to be a stateful session bean as it was necessary to maintain some conversational state with the client. The customer will browse the website for products they wish to purchase and add them to the shopping cart. This list needs to be maintained for that customer while they are browsing for other products to add. This products in the cart needs to be maintained for the duration of the customer s session, but it is not information that should be persisted to the database. This means it must be stored in the stateful session beans member variables as conversational state. The shopping cart provides methods to add, remove, and update the products in the cart. The cart stores the products in a hash map with the product s id as the key. The shopping cart has also been implemented with an Order entity as a member variable. This is for use in the checkout process, whereby the customer must specify order information such as a delivery address, a delivery method and payment card details. Once this information has been provided by the client and stored in the Order entity s properties the main function of the shopping cart can be invoked by the client. The purchase() method uses the conversational state that has been set by the client through a series of method invocations on the shopping cart to create the Order entity and its associated OrderedProduct entities in the database. 45

46 @Stateful public class ShoppingCartBean implements ShoppingCartLocal private OrderManagerLocal private ProductManagerLocal private PricingEngineLocal pricingengine; private static Logger log = Logger.getLogger(ShoppingCartBean.class.getName()); private Map<String,OrderedProduct> cartitems = new HashMap<String,OrderedProduct>(); private Order order = new Order(); private boolean orderconfirmed = false; public ShoppingCartBean() { public void addproduct(product product, int quantity) { log.info("adding product "+ product.getid() + " to shopping cart"); if(!cartitems.containskey(product.getid())) { double totalcost = calculatetotalcost(product, quantity); OrderedProduct orderedproduct = new OrderedProduct(order, product, quantity, totalcost); cartitems.put(product.getid(), orderedproduct); else { OrderedProduct orderedproduct = cartitems.get(product.getid()); int newquantity = orderedproduct.getquantity() + quantity; orderedproduct.setquantity(newquantity); orderedproduct.settotalcost(calculatetotalcost(product, newquantity)); public void purchase() { if(isorderconfirmed()) { log.info("purchasing order"); Calendar calendar = Calendar.getInstance(TimeZone.getDefault()); order.setorderdate(calendar.gettime()); order.setorderedproducts(new HashSet(cartItems.values())); // use pricing engine to calculate total cost of order order.settotalcost(pricingengine.priceorder(order)); // once everything on the order and list of products is complete we can create the order int orderid = ordermanager.createorder(order); order.setid(orderid); // send confirmation to user sendconfirmation (); // reset the bean ready for new input resetcart(); To do this the shopping cart interacts with several other session beans that have been injected into the bean by the application server through dependency injection. The PricingEngineBean is one such injected bean which is used to price the order after the products in the hash map have been set to be the ordered products of the order. Following this the OrderManagerBean, which is responsible for database operations on Order entities, is used to create the order in database. It then sends a JMS message to a queue serviced by one of the message driven beans which sends a confirmation to the customer that made the order. Finally, the cart is reset by clearing the hash map of products and creating new instance of the Order entity to prevent duplicate orders being created in the database accidentally STATELESS SESSION BEANS As is evident from the Figure 4.x a stateless session bean has been implemented for each entity bean. These stateless session beans provide the ability to perform a number of actions on their corresponding entity beans through the entity manager. Each one provides methods to persist, update, remove and find their related entity bean class. Some provide additional services on top of this. The stateless session beans for the product entities also provide methods to search for entities based on some criteria and methods to return all entities of their corresponding type. 46

47 Some of the product stateless session beans also implement the use of interceptors and security. These have been implemented to allow validation on some of the actions that can be performed on the products. The interceptors catch method invocations on the methods to update the product entities in the database and validate the proposed changes to ensure they are legal. As part of this authorization has been used to certify that the users making alterations to the products are entitled to. Only users assigned to the correct roles are allowed to alter the price of a product for instance, and of these only those assigned the product_admin or manager roles are allowed to reduce the price of the product. public class ValidateProductUpdate SessionContext ProductManagerLocal public Object validate(invocationcontext invocation) throws Exception { if(productmanager.ispricereduced((product) invocation.getparameters()[0])) { if(ctx.iscallerinrole( product_admin ) ctx.iscallerinrole( manager )) return invocation.proceed(); else return null; else return invocation.proceed(); Whilst having a stateless session bean to manage each entity bean s interaction with the entity manager are useful there are a large number of them. Most of these beans can be grouped together to provide a service though stateless session bean façades. These façades use dependency injection to gain references to instances of the other stateless session beans whose functions they are encapsulating. Rather than exposing every stateless session bean via a remote interface these façades provide a perfect way to provide a simplified interface to both local and remote clients. The ProductManagerBean is such a public class ProductManagerBean implements ProductManagerLocal, ProductManagerRemote private BluRayManagerLocal private CDManagerLocal private DVDManagerLocal private HDDVDManagerLocal hddvdmanager; public String createproduct(product product) { switch(product.getproducttype()) { case CD: return cdmanager.createcd((cd) product); case DVD: return dvdmanager.createdvd((dvd) product); case HDDVD: return hddvdmanager.createhddvd((hddvd) product); case BLURAY: return bluraymanager.createbluray((bluray) product); default: return null; As can be seen from the code snippet above the ProductManagerBean encapsulates the functionality of four other session beans into a single method. This class is itself stateless as it is does not maintain any conversation state. It merely acts as a gateway to the functionality of the other stateless session beans. By implementing a number of stateless session bean façades the number of session beans that needed to be accessed directly by clients was reduced SESSION BEAN INTERFACES Every session bean is required to implement at least one interface, and as such every session bean developed implements a local interface. Since the JBoss application server also runs Apache Tomcat in the same Java Virtual Machine (JVM) the servlets in the web container can interact with the session beans through the local interface. This allows the functionality of the session beans to be exposed over the Internet without the need for them to implement remote interfaces. Only session beans required to be accessible from the administration GUI expose remote interfaces, and these interfaces only expose the administrative functionalities that they require. 47

48 5.3.5 MESSAGE DRIVEN BEANS A number of message driven beans were implemented in order to take care of the tasks that were asynchronous in nature. These tasks were centred on the sending of to customers to confirm certain actions had been completed successfully by the session beans. The use of message driven beans was appropriate because the session beans do not care whether or not the is sent successfully and need no acknowledgment of this action taking place. To make the session beans send the directly themselves would pollute the business logic code. Since all the message driven beans developed were used to send s to customers they all performed very similar tasks which presented the opportunity to reuse code. To aid the beans an utility class was written to encapsulate all the common code that the message driven beans would use, including methods to create a mail session and send a mail message. This helped to simplify the development of the message driven beans, which could then focus solely on the creation of the mail messages. The PasswordReminderMBean is one such MDB that sends a customer a reminder of their password providing they know their = = "acknowledgemode", propertyvalue = = "destinationtype", propertyvalue = propertyvalue="queue/passwordreminderqueue") ) public class PasswordReminderMBean implements MessageListener private CustomerManagerLocal customermanager; private static Logger log = Logger.getLogger(PasswordReminderMBean.class.getName()); public PasswordReminderMBean() { public void onmessage(javax.jms.message message) { try { String recipient = ((TextMessage) message).gettext(); log.info("sending forgotten password to: " + recipient); Util.send (createMessage(recipient), recipient); catch (AddressException ex) { protected Message createmessage(string address) throws MessagingException { MimeMessage message = Util.createMimeMessage(); message.setsubject("amazon Ripoff Password Reminder"); String password = customermanager.retrievepassword( address); message.settext("here are your login details:\n\n" + " " + address + "\npassword: " + password); return message; All message driven beans implemented used queues over topics as the messaging model, as can be seen in the PasswordReminderMBean source code above. This was an appropriate choice of messaging model as each message would only be processed by a single message driven bean instance, thus resulting in a single being sent per message received. If a topic had been used instead several MDB instances would have received and processed the JMS message, resulting in multiple copies of the being sent out to the recipient. 5.4 WEBSITE DEVELOPMENT The website was implemented using servlets and JSP pages. It was developed as a way to test the enterprise beans whose development was the main focus of the project. The website was intended for use by the firm s customers, providing them with a number of features but primarily allowing them to browse the products on offer and purchase them over the Internet SERVLETS The website required a large number of servlets to be developed to implement all the features that it offers. It became clear early on in the development of the initial batch of servlets that they were all very similar. This led to the development of a common abstract base class BaseServlet that encapsulated the common code applicable to all servlets and provided several abstract methods for subclasses to implement. These methods were used to separate the tasks that each servlet would need to perform, such as initialising the servlets resources, checking the request is valid, and processing the request. From this base class a number of subclasses were developed that were used to as 48

49 superclasses to related groups of servlets. Figure 5.5 shows a subset of the class hierarchy of the servlets covering only the abstract classes: Figure 5.5: Servlet class hierarchy The concrete classes at the bottom of the hierarchy (not shown on the diagram) were typically very short classes that only had to have code specific to what they were tying to achieve. This allowed for the rapid development of new servlets since the majority of the groundwork had already been laid by the classes higher up the hierarchy. The servlet ListProductServlet and an implementation of this class, ListDVDServlet, highlight this: public abstract class ListProductServlet extends ProductServlet { protected int maxresults = 20; protected int firstindex = 0; protected boolean checkrequest(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { if(request.getparameter("maxresults")!= null) maxresults = Integer.parseInt(request.getParameter("maxResults")); if(request.getparameter("firstindex")!= null) firstindex = Integer.parseInt(request.getParameter("firstIndex")); return true; protected void processrequest(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { request.setattribute("title", gettitle()); request.setattribute("products", productmanager.getproducts(getproducttype(), maxresults, firstindex)); redirectrequest(request, response, "/products/listproducts.jsp"); protected abstract String gettitle(); protected abstract ProductType getproducttype(); public class ListDVDServlet extends ListProductServlet { protected String gettitle() { return "DVD"; protected ProductType getproducttype() { return ProductType.DVD; JAVASERVER PAGES Every web page was implemented as a JSP page as they all required at least a small amount of Java scripting to be included. Using JSP pages allowed for a convenient way of preventing the servlets from having to return HTML pages as their results which would have required much more processing than returning one or more objects. It also served to decouple the servlets from the presentation of their results. A significant number of JSP pages had to be created in order to cover every page of the website, but there were plenty of opportunities for code reuse which was exploited to keep the amount of repeated code down to a minimum. For example, the code for displaying the login status of a user needed to be used on every other JSP page: <% customer.entity.customer customer = (customer.entity.customer) session.getattribute("customer"); if (customer!= null) {%> Welcome back <% out.write(customer.getfirstname() + " " + customer.getlastname()); %>! If this is not you then please click <a href="/ecommerce-war/login/logout.jsp">here</a> <% else {%> You are not logged in! <a href="/ecommerce-war/login/loginservlet">log in</a> or <a href="/ecommercewar/register/registerservlet">register</a> to begin shopping <%%> 49

50 Rather than copy and paste the same code into all JSP pages, the same effect was achieved by defining the code in one JSP page and importing it into the others when it was needed. This login status check code formed part of the header file that every page featured. All pages could then simply add a simple import statement to gain the functionality provided by the header: <jsp:include page = "/headers/header.jsp" /> 5.5 APPLICATION DEVELOPMENT The administration client was implemented as a Java application using the Swing framework for the development of the GUI. Its aim was to provide a way for the employees of the company to interact with the database, providing the ability to maintain data on customers, products and orders REMOTE INTERFACES AND JNDI Since the administration client runs on user s machines and not within the application server it is not possible for the client to access the session beans through their local interfaces. For this reason the session beans that the administration client requires access to must expose a remote interface that the client can then gain a reference to through a JNDI lookup. The remote interfaces only expose those methods that are required for the administrative functions that the client provides support for; all other methods the beans implement are hidden from the client. Since there are a number of GUI controls in the administration client that interact with the session beans it was clear that having each control perform a JNDI lookup itself to gain a remote reference to the session beans it required was inefficient, mainly due to the fact that many controls looked up the same session beans. A more appropriate solution was to implement a singleton class called EJBConnectionManager to handle the acquisition of remote references to the desired session beans. This was then used by the GUI controls that needed access to the session beans, so that the lookup code was centralised and reused by all the other classes. Below is a sample code snippet: public class EJBConnectionManager { private static EJBConnectionManager ejbconnectionmanager; private Context jndicontext; private CustomerManagerRemote customermanager; private EJBConnectionManager() { public static EJBConnectionManager getinstance() { if(ejbconnectionmanager == null) { ejbconnectionmanager = new EJBConnectionManager(); return ejbconnectionmanager; public CustomerManagerRemote getcustomermanager() { if(customermanager == null) { try { setcontext(); Object ref = jndicontext.lookup("customermanagerbean/remote"); customermanager = (CustomerManagerRemote) PortableRemoteObject.narrow( ref, CustomerManagerRemote.class); catch (NamingException ex) { ex.printstacktrace(); return customermanager; SECURITY The administration client is intended for use solely by company employees, and as such needed some security features to be implemented in order to guarantee it was only used by authorised users. This was achieved through the use of authorization and authentication. When the users load up the admin client they are required to first enter their credentials in the form of a username and password. This is then checked and if valid the user can proceed to use the client. Once the user is successfully logged in to the application they are assigned roles that then influence what 50

51 actions they can perform. As mentioned earlier in the discussion on the implementation of the stateless session beans some methods can only be invoked by users belonging to certain roles. Any attempts to invoke a method that the user is not authorized to execute will fail. All security information is defined in flat files that are deployed to the application server as part of the deployment process. These files are used to configure JBoss security domain. Two files have been used both of which contain name value pairs, one to define usernames and their corresponding passwords (e.g. osboja=testpass ), and one to map the usernames to the list of roles associated with them (e.g. osboja=product_admin ). In order to pass the users login information to the server for validation and role association it must be provided as part of the connection properties to the server when the JNDI connection context is established. This is done by the following code snippet: private void setcontext() { if(jndicontext == null) { try { Properties p = new Properties(); p.put(context.security_principal, user); p.put(context.securiy_credentials, password); jndicontext = new InitialContext(p); catch (NamingException ex) { ex.printstacktrace(); GRAPHICAL USER INTERFACE The GUI was implemented as a series of panels, several of which were then used to build other panels to encourage reuse of the GUI components. The main GUI components were placed into a frame in a tabbed control to maximise the usage of a limited amount of screen real estate. Several related GUI controls were implemented so that they would pop up on demand in separate windows separate to the main application screen. 51

52 CHAPTER 6: RESULTS This chapter illustrates how the system developed works in practice and how it is intended to be used. A selection of features of the system will be presented that would be frequently used by the system s users in the form of an extended use case. The use of both the website and the administrative client will be covered to highlight the functions of each. 6.1 WEBSITE When the customer first arrives at the website they are shown the home page. This provides the customer with a portal to all other parts of the website. From here the customer can go and browse the products on offer by category, search for products, login and manage their account. Its design was important as the layout of the home page is replicated on all other pages since they use the same cascading style sheet. The top half of the page is common across every other page on the website, and is split into sections to aid navigation around the site. In the red highlighted box in the top left is the user s login status, where at present you can see the user is not logged in. Highlighted in green in the top right of the page are the navigation links to the user s account information, shopping cart and wish list. Just below this in the blue area is the search box that allows the user to search the website for products that match the input they enter. Alternatively, the user can browse products by clicking on the category they are interested in, as found in the yellow box below the company logo. Figure 6.1: Home page Typically the user will perform one of two tasks when they first arrive at the home page. Existing users will want to login to gain access to the shopping features that the website provides, whereas new users will first need to register with the site in order to create an account before they can start shopping for the products available. The registration page is shown in Figure 6.2. The user is required to enter their personal details such as name, date of birth and address as well as providing an address and password which will be used as the user s login details. Once all the information has been entered into the form the user can click the submit button and create an account. Any erroneous data submitted will result in the user being returned to this page and require them to correct the errors. If the data is valid then the user will be taken to a page informing them of a successful account creation where they can either login or return to the home page. When the user decides to login they are taken to the login page (Figure 6.3) where an address and corresponding password are required to validate the user s identity. In the event that the user has forgotten their password there is an option to send a reminder to the provided address in the form of an . 52

53 Figure 6.2: Register Account page Figure 6.3: Login page Once a valid set of credentials have been supplied the user is logged in which provides the user with access to their account information as well as the shopping features of the website. Account information is accessible through the My Account page shown in Figure 6.4. Notice that the user is logged in as is shown in the highlighted area at the top of the page. From this page the user has the option to view and edit information on a number of things, including their personal information, order history and wish lists. Selecting one of these options takes the user to the corresponding page where the information is presented for them to update if they so desire, as shown in Figure 6.5. Figure 6.4: My Account page Figure 6.5: Edit Customer Details page Should the user decide that they wish to begin shopping the first thing they will be required to do is browse the website for the products that they are interested in. It is possible to achieve this by either following the navigation links to the different product categories found under the company logo, or by using the search functionality that is found above the company logo. Either way the user is taken to a page where the results of their search is listed (in the case of clicking on one of the category links a search is performed for all products of the given type). In Figure 6.6 a user has performed a search across all product categories for products whose name is like the string Hot Fuzz. 53

54 Figure 6.6: Search results screen Figure 6.7: Product details page The products that are listed in the search page contain links to the details of that product which can be accessed by the user clicking on the name of the product. This takes the user to another page that displays the information of the product that they are interested in, from which the user can perform a number of actions. The user can rate the product by clicking the appropriate rating which will contribute to the overall rating of the product as shown in the red highlighted area. The user also has the option of adding this product to their shopping basket or wish list, both of which are available by clicking the respective links highlighted in the blue box. At the bottom of the page is an option for the user to review the product (in the green area), which if selected takes the user to the page shown in Figure 6.8 where they can write a review for the product. Figure 6.8: Review product page Figure 6.9: Updated product page Once the user has written their review and submitted it they are redirected back to the product page where the newly added review will be available for viewing, as seen in the highlighted area in Figure 6.9. The user also has the option of editing the review, although this option is only available for reviews they themselves have written. All users can however give feedback on a review by clicking on the Helpful/Unhelpful links found below the review text. 54

55 Once the user has browsed through the products available and added those that they wish to purchase to their basket they can proceed with the checkout process. Firstly, the user can check the items currently in their basket by following the link to the shopping cart found at the top of each page. Once here the user can remove any products if they no longer wish to purchase the item in question, and when ready click the checkout button to begin the checkout process. Figure 6.10: Shopping Cart page The first two pages of the checkout process are concerned with the user specifying a delivery address for the items as well as an address for the bill to be sent. The user is presented with the addresses that they have already registered in the past for convenience, as well as a form to enter a new address to be used if none of these are appropriate which will subsequently be added to their list of addresses for future use. This can be seen in the transition from Figure 6.11 to Figure 6.12 where the user has entered a new address to use as the dispatch address and this has become available for selection immediately when the user comes to choose the billing address. Figure 6.11: Checkout 1 Select Dispatch Address page Figure 6.12: Checkout 2 Select Billing Address page The user is then required to select a delivery method for the order from a number of options. Once this choice is made the user must either choose a pre existing payment card associated with the user or enter the details of a new card to make the payment for the products. 55

56 Figure 6.13: Checkout 3 Select Delivery Method page Figure 6.14: Checkout 4 Select Payment Card page Once the payment card has been selected the user has provided the system with everything it needs to complete the order. The user is given the opportunity to review the details of the order entered during the completed phases of the checkout process to confirm that the details are correct. Any mistakes can be rectified at this point by the user clicking the change button next to the information they wish to change, at which point they will be returned to the page where this information was provided. Once the user is sure that all the information provided is correct they can confirm the order by clicking on the corresponding button at the bottom of the page shown in Figure This completes the checkout process and the user is returned to the home page. To confirm that the order was created successfully an is sent to the user containing all the details of the order. Figure 6.15: Checkout 5 Confirm Order page Figure 6.16: Order confirmation 56

57 6.2 ADMINISTRATIVE CLIENT The administrative client provides users with the ability to maintain the data in the company database. This task is split into two distinct sections: the maintenance of customers and their associated information, and the maintenance of the products that the company stocks. When the user starts up the client they are presented with a login screen where they are required to enter a valid username and password without which they cannot gain access to the main GUI. This allows the GUI to pass the user s credentials to the server where they are checked and if valid the user is assigned their security roles. This prevents access to the GUI by unauthorised users, and provides the server with information about what actions this user is authorized to perform. Figure 6.17: Login screen Having logged in the user is presented with the main GUI screen as shown in Figure The main GUI screen is split into two tabs: one the product related actions and one for the customer actions. From the customer management perspective the user is provided with the ability to add, edit and remove customers, as well as performing the same operations on customers associated information such as their addresses, payment cards and orders. The customer management tab splits the screen into three distinct sections: one for basic customer information such as name and date of birth, one for managing address information and one for payment card management. If a user is not creating a new customer then typically they will want to find a customer to view their details, and this can be achieved by clicking on the Find button. This causes a new window to be opened that displays the GUI for finding a customer which is shown in Figure This allows the user to search for customers either by their id or on a more general basis by certain customer properties. Figure 6.18: Customer Management screen Figure 6.19: Find A Customer screen Once a customer is found and selected from the Find A Customer screen the customer management screen is populated with their information. From here the user can then update information at will, or click on the View Orders button in the bottom left corner to view the customer s orders. This screen allows for the user to manage a customer s orders, as shown in Figure

58 Figure 6.20: Customer Orders screen The other tab on the main GUI screen was for product management, providing the user with the ability to add, edit and remove products from the database. This screen presents a number of tabs also, one for each product type. Each one is tailored to the information required for that particular product. Just like the customer management screen there is also an associated screen for finding existing products in the database as shown in Figure 6.22 which works in the same way. If a user adds a new product to the database it will immediately be available for the users of the website to view and purchase. Similarly, when a user edits any of the product information and commits the changes to the database these are instantly reflected on the website. Importantly, only some users have the ability to edit product information, and this is decided by the security roles assigned to the user by the application server. Figure 6.21: Product Management screen Figure 6.22: Product Finder screen 58

59 CHAPTER 7: TESTING AND EVALUATION This chapter presents details of the testing of the system and an evaluation of the tests significance and quality. The majority of the tests are detailed in Appendix C. 7.1 TESTING STRATEGY The original testing strategy for the project was to focus heavily on the use of JUnit tests. These would be applied to all of the enterprise beans developed to provide comprehensive test coverage over the key components of the system as a whole. The testing of the website and application client would be secondary to this as they are centred on the presentation of the system s data rather than providing any database interaction or business logic. Unfortunately unit testing in EJB 3.0 was not possible. Despite JUnit support for past versions of EJB, such as 2.1, the latest incarnation of EJB has little in the way of support for unit testing. Any attempts to use JUnit to test enterprise beans met with failure, typically as a result of the tests being unable to locate the enterprise beans running on the application server. This was particularly surprising considering that the code used for the lookup of components in the application client was reused in the development of the JUnit test classes. Several other unit testing frameworks were investigated that claimed to support EJB 3.0 such as Cactus but these did not prove to be of any more use than JUnit. Eventually the original testing strategy had to be shifted as it became increasingly clear that unit testing the enterprise beans was not going to be possible. During the course of development the website and application clients became methods with which to test the enterprise beans. This proved to be rather useful given the different objectives of the two clients. On the one hand the administration client was designed almost exclusively for database access, allowing it to comprehensively test the entity beans and the corresponding session beans that manage them. From the GUI it was possible to test different types of input to the session and entity beans to ensure that the correct behaviour was being observed. The website then allowed the changes to the database to be viewed online to make sure the changes had taken place and were being propagated to the customers via the servlets and JSP pages. The website also allowed for the testing of the business logic implemented by the session beans and message driven beans that was not accessible from the administrative client. Between the website and the administrative client the full set of functionality provided by the enterprise beans was accessible and therefore testable. At the end of the implementation period a final set of testing was run to ensure that the system as a whole worked as expected. To do this regression testing was employed to rerun all the informal tests that had been run during the course of the development in a formal and documented way. The testing of the administrative client and website was largely limited to ensuring that the functions of the enterprise beans behaved correctly, although this did in turn test both of them at the same time. As part of the tests the results returned from the enterprise beans were checked to ensure they displayed properly in the respective clients and that any errors were handled. Black box testing was the testing strategy applied to the enterprise beans as they were being tested from an external perspective. 7.2 TEST RESULTS In order to test the system effectively the database first had to be populated with some test data. This data was derived from the test cases to ensure that data suitable for running the tests was available. The details of the tests described during this section can be found in Appendix C. The test cases have been presented using the table layout shown in the sample below: Figure 7.1: Sample of test cases The Test column provides details of the test that the test case applies to. It gives a brief overview of the test that has been performed and gives a hint as to what the expected result should be. The Tested By column indicates through which client the test was performed, being one of either the administrative client or the web client. 59

60 The Enterprise Bean Tested column is provides information on what enterprise beans were tested. Note that each test only lists the bean that the client directly interacts with. In the majority of cases the tests are performed on the session bean façades that wrap up the functions of a number of other session beans. This is especially true of tests performed via the web client. Whilst this is not an ideal situation it is not a significant problem. Ideally tests would be performed directly on every session bean classes including the façades to ensure maximum test coverage, but without JUnit tests this would require an unfeasible amount of manual tests to be performed. The Preconditions column specifies any preconditions that must first be met in order for the action being tested to take place. The Input column gives details of the inputs of the tests in detail where appropriate. The inputs are summarised in situations where a full listing is unnecessary. The Expected Results column provides information on what the anticipated outcome of executing the test should be. Finally, the Actual Result column indicates whether or not the actual outcome was the same as the expected one. Anything listed as as expected indicates a successful test. In terms of the tests themselves the majority have been executed via the website. This is largely due to the fact that the website provides access to most of the business logic contained within the enterprise beans. The administrative client has been used almost exclusively to test database operations on customers, products and orders since this is what it is designed for. 7.3 ANALYSIS AND EVALUATION OF TESTING The results of the tests showed that the majority of the problems encountered with the system as a whole were found in the two clients rather than the enterprise beans themselves. Considering that the clients were both developed as a means to show the reusability of the enterprise beans this is not all that surprising. Fortunately this is not too much of a problem in reality as the clients were always likely to contain bugs as the focus had been on the development of the enterprise beans. The problems with the clients are much more visible than problems in the session beans given that they are the pieces of software that the users interact with. Importantly, the bulk of the issues found in the administrative client and web client were simple fixes typically related to presentation issues. These were quickly corrected and the tests rerun. The clients played a significant role in the testing as through them all the features of the enterprise beans that were the focus of the testing could be tested. This level of access at least partially made up for the lack of unit tests that would have been the ideal solution for testing the system. Using the clients to test the enterprise beans throughout the development lifecycle meant that any bugs were fixed usually as they were discovered in both the client and enterprise bean code. This greatly assisted in the final testing presented here as there were no unexpected problems when the tests were run on the final integrated system. Overall the testing showed that the implemented system was a working solution to the original requirements. The results are unsurprising because the tests that performed had already been run during the course of the project as they were an integral part of the development effort. Nonetheless, having a formal proof of the working implementation is useful. This is not to say however that there are no problems with the testing. Indeed, there are numerous problems with the testing that has been performed. The majority of the tests were based on black box testing where inputs and outputs to the enterprise beans were monitored. Whilst this was useful in some respects, it is not nearly comprehensive enough to provide full confidence in the system. Performing other forms of testing such as usability testing and white box testing would have been most beneficial if the system was to be used in the real world. The level of test coverage is another problem. With more time a much more comprehensive suite of tests could have been produced that tested all the features of the web client and GUI as well rather than these tow being used as a means to test the enterprise beans. Although the testing revealed that the enterprise beans worked as a whole it would have been much better if JUnit tests had been implemented. Not only would this have resulted in a much greater level of test coverage on the enterprise beans but it would also have allowed the tests to be performed in a fraction of the time once written. This would have freed up time to also exhaustively test the website and GUI to get a much better coverage of tests across the system as a whole rather than needing to focus on the enterprise beans in the interests of time. 60

61 CHAPTER 8: CONCLUSIONS 8.1 ACHIEVING THE PROJECT OBJECTIVES The key aim of the project was develop a component based online ordering system which would allow the author to gain a detailed knowledge of software components developed using Enterprise JavaBeans 3.0. The system proposed was an ecommerce application for a fictional electronic entertainment company that run an online store to retail their products. These aims have been met to a high standard as a result of the implementation of such a system. A number of software components have been developed using EJB as well as two clients that use these components as examples of how they can be reused to quickly develop distributed business applications. The development of the Enterprise JavaBeans was focused on utilising as many of the features of EJB as possible so a concrete understanding of how these different aspects of EJB worked could be acquired. With only very few exceptions most of these features were used by the different components that were developed as part of the project to achieve this aim. The two clients that were developed then allowed for an understanding of how these components could be accessed and used to provide functionality to the systems users. These also provided an opportunity to achieve some extra aims that did not form the form a part of the initial list of project objectives but were important nonetheless; an understanding of web components and HTML, and also experience of GUI design in Java. In the end a working system was produced that met the objectives of the project proposal. Any significant issues were identified during the testing phase and corrected, and although there is plenty of scope for further work the ordering system as it stands is functional and ready for use. 8.2 ISSUES ENCOUNTERED During the implementation of the project there were several times when issues were encountered, of which most centred on the application server. EJB application servers are extremely complicated pieces of software and need to be in order to provide a full range of system level services and a working environment in which EJB developers can deploy their beans. However, even the smallest of errors in the coding of the beans often led to the application server throwing out cryptic error messages that were far more confusing and complicated than they needed to be. The server often had problems with JNDI, seemingly not binding the objects to the expected names for lookup unless they were explicitly set in an XML deployment descriptor. This was most confusing given that the EJB specification provides a way to set these object bindings via annotations, but presumably the server did not support this particular annotation. A similar problem was encountered with attempts to use dependency injection to acquire references to beans in servlet classes. Whilst the EJB specification states that this too is supported through the use of annotations it appears that JBoss did not allow this. Even though this did not prove overly problematic in the end as it was possible to gain references through using JNDI manually, it highlights the fact that even though EJB claims to be portable between application server vendors in reality this is not yet the case. The other area that provided the majority of the issues encountered was Java Persistence. Unfortunately it does not always do what you expect, and some things cannot be achieved with it at present. The most common examples of this came with attempts to remove entities from the database, where in some cases it would result in cryptic error messages that it was not possible to remove an item from the database that it was about to persist. This was most confusing as the code merely stipulated that the entity in question be removed, and also that the same code for removing from the database worked for some entities and not for others. The other most frustrating issue encountered with Java Persistence was the fact that it does not support the use of secondary tables with entity inheritance which was used in the implementation of products, which meant any joins with other tables required SQL to be written separately to retrieve and persist this information whenever product entities were being used. 8.3 ALTERNATIVE IMPLEMENTATIONS A better implementation of the system that was developed could certainly have been achieved through an alternative implementation. A number of design decisions were made with the intention of using as many of the features offered by EJB, which often led to the best implementation of certain functions of the system being overlooked in favour of trying different implementations. This was compounded by the fact that the design of the project was constantly evolving as a greater understanding of the workings of EJB was acquired. Trying new features often revealed the weaknesses in the implementations of already completed components, but these were often left unchanged as 61

62 demonstrations of the particular features of EJB that they displayed. If a more complete understanding of EJB had been available at the beginning of the project there would have been several features of EJB that were more appropriate to the development of this project that would have been used repeatedly at the expense of some others. However, this would have conflicted with one of the aims of the project which was to learn Enterprise JavaBeans 3.0. Without attempting to try as many of the features EJB offered as possible this aim could not have been achieved as successfully as it was. That being said, if the project s only focus had been the development of an ecommerce application for an online retailer this alternate implementation would have been superior. The administrative client application that was developed is the other area where an alternate implementation would have been possible and potentially beneficial. It is certainly the case that the majority of computer users use the Windows operating system, and with this in mind developing the admin GUI in C# is a suitable alternate implementation. C# is the current technology of choice for developing Windows GUI applications and despite the platform independent benefits of the current Java implementation developing the GUI using C# could be considered a more appropriate choice given the users will be almost certainly using the Windows operating system. This would however require more work than simply rewriting the GUI in C#, with the need for an interface to the beans to be provided through web services. This is one of the areas for further development which rendered this implementation impossible given the current state of the project, but it is certainly an alternate implementation that could have been attempted had time been available. 8.4 POTENTIAL FURTHER DEVELOPMENTS There is a huge scope for further work on the domain targeted by this project. This was indeed one of the reasons the domain was selected in the first instance as it provided many opportunities for further development during the lifecycle of the project, and having reached the end of that cycle there are still an abundance of extra features that could be implemented should further development take place in the future. Exposing the enterprise beans via web services would be one such further development. Web services are selfcontained, self describing, modular applications that can be published, located and invoked across the web [3] that use the Simple Object Access Protocol (SOAP) and the Web Service Definition Language (WSDL) to communicate through XML documents. The use of SOAP and WSDL makes web services platform independent, since both of these are themselves platform independent. This allows applications written in different languages running on various platforms to interact with one another. EJB 3.0 supports the development of web services to expose the methods of the beans, and this could be done to allow for application clients written in languages other than Java to access the business logic contained in the beans. A similar extension would be in the development of new message driven beans to provide other companies with access to the beans developed in this project. Rather than exposing the bean methods through web services a number of message driven beans could be developed to expose business logic that other firms may wish to use which would then be accessed by these clients through the sending of JMS messages. The development of a recommendation engine would be a worthwhile addition to this project. This component would be responsible for recommending products to the customer based on what they have searched for in the past as well as what they have then gone on to purchase. This would be cross referenced with customers with similar browsing and purchasing histories to present the customer with products they could be interested in but unaware of. This would be a significant extension to the project that would require a great deal of research into the best way to achieve this functionality due to its complex nature. There are a few areas of Enterprise JavaBeans 3.0 that the project did not get a chance to implement. Of these perhaps the most appropriate to add through further work would be the use of EJB Timer Service. This is a feature of the EJB container where at scheduled times (be it a specific date or at specified intervals) the container will invoke a bean s timeout method. The bean in question must either implement the TimedObject interface or have one of its methods annotated with annotation. Whilst it wasn t apparent how to include these in the project during its implementation in hindsight it appears there is a definite use for EJB Timers in the project. The managers of our fictitious company are likely to want reports generated for them presenting sales figures and other such management information at regular intervals. A session bean that uses the EJB Timer Service could be developed to generate and send reports to the firm s management every Sunday evening. This concept could then be taken further to generate other reports or send out weekly s to customer s detailing special offers or the like. 62

63 8.5 APPRAISAL OF EJB Enterprise JavaBeans 3.0 is well suited to the development of distributed business applications and provides developers with a number of benefits that make it an attractive technology for the development of these kinds of systems. Although non trivial to learn and implement at first, after the initial steep learning curve it does get easier and allows for the rapid development of software components. The reusable nature of these components is one such benefit that increases the speed of developing applications that then use these components. EJB is very focused on the development of the business logic and the separation of this from the need to write complicated system level services in order to get the beans to function is one of its biggest benefits. The fact that EJB compliant application servers supply all these services and an environment in which to run the software components make it attractive to businesses. It allows developers to focus on the development of code that represents their business and lets the application server manager everything else, minimizing the development time to just that which is needed to write the business logic. The encapsulation of common code provided by interceptors is another very useful feature of EJB which builds on this separation of business logic and system level issues. Being part of the Java EE platform provides EJB powerful interaction with the Web. This is one of the key features of EJB that has led to it becoming so widely adopted in the development of distributed business applications. The ability to provide access to the business logic contained in the beans in a simple manner through servlets or web services to expose it to the world via the medium of the Internet is a feature that is hard not to appreciate. That being said, EJB 3.0 is perhaps not as good for developing software components as it might appear on the surface. Entity beans tie the session and message driven beans that use them very closely to the database implementation. Whilst this may be fine for a single company, making an EJB system generic enough to distribute between firms is very difficult unless they convert their existing databases to the same format as that which the entity beans are designed around. If the project had been aimed at creating a generic system for any online retailer this would have been very difficult to achieve. In order for the system to be suitably generic it would require the each company to map the recode the entity beans to map to their databases. This limits the extent to which the beans developed in EJB can truly be considered to be software components. The other most significant limitations of EJB have already been touched on in section 8.2. The application server is a complicated piece of software that is very hard to get to grips with. It is difficult to set up an environment and often throws out complicated error messages that provide very little assistance on diagnosing the problem. Many of these are typically related to JNDI and the implementation of the Java Persistence API that the server provides. 8.6 CLOSING COMMENTS Creating a component based online ordering system using EJB 3.0 has proved to be a challenging but worthwhile experience that has provided the author with a greater understanding of both software components in general and a technology that can be used to implement them. Despite encountering several issues and limitations of the technology the project objectives have still been met, and there remains plenty of scope for further work should someone decide to continue development in the future. 63

64 REFERENCES 1. Clemens Szyperski: Component Software: Beyond Object Oriented Programming. 2nd ed. Addison Wesley Professional, ISBN JSR Enterprise JavaBeans 3.0 Final Release (ejbcore), 14 th April ibm.com/developerworks/educationnsf/webservices onlinecoursebytitle/ba cfb862569a400601c18?opendocument, Web Services the Web s next revolution, November 29 th Richard Monson Haefel: Enterprise JavaBeans. O Reilly, ISBN X. 5. Rima Patel Sriganesh, Gerald Brose, Micah Silverman: Mastering Enterprise JavaBeans 3.0. Wiley Publishing, Inc., 2006, ISBN Kung Kiu Lau (editor): Component Based Software Development: Case Studies. World Scientific Publishing Co. Pte. Ltd., ISBN linz.ac.at/publications/html/combo/combo.2.html, Software Components, 14 th October Notions of Software Componentry, 14 th October Component Based Software Development / COTS Integration, 16 th March Component Based Software Development An Overview, 16 th March ibm.com/developerworks/websphere/library/techarticles/0008_brown/0008_brown.html, Choosing the Right EJB Type: Some Design Criteria, 1 st November ibm.com/developerworks/java/library/j what are ejbs/part1/, What Are Enterprise JavaBeans Components, 14 th April George T. Heineman, William T. Councill, Component Based Software Engineering: Putting the Pieces Together. Addison Wesley Professional, ISBN /jw 0815 ejb3.html?page=2, Simplify Enterprise Java Development with EJB 3.0, 26 th November architecture.com/ejb_servers/index.html, EJB Servers Articles and Products, 15 th October pj40, What are Enterprise Beans, 15 th October ent/jenut/ch07_02.htm, EJB Roles, 15 th October

65 APPENDIX A: GANTT CHART 65

66 APPENDIX B: DATABASE TABLES ADDRESS Field Type Null Key Default Extra id int(10) unsigned NO PRI auto_increment full_name varchar(50) NO address_line_1 varchar(40) NO address_line_2 varchar(40) YES town_city varchar(20) NO county varchar(15) NO post_code varchar(8) NO country varchar(20) NO phone varchar(11) NO deleted tinyint(1) NO 0 customer_id int(10) unsigned NO MUL FOREIGN KEY (`customer_id`) REFERENCES `customer` (`id`) BLURAY Field Type Null Key Default Extra asin varchar(20) NO PRI studio varchar(45) NO original_release_date datetime NO classification varchar(16) NO resolution varchar(6) NO FOREIGN KEY (`asin`) REFERENCES `product` (`id`) CD Field Type Null Key Default Extra asin varchar(20) NO PRI artist varchar(45) NO label int(10) unsigned NO number_of_discs varchar(16) NO FOREIGN KEY (`asin`) REFERENCES `product` (`id`) CUSTOMER Field Type Null Key Default Extra id int(10) unsigned NO PRI auto_increment first_name varchar(25) NO last_name varchar(25) NO date_of_birth datetime NO sex char(1) NO varchar(40) NO password varchar(20) NO title varchar(5) NO 66

67 CUSTOMER_PREFERENCES Field Type Null Key Default Extra id int(10) unsigned NO PRI auto_increment customer_id int(10) unsigned NO MUL default_address int(10) unsigned YES MUL NULL default_wish_list int(10) unsigned YES MUL NULL default_delivery_method varchar(20) YES NULL results_per_page int(10) unsigned YES NULL FOREIGN KEY (`customer_id`) REFERENCES `customer` (`id`) FOREIGN KEY (`default_address`) REFERENCES `address` (`id`) FOREIGN KEY (`default_wish_list`) REFERENCES `list` (`id`) DVD Field Type Null Key Default Extra asin varchar(20) NO PRI studio varchar(30) NO original_release_date datetime NO region int(10) unsigned NO classification varchar(20) NO number_of_discs int(10) unsigned NO FOREIGN KEY (`asin`) REFERENCES `product` (`id`) HD_DVD Field Type Null Key Default Extra asin varchar(20) NO PRI studio varchar(30) NO original_release_date datetime NO classification varchar(20) NO resolution varchar(6) NO FOREIGN KEY (`asin`) REFERENCES `product` (`id`) LIST Field Type Null Key Default Extra id int(10) unsigned NO PRI auto_increment list_name varchar(40) NO list_type char(1) YES NULL private tinyint(1) NO customer_id int(10) unsigned NO MUL FOREIGN KEY (`customer_id`) REFERENCES `customer` (`id`) 67

68 ORDERED_PRODUCT Field Type Null Key Default Extra order_id int(10) unsigned NO PRI product_id varchar(20) NO PRI quantity int(10) unsigned NO 1 total_cost double NO FOREIGN KEY (`order_id`) REFERENCES `orders` (`id`) FOREIGN KEY (`product_id`) REFERENCES `product` (`id`) ORDERS Field Type Null Key Default Extra id int(10) unsigned NO PRI auto_increment customer_id int(10) unsigned NO MUL dispatch_address_id int(10) unsigned NO MUL billing_address_id int(10) unsigned NO MUL payment_card_id int(10) unsigned NO MUL delivery_type tinyint(2) NO order_date_time datetime NO total_cost double NO FOREIGN KEY (`customer_id`) REFERENCES `customer` (`id`) FOREIGN KEY (`dispatch_address_id`) REFERENCES `address` (`id`) FOREIGN KEY (`billing_address_id`) REFERENCES `address` (`id`) FOREIGN KEY (`payment_card_id`) REFERENCES `payment_card` (`id`) PAYMENT_CARD Field Type Null Key Default Extra id int(10) unsigned NO PRI auto_increment card_number char(16) NO card_holder varchar(50) NO card_type varchar(16) NO issue_number char(2) YES NULL end_date datetime NO start_date datetime YES NULL deleted tinyint(1) 0 customer_id int(10) unsigned MUL FOREIGN KEY (`customer_id`) REFERENCES `customer` (`id`) 68

69 PRODUCT Field Type Null Key Default Extra id varchar(20) NO PRI product_name varchar(100) NO review varchar(1000) YES NULL description varchar(1000) YES NULL price double NO rrp double NO release_date dataetime NO product_type varchar(7) NO total_rating int(10) unsigned NO 0 times_rated int(10) unsigned NO 0 deleted tinyint(1) NO 0 RECOMMENDED_LIST_PRODUCT Field Type Null Key Default Extra list_id int(10) unsigned NO PRI product_id varchar(20) NO PRI reason varchar(255) NO FOREIGN KEY (`list_id`) REFERENCES `list` (`id`) FOREIGN KEY (`product_id`) REFERENCES `product` (`id`) REVIEW Field Type Null Key Default Extra id int(10) unsigned NO PRI auto_increment text varchar(1000) NO rating tinyint(2) NO recommended tinyint(1) NO found_helpful int(10) unsigned NO found_unhelpful int(10) unsigned NO customer_id int(10) unsigned NO MUL product_id varchar(20) NO MUL FOREIGN KEY (`customer_id`) REFERENCES `customer` (`id`) FOREIGN KEY (`product_id`) REFERENCES `product` (`id`) WISH_LIST_PRODUCT Field Type Null Key Default Extra list_id int(10) unsigned NO PRI product_id varchar(20) NO PRI priority tinyint(2) NO comment varchar(255) YES NULL FOREIGN KEY (`list_id`) REFERENCES `list` (`id`) FOREIGN KEY (`product_id`) REFERENCES `product` (`id`) 69

70 APPENDIX C: TEST DATA 70