Introduction
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 (1).
There are two factors significant driving forces driving behind the evolution of web application technologies. First is the desire of developers to create complex web applications quickly and efficiently. Secondly, as applications are moved to the cloud, demand for intuitive and responsive desktop-like web application experiences increases (2).
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 proposal allowing developers and users to realize their dreams, Server+client Fusion architecture.
Before we discuss what Server+client Fusion architecture is and what it provides let’s first discuss current architectures.
Current architectures
The two architectures employed today are the server-centric architecture and client-centric architecture. Let’s begin by discussing the server-centric architecture.
Server-centric
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 (3).
Figure 1. Server-centric architecture
This gives numerous benefits to the developer such as:
- 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, these are:
- Lack of client-side control
- Server-centric solutions are not suitable for building applications such as action orientated online games
We will discuss what these disadvantages mean to the developer later in the article, but first let us investigate client-centric architecture.
Client-centric
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 (4).
Figure 2. Client-centric architecture
The client-centric approach does provide developers with the following 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 very complex, demanding high levels of security and requiring a large amount of data access. These demands generally push architectures and frameworks to the limits. Let us investigate the problems with implementing enterprise applications using a client-centric architecture.
Client-centric
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 (5). 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 very 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.
Server-centric
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 which we will be discussed in depth along with Server+client Fusion in the next section.
Server+client Fusion: A new architectural proposal
The solution sounds easy. To obtain the benefits of both architectures why not combine them? While this is an easy statement to make it is not as easy to implement. To make the union work a lot of technologies need to be integrated. For example most people do not just start writing JavaScript at the client. Many use a snippet framework such as jQuery (2).
For a developer wanting to combine snippet frameworks such as jQuery and larger frameworks this can cause integration problems. Therefore it is best for one package to provide the Server+client Fusion architecture out of the box.
This is where Server+client Fusion steps up to the plate. The concept was first introduced by ZK 5, which is a Java based AJAX framework. ZK’s mantra is that it is B!B’developer-centricB!B( as it provides the developers the ability to create their applications quickly using Server-centric architecture then optimize them using client-side constructs. This is demonstrated by Figure 3. Server+client Fusion.
Figure 3. Server+client Fusion
Advantages of Implementation
There are two advantages to this approach:
- Provides all the advantages of server-centric and client-centric approaches
- Provides none of the disadvantages
Server+client Fusion provides developers and architects with a choice of implementation. A good framework architecture is flexible empowering developers and architects to implement their applications in a smart and elegant manner.
Real-world use
In most real world situations you will want to build the initial application quickly and effectively using server-centric technology, and then introduce client-side optimizations. This is where ZK’s Server+client Fusion architecture comes in to its own. For example, when implementing auto-completion functionality, you can preload data improving response time.
Normally productivity and optimization using client-side techniques do not go hand in hand due to Granularity issues. However, ZK has an excellent base which takes care of server-centric granularity issues by applying a batch processing model to deal with emergent and deferrable requests. With Server+client Fusion, developers now have a choice to further optimize the granularity based on an application’s requirements.
Conclusion
In conclusion, Server+client Fusion will aid in the development of large scale web applications which are now coming to the fore due to the advent of cloud computing. Cloud computing is driving a trend for more innovation in web development with the goal to produce web applications in the quickest and most efficient manner possible.
Creating enterprise web applications rapidly and efficiently is getting harder and harder as requirements get more complex. For example 5 to 10 years ago there was no need to have Word and Excel style web applications. Now the trend is moving towards ever increasingly complex applications being moved to the cloud.
Works Cited
- Staten, James, et al. Is Cloud Computing Ready For The Enterprise? March 7, 2008.
- Linthicum, David. Cloud Computing and SOA Convergence in Your Enterprise: A Step-by-Step Guide . s.l. : Addison-Wesley Professional, 2009. 978-0136009221.
- Chen, Henri and Cheng, Robbie. ZK: AJAX without the Javascript Framework. s.l. : Apress, 2007. 978-1590599013.
- Cheng, Robbie. How to Choose an RIA Solution. AJAX World. [Online] December 30, 2008. http://AJAX.sys-con.com/node/781133.
- Gupta, Vipul. Accelerated GWT: Building Enterprise Google Web Toolkit Applications. s.l. : Apress, 2008. B001PBEW34.