Olstore - Read Me

Versions

olstore (Original)

The original Olstore uses Struts and EJBs. In this version of Olstore the EJBs are accessed using a helper singleton class called EJBHomeFactory. Struts actions use EJBs directly and therefore it is impossible to use another persistence method without having to rewrite all of the actions.

olstore-spring

Olstore that still uses Struts but communication with the EJBs is simplified using the Spring Framework. To access the stateless UserHelper EJB the getBean() function provided by Spring is now used. The applicationContext.xml (olstoreweb/WEB-INF/spring/applicationContext.xml) configuration file specifies the UserHelper bean.

    <bean id="itemHelper"
class="org.springframework.ejb.access.LocalStatelessSessionProxyFactoryBean"

        lazy-init="true">

         <property
name="jndiName">

   
         
<value>ejb/ItemHelper</value>

         </property>

        <property
name="resourceRef">

   
         
<value>true</value>

        </property>

        <property
name="businessInterface">

   
         
<value>olstore.session.helper.ItemHelper</value>

        </property>

    </bean>

This delegates the retrieval of the LocalHome interface for ItemHelper to Spring and returns an object that implements the business interface we created for ItemHelper. To access the EJB in this way from a struts action all we need to do is to have the actions extend org.springframework.web.struts.ActionSupport. We can then simply access the item like this:



ItemHelper itemHelper =
(ItemHelper)getWebApplicationContext().getBean("itemHelper");

olstore-springmvc

In this version the view and controller parts of the application use SpringMVC instead of Struts. All of the Struts actions were rewritten as SpringMVC controllers and the JSP pages that used Struts-specific tags were rewritten to display objects provided by the Spring framework using the Java Standard Tag Library.

In addition to that the controllers no longer use EJBs directly. Instead all of the functionality of the Olstore is now defined and exposed by OlstoreFacade interface. The implementation for this version is olstore.domain.logic.OlstoreImpl.

This facade uses a number of manager classes to interact with the EJB objects. These managers wrap the LocalHome interfaces of the entity and session EJBs and simplify the execution of operations. The managers are set using dependency injection by Spring. The applicationContext.xml (olstoreweb/WEB-INF/springmvc/applicationContext.xml) file contains this configuration to tell Spring which managers to inject into this particular implementation of OlstoreFacade:

<bean id="olstore" class="olstore.domain.logic.OlstoreImpl">

    <property name="itemManager"
ref="itemManager"/>

    <property name="orderManager"
ref="orderManager"/>

    <property name="userManager"
ref="userManager"/>    

    <property name="typeManager"
ref="typeManager"/>       
           
           
        

    <property name="shoppingCart"
ref="shoppingCart"/>

    <property name="defaultType">

        <bean
class="org.springframework.jndi.JndiObjectFactoryBean">

           <property
name="jndiName">

              
<value>DEFAULT_TYPE</value>

           
</property>

            <property
name="resourceRef">

           
    <value>true</value>

           
</property>

        </bean>

    </property>   
    

</bean>

In addition to the managers a default type is retrieved from the JNDI registry right there in the configuration file and injected into OlstoreImpl as a String.

In this way the controllers are completely independent of the way in which Olstore is actually implemented. They simply execute methods on the OlstoreFacade object that is similarly injected into them by Spring as specified in the olstore-servlet.xml (olstoreweb/WEB-INF/springmvc/olstore-servlet.xml) file.



<bean name="/store/viewItem.do"
class="olstore.controller.ViewItemController">

   <property name="olstore" ref="olstore"/>

</bean>

The above configuration defines what controller class will be invoked when the user accesses the url "store/viewItem.do" and provides the OlstoreFacade object as a property to this controller class. Inside the controller retrieving a POJO object representing the item is as simple as:



String itemId = request.getParameter("itemId");

ItemValue item = this.olstore.getItemById(itemId);

Build

The main build.xml file defaults to calling the 'install' target. The 'install' target builds all 3 versions of Olstore (see below for file names). To build specific versions, invoke the build as follows:

ant original - Builds only the original version as olstore.ear
ant spring - Builds the 2nd version with Struts and Spring communication with the EJBs as olstore-spring.ear
ant springmvc - Builds the 3rd version with Spring MVC used instead of struts as olstore-springmvc.ear

Each version's build is handled by a specific build file, and individual build options can be done on those specific files. The files are as follows:

build-struts.xml - The original version.
build-spring.xml - The 2nd version with Struts and Spring EJB Communication
build-springmvc.xml - The 3rd version with Spring MVC used instead of Struts

Though the three versions appear to be the same when viewed, the backend code is different in a few areas which will be outlined below:

