Epda Final Report

CT027-3-3-EPDA | Individual Assignment | UC3F1812SE
Table of Contents
Assumptions.................................................................................................................................... 2
1.0 Part One .................................................................................................................................... 4
1.1 Brief history on distributed computing ................................................................................. 4
1.2 Discussion on architectural evolution of distributed computing .......................................... 6
1.3 Discussion on Microservices ................................................................................................ 8
1.4 Discussion on the role of Microservices in the distributed web application ...................... 12
1.5 Discussion on Spring Boot Microservices framework ....................................................... 14
1.6 Discussion on alternative framework.................................................................................. 18
1.7 Justifications for Adopted Flask Framework ...................................................................... 20
2.0 Part Two ............................................................................................................................. 21
2.1 Design of Web Components ............................................................................................... 21
2.2 User Manual ........................................................................................................................ 27
2.2.1 Customer ...................................................................................................................... 27
2.2.2 Admin .......................................................................................................................... 32
2.3 Design of Business Tier ...................................................................................................... 39
2.3 Overview of Architecture ................................................................................................... 42
2.4 UML Diagrams ................................................................................................................... 46
2.5 Database Design.................................................................................................................. 47
2.6 Entity Relationship Diagram (Crow’s foot notation).......................................................... 56
References ..................................................................................................................................... 57
1
Assumptions
1. All users must login to use the system.

2. Discussion about the functionalities.
a. The following functionalities should be provided for the managing staff’s interface:
 One pre-registered Managing staff.
 To register new staff.
- Name, ID, gender, phone, IC, email, address.
- To delete, search, and update all staff’s information.
 To approve customers’ registrations.
- Name, ID, gender, phone, IC, email, address.
- To delete, search, and update all customers’ information.
 To add, delete, search, and update all food information.
- Minimum 10 types.
- Name, quantity, top up, & descriptions.
 To access all rating and feedback.
 In addition, some reporting functionality is required such as the number of
orders and the performances of the staff over a given time etc (managing staff
would like to get as much useful information from the system as possible and
is therefore open to the inclusion of any other useful reports).
- 5 reports.
b. The following functionalities should be provided for the reservation staff’s
interface:
 To edit individual profile.
 To approve reservations from customers.
- Must have enough stock and available delivery staff – quantity will be
updated after the approval.
- Customers’ will be notified and e-wallet will be updated after the approval.
 To assign AVAILABLE delivery staff to handle reservations which have been
approved.
- The delivery staff status will be changed from AVAILABLE to
OCCUPIED.
2
- If no available delivery staff, the reservation will be rejected.

- The system must show only available delivery staff.
c. The following functionalities should be provided for the delivery staff’s interface:
 To make sure the assigned delivery tasks are completed.
- Customer will update the status from OCCUPIED to AVAILABLE.
 To rate and comment about individual customers.
 To access individual ratings and comments given by the customers.
d. The following functionalities should be provided for the customers’ interface:
 To make reservations with enough amount in e-wallet and top up e-wallet.
 To access the details of individual reservations and orders.
 To rate and comment about the delivery staff.
 To access individual ratings and comments given by the delivery staff.
3
1.0 Part One
1.1 Brief history on distributed computing

Since 1945 when modern computer era began, until 1985, most of the computer were in
accessible to the public as it is large and expensive. Fast forward a few decades, development of
powerful microprocessors starts to take place that has led to multicore CPUs as we have now. Now
64-bit CPUs are the common. More than that, from microprocessors it has also led to the fast-
paced development of high-speed computer network which allow computers to connect to each
other and transfer small amount of information in few microseconds. These developments fuelled
the next generation of computing as more computer are generally geographically scattered and are
known as distributed system. Distributed system as defined by different authors:
 “A distributed system is a collection of autonomous computing elements that appears to its

users as a single coherent system (Steen & Tanenbaum, 2017)”.
 “A term that describes a wide range of computers, from weakly coupled systems such as
wide-area networks to strongly coupled systems such as local area networks to very
strongly coupled systems such as multiprocessor systems (Goscinski, 1991).”
Based on the definition, we can see distributed systems having two features which is that
a distributed system is a collection of computing elements that can be independently of each other
or also known can be refer to as a node. The second feature would be how users perceive it as a
single system. Certain characteristics such as “no common physical clock” and “geographical
separation” has explained how computers can be said to be distributed. Especially “no common
physical clock” as it introduces the element of “distribution” into the system and that has given
rise to the inherent asynchrony nature among processors (Kshemkalyani & Singhal, 2007). The
image below provided an illustration for the definition provided by A. Goscinski:
4
Figure 1.0: A distributed system that connects processors by a communication network

