63

CHAPTER 5

DYNAMICALLY ADAPTIVE ARCHITECTURE FOR

WEB BASED APPLICATIONS

5.1. INTRODUCTION

Recently, web services have emerged to be a paradigm for business organizations

and associations reported by Bekele et.al (2011). A workflow is employed for
supporting workflow management systems for the purpose of business execution. It is
chiefly focused on merging the web services into aggregate services. The modeling and
control of the execution of sophisticated application processes are the important goals of
workflow management in business organization. The syntax of the workflow system is
utilized for smoothly running the business and many organizations are applying the
workflow language in workflow system for various segments of the business plan
explained by Preist (2004).

The language, which is used in workflow management systems are known as

business process management (BPM). The best instances for workflow languages are
Web Services Business Process Execution Language (WS-BPEL), and another
Workflow Language (YAWL) that are employed in workflow management systems for
running the business in a smooth manner. Workflow language is largely utilized for
high level system operations for instance copying files, moving task etc. Workflow
could be a set of consecutive task. The task might sometimes be divided to services.

5.2 PRINCIPLES OF OPERATION

The web is getting utilized for applications containing considerable business

logic complexity and have significant user interface requirements proposed by
Fraternali (2002). The ad hoc improvements that have rendered the web application
software to be a possibility (like CGI and JavaScript) have generated an application
support infrastructure, which caters the application software upgrades and maintenance
to be very complex. Moreover, the web offers especially a poor support for complicated
user interfaces explained by Kristensen (2002).
 64

A huge difference between this architecture and the architectures, which are
based on MVC is the absence of a direct interface between the view (user interface) and
controller modules. The components of MVC will be used, though not the pattern itself.
Now the controller acts as a mediator for every interaction between the view and model
modules. Another important characteristic of this architecture is the disintegration of the
controller (the central processing layer) into elements. What is necessary for the
architecture is the association between the user-interfacing units (the view components)
and the central-processing units (the sub controllers).

Every central-processing unit is responsible for the management of one or more

user-interfacing units, and every user-interfacing unit interfaces to just one central-
processing unit reported by Stacey et.al (2004). One central processing unit along with
its managed user-interfacing units carries out a single task working as a team.
The different teams constitute the application on the whole. These teams can only
interact by means of the central processing layer. Therefore the control logic of the
overall application is observed in the interrelationship between the central processing
units. In this manner, the user-interfacing units are not merged with central-processing
units, limiting the scope of the design, realization and maintenance of any component
suggested by Zhao et.al (2002).

One more advantage is that the presentation logic can be entirely isolated from
application logic and business logic explained by Zeng et.al (2007). Owing to the
execution demarcation, the user-interfacing layer in a current web-based application is
not monolithic. The layer would be as a set of web pages, every one of which can carry
out just a small part of the task. Then the application has to be divided into several
steps. Unluckily, the burdens associated with HTTP result in complexity of the user-
interfacing layer. This is due to the fact that the simplest interaction (even with
continuous connections) needs a whole page update from the server in case the user
wants to be provided with the immediate feedback needed, just after a submit method is
run. There are different means of avoiding or abstracting these shortcomings.

The first one is to make use of a framed page. Here, though the updates are
conducted often, many frames stay in position. Another technique is the simulation of
frames employing active pages on the basis of templates. Here, the user observes the
 65

update done on the pages though only tiny bits of the page are changed at every update.
But the complexity involved in the application development environment stays for both
these choices explained by Kirda (2007). A third method of dealing with the execution
segmentation is to make use of HTTP to be a part of an event-based interaction between
the client and server. In this condition, elaborate interaction with the user can be
managed with more efficiency with no full update of the page each time. This idea
offers the subject of the section that follows.

5.2.1 Workflow

Self-adaptive systems, which change their functional behavior during the time of
execution, render a required a degree of flexibility. Web applications are generally open
systems that adapt according to dynamically changing user requirements. The idea of
self-adaptation is significant in these software systems. It is a review of a Web application
architecture shown in Fig 5.1 that yields the baseline infrastructure for the on-the-fly
modification of the application characteristics. A Web browser is utilized on the client side.
It uses the HTTP protocol for sending requests to the Web server. Every request calls the
server-side programs for implementing the application features that are written in PHP.
A simple instance of such HTTP protocol is http://.../list.php?action=items.

