BEGUM ROKEYA UNIVERSITY, RANGPUR.

ASSIGNMENT FOR
WEB ENGINEERING

CSE

SUBMITTED BY
Group-02 SUBMITTED TO
Members:
Ahsan Habib 1306007
Md. Ariful Hasan 1306009
Md. Hasan Ali Emon 1306028 PRODIP KUMAR SARKAR
Md. Abdul Mamun 1209003
Md. Mehedi Hasan Nayem 1209022
Soyeb Ahmed 1209064
Assistant Professor,
Session: 2013-2014
4rd Year 2nd Semester Department of Computer Science &
Department of Computer Science & Engineering,
Engineering,
Begum Rokeya University, Rangpur.

What is an Architecture?

Date of Submission: 5/11/20

 1

There is no unique definition of the term “Architecture”. The following points will
describe Architecture:

1. Architecture describes structure: According to (Bass et al. 1998), the architecture

of a software system consists of its structures, the decomposition into components,
and their interfaces and relationships. It describes both the static and the dynamic
aspects of that software system, so that it can be considered a building design and
flow chart for a software product.
2. Architecture forms the transition from analysis to implementation: When we
create architecture, we try to break the functional requirements and quality
requirements down into software components and their relationships and interfaces in
an iterative approach. This process is supported by a number of approaches, such as
the Unified Process.
3. Architecture can be looked at from different viewpoints: Depending on the point
of view from which architecture is seen, we can emphasize and itemize different
architectural aspects. We normally distinguish between four different views: (1) the
conceptual view, which identifies entities of the application domain and their
relationships; (2) the runtime view, which describes the components at system
runtime, e.g., servers, or communication connections; (3) the process view, which
maps processes at system runtime, while looking at aspects like synchronization and
concurrency; and (4) the implementation view, which describes the system’s software
artifacts, e.g., subsystems, components, or source code. This differentiation into
different viewpoints is also supported by modeling languages, e.g., the Unified
Modeling Language.
4. Architecture makes a system understandable: Structuring software systems and
breaking them down into different perspectives allows us to better manage the
complexity of software systems, and the systems become easier to understand. In
addition, the abstraction of system aspects facilitates the communication of important
architectural issues.
5. Architecture represents the framework for a flexible system: Tom DeMarco refers
to architecture as a “framework of change”, i.e., the software architecture forms the
framework in which a software system can evolve. If extensions of a system have not
been accounted for in advance, then such an extension will at best be difficult to
realize.
 2

Considering the above properties of architectures, we can easily see that architectural
decisions are of enormous importance for the development of Web applications.

Developing Architectures:

The requirements of software and thus its architecture is subject to change. Technical and
organizational constraints change during and after the development of an application. This
may be due to unclear requirements at the beginning of the development process or a change
of requirements after a system’s completion. This is the reason why software systems are
often referred to as “moving targets”. Figure shows the different factors and constraints
influencing the development of an architecture according to (Jacobson et al. 1999).

Figure: Factors influencing the development of an architecture (Jacobson et al. 1999)

The architecture of an application is primarily influenced by functional requirements, i.e., the

services provided by a system, and quality considerations such as scalability or performance.
Apart from these requirements, architectures are further influenced by technical constraints,
such as the used system software (e.g., the operating system), the middleware (e.g., a
CORBA implementation), legacy systems to be integrated, standards used, development rules
 3

(e.g., coding guidelines), or distribution aspects (e.g., the distribution over different locations
of a company). Moreover, the software architect’s experiences play a considerable role in the
definition of an architecture. Because software systems are moving targets, architectures are
typically developed in an iterative way. This approach should make the risks resulting from
insecure requirements and constraints calculable and controllable. However, an iterative
approach does not guarantee a good architecture. An iterative approach is not sufficient for
solving specific design problems, such as the integration of a legacy system, in the
development of an architecture. Fortunately, design patterns have proven to be very effective
in supporting such design decisions.

Patterns:
Patterns describe recurring design problems, which arise in a specific design context, and
propose solutions. A solution describes the participating components, their responsibilities,
the relationship between these components, and the interplay of these components within the
specific problem. This means that patterns enable us to reuse proven and consolidated design
knowledge, supporting the development of high-quality software systems. Buschmann et al.
(1996) identifies patterns on three different abstraction levels:

1. Architecture patterns: These patterns map fundamental structuring mechanisms for

software systems. They describe architectural subsystems, their responsibilities,
relationships, and interplay. One example of this type of pattern is the Model-View-
Controller (MVC) (Buschmann et al. 1996).
2. Design patterns: These patterns describe the structure, the relationships, and the
interplay between components to solve a design problem within a defined context.
Design patterns abstract from a specific programming language, but they move within
the scope of architecture patterns. An example of a design pattern is the Publisher-
Subscriber pattern described in (Buschmann et al. 1996).
3. Idioms: describe patterns that refer to a specific implementation in a programming
language, such as, for example, the Counted-Pointer idiom for storage management in
C++ (Buschmann et al. 1996)

Categorizing Architectures:

A number of architectures for specific requirements in several application domains have been
developed in the past few years. Anastopoulos and Romberg (2001) and Bongio et al. (2003)
describe architectures for Web application environments, taking the layering aspect of
 4

architectures, or the support of different data and data formats – the data aspect of
architectures – into account:

1. Layering aspect: Layering means that software systems are structured in several tiers
to implement the principle of “separation of concerns” within a software system.
Many frameworks in the field of distributed systems and Web applications are
primarily structured by the layering aspect, e.g., J2EE (Sun Microsystems 2003a)
Architectures used to integrate legacy systems, also referred to as Enterprise
Application Integration (EAI), and portals also fall in this category.
2. Data aspect: Data can be structured or non-structured. Structured data follow a
defined scheme like tables in a relational database or XML structures in a document.
Non-structured data are multimedia contents, e.g., images, audio, and video, which
typically do not follow an explicit scheme. This makes their automatic processing
difficult.
Web application architecture specifics

How Web Application Architecture Works

With web applications, you have the server vs. the client-side. In essence, there are two
programs running concurrently:

● The code which lives in the browser and responds to user input

● The code which lives on the server and responds to HTTP requests

Image via Wikipedia

 5

When writing an app, it is up to the web developer to decide what the code on the server
should do in relation to what the code on the browser should do. With server-side code,
languages include:

● Ruby on Rails
● PHP
● C#
● Java
● Python
● Java script

In fact, any code that can respond to HTTP requests has the capability to run on a server.
Here are a few other attributes of server-side code:

● Is never seen by the user (except within a rare malfunction)

● Stores data such as user profiles, tweets, pages, etc…
● Creates the page the user requested

With client-side code, languages used include:

● CSS
● Java script
● HTML

These are then parsed by the user’s browser. Moreover, client-side code can be seen and
edited by the user. Plus, it has to communicate only through HTTP requests and cannot read
files off of a server directly. Furthermore, it reacts to user input.

An Example of How It Works

To better understand, let us look at the following example:

You find this cool new website and you want to create an account, so you decide to click the
“sign up” button. You are then redirected to a page where you find a form asking you to enter
your information. After you are done filling the form you are redirected to the profile section
and you can now use the app.

In this example, the sign-up form is on the client-side, where data is collected from the user.
On the other hand, all the actions that are happening behind the scenes like adding the user to
the database, checking if the email is unique and valid, redirecting the user to different pages,
etc., are the backend of our Web app.
 6

Components of a Generic Web Application Architecture:

Below Figure shows the basic components of Web architectures and their relationships.
Communication between these components is generally based on the request–response
principle, i.e., one component (e.g., a Web browser) sends a request to another component
(e.g., a Web server), and the response to this request is sent back over the same
communication channel (synchronous communication).

The following list briefly describes each of these components:

1. Client: Generally, a browser (user agent) is controlled by a user to operate the Web
application. The client’s functionality can be expanded by installing plug-ins and
applets.
2. Firewall: A piece of software regulating the communication between insecure
networks (e.g., the Internet) and secure networks (e.g., corporate LANs). This
communication is filtered by access rules.
3. Proxy: A proxy is typically used to temporarily store Web pages in a cache. However,
proxies can also assume other functionalities, e.g., adapting the contents for users
(customization), or user tracking.

Figure: Basic components of web application architectures.

4. Web server: A Web server is a piece of software that supports various Web protocols
like HTTP, and HTTPS, etc., to process client requests.
5. Database server: This server normally supplies an organization’s production data in
structured form, e.g., in tables.
 7