(Kshemkalyani & Singhal, 2007).
A typical distributed computing system is shown in figure 1.0 whereby the computers are
equipped with memory processing unit and connected by a communication network. If we assume
these distributed systems to be able to perform high performance computing tasks, two subgroups
could be formed which are cluster computing and grid computer. These concepts make up the basis
of distributed computing or high-performance distributed computing. Cluster computing requires
the underlying hardware that consist of collection of similar workstations and are connected using
high-speed-local-area network (Steen & Tanenbaum, 2017). While grid computing is federation
of computer systems where each system could fall in different administrative domain and may
have different hardware, software or deployed network technology (Steen & Tanenbaum, 2017).
Grid computing is a form of distributed computing that supports parallel programming on a
network of variable size computers. The main goal is to solve difficult computational problem as
quickly as possible while reducing the cost compared to conventional methods. Some example of
grid computing includes particle accelerator and collider built by European Organization of
Nuclear Research (CERN) and SETI (Ghosh, 2007).
Why is distributed computing considered to be important in this era of modern computing?

The reasons of their importance are manifold such as its resource sharing, how it is speed up
computation and how it is fault tolerance. Through resource sharing, a common example includes
the use of distributed database in sharing of software resources. As large database could store
several host machines and consistently updated or retrieval by agent processes. More than that,
distributed computing is able break up total problem into smaller subproblems and assigned it to
multiple processors that can operate concurrently has enhanced the speed of computation. This
5
approach also promotes scalability as user could increase computational power by just adding more
processing core instead of investing in a single superfast uniprocessor. Lastly, computing systems
that built around a single node are prone to complete collapse when the processor fails, this risky
nature has given rise to distributed computing. By incorporating redundant processing which can
be seen in distributed computing, a system’s reliability or availability could be increased (Ghosh,
2007).
1.2 Discussion on architectural evolution of distributed computing

Architectural style is formulated in a way which the components are connected to each other,
the data exchanged between components, and finally how these elements could configure into a
system. Using components and connectors, they made up several various configurations for
distributed computing that has become architectural style and has evolved throughout time. These
are the evolution as it time goes on:
1. Client/Server
2. Service Oriented Architecture (SOA)
Client/Server belongs to traditional architectures and with the growth of networking

capabilities it rose to consider various users to communicate and demand for services from servers.
The client server model relied on Remote Procedure Calls as a communication method for
distributed systems which it was one of the most popular during its time (Ismail, et al., 2000). The
client/server model consisted of two programs that communicate with each other whereby one is
the client, and another is server. Client will do the initiation while server will be the receiver.
Client/server soon evolve from two tier to three then n-tier architectures (Salah, et al., 2016). Many
distributed applications based on client/server are divided into three layers (1) user interface layer,
(2) processing layer, and (3) data layer. These clients and servers could be distributed into layers
across different machine, thus creating a two-tiered architecture as seen in figure below:
6
Figure 2: Two Tier architecture (Steen & Tanenbaum, 2017)
With further distinguishing between client/server, it is possible to turn a server into a client
whereby the processing layer could be executed by a separate server and distribute it across client
and server machines. This makes a three-tiered architecture and eventually creating a horizontal
distribution (Steen & Tanenbaum, 2017). As client or server could be split up into logically
equivalent parts and each part could operate its fair share of data set thus balancing the load, this
process is also known as peer to peer systems. The peer to peer paradigm then came to ease file
sharing among different hosts other than the server itself which resulted in a reduced latency
caused by centralized server. These paradigm shift could overcome limitation of client server in
achieving higher processing power (Gital, et al., 2014).
More than that, recommendation to include a middleware between servers and various
clients enabling them to integrate with the system soon took place, resulting in Service Oriented
Architecture. It is an evolution of client/server model as it allows services to be loosely coupled,
reusable and dynamically adapts to changing environment (Ismail, et al., 2000). SOA separates
various services, so they can operate independently. Distributed system is constructed with
composition of many different services such as storage. For example, business application could
make use of the cloud storage that is offered by cloud provider and these cloud storages are just
completely encapsulated into a single unit with the interface made available to customers (Steen
& Tanenbaum, 2017). In this part of development of distributed computing, problem comes from
service composition and making sure that these services operate in harmony. SOA centralizes the
7
complex operations such as business constraints and service orchestration all in the ESB. This
created a monolith of reusable services, but it will not be able to keep pace of customers and
business expectations (Newman, 2015). A monolith is a software application whose modules connt
be executed independently. This makes monoliths difficult to use in distributed system without
specific framework (Dragoni, et al., 2017). In other words, SOA isn’t scalable when resources are
few and highly demanded. Through SOA, it is difficult to understand the ways to split highly
complex system into small sub system. With such drawbacks, came the rise of microservices.
1.3 Discussion on Microservices

The term “microservices” was first introduced in 2011 at an architectural workshop as a
way to describe the participants’ common ideas in software architecture patterns (Fowler & Lewis,
2014). But since then microservice architecture gained popularity relatively recently and can be
considered to be in its infancy. Microservices is a cohesive, independent process interacting via
messages. As an example, consider a service intended to compute calculations (Dragoni, et al.,
2017). Microservices approach is a relatively new term in software architecture patterns. To put it
simply, microservice is an approach to develop application as a set of small independent services
that can run its own independent process. These services could sometime communicate with light
weight mechanism such as HTTP. It is an opposite to monolithic architecture (Namiot & Sneps-
Sneppe, 2014). Monolith application could be difficult to understand and modify as it gets bigger.
Microservices keeps the independent services small and focused as it focuses the service
boundaries on business boundaries and explicit boundary. This avoid the temptation to grow too
large with the difficulties that it might face (Newman, 2015).
How does the size of a microservice defined? Lines of codes (LOC) can be an indicator
(Wolff, 2016). One of its problem using this approach is that it would depend on the programming
language used. Some languages require more code than others to express the same functionality.
More than that, microservices is seen as an architecture approach thus it should follow the
condition of the domain without adhering to technical metrics like LOC. LOC and the size of the
microservices can be influenced by several factors such as modularization, team size, or distributed
communication.
8
Figure 3: Factors influencing the size of microservice (Wolff, 2016)
Modularization helps software developers to build software in modules as it is better suited