*Component*	Olstore Original	Olstore Spring	Olstore Springmvc
Build File	/build-original.xml	/build-spring.xml	/build-springmvc.xml
Source Code	/src-original/olstore/*	/src/olstore/action /src/olstore/dto /src/olstore/entity /src/olstore/form /src/olstore/framework /src/olstore/global /src/olstore/session /src/olstore/util /src/olstore/validation	/src/olstore/util /src/olstore/framework /src/olstore/dto /src/olstore/controller /src/olstore/domain
JSP Source	/olstoreweb/struts/*	/olstoreweb/struts/*	/olstoreweb/spring/*
Deployment Descriptor	/olstoreweb/WEB-INF/web-original.xml	/olstoreweb/WEB-INF/web-spring.xml	/olstoreweb/WEB-INF/web-springmvc.xml
Spring Configuration	N/A	/olstoreweb/WEB-INF/spring/applicationContext.xml	/olstoreweb/WEB-INF/springmvc/applicationContext.xml /olstoreweb/WEB-INF/springmvc/olstore-servlet.xml

Deployment

Though there are 3 possible versions of Olstore to deploy, only 1 version at a time may be deployed. All 3 versions are available at http://localhost:9000/olstore/ once they have been deployed.

Clearing/Dropping the Database

NOTE: there may be other application using this same database. Clearing/dropping the database will remove all information stored in it. Clear/drop this database at your own risk.

Here is an example of how you would clear/drop a database when using the PostgreSQL supplied with the Olstore (please adapt to the datasource you are using):

	Stop the jonas server: 	service jonas stop
	Drop the database: 	dropdb -p 5433 db_jonas
	Create the database: 	createdb -p 5433 db_jonas
	Start the server: 	service jonas start
	Deploy the app: 	jonas admin -a olstore.ear (or using the JonasAdmin Web Application)
	visit Olstore:		http://localhost:9000/olstore

Alternatively, tables in the database related to the olstore application are prefixed with 'olstore' in their names and they can be selectively dropped.

How To Setup The UDDI Registry

One of the features that comes with the two web services endpoints for Olstore is the ability to register these endpoints to a UDDI registry.

JOnAS comes with a UDDI registry based on jUDDI from Apache. You will need to follow the instructions provided with jonas to get jUDDI up and running.

You can find them at this following URL: http://jonas.objectweb.org/current/doc/doc-en/integrated/howto/install_juddi.html

IMPORTANT: The datasource.name should be set to 'jUDDIDB' (without the quotes) as that is the JNDI name specified in jUDDI's configuration files.

NOTE: You have to make sure that the user that you are going to be connecting to the registry as is listed as one of the publishers. Do this by adding a new row to the 'PUBLISHER' table.

Olstore registers its endpoints in the registry at the time it populates the database with all the product and user information. If the registry is not setup at that time Olstore skips and finishes populating product/user information anyway. If you need to register the endpoints again simply clean the database to trigger the populate action of Olstore. Instructions for PostgreSQL are provided above.

You can modify defult properties in the juddi.properties file.

How To Set UDDI Properties

In the olstoreUDDI.properties (olstoreweb/WEB-INF) file the UDDI publish and discover URLs, username and password, and endpoint URLs are defined. By default all URLs are directed at "localhost:9000" and uses the username/password pair juddi/password. You can modify the defaults by editing the olstoreUDDI.properties file.

How To Use The Online Store Demo

The online store demo acts like almost any other online store, except it has the added feature that users can have friends associated with them. Users can buy products or mark products as interesting and these products will be displayed to their friends. This was done with the presumption that friends usually share the same interests and basic spending habits. How to use this demo should be intuitive to the user. Most actions can be performed by using a navigation bar on the left side of the screen.

There are two classes of users: customers and administrators.

CUSTOMERS: Customer users can perform the usual actions associated with an online store. They can browse and purchase products, mark products as interesting, checkout items, check the status of their orders, see which items they have bought, and update their user information. The usernames and passwords of some built in users are listed below. Some of these users already have friends associated with them and some have also purchased items. Also note that a new user can be created by clicking on the "register a new user" link on the login page.

Customer Usernames and Passwords:

	mwringe/qwerty
	aahmed/password
	SamOak/Oaktree
	bobbyv/bob47
	lucy666/meow666
	troll/troll9
	mfrost/elley
	icyMeg/74yci
	Sammy/MarG14
	user1/user1
	user2/user2
	user3/user3
	user4/user4

ADMINISTRATORS: Another class of users is Administrator. These users can perform the same actions that customers can, but they also have special administrative actions they can perform. Administrators can: update the information about an item, create a new item, create a new type of item, and update orders. The usernames and passwords of the administrators are listed below. Please note that new administrators cannot be created by a user at this time.

Administrator Usernames and Passwords:

	admin/admin
	vivek/vivek
	jonas/jonas