Once such an HTTP request is received, the respective PHP program file
referred to aslist.php is loaded and executed. The application programs may then access
the persistent data stored in databases like MySQL and create an HTML document to be
a value in the HTTP-response. The HTML document shows on a Web browser in
graphical form for the client’s manipulation Gustavo et al (2004). Most of the Web
applications need different sequential HTTP requests for providing a non-trivial service.
Electronic commerce sites (EC-sites) are the specific applications, which depend on the
long-term transaction.

The HTTP protocol has no state and the called PHP program gets initialized at
every HTTP request. All of the execution states are lost once the HTTP-response is
generated. Implementation of a long-term transaction needs a piece of information to be
provided to the next HTTP requests. Two types of data are brought into use for these
purposes, Cookies, chunks of data that identify the user sessions offered by the Web
server, and few application specific data that are stored explicitly in database. These
 66

pieces of information along with the HTML document comprise the global state of a
long-term transaction with consecutive HTTP requests. A huge program is segmented
into different PHP program files in a modular manner.

Fig 5.1 PHP-based Web Application Architecture

PHP language yields a primitive requirement for programmers for specifying the
on-demand loading of a program file in an explicit manner.

require <file name>

where <file_name> is typically a String constant. However, the primitive require, can
also take an expression, particular a function call, in the form of its argument.

require function name (parameters)

The function may output a String data for the representation of a file name after
some calculation is done by making use of the parameters given. As small computation
is necessary, the result could be changed at every call. The method renders it possible to
change the PHP source file that has to be loaded dynamically at runtime. Moreover, the
function is written such as to utilize an indirect mapping table for finding the suitable
files to be loaded. Such a table is realized in the form of an entry saved in the persistent
 67

data storage. Few model information like Component-level feature diagram is in place
to get included in PHP-based Web application architecture in case it is translated into
mapping table.

Three Steps for Self-Adaptation defines the architecture proposed of PHP based
self-adaptive application systems. It follows the concepts of the three component
approach of Monitor, Diagnoser, and Reconfigurator, similar to the Monitor-Analysis
Planning-Execution loop. Monitor tracks the event traces for generating the flow of
system execution. The traces contain low level of information gathered from program
execution. Diagnoser, in turn, uses the filtered and normalized pieces of information
generated by the Monitor, and discovers the root causes. The process can be used for the
identification of violation at a concept level by exploiting the execution traces of the
low level program. Reconfiguration does the planning and modifies the program
components in order to compensate for actions responding to the violation.

In Fig 5.2, Event Generator modifies the low level information similar to
program execution steps to sequential filtered events. A PHP application program
begins its execution once a HTTP request is received from Web browser explained by
Ovanovic et.al (2006). Its external behavior is observed with coarse-grained execution
steps, and it is not required to adhere to the program by going through each statement.
The PHP program does the exchange of the following types of information with the
external or execution environment where it executes. 1) Input data sent in the HTTP-
request, 2) Persistent data saved in the DB, 3) Graphical view data in the HTML
document generated.

The program states that change when the program is getting executed are
temporary. They are lost once the program is terminated after the creation of an HTTP-
response. They have no impact on the behavior of PHP programs initialized with the
next consecutive HTTP requests. It is considered that the Web application behavior is
defined in terms of the monitoring points that are mentioned above. Monitor Automaton
in Fig 5.2 is a typical finite-state transition system that has the responsibility for
performing the role of Diagnoser. It is well-known that regular language is sufficient to
acquire the pieces of behavior produced by Web page transitions suggested by Olender
et.al (1990) and the sequences of invocation reported by Ricca et.al (2001) also.
 68

Fig 5.2 Self-adaptive Architecture

Every monitoring point is associated with a transition of Web pages or the

invocation of a PHP function. Regular language can truly help in expressing the
significant aspects of the behavior. Every monitor automaton is described to be a
subclass of an abstract class Automaton. Among the methods defined by Automation,
transit (alpha: string) method realizes on how the automation performs its state
transition. It is defined to be subclass-responsibility, and every subclass must yield a
concrete transit method Bekele et al (2011). Reasoner is implemented from
Reconfiguration to use the model information for selecting the suitable PHP program
files. Reasoner produces the contents of the mapping table at runtime by making use of
the model information. Fig 5.3 describes the control- and data-flow in the Monitor and
Diagnose portion of the architecture elaborately
 69

Fig 5.3 Three Steps Framework

It makes modifications to the runtime monitoring framework in order to include

Reasoner explained by Nakajima (2010). At first, during the loading of Event Handler,
it accesses the persistent storage to obtain the pieces of information presented on the
internal states of the automata discussed in Gellersen et.al (1999) and Schwabe et.al
(1998). Web application comprises of many Web pages, called by sequential HTTP
requests. The entire behavior of a Web application needs the inclusion of pieces of
information in the sequential Web pages that are invoked.

