FIXEdge® Java (FEJ) is an application server providing FIX connectivity. Orders routing to multiple destinations, receiving and distributing executions to internal systems, fanning out quotes and receiving market data, capturing and reporting trades are just few use case examples covered by FEJ. Unique internal architecture allows supporting balance between flexibility and high-performance requirements.
FEJ is also used as a generic message switch, as an integration server, routing and converting data between different FIX protocol versions and /or XML. Its open architecture allows plugin modules to integrate proprietary transport and data formats.
FEJ's FIX sessions management mechanism is built on top of FIX Antenna Java and inherits most parts of its functionality, including zero GC and strong optimization for low latency FIX message processing.
Features
Feature | Description |
---|---|
High throughput / low latency |
FIXEdge Java leverages FIX Antenna Java Engine's performance. The engine has been benchmarked on this hardware with the following results:
Latest performance testing results for FIXEdge Java can be found here. |
FIX standard support |
FIXEdge Java ensures FIX standard compliance by supporting:
|
Session management |
|
Delivery modes |
|
Message routing and transformation |
|
Connectivity |
|
Persistence API |
|
Security |
|
Monitoring and administration |
|
High availability |
|
Modularity |
|
Packaging |
FIXEdge Java is distributed as an Linux native installation package (DEB,RPM). The package includes:
FIXEdge Java package is available as a Docker container. |
Platforms
Operating System |
|
Transports
Additional non-FIX transports are available via pluggable transport adaptors.
Transport Adaptor | Description |
---|---|
Kafka |
Kafka Adapter is intended to communicate FIX messages to other applications using the Kafka streaming platform as middleware. |
JMS |
JMS Adaptor for FIXEdge Java is intended for communication between FEJ and third-party applications via JMS. The JMS Adaptor is a library that exposes a set of methods for communicating with FEJ's Transport Layer. |
WebSockets |
WebSockets Adapter is intended for full-duplex communication between the FIXEdge Java and web applications. |
SMTP |
SMTP Adaptor is intended to send (via email) FIX messages from FIXEdge Java to clients using the SMTP protocol; FIX email message can be automatically converted to a standard email message. |
Camel |
Camel Adapter is intended to communicate FIX messages to/from third-party applications via Camel routes. |
Transformation and routing
FIXEdge Java provides users with the ability to configure business rules to filter, transform, and route FIX messages, and handle session events using highly customizable Groovy scripts and pure Java code.
However, to enable non-programmers to intuitively author and maintain business rules Groovy DSL (Domain Specific Language) was implemented.
Groovy DSL covers most use cases in FIX protocol-defined workflows: routing to endpoints, FIX message transformation, and handling of important session management events. It supports both a declarative style of writing rules for unconditional routing "from <endpoint A> to <endpoint B>" and an imperative style where DSL conditional logic and executable actions are expressed explicitly for a given session and selected set of fields.
The DSL message rules are defined by the description and bound for the processing of incoming messages from a particular session or group of sessions.The DSL-defined business rules are stored in a way similar to the rules expressed in Groovy or Java. The rules.groovy configuration file allows mixing and matching DSL with pure Groovy and Java code for backward compatibility and complex cases with message enrichment. The processing of DSL-expressed rules is as efficient as Groovy and Java written rules.
Pure Groovy | Groovy DSL Rule |
---|---|
// Unconditional Routing Rule messageRule("From session3 to session4") .sourceCondition( { source -> source.id == "session3" }) .action( { ctx -> try { routingContext.getDestinationById("session4").send(ctx.messageEvent) } catch (all) { logger.error(all.getMessage(), all) } }) .build(), |
// Unconditional Routing Rule rulesDSL(routingContext as RoutingContext) { routing { from "session3" to "session4" } }
|
// Routing Message Rule messageRule("Routing Rule sample") .sourceCondition( { source -> source.id == "session2" }) .condition( { ctx -> ctx.getMessage().getTagValueAsString(35) == "D" }) .action( { ctx -> logger.info("Send message to: session1") try { routingContext.getDestinationById("session1").send(ctx.messageEvent) ctx.exit() } catch (all) { logger.error(all.getMessage(), all) } }) .build(), |
// Routing Message Rule rulesDSL(routingContext as RoutingContext) { messageRules { messageRule("From session2 all msg with type D route to session1") { source { id "session2" } condition { msgType "D" } action { sendTo "session1" context exit } } } } |
// Event Rule eventRule("FIX Session Connect") .eventType(FIXSessionStateEvent.class) .condition({ event -> return event.sessionId == "session1" && isConnected(event.sessionState as SessionState) }) .action({ event -> logger.info("[FIX Session Connect] Session is connected: session1") }) .build() |
//Event Rule rulesDSL(routingContext as RoutingContext) { eventRules { FixSessionStateEventRule("FIX Session Connect") { condition { session "session1" sessionState connected } action { log "[FIX Session Connect] Session is connected: session1" } } } } |
For detailed information on the rules language, consult our Groovy DSL Business Rules Guide.
High Availability
FIXEdge Java supports work in multiple node clusters with state replication, Failover and Recovery service is available as well.
Cluster archtecture provides users with the ability to:
- Automatically resolve and register FIXEdge Java servers as cluster nodes
- Define the primary node automatically at the initial start of the cluster
- Monitore and manage FIXEdge Java servers
- Control failover activities on a single node
Failover and Recovery service supports controlled manual failover for maintenance purposes.
Replication service maintains backup copies of primary Persistence API storages and supports an actual and ready-to-work copy of current data on standby servers within the cluster. Synchronous and asynchronous replication modes are available for FIX sessions.
- Synchronous replication mode is recommended for use when data loss is critical (e.g. order processing).
- Asynchronous replication mode is recommended for use when performance is very important, while the clear data is not essential, or data can be restored from other sources (e.g. market data processing).
Modularity
All major functionality of FEJ is implemented as a set of independent modules, which can be enabled or disabled separately. Each module is configurable and extendable.
Modules list:
- Transport modules
- FIX Antenna
- JMS Adaptor
- CME iLink connectivity
- Service modules
- Persistence API
- Cluster Manager
- Replication
- Monitoring
- Configuration
- Scheduling
- Logging
- Rule Engine module
- Dynamic Router
Administration
Interactive shell and JMX are used for FIXEdge Java administration. The main FEJ specific administration functions are:
- Start and stop FIX server
- Manage FIX connectivity on server and session levels
- Manage cluster service
For logs generation FEJ uses Log4j2 logging framework.
Built-in remote monitoring and administrative interface for sessions monitoring and management, inherited from FIX Antenna Java:
- Utilizing FIX protocol and the same FIX listen port for an administrative session
- Friendly XML-based DSL for administrative instructions: easy to read, easy to extend
- Rich UI for monitoring session statuses and parameters in real time on desktop app or web browser.
Administration functionality can be extended to manage each FEJ module separately.
Please contact us at sales@b2bits.com to obtain the free trial version of FIXEdge Java or for any additional information.