6. Media server: This component is primarily used for content streaming of non-
structured bulk data (e.g., audio or video).
7. Content management server: Similar to a database server, a content management
server holds contents to serve an application. These contents are normally available in
the form of semi-structured data, e.g., XML documents.
8. Application server: An application server holds the functionality required by several
applications, e.g., workflow or customization.
9. Legacy application: A legacy application is an older system that should be integrated
as an internal or external component.

What are layers?

As applications grow in complexity, one way to manage that complexity is to break up the
application according to its responsibilities or concerns. This follows the separation of
concerns principle and can help keep a growing codebase organized so that developers can
easily find where certain functionality is implemented. Layered architecture offers a number
of advantages beyond just code organization, though.
By organizing code into layers, common low-level functionality can be reused throughout the
application. This reuse is beneficial because it means less code needs to be written and
because it can allow the application to standardize on a single implementation, following
the don't repeat yourself (DRY) principle.

2-Layer Architecture:
It is like Client-Server architecture, where communication takes place between client and
server.
In this type of software architecture, the presentation layer or user interface layer runs on the
client side while dataset layer gets executed and stored on server side.
There is no Business logic layer or immediate layer in between client and server.

N-Layer Architecture
N represents a number and It represents the Layers of an application. Very common is 3-
layer applications. It comprises 3-layers, Presentation Layer, Business Logic Layer, and
Data Access Layer. “Tire” is often used instead of “layer”. Both indicate the same aspect of
thinking.
 8

Figure: 3-layer Architecture

When an application behavior is split among multiple layers, these layers are logically
separated. In some cases separate layers are physically deployed to different devices or
different process boundaries on the same device. In which case it is called physically
separated.

It is not important for separated tiers to be deployed in separate devices.

3-Layer design is one of the most common in N-layer architecture and best practice
application design. It is used by most developers. Workflow layer is encapsulated into the
service layer. Different presentation layers will use different services with interfaces
appropriate to their workflow.

Benefits of N-tier Architecture

1. Reuse code

For example Let's say you have a class that reads, writes, delete, and finds an entity. You can
use this class with entity customer, and entity product. You don't need to write these
functionalities each time. The entire DAL module is reusable (Data Access Layer). Code
reuse benefits are,

1. Improve productivity via Reuse

2. Improve Productivity via Team Segment
3. Improve Maintainability

If a change is made with the Database it will only affect only DAL. If change is BL it will
only affect BL.

2. Looser Coupling
 9

Each change will affect a specific layer of the application. Unless the changes are extreme.

3. More physical deployment

You can easily add additional physical deployment. Adding this feature can affect
performance.

4. Secure

You can secure each of the three layers separately using different methods.

5. Easy to manage

You can manage each layer separately, adding or modifying each layer without affecting the
other layers.

6. More efficient development

N-layer architecture is very friendly for development, as different teams may work on each
layer. This way, you can be sure the design and presentation professionals work on the
presentation layer and the database experts work on the data layer.

7. Easy to add new features

If you want to introduce a new feature, you can add it to the appropriate layer without
affecting the other layers.

8. Scalable

If you need to add more resources, you can do it per layer, without affecting the other layers.

9. Flexible

Apart from isolated scalability, you can also expand each layer in any manner that your
requirements dictate.

In short, with n-layer architecture, you can adopt new technologies and add more components
without having to rewrite the entire application or redesigning your whole software, thus
making it easier to scale or maintain. Meanwhile, in terms of security, you can store sensitive
or confidential information in the logic layer, keeping it away from the presentation layer,
thus making it more secure.

How It Works and Examples of N-Layer Architecture

When it comes to n-layer architecture, a three-layer architecture is fairly common. In this
setup, you have the presentation or GUI layer, the data layer, and the application logic layer.

The application logic layer. The application logic layer is where all the “thinking” happens,
and it knows what is allowed by your application and what is possible, and it makes other
decisions. This logic layer is also the one that writes and reads data into the data layer.
 10

The data layer. The data layer is where all the data used in your application are stored. You
can securely store data on this layer, do transactions, and even search through volumes and
volumes of data in a matter of seconds.

The presentation layer. The presentation layer is the user interface. This is what the
software user sees and interacts with. This is where they enter the needed information. This
layer also acts as a go-between for the data layer and the user, passing on the user’s different
actions to the logic layer.

