Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS Current Architectures Server+client Fusion: An Architectural Proposal

Over the past decade, Web applications have evolved from static HTML pages, to Dynamic HTML pages, to applets and Flash, and, finally, to Ajax technologies. Ajax systems will play an ever increasingly important role in future as the proliferation of complex Web Applications into our daily lives continues. In general, there are two factors significant driving forces driving behind the evolution of web application technologies:

• The desire of developers to create complex web applications quickly and efficiently.
• As applications are moved to the cloud, demand for intuitive and responsive desktop-like web application experiences increases.

The combination of productivity, complexity, and responsiveness is not necessarily easy to achieve and some sacrifices have to be made at times. However, with the turn of the decade comes a new architectural proposal -- Server+client Fusion architecture.

Current Architectures

The two architectures employed today are the server-centric architecture and client-centric architecture.

The server-centric approach dictates that code is written and executed on the server. Server-centric implementations include Oracle ADF, RichFaces, and ZK 3. Server and client engines handle Ajax calls and client and server-side component trees transparently. Client engines will also take care of browser rendering. demonstrates a typical implementation of server-centric architecture.

Figure 1: Server-centric architecture

This approach provides developers with numerous benefits, including:

• Writing server-based code is more secure than client-based code as the business logic is not exposed client-side
• Server-centric architectures tend to be more productive as they allow direct access to server resources such as databases and there is no need to implement complex client/server communication
• Server-centric systems implemented using frameworks tend to be much easier to maintain as there is only one code-base

However, the server-centric approach does have its drawbacks, such as:

• Lack of client-side control
• Server-centric solutions are not suitable for building applications such as action orientated online games

The client-centric approach is centered on writing code for the client, in the web's case a browser which will interact with server-based applications. Figure 2 demonstrates a typical client-centric implementation. In this implementation there are two applications, one at the client (browser) and one at the server. The browser also, under normal circumstances, contains an Ajax and widget engine powered by snippet frameworks such as jQuery and/or UI frameworks such as ExtJS and GWT.

Figure 2: Client-centric architecture

The client-centric approach does provide developers with some benefits:

• Complete client-side control
• When dealing with client-based interactions client-centric solutions are very responsive
• Easy integration with existing web sites
• Can use in conjunction with any server side technology such as PHP and ASP.NET

However, there are disadvantages to this approach, one being the need for two applications as demonstrated in Figure 2. Other disadvantages include:

• Higher security risks, for example exposure of business logic at the client
• Need to implement complex client/server interaction to access the server's resources
• Client footprints of enterprise applications tend to be large regardless of the framework
• Code is duplicated at the client and server, therefore harder to develop and maintain
• Developers need to be familiar with multiple technologies, such as JavaScript and PHP

To understand what future developers require from a framework we have to drill down into the weaknesses of both the server-centric and client-centric architectures and what they mean to developers.

Enterprise Architectural Concerns

Enterprise applications tend to be complex, demanding high levels of security and requiring a large amount of data access. These demands generally push architectures and frameworks to the limits.

The client-centric architecture is one that provides additional complexity to application development. There are two applications needed, one that runs on the server and one that runs on the client. Building a communication layer that is reliable and provides optimum performance can cause problems for developers and lead to complex, hard to maintain code.

This custom communication also serves up another big problem. Communication needs a tunnel from the client to the server opening up security issues. In most cases the tunnel is used by application traffic, however, this tunnel can be hijacked by hackers in an attempt to break into the system. These tunnels are notoriously insecure as they are not the result of many years of development and testing.

Due to the client being the focus of the application, the term "fat-client" is appropriate. Fat-client architectures are usually harder to maintain and do expose business logic which for most enterprises is unacceptable. In addition, if this business logic is heavy and there is a lot of action at the client, the load can be too much causing it to become unresponsive and in some cases exit ungracefully.

The main disadvantages of the client-centric approach revolve around security concerns and the lack of productivity. This is where server-centric solutions shine. However, we need to analyze the issues when implementing server-centric architectures.

While the server-centric approach can be especially secure and offer excellent productivity it does tend to lack full client-side control. This means that the developer isn't able to leverage client capabilities. When implementing applications using server-centric there can be granularity issues. Granularity is concerned with the amount of request cycles which are completed between the client and server. Too many and your application is not responsive, too few and they do not provide a rich, interactive experience. However, these issues are highly dependent on the implementation of the framework and application in question.

1 Current Architectures | 2 Server+client Fusion: An Architectural Proposal Next Page

RELATED ARTICLES Examining Wolfram Workbench 2.0 'Apps for Inclusion' Challenge Announced Microsoft's Chuck Thacker Receives Turing Award Book Review: Learning Python, Fourth Edition Other Voices: DevOps -- Why Now?		TOP 5 ARTICLES No Top Articles.