to deal with its complexity as they only need to understand the modules instead of the entire
software. In microservices, modularization limits its size as it forces developers to only create
when it understands all its aspects (Wolff, 2016).
Team size deals with the effort taken by the team to implement features within a
microservice and deploy these features into production independently of other teams. Team size
sets the upper limit for the size of microservices. When microservices are small, a team can be
responsible for several microservices only. When a microservices reaches a size that prevents its
further development by a single team, its too large. A typical team should be 3 to 9 people. The
teams are supposed to work and bring software into production independently of each other
whereby each team work on a separate microservice (Wolff, 2016).
Similarly, based on the chart in Figure 3, distributed communication overhead increases

with the number of microservices. Microservices run within independent processes, thus its
communication would be distributed via the network. When a microservice is small, distributed
communication increases, overall system gets slower because a call on another system via the
network is orders of magnitude slower than a direct call within the same process (Wolff, 2016).
9
Architecture
The domain architecture of a microservice-based system determines which microservices

within the system should implement which domain. It defines how the entire domain is split into
different areas, each of which are implemented by one microservice and thus one team (Wolff,
2016). The benefits of microservices are seen most clearly in very dynamic environments. Due to
the independent deployment of individual microservices, teams can work in parallel on different
features without the need for significant coordination.
An example is the Event-driven architecture whereby each microservices call each other
in order to implement shared logic. A microservice architecture is a distributed application where
all modules are microservices (Wolff, 2016). For example, at the end of the order process the
microservice for billing as well as the microservice for the order execution can be called to create
the bill and make sure that the ordered items are indeed delivered in figure 4.
Figure 4: Example (Wolff, 2016)
Event-driven architecture (EDA) enables a different modelling in figure 5: When the order
processing has been successfully finished, the order process will send an event. It is an event
emitter. This event signals all interested microservices that there is a new successful order. Thus,
one microservice can now print a bill, and another microservice can initiate a delivery (Wolff,
2016).
10
Figure 5: EDA (Wolff, 2016)
EDA promotes loose coupling and facilitate changes as each microservice need to know little about
each other. For figure 5, other microservices which are interested in order could easily register
without modifying the order process.
To give an example of another microservice architecture, assume that there’s a presence

of two microservices: Calculator and Displayer. The first is the calculator microservice; the second
renders and displays images. A new microservice is then introduced, called Plotter, that
orchestrates Calculator to calculate the shape of the graph and that invokes Displayer to render the
calculated shape. Since all the components of a microservice architecture are microservices, its
distinguishing behaviour derives from the composition and coordination of its components via
messages (Dragoni, et al., 2017). Figure below shows an example of a microservice architecture
for the example stated:
11
Figure 4: A microservice architecture as an example (Dragoni, et al., 2017).
1.4 Discussion on the role of Microservices in the distributed web application

Large internet companies like Amazon, Netflix and Linkedin uses microservices
architecture to deploy large applications in the cloud as a set of small services which could be
independently developed, tested, deployed, scaled, and operated (Villamizar, et al., 2017).
Microservices architecture can be deployed in a cloud in the figure 4. Microservice μS1 is deployed
using a load balancer and several web servers. Microservice μS2 is also deployed using a load
balancer and several web servers, and it also uses a relational database. The gateway is deployed
using a load balancer and several web servers.
Figure 5: Microservices architecture in the cloud (Villamizar, et al., 2017)
There are many key benefits in using microservices when applied key concepts behind
distributed systems are considered. Below is a list of some of its key benefits and will be discussed:
1. Technology Heterogeneity
2. Scaling
12
3. Ease of Deployment
Technology Heterogeneity
In order to fit the current business needs, a system would be composed of multiple,
collaborating services and through the use of microservices, different technology can be used
inside each one. If one part of the system requires an improve in performance, then the old
component could be swap with different technology stack that is better able to achieve the
performance levels required. With microservices, technology could be adopted more quickly and
understand how new advancement could be beneficial (Newman, 2015).
Scaling
In monolithic architecture, everything has to be scale together as if one small part is

constrained by performance, then its behaviour is locked up in the giant monolithic application.
With smaller services, only those required to scale should be scaled and this made it easier to scale
according to the needs of the users (Newman, 2015).
Ease of Deployment
Microservices allows changes to a single service and deploy it independently of the rest of
the system. Not just deployment, it also encourages fast rollback if there’s any problem because
individual service can be isolated easily. New functionality could reach out to customer more
quickly for large organization (Newman, 2015).
13
1.5 Discussion on Spring Boot Microservices framework

