How Thin Clients and Desktop Apps Work

With the release of BBj 19.20, BBj offers a new alternative to Java’s deprecated Web Start remote deployment solution: Desktop Apps. This approach is now essentially identical to the standard BBj “thin client” execution, where the client computer requests and receives individual class downloads from the BBjServices server. This “on demand” downloading includes server-side caching and optimization code that learns which classes clients frequently request together, and then optimizes future class downloads by delivering the needed classes in groups rather than in individual request/response pairs. This decreases the number of client-to-server round trips and the corresponding latency delays. In contrast to standard thin client execution, though, the Enterprise Manager lets you configure your Desktop Apps to use a specific Java Runtime Engine (JRE), which it will also download from the server as needed. Because of all of these interactions, the delay in starting a Desktop App on the first client in the enterprise for the very first time will be longer than subsequent executions. This is true for any client in the enterprise. Read on for more details.

BBj’s Thin Client Class Downloading

A new installation of BBjServices does not know what classes and resources an application might need on a remote client in order to run. The very first time a thin client application (including a Desktop App) is launched against a BBjServices installation (running on any client connected to that server), that startup will trigger the download of any BBj classes it needs to run.  Although this delay can be noticeable, it should not be excessively long unless the network bandwidth between the client and the server is very low. And, in any case, subsequent runs of that thin client program should never again be as slow as the first time, even if BBjServices restarts, unless the user deletes the BBjServices’ cache or does a new, clean BBjServices install (with no class cache).

Server Caching

The first-time download consists of the thin client telling BBjServices what classes and resources it needs. BBjServices finds and sends the requested classes, while also caching that knowledge. All future thin client launches of that application against that BBjServices server will benefit from that cached knowledge, speeding them up considerably.

Server caching of classes continues during subsequent runs of thin client applications. BBjServices continues to gather information about what classes are usually requested together, and continues to optimize the cache for future downloads. After the first run (or two), the remote launcher (and presumably the rest of the network communication) is basically optimal – thin client startup and execution is at that point constrained solely by the network bandwidth and latency between the client and the server.

Pre-Loading the Server Cache

One way to speed up the first-time launch of a thin client program would be to preload the cache on your BBjServices server. To do this, run your BBj thin client application on any client computer once or twice before making the client installation available to “real” customers. This could include running from a test client computer, or even from a “beta test” client workstation. It is important that the client connect to the same production server that your customers will use, or they will not benefit from pre-loading the server cache.

Client Caching

As a further optimization, each individual thin client machine and user also keeps a local cache of all of the BBj resources that it gets from the server. The thin client will check the local cache for anything it needs before asking the server, which means that it may not need to download anything from the server after the first execution. This local cache is keyed by the server version information, which means that a stale cache should not be a concern. If you install a new version of BBjServices on the server the client will automatically know that the existing cache is invalid and start building a new local cache.

Summary

BBj Thin Client execution, including Desktop Apps, must download the classes it needs from the server in order to run. This process is automated, in that the client requests the classes and other resources it needs from the server, and the server finds and downloads them to the client.  There are two caches implemented, a Server Cache and a Client Cache, to optimize this class downloading.  In the final assessment, downloading required classes is designed to minimize network traffic, combining classes into sets that are downloaded with the minimum number of round-trips. Overall, this process delivers optimized remote deployment performance.

Additional Reading

For more information on optimizing the performance of your application code to reduce round-trips between the client and the server, see this article:

BUI to the Max – Amp Up and Fine-Tune (the Section on Performance is equally applicable to BBj Thin Client and Desktop applications as it is to BUI applications).