Architecture Of Web Applications

Architecture of web applications While the Web was originally designed to foster collaboration across distributed networks, stronger requirements, such as fault-tolerance, scalability, and peak performance were added later as a result of leveraging the existing communication mechanisms 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 are in 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 its functions into isolated modules that communicate with the rest of the solution through well-defined interfaces. Client-server engines embrace the same principle and 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-time identification 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 the components 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 share critical resources. The cost of designing an application from scratch is lower when its components can share design elements. Instead, distributed applications have a better 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 identify resources in the application leads to name services, and the need to protect the application from unwanted users leads to authorization servers and encryption techniques. 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 or scaled 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 the other 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 same function. 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 consequence of a natural evolution towards Web applications. In the case of data repositories, Web servers can be seen as instantiations of the client-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 or built dynamically by the server, either from local data or, most typically, from application and database servers that feed the data to the Web server. That perspective of the Web server focuses on the basic services the Web server has to

perform: control communications, control the data flow, and ensure the privacy of the 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 of concurrent users, the distribution of the Web services to different platforms, some form of fail-safe operation, performance guarantees in terms of response time or throughput, and the integration of heterogeneous components. Keeping some form of state of the transaction in that environment has proven to be a challenge that has limited the migration to the Web of many simple commercial applications that otherwise 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 of concurrent 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 in simple cases, to upgrade the platform. Resource replication has the added advantage of providing extra processing power without bringing down the network and incrementally increasing the resilience of the solution to server downtime. Replication does not come cost-free. Interfaces have to be standardized, and the communication mechanisms must preserve the implicit assumptions made during system design. For example, error checking ideally should be done for each data unit, 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 the application. Standardization--either formal or de facto--also encompasses among other things file formats, markup languages, object brokering, network management, and high-availability protection. The decomposition of the application into separate and relatively independent modules also leads to service specialization. The economies of scale from the mainframe have become economies of specialization: servers are designed so that they can accomplish simple tasks and the traditional role of the systems architect is being complemented by the systems integrator, who may use off-the-shelf components to build a robust solution with relative ease. From the user's perspective, except for the user interface, there is little or no difference 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 order will 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 transactions with a consistent context. In the last example, the user accesses the home page of the Web site to check the current offerings. For some users, the home page may change while they are still on line, 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 a mechanism to preserve the state between logical transactions. When the user is ready to check out, the system validates the credit and shipping information, current inventory, 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

systems, such as order processing, supply chain, and marketing statistics. Although each 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 (for example, by building Java libraries to support industry-dependent functionality), efficient queuing mechanisms tied to multithreading schemes to improve the scalability of the application, cookie-less state preservation methodologies, and caching. An Evolution-oriented Architecture for Web Applications Abstract: The Web has become an efficient environment for application delivery. The originally intended idea, as a distributed system for knowledge-interchange, has given way to organizations offering their products and services using the Web as a global point of sale. Although the arising possibilities look promising, the development process remains ad-hoc in real-life Web development. The understanding of Web application development mostly neglects architectural approaches, resulting in Web sites that fail in achieving typical goals like evolvable and maintainable structures of the information space. Beyond that, as the architecture of a Web application matures, more and more knowledge about the domain becomes embodied into code and therefore burdens maintenance and reuse of 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 application development. The object-oriented WebComposition Markup Language, which is an application of the XML, will be presented as basis for a generic evolvable framework for 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.