FREE MOBILE CLOUD
COMPUTING CONCEPTS - TRAINING_MODULES_WITH_TONS_OF_VIDEOS
thick-fat-client....
Thick Client
Thick clients, also called heavy clients, are full-featured computers
that are connected to a network. Unlike thin clients, which lack hard drives and other features, thick clients are functional whether they are connected to a network
or not.
While a thick client is fully functional without
a network connection, it is only a "client" when it is connected to a server. The server may provide the thick client
with programs and files that are not stored on the local machine's hard drive. It is not uncommon for workplaces to provide
thick clients to their employees. This enables them to access files on a local server or use the computers offline.
When a thick client is disconnected from the network,
it is often referred to as a workstation. ++++++++++++++++++++++++++++++
Why
Thick Clients Are Relevant in Cloud Computing
Return of Thick Clients
Thick Clients Traditionally thick clients have
been used for providing rich user interface functionalities and also for mobile workers who would like to execute functions
without connecting to the network or firewall. The major characteristics are;
Offline Working
Higher Multimedia Requirements
However, enterprises have slowly moved away from thick clients due to the fact that building
business logic and intelligence on fat clients and keeping it updated is a difficult task, as the business rules change more
often than the user interface and multimedia needs and keeping it in sync with several client machines is a daunting task.
The term thick clients can be interchangeably used with ‘fat clients' or ‘rich
clients.'
Cloud and Thick Clients With the concept of
delivering ‘Everything as a Service' and access to information using standardized interfaces, cloud computing opens
the doors for rich thick client applications to be part of application landscape again for specific needs. Some of the features
of cloud computing that support the usage of thick clients again are:
Cloud is here to be consumed not only by traditional multi tiered applications, but more for smart devices, which
are typically thick clients
Standards-based APIsupport
the creation of thick clients using multiple technologies and rendering devices
SaaS-based applications will allow the thick clients to concentrate on rich user interface functionality and rendering
while leaving the business rules with cloud, leaving the maintenance much simpler than earlier.
Users can access both cloud and conventional computing services
Mobility
and offline use. Fast Internet access is still not pervasive. Users can work with locally installed applications even when
offline
Performance and additional capabilities. Users can run graphics
and compute-intensive workloads on the client. Without local execution, this would be slow or impossible.
Popular Thick Clients That Could Emerge Out of Cloud 1. WPF - Windows Presentation Foundation:
As always Microsoft's dominance on the rich client and desktop is reflected in the features and ease of development
of WPF applications
Provides a unified support for:
o Graphical interface, e.g., forms and controls
o
On-screen documents
o Fixed-format documents
CIO, CTO & Developer Resources
o Images
o Video and audio
o Two-dimensional graphics
o Three-dimensional graphics
WPF based clients can access the APIs exposed by Windows Azure and hence can access the business
logic on the Cloud
2. Widget / Gadget Framework:
Windowscontains
mini-programs calledgadgets, which offer information at a glance and provide easy access to frequently used tools. For example,
you can use gadgets to display a picture slide show or view continuously updated headlines.
The Google Desktop APIs let you create gadgets, indexing plug-ins, and more for Google Desktop. You can also integrate
Google Desktop search into your own applications.
Google Gadget APIs can
be used to create Gadgets that can run on multiple smart devices as thick client and yet connect to Cloud to access the enterprise
data
The Gadget APIs can connect to Cloud using the APIs exposed, making
them highly extensible, while providing the flexibility of running it locally
3. Applets / Application Clients In Java EE World:
A web page received from the web tier can include an embedded applet. Anappletis a small client
application written in the Java programming language that executes in the Java virtual machine installed in the web browser.
However, client systems will likely need the Java Plug-in and possibly a security policy file for the applet to
successfully execute in the web browser.
Anapplication clientruns on a
client machine and provides a way for users to handle tasks that require a richer user interface than can be provided by a
markup language. It typically has a graphical user interface (GUI) created from the Swing or the Abstract Window Toolkit (AWT)
API, but a command-line interface is certainly possible.
With the support
of Web Services and SOAP-based APIs as part of Java EE, thick clients in Java EE can connect to Cloud to provide the desired
functionality
Fat clients are back - big time
Back
in the days when I used to develop software (1992-1998), the client-server paradigm for software development ruled. Data was
stored on the server-side and it was, except for server side calculations, manipulated locally on our PC desktops. We interacted
with the data via fat but highly interactive, stable and speedy Windows applications.
When the world wide web arrived
to our desktops, it was sort of implied that web sites would evolve into highly interactive applications run inside of a web
browser. The web was the future, and we assumed that it would mean that we would interact with everything via a web browser.
Yet, the last couple of years we have seen things moving in quite the opposite direction. The client-server paradigm with
fat native clients is back. What is new is that the servers are in a cloud somewhere and can be accessed via web applications
in a web browser as well as via native apps.
Several trends interplay and pave the way for the comeback of fat
clients, such as the following:
Our consumption of rich media such as video, photos and music increases
We store more of our information in the cloud (because we want to be ablet to access it from anywhere)
We want highly interactive, reliable and fast user experiences also when it comes to Internet-based
tools
We are becoming more and more mobile, using mobile devices such
as smartphones and tablets
The capacity of the Internet and broadband
connections, especially mobile have a hard time keeping up with, ever increasing traffic volumes
The bottom line is: we need the broadband for shuffling our content, not
for downloading applications. Besides, it doesn't make much sense to download an application every time we need it, especially
if it's easy to access and install the application locally on a device. App stores make these tasks really easy and nothing
like the messy and error-prone installation procedures we have gotten used to with Microsoft Windows.
The risk of downloading and infecting devices with malicious code also decreases if
it is just content and not applications that is downloaded. No code except maybe for style sheets and content markup would
be downloaded. Security mechanisms, such ad encryption and access rights, can be put the content itself so that it does not
slip away and get into the wrong hands.
Fat clients are back big time, and there is no reason to think they aren't
here to stay.
thin-client
clould client
Thin client computing, centralized
computing, controller based computing, server based computing; there are several names for the particular architecture that
involves a client device exchanging data with a host that minimizes the processing that is required for the client. Although
over the years there have been shifts back and forth from thin client to thick client and back again, the reasons for the
shifts are usually the same.
Clients become thicker with increasing bandwidth and increasing processor power.
Thinner clients as new transmission media decreases bandwidth and portability of devices decreases processing power.
The mainstream reasons for changing architecture involves tradeoffs between bandwidth and processing power but there are
other less obvious but equally important reasons for staying with thin client architecture which involve dedicated data collection
applications in mobile environments. Although IT personnel must continuously consider open systems and flexibility when choosing
an architecture, tradeoffs in performance may occur if other options are not considered.
The needs of data collection clients
Data collection is a highly specialized application where the use of radio frequency (RF) clients increase
the productivity of workers immensely. The RF clients give the data collection worker instant real time access to data, precise
accuracy for input of data and mobility in the wireless LAN. The worker does not need to be a skilled computer user; the applications
are developed for speed, simplicity and minimal key strokes and minimal training. These blue collar workers may be transient,
seasonal or part time workers who need to be productive in a minimal amount of time.
The WMS or Warehouse Management
Systems applications while sophisticated in themselves, have simple user interfaces designed for speed and simplicity. The
WMS application is often the only application that will ever be run on the data collection terminal. While it is the flexibility,
reliability, supportability and programmability that drives the selection criteria of mobile client devices, the mobile data
collection worker usually requires minimal processing power to run the WMS application.
The data collection worker
is driven by the necessary functions in the supply chain logistics management, picking, packing, inventory etc., where innovations
do not evolve at the speed of technology. So while it is seemingly conflicting requirements between the data collection
worker and the IT group which must support them, the WLAN system for data collection must strike a balance which will satisfy
both.
For
data collection, speed is the key
The end user has little concern for how the processing is done, as long
as it is done fast and there is no waiting time.
With thin client computing, the bulk of the processing is not
done at the mobile client, meaning the more powerful controller can do the processing faster.
The client can save
on processor cycles and therefore battery life, simplifying the device management required for end user. The central controller
can optimize the data stream, minimizing data traffic over the RF link , which results in fewer collisions and congestion.
It all adds up to less time spent waiting for the end user, meaning they can be more productive and less frustrated.
Routine things for office workers have
more complications for mobile workers. It is normal for an office worker to turn on their computer and log into the network
and start their applications once a day. The mobile data collection worker may have their mobile device powered down several
times a shift for a variety of reasons, each break or lunch period, to change batteries, or the mobile device will power down
itself to conserve battery life.
Each time the device is powered down the login and application start process
will have to be repeated. This causes undo delays and frustrations for the mobile worker which could be avoided with a controller
based architecture. In a controller based system the host session is held open by the controller independent of what the mobile
device does.
Even if the mobile device is restarted, the controller will present the user with the last screen
that they were working on, they resume working where they left off. While thick client devices can be programmed to automate
the login process, a change in login, host name or address or application requires all of mobile devices to have to be reprogrammed
again, which can be a large and time consuming task if there are more than a handful of mobile client devices. In a thin client
situation, the change is made at the controller and all the thin client devices are instantly updated.
The issue alone of simplifying the login procedure can increase
the productivity of a data collection worker by reducing the waiting time and frustration that is encountered. The speed and
reliability of a controller based thin client architecture gives the data collection worker more comfort and confidence to
make productive use of the mobile device.
For IT, supportability is the key
Speed is less of an issue for those
that must support the system. How flexible, reliable and easily programmable a system is can be lumped into how easily the
system can be supported. In a data collection environment, there could be hundreds of devices to support, so it is very easy
to conclude that the simpler the client devices are, the easier they would be to support. Maintaining several thin client
devices from a central point reduces actual support time and effort, scheduled down time and actual productivity of the operation.
Flexibility
Flexibility in a wireless LAN is how easily the system will adapt to changes.
In a centralized
system, any changes made at the controller affect all the client devices or groups of devices. In an automated login procedure,
should the host name or address change, the central change made on the controller will redirect all the mobile clients in
one simple step. This compares to reprogramming each individual client device. Network management systems may offer
centralized programming features but this does not eliminate the fact that each device must be reprogrammed and tested to
ensure that the change actually took place.
Centralized key mapping is another functionality that can be instantly rolled out to all
attached clients. If a change in a process or program causes a different keystroke from the data collection terminal, the
change can be made at the controller without reprogramming the individual client devices.
Often applications are developed for stationary nodes and
then moved out to mobile devices for data collection applications. The data collection clients will have smaller screen sizes,
making the application screens impossible to read on the mobile devices. Controller based computing offers the ability to
optimize the screen size at the controller without changes to the host application. The fields and screens can be reduced
in size and content to present the user with a simpler screen that fits perfectly onto the mobile unit. Redundant or unnecessary
screens can be skipped altogether. This greatly reduces time and effort spent changing the application program to suit the
mobile system and simplifies the user interface.
Reliability
Centralized or controller based architecture
is often faulted for having a single point of failure for the entire system. Modern systems however take reliability into
account and employ controller redundancy to reduce the risk of failure. Controller based systems can in fact be scaled to
meet system size requirements and with added redundancy, can make extremely reliable and high performance systems. Most data
collection systems that initially promote controllerless architecture, will recommend a controller for large or complex systems,
to increase performance and reliability.
For smaller systems, less powerful controllers or mini-controllers can
be used to increase the scale of economy without compromising on reliability and performance.
For every system, wired or wireless, thick or thin client,
there will be a time when problems will occur. Data collection systems are mostly located at warehouse or manufacturing sites,
remote from the enterprise head office, and therefore remote from the enterprise IT support group. The isolation of the data
collection system makes the job of supporting it more of a challenge than the local LAN. With a centralized controller based
system, the possibility of isolation and diagnosis of the problem is far greater than a decentralized thick client system.
The controller gives remote support access to the system, browser based or dial-in connections allow diagnostics designed
for the wireless LAN to be run and logged for real time or post event analysis. Thick client wireless systems are not well
suited to remote support due to the added complexity that a wireless system has over a wired system. General purpose diagnostics
tools for wired LANs may not be powerful enough for wireless LANs. More independent components in the system mean more difficulty
isolating and troubleshooting the problem.
For remote wireless systems, a central controller provides a more reliable and maintainable architecture. The single
point of failure can be eliminated with a redundant controller and the controller becomes a central reference point for isolation
and diagnosis of system problems. Access to the system is now possible by allowing remote access to the system.
Programmability
Centralized computing means the majority of the processing is done on the host system. Any changes
to the business may require a change to the WMS application and rolling out changes to mobile clients in a centralized system
is accomplished instantly. Making changes to a thick client system may require downloading modified applications to hundreds
mobile devices, scheduling downtime or off hours work to accomplish change. The most efficient data collection systems run
in real time, on wireless LAN networks. Thick client applications that run in real time are often the result of batch systems
being converted to real time systems.
These applications do not take full advantage of the real time wireless
architecture that allows for centralized computing.
Summary
Although the available bandwidth and processing
power for mobile client devices continues to grow, making development of thick client applications possible, reasons such
a speed, stability and reliability make a centralized thin client architecture more attractive. The network controller provides
the central point of control and connectivity to the distributed mobile system making remote problem isolation possible. Flexibility
and maintenance are more easily accomplished when a central point of control is available. Because data collection systems
have characteristics such as remote physical locations and fast transaction rates, they are different from common enterprise
networks. Centralized controller based wireless systems designed for data collection will outperform a general purpose wireless
systems for both speed and simplicity for the end user and maintenance and for the support group.
