Architecture
This diagram illustrates the interactions among the parts of TIBCO® Messaging as messages flow between TIBCO FTL® clients and Kafka clients.
Message Flow
Messages flow among the parts in the lower level of the diagram. (Components in the upper level of the diagram play supporting roles outside the message path.)
Publishers in FTL applications (lower left, light blue) send FTL messages. The source connector in the FTL bridge can subscribe to those messages. When the bridge (green ellipse) receives FTL messages, it translates them to equivalent Kafka messages, and delivers them to the Kafka broker (light green). Subscribing Kafka applications (orange) can consume the messages from topics in the Kafka broker.
In the opposite direction, publishers in Kafka applications (orange) send Kafka messages to the Kafka broker (light green), which stores them in topics. The sink connector in the FTL bridge (green ellipse) consumes those messages, translates them to equivalent FTL messages, and publishes them on its endpoint. Subscribers in FTL applications (lower left, light blue) receive and process the messages.
Parts
- FTL clients rely on the realm server for realm configuration definitions (light blue lines). Clients also send their operating metrics to the realm server.
Notice that FTL bridge connectors are FTL application clients of the realm server.
- The schema repository relies on the realm server as back-end storage for schemas.
Notice that the schema repository is required only when the Kafka client applications use Avro messages.
Message Representations
- Avro Messages Apache Avro is a widely used, compact representation. Parsing is fast. Avro supports schema evolution and field name aliases.
- JSON String JSON strings impose a minimal structure.
- JSON Messages with Schemas Schemas can extend the scope of message interoperability to third-party Kafka sink connectors.