Channels ▼
RSS

JVM Languages

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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Comments:

Video