Using empty client knowledge to enhance debugging practices

Understanding the differences between thick client, thin client and empty client server usage can improve your software debugging practices, says an expert. By applying a background understanding of empty client Web platform usage testers and developers can better gauge application communication needs.

This Content Component encountered an error
This Content Component encountered an error

In recent months, there has been increasing discussion about a new trend called Empty Client, which was initially promoted as a security benefit for cloud computing. A closer look may help us understand how the concept could help our debugging issues. Despite how far we've come with technological development, it seems that we have quite a distance to travel. But that may change soon. Empty Client is an emerging open source methodology,...

which offers a different approach to architecting, developing and deploying AJAX applications, and could provide a single level debugging solution. If you want to compare it to other methods or paradigms today, it is easiest to explain that Empty Client offers a new balance between the Thin and Thick Client approaches, and a new channeling of the AJAX calls.

The Thin Client model communicates with a central processing server, which means that there is little hardware and software installed on the user's machine. This allows all end users' systems to be centrally managed with software deployed on a central server location, as opposed to being installed on each individual system. This is usually used in places where it would create a major headache for IT to deploy and maintain so many user stations. In contrast, a Thick Client will provide users with more features, graphics and choices, thereby expanding the opportunities to enhance the applications.

Unlike Thin Clients, Thick Clients do not rely much on a central processing server because most of the processing is done locally on the user system, and the server is accessed primarily for storage and data retrievals purposes. For that reason, Thick Clients often are not well-suited for public environments. For the Thick Client method, IT needs to maintain all systems for software deployment and upgrades, rather than just maintaining the applications on the server. Additionally, Thick Clients often require operating specific plug-ins, again creating more work and limitations for deployment. The trade-off is a more robust and local computing environment.

The Empty Client approach promises to offer solutions for both the Web and cloud, serving both the desktop and Web environments (or Thick and Thin Client approaches), and enhancing them with AJAX. With the Empty Client approach, an optimized protocol generates and extends server side power, typically achieved with Thin Client, and make it available for data centric, customizable and scalable Web applications, typically achieved with Thick Client. Furthermore, the Empty Client leverages the client's processing power to render the UI and to activate any of the server's instructions.

The Empty Client uses asynchronous refreshes, and a JavaScript-based engine to communicate with the server. Instead of communicating at the component level in a scattered way, it communicates the incremental updates, asynchronously through one central pipeline. What this means is that rather than open numerous routes to the server, it channels all communication through its centrally controlled pipeline. Essentially, Empty Client relies on AJAX but does all the plumbing under the hood.

Empty Client also achieves the highest scalability and performance that, in the past, was enabled only with the Thick Client approach. It is called the Empty Client because it doesn't run any logic or data manipulation on the client, it doesn't expose data or logic, nor does it require exposing Web services consumed by the client, which is a non-secured very common practice on traditional AJAX development methods.

With this approach, the UI control's process is an integral part of the control just like a single layered desktop control, only divided into the control rendering part (on the client) and the control's logic part (on the server). It executes on top of traditional and standard Web platforms and creates the feeling of a native client side application that usually run as Thick or Fat Client only with a Thin Client footprint.

The Empty Client differs from the Thin Client also because it runs on any plain browser with no plug-ins, and it does not transfer bitmaps. This way, the Empty Client is really offering the best of both worlds by allowing central computing with the strong processing power that clients typically have today.

How does the Empty Client approach work?

The Empty Client approach allows the application to be developed and run on the server, and its user interface is "projected" onto the client. A unique algorithm is charged with the task of transferring user interactions and application responses back to the client. While other frameworks utilize AJAX to enhance scattered parts of the applications (like individual controls), the Empty Client approach seeks AJAX to accomplish one specific need: acting as its main pipeline to the server. This explains why it is so secure, why there is no need to code AJAX, and why there is a very speedy performance regardless of the size or the amount of data that is processed and presented by the application. All one actually has on the client is a small JavaScript kernel that is responsible for UI drawing on the browser (creating standard HTMLs), receiving the user interaction and sending it back to the server. This interaction passed by the client cannot instruct the server or change the application's behavior since the entire logic is executed and validated exclusively by the server. With this approach, security hazards are completely removed as there is "nothing" on the client to hack into or manipulate to get access into the server.

Non-Empty Client Web debugging and testing experience vs. Empty Client

Traditional Web debugging requires:

  • Server code debugging (using Visual Studio)
  • Client-server communications debugging figures 1-2 using Visual Studio and client development tools
  • Client scripting language debugging figures 1-3 using client development tools
  • HTML and CSS actual rendering figure 3 using client development tools

With Empty Client, development is done in a WYSIWYG designer and object oriented code and debugging is straight forward:

Where do we go from here?

Many developers probably constantly struggle with the current complexities of Web development and debugging methods as I did. But I realized that I'd rather find the right abstraction in order to be able concentrate on what really matters, which is being able to develop, debug and test my customer's applications efficiently. Being able to do that actually means leaving almost no place for guesses and false debugging related mistakes.

The history of software development has shown us that we can do better and we can do simpler. Empty Client is still in its infancy, and may not be the end all solution. As with every new technological trend, there are the positives and negatives – and we still have to figure out all the aspects of Empty Client. But for those who are tired of the debugging complexities we face, it may be an option worth further exploration.

This was first published in January 2010

Dig deeper on Software Configuration and Change Management

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSOA

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close