Spring Boot came to Spring over the past year to help develop Spring application with
more minimal friction, more agility and able to focus on addressing the application’s functionality
with minimal needs to configure Spring itself (Walls, 2016). Through minimal Spring
configuration, it has help eliminate the need to manually setup boilerplate configuration (Reddy,
2017). Spring Boot is a framework to develop production-ready microservices in Java. It can be
used to build RESTful microservices (RV, 2016). Spring Boot Microservices framework should
be used with proper knowledge of the characteristics of the systems as it is difficult to map to
advantage or disadvantage of using Spring Boot. Right design decisions should be taken, and the
trade-offs to be applied for a successful microservice development. Spring Boot can generate
WAR files, which can be installed on a Java application or web server. The result of the build is a
JAR file in that case, which can be run with a Java Runtime Environment (JRE). The JAR file
contains everything for running the application and also the necessary code to deal with HTTP
requests. This approach is by far less demanding and simpler than the use of an application server.
With a simple example in figure 8, the main program main hands control over to Spring Boot. The
annotation @SpringBootApplication would allow Spring Boot to generate a suitable environment.
For example when a web server is started, Spring web application is generated as the application
is web application. Because of @RestController the Spring Framework instantiates the class and
calls methods for the processing of REST requests. @RequestMapping shows which method is
supposed to handle which request. Upon request of the URL “/” the method hello() is called, which
returns as result the sign chain “hello” in the HTTP body. In an @RequestMapping annotation,
URL templates such as “/customer/{id}” can be used. Then a URL like “/customer/42” can be cut
into separate parts and the 42 bound to a parameter annotated with @PathVariable (Wolff, 2016).
Figure 8: simple Spring Boot REST Service (Wolff, 2016)
14
Benefits
Spring Boot starters enable developers to specify build dependencies by what they offer rather
than the use of explicit library names and version. More than that, Spring Boot makes configuration
parameters and abstracts many lower level implementations, it minimizes the chance of error to a
certain extent. Spring Boot recognizes the nature of the application based on the libraries available
in the class path and runs the autoconfiguration classes packaged in these libraries (RV, 2016).
Figure 6: Code Snippet
In Figure 5, Spring Boot framework understands that the project is set to use the Spring Data JPA
and HSQL databases. It automatically configures the driver class and other connection parameters
(RV, 2016).
Drawbacks
In terms of testability of servers, microservices pose a challenge as in order to achieve a

full-service functionality, one service may rely on another service, and that, in turn, on another
service—either synchronously or asynchronously. The issue is how to test an end-to-end service
to evaluate its behavior? The dependent services may or may not be available at the time of testing.
Besides that, logging and monitoring also faces challenges as with a large number of microservices,
and with multiple versions and service instances, it would be difficult to find out which service is
running on which server, what's the health of these services, the service dependencies, and so on
(RV, 2016).
Architecture
Spring Boot Framework could use Event-Driven Architecture whereby different

microservices send events whenever an important action happens. These events are exchanged
15
between microservices through a message broker or event bus. Others can subscribe to events for
which they are interested and react to them. An important concept that is related: an action that
already happened, others can’t change it and can’t prevent it from happening. Any system that uses
this architecture also known as reactive systems because of the action-reaction pattern (Macero,
2017). A sample of Event-Driven Architecture that is applied to an application:
Figure 7: Sample Event-Driven Architecture (Macero, 2017)
Building Web Applications with Spring Boot
Spring MVC is the most popular Java Web framework based on the Model View Controller
(MVC) design pattern. Spring Boot makes it very easy to get started with Spring MVC because
the Spring Boot autoconfiguration mechanism configures most of the components such as
DispatcherServlet, ViewResolvers, ContentNegotiatingViewResolver etc, with default values and
provides the options to customize them. Spring Boot provides embedded servley container support,
so application could be built in a self-contained deployment unit (Reddy, 2017). Spring Boot
provides the Web starter spring-boot-starter-web for developing web applications using Spring
MVC.
16
Figure 8: SpringMVC request processing flow (Reddy, 2017)
17
1.6 Discussion on alternative framework

The featured alternative framework would be Flask. Born in 2010, Flash is a small
framework by most standards, small enough to be called a “microframework”. Flask promotes
readability and easy understanding of its source code (Grinberg, 2014). Flask is a lightweight Web
framework written in Python and it has since become one of most widely used Python web
frameworks for start-ups, and a perfect tool for quick and simple solutions in most businesses.
Flask aims at keeping the core of the framework small but highly extensible thus writing
application or extensions very easily and flexible, while empowering developer to choose their
own configuration for their application (Aggarwal, 2014). Its simplicity can be seen in the code
snippet in Figure 8:
Figure 9: Hello World Application (Aggarwal, 2014)
It contains sets of powerful libraries that are well suited for web development such as (Copperwaite
& Leifer, 2015):
 Template rendering with Jinja2, one of the most powerful Python template engines
 Easy-to-use, flexible application configuration management
 URL routing that makes it easy to map URLs to your code