Imagine surfing on your favorite website. The presentation layer is the Web application that
you see. It is shown on a Web browser you access from your computer, and it has the CSS,
JavaScript, and HTML codes that allow you to make sense of the Web application. If you
need to log in, the presentation layer will show you boxes for username, password, and the
submit button. After filling out and then submitting the form, all that will be passed on to the
logic layer. The logic layer will have the JSP, Java Servlets, Ruby, PHP and other programs.
The logic layer would be run on a Web server. And in this example, the data layer would be
some sort of database, such as a MySQL, NoSQL, or PostgreSQL database. All of these are
run on a separate database server. Rich Internet applications and mobile apps also follow the
same three-layer architecture.

Considerations for Using N-Layer Architecture for Your Applications

Because you are going to work with several layers, you need to make sure that network
bandwidth and hardware are fast. If not, the application’s performance might be slow. Also,
this would mean that you would have to pay more for the network, the hardware, and the
maintenance needed to ensure that you have better network bandwidth.

Also, use as fewer layers as possible. Remember that each layer you add to your software or
project means an added layer of complexity, more hardware to purchase, as well as higher
maintenance and deployment costs. To make your n-layer applications make sense, it should
have the minimum number of layers needed to still enjoy the scalability, security and other
benefits brought about by using this architecture. If you need only three layers, don’t deploy
four or more layers.

Disadvantages of N-tier Architecture

1. Adding additional servers to our application to increase its performance and
scalability. But in reality the fastest an application can perform is when all its
processes are in-process in a single machine.
2. More complex designs
3. The skills and experience required for the team is more complex
4. Multiple physical machines must be deployed in a batch or else the application must
be designed to support multiple different versions of API concurrently.

Data-aspect Architectures

Data can be grouped into either of three architectural categories:

1. Structured data of the kind held in databases;
2. Documents of the kind used in document management systems; and
 11

3. Multimedia data of the kind held in media servers.

In this respect, Web applications are normally not limited to one of these data
categories; they rather integrate documents, media, and databases.

Database-centric Architectures

A number of tools and approaches are available to integrate databases into Web
applications. These databases are accessed either directly from within Web server
extensions (in the case of 2-layer architectures), or over-application servers (in the
case of n-layer architectures). Since database technologies (and particularly
relational databases) are highly mature, they are easy to integrate. APIs are
available for different platforms, e.g., Java Database Connectivity (JDBC) for Java-
based applications, or Open Database Connectivity (ODBC) for Microsoft
technologies (Saake and Sattler 2003), to access relational databases. Bongio et al.
(2003) describes the design of data-intensive Web applications.

Architectures for Web Document Management

Figure: A content management architecture for Web applications

(according to Anastopoulos and Romberg 2001)

Above figure shows the components of a content management architecture. A Web

server receives a client request and forwards it to a content delivery server. The
content delivery server is responsible for distributing – and perhaps caching – the
contents. If a requested content is not in the cache, then the request is forwarded to
the content management server. The content can be available directly on that server
(in static form as a document, or in a content database), or it can be accessed
 12

externally. Depending on the type of integration, external content can be retrieved

either by accessing external databases (directly or by use of an aggregation service)
or from a syndication service. In contrast to accessing a database, syndication
services can handle additional functionalities, e.g., automated billing of licensing
rights.

One example of a publisher component to prepare static XML documents is the

Cocoon 2 open-source framework. Cocoon 2 supports the publication of XML
documents in the Web. Its range of application is primarily the transformation of XML
contents documents into different output formats. The underlying processing work is
based on a pipeline model, i.e., a request is accepted and forwarded to a generator
pre-defined in a configuration file. Within the pipeline, the XML document is subject
to several processing steps to bring it into the desired output format. All processing
steps in the pipeline can access information about the request, e.g., the user agent,
to adapt the response to the request (e.g., customization of the user interface).

Figure: The Cocoon 2 pipeline.

The generator is called at the beginning of the process; it is responsible for parsing
the XML document. The generator uses the SAX parser to read the XML document,
and then generates SAX messages, called events. The generator has to forward
these events to the pipeline. These SAX events can be used to transform or forward
the document. This means that the generator makes data available for processing.

The transformer can be compared with an XSL stylesheet. Finally, a serializer is

