Advantages vs.
Swing and Java Web Start

Three key advantages of ULC applications vis-a-vis conventional Swing applications:

UltraLightClient (ULC) is an add-on technology to Swing rather than a competitor. While conventional Swing applications have a client-side architecture, ULC offers the technology required to leverage Swing's functionality in a server-side web architecture.

ULC compared to Swing

Diagram comparing architectures of UltraLightClient and Swing

No Application Deployment on Client

ULC applications are deployed on the server. The UI is executed by a Presentation Engine that resolves the deployment issues of conventional Java clients:

Application Deployment on Client

Conventional Swing applications are deployed on the client, which is often difficult:

  • the Presentation Engine serves any number of applications, like a browser.
  • each application requires a client-side deployment.
  • the size of the Presentation Engine is small.
  • the size of the client-side deployment is large.
  • the Presentation Engine supports multiple JRE releases. It works out-of-the-box on many clients, because most clients have some version of Java installed, either as a browser plug-in, or on the desktop.
  • each client application requires a specific JRE release. The latter is often not available on the client and difficult to install because other applications require a different release.
As a result, this Presentation Engine can be easily downloaded and executed as an Applet at runtime. Likewise, its deployment with Java Web Start or other mechanisms is substantially simplified. Due to these three characteristics, client deployment as an Applet is often impossible. Likewise, distribution with Java Web Start or other mechanisms is often too difficult in heterogeneous environments.

Scalable Server-side Architecture

Both the programming model and the execution model of ULC are server-side. Applications are installed and executed on the server. The client executes a compiled Presentation Engine that is independent of individual applications. As a consequence,

Client-side or Distributed Architecture

Swing applications have a client-side or distributed programming model and execution model. The code for the rich UI executes on the client, possibly together with business logic. As a consequence,
  • the developer is alleviated from the difficult issue of distributing logic between client and server.
  • the developer has to distribute logic between client and server, which is expensive and error-prone.
  • applications are easy to scale up for thousands of users, because
    - client/server interaction is built-in and highly optimized, and
    - standard Java EE is supported out of the box.
  • applications are often difficult to scale up, because
    - client/server interaction has to be optimized for each application, and
    - server-side scaling options must be evaluated for each application.
  • applications are easy to protect against security attacks, because the client executes the Presentation Engine only.
  • applications are difficult to protect against security attacks, because the architecture allows executing any kind of code on the client.
  • applications can share the entire software platform with HTML applications and are easy to integrate with HTML applications.
  • applications need their own software platform and are difficult to integrate with HTML applications.

Versatile Applications

ULC offers two features that lead to outstandingly versatile applications:

Single Purpose Applications

Swing offers no out-of-the-box support for versatility of applications:
  • the built-in distribution of logic between client and server enables applications to run both as multi-user server applications and single-user client applications.
  • the developer distributes logic between client and server, which leads to rigid operating scenarios.
  • the abstract API to the infrastructure enables deploying applications in any web container or stand-alone, without changing the code.
  • the developer has direct access to the infrastructure, which leads to hard-coded dependencies.
It is easy to build applications that can be executed in multiple operating scenarios: within a corporate network, over the internet, and even stand-alone. The latter option is particularly useful for the development of applications that run both on- and offline. Applications are typically built for a single purpose and operating scenario: either as a client/server application running within a corporate network, a client/server application running over the Intranet, or a stand-alone application.