With these features, it can handle Ajax requests, browser requests, and user sessions between
request and so on. Flask would be used to combine with Werkzeug and Jinja2 frameworks. It is
also responsible for answering requests and presenting the output (Maia, 2015).
Architecture
As covered in Spring Boot Framework, Flask can also be used in MVC architecture
whereby it would only cover C and V. But it will not be able to work with integrated model layer
out of the box, but it does accept database solution from another model layer (Maia, 2015). Flask
18
can maximise the use of Jinja2 to implement the View layer of an MVC architecture. For example,
consider a user who is registering a new account on a website. The user types an email address and
a password in a web form and clicks the Submit button. On the server, a request that includes the
data from the user arrives and Flask dispatches it to the view function that handles registration
requests. This view function needs to talk to the database to get the new user added and then
generate a response to send back to the browser. These two types of tasks are formally called
business logic and presentation logic. Code would be hard to understand and maintain if both
logics are mixed together. Thus, the presentation logic will be move into templates. A template is
a file that contains the text for a response, placeholder variables for dynamic parts known only in
the context of a request. This placeholder variables is called rendering and this powerful template
is called Jinja2 (Grinberg, 2014). Jinja2 can be use with template files or string in order to create
formatted text such as HTML, or Markdown. It can be used to put together, reuse, and extend
template (Maia, 2015). An example uses of template called user.html that can be called in
render_template function for representing a variable with its response:
Figure 10: Response (Grinberg, 2014)
Flasks looks for predefined templates in templates subfolder located within an application folde.
Figure 11: user.html template use to call the response (Grinberg, 2014)
19
1.7 Justifications for Adopted Flask Framework

Given Flask is one of the most popular Python web frameworks, for starters, Flask has a
lot of resources available such as guides, tutorials and books. Flask is simple, but it manages to
provide the necessary tools to build a quick prototype for a web app right after a fresh install and
doesn’t take much lines of Python as it is all modular as compared to Spring Boot in terms of
configuration. With all the main components packed in the Flask package, building a simple web
app in a single Python file is as easy as it gets. Besides that, the flexibility that Flask has given
developers to develop web application is much more compared to Spring Boot. Such example can
be seen in the choice of not having an object relation mapping as Flask gives a lot of options to
developers in the templates (Jinja2) and developers can just choose one that is suited for a task.
20
2.0 Part Two
2.1 Design of Web Components

In this section, the design of the web components would be discussed and how they are
implemented in this project. Some of the web components that would be covered are:
1) JSPs
2) Servlets
Before going into the implementation, it is essential to have a bird’s eye view of JSP and Servlet
and understand their importance.
JSP
JavaServer Pages or also known as JSP is one solution to providing dynamic Web content
(Marco, 2001). Without JSP, to update the appearance or the content of plain static HTML, it must
be done manually. Through JSP, content dependent on many factors could be achieved including
time of the day, the information provided by the user, the user’s history of interaction with the
website and even the browser’s type. It provided online services in which it can be tailored to each
response for the viewer who made the request, depending on their preference and requirements
(Zambon, 2012). Customers want and expect some sort of personalization from sites they visited.
It contains both HTML and JSP tags but it is still a text document (Wolf, 2017). JSP combines
static text with special JSP tags and these static texts represent invariant parts of the Web page.
The static text and the JSP tags will be sent to a Java-enabled server that generates HTML from
both static and JSP tag. The server would send generated HTML back to the browser for display
and continued user interaction.
JSP files typically have a .jsp extension, such as home.jsp. The extension allows JSP-enabled
server to recognize it as a JSP page and in turn processes the special tags as JSP tags (Marco, 2001).
Figure below shows JSP can be viewed by a user. With JSP, the web page will not exist on the
server as the server creates it fresh when responding to each request.
21
Figure 12: View a JSP page (Zambon, 2012)
How does it work? Based on the book by Giulio Zambon, it provided a brief description on the
steps involved:
1. The browser or the user operating the web browser can send an HTTP request to the web
server. The URL would end in .jsp, for example home.jsp.
2. This web server is not a normal server, but it is a Java server with the necessary extensions
to identify and handle java servlets. The web server would recognize the HTTP request is
for a JSP page then forwards it to a JSP engine.
3. The JSP engine would load the JSP page from disk and converts it into a Java Servlet. The
servlet is indistinguishable from another servlet developed by Java rather than JSP, but the
Java code of a JSP servlet is not easy to read or modified.
4. The JSP engine complies the servlet into an executable class and forwards the original
request to another servlet engine.
5. The servlet engine loads the servlet class and executes it. During execution, the servlet
would produce an output in HTML format which the servlet engine passes to web server
inside the HTTP response. The servlet has Java println statements that write the static text
to the output stream and Java code that implements the functionality of the JSP tags (Marco,
2001).
6. Browser would receive the forwarded HTTP response from the web server.
7. The dynamically generated HTML page inside the HTTP response would be handled by
the web browser as a static page.
22
Example of JSP’s implementation in the project:
The JSP file involved is called login.jsp. Below is a code snippet of the JSP page whereby it
receives user inputs (Username and Password) and submit the JSP page to server with a “POST”
service. The ACTION attribute of the HTML form specified the action upon submitting the form
is to send the name of a JSP page with the two parameters to the server. This would cause the JSP-
enabled server (Login.java) to recognize the .jsp extension and takes appropriate action. In this
case, the servlet would take the necessary action depending on the parameters and forward it to
relevant JSP page involved.
Figure 13: login.jsp (Wong, 2019)
23
Figure 14: The Login page (Wong, 2019)
24
Figure 15: Login.java (Wong, 2019)
25
Servlet
The controller is housed in the Java Servlets. The controller layer contains code to handle
application-specific logic. This includes request such as receiving data from web pages, sending
data to classes in service layer and sending the user to next servlet or JSP. Where else the controller
does not access the database directly, but in the project’s case, it’s through the facades (Wolff,
2016).
Servlets are Java Classes that respond to incoming HTTP requests. The request is sent by
browser through actions such as submitting a form. The servlet will get respond and process the
request. Because the servlet only has two methods, doGet and doPost, they correspond to the get
or post method of a form respectively (Wolf, 2017). The servlets implement javax.servlet.Servlet
interface (Perry, 2004). Below is a sample code snipper of the Register.java class.
Figure 16: Register.java (Wolff, 2016)
26
2.2 User Manual

