| Interface | Description | 
|---|---|
| ApplicationContext | 
 An application context for  
GatewayApplication. | 
| DiffusionGatewayFramework.Implementation | 
 Do not use - Use static methods on  
DiffusionGatewayFramework. | 
| GatewayApplication | 
 The interface that a Gateway Framework application must implement. 
 | 
| GatewayApplication.ApplicationDetails | 
 Basic details of the application. 
 | 
| GatewayApplication.ApplicationDetails.Builder | 
 A builder for application details. 
 | 
| GatewayFramework | 
 Gateway Framework. 
 | 
| GatewayMeterRegistry | 
 Interface to supply  
MeterRegistry instance and to provide useful
 utility methods to create tags which can be used by application and
 framework. | 
| HybridHandler<T> | 
 The interface that a hybrid handler must implement. 
 | 
| MissingTopicNotification | 
 Notification that a session has made a subscription request using a selector
 that does not match any topics. 
 | 
| MissingTopicNotificationHandler | 
 Handler called when any session subscribes using a topic selector that
 matches no topics. 
 | 
| PollingSourceHandler | 
 The interface that a polling source handler must implement. 
 | 
| Publisher | 
 Allows updates to be published to Diffusion by  
source
 handlers or hybrid handlers. | 
| ServiceDefinition | 
 A service definition contains the details of a service required when
 instantiating a  
ServiceHandler for the service. | 
| ServiceHandler | 
 Base interface for all service handlers. 
 | 
| ServiceType | 
 A service type. 
 | 
| SharedConfig | 
 Defines a SharedConfig. 
 | 
| SharedConfigType | 
 A sharedConfig type. 
 | 
| SinkHandler<T> | 
 The interface that a sink handler must implement. 
 | 
| SinkHandler.SinkServiceProperties | 
 The service properties that apply to the sink service. 
 | 
| SinkHandler.SinkServiceProperties.Builder | 
 A builder for sink service properties. 
 | 
| SourceHandler | 
 The base interface for source service handlers. 
 | 
| SourceHandler.SourceServiceProperties | 
 The properties that apply to topics created by and published to by the
 service. 
 | 
| SourceHandler.SourceServiceProperties.Builder | 
 A builder for source service properties. 
 | 
| StateHandler | 
 State Handler. 
 | 
| StreamingSourceHandler | 
 The interface that a streaming source handler must implement. 
 | 
| Subscriber | 
 A subscriber to be used to subscribe to or unsubscribe from Diffusion topics. 
 | 
| TopicProperties | 
 Diffusion topic properties. 
 | 
| UpdateContext | 
 A holder for the update context that contains the Gateway application-specific
 update context, which can be used to process the update. 
 | 
| Class | Description | 
|---|---|
| CustomPublisher<U,C extends UpdateContext> | 
 An extension of a  
Publisher that enables overriding the default
 publication mechanism in a specific type of Gateway application. | 
| Enum | Description | 
|---|---|
| DiffusionGatewayFramework | 
 Provides static methods for use with the Diffusion Gateway Framework. 
 | 
| ServiceHandler.PauseReason | 
 The reason that a service is being paused. 
 | 
| ServiceHandler.ResumeReason | 
 The reason that a service is being resumed. 
 | 
| ServiceMode | 
 Service mode of operation. 
 | 
| ServiceState | 
 Indicates the current state of a service. 
 | 
| SinkHandler.UnsubscriptionReason | 
 The reason for an unsubscription from a Diffusion topic. 
 | 
| StateHandler.Status | 
 Indicates the type of status being reported when using the
  
StateHandler.reportStatus(com.diffusiondata.gateway.framework.StateHandler.Status, java.lang.String, java.lang.String) method. | 
| TopicProperties.PersistencePolicy | 
 The persistence policy to be applied to topics created by the service. 
 | 
| TopicType | 
 Specifies a Diffusion topic type. 
 | 
