8/14/2019 Architecture of Web Applications

1/3

Architecture of web applications

While the Web was originally designed to foster collaboration across distributednetworks, stronger requirements, such as fault-tolerance, scalability, and peak

performance were added later as a result of leveraging the existing communicationmechanisms in the Web to support transaction-based applications.

The building blocks of the architecture have not changed much over time, but the

richness of the solution and the flexibility of the interaction between these blocks arein constant evolution. Software modularization at the program level in the sixties was

extended to client-server architectures in the late seventies and early eighties that,in turn, evolved into the Web architectures of the nineties. For example, the design

of traditional transaction processing engines is based on the decomposition of itsfunctions into isolated modules that communicate with the rest of the solution

through well-defined interfaces. Client-server engines embrace the same principleand provide these functions by means of distributed objects. The architecture of the

solution on the Web still follows the basic decomposition rules, and adds the run-timeidentification and binding of resources. The solution may look on paper similar to a

single-server classical application, but the degree of flexibility in the selection of thecomponents that will actually perform the work forces the designer to build in or

reuse services to integrate the solution.

Mainframes may benefit from economies of scale by centralizing functions that sharecritical resources. The cost of designing an application from scratch is lower when its

components can share design elements. Instead, distributed applications have abetter fit when the designer looks at the overall set of applications in which design

elements are shared among different solutions. In that case, single functions can be

assigned to specialized servers. For example, the need to discover and identifyresources in the application leads to name services, and the need to protect the

application from unwanted users leads to authorization servers and encryptiontechniques. The end result for the user is that the application can be deployed faster

and is more flexible and scalable because individual components can be replicated orscaled according to the needs of the solution.

The Web is an Extension of the Client-Server Paradigm

Software modularization was introduced to reduce the cost of building complex

systems. Instead of having to consider the iterations of each component with all theother components of the solution, modules present a first step in isolating the details

of the implementation of a given function and allowing multiple uses of the samefunction. For example, if input data is validated outside of the application, the

resulting application is simpler to develop. Validation was done initially by the

application, then by separate routines in the program, then using intelligent

peripherals, and later on, on a different server. All these options are a consequenceof a natural evolution towards Web applications.

In the case of data repositories, Web servers can be seen as instantiations of theclient-server paradigm where the Web server delivers multimedia content to clients

such as browsers, applets, and search robots. Content may be stored in the server orbuilt dynamically by the server, either from local data or, most typically, from

application and database servers that feed the data to the Web server. Thatperspective of the Web server focuses on the basic services the Web server has to

8/14/2019 Architecture of Web Applications

2/3

perform: control communications, control the data flow, and ensure the privacy ofthe data if the client requests some form of encryption. Commercial applications

based on a Web-server interface also require the support of a large number ofconcurrent users, the distribution of the Web services to different platforms, some

form of fail-safe operation, performance guarantees in terms of response time orthroughput, and the integration of heterogeneous components. Keeping some form

of state of the transaction in that environment has proven to be a challenge that haslimited the migration to the Web of many simple commercial applications thatotherwise would greatly benefit from the lower cost of operations in the Internet

environment.

Scaling the solution from a few thousand users to hundreds of thousands ofconcurrent users forces one either to change the algorithms used by the application

to maintain the state by, for example, distributing and replicating the services, or insimple cases, to upgrade the platform. Resource replication has the added advantage

of providing extra processing power without bringing down the network andincrementally increasing the resilience of the solution to server downtime.

Replication does not come cost-free. Interfaces have to be standardized, and thecommunication mechanisms must preserve the implicit assumptions made during

system design. For example, error checking ideally should be done for each dataunit, but just once. By duplicating the effort on both ends of the communications

pipe, the solution becomes more expensive without giving any extra benefit to theapplication. Standardization--either formal or de facto--also encompasses among

other things file formats, markup languages, object brokering, networkmanagement, and high-availability protection.

The decomposition of the application into separate and relatively independentmodules also leads to service specialization. The economies of scale from the

mainframe have become economies of specialization: servers are designed so thatthey can accomplish simple tasks and the traditional role of the systems architect is

being complemented by the systems integrator, who may use off-the-shelfcomponents to build a robust solution with relative ease.

From the user's perspective, except for the user interface, there is little or nodifference between this process and the traditional process in which all the steps are

done over the phone. On the other hand, the expectation that the state of the orderwill be kept consistent across the steps of the user interaction is a consequence of

the fact that the user does not have to know what logical services are involved.When a user accesses an electronic commerce site, the context where the user

operates has to be kept consistent. Session is defined as a set of logical transactionswith a consistent context.

In the last example, the user accesses the home page of the Web site to check thecurrent offerings. For some users, the home page may change while they are still online, but there is an expectation that offers remain valid while the older page still can

be retrieved from the cache. Next, the user may browse through the catalog--while

the catalog is being updated--and put some items in the shopping cart, which is amechanism to preserve the state between logical transactions. When the user is

ready to check out, the system validates the credit and shipping information, currentinventory, offers, discounts, and any other information about the context of the user.

Finally, if the user confirms the order, the system executes transactions in other

8/14/2019 Architecture of Web Applications

3/3

systems, such as order processing, supply chain, and marketing statistics. Althougheach transaction can be processed by a different server, sessions have to be

managed by or at least through one Web server. At this time, state preservation,scalability, and high availability are the main concerns in the development of Web

applications. Solutions are being developed in the areas of code portability (forexample, by building Java libraries to support industry-dependent functionality),

efficient queuing mechanisms tied to multithreading schemes to improve thescalability of the application, cookie-less state preservation methodologies, andcaching.

An Evolution-oriented Architecture

for Web ApplicationsAbstract: The Web has become an efficient environment for application delivery. The

originally intended idea, as a distributed system for knowledge-interchange, hasgiven way to organizations offering their products and services using the Web as a

global point of sale. Although the arising possibilities look promising, thedevelopment process remains ad-hoc in real-life Web development. The

understanding of Web application development mostly neglects architecturalapproaches, resulting in Web sites that fail in achieving typical goals like evolvable

and maintainable structures of the information space. Beyond that, as thearchitecture of a Web application matures, more and more knowledge about the

domain becomes embodied into code and therefore burdens maintenance and reuseof parts of the application. In this paper, we will propose an architecture and a

framework using the notion of services as model entities for Web applicationdevelopment. The object-oriented WebComposition Markup Language, which is an

application of the XML, will be presented as basis for a generic evolvable frameworkfor services. Finally, the results of its usage will be described in detail by giving an

example of a large-scale transnational Intranet, where the framework is in use.