This section will cover the general navigation of all pages for the respective users:
1) Customer
2) Admin
3) Staff (Delivery and Reservation)
The Delivery and Reservation staff share similar pages with admin but some of it has restricted
functionality. Thus, the user manual would include a note if the view is present in delivery or
reservation staff to reduce redundancy.
2.2.1 Customer
1) Login
Figure 17: Screenshot (Wong, 2019)
27
2) Register
3) Home Screen
28
4) Profile
Reservation and delivery staff is also able to edit their profile using the same method.
5) Edit Profile
29
6) Making Order/Delivery
7) View Order Status
30
8) History
9) Top Up Wallet

31
2.2.2 Admin
1) Admin Page

32
2) Customer
3) Customer – View Customer
33
4) Customer – Edit/Delete Customer
5) Edit Customer
34
6) View/Add Staff
7) Edit/Delete Staff
35
8) Assign/Make Available Delivery

- This also available for reservation staff to assign delivery man to task.
- But the delivery staff can only view his/her job.
36
9) View/Add Foo
10) Edit/Delete Food
37
11) Approve/Delete/ Food Order

- The reservation is also able to approve or delete food orders.
12) Complete Delivery for Delivery Staff

- Deliver Staff can complete delivery and assign ratings
38

13) Report
2.3 Design of Business Tier

EJBs or Enterprise JavaBeans provided the rationale of the need for server-side distributed
components. It is a business component framework that could unify the emergence of separate
technologies (RMI, JTA) and incorporate them under a standard component development model.
It has become a robust and standard framework for deploying and executing business components
in a distributed multiuser environment (Wetherbee, et al., 2018).
The EJB component model consisted of three objects types that developers may build or
customize:
1) Session beans
2) Message-driven beans
3) Entities (Java Persistence API)
Session beans and Message-driven beans are considered to be enterprise beans. In earlier version
of EJB, entities are referred to as entity beans, but recent version has set entities to be managed by
39
persistence provider and not EJB container, thus no longer considered as enterprise beans
(Wetherbee, et al., 2018).
Session beans
Session beans provided a model for the business process of the Java Application and
encapsulate a business logic for each process. They are Java components that run on EJB container
which is typically used to model a task such as entering customer information or implementing a
process that maintains a conversation state with client application. Some use cases to hold business
logic includes the order entry and expense reporting applications (Wetherbee, et al., 2018). Which
in the project’s case, it is used for food order entry, human resource etc. In human resource, it
creates a new employee and assigns the employee to a particular department.
Session beans has three types which is stateless, stateful and singleton. Stateless bean does
not maintain any conversational state on behalf of the client application. Where else, stateful
maintains a state and an instance of the bean which is tied to a specific client request. It runs on
server and can be seen as an extension to client program. Lastly, the singleton is instantiated only
once for a single application. It lives only for the full duration of an application and maintain the
state between each invocations (Wetherbee, et al., 2018). Figure below shows session beans in a
3-tier architecture with a web application:
Figure 40: 3-tier architecture with a web application (Wetherbee, et al., 2018)
Message-Driven Beans
Messaging is one of the viable solutions for integrating existing and new applications in an
asynchronous communication and loosely coupled transaction model. This allow the application
40
to avoid waiting for the receiver when sending a message because both sender and receiver
understand the message format.
The message-driven bean is an asynchronous message consumer that processes messages

delivered via JMS. It provided a standard messaging component model that achieves the goal of
asynchronous and message-oriented architecture in enterprises (Wetherbee, et al., 2018).
Message-driven bean doesn’t have business interfaces but rather:
- Message-driven class
- Optional callback listener class
- Optional interceptor class
Figure 41: Sample Message-driven Bean use case (Wetherbee, et al., 2018)
41
2.3 Overview of Architecture

