In the previous blog posts on Gluon Cloud, we explained the functionality provided by Gluon Cloud. We showed how you can synchronize data between application instances, and how to integrate Gluon Cloud with existing back-end systems and cloud providers. Today, we will discuss the overarching role of Gluon Cloud in the client-server landscape.
History
One of the most important reasons why people use Java for development is because of the ‘Write Once Run Anywhere’ paradigm. Java source code is translated to Java bytecode, which can be executed in different environments, and using different mechanisms, e.g. by an interpreter, a JIT compiler or an AOT compiler. As a developer, you write code using the Java language and the Java APIs, and you don’t have to worry about how the code is actually executed.
When Sun announced the J2ME, J2SE and J2EE brands in 1999, some people were worried about fragmentation of the language. The message was though that you can use the same language and the same syntax in different environments. The different products J2ME, J2SE and J2EE provided different APIs for these different environments.
Many things have changed since 1999. Devices are now more powerful, and back-end systems are increasingly using cloud functionalities. However, the core principle still stand:
- You can use the Java language to write code for a wide range of devices from tiny embedded systems up to massive back-end systems
- The characteristics of the different environments provide different opportunities and encourage different patterns.
The Problem With Using Enterprise Frameworks On The Client
The JavaFX client platform does not exclude the usage of any Java server-side technology. It is entirely possible to combine a JavaFX client application with a Java EE application server. It is often tempting to do so, as this is similar to the way web clients are built: the web framework is often a component inside the enterprise application deployed on a backend system. Programming this web framework allows the same APIs to be used as the APIs in the enterprise application, as they live in the same container.
With JavaFX, the execution power shifts towards the client. The code needed to build and render a user interface is not executed on the server instance. JavaFX allows developers to decide on a balance between a thin client and a fat client. Regardless of how much logic is executed on the server or on the client, developers have to take into account that all code executed on the client runs in an environment that is very different from a server environment. When the client is a mobile or embedded device, these differences are often even more pronounced. Some of these differences are:
- Client systems have no load balancer with failover support
- The application developer can not control the other components on a client system. The end-user might be multitasking a lot, runs out of disk space or manually remove some files.
- The lifecycle management (install, start, pause, stop, uninstall, upgrade) of applications on the client is very different from typical server applications.
- Network connectivity is often different in a client situation. Connection is not always guaranteed, and even when there is a connection, there are differences. Some operations should only be executed when a wifi connection is available, some operations should not happen when the device is using roaming data.
- The power consumption of client devices is very different. When a device is connected to external power, it is typically allowed to act differently then when running on battery. When battery is running low, the applications running on a device are expected to behave differently to extend the life of the device so that it remains operational.
While these differences do not require you to use a different language, a different syntax, or even a different data model, they often require developers to apply different patterns than the common ones in enterprise and web development. A typical example is the case where a client component wants to send data to a back-end system. Using a web component, it is often fair to assume that the back-end system (assuming this is part of the same enterprise software) can take and handle requests. In a typical client application, this is often not the case. The network may be unavailable, or the user is currently not advised to use it for uploading large data sets. In this case, the consumer of the network call should be notified, and/or the application should behave accordingly — i.e. a friendly notification should be shown, an icon is displayed while the data is saved locally, and the data can be sent when a connection is available.
How Gluon Cloud Can Help
The role of Gluon Cloud, combined with the Gluon Mobile library, is to shield client developers from the typical infrastructure-related issues encountered with mobile and client development. Rather than creating your own failover boilerplate code and catching all possible exceptions when communicating with enterprise systems, or storing local and remote data, you can rely on Gluon Cloud to handle this for you. Of course Gluon Cloud can’t fix broken connectivity. But rather than throwing exceptions and requiring developers to come up with proper scenario’s, Gluon Cloud will manage this, and the Gluon Mobile APIs use the JavaFX property patterns to set state information when states are changing. As such, Gluon Cloud provides enterprise functionality in a way that is familiar to JavaFX developers.
Gluon Cloud provides the typical enterprise functionality, but in a way that works well with the JavaFX API and that takes into account the client-specific context we discussed above. Gluon Cloud itself is an enterprise application, and the communication between existing back-ends and cloud providers can leverage all patterns that are common in enterprise development. As stated yesterday, we are constantly improving the ability of Gluon Cloud to take advantage of existing back-end systems and cloud providers.
Summary
While it is theoretically possible to use existing enterprise code and patterns in JavaFX Client applications, it is often advised not to do so. The amount of boilerplate code required to deal with all possible situations that can occur on client systems is huge. On mobile and desktop systems, the situation is even more pronounced. Gluon Cloud is a great bridge that on one side allows Java Client developers to use and leverage JavaFX Client APIs, and on the other hand allows Java Enterprise developers to use their favorite tools, patterns and libraries.