Monitor automata must be rendered persistent as they continue to exist even

after the exit of a Web page. Every persistent data are required to be kept as small as
possible as the size of the data impacts the execution performance. These data are
serialized in order to be stored in MySQL DB, and then deserialize while they are again
loaded onto the memory space. The information of automata that has to be rendered
persistent is only an identifier for representing their internal states. Such kind of an
identifier could be very small, and can be supposed that it will not degrading the
execution performance.

Second, Event Generator transmits an event to Event Handler, and it then

deputes the event to a group of Automaton instances. Usually, a Web application shall
be monitored from not just one viewpoint, but more. One automaton is brought into use
for checking a specific aspect so as to describe an automaton in a simple manner.
 70

Therefore, a set of automata have to observe one event at a time, implying that the
events are broadcasted to more than one number of automaton. Every automaton has to
make a check if the incoming event is efficient enough in modifying its own states, but
neglects the one, which is not capable of doing any transition. An event such as this can be
supposed that it disappears, which in turn, implies it to be implicitly consumed. As it attains
one pre-determined final states, Automaton requests the Reasoner to conduct a check over
itself to look for the execution points in the program to get itself to the final state.

Every Automaton has the responsibility for the monitoring of a specific aspect,
and Reasoner, in turn, can get all the information required for the identification of the
causes. The source codes of Automaton subclass have to get replaced at the time of
execution that can be realized by the mapping table strategy employed by Reasoner.

5.2.2 Dedicated controller layer

In the MVVM model there is no separate controller layer, therefore it is assumed

the MVVM also takes the role of the controller. It has the responsibility for implementing
whatever happens if a button is clicked, and choosing the new view to display.

5.3 WEB SERVER ASSUMPTION

The first Web sites, developed by Tim Berners-Lee while at CERN (the European
Laboratory for Particle Physics), created distributed hypermedia system, which
facilitated the researchers to access the documents and information, which are published
by fellow researchers, direct from their computers as defined by Conallen (2003).
Documents were accessed and observed with a piece of software known as a browser, a
software application, which executes on a client computer. The user can make request
for documents from other computers on the network with a browser and provide those
documents on the display of the user.

In order to view a document, the user must open the browser and submit the
name of the document and the name of the host computer in which it can be found.
The browser then sends a request to the host computer for the document. The request is
taken care by a software application known as a Web server, an application generally
that can run as a service, or a daemon, which does the monitoring of the network
activity on a specific port, typically port 80. The browser sends a specifically formatted
 71

request for a document (Web page) to the Web server via this network port. The Web
server, on receipt of the request, finds the document on its local file system, and then
returns it back to the browser; illustrated in Fig 5.4.

Fig 5.4 Basic web system

This web system is a hypermedia system as the resources in the system are
connected with one another. The terminology of web springs from observing at the
system to be a set of nodes with interconnected links. Seen from one view, it is seen as a
spider’s web. The links render a way for navigating through the resources of the system.
Many of the links connect the textual documents, though the system could be employed
for distributing audio, video, and custom data also. Links render the navigation to other
documents to be easy. The user just clicks a link in the document, and then the browser
considers that to be a request for loading the referenced document or resource in its place.

Browsers and Web servers make use of a specific protocol, referred to as the
Hyper Text Transfer Protocol (HTTP) that indicates the way in which a browser must
format and convey a request to a Web server. The client browser then sends a document
request comprising of a line of characters ended by a CR/LF (carriage return/line-feed)
pair. A server that is well-behaved will not need the carriage return character.
This request contains the word GET, a space, and the location of the document
corresponding to the root of the Web server’s file system. During the configuration of
Web server/site, it is generally set up to make use of a certain directory on the host
machine’s local file system to be the root directory of the Web site. Documents get
associated with this directory.
 72

5.4 SUMMARY

Web-based tab system has managed many numbers of thousands of transactions

with no errors, providing flexibility to the tabbing staff. Deployment of technologies
like the ORM into the model layer is done, the potential object-oriented programming is
used and then is combined with the flexibility, reliability, and scalability of SQL
databases. PHP allows us to rapidly design reliable modular applications and carry out
the simplification of the code design by utilizing lists and dictionaries in the form of
inputs. At last, making use of REST and Ajax, the lightweight Web services is designed
such that the third parties can conveniently interface with, facilitating rich, interactive
Web front ends.