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.

EPAM B2BITS FIXEdge Java

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:

  • FIX Engine is able to handle more than 500 sessions
  • The maximal total steady throughput is about 500000 msg/sec
  • The memory consumption and release through  GC is stable

Latest performance testing results for FIXEdge Java can be found  here.

FIX standard support

FIXEdge Java ensures FIX standard compliance by supporting:

  • FIX 4.0 - FIXT 1.1 session-level FIX versions
  • FIX 4.0 - FIXLatest application-level FIX versions
  • Customizable FIX dictionaries
  • All FIX message types (pre-trade, trade, post-trade and market data)
  • QuickFIX-formatted dictionaries
  • FIX messages validation
  • Custom Logon messages
  • Guaranteed delivery:
    • Relies on the store and forward technique
    • Flat files are used for persistence to achieve maximum performance
  • High-presision timestamps in accordance with MiFID II requirements

Session management

  • Based on FIX Antenna Java functionality
  • Configure and run acceptor and initiator sessions separately or/and by groups
  • Authorize using username and password fields in Logon message
  • Incoming and outgoing sequence numbers management
  • Intraday logout tolerance

Smart session scheduling:

  • CRON expressions for sessions schedule accurate to the second
  • Support of different time zones
  • Ability to assign one schedule to multiple sessions or configure it per session

Delivery modes

  • Undelivered messages are provided to the counterparty on connection via FIX standard resend request mechanism
  • Later delivery mode allows unsent messages to be stored in the queue and delivered later by schedule or when connection is re-established
  • Rejecting mode allows rejecting messages that cannot be sent during some reasonable and customizable time period
  • Configurable throttling of incoming messages

Message routing and transformation

Connectivity

Persistence API

  • Easy and fast way to store data in PersistentSequence and PersistentQueue storages
  • FIX Antenna Java is integrated with Persistent API:
    • Transient sessions support (no persistence)
    • Significant performance increase while forgoing recovery
    • Applicable when recovery is not required (e.g. for market data) or when persistence is done by application logic
  • Easy leveraging of Persistence API to create proprietary storage

Security

  • Standard FIX authorization utilizing username and password fields in FIX Logon message
  • Use of LDAP as an authentication service for incoming sessions
  • Spring Security framework for authentication purposes
  • Built-in SSL/TLS support
  • Support of SSL certificates with passwords
  • List of available ciphers for secure connections
  • Initiator sessions can use a certificate signed by counterparty's CA certificate for authentication
  • Acceptor sessions can have dedicated port

Monitoring and administration

High availability

Modularity

  • Modular structure where each module can work independently or be coupled with other modules, depending on user needs

Packaging

FIXEdge Java is distributed as an Linux native installation package (DEB,RPM).

The package includes:

  • Binaries (executable and libraries)
  • Scripts to register/unregister/start/stop FIXEdge Java as service/daemon
  • Default configuration files
  • Documentation
  • Software escrow is available on demand

FIXEdge Java package is available as a Docker container.

Platforms

Operating System
  • Windows 10
  • Windows 11
  • Ubuntu Linux 20.04
  • Ubuntu Linux 22.04
  • Rocky Linux 8
  • Rocky Linux 9
  • CentOS Linux 7
  • Other Linux distributions
  • Docker
Any platform is available with JVM.
Can't find your platform in the table?

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. 

more details

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.

more details

WebSockets

WebSockets Adapter is intended for full-duplex communication between the FIXEdge Java and web applications.

more details

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.

more details

Camel

Camel Adapter is intended to communicate FIX messages to/from third-party applications via Camel routes.

more details

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).

FIX server Java Cluster

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.