The web application’s architecture is based on the model-view-controller (MVC) pattern.
The MVC is a software design pattern used for creating data driven web application. In general,
design pattern is a general solution to address common software design challenges. Using the MVC,
it can be separated into presentation layer (view), business logic (controller) and database layer
(model). When changes are made to a layer, it will impact minimally to another.
MVC promotes code reuse and maintainability. In reusability, the application’s logic
implementation in the model and controller gets reused for each different view. More than that,
the code is in independent units and can be maintained without fully understanding the entire
application (Wolf, 2017).
Figure 42: An MVC model (Zambon, 2012)
42
JSP (View)
Figure 43: View (Wong, 2019)
43
Servlet (Controller)
Figure 44: Controller
44
Entity Bean (Model)
Figure 45: Model
45
2.4 UML Diagrams
46
2.5 Database Design

The database consisted of 5 tables:
1) FoodDetails
2) StaffDetails
3) TempFoodOrder
4) UserAccount
5) UserMoney
1. Food Details
Stores food information such as the id, name, price, quantity, description and its type
(Food/Drinks).
Column name Data type

id (Primary key) String
foodname String
price int
quantity int
description String
foodtype char
47
48
2. Staff Details
Staff Details act as the human resource database that stores information such as id, password,
staff name, staff gender, phone, ic, email, address, his/her role and status.

password String
staffname String
gender char
phone int
ic String
email String
address String
staffrole char
staffstatus String
49
50
3. TempFoodOrder
Stores information regarding the food order and allows reservation staff and admin to approves
the order. Information such as id, userid, foodids’, orderdatetime, price, address,status, quantity,
deliverystatus, deliveryman.

id (Primary key) Long
userid String
foodid List
orderdatetime String
price int
address String
status String
quantity int
deliverystatus char
deliveryman String
rating status
51
52
4. UserAccount
Stores information about the user/customer such as username, password, name, ic, gender, phone
number, email, address, status, UserMoney.

password String
ic int
gender char
phoneno int
email String
address String
status char
UserMoney id (Foreign key) object
53
54
5. UserMoney
Stores the userid and its balance.

id (Primary key) Long
balance double
55
2.6 Entity Relationship Diagram (Crow’s foot notation)

FoodDetails
UserMoney
PK id
PK id
foodname
balance
price
quantity
description
StaffDetails
TempFoodOrder foodtype
UserAccount PK id
PK id
PK id
password
userid
password
staffname
orderdatetime
name gender
price
ic phone
address
gender ic
status
phoneno email
quantity
email address
deliverystatus
address staffrole
deliveryman
status staffstatus
foodid
56
References
6. Aggarwal, S., 2014. Flask Framework Cookbook. 1 ed. Birmingham: Packt Publishing Ltd..
7. Copperwaite, M. & Leifer, C., 2015. Learning Flask Framework. 1 ed. Birmingham: Packt
Publishing Ltd..
8. Dragoni, N. et al., 2017. Microservices: Yesterday, Today, and Tomorrow. s.l.:Springer

International Publishing AG 201.
9. Fowler, M. & Lewis, J., 2014. Microservices. [Online]

Available at: https://martinfowler.com/articles/microservices.html
[Accessed 6 March 2019].
10. Ghosh, S., 2007. Distributed Systems An Algorithmic Approach. 1 ed. New York: Taylor
& Francis Group, LLC.
11. Gital, A. Y. et al., 2014. Performance analysis of cloud-based CVE communication

architecture in comparison with the traditional client server, P2P and hybrid models. The
5th International Conference on Information and Communication Technology for The
Muslim World (ICT4M), pp. 1-6.
12. Goscinski, A., 1991. Distributed Operating Systems: The Logical Design. 1 ed. Boston:
Addison-Wesley Longman Publishing Co., Inc.
13. Grinberg, M., 2014. Flask Web Development. 1 ed. Sebastopol: O’Reilly Media, Inc.
14. Ismail, L., Hagimont, D. & Mossire, J., 2000. Evaluation of the mobile agents technology:
Comparison with the client/server paradigm. Information Science and Technology (1ST),
Volume 19.
15. Kshemkalyani, A. D. & Singhal, M., 2007. DISTRIBUTED COMPUTING: PRINCIPLES,

ALGORITHMS, and SYSTEMS. Chicago: Cambridge University Press.
16. Macero, M., 2017. Learn Microservices: A Practical Approach to RESTful Services using
RabbitMQ, Eureka, Ribbon, Zuul and Cucumber. 1 ed. New York: pringer
Science+Business Media New York.
57
17. Maia, I., 2015. Building Web Applications with Flask. 1 ed. Birmingham: Packt Publishing
Ltd..
18. Marco, L., 2001. EJB & JSP: Java On The Edge,. Unlimited Edition ed. s.l.:Wiley.
19. Namiot, D. & Sneps-Sneppe, M., 2014. On Micro-services Architecture. International

