Evento Framework
  • Introduction
  • Architecture Overview
    • Distributed Systems & Microservices
    • Recative Manifesto & Reactive Principles
    • State-of-the-art Patterns
      • DDD (Domain Driven Design)
      • CQRS (Command Query Responsability Separation)
      • Event Sourcing
      • Messaging
      • Saga
  • GETTING STARTED
    • Quick Start
    • TodoList - RECQ Tutorial
      • Problem Description and Requirement Gathering
      • RECQ Payload Design
      • RECQ Components Design
      • Set up your Development Environment
      • RECQ Payload Evento Implementation
        • Domain Commands
        • Domain Events
        • Views
        • Queries
      • RECQ Components Evento Implementation with Spring Data
        • TodoListAggregate
        • TodoList Model with Spring Data
        • TodoListProjector
        • TodoListProjection
        • TodoList Invoker
      • Expose the RECQ architecture with Spring Web
      • Test Your App
    • Extend TodoList - Handle Complexity Tutorial
      • Unique identifier generation
      • Extends behaviors with Observer and Services
      • Cross Domain Consistency with Sagas
      • Handle Real time data updates with MQTT and Save-Notify Pattern
  • RECQ Patterns
    • RECQ Patterns
    • RECQ System Pattern
      • Component
      • Message Gateway
      • System State Store
    • RECQ Communication Pattern
      • Component to Component
      • Component to System State Store
      • System State Store to Component
    • RECQ Component Pattern
      • Aggregate
      • Projector
      • Projection
      • Service
      • Invoker
      • Saga
      • Observer
  • Evento Framework
    • Evento Framework Introcution
    • Payload and Messages
      • Command
        • Domain Command
        • Service Command
      • Event
        • Domain and Service Event
      • Query and View
    • @Component
      • @Aggregate
        • Aggregate State
        • @AggregateCommandHandler
        • @EventSourcingHandler
      • @Projector
        • Projector @EventHandler
      • @Projection
        • @QueryHandler
      • @Service
        • @CommandHandler
      • @Invoker
      • @Saga
        • SagaState
        • @SagaEventHandler
      • @Observer
    • Dead Event Queues
    • EventoBundle
      • EventoServerMessageBusConfiguration
      • ConsumerStateStore
        • InMemoryConsumerStateStore
        • PostgresConsumerStateStore
        • MysqlConsumerStateStore
      • Context
      • TracingAgend and @Track
        • SentryTracingAgent
      • Autoscaling Protocol
        • ThreadCountAutoscalingProtocol
      • Injector and @Component
  • Evento Server
    • Evento Server Introduction
    • SetUp Evento Server
      • Advanced Options
      • Evento Event Store Modes: APES and CPES
    • Evento Server Cluster
    • Bundle Deploy Script
  • EVENTO GUI
    • Explore RECQ Systems Visually
    • GUI Auth
    • Payload Catalog
    • Component Catalog
    • Bundle Catalog
    • Cluster Status (Experimental)
    • Flows
      • Performance Evaluation
    • Application Graph
    • System State Store
  • Evento CLI
    • Evento CLI Introduction
    • Update Version
    • Publish
Powered by GitBook
On this page
  1. RECQ Patterns
  2. RECQ System Pattern

Message Gateway

Facilitating Communication in a RECQ System

PreviousComponentNextSystem State Store

Last updated 1 year ago

The Message Gateway is the component in a RECQ architecture that acts as a central hub for message routing and communication between components. It promotes loose coupling and asynchronous communication by mediating interactions between components.

Why Use a Message Gateway?

  • Reduced Coupling: By routing messages through the gateway, components don't need to be aware of the specific location or implementation details of other components they need to interact with. This reduces coupling and simplifies development and maintenance.

  • Centralized Message Routing: The gateway can implement routing logic to determine the appropriate recipient component for a message based on its content or message type.

  • Message Transformation and Validation (Optional): The gateway can potentially transform messages to a common format or validate messages before sending them to the recipient component.

Message Gateway Functionality:

  • :

    • The gateway implements the Publish/Async Response pattern for command-like messages.

    • It uses correlation IDs to associate responses with the original requests, enabling the sender to identify the corresponding result.

Sub-Modules of the Message Gateway:

  • Command Gateway:

    • This sub-module facilitates sending commands to the system.

    • It typically exposes a single asynchronous method called "send" which accepts a message of type "Command" as input.

    • Upon sending the command, the gateway may:

      • Route the command to the appropriate Command Service based on the command type.

      • Return the event generated by the component that handled the command (if successful).

      • Return a failure message if the command execution fails.

  • Query Gateway:

    • This sub-module facilitates sending queries to the system.

    • It typically exposes a single asynchronous method called "query" which takes a message of type "Query" as input.

    • The gateway routes the query to the appropriate Query Service.

    • It then receives and returns an object of type "QueryResponse" containing the data retrieved by the Query Service.

Benefits of Using a Message Gateway:

  • Improved Maintainability: Centralized message routing simplifies changes to message formats or routing logic.

  • Enhanced Monitoring and Tracing: The gateway can act as a central point for monitoring message flows and tracing requests/responses within the system.

  • Potential Security Advantages: The gateway can be used to implement security measures like message authorization or encryption.

Considerations:

  • Introducing a message gateway adds another layer of complexity to the system.

  • It may introduce a single point of failure if not designed and implemented with proper redundancy and fault tolerance.

Conclusion:

The Message Gateway can be a valuable tool in a RECQ architecture by promoting loose coupling and simplifying communication between components.

Publish/Async Response Pattern with Correlation IDs
Message Gateway Structure