Webflux-based applications

Creating an application reactor project

The base for all webflux-based application is a so called reactor project. The GIT repository contains the reactor project. For this reason, branching is performed on the reactor project level which turned out as quite handy.

1. Create a new Maven project
2. Select the 'fcc-webflux-javafx-template' archetype.
   
3. Specify the archetype parameters. Read the help texts carefully or use the screenshot below as template.
   • Group Id Use de.gsi.fcc.applications
   • Artifact Id The name of the created reactor project. It's recommended to name it 'MYAPPNAME-reactor'. In this example MYAPPNAME is 'device-scheduler'.
   • Version Use the snapshot version currently used in the development environment e.g. '16.1.0-SNAPSHOT'.
   • Package Enter the package name. This name will be automatically derived from Artifact Id. Please remove 'reactor', which is appended automatically and use points instead of dashes/underscores.
   • name Used in app title. In a reactor project called 'myappname-reactor' this could be e.g. 'My App Name'.
   • description: Enter a meaningful description.
   • moduleClassPrefix Use as class name prefix. When the reactor is called 'device-scheduler-reactor' this should be something like 'DeviceScheduler'.
   • modulePrefix Used as prefix for the actual maven projects inside the reactor. In a reactor project called 'myappname-reactor' this should be 'myappname'.
     
4. After the project has been created the following projects should have been created:

• MYAPPNAME-base-lib
• MYAPPNAME-service-lib
• MYAPPNAME-client-lib
• MYAPPNAME-app-fx

Getting started

2-tier only

1. Identify which information must be transformed to and from the client. Define these methods in you APPNAMEService interface in the base project.
2. Create immutable domain objects in the base project if needed.
3. Implement these methods in the APPNAMEServiceImpl class in the service project.
4. Use the methods in you client or application.

3-tier

1. Create DTOs for the domain objects in the base project.
2. Extend the REST Controller class in the service project (server package).
3. Extend the WebFluxClient class.

The app reactor project

This is the project created by the archetype. The actual project names depend on the names and identifiers entered during the creation of the reactor project.

The base project

The base project is based on webflux-base-lib. It is used by both client and service project.

It contains domain objects and the actual service interface. It also contains classes for data transport (DTOs). The domain objects should contain only data required for communication between service and client. Existing domain objects should not be used directly.

The service project

The service project is based on the webflux-service-lib project. It is used by the client in 2-tier mode. The project is the workhorse of the whole app. The application service interface is implemented here. All heavy dependencies should be placed here.

The client project

2-tier: The client lib is based on the actual service lib and the webflux-client-lib.
3-tier: The client lib is based on the actual base lib and the webflux-client-lib.
The client project includes the ServiceProvider class which can be used to execute service methods from the client.
Having a client project separate from the actual application project can be used to easily create service-to-service communication based on webflux.
The project can also be used to include non UI-framework-dependent code e.g. for performance reasons. This should be avoided but may make sense in some cases.

The app-fx project

The app-fx project is based on webflux-uilib-fx and the actual client lib..
This is the actual application class of the project. Only this project can contain UI-framework-dependent code.
If possible it should be limited to visualising data received from the service and sending entered data to the service.

webflux-reactor

webflux-reactor is the base project for all app reactor projects. It contains common code for webflux-based applications services.

webflux-base-lib

• BasicWebFluxService. This basic service class provides methods which can be directly. Currently there is just one method called messages(), which can be used to transport localized messages to a client.
• The domain package contains immutable java classes. The domain.dto package contains the corresponding DTO classes.

webflux-service-lib

• ServerBase: Main server class loads default properties and optionally LSA properties. Optionally loads an application-defined properties file.
• utils package:
  • AbstractSubscription: A base class for subscriptions. Based on StatusSubscription class in ionsource.
  • Messanger/Messages: Provides sending localized messages to a client.
  • A few more utility classes
• service package: BasicWebFluxServiceImpl: Basic service implementation. Currently there is just the implementation for the messages() method.

webflux-client

• WebFluxClient: Encapsulates access to a webflux service in 3-tier.
• BaseWebFluxClient: Client implementation of BasicWebFluxService.
• WebFluxServiceProvider: Abstract base class for accesing Used to access the methods provided by the server. Derived class implemented in generated project.

webflux-uilib-fx

• GsiWebFluxApplicationBase: Base class for all webflux-based applications. Extends the GsiApplicationBase by adding methods useful for handling the localized message handling.

Sample service methods

DataGrid / DataGridError

Demonstrates a subscription (based on AbstractSubscription). Subscriptions are performed as Flux objects.

DataPoint

Demonstrates setting a value just once and setting a value. Retrieving a value is performed using Mono objects.

Flux framework

You can find a list of useful resources in the internal Applications wiki

2-tier mode

Running in 2tier mode is currently the default behavior and requires no addtional configuration.

3-tier mode

Transferring data in 3-tier mode

The application must have been prepared to transport data between service and client properly. This requires creating data transport objects (DTOs) as well as defining endpoints on both service and client side.

Running in 3-tier mode

There is currently no production environment start for webflux-based applications. You can still test this locally though.

Define the server port by specifying the VM argument -Dserver.port=9090 Make sure the is no other server running on this port or choose another.

The application reads the host and the port of the server from a config file. To start the application use the VM argument -Dapp.architecture=3-tier

TBD

• There are currently language files in both service and client project. There are no commonly used language files for now.

ToDo

The remaining tasks should be created in Jira.

• Use maven profiles (or whatever) to use service dependency in 2-tier, but not in 3-tier
• Load default properties in client/app-fx? Not required currently but performed in GsiApplicationBase
• Fix warning related to 'parent.relativePath'.
• ReadTimeoutExceptions when using messages() in 3-tier mode.