Journal of Open Information Technologies ISSN: 2307-8162, 2(9).
20. Newman, S., 2015. Building Microservices: Designing Fine-Grained System. 2 ed.
California: O’Reilly Media, Inc..
21. Perry, B. W., 2004. Java Servlet & JSP Cookbook. 1 ed. s.l.:O'Reilly.
22. Reddy, K. S. P., 2017. Beginning Spring Boot 2: Applications and Microservices with the
Spring Framework. 1 ed. Hyderabad: Springer Science+Business Media New York.
23. RV, R., 2016. Spring Microservices: Build scalable microservices with Spring, Docker,
and Mesos. 1 ed. Birmingham: Packt Publishing Ltd..
24. Salah, T. et al., 2016. The Evolution of Distributed Systems Towards Microservices
Architecture. The 11th International Conference for Internet Technology and Secured
Transactions (ICITST-2016).
25. Steen, M. v. & Tanenbaum, A. S., 2017. Distributed Systems. 3 ed. s.l.:Maarten van Steen.
26. Villamizar, M. et al., 2017. Cost comparison of running web applications in the cloud using
monolithic, microservice, and AWS Lambda architectures. Service Oriented Computing
and Applications, 11(2), pp. 233-247.
27. Walls, C., 2016. Spring Boot In Action. 1 ed. New York: Manning Publications Co..
28. Wetherbee, J., Nardone, M., Rathod, C. & Kodali, R., 2018. Beginning EJB in Java EE 8:
Building Applications with Enterprise JavaBeans. 3 ed. New York: Springer
29. Wolf, D., 2017. Java EE Web Application Primer Building Bullhorn: A Messaging App
with JSP, Servlets. JavaScript, Bootstrap and Oracle. 1 ed. NewYork: Springer
58
30. Wolff, E., 2016. Microservices: Flexible Software Architecture. 1 ed. Boston: Pearson
Education, Inc.
31. Wong, G., 2019. Screenshot of Code Snippets. Kuala Lumpur: s.n.
32. Zambon, G., 2012. Beginning JSP, JSF and Tomcat. 1 ed. New York: Springer
59

Epda Final Report

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Epda Final Report

Diunggah oleh

Hak Cipta:

Format Tersedia

CT027-3-3-EPDA | Individual Assignment | UC3F1812SE

1.0 Part One .................................................................................................................................... 4

1.1 Brief history on distributed computing ................................................................................. 4

1.2 Discussion on architectural evolution of distributed computing .......................................... 6

1.3 Discussion on Microservices ................................................................................................ 8

1.5 Discussion on Spring Boot Microservices framework ....................................................... 14

1.6 Discussion on alternative framework.................................................................................. 18

1.7 Justifications for Adopted Flask Framework ...................................................................... 20

2.0 Part Two ............................................................................................................................. 21

2.1 Design of Web Components ............................................................................................... 21

2.2 User Manual ........................................................................................................................ 27

2.2.1 Customer ...................................................................................................................... 27

2.2.2 Admin .......................................................................................................................... 32

2.3 Design of Business Tier ...................................................................................................... 39

2.3 Overview of Architecture ................................................................................................... 42

2.4 UML Diagrams ................................................................................................................... 46

2.5 Database Design.................................................................................................................. 47

2.6 Entity Relationship Diagram (Crow’s foot notation).......................................................... 56

1. All users must login to use the system.

- If no available delivery staff, the reservation will be rejected.

1.0 Part One

1.1 Brief history on distributed computing

 “A distributed system is a collection of autonomous computing elements that appears to its

Figure 1.0: A distributed system that connects processors by a communication network

Why is distributed computing considered to be important in this era of modern computing?

1.2 Discussion on architectural evolution of distributed computing

Client/Server belongs to traditional architectures and with the growth of networking

Figure 2: Two Tier architecture (Steen & Tanenbaum, 2017)

1.3 Discussion on Microservices

Figure 3: Factors influencing the size of microservice (Wolff, 2016)

Modularization helps software developers to build software in modules as it is better suited

Similarly, based on the chart in Figure 3, distributed communication overhead increases

The domain architecture of a microservice-based system determines which microservices

Figure 4: Example (Wolff, 2016)

Figure 5: EDA (Wolff, 2016)

To give an example of another microservice architecture, assume that there’s a presence

Figure 4: A microservice architecture as an example (Dragoni, et al., 2017).

1.4 Discussion on the role of Microservices in the distributed web application

Figure 5: Microservices architecture in the cloud (Villamizar, et al., 2017)

In monolithic architecture, everything has to be scale together as if one small part is

1.5 Discussion on Spring Boot Microservices framework

Figure 8: simple Spring Boot REST Service (Wolff, 2016)

Figure 6: Code Snippet

In terms of testability of servers, microservices pose a challenge as in order to achieve a

Spring Boot Framework could use Event-Driven Architecture whereby different

Figure 7: Sample Event-Driven Architecture (Macero, 2017)

Building Web Applications with Spring Boot

Figure 8: SpringMVC request processing flow (Reddy, 2017)

1.6 Discussion on alternative framework

Figure 9: Hello World Application (Aggarwal, 2014)

Figure 10: Response (Grinberg, 2014)

1.7 Justifications for Adopted Flask Framework

2.0 Part Two

2.1 Design of Web Components

Figure 12: View a JSP page (Zambon, 2012)

Example of JSP’s implementation in the project:

Figure 13: login.jsp (Wong, 2019)

Figure 14: The Login page (Wong, 2019)

Figure 15: Login.java (Wong, 2019)

Figure 16: Register.java (Wolff, 2016)

2.2 User Manual

Figure 17: Screenshot (Wong, 2019)

Figure 18: Screenshot (Wong, 2019)

Figure 19: Screenshot (Wong, 2019)