Spring is a popular DI container in the java world, this tutorial demonstrates how the construction logic of spring can
be combined with the dispatching logic of Fluxtion to simplify building event driven applications. The goal is to allow
the developer to concentrate on developing application logic while the container automatically builds the object graph
and constructs event dispatch logic.
Fluxtion is a dependency injection container specialised for event driven application deployments. The container
exposes event consumer end-points, routing events as methods calls to beans within the running container. A bean
registers a method as an event-handler by using Fluxtion annotations. Any beans referencing an event-handler bean will
be triggered by the container as the internal dispatcher propagates an event notification through the object graph.
All methods on an interface can be exported by annotating the interface in an implementing bean, the container exports
the interface methods as a single service. A client can look up an exported service by interface type using the
container apis. All method calls on the service proxy are routed through the container’s internal dispatcher.
This example builds a small banking application, that supports credit, debit, account query, credit checking,
opening hours and persistence functions. The methods are grouped into service interfaces that are exposed by the
container.
The steps to combine spring and fluxtion:
Create service interfaces that define the api of the banking app
Create implementing classes for the service interfaces
Create a spring config file declaring instances the DI container will manage
Use Fluxtion annotations to export services and define event notification methods
Pass the spring config file to the Fluxtion compiler and generate the DI container AOT
Create an instance of the DI container and locate the service interfaces
Use the service interfaces in the sample application
service: interfaces the sample main and banking app invoke
node: implementations of the service interfaces
data: data types used by services
generation: location of the Fluxtion ahead of time generated DI container
Spring beans
Fluxtion provides support for building the DI container using spring configuration. The example uses a spring
configuration file to declare the beans that will be managed by the Fluxtion DI container:
Once the file is created the file location can be passed to Fluxtion to build the container:
Invoking a service
The BankingApp instance creates an instance of the AOT generated Fluxtion DI container and provides access to container
exported services. The service reference the client code receives is a proxy the DI container creates, the
proxy handler routes method calls to instances managed by the container.
Services the DI container exposes are event driven, they are designed to be invoked asynchronously and do not return
application values to client code. A service method can optionally return a boolean value that is used by the container
as an event propagation flag. If the flag is true then child references are notified the parent has changed due to an
external event. Child instances are notified of event propagation by the container calling a trigger method. A trigger
method is any zero argument method marked with an OnTrigger annotation. OnTrigger methods return an event
propagation flag to control event notification dispatch in the same was as exported service methods.
The fluxtion DI container manages all the proxy creation, event dispatch to services, monitoring dirty flags and
propagating event notifications to child references. To access an exported service client code calls:
Main method execution
The main method creates an instance of the BankingApp, rerieves service interfaces and invokes application methods on
the interfaces. It is expected the BankingApp would be instantiated and used within a larger application that marshalls
client requests from the network and then invokes the BankingApp appropiately.
running the main method prints the following to the console:
Exporting a service
To export a service the following steps are required:
Create an interface and then implement the interface with a concrete class
The implementation class must extend ExportFunctionNode
Mark the interface to export with @ExportService annotation
For example to export the CreditCheck service:
CreditCheck interface
CreditCheckNode concrete class
The CreditCheckNode implements two interfaces CreditCheck and TransactionProcessor. Only the CreditCheck interface
methods are exported as this is only interface marked with @ExportService
Notice the two CreditCheck methods are annotated with @NoPropagateFunction, telling Fluxtion that no event
propagation will occur when either of these methods is invoked. The credit black list is a map and these methods should
only change the state of the internal map and not cause further processing to occur in the object graph.
Locating a service
The steps required to locate a service and invoke methods on it are:
Build the DI container using one of the Fluxtion build methods
To correctly intitialise the container call eventProcessor.init() on the DI instance
To access the service call T service = eventProcessor.getExportedService() with the desired service type T
Accessing CreditCheck service
The code below uses an enum to allow the user to select the DI generation strategy, in this example we are using the
AOT strategy. After eventprocessor generation the exported service are located and assigned to member variables in
the BankingApp class.