| UpdateMode | 
 The update mode describes the style of updating that should be used
 when publishing to Diffusion. 
 | 
This API provides the ability to write applications that interact with a Diffusion server and either consume data from back end 'sources' and publish to Diffusion, or consume data from Diffusion and feed to back end 'sinks'.
In addition, it provides the ability to write applications that consume Diffusion topics and feed data directly back to other Diffusion topics. This mode of operation is a useful way to transform Diffusion topic data. In this mode, the application may have no need to interact with any back end system.
The API provides a simple framework for creating such applications without the need for any detailed knowledge of Diffusion. Such applications may be 'adapters' providing integration between Diffusion and other diverse data systems.
 To use the framework, an application must implement the
 GatewayApplication interface and also provide
 service handler
 implementations for services that the application is to provide.
 
A service is defined as a 'source' service, a 'sink' service, or a 'hybrid' service.
A 'source' service consumes data from some back end data source and publishes to Diffusion topics, either by streaming data updates from the back end or by polling the back end for updates.
A 'sink' service consumes streaming data from a Diffusion topic and publishes it to a back end 'sink'.
A 'hybrid' service is a combination of a 'sink' and 'source' service in that it both consumes data from Diffusion topics and can publish back to other Diffusion topics.
 An application must declare itself to the framework using the
 DiffusionGatewayFramework.start method. In this method, the application
 and the framework will be initialized and started.
 During the application initialization, the framework will call
 back on the application via its
 getApplicationDetails method to obtain basic details about the application
 and the 'service
 types' that it supports. There can be many instances of any service type,
 each with different parameters (for example, to consume from and publish to
 different topics). Each service type should have a JSON schema that defines
 the application-specific parameters that define the instance of the service.
 
 Applications may optionally make use of
 SharedConfigs. A sharedConfig
 may be used within the configuration to define common information about the
 service. For example, if many service types use the same connection details
 to the back end (for example, credentials), then they can use a common sharedConfig
 definition rather than providing the details separately for each service
 type. If a service uses a sharedConfig, then it will be provided by the
 framework when adding the service to the application. Applications that use
 sharedConfigs must define the
 'sharedConfig types'
 that the application supports and also return them via the
 GatewayApplication.getApplicationDetails()
 method. Each configured sharedConfig needs to name the sharedConfig type that defines
 it.
 The framework then calls the
 GatewayApplication#initialize method passing
 ApplicationContext
 containing application configuration details and other resources, which
 the application can use to initialize any resources as required.
 
The framework will then validate the configuration and ensure it is compatible with the service types declared by the application.
After initialization of the application, connection to the Diffusion server (using bootstrap connection parameters) will be established and the application will be registered with the server. If the application has connected previously, then the saved configuration of the application will be retrieved from the server (although there is an option to override this configuration with a locally supplied configuration if required).
 It then calls the
 start method to perform any initial
 startup processing defined in the application.
 
 For each configured service, the framework will call the appropriate factory
 method on the application to add the service, and the application must return
 a suitable implementation of a
 ServiceHandler to
 handle the back end access for the service.
 
 For example, if the configuration defines a service that is a 'streaming
 source' service, then the framework will call the
 addStreamingSource method. The application only needs to provide the factory
 methods for the service modes that it provides.
 
 Each handler will be started by the framework using the
 start
 method. The handler should not process any back end interactions until this
 has been called and must stop processing when
 stop is
 called.
 
Applications are monitored and controlled from the Diffusion management console. The console may be used to add new services of the supported types, and one of the 'add' methods will be called on the application if this occurs.
 Additionally, the console may remove or update services. In the case of
 removal, the framework will first call the
 ServiceHandler to
 stop the
 service (if it is running). In the case of updating the service, the
 framework will first remove the service as above and then add it again using
 the appropriate 'add' method.
Copyright © 2025 DiffusionData Limited. All rights reserved.