Web application - Shopizer

tukwilagleefulInternet and Web Development

Oct 31, 2013 (3 years and 10 months ago)

1,050 views

Architecture document

This document describes the software architecture and different components used in Shopizer. The
software is layered in 3 tiers as recommended by engineering best practices. There are 3 main areas in
the system described as
web applic
ations
,
core section

and
module
s
. The web applications are
providing shopping, checkout and administration functionalities. The core area holds business objects,
model objects, services and modules. The core is packaged in a manner that it could be used st
and alone
providing e
-
commerce functionalities all exposed as services. Modules are plug and play pieces of code
providing functionalities enhancement and integration points with external software and services.
Modules also contain code that need to be ch
anged when running Shopizer in different environments.

The diagram below is a high level view of the target software architecture

for all areas


Web application

Web applications are implemented as a standard web application running stand alone and a set o
f
portlets to be deployed on compatible Portlet 2 portal application servers.

Standard web application

A standard web application contains shopping pages, shopping cart, checkout and an administration
section. The standard web application provides all e
-
co
mmerce functionalities but also a CMS, a
template engine and a security framework. ** TO BE DESCRIBED LATER

**

Portlet web application

The portlet web application project contains all e
-
commerce features delivered as portlets to be
integrated to portal ser
vers. The functionalities of Security, CMS, templates and search are delegated to
the responsibility of the portal server. Portlets are integrated as content in the portal server and must
provide mechanisms to interact between them.

The following table des
cribe
s

the main components of the portlet web application project:

Component

Description

Shopping Portlets

Those are JSR
-
286 portlets that can be deployed to any portlet 2
compatible portal server (as of today Liferay is the target portal server).

** See
Admin interface.doc document

** See Portlets.doc document

Portlets Controllers

Portlets Controllers are implemented using Spring Portlet MVC 3. A
portlet can have multiple controllers and multiple pages. The controller
is the entry point to all actions ta
ken on the web site. Most of the data
displayed in the portlet is driven by ajax requests. The controller get the
information
submi
ted , from the portlet configuration and from the
request and session as input to the services of the core in order to
retrie
ve model objects to work with.

Model

The web application also contains model objects which are subsets of
the core model objects. Those objects (POJOs) are used mainly to expose
JSON objects to the jsp pages. Since the core model objects are often
complex

and may contain huge graph of
embedded objects, those
presentation layer simple model objects are easier to work with and do
not contain serialization to JSON potential issues.

Modules

Since portal servers have their own implementation for Security, CMS,

search etc.. The presentation layer modules will provide abstraction to
portal servers APIs required to provide functionality. Modules will have
to be implemented differently depending of the targeted portal servers.

As of now, know modules are required f
or non portlet standard
functionalities such as:

-

Search

-

Retrieve logged in user

-

Interact with the CMS to save and retrieve product images

-

Get contextual information

-

Tag content

Product Tag Libs

Those JSTL are used to expose the product information in the
JSP pages.
Those JSTL must be the same between portlet web application and
standard web application

Category Tag Libs

Those JSTL are used to expose the category information in the JSP pages.
Those JSTL must be the same between portlet web application and
standard web application

Price Utility

The price utility uses the core and specific logic to determine the price to
be displayed to the user based on the user context.





Core

The core ‘backend’ contains the services, model objects and application mod
ule for Shopizer. The core
can be used i
nside of any type of project requiring essential e
-
commerce services. The core model
objects are implemented using Hibernate and JPA 2. All model objects use annotations to map to the
database. The core uses HBM2DDL
in order to generate the schema in the appropriate database dialect.
The schema is generated on the first usage and updated if required on subsequent usages. The core
project contains all unit tests that will give an understanding of the data flow and how
to use the
different core services for different CRUD operations.

The core project also contains the Integration and application modules which are described as plug and
play pieces of codes providing micro functionalities and integration pointes with exter
nal systems. As of
now price calculation and pricing rules are implemented as application modules. Shipping and Payment
are implemented as integration modules. They provide a ‘
one
-
to
-
many’ interface to different integration
systems for getting shipping quo
tes and to process payments.






The following table describes the main components of the core project

Component

Description

Services

Services are the entry point to the core layer. They provide CRUD
operations the object model but also application serv
ices such as
notification and computation (tax calculation, order total).

Model objects

Those are POJOs annotated and mapped to the database. Thos objects
are used in all layers of the application.

Payment modules

Shopizer supports integration with Beans
tream and AuthorizeNet credit
card processing. We also support Paypal express checkout and adaptive
payments. The payment module interface is a single ‘one
-

-
many’ entry
poin琠瑯 all i浰le浥n瑡瑩on

Shipping 浯Tules

Shopizer suppor瑳 in瑥gra瑩on wi瑨 䍡na
Ta Pos琬 USPS, UPS anT FeTex
(Purola瑯r anT DHL 瑯 co浥) The shipping 浯Tule in瑥rface is a single
‘one
-

-
many’ entry point to all carrier implementation.

Pricing 浯Tules

Pricing require浥n瑳 can be very co浰lexes anT we offer 瑨e possibili瑹
瑯 le琠瑨e
user i浰le浥n琠瑨eir own pricing sche浥s 瑨rough 瑨e pricing
浯Tules i浰le浥n瑡瑩on.


Also we will suppor琠Tyna浩c pricing rules 瑯 be buil琠on JBOSS Drules












Modules

Shipping modules

Shipping modules allow calculating a shipping quote for
one
-
to
-
many items. Shipping modules can be
integrated shipping modules or a custom shipping fee calculation piece of code. Before invoking the
appropriate shipping module, the system will have to prepare the shipping required informations
offered by the sh
ipping service.




Payment modules

To be documented

Pricing modules

To be documented

Object model

The following sections describe the different sections of the object model

Reference object

Reference objects are objects used as foreign objects for most of

the functionalities of Shopizer.



Merchant

A merchant is the entity that defines the store entities. Shopizer supports multiple merchants (not in
portlet version) which mean that one instance of Shopizer can have multiple store offering different
invent
ories and having their own look and feel.



Categories

Categories allow grouping of products. A product can belong to multiple categories. Also illustrated on
this diagram is the product relationship. The relationship concept allows grouping products in o
ther
contexts such as related items, accessories and bundles (a product created of multiple products)



Products

The products package is the bulk of Shopizer. A product will have descriptions by language, one to
multiple images and attributes. Attributes
can be options or specifications. Attributes can have price and
an image attached. A product can have multiple availabilities. By default a product is available for
everyone but it is possible to have specific or closed availability by regions. Availabilit
y will have at least
on price but based on the model a product can have multiple prices.

A price can have a special price
with a start date/end date or
duration
.



Orders

These are the classes that maintains all information pertaining to an order



Taxes

Taxes cannot be under estimated. Shopizer offers a model that can fit all types of taxes



Customer

A customer is created for each order. A customer can also be created to provide reviews on products.