responsible for converting to the desired output format, e.g., HTML or XML again. A
powerful configuration mechanism in the form of an XML configuration file can be
used to select and define generator, transformer, and serializer. For example, the
 13

configuration routine lets one control the processing pipeline, depending on the
request and the processing results.
Architectures for Multimedia Data
The ability to handle large data volumes plays a decisive role when designing
systems that use multimedia contents. While the data volume is normally not
decisive in database-centric Web applications, it influences the architecture and the
design of multimedia Web applications considerably. A detailed overview of
architectural issues concerning multimedia data in Web applications can also be
found in (Srinivasan et al. 2001).
Basically, multimedia data, i.e., audio and video, can be transmitted over standard
Internet protocols like HTTP or FTP, just like any other data used in Web
applications. This approach is used by a large number of current Web applications
because it has the major benefit that no additional components are needed on the
server. Its downside, however, is often felt by users in that the media downloads are
very slow.

We can use streaming technologies to minimize these waiting times for multimedia
contents to play out. Streaming in this context means that a client can begin playout
of the audio and/or video a few seconds after it begins receiving the file from a
server. This technique avoids having to download the entire file (incurring a
potentially long delay) before beginning playout. The contents have to be transmitted
in real-time, which requires a corresponding bandwidth, and low jitter, to ensure
continuous playout of the contents. A guaranteed transmission bandwidth is
appropriately called quality of service.
Two protocols are generally used for the streaming of multimedia contents. One
protocol handles the transmission of multimedia data on the network level and the
other protocol controls the presentation flow (e.g., starting and stopping a video) and
the transmission of meta-data. One good example of a network protocol is the Real-
Time Protocol (RTP), which collaborates with a control protocol, the Real-Time
Streaming Protocol (RTSP). In addition to these popular protocols, there are several
proprietary products, e.g., Progressive Networks Audio (PNA) and Progressive
Networks Metafile (PNM) of RealNetworks, or the Microsoft Media Server (MMS)
protocol.
We can identify two distinct fields of application for multimedia data streaming. First,
making existing contents available on-demand, e.g., video-on-demand, and second,
broadcasting live contents to a large number of users, e.g., Webcasting. Each of
these two use cases poses totally different requirements on the network, and the
hardware and software architectures. While each user establishes his or her own
connection to the server in an on-demand scenario, causing major bandwidth and
server load problems, broadcasting makes especially high demands on the network
level. Examples are given in (Srinivasan et al. 2001) and (Roy et al. 2003). Ideally, a
server used for broadcasting should manage one single media stream, which is
simultaneously broadcasted to all users by the network infrastructure (e.g., by
 14

routers), as visualized in below Figure. However, since multicasting is not supported

generally on the Internet, the server has to use point-to-point connections, similar to
the on-demand scenario, to “simulate” the broadcast functionality.

Figure: Streaming media architecture using point-to-point connections.

Figure: Streaming media architecture using a broadcasting infrastructure.

In order to keep such systems scalable to the desired number of users, it is often
necessary to distribute multimedia data to keep the users’ access paths as short as
possible. This approach forwards a user’s request to the nearest node that holds the
required data. The distribution itself can be based on either a push or a pull
mechanism. The push mechanism won’t transmit the contents to a local node unless
at least one user or a specific number of users requested them. This mechanism is
typically used when there is no information about the spatial distribution of the user
group. In contrast, the pull mechanism transmits the contents by a pre-defined
distribution plan, which means that the media distribution can be optimized with
regard to the transmission medium (e.g., satellite) and the transmission time(e.g.,
overnight). Of course, this type of distribution needs to know the local distribution of
 15

the user group. Building such a distribution infrastructure is very costly and
maintenance-intensive, which is the reason why it is not widely used.

Another unsolved problem is the poor interactivity of media since special browser
plug-ins (e.g., Apple’s QuickTime Player, or Microsoft’s Windows Media Player) are
normally used to visualize multimedia contents, but these plug-ins have no way of
representing links or anchors. An additional problem occurs for time-sensitive media,
such as audio and video, because the contents of an HTML page – text and images
– cannot be synchronized to a medium’s contents. However, languages like SMIL
(Synchronized Multimedia Integration Language) try to overcome this limitation and
thus can be used to specify media interaction features.